What a card test environment is
A card test environment is a payment sandbox wired to a provider's simulator rather than to live card networks. It accepts reserved test card numbers, returns scripted authorization responses, and lets engineers run checkout, refund, subscription, and 3-D Secure flows without moving real money. Because no real account is charged, the environment can be rebuilt, reset, or deleted at will. It is a development tool, not a place to check whether an unknown card number is live.
Prerequisites
- A sandbox account with a payment provider or acquirer simulator.
- Separate API credentials for test and production, stored in different secret stores.
- A staging build of your application that points at the sandbox base URL.
- A written data policy covering what test data may be stored and for how long.
How to set up the environment
- Create a dedicated sandbox project in the provider dashboard and name it after the team that owns it.
- Generate test API keys and load them into your staging secret manager only. Never copy them into a mobile build or a public repository.
- Point the staging application at the sandbox endpoint, and add a startup check that refuses to boot if a production key is detected.
- Seed the test catalog with the provider's reserved card numbers. Each number maps to a fixed outcome, such as approval, soft decline, hard decline, or insufficient funds.
- Add simulated issuer challenges for 3-D Secure by enabling the frictionless and challenge test cases in the sandbox configuration.
- Write automated tests for the failure paths first: expired card, wrong CVC, do-not-honor, and network timeout. These paths break production checkouts most often.
- Exercise the full lifecycle in order: authorize, capture, partial refund, full refund, and chargeback simulation.
- Mask or truncate any card number that appears in logs, traces, or dashboards. Test numbers still deserve the same handling as real ones.
- Reset the sandbox on a schedule so stale test customers and tokens do not accumulate.
What to keep out of a test environment
Live card numbers, real CVV values, and production customer records do not belong in a sandbox. PCI DSS prohibits storing sensitive authentication data such as the CVV after authorization, and a test system is not exempt because the traffic is simulated. If you need realistic data, generate synthetic values with a tokenization service or the provider's own test fixtures.
Keep the boundary enforced with network rules, separate databases, and a review step before any staging code reaches production. When the sandbox and production share credentials or storage, the test environment stops being a test environment.