Theme
PCI posture
This page is the merchant-facing summary of why your integration stays out of PCI scope, and of digid pay's own posture as a service provider. Keep it handy for your own assessor or auditor.
The merchant story: SAQ A
Because card entry happens entirely inside digid pay Secure Fields (the hosted tokenization iframes served from digid pay's vault boundary) — never in your DOM, your servers, or your logs — your payment page is not in scope for card data. digid pay is the entity whose systems handle the tokenization boundary.
The wording you can rely on:
Card entry happens entirely inside digid pay's vault boundary, never in our DOM or servers, so our payment page qualifies for SAQ A under the card-brand self-assessment questionnaires.
What makes SAQ A hold for you
- The card-number field you present is a digid pay Secure Field iframe — the PAN is typed into digid pay's vault, not your page.
- Your servers never receive, store, process, or transmit a PAN.
- Your pages contain no script that reads card data from the fields (the fields are isolated iframes; your code cannot reach them).
- Your snippet is SRI-pinned and versioned, so the code you load is the code you audited (Snippet).
digid pay's service-provider posture
digid pay operates as a payment service provider and completes an annual SAQ D-SP self-assessment (Level 2 service provider). The architecture keeps digid pay's own card-data environment empty by construction:
| Layer | Card data exposure |
|---|---|
| digid pay Secure Fields + tokenization vault | the only place card data is captured and stored — inside the vault boundary |
| digid pay API, webhooks, dashboard, logs | token-only; no PAN by construction |
| Your systems | none — you integrate with tokens and webhooks |
digid pay holds no PAN in its systems, logs, exports, or repositories. Log scrubbers enforce the PAN-pattern ban across all environments, including the open sandbox (see Sandbox rules).
Evidence on request
digid pay makes available to merchants (on request, per the service-provider obligations) a summary of its compliance posture and evidence — including attestations from the certified parties in the chain (the tokenization vault and the acquiring partner). For a full evidence pack, contact contact@digid.cc with your merchant account reference.
What digid pay is not
- Not a certified acquirer and not a payment institution holding your funds (Settlement).
- Not a party that ever handles card data on your behalf outside the vault boundary.
- The acquiring and SCA obligations sit with our European acquiring partner; digid pay's role is orchestration, tokens, and brand.
Related
- Tokens & card data — the model behind this posture.
- Secure Fields — the SAQ A wording in context.
- Accounts — merchant lifecycle.