Маршрутизация платежей и 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, санкции/PEP, 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. Фильтры комплаенса: санкции/PEP, гео-блоки, возраст/самоисключение.
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) Региональные паттерны

ЕС/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 до и после маршрутизации.
• Санкции/PEP, возраст/самоисключение — как «жесткие» фильтры.
• Лимиты 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) часто лучше карт по скорости/стоимости — учитывайте в маршрутизации.