Bei 10.000 Bestellungen pro Monat läuft der Checkout. Bei 100.000 bricht er ein. Das ist keine Randbeobachtung, sondern ein Muster, das sich durch die Payment-Infrastruktur fast jedes schnell wachsenden Händlers zieht. Die Systeme, die ein Unternehmen an die erste Umsatzmillion tragen, versagen leise beim nächsten Wachstumsschritt — und die meisten Teams merken es erst, wenn der Ausfall bereits Geld kostet.
Wer Payment-Skalierung aus Betreibersicht kennt, weiß: Das Problem ist selten der Zahlungsdienstleister selbst. Es sind die Zwischenschichten. Ein Plugin, das Retry-Logik für fehlgeschlagene Transaktionen übernimmt. Ein Webhook-Handler, der 200 statt 2.000 Events pro Minute verarbeitet. Eine Reconciliation, die bei kleinen Volumina manuell nachvollziehbar bleibt und ab einer gewissen Größenordnung stillschweigend falsche Werte produziert.
Was genau bricht, wenn der Erfolg kommt?
Drei Fehlerquellen dominieren. Erstens: hartkodierte Limits. Timeouts, Rate-Limits, Batch-Größen — sie werden für ein frühes Volumen gewählt und nie überprüft. Zweitens: fehlende Idempotenz. Wird ein Webhook doppelt zugestellt, entsteht eine doppelte Buchung oder ein Geister-Refund. Drittens: Monitoring, das nur auf Ausfälle, nicht auf Drift achtet. Ein System kann monatelang laufen und dabei langsam falsch werden.
Für Shopbetreiber ist das unangenehm, weil die Symptome im Dashboard oft unsichtbar bleiben. Die Conversion-Rate sinkt um 0,4 Prozentpunkte, der Umsatz pro Besucher ebenfalls — kein Alarm, keine Meldung. Erst wenn Retouren, Chargebacks oder Support-Tickets auffallen, ist der Fehler längst etabliert. Genau hier liegt der eigentliche Nachrichtenwert dieser Beobachtung aus dem Payment-Segment: Die Erfolgskurve und die Fehlerkurve verlaufen anfangs parallel und deckungsgleich.
Wie testen Händler ihre eigene Infrastruktur realistisch?
Der wirksamste Gegencheck ist ein Lasttest mit realistischem Zahlungsverhalten, nicht mit synthetischen Bestellungen. Also: Wiederholte Autorisierungen desselben Kunden, abgebrochene Checkouts, Teilzahlungen, Refunds innerhalb von Minuten. Wer sein System nur mit sauberen Testbestellungen prüft, misst nichts.
Ein zweiter Hebel ist die Trennung von Zahlungsabwicklung und Geschäftslogik. Läuft die Retry-Kette im Shop-System selbst — etwa über eine Checkout-Extension in Shopware oder eine WooCommerce-Erweiterung —, skaliert sie nur so weit wie der Webserver. Payment-Provider wie Adyen, Stripe oder Mollie bieten eigene Retry- und Tokenisierungs-Layer, die genau diesen Engpass umgehen. Händler, die das auslagern, verlieren selten Conversion, weil die Wiederholung im Hintergrund läuft, statt den Kunden erneut durch den Zahlungsvorgang zu schicken.
Die Systeme, die dich zu 10.000 Kunden gebracht haben, sind dieselben, die bei 100.000 leise aufgeben.
Praktisch bedeutet das: ein Monitoring, das nicht nur Ausfälle zählt, sondern Fehlerraten pro Provider, pro Zahlungsmethode und pro Stunde. Die meisten Händler über 1 Mio. Euro Jahresumsatz haben das nicht. Sie haben ein Dashboard, das zeigt, ob Payment funktioniert — nicht, wie gut es funktioniert. Genau diese Lücke kostet bei jedem Wachstumsschritt Geld, meist bevor irgendwer im Team es bemerkt.
Wer skalieren will, sollte weniger Geld in neue Kanäle stecken und mehr in die eigene Abwicklung. Der nächste Wachstumsschritt kommt schneller als das nächste Refactoring.