Submerchantes y cascadas

1) Base conceptual

Submerchant es una entidad legal que acepta pagos a través de un proveedor/merchant principal (PayNat/plataforma/operador). Los flujos de efectivo van al MID maestro/cuenta de la plataforma, a continuación, la plataforma paga al submerciente (split/sweep).

Cascada (cascading) es una estrategia de enrutamiento de transacciones sucesivas o paralelas a través de múltiples PSP/ecuairers/MID bajo reglas (GEO, BIN, tarifa, riesgo, carga) para aumentar las autorizaciones y reducir el costo.

El modelo de PayNat es una plataforma como «mini equairer»: onboarding submercient (KYB/PCI), asignación de sub-MID, reglas uniformes KYC/AML y disputs, settlement centralizado y pagos.

2) Dónde y cuándo se necesita en iGaming

Multimarca/etiqueta blanca: un operador, docenas de submarca/estudios → son más fáciles de mantener MIDs/descriptores e informes.
Marketing de contenido: plataforma - MoR/PayNat, estudios - submercionales (revshare, splits).
Alto riesgo/geomalla: Las cascadas PSP reducen las fallas, los choques de incidentes y el costo de los pagos.
Métodos locales/pasillos de pago: necesita elegir un proveedor sobre la marcha y fallback.

3) Responsabilidad y funciones

4) Jerarquía de MIDs y descriptores

Master MID (plataforma)

└─ Sub-MID (s) por marca/geo/método

└─ Routing Profiles (PSP1→PSP2… cascada)

• Descriptores individuales en sub-MID: menos Disputs.
• Separe las tarjetas/A2A/métodos locales por sub-MID para análisis y control de reservas puros.
• Versione los perfiles de enrutamiento (v1/v2) para A/B.

5) Cascadas: cómo construir

5. 1. Decisión «sobre la marcha»

Al autorizar: seleccionar la ruta por reglas (GEO, BIN/IIN, marca, tarjeta debit/credit, clase de riesgo, límite PSP, AR/DR actual, tarifa/FX, SLA de incidentes).

5. 2. Tipos de cascadas

Consecutivo: PSP_A → (soft decline) → PSP_B → PSP_C.
Paralelo (split-traffic):% del tráfico a diferentes PSPs para benchmarking y descorrelación.
Sticky BIN: asegurar un grupo BIN exitoso para el mejor PSP.

5. 3. Restricciones

Contar idempotency (para no aplastar la captura).
Negociar con PSP reintentos (retry window, soft codes).
Tenga en cuenta las políticas de 3DS y los mayúsculas de liability en cada ruta.

6) Settlement, T + N, reservas y splits

Cada PSP/equairer tiene su cut-off/T + N y su reserva de rolling.
La plataforma suma los recibos a nivel sub-MID y mantiene reserve-ledger con el calendario release.
Pagos a submiembros: net of fees & reserve + su participación (revshare/CPA) en el período de referencia.
Mantenga divididos por transacción (platform/studio/affiliate/tax) o artículo por período.

7) Antifraude, 3DS y límites a nivel submercial

Diferentes umbrales de puntuación para las clases de mercado A/B/C.
3DS-gobernaba por el BIN/geo/cheque (обяз./мягко/step-up).
Velocity-limites (deposiciones/conclusiones, intentos de mapas) y caps por submerciente.
Submerchantes «grises»: límites más estrictos, solo métodos blancos y pagos diferidos.

8) Tarifas y take-rate

Considere la puntuación de toma efectiva por submensaje: fees PSP (interchange/scheme/markup/fixed) + slippage FX + fracción de plataforma + efecto de reserva.
Utilice IC++ y BIN-routing para reducir el costo blended en cascada.

9) Datos y modelo mínimo

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

10. 1. Costo efectivo por submerciente

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. Eficacia de la cascada (AR/DR) según las reglas

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 de reserva por submerciente

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. Cálculo de un submerchante net payable

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

AR/DR por cascada: por GEO/BIN/método/PSP, fracción 3DS, share soft-decline.
Take-Rate% y la pila de componentes fees por submerciente.
CB Ratio/Refund Rate en sub-MID.
Reserva Balance & Release ETA por submercientes/PSP.
Settlement SLA: T+N hit-rate, funding delays.
PayOut Health: frecuencia y montos de pagos a los submercientes, retrasos.
FX Slippage en cascadas (effective vs reference).

12) Alertas y umbrales

Desglose de ruta: caída de AR> Y bps hora-a-hora en la regla.
CB Spike: crecimiento de charjbacks en el submerciente> X bps w/w.
Reserva Imbalance: ledge de reserva - P1.
Settlement Delay: violación de T + N en PSP → auto-switch en cascada.
Take-Rate Spike: aumento de valor> umbral (fees o FX).
Policy Drift: transacciones sin referencia a perfil/rule/idempotency - P1.
Payout Delay: retraso en el pago al submerciente> SLA.

13) Onboarding y cumplimiento de los submerchantes

CUV/sanciones/RR: paquetes de documentos, beneficiarios, fuentes de fondos.
PCI/seguridad: tokenización, prohibición de almacenamiento PAN en el submerciente.
Políticas de reembolsos/bonos: normas uniformes, tickets SLA.
Informes agregados: separados por marcas, geo, métodos.
Límites/capps: revoluciones diarias/semanales, payout-caps, pagos diferidos para high-risk.

14) Mejores prácticas (corto)

1. Versione los perfiles de enrutamiento y almacene los registros explain de las soluciones.
2. Mantenga las pruebas BIN y A/B de PSP para la estabilidad y el precio de AR.
3. Muppite fees/FX/reserva hasta el nivel de submerciente; pague net-of-fees por SLA.
4. Idempotency + retry-policy sólo por soft-decline; cumpla con los límites de PSP.
5. Descriptores y sub-MIDs - exclusivos de la marca/geo: menos dispouts.
6. Ledger de reserva con calendario release y alertas missed-release.
7. Informes transparentes a submerciente: descifrar fees, reserve, FX, disputs.
8. Failover playbooks: la caída de PSP/pasillo es un reroute instantáneo.

15) Lista de verificación de implementación

• Referencias 'submerchants',' routing _ profiles ',' routing _ rules '.
• Protocolos KYB/KYC/AML y almacenamiento de estados.
• Enrutador con idempotency y lógica soft-decline.
• Importar archivos settlement PSP → 'settlement _ fees' + reserve-ledger.
• Mecanismo de payouts a los submerchantes + actos/estamentos.
• Dashboards AR/DR/CB/fees/reserve + alertas.
• Documentos: Política de Disputs, Reglas de 3DS, Límites y SLA.

Los submerciales dan escala y flexibilidad, y las cascadas dan sostenibilidad, conversión y valor manejable. La arquitectura de la jerarquía de MIDs, los perfiles de enrutamiento versionables, la contabilidad transparente de fees/reservas y el estricto cumplimiento convierten un complejo circuito de pago multi-GEO en un sistema predecible: alta autorización, baja tasa de toma, pagos rápidos y un mínimo de sorpresas de riesgo.