Untergrößen und Kaskaden

1) Konzeptionelle Basis

Submerchant ist eine juristische Person, die Zahlungen über den Haupthändler/Anbieter (PayFac/Plattform/Betreiber) akzeptiert. Die Cashflows gehen an den Master-MID/das Plattform-Konto, dann zahlt die Plattform an den Sub-Mercher (Split/Sweep).

Cascading (Cascading) ist eine Strategie zum seriellen oder parallelen Routing einer Transaktion über mehrere PSPs/Acquirer/MIDs nach Regeln (GEO, BIN, Tarif, Risiko, Last), um die Berechtigungen zu erhöhen und die Kosten zu senken.

PayFac-Modell - Plattform als „Mini-Acquirer“: Onboarding des Sub-Merchants (KYB/PCI), Vergabe von Sub-MIDs, einheitliche KYC/AML-Regeln und Dispute, zentrale Ansiedlungen und Auszahlungen.

2) Wo und wann es in iGaming benötigt wird

Multi-Brand/White-Label: Ein Operator, Dutzende von Submarken/Studios → einfacher zu MIDs/Deskriptoren und Reporting zu führen.
Content-Marktplatz: Plattform - MoR/PayFac, Studios - Submerchants (Revshare, Splits).
Hohes Risiko/Geo-Mix: PSP-Kaskaden reduzieren Ausfälle, Störungsschocks und Zahlungskosten.
Lokale Auszahlungsmethoden/Korridore: Sie benötigen eine Auswahl an On-the-fly-Anbietern und Fallbacks.

3) Verantwortung und Rollen

4) Hierarchie der MIDs und Deskriptoren

Master MID (Plattform)

└─ Sub-MIDs nach Marken/Geo/Methoden

└─ Routing Profiles (PSP1→PSP2… Kaskade)

• Separate Deskriptoren auf dem Sub-MID: weniger Dispute.
• Trennen Sie Karten/A2A/lokale Methoden nach Sub-MIDs für reine Analyse- und Reservekontrolle.
• Versionieren Sie Routing-Profile (v1/v2) für A/B.

5) Kaskaden: wie man baut

5. 1. Entscheidung „on the fly“

Bei Autorisierung: Route nach Regeln auswählen (GEO, BIN/IIN, Marke, Debit/Credit-Karte, Risikoklasse, PSP-Limit, aktuelle AR/DR, Tarif/FX, SLA-Vorfälle).

5. 2. Arten von Kaskaden

Der Konsequente: PSP_A → (soft decline) → PSP_B → PSP_C.
Parallel (Split-Traffic):% des Datenverkehrs zu verschiedenen PSPs für Benchmarking und Dekorrelation.
Sticky BIN: Sichern Sie einen erfolgreichen BIN-Pool für die beste PSP.

5. 3. Beschränkungen

Zählen Sie idempotency (um die Gefangennahme nicht zu übertreiben).
Wiederholungsversuche mit PSP abstimmen (Retry-Fenster, Soft-Codes).
Berücksichtigen Sie die 3DS-Politik und die Liability Shift auf jeder Route.

6) Siedlung, T + N, Reserven und Splits

Jede PSP/Acquirer hat ihr eigenes Cut-off/T + N und ihre eigene Rolling Reserve.
Die Plattform aggregiert die Einnahmen auf Sub-MID-Ebene und führt einen Reserve-Ledger mit einem Release-Kalender.
Zahlungen an Subunternehmer: net of fees & reserve + deren Anteil (revshare/CPA) am Berichtszeitraum.
Halten Sie Splits nach Transaktion (Plattform/Studio/Affiliate/Steuer) oder Post-Post nach Periode.

7) Betrugsbekämpfung, 3DS und Limits auf Submerchant-Ebene

Unterschiedliche Scoring-Schwellenwerte für A/B/C-Marktklassen.
3DS-lenkte nach dem BIN/geo/Scheck (обяз./мягко/step-up).
Velocity-Limits (Einzahlungen/Schlussfolgerungen, Kartenversuche) und Caps pro Submerchant.
„Graue“ Submerchants: Striktere Limits, nur weiße Methoden und verzögerte Auszahlungen.

8) Tarife und Take-Rate

