Load Testing for Payment Gateway Transaction Surges

Payment flows are the worst surface to learn load-testing lessons on. A failed auth is a lost order, a duplicate capture is a chargeback, a webhook backlog turns into stale fulfillment. This template targets failure modes we hit pushing real card flows under load.

Never aim load at a live processor

Do not point VUs at api.stripe.com or any live PSP. You'll get rate-limited, may breach your acquirer agreement, and can drag yourself into PCI-DSS scope you didn't sign up for. Use Stripe test mode, Adyen test API, Braintree sandbox. To exercise your orchestration layer — token vaulting, idempotency, retry, ledger writes — stub the PSP behind WireMock or a small Express service that returns realistic latency and the same error codes the real processor emits (card_declined, processing_error, rate_limited).

Idempotency under retry storms

Most payment bugs at scale aren't "the API got slow" — they're "two retries collided and we charged twice." One idempotency key per logical order, reused across retries; verify your backend de-duplicates when 1,000 VUs hammer the same endpoint with the same key. Then break it: same key, different amount, confirm rejection. Stripe returns HTTP 400 idempotency_error — handle it like a network timeout.

3DS and async auth

Sync auth p95 should sit under 800 ms, capture p99 under 2 s, but 3DS blows that up — budget 5 s for the challenge round-trip and 1–2 s for the result callback. Model 3DS as a separate scenario, not a percentile bucket. Roughly 10–25% of European card volume hits a challenge depending on issuer and SCA exemptions; a test mix with 0% challenges isn't reality. Park the VU on the challenge URL for realistic think-time, don't loop straight back into a new auth.

Webhooks are the second system

The auth response is half the story. Settlement, refund, dispute, 3DS-completed events arrive async and the receiver has to keep up. Target 99.9% of webhooks processed within 30 s, hard SLO 5 min. Replay signed Stripe or Adyen payloads at 10×, 50×, 100× expected rate; watch queue depth, signature-verification CPU, DB write contention. Common failure: handler does a sync upsert plus email send, and at 200 events/sec the pool starves. Move side effects to a queue, ack in < 200 ms.

PSP rate limits and circuit breakers

Stripe publishes ~100 read and 100 write ops/sec per account; Adyen and Checkout.com have their own and will 429 with Retry-After well before you finish ramping. Your client must read that header, not back off blindly, and your breaker must open before the PSP starts shedding. Inject 429s from your stub at 5%, 20%, 50% and confirm transactions queue or fail-fast instead of piling retries that worsen the storm.

Running it on LoadFocus

Use JMeter mode if you already have a .jmx with CSV-driven test cards and parameterized idempotency keys, or k6 if you'd rather script in JS. Both run from 26+ cloud regions with thousands of VUs, real-time auth/capture/webhook charts, and CI hooks (GitHub Actions, GitLab, Jenkins) so a p95 auth regression fails the build. Start at 10% of your peak Black Friday minute, validate idempotency and 429 handling there, then scale up.