Test cards
The test processor ships with every plugin, needs no credentials and behaves identically on every platform. Card numbers decide the outcome, so a test suite can assert on real behaviour instead of mocking it.
Any expiry date in the future and any three-digit CVC are accepted unless the table says otherwise.
Deterministic outcomes
| Card number | Outcome |
|---|---|
4111 1111 1111 1111 |
Captured |
4242 4242 4242 4242 |
Captured |
5555 5555 5555 4444 |
Captured, brand mastercard |
4000 0000 0000 0002 |
Declined — card_declined |
4000 0000 0000 9995 |
Declined — insufficient_funds |
4000 0000 0000 0069 |
Declined — expired_card |
4000 0000 0000 3220 |
Simulated 3-D Secure challenge inside the iframe, with Complete and Fail buttons |
4000 0000 0000 0341 |
Authorization succeeds, capture fails |
| Any other Luhn-valid number | Captured |
Special cases that do not depend on the card:
| Trigger | Outcome |
|---|---|
Order amount exactly 44.00 |
processor_error — a technical failure, which is what triggers failover |
CVC 000 |
incorrect_cvc |
Refund of an order whose amount was 44.00 |
Refund fails; all other refunds succeed |
Processor references from the test processor look like test_ch_<random>.
What each one is for
4111 1111 1111 1111— the happy path. Use it for the first end-to-end run.4000 0000 0000 0002— proves that a decline does not fail over: the iframe resets, the customer is asked for another card, and no second shop is contacted.- Amount
44.00— proves that a technical failure does fail over: the seller re-routes with the failing shop excluded and the next candidate takes the payment. Put a second candidate in your rule before you try it. 4000 0000 0000 3220— proves that a 3-D Secure challenge works inside the iframe, including the parent page waiting for the result rather than timing out.4000 0000 0000 0341— proves that an authorization that later fails to capture leaves the order in the right state and does not mark it paid.
Stripe in test mode
When the charger shop uses Stripe with test keys, use Stripe's own test cards — they are documented by Stripe and behave the same way through our flow. The ones our end-to-end suite uses:
| Card number | Outcome |
|---|---|
4242 4242 4242 4242 |
Succeeds, no authentication |
4000 0025 0000 3155 |
Requires 3-D Secure authentication |
4000 0000 0000 9995 |
Declined — insufficient funds |
4000 0000 0000 0002 |
Declined — generic |
Never put a live key in a test shop, or a test key in a live shop. The environment is part of the shop key prefix and part of every grant, so a mismatch fails loudly rather than silently charging someone.
Sandbox and billing
Test-environment decisions are never billed, however many you make. Run your continuous integration against the sandbox as hard as you like — see pricing.