Utilice esta página para agregación e integración de juegos. Si el proyecto sustituye toda la plataforma central, consulte el motor de casino.
Confirme el catálogo antes de comparar cantidades de juegos
Identifique los estudios y títulos prioritarios, los territorios de los jugadores, las monedas, los dispositivos y las funciones promocionales necesarias. Confirme los permisos pertinentes de proveedores y comerciales. Que un estudio figure en un catálogo amplio no supone el compromiso de que todos sus juegos o configuraciones estén disponibles para su negocio.
Mantenga las exclusiones en el alcance del trabajo. Un título que se inicia en modo de demostración puede seguir necesitando aprobación o una configuración distinta para jugar con dinero real. La página de selección de proveedores detalla la información que debe solicitarse para la preselección.
Decida dónde se mantienen los fondos del jugador
| Modelo de monedero | Consecuencia operativa | Pregunta de verificación |
|---|---|---|
| Monedero seamless | Las transacciones de juego llaman al registro contable de cuentas acordado | ¿Cómo se confirman y concilian los cargos, los abonos y las reversiones? |
| Monedero de transferencia | Los fondos se mueven entre una cuenta principal y un saldo del proveedor | ¿Cómo se recuperan las transferencias pendientes, los fondos devueltos y los saldos del proveedor? |
El modelo afecta al saldo disponible, las retiradas de fondos, los bonos y el soporte. Establezca el comportamiento real de cada proveedor conectado en lugar de suponer que todos los estudios gestionan de la misma forma el juego interrumpido.
Distinga una ronda de sus transacciones
Un identificador de ronda agrupa los eventos de esa ronda de juego. Los identificadores de transacción distinguen las acciones financieras individuales. Una ronda puede contener varios abonos u otra secuencia permitida por el juego. No suponga que cada ronda tiene un cargo y un abono.
Defina las comprobaciones de saldo, los cargos, los abonos y las reversiones en la documentación real de la interfaz. Especifique a qué evento original se refiere una corrección y qué ocurre si llega después de un evento posterior. Un reintento debe poder reconocerse como la misma solicitud, en lugar de interpretarse como otra apuesta o premio.
La sesión y el registro financiero también tienen duraciones distintas. Que un jugador cierre el navegador no demuestra que todas las rondas hayan terminado. Identifique el informe y el responsable de las rondas y transacciones pendientes.
Acuerde las pruebas de aceptación
Pruebe un inicio satisfactorio, un cargo repetido, un tiempo de espera agotado tras una acción financiera, una discrepancia de moneda y una ronda interrumpida. Incluya un abono o una reversión posteriores cuando lo permita la secuencia documentada del proveedor. Concilie el registro contable del jugador con el informe del proveedor mediante los identificadores originales.
En cada caso, conserve la solicitud, la respuesta, el estado esperado y el resultado real. Defina quién investiga las discrepancias y qué permite que la integración pase a producción. El comportamiento exacto de firma, reintento, caducidad y límites de frecuencia debe proceder de la documentación acordada.
Estime el trabajo a partir de su punto de partida
El calendario depende de su monedero, autenticación, historial de transacciones, configuración de catálogo y capacidad de pruebas. Identifique las carencias de esos componentes antes de presupuestar la integración como un número fijo de días. Mantenga la aprobación del proveedor y la aceptación técnica como dependencias independientes.
Solicite la documentación y el alcance de API pertinentes. Envíe la información de su operador y mercados, el modelo de monedero, los estudios requeridos y las monedas. Incluya un resumen de cómo gestiona actualmente el registro contable los reintentos y las reversiones para abordar pronto la parte difícil.