Cómo el casino conecta proveedores en vivo a través de bridge

Qué es un puente en el contexto de un casino en vivo

Bridge es una capa intermedia entre la plataforma del operador y los proveedores en vivo (Evolution, Pragmatic Live, Ezugi, TVBet, etc.) que normaliza la API, los eventos, la lógica y las facturas. En pocas palabras, el puente hace que una docena de integraciones diferentes «a la vista» sean iguales: un solo contrato de apuestas, un solo esquema de estados de rondas, webhooks monótonos e informes.

¿Por qué lo necesita?

Contrato único para docenas de proveedores (menos cambios en la plataforma).

Idempotencia y protección contra tomas (retraídas en red, reconnect del jugador).

Normalización del directorio (tablas, límites, side-bets, locales).

Caja única y reglas de riesgo (límites, AML/KYT, RG).

Monitoreo de QoS de streaming y SLA por proveedor.

Cadena de componentes

1. Casino Platform (host): cuentas, KYC/RG, bonos, billetera, frente.

2. Puente: adaptadores de proveedores, bus de eventos, mapping de mesas/límites, Finnet, lógica, webhooks.

3. Live-Provider: stream (normalmente WebRTC/HLS), motor de juego, cálculo de resultados, distribuidores.

4. Cartera: Seamless (el saldo se mantiene en el operador) o Transfer (el depósito en el banco del juego por el proveedor).

5. Observabilidad: métricas de streaming (FPS, RTT, buffer), métricas de negocio (Bet, GGR, Hold).

Protocolos de red y sesiones

Vídeo:

WebRTC - baja latencia (100-500 ms), se requiere ICE/STUN/TURN.
HLS/LL-HLS - mayor latencia, pero más fácil CDN.
Apuestas y eventos: WebSocket/HTTP-SSE/NAT.
Tokens: JWT/opaque de vida corta (TTL 3-10 min), rotación a petición del proveedor.

Modelos de billetera

1) Seamless wallet (recomendado)

La apuesta/pago pasa a través del puente a la cartera del operador.

Ventajas: equilibrio único, control de límites instantáneo, RG simplificado.

Contras: estrictos requisitos de disponibilidad de billetera (SLA).

2) Transfer wallet

El jugador transfiere los fondos al «banco de la mesa» del proveedor.

Ventajas: menos carga en la cartera del operador durante los picos.

Contras: más difícil de devolver, reconcile y control AML, fricción en UX.

Ciclo de vida de la sesión

1 ./createSession → bridge crea 'sessionId', devuelve 'streamUrl',' betSocketUrl'.

2. El frente abre el reproductor (WebRTC/HLS) y la conexión de eventos.

3. El jugador apuesta → 'placeBet' en bridge ('idempotencyKey', 'roundId', 'selection', 'stake').

4. Bridge preautoriza la cantidad (hold) en la cartera → confirma al proveedor.

5. El proveedor declara 'bettingClosed' → spin/deal → 'roundNat'.

6. Bridge calcula el pago, adeuda/devuelve hold, genera 'transactionId'.

7. Bridge lanza webhook a la plataforma ('roundId', 'nat', 'payout', 'balanceAfter'), escribe en el ledger.

8. Finalización/reconexión - por 'sessionId' (idempotente).

Contrato de eventos (ejemplo)

Tasa → puente (WS/NAT):

json
{
"type": "bet. place",  "idempotencyKey": "c0a4-77f…",  "sessionId": "sess_abc123",  "roundId": "R-2025-10-17-18:45:03-Table23",  "selection": [{"market":"roulette_straight","value":"17"}],  "stake": {"amount":"5. 00","currency":"EUR"},  "limitsProfile":"VIP_A"
}

Respuesta de puente:

json
{
"status":"accepted",  "balanceHold":"-5. 00",  "betId":"bet_9f2…",  "effectiveLimits":{"maxBet":"5000. 00"}
}

Resultado de la ronda → plataforma (webhook):

json
{
"event":"round. settle",  "roundId":"R-2025-10-17-18:45:03-Table23",  "bets":[
{"betId":"bet_9f2…","stake":"5. 00","payout":"180. 00","outcome":"WIN"}
],  "transactions":[
{"id":"trn_bet_9f2…","type":"DEBIT","amount":"5. 00"},   {"id":"trn_pay_9f2…","type":"CREDIT","amount":"180. 00"}
],  "balanceAfter":"1320. 40"
}

Reglas clave:

Idempotencia: todas las consultas con 'idempotencyKey'.
Tipificación clara de los resultados: 'WIN/LOSE/PUSH/VOID/RETRY'.
Identificadores estables: 'roundId' es único globalmente (tabla + tiempo + shard).

Directorio y límites

Discovery: '/providers/: id/tables '- lista de mesas, límites, side-bets, idiomas, horario.

Grupos de límites: 'DEFAULT', 'VIP _ A', 'VIP _ B', 'Ultra'.

Reglas de mapeo: país/moneda/estado KYC → mesas y perfiles de límite válidos.

