Das Problem
Die Deutsche Payment stellt registrierten Händlern als B2B-SaaS-Angebot eine integrierte Plattform zur Verfügung, mit der sie individuelle Zahlungskanäle für ihre Endkunden – konkret für die Käufer ihrer Waren – einrichten können.
Die Deutsche Payment hat beschlossen, ihren Kunden ein neues Reporting-Tool an die Hand zu geben, mit dem sie die Nutzung ihrer Plattform überwachen und fundierter entscheiden können, welche Zahlungslösungen zum Einsatz kommen sollen. Die Grundidee war, eine aggregierte Ansicht aller Zahlungen zu bieten, die registrierte Händler von jedem an die Plattform angeschlossenen Zahlungsgateway erhalten. kreuzwerker stand der Deutsche Payment bei diesem Greenfield-Projekt zur Seite und entwickelte das Reporting-Tool als Cloud-Service – von null an.
Die Lösung
Um eine resiliente Lösung zu realisieren und das Leistungspotenzial der von AWS bereitgestellten Dienste voll auszuschöpfen, empfahl kreuzwerker eine Multi-Service-Architektur, in der die von den Zahlungs-Gateways übermittelten Ereignisse standardisiert und in einer relationalen Datenbank gespeichert werden, damit sie später von einem Aggregationsdienst abgerufen werden können. Dies läuft konkret wie folgt ab:
Die Payment Gateways generieren auf der Plattform der Deutsche Payment Ereignisse, die von einem API-Gateway verarbeitet werden. Die Ereignisse werden über SQS zu AWS-Lambda-Funktionen geleitet, die jeweils die Aufgabe haben, das Ereignis nach Maßgabe des Ereignis-Typs und des entsprechenden Händlers zu verarbeiten. Die AWS-Lambda-Funktionen verarbeiten die Ereignisse und wandeln sie in das Datenmodell um, das für die aggregierte Ansicht benötigt wird. Die Lambdas leiten diese transformierten Ereignisse an eine andere SQS-Warteschlange weiter, die dazu dient, die Anfragen zum Verfassen dieser Ereignisse zu drosseln. Ein auf Fargate in ECS bereitgestellter Microservice nimmt diese Ereignisse auf und speist sie in die Aurora-Datenbank ein.
Im letzten Schritt stellt ein weiterer Microservice in ECS Fargate die APIs für den Zahlungsaggregator bereit, der mit Daten aus der Aurora-Datenbank versorgt wird. Die ursprüngliche Architektur wurde von kreuzwerker in Form eines PoC bereitgestellt und optimiert, damit die Architektur in Staging- und Produktionsumgebungen eingesetzt werden kann.
Das Diagramm unten zeigt die komplette Architektur, die mit dem Ziel maximaler Skalierbarkeit, Ausfallsicherheit und Zuverlässigkeit entwickelt wurde:
Das Ergebnis
Das Reporting-Tool und die dazugehörige Infrastruktur wurden unter Einhaltung des Projektzeitplans entwickelt, getestet und erfolgreich zum Einsatz gebracht. Schlüsselfunktionen wie das Onboarding von Händlern, die Verarbeitung von Zahlungsereignissen (Filterung nach Händlern) und die Rechnungserstellung für jeden Mandanten werden derzeit in der Produktion eingesetzt.
In Zusammenarbeit mit dem kreuzwerker-Entwicklungsteam hat die Deutsche Payment außerdem ihre bestehenden manuellen Bereitstellungs- und Testprozesse durch die Integration einer CI/CD-Pipeline auf Basis von GitHub Actions verbessert und automatisiert. Dieser Service dient auch als Grundlage für die Bereitstellung zusätzlicher Dienste für Kunden – zum Beispiel ein Empfehlungssystem, das auf maschinellem Lernen basiert.
Fazit
Die Deutsche Payment, ein Anbieter von SaaS-Zahlungslösungen, ging eine Partnerschaft mit kreuzwerker ein und richtete auf ihrer Plattform einen neuen Dienst ein, um die Anwendung für die Nutzer angenehmer zu gestalten. Dafür wurden native AWS-Cloud-Technologien wie ECS Fargate, Lambda, API-Gateway, SQS und weitere eingesetzt, um eine schnelle Entwicklung und Skalierung zu ermöglichen. Durch Steigerung der Cloud-Agilität konnte die Deutsche Payment mit Unterstützung von kreuzwerker innerhalb weniger Wochen einen neuen Service für die aggregierte Ansicht von Zahlungsvorgängen in Betrieb nehmen.