How to Test a Checkout Flow Without a Real Credit Card in 2026

Why Sandbox Testing Is Non-Negotiable for Checkout Flows

Checkout is where your application handles real money, real personal data, and real customer trust. A broken checkout does not just create a bug report. It creates lost revenue, chargebacks, and support tickets from angry customers who were charged twice or not charged at all but never received a confirmation. Testing checkout flows with real credit cards is expensive, slow, and introduces compliance headaches around storing and handling live payment credentials in test environments.

Every major payment provider offers a sandbox or test mode specifically designed for this. These test environments simulate the full payment lifecycle, including successful charges, declined cards, network timeouts, 3D Secure authentication challenges, and webhook delivery, without moving a single cent. The test card numbers are publicly documented and will never accidentally process a real transaction.

The goal of sandbox testing is not just to verify that a successful payment works. It is to verify that every failure mode is handled gracefully: declined cards show a clear message, expired cards are caught before submission, network errors trigger a retry or a helpful error state, and partial failures (charged but webhook failed) are recoverable. If you only test the happy path, you are only testing the scenario that needs the least testing.

Step 1: Set Up Stripe Test Mode and Use Test Cards

Stripe's test mode is the industry standard for payment testing. Every Stripe account has a separate set of API keys for test mode, and transactions made with test keys never touch real payment networks.

Enable test mode: In your Stripe Dashboard, toggle the "Test mode" switch in the top-right corner. Copy your test-mode publishable key (starts with pk_test_) and secret key (starts with sk_test_). Use these in your development and staging environments. Never use live keys outside production.

Essential test card numbers:

• 4242 4242 4242 4242 - Visa, always succeeds
• 4000 0000 0000 3220 - Triggers 3D Secure 2 authentication
• 4000 0000 0000 9995 - Always declined (insufficient funds)
• 4000 0000 0000 0002 - Always declined (generic decline)
• 4000 0000 0000 0069 - Declined with expired card error
• 4000 0000 0000 0127 - Declined with incorrect CVC error
• 4000 0027 6000 3184 - Requires authentication, succeeds when completed

For all test cards, use any future expiration date (e.g., 12/34), any 3-digit CVC (e.g., 123), and any 5-digit zip code.

Testing webhooks locally: Stripe sends webhook events (payment succeeded, payment failed, subscription updated) to a URL you configure. For local development, use the Stripe CLI to forward webhooks to your local server:

stripe listen --forward-to localhost:3000/api/webhooks/stripe

This gives you a webhook signing secret (starts with whsec_) that you use to verify webhook signatures locally. Trigger test events with stripe trigger payment_intent.succeeded to verify your webhook handler processes them correctly.

Step 2: Configure PayPal Sandbox Accounts

PayPal's sandbox environment runs on sandbox.paypal.com and simulates the full PayPal checkout experience, including buyer login, payment approval, and seller receipt. Unlike Stripe's simple test card numbers, PayPal requires you to create sandbox buyer and seller accounts.

Create sandbox accounts: Go to the PayPal Developer Dashboard and navigate to Sandbox > Accounts. PayPal automatically creates a default business (seller) and personal (buyer) account. You can create additional accounts to test specific scenarios. Each sandbox buyer account has a fake email, password, and a pre-loaded balance (usually $9,999).

Get sandbox API credentials: Under your sandbox business account, click "View/Edit" to find the sandbox Client ID and Secret. Use these in your application's PayPal integration for your staging environment. Your checkout redirect should point to sandbox.paypal.com, not the live paypal.com.

Test scenarios to cover:

• Successful payment with sandbox buyer account - verify the full redirect flow works and your server receives the capture confirmation
• Buyer cancels during PayPal login - verify your application handles the cancel redirect URL correctly and returns the user to the cart with items intact
• Insufficient sandbox balance - edit the sandbox buyer's balance to $0 and attempt a purchase
• Currency mismatches - if you sell in multiple currencies, test each one; PayPal sandbox supports all live currencies
• Refunds - process a sandbox refund through your admin panel or the PayPal sandbox dashboard and verify your system updates the order status

