Test cards and sandbox

How to Test a Payment Gateway Without Real Cards (2026 Guide)

Published: 2026-09-29  ·  11 min read

To test a payment gateway without real cards you use each provider's test environment (sandbox) together with official test cards and valid numbers generated with the Luhn algorithm.

Key points

• Never use real cards in tests: you expose data, risk real charges and may breach PCI DSS.
• Always work in the sandbox with test API keys.
• Cover 4 types of tests: success, declines, 3D Secure and refunds/chargebacks.
• Distinguish official cards (for the gateway flow) from the Luhn generator (for validation, volume and formats).
• Separate format tests from flow tests so they stay deterministic.
• Use a QA checklist and automate the critical scenarios.

This is the standard workflow QA teams follow in 2026: separate format validation tests from payment flow tests, cover every error scenario and never touch a production card. In this guide you will see why, how to do it step by step and which mistakes to avoid.

Why you should not use real cards in tests

The temptation to test with a real card "just once" is an expensive mistake. These are the reasons to avoid it:

• Risk of real charges. A slip-up with production keys can generate actual charges.
• Data exposure. Entering a real number in a development environment leaves it within reach of logs, databases and backups.
• PCI DSS non-compliance. Handling real card data widens the scope of the standard and its audits.
• Non-reproducible results. You cannot force a specific decline with a real card, so you cannot test the error paths.
• Legal and issuer problems. Using your own card in repeated tests can trigger anti-fraud alerts.

The alternative is simple and free: sandbox + test cards. Everything you need to validate an integration is available without using real data.

What the sandbox is and how it works

The sandbox is an isolated environment that replicates the gateway's behavior without connecting to the real financial system. It has its own credentials and its own data.

Key points:

• Test API keys. Stripe uses sk_test_ and pk_test_ keys; PayPal uses the sandbox with its own client_id. These keys route traffic to the test environment.
• Different endpoints. The sandbox points to test servers (for example, api-m.sandbox.paypal.com), not to production ones.
• Independent data. Sandbox customers, cards and transactions do not affect your real account.
• Simulated behavior. You can force approvals, declines and authentications with test cards.

Configuring the sandbox correctly is the first step. If you mix test keys with production endpoints (or the other way around), your tests will not be reliable.

The 4 types of tests you must cover

A solid payments integration does not settle for "the successful payment works". There are four blocks of scenarios worth covering:

1. Successful payment

The base case: the card is approved and the order is completed. Verify that:

• The transaction status is COMPLETED or succeeded.
• The payment is recorded correctly in your system.
• The amount and currency match what was expected.
• The user receives the appropriate confirmation.

2. Declines and errors

This is where most of the testing value lies. You must reproduce every relevant error code:

• Insufficient funds (insufficient_funds).
• Card declined (card_declined).
• Expired card (expired_card).
• Incorrect CVC (incorrect_cvc).
• Incorrect number (incorrect_number).
• Validation errors from the form itself.

For each one, check that your application shows a clear message and does not break the flow.

3. 3D Secure authentication

If your integration uses 3DS, test both the successful authentication path and the failed authentication path. Verify that the redirect works, that timeouts are handled and that a decline after authentication is handled correctly.

4. Refunds and chargebacks

The lifecycle of a payment does not end at the charge. Test:

• Full and partial refunds. Check the status (pending, succeeded, failed) and the associated webhooks.
• Asynchronous refund. Some gateways process the refund with a delay; make sure you handle that state.
• Chargebacks (disputes). Many gateways let you simulate disputes to test your handling flow.

Covering these four blocks gives you confidence that your integration responds well in any scenario, not just the happy one.

Official cards vs Luhn generator: when to use each

Both tools are necessary, but for different things. Confusing them is one of the most frequent mistakes.

The practical rule: use official cards to test the gateway's behavior and the Luhn generator for validation, volume and generic test data. You have the official list of Stripe and PayPal test cards in our dedicated guide and more numbers in the test cards directory.

Step by step: testing your gateway with the generator

This is a practical workflow to prepare your tests:

