SLA mit Zahlungsanbietern

TL; DR

Starke SLA = messbare KPIs, die an den Geschäftseffekt gebunden sind (AR, TtW, TtR, Latenz, SLA Webhook, Settlement Timeliness) sowie Prozessverpflichtungen (Eskalationen, RFO/RCA, Änderungen) und finanzielle Anreize (Service Credits). Wir überwachen unsere eigenen Metriken und Anbieterdaten, überprüfen im täglichen Zyklus und halten die fertigen Failover-Playbooks bereit.

1) Begriffe und Umfang

SLA (Service Level Agreement) - vertragliche Verpflichtungen zur Qualität der Dienstleistung.
SLO (Service Level Objective) - spezifische Zielwerte nach Metriken (Stunde/Tag/Monat).
PSP/Acquirer/APM/Bank/RTP - Anbietertypen; SLA kann sich in den Schienen unterscheiden.
Methoden/Aktionen: „deposit/auth/capture“, „refund“, „payout/withdrawal“, „webhooks“, „settlement“.

SLA-Umfang: API/Panel, Zahlungsabwicklung, Meldungen, Reporting/Register, Support, Änderungen (Change Management), Sicherheit und Compliance.

2) SLA-Metrik-Wörterbuch

2. 1 Verfügbarkeit und Leistung

API Uptime% (Minuten-/Fünf-Minuten-Granularität)

Auth/Capture Latency p95/p99 (сек)

Webhook Delivery p95 (сек) и Success % (≥99. 9%)

Settlement Timeliness: Anteil der Gefechte an der gemeldeten T + N (≥99%)

2. 2 Umwandlung und Qualität

Approval Rate (AR) nach Segmenten: 'country × BIN × method × device' (variabel als „Referenzkorridor“ mit Ausnahmen)

Soft Decline Recovery Support (Unterstützung von Retrays, Routing)

Refund Success % и TtR p95

Payout Success % и TtW p95

Duplicate/Idempotency Incidents = 0

2. 3 Zuverlässigkeit von Daten und Reporting

Report Delivery SLA: реестры `transactions/settlements/fees` до `HH:MM UTC` (≥99. 5%)

Schema Stability/Change Notice: ≥30 Tage im Voraus

Webhooks vs Reports Consistency: Diskrepanzen ≤0. 05%

2. 4 Vorfälle und Support

MTTA/MTTR (Time to Response/Recovery) nach Prioritätsstufen

RFO/RCA (Reason For Outage/Root Cause Analysis) ≤ 5 Werktage

Geplante Wartungsanzeige ≥ 7 Tage (kritisch - ≥14)

3) Empfohlene Zielwerte (Benchmarks)

(Angepasst an Methode/Markt; card/instant/APM unterscheiden sich.)

Uptime API (monatlich): ≥ 99. 95% (kritische Kontur)

Latency p95: Auth ≤ 1. 0 s, Capture ≤ 1. 5 s, Webhooks ≤ 3 s

AR-Korridor (Referenz): nicht niedriger als der Median nach Markt/BIN in Ihrer Matrix - 2-3 Prozentpunkte (Berechnungsmethode festlegen)

Refund TtR p95: Karten ≤ T + 1 BD, Instant Rails ≤ 60 s

Payout TtW p95 (instant): ≤ 120 s; (T + 1) - 100% am angegebenen Tag

Settlement Timeliness: ≥ 99% in der angegebenen T + N

Report Delivery: ≥ 99. 5% bis zur vereinbarten Zeit

4) Messung und Evidenzbasis

Merchant-Seite (Sie): API-Telemetrie (App-Level-Timer), Protokollierung 'request _ id', Webhook-Protokolle, interne' auth/capture/refund/payout '-Events, eigenes Uptime/Latency Dashboard.
Anbieterseite: Status-Seite, technische Berichte zu Vorfällen, SLA-Berichte, AR/Latency-Uploads, Settlement-Statement.
Überleitung: Tägliche Aufzeichnung Ihrer Ereignisse mit PSP-Berichten (siehe „Überleitung“...), statistische AR/Latenzkontrolle (Korridore).
Einheitliche Zeitzone: UTC, ntp Synchronisation.

5) Finanzielle Anreize und Kredite

• Die Degradation von Uptime/Latency/Webhook → einen festen Prozentsatz der Gebührenkredite.
• Das verspätete Settlement → einen Kredit in% des verspäteten Betrags/der verspäteten Provision.
• Chronische Verstöße gegen den AR-Korridor → Überprüfung des Routings/Provision/gemeinsamer Plan.
• Cap/Collar: Obergrenze für Kredite/Monat, Ausnahmen (höhere Gewalt, regulatorische Maßnahmen).
• Non-performance Exit: Kündigungsrecht bei N aufeinander folgenden Verstößen.

6) Der Prozess der Vorfälle und Eskalationen

Klassen P0-P3 (P0 - vollständige Nichtverfügbarkeit/Massenausfälle).
MTTA/MTTR-Ziele: z. B. P0 MTTA ≤ 15 Minuten, MTTR ≤ 2 Stunden.
Kanäle: Chat im Dienst/Telefon, Ticket-System, Status-Seite.
RCA (≤5 r.d.) mit einem Präventionsplan: technische, prozessuale, Routing-Maßnahmen.
Kommunikation für Sapport: Meldungsvorlagen für Spieler (Verzögerungen/Alternativen).

7) Änderungsmanagement (Change Management)

Notice ≥ 30 Tage für: API/Registry-Schema, 3DS-Parameter, Routen, Settlement-Kalender, Provisionsmodelle.
Gemeinsame Tests in Sandbox + Pilot 5-10% des Verkehrs.
Rollback-Plan und „Feature-Flag“ auf Ihrer Seite.

8) Sicherheit und Compliance im SLA

Verschlüsselung im Transit/Ruhezustand, Zertifizierung (PCI DSS/SOC), Schwachstellen und Zeitpunkt ihrer Behebung.
Sanktions-/AML-Screening, PEP, SoF/SoW - vom Anbieter unterstützte Funktionen und deren SLAs.
Data Processing Addendum (DPA), retention и DSAR.
Breach Notification: ≤ 24 Stunden bei einem Sicherheitsvorfall.

9) Überwachung und Dashboards

1. Uptime/Latency (p50/p95/p99) nach Methoden und Regionen.

2. Webhook SLA: Lieferzeit, Erfolgsquote, Prasseln/Duplikate.

3. AR/Soft Declines im Schnitt „BIN × country × provider“.

4. Refund/Payout Health: Success %, TtR/TtW p95.

5. Settlement Timeliness und Aging der unerhörten Schlachten.

6. Incident Panel: MTTA/MTTR, offene RCA, Memo Credit.

10) Datenmodell für SLA-Analysen (Minimum)

ts_utc, provider, method_code, action(auth/capture/refund/payout/webhook/settlement),
latency_ms, status, is_success,
bin, country, device_os,
webhook_delivery_sec, webhook_retry_count,
settlement_date, settlement_status,
incident_id, severity, mtta_sec, mttr_sec

11) SQL-Schnitte (Beispiel)

11. 1 Uptime/Latency

sql
SELECT
DATE_TRUNC('hour', ts_utc) AS h,
provider, method_code, action,
COUNT() FILTER (WHERE is_success)=1. 0 / COUNT() AS success_rate,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY latency_ms) AS p95_ms
FROM sla_events
WHERE action IN ('auth','capture')
GROUP BY 1,2,3,4;

11. 2 Webhook SLA

sql
SELECT
DATE_TRUNC('hour', ts_utc) h, provider,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY webhook_delivery_sec) AS wb_p95,
AVG(CASE WHEN webhook_retry_count=0 THEN 1 ELSE 0 END) AS wb_success
FROM sla_events
WHERE action='webhook'
GROUP BY 1,2;

11. 3 Settlement Timeliness

sql
SELECT settlement_date, provider,
AVG(CASE WHEN settlement_status='ON_TIME' THEN 1 ELSE 0 END) AS on_time_share
FROM sla_events
WHERE action='settlement'
GROUP BY 1,2;

12) SLA Artikelvorlage (Probe)

text
1. Availability
- Monthly API Uptime ≥ 99. 95% (5-min granularity).
- Exclusions: Planned Maintenance (≤ 2h/month, 00:00–06:00 UTC, 7d notice).

