Braintree, Stripe, PayPal & Square Test Card Numbers (2026 List)
Up-to-date test and dummy credit card numbers for Braintree, Stripe, PayPal, and Square. Organized by brand and success/failure pattern, with one-click copy for fast payment integration testing.
| Service | [[ labels.col_number ]] | [[ labels.col_brand ]] | [[ labels.col_behavior ]] | |
|---|---|---|---|---|
| [[ card.service ]] | [[ formatNumber(card.number) ]] | [[ card.brand ]] [[ labels['subtype_' + card.subtype] ]] | [[ behaviorLabel(card.behavior) ]] |
What Are Test Credit Card Numbers?
When you build a payment feature, you need to reproduce outcomes like "success," "insufficient funds," or "stolen card" without touching a real card. To make that possible, every major payment processor publishes a set of fixed card numbers that are wired to specific outcomes on their servers. This page collects the current test numbers for Stripe, PayPal, Square, and Braintree, organized by brand and by result, so you can filter to what you need and copy it with one click.
These numbers only mean anything inside a sandbox. As long as you pair them with a test API key, no real charge is ever created — but pairing them with a live key simply gets the transaction declined, since production systems never recognize these numbers as real cards. Always switch keys and numbers together, and note that processors do occasionally update their test numbers, so check the provider's own documentation if something behaves differently than expected here.
How to Use This List
- Pick the payment service tab Choose the processor you are integrating (Stripe, PayPal, Square, or Braintree) to narrow the table to just its numbers.
- Filter by the outcome you need Use the Success, Failure, or 3D Secure filter to isolate the scenario you are testing, such as an error-handling path.
- Copy the card number Click Copy next to any row to put that number on your clipboard, ready to paste straight into a checkout form.
- Fill in CVC and expiry Any digits work for CVC (4 digits for Amex) and any future date works for expiry — there is no need for exact values.
Tips for getting more out of it
- In Stripe test mode, any 3-digit CVC (4 digits for Amex), any future expiry date, and any 5-digit zip code will pass. No real charge occurs unless you use a live key.
- All test card numbers are designed to pass the Luhn check (card number validation algorithm). This lets you reproduce gateway test scenarios without being rejected by front-end validation.
- For 3D Secure (3DS) testing, use dedicated cards.
4000002500003155triggers the authentication dialog, and4000000000003220is used for the 3DS 2 flow. - Using test card numbers in production will result in a declined transaction. Always pair test keys with test card numbers. For Stripe, test keys start with
sk_test_.
Common Use Cases
Verifying a new checkout integration
Right after wiring up a payment form, running one successful test number confirms your keys and request structure are correct before you dig further.
Building out error handling
Numbers mapped to insufficient funds, expired cards, or CVC errors let you check that each failure shows the right message to the customer.
Testing 3D Secure flows
The dedicated 3DS numbers let you follow the authentication dialog through to the redirect back into your app, a step that is easy to miss during implementation.
Documenting QA test plans
Pasting the number-to-outcome mapping directly into a test script saves testers from hunting for numbers every single run.
Generating fixtures for automated test suites
The same fixed numbers can be dropped into CI test fixtures so payment flows are exercised consistently on every build.
Payment Testing Glossary
- Test key
- An API key scoped to a sandbox environment. Stripe test keys start with
sk_test_; using one guarantees no real money moves. - Sandbox
- An environment fully separated from production where you can freely reproduce successes and failures without touching real funds.
- Luhn check
- A checksum formula that verifies whether a card number's digits form a valid sequence. It catches typos but cannot confirm a card actually exists.
- BIN / IIN
- The first six to eight digits of a card number, which identify the issuing bank and card network before the rest of the number is even checked.
- CVC / CVV
- The 3-digit (4-digit on Amex) security code printed on the card. Sandbox environments accept any digits in its place.
- 3D Secure
- An extra identity-verification step shown during checkout. Dedicated test numbers trigger this dialog so you can test the full flow.
- Authorization
- A hold placed on a card to confirm funds are available. The actual charge is only finalized in a later capture step.
FAQ
sk_test_), no real charge will occur. If you accidentally use a live key, the transaction will be attempted even with test card numbers, so be careful not to mix them up.
Side Note — The Luhn Algorithm — The Guardian of Card Numbers Since 1954
The "check digit" at the end of a credit card number is validated by an algorithm invented in 1954 by IBM engineer Hans Peter Luhn. Every second digit from the right is doubled, all digits are summed, and the result must be divisible by 10. This simple check is still used by major brands including Visa, Mastercard, and Amex, and catches the vast majority of accidental typos.
However, the Luhn check is purely designed to detect digit errors — it does not verify whether a card actually exists. Using the Luhn check in client-side form validation is purely a UX improvement (instant error feedback) and does nothing to prevent fraud. Real authorization must always be performed server-side through a payment gateway.
Test card numbers are fixed numbers that each payment service has deliberately designed to pass the Luhn check. For example, Stripe's 4242424242424242 is easy to remember and passes Luhn validation. The number itself has no inherent meaning — it is simply mapped to a behavior (e.g., "success" or "failure") within Stripe's system.