Enrutamiento de pagos y failover

Enrutamiento de pagos y failover

1) Por qué es necesario

Conversión: la elección correcta del canal/PSP por BIN/banco/geo/riesgo aumenta la tasa de Auth en 5-15 p.p.
Costo: la elección dinámica por «éxito × comisión» reduce la tasa efectiva en 10-30 bps.
Sostenibilidad: aislamiento de caídas PSP/3DS/bancos; continuación de la recepción y pagos en caso de interrupciones parciales.
Cumplimiento/RG: implementación flexible de límites, restricciones geográficas, autoexclusiones y regulaciones sancionadoras directamente en el enrutamiento.

2) Arquitectura de destino (capas)

1. Checkout Layer - Localización de monedas/métodos, APM discovery, 3DS UX.
2. Orchestrator de pago (Rule Engine) - enrutamiento, retry inteligente, idempotencia, circuit-breaker.
3. Risk/KYT Engine - device/behavior, sanciones/RER, velocity, RG-limites, 3DS-policy.
4. Compliance Hub - KYC, proveedores de sanciones, afiliaciones/límites, auditorías.
5. Wallet & Ledgers - ledgers de dinero y juego, bonos pasivos, multivalor.
6. Reconciliation & Reporting - T + 0/T + 1 conciliaciones, códigos reason, registros fiscales.
7. Observabilidad y seguridad: métricas/logs/traces, alertas, RBAC, segmentación PCI.
8. Data/ML - Puntuación de riesgo, predicción de conversión por banco/método.

3) Modelo de datos e idempotencia

Payment Intent (PI): un único objeto para depositar/pagar con los campos: amount, currency, method, geo, BIN, risk_score, rg_limits, route_history, idempotency_key, status.
Idempotencia: cada hop (PSP-A → PSP-B) se realiza con un solo idempotency_key; la repetición de llamadas no cambia el estado del guardabosques.
Route Journal: el registro de rutas y respuestas (PSP id, reason code, latency, 3DS flow, fee), es necesario para A/B y formación de modelos.

4) Algoritmo de enrutamiento (referencia)

4. 1 Recepción (Acquiring)

1. Pre-puntuación: GEO, BIN/IIN, banco emisor, dispositivo, cheque, riesgo-score, estado RG.
2. Filtros de cumplimiento: sanciones/RER, geo-bloques, edad/auto-exclusión.
3. Reglas de costo/éxito: score = w1· AuthRate + w2· (−Fee) + w3· Salud − penalties.
4. Política 3DS: TRA/whitelisting/step-up en riesgo, selección de challenge vs frictionless.
5. Selección de ruta: PSP-A → (en fallos/errores) → PSP-B → método alternativo (APM/banca abierta).
6. Smart Retry: cambio de modo 3DS, MID, mcc/fallback, tiempo-becoff por códigos reason (05/51/62 ≠ 91/96).
7. Post-processing: grabación en Route Journal, actualización de escalas.

4. 2 Pagos (Payouts)

1. Priorización: velocidad (instant/near-instant) ↔ costo ↔ disponibilidad.
2. KYT/AML/RG: velocity, patrones «abrazados», límites, fuente de fondos, listas de excepciones.
3. Enrutamiento: card-to-card OCT/RTP/Faster Payments/SEPA Instant/Pix/UPI.
4. Failover: cheued payouts si el banco/PSP no está disponible, cola de drain periódica.
5. Confirmation: webhooks con firma que compensan las transacciones en caso de discrepancias.

5) Patrones de falla

5. 1 Circuit-breaker

Local (en PSP): se activa cuando se error_rate↑, latency↑, spike in declines (issuer-specific).
Global (por método): con un fallo de la industria (por ejemplo, ACS/3DS de un gran banco).
Estados: Cerrado → Abierto → Medio-abierto; los tiempos de espera y los umbrales se establecen por segmentos GEO/BIN.

5. 2 Active-Active vs Active-Passive

Active-Active: PSP/métodos paralelos; Equilibrio de reglas/costo; mejor RTO/RPO.
Active-Passive: ahorros en comisiones/soporte, pero más tiempo que RTO; apto para GEO/métodos secundarios.

5. 3 Degradation Modes

Desactiva los métodos de alto riesgo, transfiere parte del tráfico a banca abierta/APM.
Forzado 3DS desafío-todo para «quemar» BIN-bancos.
Límite de tiempo por sumas/frecuencia (riesgo RG +).

6) Trabajar con 3DS/SCA (dinámicamente)

Frictionless por defecto en cheques de bajo riesgo/pequeños, challenge - en los de alto riesgo.
Excepciones PSD2: LVA, MOTO, MIT - en el orquestador, no en la aplicación.
Fallback: al degradar ACS, aumenta la tasa de desafío o desplaza temporalmente el tráfico hacia un método alternativo (banca abierta).
KPI: challenge rate, frictionless share, post-3DS approvals.

7) Integración con antifraude/KYT/RG

Antes del enrutamiento: puntuación (dispositivo, comportamiento, proxy/VPN, riesgo BIN, historial).
En enrutamiento, seleccione 3DS/canal/PSP por risk_score.
Antes del pago - KYT/velocity/anti-arb (win→withdraw rápido, tarjetas múltiples, dispositivos relacionados).
Los límites de RG y la autoexclusión son reglas de parada «rígidas» a nivel de orquestador.

8) Observabilidad y datos

Métricas en tiempo real: auth_rate, decline_reason mix, p95 latency, PSP health, 3DS success, payout time, queue depth.
Alertas: umbrales por bancos/métodos, pegamento con páginas de status externo.
A/B & Lerning: actualización de los pesos de enrutamiento basados en la conversión/costo; grupos de control sin retraídas para calibración.

