Stellen Sie sich einen Checkout vor, bei dem die Zahlung erfolgreich ist, die Aktualisierung der Bestellung jedoch fehlschlägt. Der Kunde sieht eine Fehlermeldung und versucht es erneut. Währenddessen verfügt der Support über einen Transaktionsdatensatz, das Lager hat keine bestätigte Bestellung, und die Finanzabteilung muss wissen, ob der Kunde noch etwas schuldet.

Welches System sollte diese Situation lösen? In solchen Vorfällen werden Architekturentscheidungen sichtbar: Wenn Zuständigkeiten nicht definiert sind, erhält jeder Fall eine individuell entwickelte Lösung, und diese Lösungen sammeln sich dort an, wo sie am einfachsten umzusetzen sind.

Eine Architektur sollte diese Frage beantworten, bevor die erste Transaktion in die Produktion gelangt. Andernfalls übernimmt der Zahlungscode nach und nach die Wiederherstellung von Bestellungen, Abonnementregeln, Rechnungsanpassungen und Fulfillment-Entscheidungen.

Das nachfolgend beschriebene Zuständigkeitsmodell bietet einen praktischen Ausgangspunkt: Das Gateway sollte sich auf die Kommunikation mit Zahlungsanbietern konzentrieren, Zahlungsoperationen sollten einen eigenen Verantwortungsbereich erhalten, und Entscheidungen sollten bei der Abrechnung und den Bestellungen verbleiben.

Mit vier Verantwortungsbereichen beginnen, nicht mit drei

Für dieses Design sollte das Payment Gateway vom umfassenderen Zahlungsservice unterschieden werden. Das Modell verwendet vier logische Grenzen, die das Gateway, den Zahlungsservice, die Abrechnung und die Bestellungen umfassen.

Diese Grenzen sind als Zuständigkeitsgrenzen zu verstehen, nicht als Vorgabe, vier Microservices bereitzustellen. Wenn es zum Team passt, kann mit Modulen innerhalb einer einzigen Anwendung begonnen werden. In jedem Fall sollten die Verantwortlichkeiten eindeutig festgelegt sein.

Bei der Prüfung einer Payment-Gateway-Architektur sollte das Komponentendiagramm durch eine Entscheidungskarte ergänzt werden: Wer legt den Betrag fest, wer fordert den Einzug an, wer erfasst das Ergebnis, und wer genehmigt die nächste geschäftliche Aktion?

Das Gateway nahe am Zahlungsanbieter halten

Das Gateway sollte einen engen Vertrag haben. Es sollte eine unterstützte Zahlungsoperation annehmen, sie in das Format des Zahlungsanbieters übersetzen und ein Ergebnis zurückgeben, das der Zahlungsservice interpretieren kann.

Die Isolation hat einen praktischen Grund: Zahlungsanbieter unterscheiden sich bei APIs, Authentifizierungsschemata, Feldformaten und Benachrichtigungsmechanismen. Wenn diese Unterschiede in einer Schicht gebündelt werden, bleibt der übrige Teil des Systems von den Besonderheiten der Anbieter abgeschirmt.

Zu seinen Verantwortlichkeiten können gehören:

• Die an den Zahlungsanbieter gerichtete Anfrage validieren
• Die Kommunikation mit dem Zahlungsanbieter authentifizieren
• Interne Felder in anbieterspezifische Felder übersetzen
• Eingehende Benachrichtigungen des Zahlungsanbieters überprüfen
• Antworten abbilden und dabei nützliche Details des Zahlungsanbieters erhalten

Produktwissen gehört nicht in diesen Vertrag. Das Gateway sollte keine Kenntnisse über Treuestufen, Versandberechtigung, Kulanzzeiträume von Abonnements oder Aktionspakete benötigen. Übergeben werden sollten der genehmigte Betrag, die Währung, die Zahlungsreferenz und die erforderlichen Informationen zur Zahlungsmethode – nicht die Regeln, aus denen diese Angaben entstanden sind.

Eine nützliche Prüfungsfrage lautet: Würde eine Änderung der Rückgaberichtlinie eine Änderung des Gateway-Codes erfordern? Falls ja, sollte die Grenze erneut geprüft werden.

Zahlungsoperationen einem eigenen Verantwortlichen zuweisen

Zahlungsversuche und ihre Ergebnisse gehören in den Zahlungsservice. Für jeden Versuch sollten eine interne Kennung, relevante Referenzen des Zahlungsanbieters, der angeforderte Betrag, die Währung, der Operationstyp und der Status erfasst werden. Die Historie sollte ausreichend sein, um zu untersuchen, was angefordert und was tatsächlich bestätigt wurde.

