Test Credit Card Numbers: A Reference for Payment Testing

TL;DR

• A test credit card is a number issued by a payment provider that behaves like a real card inside a sandbox while moving zero money.
• Stripe's universal success card is 4242 4242 4242 4242, with any future expiry date and any three-digit CVC. American Express takes a four-digit CVC.
• Specific test credit card numbers trigger specific declines, which is how you cover the error paths most suites skip.
• Stripe advises using PaymentMethod tokens such as pm_card_visa in code rather than raw numbers, since embedded card numbers can create PCI compliance problems at go-live.

Every payment provider publishes test credit card numbers. They look like real cards, pass validation, and reach your code the same way a customer's card does, while moving no money and touching no real account.

This page collects the numbers worth keeping to hand, grouped by what they do rather than by provider marketing. All values below come from provider documentation, linked at each section.

Which Stripe Test Credit Card Numbers Simulate a Successful Payment?

These test credit card numbers simulate a successful payment. Use any future expiry date, such as 12/34, and any three-digit CVC. American Express requires four digits.

Source: Stripe test card numbers.

One detail worth knowing: cross-border fees are assessed on the issuer country, so cards issued outside the US such as JCB and UnionPay can attract a cross-border fee even in a sandbox. A test credit card that appears to cost more than another is usually explained by this.

Which Test Credit Card Numbers Trigger Each Decline?

This is the table that gets needed often and used rarely. Each test credit card below triggers a specific failure, which lets you assert that your error handling says something useful rather than showing a generic message.

Source: Stripe test card numbers.

The distinction between lost_card and stolen_card matters for messaging. Both decline, and in most jurisdictions your checkout should avoid telling the user which, since that detail is useful to whoever is holding the card.

Worth testing explicitly: incorrect_number uses 4242 4242 4242 4241, a single digit different from the universal success card. It fails the Luhn check, which makes it the right value for verifying client-side validation separately from gateway behaviour.

What Test Credit Card Numbers Do Other Providers Use?

Each gateway maintains its own set, and the numbers rarely transfer between them.

PayPal card testing documents the sandbox cards for its hosted fields and checkout integrations.

Adyen test card numbers covers a wide brand range plus 3D Secure scenarios, and its decline behaviour is driven by the amount in some flows rather than by the card number alone.

Where you integrate several providers, keep the sets separate per environment configuration rather than in one shared list, since a number valid in one sandbox is usually invalid in another.

Should You Put Test Credit Card Numbers in Code?

This is the part most reference lists skip, and it has real consequences.

Stripe advises keeping raw card numbers out of API calls and server-side code, even in a test environment. The recommendation is to use a PaymentMethod token such as pm_card_visa instead. The reason is PCI scope: code paths that handle raw card numbers can fall inside PCI DSS requirements once they reach production, and test code has a way of becoming production code.

The practical rule that follows: use literal test credit card numbers when typing into a payment form during UI testing, and use provider tokens when writing API tests or server-side fixtures.

The PCI Security Standards Council publishes the requirements that define this scope. The short version: minimising the code that ever touches a card number reduces what has to be assessed.

What to Actually Test

A test credit card is only useful attached to a scenario. Five are worth covering on every payment integration.

The success path, with the amount, currency, and resulting order state all asserted rather than merely checking that no error appeared.

Each decline, with its own case. A checkout showing identical copy for insufficient funds and a stolen card is a support problem and in the second case a security one.

The retry path. A declined payment followed by a corrected card should succeed, and it should charge once. Double charges after a retry are among the most expensive defects a checkout can carry, which is why regression testing over the payment path belongs on every release.

3D Secure and authentication challenges, which behave as a separate flow and frequently break automation. They belong with the same handling pattern as OTP testing.

Network interruption mid-payment. A request that succeeds server-side while the client loses connectivity produces a user who was chared and sees failure. Our network traffic inspection and environment network profiles cover this state.

