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

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: менше диспутів.
• Розділяйте карти/А2А/локальні методи по суб-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) Онбординг і комплаєнс субмерчантів

КУВ/санкції/РЕР: пакети документів, бенефіціари, джерела коштів.
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, швидкі виплати і мінімум сюрпризів за ризиками.