Stripe test cards

How to use a Stripe test card

Three steps. Test cards are accepted only by test API keys, so nothing here can touch a real card or a real customer.

1. Switch to test keys. Use your test publishable and secret keys, or a sandbox. Stripe's services agreement forbids putting real card details through a test flow, and it also forbids putting test numbers through a live one — they are simply declined.
2. Pick the card for the outcome you want. Use 4242 4242 4242 4242 for a plain success. To exercise your error handling, pick the card whose row names the decline code you want to see, and give it any three-digit CVC and any future expiry date.
3. In server code, use the PaymentMethod instead. Stripe recommends passing a token such as pm_card_visa rather than raw digits in API calls, so your test code never contains a card number. The PaymentMethod column carries the token for every card that has one.

Which card triggers which failure — and what your webhook will see

Handling a failed payment well means holding three things in your head at once: the error.code your API call throws, the decline_code the issuer attached to it, and the event that later lands on your webhook endpoint. Stripe documents those on three different pages, so most integrations are written against one of them and surprised by the other two. This is the same information as one row per outcome.

Two habits fall out of reading it as one table. First, card_declined is not a reason, it is a category — the reason is in decline_code, and only three of the eight declines above even carry one. If your error handler switches on error.code alone, insufficient funds and a stolen card look identical to it, and you will show the wrong message to the customer whose card simply ran out of money.

Second, some outcomes never appear in the response at all. A charge queued for review, a dispute opened three weeks later, an asynchronous refund that flips from succeeded to failed — none of those are visible at the moment of the API call. They arrive as events, or they do not arrive at all because the endpoint was never built. That is the failure mode worth testing on purpose: block the card, then check what your system did with the event.

Two footnotes the table cannot hold. Stripe skips the CVC and postal code checks entirely if you do not send those fields, so the cards that simulate a failed check quietly succeed unless your form actually collects them. And for Radar-blocked payments, generic_decline is documented as the code that covers "Radar or Adaptive Acceptance blocked the payment" — which is deliberate: the customer must not be told that they were flagged as fraudulent.

Testing 3D Secure

3D Secure is the authentication step European regulation requires for most online card payments, and it is where a working integration most often falls over — because the happy path never sees it. A payment that needs authentication does not fail and does not succeed: it comes back with the PaymentIntent in requires_action, and your front end has to hand control to Stripe.js so the customer can complete the challenge.

Nine cards in the table exercise the branches, and the distinction that saves the most time is required versus supported:

• 4000 0000 0000 3220 — authentication is required and succeeds. This is the card to build against. Use it, and you will discover whether your client actually calls the confirmation step or silently treats requires_action as a failure.
• 4000 0000 0000 3055 — 3D Secure is supported but not requested by default. Useful for checking that you have not made authentication mandatory by accident.
• 4000 0084 0000 1629 and 4000 0084 0000 1280 — the two ways the flow can end badly: the customer authenticates and the issuer declines anyway, and the lookup itself errors out. Both come back as card_declined, so an error handler that assumes a completed challenge means a completed payment will show a success screen for a payment that never happened.
• 4000 0025 0000 3155 and 4000 0027 6000 3184 — the saved-card cases. The first needs authentication for off-session charges until the card is set up for future payments; the second always needs it. If you plan to charge people later without them present, these two are the difference between a working renewal and a dead one.

One thing that catches people out: only the cards in this group genuinely test 3D Secure. Other test cards may trigger it, but Stripe returns attempt_acknowledged and skips the extra steps, so your challenge UI never renders and you conclude, wrongly, that it works. Redirects also do not happen for payments created directly in the Stripe Dashboard — drive it from your own front end or from an API call.

Testing refunds, disputes and the things that arrive late

Refunds in live mode are not instant and are not guaranteed. A refund can report success and fail hours later, or sit at pending and resolve afterwards. Almost every test suite misses this, because with any ordinary test card refunds settle immediately and never change status again. Two cards restore the real behaviour: 4000 0000 0000 7726 starts the refund pending and later moves it to succeeded, and 4000 0000 0000 5126 reports succeeded and later fails. Both emit an event afterwards, which is exactly the code path you want to have written before a customer is on the phone about money they never got back.

Disputes work the same way in slow motion. The charge succeeds normally, then a chargeback appears days later, with charge.dispute.created as the only notification you will get. 4000 0000 0000 0259 raises a fraud dispute, 4000 0000 0000 2685 raises "product not received", and 4000 0000 0000 1976 raises an inquiry rather than a full chargeback — worth separating, because an inquiry can often be closed without escalation and a chargeback cannot. 4000 0000 0000 5423 produces an early fraud warning instead, which is the network telling you a dispute is probably coming while there is still time to refund voluntarily.

To simulate the outcome as well as the event, respond to the dispute with the literal evidence strings Stripe reserves for testing: winning_evidence closes it as won, losing_evidence closes it as lost, and escalate_inquiry_evidence turns an inquiry into a real chargeback. Pass whichever one as the uncategorized text field.

Last of the late-arriving group: 4000 0000 0000 0077 puts the funds straight into your available balance rather than the pending one. That is not a payments test, it is a bookkeeping test — useful if anything downstream reconciles payouts and you would rather not wait out a settlement window to find out whether it works.

Download the fixtures as JSON or CSV

A table you have to copy by hand is a table you will get wrong. The two download buttons at the top of the page give you the same 55 cards as machine-readable files, generated in the browser from the data this page is rendered from — so what you download cannot drift from what you just read.

The JSON is an object with source, checked, count and a cards array. Each card carries a stable id you can reference from a test name, the digits, the brand, the group, a one-line description, the CVC and expiry rules, and the three cross-reference fields: payment_method, error_code, decline_code and webhook_event. Fields that do not apply are null rather than absent, so a parser never has to guard for missing keys.

The CSV carries the same eleven columns with RFC 4180 quoting, which means it opens in a spreadsheet and loads in pandas without a converter argument. Handy for a seed script, or for the QA spreadsheet someone will inevitably ask you for.

Both downloads follow whatever filter is applied. Narrow the table to declines, press Download JSON, and you get ten rows rather than fifty-five — which is usually what a parameterised test wants:

test.each(fixtures.cards.filter(c => c.group === 'decline'))(
  '$id surfaces $decline_code',
  async ({ payment_method, error_code, decline_code }) => { /* … */ },
);

The files carry the source URL and the date they were checked, because a card list without a date is a card list you cannot trust in six months. If Stripe changes a number, the honest fix is to re-check the source rather than to keep a stale copy in your repository.

What you are actually building

Nobody looks up test cards for fun. You are here because you are wiring a checkout, and the checkout is one piece of a larger thing: a catalogue, a price the customer cannot edit, a session created somewhere with a secret, a webhook that decides whether the order counts as paid, and then everything that happens after the money arrives.

The piece that goes wrong most often is not the card. It is the price. A static site that keeps its prices in HTML and posts an amount to a checkout endpoint is trusting the browser with the number, and the browser is not trustworthy — that is a whole class of bug the test cards will never catch, because a tampered payment succeeds beautifully.

Clize builds on Stripe Checkout for exactly this reason and puts the price on the server side: a hosted store prices every basket against the _catalog.json deployed with the site and ignores whatever amount the client claims. If that is the shape of your problem, the catalogue file has a generator and a validator here, and if you only need one customer to pay one amount, clize pay link --amount 49 returns a live Stripe Checkout URL without a Stripe account of your own — that charge is real money, so keep it well away from the numbers on this page.

$ npm i -g @clize/clize && clize login
$ clize pay link --amount 49 --for "invoice 1042"