What Changes About Payment Testing on Mobile?

Mobile adds surfaces a browser-based test misses.

Platform payment sheets, Apple Pay and Google Pay, run in system UI rather than your app. Both provide sandbox modes with their own test accounts, separate from your gateway's test credit card list.

In-app purchases for digital goods route through the app stores entirely, bypassing your payment provider. Apple and Google both supply sandbox tester accounts, and renewal intervals are compressed in sandbox, which changes what a subscription test observes.

Autofill and keyboard behaviour differ enough across devices that a card entry form working on one handset can be unusable on another. Mobile app testing on real hardware is what surfaces this.

Backgrounding mid-payment is a mobile-only state. A user switching apps during a 3D Secure redirect and returning should find a coherent result rather than a reset form.

Where Should Test Credit Card Numbers Be Stored?

Test credit card numbers are public, so secrecy is beside the point. Configuration hygiene still matters.

Hold them in variables scoped per environment rather than hardcoding them into test definitions, so a staging run and a local run resolve the same reference differently.

Keep the gateway's test keys scoped the same way. A test key is harmless; a production key reaching a test environment is the failure worth preventing.

Assert that production builds reject these numbers. A test credit card accepted by your live checkout means a configuration leak, and a scheduled check catches it faster than a reconciliation will.

How Autosana Fits

We run the payment journeys these numbers exist to exercise, on real devices.

Our flows describe the checkout journey in plain language, so entering a decline card and asserting the error message reads as one test rather than a script of field selectors.

Variables holds each test credit card per environment, and environments sets the gateway target and network profile so the interruption case above is reachable.

We group payment scenarios into suites that run on every release candidate, covering success, each decline, and the retry path together rather than leaving error branches for a quieter sprint.

Execution happens on real iOS and Android hardware, which is where platform payment sheets, autofill, and backgrounding behave as users experience them. End-to-end suites crossing a payment gateway are among the most abandoned, usually because each challenge got handled ad hoc.

Conclusion

Take your checkout and count how many of the nine decline codes above have a test case.

Most integrations cover the success path thoroughly and one generic decline. The gap is where support tickets come from, because a user told "payment failed" with zero explanation will contact you rather than retry.

Then test the retry path and assert the charge count. One success after one decline should produce exactly one charge, and verifying that is cheaper than the refund queue that proves it was broken.

FAQ

What is a test credit card?

A test credit card is a number published by a payment provider that behaves like a real card inside a sandbox environment while moving zero money and touching no real account.

What is the most common test credit card number?

Stripe's universal success card is 4242 4242 4242 4242, used with any future expiry date such as 12/34 and any three-digit CVC. American Express test cards take a four-digit CVC.

How do you test a declined payment?

Use a decline-specific number. Stripe's generic decline is 4000 0000 0000 0002, insufficient funds is 4000 0000 0000 9995, and expired card is 4000 0000 0000 0069, each returning its own error code.

Do test credit card numbers work across providers?

Rarely. Each gateway publishes its own set, and a number valid in one sandbox is usually invalid in another. Keep the sets separate per environment configuration rather than in one shared list.

Should you put test card numbers in code?

Stripe advises using PaymentMethod tokens such as pm_card_visa in API calls and server-side code instead, since code paths handling raw card numbers can fall inside PCI DSS scope once they reach production.

What is the difference between 4242 4242 4242 4242 and 4242 4242 4242 4241?

One digit. The second fails the Luhn checksum, which makes it the right value for verifying client-side validation separately from gateway behaviour.

What changes about payment testing on mobile?

Platform payment sheets run in system UI with their own sandbox accounts, in-app purchases bypass your gateway entirely, autofill differs across devices, and backgrounding mid-payment is a state browsers rarely produce.

What payment scenarios are most often untested?

Each individual decline reason, the retry path with its charge count asserted, authentication challenges such as 3D Secure, and network interruption after the server has charged but before the client confirms.