Short answer
Card checkout procedure testing means running a payment through every step a real customer would hit, using processor-issued test card numbers in a sandbox account. You are not checking whether the form looks nice. You are checking that each state change fires in the right order and leaves the order in a state your backend can reconcile: authorization, CVV/CVC check, address verification, 3-D Secure challenge, capture, void, refund, and webhook delivery.
What the procedure actually covers
- Tokenization of the card number before it touches your server.
- Client-side validation (length, Luhn, expiry, CVC digit count) versus what the gateway rejects.
- The authorization request and the response code you get back.
- Capture timing: auth-and-capture in one call, or auth now and capture at fulfillment.
- Partial captures, voids, refunds, and how each one shows up on the order record.
- Webhook handling, including duplicate and out-of-order events.
Order of operations you should verify
- Customer submits the form. Your code sends only a token or payment method ID.
- Gateway returns an authorization result. Inspect the raw response, not just the success flag.
- If the issuer requests authentication, the 3-D Secure challenge runs in an iframe or redirect.
- On approval, you capture or schedule capture, then write the transaction ID to the order.
- Webhook arrives and confirms the same state your synchronous call reported.
Step 5 is where most integrations fail. A checkout that only trusts the synchronous response will drift whenever a webhook lands late.
Testing CVV/CVC validation on its own
CVV verification happens at the issuer, not in your code. Sandboxes simulate it. Test four cases: correct value, wrong value, missing value, and the 4-digit CID used by American Express, which sits on the front of the card and not the back. Confirm your logs never capture the CVC or the full card number. PCI DSS classifies CVV2/CVC2/CID as sensitive authentication data, and it cannot be retained after authorization, even encrypted.
Checkout Process Card Test Guide for Selling CVV Online
Test cards and expected results
Every major processor publishes a test card set with fixed behaviors. Stripe, for example, documents a plain success number, an always-declined number (4000 0000 0000 0002), an insufficient-funds number, and a number that forces a 3-D Secure challenge (4000 0000 0000 3220). The CVC value expected for test cards differs by processor: some document 123, some accept any three digits, and some reject 000 on purpose. Read your gateway's table before you file a bug.
Idempotency, retries, and races
Click the pay button twice with a slow connection. Kill the network mid-request. Replay the same webhook event twice. If two charges appear in the dashboard, you have an idempotency gap. Send an idempotency key with every create call and store it next to the order, so a retry returns the original result instead of a second authorization.
Common failure modes
- Decline codes mapped to a generic error, so support cannot tell a bad CVC from a closed account.
- Frontend validation stricter than the gateway, blocking valid international cards.
- Currency or amount sent as a float and rounded somewhere in the chain.
- Refund issued against the payment intent instead of the charge, leaving the order in a half-refunded state.
- Test keys left in a staging build that talks to live data.
Keep test data separate
Never paste a live card number into a sandbox, and never run test numbers against a production key. PCI DSS applies wherever real account data flows, and one stray live PAN in a log file turns a QA exercise into a compliance incident.