Payment-Integration
Ein Zahlungsanbieter kann mit HTTP 200 antworten und trotzdem reihenweise Zahlungen ablehnen. Eine Anfrage läuft in eine Zeitüberschreitung, und niemand weiß, ob Geld bewegt wurde. Ein Webhook kommt zweimal, einer gar nicht. Nichts davon zeigt eine Demo, alles davon zeigt die erste Monatsabrechnung. Ich baue Zahlungsstrecken, die mit diesen Fällen rechnen, statt sie zu entdecken.
Aufnahme und Zielbild als abgegrenztes Mandat von zwei bis drei Wochen, Umsetzung danach je Anbieter. Bestehende Zahlungen laufen während des Umbaus weiter.
Remote aus Deutschland. Direkt mit mir, ohne Agentur dazwischen.
Die Ausgangslage
Jeder Anbieter hat eine gute Dokumentation für den Fall, dass alles funktioniert. Der Code dafür ist an einem Tag geschrieben. Die eigentliche Arbeit liegt in den Fällen dazwischen: Die Anfrage an den Anbieter läuft in eine Zeitüberschreitung, und das eigene System weiß nicht, ob die Karte belastet wurde. Wer dann einfach wiederholt, bucht doppelt ab. Wer nicht wiederholt, verliert die Zahlung. Beides passiert in echten Systemen jeden Tag, nur selten genug, dass es im Test nie auffällt.
Der zweite Teil kommt am Monatsende. Das eigene System zählt eine Summe, die Abrechnung des Anbieters eine andere. Dazwischen liegen Zahlungen, die im Zwischenzustand hängen geblieben sind, Rückbuchungen, Erstattungen und Währungsdifferenzen. Jeder dieser Fälle ist für sich unspektakulär. In Summe entscheiden sie darüber, ob die Buchhaltung Ihren Zahlen traut.
Der dritte Teil ist die Abhängigkeit. Wer einen Anbieter direkt in den Bestellprozess schreibt, hat ihn nicht angebunden, sondern eingebaut. Dann ist der Wechsel ein Projekt, ein zweiter Anbieter für einen neuen Markt eine Umbaumaßnahme, und ein Ausfall des Anbieters ist ein Ausfall des eigenen Verkaufs. In einem Payment-Backend für über sechs Millionen Nutzer bekam deshalb jeder der neun Anbieter einen eigenen Dienst hinter einer gemeinsamen Schnittstelle. Neue Anbieter waren danach eine Sache von Tagen statt Wochen.
Kommt Ihnen etwas davon bekannt vor?Was ich mache
Der Rest des Systems kennt einen Zahlungsvorgang, keinen Anbieter. Jeder Anbieter wird ein Adapter hinter dieser Schnittstelle, mit seinen eigenen Datenmodellen, Fehlercodes und Eigenheiten. Die Besonderheiten bleiben dort, wo sie hingehören, und ein zweiter Anbieter ist ein weiterer Adapter statt einer Änderung quer durch die Anwendung.
Jeder Zahlungsvorgang bekommt einen Schlüssel, der den fachlichen Vorgang meint und nicht den einzelnen Versuch. Damit darf eine Anfrage nach einer Zeitüberschreitung gefahrlos wiederholt werden: Der zweite Aufruf liefert das Ergebnis des ersten, statt ein zweites Mal Geld zu bewegen. Was trotzdem nicht durchgeht, landet in einer eigenen Warteschlange mit Zuständigkeit statt im Nirgendwo.
Anbieter stellen Ereignisse mindestens einmal zu, nicht genau einmal, und nicht zwingend in der richtigen Reihenfolge. Die Verarbeitung prüft deshalb die Signatur, erkennt Wiederholungen am Ereignis, nimmt zuerst an und verarbeitet danach, und holt den Stand beim Anbieter nach, wenn ein Ereignis ausbleibt. Eine Bestellung hängt dann nicht mehr davon ab, dass eine einzelne HTTP-Anfrage ankommt.
Ein täglicher Abgleich zwischen eigenen Buchungen und den Berichten des Anbieters, mit einer Liste der Abweichungen und einer Regel je Abweichungsart: Zwischenzustand, Rückbuchung, Erstattung, Währungsdifferenz. Am Monatsende ist dann keine Überraschung mehr offen, sondern eine Liste bereits geklärter Fälle.
Bei Zahlungen zählt nicht die technische Fehlerquote, sondern die fachliche: wie viele begonnene Zahlungen tatsächlich ankommen, je Anbieter, Zahlungsart und Land. Ein Anbieter, der mit 200 antwortet und doppelt so oft ablehnt wie letzte Woche, fällt nur so auf. Dieselbe Kennzahl erlaubt es, bei einer Störung auf einen zweiten Anbieter umzuleiten.
Kartendaten gehen direkt vom Browser zum Anbieter, über dessen Formularfelder oder Zahlungsseite. Ihre Server sehen nur ein Token. Das hält den eigenen Prüfumfang klein und die Architektur einfach. Starke Kundenauthentifizierung wird über die Abläufe des Anbieters abgewickelt statt selbst gebaut.
Passen Ihre Zahlen am Monatsende zusammen?
Schreiben Sie mir, welche Anbieter Sie heute nutzen und wo es zuletzt geknirscht hat. Sie bekommen eine Einschätzung, bevor Sie etwas beauftragen.
Ablauf
Vier Schritte, und nach dem zweiten steht fest, was sich ändert und was es kostet. Kein Schritt setzt voraus, dass Sie den nächsten beauftragen.
Welche Anbieter, welche Zahlungsarten, welche Märkte. Wo der Anbieter im Code steckt, wie Webhooks heute verarbeitet werden und was die letzten Monatsabgleiche ergeben haben. Dazu die Fälle, die Ihrem Support am meisten Arbeit machen.
Die interne Zahlungsschnittstelle, die Idempotenzregeln, der Webhook-Weg und der Abgleich, als kurzes Dokument mit Aufwand je Schritt. Damit können Sie entscheiden, auch gegen mich.
Ein Anbieter nach dem anderen hinter die neue Schnittstelle, während bestehende Zahlungen weiterlaufen. Altsystem und neuer Weg laufen eine Zeit lang parallel, und vorher ist je Datenbereich festgelegt, welches System im Zweifel recht hat.
Der erste vollständige Monatsabgleich über den neuen Weg, die Kennzahlen je Anbieter und ein Runbook für die Fälle, die nachts passieren. Danach gehört es Ihrem Team.
Das Ergebnis
Eine Zeitüberschreitung ist ein Grund zu wiederholen, nicht ein Risiko. Der Support hört auf, Erstattungen für Fehler des eigenen Systems auszulösen.
Die Buchhaltung bekommt am Monatsende eine Liste geklärter Fälle statt einer Differenz, die jemand erklären muss.
Ein zweiter Anbieter für einen neuen Markt oder der Wechsel weg vom ersten ist ein Adapter, kein Umbau. Das stärkt auch die nächste Preisverhandlung.
Nicht ob der Server läuft, sondern wie viele Zahlungen durchgehen, je Anbieter. Ein schleichender Rückgang fällt am selben Tag auf, nicht in der Monatsauswertung.
Eingesetzte Technologien
Aus der Praxis
Eine Payment-API, die für eine andere Größenordnung gebaut war. Neun Anbieter hinter einer gemeinsamen Schnittstelle, jeder als eigener Dienst, Idempotenz je fachlichem Vorgang und ein Abgleich, der am Monatsende aufgeht. Umgebaut bei laufendem Zahlungsbetrieb.
Case Study lesenEbenfalls aus echten Projekten
Dieselbe Idee wie hinter der Zahlungsschnittstelle: eine Grenze, an der fremde Datenmodelle übersetzt werden, damit der Rest des Systems sie nie sieht.
Artikel lesen
Mit wem Sie es zu tun haben
Ich bin Tim Rutte. Über 20 Jahre Softwareentwicklung, davon vier Jahre an einer Payment-API mit neun Anbietern und über sechs Millionen Nutzern. Sie sprechen mit der Person, die Ihren Code anfasst, vom ersten Gespräch bis zur Übergabe.
Häufige Fragen
Das hängt weniger von der Technik ab als von Ihren Märkten und Zahlungsarten. Stripe ist schnell angebunden und für die meisten Produkte ein guter Anfang. Adyen lohnt sich eher bei großem Volumen und vielen Ländern. Wichtiger als die Wahl ist, dass sie revidierbar bleibt: Mit einer eigenen Zahlungsschnittstelle ist der zweite Anbieter ein Adapter, keine Entscheidung für die nächsten zehn Jahre.
Für den Anfang meist nicht. Ein zweiter lohnt sich, wenn ein Markt eine Zahlungsart verlangt, die der erste nicht kann, oder wenn ein Ausfall des Anbieters so teuer ist, dass Sie umleiten können müssen. Die Architektur sollte beides erlauben, auch wenn Sie es nie nutzen.
Erst entsteht die interne Schnittstelle, und der bisherige Anbieter wird ihr erster Adapter. Dann kommt der neue als zweiter dazu und übernimmt schrittweise, etwa nach Land oder Zahlungsart. Bestehende Abonnements und gespeicherte Zahlungsmittel sind dabei der aufwendigste Teil, weil sie zwischen Anbietern übertragen werden müssen. Das klären wir vorab mit beiden Anbietern.
Dass derselbe Aufruf zweimal dieselbe Wirkung hat wie einmal. Bei Zahlungen ist das der Unterschied zwischen einer harmlosen Wiederholung und einer doppelten Abbuchung. Die großen Anbieter unterstützen dafür Idempotenzschlüssel, aber nur, wenn das eigene System denselben Schlüssel für denselben fachlichen Vorgang wiederverwendet. Genau das fehlt in den meisten Anbindungen.
Die Architektur soll dafür sorgen, dass Kartendaten Ihre Server nie berühren: Sie gehen direkt vom Browser zum Anbieter, Ihr System sieht nur ein Token. Das hält den Prüfumfang klein. Welche Nachweise Sie konkret brauchen, klärt Ihr Anbieter oder Ihr Prüfer. Eine Rechts- oder Compliance-Beratung ist diese Leistung nicht.
Abgerechnet wird nach Aufwand, Aufnahme und Zielbild als abgegrenztes Mandat von zwei bis drei Wochen. Die Größenordnung nenne ich im Erstgespräch, sobald klar ist, wie viele Anbieter, Zahlungsarten und Märkte es gibt und wie tief der heutige Anbieter im Code steckt. Ein Anbieter in einem neuen Produkt ist eine andere Arbeit als der Wechsel weg von einem, an dem seit Jahren alles hängt.
Wenn die Standardlösung die Zahlung selbst abwickelt und der Abgleich stimmt, meist nicht. Es lohnt sich, sobald Zahlungen aus mehreren Systemen zusammenlaufen, Abonnements dazukommen oder die Buchhaltung regelmäßig Differenzen erklären muss. Dann ist die Zahlungsstrecke ein eigenes System, auch wenn sie nicht so heißt.
Weitere Leistungen
Backends für SaaS und Plattformen, die unter echter Last halten: in Go und PHP 8, event-getrieben, mit Mandantentrennung und Wiederanlauf im Entwurf.
Mehr erfahrenSaaS-Plattformen, die beim zehnten Kunden noch tragen: entschiedene Mandantentrennung, Abrechnung mit nachvollziehbarer Nutzungsmessung und eine Bruchliste für das zehnfache Volumen.
Mehr erfahrenOnlineshops für Händler, deren Standardshop an der Anbindung scheitert: Warenwirtschaft, Kasse und Filialbestände in Echtzeit, Abholung in der Filiale, Suche und Produktvorschläge.
Mehr erfahren