Zählen Sie die effektive Take-Rate nach Submerchant: PSP fees (interchange/scheme/markup/fixed) + FX slippage + Plattform-Aktie + Reserve-Effekt.
Verwenden Sie IC++ und BIN-Routing, um die Blended-Kosten in der Kaskade zu senken.

9) Daten und Minimalmodell

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-Vorlagen

10. 1. Effektive Kosten nach Teilbetrag

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. Kaskadeneffizienz (AR/DR) nach Regeln

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-Saldo nach Teilbetrag

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. Berechnung net payable submerchant

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 und KPIs

AR/DR nach Kaskade: nach GEO/BIN/Methode/PSP, 3DS-Anteil, Soft-Decline-Anteil.
Take-Rate% und Component Stack fees nach Submerchant.
CB Ratio/Refund Rate auf Sub-MID.
Reserve Balance & Release ETA auf Submerchants/PSP.
Settlement SLA: T+N hit-rate, funding delays.
Payout Health: Häufigkeit und Höhe der Zahlungen an Subunternehmer, Verzögerungen.
FX Slippage in Kaskaden (effective vs reference).

12) Alerts und Schwellenwerte

Routing Degradation: Fall AR> Y bps Stunde-zu-Stunde auf die Regel.
CB Spike: Chargeback-Wachstum im Submerchant> X bps w/w.
Reserve Imbalance: Der Reserve-Ledger - P1 - kommt nicht zustande.
Settlement Delay: T + N-Verletzung bei PSP → Auto-Switch in der Kaskade.
Take-Rate Spike: Wertsteigerung> Schwelle (fees oder FX).
Policy Drift: Transaktionen ohne Bezug zu profile/rule/idempotency - P1.
Auszahlungsverzögerung: überfällige Zahlung an den Untermensch> SLA.

13) Onboarding und Compliance von Sub-Merchants

KUV/Sanktionen/RER: Dokumentenpakete, Begünstigte, Mittelquellen.
PCI/Sicherheit: Tokenisierung, Verbot der Speicherung von PAN im Submerchant.
Rückgabe-/Bonusrichtlinien: einheitliche Standards, SLA-Tickets.
Aggregiertes Reporting: getrennt nach Marken, Geo, Methoden.
Limits/Kapps: Tages-/Wochenumsätze, Auszahlungsobergrenzen, ausstehende Auszahlungen für hohe Risiken.

14) Best Practices (kurz)

1. Versionieren Sie Routing-Profile und speichern Sie explain-Entscheidungslogs.
2. Halten Sie sticky BIN und A/B PSP-Tests für AR-Nachhaltigkeit und Preis.
3. Muppite fees/FX/Reserve bis Submerchant Level; zahlen net-of-fees auf SLA.
4. Idempotency + retry-policy nur auf soft-decline; Beachten Sie die PSP-Limits.
5. Deskriptoren und Sub-MIDs - einzigartig für Marke/Geo: weniger Dispute.
6. Reserve-Ledger mit Release-Kalender und Alert-Missed-Release.
7. Transparente Berichte an Submerchant: Entschlüsselung von Fees, Reserve, FX, Disputen.
8. Failover-Playbooks: PSP/Korridor Drop ist eine sofortige Reroute.

15) Checkliste Umsetzung

• Verzeichnisse' submerchants', 'routing _ profiles', 'routing _ rules'.
• KYB/KYC/AML-Protokolle und Statusspeicherung.
• Router mit Idempotency und Soft-Decline-Logik.
• Importieren von PSP-settlement-Dateien → 'settlement _ fees' + reserve-ledger.
• Payouts-Mechanismus für Submerchants + Acts/Statements.
• Dashboards AR/DR/CB/fees/reserve + alerts.
• Dokumente: Disputationspolitik, 3DS-Regeln, Limits und SLAs.

Zusammenfassung

Submerchants geben Maßstab und Flexibilität, während Kaskaden Nachhaltigkeit, Konvertierung und überschaubare Kosten bieten. Die Architektur aus MIDs-Hierarchie, versionierbaren Routing-Profilen, transparenter Fees-/Reserve-Bilanzierung und strikter Compliance verwandelt den komplexen Multi-GEO-Zahlungskreislauf in ein vorhersehbares System: hohe Autorisierung, niedrige Take-Rate, schnelle Auszahlungen und ein Minimum an Risikoüberraschungen.