Test Credit Card Numbers for Developers: Safe Sandbox Testing

Test credit card numbers for developers: safe sandbox payment testing

Last reviewed: September 29, 2026. Payment providers update their test card lists from time to time. Always check your provider's current testing documentation before you rely on a specific number.

Short answer: Test credit card numbers are special numbers that payment providers publish so developers can try out a checkout without moving real money. They only work in a provider's sandbox or test mode, with test API keys. The best-known example is Stripe's 4242 4242 4242 4242, which works with any future expiry date and any three-digit CVC. Braintree and Square document 4111 1111 1111 1111 for their sandboxes. Providers also publish numbers that trigger declines, 3-D Secure challenges and disputes, so you can test failure paths as well as the happy path.

The rule is simple: use only the official test numbers from your own payment provider's documentation, and only in test mode. Never test with a real card, and never try test or made-up numbers on a live checkout. Live systems decline them, and trying to pay for real goods with fabricated card numbers is fraud.

Every online shop, subscription app and marketplace needs a payment form, and every payment form needs to be tested many times before real customers see it. You need to know that a good card goes through, that a bad card is refused with a clear message, that the bank's security check appears when it should, and that your database, emails and webhooks react the right way.

You cannot do that safely with your own card, and you cannot do it with numbers you make up. The answer is the set of test card numbers and test tokens that each payment provider publishes for its sandbox. This guide lists the documented numbers from the major providers and shows how to use them to test declines, Strong Customer Authentication, wallets, refunds, disputes and bank payments. It then covers automated testing, PCI DSS scope, log masking, card-testing attacks and a go-live checklist.

This article is general technical information for developers. It is not legal or compliance advice.

In this guide

What test card numbers are (and are not)
Why you should never test with real cards
Sandbox vs live: keys and environments
How test mode behaves
Stripe test card numbers
Simulating declines and errors
Testing 3-D Secure and SCA
PayPal, Braintree, Adyen, Checkout.com and Square
Testing webhooks, refunds and disputes
Testing Apple Pay and Google Pay
Test bank accounts: ACH and SEPA
Automated testing: unit, integration and end-to-end
Keeping PCI DSS scope small and logs clean
What happens if test numbers reach a live site
Card-testing attacks and how to protect checkout
Common mistakes
Checklist before you go live
FAQ
Bottom line
Sources

What test card numbers are (and are not)

A test card number looks like a real card number but is reserved for testing. Payment providers publish these numbers in their developer documentation. When you send one to the provider's test environment, the provider recognises it and returns a scripted result. One number always succeeds. Another always comes back as "insufficient funds". Another always asks for a 3-D Secure check. Nothing reaches a real bank, and no money moves.

Test numbers follow the same format rules as real cards. They start with the right prefix for their brand (4 for Visa, 51 to 55 or 2221 to 2720 for Mastercard, 34 or 37 for American Express), they have the right length, and, with a few deliberate exceptions, they pass the Luhn checksum, the check-digit formula that catches typing mistakes. To see how that last digit is calculated, read our guide to what the Luhn algorithm is and how it validates a card number.

That format matters. Your front end, your provider's card field and the provider's API all check the format first. A test number gets through those checks, so the rest of your flow runs just as it would for a customer.

What test numbers are not

They are not real cards. No bank issued them, no one holds them, and there is no money behind them.
They are not universal. Stripe's decline cards only trigger declines at Stripe. Always use the list for the provider you are integrating with.
They are not for live systems. In live mode, providers decline known test numbers.
They are not something to invent. A number that merely passes a Luhn check is not a test card. Only the numbers a provider documents have scripted behaviour in its sandbox.

Think of test numbers as switches the provider has wired into its sandbox. Each switch produces one known outcome. Your job is to flip each one and make sure your system handles the result correctly.

Why you should never test with real cards

It is tempting to grab your own card and make a quick $1 payment "just to be sure". Do not. There are several good reasons.

