A checkout test with card payment is a sandbox exercise: you run your checkout flow against a payment provider's test environment using published test card numbers instead of real card data. The test confirms that your form validates input, your integration sends a proper authorization request, and your store handles approvals, declines, and authentication challenges as expected.
Why providers publish test card numbers
Payment processors publish test card numbers so developers can exercise an integration without moving money or touching live cardholder data. Each number maps to a simulated outcome, so the same checkout can be replayed against an approval, a generic decline, a lost card response, or a 3D Secure challenge. Because the numbers are public and tied to sandbox accounts, the results are repeatable and safe to share with a QA team.
What to prepare before you test
- Sandbox or test-mode API keys, kept separate from production credentials.
- A test product or a zero-value order so totals are easy to trace.
- A webhook endpoint that can receive and log event payloads.
- A short checklist of outcomes you expect to see for each card you plan to submit.
- Browser tools open on the network tab so you can inspect the tokenization request.
How to run the test step by step
- Switch your store to test mode and confirm the checkout page loads the sandbox tokenization script.
- Add the test item to the cart and move to checkout. Fill the address fields with any clearly fake data.
- Enter a published test card number, a future expiry date, and any test CVC value the provider documents.
- Submit the payment and watch for the redirect or modal used by your 3D Secure flow.
- Compare the on-screen result, the provider dashboard entry, the webhook event, and the order status in your own system. All four should agree.
- Repeat with a decline scenario and confirm the order is not marked as paid.
Scenarios every test run should cover
- Approved payment with a standard test number.
- Generic decline and insufficient funds responses.
- Expired card and incorrect CVC handling in the form itself.
- 3D Secure challenge completed, abandoned, and failed.
- Duplicate submission, to check that idempotency keys stop double charges.
- Refund and void on a settled test transaction.
- Currency, locale, and address format variations.
- Network timeout or dropped response, to see how the order state recovers.
Reading the results
The provider response tells you whether the authorization succeeded, but the webhook tells you what actually happened to the payment. Log every event payload with a timestamp and match it to the order. If your application marks an order paid from the browser callback alone, a dropped connection can leave a paid order behind a failed charge or a charge with no order at all. Treat the webhook as the source of truth and the browser response as a user interface hint.
Common failure points
- Test keys in a production build, or production keys on a staging host.
- Webhook signature verification skipped, so replay attacks go unnoticed.
- Order created after the charge instead of before it, which makes recovery hard.
- Amounts passed as floating point values instead of minor units.
- 3D Secure return URL pointing at a page that no longer exists.
Rules for handling card data during testing
Only use card numbers that the processor publishes for testing. Never enter a real card number you do not own into a form, a sandbox, or a shared QA environment. PCI DSS requirements apply to any environment that touches cardholder data, and test environments are usually kept out of scope by design, not by accident. Store only the tokens and reference identifiers your provider returns, keep the test data set clearly labeled, and delete it when the integration work is finished.
Quick answer recap
A checkout test with card payment works best when you use sandbox credentials, published test card numbers, and a fixed list of scenarios. Verify the screen, the dashboard, the webhook, and your order record together, because a passing checkout page is not proof that the payment was recorded.