Security overview
When you’re wiring this up, one thing people usually want to understand first is where the compliance boundary sits. Here’s the basic picture.
The short version
When you create a card, the response includes last_four and nothing more.
Retrieving the full card number or CVV is a separate operation with its own
permission and audit trail.
This keeps your infrastructure outside PCI DSS cardholder-data scope. If you build a passthrough that decrypts card data on your servers, your infrastructure comes back into scope. It’s worth making that choice deliberately rather than discovering it later.
Credentials
The API uses the authentication controls below. Some of the surrounding controls are available on the API today, while others are part of the wider platform build. We call out that distinction clearly so you know what to say when completing a security questionnaire.
On the API surface now
| Control | Detail |
|---|---|
| OAuth 2.0 client credentials | private_key_jwt assertions are exchanged for opaque fifteen-minute tokens. There is no shared secret; we only hold public keys |
| Key rotation | Keep up to three keys per client. Add the new key, move traffic across, then remove the old one — no downtime or coordination needed |
| IP allowlisting | Organization-wide network policy plus a per-client allowlist, enforced on every API call and token request |
| Scoped permissions | cards:secrets is not granted by default |
| Webhook signatures | HMAC-SHA256, with both signatures sent during a rotation overlap |
Cardholder PII
The API returns cardholder details only to credentials authorized to read that cardholder. The boundary here is access control rather than field-level masking.
Keep credentials scoped to the job they need to do. For example, a reporting service generally shouldn’t use credentials that can also read cardholder records.
Some sensitive information deliberately has no field in the API, including identity documents, PANs, and PIN digits.
Details about storage, including encryption at rest, data residency, and retention, are covered in the security questionnaire we provide under NDA rather than published here.
Transport
We require TLS 1.2 or later, with TLS 1.3 preferred.
Plain HTTP requests are refused rather than redirected. By the time a redirect happens, credentials may already have crossed the network in the clear.
Webhook endpoints must also present a certificate that validates against a public root. Self-signed certificates are rejected when you configure the endpoint.
Webhook authenticity
Every webhook delivery is signed with HMAC-SHA256 over the timestamp and raw request body.
Checking that signature lets you confirm that an event really came from us rather than someone who happens to know your endpoint URL. See signature verification.
In this guide
- PCI DSS scope — where the boundary sits and the decision that can move it
- Encryption and key management — the keys you handle and how each one rotates
- Audit logs — what we record and what you’ll need to record on your side
- Responsible disclosure — how to report a vulnerability