No. Use your payment provider's test mode and its published test card numbers. Real cards in staging put cardholder data in a system that is usually less protected, and at least one major provider states in its documentation that its agreement prohibits testing in live mode with real payment method details.
What the documentation says
Stripe's testing guide describes testing your integration in a sandbox by simulating transactions with test values, and says these transactions do not move funds. It lists test card numbers by brand, such as a Visa number ending 4242, that accept any three digit CVC and any future expiry date. Under a heading telling readers not to use real card details, it says the Stripe Services Agreement prohibits testing in live mode using real payment method details.
Other providers publish similar sandbox modes with their own test values. The principle is the same: payment providers give you a safe place to rehearse, so use it.
Why real cards in staging are a bad idea
- Scope grows. Card data in a system pulls that system into payment security obligations, and staging usually has weaker controls.
- Leak paths multiply. Test logs, screenshots, bug tickets and recorded demos can capture the numbers.
- Real money can move. A mistaken configuration can charge a live card.
- Provider terms. Some agreements restrict live mode testing, as noted above.
Steps for safe payment testing
- Separate keys. Staging uses sandbox API keys only. Production keys never leave production. The related post on building integrations with sandbox keys covers this in more depth.
- Use published test values. Keep a short page in your repository listing the test cards, failure cases and edge cases you use, copied from the provider's own documentation, and link back to it.
- Cover the failure paths. Providers list test values that simulate declines, authentication challenges and disputes. Run them, because failure handling is where bugs live.
- Test webhooks end to end. Use the provider's tools to deliver sandbox events to staging, and verify signatures as you would in production.
- Block live keys by check. Add a startup assertion that refuses to boot in staging if a live key pattern is present.
- Scrub captures. Even test cards teach bad habits. Make sure screen recordings and tickets show test numbers only, and train people to spot the difference.
- Review quarterly. Check that no real card numbers appear in test databases, logs or fixtures. Search for number patterns that pass the standard checksum.
For end to end tests in the browser
Automated browser tests can fill card forms with the test numbers. Keep those values in test configuration, not in the page source. If the provider's hosted form blocks automation, use their documented testing approach, such as test payment method tokens, rather than working around the form.
Mistakes to avoid
- A "one real purchase to be sure" step in a release checklist.
- Copying production orders into staging with stored payment references still valid.
- Sharing sandbox keys in chat, as if they were harmless. They are still credentials for your sandbox account.
- Forgetting that refunds and payouts have their own test behaviour.
Quick check
Are test card numbers secret?
No. They are published in the provider's documentation. The secret part is your sandbox API key.
Is it ever fine to test with a real card?
Follow your provider's agreement. For most teams, the answer is to use test mode and keep real cards out of non production systems entirely.
Sources
Last reviewed: 19 October 2026.
