GH GambleHub

Cascade au niveau des fournisseurs

1) Qu'est-ce que la cascade et pourquoi il est dans iGaming

Cascading (fournisseur cascading) : sélection dynamique et/ou commutation séquentielle entre plusieurs PSP/équionneurs pour la même tentative de paiement ou pour la distribution du trafic dans son ensemble. Objectifs :
  • AR↑/ DR↓ : contournement des émetteurs « capricieux », sélection du meilleur PSP pour un BIN/géo/méthode spécifique.
  • Coût de ↓ : IC + +/markup plus bas sur une partie du panier, minimisation de fix-fia sur micro-ticket.
  • Durabilité : échec lors d'incidents, dégradation de 3DS, chute de couloirs de paiement.
  • Conformité : respect des géopolitiques, sanctions, interdictions locales et licences.

2) Modèles de cascade

1. Séquentiel (séquentiel)

PSP_A → (soft-decline/tekhnitchesky le refus) → PSP_B → PSP_C.
La « fenêtre étroite » des retraits est utilisée pour ne pas créer de prises/risques de colle multiple de fonds.

2. Parallèle (split-traffic/multi-arm)

Répartition du flux (%/règles) entre plusieurs PSP pour l'étalonnage, l'apprentissage des règles et la réduction des échecs corrélés.

3. Sticky BIN / Sticky GEO

Mémorisation de la « meilleure » PSP pour une bande BIN/émetteur/géo spécifique (caches de solutions avec TTL).

4. Method-aware / Feature-aware

Différents fournisseurs pour les cartes, A2A, portefeuilles, méthodes locales ; prise en compte des spécificités de la 3DS-rails, du comportement DCC/FX, de la tokénisation.

5. Limit-aware / SLA-aware

Tenez compte des limites des fournisseurs, des réserves, des incidents SLA, des coupures et des retards funding.

3) Moteur de décision (rules-engine) : signaux d'entrée

Caractéristiques : BIN/IIN, marque, débit/credit, commercial/premium, country of issuer.
Géo et conformité : pays du joueur (IP/GPS/SIM/KYC), sanctions, licences.
Transaction : montant (unités mineures), devise, canal (web/app), risque-score.
Historique des fournisseurs : AR/DR par BIN/géo/méthode au cours des 15 à 60 dernières minutes, part soft-decline, 3DS-pass-rate.
Coût : IC + +/markup/fix, spread FX, rolling reserve %.
Restrictions : rate-limit du fournisseur, maintenance/incidents, caps de circulation journalière.

Sortie : liste prioritaire des itinéraires '[(PSP, MID, require_3DS, retry_window_ms, max_attempts)]'.

4) Retrai, idempotence et sécurité

Idempotency-key pour essayer (user_id+order_id+nonce) commun à tous les fournisseurs en cascade.
Rétrospective uniquement sur soft-decline (network/3DS/timeout/fonds insufficient), jamais avec des codes "durs' (stolen, do not honor ref, etc.).
Anti-soufflage : le statut 'AUTORISÉ '/' CAPTURED' ferme la cascade ; toutes les autres branches sont annulées.
Fenêtres : 1ère retraite ≤ 2-5 secondes, budget total ≤ 15-30 secondes avec UX.
Politique 3DS : possible step-up sur la deuxième/troisième branche si la première tombe sans 3DS.

5) 3DS, liability shift и AR

Le choix de 'frictionless '/' challenge' dépend du risque et du support PSP (delegated auth, TRA, whitelisting).
Dans les geos/émetteurs « rigides », force 3DS sur les parties du panier.
Surveillez liability shift par les fournisseurs : où il est le plus souvent atteint - y transporte des BIN risqués.

6) Coût : IC++, blended, fix-fiya et FX

Pour chaque PSP, comptez le taux effectif de prise = interchange + scheme + markup + fixe + FX-slippage.

En cascade, utilisez la fonction de prix dans la notation de l'itinéraire :
  • `Score = w1AR_live + w2(−Cost_bps) + w3(SLA_health) + w4(FX_quality) +...`
  • Micro-ticket : le poids de fix-fia est plus élevé que → les fournisseurs préférés avec un fix bas.
  • Tenez compte séparément de la réserve % et du funding T + N - affectant le cache flow.

7) Incidents, coupures et routage