9) KPI y puntos de referencia de destino

Auth Rate (mapas): EU 85-92%, US 80-88%, LATAM 70-85% (sin orquestación - borde inferior).
p95 latency auth API: < 3 c; webhooks: < 60 c.
Share of Instant Payouts: ≥ el 70% de los cheques «ligeros».
Eficacia de enrutamiento (conversión ÷ costo): + 5-10% a la baselina en un trimestre después de la afinación.
Circuito-break RTO: <2 min para cambiar; RPO: 0 (idempotencia).
Chargeback rate: < 0. 5% por cuenta (depende del producto/GEO).

10) Incidencias de Playbucks (parche)

10. 1 Declines masivos por banco emisor

1. Confirmar spike por BIN/issuer.
2. Abrir un circuit-breaker local → redistribuirlo a alt-PSP/método.
3. Aumentar la tasa de desafío para los afectados por BIN, habilitar la retracción inteligente.
4. Comunicación a los canales de estado; RCA con datos de códigos reason.

10. 2 Caída 3DS/ACS

1. Detecto de crecimiento timeouts/» soft decline».
2. Transferir parte del tráfico a open banking/APM; incluir «challenge-all» donde ACS está vivo.
3. Reducir el cheque de riesgo (límites de cantidad/velocidad), reforzar la supervisión.

10. 3 Inestabilidad PSP

1. Funcionó una alerta de salud → un breaker abierto.
2. Transferencia a PSP/MID de respaldo; prohibición de métodos «pesados» con alta latencia.
3. Recuperación a través de medio abierto con canarios (1-5% de tráfico), luego gradación.

10. 4 Retrasos en los pagos

1. Transferencia a cheued payouts con prioridades (VIP, límite de importe).
2. Mover la pieza a vías alternativas (RTP/FPS/SEPA Instant/Pix).
3. Notificaciones transparentes a los jugadores; Escalaciones manuales> Horas X.

11) SLA y anclajes contractuales (qué exigir al PSP)

Disponibilidad: ≥ 99. 95% de admisión; p95 latency < 3 c; webhooks < 60 c.
Incidentes: TTA ≤ 15 min, solución (MID/APM fallback), RCA ≤ 5 días.
Datos: códigos de reason crudos, detalles de los bancos, devoluciones de tokens ≤ 10 días a la salida.
Finanzas: limitación de reservas/holdback, fees transparentes (incluidos 3DS/network tokens), cap en recargos FX.
Seguridad: PCI-AOC, firmas webhooks, key rotation, SOC 2/ISO 27001 (preferiblemente).

12) Patrones regionales

EC/UK: PSD2/SCA; tarjetas + banca abierta (SEPA Instant/FPS). Fuerte orquestación 3DS, TRA y whitelisting.
Estados Unidos: tarjetas + ACH; prioridad de pago instantáneo (push-to-card, RTP). Los circuitos Charjback son obligatorios.
LATAM: Pix (BR), SPEI (MX), PSE (CO); APM-heavy; enfoque en el riesgo de desvío y el documento-KYC.
Turquía/CA: transferencias/carteras locales; circuito sancionador reforzado/AML, límites de cantidad/velocidad.
Asia/India: carteras UPI/E; Reglas velocity estrictas; Enrutamiento por bancos emisores.

13) Hojas de verificación de implementación

Arquitectura/datos

• Payment Intent + idempotencia en todos los hops.
• Route Journal, códigos reason crudos, webhooks con firma.
• Separación de los administradores de dinero/juegos; transacciones compensatorias.

Enrutamiento/reglas

• Motor de regla por GEO/BIN/issuer/riesgo/costo.
• Smart retry con tiempo-bekoff y cambio de 3DS/MID.
• Circuit-breakers locales y globales; canary-reintegro.

Riesgo/cumplimiento

• Integración de risk/KYT/RG antes y después del enrutamiento.
• Sanciones/RER, edad/autoexclusión - como filtros «rígidos».
• Límites de velocity/sumas; Registro de soluciones.

Observabilidad/SLA

• Dashboards por Auth Rate, latency, decline mix, payout time.
• Alertas por umbrales; runbooks sobre incidentes.
• SLA en el contrato, QBR y multas por infracciones.

14) Pseudocódigo de estrategia (para el equipo)

on PaymentRequest(PI):
ensureIdempotency(PI.key)
risk = RiskEngine.score(PI)
if not ComplianceHub.pass(PI, risk): reject()

candidates = RouteCatalog.filter(PI.geo, PI.method, PI.bin, risk)
for route in rankBy(Score(AuthRate, Fee, Health, Risk), candidates):
res = PSP.call(route, PI, policy=ThreeDS.select(risk))
log(RouteJournal, route, res)
if res.approved: return approve(PI)
if isRetryable(res.reason): continue with SmartRetryAdjustments()
return decline(PI)

15) Economía y optimización A/B

Считайте effective rate = (Fees + 3DS + FX + chargeback cost − interchange rebates) / Approved Volume.
A/B: mínimo de 10k transacciones/rama, 2-4 semanas; fijar por bancos/métodos.
Optimice los pesos de AuthRate vs Fee por GEO/estacionalidad; controle el «sesgo» en rieles caros pero de conversión.

16) Lo que es importante recordar

Orquestrador + reglas + datos - el corazón de la sostenibilidad de pagos y la conversión.
Idempotent/Payment Intent elimina el doble cargo y simplifica el failover.
Circuit-breakers y canary-return proporcionan una estabilización rápida sin «swing».
Los SLA contractuales y los datos transparentes de PSP no son una opción, sino un requisito.
Los raíles regionales (open banking, RTP, Pix/UPI) a menudo son mejores que los mapas en velocidad/costo - tenga en cuenta en el enrutamiento.