2. Performance
- Auth p95 latency ≤ 1. 0 s; Capture p95 ≤ 1. 5 s.
- Webhook delivery p95 ≤ 3 s, success ≥ 99. 9%, no duplicates.

3. Financial Operations
- Settlement T+N on-time ≥ 99%; reports delivered by 07:00 UTC D+1 (≥ 99. 5%).

4. Incident Management
- P0: MTTA ≤ 15 min, MTTR ≤ 2 h; P1: 30 min / 4 h.
- RCA within 5 business days with preventive actions.

5. Data & Changes
- 30-day advance notice for API/report schema changes.
- Backward compatibility window ≥ 60 days.

6. Remedies
- Service credits per breach (tiered), cap 25% monthly fees.
- Termination right upon 3 consecutive P0 breaches.

13) Failover-Playbooks

Degradation Auth/Latency

Aktionen: Aktivieren Sie Smart-Routing auf einer alternativen PSP, erhöhen Sie die 3DS-challenge auf anfällige BINs, Soft-Decline-Retrays mit Backoff.

Webhook-Latenz/Duplikate

Aktionen: Gehen Sie auf Polling, aktivieren Sie Idempotenz auf Handlern, frieren Sie Auto-Refands vorübergehend ein.

Siedlung verzögert sich

Aktionen: Aktivieren Sie Treasury StressRes, senken Sie vorübergehend die Sofortzahlungslimits, eskalieren Sie in PSP, Credit Memo.

Probleme mit Payouts

Aktionen: Wechseln Sie auf die Standby-Schiene (SEPA/RTP/andere PSP), aktivieren Sie „payout-lock“ für hohes Risiko, VIP-Priorisierung.

14) Anbieter- und QBR-Management

QBR (quarterly business review): AR/Latency/Webhook/Settlement/KPI-Credits, Verbesserungsplan, Roadmap fit.
Benchmarking: Vergleichstabelle der Anbieter nach SLO, Vorfällen, Kosten (Cost/GGR), Berichtsqualität.
Scorecard: 0-5 für jeden SLA-Abschnitt.

15) SLA Implementierung Checkliste

• Metriken, Formeln und Segmentierung sind definiert (UTC, p95/p99, Berechnungsgrundlagen).
• Sammlung/Dashboards und täglicher Abgleich mit PSP-Berichten eingerichtet.
• MTTA/MTTR vorgeschrieben, Eskalationen, Kontakte 24/7, Status-Seite.
• Servicekredite und Kündigungsrecht bei chronischen Beeinträchtigungen sind verankert.
• Änderungshinweis ≥ 30 Tage, Sandbox-Tests und Rollback-Plan.
• Sicherheit/Compliance: PCI/SOC, breach ≤ 24h, DPA/retention.
• Failover-Playbooks und Integration mit dem Routing-Orchestrator.
• QBR/Scorecard, regelmäßige Kalibrierung von AR-Korridoren.

16) Häufige Fehler

Unscharfe Definitionen (was als „Erfolg“ zu betrachten ist, wo p95 zu zählen ist) → Streitigkeiten und „Papier“ SLA.
Das Fehlen eigener Metriken → die Abhängigkeit von den Berichten des Anbieters.
Keine finanziellen Anreize → SLA funktioniert nicht.
Mischen von AR mit Anti-Betrugseffekt → Notieren Sie, was in der Berechnungsbasis enthalten ist.
Ignorieren Sie den Settlement-Kalender und die Zeitzone → Unstetigkeiten und Kassenbrüche.

Zusammenfassung

Ein Arbeits-SLA ist kein Satz allgemeiner Phrasen, sondern ein Vertrag, der mit Zahlen und Prozessen genäht ist: klare SLOs für Verfügbarkeit/Geschwindigkeit/Conversion/Schlussfolgerungen/Berichterstattung, die durch Ihre Telemetrie bestätigt werden, mit Memo-Credits für Verstöße und fertige Failover-Playbooks. Ein solcher SLA gleicht Erwartungen aus, verkürzt Reaktionszeiten und unterstützt ausdrücklich Monetarisierungsziele: AR höher, TtW/TtR niedriger, Cash-Latenzen selten und Vorfälle beherrschbar.