Your PCI DSS obligations

PCI DSS (the Payment Card Industry Data Security Standard) is the card brands’ rulebook for protecting card details. Most people have heard of it; few know how it works. In short: every business involved in taking a card payment is bound by it, not only the ones that see card numbers, and each has to make sure the next one along is too. That includes your platform, even though Shuttle handles the card details for you.

The chain, and where you sit

1. The card brands (Visa, Mastercard, American Express, Discover and JCB) write the rules, through the PCI Security Standards Council.
2. Your merchant’s payment provider gives the merchant an account to take cards. In return, the merchant agrees in its contract to follow PCI DSS. That includes using only service providers that follow it too, and checking at least once every 12 months that each one still does (requirement 12.8.4).
3. Your platform is how the merchant takes those payments, even when you hand the card details on to another provider to process, whether that is Shuttle, Stripe, PayPal or anyone else. That makes you the merchant’s service provider: you have to follow PCI DSS yourself, and prove it. Outsourcing the card handling reduces what you have to do; it doesn’t take you out of the chain.
4. Shuttle handles the card details for you. That makes Shuttle your service provider, and you have the same duty: check at least once every 12 months that we follow PCI DSS (requirement 12.8.4). We do, at Level 1, the highest level: see Security and our Attestation of Compliance.

Each link proves its compliance to the one before it with an Attestation of Compliance (AOC), renewed every year: the merchant will ask you for yours, and you hold ours.

How much depends on who handles the card

What PCI DSS asks of you depends mostly on one thing: whether card numbers ever pass through your systems.

How you take the card	Who sees the card number	What PCI DSS asks of you
Your own systems: a card form you build, or sending card numbers to a provider’s API	You: your pages, servers and possibly staff	All of it. Storing, transmitting and protecting card data, and every system around it, are yours to secure and to prove
An iframe: a Shuttle payment form embedded in your page	Shuttle only	Much less. Card data stays with Shuttle, but the page that hosts the iframe could be tampered with, so you protect it
A hosted page: the customer is sent to a Shuttle-hosted page or payment link	Shuttle only	The least. The payment page is entirely Shuttle’s; you secure the systems that send customers to it

So avoid handling card details yourself wherever you can, and use a provider that takes them for you.

That is true of any provider, not just Shuttle. None can take PCI DSS off you entirely: you remain a service provider, with your own obligations to meet and prove. When a provider says it “handles PCI for you”, what it means is what this page describes: it takes the card data, and with it most of the requirements, and leaves you a smaller set of your own.

The full split, requirement by requirement, is in our Shared Responsibility Matrix (PCI DSS v4.0), which covers the hosted page and iframe.

Your scope in detail

PCI DSS sorts your systems into three groups:

• Cardholder data environment (CDE): systems that store, process or transmit card data. Because the card goes straight into Shuttle, you hold little or no CDE: that environment is Shuttle’s.
• In-scope systems: systems connected to the CDE, or that could affect the security of the card data or the payment. You still have these, for example the infrastructure that serves the page that redirects to or embeds Shuttle, and the services it depends on. A system doesn’t need to touch card data to be in scope.
• Out-of-scope systems: kept apart from both by validated segmentation. Drawing and validating that boundary is your responsibility.

Do you still need PCI DSS?

Yes. As a service provider you validate your compliance each year, and your merchants (and possibly their payment providers) will ask for your Attestation of Compliance. Using Shuttle changes how much there is to validate, not whether you do it.

How you validate depends on your service-provider level, set by the card brands on annual transaction volume:

Level	Transactions a year	How you validate
Level 1	More than 300,000	Annual on-site assessment by a QSA (Report on Compliance), plus quarterly ASV scans
Level 2	300,000 or fewer	Annual self-assessment (SAQ D for service providers), plus quarterly ASV scans

Thresholds vary by card brand. The shorter forms you may have heard of, SAQ A and SAQ A-EP, are for merchants, not service providers: as a platform, you use the service-provider SAQ D or a QSA assessment.

What you avoid, and what you still carry

Because card data never enters your environment, you largely avoid:

• Protecting stored card data (requirement 3): you store no card numbers, so storage, retention, masking and key management fall to Shuttle.
• Protecting card data in transit (requirement 4): the customer’s browser sends the card straight to Shuttle.
• Physical card handling (requirement 9): no staff handle cards, and there are no card terminals or card data media.

You still carry, in full or nearly:

• Your general security programme (requirements 1, 2, 5, 7, 8, 10 and 11) for the infrastructure that serves the page which redirects to or embeds Shuttle, and admin access to it.
• Payment-page integrity (6.4.3 and 11.6.1): the page that embeds or launches Shuttle is an e-skimming target, so you inventory and integrity-check its scripts and detect tampering. This weighs most with the iframe.
• Managing Shuttle as a service provider (requirement 12.8): list Shuttle as a third-party service provider (12.8.1), hold a written agreement (12.8.2), check our compliance at least once every 12 months, for example with our Attestation of Compliance (12.8.4), and keep a record of which requirements Shuttle covers and which are yours, which is what the responsibility matrix is for (12.8.5). As a service provider yourself, you owe the same to your own customers: acknowledge your responsibilities in writing and give them the information they need (12.9).

Watch for leaks: your aim is that card numbers never enter your environment. Have a way to detect and remove one if it ever lands in logs, CRM records or notes (12.10.7).

This page and the matrix are a planning and scoping aid, not a substitute for your own scope validation (requirement 12.5.2) or a QSA’s assessment.