Субмерчанты и каскады

1) Понятийная база

Субмерчант — юридическое лицо, принимающее платежи через главного мерчанта/провайдера (PayFac/платформа/оператор). Денежные потоки идут на мастер-MID/счет платформы, далее платформа выплачивает субмерчанту (split/sweep).

Каскад (cascading) — стратегия последовательного или параллельного роутинга транзакции через несколько PSP/эквайреров/MID по правилам (GEO, BIN, тариф, риск, нагрузка) для повышения авторизаций и снижения стоимости.

PayFac-модель — платформа как «мини-эквайрер»: онбординг субмерчанта (KYB/PCI), присвоение суб-MID, единые правила KYC/AML и диспутов, централизованные settlement и выплаты.

2) Где и когда это нужно в iGaming

Мультибренд/white-label: один оператор, десятки суббрендов/студий → проще вести MIDs/дескрипторы и отчетность.
Маркетплейс контента: платформа — MoR/PayFac, студии — субмерчанты (revshare, сплиты).
Высокий риск/гео-микс: каскады по PSP уменьшают отказы, шоки по инцидентам и стоимость платежей.
Локальные методы/коридоры выплат: нужен выбор провайдера на лету и fallback.

3) Ответственность и роли

4) Иерархия MIDs и дескрипторов

Master MID (платформа)

└─ Sub-MID(ы) по брендам/гео/методам

└─ Routing Profiles (PSP1→PSP2… каскад)

• Отдельные дескрипторы на суб-MID: меньше диспутов.
• Разделяйте карты/A2A/локальные методы по суб-MID для чистой аналитики и контроля резерва.
• Версионируйте routing-профили (v1/v2) для A/B.

5) Каскады: как строить

5.1. Решение «на лету»

При авторизации: выбрать маршрут по правилам (GEO, BIN/IIN, brand, карта debit/credit, риск-класс, лимит PSP, текущий AR/DR, тариф/FX, SLA инцидентов).

5.2. Типы каскадов

Последовательный: PSP_A → (soft decline) → PSP_B → PSP_C.
Параллельный (split-traffic): % трафика на разные PSP для бенчмаркинга и декорреляции.
Sticky BIN: закрепление успешного BIN-пула за лучшим PSP.

5.3. Ограничения

Считать idempotency (чтобы не задвоить capture).
Согласовать с PSP повторные попытки (retry window, soft codes).
Учитывать 3DS-политику и liability shift на каждом маршруте.

6) Settlement, T+N, резервы и сплиты

У каждого PSP/эквайрера свой cut-off/T+N и свой rolling reserve.
Платформа агрегирует поступления на уровне суб-MID и ведет reserve-ledger с release-календарем.
Выплаты субмерчантам: net of fees & reserve + их доля (revshare/CPA) по отчетному периоду.
Поддерживайте сплиты по транзакции (platform/studio/affiliate/tax) или постатейно по периоду.

7) Антифрод, 3DS и лимиты на уровне субмерчанта

Разные скоринг-пороговые для A/B/C классов рынков.
3DS-правила по BIN/гео/чеку (обяз./мягко/step-up).
Velocity-лимиты (внесения/выводы, попытки карт) и caps по субмерчанту.
«Серые» субмерчанты: строже лимиты, только белые методы и отложенные выплаты.

8) Тарифы и take-rate

Считайте effective take-rate по субмерчанту: PSP fees (interchange/scheme/markup/fixed) + FX slippage + доля платформы + резерв-эффект.
Используйте IC++ и BIN-routing, чтобы снижать blended-стоимость в каскаде.

9) Данные и минимальная модель

sql
-- Directories
CREATE TABLE ref. submerchants (
sub_id    BIGSERIAL PRIMARY KEY,
legal_name  TEXT, brand TEXT, country TEXT, risk_class TEXT, status TEXT,
created_at TIMESTAMP, meta JSONB
);

