Testing card checkout integration means running every payment path inside your processor's sandbox before a real customer touches the form. You use documented test card numbers to simulate approvals, declines, 3D Secure challenges, and network errors, then confirm that your server, database, and webhooks all reach the correct state. Only after those paths pass should you swap in live credentials.
Work in the sandbox first
Every major processor gives you a separate test environment with its own API keys. Nothing you do there moves money, so you can trigger edge cases on purpose and repeat them as often as you need. Keep test keys out of production configuration files, and make the environment switch a single, obvious constant so nobody ships the wrong key by accident.
What test card numbers let you simulate
Test card numbers are published by each processor and are tied to specific outcomes. A typical set includes:
- An approved payment that settles normally
- A generic decline
- Insufficient funds
- An expired card
- An incorrect CVC or postal code
- A card that requires a 3D Secure challenge
- A card that fails authentication
These numbers only work in test mode. Their entire purpose is to let you drive your own error handling without needing real accounts.
test checkout process with card
Scenarios your checkout must handle
A checkout that only works on the happy path will break in production within a week. Build a test matrix that covers:
- A standard one-time payment
- A saved card charged later, outside the customer session
- A full refund and a partial refund
- A void issued before settlement
- A 3D Secure challenge that the customer completes
- A 3D Secure challenge that the customer abandons
- A timeout or dropped connection during the authorization call
- The same request submitted twice
- Rounding and currency behavior for each market you sell in
Idempotency and retries
Networks fail. If your server retries an authorization without an idempotency key, you can charge a customer twice. Send a unique key with every create request, then force a retry in the sandbox and verify that only one charge exists on the backend.
Webhooks are part of the test
Client-side confirmation is not proof of payment. Subscribe to your processor's webhook events for authorization, capture, refund, and dispute, then check that your order record updates from the event and not from the browser callback. Test signature verification and replay protection as well, and confirm that a duplicate event does not create a duplicate order.
Never use real card numbers in test
Cardholder data protection rules apply to test systems too. Storing or transmitting a live account number in a development environment puts that data outside the controls required for production and creates a reportable incident if the environment leaks. Use only processor-issued test numbers, and keep production data out of logs, fixtures, and screenshots.
Pre-launch checklist
- Live keys are loaded from environment variables, not source code
- Every decline and error code maps to a clear customer message
- Idempotency keys are sent on all create and capture calls
- Webhook signature verification is enabled
- Refunds, voids, and disputes are tested end to end
- Logs contain no full card numbers or CVC values
- Monitoring alerts fire on authorization failure spikes
Run the full matrix once more against live credentials with a low-value real card you control, and refund it immediately. That single transaction confirms the account is active, the descriptor is correct, and settlement works as expected.