Tip: PayPal sandbox can be slow and occasionally flaky. If a test fails with a generic error, wait 30 seconds and retry before investigating your code. Also, sandbox sessions expire. If the buyer login stops working, reset the sandbox buyer's password in the Developer Dashboard.

Step 3: Test Apple Pay, Google Pay, and Other Methods

Modern checkout flows often support multiple payment methods beyond cards. Each has its own test mode requirements.

Apple Pay testing: Apple Pay requires a real Apple device (iPhone, iPad, or Mac with Touch ID/Face ID) even in test mode. You cannot test Apple Pay in a simulator. Register your domain with Stripe or your payment provider for Apple Pay, enable test mode, and use a real device connected to your Stripe test environment. The payment will simulate without charging anything. In your Stripe Dashboard, under Settings > Payment Methods, enable Apple Pay and verify your domain verification file is served at /.well-known/apple-developer-merchantid-domain-association.

Google Pay testing: Google Pay is easier to test. Add your Google account to the Google Pay test card suite by joining the Google Pay test mode group. When using Stripe with Google Pay in test mode, the Google Pay button will appear and simulate a payment without charging your real card.

Buy Now, Pay Later (Klarna, Afterpay, Affirm): Each BNPL provider has sandbox modes. Klarna's test environment uses a set of test personal details (not card numbers, since Klarna collects customer identity info). Check Klarna's developer docs for region-specific test credentials. Afterpay sandbox requires a separate merchant account and uses test customer details. These flows are worth testing because they involve multi-step redirects that can easily break.

Bank transfers and ACH: Stripe supports ACH Direct Debit testing with test account numbers. Use routing number 110000000 and account number 000123456789 for a successful payment, or 000111111116 for a failed payment. ACH payments are not instant, so verify your application handles the pending state correctly and sends a confirmation only after the payment succeeds (typically 3-5 business days in production, but instant in test mode).

Step 4: Systematically Test Every Failure Mode

The difference between a checkout that works and a checkout that is reliable is failure mode coverage. Build a test matrix and run through each of these scenarios explicitly.

Payment failures:

