A sandbox test card is a fake card number that a payment gateway publishes for its test environment. You enter it the same way a customer enters a real card, the gateway returns an approval or a decline, and no money moves because the number is not tied to any bank account. Use it to verify your checkout form, your server-side charge call, and your error handling before you accept live payments.

What a sandbox test card can and cannot do

Test cards exercise the full request path: tokenization, authorization, capture, refund, and webhook delivery. The sandbox mirrors the shape of production, so a successful charge returns a test charge object you can inspect, list, and delete.

Test cards cannot predict how a real issuer will respond, and they never reach a card network. Treat every result as a check on your integration code, not on your fraud rules or your risk model.

Prerequisites

  • A sandbox or test-mode account with your payment gateway
  • Test API keys, not live keys, loaded in your environment file
  • The gateway's client library installed in your project
  • A test customer record or a tokenization endpoint you can call
  • Access to the gateway's published test card list for your region

How to run a sandbox test card payment

  1. Create a sandbox account with the gateway and confirm test mode is active in the dashboard header.
  2. Copy the test publishable key and test secret key into your local environment variables.
  3. Open the gateway's test card documentation page and copy one approval card number for the brand you want to test.
  4. Build a checkout form that posts the card number, a future expiry date, a three-digit CVC, and a billing postal code.
  5. Submit the form and confirm the gateway returns a successful charge or payment intent status.
  6. Open the dashboard test view and match the charge ID from your response to the record shown there.
  7. Repeat the flow with a decline card number and confirm your code shows a readable failure message instead of a crash.
  8. Run a refund against the approved test charge and check the refund object status.
  9. Delete the test customer and test charges once your checks pass, so later runs start clean.

Test card numbers that appear in most gateway docs

These numbers are published openly by major processors for test mode only. They pass a Luhn check, so most client-side validators accept them.

  • 4242 4242 4242 4242, Visa, returns an approval in the Stripe sandbox
  • 4000 0000 0000 0002, Visa, returns a generic card decline
  • 4000 0000 0000 3220, Visa, forces a 3D Secure authentication step
  • 5555 5555 5555 4444, Mastercard, returns an approval
  • 4111 1111 1111 1111, Visa, returns an approval in the Braintree sandbox
  • 3782 822463 10005, American Express, uses a four-digit CVC
  • Any future expiry date and any CVC value work with these numbers

Testing declines, 3DS, and other failure paths

Approvals only prove the happy path. Pick at least one decline card, one insufficient-funds card, and one authentication card from your gateway's list. Watch how your server maps the gateway error code to a message, how your client renders it, and whether your webhook handler records the failed attempt. Check the order in which the gateway fires events, since a payment intent can move through several states before it settles in test mode.

Mistakes that waste time

  • Running test cards against live keys, which returns an authorization error and can flag the account
  • Reusing a test card number with a hard-coded expiry date that has already passed
  • Skipping the webhook check, then discovering the handler breaks on a real event
  • Testing one card brand and assuming all brands behave the same
  • Leaving test customers and charges in the dashboard until the data becomes hard to read