Payment-Integration unter Zeitdruck

Der Auftraggeber, ein Fahrzeugvermieter, wickelte Zahlungen über die Website (Vue.js) und eine Flutter-App (Android und iOS) gegen ein gemeinsames PHP-Backend ab. Der bestehende Zahlungsdienstleister sollte durch Revolut ersetzt werden — mit einer harten Deadline von vier Wochen von Kickoff bis Go-Live.

Die eigentliche Schwierigkeit war nicht die Integration an sich, sondern das Risiko: Ein Zahlungssystem im laufenden Betrieb auszutauschen heißt, genau an der Stelle zu operieren, an der das Unternehmen sein Geld verdient. Ein Fehler beim Cutover trifft sofort jeden Kunden im Checkout.

Statt den neuen Anbieter direkt in Clients und Checkout zu verdrahten, haben wir die Zahlungslogik serverseitig hinter einen Adapter/Orchestrator gelegt. Dieser entscheidet pro Anfrage, welcher Zahlungsanbieter und welcher Bezahl-Flow gilt — die Clients fragen nur noch „wie soll bezahlt werden“, die Antwort kommt vom Server.

Damit wurde aus dem Big-Bang eine steuerbare Umstellung: In der Übergangsphase ließ sich der Traffic prozentual zwischen altem und neuem Anbieter aufteilen, schrittweise hochfahren und bei Problemen sofort zurückrouten — ohne Deployment, ohne Downtime.

• Zentrale Routing-Logik statt doppelter Implementierung. Welcher Anbieter und welcher Bezahl-Flow gilt, entscheidet der Orchestrator an einer einzigen Stelle im Backend — nicht verteilt und hartcodiert über Web und App hinweg. Erst das machte das Traffic-Splitting und den Wechsel überhaupt steuerbar.
• Client-Anpassung an Revolut-Specifics. Web und App mussten an die Eigenheiten des neuen Anbieters angepasst werden, damit der Bezahlvorgang für den Nutzer nahtlos bleibt — welchen Flow sie rendern, steuert aber der serverseitige Adapter.
• Asynchrone Bestätigung & Idempotenz. Zahlungsbestätigungen treffen asynchron per Webhook ein; Retries dürfen niemals zu Doppelbelastungen führen.
• PCI-Scope minimiert. Kartendaten bleiben über Tokenisierung beim Zahlungsdienstleister und damit außerhalb der eigenen Systeme.

Der Wechsel ging termingerecht innerhalb der vier Wochen live — ohne eine einzige Minute Ausfall im Zahlungsfluss. Durch das prozentuale Routing ließ sich der neue Anbieter kontrolliert hochfahren, statt das gesamte Volumen auf einmal umzustellen.

Das Adapter/Orchestrator-Pattern bleibt über das Projekt hinaus wertvoll: Ein weiterer Anbieterwechsel oder ein Multi-PSP-Setup ist jetzt eine Konfigurations- und keine Umbau-Frage mehr.