Plataformas de orquestación de pagos

1) Qué es POP y por qué se necesita en iGaming

• Aumenta la AR y reduce la RD mediante routing/cascadas inteligentes (BIN/GEO/método/precio/salud).
• Reduce el costo (IC + +/markup/fixed/FX-slippage) a través de la selección de proveedores smart-routing y A/B.
• Mejora la resistencia: failover, circuit-breaker, muestras de salud, degradación a modos seguros.
• Acelera el go-to-market: una sola API/SDK, directorio de adaptadores, administración de políticas sin versiones.
• Asegura el cumplimiento: KYC/AML/sanciones, geobloqueos, same-method, MoR/submercientes.
• Simplifica la presentación de informes: normalización de los estados, ficheros de contenido, escaparates ND/GGR/NGR/fees/impuestos.

2) Build vs Buy: cómo elegir

Comprar (POP externo): inicio más rápido, adaptadores/dashboards/SLA terminados; contras - margen del proveedor, profundidad limitada de la personalización, vendor lock-in.
Build (in-house): control total de las reglas/datos/precio; contras - CAPEX/competencias/procesos SOC2.
Híbrido: mercados/métodos críticos - en casa, «cola larga» - a través de POP externo.

Criterios: cobertura GEO/métodos, latencia, transparencia de precios, acceso a datos raw y webhooks, soporte de tokens/3DS2 de red, orquestación de pago, sandbox, versión API, SLA/penalti.

3) Arquitectura de destino POP (capas)

1. API-Gateway & Auth — rate-limit, OAuth/JWT, mTLS, schema-validation, idempotency-keys.
2. Rules-Engine - Políticas declarativas (GEO/BIN/método/suma/riesgo/precio/SLA/sanciones).
3. Router/Cascader — выбор `(PSP, MID, require_3DS, retry_window, max_attempts)`; sticky BIN/GEO.
4. Provider Adapters es una interfaz unificada (authorize/capture/refund/void/payout/tokenize).
5. 3DS & Risk Orchestration - TRA/whitelisting, challenge/funnel, autentica delegada.
6. Reconciliation - importación de archivos de settlement, mapping de códigos, espaciamiento fees/reserve.
7. Payout Orchestration - selección del corredor, same-method/return-to-source, cut-off/T + N, validación.
8. Treasury/FX - Libros de monedas múltiples, EOD-reval, FX realizado/unrealizado, previsión de liquidez.
9. La Plataforma de Datos es un bus de eventos (Kafka/PubSub), outbox, DWH/lags, escaparates ND/GGR/NGR/fees/tax.
10. Observabilidad - logs/métricas/tracks, SLO/SLI, alertas, incidentes de playbooks.
11. Admin/UI - Administrar reglas, pruebas AB, pasillos de pago, límites, claves.

4) Enrutamiento y reglas: señales de entrada

Карта: BIN/IIN, brand, debit/credit, commercial/premium, issuer country.
Geo/Compliance: IP/GPS/SIM/KYC country, planillas, licencias, clase de mercado (A-D).
Transacción: Cantidad/Moneda/Canal, Velocity, Riesgo-Score Frod, Estado 3DS.
Proveedores: AR/DR, soft-decline%, 3DS pass, latency/bugs, SLA health.
Costo: IC + +/markup/fixed, FX-quality, reserve%, funding T + N.
Restricciones: límites PSP, mantenimiento, incidentes, prohibiciones locales.

• `Score = 0. 45AR_live − 0. 25Cost_bps + 0. 15SLA_health + 0. 10FX_quality + 0. 05Reserve_score`

Política de retiro: sólo soft-decline; idempotency-key común a toda la cascada; Presupuesto de 15-30 segundos.

5) 3DS и liability shift

Estrategias: Escalamiento frictionless→challenge, 3DS coercitivo en riesgo-GEO/BIN, auth delegado.
Almacene el resultado (liability_shift=true/false), códigos ACS/DS para las pantallas.
Política A/B 3DS: equilibrio AR vs liability.

6) Tokenización

tokens de red (Visa/MC/DC): estabilidad AR, menos errores de lifecycle.
Vault tokens: caja fuerte única → multi-PSP; mapeo de tokens específicos de PSP.
Rotación PAN/expiry, actualizaciones COF/COFT, indicadores de tarjeta-on-file, registro DS.

7) Reconciliación y costo

