Каскадирование на уровне провайдеров

1) Что такое каскадирование и зачем оно в iGaming

• AR↑ / DR↓: обход «капризных» эмитентов, выбор лучшего PSP для конкретного BIN/гео/метода.
• Стоимость ↓: IC++/markup ниже на части корзины, минимизация фикс-фии на micro-ticket.
• Устойчивость: failover при инцидентах, деградациях 3DS, падении коридоров выплат.
• Комплаенс: соблюдение геополитик, санкций, локальных запретов и лицензий.

2) Паттерны каскадирования

1. Последовательное (sequential)

PSP_A → (soft-decline/технический отказ) → PSP_B → PSP_C.
Используется «узкое окно» ретраев, чтобы не создавать дублей/риски многократного холда средств.

2. Параллельное (split-traffic / multi-arm)

Распределение потока (%/правила) между несколькими PSP для бенчмарка, обучения правил и снижения коррелированных отказов.

3. Sticky BIN / Sticky GEO

Запоминание «лучшего» PSP для конкретного BIN-диапазона/эмитента/гео (кэши решений с TTL).

4. Method-aware / Feature-aware

Разные провайдеры для карт, A2A, кошельков, локальных методов; учет специфики 3DS-rails, DCC/FX-поведения, токенизации.

5. Limit-aware / SLA-aware

Учет лимитов провайдеров, резервов, SLA инцидентов, cut-off и funding-задержек.

3) Решающий движок (rules-engine): входные сигналы

Карточные признаки: BIN/IIN, brand, debit/credit, коммерческая/премиум, country of issuer.
Гео и комплаенс: страна игрока (IP/GPS/SIM/KYC), санкции, лицензии.
Транзакция: сумма (minor units), валюта, канал (web/app), риск-скор.
История провайдеров: AR/DR по BIN/гео/методу за последние 15–60 мин, доля soft-decline, 3DS-pass-rate.
Стоимость: IC++/markup/фикс, FX-спред, rolling reserve %.
Ограничения: rate-limit провайдера, maintenance/инциденты, капы дневного оборота.

Выход: приоритетный список маршрутов `[(PSP, MID, require_3DS, retry_window_ms, max_attempts)]`.

4) Ретраи, идемпотентность и безопасность

Idempotency-key на попытку (user_id+order_id+nonce), общий для всех провайдеров в каскаде.
Ретрай только на soft-decline (сетевые/3DS/timeout/insufficient funds), никогда при «жестких» кодах (stolen, do not honor повторно и пр.).
Анти-дулинг: статус `AUTHORIZED`/`CAPTURED` закрывает каскад; все прочие ветви отменяются.
Окна: 1-й ретрай ≤ 2–5 сек, суммарный бюджет ≤ 15–30 сек с учетом UX.
3DS-политика: возможно step-up на второй/третьей ветке, если первая упала без 3DS.

5) 3DS, liability shift и AR

Выбор `frictionless`/`challenge` зависит от риска и PSP-поддержки (delegated auth, TRA, whitelisting).
В «жестких» гео/эмитентах — принудительный 3DS на части корзины.
Отслеживайте liability shift по провайдерам: где он чаще достигается — туда переносить рискованные BIN’ы.

6) Стоимость: IC++, blended, фикс-фии и FX

Для каждого PSP считайте effective take-rate = interchange + scheme + markup + fixed + FX-slippage.

• `Score = w1AR_live + w2(−Cost_bps) + w3(SLA_health) + w4(FX_quality) +...`
• Micro-ticket: вес фикс-фии выше → предпочтительней провайдеры с низким fix.
• Отдельно учитывайте reserve% и funding T+N — влияет на кэш-флоу.

7) Инциденты, cut-off и маршрутизация

Health-фид: статусы PSP/коридоров (auth API, 3DS ACS, payout rails).
Auto-failover: мгновенный reroute при падении AR/health ниже порога.
Cut-off-aware: перед закрытием сеттлмента избегайте partial-capture на PSP с неудобным T+N.
Throttling: чтобы не «дожечь» лимит провайдера, разносите трафик.