CREATE TABLE ref. routing_profiles (
profile_id BIGSERIAL PRIMARY KEY,
name TEXT, version TEXT, enabled BOOLEAN, meta JSONB
);

CREATE TABLE ref. routing_rules (
rule_id BIGSERIAL PRIMARY KEY,
profile_id BIGINT REFERENCES ref. routing_profiles,
method TEXT, geo TEXT, bin_from TEXT, bin_to TEXT,
psp TEXT, mid TEXT, require_3ds BOOLEAN,
priority INT, soft_codes JSONB, enabled BOOLEAN, meta JSONB
);

-- Transactions linked to a sub-merchant and a route
CREATE TABLE payments. transactions (
id BIGSERIAL PRIMARY KEY,
sub_id BIGINT REFERENCES ref. submerchants,
profile_id BIGINT, rule_id BIGINT,
provider TEXT, mid TEXT, method TEXT, brand TEXT,
status TEXT, decline_code TEXT,
amount_original NUMERIC(18,6), currency_original TEXT,
amount_reporting NUMERIC(18,6), reporting_currency TEXT,
fx_reference_rate NUMERIC(18,10), fx_effective_rate NUMERIC(18,10),
authorized_at TIMESTAMP, captured_at TIMESTAMP, settled_at TIMESTAMP, funded_at TIMESTAMP,
user_id BIGINT, country_player TEXT, bin TEXT, three_ds_used BOOLEAN,
idempotency_key TEXT UNIQUE, meta JSONB
);

-- Phi and reserves for sub-merchant/provider/period
CREATE TABLE finance. settlement_fees (
sub_id BIGINT, provider TEXT, mid TEXT,
period_start TIMESTAMP, period_end TIMESTAMP,
interchange_amt NUMERIC, scheme_amt NUMERIC, markup_amt NUMERIC,
auth_amt NUMERIC, refund_amt NUMERIC, cb_amt NUMERIC, gateway_amt NUMERIC,
fx_spread_amt NUMERIC, reserve_delta NUMERIC, total_fees NUMERIC, currency TEXT
);

CREATE TABLE finance. reserve_ledger (
id BIGSERIAL PRIMARY KEY,
sub_id BIGINT, provider TEXT, mid TEXT,
hold_date DATE, release_due_date DATE,
hold_amount NUMERIC, released_amount NUMERIC,
cb_consumed NUMERIC, fines_consumed NUMERIC,
status TEXT, meta JSONB
);

-- Submerchant payments
CREATE TABLE payouts. submerchant_settlements (
sub_id BIGINT, period_start TIMESTAMP, period_end TIMESTAMP,
gross_sales NUMERIC, refunds NUMERIC, chargebacks NUMERIC,
fees_total NUMERIC, reserve_delta NUMERIC, revshare NUMERIC,
net_payable NUMERIC, currency TEXT, paid_at TIMESTAMP, statement_ref TEXT
);

10) SQL-шаблоны

10.1. Эффективная стоимость по субмерчанту

sql
SELECT t. sub_id,
SUM(t. amount_reporting) AS volume_rep,
SUM(f. total_fees)    AS fees_rep,
100. 0 SUM(f. total_fees) / NULLIF(SUM(t. amount_reporting),0) AS take_rate_pct
FROM payments. transactions t
JOIN finance. settlement_fees f
ON f. sub_id=t. sub_id
AND t. settled_at BETWEEN f. period_start AND f. period_end
WHERE t. settled_at BETWEEN:from AND:to
GROUP BY 1
ORDER BY take_rate_pct DESC;

10.2. Эффективность каскада (AR/DR) по правилам

sql
SELECT r. profile_id, r. psp, r. mid,
COUNT() FILTER (WHERE t. status='APPROVED') AS approvals,
COUNT() FILTER (WHERE t. status='DECLINED') AS declines,
ROUND(100. 0 COUNT() FILTER (WHERE t. status='APPROVED') / NULLIF(COUNT(),0), 2) AS ar_pct
FROM payments. transactions t
JOIN ref. routing_rules r ON r. rule_id=t. rule_id
WHERE t. authorized_at BETWEEN:from AND:to
GROUP BY 1,2,3
ORDER BY ar_pct DESC;

