Test de charge pour les pics de transactions de passerelle de paiement

Les flux de paiement sont la pire surface pour apprendre les leçons du load testing. Une auth échouée est une commande perdue, une capture dupliquée est un chargeback, un backlog de webhooks devient du fulfillment en retard. Ce template cible les modes de défaillance rencontrés en poussant de vrais flux de cartes sous charge.

Ne visez jamais un processeur live

Ne pointez pas les VUs sur api.stripe.com ni sur aucun PSP live. Vous serez rate-limited, vous risquez d'enfreindre votre accord acquéreur, et vous pouvez vous embarquer dans une portée PCI-DSS que vous n'aviez pas signée. Utilisez Stripe test mode, l'API test Adyen, la sandbox Braintree. Pour exercer votre couche d'orchestration — token vaulting, idempotence, retry, écritures de ledger — stubbez le PSP derrière WireMock ou un petit service Express qui renvoie une latence réaliste et les mêmes codes d'erreur que le processeur réel (card_declined, processing_error, rate_limited).

Idempotence sous tempêtes de retry

La plupart des bugs de paiement à l'échelle ne sont pas "l'API a ralenti" — ils sont "deux retries se sont télescopés et on a facturé deux fois". Une clé d'idempotence par commande logique, réutilisée à travers les retries ; vérifiez que votre backend dédoublonne quand 1 000 VUs martèlent le même endpoint avec la même clé. Puis cassez-la : même clé, montant différent, confirmez le rejet. Stripe renvoie HTTP 400 idempotency_error — traitez ça comme un timeout réseau.

3DS et auth asynchrone

L'auth sync p95 doit rester sous 800 ms, capture p99 sous 2 s, mais 3DS fait exploser ça — budgetez 5 s pour l'aller-retour du challenge et 1 à 2 s pour le callback de résultat. Modélisez 3DS comme un scénario à part, pas un bucket de percentile. Environ 10 à 25% du volume cartes européen déclenche un challenge selon l'émetteur et les exemptions SCA ; un test mix à 0% de challenges n'est pas la réalité. Parkez le VU sur l'URL du challenge pour un think-time réaliste, ne rebouclez pas direct dans une nouvelle auth.

Les webhooks sont le deuxième système

La réponse d'auth est la moitié de l'histoire. Settlement, refund, dispute, événements 3DS-completed arrivent en async et le receveur doit suivre. Visez 99,9% des webhooks traités en moins de 30 s, SLO dur 5 min. Rejouez des payloads Stripe ou Adyen signés à 10×, 50×, 100× du taux attendu ; surveillez la profondeur de queue, le CPU de vérification de signature, la contention des écritures DB. Échec courant : le handler fait un upsert sync plus l'envoi d'un email, et à 200 événements/sec le pool meurt de faim. Déplacez les side effects vers une queue, ackez en < 200 ms.

Rate limits PSP et circuit breakers

Stripe publie ~100 ops read et 100 write/sec par compte ; Adyen et Checkout.com ont les leurs et vous renverront 429 avec Retry-After bien avant que vous ayez fini de ramper. Votre client doit lire ce header, pas backer off à l'aveugle, et votre breaker doit s'ouvrir avant que le PSP ne commence à délester. Injectez des 429 depuis votre stub à 5%, 20%, 50% et confirmez que les transactions queuent ou fail-fast au lieu d'empiler les retries qui aggravent la tempête.

L'exécuter sur LoadFocus

Utilisez le mode JMeter si vous avez déjà un .jmx avec cartes de test pilotées par CSV et clés d'idempotence paramétrées, ou k6 si vous préférez scripter en JS. Les deux tournent depuis 26+ régions cloud avec des milliers de VUs, graphiques temps réel auth/capture/webhook, et hooks CI (GitHub Actions, GitLab, Jenkins) pour qu'une régression p95 d'auth fasse échouer le build. Commencez à 10% de votre minute pic de Black Friday, validez idempotence et gestion des 429 là, puis montez en charge.