8) Минимальная модель данных

sql
-- Providers and MIDs
CREATE TABLE ref. providers (
provider TEXT PRIMARY KEY, model TEXT, pricing_model TEXT, fx_policy TEXT, reserve_pct NUMERIC, meta JSONB
);
CREATE TABLE ref. mids (
mid TEXT PRIMARY KEY, provider TEXT REFERENCES ref. providers, country TEXT, method TEXT, descriptor TEXT, meta JSONB
);

-- Cascade Rules/Profiles
CREATE TABLE ref. cascade_profiles (
profile_id BIGSERIAL PRIMARY KEY, name TEXT, version TEXT, enabled BOOLEAN, meta JSONB
);
CREATE TABLE ref. cascade_rules (
rule_id BIGSERIAL PRIMARY KEY, profile_id BIGINT REFERENCES ref. cascade_profiles,
geo TEXT, bin_from TEXT, bin_to TEXT, method TEXT,
provider TEXT, mid TEXT, require_3ds BOOLEAN, priority INT,
retry_on_soft JSONB, max_attempts INT, ttl_seconds INT, enabled BOOLEAN, meta JSONB
);

-- Online Provider Performance Metrics (Sliding Window)
CREATE TABLE live. provider_stats_15m (
provider TEXT, method TEXT, geo TEXT, bin6 TEXT,
approvals INT, declines INT, soft_declines INT, three_ds_pass INT,
avg_latency_ms INT, updated_at TIMESTAMP
);

-- Transactions with idempotency and selected route
CREATE TABLE payments. auth_attempts (
attempt_id BIGSERIAL PRIMARY KEY, idempotency_key TEXT, step INT,
provider TEXT, mid TEXT, require_3ds BOOLEAN, status TEXT, decline_code TEXT,
amount_minor BIGINT, currency TEXT, bin TEXT, geo TEXT,
started_at TIMESTAMP, finished_at TIMESTAMP, meta JSONB
);

9) SQL-шаблоны анализа

9.1. Онлайн-рейтинг провайдеров (AR и soft-decline share)

sql
SELECT provider, method, geo,
SUM(approvals) AS appr,
SUM(declines) AS decl,
ROUND(100. 0 SUM(approvals) / NULLIF(SUM(approvals+declines),0), 2) AS ar_pct,
ROUND(100. 0 SUM(soft_declines) / NULLIF(SUM(declines),0), 2) AS soft_share_pct
FROM live. provider_stats_15m
WHERE updated_at > now() - INTERVAL '20 minutes'
GROUP BY 1,2,3
ORDER BY ar_pct DESC, soft_share_pct DESC;

9.2. Эффект каскада на заказах (step-conversion)

sql
WITH s AS (
SELECT idempotency_key,
MAX(step) AS steps,
BOOL_OR(status='APPROVED') AS approved
FROM payments. auth_attempts
WHERE started_at BETWEEN:from AND:to
GROUP BY 1
)
SELECT steps,
COUNT() AS orders,
100. 0 SUM(approved::int) / NULLIF(COUNT(),0) AS conv_pct
FROM s
GROUP BY 1
ORDER BY 1;

9.3. Sticky BIN: лучший провайдер по BIN6

sql
SELECT bin6,
provider,
ROUND(100. 0 SUM(approved)::NUMERIC / NULLIF(COUNT(),0), 2) AS ar_pct
FROM (
SELECT LEFT(bin,6) AS bin6, provider, (status='APPROVED') AS approved
FROM payments. auth_attempts
WHERE started_at BETWEEN:from AND:to
) t
GROUP BY 1,2
QUALIFY ROW_NUMBER() OVER (PARTITION BY bin6 ORDER BY ar_pct DESC) = 1;

9.4. Стоимость по провайдеру (all-in take-rate)