10.3. Резерв-баланс по субмерчанту

sql
SELECT sub_id,
SUM(hold_amount - released_amount - cb_consumed - fines_consumed) AS reserve_balance
FROM finance. reserve_ledger
WHERE hold_date <=:as_of
GROUP BY 1;

10.4. Расчет net payable субмерчанту

sql
SELECT s. sub_id,
SUM(s. gross_sales - s. refunds - s. chargebacks
- s. fees_total + s. reserve_delta - s. revshare) AS net_payable
FROM payouts. submerchant_settlements s
WHERE s. period_start >=:from AND s. period_end <:to
GROUP BY 1;

11) Дашборды и KPI

AR/DR по каскаду: по GEO/BIN/методу/PSP, доля 3DS, soft-decline share.
Take-Rate % и компонентный стек fees по субмерчанту.
CB Ratio / Refund Rate на суб-MID.
Reserve Balance & Release ETA по субмерчантам/PSP.
Settlement SLA: T+N hit-rate, funding delays.
Payout Health: частота и суммы выплат субмерчантам, задержки.
FX Slippage в каскадах (effective vs reference).

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

Routing Degradation: падение AR > Y bps час-к-часу на правиле.
CB Spike: рост чарджбеков у субмерчанта > X bps w/w.
Reserve Imbalance: несходится леджер резерва — P1.
Settlement Delay: нарушение T+N у PSP → авто-switch в каскаде.
Take-Rate Spike: рост стоимости > порога (fees или FX).
Policy Drift: транзакции без привязки к profile/rule/idempotency — P1.
Payout Delay: просрочка выплаты субмерчанту > SLA.

13) Онбординг и комплаенс субмерчантов

KYB/санкции/PEP: пакеты документов, бенефициары, источники средств.
PCI/безопасность: токенизация, запрет хранения PAN у субмерчанта.
Политики возвратов/бонусов: единые стандарты, SLA тикетов.
Агрегированная отчетность: раздельно по брендам, гео, методам.
Лимиты/каппы: дневные/недельные обороты, payout-caps, отложенные выплаты для high-risk.

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

1. Версионируйте routing-профили и храните explain-логи решений.
2. Держите sticky BIN и A/B-тесты PSP для устойчивости AR и цены.
3. Маппите fees/FX/резерв до уровня субмерчанта; платите net-of-fees по SLA.
4. Idempotency + retry-policy только по soft-decline; соблюдайте лимиты PSP.
5. Дескрипторы и суб-MIDs — уникальные для бренда/гео: меньше диспутов.
6. Леджер резерва с release-календарем и алертами missed-release.
7. Прозрачные отчеты субмерчанту: расшифровка fees, reserve, FX, диспутов.
8. Failover-плейбуки: падение PSP/коридора — мгновенный reroute.

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

• Справочники `submerchants`, `routing_profiles`, `routing_rules`.
• Протоколы KYB/KYC/AML и хранение статусов.
• Маршрутизатор с idempotency и soft-decline-логикой.
• Импорт settlement-файлов PSP → `settlement_fees` + reserve-ledger.
• Механизм payouts субмерчантам + акты/стейтменты.
• Дашборды AR/DR/CB/fees/reserve + алерты.
• Документы: политика диспутов, 3DS-правила, лимиты и SLA.

Резюме

Субмерчанты дают масштаб и гибкость, а каскады — устойчивость, конверсию и управляемую стоимость. Архитектура из иерархии MIDs, версионируемых routing-профилей, прозрачного учета fees/резервов и строгого комплаенса превращает сложный мульти-GEO платежный контур в предсказуемую систему: высокая авторизация, низкий take-rate, быстрые выплаты и минимум сюрпризов по рискам.