PCI DSS scope
"Does integrating with you put us in PCI DSS scope?" is usually one of the first questions teams ask when looking at a card issuing platform.
The short answer: not if card details stay protected until they reach the cardholder, and your servers never hold the key or handle the readable details.
This page explains where that line sits and what can move it. It covers the underlying principles, not specific API calls, so it should stay relevant as the API evolves.
The boundary
Full card numbers, CVVs, and PINs stay within the processor's PCI DSS environment. When a cardholder needs to view their card details, those details are sent in a protected form that only their device can read.
PINs travel the other way. The cardholder's device encrypts the PIN so that only we can read it, and your servers only pass along something they can't read.
Your application only gets masked details and protected values it can't read.
The key point is that your servers never see the actual card details in plain text. The cardholder's device does.
Why the boundary holds
The platform is designed to keep sensitive card details out of your hands in the first place:
- Regular API responses don't include full card numbers, CVVs, or PINs. You only see masked details in ordinary records.
- Viewing full card details is a separate, permissioned, and audited action. The values are returned in a protected form for a key you control, rather than as readable text.
- A PIN is protected before it reaches your systems. The device encrypts it for us, so what your servers hold can't be read by them.
- Identity verification uses the results from your identity provider. You don't need to receive the underlying identity documents through this flow.
The idea is simple: if the platform never gives your application a readable card value, your application can't accidentally expose one. That's a stronger safeguard than just promising not to store sensitive data.
The one decision that changes the scope
It comes down to two things: where the decryption key lives and where the readable card number is handled.
If your servers only pass around protected values they can't read, those values aren't exposed to your application in plain text.
But as soon as a server holds the key and decrypts the card number, that server is handling cardholder data and can bring systems into scope.
The same principle applies to PINs. They stay out of scope only while they stay encrypted. As soon as one of your servers handles a PIN as readable text, that server is in scope.
It's worth making these decisions during implementation, rather than waiting until an auditor asks how the integration works.
Which side of the line are you on?
| If your product… | Cardholder data in your systems |
|---|---|
| Issues cards and shows masked details | None from those details alone. Masked details aren't cardholder data. |
| Reads protected card details only on the cardholder's device | None on your servers. They only handle values they can't decrypt. |
| Decrypts card details inside a hardware security module (HSM) without exposing the number | Depends on the design and your assessor's evaluation. The HSM and relevant systems handling the data may be in scope. |
| Encrypts the PIN on the cardholder's device and only relays it | None on your servers. They only handle a value they can't read. |
| Handles the PIN as readable text on your servers | Yes. Those servers handle a PIN and are in scope. |
| Decrypts protected card details on your servers | Yes. Those servers handle cardholder data. |
| Displays the readable number in a screen your own code can capture | The relevant parts may be in scope. Your code and systems can access the card data. |
The first two are the designs we recommend. The others can work, but they need a closer look at the impact on your PCI DSS scope.
These are general design guidelines, not a guarantee of scope exclusion. Your final scope depends on the actual implementation, connected systems, and assessment of your environment.
What you're still responsible for
Being outside the cardholder-data scope doesn't mean you can stop thinking about security. There are still a few things to get right.
- Protect cardholder personal information. Names, addresses, dates of birth, and identity documents still need to be handled securely and in line with your own regulatory obligations.
- Keep readable card details out of logs. Don't put them in application logs, traces, or support tickets. Crash reporters and analytics SDKs can also capture screen content or view hierarchies, so check what they collect.
- Mask card details in internal tools. If an admin screen shows full card details, the systems involved may be in scope, regardless of how the data got there.
- Protect your API credentials. A leaked production key could let someone issue cards or perform other sensitive actions. Treat it like any other production secret.
The goal is to keep readable card details away from your systems wherever possible. That makes the boundary easier to maintain and gives you less sensitive data to protect.