Custom Stack Payments Schweiz: Build vs Buy richtig entscheiden

Mit eigener Architektur steigt der Freiheitsgrad, aber auch die Verantwortung für Stabilität, Governance und Weiterentwicklung. Ein Custom-Stack-Ansatz lohnt sich ab ca. CHF 2 Mio. Jahresumsatz oder bei spezifischen Anforderungen, die SaaS-Plattformen nicht abdecken.

Eine typische Custom-Payment-Architektur besteht aus folgenden Schichten:

1. Frontend/Checkout-Layer: Tokenisierung via PSP-SDK (Stripe Elements, Adyen Web Components). Keine Kartendaten berühren den eigenen Server.
2. Payment-Service (Backend): Zentrale Abstraktionsschicht, die PSP-Aufrufe kapselt. Hier laufen Autorisierung, Capture, Refund und Webhook-Verarbeitung.
3. Routing-Engine (optional): Entscheidet basierend auf Methode, Währung, Betrag oder Region, welcher PSP angesteuert wird.
4. Reconciliation-Layer: Gleicht PSP-Transaktionen mit internen Bestellungen und dem Buchhaltungssystem ab.
5. Observability: Logging, Metriken und Alerting über alle Schichten hinweg.

Der Payment-Service sollte als eigenständiger Microservice oder zumindest als klar abgetrenntes Modul implementiert werden – nicht als Teil der Bestelllogik.

Orchestrierungslösungen wie Spreedly, Primer oder lokale Anbieter wie Datatrans bieten eine Mittelweg-Option: weniger Entwicklungsaufwand bei trotzdem Multi-PSP-Fähigkeit.

Ein Custom-Stack Payment-Setup benötigt folgende Rollen (können in kleineren Teams kombiniert werden):

• Payment Engineer: API-Integration, Webhook-Handling, Tokenisierung
• DevOps/SRE: Deployment, Monitoring, Incident Response
• Finance/Treasury: Reconciliation, Abrechnungskontrolle, Cashflow-Management
• Compliance/Legal: PCI-DSS, Datenschutz (DSG/DSGVO), Vertragsmanagement
• Product Owner: Priorisierung von Methoden, Märkten und Features

Ohne dedizierte Payment-Kompetenz im Team steigt das Risiko von stillen Fehlern, die erst bei Reconciliation oder Kundenbeschwerden auffallen.

Ohne Observability ist ein Custom-Stack blind. Empfohlene Mindestausstattung:

• Structured Logging: Jede Transaktion mit Correlation ID loggen (z. B. via ELK-Stack oder Datadog)
• Metriken: Acceptance Rate, Latenz pro PSP, Fehlerrate nach Methode (Prometheus + Grafana oder Datadog)
• Alerting: Sofort-Alert bei Acceptance-Rate-Drop > 5 %, PSP-Timeout-Rate > 2 %, Webhook-Failure-Rate > 1 %
• Dashboards: Echtzeit-Übersicht über Transaktionsvolumen, Erfolgsrate und durchschnittliche Autorisierungszeit pro PSP

Ein robustes Failover-Pattern für Multi-PSP-Setups:

1. Health Check: Regelmässiger Ping an PSP-Status-Endpoints (alle 30 Sekunden)
2. Circuit Breaker: Nach 3 konsekutiven Fehlern den PSP für 60 Sekunden deaktivieren
3. Fallback-Routing: Automatisches Umleiten auf sekundären PSP bei Circuit-Breaker-Auslösung
4. Recovery: Nach Ablauf der Sperrzeit zunächst 10 % des Traffics auf den primären PSP leiten (Canary)
5. Benachrichtigung: Ops-Team automatisch informieren bei jedem Failover-Event

Wichtig: Failover nur für den gleichen Methodentyp implementieren. TWINT kann nicht auf Stripe fallen; Karten können von Adyen auf Stripe umgeleitet werden.

• PCI-DSS: Mindestens SAQ A (Tokenisierung via PSP). Bei eigener Kartenverarbeitung SAQ D – in der Praxis für KMU unrealistisch.
• Schweizer DSG (nDSG): Zahlungsdaten sind Personendaten. Datenbearbeitung im Ausland erfordert angemessenes Datenschutzniveau.
• Geldwäschereigesetz (GwG): Relevant, falls die Plattform als Zahlungsdienstleister agiert (z. B. bei Marketplace-Modellen).
• FINMA-Regulierung: Bei Entgegennahme von Publikumseinlagen oder bei Zahlungsdienstleistungen im regulierten Bereich.
• Vertragsrecht: PSP-Verträge auf Schweizer Recht prüfen, insbesondere Haftungsklauseln bei Ausfällen.

Strategien, um Abhängigkeit von einem einzelnen PSP zu reduzieren:

• Abstraktionsschicht: Eigene Payment-API definieren, die PSP-spezifische Aufrufe kapselt. Wechsel betrifft nur den Adapter, nicht die Geschäftslogik.
• Token-Portabilität: Network Tokens (Visa/Mastercard) statt PSP-proprietäre Tokens verwenden, wo möglich.
• Datenexport: Regelmässige Exports von Transaktionsdaten und Kunden-Token-Mappings sicherstellen.
• Vertragliche Absicherung: Ausstiegsklauseln und Daten-Rückgabepflichten im PSP-Vertrag verankern.
• Schrittweise Migration: Bei PSP-Wechsel neuen Traffic auf den neuen PSP leiten, bestehende Subscriptions/Token auf dem alten PSP auslaufen lassen.

Die beste Lösung ist selten maximal komplex. Ziel ist ein robustes, evolvierbares Setup mit klarer Ownership. Starte mit einem PSP, baue die Abstraktionsschicht von Beginn an ein und erweitere auf Multi-PSP, sobald Volumen, Ausfallrisiko oder internationale Expansion es erfordern.