Payment System Architecture: Wie sie über Resilienz und Souveränität entscheidet

Die Kernfrage jeder Payment Architecture

Im Kern geht es bei jeder Payment Architecture um eine einfache Frage: Laufen Zahlungen über ein extern vorgegebenes, festgelegtes Setup oder kann mein Unternehmen aktiv steuern, wie sie laufen?

Die Payment Architecture definiert, wie diese unterschiedlichen Bausteine zusammenspielen – und wie autonom ein Unternehmen Anbieter, Datenflüsse und Reporting steuern kann.

Zum Hintergrund

Im Rahmen ihrer Services bieten Zahlungsdienstleister Händlern oft komplett aufgesetzte, vorgegebene Payment-Strukturen und -Prozesse, die schnell und einfach integriert werden können. Dieser Service hat aber einen Preis: Die Händler sind an diese Dienstleister und deren Strukturen gebunden, haben deutlich weniger Datenhoheit und müssen sich nach den vorgegebenen Prozessen und Abläufen richten.

Checkout / POS

Payment Gateway

Payment Layer (optional)

Payment Orchestrator (optional)

Payment Service Provider / PSP

Acquirer

Fraud- & Risk-Management

Prüfung, Verbuchung, Analyse & Reporting

Initiierung

Validierung und Tokenisierung

Autorisierung / Issuing

Capture / Settlement

Payment Reconciliation / Zahlungsabgleich

Zuverlässigkeit

Zahlungen dürfen nicht «verloren gehen». Auch bei Fehlern, Timeouts oder Teilausfällen muss das Payment System stabil bleiben, damit Zahlungsstatus und Transaktionsdaten nachvollziehbar aufgelöst werden können.

Zu den entsprechenden Massnahmen zählen schnelle Fehlererkennung, Fallbacks wie alternatives Routing von Transaktionen im Falle von Ausfällen und stabile Prozesse im operativen Alltag. Am POS z.B. beginnt das schon mit einer zuverlässigen Kommunikation zwischen POS-Terminal und Kassensystem.

Konsistenz

Im Kontext von Zahlungsprozessen bezeichnet Konsistenz die Nachvollziehbarkeit einer Transaktion. Das bedeutet, dass doppelte Buchungen, fehlende Transaktionen oder ausgeglichene Zahlungen vermieden werden müssen.

In diesem Zusammenhang spielt das Konzept Idempotenz eine entscheidende Rolle: Wird eine Zahlungsanfrage mehrfach gesendet, stellt das System über eindeutige Schlüssel sicher, dass sie nur einmal ausgeführt und verbucht wird.

Sicherheit

Payment Architecture muss sensible Zahlungs- und Kontodaten schützen und gleichzeitig Betrugsrisiken reduzieren. Für den Schutz der Zahlungs- und Kontodaten sind z.B. Tokenisierung und PCI-DSS relevant, während 3D Secure, SCA/PSD2 und Fraud-Prüfung dem Schutz vor betrügerischen Aktivitäten dienen.

Spezielle Fraud-Risk-Engines können Transaktionen in Echtzeit prüfen. Eine gesunde Balance bleibt hier jedoch wichtig: Zu wenig Schutz erhöht das Risiko, zu strenge Fraud- oder Authentifizierungsregeln können legitime Zahlungen erschweren und die Conversion reduzieren.

Skalierbarkeit

Payment-Systeme müssen auch bei einem plötzlich stark erhöhten Transaktionsvolumen stabil funktionieren – etwa in Peak-Phasen wie «Black Friday» oder während des Jahresendgeschäfts.

Skalierbarkeit wird zudem relevant, wenn Unternehmen in neue Märkte expandieren, zusätzliche Zahlungsmethoden integrieren oder mehrere Anbieter parallel steuern.

Grundvoraussetzung ist eine Architektur- und Datenbank-Strategie, die Wachstum ermöglicht, ohne dass die Kerninfrastruktur jedes Mal neu aufgebaut werden muss.

Souveränität und Steuerbarkeit

Gerade vor dem Hintergrund wachsender geopolitischer Spannungen spielt der Wunsch nach möglichst grosser Unabhängigkeit für Unternehmen eine immer wichtigere Rolle.

Die Abhängigkeit von einem einzelnen Anbieter birgt aber nicht nur das Risiko von Ausfällen – mit den damit einhergehenden Umsatzeinbussen. Auch im Sinne der Kostenoptimierung und der Systemflexibilität ist eine höhere Souveränität inzwischen für viele Unternehmen zu einem wichtigen strategischen Ziel bei der Gestaltung ihrer Payment Systeme geworden.

Der Kern: Steuerbarkeit statt Abhängigkeit

Anstatt sich darauf zu verlassen, dass Payment «einfach funktioniert», verfolgen immer mehr Unternehmen das Ziel, dass Payment aktiv für sie «arbeitet». Grundvoraussetzung ist eine aktive Steuerung über souverän verwaltete Payment Layer.

Sie ermöglichen es, Daten auszuwerten, Ausfälle abzufedern, Anbieter zu vergleichen, Kosten zu optimieren und neue Anforderungen schneller umzusetzen.

Welche Folgen hat die Abhängigkeit von Dienstleistern?

