Test cards and sandbox
Stripe and PayPal test cards: official numbers for testing
Published: · 12 min read
Stripe and PayPal test cards are fictitious numbers, published by each gateway, that simulate payments in their testing environment (sandbox): they do not move real money and only work with test API keys.
Key points
- Test cards only work in test mode; in production they are declined.
- In Stripe, the universal success number is 4242 4242 4242 4242 (Visa), with any CVC and a future date.
- Stripe includes specific cards for each decline code (insufficient funds, stolen card, incorrect CVC…).
- PayPal uses the sandbox: static test numbers or cards generated from its own tool.
- Never use real cards in testing; you expose data and may breach PCI DSS.
- When you need many numbers or a specific format, a Luhn generator covers what the official lists cannot.
The golden rule is simple: always use the numbers that each gateway documents officially. Each provider publishes its own list and those numbers only work in its sandbox. In this guide we have gathered the most used ones from Stripe and PayPal, with their behaviours and official sources, so you can copy and paste with confidence.
What test cards are and why use them
A test card is a number that the gateway recognises in its testing environment and to which it associates a specific behaviour: approving the payment, declining it with a specific code, requiring 3D Secure, etc. They are designed so that you can test every flow of your integration without depending on real cards.
Their advantages are clear:
- Zero risk. There is no real money or customer data at stake.
- Case coverage. You can reproduce declines, errors and authentications that you could not control with a real card.
- Repeatability. The same number always produces the same result, so tests are deterministic.
- Compliance. You avoid handling real card data in your development environment.
That said: each gateway has its own list, and a Stripe number does not work in PayPal or vice versa. In addition, these numbers only operate with test API keys. If you try to use them in production, they will be declined.
Stripe test cards: success numbers
Stripe documents a list of cards that always approve the payment. These are the most used (with any 3-digit CVC and any future date; 4-digit CVC for American Express):
| Network | Card number | Type |
|---|---|---|
| Visa | 4242 4242 4242 4242 | Credit |
| Visa (debit) | 4000 0566 5566 5556 | Debit |
| Mastercard | 5555 5555 5555 4444 | Credit |
| Mastercard (series 2) | 2223 0031 2200 3222 | Credit |
| Mastercard (debit) | 5200 8282 8282 8210 | Debit |
| Mastercard (prepaid) | 5105 1051 0510 5100 | Prepaid |
| American Express | 3782 8224 6310 005 | Credit (4-digit CVC) |
| American Express | 3714 4963 5398 431 | Credit (4-digit CVC) |
| Discover | 6011 1111 1111 1117 | Credit |
| Discover | 6011 0009 9013 9424 | Credit |
| Diners Club | 3056 9300 0902 0004 | Credit |
| JCB | 3566 0020 2036 0505 | Credit |
| UnionPay | 6200 0000 0000 0005 | Credit |
Rules for using them in Stripe:
- Enter any future expiry date (for example, 12/34).
- Use any 3-digit CVC (4 for American Express).
- Make sure you are using a test API key (sk_test_...), not a production one.
- Any other field in the form can hold any value.
The 4242 4242 4242 4242 is the most famous: it approves the payment in practically every scenario. If you need a card from that specific network, you can generate and validate it with our Visa card generator and the validator.
Stripe test cards: declines and decline codes
One of Stripe's biggest advantages is that it documents cards that force a specific decline, which lets you test how your application responds to each error:
| Scenario | Card number | Error code | Decline code |
|---|---|---|---|
| Generic decline | 4000 0000 0000 0002 | card_declined | generic_decline |
| Insufficient funds | 4000 0000 0000 9995 | card_declined | insufficient_funds |
| Lost card | 4000 0000 0000 9987 | card_declined | lost_card |
| Stolen card | 4000 0000 0000 9979 | card_declined | stolen_card |
| Expired card | 4000 0000 0000 0069 | expired_card | — |
| Incorrect CVC | 4000 0000 0000 0127 | incorrect_cvc | — |
| Processing error | 4000 0000 0000 0119 | processing_error | — |
| Incorrect number | 4242 4242 4242 4241 | incorrect_number | — |
| Rate limit | 4000 0000 0000 6975 | card_declined | card_velocity_exceeded |
Important details about declines:
- You must send the CVC for the CVC check to be able to fail. If you omit the field, Stripe skips the verification and the card does not fail for that reason.
- Cards that simulate issuer declines cannot be attached to a Customer object.
- To test a decline with an already attached card, Stripe offers the card 4000 0000 0000 0341 ("declines after attaching"): the attachment works, but the charge fails.
- The number 4242 4242 4242 4241 fails with "incorrect number" precisely because it does not pass the Luhn algorithm. It is a good reminder of what Luhn is for and what it is not.
3D Secure test cards in Stripe
If your integration uses 3D Secure (3DS) authentication, Stripe documents specific cards:
| Scenario | Card number | Behaviour |
|---|---|---|
| Authentication required (3DS2) | 4000 0000 0000 3220 | Requires completing 3DS to approve |
| Authentication required (3DS2, US) | 4000 0000 8400 0027 | Requires 3DS to approve |
| 3DS required and declined | 4000 0000 8400 1629 | After authenticating, the payment is declined |
| 3DS required, lookup failure | 4000 0000 8400 1280 | The 3DS lookup fails with a processing error |
| 3DS supported, not required | 4000 0000 0000 3055 | 3DS can run, but it is not mandatory |
| 3DS frictionless | 4000 0000 3220 0000 | 3DS required on all transactions, approves without friction |
| 3DS not supported | 3782 8224 6310 005 | Does not support 3DS; the attempt proceeds without authentication |
A practical warning: 3D Secure redirects do not trigger for payments created directly from the Stripe dashboard. You need to test them from your frontend or through an API call.
PayPal test cards: sandbox and Payflow
PayPal handles testing differently: instead of a single fixed list, it offers a sandbox with static numbers and a tool to generate cards.
PayPal sandbox static numbers
PayPal documents test numbers for its checkout integration. Here are some (use a future date and a 3-digit CVC, or 4 for American Express):
| Network | Test number |
|---|---|
| Visa | 4012 8888 8888 1881 |
| Visa | 4005 5192 0000 0004 |
| Visa | 4012 0000 3333 0026 |
| Mastercard | 2223 0000 4840 0011 |
| Maestro | 6304 0000 0000 0000 |
| Maestro | 5063 5169 4500 5047 |
| American Express | 3714 4963 5398 431 |
| American Express | 3766 8081 6376 961 |
| Diners Club | 3646 1510 0000 39 |
| JCB | 3636 5000 0000 0260 |
| UnionPay (CUP) | 6200 6800 0000 0004 |
The PayPal card generator
In addition to the fixed numbers, PayPal includes a test card generator in its documentation inside the sandbox. You can choose the network (Visa, Mastercard, American Express, Discover, Maestro, JCB, ELO), the country and generate a card with number, date and CVC. It is ideal when you need several cards of the same type or want to simulate different countries.
Simulating declines in PayPal
In the checkout integration, PayPal does not use different numbers for each decline: instead, you enter a rejection trigger in the cardholder name field. Some examples:
| Scenario | Trigger | Response code |
|---|---|---|
| Card refused | CCREJECT-REFUSED | 0500 (DO_NOT_HONOR) |
| Fraudulent card | CCREJECT-SF | 9500 (SUSPECTED_FRAUD) |
| Expired card | CCREJECT-EC | 5400 (EXPIRED_CARD) |
| Luhn checksum failure | CCREJECT-IRC | 5180 (INVALID_OR_RESTRICTED_CARD) |
| Insufficient funds | CCREJECT-IF | 5120 (INSUFFICIENT_FUNDS) |
| Lost or stolen card | CCREJECT-LS | 9520 (LOST_OR_STOLEN) |
| CVC failure | CCREJECT-CVV_F | 00N7 (CVV2_FAILURE) |
Note the CCREJECT-IRC case: PayPal includes a trigger that simulates a Luhn checksum failure. It is proof that gateways use Luhn as a format filter and that this scenario is worth testing.
Payflow: classic test cards
If you use Payflow, PayPal documents a set of specific test numbers. Payflow's general rule is clear: during testing only the test numbers work; any other number produces an error. The expiry date must be a valid future date in mmyy format.
Comparison table: Stripe vs PayPal
| Feature | Stripe | PayPal |
|---|---|---|
| Testing environment | Test mode with sk_test_ keys | Sandbox |
| Typical success number | 4242 4242 4242 4242 | 4012 8888 8888 1881 |
| Fixed list of numbers | Yes, very extensive | Yes, more limited |
| Own card generator | No (fixed list) | Yes (sandbox) |
| Decline simulation | Cards per decline code | Triggers in the cardholder name |
| 3D Secure | Dedicated 3DS cards | Documented 3DS scenarios |
| Official source | docs.stripe.com/testing | developer.paypal.com |
Both gateways cover the essentials, but they differ in method: Stripe uses one number per scenario, while PayPal combines fixed numbers with triggers to provoke errors.
Limitations of test cards
Test cards are powerful, but they have limits worth knowing:
- They only work in the sandbox. In production they are declined.
- They depend on the gateway. The Stripe number does not work in PayPal or vice versa.
- They do not reproduce all real behaviour. A real payment goes through the issuer, with anti-fraud rules that the sandbox does not replicate.
- The lists change. Providers update numbers and behaviours; it is worth checking the official documentation.
- They require test keys. A slip with production keys can cause real attempts.
That is why, in addition to the official lists, many format and validation tests are done with locally generated numbers.
When to use a Luhn generator instead of the official lists
The official cards are perfect for testing the payment flow of a specific gateway. But there are scenarios where they are not enough:
- You need many numbers to populate a test database or run load tests.
- You want a specific format (a particular length or network) that the official list does not cover.
- You are testing client-side validation, not the gateway server: you only need numbers valid under Luhn.
- You export to several formats (JSON, CSV, XML) to feed your fixtures.
In those cases, a Luhn-valid card generator is the right tool. It creates well-formed numbers, with a real BIN and a correct check digit, without risking real data. You can also check the directory of test cards to see more official numbers.
A real testing case
A team integrating Stripe wanted to test their retry logic on insufficient funds. Their first attempt was to always use the same decline card, but Stripe keeps the card state between tests, so the results stopped being reliable. The solution was to use a different card for each independent scenario and to separate format tests (with Luhn-generated numbers) from payment flow tests (with Stripe's official cards). With that separation, the retry tests became deterministic and stopped giving false positives.
Ready to prepare your test data? Generate batches of Luhn-valid numbers in JSON, CSV or XML with the credit card generator and check them with the validator.
Conclusion
Stripe and PayPal test cards are the correct way to test payments without using real data. Stripe offers a very extensive list, with one number for each scenario and decline code; PayPal combines sandbox static numbers with triggers to provoke errors.
Remember the three basic rules: use only official numbers, always work in test mode and never use real cards. And when you need volume, specific formats or local validation tests, complement the official lists with a Luhn generator.
If you want to go deeper into the whole process, do not miss our guide on how to test a payment gateway without real cards.
Responsible use notice: the numbers in this article are official test cards from each gateway, valid only in their sandbox environment. The numbers generated on this site are fictitious and must be used solely for software testing. Never use them for fraud.
Official sources
- Stripe, "Test card numbers" (official documentation): docs.stripe.com/testing
- PayPal Developer, "Card testing" (sandbox): developer.paypal.com/sandbox-testing/card-testing
- PayPal Developer, "Test Payflow transactions": developer.paypal.com
- What a card BIN is
- What a card CVV or CVC is
Frequently Asked Questions
Can I use Stripe test cards in PayPal?
No. Each gateway has its own list and its numbers only work in its sandbox.
Do test cards move real money?
No. They run in the testing environment and do not generate real charges.
Why is my Stripe test card not working?
Check that you are using a test API key (sk_test_), that the expiry date is in the future and that you send the CVC when the scenario requires it.
What is the difference between a generic decline and a decline code?
The generic decline indicates that the operation failed; the decline code (insufficient_funds, stolen_card, etc.) explains the specific reason.
StripePayPalsandbox3D Secure
Ready to generate your test numbers?
Use the free generator and get Luhn-valid cards with CVV and expiry in seconds.