Real money moves. A real card against live keys creates a real charge. You then have to refund it, and depending on your provider and pricing, the processing fee may not come back. A forgotten test subscription can keep billing someone every month.
You create card data you must protect. Once a real card number passes through your staging server, logs or database, you are handling cardholder data, which can pull those systems into scope for the Payment Card Industry Data Security Standard (PCI DSS). Staging servers and debug logs are rarely protected to that level.
It looks like fraud. Many small charges, repeated declines and quick refunds on one card are exactly the pattern issuer fraud systems watch for. Your card may be blocked and your merchant account flagged.
You cannot test the hard cases. You cannot make your own card come back as stolen, expired or blocked for fraud. Test cards trigger each of those outcomes on demand.
Other people's cards are off-limits. Using a colleague's card spreads real card data around. Using card details you found, bought or guessed is illegal.

A narrow exception is a single "live smoke test" after launch, where some teams make one small real purchase with a company card intended for that purpose and refund it. If you do that, follow your company's policy and keep the card number out of your own logs.

Sandbox vs live: keys and environments

Every major payment provider separates testing from real payments. You choose which environment you are talking to mainly through your API keys or credentials.

Provider	Test environment	How you tell test from live
Stripe	Test mode and sandboxes in the Dashboard	Test keys start with `pk_test_` and `sk_test_`; live keys start with `pk_live_` and `sk_live_`
PayPal	Sandbox (developer.paypal.com)	Separate sandbox and live app credentials; sandbox API calls go to `api-m.sandbox.paypal.com`
Braintree	Sandbox (separate sign-up)	Separate sandbox account and keys; the SDK environment is set to sandbox or production
Adyen	Test Customer Area	Separate test and live accounts, API keys and endpoints
Checkout.com	Sandbox	Separate sandbox and production accounts, keys and base URLs
Square	Sandbox per application in the Developer Console	Separate sandbox and production application IDs and access tokens; sandbox calls go to `connect.squareupsandbox.com`

Rules for handling keys

Keep test and live keys apart. Load them from environment variables or a secrets manager, not from code. Development and staging should only ever hold test keys.
Never commit secret keys. Test secret keys still give access to your test data and account settings. Treat both kinds as secrets and use a secret scanner.
Publishable keys are public, secret keys are not. Publishable keys can sit in front-end code. Secret keys stay on the server.
Make the mode visible. A "TEST MODE" banner in the admin panel whenever a test key is loaded prevents big mistakes.
Fail loudly on mismatches. A start-up check that refuses to boot production with a _test_ key, or staging with a _live_ key, catches configuration errors early.

How test mode behaves

Test mode is designed to feel like the real thing, but a few details differ.

Expiry dates and CVCs

At Stripe, you can use any valid future expiry date, such as 12/34, and any three-digit CVC (four digits for American Express). Name and postal code can hold any value unless you are testing address checks. Some providers expect specific values instead: Adyen lists a fixed expiry and CVC for its test cards, and Square lists specific CVVs. If a test card is declined for no clear reason, check this first.

Amounts

You can charge any amount your integration allows, within the provider's normal limits. Some providers, such as Braintree and Checkout.com, use special amounts to trigger particular responses, so a "random" test amount might produce an unexpected decline. Read the docs before you choose values for automated tests.

Nothing leaves the sandbox, but webhooks still fire

Test payments never reach card networks or banks, and test data is kept apart from live data. But test events still send webhook notifications to the endpoints you register for test mode. That means you can, and should, test your whole event-driven flow, not just the payment call.

Test mode also compresses things that take days in real life, such as bank transfers settling or disputes moving through stages. Do not treat test-mode timings as a guide to live timings.

Stripe test card numbers

Stripe's list is the one most developers meet first, and its "4242" card has become shorthand for test payments in general. These brand test cards come from Stripe's testing documentation. Each succeeds in test mode with any future expiry and any CVC.

Brand	Test number	CVC	Notes
Visa	4242 4242 4242 4242	Any 3 digits	The standard success card
Visa (debit)	4000 0566 5566 5556	Any 3 digits	Useful if your logic treats debit differently
Mastercard	5555 5555 5555 4444	Any 3 digits	Standard Mastercard success card
Mastercard (2-series)	2223 0031 2200 3222	Any 3 digits	Checks that your validation accepts the 2-series range
Mastercard (debit)	5200 8282 8282 8210	Any 3 digits	Debit variant
American Express	3782 822463 10005	Any 4 digits	15 digits; four-digit CVC
American Express	3714 496353 98431	Any 4 digits	Second Amex test number
Discover	6011 1111 1111 1117	Any 3 digits	Standard Discover success card
Diners Club	3056 9300 0902 0004	Any 3 digits	16-digit Diners test number
JCB	3566 0020 2036 0505	Any 3 digits	JCB test number
UnionPay	6200 0000 0000 0005	Any 3 digits	UnionPay test number

Stripe also lists country-specific cards, co-branded cards and cards with particular funding types. If your business logic depends on card country or funding type, look up the matching card rather than assuming.

Test payment methods and tokens

Typing card numbers is fine for manual testing in the browser. On the server, you should not send raw card numbers at all. Stripe's integrations send card details straight from the customer's browser to Stripe, and your server only sees a PaymentMethod ID.

For server-side tests, Stripe provides ready-made test PaymentMethods such as pm_card_visa and pm_card_mastercard, and older-style tokens such as tok_visa. You pass these IDs where you would normally pass a PaymentMethod from the browser. Stripe publishes matching IDs for many of its decline and special-case cards too; check the "PaymentMethods" and "Tokens" tabs of its testing page. Your tests never handle raw card numbers, and your server code stays identical in test and live.

Simulating declines and errors

The success path is the easy part. Most real bugs live in failure paths: an unclear error, a spinner that never stops, an order marked as paid when it was not, or a retry that charges twice. Stripe publishes cards that fail in specific ways.

Scenario	Stripe test number	What happens
Generic decline	4000 0000 0000 0002	Declined with `card_declined` and decline code `generic_decline`
Insufficient funds	4000 0000 0000 9995	Declined with decline code `insufficient_funds`
Lost card	4000 0000 0000 9987	Declined with decline code `lost_card`
Stolen card	4000 0000 0000 9979	Declined with decline code `stolen_card`
Expired card	4000 0000 0000 0069	Declined with `expired_card`
Incorrect CVC	4000 0000 0000 0127	Declined with `incorrect_cvc`
Processing error	4000 0000 0000 0119	Fails with `processing_error`
Incorrect number	4242 4242 4242 4241	Rejected with `incorrect_number` because the check digit is wrong
Blocked as highest risk	4100 0000 0000 0019	Blocked by Stripe's fraud screening (Radar)
Attach succeeds, charge fails	4000 0000 0000 0341	Saving the card to a customer works, but later charges are declined

The "incorrect number" card is 4242 4242 4242 4242 with the last digit changed, so it fails the Luhn check. Our Luhn algorithm explainer shows why a single changed digit is always caught. Your front end should catch this before submission and ask the customer to check the number, rather than saying "the payment failed".

What to check for each failure

The message. Show a clear, human message such as "Your card was declined. Please try another card or contact your bank." Do not show raw codes, and do not tell the customer their card was reported stolen; Stripe recommends a generic message for lost and stolen card declines.
The order state. The order stays unpaid, stock is not allocated, and no confirmation email goes out.
The retry path. The customer can try another card without refilling the form or creating a duplicate order.
Logs. The decline is logged with its code, without the card number.
Idempotency. If your server retries after a timeout, idempotency keys stop a payment being created twice.

Test cards cover card-level outcomes only. Also test a slow or unreachable provider API, a webhook endpoint that is down, and a customer who closes the tab mid-redirect. Mocked HTTP responses in your own test suite handle those.

Testing 3-D Secure and SCA

3-D Secure (3DS) is the extra check where the card issuer asks the customer to confirm a payment, usually in a banking app or with a one-time code. In the European Economic Area and the UK, Strong Customer Authentication (SCA) rules mean many online card payments need this check unless an exemption applies. Issuers elsewhere can also request 3DS on risky payments.

Stripe provides cards that simulate each 3DS situation. In test mode, a test authentication page replaces the real bank screen, with buttons to complete or fail the check.

Scenario	Stripe test number	What it tests
Authentication unless set up	4000 0025 0000 3155	Needs authentication for one-off payments; once set up for future use, later off-session payments do not
Always authenticate	4000 0027 6000 3184	Needs authentication on every payment, including off-session ones
Authenticate, then insufficient funds	4000 0082 6000 3178	Authentication succeeds, then the payment is declined
3DS required	4000 0000 0000 3220	A 3DS2 challenge must be completed
3DS supported, not required	4000 0000 0000 3055	Supports 3DS, but succeeds without a challenge

The 3DS cases to cover

Challenge completed. Confirm the order only after this.
Challenge failed. Show a clear message and let the customer retry or use another card.
Challenge abandoned. The customer closes the pop-up. The payment stays incomplete, and your system must not treat it as paid.
Off-session payments. If you charge saved cards later, test what happens when the bank asks for authentication while the customer is away. You need a way to bring them back, often an email with a link.
Mobile and redirects. Test on mobile browsers and in-app web views, where redirects and pop-ups often break.

Adyen, Checkout.com and Braintree document their own 3DS test cards. 3DS test cards are provider-specific, so use your provider's list.

PayPal, Braintree, Adyen, Checkout.com and Square

Here is how the other major providers approach testing. The numbers below appear in each provider's own documentation, but lists change, so confirm them before you hard-code anything.

Provider	Example documented test card	Expiry and CVC	How to simulate failures
Braintree	Visa 4111 1111 1111 1111; Mastercard 5555 5555 5555 4444; Amex 3782 822463 10005; Discover 6011 1111 1111 1117	Any future expiry; see docs for CVV behaviour	Documented test amounts trigger processor declines; fake nonces for other outcomes
Adyen	Visa 4111 1111 4555 1142; Mastercard 5555 3412 4444 1115	Expiry 03/2030; CVC 737 (see docs for Amex)	Documented method to request specific result codes and refusal reasons
Checkout.com	Visa 4242 4242 4242 4242 and 4543 4740 0224 9996; other brands in docs	Any future expiry; see docs for CVV	Specific cards and special amounts return documented response codes
Square	Visa 4111 1111 1111 1111; other brands in docs	Any future expiry; specific CVV per brand	Test nonces such as `cnon:card-nonce-ok` and documented decline nonces
PayPal	Sandbox buyer accounts; sandbox card details in PayPal's docs	As shown in PayPal's sandbox docs	Negative testing to force specific API errors

PayPal sandbox

For PayPal wallet payments you do not use a card number. You log in at checkout with a sandbox "personal" (buyer) account, and payments land in a sandbox "business" account. PayPal creates default sandbox accounts in the developer dashboard, and you can add more with different countries. For PayPal's advanced card processing, where customers type card details into PayPal-hosted fields, PayPal documents sandbox card details for that flow. Its "negative testing" feature lets you force specific API errors.

Braintree sandbox

Braintree, owned by PayPal, has a separate sandbox sign-up. Its list includes 4111 1111 1111 1111, one of the oldest and most recognised test numbers. For server-side tests it documents fake nonces such as fake-valid-nonce. Certain transaction amounts produce specific processor responses in the sandbox, so if a transaction is declined unexpectedly, check whether the amount falls in a documented decline range.

Adyen, Checkout.com and Square

Adyen gives you a separate test Customer Area with its own test cards, most using expiry 03/2030 and CVC 737, plus separate cards for 3DS2 and local schemes. Checkout.com's sandbox documents success cards per scheme, 3DS cards and special amounts that trigger response codes. Square gives each application a sandbox with a test seller account, documented sandbox cards, and test nonces such as cnon:card-nonce-ok for server-side tests.

Testing webhooks, refunds and disputes

A payment is a series of events that plays out over seconds, days or months. Your system learns about most of them through webhooks. If you only test the payment call, you are testing a small part of the flow.

Webhooks

Register a separate webhook endpoint for test mode. For local development, the Stripe CLI can forward test events to a local URL and trigger sample events on demand; other providers offer similar tools or test notifications. Check that:

Signatures are verified. A tampered or unsigned request is refused.
Duplicates are harmless. Providers may send an event more than once, so processing it twice must not ship an order twice.
Order does not matter. Events can arrive out of order.
Responses are fast. Acknowledge quickly and do slow work in a background job, or the provider will retry.
Downtime is recoverable. Turn off your endpoint, make a test payment, turn it back on, and confirm retries arrive.

Refunds

Refund test payments fully and partially, from your admin panel and from the provider's dashboard. Check that order status, stock, accounting records and customer emails all update. Stripe also documents test cards for refund failures, so you can test that path too.

Disputes and chargebacks

Stripe's test card 4000 0000 0000 0259 creates a payment that is then disputed as fraudulent, and Stripe documents other cards for other dispute reasons and inquiries. In test mode you can simulate the outcome by submitting special evidence text, winning_evidence or losing_evidence; check Stripe's docs for current values. Use these to confirm your team is notified, the order is flagged and your evidence process works. For the cardholder side of disputes, see our guide to disputing a credit card charge in the US and UK.

Subscriptions and saved cards

Waiting a month for a renewal is not practical. Stripe's "test clocks" let you move a test customer's time forward and watch renewals, trial endings and retries. Combine them with the "attach succeeds, charge fails" card to test dunning emails and retry logic.

Testing Apple Pay and Google Pay

With digital wallets the customer does not type a card number. The wallet sends an encrypted payment token that your provider decrypts, so testing works differently.

Apple Pay

Apple Pay on the web only appears on supported Apple devices and browsers, over HTTPS, from a domain registered with your provider. You usually cannot test it on plain http://localhost, so teams use an HTTPS tunnel or a registered staging domain. With Stripe, you can use a real card in your Apple Wallet in test mode; Stripe's docs say it returns a test result without charging the card. Apple also offers sandbox tester accounts and test cards for developers working with Apple Pay directly.

Google Pay

The Google Pay API has a TEST environment that returns test payment data rather than a real card token. Google also documents a test card suite you can opt into. Providers such as Stripe, Adyen and Braintree explain how their test modes work with Google Pay.

What to test for wallets

The button appears only where supported, and the page still works where it does not.
The amount, currency and line items in the wallet sheet match your cart.
Shipping changes inside the sheet update the total correctly.
Cancelling the sheet returns the customer to checkout cleanly.

Test bank accounts: ACH and SEPA

Bank debits behave very differently from cards. They take days to settle and can fail after they first look successful, so they need their own tests.

US ACH. Stripe documents the test routing number 110000000 with account numbers that produce different outcomes. For example, account number 000123456789 succeeds, while other documented numbers simulate failures such as a closed account or insufficient funds.

SEPA Direct Debit. Stripe publishes test IBANs for several countries. A common German example is DE89 3704 0044 0532 0130 00, listed as a test IBAN that succeeds. Stripe also lists IBANs that fail, or that succeed and are then disputed. These work only in test mode.

What to test for bank payments

Delayed success. The payment starts as "processing". Do not ship goods until you receive the success event, unless you accept that risk on purpose.
Delayed failure. A payment can fail days later. Your system must be able to reverse an order or suspend access.
Mandates. Show the correct mandate text and store the mandate reference.
Notifications. Some schemes require you to notify customers before debiting them. Test that those emails are sent.

Automated testing: unit, integration and end-to-end

Payment code changes often, and a checkout that worked last month can break after a library upgrade. A layered automated test suite catches that before customers do.

Unit tests: no network

Unit tests should not call your provider. Mock the client library or HTTP responses and test your own logic: amount calculation, mapping decline codes to messages, order state changes and webhook handling. Use sample webhook payloads from the provider's docs as fixtures. This is where to cover most edge cases, such as zero-decimal currencies and partial refunds.

Integration tests: the sandbox, with test tokens

Integration tests call the provider's real test environment with test keys. On the server, use test tokens or nonces rather than raw card numbers: pm_card_visa at Stripe, fake-valid-nonce at Braintree, cnon:card-nonce-ok at Square, and their decline equivalents. This confirms your code and the provider's API still agree on formats and responses.

Keep these tests focused, since they are slower and depend on the sandbox being up. Test environments have rate limits, and providers generally ask you not to load-test against them. For load tests, mock the provider.

End-to-end tests: the real browser

End-to-end (E2E) tests drive a real browser through checkout, commonly with Playwright or Cypress. Here you do type test card numbers, because you are testing what a customer does.

Hosted fields live in iframes. Stripe Elements, Braintree Hosted Fields, Adyen components and similar tools put card inputs in iframes from the provider's domain. Playwright reaches them with frame locators; Cypress needs extra set-up for iframes and cross-origin content.
Keep numbers in one fixture file, with a comment linking to the provider's docs, so an update touches one place.
Test a few paths, not every card. Cover success, one decline and one 3DS challenge per form. Leave the long tail to unit and integration tests.
Handle the 3DS test page. Your test must click "complete" or "fail" on the provider's test page, which often loads in a nested frame.
Do not over-test hosted checkouts. With a fully hosted page such as Stripe Checkout, focus on what happens before the redirect and after the customer returns.

CI pipelines

Store test keys as encrypted CI secrets. Make sure CI logs do not print full request bodies. Add a check that fails the build if a live key pattern, such as sk_live_, appears in the code.

Keeping PCI DSS scope small and logs clean

PCI DSS applies to any business that stores, processes or transmits cardholder data. The current version is PCI DSS v4.0.1. How much of it applies to you depends heavily on how your checkout is built, and those design choices are made while you build and test.

Let the provider handle card numbers

The simplest way to reduce scope is to keep card numbers off your servers entirely:

Hosted payment pages. The customer is redirected to a provider page, such as Stripe Checkout, and returns when done.
Hosted fields and embedded components. Card inputs are provider-served iframes, such as Stripe Elements, Braintree Hosted Fields, Adyen Web Components, Checkout.com Frames or Square's Web Payments SDK. Your server receives only a token.

Merchants whose card payments are fully outsourced this way may be eligible for the shortest self-assessment questionnaire, SAQ A. If your own page code handles card data directly, you are likely in a larger scope such as SAQ A-EP or SAQ D. Your acquirer or a Qualified Security Assessor can confirm which applies. Under v4, even SAQ A merchants have requirements about protecting their payment pages from tampering, so hosted fields reduce your scope without removing your responsibilities.

Building with hosted fields from day one also means your test flow matches your live flow. You never write a "temporary" form that posts card numbers to your own server "just for testing". Temporary code has a way of reaching production.

Masking card data in logs

Card data can still leak through a debug statement that prints a whole request, an error tracker that captures form fields, or a session-replay script. Set rules while you are still in test mode.

Never log full card numbers, test or real. If you get used to logging test numbers, one day you will log a real one.
Show the last four only. For receipts and support screens, brand plus last four digits is enough. PCI DSS strictly limits how many digits may be displayed.
Never store the CVC. PCI DSS does not allow storing the security code after authorisation, even encrypted.
Scrub error trackers and analytics. Mask input fields and drop fields named like card, pan or cvc. Check what these tools actually capture during a test payment.
Add an automated check. A log filter can look for card-shaped numbers (13 to 19 digits that pass a Luhn check) and mask them. A test that pushes a test card number through your logging pipeline and asserts it comes out masked is cheap and useful.