Normalización de los estados (authorize/capture/refund/chargeback/representment).
Importación de archivos settlement: descomposición de Interchange/Scheme/Markup/Fixed/FX/Reserve.
Cálculo de la tasa de toma efectiva y la ranura FX por PSP/método/MID/GEO.
Informes Variance: 'Tx → File → Funding' (delta> umbral → ticket).

8) Payout-orquestación y trejerie

Corredores: selección del proveedor por GEO/moneda/banco, retorno-tasa/ETA/SLA.
Políticas: same-method/return-to-source, niveles SoF/KYC, pagos diferidos (T + N + K).
FX: selección de divisas de origen, saldos EOD-reval, FX realizable en funding/payout.
Reservas: rolling/reserve-ledger y calendario de lanzamientos.

9) Seguridad y cumplimiento

SANCTIONS/PEP/AML: cribado centralizado, kill-switch por GEO/contrapartida.
PCI DSS: mTLS, segmentación PAN-scope, loging prohibido de campos sensibles, P2PE/SDK.
GDPR/Privacidad: DPA, roles Controller/Processor, DSR/DSAR, períodos de retención.
Regulación de iGaming: geobloqueos, licencias, RG/autoexclusión, formatos de informes de reguladores.

10) Observabilidad, SLO e incidentes

SLI/SLO: AR, 3DS pass, p95 latency, error-rate, funding T+N hit-rate, payout ETA.
Алерты: routing degradation, soft-decline surge, 3DS anomaly, take-rate spike, health down.
Playbooks: failover PSP/ACS, reroute GEO/BIN, desactivar la regla problemática, degradarse a «sólo métodos blancos».
Post-incidentes: RCA, cambios de pesos/umbrales, pruebas de regresión.

11) Data & BI capa

Event-driven: outbox → Kafka/PubSub → consumers (router, 3DS, antifraud, DWH).
Exactly-once (prácticamente): patrón de outbox, consumidores idempotentes, desduplicación por claves.
Витрины: `transactions_flat`, `provider_fees`, `fx_settlement`, `ggr_rollup`, `vat_ledger`, `payout_corridors`, `reserve_ledger`.
AB-тесты: bandits/splits, guardrails (min-AR, max-take-rate).

12) Modelo de referencia de datos (simplificado)

sql
-- Providers/MID/ref methods. providers(provider PK, pricing_model, fx_policy, reserve_pct, meta)
ref. mids(mid PK, provider FK, country, method, descriptor, enabled, meta)

-- Profiles/routing rules ref. routing_profiles(profile_id PK, name, version, enabled, meta)
ref. routing_rules(
rule_id PK, profile_id FK, iso2, bin_from, bin_to, method,
provider, mid, require_3ds, priority, retry_soft JSONB,
max_attempts, ttl_seconds, enabled, meta)

-- Online provider metrics (sliding window)
live. provider_stats_15m(
provider, method, iso2, bin6, approvals, declines, soft_declines,
three_ds_pass, avg_latency_ms, updated_at)

-- Transactions/attempts with payments idempotency. auth_attempts(
attempt_id PK, idempotency_key, step, provider, mid, require_3ds,
status, decline_code, amount_minor, currency, bin, iso2,
started_at, finished_at, meta)

-- Settlement/fees/reserve finance. settlement_fees(
batch_id, provider, mid, period_start_at, period_end_at, currency,
interchange_amt, scheme_amt, markup_amt, auth_amt, refund_amt,
cb_amt, gateway_amt, fx_spread_amt, reserve_delta, total_fees)

treasury. reserve_ledger(
id PK, provider, mid, hold_date, release_due_date,
hold_amount, released_amount, cb_consumed, fines_consumed, status, meta)

-- Payout corridors. corridors(
corridor_id PK, from_iso2, to_iso2, method, provider,
success_rate_7d, return_rate_7d, avg_eta_hours, status, updated_at)

13) Ejemplos de reglas y consultas

13. 1. Pseudo-DSL reglas de enrutamiento

yaml rule: "cards_eu_low_risk_v2"
when:
iso2 in [DE, NL, AT, FI] AND method == "CARD"
AND bin. issuer_country == iso2 score:
AR_live: 0. 45
Cost_bps: -0. 25
SLA_health: 0. 15
FX_quality: 0. 10
Reserve_score: 0. 05 routes:
- psp: "Acq_A" mid: "A_DE_01" require_3ds: false max_attempts: 1
- psp: "Acq_B" mid: "B_EU_02" require_3ds: true max_attempts: 1 retry_on_soft: [TIMEOUT, ISSUER_UNAVAILABLE, SOFT_DECLINE]
budget_ms: 20000

