Test Card Numbers — Sandbox Cards by Gateway

There are two kinds of test card number, and using the wrong one wastes hours. Generated test numbers, like the ones from our credit card generator, are synthetic — they pass client-side validation and brand detection, which is what you need while you are building a form. Gateway sandbox numbers are registered inside a specific processor’s test environment: they return real authorisation responses, trigger named decline codes, and drive 3-D Secure flows. This page collects the sandbox numbers. Use them when the thing you are testing is the processor, not your form.

Card numbers on this page were last checked against provider documentation on 3 August 2026. Providers do change what they publish — the official link beside each claim is authoritative.

Which one do I need?

The line is clean: anything that happens before the request leaves your server can be tested with generated numbers, and anything that depends on the answer coming back needs the processor’s own.

Stripe

Stripe’s set is the most complete of any provider, and the one most people mean when they say “test card”. Any future expiry and any CVV of the right length work; the number alone decides the outcome.

Every decline path has its own number, which is what makes this set worth copying into a fixture file rather than hand-typing:

That last one is the only number on this page that deliberately fails the Luhn checksum — it exists to test the branch where your own validation should have caught the input first.

For authentication, 4000 0027 6000 3184 always requires a 3-D Secure challenge, 4000 0025 0000 3155 requires one unless the card is already set up for off-session use, and 4000 0082 6000 3178 authenticates successfully and then declines with insufficient_funds — the case that breaks naive code assuming authentication implies approval.

Source: Stripe — Testing · Verified: 2026-08-03

PayPal

PayPal’s sandbox splits the work differently: the card number selects the brand, and the cardholder name selects the outcome. That is unusual enough to catch people out.

To force a failure, send one of these case-sensitive values in the cardholder name field: CCREJECT-REFUSED (card refused), CCREJECT-IF (insufficient funds), CCREJECT-EC (expired card), CCREJECT-LS (lost or stolen), CCREJECT-SF (suspected fraud), or CCREJECT-CVV_F (CVV failure). Sandbox credentials come from a business account created in the PayPal Developer Dashboard, not from your live account.

Source: PayPal — Card testing · Verified: 2026-08-03

Braintree

Braintree is PayPal-owned but has its own sandbox and its own conventions. Cards select the brand; the transaction amount selects the processor response.

Amounts do the rest: anything from $0.01 to $1,999.99 is authorised and settled, $2,000.00–$2,999.99 is processor-declined, $3,000.00–$3,000.99 fails outright, and $5,001.00 is gateway-rejected for an incomplete application. This is the cleanest way in any sandbox to test a decline without changing the card on file.

Source: Braintree — Testing · Verified: 2026-08-03

Adyen

Adyen pins both the expiry and the security code, and its examples expect them. Use 03/2030 and CVC 737 — or 7373 for American Express — unless a specific test says otherwise.

Adyen’s refusal model is worth understanding before you test against it. Rather than a flat “declined”, the API returns a refusalReason plus a refusalReasonCode, and its documentation maps which of those you are allowed to surface to a shopper and which you must not. Test the mapping, not just the boolean.

Source: Adyen — Test card numbers · Verified: 2026-08-03

Square

Square keys its error states on fields other than the card number, which makes it the easiest sandbox to misread. 4111 1111 1111 1111 with CVV 111 succeeds; the same card with CVV 911 fails CVV verification.

The triggers: CVV 911 produces a CVV failure, postal code 99999 a postal-code failure, expiry 01/40 an expiration failure, card 4000 0000 0000 0002 a decline, and 4000 0000 0000 0010 a card-on-file authorisation decline.

Source: Square — Sandbox payments · Verified: 2026-08-03

Authorize.Net

Authorize.Net has the oldest test data set here, and one configuration detail that trips up nearly everyone: your sandbox account should be left in Live Mode. Transactions submitted in the separate “test mode” are not stored and return a transaction ID of zero, so anything you build on top of the response falls apart.

Outcomes come from the billing ZIP and the card code. ZIP 46282 forces a decline, 46203 an invalid-AVS-data response, 46205 an address mismatch and 46201 an address-only match; card codes 900, 901 and 904 produce CVV match, no-match and not-processed respectively.

Source: Authorize.Net — Testing guide · Verified: 2026-08-03

Other gateways in brief

iyzico publishes the most useful Turkish set, organised by issuing bank and including Troy cards — 9792 0300 0000 0000 for Troy credit and 9792 0200 0000 0001 for Troy debit — plus a long list of error generators such as 4111 1111 1111 1129 for insufficient funds and 4151 1111 1111 1112 for a failed 3-D Secure initialisation. See iyzico — Test cards.

Mollie does not really use card numbers as the control surface. Test mode replaces the checkout screen with a panel where you pick the final state directly, and its published cards — Visa 4543 4740 0224 9996, Mastercard 2223 0000 1047 9399, Amex 3782 822463 10005 — all resolve as Mastercard internally. See Mollie — Testing.

