Test cards
The hosts, keys and card numbers to test with — the same for either API version
Sandbox vs production
Sandbox and production are separate hosts, each paired with its own API key prefix:
| Environment | Base URL | API key prefix | PSP connection |
|---|---|---|---|
| Sandbox | https://api.sandbox.settleflow.io | pk_test_... | Built-in simulator PSP (TEST_MERCHANT) — no real charges. |
| Production | https://api.settleflow.io | pk_live_... | Real acquirer. |
The host and the key prefix must match: a pk_test_ key is only valid on the sandbox host, and a pk_live_ key only on the production host.
Routing is enforced server-side: a pk_test_* key only resolves routes backed by the simulator PSPs, and a pk_live_* key only resolves real-PSP routes. There is no way for a test key to accidentally trigger a real charge — and conversely, a live key cannot route to the simulator.
Test cards
The sandbox recognises these card numbers. Use any valid future expiry date (e.g. 12 / 2028) and any 3-digit CVV unless noted.
| Card number | Behaviour |
|---|---|
4111111111111111 | Direct authorize + capture, no 3-D Secure challenge. |
4000000000003220 | Forces a 3DS2 challenge — the response carries a redirect URL. |
4000000000005126 | Payment succeeds; any refund of it is declined by the issuer. |
More test cards for specific edge cases (declines, insufficient funds, soft declines) can be requested from your account manager.
In sandbox, only documented test cards are accepted. Any other card — including a real, Luhn-valid PAN — is rejected as a failed payment with a message stating that only test cards are allowed. This prevents a mis-configured integration from believing a real transaction was captured when it can never be settled.
What the sandbox simulates
- Luhn validation (same as production).
- The 3-D Secure challenge redirect flow — the redirect points at a simulated ACS page.
- Webhook delivery with signed payloads (same HMAC scheme as production, using your sandbox webhook secret).
- Refund and status lookups against sandbox transactions.
What the sandbox does not simulate:
- Real card network authorization latency (responses are faster than production).
- Dynamic chargeback / dispute flows — these must be staged by support.
- Bank-level decline reasons that depend on the issuing bank.
Then what
Version-specific checklists — what to prove before switching, and the cutover itself: