Плейбук інцидентів в платежах

TL; DR

Інцидент у платежах - це керована операція: швидко класифікуй → стабілізуй UX (фейловер/деградація) → збережи гроші (ідемпотентність/блок-правил) → прозоро комунікуй → віднови → зафіксуй RCA. Головні SLO: MTTA, MTTR, TtW/TtR, AR, Webhook p95, нульова терпимість до double charge/refund.

1) Матриця серйозності (Severity & Impact)

Тригери: альберти SLA/казначейства/звірки, піки саппорту, моніторинг AR/latency/webhooks.

2) Ролі і канал зв'язку

Incident Commander (IC) - власник таймлайну і рішень.
Payments Tech Lead - маршрутизація, ідемпотентність, фіч-прапори.
Treasury Lead - ліквідність, prefunding, stress-резерви.
Risk/AML - санкції, блок-правила, SoF/SoW.
Comms Manager - шаблони для саппорту/партнерів, статус-апдейти.
Recon/Finance - звірка, сторно/журнали, оцінки втрат.

Штаб: #payments -incident-warroom (чат), Zoom-бридж + живий документ таймлайну (UTC).

3) Універсальний цикл (for any incident)

1. Detect & Triage → підтвердити метрики/охоплення, присвоїти Sev.
2. Stabilize UX → фейловер роутингу, деградація фіч, заморожування небезпечних автомобілів.
3. Money Safety → включити ідемпотентність/блоки (refund/payout), зафіксувати журнали.
4. Communicate → внутрішній апдейт (15/30/60 хв), зовнішні повідомлення (статус/ЕТА/обхідні шляхи).
5. Recover → покроковий відкат/відкриття, верифікувати SLO.
6. Reconcile → порівняти леджер/PSP/банк, розрахувати financial impact.
7. RCA (≤5 р.д.) → корінь, дії, запобігачі, завдання.

4) Типові сценарії і Runbook'і

4. 1 Auth Drop/Latency Spike (карти/А2А)

Симптоми: AR↓, soft declines↑, p95 auth>1–2 s.

• Smart-routing: PSP_A→PSP_B, збільшити 3DS-challenge на вразливих BIN.
• Обмежити ретраї (backoff + джиттер), захистити ідемпотентність'auth _ key'.
• Сегмент-toggle: high-risk в «строгий» сценарій; знизити high-ticket ліміти.
• Комунікації: «замітка про деградацію», рекомендувати альтернативний метод.
• Відновлення: поетапне повернення частки трафіку, контроль AR в розрізі BIN × GEO.

4. 2 Webhooks Delay / Duplicate

Симптоми: p95> 3-5 c, пропуски capture/refund/payout, дублікати.

• Перейти на polling; посилити TTL ідемпотентності.
• Заморозити авто-рефанди і ризиковані авто-виплати.
• Анти-дубль: store-once по `idempotency_key/provider_txid`.
• Провести catch-up обробку; звірка з реєстрами PSP.
• Відновлення: включити webhooks, порівняти консистентність зі звітами.

4. 3 Payout Fail / TtW Degradation

Симптоми: Success%↓, TtW p95↑, повернення/тайм-аути.

• Фейловер на резервну рейку (RTP/SEPA/інший PSP).
• Treasury: prefund top-up payout-пулу, StressRes активація.
• Payout-lock для high-risk, пріоритизація VIP.
• Комунікації: ETA і альтернативи, прозорість статусів в особистому кабінеті.

4. 4 Refund Errors / Double Refund Risk

Симптоми: Refund error rate↑, спірні/дублюючі повернення.

• Глобальний refund-freeze на авто-маршруті, тільки ручний з правами.
• Жорстка ідемпотентність'payment _ id + amount + reason'; row-lock на залишок.
• Повторна звірка по PSP report; сторно дублів в леджері, кейси в DLQ.
• Комунікації:模板 для карт (T + 1-T + 5 б.д.), instant - до 60 с.

4. 5 Settlement Delay / PSP Batch Mismatch

Симптоми: D + N не зарахувалося, diff в сумах/fee.

• Treasury: включити StressRes, обмежити миттєві виплати.
• Recon: позначити батч «SUSPENSE», підняти тікет PSP, запросити statement.
• FX/Fees: прийняти тимчасову «істину» (policy) або чекати коригування.
• Комунікації: Q&A для саппорту (безпека засобів, терміни врегулювання).

4. 6 Crypto On/Off-Ramp Degradation

Симптоми: TtH↑, slippage↑, дефіцит ліквідності майданчика.

• SOR→alternativnyy CEX/OTC, зменшити розмір лота (TWAP).
• Переклад входять в стейбл/фіат, ліміт depeg-експозиції.
• Kill-switch при розбіжності оракула> ліміту bps.

4. 7 Voucher/Wallet Anomalies

Симптоми: Invalid PIN spike, velocity, гео-миск.

• Ліміти/кулдаун, прив'язка redeem до пристрою, payout-lock + turnover.
• Запит чеків/SoF, поповнення блок-листів (email/device/ASN/retailer).

5) Чек-листи дій

5. 1 П'ять перших хвилин (P0/P1)