Das Modell sollte nicht auf ein einziges „bezahlt“-Flag reduziert werden. Stattdessen sollten die für die Abläufe erforderlichen Unterscheidungen definiert werden, einschließlich ungeklärter Ergebnisse. Die Kommunikation mit Zahlungsanbietern ist mitunter tatsächlich unsicher – Zeitüberschreitungen, verspätete Benachrichtigungen und Aktualisierungen in falscher Reihenfolge sind alltäglich. Das Zustandsmodell muss daher Raum für Unklarheit lassen, statt jedes Ergebnis zu Erfolg oder Misserfolg zu verdichten.

Für die folgende hypothetische Abfolge sollte ausdrücklich ein Design vorgesehen werden: Der Zahlungsservice fordert eine Autorisierung an, die Anfrage erreicht den Zahlungsanbieter, und die Antwort geht verloren. Anschließend muss die Anwendung entscheiden, was als Nächstes zu tun ist. Eine Zeitüberschreitung sollte niemals automatisch eine neue Belastung auslösen. Der Zahlungsservice muss den ursprünglichen Versuch zunächst klären oder sicher verwalten, bevor eine weitere Operation zugelassen wird.

Zwei Arten von Wiederholungsversuchen sollten ebenfalls getrennt werden:

• Technischer Wiederholungsversuch: Erneute Kommunikation für dieselbe beabsichtigte Operation unter festgelegten Sicherheitsregeln.
• Einzugswiederholung: Ein neuer Versuch, einen offenen Betrag einzuziehen.

Die Behandlung technischer Wiederholungsversuche sollte dem Design der Zahlungsintegration zugewiesen werden. Die Abrechnung bestimmt Zeitpunkt und Berechtigung eines erneuten Einzugs, während der Zahlungsservice den genehmigten Versuch ausführt.

Die Abrechnung entscheiden lassen, was geschuldet wird

Die Abrechnung ist für die Zahlungsverpflichtung zuständig: die Berechnung der Belastung, die Rechnung, Gutschriften und den verbleibenden Saldo. Bei einem Abonnementprodukt gehören Regeln für Planänderungen, anteilige Berechnungen, Abrechnungszeiträume und Einzugspläne hierher.

Die Abrechnung sollte verpflichtet sein, jede Einzugsanfrage mit einem ausdrücklichen Betrag, einer Währung und einem Verweis auf die einzuziehende Verpflichtung zu stellen. Der Zahlungsservice meldet das Ergebnis, und die Abrechnung bestimmt anschließend, wie sich dieses Ergebnis auf den Saldo auswirkt.

Betrachten wir eine hypothetische Rechnung über $100 mit einer Gutschrift von a30. Die Abrechnung sollte die verbleibenden $70 anfordern. Das Gateway sollte niemals aufgefordert werden, diese Berechnung aus Abonnementmetadaten zu rekonstruieren.

Mit zunehmender Komplexität der Preisgestaltung steigen die Risiken: Jede Berechnung, die in der falschen Komponente landet, wird zu Logik, die später gefunden, migriert und systemübergreifend abgeglichen werden muss.

Dieselbe Disziplin gilt nach einer Rückerstattung. Zahlungsdatensätze legen fest, welcher Betrag über den Zahlungsanbieter zurückgegeben wurde; die Abrechnung bestimmt, welcher Rechnung oder welcher Saldoanpassung diese Rückgabe entspricht.

Die Bestellungen entscheiden lassen, was mit dem Kauf geschieht

Entscheidungen über Fulfillment und den Lebenszyklus eines Kaufs verbleiben im Bestellbereich. Der Zahlungsservice sollte ein Zahlungsergebnis veröffentlichen und keine Anweisung an das Lager erteilen. Der Bestellablauf sollte dieses Ergebnis gemeinsam mit seinen anderen Anforderungen interpretieren. Die Interpretation des Ergebnisses ist ebenso eine geschäftliche wie eine technische Entscheidung, da dieselbe bestätigte Zahlung für unterschiedliche Fulfillment-Modelle ein unterschiedliches Gewicht haben kann.

Ein Beispiel für eine ausdrückliche Fulfillment-Regel: Die Bestellung darf erst freigegeben werden, wenn die erforderliche Zahlungsbedingung erfüllt, der Bestand reserviert und jede notwendige Prüfung abgeschlossen ist. Die Zahlungsbedingung sollte zum Geschäftsmodell passen und niemals in einem Handler für Antworten des Zahlungsanbieters verborgen werden.

Für Stornierungen gilt dieselbe Trennung. Die Bestellungen entscheiden, ob eine Stornierung zulässig ist und was mit dem Kauf geschehen soll, und fordern anschließend über den Zahlungsservice die passende Zahlungsoperation an. Ein überladenes „cancel“-Kommando sollte vermieden werden, da es die Bestellung stornieren, eine Autorisierung freigeben, eine Zahlung erstatten oder ein Abonnement beenden könnte. Jede Aktion sollte präzise benannt werden.

Rückerstattungen koordinieren, ohne einem System alle Aufgaben zu geben

