SLA z dostawcami płatności

TL; DR

Silny SLA = wymierne KPI związane z wpływem działalności gospodarczej (AR, TtW, TtR, latency, webhook SLA, timing), plus zobowiązania procesowe (eskalacje, RFO/RCA, zmiany) i zachęty finansowe (kredyty usługowe). Monitorujemy za pomocą własnych mierników i danych dostawcy, sprawdzamy w codziennym cyklu i utrzymujemy gotowe feilover playbooks.

1) Warunki i zakres

SLA (Umowa o poziomie usług) - zobowiązania umowne dotyczące jakości usług.
SLO (Cel poziomu usług) - szczegółowe poziomy docelowe według mierników (godzina/dzień/miesiąc).
PSP/Acquirer/APM/Bank/RTP - typy dostawców; SLA może się różnić na szyny.
Metody/działania: "deposit/auth/capture", "refund", "payout/within", "webhooks'," settlement ".

Zakres SLA: API/panel, przetwarzanie płatności, powiadomienia, raportowanie/rejestry, wsparcie, zmiany (zarządzanie zmianami), bezpieczeństwo i zgodność.

2) Słownik SLA Metrics

2. 1 Dostępność i wydajność

API Uptime% (ziarninistość minutowa/pięciominutowa)

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

Webhook Delivery p95 (сев) а Sukces% (≥ 99. 9%)

Czas rozliczenia: odsetek partii włączonych do zadeklarowanego T + N (≥ 99%)

2. 2 Konwersja i jakość

Wskaźnik homologacji (AR) według segmentu: „kraj × BIN × metoda × drink”

Wsparcie odzyskiwania miękkiego spadku

Zwrot Sukces% а TtR p95

Payout Sukces% а TtW p95

Duplikat/Idempotencja Incydenty = 0

2. 3 Wiarygodność danych i sprawozdawczość

Raport Dostawa SLA: реестра „transakcje/rozliczenia/opłaty” ма „HH: MM UTC” (≥ 99. 5%)

Powiadomienie o stabilności/zmianie schematu - ≥ 30 dni wypowiedzenia

Haki vs Raporty Spójność: ≤ 0 rozbieżności. 05%

2. 4 Incydenty i wsparcie

MTTA/MTTR według poziomu priorytetowego

RFO/RCA (przyczyna przerwy/analiza przyczyny głównej) ≤ 5 dni roboczych

Planowane powiadomienie o utrzymaniu ≥ 7 dni (krytyczne - ≥ 14)

3) Zalecane wartości docelowe (wartości odniesienia)

(Dostosowane do metody/rynku; card/instant/APM różnią się.)

Uptime API (miesięcznie): ≥ 99. 95% (obwód krytyczny)

Opóźnienie p95: Auth ≤ 1. 0 s, wychwytywanie ≤ 1. 5 s, Webhooks ≤ 3 s

Korytarz AR (odniesienie): nie niższa niż mediana według rynku/BIN w macierzy - 2-3 punkty procentowe (ustalić metodę obliczeniową)

Zwrot TtR p95: karty ≤ T + 1 pb, szyny błyskawiczne ≤ 60 s

Wypłata TtW p95 (natychmiastowa): ≤ 120 s; (T + 1) - 100% w zadeklarowanym dniu

Terminowość rozliczeń: ≥ 99% w zadeklarowanym T + N

Dostawa raportu: ≥ 99. 5% przed uzgodnionym czasem

4) Podstawa pomiaru i dowodu

Strona handlowca (ty): telemetria API (timery poziomu aplikacji), logowanie 'quest _ id', dzienniki haków internetowych, zdarzenia wewnętrzne' auth/capture/refund/payout ', własna tablica rozdzielcza Uptime/Latency.
Strona dostawcy: strona statusu, raporty techniczne dotyczące incydentów, raporty dotyczące SLA, przesyłki na AR/latency, rozliczenie.
Pojednanie: codzienne uzgodnienie zdarzeń z raportami PSP (patrz „Pojednanie”...), kontrola statystyczna AR/latency (korytarze).
Ujednolicona strefa czasowa: UTC, synchronizacja ntp.

5) Zachęty finansowe i pożyczki

• Uptime/Latency/Webhook degradacja → stałe% kredyty opłaty.
• Opóźnienie rozliczenia → pożyczka w% opóźnionej kwoty/prowizji.
• Przewlekłe naruszenia korytarza AR → routing/przegląd komisji/wspólny plan.
• Cap/Collar: górny limit kredytów/miesiąc, wyjątki (siła wyższa, działania regulacyjne).
• Wyjście z niewykonania: prawo do wypowiedzenia w przypadku kolejnych naruszeń N.

6) Proces incydentu i eskalacji

