Guía de integración · 2026
Seguridad de una API de casino: firmas, listas de IP permitidas e idempotencia
Una API de casino mueve dinero en cada giro. Aquí la seguridad tiene menos que ver con los firewalls y más con tres preguntas: ¿es auténtica esta solicitud?, ¿es inofensiva si llega dos veces? y ¿se puede rastrear después cada cambio de saldo? Estos son los controles que debe acordar con su proveedor antes de la primera apuesta real.
La versión corta
- Firme cada solicitud en ambas direcciones y rechace todo lo que no supere la verificación.
- Incluya en una lista de permitidos las IP de los servidores en ambos lados; los endpoints de la billetera nunca están abiertos a internet.
- Haga que cada llamada a la billetera sea idempotente según el ID de transacción.
- Mantenga tokens de sesión de corta duración y vinculados a un jugador y a un juego.
- Registre cada solicitud y cada respuesta; las necesitará en caso de disputa.
Qué demuestra una solicitud firmada
Una firma es un hash del cuerpo de la solicitud y de una marca de tiempo, generado con un secreto que solo usted y el proveedor conocen. El lado receptor lo vuelve a calcular; si los dos valores difieren, la solicitud fue falsificada o alterada y se rechaza. La marca de tiempo también importa: acepte solicitudes solo dentro de una ventana corta, y así una solicitud interceptada no podrá reenviarse una hora después.
En IGP, cada llamada a través de la API de casino lleva un hash para que el servidor pueda demostrar que procede de usted. Pida la misma protección en los callbacks que llegan a su billetera, y pruebe ambas direcciones, no solo la que usted envía.
Listas de IP permitidas
El endpoint de su billetera es donde se mueve el dinero, así que solo debería responder a los servidores del proveedor. Acuerde IP de salida fijas en ambos lados, mantenga listas separadas para staging y producción, y trate cualquier cambio en la lista como una solicitud de cambio, no como un arreglo rápido.
Idempotencia: el control que protege los saldos
Las redes sufren timeouts. Cuando un proveedor no recibe su respuesta a tiempo, vuelve a enviar el mismo débito o crédito. Si su billetera trata el reintento como una transacción nueva, el jugador paga dos veces o cobra dos veces.
La solución es sencilla e innegociable: guarde cada ID de transacción y, cuando uno vuelva a llegar, devuelva la respuesta original sin mover el saldo. Los rollbacks deben hacer referencia a la transacción que revierten. Nuestro checklist de integración de API de casino incluye las pruebas para los tres casos.
Tokens de sesión y lanzamiento de juegos
Una sesión de juego comienza con un token que su plataforma emite al lanzar el juego. Vincúlelo a un jugador, un juego y una moneda, dele una vida corta y verifíquelo en la primera llamada a la billetera. No incluya datos personales en las URL de lanzamiento; un ID de jugador y un token son suficientes.
| Control | Qué impide | Responsable |
|---|---|---|
| Firma de la solicitud | Llamadas falsificadas o alteradas | Operador y proveedor |
| Ventana de marca de tiempo | Solicitudes reenviadas | Operador y proveedor |
| Lista de IP permitidas | Llamadas desde servidores desconocidos | Operador y proveedor |
| ID de transacción idempotentes | Débitos y créditos dobles en los reintentos | Billetera del operador |
| Tokens de sesión de corta duración | Sesiones de juego secuestradas o reutilizadas | Plataforma del operador |
| TLS en cada llamada | Interceptación en tránsito | Operador y proveedor |
| Registros de auditoría | Disputas que no puede demostrar ni en un sentido ni en otro | Operador y proveedor |
Antes de la salida en vivo
- Envíe una solicitud con una firma incorrecta y una con una marca de tiempo caducada; ambas deben ser rechazadas.
- Llame a la billetera desde una IP que no esté en la lista; la llamada debe ser rechazada.
- Envíe dos veces el mismo débito y dos veces el mismo crédito; el saldo debe moverse una sola vez en cada caso.
- Lance un juego con un token caducado; no debe abrir una sesión con dinero real.
- Elija una ronda al azar de ayer y rastréela de principio a fin en sus registros.
Preguntas frecuentes
Una integración firmada, 150+ proveedores
Solicitudes firmadas, una sola billetera y un único flujo de transacciones normalizado para 18.000+ juegos, con un sandbox para probar todos los controles anteriores.