What happens if test numbers reach a live site

Sooner or later someone types 4242 4242 4242 4242 into a live checkout: a developer in the wrong environment, a curious visitor, or a fraudster probing for misconfiguration.

They are declined

In live mode, providers reject their own test numbers. Stripe, for example, returns a decline explaining that the request was in live mode but used a known test card. No money moves, and no goods should be released as long as you only fulfil orders after a confirmed payment.

If a test number ever succeeds on what you believe is your live site, investigate immediately. It almost always means your "live" site is running on test keys, and real customers' payments are not being collected either.

Using fabricated numbers for real purchases is fraud

Test numbers exist for developers to test their own integrations. They are not free credit. Anyone who tries to pay for real goods or services with test numbers, or with card numbers they made up or obtained without permission, is attempting fraud. Passing a Luhn check only means the digits are well-formed; it says nothing about whether an account exists and gives no right to use one. Such attempts are logged by merchants and providers and can lead to blocked accounts and legal consequences.

Card-testing attacks and how to protect checkout

To a fraudster, "card testing" means something else. In a card-testing attack, criminals with stolen or guessed card details use a merchant's checkout, usually with scripts, to find out which cards work. They make many small attempts, note which are approved, and use the working cards for larger fraud elsewhere.

These attacks hurt merchants even when every attempt is declined. You may pay fees per authorisation attempt, your authorisation rate drops, successful fraud later turns into disputes, and your provider may restrict your account if attacks continue.

Warning signs

A sudden spike in payment attempts, often at odd hours.
Many small-value payments or zero-amount card verifications.
A high share of declines for incorrect number, incorrect CVC or expired card.
Many different cards from one IP address, device, account or email address.
Direct hits on your payment endpoint without normal page views before them.

How merchants protect checkout

Use your provider's fraud tools, such as Stripe Radar or Adyen's risk management, and review their rules.
Rate-limit attempts per IP, session, account and card fingerprint, with stricter limits on failures.
Add friction where it counts, such as a bot check on the payment step or after a few failures.
Protect card-saving and free-trial flows, which verify cards with small or zero amounts and are favourite targets.
Do not create payment objects on page load, only when the customer actually checks out.
Use 3-D Secure on risky payments, which makes stolen numbers far less useful.
Monitor and alert on attempt volume, authorisation rate and decline rate, so you spot an attack in minutes.

For more, see our guide to card-not-present fraud prevention for small merchants.

Common mistakes

Using another provider's test numbers. A number from an old tutorial may belong to a different provider or an outdated list. If a test card misbehaves, first check it is on your provider's current list.
Only testing the happy path. Many integrations are tested with 4242 and nothing else, and the first real decline shows a blank screen. Test every decline you can trigger, plus 3DS and webhook failures.
Fulfilling orders on the browser's "success" callback. A closed tab or tampered page can leave an unpaid order marked as paid. Confirm payment on the server, ideally through webhooks.
Mixing test and live data. Live keys in staging, or test webhooks on the live account, cause confusion. Keep environments strictly separate and clearly labelled.
Hard-coding test numbers in application code. A "demo" button that pre-fills 4242 is harmless in a sandbox and embarrassing in production. Keep test numbers in test fixtures.
Logging full requests. Verbose logging left on in production is a common way for card data to leak.
Ignoring currency details. Zero-decimal currencies such as the Japanese yen are sent as whole numbers; getting this wrong charges far too much or too little. International customers may also pay extra at their own bank, as our guide to foreign transaction fees and DCC explains.
Not re-testing after upgrades. Re-run your suite, including a manual 3DS check, whenever you upgrade a payment library or API version.

Checklist before you go live

Before you swap test keys for live keys, walk through this list or turn it into automated checks.

Keys and configuration