Cambio de límites en caliente: eventos 'limits. update 'sin reiniciar la mesa.

Observabilidad y calidad del streaming (QoS)

Métricas por jugador:

RTT de señales de apuestas (objetivo <150 ms WebRTC).
Dropped frames / buffer events.
Adaptación Bitrate/Resolution.
Bet window latency (tiempo entre 'bettingOpen' y la aceptación real de la apuesta).

Métricas por proveedor/mesa:

Aptime de mesa, redondos abortados, late settlements, frecuencia 'VOID'.
Tiempo medio-a-settle después de cerrar las apuestas.
alertas de QoS: degradación de FPS, ráfagas de 'retry'.

Cumplimiento y seguridad

KYT/AML: análisis de fuentes de depósito, bandera de «alto riesgo» → prohibición de apuestas en vivo.

RG (juego responsable): tiempos de espera, límites, auto-exclusión - se aplican hasta 'placeBet'.

Residencia de datos: la lógica y la PII se almacenan en el operador; bridge sólo almacena tecnología. registros y agregados.

Seguridad de transporte: mTLS/IP-whitelist a proveedores, firma de solicitudes HMAC, TTL corto de tokens.

Auditoría: ledger inmutable (WORM/append-only), exportación por 'roundId '/' sessionId'.

Cálculo, reconcile y devoluciones

settle On-the-fly: débito/crédito instantáneo para cada resultado.

Batch reconcile: conciliar los informes del proveedor (hourly/daily) con el bridge ledger (P&L, comisión).

VOID/REFUND scripts: error de streaming, error del distribuidor, disputa - retorno parcial/completo con códigos de causa claros.

Dispute Center: un conjunto de 'roundId' ↔ grabar un vídeo (código de tiempo) para que el soporte resuelva rápidamente los tickets.

Rendimiento y tolerancia a fallas

Escalado: adaptadores de proveedores sin estado + Kafka/NATS como bus de eventos.

Almacenamiento: caliente (Redis) para sesiones/límites, cálido (Postgres) para ledger, frío (S3) para logs.

Folbacks: si la cartera no responde - 'SOFT _ DECLINE' con retraídas; si el proveedor no está disponible - desactivar las mesas/ocultar en el vestíbulo.

Retratos idempotentes: por temporizadores de red, repetir 'placeBet '/' settle' es seguro.

UX: patrones de front-tend

Sincronización de relojes: utilice 'serverTime' de bridge para temporizadores «Cerrar apuestas a través de»....

Localización: idioma del distribuidor ≠ idioma de la interfaz; mostrar subtítulos/glosario de términos.

Reproductor de streaming: auto-fallback WebRTC → LL-HLS cuando hay una red deficiente.

Error UI: códigos comprensibles ('LBRG-401 TOKEN_EXPIRED',' LBRG-429 LIMIT_EXCEEDED', 'LBRG-503 PROVIDER_DOWN').

Multiability: Swich rápido de mesas sin interrupción de sesión (reuse 'sessionId').

Anti-patterny

Almacenar tokens de larga vida en el cliente.

Aceptar la apuesta después de 'bettingClosed' debido al Diley - la disputa está garantizada.

Falta de 'idempotencyKey' → dobletes en los retratos.

Mezcle las zonas de tiempo en 'roundId' e informes.

Poner límites «en el ojo» sin perfiles y estado KYC.

Ignorar el QoS de streaming es un churn alto en las redes móviles.

Plan de implementación paso a paso (lista de verificación)

Arquitectura y contratos

Fijar un único contrato de eventos: 'bet. place`, `bet. accepted`, `bet. rejected`, `round. settle`, `limits. update`, `session. close`, `provider. error`.
Definir idempotencia y formatos 'roundId', 'betId', 'transactionId'.
Seleccionar modelo de billetera (Seamless prioritario).

Seguridad

mTLS a proveedores, firma HMAC webhooks, token TTL ≤ 10 minutos.
Política de RG/AML/KYT antes de la admisión a tasas, registro de auditoría.

Directorio y límites

Importación de mesas y perfiles de límite, mapping por país/moneda/CCA.
Actualización en caliente de los límites y estados de las mesas.

Frontend

Reproductor WebRTC con folback LL-HLS, reloj de sincronización, temporizadores de apuestas estables.
Códigos de error y mensajes humanizados.

Plan de prueba

Escenarios de alta latencia/packet-loss, reconnectación sin pérdida de apuesta.
Doble click apuesta → un débito (idempotencia).
VOID/REFUND, rondas polémicas, informes divergentes.

Observabilidad

Дашборд QoS: RTT, dropped frames, aborted rounds, time-to-settle.
Alertas de SLA del proveedor, informes de reconcile.

Bridge transforma el «zoo» de las integraciones en vivo en un sistema manejable: tarifas únicas, cálculos únicos, UX predecible y control de calidad de streaming transparente. Con el bridge correctamente diseñado, el operador conecta nuevos proveedores en vivo más rápidamente, reduce los riesgos tecnológicos y protege a P&L a través de la idempotencia, límites estrictos y una clara observabilidad.