Sandbox behaviour and test data

What test mode is

Every account has two ledgers. They share nothing: separate keys, separate objects, separate webhook endpoints, separate reports. A sk_test_ key cannot read or move live funds under any circumstance, which makes the sandbox safe to hand to a contractor.

• Isolation Your sandbox is yours alone. It is not a shared mock, so one team's data never appears in another's list call.
• Parity Same endpoints, same fields, same errors, same event names. The only difference in your code should be which key it reads.
• Speed Settlement is compressed: what takes a working day in live mode resolves in seconds, so an end-to-end test finishes inside a CI run.
• Reset Clear the sandbox from the dashboard at any time. Objects go, keys and endpoint configuration stay.

Test cards

Use any future expiry date, any three-digit CVC and any postcode. The number decides the outcome. All of them run through hosted fields exactly as a real card would.

When you need a decline the card list does not cover, steer it with the amount instead. The trigger works on every method, so the same test fixture exercises cards and APMs alike.

# the last two minor units steer the outcome in test modeamount: 4200   → succeededamount: 4201   → failed, insufficient_fundsamount: 4202   → failed, do_not_honoramount: 4203   → failed, fraud_suspectedamount: 4204   → processing for 90s, then succeededamount: 4205   → canceled by the payer​# works on every method, including the APMs below

Live mode ignores these entirely — 4201 is simply 42.01 EUR there. The trigger table is a test-ledger behaviour, not a hidden API.

Forcing 3-D Secure outcomes

Authentication is where checkout conversion is won or lost, so it deserves more than one happy path in your suite. The sandbox challenge page offers every outcome the real flow can produce.

APM and bank simulators

Each alternative method redirects to a simulator that mirrors the real interface closely enough to test your copy and your timing, and offers the same outcome buttons.

Payouts and disputes

Money leaving is easier to get wrong than money arriving, because the failure paths are rarer and therefore less tested. Two IBANs and one card cover the cases that matter.

Disputes in the sandbox run the full lifecycle on a compressed clock: opened, evidence due, submitted, then won or lost depending on whether you uploaded anything. Both endings are worth wiring, because the accounting entries differ. See payouts and anti-fraud for what each state means commercially.

Triggering events by hand

You do not need a real object to test a handler. In test mode a single call fires any event type at every subscribed sandbox endpoint, correctly signed.

# force any event against a sandbox endpointcurl -X POST https://api.bazpay.com/v1/test/events \  -H "Authorization: Bearer sk_test_9f2c…" \  -d '{"type": "dispute.opened",       "payment": "pay_3fJ2Qk8vTn"}'​{ "id": "evt_9Rt2Ny7cVb", "delivered_to": 1 }

delivered_to counts the endpoints that received it. Zero means nothing is subscribed to that type — the usual reason a handler seems not to run.

Three cases worth building into the suite while this is easy:

• The same event twice, to prove your deduplication index actually holds.
• A refund.settled before its payment.succeeded, to prove out-of-order arrivals do not corrupt an order.
• A deliberate 500 from your handler, to watch the retry ladder and confirm the event eventually lands.

Signature verification and the retry schedule: the webhooks guide.

What the sandbox cannot tell you

A green test suite is necessary and not sufficient. Four things behave differently once real money and real issuers are involved, and knowing which four is the point of this section.

• Approval rates Sandbox issuers always follow the script. Real ones decline for reasons no simulator models — velocity, geography, an issuer's own outage.
• Latency Test authorisations return in milliseconds. Live card authorisations take a few hundred, and a bank redirect depends on how fast the payer opens their app.
• Settlement timing The sandbox compresses days into seconds. Reconciliation logic that assumes same-day settlement will pass here and fail in production.
• Fraud rules Your live rule set is tuned against your own traffic. Sandbox scoring is deterministic and will not surprise you the way a real ruleset can.