Security Compliance
PCI DSS SAQ A
Section titled “PCI DSS SAQ A”The Payment Card Industry Data Security Standard (PCI DSS) requires every business that accepts card payments to validate compliance. The standard defines several Self-Assessment Questionnaire (SAQ) levels based on how you handle card data.
By using Zatlas Card Capture, your website qualifies for SAQ A — the simplest and least burdensome level. SAQ A applies when:
- You never process, store, or transmit cardholder data on your servers.
- All card data entry is handled by a PCI-compliant third-party (Zatlas) inside an isolated iframe.
- Your pages are served over HTTPS.
The card form rendered by the SDK lives inside an iframe hosted on fields.zatlas.com. Your JavaScript cannot read or modify the iframe contents due to browser same-origin policy. Card numbers, expiry dates, and CVCs never touch your DOM, your JavaScript, or your servers.
How card data flows
Section titled “How card data flows”The diagram below shows the data boundary between your website and the Zatlas iframe.
Your website sends configuration (amount, currency, access token) to the SDK. The iframe collects card data from the guest and sends it directly to the Zatlas API over HTTPS. Your website receives only the result — either a payment confirmation or a mth_* token. At no point does raw card data pass through your code.
What you receive
Section titled “What you receive”Depending on your integration mode, the SDK returns different data to your application. None of it is sensitive cardholder data.
| Field | checkout mode | createToken mode |
|---|---|---|
Payment ID (pay_...) | Yes | — |
| Payment status | Yes | — |
Token ID (mth_...) | Yes | Yes |
| Card brand | Yes | Yes |
| Last 4 digits | Yes | Yes |
| Expiry month / year | Yes | Yes |
| Full card number | Never | Never |
| CVC | Never | Never |
Security layers
Section titled “Security layers”The SDK employs multiple layers of defense to protect card data in transit and at rest.
| Layer | Description |
|---|---|
| Isolated iframe | Card fields render inside a cross-origin iframe (fields.zatlas.com). Your JavaScript cannot access iframe contents via contentWindow, contentDocument, or any DOM API. |
| TLS 1.2+ | All communication between the iframe and the Zatlas API uses HTTPS with TLS 1.2 or higher. Older protocols are rejected. |
| Content Security Policy | The iframe enforces a strict CSP that blocks inline scripts, external resources, and form submissions to unauthorized origins. |
| Tokenization | Raw card data is immediately tokenized on Zatlas servers. Tokens are not reversible — there is no API to retrieve the original card number from a token. |
| Short-lived access tokens | OAuth2 access tokens expire after 1 hour. Even if an access token is intercepted, it cannot be used to retrieve card data. |
| Origin validation | The SDK validates the parent page origin against the allowed domains registered for your publishable key. If the origin does not match, the iframe refuses to load. |
| No local storage | The SDK does not write card data to localStorage, sessionStorage, cookies, or IndexedDB. All card data exists only in the iframe’s in-memory state. |
Your responsibilities
Section titled “Your responsibilities”While Zatlas handles the heavy lifting of card data security, you are responsible for:
- Serving your pages over HTTPS. The SDK will refuse to load on non-HTTPS origins (except
localhostfor development). - Keeping your access token server-side. Generate OAuth2 tokens on your server and pass them to the frontend. Never embed your
client_secretin client-side code. - Protecting your publishable key. While publishable keys are safe to include in frontend code, restrict their allowed domains to prevent unauthorized usage. Contact the Zatlas team to manage your domain allowlist.
- Not logging card data. Do not attempt to intercept, log, or store any data from the iframe. This would break your SAQ A eligibility.
- Keeping dependencies updated. Run
npm update @zatlas/card-captureregularly to receive security patches and improvements. - Monitoring for errors. Subscribe to the SDK’s error event and log infrastructure errors so you can respond quickly if something goes wrong.