A card test sample is a card number that a payment processor publishes for use in its sandbox or test mode. The number passes format checks, routes to a simulated authorization, and returns a predictable response. Developers use these samples to confirm checkout forms, API payloads, and error handling work before live traffic reaches the account. A test number belongs to one processor and stops working the moment the request leaves test mode.

Prerequisites

  • Sandbox account with the payment processor
  • Test-mode API keys, separate from live keys
  • Access to the processor's published test card list
  • A staging checkout or API client you can run requests against

How to run a card test sample

  1. Switch the integration to test mode. Confirm the dashboard shows a test banner and the keys carry the test prefix.
  2. Open the processor's test card documentation and copy the number that matches the scenario you need: approval, generic decline, insufficient funds, or expired card.
  3. Paste the sample number into the checkout field or the API request body.
  4. Fill the remaining fields with any future expiry date, any three- or four-digit CVC, and a billing ZIP in a format the processor accepts.
  5. Submit the request and record the response: status, authorization code, and decline code.
  6. Repeat the run for every decline scenario on your list and check that the interface shows the correct message for each.
  7. Run the authentication flow with the processor's challenge and frictionless test cards if you support 3-D Secure.
  8. Replay the same request to confirm idempotency and webhook delivery behave as designed.
  9. Clear test records and swap the keys back to live mode before release, then search the codebase for leftover test identifiers.

Test the decline paths first

Approvals are the easy case. Declines expose the gaps: missing error copy, a spinner that never resolves, or an order written to the database on a failed authorization. Walk every decline code your processor documents and map each one to a user-facing message.

What each field does

  • Card number selects the simulated outcome and the card brand.
  • Expiry must sit in the future or the request fails validation before authorization.
  • CVC is checked only when the test card is built to trigger a CVC mismatch.
  • Billing ZIP drives address verification results on processors that simulate AVS.

Common mistakes

  • Entering live card numbers in a test environment. PCI DSS keeps production cardholder data out of non-production systems.
  • Assuming a sample from one processor works at another. Number ranges and behavior differ by provider.
  • Hardcoding a sample number in production code paths.
  • Skipping address verification, which causes unexpected declines in the live flow.
  • Shipping with sandbox keys still in the build config.