They should document the boundary explicitly: the PSP may secure the hosted iframe, but the merchant still owns the parent page, browser execution, and local monitoring. Clear ownership prevents gaps where each side assumes the other is covering runtime integrity.
Where PCI DSS and PSP responsibilities overlap
When a payment service provider hosts part of the checkout flow, the merchant should treat the boundary as an explicit control decision, not an assumption. The hosted iframe may be the PSP’s responsibility, but the merchant still controls the surrounding page, browser-side execution, tag injection paths, and local observability. That boundary should be written down, owned, and tested.
In practice, overlap is where confusion starts. A PSP can protect the hosted payment component, but it cannot compensate for weak merchant-side page integrity, third-party script drift, or missing monitoring on the customer’s browser session. The merchant’s job is to know exactly which assets remain in scope and which controls must still be evidenced locally.
That distinction matters because PCI DSS obligations are not eliminated by outsourcing. They are redistributed. The merchant needs a documented split that shows which party handles hosted UI security, sensitive input handling, and service integrity, and which party retains responsibility for the parent page, client-side trust boundary, and any anti-skimming monitoring that depends on the merchant environment.
What the merchant still owns even when the PSP hosts the iframe
The merchant still owns the security of the page that loads the iframe, including content integrity, script governance, and the browser context around the payment widget. If the parent page is compromised, a skimmer can observe keystrokes, alter form behaviour, or redirect data before it ever reaches the PSP. That is why the merchant cannot treat hosted checkout as a full handoff.
This is also where access and change control become relevant. Any script, tag manager, analytics tool, or front-end dependency that can modify the page can become part of the attack surface. If those controls are not reviewed and monitored, the PSP’s hosted component may remain intact while the merchant’s page becomes the path of compromise.
For guidance on boundary setting and mapped control ownership, the Identity Security Regulatory Map is useful for showing how payment, access, and governance obligations are split across parties. NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives also helps when the merchant needs to prove which runtime controls remain under its own operational control.
External guidance is strongest where it anchors the minimum payment-security expectation. The PCI Security Standards Council’s PCI DSS v4.0 document library is the primary reference for the control boundary, especially where least privilege, account handling, and environment-specific responsibilities must be evidenced.
How to document the boundary so anti-skimming controls do not get dropped
The most useful boundary document is short, explicit, and operational. It should identify the hosted PSP component, the merchant-owned parent page, who reviews browser-side changes, what monitoring exists for script integrity, and how exceptions are escalated. If the document cannot answer those points, the overlap is still ambiguous.
Good boundary language should also make failure states visible. For example, if the PSP confirms hosted field protections but the merchant cannot attest to page integrity checks or script governance, then the merchant has not fully discharged its side of the anti-skimming responsibility. The control gap is not theoretical, because browser-side attacks often exploit precisely that split.
Use the external standard and the supporting control model together. PCI DSS v4.0 sets the compliance baseline, while NIST SP 800-53 Rev 5 Security and Privacy Controls gives a broader control vocabulary for access control, audit, configuration management, and system integrity. CIS Controls v8 is also useful where the merchant needs a practical control set for asset, account, and logging discipline.
For browser-side assurance, the merchant should also consider front-end testing and configuration review as part of the same boundary, not as an afterthought. The point is not to prove the PSP is weak, but to prove the merchant knows exactly where its own detection and integrity obligations begin.
Why overlap creates skimming risk, and what practitioners should verify
Overlap becomes risky when each party assumes the other is watching the same failure mode. The PSP may assume the merchant will catch hostile page changes; the merchant may assume the PSP’s hosted field makes local integrity monitoring unnecessary. That gap is attractive to skimmers because it allows compromise in the merchant page while leaving the payment iframe untouched.
Failure mechanism: A malicious script, compromised third-party tag, or altered browser context intercepts payment data or changes where the data is sent, even though the PSP-hosted iframe remains legitimate.
Impact: Card data exposure, failed PCI evidence, and a misleadingly “secure” checkout flow that hides compromise until after transactions or customer reports reveal the issue.
Merchant teams should verify three things before they trust the design: first, who owns the parent-page integrity controls; second, what monitoring detects unexpected front-end changes; third, whether the PSP contract and the merchant’s own runbooks match the actual technical boundary. If those three do not align, the payment flow is still under-governed.
For a broader control perspective, ISO/IEC 27001:2022 Information Security Management is relevant where the merchant needs formal control ownership, change governance, and evidence retention around the checkout environment. The ISO/IEC 27002:2022 Information Security Controls guidance is useful for turning that ownership into implementable control statements.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while PCI DSS v4.0 and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | Req. 7, Req. 8 — Restrict Access and Identify Users | PCI DSS defines access and account responsibilities at the payment boundary. |
| Recommendation — Document which party owns hosted checkout controls and evidence the merchant-side boundary. | ||
| NIST SP 800-53 Rev 5 | CM-03 — Configuration Change Control | Checkout-page integrity depends on controlled changes to browser-side components. |
| AU-02 — Event Logging | Local monitoring is needed to detect tampering in the merchant-controlled page. | |
| Recommendation — Require formal approval and review for any front-end change that can affect payment flow. Log browser-side and checkout-page integrity events so tampering is detectable. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The merchant must define and evidence who controls each side of the checkout boundary. |
| Recommendation — Assign explicit control ownership for the merchant page, hosted iframe, and monitoring duties. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Front-end scripts and page assets need secure baseline configuration to resist skimming. |
| Recommendation — Harden and monitor web assets that execute around the payment iframe. | ||
Practitioner Guidance
What to prioritise: Put the boundary statement into the merchant’s PCI evidence pack and make sure it names the parent page, the PSP iframe, and the monitoring owner for each side. If the document only says “PSP handles checkout,” it is too vague to support assurance.
What to verify: Confirm that the merchant can still detect unexpected page changes, third-party script drift, and front-end tampering even when the payment fields are hosted elsewhere. The control is not credible unless the merchant can show some local visibility into the browser runtime.
Common mistake: Treating outsourced payment capture as outsourced checkout security. The hosted widget may reduce exposure, but it does not remove the merchant’s duty to secure the surrounding execution environment.
Practitioner takeaway: The safest operating model is explicit shared responsibility with no gray zone, because anti-skimming fails most often where the technical boundary is real but the ownership boundary is not.
Related resources from NHI Mgmt Group
- What breaks when merchants leave script management for PCI DSS 4.0 controls largely unmanaged?
- How should security teams implement anti-phishing controls to meet PCI DSS 4.0 requirements without disrupting legitimate email delivery?
- What happens when PCI DSS anti-phishing controls are delayed until the last minute?
- What is the difference between human IAM controls and NHI governance?