Every online checkout page is a small software supply chain. The shopper never sees it, but the path from a credit card number being typed into a form to an authorization code coming back from Visa passes through a remarkable number of dependencies. A merchant's frontend library, a processor's drop-in iframe, a tokenization SDK, a fraud scoring vendor, a 3D Secure flow handler, a webhook listener, a settlement reconciliation job. Each one is code that somebody else wrote, deployed, and updates on a cadence the merchant usually cannot control.
For most of the industry's history this was treated as a procurement problem. You picked a processor, signed the MSA, and trusted that the logos behind them -- Visa, Mastercard, the PCI Security Standards Council -- had worked out the security details. That assumption has not aged well. The past five years have produced a steady stream of incidents where the break occurred in a component of the payment stack rather than in the merchant or the processor themselves, and regulators have noticed.
The Magecart Pattern Never Stopped
The British Airways breach of 2018 made Magecart a household term in security circles, but the attack pattern is older than that and has not slowed down. Attackers compromise a script that the merchant loads into the checkout page -- often an analytics library, a chat widget, or a tag management loader -- and inject skimming code that siphons card numbers directly from the DOM before they ever reach the processor.
What makes this a supply chain problem rather than a merchant problem is that the compromised script is not hosted by the merchant. It comes from a CDN, a SaaS vendor, or a marketing tool provider. The merchant's security controls -- WAF, CSP if they have one, vulnerability scanning on their own code -- do not see the change. The attackers exploit the implicit trust chain of the modern web: scripts loaded from trusted hostnames run with full access to the page.
PCI-DSS 4.0 addressed this explicitly with Requirement 6.4.3, which mandates that scripts on payment pages be inventoried, that their integrity be validated, and that authorization for each script be documented. The requirement became mandatory in March 2025, and it is the first time PCI has forced merchants to manage their frontend supply chain as a first-class control.
The Gateway Library Problem
Server-side, the dependency risk is usually in the processor's own SDK. A Stripe, Adyen, or Braintree SDK sits in the merchant's application and has access to card data in the instants before it is tokenized. If that SDK is vulnerable -- or if one of its transitive dependencies is vulnerable -- the blast radius includes every cardholder who checks out during the exposure window.
This is not a hypothetical risk. The 2021 Event-Stream incident, in which a malicious maintainer pushed a crypto-stealing backdoor into a widely used npm package, illustrated how deeply trust can be abused in a modern dependency graph. Payment SDKs pull in hundreds of transitive dependencies, and any one of them can be the pivot point. The Codecov breach of 2021 and the subsequent compromises of CI/CD tooling showed that even the infrastructure used to build payment code is in scope.
Mature payment teams now maintain an SBOM for every service in the payment path, scan it continuously against the KEV catalog and other vulnerability feeds, and track the specific versions of processor SDKs deployed to production. When a processor publishes a security advisory, the question "are we affected" is answered in minutes from SBOM data rather than by emailing the vendor.
Fraud and 3DS Providers: The Invisible Dependency
3D Secure flows have become standard for card-not-present transactions in Europe under PSD2 Strong Customer Authentication, and they are increasingly used elsewhere. The flow typically involves redirecting the shopper through an ACS (Access Control Server) operated by the issuing bank, mediated by a directory server run by the card network, orchestrated by the merchant's 3DS server.
Each hop is a piece of software maintained by a different party. The merchant's 3DS server is often provided by the payment gateway but sometimes sourced from a specialized vendor. The ACS software and the directory server software are from a small set of specialized suppliers. An availability or integrity problem in any of these components breaks checkout for the merchant, and in most cases the merchant has no visibility into what went wrong.
Fraud providers create a similar dependency. A fraud scoring API is often consulted in-line during the authorization flow, and its latency and availability directly affect checkout conversion. If the fraud provider's software is compromised, the attacker gains the ability to influence approval decisions at scale.
Card Network Tokenization and Network Tokens
Network tokenization, in which the card networks themselves issue tokens that can be used in place of the Primary Account Number, adds another dependency. Visa Token Service, Mastercard Digital Enablement Service, and the equivalent offerings from Amex and Discover are all software systems that sit in the payment path. Merchants and processors integrate through SDKs and APIs, and the integration layer is software that needs to be patched and monitored like any other.
The upside of network tokens is real -- they reduce the blast radius of a merchant breach and improve authorization rates -- but they also concentrate risk in the network's own systems. The 2024 reports of attempted compromises against tokenization infrastructure reinforced that this concentration is a valid concern.
Building a Payment Dependency Program
A credible payment dependency program starts with visibility. You cannot manage a supply chain you cannot see. The baseline deliverables are an inventory of every script loaded on the payment page, an SBOM for every service that handles card data or authentication, and a register of every third-party service called during checkout.
Visibility alone is not enough. The inventory has to be kept current -- drop-in SDKs change versions silently, tag managers let marketing teams add new scripts without engineering review, and processors push minor SDK updates under the assumption that merchants will accept them. Teams need automated detection of changes and a rule set that forces changes to payment-path components through a review process.
Monitoring against vulnerability feeds is the next layer. CVEs published against a processor SDK, a 3DS library, or a tokenization component need to trigger an immediate triage process. The CISA KEV catalog, vendor advisories, and private intelligence feeds all feed into this. For payment code, the threshold for "is this a priority" should be lower than for general applications, because the impact of exploitation is direct financial loss and card data exposure.
The third layer is policy and governance. PCI-DSS 4.0 Requirement 6.4.3 is a floor, not a ceiling. A good policy defines which components can appear on a payment page, which third parties can be called during authorization, what the acceptable latency and availability SLOs are, and how changes are approved. The policy is enforced at build time through SBOM-aware gates and at runtime through CSP, SRI, and network egress controls.
The Contractual Side
No technical program survives a processor incident without good contracts. Payment MSAs should require prompt notification of security issues, a defined vulnerability management SLA, SBOM disclosure on request, and audit rights. Where a processor uses subcontractors -- and they all do -- the flow-down obligations need to be explicit.
The regulatory direction is clear. DORA's subcontractor visibility expectations, PCI-DSS 4.0's inventory and attestation requirements, and the FFIEC examination focus on third-party software all push in the same direction: the merchant or payment service provider is responsible for the whole supply chain, not just the parts it controls directly.
How Safeguard Helps
Safeguard gives payment teams a single source of truth for every dependency in the payment path, from processor SDKs and 3DS libraries down to the frontend scripts that PCI-DSS 6.4.3 now requires be inventoried. Continuous SBOM monitoring catches newly disclosed vulnerabilities in processor and fraud-provider code within minutes of publication, and policy gates prevent an unapproved script or an outdated SDK from reaching production. When a card network publishes an advisory, Safeguard's query engine tells the team exactly which services and which merchants are affected, turning what used to be a multi-day scramble into a targeted, auditable response.