Test mode
Every account has a test mode with its own keys and its own data. Test requests go through the same API and behave like live ones, but no card is charged and no money moves.
What’s the same, and what isn’t
- The same: every endpoint, every validation rule, idempotency, webhooks, events and the dashboard.
- Separate: test keys (
sk_test_,pk_test_) only see test objects, and test events only go to test webhook endpoints. Live keys never see test data. - Different: nothing is charged. Test charges never pay out, and they don’t count toward fees.
In the dashboard, the Test mode switch shows your test data; everything you do there stays in test mode.
Triggering declines and failures
The cents of a test charge’s amount choose what happens. Use these to check how your integration handles each case:
| Amount ends in | Example | Result |
|---|---|---|
951 | 1951 ($19.51) | Declined: 402 card_declined, decline_code: insufficient_funds |
952 | 1952 ($19.52) | Declined: 402 card_declined, decline_code: card_declined |
953 | 1953 ($19.53) | Declined: 402 card_declined, decline_code: expired_card |
954 | 1954 ($19.54) | No answer in time: 502 processor_unavailable. The charge is unknown, then resolves as succeeded, with an event. |
| anything else | 2000 ($20.00) | Succeeds |
The last three digits of the amount in cents count, so 1951 and 10951 both decline for insufficient funds.
Going live
When your account’s application is approved, create live keys in the dashboard, use them in place of the test keys, and add live webhook endpoints. Test objects don’t carry over: customers and saved cards need to be created again in live mode.