Testing a checkout flow means simulating everything that happens between a user clicking "Pay" and your backend confirming "funds cleared" โ declined cards, fraud checks, refunds, webhooks firing out of order โ without ever charging a real account. Payment processors publish sandbox environments and well-known test card numbers exactly for this purpose. This guide covers the test cards and sandbox tooling offered by Stripe, PayPal, Braintree, Adyen and Square, plus a workflow for combining them with fake billing data.
What "test cards" actually are
A test card is a 16-digit PAN (Primary Account Number) the processor has reserved in its sandbox. The number passes Luhn checksum validation, looks like a real Visa or Mastercard, and triggers a specific processor response โ success, decline, card-insufficient-funds, expired, etc. โ without ever routing to a real issuer. Most processors publish a handful of well-known test cards in their docs; use those instead of inventing your own, because the last four digits are usually coded to mean specific decline codes.
Stripe โ the most complete sandbox
Stripe is the gold standard for test infrastructure. Their sandbox ("test mode") accepts publishable + secret test keys starting with pk_test_ and sk_test_, so every API call has a test equivalent and every webhook is mirrorable via the Stripe CLI.
Essential Stripe test cards
| Number | Brand | Result |
|---|---|---|
| 4242 4242 4242 4242 | Visa | Succeeds |
| 4000 0027 6000 3184 | Visa | Declined โ attaches a fraudulent block |
| 4000 0000 0000 0002 | Visa | Generic decline |
| 4000 0000 0000 9995 | Visa | Insufficient funds |
| 4000 0000 0000 0069 | Visa | Expired card |
| 4000 0082 6000 3178 | Visa | Requires 3DS authentication |
| 5555 5555 5555 4444 | Mastercard | Succeeds |
| 3782 822463 10005 | Amex | Succeeds (Amex test card, 15 digits) |
Stripe CLI: replaying webhooks locally
The killer feature is the Stripe CLI, which forwards live test-mode events to your local webhook endpoint:
stripe login
stripe listen --forward-to http://localhost:8080/webhooks/stripeThat one command is the difference between "I tested the happy path" and "I tested the entire happy path including the webhook that updates my database". Trigger specific events manually:
stripe trigger payment_intent.succeeded
stripe trigger invoice.payment_failed
stripe trigger charge.refundedPayPal โ sandbox accounts and fakes
PayPal exposes a "sandbox" environment with separate sandbox buyer and merchant accounts you create from the Developer Dashboard. Create at least one sandbox business account (merchant) and one personal sandbox buyer.
Sandbox test cards โ used inside the PayPal sandbox for guest checkout โ include these well-known values:
- Visa: 4032035728984848 (expires any future date, CVV 123)
- Mastercard: 5425233430109242
- Amex: 374245455400126
These cards only work inside PayPal's sandbox; using them anywhere else produces a generic decline. The PayPal sandbox does not support the variety of decline scenarios Stripe does โ to test PayPal declines, use the reviewer tool in the developer dashboard to attach a "negative testing" flag to your sandbox account that forces the next transaction to fail.
Braintree โ sandbox cards
Braintree (a PayPal company) separates sandbox keys from production keys at initialization time, and publishes its own set of test cards keyed to specific response codes:
| Number | Result |
|---|---|
| 4111 1111 1111 1111 | Approved |
| 5105 1051 0510 5100 | Approved (Mastercard) |
| 4000 1111 1111 1115 | Processor declined โ card type not enabled |
| 5000 1111 1111 1114 | Processor declined โ declined by issuer |
| 4000 1111 1111 1112 | Processor declined โ blocked |
Braintree also lets you control the AVS and CVV response by setting specific street addresses or CVV values โ useful when testing advanced fraud and card-verification paths.
Adyen and Square
Adyen offers a test account with predictable per-card-number outcomes and excellent refusal-reason codes. Common test cards include 4111 1111 1111 1111 (Visa, authorised) and 5101 1800 0000 0007 (Mastercard). Adyen's "test" prefix on the response object makes auditing easy.
Square publishes sandbox cards like 4111 1111 1111 1111 (Visa charges successfully) and 5105 1051 0510 5100 (Mastercard declines). The Square Sandbox lets you create sandbox customers and store cards on file.
Best practice: test every decline path
Concrete checklist that exercises the failure surface most teams forget:
- Successful charge with valid card
- Generic processor decline
- Insufficient funds
- Expired card
- 3DS-required scenario (verify challenge modal appears and challenge completion succeeds; verify and cancel โ each path matters)
- Card saved on file, then charged later via the saved token
- Refund full and refund partial
- Refund issued for a charge that was already disputed (recovery path)
- Webhook arrives twice โ verify your handler is idempotent
- Webhook arrives before your database insert (the rare out-of-order case Stripe calls "eventid ahead of state")
An idempotent webhook handler is non-negotiable. Use the event ID as your idempotency key. If you find yourself writing
if (!exists) { insert } else { skip }in your handler โ congratulations, you have written idempotency. Do not lose it during the next refactor.
Pairing test cards with fake billing data
A successful sandbox charge also depends on AVS (Address Verification System) โ the issuer checks the ZIP and street number against the card on file. For most sandbox cards, the test environment ignores AVS results, but for testing your form's error paths (incorrect ZIP triggering an error message, for example) you need stable but obviously fake billing data.
This is where the USA Data Tools address generator fits in:
curl "https://vic999.com/us-address/api/v1/address?count=20" \
-H "Authorization: Bearer YOUR_API_KEY" \
-o fixtures/billing-addresses.json- Realistic addresses let you assert your form accepts every ZIP-to-state combination.
- State-specific data is invaluable for testing sales tax line items before the charge.
- The Tax-Free States generator lets you verify zero-tax checkout in Delaware, Montana, New Hampshire, and Oregon.
Pair generated billing addresses with Stripe's 3DS-required test card and a generated purchase amount, and you have a fully reproducible checkout test scenario that exercises AVS, taxes, and 3DS in one shot.
Idempotency โ the silent checkout killer
Real-world payment outages look like this: a user clicks Pay, the request times out at 28 seconds, the user clicks Pay again โ and they get charged twice. Every payment API supports an idempotency key; use it.
// Stripe example: pass an idempotency key
const paymentIntent = await stripe.paymentIntents.create({
amount: 1999,
currency: "usd",
customer: customerId,
}, {
idempotencyKey: `order_${orderId}_pay`,
});The same call twice from the same client (or 50 times from a panicking user) becomes a single charge. Build an end-to-end test that double-sends the Pay request and asserts only one charge exists; this single test prevents ~30% of real production payment incidents.
Webhook replay: catch the rare-but-catastrophic bugs
Stripe lets you replay any webhook from the dashboard. Save payment_intent.id, click "Resend" 12 hours later, and verify your handler treats it correctly โ many a real bug surfaces only in that scenario. With generated order IDs and addresses, you have a fully reproducible fixture that triggers exactly the path you want.
CI integration
Wire your decline matrix into nightly CI using separate sandbox keys:
- name: Checkout decline matrix
run: npx playwright test checkout-declines
env:
STRIPE_SECRET_KEY: ${{ secrets.STRIPE_TEST_SECRET_KEY }}
STRIPE_PUBLISHABLE_KEY: ${{ secrets.STRIPE_TEST_PUBLISHABLE_KEY }}
BILLING_FIXTURES_URL: https://vic999.com/us-address/api/v1/address?count=50The night it goes green, ship it.
What to use the test data generators for in payments
- Realistic billing addresses for the AVS path
- Phone numbers for the order-confirmation SMS path
- An EIN for business-account KYB (use EIN Generator)
- An SSN-format fixture for individual KYC (use the reserved-range SSN Test Format)
Wrapping up
Testing payment flows is not complicated โ it is comprehensive. The processor sandboxes cover the charge side; generated fake data covers the form and AVS side; an idempotency-key pattern plus a replay-driven webhook test covers the silent failures that turn into $30k refunds. Start by writing out the decline matrix above, wire it up with Stripe CLI to your local webhooks, and use the address generator for the fake billing rows. Your checkout stops being a black box the first night the matrix goes green.