En cascada a nivel de proveedor

1) Qué es la cascada y por qué está en iGaming

• AR↑/ DR↓: eludir los emisores «caprichosos», elegir el mejor PSP para un BIN/geo/método específico.
• Costo de ↓: IC + +/markup es menor en las partes de la cesta, minimizando la fix fia en el micro-ticket.
• Sostenibilidad: falla en incidentes, degradación de 3DS, caída de corredores de pago.
• Cumplimiento: cumplimiento de geopolíticas, sanciones, prohibiciones locales y licencias.

2) Patrones de cascada

1. Secuencial (sequential)

PSP_A → (soft-decline/tehnichesky la renuncia) → PSP_B → PSP_C.
Se utiliza la «ventana estrecha» de los retraídos para no crear tomas/riesgos de múltiples fondos.

2. Paralelo (split-traffic/multi-arm)

Distribución del flujo (%/reglas) entre varios PSPs de referencia, formación de reglas y reducción de fallos correlacionados.

3. Sticky BIN / Sticky GEO

Recuerde el «mejor» PSP para una banda BIN específica/emisor/geo (cachés de soluciones con TTL).

4. Method-aware / Feature-aware

Diferentes proveedores de tarjetas, A2A, carteras, métodos locales; teniendo en cuenta la especificidad de la 3DS-rails, el comportamiento DCC/FX, la tokenización.

5. Limit-aware / SLA-aware

Contabilice los límites de proveedores, reservas, incidentes de SLA, cortes y retrasos de funding.

3) Motor decisivo (rules-engine): señales de entrada

Señalización de la tarjeta: BIN/IIN, marca, debit/credit, comercial/premium, country of issuer.
Geo y cumplimiento: país del jugador (IP/GPS/SIM/KYC), sanciones, licencias.
Transacción: cantidad (unidades menores), moneda, canal (web/app), riesgo-score.
Historial de proveedores: AR/DR por BIN/geo/método en los últimos 15-60 minutos, fracción soft-decline, 3DS-pass-rate.
Costo: IC + +/markup/fix, FX-spread, rolling reserve%.
Restricciones: proveedor de rate-limit, mantenimiento/incidentes, gotas de circulación diurna.

Salida: lista prioritaria de rutas '[(PSP, MID, require_3DS, retry_window_ms, max_attempts)]'.

4) Retraídas, idempotencia y seguridad

Idempotency-key para el intento (user_id+order_id+nonce), común a todos los proveedores en cascada.
Retrase sólo en soft-decline (fondos de red/3DS/timeout/insufficient), nunca con códigos «duros» (stolen, do not honor repetidamente, etc.).
Anti-dooling: el estado 'AUTHORIZED '/' CAPTURED' cierra la cascada; Todas las demás ramas se cancelan.
Ventanas: 1er Retray ≤ 2-5 segundos, presupuesto total ≤ 15-30 segundos con UX en mente.
Política de 3DS: es posible pasar a la segunda/tercera rama si la primera cayó sin 3DS.

5) 3DS, liability shift и AR

La elección de 'frictionless '/' challenge' depende del riesgo y del soporte PSP (delegated auth, TRA, whitelisting).
En geo/emisores «duros» - 3DS forzado en la parte de la papelera de reciclaje.
Realice un seguimiento de los shift de liability por proveedor: donde es más probable que se logre - llevar los BIN's arriesgados allí.

6) Costo: IC++, blended, fix fii y FX

Para cada PSP, considere el efecto take-rate = interchange + scheme + markup + fixed + FX-slippage.

• `Score = w1AR_live + w2(−Cost_bps) + w3(SLA_health) + w4(FX_quality) +...`
• Micro-ticket: el peso de la fix fia es mayor → los proveedores de fix bajo preferidos.
• Tenga en cuenta por separado reserve% y funding T + N: afecta al flow de caché.

7) Incidentes, corte-apagado y enrutamiento

