Diversificación de proveedores y rieles
TL; DR
Un proveedor = un SPOF. El modelo de trabajo es un portafolio de rieles y proveedores con routing inteligente: un proveedor básico y de respaldo para cada método crítico, un failover automático ≤ 10 min, control SLA y límites de tesorería. Objetivo: AR↑, TtW/TtR↓, Cost/GGR↓, riesgo de kontsentratsii↓, mientras que - UX predecible y cumplimiento de licencias.
1) Por qué diversificar
Conversión (AR/Capture): diferentes acuarios/PSP muestran diferentes uplift por BIN/país/ECI.
Fiabilidad: Failover cuando se degradan las API/webhooks/settlement.
Alcance de los métodos: ARM locales/monederos/vales/raíles bancarios.
Costo: competencia por comisiones/FX/fees, optimización de costo/GGR.
Cumplimiento/sanciones: alternativas en bloques/restricciones regionales.
Tesorería: balance prefundado en diferentes rieles, flexibilidad de liquidez.
2) Mapa del carril (portafolio por capas)
Tarjetas (Visa/Mastercard/Local) - alto porcentaje de facturación, sensible a BIN/3DS2/emisores.
A2A/Open Banking/PIX/UPI/Sofort - bajo costo, barrido rápido, diferentes UX.
RTP/Instant/SEPA/ACH/SWIFT - Conclusiones y grandes sumas, horarios T + N.
Wallets (Skrill/Neteller/... )/Super-apps - UX rápido, límites/regionalidad.
Vouchers - fuera de línea/caché en dígitos, aumento de los riesgos de abusivos.
Crypto On/Off-ramp es global, pero se requieren políticas de cobertura y AML.
Regla: por cada rama crítica, un mínimo de 2 proveedores (Primary/Secondary), y en Cards, 2 + acuarios por región.
3) Arquitectura: cómo se ve el contorno multi-controlador
Payment Orchestrator/Router: decide dónde enviar el intento (por la matriz de reglas y los indicadores en línea).
Feature-flags: nebulizadores instantáneos para failover/degradación.
Idempotency & Replay-bus: clave única para intentar, retraídas seguras.
Webhook Hub: dedoop/retray/polling-back.
Treasury Layer: límites prefundidos en rieles, reservas de estrés, FX.
Recon Layer: registros unificados, correlación de settlement↔bank.
Monitor SLA: comparación de métricas de proveedores con nuestras telemetrías.
4) Smart-routing: estrategia y señales
4. 1 Señales para seleccionar un proveedor
AR/Soft-decline по BIN×issuer×country×device.
Latency p95/p99, fracción de tiempo de espera.
3DS fricción (challenge share, abandon).
Costo (fee %/fixed, FX, spread).
Frod/call (chargeback/friendly share).
Ventanas temporales (noche/días festivos), incidentes/trabajos.
4. 2 Políticas de enrutamiento (ejemplo)
Performance-first: máximo de AR cuando se limita el costo/GGR.
Coste-aware: con igual AR - hacia un proveedor barato.
Risk-aware: high-ticket/new users → un proveedor/flow más estricto.
Geo/BIN-affinity: listas blancas de acuarios «fuertes» por emisor/país.
Fair-share: no permitir la monoconcentración (> X% de la facturación diaria en una sola contraparte).
5) Feilover: reglas y SLO
Desencadenantes: 'AR_gross↓> 3 p.p. a p7', 'Auth p95> 1. 5s`, `Webhook p95>5s`, `Success Payout↓`, `Settlement on-time<99%`.
Acciones: cambiar a Secondary, limitar los retiros, pausa en auto-refundido/pagos de auto peligroso.
SLO: Auto-Feilover ≤ 10 min, retorno de la proporción de tráfico por etapas (25%→50%→100%) después de la estabilización en intervalos N.
6) Tesorería y liquidez en diversificación
Prefund en rieles de pago en ambos proveedores (rodando p95 + 20%).
StressRes en caso de retrasos de settlement en Primary.
FX/Costo: Tenga en cuenta los cargos/spreads ocultos al routing.
Límites de contrapartida: día/semana por saldo/volumen de negocios; barridos diurnos.
7) SLA y contratos
API Uptime/Latency, Webhook SLA, Settlement Timeliness, Report Delivery.
Créditos de servicio por infracciones; termination right cuando se realiza la sistemática.
Change-notice ≥ 30 días por esquema/registro; pilotos de sandbox y un plan de retroceso.
KYC/AML/Sanctions, DPA/PCI/SOC, breach ≤ 24h.
8) Scorecard proveedores (puntuación 0-5)
Solución: el tráfico y las prioridades de routing son en términos de puntuación total con pesos (por ejemplo, conversión del 40%, confiabilidad del 30%, finanzas del 20%, el 10% restante).
9) KPI de cartera
AR_net ↑, Capture_Success ↑.
Payout Success %, TtW p95 ↓, Refund TtR p95 ↓.
Costo/GGR ↓ (en el riel y en general).
Concentration Risk ↓ (máxima participación del proveedor).
Failover Time (mediana/p95), Incidents/Month, Service Credits/Month.
10) Modelo de datos (escaparate de routing/evaluación)
ts_utc, country, provider, rail (card/a2a/rtp/wallet/voucher/crypto),
bin, issuer_country, device_os, ticket_bucket,
auth_attempted, auth_approved, captured_tx,
latency_auth_ms_p95, webhook_delivery_sec_p95,
fees_fixed, fee_pct, fx_spread_bps,
payout_attempted, payout_success, ttw_p95_sec,
settlement_date, settlement_on_time_flag
11) Cortes SQL (ejemplos)
11. 1 Scorecard por proveedor
sql
WITH base AS (
SELECT provider, rail,
AVG(captured_tx::decimal / NULLIF(auth_attempted,0)) AS ar_net,
PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY latency_auth_ms_p95) AS p95_latency,
AVG(payout_success::decimal / NULLIF(payout_attempted,0)) AS payout_succ,
AVG(ttw_p95_sec) AS ttw_p95,
AVG(settlement_on_time_flag::int) AS settle_on_time,
AVG(fees_fixed + fee_pct) AS avg_cost_idx
FROM provider_daily_metrics
GROUP BY 1,2
)
SELECT FROM base ORDER BY rail, ar_net DESC;
11. 2 A/B uplift routing (PSP_A→PSP_B)
sql
SELECT rail, country, bin,
AVG(CASE WHEN route='A' THEN captured_tx::decimal/NULLIF(auth_attempted,0) END) AS ar_A,
AVG(CASE WHEN route='B' THEN captured_tx::decimal/NULLIF(auth_attempted,0) END) AS ar_B,
(AVG(CASE WHEN route='B' THEN captured_tx::decimal/NULLIF(auth_attempted,0) END)
-AVG(CASE WHEN route='A' THEN captured_tx::decimal/NULLIF(auth_attempted,0) END)) AS uplift
FROM routing_experiments
GROUP BY 1,2,3
ORDER BY uplift DESC;
11. 3 Concentración por proveedores
sql
SELECT date, provider,
SUM(captured_amount) AS amt,
SUM(SUM(captured_amount)) OVER (PARTITION BY date) AS amt_total,
SUM(captured_amount)::decimal / NULLIF(SUM(SUM(captured_amount)) OVER (PARTITION BY date),0) AS share
FROM provider_settled
GROUP BY 1,2
ORDER BY date DESC, share DESC;
12) Playbucks
P0: caída de AR en Cards (DE/FR BIN-cluster)
Acciones: Failover en Aquyer _ En, elevar la 3DS-challenge a un clúster BIN, limitar retraídas, incluir una sugerencia de método alternativo.
P1: payouts de retraso en Wallet_X
Acciones: routing en Wallet_Y/RTP, reponer payout-pool, priorizar VIP, mensaje de estado a los jugadores.
P1: Webhook rebezg en PSP_A
Acciones: cambiar a polling, congelar auto-refundiciones, mejorar la idempotencia, la conciliación con los informes.
P2: Crecimiento del costo/GGR en A2A_B
Acciones: traducir bajo-ticket a A2A_C, solicitar descuento/memo de crédito por SLA, comprobar FX/spreads.
13) Riesgos y cómo controlarlos
Concentración: límite máximo de la cuota de volumen de negocios/balance por contraparte (día/semana).
Operativo: SPOF webhooks, ningún polling-backup - ponga ambos.
Regulador: prohibiciones/límites locales - Alternate rails por países.
Tesorería: pools de pago no financiados - rolling p95 + buffer.
FX/Costo: comisiones ocultas/mercado-impacto - monitoreo de slippage.
Seguridad: Sanciones/AML - Detección única en la entrada y en los pagos.
14) Implementación: hoja de ruta
1. Auditoría de rieles y proveedores actuales: métricas, incidentes, costo.
2. RFP/contratos: SLO/préstamos, informes, sandbox/rollback.
3. Orquestador/enrutamiento: reglas, señales en línea, banderas de fijación.
4. Tesorería: límites prefund/StressRes, barridos y política FX.
5. Monitoreo/dashboards: AR/Latency/Webhook/Settlement/Cost.
6. Drills Feilover: mensuales (Cards/A2A/Wallet/Payout).
7. QBR con tarjeta Score: revisión de prioridades/cuota de tráfico.
15) Paquete de caso UAT
Failover ≤ 10 min: dañar artificialmente el PSP_A, asegurarse de la estabilidad de AR en el PSP_B.
Idempotency: retrae en tiempo de espera → 1 cargo/1 refund.
Webhook outage: cambiar a polling sin tomas/pérdidas.
Payout reroute: Wallet_X down → RTP/SEPA success p95 ≤ SLO.
Settlement mismatch: «Suspense» proceso y corrección correcta.
Ruta A/B: uplift estadísticamente significativo por BIN × GEO.
16) Errores frecuentes
Monoprovider en el carril crítico - la ausencia de Feilover.
Enrutamiento «por sensaciones» - sin señales en línea y verificación A/B.
No hay límites de concentración y prefundidos - saltos de caja en los pines.
Webhook sin reserva de polling - pérdida de eventos/toma.
Mezcla de bases métricas - conclusiones incorrectas sobre AR/costo.
La falta de SLA/créditos es la débil motivación del proveedor para corregir.
Resumen
La diversificación es una estrategia de cartera: mix raíl y proveedores + routing inteligente + failover automático + tesorería + SLA rígidos. Este circuito aumenta la conversión, reduce el costo, proporciona resistencia a incidentes y choques regulatorios, y hace que la monetización de pagos sea predecible y manejable.