Маршрутизація платежів і failover

Маршрутизація платежів і failover

1) Навіщо це потрібно

Конверсія: правильний вибір каналу/PSP по BIN/банку/гео/ризику підвищує Auth Rate на 5-15 п.п.
Вартість: динамічний вибір по «успішність × комісія» знижує effective rate на 10-30 bps.
Стійкість: ізоляція від падінь PSP/3DS/банків; продовження прийому і виплат при часткових збоях.
Комплаєнс/RG: гнучка реалізація лімітів, гео-обмежень, самовиключень і санкційних правил прямо в маршрутизації.

2) Цільова архітектура (шари)

1. Checkout Layer - локалізація валют/методів, APM discovery, 3DS UX.
2. Payment Orchestrator (Rule Engine) - маршрутизація, smart retry, ідемпотентність, circuit-breaker.
3. Risk/KYT Engine - device/behavior, санкції/РЕР, velocity, RG-ліміти, 3DS-політика.
4. Compliance Hub - KYC, санкційні провайдери, аффордабіліті/ліміти, аудити.
5. Wallet & Ledgers - грошовий та ігровий леджери, бонус-пасиви, мультивалюта.
6. Reconciliation & Reporting - T + 0/T + 1 звірки, reason codes, податкові реєстри.
7. Observability & Security - метрики/logs/traces, алерти, RBAC, PCI-сегментація.
8. Data/ML - скоринг ризику, передбачення конверсії по банках/методах.

3) Модель даних та ідемпотентність

Payment Intent (PI): єдиний об "єкт для депозиту/виплати з полями: amount, currency, method, geo, BIN, risk_score, rg_limits, route_history, idempotency_key, status.
Ідемпотентність: кожен hop (PSP-A → PSP-B) виконується з одним idempotency_key; повтор викликів не змінює стан леджера.
Route Journal: журнал маршрутів і відповідей (PSP id, reason code, latency, 3DS-флоу, fee), потрібен для A/B і навчання моделей.

4) Алгоритм маршрутизації (еталон)

4. 1 Прийом (Acquiring)

1. Pre-score: GEO, BIN/IIN, банк-емітент, пристрій, чек, ризик-скор, RG-статус.
2. Фільтри комплаєнсу: санкції/РЕР, гео-блоки, вік/самовиключення.
3. Правила вартості/успішності: score = w1·AuthRate + w2·(−Fee) + w3·Health − penalties.
4. 3DS-політика: TRA/whitelisting/step-up за ризиком, вибір challenge vs frictionless.
5. Вибір маршруту: PSP-A → (на відмовах/помилках) → PSP-B → альтернативний метод (APM/open banking).
6. Smart Retry: зміна 3DS-режиму, MID, mcc/fallback, тайм-бекофф за reason codes (05/51/62 ≠ 91/96).
7. Post-processing: запис в Route Journal, оновлення ваг.

4. 2 Виплати (Payouts)

1. Пріоритизація: швидкість (instant/near-instant) ↔ вартість ↔ доступність.
2. KYT/AML/RG: velocity, патерни «обнал», ліміти, джерело коштів, списки винятків.
3. Маршрутизація: card-to-card OCT / RTP / Faster Payments / SEPA Instant / Pix / UPI.
4. Failover: queued payouts при недоступності банку/PSP, періодичний drain черги.
5. Confirmation: webhooks з підписом, що компенсують транзакції при розбіжностях.

5) Failover-патерни

5. 1 Circuit-breaker

Локальний (на PSP): спрацьовує при error_rate↑, latency↑, spike in declines (issuer-specific).
Глобальний (на метод): при галузевому збої (наприклад, ACS/3DS у великого банку).
Стани: Closed → Open → Half-open; тайм-аути і пороги задаються за сегментами GEO/BIN.

5. 2 Active-Active vs Active-Passive

Active-Active: паралельні PSP/методи; балансування за правилами/вартістю; найкраща RTO/RPO.
Active-Passive: економія на комісіях/підтримці, але довше RTO; годиться для вторинних GEO/методів.

5. 3 Degradation Modes

Відключення high-risk методів, переклад частини трафіку в open banking/APM.
Примусовий 3DS challenge-all для «палаючих» BIN-ів/банків.
Тимчасовий ліміт на суми/частоту (RG + ризик).

6) Робота з 3DS/SCA (динамічно)

Frictionless за замовчуванням при низькому ризику/малих чеках, challenge - при high-risk.
Винятки PSD2: LVA, MOTO, MIT - в оркестраторі, а не в додатку.
Fallback: при деградації ACS - підвищувати challenge rate або тимчасово зміщувати трафік в альтернативний метод (open banking).
KPI: challenge rate, frictionless share, post-3DS approvals.

7) Інтеграція з антифрод/KYT/RG

До маршрутизації - скоринг (device, поведінка, проксі/VPN, BIN-ризик, історія).
У маршрутизації - вибір 3DS/каналу/PSP по risk_score.
Перед виплатою - KYT/velocity/анти-арб (швидкий win→withdraw, множинні карти, зв'язані пристрої).
RG-ліміти і самовиключення - «жорсткі» стоп-правила на рівні оркестратора.

8) Спостережуваність і дані

Метрики в реальному часі: auth_rate, decline_reason mix, p95 latency, PSP health, 3DS success, payout time, queue depth.
Алерти: пороги по банках/методах, склейка із зовнішніми статус-сторінками.
A/B & Лернінг: оновлення ваг маршрутизації на основі конверсії/вартості; контрольні групи без ретраїв для калібрування.