Health-Fid : statuts PSP/corridors (API auth, ACS 3DS, payout rails).
Auto-failover : reroute instantanée lorsque l'AR/santé tombe en dessous du seuil.
Cut-off-aware : avant de fermer le settlment, évitez la capture partielle sur PSP avec un T + N. inconfortable.
Throttling : afin de ne pas « vivre » la limite du fournisseur, distribuez le trafic.

8) Modèle de données minimum

sql
-- Providers and MIDs
CREATE TABLE ref. providers (
provider TEXT PRIMARY KEY, model TEXT, pricing_model TEXT, fx_policy TEXT, reserve_pct NUMERIC, meta JSONB
);
CREATE TABLE ref. mids (
mid TEXT PRIMARY KEY, provider TEXT REFERENCES ref. providers, country TEXT, method TEXT, descriptor TEXT, meta JSONB
);

-- Cascade Rules/Profiles
CREATE TABLE ref. cascade_profiles (
profile_id BIGSERIAL PRIMARY KEY, name TEXT, version TEXT, enabled BOOLEAN, meta JSONB
);
CREATE TABLE ref. cascade_rules (
rule_id BIGSERIAL PRIMARY KEY, profile_id BIGINT REFERENCES ref. cascade_profiles,
geo TEXT, bin_from TEXT, bin_to TEXT, method TEXT,
provider TEXT, mid TEXT, require_3ds BOOLEAN, priority INT,
retry_on_soft JSONB, max_attempts INT, ttl_seconds INT, enabled BOOLEAN, meta JSONB
);

-- Online Provider Performance Metrics (Sliding Window)
CREATE TABLE live. provider_stats_15m (
provider TEXT, method TEXT, geo TEXT, bin6 TEXT,
approvals INT, declines INT, soft_declines INT, three_ds_pass INT,
avg_latency_ms INT, updated_at TIMESTAMP
);

-- Transactions with idempotency and selected route
CREATE TABLE payments. auth_attempts (
attempt_id BIGSERIAL PRIMARY KEY, idempotency_key TEXT, step INT,
provider TEXT, mid TEXT, require_3ds BOOLEAN, status TEXT, decline_code TEXT,
amount_minor BIGINT, currency TEXT, bin TEXT, geo TEXT,
started_at TIMESTAMP, finished_at TIMESTAMP, meta JSONB
);

9) modèles d'analyse SQL

9. 1. Classement en ligne des fournisseurs (AR et soft-decline share)

sql
SELECT provider, method, geo,
SUM(approvals) AS appr,
SUM(declines) AS decl,
ROUND(100. 0 SUM(approvals) / NULLIF(SUM(approvals+declines),0), 2) AS ar_pct,
ROUND(100. 0 SUM(soft_declines) / NULLIF(SUM(declines),0), 2) AS soft_share_pct
FROM live. provider_stats_15m
WHERE updated_at > now() - INTERVAL '20 minutes'
GROUP BY 1,2,3
ORDER BY ar_pct DESC, soft_share_pct DESC;

9. 2. Effet de cascade sur les commandes (step-conversion)

sql
WITH s AS (
SELECT idempotency_key,
MAX(step) AS steps,
BOOL_OR(status='APPROVED') AS approved
FROM payments. auth_attempts
WHERE started_at BETWEEN:from AND:to
GROUP BY 1
)
SELECT steps,
COUNT() AS orders,
100. 0 SUM(approved::int) / NULLIF(COUNT(),0) AS conv_pct
FROM s
GROUP BY 1
ORDER BY 1;

9. 3. Sticky BIN : Le meilleur fournisseur de BIN6

sql
SELECT bin6,
provider,
ROUND(100. 0 SUM(approved)::NUMERIC / NULLIF(COUNT(),0), 2) AS ar_pct
FROM (
SELECT LEFT(bin,6) AS bin6, provider, (status='APPROVED') AS approved
FROM payments. auth_attempts
WHERE started_at BETWEEN:from AND:to
) t
GROUP BY 1,2
QUALIFY ROW_NUMBER() OVER (PARTITION BY bin6 ORDER BY ar_pct DESC) = 1;

9. 4. Coût par fournisseur (take-rate)

sql
SELECT provider,
SUM(amount_reporting) AS volume_rep,
SUM(interchange_amt + scheme_amt + markup_amt + auth_amt + refund_amt + cb_amt + gateway_amt + fx_spread_amt) AS fees_rep,
100. 0 SUM(interchange_amt + scheme_amt + markup_amt + auth_amt + refund_amt + cb_amt + gateway_amt + fx_spread_amt)
/ NULLIF(SUM(amount_reporting),0) AS take_rate_pct
FROM finance. settlement_fees
JOIN dw. transactions_flat USING (provider)
WHERE period_start_at >=:from AND period_end_at <:to
GROUP BY 1
ORDER BY take_rate_pct;

