Test Credit Card Information: Sandbox Card Numbers Guide

Stripe's published test card library is the top pick for most teams. It is the most complete public set, it covers approvals, declines, and 3-D Secure challenges, and it is maintained next to the API docs. I judged each option on four criteria: how many failure scenarios it simulates, whether it supports authentication testing, how quickly a developer can find the right number, and whether the list gets updated when card network rules change.

How to Choose the Best Card Test Set for Buying or Selling CVV

What test credit card information actually is

A test card number is a synthetic primary account number published by a payment processor so developers can run transactions against a sandbox. The numbers pass a Luhn check, carry a plausible issuer range, and route only to test endpoints. No bank account sits behind them, and no real person is charged.

more on this topic

This is not the same thing as card data pulled from a breach. A test PAN has no CVV that belongs to a cardholder, no billing address, and no value outside a sandbox. Buying, selling, or trading real card numbers is a crime in every US jurisdiction, and a set of test numbers cannot be repurposed for that. If a page offers live card data for sale, it is not test data.

related article

Stripe test cards

Stripe's list is the reference implementation most developers reach for first. The classic approval number, 4242 4242 4242 4242, appears in nearly every tutorial written in the last decade, and a companion number, 4000 0000 0000 0002, triggers a generic decline so you can test your error states.

• Pros: covers approvals, specific decline codes, insufficient funds, expired card responses, and 3-D Secure authentication flows. Numbers are grouped by scenario, so you can pick a failure mode instead of guessing.
• Pros: works with Stripe Elements, Checkout, and the raw API, and the docs ship alongside the SDKs you are already installing.
• Cons: the numbers are built for Stripe's sandbox. Pointing them at another gateway usually produces a routing error rather than a useful test result.
• Cons: the list is long enough that new developers sometimes grab a decline card by accident and spend an afternoon debugging a working integration.

Use case: solo developers, small SaaS teams, and anyone building a first payment integration or a subscription billing flow.

PayPal and Braintree sandbox cards

PayPal's developer sandbox and Braintree both ship test card numbers, and Braintree adds a card generator inside the dashboard so you can mint a number with the exact issuer and response code you need.

• Pros: the only realistic way to test PayPal-specific flows, including vaulting and reference transactions.
• Pros: the generator removes the guesswork when you need a specific CVV or postal code response.
• Cons: fewer pre-built decline scenarios than Stripe publishes.
• Cons: you need a sandbox business account before any number works.

Use case: marketplaces and stores where PayPal is the primary or secondary checkout button.

Adyen and Worldpay test cards

Enterprise gateways publish their own test sets, often organized by card scheme and region.

• Pros: strong coverage of regional schemes that US-focused processors ignore, plus dedicated 3DS2 simulators.
• Pros: response simulation covers AVS and CVV mismatches in detail, which matters for high-risk merchant accounts.
• Cons: test credentials sit behind a merchant account or partner portal, so access takes longer.
• Cons: documentation is split across several portals and release notes.

Use case: teams with an existing enterprise contract, or anyone testing cross-border and multi-scheme routing.

Criteria that matter when you choose a set

1. Luhn validity, so your client-side validation passes instead of rejecting the number before it reaches the gateway.
2. Approval and decline coverage, so you can test both the happy path and every error message your UI renders.
3. Issuer variety across Visa, Mastercard, American Express, and Discover.
4. 3-D Secure and SCA simulation, which is now mandatory for European and increasingly common for US traffic.
5. CVV and AVS response codes, so your fraud rules can be exercised.
6. Maintenance, meaning the list is refreshed when networks retire ranges.

How to use test cards without breaking the rules

Keep test keys and live keys in separate environments, and never send a test PAN to a production endpoint. Stripe and the other processors will reject it, and repeated attempts can trip risk monitoring on your live account. Store test data in a sandbox database, not in the same tables as real customer records. Read the processor's acceptable use terms before you automate anything.

One more boundary worth stating plainly: test numbers exist to validate code, and they have no cash value. They are published by the companies that run the rails. Any listing that claims to sell working card numbers with matching CVV is offering stolen data, and buying it carries federal exposure under wire fraud and access device statutes.

Quick recommendation

Start with the Stripe set if you are building a new integration, because the coverage is broad and the documentation is short. Move to the PayPal or Braintree set when PayPal is on your checkout page, and to Adyen or Worldpay when you already have an enterprise contract and need regional scheme testing. Whichever you pick, verify every number against the processor's own documentation the day you wire it into your test suite, since published ranges do change.