Payment flow & roles

Who does what in a digid pay payment, by role and certification only — no vendor names. Card data exists in exactly two places at any moment: inside the digid pay tokenization vault's hosted fields (browser → vault TLS) and in the single leg from the vault to the acquiring partner. Everything else — your systems, digid pay's gateway, its logs and database — never holds or transports a PAN.

flowchart TD
    classDef pci fill:#4a1f1f,stroke:#e57373,color:#ffebee
    classDef merchant fill:#14301f,stroke:#66bb6a,color:#e8f5e9
    classDef digidpay fill:#0d2a4a,stroke:#42a5f5,color:#e3f2fd
    classDef neutral fill:#263238,stroke:#90a4ae,color:#eceff1

    S0(["Shopper at checkout"]):::neutral
    S1["MERCHANT WEBSHOP<br/>order logic · renders the checkout<br/>lowest SAQ class"]:::merchant
    S2["CHECKOUT SNIPPET (on merchant page)<br/>embeds hosted fields · ships versioned<br/>from the digid pay asset host, runs in merchant DOM"]:::merchant
    S3["DIGID PAY TOKENIZATION VAULT — capture<br/>PCI DSS certified · hosted fields<br/>tokenizes the card at input"]:::pci
    S4["DIGID PAY GATEWAY<br/>orchestration · plans · keys · webhooks<br/>no PAN by construction"]:::digidpay
    S5["ACQUIRING PARTNER<br/>regulated acquirer<br/>KYC · SCA/3-D Secure · clearing"]:::pci
    S6["CARD SCHEMES + ISSUER<br/>authorization"]:::pci
    S7["digid pay status + ledger update<br/>event-driven · no PAN"]:::digidpay
    S8["MERCHANT WEBHOOK (HMAC-signed)<br/>order finalized"]:::merchant
    S9["SETTLEMENT<br/>acquirer → merchant bank, T+n<br/>margin split to digid pay<br/>funds never touch the gateway"]:::neutral

    S0 -->|"opens checkout"| S1
    S1 -->|"embeds"| S2
    S2 -->|"renders hosted fields"| S3
    S0 -.->|"PAN typed DIRECTLY into vault fields —<br/>never merchant or gateway DOM"| S3
    S3 -->|"card token returned to page"| S2
    S2 -->|"token + order → gateway API"| S4
    S4 -->|"tokenized charge payload"| S5
    S5 -->|"auth request"| S6
    S6 -->|"approve / decline"| S5
    S5 -->|"result (no PAN)"| S7
    S7 -->|"notifies"| S8
    S8 -->|"confirmation"| S0
    S5 -.->|"settles"| S9
    S9 -.->|"gateway margin only"| S4

The invariant: raw card data exists in exactly two places at any moment — inside the vault's hosted fields (browser → vault TLS) and in the single leg from the vault to the acquiring partner. The gateway, its logs, its database, and the merchant's site never hold or transport a PAN. That is what keeps merchant PCI burden minimal and the platform's compliance self-assessable.

Role → responsibility table

Role	Certification	Responsible for	Card data exposure
Merchant webshop	lowest SAQ class	orders, UX, integration	none
digid pay gateway	service provider, annual self-assessment (SAQ D-SP); empty card-data environment	orchestration, plans, keys, webhooks, brand, support	none — tokens only
digid pay tokenization vault	PCI DSS certified service provider	card capture (hosted fields), secure storage, token↔card translation	yes, inside its certified boundary
Acquiring partner	PCI DSS certified · licensed	merchant KYC/underwriting, SCA/3-D Secure, scheme clearing, settlement	yes, end to end as the regulated party
Card schemes + issuer	scheme rules	authorization decisions	yes, within schemes

What a services partner can operate without touching anything sensitive

Merchant recruitment, onboarding hand-holding (KYC completes directly with the acquiring partner, not with digid pay), integration support against these docs and the snippet, first-live-payment accompaniment, and dispute routing (the acquiring partner answers them). No card data, no funds, no underwriting — clean to contract.

Related

• Tokens & card data — the model behind this diagram.
• PCI posture — the merchant-facing summary.
• Settlement — the T+n flow.