sql
SELECT provider,
SUM(amount_reporting) AS volume_rep,
SUM(interchange_amt + scheme_amt + markup_amt + auth_amt + refund_amt + cb_amt + gateway_amt + fx_spread_amt) AS fees_rep,
100. 0 SUM(interchange_amt + scheme_amt + markup_amt + auth_amt + refund_amt + cb_amt + gateway_amt + fx_spread_amt)
/ NULLIF(SUM(amount_reporting),0) AS take_rate_pct
FROM finance. settlement_fees
JOIN dw. transactions_flat USING (provider)
WHERE period_start_at >=:from AND period_end_at <:to
GROUP BY 1
ORDER BY take_rate_pct;

10) KPI и дашборды

AR/DR по провайдерам и BIN/гео/методу (онлайн-окна 15/60 мин и day-to-date).
Step-conversion: доля одобрений на 1-й, 2-й, 3-й ветке.
Take-Rate % и FX-slippage по провайдеру/MID.
3DS pass-rate и доля liability shift.
Health/SLA: latency, timeouts, error rate, инциденты.
Reserve & Funding: reserve% и T+N hit-rate по провайдерам.

11) Алерты и пороги

Routing Degradation: падение AR у выбранного провайдера > Y bps за 10–30 минут.
Soft-decline surge: рост доли soft-decline → разрешить дополнительную ветку каскада.
3DS Anomaly: падение 3DS pass-rate > X% у конкретного эмитента/BIN-кластера.
Take-Rate Spike: рост all-in стоимости > порога bps.
Health Down: SLA breach (latency/error) — авто-failover.
Policy Drift: попытки без idempotency_key/без профиля каскада — P1.

12) AB-тесты и обучение правил

Multi-arm bandit или фиксированное split-traffic на новые маршруты.
Explore/Exploit: часть трафика держать на «обучение» sticky BIN.
Горизонты оценки: онлайн (15/60 мин) для инцидентов и неделя/месяц — для стоимости.
Guardrails: минимальный AR/макс take-rate для остановки эксперимента.

13) Комплаенс и «крайние» случаи

Уважать санкции/лицензии/геоблоки: некоторые провайдеры не могут обслуживать отдельные страны/методы.
Same-method / Return-to-source: каскад не должен ломать политику возвратов.
Tokenization/PCI: единая токен-схема между PSP (network tokens/ vault).
Chargebacks: логируйте, через какую ветку прошел capture — для диспутов.

14) Best practices (коротко)

1. Ретрайте только soft-decline, с единым idempotency_key.
2. Держите живую телеметрию AR/3DS/soft-decline и health провайдеров.
3. Стройте ценовую функцию маршрута (AR vs Cost vs SLA vs FX).
4. Используйте sticky BIN и AB-тесты; версионируйте профили каскада.
5. Будьте cut-off-aware: не плодите partial-capture под конец дня.
6. Имейте playbooks failover: падение PSP/ACS/коридора выплат.
7. Разделяйте данные и ответственность: кто держит PAN, кто ведет диспуты.
8. Ведите reserve-ledger по провайдерам: релизы и списания.

15) Чек-лист внедрения

• Карта провайдеров/MID, прайсинг (IC++/blended), FX-политики, резервы, T+N.
• Rules-engine: профили, правила, soft-codes, 3DS-политика, лимиты.
• Маршрутизатор: идемпотентность, ретраи, таймауты, sticky BIN-кэш.
• Телеметрия: live-метрики AR/DR/3DS/latency/health; алерты.
• Инцидент-менеджмент и failover-плейбуки.
• ETL для fees/FX/reserve; витрины take-rate и step-conversion.
• Процедуры AB-тестов и guardrails.
• Документация: комплаенс-ограничения, возвраты same-method, ответственность.

Резюме

Каскадирование на уровне провайдеров — это не «попробовать другого PSP», а дисциплина: живые метрики, умный rules-engine, строгая идемпотентность, правильная 3DS-тактика, учет стоимости/FX/резервов и готовые failover-сценарии. Такая архитектура повышает AR, снижает all-in take-rate и делает платежный контур устойчивым к сбоям и регуляторным ограничениям.