Subcontinenti e cascate

1) Base comprensibile

Il subcommissario è una persona giuridica che accetta pagamenti tramite il principale fornitore/provider (PayFc/piattaforma/operatore). I flussi di cassa vanno sul master MID/conto della piattaforma e la piattaforma paga il subcontinente (split/sweep).

Cascade (cascading) è una strategia di routing sequenziale o parallelo delle transazioni attraverso più PSP/Equaireri/MID secondo le regole (GEO, BIN, tariffa, rischio, carico di lavoro) per aumentare le autorizzazioni e ridurre i costi.

Il modello PayFc è una piattaforma come «mini-Equairer», come l'onboording del subcontinente (KYB/PCI), l'assegnazione di un secondo MID, le regole unificate di KYC/AML e display, il settement centralizzato e i pagamenti.

2) Dove e quando è necessario nel iGaming

Multibrand/white-label: un operatore, decine di sub/studi sono più facili da gestire MIDs/descrittori e report.
Il marketplace dei contenuti è la piattaforma - MoR/PayFac, gli studi - subcommissari (revshare, split).
Alto rischio/geo-mix: le cascate PSP riducono i guasti, gli shock per incidenti e il costo dei pagamenti.
Metodi/corridoi di pagamento locali: è necessario selezionare il provider al volo e fallback.

3) Responsabilità e ruoli

4) Gerarchia di MIDs e descrittori

Master MID (piattaforma)

└─ Sub-MID (s) per marchi/geo/metodi

└─ Routing Profiles (PSP1→PSP2… cascata)

• Descrittori separati per MID secondario: meno display.
• Separare le mappe/A2A/metodi locali da un MID secondario per l'analisi netta e il controllo della riserva.
• Versionare i profili di routing (v1/v2) per A/B.

5) Cascate: come costruire

5. 1. La soluzione al volo

Se autorizzato, scegli un percorso secondo le regole (GEO, BIN/IIN, brand, carta debit/credit, classe di rischio, limite PSP, corrente AR/DR, tariffa/FX, SLA incidenti).

5. 2. Tipi di cascata

Sequenziale: PSP _ A → (soft decline) → PSP _ B → PSP _ C.
Parallelo (split-traffic):% traffico su PSP diversi per benchmarking e decorazione.
Sticky BIN - Fissa il pool BIN di successo al PSP migliore.

5. 3. Vincoli

Conta idempotency (per non sovrascrivere capture).
Allinea a PSP i tentativi ripetuti (retry window, soft codes).
Tenere conto del criterio 3DS e della liability maiusc su ogni percorso.

6) Settement, T + N, riserve e split

Ogni PSP/Equairer ha il suo cut-off/T + N e il suo rolling reserve.
La piattaforma aggrega le entrate a livello secondario-MID e gestisce la riserva-ledger con un calendario release.
Pagamenti ai subtotali: net of fees & reserve + la loro quota (revshare/CPA) per periodo di segnalazione.
Supporta gli split per transazione (platform/studio/affiliate/tax) o per periodo.

7) Antifrode, 3DS e limiti a livello di sub

Diverse soglie di scrittura per le classi di mercato A/B/C.
Regole 3DS per BIN/geo/assegno ( ./morbido/step-up).
Limiti Velocity (versioni/conclusioni, tentativi di mappe) e caps per subcommercio.
Subcontinenti grigi: limiti più severi, solo metodi bianchi e pagamenti ritardati.

8) Tariffe e take-rate

Leggi effettiva take-rate in base a PSP fees (interchange/scheme/markup/fixed) + FX slippage + quota di piattaforma + effetto di riserva.
Utilizzare IC++ e BIN-routing per ridurre i costi blended a cascata.

9) Dati e modello minimo

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) Modelli SQL

10. 1. Costo efficiente del subcontinente

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. Efficacia cascata (AR/DR) secondo le regole

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. Saldo di riserva per subcontinente

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. Calcolo net payable al subcontinente

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) Dashboard e KPI

AR/DR a cascata: GEO/BIN/metodo/PSP, quota 3DS, soft-decline share.
Take-Rate% e lo stack di componente fees sottomercato.
CB Ratio/Refund Rate per MID secondario.
Reserve Balance & Release ETA per sottomercati/PSP.
Settlement SLA: T+N hit-rate, funding delays.
Payout Health: frequenza e importo dei pagamenti ai subcontinenti, ritardi.
FX Slippage a cascata (effettiva vs reference).

12) Alerti e soglie

Routing Degradation: caduta AR> Y bps ora-a-ora nella regola.
CB Spike: altezza dei charjbeek in un subtotale> X bps w/w.
Reserve Imbalance: il lettore di riserva - P1 non è disponibile.
Settlement Delay - Violazione T + N in PSP di auto-switch a cascata.
Take-Rate Spike: aumento del valore> soglia (fees o FX).
Policy Draft: transazioni senza riferimento a profile/rule/idempotency - P1.
Payout Delay: ritardo nel pagamento del sub> SLA.

13) Onboarding e compliance dei sub

CV/sanzioni/RER: pacchetti di documenti, beneficiari, fonti di fondi.
PCI/Sicurezza: Tornizzazione, disabilitazione del PAN del subcontinente.
Regole di rimborso/bonus: standard comuni, SLA ticetti.
Rapporti aggregati, separati da marchi, geo, metodi.
Limiti/cappe: rotazioni diurne/settimanali, payout-caps, pagamenti ritardati per high-risk.

14) Best practices (breve)

1. Versionare i profili di routing e memorizzare i loghi di soluzione esplicitati.
2. Tenete sticky BIN e A/B-test PSP per la stabilità AR e il prezzo.
3. Mappite fees/FX/riserva fino al livello del subtotale; pagate net-of-fees per SLA.
4. Idempotency + retry-policy solo per soft-decline; rispettate i limiti PSP.
5. Descrittori e secondari MIDs sono unici per il marchio/geo: meno display.
6. Ledger di riserva con calendario release e alert missed-release.
7. Report trasparenti al subtotale: decifrazione di fees, reserve, FX, display.
8. Playbook Failover: la caduta di PSP/corridoio - reroute istantanea.

15) Assegno-foglio di implementazione

• Elenchi di riferimento «submerchants», «routing _ profiles», «routing _ rule».
• Protocolli KYB/KYC/AML e memorizzazione degli stati.
• Router con idempotency e logica soft-decline.
• Importa i file settlement PSP → 'settlement _ fees' + reserve-ledger.
• Meccanismo payouts ai sub + atti/statment.
• Dashboard AR/DR/CB/fees/reserve + alert.
• Documenti: criteri di visualizzazione, regole 3DS, limiti e SLA.

Riepilogo

I sub offrono scala e flessibilità, mentre le cascate offrono sostenibilità, conversione e costi controllati. L'architettura MIDs, i profili di routing versionati, la contabilità trasparente di fees/riserve e la compliance rigorosa trasforma il complesso circuito di pagamento multi-GEO in un sistema prevedibile: alta autorizzazioni, basso take-rate, pagamenti rapidi e un minimo di sorprese sui rischi.