Stripe's published test card set is the top pick for most teams that need a test card, because one documented list covers approvals, decline codes, 3D Secure challenges and address verification. The criteria used in this guide are scenario coverage, documentation clarity, isolation from live credentials, and how faithfully each sandbox reproduces production behavior. A test card is a card number issued for sandbox use only. It passes the same format checks as a real card, it triggers a predictable result, and it never moves money.

What a test card actually is

A payment card number carries an issuer identification number in its leading digits, a check digit at the end, and an expiry and security code alongside it. A test card mimics that structure exactly. What separates it from a live card is context. The gateway links specific numbers to specific outcomes, such as an approval, a soft decline, a hard decline, a 3D Secure challenge or a lost card response. Those mappings only apply when the request is signed with a test API key. Send the same number with a live key and the authorization will fail at the network, which is the safety mechanism that keeps sandbox traffic away from real settlement.

Stripe test cards

Stripe documents a broad set of numbers in its developer reference and states the expected result for each one, including decline codes, radar rules and wallet behavior.

  • Pros: wide coverage of decline and dispute scenarios, clear per-number outcome tables, matching test keys for every product, and consistent behavior across server and mobile SDKs.
  • Cons: a handful of numbers are retired or renamed over time, and sandbox fraud rules do not mirror every live issuer rule.

Use it when you are building checkout, subscription billing or dunning flows and need to reproduce a specific decline without guessing at the outcome.

Adyen test cards

Adyen publishes test card sets for each payment method it supports, including regional schemes that most gateways skip.

  • Pros: strong coverage of non-US schemes, documented 3D Secure frictionless and challenge flows, and test data that matches its own risk and authentication products.
  • Cons: the documentation is split across method pages, so finding the right number takes longer, and the sandbox setup needs a merchant account configuration first.

Use it when you sell across multiple countries and need to test local payment methods rather than a single global card form.

Braintree and PayPal sandbox cards

Braintree supplies test numbers inside a PayPal developer sandbox, with a separate set for card verification and 3D Secure.

  • Pros: card and wallet testing live in one environment, so you can test a PayPal balance payment and a card payment in the same session. Decline simulation is well documented.
  • Cons: sandbox accounts need to be created per environment, and some CVV and postal code responses differ from what a live processor returns.

Use it when your checkout mixes wallets with cards and you need to confirm the order of operations across both.

How to verify a test card result

  1. Confirm the request is using a test key, never a live one.
  2. Use a number from the provider's own documentation for the outcome you want.
  3. Check the response object, not just the HTTP status. Decline codes live in the body.
  4. Test at least one approval, one soft decline and one hard decline.
  5. Run a 3D Secure challenge and a frictionless flow if your market requires authentication.
  6. Trigger a CVV mismatch and a postal code mismatch separately so you can see which field your form reports.
  7. Repeat the request with the same idempotency key to confirm retries do not create duplicate charges.

Test cards are not a substitute for real card data

Staging environments should never hold live card numbers. The PCI Data Security Standard restricts storage of sensitive authentication data, and card data used without the holder's authorization is fraud regardless of the environment. Test numbers exist so that developers can build and validate flows without touching anyone's account. Keep them in fixtures and documentation, keep live keys out of local machines, and treat any real card number that appears in a log or database as a security incident.

Common mistakes

  • Hardcoding a test number in production configuration and shipping it to live traffic.
  • Assuming Luhn validity means the number is authorized. The check digit proves format only.
  • Testing one decline code and treating the flow as covered.
  • Forgetting that expiry dates on test cards still need to be in the future.