• Card declined (insufficient funds, generic decline, lost/stolen card)
• Card expired during checkout (user starts checkout, card expires before submission)
• Incorrect CVC or zip code
• 3D Secure authentication failed (user cancels the bank's authentication prompt)
• 3D Secure authentication times out (use Stripe test card 4000 0000 0000 3220 and do not complete authentication)
• Payment provider network timeout (simulate by temporarily blocking your server's outbound connection to Stripe's API or using Stripe's test clock features)

Application-level edge cases:

• Double-click on the Pay button: does the user get charged twice?
• Browser back button during payment processing: does the user see a broken state?
• Session expires mid-checkout: is the cart preserved? Does the user have to start over?
• Item goes out of stock between adding to cart and completing payment: does the system catch this before charging?
• Coupon code applied after the payment intent is created: does the amount update correctly?
• Currency conversion rounding: if the cart total involves tax calculations, verify the amount charged matches the amount displayed to the cent

Post-payment verification:

• Confirmation email sends with correct order details
• Order appears in your admin system with correct line items and amounts
• Inventory is decremented (if applicable)
• Webhook events are processed idempotently: replay the same webhook event twice and verify the order is not duplicated

Use Stripe's webhook event log in the Dashboard to verify every expected event was received and processed by your server.

Step 5: Automate Checkout Tests with Playwright

Manual checkout testing is tedious and error-prone. Automate the most common flows with Playwright so they run on every deployment.

Here is a basic Playwright test that completes a Stripe checkout with a test card:

import { test, expect } from '@playwright/test';

test('complete checkout with Stripe test card', async ({ page }) => {
await page.goto('/products/example-product');
await page.click('button:has-text("Add to Cart")');
await page.click('a:has-text("Checkout")');

// Fill shipping details
await page.fill('#email', 'test@example.com');
await page.fill('#shipping-name', 'Test Customer');
await page.fill('#shipping-address', '123 Test Street');
await page.fill('#shipping-city', 'Testville');
await page.fill('#shipping-zip', '12345');

// Fill Stripe card element (iframe)
const stripeFrame = page.frameLocator('iframe[name*="__privateStripeFrame"]').first();
await stripeFrame.locator('[placeholder="Card number"]').fill('4242424242424242');
await stripeFrame.locator('[placeholder="MM / YY"]').fill('1234');
await stripeFrame.locator('[placeholder="CVC"]').fill('123');
await stripeFrame.locator('[placeholder="ZIP"]').fill('12345');

await page.click('button:has-text("Pay")');
await expect(page.locator('.order-confirmation')).toBeVisible({ timeout: 15000 });
await expect(page.locator('.order-total')).toContainText('$');
});

Key considerations for Stripe iframe automation: Stripe Elements renders card fields inside iframes for PCI compliance. You must use Playwright's frameLocator() to interact with elements inside the Stripe iframe. The iframe name contains __privateStripeFrame, but the exact selector may vary, so use a partial match. If your checkout uses Stripe Checkout (hosted payment page), your test will navigate to checkout.stripe.com, and you will need to interact with Stripe's hosted UI instead.

Add to your CI pipeline: Run these tests against your staging environment using Stripe test keys. Set the Stripe keys as environment variables in your CI configuration, never hardcode them in test files.

Step 6: Pre-Launch Checkout Verification Checklist

Before switching from test mode to live mode, run through this final checklist. Every item on this list has caused real production payment failures.

Environment configuration:

• Live API keys are set in production environment variables (not hardcoded in source code)
• Webhook endpoints are configured for production URLs (not localhost or staging)
• Webhook signing secrets are updated for the live environment
• SSL certificate is valid and HTTPS is enforced on all checkout pages
• Payment method configurations (Apple Pay domain verification, Google Pay merchant ID) are set for the production domain

Compliance and legal:

• PCI compliance: if you handle card data directly (not recommended), you must be PCI DSS compliant. Using Stripe Elements or Checkout keeps you in PCI SAQ A scope (the simplest level)
• Refund policy is published and linked from the checkout page
• Tax calculation is correct for all jurisdictions where you sell (use Stripe Tax, TaxJar, or Avalara for automated tax calculation)
• Invoice and receipt generation includes all legally required information for your jurisdiction

Monitoring after launch:

• Set up alerts for failed payment webhook deliveries in your payment provider's dashboard
• Monitor your application's error logging for payment-related exceptions
• Track conversion rate from cart to completed purchase. A sudden drop indicates a checkout issue
• Review Stripe Radar fraud rules and ensure legitimate transactions are not being incorrectly blocked
• Verify that your payment provider's fraud detection is not set to overly aggressive thresholds for your region and customer base

Run one final real transaction with a real card for a small amount ($1 or your currency equivalent) immediately after going live. Refund it. This confirms the full live pipeline, including the webhook from the live environment, the live email sending, and the live order creation. No amount of sandbox testing is a substitute for one real end-to-end verification.

Frequently Asked Questions

Resources and Further Reading

• Stripe Testing Documentation Official Stripe docs with the complete list of test card numbers, test tokens, and test scenarios.
• PayPal Sandbox Testing Guide PayPal's official sandbox setup instructions including creating test accounts and API credentials.
• Stripe CLI Documentation Install and configure the Stripe CLI for local webhook forwarding and event triggering.
• Playwright Documentation Getting started with Playwright for automating browser-based checkout flow testing.
• PCI DSS Compliance Guide for Developers Stripe's guide to PCI compliance levels and how using Stripe Elements minimizes your compliance burden.

Related Guides