> ## Documentation Index > Fetch the complete documentation index at: https://developers.orchestrasolutions.com/llms.txt > Use this file to discover all available pages before exploring further. # PCI Scope and Compliance > How integrating Orchestra affects your PCI DSS scope, which SAQ applies to you, and which compliance documents you can request from us. Orchestra is not a Qualified Security Assessor (QSA), and this page is not compliance advice. Your PCI DSS obligations depend on how you implemented Orchestra and on every other flow in your business that touches card data, which we cannot see or verify. For a formal determination of your compliance status, engage a QSA. If you need one, we can provide a referral - contact [support@orchestrasolutions.com](mailto:support@orchestrasolutions.com). ## 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 ### Methods that keep card data out of your systems | Integration method | How it stays out | Scope impact | | ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Payments Library](/guides/library/setup) with pre-built UI | Card entry, Google Pay, Apple Pay, and other payment methods are handled inside the library's components and provider flows. | Lowest burden. Your responsibility is limited to the integrity of the page hosting the library (script management and tamper detection, PCI DSS 6.4.3 and 11.6.1). | | [REST API charge](/guides/rest-api/charge) with a **token** | You submit an Orchestra token; Orchestra injects the real card data on the way to the gateway. | Token-only. No cardholder data in your requests. | ### Methods that expose your systems to card data | Integration method | How you are exposed | Scope impact | | ------------------------------------------------------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [REST API charge](/guides/rest-api/charge) with a **raw card** | The PAN passes through your frontend and backend before reaching Orchestra. | **In scope**. Every system that receives or forwards the PAN is part of your cardholder data environment. | | [Tokenization API](/guides/rest-api/tokenization) | Your server receives the card and sends it to Orchestra for tokenization. | **In scope** for the receiving and transmitting systems. Orchestra removes the storage burden, but transmission through your systems is still PCI DSS scope. | | [Gateway tokenization](/guides/rest-api/gateway-tokenization) | Same as Tokenization API for the initial card submission. | Token lifecycle is handled at the gateway via Orchestra; the initial card pass-through is **in scope**. | | [Card Tools](/guides/rest-api/utilities/card-tools) with a full PAN | Validation and lookup calls that include a PAN pass it through your systems. | **In scope** for the systems making those calls. Brand and metadata lookups that use only the BIN do not involve full cardholder data. | ## 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): * If card capture happens entirely inside the Payments Library and no other flow touches card data, you are typically eligible for **SAQ A**, the shortest questionnaire. * If your own code collects card data and sends it through the REST API or Tokenization API, expect **SAQ A-EP** or **SAQ D for Merchants** for those flows. **Service providers** (you store, process, or transmit card data on behalf of other businesses): * 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. The current SAQ forms are published in the [PCI SSC document library](https://www.pcisecuritystandards.org/document_library/). After opening the library, change the **Filter by** selection from "PCI DSS" to "SAQ" to list the questionnaires. ## 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](mailto: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. See our [PCI compliance page](https://orchestrasolutions.com/about/pci-compliance/) for certification details. ## 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.