SLA з платіжними провайдерами

TL; DR

Сильний SLA = вимірювані KPI, прив'язані до бізнес-ефекту (AR, TtW, TtR, latency, webhook SLA, settlement timeliness), плюс процесні зобов'язання (ескалації, RFO/RCA, зміни) і фінансові стимули (service credits). Моніторимо власними метриками і даними провайдера, звіряємо в щоденному циклі і тримаємо готові плейбуки фейловера.

1) Терміни і сфера дії

SLA (Service Level Agreement) - контрактні зобов'язання за якістю сервісу.
SLO (Service Level Objective) - конкретні цільові рівні за метриками (година/день/місяць).
PSP/Acquirer/APM/Bank/RTP - типи провайдера; SLA може відрізнятися по рейках.
Методи/дії: `deposit/auth/capture`, `refund`, `payout/withdrawal`, `webhooks`, `settlement`.

Обсяг SLA: API/панель, обробка платежів, нотифікації, звітність/реєстри, підтримка, зміни (change management), безпека і комплаєнс.

2) Словник метрик SLA

2. 1 Доступність і продуктивність

API Uptime% (хвилинна/п'ятихвилинна гранулярність)

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

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

Settlement Timeliness: частка батчів, зарахованих до заявленого T + N (≥99%)

2. 2 Конверсія і якість

Approval Rate (AR) за сегментами: 'country × BIN × method × device'( варіативно, як «референсний коридор» з винятками)

Soft Decline Recovery Support (підтримка ретраїв, маршрутизації)

Refund Success % и TtR p95

Payout Success % и TtW p95

Duplicate/Idempotency Incidents = 0

2. 3 Надійність даних і звітності

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

Schema Stability / Change Notice: повідомлення за ≥30 днів

Webhooks vs Reports Consistency: розбіжності ≤0. 05%

2. 4 Інциденти та підтримка

MTTA/MTTR (час до відповіді/відновлення) за рівнями пріоритету

RFO/RCA (Reason For Outage/Root Cause Analysis) ≤ 5 робочих днів

Planned Maintenance Notice ≥ 7 днів (критичне - ≥14)

3) Рекомендовані цільові значення (орієнтири)

(Налаштовуються під метод/ринок; карткові/instant/APM розрізняються.)

Uptime API (місячний): ≥ 99. 95% (критичний контур)

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

AR Corridor (референс): не нижче медіани по ринку/BIN у вашій матриці - 2-3 п. п. (зафіксувати метод розрахунку)

Refund TtR p95: карти ≤ T + 1 б.д., instant rails ≤ 60 s

Payout TtW p95 (instant): ≤ 120 s; (T + 1) - 100% в заявлений день

Settlement Timeliness: ≥ 99% в заявлений T + N

Report Delivery: ≥ 99. 5% до обумовленого часу

4) Вимірювання та доказова база

Сторона мерчанта (ви): телеметрія API (app-level timers), логування'request _ id', логи вебхуків, внутрішні івенти'auth/capture/refund/payout', власний Uptime/Latency дашборд.
Сторона провайдера: статус-сторінка, техзвіти по інцидентах, звіти по SLA, вивантаження по AR/latency, settlement-statement.
Звірка: щоденний reconcile ваших подій зі звітами PSP (див. «Звірка»...), статистичний контроль AR/latency (коридори).
Єдина часова зона: UTC, синхронізація ntp.

5) Фінансові стимули та кредити

• Деградація Uptime/Latency/Webhook → фіксований% fee-кредитів.
• Прострочення Settlement → кредит у% від затриманої суми/комісії.
• Хронічні порушення AR-коридору → перегляд роутингу/комісії/спільний план.
• Cap/Collar: верхній ліміт кредитів/міс., виключення (форс-мажор, регуляторні дії).
• Non-performance Exit: право розірвати при N порушеннях підряд.

6) Процес інцидентів і ескалацій