Razorpay splits its tables into domestic Indian cards, international cards, subscription cards and EMI cards, and requires a full billing address alongside the number for international tests. See Razorpay — Test card details.

Checkout.com publishes per-brand cards where the amount you send maps to the response code you want, and routes challenged 3-D Secure tests to a simulator page. See Checkout.com — Test cards.

Worldpay issues test cards against your specific test merchant profile rather than publishing a single universal list, so pull them from your own account documentation.

Universal test card numbers

These predate most of the gateways above and are recognised almost everywhere, which is exactly why they are the wrong tool for testing a specific processor’s behaviour. They are the right tool for seeding a database or exercising a form.

Every number in this table is Luhn-valid and deliberately unassigned to any account. If you find one in a data set, that data set is test data. You can confirm any of them with the card validator, and generate fresh equivalents per network from the Visa and Mastercard pages.

Building a decline matrix in your test suite

The value of the tables above is that each decline path has a stable number, so the scenarios become data rather than prose. A Stripe example:

DECLINE_CARDS = {
    "generic_decline":        "4000000000000002",
    "insufficient_funds":     "4000000000009995",
    "lost_card":              "4000000000009987",
    "stolen_card":            "4000000000009979",
    "expired_card":           "4000000000000069",
    "incorrect_cvc":          "4000000000000127",
    "processing_error":       "4000000000000119",
    "card_velocity_exceeded": "4000000000006975",
}

@pytest.mark.parametrize("expected_code,number", DECLINE_CARDS.items())
def test_decline_is_surfaced_to_the_customer(expected_code, number, checkout):
    result = checkout.pay(card=number, exp_month=12, exp_year=2030, cvc="123")

    assert result.status == "failed"
    assert result.decline_code == expected_code
    assert result.customer_message != ""      # never show a raw decline code
    assert "4000" not in result.customer_message

Eight cases, one table, and the moment a provider adds a decline reason you add a row rather than a test. Keep the numbers in one module so the six-month re-check has a single place to land.

3-D Secure and SCA testing

3-D Secure 2 is the authentication layer that lets an issuer confirm a cardholder is present before approving a transaction. Under PSD2 in the European Economic Area and the UK, strong customer authentication is mandatory for most e-commerce payments, which turned 3-D Secure from an optional anti-fraud tool into a path your checkout must handle.

Two flows matter. In the frictionless flow the issuer approves on the risk data alone and the customer sees nothing. In the challenge flow they are asked for a one-time code or a banking-app confirmation, your page hands control to the issuer, and control comes back asynchronously. Code that only ever ran the frictionless path will break the first time a challenge appears in production.

Every gateway triggers challenges with a different card — Stripe’s 4000 0027 6000 3184 always challenges, Adyen and Checkout.com route to their own simulator pages, and iyzico carries dedicated cards for each mdStatus value. Test the exemption cases too: low-value transactions, transaction risk analysis and merchant whitelisting can all skip the challenge, so a flow that assumes authentication always happens is as wrong as one that assumes it never does. Our 3-D Secure testing guide walks through the full matrix.

Setting up a sandbox account

The pattern is the same nearly everywhere: register a developer account, and you get a pair of API keys — one test, one live — that select the environment. Stripe and Square ship both in a single dashboard with a toggle. PayPal and Braintree issue a separate sandbox business account with its own credentials. Adyen provisions a test company account on request. Authorize.Net has a dedicated sandbox portal at sandbox.authorize.net, distinct from the production login.

Never commit test API keys to a public repository. Even test keys reveal your account structure, and several providers rate-limit or disable keys they find in public code.

Generated numbers vs sandbox numbers

Common testing mistakes

1. Using a test card with live keys. It fails at the network, and repeated attempts feed the card-testing fraud signals processors watch on your merchant account.
2. Letting test numbers reach a production database. Seed data has a way of migrating. Tag it at creation so it can be found and removed later.
3. Assuming sandbox behaviour equals production behaviour. The usual gap is 3-D Secure: sandboxes frequently skip a challenge that production will demand.
4. Backdating the expiry to test an expired card. Most sandboxes reject a past date at validation, so you test your own form instead of the processor. Use the documented expired-card number instead.
5. Sending a three-digit CVV with an American Express number. Amex uses a four-digit code, and a length check keyed to the brand is exactly the kind of bug a test suite should catch.
6. Never testing 2-series Mastercard. The 2221–2720 range has been live since 2017 and validation written against ^5[1-5] still rejects it. 2223 0031 2200 3222 takes one line to add.

Related pages and tools

The tool directory lists every generator on the site, the FAQ covers what a Luhn-valid number does and does not prove, and our editorial policy explains the six-month re-check cycle this page sits in.