• Призначити IC, відкрити war-room.
• Зафіксувати Sev, охоплення, старт таймлайну (UTC).
• Включити безпечні фіч-прапори (ідемпотентність, freeze потрібних автопроцесів).
• Запустити фейловер/деградацію функцій.
• Перший внутрішній апдейт (контекст, заходи, слід. ETA).

5. 2 Перед закриттям інциденту

• Відновлені SLO (AR/latency/webhooks/TtW/TtR).
• Проведена звірка (internal↔PSP↔bank), немає «чорних дір».
• Фінансовий impact оцінений, сторно/журнали оформлені.
• Зовнішній апдейт/пост в статус-каналі.
• Призначений власник RCA і завдання запобігання.

6) Моніторинг, алерти та дашборди

• 'AR_gross↓> 3 п. п. (до p7 медіани)'→ P1/P0 за охопленням.
• `Auth p95>1. 5 s / Webhook p95>5 s / Capture Success<98%` → P1.
• `Payout TtW p95> SLO` или `Success%<99%` → P1.
• `Refund Error>0. 3%` или `Double Refund>0` → P0.
• `Settlement on-time<99%` / `Report Delivery SLA breach` → P1.

1. Фанел Attempt→Auth→Capture (порівняння до лінії базису).

2. Heatmap AR по BIN×GEO×PSP.

3. Webhook p50/p95, дублікати, дребезг.

4. Payout/Refund Health (Success%, TtW/TtR).

5. Treasury: баланс L0, prefund, StressRes.

6. Recon: Mismatch Rate, Aging DLQ.

7) Комунікації (шаблони)

• "Зараз спостерігаються затримки підтвердження платежів і висновків для частини користувачів. Платежі зберігаються в безпеці. Рекомендуємо альтернативний метод X. оновлення через 30 хвилин"

8) Звірка і гроші (після стабілізації)

Прогнати авто-звірку: provider_txid/idem_key/amount/time-bucket.
Виділити DLQ: orphan/duplicate/amount mismatch/fee drift.
Оформити сторно/корекції в леджері, перерахувати Cost/GGR і Fraud Loss.
Казначейство: закрити тимчасові заходи (StressRes, payout-lock), ребаланс пулів.

9) Шаблон RCA (Root Cause Analysis)

Контекст: дата/час (UTC), Sev, охоплення, метрики.
Симптоми: що побачили (графіки/скріншоти).
Причина: корінь (тех/процеси/контрагент).
Що спрацювало/не спрацювало: фейловер, фіч-прапори, комунікації.
Фінансовий ефект: списання/невиплати/комісії/кредити SLA.

• Тих: ліміти, ідемпотентність, ретраї, тести.
• Процеси: оновлення плейбука, QBR з PSP, SLA зміни.
• Дедлайни і власники завдань.

10) Автоматизація та інтеграції

Feature-flag platform: миттєвий роутинг/деградація по країні/BIN/методу.
Runbook-бот: команды `/failover PSP_A→B`, `/freeze refunds`, `/enable polling`.
Anomaly-детектор: статистичне відхилення AR/latency зі знанням сезонності.
Post-incident macros: автоматичне відкриття RCA-шаблону, збір логів/графіків, чек-лист звірки.

11) Drill-календар і UAT

Щомісяця: «Auth drop» drill (15 хв від детекту до фейловера).
Квартально: «Webhook outage» + «Refund double-strike» (ідемпотентність).
Раз на півроку: «Settlement delay + Treasury stress» (StressRes).
UAT-пакет: тест-кейси ідемпотентності, фейловера, звірки, комунікацій.

12) Метрики успіху плейбука (операційні KPI)

MTTA/MTTR: медіана/п95 за P0/P1.
Percent auto-failover within 10 min.
Incidents preventing double charge/refund (=100%).
Post-incident recon complete ≤ D+1.
Service credits recovered / month (по SLA).
User impact minutes (сума за інцидентами).

13) Часті помилки і як їх уникнути

Пізня активація фейловера (немає автоматичних порогів).
Відсутність «freeze» на авто-рефанди при дребеззі webhooks.
Немає row-lock/версіонування → partial refund> залишку.
Комунікації без фактів/ЕТА → ескалація в саппорт.
Немає зв'язки з казначейством → TtP/TtW виходять з SLO.
Пропуск звірки → «чорні діри» у виручці.

14) Додатки (посилальні блоки всередині вашої wiki)

SLA з платіжними провайдерами - пороги алертів і кредити.
Звірка платежів і звітів PSP - процедури recon/DLQ.
Казначейство: ліквідність і резерви - StressRes/Prefunding.
KPI платіжного контуру - формули AR/TtW/TtR/Refund Health.
Часткові і повні рефанди - ідемпотентність і політика.

Резюме

Робочий плейбук - це сценарні runbook'і + автоматизація + дисципліна пост-мортемів. Він скорочує MTTR, захищає гроші (ідемпотентність/звірка/казначейство), мінімізує користувацький збиток і системно покращує відносини з PSP по SLA. Результат - AR вище, TtW/TtR в коридорах, нуль дублів, передбачувані флоу грошей.