You probably already know your mobile payment security has gaps. The harder problem is that you cannot point to exactly where they start. Without knowing where the gap begins, you cannot scope it, you cannot prioritise it, and you cannot explain it to anyone who needs to act on it.
PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1 give you the framework to answer that question precisely. Both requirements target client-side execution risk, specifically scripts and HTTP headers as received by the consumer’s browser, because the browser is the only place where what actually executed during a payment session can be observed.Â
That scope is clear on desktop web. On mobile, your execution environment splits into two layers, and most compliance programmes are only watching one of them. That is where the gap you are already sensing actually lives.
What you’ll learn
- Why mobile PCI DSS scope splits into two execution layers (mobile browser/WebView vs native app runtime), and where “desktop-only monitoring” leaves blind spots.
- How Requirements 6.4.3 and 11.6.1 apply across mobile web, native in-app payments, and WebView checkout, including the most common scope-assumption failures.
- How to build defensible coverage across both layers with audit-ready evidence: continuous script/header governance for browser contexts plus continuous SDK/runtime visibility between app releases.
Why mobile is a different compliance problem than you may think
When your customers check out on mobile, you are not dealing with one execution layer. You are dealing with two. Mobile browsers work the same way desktop browsers do from PCI’s perspective, so Requirements 6.4.3 and 11.6.1 apply directly to your mobile web checkout. But if you also have a native app, your compiled code and third-party SDKs are running inside a device runtime that is harder to audit and significantly slower to update than anything on your web server.
And if your app uses in-app WebViews for payment, those two layers are collapsing into each other in a way that carries risk from both environments simultaneously.
That matters because PCI itself states that the consumer’s browser is the only place where malicious payment-page activity can be reliably detected. If your customers are completing checkout in mobile browsers and WebViews, that statement applies to your mobile environment just as much as it does to your desktop environment. A compliance programme that only monitors your desktop checkout is covering part of the problem while leaving the rest unobserved.
Where your mobile programme is probably falling short
The gaps in mobile PCI compliance tend to cluster around scope assumptions rather than missing policies, and there is a good chance at least one of these applies to your environment.
The most common failure is excluding mobile payment pages from your monitoring scope.
PCI is explicit that embedding a third-party payment form does not remove your parent page from scope for Requirements 6.4.3 and 11.6.1. If you are monitoring your desktop checkout but not your mobile checkout route, including any single-page application views that conditionally load scripts for mobile devices, your control exists on paper while failing in practice.
The second gap is treating your WebView payments as a UI detail.Â
If your app uses a WebView for checkout, that flow can simultaneously require payment-page script governance and app-runtime controls. Most teams apply neither consistently, not because they are being careless, but because the WebView sits between two compliance frames and gets claimed by neither.
And the third gap is assuming your payment SDK provider has covered the risk.
OWASP’s mobile supply chain risk guidance is clear that third-party SDK dependencies can carry vulnerabilities that are difficult to detect. PCI scoping is equally clear that any technology which can influence the security of cardholder data is in scope, regardless of whether you store the PAN directly. If an SDK runs in the same process as payment entry and tokenisation, it is in scope, and it is your responsibility to demonstrate control over it.
Understanding where those gaps live requires understanding where payment execution actually happens across your mobile environment.
The three ways your mobile checkout might be running
Your mobile commerce environment likely uses one or more of these execution patterns, and your PCI scope needs to track where execution happens rather than where the UI appears.
Mobile web checkout runs in a mobile browser, making it the most direct application of Requirements 6.4.3 and 11.6.1. Native in-app payment entry runs inside your app binary through compiled code and embedded SDKs. In-app WebView checkout renders web content inside your app context and sits between both patterns, triggering compliance obligations from each. The table below maps how those differences affect your security posture and PCI scope.
Why your WebViews need their own compliance thinking
If your app uses WebViews for payment, you are dealing with the most compliance-complex pattern in mobile commerce. A WebView executes web content inside your native app, which means JavaScript in the WebView can be manipulated just as it can on any payment page, while native code in your surrounding app can intercept data crossing the WebView boundary.
PCI’s payment-page security supplement explicitly addresses how Requirements 6.4.3 and 11.6.1 apply to embedded payment forms and script-based redirection mechanisms, both of which appear in WebView payment flows.
If you approach your WebView checkout as “just the app,” you miss the script governance obligations. If you approach it as “just a web page,” you miss the native interception risk. Your WebView payment flow requires both lenses applied together, and it is the part of your mobile environment where treating compliance as a single-channel problem will most reliably create a gap.
What Requirement 6.4.3 requires you to do on mobile
Requirement 6.4.3 has three components you need to address: a method to confirm each payment-page script is authorised, a method to assure script integrity, and a maintained inventory with written justification for each script.
The intent, as PCI’s customised approach objective states, is that unauthorised code must not be able to execute in your payment page as rendered in the consumer’s browser.
For your mobile web checkout
Your inventory needs to reflect what is actually loaded in a mobile browser session. Conditional script loading for mobile devices is common, and if your checkout is a single-page application, it can behave as one continuous page across multiple views. If your authorisation and integrity controls were built around the desktop-rendered version of your checkout, they are likely missing scripts that only appear in the mobile-rendered path.
For your native app
Requirement 6.4.3 is triggered directly when your app uses browser-mediated payment entry, including WebViews. Where your checkout is purely native, assessor expectations still point in the same direction: third-party code that can influence payment data entry needs to be inventoried, justified, and controlled. In practice, this means translating 6.4.3’s control intent into SDK governance in your build pipeline, covering inventory, justification, authorisation, and integrity verification.
That translation is where you close the gap between what PCI demands on web payment pages and what your native app actually executes.
What Requirement 11.6.1 requires you to do on mobile
Requirement 11.6.1 requires a mechanism that detects and alerts on unauthorized modifications to security-impacting HTTP headers and script contents of your payment pages as received by the consumer’s browser, running at minimum weekly. PCI’s own rationale states that because web pages are assembled from multiple locations, the only place to detect changes or indicators of malicious activity is in the consumer browser as the page is constructed and all JavaScript interpreted.
Why this changes your monitoring approach
If your customers are completing checkout in mobile browsers and in-app WebViews, that consumer browser layer includes your mobile environment. Periodic server-side file integrity monitoring does not satisfy this requirement because it does not reflect what was delivered and executed in your users’ actual sessions.
Your monitoring needs to be tuned to mobile user agents and WebView contexts to reflect what your mobile customers actually receive.
The release cycle problem you cannot ignore
For your native app, the compliance risk from 11.6.1 is unauthorised changes in your execution environment that could enable payment data theft. The mobile release cycle makes this more urgent than it is on web. App store review and user adoption mean that when you find something, your fix will take time to reach the users who need it.
Runtime detection and continuous evidence collection between your releases are not optional enhancements. They are what keeps your compliance posture defensible while a remediation works its way through your pipeline.
How MobileGuard AI and PaymentGuard AI cover both layers of your environment
The practical challenge you are likely facing is that you are running several of these patterns simultaneously: mobile web checkout, native in-app payments, and hybrid WebView flows. PaymentGuard AI addresses your browser layer directly, automating Requirements 6.4.3 and 11.6.1 for your payment pages and iframes with continuous script inventory and authorisation reporting, integrity verification and alerting, and audit-ready compliance evidence.
MobileGuard AI addresses your app-runtime layer, giving you continuous visibility into your SDKs, data flows, and API behaviours, with real-time detection of new or changed SDK activity as your app updates between releases.
Together, they give you what a defensible mobile PCI programme requires across both channels: an inventory of what executed in your environment, proof that what executed was authorised and intact, and timely alerts when execution drifted from your known-good baseline. For your WebView checkout, which sits at the intersection of both layers, the combined coverage closes the gap that any single-channel solution will leave open.
The compliance posture you actually need for mobile
Mobile commerce PCI DSS compliance is not a harder version of web compliance. It is a broader problem spanning two execution layers in your environment, with different evidence requirements, different update constraints, and different attack vectors at each layer. Requirements 6.4.3 and 11.6.1 apply to your mobile web and WebView payment flows directly, and signal the same control expectations for your native app payment flows.
If you are ready to assess where your current mobile payment security stands against these requirements, MobileGuard AI and PaymentGuard AI give you unified visibility across your entire mobile commerce environment.
