Zahlungsrouting und Failover

Zahlungsrouting und Failover

1) Warum es notwendig ist

Conversion: Die richtige Kanal-/PSP-Auswahl durch BIN/Bank/Geo/Risk erhöht die Auth Rate um 5-15 Prozentpunkte.
Kosten: Die dynamische Auswahl nach „Erfolg × Provision“ reduziert die effektive Rate um 10-30 bps.
Widerstandsfähigkeit: Isolierung gegen PSP/3DS/Bank Stürze; Fortsetzung der Annahme und Auszahlung bei Teilausfällen.
Compliance/RG: Flexible Umsetzung von Limits, Geo-Restriktionen, Selbstausschlüssen und Sanktionsregeln direkt im Routing.

2) Zielarchitektur (Schichten)

1. Checkout Layer - Lokalisierung von Währungen/Methoden, APM-Entdeckung, 3DS UX.
2. Payment Orchestrator (Rule Engine) - Routing, Smart Retry, Idempotenz, Circuit-Breaker.
3. Risiko/KYT Engine - Gerät/Verhalten, Sanktionen/RER, Velocity, RG-Limits, 3DS-Politik.
4. Compliance Hub - KYC, sanktionierte Anbieter, Affordability/Limits, Audits.
5. Wallet & Ledgers - Geld und Spiel Ledger, Bonus-Verbindlichkeiten, Multi-Währung.
6. Reconciliation & Reporting - T + 0/T + 1 Abstimmungen, Rückrufcodes, Steuerregister.
7. Observability & Security - Metriken/Logs/Traces, Alerts, RBAC, PCI-Segmentierung.
8. Data/ML - Risiko-Scoring, Konversionsvorhersage nach Banken/Methoden.

3) Datenmodell und Idempotenz

Payment Intent (PI): ein einzelnes Objekt für Einzahlung/Auszahlung mit den Feldern: amount, currency, method, geo, BIN, risk_score, rg_limits, route_history, idempotency_key, status.
Idempotenz: Jeder Hop (PSP-A → PSP-B) wird mit einem idempotency_key ausgeführt. das Wiederholen von Aufrufen ändert nicht den Status des Ledgers.
Route Journal: Routen- und Antwortprotokoll (PSP-ID, Grundcode, Latenz, 3DS-Flow, Gebühr), benötigt für A/B und Modelltraining.

4) Routing-Algorithmus (Referenz)

4. 1 Empfang (Acquiring)

1. Pre-Score: GEO, BIN/IIN, emittierende Bank, Gerät, Scheck, Risiko-Score, RG-Status.
2. Compliance-Filter: Sanktionen/RER, Geo-Blöcke, Alter/Selbstausschluss.
3. Kosten-/Erfolgsregeln: score = w1· AuthRate + w2· (− Fee) + w3· Health − penalties.
4. 3DS-Richtlinie: TRA/whitelisting/step-up auf Risiko, Auswahl Herausforderung vs frictionless.
5. Routenauswahl: PSP-A → (bei Fehlern/Fehlern) → PSP-B → alternative Methode (APM/Open Banking).
6. Smart Retry: Änderung des 3DS-Modus, MID, mcc/fallback, Time-Becoff durch Rückrufcodes (05/51/62 ≠ 91/96).
7. Nachbearbeitung: Eintrag im Route Journal, Aktualisierung der Gewichte.

4. 2 Auszahlungen (Payouts)

1. Priorisierung: Geschwindigkeit (Instant/Near-Instant) ↔ Kosten ↔ Verfügbarkeit.
2. KYT/AML/RG: Velocity, „überholte“ Muster, Limits, Geldquelle, Ausschlusslisten.
3. Routing: Card-to-Card OCT/RTP/Faster Payments/SEPA Instant/Pix/UPI.
4. Failover: queued Zahlungen, wenn Bank/PSP nicht verfügbar ist, periodische Warteschlange drain.
5. Bestätigung: Webhooks mit Signatur, die Transaktionen bei Unstimmigkeiten kompensieren.

5) Failover-Muster

5. 1 Circuit-breaker

Lokal (auf PSP): wird ausgelöst, wenn error_rate↑, latency↑, spike in declines (issuer-specific).
Global (pro Methode): bei einem Branchenfehler (z.B. ACS/3DS bei einer Großbank).
Closed → Open → Half-Open Timeouts und Schwellenwerte werden nach GEO/BIN-Segmenten festgelegt.

5. 2 Active-Active vs Active-Passive

Aktiv-Aktiv: parallele PSP/Methoden; Ausgleich nach Regeln/Kosten; die beste RTO/RPO.
Aktiv-Passiv: Einsparungen bei Provisionen/Support, aber länger als RTO; geeignet für sekundäre GEO/Methoden.

5. 3 Degradation Modes

Deaktivieren von High-Risk-Methoden, Übertragen eines Teils des Datenverkehrs auf Open Banking/APM.
Erzwungene 3DS-Challenge-All für „brennende“ BIN-s/Banken.
Zeitlimit für Beträge/Häufigkeit (RG + Risiko).

6) Arbeiten mit 3DS/SCA (dynamisch)

Frictionless standardmäßig bei geringem Risiko/kleinen Schecks, Challenge bei hohem Risiko.
Ausnahmen PSD2: LVA, MOTO, MIT - im Orchestrator, nicht in der App.
Fallback: Wenn ACS degradiert ist - erhöhen Sie die Herausforderungsrate oder verschieben Sie den Verkehr vorübergehend in eine alternative Methode (Open Banking).
KPI: challenge rate, frictionless share, post-3DS approvals.

7) Integration mit Anti-Fraud/KYT/RG

Vor dem Routing - Scoring (Gerät, Verhalten, Proxy/VPN, BIN-Risiko, Historie).
Im Routing - Auswahl von 3DS/Kanal/PSP nach risk_score.
Vor der Auszahlung - KYT/Velocity/Anti-Arb (schnelle win→withdraw, mehrere Karten, zugehörige Geräte).
RG-Limits und Selbstausschluss sind „harte“ Stop-Regeln auf Orchestrator-Ebene.

8) Beobachtbarkeit und Daten

Echtzeit-Metriken: auth_rate, decline_reason Mix, p95 Latenz, PSP-Gesundheit, 3DS-Erfolg, Auszahlungszeit, Queue-Tiefe.
Alerts: Schwellenwerte für Banken/Methoden, Kleben mit externen Statusseiten.
A/B & Lerning: Aktualisierung der Routing-Gewichte basierend auf Konversion/Kosten; Kontrollgruppen ohne Retrays für die Kalibrierung.

9) KPIs und Zielvorgaben

Auth Rate (Karten): EU 85-92%, US 80-88%, LATAM 70-85% (ohne Orchestrierung - unterer Rand).
p95 latency auth API: < 3 c; webhooks: < 60 c.
Share of Instant Payouts: ≥ 70% der „einfachen“ Schecks.
Routing Efficiency (Umwandlung ÷ Kosten): + 5-10% zur Baseline für das Quartal nach dem Tuning.
Circuit-break RTO: <2 min zum Schalten; RPO: 0 (Idempotenz).
Chargeback rate: < 0. 5% nach Anzahl (produktabhängig/GEO).

10) Playbooks der Vorfälle (Spickzettel)

10. 1 Massendeklines über die emittierende Bank

1. Spike per BIN/issuer bestätigen.
2. Öffnen Sie den lokalen Circuit-Breaker → verteilen Sie ihn an die Alt-PSP/Methode.
3. Erhöhen Sie die Challenge-Rate für betroffene BINs, aktivieren Sie Smart Retry.
4. Kommunikation in den Status-Kanälen; RCA mit Reason-Code-Daten.

10. 2 Der Fall der 3DS/ACS

1. Timeouts/“ soft decline“ Wachstumsdetail.
2. Übertragen Sie einen Teil des Datenverkehrs in Open Banking/APM; Aktivieren Sie „Challenge-All“, wenn ACS am Leben ist.
3. Reduzieren Sie den Risiko-Check (Limits für Beträge/Geschwindigkeit), verstärken Sie die Überwachung.

10. 3 PSP-Instabilität

1. Health Alert → Open Breaker.
2. Transfer zu Backup-PSPs/MIDs; Verbot „schwerer“ Methoden mit hoher Latenz.
3. Wiederherstellung durch Halböffnung mit Kanarienvögeln (1-5% des Verkehrs), dann Gradation.

10. 4 Zahlungsverzögerungen

1. Überweisung an queued payouts mit Prioritäten (VIP, Betragslimit).
2. Verlagerung des Teils auf alternative Schienen (RTP/FPS/SEPA Instant/Pix).
3. Transparente Benachrichtigungen an die Spieler; manuelle Eskalationen> X Stunden.

