Stripe Test Cards Generator

Stripe test cards and the developer-friendly sandbox

Stripe was founded in 2010 by Irish brothers Patrick and John Collison and grew into one of the most influential payment processors in the world (valued above 70 billion dollars at its peak). Its appeal among engineers is mostly cultural — a clean REST API, official SDKs in every major language and exhaustive documentation. The test mode is fully isolated from the live mode and uses distinct API keys: secret keys start with sk_test_ and publishable keys with pk_test_. Touching a test key never touches real money, real customers or real bank rails — but every webhook, every PaymentIntent and every error mirrors the production behaviour.

This generator lists the official magic card numbers Stripe accepts in test mode. Any future expiration date and any three-digit CVC (four digits for American Express) work. Use these numbers when wiring up Checkout, the Payment Element, subscriptions or one-off charges from a backend.

The famous test numbers

A few card numbers have entered developer folklore. 4242 4242 4242 4242 is the canonical successful Visa — it is the first thing every Stripe tutorial uses. 4000 0000 0000 0002 triggers a generic decline. 4000 0000 0000 9995 simulates insufficient funds (good for surface-level UX testing). 4000 0027 6000 3184 forces a 3D Secure 2 authentication challenge — useful for European Strong Customer Authentication (SCA) flows. 5555 5555 5555 4444 is the most common Mastercard test. 4000 0000 0000 0259 opens a dispute after the charge — essential for testing chargeback webhooks.

3D Secure, SCA and global regulations

3D Secure is the protocol that adds a second authentication step (an SMS code, a banking app prompt) to card transactions. The European PSD2 directive made it mandatory through Strong Customer Authentication. The Brazilian Central Bank has a roughly analogous framework via Resolução 4.658 and the Resolução Conjunta 6 on cyber security, although enforcement targets the acquirer rather than the merchant. Stripe ships a card per scenario — frictionless, challenge required, declined after auth — so you can rehearse the entire SCA matrix without leaving the sandbox.

Brazilian payment methods inside Stripe

Stripe officially launched in Brazil in 2024 and supports local cards (including Hipercard and Elo), Pix via QR Code and boleto bancário. In sandbox, Pix payments can be simulated instantly through the Dashboard; boletos settle within seconds rather than the one-to-three business days seen in production. For comparison, Brazilian-born processors like Mercado Pago, Pagar.me (acquired by Stone in 2016), Cielo, Stone and dLocal publish similar test cards and sandbox flows — the concept is industry-standard, not a Stripe exclusivity.

Webhooks, idempotency and the Stripe CLI

Two production patterns deserve special test coverage. Webhooks arrive asynchronously and must be verified with the signing secret — never trust a webhook without checking the Stripe-Signature header. The Stripe CLI exposes stripe listen --forward-to localhost:3000/webhook for local development and stripe trigger payment_intent.succeeded to simulate events on demand. Idempotency keys protect against double charges when the network blinks during a request — include a unique Idempotency-Key header per business operation and replays will return the original response instead of charging twice.

FAQ

Can I buy something real with a test card? No. Test numbers are accepted only by test-mode keys; pasting them on a live checkout returns Your card was declined.

Do I need 4242 in production? No — production uses real cards issued by real banks. Test numbers exist only to exercise edge cases without spending money.

How long until boleto settles in production? One to three business days after the customer pays at the bank or app. In sandbox it is immediate so you can finish your QA in a single session.

Mock library or real sandbox — which is better? Mocks like nock are useful for unit tests; the real Stripe sandbox is mandatory for integration and end-to-end tests because it exercises the actual webhook signing, the 3DS redirect and the asynchronous lifecycle.