Q5 of 22 · Scenarios
How would you test a payment / checkout flow?
ScenariosMidscenariopaymentcheckoutsecurityfunctionalpci
Short answer
Short answer: Clarify payment providers, sandbox availability, guest vs authenticated flow, and retry policy first. Then cover the full transaction lifecycle, every decline scenario, security (PCI, CSRF), and behavior during provider outages.
Detail
Clarify first
- Which payment providers are integrated (Stripe, PayPal, Adyen), and is there a sandbox/test mode?
- Does the flow support guest checkout, or is authentication required?
- What is the retry policy for failed payments — automatic retry, manual retry, or immediate failure?
- Are there multiple currencies or locales to consider?
Functional
- Valid card completes order; confirmation page shown and confirmation email sent
- Order record created in the database with correct status, amount, and customer ID
- Inventory decremented by the correct quantity after successful payment
- Receipt or invoice generated with accurate line items, tax, and totals
- Saved payment method (if applicable) used correctly on return checkout
Negative / error handling
- Declined card — test multiple decline codes: insufficient funds, card lost/stolen, do-not-honor, expired card, wrong CVV
- Network timeout mid-payment — user shown a clear status (pending vs failed), no double charge
- Duplicate form submission (double-click, network retry) — idempotency prevents duplicate orders
- Payment provider returns an unexpected error code not in the integration's mapping
Edge & boundary
- Cart modified (item removed, quantity changed) after entering payment details
- Session expires mid-checkout — state preserved or user redirected to re-authenticate?
- Browser back button pressed after payment confirmation — no re-charge on page reload
- Last available unit of an item purchased by two users simultaneously — race condition handled
- Currency with no decimal places (JPY) or unusual decimal precision
Security
- PCI compliance: card data never touches your servers — tokenisation via payment provider's SDK
- HTTPS enforced throughout checkout; no card details in URLs or server logs
- CSRF token on the payment form
- 3DS / strong customer authentication redirect handled correctly
Performance
- Payment endpoint response time under load; behavior during payment provider degradation (circuit breaker, graceful fallback)
Close: automate with sandbox/mock for all card decline codes and DB-state assertion post-payment. Keep manual for 3DS redirect flows, slow-network UI feedback, and observability (do failed payments alert on-call?).
// WHAT INTERVIEWERS LOOK FOR
PCI tokenisation (card data never on your servers), idempotency for duplicate submissions, and race condition on the last available item. These signal real-world payment experience beyond basic happy-path testing.
// COMMON PITFALL
Only testing valid and declined card scenarios. Missing idempotency, 3DS, session expiry mid-flow, and the PCI scope question about where card data actually flows.