Checkliste zur Payment-Gateway-Integration

Eine Payment-Integration sieht im Quickstart einfach aus – und wird kompliziert, sobald echtes Geld fließt. Die Demo nimmt eine Karte entgegen und gibt Erfolg zurück. In der Produktion warten fehlgeschlagene Abbuchungen, Dispute, Rückerstattungen, Währungs-Sonderfälle und ein Webhook, der zweimal ankommt. Diese Checkliste zeigt, was eine Demo-Integration von einer trennt, der Sie Ihren Umsatz anvertrauen können.

Kartendaten dürfen Ihren Server nie berühren

Die wichtigste Regel überhaupt: Kartendaten sollen direkt vom Browser zum Zahlungsanbieter übertragen werden – niemals über Ihr Backend. Verwenden Sie Hosted Fields oder ein Hosted Checkout, das Payment Element oder Checkout von Stripe bzw. die entsprechende Lösung Ihres Anbieters. So bleiben Sie in der niedrigsten PCI-Compliance-Stufe und eliminieren eine gesamte Klasse von Sicherheitslücken von vornherein.

Wenn Sie rohe Kartennummern speichern, stoppen Sie und überdenken Sie das Design. Es gibt dafür fast nie einen guten Grund.

Webhooks als einzige Wahrheitsquelle behandeln

Die Browser-Weiterleitung nach der Zahlung ist keine Bestätigung – der Nutzer kann den Tab schließen. Der Webhook ist das, was Ihnen tatsächlich mitteilt, dass eine Abbuchung erfolgreich war. Bauen Sie Ihre Logik darauf auf:

• Verifizieren Sie die Signatur bei jedem Webhook, damit niemand ein „Zahlung erfolgreich"-Event fälschen kann.
• Gestalten Sie Handler idempotent – Anbieter wiederholen Zustellversuche, dasselbe Event kann also mehrfach ankommen. Verwenden Sie die Event-ID als Schlüssel und ignorieren Sie Duplikate.
• Antworten Sie sofort mit einem 2xx und erledigen Sie langsame Aufgaben asynchron, sonst häufen sich durch erneute Zustellversuche Duplikate an.

Bestellungen anhand der Weiterleitung statt des Webhooks zu erfüllen ist der häufigste Weg, wie Integrationen Bestellungen verlieren oder doppelt ausführen.

Geld-Sonderfälle abdecken

Echte Zahlungen sind unordentlicher als „Abbuchung erfolgreich":

• Fehlgeschlagene und wiederholte Zahlungen – zeigen Sie klare Fehlermeldungen und ermöglichen Sie dem Nutzer, eine andere Zahlungsmethode zu verwenden.
• Rückerstattungen und Teilrückerstattungen – modellieren Sie diese von Anfang an, nicht nachträglich.
• Dispute und Chargebacks – hören Sie auf diese Webhook-Events und halten Sie Belege zur Anfechtung bereit.
• Währungen und Beträge – speichern Sie Geldbeträge als ganzzahlige Untereinheiten (Cent), niemals als Floats.

Den Strong-Auth-Flow einplanen

Regulierungen wie SCA in Europa erfordern bei vielen Zahlungen eine zusätzliche Authentifizierung. Moderne SDKs übernehmen 3-D Secure für Sie – aber nur, wenn Sie den Payment-Intent-Flow korrekt verwenden. Testen Sie, ob der Challenge-Schritt funktioniert: Eine Zahlung, die still bei SCA scheitert, wirkt für den Kunden wie ein kaputtes Checkout.

Mit den richtigen Werkzeugen testen, nicht mit echten Karten

Verwenden Sie die Test-Kartennummern des Anbieters, um Erfolg, Ablehnung, unzureichendes Guthaben und Dispute zu simulieren. Lösen Sie Test-Webhooks mit deren CLI aus. Bestätigen Sie, dass Ihre Idempotenz tatsächlich greift, indem Sie dasselbe Event zweimal senden. Entdecken Sie diese Pfade nicht erst in der Produktion.

Vor dem Go-live

• Signaturverifizierung auf allen Webhooks.
• Idempotente Handler, verschlüsselt mit der Event-ID.
• Rückerstattungs- und Dispute-Flows implementiert und getestet.
• Geldbeträge als ganzzahlige Untereinheiten gespeichert.
• Secrets in der Umgebungskonfiguration – niemals im Client-Bundle.

Bei Pykero integrieren wir Stripe und regionale Zahlungsanbieter in Produkte, bei denen ein übersehener Sonderfall direkten Umsatzverlust bedeutet. Wenn Payments auf Ihrer Roadmap stehen, sprechen wir gerne mit Ihnen.