La respuesta corta
El problema terminológico más difícil en un proyecto de Slots API rara vez es que nadie conozca un término. Es que equipos distintos usan el mismo término para objetos diferentes. Por ejemplo, «disponible» puede significar que aparece en un catálogo, que está conectado en el entorno de pruebas, que está habilitado en producción o que se ha verificado para un mercado objetivo. Las definiciones estables mantienen las preguntas de compras, el diseño de la interfaz, las evidencias de prueba y las decisiones de producción vinculadas al mismo alcance de hechos.
Esta página ofrece definiciones concisas que se pueden reutilizar en todo el sitio. Para conocer métodos completos de selección, aceptación, fiabilidad y verificación de mercado, consulte las guías temáticas en lugar de tratar este glosario como un tutorial de implementación.
Roles principales y conceptos de catálogo
| Término | Definición concisa | Lo que no establece |
|---|---|---|
| Proveedor / proveedor de juegos | Parte que suministra contenido de juego, servicios de juego o interfaces relacionadas. | Que AG tenga derechos de distribución o que el contenido esté disponible en un mercado concreto. |
| Agregador | Capa de integración que normaliza o coordina el acceso entre una plataforma y varios proveedores. | Que desaparezcan las diferencias entre proveedores, las condiciones comerciales, la certificación o la revisión de mercado. |
| Plataforma | Sistema empresarial que gestiona cuentas de jugadores, monederos, operaciones o la experiencia de interfaz. | Que sea el proveedor, el RGS o el operador legalmente responsable en una jurisdicción concreta. |
| Operador / entidad operadora | Entidad responsable de las operaciones dentro de un proyecto o mercado especificado; su significado preciso depende del contrato y la jurisdicción. | Que conectar una API conceda autorización para operar. |
| RGS / servidor remoto de juegos | Componente de sistema que aloja o coordina la operación remota de los juegos, el estado y las interacciones de transacción relacionadas. | Que sea el agregador o que sistemas con nombres similares tengan el mismo alcance de certificación. |
| Catálogo / catálogo de juegos | Colección de registros de juegos con procedencia, identidad, versión, estado e información de revisión. | Que la inclusión en el catálogo signifique inventario en tiempo real, habilitación en producción o admisión de mercado. |
| ID de registro del catálogo | Identificador interno que sigue de manera consistente un registro de catálogo. | Que sustituya un código de juego del proveedor o un ID de transacción. |
| Código de juego del proveedor | Código utilizado por un proveedor o una interfaz ascendente para identificar un juego de forma única. | Que pueda deducirse a partir de un nombre visible o de un slug (identificador de URL). |
| Versión del juego | Versión identificable del software del juego o de una compilación de contenido. | Que sea idéntica a la versión del modelo matemático. |
| Versión del modelo matemático | Versión del modelo matemático que rige las probabilidades, los premios y las características estadísticas teóricas. | Que una interfaz sin cambios implique que el modelo no ha cambiado. |
Sesiones, rondas y transacciones
| Término | Definición concisa | Lo que no establece |
|---|---|---|
| Lanzamiento | Proceso mediante el cual una plataforma solicita y entra en un juego determinado utilizando parámetros acordados. | Que recibir un resultado de lanzamiento complete el flujo de juego o la revisión del mercado objetivo. |
| URL de lanzamiento | URL de acceso a un juego, o dirección que contiene un token, generada para un contexto de lanzamiento concreto. | Que sea un enlace público permanente o que pueda divulgarse y reutilizarse fuera del alcance acordado. |
| Sesión de juego | Contexto de interacción delimitado para un usuario, juego y entorno identificados después de entrar en el juego. | Que sea la cuenta del jugador, la sesión de inicio de sesión, el monedero o una ronda. |
| Ronda | Unidad de negocio que agrupa uno o más eventos de apuesta y resultado conforme a las reglas del juego. | Que una ronda siempre corresponda a una transacción. |
| Transacción | Registro de negocio auditable que modifica un saldo o un estado de negocio. | Que el éxito de la API signifique que todos los sistemas han alcanzado la consistencia final. |
| Apuesta | Tipo de transacción que solicita o confirma la deducción de una apuesta dentro de una ronda determinada. | Que una animación del lado del cliente demuestre que el débito se realizó correctamente. |
| Premio | Tipo de transacción que aumenta un saldo o crea un importe pagadero a partir de un resultado confirmado. | Cualquier resultado de otra ronda o un retorno del jugador a largo plazo. |
| Reembolso | Devolución basada en reglas de la totalidad o parte del efecto de una transacción existente. | Que suprimir la transacción original sea una implementación aceptable. |
| Reversión / anulación | Operación trazable que compensa un efecto de negocio existente. | Que una solicitud de reembolso arbitraria pueda reproducirse; debe referirse al objeto original y conservar la idempotencia. |
| Saldo | Estado monetario utilizado para una decisión de negocio de una cuenta, moneda y momento determinados. | Que una lectura demuestre que todos los registros asíncronos están conciliados. |
| Moneda | Unidad monetaria y reglas de precisión utilizadas para mostrar, apostar, liquidar o informar. | Que el soporte técnico de la moneda establezca autorización para el mercado objetivo. |
Conceptos de monedero y fiabilidad
| Término | Definición concisa | Lo que no establece |
|---|---|---|
| Monedero único | Modelo en el que la plataforma gestiona el saldo del jugador y las transacciones de juego colaboran con el monedero de la plataforma mediante API en tiempo real. | Que desaparezcan los requisitos de tiempos de espera, duplicados, estados desconocidos y conciliación. |
| Monedero de transferencia | Modelo en el que los fondos se mueven entre monederos del lado de la plataforma y del lado del juego, y se registran por separado. | Que ambos saldos sean intrínsecamente coherentes en tiempo real. |
| Callback | Interacción de servidor a servidor en la que una parte notifica a una dirección acordada un evento o solicita gestión de negocio. | El orden de llegada, la unicidad o una entrega exactamente una vez, salvo que el protocolo lo indique. |
| Idempotencia | Propiedad por la cual el tratamiento repetido de la misma solicitud de negocio no crea un efecto de negocio duplicado. | Que baste con devolver la misma respuesta; el sistema debe reconocer la misma intención y conservar el resultado pertinente. |
| Clave de idempotencia | Clave estable utilizada para identificar la misma solicitud de negocio. | Que la clave pueda regenerarse en cada reintento o reutilizarse indefinidamente sin un alcance definido. |
| Reintento | Otro intento, sujeto a condiciones, número de intentos y política de espera progresiva limitados, cuando no se ha establecido la finalización. | Que un tiempo de espera equivalga a un fallo; un reintento inseguro puede crear un efecto duplicado. |
| Estado desconocido | Estado en el que quien llama no puede determinar, a partir de la respuesta actual, si la acción de negocio se completó. | Que el sistema pueda registrar inmediatamente éxito o fallo; debe consultar, reintentar de forma segura con una semántica explícita o conciliar. |
| ID de correlación | Identificador de trazabilidad que vincula solicitudes, callbacks, registros y asientos entre sistemas. | Que sustituya un ID de transacción de negocio o una clave de idempotencia. |
| Conciliación de registros | Proceso de comparar registros independientes de transacciones, rondas o saldos para identificar y resolver discrepancias. | La idempotencia en tiempo real, la consulta de estado o los controles de excepciones. |
| Estado final | Estado de negocio que el protocolo define como no sujeto a más cambios mediante el proceso normal. | Que una respuesta HTTP correcta sea por sí misma el estado final de negocio. |
Entornos, versiones y evidencia de mercado
| Término | Definición concisa | Lo que no establece |
|---|---|---|
| Entorno de pruebas | Entorno y configuración no productivos utilizados para integración, verificación y aceptación. | Que una aprobación en el entorno de pruebas signifique que producción está desplegada o que se ha verificado un comportamiento comercial real. |
| Producción | Entorno que procesa tráfico y datos en vivo autorizados. | Que una URL o credencial de producción implique que todos los juegos, mercados y versiones están aprobados. |
| Versión de API | Versión identificable de los contratos de interfaz, campos y comportamiento. | Que la versión del juego o del modelo matemático sea la misma. |
| Versión de integración | Registro versionado de la topología y configuración seleccionadas entre la plataforma, el agregador, el RGS y el proveedor. | Que la evidencia antigua siga aplicando después de que cambie un componente crítico. |
| RTP / retorno al jugador | Retorno medio teórico a lo largo de un gran número de eventos conforme a reglas de juego definidas y un modelo matemático especificado. | Un resultado de un evento, un período corto o un jugador individual. |
| RNG / generador de números aleatorios | Componente o mecanismo que proporciona valores aleatorios para resultados de juego o procesos aleatorios relacionados. | Que su implementación, versión o certificación se haya verificado simplemente porque se menciona RNG. |
| Certificación / evidencia de conformidad | Evidencia de prueba o conformidad producida por un organismo especificado para un objeto, versión, requisitos y alcance definidos. | Una licencia mundial o cobertura automática de una entidad operadora, marca, dominio o versión nueva. |
| Certificación de integración | Evidencia de conformidad para una combinación y alcance de interacción concretos que implican componentes como plataforma, RGS, agregador y proveedor. | Todas las demás revisiones necesarias para un juego o entidad operadora individual. |
| Organismo de pruebas | Organización que realiza pruebas o emite informes dentro de un alcance de reconocimiento definido. | Que todos los servicios e informes del organismo estén dentro del reconocimiento de un regulador. |
| Norma | Especificación que describe requisitos técnicos, de pruebas o de control. | Que aplicar una norma de laboratorio como GLI-19 conceda automáticamente admisión jurisdiccional. |
| Disponibilidad en el mercado | Estado delimitado por el mercado objetivo, la entidad operadora, el juego y su versión, la certificación, la moneda, el idioma, los derechos y una decisión de proyecto. | Una conclusión que la inclusión en catálogo, el idioma, la moneda o la conectividad de API puedan establecer por sí solos. |
| Soporte de idioma | Capacidad lingüística verificada para una interfaz, reglas, ayuda o alcance de comunicación definidos. | Traducción completa, certificación válida o disponibilidad en el mercado. |
Nota de alcance no verificado para
RTP 0–1000Este intervalo numérico no es la definición de RTP del glosario. Aún requiere definiciones de su unidad y significado, versión del modelo matemático, permisos de acceso, material de pruebas y certificación, mercado objetivo y presentación. No debe interpretarse como una afirmación verificada de rendimiento, retorno o cumplimiento de mercado.
Ambigüedades comunes que deben eliminarse
| Declaración ambigua | Hechos que deben separarse |
|---|---|
| «Está en el catálogo, así que está disponible». | Catalogado, verificado en el entorno de pruebas, habilitado en producción, disponible comercialmente y verificado para el mercado objetivo |
| «La solicitud agotó el tiempo de espera, así que falló». | Resultado de transporte desconocido, estado de negocio desconocido, fallo confirmado, reintento seguro y requisito de conciliación |
| «Una ronda equivale a una transacción». | Una ronda es una unidad de negocio del juego; la apuesta, el premio, el reembolso y la reversión pueden ser transacciones separadas |
| «Se admiten BRL y portugués, así que Brasil está listo». | Moneda, idioma, versión del juego, topología de integración, certificación, entidad operadora, marca o dominio, y reglas de mercado |
| «Hay certificación, así que funciona en todo el mundo». | Reconocimiento del organismo de pruebas, norma, objeto probado, versión, jurisdicción, validez y condiciones del proyecto |
Lo que actualmente puede evaluarse en este sitio
- La referencia pública de la API utiliza conceptos como catálogo, lanzamiento, monedero único, monedero de transferencia, registros y proceso de integración.
- Las guías de fiabilidad explican por qué las solicitudes duplicadas, los tiempos de espera, los fallos de callback, los estados desconocidos y la conciliación pertenecen a un mismo diseño.
- Este glosario crea definiciones concisas para su uso en todo el sitio sin añadir endpoints, métodos de firma, credenciales ni hechos sobre protocolos de producción.
- El catálogo muestra 11 proveedores y 1.194 nombres de juegos. Es una instantánea a nivel de nombres, no una conclusión sobre suministro en tiempo real, habilitación en producción, derechos de contenido, versiones, certificación o disponibilidad en el mercado objetivo.
Límites que conviene tener presentes
- No se promete ningún campo concreto de API, protocolo de producción, implementación de monedero, nivel de rendimiento, SLA ni fecha de lanzamiento.
- No se promete que ningún juego, proveedor, certificado, idioma o moneda esté disponible actualmente en un mercado objetivo.
- Estas definiciones generales no sustituyen un contrato, una especificación de interfaz, una norma regulatoria ni una aprobación de proyecto.
- La expresión comercial
RTP 0–1000se conserva como término delimitado, pero no representa una definición numérica verificada, una capacidad universal, un resultado para el jugador ni un hecho de admisión de mercado.
Preguntas frecuentes
¿Un proveedor y un agregador son el mismo tipo de empresa?
Son roles diferentes. Un proveedor suministra principalmente contenido o servicios de juego; un agregador coordina el acceso entre varios proveedores y una plataforma. Una misma empresa puede desempeñar varios roles, pero los registros del proyecto deben seguir separando sus responsabilidades reales.
¿Deben callback, transacción y ronda usar el mismo ID?
Normalmente no deben reducirse a un único identificador. Un callback es un mecanismo de interacción, una transacción es un cambio de estado de negocio y una ronda es una unidad de negocio del juego. Cada uno necesita una identidad estable, y los ID de correlación los conectan conforme al contrato de interfaz.
¿RTP significa que un jugador recibe ese porcentaje cada vez?
No. RTP es una medida estadística teórica a largo plazo conforme a reglas especificadas y un modelo matemático. No garantiza el resultado de un evento ni de un período corto. Cualquier valor numérico también requiere una versión del juego y del modelo matemático, evidencia de prueba y alcance de presentación.
Lecturas relacionadas y próximos pasos
Las primeras siete guías abarcan las preguntas completas que hay detrás de estas definiciones:
- ¿Qué es una Slots API multiproveedor? — los objetos y límites conectados por la agregación.
- API de agregador frente a integración directa con proveedor — las compensaciones entre rutas de integración.
- Cómo evaluar un proveedor de Slots API — evidencia de compras y preguntas de debida diligencia.
- Del entorno de pruebas a producción — evidencia para una decisión de producción.
- Idempotencia, reintentos y conciliación — gestión de fallos, duplicados y estados desconocidos.
- Gobernanza de datos del catálogo de juegos — campos, estados del ciclo de vida, versiones y titularidad.
- Matriz de mercado, juego, versión y certificación — verificación del mercado objetivo por objeto y alcance.
Páginas principales: referencia pública de la API, catálogo de juegos y proceso de integración.
Al utilizar la sección «Contáctenos», describa el mercado objetivo, el alcance del catálogo, el modelo de monedero, el entorno y las versiones con estos términos. AG podrá entonces confirmar la terminología y el alcance de la evidencia antes de una conversación sobre el proyecto. Esto no constituye un compromiso de suministro, certificación ni producción.
Fuentes y alcance
- Inicio de AG Game
- Documentación pública de la API
- Catálogo de juegos y alcance del recuento
- Comisión de Juego del Reino Unido RTS 3: reglas, descripciones de juegos y probabilidad de ganar
- SPA del Ministerio de Hacienda de Brasil: Preguntas frecuentes técnicas
- Gaming Laboratories International: Normas
Las fuentes regulatorias y de normas se utilizan para explicar la terminología. No demuestran que un proyecto haya cumplido los requisitos citados. Para un proyecto concreto, confirme que cada definición coincide con la interfaz actual, el contrato y las reglas del mercado objetivo.
¿Quiere convertir esta guía en un plan de proyecto?
Esta guía apoya la evaluación y no sustituye la validación técnica, contractual, de certificación ni de requisitos locales.
