Test Credit Card Numbers for Every Payment Gateway (2026)

If you've ever built a checkout flow, you know the drill. You need credit card numbers that look real, pass basic validation, and trigger specific responses from your payment gateway — without touching an actual bank account.

The problem? Every payment gateway has its own set of test card numbers, scattered across docs that are either buried three links deep or formatted like they were written by someone who hates developers. Stripe's docs live in one place. PayPal's sandbox cards live in another. Braintree has its own list. Adyen has yet another.

This guide puts every test credit card number you need in one place. We've compiled the official test cards for the major payment gateways, organized by response type and card network, so you can stop tab-switching and start testing.

Why You Need Test Credit Card Numbers

Before we get to the lists, let's be clear about why test cards matter:

• Real cards in test environments are a compliance violation. PCI DSS explicitly prohibits using live cardholder data in development and QA environments. Using test numbers keeps you compliant.
• Gateway sandbox modes require specific numbers. Payment gateways run parallel sandbox environments that only accept designated test card numbers. Random numbers won't work.
• You need to simulate failures, not just successes. A robust payment flow handles declined cards, expired cards, insufficient funds, and 3D Secure challenges. Test cards let you trigger each scenario on demand.
• Automated testing demands predictable inputs. If you're running Selenium, Cypress, or Playwright tests against your checkout, you need card numbers that produce deterministic results every time.

In short: test credit card numbers are infrastructure. Treat them accordingly.

Test Credit Card Numbers by Payment Gateway

Stripe Test Cards

Stripe's test mode accepts the following cards when you're using your test API keys (keys starting with sk_test_). No real charges are made.

Successful Payments

Declined & Error Cards

CVV/Expiry rules for Stripe: Use any 3-digit CVC (4 digits for Amex), any future expiration date, and any 5-digit ZIP code.

Pro tip: Stripe's test mode is deterministic. The card number controls the response, not the amount. This makes automated testing clean and predictable.

PayPal Test Cards (Sandbox)

PayPal's sandbox environment accepts test cards through the PayPal Developer Dashboard. You'll need to create sandbox buyer and seller accounts first.

Sandbox Credit Card Numbers

Simulating Declines in PayPal

PayPal handles decline simulation differently from Stripe. Instead of specific card numbers, you control the response through the negative testing feature in your sandbox:

1. Go to your PayPal sandbox account settings
2. Enable "Negative Testing"
3. Pass specific error codes in the API's HEADEROBJ to trigger failures

Common negative testing codes:

• 10417 — Transaction cannot be processed
• 10474 — Credit card validation failure
• 10486 — Retry with a different funding source
• 10502 — Invalid credit card number
• 10527 — Card declined by issuer
• 10546 — Gateway decline
• 10761 — Card has expired

CVV/Expiry rules for PayPal: Use any future expiry date. Any 3-digit CVC (4 for Amex).

Braintree Test Cards

Braintree (owned by PayPal, but operates as a separate gateway) has its own sandbox. Enable sandbox mode through the Braintree Control Panel.

Successful Payments

Decline-Triggering Cards

CVV rules for Braintree: Use 200 for a CVV-not-verified response, 201 for an issuer-not-participating response, or any other 3-digit code for a successful CVV match.

Square Test Cards

Square uses its own sandbox. You'll need a Square Developer account and sandbox access tokens.

Test Card Numbers

Simulating Errors in Square

Square uses specific card nonces rather than card numbers to trigger error scenarios in the sandbox:

Adyen Test Cards

Adyen's test environment requires a test merchant account. All test cards use the Adyen test environment endpoint.

Successful Payments

Decline & 3DS Cards

Adyen's twist: Some decline scenarios are controlled by the amount, not the card number. For example, amounts ending in .13 trigger a refusal, and amounts ending in .51 trigger a referral.

Checkout.com Test Cards

MercadoPago Test Cards (Latin America)

If you're processing payments in Latin America, MercadoPago is likely in your stack. Their sandbox uses test users and specific card numbers per country.

Argentina (ARS)

Brazil (BRL)

Test Cards by Card Network

Sometimes you don't care which gateway — you just need a valid test number for a specific network. Here's a universal reference:

All these numbers pass Luhn validation — they're mathematically valid but not connected to any real account.

Test Cards by Response Type

Building a robust checkout means testing more than the happy path. Here's a cheat sheet for simulating different outcomes:

Success Scenarios

Decline Scenarios

3D Secure / Authentication

How Namso Gen Complements Gateway Test Cards

Gateway-provided test cards are essential — they're the only numbers that trigger specific sandbox responses. But they have limitations:

• They're hardcoded. You get the same 10–20 numbers. If you need 500 unique card numbers for bulk testing or load testing, gateway cards won't cut it.
• They don't cover all BIN ranges. Need to test how your system handles a card from a specific bank or country? Gateway test cards don't offer that granularity.
• They're sandbox-only. They won't help with client-side validation testing, form UX testing, or populating staging databases.

This is where Namso Gen fits in. It generates Luhn-valid card numbers with:

• Custom BIN prefixes — test specific banks, countries, or card types by entering any BIN
• Bulk generation — generate hundreds or thousands of unique numbers for load testing
• Full card data — card number + expiry date + CVV, formatted and ready to use
• Network-specific generation — Visa, Mastercard, Amex, Discover, and more

The workflow: Use gateway test cards to test specific response scenarios (declines, 3DS, errors). Use Namso Gen to generate bulk test data, test form validation, populate staging environments, and test BIN-specific logic.

They're complementary tools. Use both.

Best Practices for Payment Testing

1. Never Use Real Cards in Test Environments

This isn't just good practice — it's a PCI DSS requirement. Real cardholder data in dev or QA environments is a compliance violation that can cost your organization its ability to process payments. Use test cards. Always.

2. Test the Unhappy Paths

Most payment bugs live in the failure handling, not the success flow. For every test you write for a successful payment, write three for failures:

• Card declined
• Insufficient funds
• Invalid card number
• Expired card
• CVC mismatch
• 3D Secure challenge (both pass and fail)
• Network timeout
• Duplicate transaction

3. Test Across Multiple Card Networks

Don't just test with Visa. Your international customers use Mastercard, Amex, Discover, JCB, UnionPay, and Maestro. Each network has different number formats, CVC lengths, and validation rules. A form that works with Visa might break with Amex's 15-digit number or 4-digit CVC.

4. Validate Client-Side Before Server-Side

Use Luhn validation on the client to catch obviously invalid numbers before they hit your payment API. This reduces API calls, improves UX (instant feedback), and protects your rate limits. Learn how the Luhn algorithm works →

5. Automate Your Payment Tests

Manual testing is fine for exploration. For regression, automate. Tools like Cypress, Playwright, and Selenium can fill checkout forms with test card numbers and assert on the expected outcomes. Generate bulk test data with Namso Gen to feed your test suites.

6. Keep Your Test Card List Updated

Gateway providers occasionally update their test card lists. Bookmark the official docs:

• Stripe Testing Docs
• PayPal Sandbox Guide
• Braintree Test Values
• Square Sandbox
• Adyen Test Cards

Common Mistakes in Payment Testing

Using test cards in production mode. Test card numbers only work in sandbox/test mode. If your API keys are live, test cards will be declined as invalid. Always verify you're in test mode before running tests.

Ignoring 3D Secure flows. 3DS is mandatory in the EU (PSD2) and increasingly required worldwide. If you're not testing the 3DS challenge and frictionless flows, your European customers are going to have a bad time.

Hardcoding test card numbers in your test suite. Store them in config files or environment variables. When a gateway updates its test cards, you want to change one file, not fifty.

Not testing card input formatting. Users type card numbers with spaces, dashes, or no separators. Your form should handle all three. Test with 4242424242424242, 4242 4242 4242 4242, and 4242-4242-4242-4242.

Skipping currency-specific tests. Some test cards behave differently depending on the transaction currency. If you process multi-currency payments, test each currency with each card type.

FAQ

What are test credit card numbers?

Test credit card numbers are specially designated card numbers that payment gateways accept in their sandbox (test) environments. They pass Luhn validation and look like real card numbers, but they aren't connected to any actual bank account. Each gateway provides its own set of test numbers that trigger specific responses — successful charges, declines, authentication challenges, and more.

Can I use test credit card numbers to make real purchases?

No. Test credit card numbers only work in sandbox or test mode environments. They will be rejected if used in production (live) payment processing. They are not connected to any bank account and carry no monetary value.

What CVV and expiration date should I use with test cards?

For most gateways, any 3-digit CVV (or 4-digit for American Express) and any future expiration date will work. Some gateways use specific CVV values to trigger certain responses — for example, Braintree uses CVV 200 to simulate a CVV-not-verified response. Check each gateway's documentation for specifics.

Do test credit card numbers pass Luhn validation?

Yes. All official gateway test card numbers are Luhn-valid. The Luhn algorithm (also called Mod 10) is a checksum formula used to validate card number formats. Test cards are designed to pass this check so they behave like real card numbers during processing.

What's the difference between test cards and generated cards?

Gateway test cards are specific numbers provided by payment processors (Stripe, PayPal, etc.) that trigger predetermined responses in their sandbox environments. Generated cards — like those from Namso Gen — are Luhn-valid numbers that can be used for form validation testing, bulk test data, and client-side testing, but won't trigger specific gateway sandbox behaviors. For thorough testing, use both.

How do I test 3D Secure (3DS) authentication?

Each gateway provides specific test card numbers that trigger 3DS flows. For example, Stripe uses 4000 0000 0000 3220 for 3DS2 authentication and 4000 0027 6000 3184 for always-prompted 3DS. Adyen uses 4212 3456 7891 0014 for 3DS2 challenges. Check the gateway-specific sections above for full 3DS test card lists.

Are test credit card numbers the same across all gateways?

Not always. While some numbers (like 4242 4242 4242 4242 or 4111 1111 1111 1111) are widely recognized, each gateway has its own official test card list with specific numbers for triggering different response codes. Always use the test cards specified by your particular payment gateway.