Tokens & card data

digid pay is token-only by construction. A full card number exists in exactly one place during checkout — inside digid pay Secure Fields, the hosted tokenization iframes rendered on your page. What leaves those fields is a token; what your servers, digid pay systems, logs and database ever see is that token and payment metadata. Never a PAN.

The model

sequenceDiagram
    participant Shopper
    participant Your page
    participant Secure Fields
    participant Vault as digid pay tokenization vault
    participant digidpay as digid pay API
    Shopper->>Secure Fields: types card details
    Secure Fields->>Vault: card data (never touches your DOM or servers)
    Vault-->>Secure Fields: payment token
    Secure Fields-->>Your page: token + brand + last4
    Your page->>digidpay: confirm PaymentIntent with token

What merchants never touch

• A full PAN — never in your DOM, logs, database, or requests.
• CVV — never stored anywhere after the Secure Fields capture.
• Raw card-number API fields — the digid pay API rejects any number-shaped 13–19 digit field in payment requests (including in sandbox). There is no path to submit a raw card through the API.

What you do receive

Value	Purpose
payment_method token (pmt_…)	Confirms a PaymentIntent; never usable to retrieve the card.
Brand (visa, mastercard, …)	UI/branding only.
Last four digits	Receipt / display confirmation.

The PAN-pattern ban

digid pay systems run PAN-pattern scrubbers across logs (the same rule that guards production applies in sandbox — rule R3). There is no code path, log, export or repository that may contain a PAN. The API contract itself refuses card-number fields so the boundary is enforced at the edge, not only in policy.

Why your PCI burden stays low

Because card entry happens entirely inside the digid pay tokenization vault — never in your DOM or on your servers — your own checkout qualifies for the lowest SAQ class. Our PCI posture page spells out the merchant wording; digid pay operates as a service provider under its own self-assessment with an empty card-data environment.

Token lifecycle

Lifecycle	Note
Created	When Secure Fields tokenizes a card (per capture or on-file).
Used	To confirm a PaymentIntent.
Expired / invalid	Failed confirmations surface expired_token, invalid_token, or used_token — a token can only charge what it was created for.

Rules of thumb

1. Never log request bodies that could contain token-adjacent card metadata.
2. Never attempt to build your own card form — that defeats the model.
3. Treat pmt_ tokens as single-purpose: mint fresh from Secure Fields for each checkout, and use on-file tokens only for the flows that document them.
4. If a vendor asks you for a raw PAN to "test", stop — that is not how digid pay works (see Sandbox rules).

Further reading

• Secure Fields — capture tokens styled to your brand.
• Payments — confirm intents with tokens.
• PCI posture — SAQ A wording for merchants.