11) SLA und vertragliche Anker (was von der PSP zu verlangen ist)

Verfügbarkeit: ≥ 99. 95% Empfang; p95 latency < 3 c; webhooks < 60 c.
Vorfälle: TTA ≤ 15 min, Workaround (Fallback MID/APM), RCA ≤ 5 Tage.
Daten: Rohreason-Codes, Bankdetails, Token-Rückerstattung ≤ 10 Tage beim Verlassen.
Finanzen: Reservebegrenzung/Holdback, transparentes Fees (inkl. 3DS/network Token), Cap auf FX-Zertifikate.
Sicherheit: PCI-AOC, Webhooks-Signaturen, Schlüsselrotation, SOC 2/ISO 27001 (wünschenswert).

12) Regionale Muster

EG/UK: PSD2/SCA; Karten + Open Banking (SEPA Instant/FPS). Starke 3DS-Orchestrierung, TRA und Whitelisting.
USA: Karten + ACH; Sofortige Auszahlungspriorität (Push-to-Card, RTP). Charjback-Konturen sind ein Muss.
LATHAM: Pix (BR), SPEI (MX), PSE (CO); APM-heavy; Fokus auf Device-Risk und Document-KYC.
Türkei/CA: lokale Überweisungen/Wallets; Die verstärkte sankzionnyj/AML-Kontur, die Limits auf der Summe/Geschwindigkeit.
Asien/Indien: UPI/E-Wallets; strenge Velocity-Regeln; Weiterleitung zu den emittierenden Banken.

13) Checklisten zur Umsetzung

Architektur/Daten

• Zahlungsintent + Idempotenz für alle Hops.
• Route Journal, rohe Grundbuchcodes, Webhooks mit Signatur.
• Trennung von Geld/Spiel-Ledger; Kompensationstransaktionen.

Routing/Regeln

• Regelwerk GEO/BIN/issuer/Risiko/Kosten.
• Smart Retry mit Time-Becoff und 3DS/MID.
• Circuit-Breakers lokal und global; canary-Rückgabe.

Risiko/Compliance

• Integration von Risiko/KYT/RG vor und nach dem Routing.
• Sanktionen/RER, Alter/Selbstausschluss - als „harte“ Filter.
• Velocity/Summenlimits; Entscheidungsprotokoll.

Beobachtbarkeit/SLA

• Dashboards nach Auth Rate, Latenz, Decline Mix, Auszahlungszeit.
• Alerts nach Schwellenwerten; runbooks auf Vorfälle.
• SLA im Vertrag, QBR und Strafen für Verstöße.

14) Pseudocode der Strategie (für das Team)

on PaymentRequest(PI):
ensureIdempotency(PI.key)
risk = RiskEngine.score(PI)
if not ComplianceHub.pass(PI, risk): reject()

candidates = RouteCatalog.filter(PI.geo, PI.method, PI.bin, risk)
for route in rankBy(Score(AuthRate, Fee, Health, Risk), candidates):
res = PSP.call(route, PI, policy=ThreeDS.select(risk))
log(RouteJournal, route, res)
if res.approved: return approve(PI)
if isRetryable(res.reason): continue with SmartRetryAdjustments()
return decline(PI)

15) Wirtschaftlichkeit und A/B-Optimierung

Считайте effective rate = (Fees + 3DS + FX + chargeback cost − interchange rebates) / Approved Volume.
A/B: mindestens 10k Transaktionen/Zweig, 2-4 Wochen; Fixieren nach Banken/Methoden.
Optimieren Sie AuthRate vs Fee Gewichte durch GEO/Saisonalität; Steuern Sie die „Schieflage“ in teure, aber Umbauschienen.

16) Was ist wichtig zu erinnern

Der Orchestrator + Regeln + Daten sind das Herzstück von Payment Sustainability und Conversion.
Idempotence/Payment Intent eliminiert die doppelte Abschreibung und vereinfacht den Failover.
Circuit-Breaker und Canary-Return sorgen für eine schnelle Stabilisierung ohne „Swing“.
Vertragliche SLAs und transparente Daten bei der PSP sind keine Option, sondern eine Anforderung.
Regionale Schienen (Open Banking, RTP, Pix/UPI) sind oft besser als Karten in Geschwindigkeit/Kosten - berücksichtigen Sie beim Routing.