Integração
Como adotar a plataforma, por etapas
O que cada componente entrega, o que precisa existir antes, quais contratos ligam as peças e como a homologação acontece. Sem promessa de plug-and-play: carteira, meio de pagamento e identidade exigem trabalho conjunto.
Opções de adoção
Cinco caminhos, a mesma arquitetura
Suíte completa
BetFront + BetBackoffice + Game Provider (+ MotorGLI)
Operações novas ou em modernização que querem os contratos já integrados.
Pré-requisitos:
- Definição de marca, moeda e jogos do catálogo
- Meio de pagamento e verificação de identidade a integrar
- Ambiente de homologação com chaves próprias
Experiência + operação
BetFront + BetBackoffice
Quem já tem jogos e quer o Player Hub e o controle operacional.
Pré-requisitos:
- Fonte dos jogos e contrato de sessão
- Regras de jogo responsável e alçadas de saque
- Papéis e permissões da equipe
RGS integrado
Game Provider + Wallet API do BetBackoffice
Operadoras e studios que precisam de jogos server-side ligados a uma carteira com rastreabilidade.
Pré-requisitos:
- Contrato de Wallet (idempotência e reversão)
- Chaves de operador e assinatura HMAC
- Lista de origens permitidas para o front
MotorGLI independente
MotorGLI
Times de compliance e qualidade que precisam organizar a preparação de uma submissão.
Pré-requisitos:
- Escopo, versão e build a avaliar
- Norma de referência escolhida com o time regulatório
- Definição de quem revisa findings e evidências
BetBackoffice com front próprio
BetBackoffice + Front do cliente
Operadoras que já têm ou vão construir a própria experiência do jogador e querem usar o BetBackoffice como retaguarda por meio da API pública.
Pré-requisitos:
- Servidor próprio para guardar segredos: o navegador nunca fala direto com a API
- Chaves de operador e assinatura HMAC por ambiente
- Meio de pagamento e verificação de identidade (KYC) a integrar
- Lista de origens permitidas para o front
- Papéis e alçadas da equipe de operação definidos
Matriz de componentes
Quem fornece, quem consome e quem é a fonte de verdade
| Componente | Fornece | Consome | Fonte de verdade |
|---|---|---|---|
| BetFront | Experiência do jogador; URL do jogo; solicitações de saque e KYC | Sessão de jogo do Game Provider; domínio operacional do BetBackoffice | Nenhuma (apresenta e registra solicitações) |
| Front do cliente | Experiência do jogador | API pública do BetBackoffice | Nenhuma |
| BetBackoffice | Wallet API; filas de saque, KYC e risco; auditoria | Movimentações dos jogos via Wallet API | Carteira e saldo; cadastro e decisões operacionais |
| Game Provider | Sessões, rounds, apostas, settlement, SSE, verificação de sorteio | Wallet API do BetBackoffice | Estado do jogo: rounds, apostas, sementes e resultados |
| MotorGLI | Processo de avaliação, findings e estrutura do pacote | Nenhum componente (independente) | O processo de avaliação de prontidão |
Contratos conceituais
O que atravessa a fronteira entre componentes
Os contratos são lógicos: descrevem o comportamento esperado, não endereços nem infraestrutura.
Sessão e gameUrl
O servidor do front pede a sessão de jogo ao Provider por chamada assinada e entrega ao navegador apenas a URL do jogo.
API key + HMAC
Cada chamada de integração leva a chave do operador e a assinatura HMAC-SHA256 do corpo; a comparação é em tempo constante.
Wallet API
Saldo, aposta, prêmio, estorno e reversão. O débito acontece antes de a aposta ser aceita.
Idempotency key
O transactionId identifica a operação financeira; repeti-lo devolve o resultado original sem reaplicar o lançamento.
requestId e correlação
Um identificador acompanha a requisição do Provider até a carteira e é gravado nos registros de auditoria.
Eventos SSE
Fluxo de eventos do round (snapshot, mudanças de estado, multiplicador, apostas públicas) com reconexão orientada pelo servidor.
Documentação da API
Detalhe técnico no portal da API
Endpoints, autenticação HMAC, webhooks, idempotência e o checklist de homologação ficam em um portal próprio, com a referência gerada da especificação OpenAPI do BetBackoffice.
Sequência de referência
A aposta, passo a passo
Ambientes
Desenvolvimento, homologação e produção
Ambientes são estágios do ciclo de entrega — não confundir com os produtos. Cada um tem chaves e dados próprios.
Desenvolvimento
Construção e testes locais. Dados sintéticos; contratos exercitados isoladamente.
Homologação
Validação de integração e aceite. Chaves, dados e integrações próprios do ambiente.
Produção
Operação real. Imagens imutáveis por versão, migrations antes da aplicação e readiness antes do tráfego.
Checklist por fases
Do discovery ao acompanhamento
Discovery Conjunto
Escopo, componentes a adotar, jogos, moedas, meios de pagamento e requisitos regulatórios.
Sandbox / HML Conjunto
Ambiente de homologação com chaves e dados próprios; contratos exercitados de ponta a ponta.
Contrato Conjunto
Wallet, sessão, idempotência, reversões e códigos de erro acordados e testados.
Segurança Cliente e Bet Platform
Segredos apenas no servidor, CORS por lista de origens, papéis e alçadas revisados.
Observabilidade Cliente e Bet Platform
Liveness e readiness monitorados; requestId e auditoria conferidos em um fluxo completo.
Homologação Cliente
Fluxo completo com jogador de teste: aposta, prêmio, estorno, saque e auditoria.
Go-live Conjunto
Imagens imutáveis, migrations antes da aplicação, readiness verde e plano de rollback.
Acompanhamento Conjunto
Revisão dos primeiros ciclos e evolução de contratos por versão.
Responsabilidades
O que é do cliente e o que é da Bet Platform
Cliente
- Decisões de produto, marca, moedas e catálogo de jogos
- Contratação e integração de meio de pagamento e de verificação de identidade
- Definição de limites, alçadas e políticas de risco e jogo responsável
- Operação diária, atendimento e revisão de alertas
- Relação com reguladores e entidades certificadoras
Bet Platform
- Componentes da plataforma e seus contratos entre si
- Wallet API, sessão de jogo e assinatura das integrações
- Auditoria, correlação e trilha técnica por rodada
- Documentação de contratos e apoio à homologação
- Evolução versionada dos componentes
Erros comuns
O que evitar em uma integração de jogos
Duas engines para o mesmo jogo
Resultados divergentes e auditoria impossível.
Escrita direta no banco de outro produto
Quebra a idempotência e a trilha; o contrato existe para evitar isso.
Segredos no frontend
Qualquer pessoa consegue assinar chamadas de integração.
CORS amplo
Origens não autorizadas conseguem chamar a API do navegador.
Ausência de idempotência
Retentativas debitam ou creditam em duplicidade.
Deploy sem readiness
Versão nova recebe tráfego antes de banco, schema e carteira estarem prontos.
Planejar uma integração
Compartilhe o que você já tem e o que precisa. Devolvemos um plano com componentes, contratos e etapas de homologação.