The merchant is accountable for scripts on the page that hosts the embedded payment form, while the payment processor is accountable for scripts inside its own iframe. That division only works when the origin boundary is clear and the merchant validates that the processor can evidence compliance with the relevant requirement.
Why This Matters for Security Teams
Embedded payment flows create a shared responsibility model that is easy to misunderstand and hard to audit. The merchant controls the browser context that loads the payment page, so any third-party script on that page can observe or alter sensitive user interactions before data enters the processor’s iframe. That is why control ownership must be mapped to the origin boundary, not just the business relationship. NIST guidance on security controls, including NIST SP 800-53 Rev 5 Security and Privacy Controls, is useful here because it treats external dependencies, integrity, and monitoring as explicit control concerns rather than assumptions.
Teams often get this wrong by assuming the payment provider “owns” everything related to checkout because the form looks hosted by the provider. In reality, merchant-side JavaScript can introduce data exposure, DOM tampering, or session manipulation even when card data is collected inside an iframe. This is also where identity and non-human identity governance starts to matter: scripts, tags, and API clients are often deployed and updated by automated pipelines, so the accountability chain must include the machines that publish code, not only the humans who approve it.
In practice, many security teams encounter script exposure only after checkout fraud, tag compromise, or a PCI review has already surfaced the gap, rather than through intentional design review.
How It Works in Practice
The practical rule is simple: control follows the code execution environment. If a script executes in the merchant page, the merchant is accountable for its behavior, provenance, integrity, and data handling. If the payment processor executes code inside its own iframe, the processor owns that runtime boundary and its controls. This is not a legal shortcut. It is an operational distinction that should be reflected in architecture diagrams, asset inventories, and third-party assurance records.
Strong implementations usually combine technical and governance controls:
- Restrict third-party scripts to an approved inventory and review every change before deployment.
- Use Content Security Policy, Subresource Integrity, and tag management governance to reduce script drift and tampering.
- Separate the embedded payment iframe from the merchant DOM so page-level scripts cannot read form content inside the processor boundary.
- Require the processor to provide evidence of its own compliance, logging, and incident handling for code running inside the iframe.
- Monitor for unexpected script injection, altered dependencies, and supply chain changes across build and release pipelines.
For teams managing broader web risk, this is consistent with the spirit of the OWASP Non-Human Identity Top 10 because modern scripts and service accounts can behave like machine identities with access, privilege, and trust boundaries that need explicit governance. The same is true for payment integrations: accountability is not just about which company owns the page, but which entity can actually execute code, change behavior, or exfiltrate data. Current guidance suggests treating the embedded processor iframe as a separate trust zone and documenting exactly which controls apply to each zone.
These controls tend to break down when merchants allow dynamic tag injection in production without change control because the page owner loses visibility into which code is actually executing.
Common Variations and Edge Cases
Tighter script control often increases release overhead, requiring organisations to balance checkout agility against integrity and auditability. That tradeoff becomes sharper when marketing tags, A/B testing tools, and fraud controls all want JavaScript access to the same payment page.
Some environments blur the boundary. For example, a processor may provide hosted fields, but the merchant still loads analytics, chat widgets, or personalization scripts on the same page. In that case, the merchant remains accountable for every script outside the iframe, even if the checkout brand strongly implies the provider owns the whole flow. Best practice is evolving on how to evidence this cleanly in complex front-end stacks, but there is no universal standard for this yet.
Edge cases also arise when a tag manager loads other tags dynamically, when front-end code is bundled from multiple repositories, or when an iframe is visually integrated so tightly that users cannot tell where the merchant page ends and the processor boundary begins. The safest pattern is to document the trust boundary in plain language, validate processor assurance regularly, and keep an immutable record of approved scripts and release approvals. Where embedded flows are part of a broader identity or payment risk program, teams should also consider how non-human identities, CI/CD tokens, and deployment agents are governed because those actors often become the real path for script changes.
For payment or checkout environments with regulated data, align those decisions with control expectations in the NIST SP 800-53 Rev 5 Security and Privacy Controls and treat exceptions as temporary unless they are formally risk accepted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Script accountability depends on least privilege across page and iframe boundaries. |
| OWASP Non-Human Identity Top 10 | Deployment scripts and automation can function as non-human identities with real access. | |
| NIST SP 800-53 Rev 5 | SI-7 | Merchant-side scripts need integrity controls to prevent tampering and supply chain abuse. |
| PCI DSS v4.0 | 6.4.3 | Embedded payment scripts fall under secure scripting and authorization expectations. |
| NIST Zero Trust (SP 800-207) | SC-7 | Clear origin boundaries map well to zero trust segmentation between merchant and processor. |
Inventory automated deployment actors and govern their permissions, rotation, and provenance.
