How Orchestra affects your scope
PCI DSS applies to every system that stores, processes, or transmits cardholder data, even for a split second. Orchestra reduces your scope by taking those functions out of your environment: cards are captured by the Payments Library UI, stored as tokens in Orchestra’s PCI DSS Level 1 certified environment, and delivered to payment gateways directly by Orchestra. Your systems hold only tokens. The key principle: scope follows the card data. If every card in your business flows through Orchestra and never touches your servers or your own page code, your environment holds no cardholder data and your compliance burden drops to the minimum for your entity type. If some flows still touch card data (your own card form posting to your backend, an agent typing cards into your CRM, a partner sending you raw card numbers), those flows keep you in scope regardless of how well the rest is integrated.Scope impact by integration method
Scope is determined by where card capture happens, not by choosing the Payments Library over the REST API or vice versa. The Library and the API are normally both part of the same integration; the question is only whether your own systems ever handle a raw card.Methods that keep card data out of your systems
The standard Orchestra integration: the Payments Library captures the card, and the REST API operates on the resulting token.Non-standard patterns that put you in scope
These are schema-valid calls, not the intended integration. They exist for backends that already lawfully hold card data; listed here for completeness, not as an alternative to Library capture.Which SAQ applies to you
Which Self-Assessment Questionnaire (SAQ) you fill out, and whether self-assessment is even sufficient, is determined by your acquirer, the card brands, and your transaction volume, not by Orchestra. The typical outcomes: Merchants (you accept payments for your own goods or services):- The standard Orchestra integration, card capture happening entirely inside the Payments Library with no other flow touching card data, is typically eligible for SAQ A, the shortest questionnaire.
- If your own code collects card data instead and sends it through the REST API or Tokenization API, expect SAQ A-EP or SAQ D for Merchants for those flows.
- SAQ A and A-EP do not apply to service providers. The relevant instrument is SAQ D for Service Providers.
- If you integrated Orchestra so that all card data stays inside Orchestra, the bulk of the technical controls are Orchestra’s responsibility. You self-attest the remaining controls, which mostly concern your own policies, user management, and page integrity.
- High-volume service providers (Level 1) may be required by card brands to complete a full Report on Compliance (ROC) with a QSA instead of self-assessing. Check your level with your acquirer.
Compliance documents you can request
Orchestra is a PCI DSS Level 1 certified service provider. Three documents support your own compliance process, all available on request from support@orchestrasolutions.com:- Attestation of Compliance (AoC) - certifies Orchestra’s PCI DSS assessment, renewed annually.
- Shared Responsibility Matrix (SRM) - maps every PCI DSS v4.0.1 requirement to Orchestra responsibility, client responsibility, or shared, with recommendations for the client-side controls. Use it alongside SAQ D to identify which controls Orchestra covers for you.
- SAQ-D whitepaper - a QSA-authored companion document describing how outsourcing card handling to Orchestra maps to the SAQ D for Service Providers.
If a third party asks about your compliance
If a PSP, acquirer, or partner asks about your (or Orchestra’s) PCI DSS status for card data you route through Orchestra, provide them with Orchestra’s current AoC together with a statement along these lines:“We are outsourcing all raw card data handling to an integrator covered under this AoC certification.”Store the AoC and the SRM together as part of your compliance records.