Para quem é
Operadoras que precisam de jogos com resultado decidido no servidor e studios que precisam integrar jogos a uma carteira com rastreabilidade.
Problema que resolve
Jogos que calculam o resultado no navegador, ou que falam com a carteira sem contrato, são difíceis de auditar. O Provider concentra a regra do jogo e o contrato financeiro num único lugar.
Capacidades comprovadas
O que Game Provider faz hoje
Jogos com resultado no servidor
Foguete Crash, Minas, Plinko, Fortune Reels (slot de 5 rolos) e Truco Paulista em mesa sem valor monetário. O sorteio usa HMAC-SHA256 do módulo de criptografia do runtime, e um teste automatizado impede Math.random na matemática do provedor.
Sorteio verificável no Foguete Crash
O servidor publica o hash da semente antes da rodada e revela a semente ao final; qualquer pessoa pode conferir o resultado por endpoint público de verificação.
Matemática versionada
Cada rodada guarda a versão da matemática usada. Uma versão já utilizada nunca é alterada: cria-se uma nova.
Ciclo do round no banco
Estados de rodada persistidos em PostgreSQL, com transições condicionais que impedem avanço ou liquidação duplicados.
Apostas, cashout e settlement
Aposta só é aceita após o débito confirmado; cashout com atualização condicional (sem duplo cashout); fechamento por rodada com total apostado, total pago e GGR.
Eventos em tempo real por SSE
Snapshot inicial, mudanças de estado do round, multiplicador a cada tick e apostas públicas, com reconexão orientada pelo servidor.
Integração autenticada
Operadores usam API key e HMAC-SHA256 do corpo; sessões de jogo são tokens curtos, sem saldo nem dados pessoais, guardados como hash.
Rastreabilidade por requisição
requestId propagado até a carteira; cadeia jogador → sessão → round → aposta → transação → requestId.
Admin técnico e Round Inspector
Painel com rodadas, transações, catálogo e auditoria; o inspetor mostra sementes, apostas, eventos e a verificação do resultado.
Ciclo do round
Do compromisso ao settlement
O estado do round é derivado de relógios gravados no banco e cada transição é condicional: um round não avança nem é liquidado duas vezes.
WAITING
Compromisso
O round nasce com a semente do servidor já sorteada; só o hash dela é publicado.
BETTING
Janela de apostas
Apostas são debitadas na carteira antes de aceitas.
RUNNING
Em andamento
O multiplicador sobe; o cashout é condicional e idempotente.
CRASHED
Crash
A semente é revelada e o resultado passa a ser verificável.
SETTLED
Liquidado
Prêmios creditados e totais do round fechados.
Provably fair, na prática: o hash da semente é publicado antes das apostas; ao final, a semente é revelada e qualquer pessoa pode recalcular o resultado. Como o resultado depende apenas de semente do servidor, semente pública e nonce, o valor apostado e o saldo não o influenciam.
Jornada principal
Ciclo do Foguete Crash
Compromisso (commit)
Ao criar o round, o servidor sorteia a semente, publica seu hash e já grava o ponto de crash.
Janela de apostas
Apostas são debitadas na carteira antes de serem aceitas; se o débito falha, a aposta é recusada.
Round em andamento
O multiplicador cresce por uma curva determinística; o cashout é condicional e idempotente.
Crash e revelação
No crash, a semente é revelada e o resultado passa a ser verificável.
Settlement
Apostas são liquidadas, prêmios creditados na carteira e o round fechado com totais e GGR.
Limites deliberados
O que Game Provider não faz
Fronteiras claras evitam expectativas erradas — e integrações improvisadas.
- Não é a fonte de verdade do saldo: o ledger espelho do Provider serve à auditoria; o saldo mestre é da carteira do BetBackoffice.
- Nunca escreve no banco do BetBackoffice: toda movimentação passa pela Wallet API.
- Não oferece hoje notificações ao operador por callback/webhook.
- Não é auditoria externa nem certificação de RNG: os testes estatísticos e de determinismo são internos.
- Não usa WebSocket nem Redis: o tempo real é SSE e o estado autoritativo vive no PostgreSQL.
Integrações
Como Game Provider se conecta
BetBackoffice
Debita, credita, estorna e reverte pela Wallet API, com transactionId idempotente e timeout definido.
BetFront
Recebe pedidos de sessão assinados e devolve a URL do jogo; o navegador acompanha o round por SSE.
Visão técnica
Contratos, dados e segurança
Em nível público: comportamentos comprovados, sem endereços nem detalhes de infraestrutura.
Resultado independente de aposta e saldo
O resultado depende apenas de semente do servidor, semente pública e nonce.
Estados do round
WAITING, BETTING, RUNNING, CRASHED e SETTLED, derivados de relógios gravados no banco.
Eventos SSE
snapshot, round.waiting, round.betting, round.running, round.multiplier, round.crashed, round.settled, live e stream.end.
Falhas de carteira
Débito recusado rejeita a aposta; se a janela fecha após o débito, a aposta é estornada e registrada.
Prontidão e migrations
Liveness e readiness (banco, schema e carteira) sem expor detalhes; migrations com checksum e job isolado.
Continue pela plataforma
Experiência digital do jogador
BetFront
Cadastro, login, lobby, carteira e abertura de jogos em uma experiência mobile-first, com as regras financeiras e de jogo responsável aplicadas no servidor.
Ver produtoCentro de controle operacional e financeiro
BetBackoffice
Onde a operação enxerga e decide: jogador 360, carteira e ledger, saques com alçadas, KYC, risco, jogo responsável e auditoria — e onde nasce o contrato de carteira usado pelos jogos.
Ver produtoGovernança de pré-certificação e prontidão
MotorGLI
Organiza o processo de avaliação de prontidão em etapas: escopo, cenários por pilar, resultado, findings, reteste, revisão final e pacote de submissão — fora do caminho transacional.
Ver produtoVamos conversar sobre Game Provider
Conte o contexto da sua operação. Respondemos com os próximos passos de integração e homologação.