What a test transaction card is

A test transaction card is a card number that a payment processor publishes for sandbox use. It behaves like a real card inside a test environment and never touches a live bank network. To use one, switch your account or API keys to test mode, enter a number from your processor's published test list, submit the payment, and read the response. The charge is simulated, so no money moves and no cardholder is involved.

What you need first

  • A sandbox or test account with your payment provider
  • Test API keys, kept separate from live keys
  • The provider's current test card list, which changes over time
  • A staging checkout page that points at the sandbox endpoint

How to run a test transaction

  1. Open your payment dashboard and confirm the account is set to test or sandbox mode.
  2. Copy your test publishable and secret keys into your staging environment file. Never reuse live keys here.
  3. Open the processor's test card documentation and pick a card number that matches the outcome you want, such as a successful charge or a specific decline.
  4. Load your staging checkout page and enter the test card number, any future expiry date, and any three digit security code, since sandbox checks do not validate them.
  5. Fill the billing fields with dummy data such as a generic street address and a test postal code.
  6. Submit the payment and wait for the response object.
  7. Read the response code and message. A success code confirms the flow works, and a decline code confirms your error handling works.
  8. Open the dashboard transactions list to confirm the test payment appears with its status.
  9. Check your webhook log to verify the event fired and your handler stored it.
  10. Repeat the run with a decline card, an expired card, and a card that triggers authentication, so every branch of your code is exercised.
  11. Clear the test data from your staging database before you point the same code at live keys.

Common outcomes and what they mean

  • Approved: the full flow works end to end, including order creation.
  • Generic decline: your checkout shows a retry path instead of a broken screen.
  • Insufficient funds: your messaging should stay neutral and avoid blaming the customer.
  • Authentication required: your code must hand off to the challenge step and handle the return.

Before you go live

Swap test keys for live keys, remove hardcoded test card numbers from your codebase, and run one small live transaction with your own card to confirm the production endpoint resolves. Keep a short checklist of the test cases you ran so the next release repeats the same coverage.