Health feed: estados PSP/corredores (auth API, 3DS ACS, payout rails).
Auto-failover: reroute instantáneo cuando AR/health cae por debajo del umbral.
Cut-off-aware: antes de cerrar la pantalla, evite la captura parcial en PSP con un T + N incómodo.
Throttling: para no «quemar» el límite del proveedor, divulgue el tráfico.

8) Modelo mínimo de datos

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) Plantillas de análisis SQL

9. 1. Clasificación de proveedores en línea (AR y 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. Efecto de cascada en los pedidos (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: el mejor proveedor 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. Costo por proveedor (precio todo en uno)

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

AR/DR por proveedor y BIN/geo/método (ventanas en línea 15/60 min y día a día).
Step-conversion: porcentaje de aprobaciones en 1ª, 2ª, 3ª rama.
Take-Rate% y FX-slippage por proveedor/MID.
3DS pass-rate y shift de liability shift.
Salud/SLA: latency, timeouts, error rate, incidentes.
Reserve & Funding: reserve% y T + N hit-rate por proveedores.

11) Alertas y umbrales

Degradación de enrutamiento: caída de AR en el proveedor seleccionado> Y bps en 10-30 minutos.
Soft-decline surge: el crecimiento de la proporción soft-decline → permitir una rama adicional de la cascada.
3DS Anomaly: caída de 3DS pass-rate> X% en un determinado emisor/clúster BIN.
Take-Rate Spike: aumento de valor todo-en> umbral bps.
Health Down: SLA breach (latency/error) — авто-failover.
Policy Drift: intentos sin idempotency_key/bez perfil de cascada - P1.

12) Pruebas AB y normas de formación

Multi-arm bandit o split-traffic fijo para nuevas rutas.
Explore/Exploit: parte del tráfico de mantener en «aprendizaje» sticky BIN.
Horizontes de valoración: online (15/60 min) para incidencias y semana/mes para el coste.
Guardrails: mínimo AR/max-rate para detener el experimento.

13) Cumplimiento y casos «extremos»

Respetar las sanciones/licencias/geobloqueos: algunos proveedores no pueden servir a países/métodos individuales.
Same-method/Return-to-source: la cascada no debe romper la política de devoluciones.
Tokenization/PCI: un único esquema de token entre PSP (network tokens/vault).
Chargebacks: lógica a través de qué rama ha pasado la captura - para Disputs.

14) Mejores prácticas (corto)

1. Retira sólo soft-decline, con un solo idempotency_key.
2. Mantenga la telemetría en vivo de los proveedores de AR/3DS/soft-decline y salud.
3. Construya la función de precio de la ruta (AR vs Costo vs SLA vs FX).
4. Utilice las pruebas BIN y AB sticky; versionar los perfiles de cascada.
5. Sé cut-off-aware: no fructifiques una partial-capture al final del día.
6. Tener playbooks failover: caída PSP/ACS/pasillo de pago.
7. Comparta los datos y la responsabilidad: quién tiene el PAN, quién lidera las dispouts.
8. Mantenga reserve-ledger por proveedor: lanzamientos y cargos.

15) Lista de verificación de implementación

• Mapa de proveedores/MID, prising (IC + +/blended), políticas FX, reservas, T + N.
• Rules-engine: perfiles, reglas, soft-codes, políticas de 3DS, límites.
• Router: idempotencia, retraídas, temporizadores, caché BIN sticky.
• Telemetría: métricas en vivo AR/DR/3DS/latency/health; alertas.
• Gestión de incidentes y failover playbucks.
• ETL para fees/FX/reserve; vitrinas take-rate y step-conversion.
• Procedimientos de pruebas AB y guardrails.
• Documentación: restricciones de cumplimiento, devoluciones de same-method, responsabilidad.

Resumen

La cascada a nivel de proveedores no es «probar otro PSP», sino una disciplina: métricas en vivo, rules-engine inteligente, idempotencia estricta, tácticas 3DS correctas, contabilidad de costos/FX/reservas y scripts failover listos. Esta arquitectura aumenta la RA, reduce la tasa de toma y hace que el circuito de pagos sea resistente a las interrupciones y restricciones regulatorias.