Payment orchestration changes the compliance equation for organizations that process card payments. When implemented with tokenization at the point of data capture, orchestration removes merchant systems from the Cardholder Data Environment, reducing applicable PCI DSS requirements from 328 (SAQ D) to 31 (SAQ A). That 90% reduction in assessment scope translates directly to reduced audit costs, documentation burden, and third-party risk exposure.
Key takeaways:
- Tokenization at the point of capture reduces PCI DSS scope from 328 requirements (SAQ D) to 31 requirements (SAQ A)
- Traditional PCI compliance costs $300,000-$500,000 annually; orchestration with tokenization reduces this by 60-80%
- 30% of breaches in 2024 involved third-party vendors, making due diligence essential
- PCI DSS v4.0 requirements 6.4.3 and 11.6.1 create significant operational burden that hosted payment fields eliminate
This article examines payment orchestration PCI compliance from a regulatory perspective: how scope reduction works mechanically, what PCI DSS v4.0 requires for payment page security, how orchestration addresses multi-jurisdictional regulations, and what due diligence compliance officers should conduct before onboarding an orchestration provider.
What is payment orchestration? (Compliance perspective)
Payment orchestration is a software layer that sits between merchant systems and multiple payment service providers, routing transactions based on configured rules. From a compliance perspective, the relevant characteristic is where cardholder data enters the orchestration flow and whether it ever touches merchant infrastructure.
Two architectures produce different compliance outcomes:
| Architecture | Card data path | PCI scope impact |
|---|---|---|
| Server-side orchestration | Card data passes through merchant backend first | Merchant servers remain in CDE scope |
| Client-side orchestration with tokens | Card data flows directly from browser to provider | Merchant systems out of CDE scope |
Server-side orchestration adds another vendor to assess. Client-side with tokenization enables SAQ A eligibility.
The compliance value of payment orchestration depends entirely on the second architecture. Without tokenization at the point of capture, orchestration adds complexity rather than reducing scope. The platform becomes another entity handling cardholder data, requiring its own AOC review and data flow documentation.
When tokenization is implemented correctly, the merchant qualifies for SAQ A: 31 requirements focused on vendor management and policy rather than the 328 technical and operational requirements of SAQ D. According to the PCI Security Standards Council, tokenization services can satisfy nearly 90% of PCI DSS required controls for qualifying merchants (Basis Theory PCI DSS SAQ analysis).
How payment orchestration reduces PCI DSS scope
Scope reduction is not automatic. It requires a specific data flow where card numbers never traverse merchant-controlled systems.
The tokenization boundary determines scope. When a customer enters card details into a form hosted by the orchestration provider or rendered via their JavaScript library, the Primary Account Number (PAN) travels directly from the customer’s browser to the provider’s PCI-certified infrastructure. The provider returns a token to the merchant’s frontend, which passes that token to the merchant’s backend for transaction processing. The merchant’s servers interact only with tokens, never with card data.
This architecture removes the merchant’s systems from the CDE because they never store, process, or transmit cardholder data. The PCI DSS assessment scope contracts to:
- Validating that the orchestration provider maintains current PCI DSS Level 1 certification
- Confirming the integration correctly routes card data to the provider before merchant systems touch it
- Maintaining policies and procedures for vendor oversight
The quantitative difference between SAQ A and SAQ D represents real cost reduction:
Assessment type Requirements Typical annual cost Documentation burden SAQ D 328 $300,000-$500,000 Full CDE audit SAQ A 31 60-80% lower Vendor oversight
Cost data from Paymid PCI DSS compliance analysis.
For a compliance officer evaluating scope impact, request the provider’s data flow diagrams and confirm:
- Where the card data capture component is hosted
- Whether the merchant’s servers receive PANs at any point in the transaction flow
- What data elements the merchant’s systems store (should be tokens only, with optional last-four digits for display)
If the integration architecture routes card data through merchant systems before tokenization, the scope reduction benefit does not apply.
Tokenization and scope reduction: What actually happens
Tokenization replaces a Primary Account Number with a non-reversible substitute value. The token has no cryptographic relationship to the original PAN; knowledge of the token does not enable reconstruction of the card number. The original PAN is stored in the orchestration provider’s PCI-certified vault.
The scope reduction mechanism works because of three architectural properties:
| Property | What it means |
|---|---|
| Merchant systems handle only tokens | Tokens are not cardholder data under PCI DSS; systems handling only tokens are out of scope |
| Tokenization before merchant contact | Customer’s browser communicates directly with provider; merchant backend receives tokens as input |
| Vault is provider’s responsibility | The orchestration provider maintains token-to-PAN mapping in their Level 1 certified environment |
This is distinct from encryption. Encrypted card data is still cardholder data under PCI DSS. Systems that store encrypted PANs are in scope for assessment. Tokenization removes the data element entirely, replacing it with a reference that carries no cardholder data value.
For multi-processor routing, tokens can be PSP-agnostic. The orchestration provider maintains the original PAN in their vault and can detokenize to authorize through any connected processor. The merchant can switch processors, add redundancy across multiple PSPs, or optimize routing without re-collecting card data or changing their scope assessment.
PCI DSS v4.0 requirements and orchestration benefits
PCI DSS v4.0 became mandatory for all assessments on March 31, 2025, with 51 previously future-dated requirements now fully enforceable. Several requirements directly affect payment page security and third-party script management.
Requirement What it mandates Compliance burden 6.4.3 Complete inventory of all scripts on payment pages, with documented authorization and integrity verification Every JS library, analytics tag, and widget must be inventoried 11.6.1 Detection and alerting for unauthorized payment page modifications, minimum weekly Ongoing monitoring infrastructure required 8.3.1 Multi-factor authentication for all CDE access, not just administrative Expands MFA scope to any card-touching system 8.3.6 Minimum 12-character passwords with numeric and alphabetic characters Documentation scales with CDE scope
These requirements create significant operational burden for organizations that host their own payment forms. Every JavaScript library, analytics tag, and third-party widget on a payment page becomes subject to inventory, authorization documentation, and integrity monitoring.
Payment orchestration with hosted payment fields or iFrame-based capture shifts this compliance burden. When the orchestration provider hosts the card capture component:
- The provider is responsible for script inventory and integrity monitoring on their hosted payment page elements
- The merchant’s payment page contains only the provider’s JavaScript library (a single authorized script)
- Changes to the card capture interface are controlled by the provider under their PCI DSS assessment
With client-side tokenization, the merchant has no CDE systems, so MFA requirements under 8.3.1 apply only to their own production infrastructure under general security policies. Fewer in-scope systems means fewer password policy evidence requirements under 8.3.6.
For detailed PCI DSS requirement breakdowns, reference the Orchestra PCI requirements checklist.
GDPR, PSD2, and multi-jurisdictional compliance
Organizations processing payments across jurisdictions face overlapping regulatory frameworks. Payment orchestration centralizes the compliance surface area for data handling while enabling jurisdiction-specific transaction routing.
GDPR data handling
Payment card numbers qualify as personal data under GDPR. When the orchestration provider processes and stores card data on behalf of the merchant, they act as a data processor under Article 28. The merchant’s obligations include:
- Data Processing Agreement with the provider specifying processing purposes, data categories, and security measures
- Verification that data residency requirements are met (where relevant)
- Confirmation of subprocessor lists and notification procedures for subprocessor changes
- Breach notification procedures aligned with the 72-hour GDPR requirement
Key point: GDPR penalties reach 4% of global annual revenue or EUR 20 million, whichever is higher. IBM’s 2025 Cost of a Data Breach Report found the global average breach cost at $4.44 million, with US breaches averaging $10.22 million.
PSD2 and Strong Customer Authentication
The Payment Services Directive 2 requires two-factor authentication from three categories (knowledge, possession, inherence) for electronic payments within the EU/EEA. The regulation has been enforced since September 2019 in the EU and March 2021 in the UK.
Orchestration platforms handle SCA compliance by:
- Managing the full 3DS2 authentication flow with issuing banks
- Applying exemptions correctly based on transaction characteristics (low-value under EUR 30, recurring payments, trusted beneficiaries, Transaction Risk Analysis qualification)
- Routing to the appropriate authentication path based on jurisdiction and merchant preferences
When properly implemented, 85-95% of 3DS2 transactions complete via the frictionless flow without customer challenge, maintaining conversion rates while satisfying regulatory requirements. For 3DS implementation details, see the Orchestra 3D Secure documentation.
Regional variations
Jurisdiction Requirement Orchestration response India (RBI) Card-on-file tokenization mandate Provider-managed tokenization vault Brazil Local data residency requirements Regional infrastructure routing Mexico Local processing requirements Jurisdiction-aware transaction routing
An orchestration provider with multi-regional infrastructure can route transactions to comply with local mandates without requiring the merchant to build separate regional integrations.
PSD3/PSR outlook
The next Payment Services Directive iteration is expected for implementation in 2026-2027. Current focus areas include instant payments, expanded scope, and alignment with Markets in Crypto-Assets (MiCA) regulation. Orchestration providers that maintain regulatory monitoring reduce merchant exposure to implementation timelines for new requirements.
3DS2 implementation and SCA requirements
3D Secure 2 is the technical implementation of Strong Customer Authentication requirements. The protocol enables risk-based authentication where low-risk transactions proceed without customer friction while higher-risk transactions trigger additional verification.
The liability shift is the primary commercial incentive: successful 3DS authentication shifts fraud liability from merchant to issuing bank. For card-not-present transactions, which account for 65% of all credit card fraud losses globally according to Merchant Cost Consulting, this liability transfer is material.
Orchestration platforms manage 3DS2 complexity across several dimensions:
- Protocol version handling: 3DS2 versions (2.1.0, 2.2.0, 2.3.1) have different data requirements and capabilities. The orchestration provider negotiates protocol version with issuing banks and handles version-specific message formatting.
- Exemption management: SCA exemptions allow transactions to proceed without authentication under specific conditions:
- Low-value transactions (under EUR 30, cumulative limits apply)
- Recurring payments with fixed amounts
- Trusted beneficiaries (whitelisted merchants)
- Transaction Risk Analysis (TRA) exemptions based on the acquirer’s fraud rates
- Jurisdiction-specific requirements: PSD2 applies to EU/EEA transactions. The UK has separate FCA enforcement. India’s RBI has distinct authentication mandates. An orchestration provider manages jurisdiction detection and routes transactions through appropriate authentication flows without merchant-side logic for each market.
- Frictionless rate optimization: Data quality determines frictionless authentication rates. 3DS2 allows passing 100+ data elements to help issuers assess risk without customer challenge. Orchestration providers with cross-merchant data can enrich authentication requests to improve frictionless approval rates.
Exemption strategy affects both conversion (fewer authentication challenges) and liability (exempted transactions may not shift fraud liability). Orchestration providers with transaction data across merchants can optimize exemption recommendations.
For ecommerce-specific compliance considerations, reference the Orchestra ecommerce PCI compliance guide.
Vendor due diligence: Evaluating an orchestration provider
Adding a payment orchestration provider introduces a new vendor into the payment flow. The compliance officer’s evaluation should cover:
PCI DSS certification verification
- Request the current Attestation of Compliance (AOC), not a certificate or summary
- Verify the AOC is dated within 12 months
- Confirm the scope covers the services you intend to use (tokenization, vault, payment processing)
- Identify the Qualified Security Assessor (QSA) firm and assessment date
- Check card network registries: Visa Global Registry of Service Providers, Mastercard Service Provider Directory
Third-party audit reports
Report/Certification What it validates SOC 2 Type II Security, availability, and confidentiality trust principles ISO 27001 Information security management system Penetration test External security testing (full reports typically under NDA)
Data flow documentation
- Technical data flow diagrams showing where cardholder data enters, transits, and rests
- Confirmation of tokenization architecture (client-side vs. server-side)
- Subprocessor list including data centers, hosting providers, and any entities with access to cardholder data
Security questionnaire
Complete a SIG (Standardized Information Gathering) questionnaire or CAIQ (Consensus Assessments Initiative Questionnaire). Response completeness and specificity indicate the provider’s security maturity. Focus areas: access control, encryption standards, incident response, business continuity, change management.
Incident response and breach notification
- Documented incident response procedures
- Notification timeline commitments (GDPR requires 72 hours)
- What data would be affected in various breach scenarios
- Historical incident disclosure (some providers publish transparency reports)
Contract terms
- Data Processing Agreement with GDPR-compliant terms
- Liability allocation for security incidents
- Indemnification provisions
- Right to audit clause
- Termination and data return/deletion procedures
Warning: According to Verizon’s 2025 DBIR, 30% of breaches in 2024 involved a third-party vendor, double the previous year. Vendor due diligence is not optional.
The evaluation timeline typically runs 4-12 weeks and should proceed in parallel with technical evaluation.
For tokenization cost and vault service analysis, see the Orchestra vaulting cost guide.
Shared responsibility: What Orchestra handles vs. your obligations
No vendor eliminates all compliance obligations. A shared responsibility model clarifies the boundary between provider and merchant responsibilities.
| Responsibility area | Orchestra handles | Merchant obligation |
|---|---|---|
| PCI DSS certification | Level 1 certification maintenance for cardholder data processing infrastructure | Validate integration routes card data correctly |
| Tokenization service | Vault security, encryption, key management, access controls | Review AOC annually to confirm continued certification |
| 3DS2 authentication | Protocol version handling, issuer communication, exemption processing | Configure preferences and exemption strategies per risk appetite |
| Card network compliance | Visa, Mastercard, Amex scheme requirements | Ensure production integration matches assessed architecture |
| Infrastructure security | Network segmentation, intrusion detection, logging, monitoring | Maintain information security policies for non-CDE systems |
| Subprocessor management | Oversight for data center and hosting providers | Document vendor risk assessment and monitoring procedures |
| Regulatory monitoring | PCI DSS updates, scheme mandates, regional authentication requirements | Maintain data processing agreements for GDPR compliance |
The scope reduction benefit depends on correct implementation. If your development team modifies the integration in ways that route card data through your servers, your systems re-enter PCI scope. Annual validation of the integration architecture should be part of your compliance calendar.
For PCI compliance outsourcing service details, contact Orchestra to request AOC documentation and data flow diagrams.
Frequently asked questions
Does using a payment orchestration platform reduce PCI scope or add another vendor to assess?
Orchestration with tokenization reduces scope when card data passes directly from customer to the orchestration platform, removing your systems from the CDE. You still assess the vendor via AOC review, but qualify for SAQ A (31 requirements) instead of SAQ D (328). The net effect is reduced compliance burden, not increased vendor complexity.
What is the difference between SAQ A and SAQ D?
SAQ A requires 31 questions for merchants who fully outsource card handling to PCI-certified third parties. SAQ D requires 328 questions for merchants who store, process, or transmit cardholder data directly. Proper tokenization at the point of data capture enables SAQ A eligibility by removing merchant systems from the cardholder data flow.
How do I verify a payment orchestration provider’s PCI compliance?
Request the current Attestation of Compliance (AOC), verify it’s dated within 12 months, confirm the scope covers relevant services (tokenization, vault, payment processing), and check card network registries. The Visa Global Registry of Service Providers and Mastercard Service Provider Directory list validated service providers.
How does Orchestra handle 3DS2 authentication across different jurisdictions?
Orchestra manages the full 3DS2 flow including SCA exemption handling per jurisdiction requirements. PSD2/SCA applies in the EU/EEA, FCA rules apply in the UK, and RBI mandates apply in India. The platform detects jurisdiction, routes to appropriate authentication, and manages exemption strategy. Frictionless completion rates reach 85-95% for properly configured implementations.
Does PCI DSS v4.0 require 3D Secure?
PCI DSS does not mandate 3DS. However, v4.0 requirements 6.4.3 and 11.6.1 address payment page security with script inventory and change detection requirements. 3DS is mandated separately by regional regulations: PSD2/SCA in the EU, FCA requirements in the UK, and RBI mandates in India. Using an orchestration provider’s hosted payment fields satisfies the PCI requirements while the provider handles regional authentication mandates.
What happens if the orchestration provider has a security incident?
Review incident response and breach notification procedures as part of vendor due diligence. Under GDPR, notification to supervisory authorities is required within 72 hours of awareness. Contract terms should specify notification timelines to merchants and liability allocation. Historical incident transparency and documented response procedures indicate provider maturity.