Live keys live only in your production secrets store.
Production refuses to start with test keys, and staging refuses live keys.
Live webhook endpoints are registered on the live account with their own signing secrets.
Any "test mode" banner or demo pre-fill is removed from production builds.

Payment flows

Success, decline and 3DS (complete, fail, abandon) were tested with the provider's documented test cards.
Every payment method you offer was tested end to end.
Refunds, partial refunds, disputes and subscription renewals were tested.
Orders are only fulfilled after server-side payment confirmation.

Security, fraud and monitoring

Card details are collected only through provider-hosted pages or fields.
Logs, error trackers and analytics contain no card numbers or CVCs after a test payment.
Your PCI DSS self-assessment questionnaire is identified and completed.
Fraud tools, rate limits and bot protection are on for checkout and card-saving pages.
Alerts are set for payment volume, decline rate and webhook failures.

After launch

If policy allows, one small live transaction with an authorised company card is made and refunded.
Test numbers entered on the live site are confirmed to be declined.

FAQ

What is the most common test credit card number?

Stripe's 4242 4242 4242 4242 is probably the best known. It is a Visa test number that succeeds in Stripe test mode with any future expiry and any CVC. Braintree and Square document 4111 1111 1111 1111 for their sandboxes. Each works only in its own provider's test environment.

What expiry date and CVC should I use with test cards?

At Stripe, any valid future date and any three-digit CVC (four for American Express). Adyen documents 03/2030 with CVC 737 for most of its test cards, and Square lists specific CVVs per brand. Check your provider's testing page.

Can I use test card numbers to buy things?

No. Test numbers are not linked to any account and are declined on live checkouts. Trying to pay for real goods with test or made-up card numbers is attempted fraud.

Do test card numbers pass the Luhn check?

Most do, so the rest of the flow can be tested. A few are deliberately invalid, such as Stripe's 4242 4242 4242 4241. Passing the Luhn check only means the digits are well-formed, not that a number is usable. See our explainer on how the Luhn algorithm works.

Why is my test card being declined?

Common causes: live keys instead of test keys, a number from another provider's list, a past expiry date, a provider that expects a specific CVC or expiry, a test amount that triggers a documented decline, or fraud rules blocking it.

How do I test 3-D Secure without a real bank?

Use your provider's 3DS test cards. At Stripe, cards such as 4000 0025 0000 3155 and 4000 0027 6000 3184 trigger authentication, and a test page lets you complete or fail it. Adyen, Checkout.com and Braintree document their own.

Should my server-side tests use card numbers?

Preferably not. Use test payment methods, tokens or nonces such as pm_card_visa, fake-valid-nonce or cnon:card-nonce-ok. That keeps raw card numbers out of your server code and logs.

Do I need PCI DSS compliance just to test?

Test numbers are not real cardholder data, but PCI DSS applies to your live system and is shaped by how you build checkout. Using provider-hosted pages or fields from the start keeps card data off your servers and can greatly reduce your scope.

Are test card numbers the same at every provider?

Some numbers appear at several providers, such as 4242 4242 4242 4242 at Stripe and Checkout.com. But behaviour, especially for decline and 3DS cards, is provider-specific. Always use your own provider's list.

Bottom line

Use only the official test numbers, tokens and bank details from your payment provider's documentation, in its sandbox or test mode, with test API keys. Test the success path, every decline you can trigger, 3-D Secure, wallets, bank payments, webhooks, refunds and disputes, and automate the important paths with test tokens on the server.

Build checkout with provider-hosted pages or fields, mask anything card-shaped in your logs, and protect your live checkout against card-testing bots. Test numbers belong in test mode: on a live site they are declined, and using fabricated numbers to attempt real purchases is fraud. Do all that, and switching to live keys becomes a quiet, uneventful moment.

This article is for general information only. Provider test data and compliance rules change. Check your provider's current documentation and consult your acquirer or a qualified assessor about PCI DSS.

Sources

Official documentation referenced in this guide.

table of contents feature [open]