1. Configure the sandbox. Get your test API keys and point your integration to the sandbox endpoints.
2. Define the scenarios. Make a list of the cases you are going to cover: success, each decline, 3DS and refunds.
3. Generate your test data. Open the credit card generator, choose the network, the output format and the quantity (up to 9999). Download the batch as JSON, CSV or XML.
4. Validate the numbers. Check each number with the card validator to make sure it passes Luhn and that the type and BIN are the expected ones.
5. Load the data into your fixtures. Feed your automated tests with the generated numbers.
6. Run the flow scenarios. For declines and 3DS, use the gateway's official cards (the ones that reproduce each decline code).
7. Verify the results. Check statuses, error messages, webhooks and logs.
8. Document and automate. Turn the critical cases into automated tests that run on every deployment.

If you want to choose a specific network for your test data, you can start with the credit card selection page.

A real QA case

Daniel, a QA engineer at a subscription platform, had a recurring problem: every time Stripe changed an error message, his tests failed. The cause was that his tests depended on official cards for everything, including form validation tests. By separating the tests, the situation improved: format tests used numbers generated with Luhn (stable and with no external dependency) and flow tests kept using the official cards. The result was a faster, far less fragile suite that no longer broke with every provider change.

QA checklist for payment testing

Before signing off an integration, go through this list:

• The integration uses test API keys and sandbox endpoints.
• The successful payment completes the order and updates the status correctly.
• Every relevant decline code is tested and shows a clear message.
• The 3D Secure flow works on both the success and the failure path.
• Refunds (full, partial and asynchronous) are handled well.
• Webhooks are received and processed correctly.
• Logs do not contain sensitive data (full number, CVV).
• The test data is Luhn-valid and versioned as fixtures.
• The critical scenarios are automated.
• There is a clear separation between format tests and flow tests.

Ticking this list drastically reduces production incidents.

Common mistakes when testing payments

These are the failures that come up most often on teams:

• Mixing test and production keys. The most dangerous mistake: it can cause real charges.
• Using real cards "just to see". Unnecessary risk and a potential PCI DSS breach.
• Reusing the same card across several scenarios. Some gateways keep the card's state between tests, so the results stop being reliable.
• Forgetting the CVC. If you do not send it, the CVC check is skipped and you cannot test that failure.
• Not testing the error paths. A successful payment does not validate the integration; declines do.
• Ignoring webhooks. Many statuses are updated asynchronously; if you do not test webhooks, you will not see those changes.
• Not cleaning up test data. Dirty data between runs produces false positives.

Avoiding these mistakes will save you time and, above all, surprises in production.

Are you about to start your tests? Prepare your data with the credit card generator and verify each number with the validator before adding them to your fixtures.

Conclusion

Testing a payment gateway without real cards is safer, more reproducible and more complete than doing it with real data. The formula is clear: sandbox + test keys + official cards + Luhn generator, with a clean separation between format tests and flow tests.

Cover the four blocks (success, declines, 3DS and refunds), follow the checklist and avoid the classic mistakes. With that discipline, your payments integration will withstand the edge cases that always show up in production.

Start by generating your test data in the credit card generator and validate it in the validator. If you want the official list of numbers, check our guide to Stripe and PayPal test cards.

Responsible use notice: the numbers generated on this site are fictitious and valid only under the Luhn algorithm. They do not correspond to real cards, they cannot be used to make purchases and they must be used only for software testing. Using them for fraud is illegal.

Sources and further reading

• Stripe, "Test card numbers" (official documentation): docs.stripe.com/testing
• PayPal Developer, "Card testing" (sandbox): developer.paypal.com
• Stripe and PayPal test cards: official numbers
• What the CVV or CVC on a card is

Frequently Asked Questions

Can I test payments without an official test card?

To test format validation, yes: any Luhn-valid number will do. To test the gateway flow and its declines, you need the official cards.

Does the sandbox behave the same as production?

Not entirely. The sandbox simulates the behavior, but it does not replicate every anti-fraud rule from the issuer. Use it to validate your integration, not to predict 100% of real behavior.

How many test cards do I need?

One per scenario. Since the card state may persist between tests, it is best to use different numbers for independent cases.

Is it legal to generate card numbers for testing?

Generating fictitious Luhn-valid numbers to test software is legal. Using them for fraud or impersonation is not, and they would not work anyway, because they do not correspond to real cards.

testingsandboxwebhooksQA