Test mode is a complete parallel world: its own keys, its own customers, plans, subscriptions, payments and webhooks. Nothing in test mode touches a real card, and test volume never accrues a platform fee.
Use a sk_test_… key and you are in test mode; use sk_live_… and you are in live mode. There is no mode parameter — the key decides, which means a misconfigured environment variable cannot quietly charge a real customer. The dashboard has a matching switch in the top bar.
Enter these on the bank's hosted card page. Any future expiry date and any three-digit security code work.
| Number | Brand | What happens |
|---|---|---|
4242 4242 4242 4242 | Visa | Always approves. Saves the card and approves every charge, first and recurring. |
5555 5555 5555 4444 | Mastercard | Always approves (Mastercard). Same as 4242 but reports a Mastercard brand. |
4000 0000 0000 0002 | Visa | Generic decline. The first charge is declined with card_declined. |
4000 0000 0000 9995 | Visa | Insufficient funds. Declines with insufficient_funds — the most common real decline. |
4000 0000 0000 0069 | Visa | Expired card. Declines with expired_card. |
4000 0000 0000 3220 | Visa | 3-D Secure required. Forces a 3-D Secure step-up, including on recurring charges. |
4000 0000 0000 0341 | Visa | Saves, then fails recurring. The card saves and the first charge succeeds; every later merchant-initiated charge declines. Use it to exercise dunning. |
4000 0000 0000 0259 | Visa | Charge is later disputed. Approves, then the bank raises a chargeback within a few minutes. |
4111 1111 1111 1111 | Visa | Realistic mix. Approves most of the time and declines at a realistic rate — what seeded demo data uses. |
Every first payment goes through 3-D Secure, exactly as it will in production. In test mode the one-time code is 111111; any other value fails authentication so you can exercise that path too.
Recurring charges after the first do not ask for 3-D Secure — that is the entire point of the card binding. The 4000 0000 0000 3220 card simulates the rarer case where an issuer forces a step-up anyway, which surfaces as payment.requires_action.
4000 0000 0000 0341. The card saves and the first charge succeeds.interval: "day".insufficient_funds. The subscription moves to past_due, the customer is emailed an update-card link, and the first retry is scheduled.4242 4242 4242 4242 through the customer portal. The charge is attempted immediately, succeeds, and is reported as recovered revenue.Pay with 4000 0000 0000 0259. The charge approves and the bank raises a dispute against it a minute later, which appears on the Disputes screen with an evidence deadline.
Ronda currently runs against a bank simulator that implements the same flow as Ameriabank's vPOS: a hosted card page, 3-D Secure, binding registration, merchant-initiated charges, declines with real reason codes, refunds, delayed settlement and chargebacks. Swapping in the real bank changes one adapter and no database column — including in live mode, which is a complete money flow in our system regardless of which rail sits underneath.