Sandbox

Status. The sandbox environment is live: it routes test payments, mints keys, and settles nothing. The open public sandbox merchant and its shared keys are planned — a provisioning task. Until then, sandbox keys come from your own sandbox merchant account after signup.

The sandbox is a full mirror of the production API against test rails provisioned by digid pay:

• payments never move real money,
• card data follows the same token-only rules as production,
• everything is labelled livemode: false.

Two key tiers

Tier	Keys	Status
Your sandbox account	pk_sandbox_… / sk_sandbox_… per account	live (after signup)
Open public sandbox	shared pk_sandbox_… / sk_sandbox_… issued to a dedicated "Public Sandbox" merchant	planned

When the open sandbox provisions, anyone can call the API with the published keys and the exact contract below without signing up.

Open sandbox contract (planned)

Shared credentials will be published here and mirrored in the dashboard test page. They are enforced as follows:

• Sandbox-only routing. A sandbox key that attempts a livemode PaymentIntent is rejected.
• Test-PAN only. Card entry is token-only (rule R1); where a token is minted, only test PANs in the permitted BIN series succeed. Any raw number-shaped field in a payment request under a sandbox key is rejected with a structured error.
• Amount caps. PaymentIntents over the sandbox cap are refused.
• Per-key rate limits. Edge rate limits apply per key (see Rate limits).
• No settlement. The ledger is demo-only; nothing settles and no money moves.

PCI integrity rules (binding for the open sandbox)

The empty-card-data-environment story must hold even for anonymous traffic:

1. R1 — Token-only ingestion. The sandbox exposes the same capture model as production. Card entry happens through digid pay Secure Fields; PANs terminate in the vault's test project, never in request bodies or logs. Raw card fields are rejected for sandbox keys.
2. R2 — Card-testing prevention. Test-PAN whitelisting by BIN series, low amount caps, per-key rate limits and no settlement path make stolen-card validation against the sandbox worthless.
3. R3 — Zero PAN retention. The same log scrubbers used in production apply to sandbox traffic. If R1 ever regresses, scrubbers and no body-logging are the safety net.
4. R4 — Sandbox ≠ evidence. Sandbox flows are never described as PCI-scoped. The compliance argument rests on the production token-only architecture; a test-PAN-only sandbox with R1–R3 keeps systems out of a real card-data environment even under abuse.

Test cards

Use these in digid pay Secure Fields in sandbox. They never hit a real card network.

Card	Outcome
4242 4242 4242 4242, any future expiry, any CVC	succeeds
4000 0000 0000 0002	declined (card_declined)
4000 0000 0000 0008	declined — insufficient funds
4000 0000 0000 0005	declined — expired card
4000 0000 0000 0127	requires SCA (requires_action)
any other valid-shape test PAN	declined

Expiry must be a future month; CVC any three digits. Full brand-specific test ranges are listed in the dashboard test page once you are signed in.

Test PAN 4242 4242 4242 4242 is a published test card — harmless. Real card data never appears here, and never send a real PAN into sandbox (R1 rejects it anyway).

Trying it

# Create a PaymentIntent in sandbox (test rails)
curl https://api.digid.cc/v1/payment_intents \
  -u sk_sandbox_...: \
  -H "Idempotency-Key: sandbox-test-1" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 1500,
    "currency": "eur",
    "merchant_reference": "sandbox-demo-1"
  }'

Then confirm it with a token captured from Secure Fields against the test card that produces the outcome you want to exercise:

curl https://api.digid.cc/v1/payment_intents/pi_.../confirm \
  -u sk_sandbox_...: \
  -H "Idempotency-Key: sandbox-test-1-confirm" \
  -H "Content-Type: application/json" \
  -d '{ "payment_method": "pmt_test_..." }'

Expect status: succeeded, or requires_action / failed matching the card you used. Every transition also emits a webhook.

Hard limits in sandbox

Limit	Value
Max amount per PaymentIntent	documented in dashboard test page (low)
Per-key request rate	see Rate limits
Settlement	none — ledger demo only
Raw card fields	rejected (R1)
Live-mode intents under sandbox keys	rejected

Between sandbox and live

Sandbox and live are modes on the same merchant account — same dashboard, same object model, separate key pairs (sandbox vs live). Live keys are only minted after activation (Accounts). A sandbox key never moves money; a live key never touches test rails.