Класи P0-P3 (P0 - повна недоступність/масові відмови).
MTTA/MTTR цілі: наприклад, P0 MTTA ≤ 15 хв, MTTR ≤ 2 год.
Канали: черговий чат/телефон, тікет-система, статус-сторінка.
RCA (≤5 р.д.) з планом профілактики: технічні, процесні, маршрутизаційні заходи.
Комунікація для саппорту: шаблони повідомлень для гравців (затримки/альтернативи).

7) Управління змінами (Change Management)

Notice ≥ 30 днів на: схему API/реєстрів, параметри 3DS, маршрути, settlement-календар, комісійні моделі.
Спільні тести в Sandbox + пілот 5-10% трафіку.
Rollback план і «feature-flag» на вашому боці.

8) Безпека та комплаєнс в SLA

Шифрування в транзиті/спокої, сертифікації (PCI DSS/SOC), вразливості та терміни їх усунення.
Санкційний/AML-скринінг, PEP, SoF/SoW - підтримувані провайдером функції та їх SLA.
Data Processing Addendum (DPA), retention и DSAR.
Breach Notification: ≤ 24 годин при інциденті безпеки.

9) Моніторинг і дашборди

1. Uptime/Latency (p50/p95/p99) за методами та регіонами.

2. Webhook SLA: час доставки, частка успішних, дребезг/дублікати.

3. AR/Soft Declines в розрізі'BIN × country × provider'.

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

5. Settlement Timeliness і Aging невошедших батчей.

6. Incident Panel: MTTA/MTTR, відкриті RCA, кредит-мемо.

10) Модель даних для SLA-аналітики (мінімум)

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-зрізи (приклад)

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 (зразок)

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) Плейбуки фейловера

Деградація Auth/Latency

Дії: включити smart-routing на альтернативний PSP, збільшити 3DS-challenge на вразливих BIN, ретраї soft-decline з бекоффом.

Webhook затримки/дублікати

Дії: перейти на півлінг, включити ідемпотентність на обробниках, тимчасово заморозити авто-рефанди.

Settlement затриманий

Дії: задіяти казначейський StressRes, тимчасово знизити ліміти миттєвих виплат, ескалація в PSP, кредит-мемо.

Проблеми payouts

Дії: переключити на резервну рейку (SEPA/RTP/інший PSP), включити'payout-lock'для high-risk, пріоритизація VIP.

14) Управління провайдерами та QBR

QBR (quarterly business review): AR/Latency/Webhook/Settlement/KPI-кредити, план поліпшень, дорожня карта фіч.
Benchmarking: порівняльна таблиця провайдерів по SLO, інцидентам, вартості (Cost/GGR), якості звітності.
Scorecard: 0-5 по кожному розділу SLA.

15) Чек-лист впровадження SLA

• Визначені метрики, формули і сегментація (UTC, p95/p99, бази розрахунку).
• Налаштовані збір/дашборди і щоденна звірка зі звітами PSP.
• Прописані MTTA/MTTR, ескалації, контакти 24/7, статус-сторінка.
• Закріплені service credits і право на розірвання при хронічних порушеннях.
• Change-notice ≥ 30 днів, sandbox-тести і rollback-план.
• Безпека/комплаєнс: PCI/SOC, breach ≤ 24h, DPA/retention.
• Плейбуки фейловера та інтеграція з оркестратором маршрутизації.
• QBR/scorecard, регулярне калібрування AR-коридорів.

16) Часті помилки

Розмиті визначення (що вважати «успіхом», де вважати p95) → суперечки і «паперовий» SLA.
Відсутність своїх метрик → залежність від звітів провайдера.
Немає фінансових стимулів → SLA не працює.
Змішування AR з антифрод-ефектом → фіксуйте, що входить в базу розрахунку.
Ігнор settlement-календаря і таймзон → несшивки і касові розриви.

Резюме

Робочий SLA - це не набір загальних фраз, а контракт, прошитий цифрами і процесами: чіткі SLO по доступності/швидкості/конверсії/висновками/звітності, що підтверджуються вашою телеметрією, з кредит-мемо за порушення і готовими плейбуками фейловера. Такий SLA вирівнює очікування, скорочує час реакції і прямо підтримує цілі монетизації: AR вище, TtW/TtR нижче, касові затримки - рідкість, а інциденти - керовані.