9) KPI і цільові орієнтири

Auth Rate (карти): EU 85-92%, US 80-88%, LATAM 70-85% (без оркестрації - нижній край).
p95 latency auth API: < 3 c; webhooks: < 60 c.
Share of Instant Payouts: ≥ 70% «легких» чеків.
Routing Efficiency (конверсія ÷ вартість): + 5-10% до baseline за квартал після тюнінгу.
Circuit-break RTO: <2 хв для перемикання; RPO: 0 (ідемпотентність).
Chargeback rate: < 0. 5% по count (залежить від продукту/GEO).

10) Плейбуки інцидентів (шпаргалка)

10. 1 Масові declines по банку-емітенту

1. Підтвердити spike по BIN/issuer.
2. Відкрити локальний circuit-breaker → перерозподілити в alt-PSP/метод.
3. Збільшити challenge rate для порушених BIN, включити smart retry.
4. Комунікація в статус-канали; RCA з даними reason codes.

10. 2 Падіння 3DS/ACS

1. Детект по зростанню timeouts/» soft decline».
2. Перевести частину трафіку в open banking/APM; включити «challenge-all» там, де ACS живий.
3. Знизити ризик-чек (ліміти по сумах/швидкості), посилити моніторинг.

10. 3 Нестабільність PSP

1. Спрацював health-алерт → open breaker.
2. Перенесення в резервні PSP/MID; заборона «важких» методів з високою латентністю.
3. Відновлення через half-open з канарками (1-5% трафіку), потім gradation.

10. 4 Затримки по виплатах

1. Переклад в queued payouts з пріоритетами (VIP, ліміт суми).
2. Переїзд частини на альтернативні рейки (RTP/FPS/SEPA Instant/Pix).
3. Прозорі сповіщення гравцям; ручні ескалації> X годин.

11) SLA і договірні якоря (що вимагати від PSP)

Доступність: ≥ 99. 95% прийому; p95 latency < 3 c; webhooks < 60 c.
Інциденти: TTA ≤ 15 хв, обхідний шлях (fallback MID/APM), RCA ≤ 5 днів.
Дані: сирі reason codes, деталізація по банках, повернення токенів ≤ 10 днів при виході.
Фінанси: обмеження резервів/holdback, прозорі fees (вкл. 3DS/network tokens), cap на FX-надбавки.
Безпека: PCI-AOC, підписи webhooks, key rotation, SOC 2/ISO 27001 (бажано).

12) Регіональні патерни

EC/UK: PSD2/SCA; картки + open banking (SEPA Instant/FPS). Сильна 3DS-оркестрація, TRA і whitelisting.
США: карти + ACH; пріоритет миттєвих виплат (push-to-card, RTP). Чарджбек-контури обов'язкові.
ЛАТАМ: Pix (BR), SPEI (MX), PSE (CO); APM-heavy; фокус на девайс-ризику і документ-KYC.
Туреччина/ЦА: локальні перекази/гаманці; посилений санкційний/AML-контур, ліміти на суми/швидкість.
Азія/Індія: UPI/e-гаманці; суворі velocity-правила; маршрутизація по банках-емітентах.

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

Архітектура/дані

• Payment Intent + ідемпотентність на всі hops.
• Route Journal, сирі reason codes, webhooks з підписом.
• Поділ грошових/ігрових леджерів; компенсуючі транзакції.

Маршрутизація/правила

• Rule-engine по GEO/BIN/issuer/ризик/вартість.
• Smart retry з тайм-бекоффом і зміною 3DS/MID.
• Circuit-breakers локальні і глобальні; canary-повернення.

Ризик/комплаєнс

• Інтеграція risk/KYT/RG до і після маршрутизації.
• Санкції/РЕР, вік/самовиключення - як «жорсткі» фільтри.
• Ліміти velocity/сум; журнал рішень.

Спостережуваність/SLA

• Дашборди по Auth Rate, latency, decline mix, payout time.
• Алерти по порогах; runbooks на інциденти.
• SLA в договорі, QBR і штрафи за порушення.

14) Псевдокод стратегії (для команди)

on PaymentRequest(PI):
ensureIdempotency(PI.key)
risk = RiskEngine.score(PI)
if not ComplianceHub.pass(PI, risk): reject()

candidates = RouteCatalog.filter(PI.geo, PI.method, PI.bin, risk)
for route in rankBy(Score(AuthRate, Fee, Health, Risk), candidates):
res = PSP.call(route, PI, policy=ThreeDS.select(risk))
log(RouteJournal, route, res)
if res.approved: return approve(PI)
if isRetryable(res.reason): continue with SmartRetryAdjustments()
return decline(PI)

15) Економіка та A/B-оптимізація

Считайте effective rate = (Fees + 3DS + FX + chargeback cost − interchange rebates) / Approved Volume.
A/B: мінімум 10k транзакцій/гілку, 2-4 тижні; фіксуйте за банками/методами.
Оптимізуйте ваги AuthRate vs Fee по GEO/сезонності; контролюйте «перекіс» в дорогі, але конверсійні рейки.

16) Що важливо запам'ятати

Оркестратор + правила + дані - серце платіжної стійкості та конверсії.
Ідемпотентність/Payment Intent виключають подвійне списання і спрощують failover.
Circuit-breakers і canary-повернення забезпечують швидку стабілізацію без «гойдалок».
Договірні SLA і прозорі дані у PSP - не опція, а вимога.
Регіональні рейки (open banking, RTP, Pix/UPI) часто краще карт за швидкістю/вартістю - враховуйте в маршрутизації.