Submerches and cascades

1) Conceptual base

A sub-merchant is a legal entity that accepts payments through the main merchant/provider (PayFac/platform/operator). Cash flows go to the master MID/platform account, then the platform pays the sub-merchant (split/sweep).

Cascading is a strategy of sequential or parallel transaction routing through several PSP/acquirers/MID according to the rules (GEO, BIN, tariff, risk, load) to increase authorization and reduce cost.

PayFac-model - platform as a "mini-acquirer": onboarding of a sub-merchant (KYB/PCI), assignment of sub-MID, uniform rules of KYC/AML and disputes, centralized settlement and payments.

2) Where and when you need it in iGaming

Multi-brand/white-label: one operator, dozens of sub-brands/studios → easier to maintain MIDs/descriptors and reporting.
Content marketplace: platform - MoR/PayFac, studios - submersibles (revshare, splits).
High risk/geo-mix: PSP cascades reduce failures, incident shocks and payment costs.
Local methods/payment corridors: you need to choose a provider on the fly and fallback.

3) Responsibilities and roles

4) Hierarchy of MIDs and descriptors

Master MID (platform)

Sub-MID (s) └─ by Brand/Geo/Method

└─ Routing Profiles (PSP1→PSP2… cascade)

• Separate descriptors on sub-MID: fewer disputes.
• Separate cards/A2A/local methods by sub-MID for pure analytics and reserve control.
• Version routing profiles (v1/v2) for A/B.

5) Cascades: How to build

5. 1. On-the-fly solution

When authorizing: select a route according to the rules (GEO, BIN/IIN, brand, debit/credit card, risk class, PSP limit, current AR/DR, tariff/FX, SLA incidents).

5. 2. Types of cascades

Consecutive: PSP_A → (soft decline) → PSP_B → PSP_C.
Split-traffic:% of traffic to different PSPs for benchmarking and decorrelation.
Sticky BIN: securing a successful BIN pool for the best PSP.

5. 3. Restrictions

Read idempotency (so as not to double capture).
Agree with PSP on repeated attempts (retry window, soft codes).
Consider 3DS policy and liability shift on each route.

6) Settlement, T + N, reserves and splits

Each PSP/acquirer has its own cut-off/T + N and its own rolling reserve.
The platform aggregates receipts at the sub-MID level and maintains a reserve-ledger with a release calendar.
Payments to sub-merchants: net of fees & reserve + their share (revshare/CPA) for the reporting period.
Support splits by transaction (platform/studio/affiliate/tax) or by article by period.

7) Antifraud, 3DS and limits at the sub-merchant level

Different scoring thresholds for A/B/C classes of markets.
3DS rules for BIN/geo/check (mandatory/soft/step-up).
Velocity-limits (input/output, card attempts) and caps by submerchant.
"Gray" substandards: stricter limits, only white methods and deferred payments.

8) Tariffs and take-rate

Consider effective take-rate by submerchant: PSP fees (interchange/scheme/markup/fixed) + FX slippage + platform share + reserve-effect.
Use IC++ and BIN-routing to reduce blended cost in a cascade.

9) Data and minimum 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 templates

10. 1. Effective cost per submerchant

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. Cascade efficiency (AR/DR) by rule

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. Reserve-balance by submerchant

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 settlement

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) Dashboards and KPIs

AR/DR by cascade: by GEO/BIN/method/PSP, share of 3DS, soft-decline share.
Take-Rate% and component stack fees by submerchant.
CB Ratio/Refund Rate on sub-MID.
Reserve Balance & Release ETA by Submerchant/PSP.
Settlement SLA: T+N hit-rate, funding delays.
Payout Health: frequency and amounts of payments to submerchants, delays.
FX Slippage in cascades (effective vs reference).

12) Alerts and thresholds

Routing Degradation: Fall AR> Y bps hour-to-hour on rule.
CB Spike: Sub-merchant's chargeback growth> X bps w/w.
Reserve Imbalance: Reserve Ledger Fails - P1.
Settlement Delay: PSP T + N violation → auto-switch in cascade.
Take-Rate Spike: cost growth> threshold (fees or FX).
Policy Drift: transactions without binding to profile/rule/idempotency - P1.
Payout Delay: late payment to the sub-merchant> SLA.

13) Onboarding and sub-merchant compliance

ESC/sanctions/REP: packages of documents, beneficiaries, sources of funds.
PCI/security: tokenization, ban PAN storage at the sub-merchant.
Returns/bonus policies: uniform standards, SLA tickets.
Aggregated reporting: separately by brand, geo, methods.
Limits/caps: daily/weekly turnovers, payout-caps, deferred repayments for high-risk.

14) Best practices (short)

1. Version routing profiles and store explain decision logs.
2. Keep sticky BIN and A/B PSP tests for AR stability and price.
3. Mappite fees/FX/reserve to the level of the sub-merchant; pay net-of-fees on SLA.
4. Idempotency + retry-policy only by soft-decline; comply with PSP limits.
5. Descriptors and sub-MIDs are unique to the brand/geo: fewer disputes.
6. Reserve ledger with release calendar and missed-release alerts.
7. Transparent reports to the sub-merchant: decoding fees, reserve, FX, disputes.
8. Failover playbooks: PSP/corridor drop - instant reroute.

15) Implementation checklist

• Directories' submerchants', 'routing _ profiles', 'routing _ rules'.
• KYB/KYC/AML protocols and status storage.
• Router with idempotency and soft-decline logic.
• Import PSP settlement files → 'settlement _ fees' + reserve-ledger.
• Payouts mechanism to sub-merchants + acts/statutes.
• Dashboards AR/DR/CB/fees/reserve + alerts.
• Documents: Dispute Policy, 3DS Rules, Limits, and SLAs.

Summary

Submerchants provide scale and flexibility, and cascades provide stability, conversion, and manageable cost. The architecture from the hierarchy of MIDs, versioned routing profiles, transparent fees/reserves accounting and strict compliance turns a complex multi-GEO payment loop into a predictable system: high authorization, low take-rate, quick payments and a minimum of surprises on risks.