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 ниже, кассовые задержки — редкость, а инциденты — управляемы.