Submerchantlar va kaskadlar
1) Tushuncha bazasi
Submerchant - to’lovlarni bosh merchant/provayder (PayFac/platforma/operator) orqali qabul qiluvchi yuridik shaxs. Pul oqimlari platformaning master-MID/hisob raqamiga o’tadi, keyin platforma submerchantga (split/sweep) to’laydi.
Kaskad (cascading) - avtorizatsiyalarni oshirish va qiymatni pasaytirish uchun qoidalar (GEO, BIN, tarif, tavakkalchilik, yuk) bo’yicha bir nechta PSP/ekvayers/MID orqali tranzaksiyalarni izchil yoki parallel routing qilish strategiyasi.
PayFac-model - «mini-ekvayer» platformasi: submerchant onbording (KYB/PCI), submid berish, KYC/AML va munozaralarning yagona qoidalari, markazlashtirilgan settlement va to’lovlar.
2) iGaming’da qayerda va qachon kerak
Multibrend/white-label: bitta operator, oʻnlab subbrendlar/studiyalar → MIDs/deskriptor va hisobotlarni yuritish osonroq.
Kontent bozori: platforma - MoR/PayFac, studiyalar - submerchantlar (revshare, split).
Yuqori xavf/geo-miks: PSP kaskadlari nosozliklar, hodisalar bo’yicha shoklar va to’lovlar qiymatini kamaytiradi.
Mahalliy toʻlov usullari/yoʻlaklari: uchish uchun provayder va fallback tanlash kerak.
3) Mas’uliyat va rollar
4) MID va deskriptorlar ierarxiyasi
Master MID (platforma)
─ Sub-MID (lar) brendlar/geo/usullar bo’yicha
└─ Routing Profiles (PSP1→PSP2… kaskad)
Tavsiyalar:- Submid uchun alohida deskriptorlar: munozaralardan kam.
- Xaritalarni/A2A/lokal usullarni sof tahlil va zaxira nazorati uchun sub-MID bilan ajrating.
- A/B uchun routing profillarini (v1/v2) versiya qiling
5) Kaskadlar: qanday qurish kerak
5. 1. «Uchish» yechimi
Avtorizatsiya qilishda: qoidalar bo’yicha yo’nalishni tanlash (GEO, BIN/IIN, brand, debit/credit kartasi, xavf-sinf, PSP limiti, joriy AR/DR, tarif/FX, SLA hodisalar).
5. 2. Kaskad turlari
Ketma-ket: PSP_A → (soft decline) → PSP_B → PSP_C.
Parallel (split-traffic): benchmarking va dekorrelyatsiya uchun turli PSPlarga% trafik.
Sticky BIN: muvaffaqiyatli BIN-pulni eng yaxshi PSPga biriktirish.
5. 3. Cheklovlar
idempotency deb hisoblash (capture qoʻshilmasligi uchun).
Qayta urinishlarni (retry window, soft codes) PSP bilan kelishish.
Har bir yoʻnalishda 3DS siyosati va liability shiftini hisobga olish.
6) Settlement, T + N, rezervlar va splitlar
Har bir PSP/ekvayerning o’z cut-off/T + N va o’z rolling reserve mavjud.
Platforma tushumlarni sub-MID darajasida birlashtiradi va release-kalendar bilan reserve-ledger yuritadi.
Submerchantlarga to’lovlar: net of fees & reserve + ularning hisobot davri bo’yicha ulushi (revshare/CPA).
Splitlarni tranzaksiya (platform/studio/affiliate/tax) yoki davrga qarab moddama-modda saqlang.
7) Antifrod, 3DS va submerchant darajasidagi limitlar
Bozorlarning A/B/C klasslari uchun turli xil skoring-chegara.
BIN/geo/chek bo’yicha 3DS qoidalari (majburiyat ./yumshoq/step-up).
Velocity-limitlar (kiritishlar/xulosalar, xaritalarga urinishlar) va submerchant bo’yicha caps.
«Kulrang» submerchantlar: qattiqroq limitlar, faqat oq usullar va kechiktirilgan to’lovlar.
8) Tariflar va take-rate
Effective take-rate submerchant bo’yicha hisoblang: PSP fees (interchange/scheme/markup/fixed) + FX slippage + platforma ulushi + zaxira-effekt.
Kaskaddagi blended qiymatini pasaytirish uchun IC++ va BIN-routingdan foydalaning.
9) Ma’lumotlar va eng kam model
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 namunalari
10. 1. Submerchant bo’yicha samarali qiymat
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. Qoidalar bo’yicha kaskad samaradorligi (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. Submerchant bo’yicha zaxira-balans
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. Submerchant uchun net payable hisobi
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) Dashbordlar va KPI
Kaskad bo’yicha AR/DR: GEO/BIN/PSP usuli bo’yicha, 3DS ulushi, soft-decline share.
Take-Rate% va submerchant boʻyicha fees komponent steki.
CB Ratio/Refund Rate submid.
Reserve Balance & Release ETA submerchantlar/PSP bo’yicha.
Settlement SLA: T+N hit-rate, funding delays.
Payout Health: submerchantlarga to’lovlarning chastotasi va summasi, kechikishlar.
FX Slippage kaskadlarda (effective vs reference).
12) Alerta va ostonalar
Routing Degradation: qoidada AR> Y bps soatiga-soatiga tushadi.
CB Spike: submerchantdagi charjbeklarning o’sishi> X bps w/w.
Reserve Imbalance: zaxira legeri - P1 mos kelmaydi.
Settlement Delay: kaskaddagi PSP → avto-switchda T + N buzilishi.
Take-Rate Spike: qiymatning oshishi> chegara (fees yoki FX).
Policy Drift: profile/rule/idempotency - P1.
Payout Delay: submerchantga to’lovni kechiktirish> SLA.
13) Onbording va komplayens submerchantlar
KV/sanksiyalar/TB: hujjatlar paketlari, benefitsiarlar, mablag’lar manbalari.
PCI/xavfsizlik: tokenlash, submerchantda PAN saqlashni taqiqlash.
Qaytarish/bonuslar siyosati: yagona standartlar, SLA chiptalari.
Agregatsiya qilingan hisobot: brendlar, geolar, usullar bo’yicha alohida.
Limitlar/kappalar: kundalik/haftalik aylanmalar, payout-caps, high-risk uchun kechiktirilgan to’lovlar.
14) Best practices (qisqacha)
1. Routing profillarini va explain-loglarini saqlang.
2. Sticky BIN va A/B PSP testlarini AR barqarorligi va narxlari uchun saqlang.
3. Mappite fees/FX/zaxira submerchant darajasigacha; SLA bo’yicha net-of-fees to’lang.
4. Idempotency + retry-policy faqat soft-decline bo’yicha; PSP limitlariga rioya qiling.
5. Deskriptorlar va sub-MIDs - brend/geo uchun noyob: munozaralar kamroq.
6. Release taqvimi va missed-release alertlari bilan zaxira ledjeri.
7. Submerchantga shaffof hisobotlar: fees, reserve, FX, munozaralar.
8. Failover-pleybuklar: PSP/koridorning qulashi - tezkor reroute.
15) Joriy etish chek-varaqasi
- ’submerchants’,’routing _ profiles’,’routing _ rules’maʼlumotnomalari.
- KYB/KYC/AML protokollari va maqomlarni saqlash.
- Idempotency va soft-decline-mantiqqa ega bo’lgan marshrutizator.
- PSP settlement fayllarini import qilish →’settlement _ fees’+ reserve-ledger.
- Submerchantlar uchun payouts mexanizmi + aktlar/statmentlar.
- Dashbordlar AR/DR/CB/fees/reserve + alertlar.
- Hujjatlar: munozaralar siyosati, 3DS qoidalari, limitlari va SLA.
Xulosa
Submerchantlar masshtab va moslashuvchanlik, kaskadlar esa barqarorlik, konversiya va boshqariladigan qiymat beradi. MIDs ierarxiyasi, versiyalashtiriladigan routing-profillar, fees/zaxiralarning shaffof hisobi va qat’iy komplayens arxitekturasi murakkab multi-GEO to’lov konturini oldindan aytib bo’ladigan tizimga aylantiradi: yuqori avtorizatsiya, past take-rate, tezkor to’lovlar va xavflar bo’yicha kutilmagan hodisalar.