> ## Documentation Index
> Fetch the complete documentation index at: https://developers.pcibooking.net/llms.txt
> Use this file to discover all available pages before exploring further.
# PCI Scope and Compliance
> How integrating PCI Booking affects your PCI DSS scope, which SAQ applies to you, and which compliance documents you can request from us.
PCI Booking is not a Qualified Security Assessor (QSA), and this page is not compliance advice. Your PCI DSS obligations depend on how you implemented PCI Booking 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@pcibooking.net](mailto:support@pcibooking.net).
## How PCI Booking affects your scope
PCI DSS applies to every system that stores, processes, or transmits cardholder data, even for a split second. PCI Booking reduces your scope by taking those functions out of your environment: cards are captured on PCI Booking hosted pages, stored in PCI Booking's PCI DSS Level 1 certified environment, and delivered to payment gateways or third parties directly by PCI Booking. Your systems hold only tokens.
The key principle: **scope follows the card data**. If every card in your business flows through PCI Booking 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 (an agent typing cards into your CRM, a partner sending you raw card numbers, a legacy import file), 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 |
| -------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Hosted Card Entry Form](/capture-cards/hosted-card-entry-form) | The cardholder enters the card in a PCI Booking iframe served from our domain; your page only builds the URL. | Lowest burden. Your responsibility is limited to the integrity of the page embedding the iframe (script management and tamper detection, PCI DSS 6.4.3 and 11.6.1). |
| [Card By Link](/capture-cards/card-by-link) | The card is entered on a PCI Booking hosted page reached via an email or SMS link. | Lowest burden. Capture happens entirely outside your environment. |
| [Payments Library](/payments-library/overview) | Payment credentials are handled in PCI Booking and payment-provider flows. | Lowest burden for alternative payment methods. |
| [Server-side tokenization](/capture-cards/tokenization-on-response) (Tokenization on Request / on Response, Universal Tokenization, File Transfer) | PCI Booking sits in the message path and replaces card numbers with tokens **before** the message reaches your system. You receive tokens only. | Lowest burden. Third parties send card data to PCI Booking, not to you, so your systems are never exposed to it. |
| [Universal Payment Gateway](/use-tokens/universal-payment-gateway) and [Token Replacement](/use-tokens/token-replacement-api) | You submit tokens; PCI Booking injects the real card data on the way to the gateway or third party. | Token-only. No cardholder data in your requests or responses. |
| [Card Display forms](/use-tokens/card-display) | Card details are shown inside a PCI Booking hosted iframe or standalone page; the PAN never enters your page's DOM or your servers. | Your **systems** stay out of scope, but your **people and processes** do not: an agent who views a full card number is handling cardholder data, and PCI DSS requires that access be limited to a documented, legitimate business need (Requirement 3.4.1). Define a clear procedure for when agents may reveal a card, what they may do with it, and restrict the permission to the smallest possible group. Same page-integrity responsibilities as other embedded iframes. |
### Methods that expose your systems to card data
| Integration method | How you are exposed | Scope impact |
| ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Store a Card via Direct API](/capture-cards/store-card-migration) | Your system holds the raw card data in order to push it to the [Store Paycard](/api-reference/tokenize-cards/store-paycard) endpoint. | **In scope**: to use this API you must already have the card, so every system that holds or transmits it is part of your cardholder data environment. We recommend this method only for migrating cards from another storage system into PCI Booking. |
| [Retrieve full card details](/api-reference/manage-tokens/retrieve-card-details) via API | Your system receives the PAN. | **In scope** for every system that receives, displays, or forwards the PAN. Prefer Card Display forms to keep the PAN out of your systems entirely. |
## 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 PCI Booking. The typical outcomes:
**Merchants** (you accept payments for your own goods or services):
* If card capture is fully hosted by PCI Booking (Hosted Card Entry Form, Card By Link) and no other flow touches card data, you are typically eligible for **SAQ A**, the shortest questionnaire.
* If your own page code participates in card entry, or you use server-side tokenization, 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 - PMSs, channel managers, booking engines, OTAs):
* SAQ A and A-EP do not apply to service providers. The relevant instrument is **SAQ D for Service Providers**.
* If you integrated PCI Booking so that all card data stays inside PCI Booking, most SAQ D controls are covered by PCI Booking and documented as such in our [Shared Responsibility Matrix](#compliance-documents-you-can-request). 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
PCI Booking is a **PCI DSS Level 1 certified service provider** (v4 compliant, certified annually). Three documents support your own compliance process, all available on request from [support@pcibooking.net](mailto:support@pcibooking.net):
* **Attestation of Compliance (AoC)** - certifies PCI Booking's PCI DSS assessment, renewed annually.
* **Shared Responsibility Matrix (SRM)** - maps every PCI DSS v4.0.1 requirement to PCI Booking responsibility, client responsibility, or shared, with recommendations for the client-side controls. Use it alongside SAQ D to identify which controls PCI Booking covers for you.
* **SAQ-D whitepaper** - a QSA-authored companion document describing how outsourcing card handling to PCI Booking 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 PCI Booking's) PCI DSS status for card data you route through PCI Booking, provide them with PCI Booking'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.
Certification references: [PCI DSS compliance](https://pcibooking.net/pci-compliance/), [ISO 27001:2022](https://pcibooking.net/27001-certified), [GDPR and data residency](https://pcibooking.net/gdpr), [PSD2](https://pcibooking.net/psd2).