Zahlungsanbindung: Was die Entwicklung richtig machen muss
Zahlungsanbindung sieht in einem Tutorial einfach aus und ist im Produktivbetrieb unerbittlich, denn jeder Fehlerfall bedeutet entweder eine Kundin, die gezahlt hat und nichts bekam, oder eine Kundin, die etwas bekam und nicht zahlte.
Dieser Leitfaden behandelt, wie der Ablauf funktioniert, die eine Entwurfsentscheidung, die die meisten Probleme verhindert, und die Fälle, die vor dem Start bewusst getestet gehören.
Wie der Ablauf tatsächlich funktioniert#
Egal welcher Anbieter, die Form ist dieselbe: Ihr Server erzeugt eine Zahlungsabsicht, die Kundin authentifiziert sich beim Zahlungsdienst, und der Dienst teilt Ihnen das Ergebnis mit — zweimal, über zwei verschiedene Wege.
- Ihr Server erzeugt eine Zahlungsabsicht mit Betrag, Währung und einem Verweis auf Ihre Bestellung.
- Die Kundin gibt Kartendaten in einem gehosteten Feld oder auf einer gehosteten Seite ein, sodass die Daten Ihren Server nie berühren.
- Es kann eine starke Authentifizierung nötig sein, die einen Schritt hinzufügt, den die Kundin abschließen muss.
- Der Dienst leitet die Kundin mit einem Ergebnis zurück auf Ihre Website.
- Unabhängig davon sendet der Dienst einen Server-zu-Server-Webhook mit dem maßgeblichen Ergebnis.
- Ihr System aktualisiert die Bestellung — aus dem Webhook, nicht aus der Weiterleitung.
- Die Abwicklung wird erst ausgelöst, nachdem die Zahlung bestätigt ist.
Die Schritte 4 und 5 sind der ganze Entwurf. Die Weiterleitung ist ein Hinweis darauf, was geschehen ist; der Webhook ist die Tatsache.
Warum Webhooks die maßgebliche Quelle sein müssen#
Der Browser der Kundin ist ein unzuverlässiger Erzähler. Er kann sich während der Weiterleitung schließen, die Verbindung verlieren oder manipuliert werden. Hängt Ihr Bestellstatus davon ab, dass die Kundin auf Ihrer Erfolgsseite ankommt, werden Sie bezahlte Bestellungen haben, die nie erfasst wurden.
- Aktualisieren Sie den Bestellzustand nur aus verifizierten Webhooks; behandeln Sie die Weiterleitung rein als Nachricht an die Nutzerin.
- Prüfen Sie Webhook-Signaturen. Ein nicht authentifizierter Endpunkt, der Bestellungen als bezahlt markiert, ist genau so schlimm, wie es klingt.
- Machen Sie die Webhook-Verarbeitung idempotent — Anbieter wiederholen, und Duplikate werden ankommen.
- Antworten Sie schnell und verarbeiten Sie asynchron; langsame Endpunkte werden wiederholt und irgendwann abgeschaltet.
- Protokollieren Sie jede Webhook-Nutzlast. Zahlungsstreitigkeiten werden mit Protokollen entschieden.
- Behandeln Sie Ereignisse in falscher Reihenfolge, denn sie können und werden so ankommen.
Die Fehlerfälle, die zu testen sind#
Jeder davon kommt im Produktivbetrieb vor. Testen Sie sie bewusst, mit den Testkarten des Anbieters, vor dem Start.
| Fall | Was passieren muss |
|---|---|
| Kundin schließt den Tab nach der Zahlung | Der Webhook schließt die Bestellung trotzdem ab; die Bestätigungsmail geht raus |
| Karte abgelehnt | Klare Meldung, Warenkorb erhalten, weiterer Versuch möglich |
| Starke Authentifizierung fehlgeschlagen | Bestellung nicht bestätigt; Kundin erfährt, was als Nächstes zu tun ist |
| Doppelter Webhook | Bestellung einmal aktualisiert, nicht zweimal; kein zweiter Versand |
| Webhook kommt vor der Weiterleitung an | Die Erfolgsseite zeigt die bereits abgeschlossene Bestellung |
| Teilerstattung | Bestellsummen und jeder Buchhaltungsexport bleiben konsistent |
| Bestand zwischen Zahlung und Versand aufgebraucht | Definierter Prozess: Erstattung, Nachlieferung oder Ersatz |
| Währungsrundung | Der belastete Betrag entspricht exakt der angezeigten Summe |
Geltungsbereich, Compliance und Geld#
Einige wenige Entscheidungen bestimmen, wie viel regulatorische Last Sie übernehmen und wie viel der Transaktion Ihnen bleibt.
- Speichern Sie nie Kartennummern. Nutzen Sie gehostete Felder oder eine gehostete Seite, damit Kartendaten Ihren Server nie erreichen; das hält den PCI-Geltungsbereich minimal.
- Verstehen Sie die Gebührenstruktur. Prozentsatz plus Fixgebühr, plus Währungsumrechnung, plus Rückbuchungsgebühren. Der genannte Prozentsatz ist nicht die Kosten.
- Prüfen Sie den Auszahlungsrhythmus. Tage bis zur Gutschrift beeinflussen die Liquidität stärker als ein kleiner Ratenunterschied.
- Bestätigen Sie, dass der Erstattungsweg vor dem Start durchgängig funktioniert, einschließlich Teilerstattungen.
- Unterstützen Sie die lokalen Zahlungsmethoden Ihres Marktes — Karten sind nicht überall der Standard, und die dominierende lokale Methode zu verpassen kostet Konversionen.
- Halten Sie einen zweiten Anbieter bereit, wenn Zahlungen kritisch sind. Ausfälle kommen vor und stoppen den Umsatz vollständig.
Häufige Fragen
Gehostete Kasse oder eingebettetes Formular?
Die gehostete Kasse ist einfacher, hält den PCI-Geltungsbereich am kleinsten und wird vom Anbieter gepflegt — für die meisten Shops ist sie der richtige Standard. Eingebettete Felder halten die Kundin auf Ihrer Domain und geben mehr Kontrolle über das Erlebnis, um den Preis von mehr Code und mehr Verantwortung. Beide halten Kartendaten von Ihrem Server fern, und das ist der Teil, auf den es ankommt.
Was passiert, wenn mein Webhook-Endpunkt ausfällt?
Anbieter wiederholen mit Backoff, typischerweise über Stunden oder Tage, sodass ein kurzer Ausfall sich von selbst erholt. Ein langer Ausfall bedeutet unbestätigte Bestellungen, überwachen Sie den Endpunkt also und lassen Sie sich bei Fehlern alarmieren. Bauen Sie außerdem einen Abgleich, der Anbietertransaktionen täglich gegen Ihre Bestellungen prüft — er fängt alles, was die Wiederholungen verpasst haben.
Muss ich starke Kundenauthentifizierung behandeln?
Wenn Sie an Kundinnen in Regionen verkaufen, die sie verlangen, ja, und moderne Anbieter-SDKs übernehmen den Großteil des Ablaufs. Was Sie behandeln müssen, ist das Ergebnis: Eine Bestellung, die auf Authentifizierung wartet, ist nicht bezahlt, und sie als bezahlt zu behandeln heißt, Ware zu versenden, für die Sie nie Geld bekommen haben.
Wie teste ich Zahlungen sicher?
Jeder Anbieter hat einen Testmodus mit Karten, die bestimmte Ergebnisse auslösen — Ablehnung, Authentifizierung nötig, Betrug. Arbeiten Sie die ganze Liste ab, einschließlich der unbequemen Fälle in der Tabelle oben. Machen Sie dann vor dem Start eine kleine echte Transaktion im Produktivbetrieb und erstatten Sie sie, denn der Testmodus beansprucht weder Ihre Live-Schlüssel noch Ihre Live-Webhook-URL.
zahlungsanbindungecommerce zahlungenwebhookspci compliancekasse entwicklungonlinezahlungen
