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

1) Що таке каскадування і навіщо воно в iGaming

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

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

1. Послідовне (sequential)

(soft-decline/технічна відмова) .
Використовується «вузьке вікно» ретраїв, щоб не створювати дублів/ризики багаторазового холда коштів.

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, don't 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 і робить платіжний контур стійким до збоїв і регуляторних обмежень.