13. 2. Clasificación de proveedores en línea

sql
SELECT provider, method, iso2,
SUM(approvals) appr, SUM(declines) 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;

13. 3. Costo por proveedor (precio todo en uno)

sql
SELECT provider,
SUM(total_fees) / NULLIF(SUM(t. amount_reporting),0) 100 AS take_rate_pct
FROM finance. settlement_fees f
JOIN dw. transactions_flat t ON t. provider=f. provider
WHERE f. period_start_at>=:from AND f. period_end_at<:to
GROUP BY 1
ORDER BY take_rate_pct;

13. 4. Efecto de cascada (step-conversion)

sql
WITH s AS (
SELECT idempotency_key, MAX(step) steps, BOOL_OR(status='APPROVED') approved
FROM payments. auth_attempts
WHERE started_at BETWEEN:from AND:to
GROUP BY 1
)
SELECT steps, COUNT() orders,
100. 0 SUM(approved::int) / NULLIF(COUNT(),0) AS conv_pct
FROM s GROUP BY 1 ORDER BY 1;

14) KPI y dashboards

AR/DR por PSP/MID/GEO/BIN/método (15/60-min ventana + DTD).
Step-conversion (1ª/2ª/3ª rama).
Take-Rate% y FX-slippage por proveedor/método.
3DS pass-rate и liability shift.
Salud/SLA: latency, timeouts, error-rate, incidentes.
Reserve & Funding: reserve% и T+N hit-rate.
Payout Corridors Health: success/returns/ETA.
Policy Coverage: proporción de eventos con una versión actualizada del perfil.

15) Alertas y umbrales

Routing Degradation: caída de AR> Y bps en 10-30 min.
Soft-Decline Surge: la proporción de soft-decline está creciendo → incluir la rama dop./step-up 3DS.
3DS Anomaly: una caída de la tasa de paso> X% en BIN/emisor/PSP.
Take-Rate Spike: aumento de valor todo-en> umbral.
Health Down: SLA breach (latency/error) — авто-failover.
Policy Drift: intentos sin idempotency_key/bez de perfil - P1.
Settlement Delay: infracción de la reserva T + N o missed-release.

16) Mejores prácticas (corto)

1. Idempotencia y retraídas solo por soft-decline, clave compartida por cascada.
2. Telemetría en vivo AR/3DS/latency/health y auto-failover.
3. Función de precio de ruta (AR vs Costo vs SLA vs FX) + sticky BIN/GEO.
4. Network tokens + un solo vault; COF/COFT se coloca correctamente.
5. Cut-off-aware: no fructificar con una captura parcial al final del día.
6. Reconciliation: cálculo propio fees/FX, informes variance.
7. Orquestación de pago con same-method y control de pasillos.
8. Versificación de reglas y pruebas A/B con guardrails.
9. Separación de capas: router ≠ antifraud ≠ policy engine; manuales generales.
10. Seguimiento de sanciones/licencias/políticas, kill-switch por GEO.

17) Lista de verificación de implementación

• Selección del modelo (build/buy/hybrid), mapa GEO/métodos/PSP/MID.
• Circuito API, idempotencia, outbox, bus de evento, DWH.
• Rules-engine + UI: perfiles, pesos, soft-codes, políticas de 3DS.
• Adaptadores: API/códigos normalizados, conjuntos de prueba de sandbox.
• Telemetría/alertas/SLO, el feed de salud de los proveedores.
• Reconciliation: importación de archivos, varios fees/reserva/FX.
• Orquestación de pago: pasillos, same-method, SoF/KYC.
• Seguridad: PCI/GDPR/sanciones, secretos/rotación, accesos.
• Documentación y playbooks de incidentes; pruebas de regresión.

Resumen

El POP no es solo un «proxy antes del PSP», sino un bus operativo central de pagos: routing y cascadas inteligentes, orquestación de 3DS/riesgo, reconciliation y payouts, trejery/FX, observabilidad y cumplimiento. Al construir una plataforma con idempotencia, telemetría en vivo, costo transparente y reglas, levanta AR, baja la tarifa de toma todo en uno, protege a P&L de fallas y acelera la entrada a nuevos mercados sin reescribir el producto.