Für ein Finanzprodukt ist eine Zahlung kein Punkt auf einer Funktionsliste - sie ist der Moment der Wahrheit. Hier schließt der Kunde die Transaktion ab oder bricht den Kauf ab, und hier stimmen Ihre Salden auf den Cent oder Sie suchen eine Woche lang nach der Differenz. Zahlungsintegration entscheidet deshalb über Conversion, Vertrauen und darüber, ob die Buchhaltung den Tag schließen kann.
Nach unserer Erfahrung aus Banking- und Fintech-Projekten liegt die Schwierigkeit nicht darin, das erste Gateway anzubinden, sondern darin, viele Zahlungsmethoden, viele Anbieter und viele Standards in einem vorhersehbaren Ganzen zu halten, das nicht beim ersten Timeout umfällt. Dieser Artikel handelt deshalb davon, wie Sie eine Zahlungsschicht bauen, die Jahre trägt - und wer sie bauen sollte.
Warum ist Zahlungsintegration so schwierig?
Weil eine Zahlung kein einzelnes System ist, sondern eine Kette unabhängiger Beteiligter, von denen jeder für sich ausfallen kann. Zwischen dem Klick auf „Bezahlen” und der Buchung der Mittel läuft der Ablauf über ein Gateway, einen Acquirer, ein Kartensystem oder ein Überweisungssystem, die Bank des Kunden und Ihr eigenes Backend - und jedes Glied hat ein anderes SLA und eine andere Art, Fehler zu melden.
Dazu kommt die schiere Zahl der Standards, die Sie parallel unterstützen müssen: Karten und 3-D Secure, Sofortüberweisungen, lokale Verfahren, Mobile Wallets und zunehmend Open Banking. Jeder Standard bringt eigene Regeln für Autorisierung, Erstattungen und Streitfälle mit, und die Regulierung (PSD2, SCA) legt weitere Anforderungen darauf. Zahlungsintegration ist deshalb ein Projekt am Schnittpunkt von Technologie, Finanzen und Compliance - und genau an diesem Schnittpunkt geht einem einzelnen Produktteam am häufigsten die Tiefe aus.
Was sind Payment-Gateways und PSPs, und worin unterscheiden sie sich?
Es hilft, vier Begriffe zu trennen, die in Geschäftsgesprächen verschwimmen:
- ein Payment-Gateway ist die technische Schicht, die Zahlungsdaten annimmt, verschlüsselt und weitergibt - der „Stecker” zwischen Ihrer Anwendung und der Welt der Abrechnung,
- ein Zahlungsdienstleister (PSP) gibt Ihnen nicht nur ein Gateway, sondern auch die Bündelung vieler Zahlungsmethoden, die Abrechnung und das Reporting an einer Stelle,
- ein Acquirer wickelt die tatsächliche Bewegung des Geldes zwischen Banken ab,
- ein Payment-Orchestrator sitzt über den PSPs und erlaubt es, Anbieter zu wechseln und Transaktionen zu routen, ohne die Integration neu zu schreiben.
Die Entscheidung „ein PSP oder mehrere” prägt die gesamte Architektur: Mehrere Anbieter verlangen eine Abstraktionsschicht, damit das Hinzufügen einer weiteren Zahlungsmethode nicht den Umbau von allem bedeutet - und genau diese Schicht entwerfen wir am häufigsten mit unseren Kunden.
Wie funktionieren Sofortüberweisungen und welche Standards gelten?
Sofortüberweisungen haben die Erwartungen der Kunden verändert: Geld soll in Sekunden ankommen, rund um die Uhr, auch am Wochenende. Technisch heißt das Betrieb 24/7 ohne jene Wartungsfenster, die sich das klassische Bankwesen einst erlaubte. Ein Instant-Payments-System verzeiht keine Ausfallzeit - die Transaktion geht sofort durch, oder der Kunde weiß sofort, dass etwas fehlgeschlagen ist.
In Europa ist der ordnende Standard hier SEPA Instant Credit Transfer, daneben lokale Verfahren in den einzelnen Märkten. Jedes dieser Systeme setzt eigene Limits, Nachrichtenformate (zunehmend auf Basis von ISO 20022) und Bestätigungsregeln. Unsere Engineers gehen das an, indem sie die Zahlung als asynchronen Prozess mit expliziten Status entwerfen und nicht als eine einzelne Anfrage - denn nur so lassen sich ein sofortiger Erfolg und eine verzögerte Bestätigung oder Ablehnung ehrlich abbilden.
Wie gehen Sie mit Tokenisierung und Sicherheit (PCI DSS) um?
Kartendaten sind Material, das Sie besser nicht selbst halten. Grundlage einer sicheren Integration ist deshalb, sensible Daten aus den eigenen Systemen herauszuhalten und den PCI-DSS-Geltungsbereich auf ein Minimum zu schrumpfen:
- Tokenisierung ersetzt die Kartennummer durch ein Token, das für sich genommen für einen Angreifer wertlos ist,
- Hosted Fields und Redirects sorgen dafür, dass Kartendaten Ihren Server nie berühren,
- Verschlüsselung bei Übertragung und Speicherung schützt, was Sie tatsächlich vorhalten müssen,
- Segmentierung der Umgebungen und Zugriffssteuerung verkleinern den Umfang des PCI-DSS-Audits,
- 3-D Secure und starke Kundenauthentifizierung (SCA) verlagern einen Teil des Risikos auf den Herausgeber und erfüllen die regulatorische Anforderung.
PCI-DSS-Konformität ist kein einmaliges Zertifikat, sondern eine Art, das System zu entwerfen. Wir legen die Architektur so an, dass der Fußabdruck sensibler Daten so schmal wie möglich bleibt - je weniger Kartendaten durch Ihre Systeme fließen, desto günstiger das Audit und desto kleiner die Angriffsfläche.
Wie sichern Sie Zuverlässigkeit, Fehlerbehandlung und Abstimmung?
Diesen Teil sehen Sie erst, wenn etwas schiefgeht, und genau deshalb wird er so leicht übersehen. Eine Zahlung ist verteilt, Sie müssen also davon ausgehen, dass eine Antwort verloren geht, verspätet ankommt oder zweimal ankommt. Wir entwerfen Operationen idempotent, mit einem eindeutigen Transaktionsschlüssel, sodass ein wiederholter Versuch den Kunden nie doppelt belastet und sich jeder Status aus dem Log rekonstruieren lässt.
Die andere Hälfte dieser Arbeit ist die Abstimmung: der tägliche Abgleich dessen, was Ihr System sieht, mit dem, was PSP und Bank melden. Ohne sie beginnen die Salden auseinanderzulaufen und Streitfälle häufen sich. Wir bauen den automatischen Abgleich von Transaktionen, Abweichungsberichte und einen klaren Weg für Erstattungen und Chargebacks, dazu Monitoring und Alarmierung auf der Ebene einer einzelnen Zahlungsmethode - denn der Ausfall eines Gateways soll nicht wie der Ausfall des ganzen Produkts aussehen.
Welche Kompetenzen stellen wir für ein Zahlungsprojekt bereit?
Ein festes Rezept für die Teamgestalt gibt es hier nicht - wir passen die Besetzung an Phase und Architektur an. Meist besetzen wir die Rollen, die wirklich über die Qualität der Zahlungsschicht entscheiden:
- Backend-Entwickler (Java, .NET, Node), die Integrationen mit Gateways, PSPs und Überweisungssystemen bauen,
- einen Lösungsarchitekten, der die Abstraktion über die Anbieter und das Transaktionsmodell entwirft,
- DevOps- / SRE-Spezialisten, die Zuverlässigkeit, Monitoring und 24/7-Betrieb verantworten,
- QA-Engineers, die Fehlerpfade, Timeouts, Erstattungen und Abstimmung testen,
- Security- und Compliance-Kompetenz, die PCI DSS und regulatorische Anforderungen begleitet.
Ein wichtiger Hinweis: Wir schreiben hier über Kompetenz, nicht über ein fertiges Zahlungsprodukt. Wir stellen die Menschen, die es bauen - Engineers mit Erfahrung aus Banking- und Fintech-Projekten, eingebunden in Ihr Team und Ihre Prozesse.
Wie schnell kann ein Team in ein Zahlungsprojekt einsteigen?
Tempo zählt, denn das Marktfenster für eine neue Zahlungsmethode kann kurz sein. Als Nearshore-Partner aus Polen arbeiten wir in einer nahen Zeitzone, sodass unsere Spezialisten ohne langen Anlauf in Ihren Rhythmus aus Code-Reviews und Terminen einsteigen. Den Besetzungsprozess schließen wir meist in etwa drei Wochen ab und prüfen die Kompetenzen vor dem Start - bei Zahlungen ist Erfahrung in regulierten Projekten nichts, was man auf Zuruf glaubt.
Wie machen wir das bei RITS?
Wir tun es als Nearshore-Partner aus Polen, der Kompetenzen dort ergänzt, wo sie fehlen, und einen Teil des Systems verantwortet:
- wir besetzen die Rollen Backend, Architektur, DevOps und QA rund um Ihre konkrete Zahlungsarchitektur,
- wir entwerfen die Abstraktionsschicht über Gateways und PSPs, sodass ein Anbieterwechsel keine Neuentwicklung ist,
- wir automatisieren Abstimmung, Erstattungen und Fehlerbehandlung und binden das Team in Ihre Prozesse und Werkzeuge ein.
Meist ist das Individualsoftware, gebaut von unserem Team, und dort, wo Kompetenzen schnell aufzustocken sind, Team-Verstärkung.
Wo beginnen Sie mit der Zahlungsintegration?
Beginnen Sie mit dem wichtigsten einzelnen Zahlungsweg (z. B. einer Kartenzahlung mit 3-D Secure oder einer Sofortüberweisung) und mit der Frage, wie die Abstimmung dafür aussehen wird. Das steuert Ihre Wahl des PSP, Ihr Transaktionsmodell und die Rollen, die Sie brauchen. Die Unterschiede zwischen den Kooperationsmodellen haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Sie bauen oder erneuern eine Zahlungsintegration? Sprechen wir darüber - wir finden ein Team und eine Architektur passend zu Ihrem Finanzprodukt.