Die Abhängigkeit von einzelnen Anbietern kann langfristig Risiken schaffen: Ein Anbieterwechsel kann technisch aufwändig oder teuer werden, Konditionen bzw. Gebühren können sich schwieriger verhandeln lassen und die Roadmap des Anbieters kann eigene Weiterentwicklungsmöglichkeiten begrenzen.

Ohne eine aktive Fallback-Strategie kann ein einzelner Anbieter zudem zur kritischen Achilles-Sehne werden – insbesondere dann, wenn Zahlungsflüsse, Datenzugriff und Reporting vollständig über diesen Anbieter laufen.

Wie schafft man Souveränität im Payment Kontext?

Wer die eigenen Zahlungsprozesse optimieren will, darf entscheidende Komponenten und Schritte des Transaktionsflusses nicht von externen Dienstleistern bestimmen lassen.

Die Angebote der «All-in-One» Payment-Modelle reduzieren zwar deutlich die Komplexität – allerdings auf Kosten der Steuerbarkeit und Souveränität!
Wer in Sachen Payment souverän sein will, muss …

• die eigenen Zahlungsdaten selbständig verwalten, anstatt sich blind auf den Zahlungsdienstleister zu verlassen.
• die Anbieter im Prozess austauschbar halten (z.B. durch eine Multi-Provider-Strategie).

Der nächste Schritt ist, durch Orchestrierungsschichten eine eigene Steuerungslogik aufzubauen, durch die Zahlungsflüsse intelligent im Hintergrund gesteuert werden können.
Das Thema Souveränität beginnt übrigens schon am POS: Eine Middleware für die universelle Anbindung unterschiedlicher POS-Terminals kann den Wechsel eines Anbieters und eine Multi-Acquiring-Strategie enorm erleichtern.

Einfachheit vs. Kontrolle

Verlässt man sich auf einen Single-Provider-Ansatz, profitiert man von schneller Einrichtung und einem vergleichsweise einfachen Betrieb. Dafür liegen Datenhoheit und Steuerung komplett beim Anbieter.

Komplexere Architekturen mit Layern, Routing oder Orchestrierung erfordern mehr Planung und Koordination. Langfristig ermöglichen sie jedoch mehr Kontrolle über Anbieterwahl, Datenflüsse, Kosten und Weiterentwicklung.

Schnelligkeit vs. Optimierung

Schnell live zu gehen, kann in frühen Phasen oder bei einfachen Setups sinnvoll sein. Problematisch wird es dann, wenn kurzfristige Geschwindigkeit langfristige Optimierungen erschwert.

Wer Payment Architecture langfristig und nachhaltig gestalten will, sollte deshalb früh prüfen, welche technischen und reporting-seitigen Abhängigkeiten durch direkte Anbieterintegration, fehlende Datenzugriffe oder starre Schnittstellen entstehen.

Outsourcing vs. Eigensteuerung

Externe Anbieter können Komplexität reduzieren und operative Arbeit abnehmen. Dies ist sinnvoll, solange zentrale Schnittstellen und Steuerungsmöglichkeiten nicht vollständig ausgelagert werden.

Die Herausforderung liegt in der Balance: Standardprozesse können extern abgebildet werden. Der direkte Zugriff auf die Zahlungsdaten und die Möglichkeit zum Anbieterwechsel sollten jedoch nicht vollständig aus dem eigenen Einflussbereich verschwinden.

Standard-Reports vs. individuelle Analysen

Wer nur auf die Reports des PSP angewiesen ist, sieht nur, was der Anbieter zeigt. Wer die Datenhoheit über die Zahlungsdaten behält, kann individuelle Analysen vornehmen – und damit wertvolle Einblicke als Basis für die weitere Optimierung bekommen.

Spezielle Analysetools – wie das Payment-Analytics-Center in der Matchbox-Software von treibauf – ermöglichen präzisere Einblicke in Kostenstrukturen, Zahlungsmix und Gebührenentwicklung. Eine solide Basis für bessere strategische Entscheidungen!

Zentrale Architektur: ein Anbieter

Bei einer zentralen Architektur bündelt ein Anbieter, häufig ein Payment Service Provider, komplett den Grossteil der Zahlungsabwicklung. Das macht den Einstieg einfacher und reduziert den initialen Integrationsaufwand.

Der Nachteil: Abhängigkeiten können später Kosten verursachen, etwa bei Preissteigerungen oder Anbieterwechseln. Auch Optimierungsmöglichkeiten, Flexibilität und Expansion in neue Märkte können stark begrenzt sein, wenn Schnittstellen, Daten und Steuerungslogik direkt an einen Anbieter gebunden sind.

Dezentrale / modulare Architektur

Bei einer dezentralen oder modularen Architektur übernehmen mehrere Anbieter unterschiedliche Funktionen. Das schafft mehr Flexibilität, verteilt Risiken und kann die Performance verbessern – etwa bei Zahlungsmethoden, Märkten, Konditionen oder Ausfallsicherheit.

Dafür steigt die Komplexität. Mehr Anbieter bedeuten mehr Schnittstellen, komplexeres Management, einen initial höheren Integrationsaufwand sowie höhere Anforderungen an Reporting, Governance und Reconciliation.