PCI scope
Paylera operates as a PCI-DSS service provider at SAQ-A. As long as you use the supported payment flows, your servers never see PAN or CVV, and your assessment burden is the lightest available — SAQ-A.
What “SAQ-A” means
SAQ-A is the simplest PCI self-assessment questionnaire. It applies to merchants who:
- Accept only card-not-present transactions.
- Have outsourced all cardholder data functions to PCI-validated third parties.
- Never electronically store, process, or transmit cardholder data on any system or premises they control.
About 20 questions. No quarterly scans. No paperwork tornado.
The supported flows
To stay within SAQ-A, capture cards via one of:
| Flow | What | PCI |
|---|---|---|
| Hosted checkout | Customer redirects to a Paylera-hosted page; we handle card capture. | SAQ-A. |
| Setup intents + provider SDK | Card collected by the provider’s tokenisation SDK loaded from the provider’s CDN; your frontend never reads the PAN. | SAQ-A. |
| Customer portal | Customer manages methods on a Paylera-hosted page. | SAQ-A. |
What pulls you out of SAQ-A and into SAQ A-EP (a much heavier
assessment): proxying card data through your servers, even briefly. Even
a console.log(card_number) in a forgotten dev branch can do it. Don’t
do it.
What we never store
- PAN (the card number).
- CVV / CVC.
- Track data (mag stripe / chip).
- PIN data.
What we do store, with full encryption at rest:
- Provider tokens (
pm_…) — useless without the provider’s keys. - Last 4 digits.
- Card brand and country.
- Expiry month / year.
- Cardholder name (where the provider returns it).
- BIN (first 6) — used for routing and risk; never the full PAN.
Provider tokens
Provider tokens are not cardholder data — they’re per-merchant references that only have meaning at the issuing provider. PCI-DSS v4.0 §3 explicitly excludes them from cardholder data scope.
We treat them with care anyway: encrypted at rest with a tenant-scoped DEK, KEK rotated on schedule, access audited.
What you must still do
- Use a TLS 1.2+ certificate on every page where Paylera-hosted surfaces are linked or embedded.
- Don’t cache card data in your frontend, even briefly. The tokenisation SDKs handle this; don’t read the input fields they create.
- Don’t log full request / response bodies that include card tokens — tokens are scoped to your tenant, but token leakage at scale is still a security incident.
- Restrict who can see provider tokens in your operator tooling. The dashboard does this by default; if you build internal tools, match it.
- Complete SAQ-A annually with your acquirer.
Webhooks and PCI
Webhooks deliver event payloads that may contain provider tokens
(payment.payment_method_id, customer.payment_methods[]). They
never contain PANs. Your handler stays in SAQ-A scope.
Forensics support
If your acquirer ever requests a “forensic audit” because a card has
been disputed in unusual ways, contact support@paylera.io. We
maintain audit-ready records of every tokenisation, payment, and refund
for the longer of 7 years or the duration of any open dispute.
ROC vs SAQ
If you’re a Level 1 merchant (>6M card transactions / year), you’re
required to file a Report on Compliance (ROC) instead of an SAQ.
Paylera’s service provider AOC (Attestation of Compliance) is
sharable under NDA — your QSA can rely on it for the scope Paylera
covers. Email compliance@paylera.io.
Quick checklist
- All card capture goes through hosted checkout, the customer portal, or the provider’s tokenisation SDK.
- No card numbers, CVVs, or track data anywhere on your servers.
- Internal tools that display saved methods show only last 4, brand, expiry — never re-fetch full PANs.
- Logs are scrubbed of payment method tokens at the SIEM level (or better, never written).
- SAQ-A filed annually with your acquirer.