Ein Rückerstattungsablauf ist ein guter Test dafür, ob die Grenzen eingehalten werden. Nehmen wir an, ein Kunde gibt einen Artikel aus einer Bestellung mit drei Artikeln zurück. Der Ablauf sollte so strukturiert sein:

• Die Retouren- oder Bestellkomponente genehmigt die Rückgabe.
• Der für die kaufmännische Berechnung zuständige Verantwortliche bestimmt den erstattungsfähigen Betrag.
• Der Zahlungsservice prüft die Zahlungshistorie und die geltenden Grenzen für Operationen.
• Das Gateway übermittelt die Anfrage an den Zahlungsanbieter.
• Der Zahlungsservice erfasst das bestätigte oder ungeklärte Ergebnis.
• Die Abrechnung und die Bestellungen aktualisieren jeweils ihre eigenen Datensätze.

Für jede Berechnung sollte es einen Verantwortlichen geben. Die Abrechnung und die Bestellungen sollten nicht unabhängig voneinander unterschiedliche Rückerstattungsbeträge berechnen und dann erwarten, dass der Zahlungsbereich zwischen ihnen auswählt.

„Rückerstattung angefordert“ sollte getrennt von „Rückerstattung bestätigt“ geführt werden. Wenn das Ergebnis des Zahlungsanbieters ungeklärt ist, sollte diese Unsicherheit erhalten bleiben und ein Untersuchungsweg bereitgestellt werden, statt den gesamten Ablauf als abgeschlossen zu markieren.

Wiederherstellung zum Bestandteil des Vertrags machen

Jede Operation über Zuständigkeitsgrenzen hinweg sollte mehr als nur die erfolgreiche Antwort spezifizieren. Dokumentiert werden sollten:

• Wie wiederholte Anfragen identifiziert werden
• Welche Komponente den maßgeblichen Zustand besitzt
• Wie verspätete oder doppelte Benachrichtigungen behandelt werden
• Was geschieht, wenn die nächste Komponente nicht verfügbar ist
• Wie Mitarbeiter ungeklärte Ergebnisse untersuchen
• Welche Aktionen sicher wiederholt werden können

Gerade für wiederholte Anfragen bieten Zahlungsanbieter häufig Idempotenzmechanismen an, die genau für diesen Zweck entwickelt wurden. Dadurch kann dieselbe Operation erneut übermittelt werden, ohne zweimal ausgeführt zu werden.

Jeder Bereich sollte eigene Kennungen erhalten, die ausdrücklich miteinander verknüpft werden: Bestell-ID, Rechnungs-ID, Zahlungs-ID, Versuchs-ID und Referenz des Zahlungsanbieters. Eine einzige Kennung sollte nicht gezwungen werden, jede Beziehung abzubilden.

Supportmitarbeiter können eine zusammengeführte Zeitleiste erhalten, aber Korrekturen sollten weiterhin den Kontrollen der jeweils verantwortlichen Komponente unterliegen. Ein praktisches Dashboard sollte nicht zur Berechtigung werden, die Zahlungshistorie zu überschreiben oder Rechnungssalden stillschweigend zu verändern.

Die Grenzen anhand geschäftlicher Änderungen testen

Vor der Freigabe des Designs sollten mehrere Änderungen durchgespielt werden:

• Einen Zahlungsanbieter hinzufügen, ohne die Preisregeln zu ändern.
• Den Zeitpunkt von Abonnement-Einzügen ändern, ohne Gateway-Adapter zu bearbeiten.
• Teilrückgaben einführen, ohne die Verarbeitung von Benachrichtigungen des Zahlungsanbieters neu zu schreiben.
• Die Fulfillment-Richtlinie ändern, ohne die Definitionen der Zahlungszustände zu verändern.

Unerwartete Änderungen über Komponentengrenzen hinweg sollten als Signale für eine Überprüfung betrachtet werden. Eine gewisse Koordination ist legitim; nicht erklärte Kopplung verdient Aufmerksamkeit.

Eine Verschiebung von Zuständigkeiten kündigt sich selten an; sie sammelt sich schrittweise durch zweckmäßige Einzeländerungen an. Werden diese Durchläufe bei der Einführung eines neuen Zahlungsanbieters, einer neuen Zahlungsmethode oder eines neuen Preismodells wiederholt, bleiben die Grenzen auch lange nach der ursprünglichen Designprüfung sichtbar.

Das Gateway sollte an der Kommunikation mit dem Zahlungsanbieter enden. Der Zahlungsservice sollte für die Ausführung von Zahlungen und die zugehörigen Nachweise zuständig sein. Die Abrechnung sollte Zahlungsverpflichtungen und Salden verantworten. Die Bestellungen sollten den Kauf und dessen Fulfillment besitzen.

Diese Verantwortlichkeiten sollten in Schnittstellen, Wiederherstellungsverfahren und der Teamverantwortung festgeschrieben werden. Ein Diagramm allein wird sie nicht voneinander getrennt halten.