Test cards & sandbox
The sandbox includes a deterministic test PSP (the simulator) plus real Stripe, Adyen and Shift4 test modes. Everything below is scripted and repeatable — perfect for CI.
Simulator (method sim_card)
The last two digits of the amount select the outcome:
| amount ends in | outcome |
|---|---|
…05 | declined — insufficient_funds |
…51 | declined — card_declined |
…61 | 3DS challenge — requires_action |
…19 | technical failure — psp_timeout (ambiguous: payment held in processing, no fallback) |
…99 | technical failure — psp_error (ambiguous: payment held in processing, no fallback) |
| anything else | success — captured (or authorized with manual capture) |
Example: 4000 captures, 4005 declines, 4019 times out. A timeout is ambiguous — the charge may exist at the PSP — so the payment is held in processing for reconciliation instead of being retried on another provider (see routing & fallback). To exercise your fallback chain, disable a connection or point one at an unreachable host.
Stripe test mode (method card)
stripe.token | outcome |
|---|---|
pm_card_visa | success |
pm_card_chargeDeclinedInsufficientFunds | insufficient_funds |
pm_card_threeDSecure2Required | 3DS challenge |
Full catalogue: the Stripe testing docs — every token works through Vermilion unchanged.
Adyen test mode (method card)
Use Drop-in-style encrypted fields with Adyen's test_ convention:
| field | value |
|---|---|
adyen.encryptedCardNumber | test_4111111111111111 |
adyen.encryptedExpiryMonth | test_03 |
adyen.encryptedExpiryYear | test_2030 |
adyen.encryptedSecurityCode | test_737 |
Deterministic refusals: add adyen.testAcquirerResponseCode — "12" yields insufficient_funds, "6" an expired card, "2" a generic refusal.
Environments
- Sandbox and live are fully separate: keys, data, PSP connections, webhooks.
- The simulator exists only in sandbox; live environments route to real PSPs only.
- Switch environments in the dashboard's sidebar selector.