Sous-mesures et cascades

1) Base conceptuelle

Le sous-fournisseur est une entité juridique qui accepte les paiements par l'intermédiaire du principal fournisseur/fournisseur (PayFac/plateforme/opérateur). Les flux de trésorerie vont au compte principal MID/plate-forme, puis la plate-forme paie le sous-acteur (split/sweep).

Cascade (cascading) - stratégie de routage de transaction en série ou en parallèle à travers plusieurs PSP/acquéreurs/MID selon les règles (GEO, BIN, tarif, risque, charge) pour augmenter les autorisations et réduire le coût.

Le modèle PayFac est une plate-forme en tant que « mini-acquéreur » : onbording submersible (KYB/PCI), attribution de sous-MID, règles unifiées KYC/AML et disputations, settlement centralisé et paiements.

2) Où et quand c'est nécessaire dans iGaming

Multibrand/white-label : un opérateur, des dizaines de sous-brands/studios → il est plus facile de tenir des MIDs/descripteurs et des rapports.
Marketing de contenu : plate-forme - MoR/PayFac, studios - sous-mesures (revshare, split).
Risque élevé/mélange géographique : les cascades selon PSP réduisent les pannes, les chocs d'incident et le coût des paiements.
Méthodes locales/couloirs de paiement : vous avez besoin de choisir un fournisseur à la volée et fallback.

3) Responsabilités et rôles

4) Hiérarchie des MIDs et des descripteurs

Master MID (plateforme)

└─ Sub-MID (s) par marque/géo/méthode

└─ Routing Profiles (PSP1→PSP2… cascade)

• Descripteurs individuels sur le sous-MID : Moins de disputations.
• Séparez les cartes/A2A/méthodes locales selon le sous-MID pour l'analyse nette et le contrôle de la réserve.
• Versioner les profils de routage (v1/v2) pour A/B.

5) Cascades : Comment construire

5. 1. Une solution « à la volée »

En cas d'autorisation : choisir l'itinéraire selon les règles (GEO, BIN/IIN, marque, carte debit/credit, classe risque, limite PSP, AR/DR actuel, tarif/FX, SLA incidents).

5. 2. Types de cascades

Cohérent : PSP_A → (soft decline) → PSP_B → PSP_C.
Parallèle (split-traffic) :% du trafic vers différents PSP pour le benchmarking et la décorrélation.
Sticky BIN : Ancrer un pool BIN réussi derrière le meilleur PSP.

5. 3. Restrictions

Comptez idempotency (pour éviter la capture).
Aligner les tentatives répétées avec PSP (retry window, soft codes).
Prendre en compte la politique 3DS et la liability shift sur chaque itinéraire.

6) Settlement, T + N, réserves et split

Chaque PSP/acquéreur a sa propre cut-off/T + N et sa propre réserve de roulement.
La plate-forme agrège les recettes au niveau sous-MID et gère reserve-ledger avec le calendrier de sortie.
Paiements aux sous-indicateurs : net of fees & reserve + leur part (revshare/CPA) par période de déclaration.
Prendre en charge les séparations par transaction (platform/studio/affiliate/tax) ou par période.

7) Antifrod, 3DS et limites au niveau de la sous-mesure

Différents seuils de notation pour les classes A/B/C des marchés.
Règles 3DS sur le BIN/geo/chèque (pb ./soft/step-up).
Limites de velocity (dépôts/conclusions, tentatives de cartes) et caps par sous-mesure.
Sous-mesures « grises » : limites plus strictes, méthodes blanches seulement et paiements différés.

8) Tarifs et taux de take-rate

Comptez le taux effectif par sous-indicateur : PSP fees (échange/scheme/markup/fixed) + FX slippage + part de plateforme + réserve-effet.
Utilisez IC++ et BIN-routing pour réduire le coût en cascade.

9) Données et modèle minimum

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) modèles SQL

10. 1. Coût effectif par sous-mesure

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. Efficacité de la cascade (AR/DR) selon les règles

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. Réserve-bilan par sous-secteur

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. Calcul net payable à la sous-mesure

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 et KPI

AR/DR par cascade : par GEO/BIN/méthode/PSP, part 3DS, partage soft-decline.
Take-Rate % et la pile de composants fees par sous-mesure.
CB Ratio/Refund Rate sur le sous-MID.
Reserve Balance & Release ETA par sous-mesure/PSP.
Settlement SLA: T+N hit-rate, funding delays.
Payout Health : fréquence et montants des paiements aux sous-entreprises, retards.
FX Slippage en cascades (effective vs reference).

12) Alertes et seuils

Routing Degradation : chute AR> Y bps heure à heure sur la règle.
CB Spike : croissance des chargbacks chez le sous-mesure> X bps w/w.
Reserve Imbalance : Le ledger de la réserve est P1.
Settlement Delay : violation T + N chez PSP → auto-switch en cascade.
Take-Rate Spike : augmentation du coût> seuil (fees ou FX).
Policy Drift : transactions sans lien avec profile/rule/idempotency - P1.
Payout Delay : retard de paiement au sous-acteur> SLA.

13) Onbording et conformité des sous-indicateurs

KVD/Sanctions/RER : dossiers, bénéficiaires, sources de fonds.
PCI/sécurité : Tokenization, interdiction de stockage PAN dans le sous-mesure.
Politiques de remboursement/bonus : normes uniformes, tickets SLA.
Rapports agrégés : séparés par marques, géo, méthodes.
Limites/kappa : chiffre d'affaires journalier/hebdomadaire, payout-caps, paiements différés pour les risques élevés.

14) Meilleures pratiques (en bref)

1. Versez les profils de routage et stockez les logs d'exploitation des solutions.
2. Gardez le BIN sticky et les tests A/B PSP pour la durabilité de l'AR et le prix.
3. Mappite fees/FX/réserve jusqu'au niveau de sous-mesure ; payer net-of-fees par SLA.
4. Idempotency + retry-policy uniquement par soft-decline ; respecter les limites du PSP.
5. Les descripteurs et les sous-MID sont uniques à la marque/geo : moins de disputes.
6. Ledger de réserve avec release-calendrier et alertes missed-release.
7. Rapports transparents à la sous-mesure : décryptage de fees, reserve, FX, disputes.
8. Failover-playbooks : la chute du PSP/corridor est un reroute instantané.

15) Chèque de mise en œuvre

• Les manuels 'submerchants', 'routing _ profiles', 'routing _ rules'.
• Les protocoles KYB/KYC/AML et le stockage des statuts.
• Routeur avec idempotency et soft-decline-logique.
• Importer les fichiers settlement PSP → 'settlement _ fees' + reserve-ledger.
• Mécanisme de paiement des sous-indicateurs + actes/statents.
• Dashboards AR/DR/CB/fees/reserve + alerties.
• Documents : Politiques de dispute, règles 3DS, limites et SLA.

Résumé

Les sous-mesures donnent l'échelle et la flexibilité, et les cascades donnent la durabilité, la conversion et le coût gérable. L'architecture de la hiérarchie des MIDs, des profils routing versionables, de la comptabilité transparente des fees/réserves et de la complience rigoureuse transforme une boucle de paiement multi-GEO complexe en un système prévisible : autorisation élevée, taux bas, paiements rapides et un minimum de surprises sur les risques.