klasy P0-P3 (P0 - całkowita niedostępność/awarie masy).
Cele MTTA/MTTR: na przykład P0 MTTA ≤ 15 min, MTTR ≤ 2 h.
Kanały: czat dyżurny/telefon, system biletów, strona stanu.
RCA (≤ 5 dni roboczych) z planem zapobiegania: środki techniczne, procesowe, routingowe.
Komunikacja dla wsparcia: szablony wiadomości dla graczy (opóźnienia/alternatywy).

7) Zarządzanie zmianami

Ogłoszenie ≥ 30 dni dla: systemu API/rejestru, parametrów 3DS, tras, kalendarza rozliczeń, modeli prowizji.
Testy połączeń w piaskownicy + pilot 5-10% ruchu.
Plan rollback i „feature-flag” po twojej stronie.

8) Bezpieczeństwo i zgodność w SLA

Szyfrowanie w tranzycie/odpoczynku, certyfikacja (PCI DSS/SOC), luki i czas ich eliminacji.
Sankcja/AML screening, PEP, SoF/SoW - funkcje obsługiwane przez dostawcę i ich SLA.
Data Processing Addendum (DPA), retencja - DSAR.
Powiadomienie o naruszeniu: ≤ 24 godziny na wypadek bezpieczeństwa.

9) Monitoring i deski rozdzielcze

1. Czas uptime/opóźnienie (p50/p95/p99) według metody i regionu.

2. Webhook SLA: czas dostawy, wskaźnik sukcesu, bounce/duplikat.

3. AR/Soft Declines w kontekście „BIN × country × provider”.

4. Zwrot/wypłata Zdrowie: Sukces%, TtR/TtW p95.

5. Harmonogram rozliczeń i starzenie się nieosiągających partii.

6. Panel incydentu: MTTA/MTTR, open RCA, notatka kredytowa.

10) Model danych dla SLA (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) plasterki SQL (przykład)

11. 1 Czas uptime/opóźnienie

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 Terminowość rozliczeń

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) szablon pozycji SLA (próbka)

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) Feilover playbooks

Degradacja Auth/Latency

Działania: umożliwienie inteligentnego routingu na alternatywnym PSP, zwiększenie 3DS-challenge na wrażliwych BIN, przekaźniki miękkiego spadku z backoff.

Opóźnienia/duplikaty w systemie Webhook

Akcje: przełączyć się do sondażu, włączyć idempotencję na obsługujących, tymczasowo zamrozić auto-refands.

Opóźnione rozliczenie

Działania: użyj Skarbu Państwa, tymczasowo obniżyć natychmiastowe limity płatności, eskalację do PSP, notatkę kredytową.

Kwestie wypłat

Działania: przejście na koleję w trybie gotowości (SEPA/RTP/inne PSP), umożliwienie „blokady wypłat” dla priorytetyzacji VIP o wysokim ryzyku.

14) Zarządzanie dostawcą i QBR

QBR (kwartalny przegląd działalności): AR/Latency/Webhook/Rozliczenie/KPI kredyty, plan poprawy, funkcja mapy drogowej.
Analiza porównawcza: tabela porównawcza dostawców według SLO, incydenty, koszt (Cost/GGR), jakość sprawozdawczości.
Karta wyników: 0-5 na każdej sekcji SLA.

15) Lista kontrolna wdrażania SLA

• Zdefiniowano metryki, wzory i segmentację (UTC, p95/p99, podstawy obliczeniowe).
• Zbiory/deski rozdzielcze i codzienne uzgadnianie z raportami PSP są skonfigurowane.
• Zalecane MTTA/MTTR, eskalacje, kontakty 24/7, strona stanu.
• Kredyty serwisowe i prawo do zakończenia choroby przewlekłej są zapisane.
• Powiadomienie o zmianie ≥ 30 dni, testy piaskownicy i plan zwrotu.
• Bezpieczeństwo/Zgodność: PCI/SOC, naruszenie ≤ 24h, DPA/zatrzymanie.
• Feilover playbooks i integracja z orkiestrą routingu.
• QBR/scorecard, regularna kalibracja korytarzy AR.

16) Częste błędy

Niewyraźne definicje (co jest uważane za „sukces”, gdzie uważa się p95) → spory i „papier” SLA.
Brak własnych wskaźników → zależność od raportów dostawcy.
Nie ma zachęty finansowej → SLA nie działa.
Mieszanie AR z efektem zwalczania nadużyć → zapisać, co jest zawarte w podstawie obliczeń.
Ignorowanie kalendarza rozliczeń i harmonogramów → niedopasowania i luk pieniężnych.

Podsumowanie

Roboczy SLA to nie zestaw ogólnych zwrotów, ale kontrakt zszyty liczbami i procesami: jasne SLO na temat dostępności/szybkości/konwersji/wniosków/raportowania, potwierdzone przez telemetrię, z notatką kredytową za naruszenia i gotowe feilover playbooks. Taki SLA wyrównuje oczekiwania, skraca czas reakcji i bezpośrednio wspiera cele monetyzacji: AR jest wyższa, TtW/TtR jest niższa, opóźnienia w skrzynce są rzadkie, a incydenty są zarządzalne.