10) KPI et dashboards

AR/DR sur les fournisseurs et BIN/géo/méthode (fenêtres en ligne 15/60 min et day-to-date).
Step-conversion : part des approbations sur la 1ère, 2ème, 3ème branche.
Take-Rate % et FX-slippage par fournisseur/MID.
3DS pass-rate et part de liability shift.
Santé/SLA : latency, timeouts, taux d'erreur, incidents.
Reserve & Funding : reserve % et T + N hit-rate par fournisseur.

11) Alertes et seuils

Routing Degradation : Chute AR chez le fournisseur sélectionné> Y bps en 10 à 30 minutes.
Soft-decline surge : l'augmentation de la part de soft-decline → permettre une branche supplémentaire de cascade.
3DS Anomalie : chute de 3DS pass-rate> X % chez un émetteur/un cluster BIN particulier.
Take-Rate Spike : Augmentation du coût all-in> seuil bps.
Health Down: SLA breach (latency/error) — авто-failover.
Policy Drift : Tentatives sans profil de cascade idempotency_key/bez - P1.

12) Tests AB et apprentissage des règles

Bandit multi-arm ou split-traffic fixe sur de nouveaux itinéraires.
Explore/Exploit : une partie du trafic à conserver sur la « formation » sticky BIN.
Horizons d'évaluation : en ligne (15/60 min) pour les incidents et semaine/mois - pour le coût.
Guardrails : minimum AR/max take-rate pour arrêter l'expérience.

13) Conformité et cas « extrêmes »

Respecter les sanctions/licences/géoblocks : certains fournisseurs ne peuvent pas servir des pays/méthodes individuels.
Same-method/Return-to-source : la cascade ne doit pas briser la politique de retour.
Tokenization/PCI : un schéma unique entre PSP (network tokens/vault).
Chargebacks : Loger par quelle branche la capture est passée - pour les disputes.

14) Meilleures pratiques (en bref)

1. Remettez seulement soft-decline, avec un seul idempotency_key.
2. Gardez la télémétrie en direct des fournisseurs de services de AR/3DS/soft-decline et de santé.
3. Construire la fonction de prix de l'itinéraire (AR vs Cost vs SLA vs FX).
4. Utiliser des tests BIN et AB ; Versez les profils de la cascade.
5. Soyez cut-off-aware : ne produisez pas de capture partielle à la fin de la journée.
6. Avoir playbooks failover : chute PSP/ACS/couloir de paiement.
7. Partagez les données et la responsabilité : qui tient le PAN, qui mène les débats.
8. Reserve-ledger par fournisseur : releases et débits.

15) Chèque de mise en œuvre

  • Carte des fournisseurs/MID, tarification (IC + +/blended), politiques FX, réserves, T + N.
  • Rules-engine : profils, règles, soft-codes, politique 3DS, limites.
  • Routeur : idempotence, retraits, temporisations, sticky BIN cache.
  • Télémétrie : live-metrics AR/DR/3DS/latency/health ; alerte.
  • Incident-gestion et failover-playbooks.
  • ETL pour fees/FX/reserve ; vitrines take-rate et step-conversion.
  • Procédures des tests AB et guardrails.
  • Documentation : restrictions de conformité, retour de same method, responsabilité.

Résumé

La cascade au niveau des fournisseurs n'est pas « d'essayer un autre PSP », mais une discipline : métriques en direct, rules-engine intelligent, idempotence stricte, tactique 3DS correcte, comptabilité coût/FX/réserves et scénarios d'échec prêts à l'emploi. Une telle architecture augmente l'AR, réduit le taux de charge et rend la boucle de paiement résistante aux pannes et aux contraintes réglementaires.

Contact

Prendre contact

Contactez-nous pour toute question ou demande d’assistance.Nous sommes toujours prêts à vous aider !

Commencer l’intégration

L’Email est obligatoire. Telegram ou WhatsApp — optionnels.

Votre nom optionnel
Email optionnel
Objet optionnel
Message optionnel
Telegram optionnel
@
Si vous indiquez Telegram — nous vous répondrons aussi là-bas.
WhatsApp optionnel
Format : +code pays et numéro (ex. +33XXXXXXXXX).

En cliquant sur ce bouton, vous acceptez le traitement de vos données.