Tus jugadores.
Una nueva batalla.
Conectá tu casino con Roulette Battle mediante una API de servidor a servidor. Mesas de dos y cuatro jugadores, ruleta 3D y resultados compartidos en vivo.
1. Habilitá el casino
En Administración → API para casinos, creá una credencial por casino. El secreto se muestra una sola vez y debe guardarse únicamente en su backend. Cada casino tiene jugadores aislados y un cupo inicial de cero. Habilitá un cupo autorizado, con motivo y referencia, para permitir cargas. Cada carga descuenta ese cupo mediante un movimiento contable.
2. Enviá usuario y fichas con API v2
POST https://roulettebattle.com/roulette-battle/api/v2/launch
El cuerpo y la respuesta usan AES-256-GCM con claves distintas por dirección, derivadas por HKDF-SHA256. La solicitud lleva además HMAC-SHA256, fecha y nonce. El transporte requiere HTTPS. La API no admite llamadas desde el navegador.
Contenido antes de cifrar:
{
"username": "jugador_123",
"displayName": "Luis",
"credits": 10000,
"transferId": "deposito-20260914-0001",
"ageConfirmed": true
}username identifica al jugador dentro de ese casino. credits es la cantidad a sumar, no su saldo total: un entero de 0 a 1.000.000. Una ficha de saldo equivale a un peso ARS; las fichas visuales del paño no tienen valor monetario. Con cero se abre la cuenta sin cargar. Un importe positivo requiere transferId único, de 8 a 100 letras, números, guion o guion bajo.
La misma referencia y los mismos datos nunca duplican una carga. Reutilizarla con otro jugador o monto devuelve conflicto. Un resultado incierto conserva el cupo reservado y reintenta la referencia original ante la billetera. Un rechazo definitivo devuelve el cupo, sin abrir el juego con saldo inexistente.
3. Usá el cliente de servidor
Descargar cliente Node.js →. Guardalo como casino-client.mjs en el backend. No lo incluyas en el JavaScript del navegador.
import { makeLaunchRequest } from './casino-client.mjs';
// Las credenciales quedan en las variables privadas del servidor.
const request = makeLaunchRequest({
id: process.env.ROULETTE_CASINO_ID,
secret: process.env.ROULETTE_CASINO_SECRET,
username: 'jugador_123',
displayName: 'Luis',
credits: 10000,
transferId: 'deposito-20260914-0001',
ageConfirmed: true
});
const response = await fetch(request.url, {
method: 'POST', headers: request.headers, body: request.body
});
const envelope = await response.json();
if (!envelope.v) throw new Error(envelope.error);
const result = request.decode(envelope);
if (result.status === 'ready') {
// Redirigí al jugador a result.launchUrl.
} else {
// pending: reintentá con nueva firma/nonce y MISMO transferId.
// review: requiere revisión administrativa; conservá la referencia.
// rejected: no hubo carga y el cupo fue devuelto.
}Protocolo criptográfico
Sobre JSON: {v:2, alg:"A256GCM", iv, tag, data}. Los tres campos binarios usan base64url sin padding: IV aleatorio de 12 bytes, tag de 16 bytes. HKDF-SHA256 recibe el secreto UTF-8 como IKM, el ID de casino UTF-8 como salt y roulette-battle/api-v2/request o roulette-battle/api-v2/response como info; produce 32 bytes. El AAD es la unión con saltos de línea de ID, timestamp, nonce, método y ruta exacta con query.
Encabezados: X-Casino-Key, X-Timestamp (segundos Unix), X-Nonce (16 a 80 caracteres) y X-Signature (hex SHA256). HMAC usa el secreto UTF-8 y firma:
timestamp nonce POST /roulette-battle/api/v2/launch sha256_del_sobre_JSON_exacto
El reloj admite 60 segundos de diferencia. Cada nonce se usa una vez. En cada reintento generá nonce e IV nuevos, conservando el mismo transferId. Límite: 120 aperturas por minuto y casino. Nunca registres secretos, contraseñas, contenido descifrado ni launchUrl en logs.
4. Entrada al juego
Con estado ready, la respuesta cifrada incluye launchUrl, expiresAt, singleUse:true, creditsAdded, creditsAvailable y transferId. El enlace vence en 90 segundos, se usa una sola vez y se intercambia por una cookie HttpOnly. El fragmento del enlace se retira de la barra al ingresar. El jugador conserva su perfil y estadísticas.
201 indica listo; 202 indica operación pendiente o en revisión. Los errores de firma, permisos o estructura se devuelven como JSON genérico sin datos privados. Un rechazo definitivo de la billetera devuelve 409 con respuesta cifrada y estado rejected. La API v1 existente sigue admitiendo apertura firmada sin carga; si se envía dinero a v1, lo rechaza y exige v2.
Administración y errores
Revocar una integración invalida sus enlaces pendientes y sesiones. Los giros que ya comenzaron conservan su liquidación. El servidor devuelve {"error":"mensaje"}: 400 para datos inválidos, 401 para firma o enlace inválido, 403 para permisos, 409 para conflictos, 429 para límites y 503 cuando un proveedor no responde.
El cliente no puede fijar el número ganador, el premio ni la comisión de una ronda. Los resultados y movimientos se resuelven en el servidor.