Who Is Actually Handling Your Customer's Payment Data? A Merchant's Guide to Mapping the Invisible Vendor Chain
The Vendor You Don't Know You Have
Ask a typical US merchant who processes their payments, and they will give you a name: Stripe, Square, Braintree, Worldpay, or one of a dozen other recognizable platforms. Ask them who else touches their customers' payment data, and the conversation often stops there.
The reality is considerably more complex. Behind every major payment processor is a network of sub-processors, tokenization providers, fraud screening vendors, data analytics firms, gateway operators, and acquiring banks — each of which receives some portion of the transaction data flowing through the merchant's checkout. Some of these relationships are disclosed in service agreements. Many are not prominently surfaced. A few exist several layers deep in vendor chains that merchants have never reviewed.
This matters for reasons that extend well beyond academic compliance interest. Under PCI DSS (the Payment Card Industry Data Security Standard), merchants bear responsibility for ensuring that any third party handling cardholder data on their behalf maintains equivalent security standards. Under various state privacy laws — California's CPRA, Virginia's CDPA, and others — merchants may have disclosure and data-sharing obligations that apply to their vendor relationships. And under the terms of most processor agreements, merchants who fail to maintain PCI compliance — including vendor oversight — face fines, increased processing rates, and potential account termination.
The question is not whether your vendor chain creates liability. It does. The question is whether you know where that liability sits.
Why the Vendor Chain Is Invisible by Design
Payment processors have a business incentive to present a seamless, unified service. From the merchant's perspective, a single integration handles everything: checkout, authorization, fraud screening, tokenization, settlement, and reporting. The complexity underneath is abstracted away.
This abstraction is genuinely useful for getting businesses operational quickly. But it has a side effect: merchants rarely encounter the contractual language that discloses sub-processor relationships, and when they do, it is typically buried in a master service agreement that few people read in full.
A standard processor agreement will include a sub-processor clause — often titled something like "Use of Third-Party Service Providers" or "Subcontracting" — that grants the processor broad authority to engage additional vendors in the delivery of services. These clauses typically do not enumerate specific vendors. They establish a right to use them and, in some cases, require the processor to maintain a list of sub-processors upon request.
Few merchants ever make that request.
What's Typically in the Chain
While every processor's vendor network differs, most enterprise-grade payment ecosystems include some combination of the following:
Tokenization providers. Rather than storing raw card numbers, most processors replace them with tokens — non-sensitive placeholders that can be used for recurring billing. The tokenization service may be operated by the processor directly, by the card network (Visa Token Service, Mastercard Digital Enablement Service), or by a third-party vault provider.
Fraud and risk scoring vendors. Real-time fraud screening often involves third-party machine learning platforms that receive transaction data — including device fingerprints, behavioral signals, and sometimes cardholder history — to generate risk scores. Vendors in this space include companies like Kount (now part of Equifax), Sift, and Forter, among others.
Payment gateways. If a merchant uses a gateway that is separate from their acquirer — a common configuration in older or more complex integrations — transaction data passes through the gateway before reaching the processor. The gateway is a distinct entity with its own data handling practices.
Acquiring banks. The processor's acquiring bank is the financial institution that sponsors the merchant's card acceptance and interfaces with card networks on the processor's behalf. Acquiring banks receive settlement data and, in some configurations, authorization data as well.
Analytics and reporting platforms. Some processors integrate third-party business intelligence or reporting tools that receive anonymized or pseudonymized transaction data. Depending on the data fields transmitted, these may or may not constitute cardholder data under PCI DSS definitions.
Customer support platforms. When merchants contact their processor's support team, interactions may be logged in a CRM system operated by a third party. If support agents can view transaction details during those interactions, the CRM vendor may be in scope for cardholder data handling.
The DIY Vendor Audit: A Practical Checklist
Mapping your payment data vendor chain does not require a specialized security firm, though one may be warranted for complex environments. It does require systematic effort and a willingness to ask questions that processors are not always eager to answer.
Step 1: Request your processor's sub-processor list. Contact your processor's compliance or legal team and formally request a current list of sub-processors that may handle cardholder data on your behalf. Most reputable processors are obligated to provide this under GDPR (if you have any EU customers) and will generally comply as a matter of standard practice. Document the request and the response.
Step 2: Review your master service agreement. Locate the sub-processor and data handling clauses. Note what the processor is permitted to do with transaction data beyond processing the transaction itself — including whether they may use it for their own analytics, fraud modeling, or product development purposes.
Step 3: Map your own integrations. List every third-party plugin, widget, or API integration on your checkout or payment pages. This includes fraud screening tools you may have added independently, address verification services, buy-now-pay-later widgets, and analytics tags. Each of these may receive payment-adjacent data.
Step 4: Verify PCI DSS compliance for each vendor. For vendors that handle cardholder data, request evidence of PCI DSS compliance — typically a current Attestation of Compliance (AOC) or a listing on the PCI Security Standards Council's list of validated service providers. Vendors that cannot produce this documentation represent an unmitigated compliance gap.
Step 5: Review your privacy policy disclosures. Under CPRA and similar state laws, your privacy policy must accurately disclose the categories of third parties with whom you share personal information, including payment-related data. If your vendor audit surfaces relationships not currently reflected in your disclosures, those disclosures need to be updated.
Step 6: Assess your contractual coverage. Your agreements with payment vendors should include data processing addenda or security addenda that establish each vendor's obligations regarding cardholder data. If such addenda are absent, you are relying on the vendor's goodwill rather than contractual protections.
What You Are Actually Liable For
PCI DSS operates on a principle of shared responsibility, but that sharing has limits. If a sub-processor experiences a data breach and it can be established that the merchant failed to exercise appropriate vendor oversight, the merchant may face fines from card networks, liability for card reissuance costs, and regulatory scrutiny under applicable state laws.
The Federal Trade Commission has also pursued enforcement actions against companies that failed to implement reasonable data security practices — a category that increasingly includes inadequate vendor management. For businesses operating in regulated industries such as healthcare or financial services, additional federal frameworks may impose independent vendor oversight requirements.
The cost of a vendor audit is measured in hours. The cost of discovering an undisclosed data breach through a card network investigation is measured in a very different currency.
Transparency as a Competitive Differentiator
There is a business case for vendor transparency that extends beyond compliance. Customers in the US are increasingly attentive to how their financial data is handled. Merchants who can demonstrate that they know exactly which companies touch customer payment data — and that each of those companies meets documented security standards — are in a stronger position when data security becomes a purchasing criterion.
Knowing your vendor chain is not a defensive posture. It is a foundation for the kind of payment security that businesses and their customers can actually rely on.
