Lasttests für Spitzenbelastungen bei Zahlungsgateway-Transaktionen

Payment-Flows sind die schlechteste Flache, um Lasttest-Lessons zu lernen. Eine fehlgeschlagene Auth ist ein verlorener Auftrag, eine doppelte Capture ein Chargeback, ein Webhook-Backlog wird zu veralteter Fulfillment. Dieses Template zielt auf Ausfallmodi, die wir beim Pushen echter Kartenflusse unter Last getroffen haben.

Richten Sie Last niemals auf einen Live-Processor

Zeigen Sie VUs nicht auf api.stripe.com oder einen Live-PSP. Sie werden rate-limited, brechen moglicherweise Ihre Acquirer-Vereinbarung und ziehen sich in einen PCI-DSS-Scope hinein, fur den Sie nicht unterschrieben haben. Nutzen Sie Stripe Test Mode, Adyen Test API, Braintree Sandbox. Um Ihre Orchestrierungsschicht zu belasten - Token Vaulting, Idempotenz, Retry, Ledger Writes - stubben Sie den PSP hinter WireMock oder einem kleinen Express-Service, der realistische Latenz und dieselben Error-Codes liefert wie der echte Processor (card_declined, processing_error, rate_limited).

Idempotenz unter Wiederholungssturmen

Die meisten Payment-Bugs unter Last sind nicht "die API wurde langsam" - sondern "zwei Retries kollidierten und wir haben doppelt belastet". Ein Idempotency-Key pro logischer Bestellung, uber Retries hinweg wiederverwendet; verifizieren Sie, dass Ihr Backend dedupliziert, wenn 1.000 VUs denselben Endpoint mit demselben Key hammern. Dann brechen Sie es: selber Key, andere Summe, Ablehnung bestatigen. Stripe liefert HTTP 400 idempotency_error - behandeln Sie das wie ein Netzwerk-Timeout.

3DS und asynchrone Auth

Sync-Auth-p95 sollte unter 800 ms liegen, Capture-p99 unter 2 s, aber 3DS sprengt das - kalkulieren Sie 5 s fur den Challenge-Round-Trip und 1-2 s fur den Result-Callback ein. Modellieren Sie 3DS als separates Szenario, nicht als Perzentil-Bucket. Etwa 10-25% des europaischen Kartenvolumens treffen je nach Issuer und SCA-Ausnahmen auf eine Challenge; ein Test-Mix mit 0% Challenges ist nicht die Realitat. Parken Sie den VU auf der Challenge-URL fur realistische Think-Time, springen Sie nicht direkt zuruck in eine neue Auth.

Webhooks sind das zweite System

Die Auth-Response ist die halbe Geschichte. Settlement-, Refund-, Dispute-, 3DS-Completed-Events kommen async an, der Receiver muss mithalten. Zielen Sie auf 99,9% der Webhooks innerhalb von 30 s verarbeitet, harte SLO 5 min. Spielen Sie signierte Stripe- oder Adyen-Payloads mit 10x, 50x, 100x ab; beobachten Sie Queue-Depth, Signature-Verification-CPU, DB-Write-Contention. Haufiger Fehlermodus: Handler macht synchrones Upsert plus E-Mail-Versand, bei 200 Events/Sek. verhungert der Pool. Seiteneffekte in eine Queue, acken in < 200 ms.

PSP-Rate-Limits und Circuit Breaker

Stripe publiziert ~100 Read- und 100 Write-Ops/Sek. pro Account; Adyen und Checkout.com haben ihre eigenen und liefern 429 mit Retry-After deutlich bevor Sie das Ramping fertig haben. Ihr Client muss diesen Header lesen, nicht blind backoffen, und Ihr Breaker muss offnen, bevor der PSP zu shedden anfangt. Injizieren Sie 429s aus Ihrem Stub mit 5%, 20%, 50% und bestatigen Sie, dass Transaktionen queuen oder fail-fast laufen, statt Retries zu stapeln, die den Sturm verschlimmern.

Ausfuhrung auf LoadFocus

Nutzen Sie JMeter-Modus, wenn Sie bereits eine .jmx mit CSV-Testkarten und parametrisierten Idempotency-Keys haben, oder k6, wenn Sie lieber in JS scripten. Beide laufen aus 26+ Cloud-Regionen mit Tausenden VUs, Echtzeit-Auth/Capture/Webhook-Charts und CI-Hooks (GitHub Actions, GitLab, Jenkins), damit eine p95-Auth-Regression den Build brechen lasst. Starten Sie bei 10% Ihrer Peak-Black-Friday-Minute, validieren Sie dort Idempotenz und 429-Handling, dann skalieren Sie hoch.