Changelog

2026-10-18: confirmação financeira e controles de mercado

Mudança de compatibilidade da carteira: respostas de sucesso de débito, crédito e rollback passam a exigir o txId exato, balance inteiro explícito e a mesma currency. Antes, o ID podia ser omitido. Atualize e homologue a carteira antes de adotar esta revisão do servidor. Respostas 4xx vazias/inválidas ficam incertas.

• Limites de exposição passam a reservar capacidade antes do débito e no aceite, incluindo pagamentos pendentes e correções não recuperadas. Novos escopos: competição, marca, grupo explícito de eventos e empresa por moeda/ambiente. O limite da empresa exige dois administradores da plataforma; os novos tetos começam desativados.
• Em produção, sessões de jogadores passam a exigir integração do operador e carteira seamless. Endpoints locais de conta, KYC e caixa retornam 403 operator_managed; tokens antigos de login local são recusados. Login de staff e controles de conta, jurisdição, sessão e limites permanecem. Jogadores integrados com carteira seamless não precisam de consulta nem heartbeat de localização, em staging e produção. O módulo B2B inicia sem esse provedor e não registra um país fictício; esta mudança não homologa a operação com dinheiro real.
• Créditos incertos substituídos por correções ficam para revisão; o conciliador da carteira não ultrapassa a fila financeira.
• Apostas revalidam após a resposta da carteira; cash-out recalcula antes da confirmação. Catálogo, apostas de longo prazo, mercados especiais e produtos suplementares protegem as alterações locais de preço/estado na implantação com uma única instância, com prazo também para adquirir a trava.
• Mercados especiais fecham e gravam um resultado recuperável na mesma transação, antes da liquidação. Uma interrupção no envio é recuperada automaticamente a partir desse resultado; novas apostas não atravessam o fechamento.
• Alterações do catálogo e seus resultados são gravados juntos antes da publicação. A confirmação de apostas e cash-outs lê o catálogo persistido e as regras atuais de preço/produto do operador; um cache antigo não ignora um bloqueio confirmado. Resultados pendentes sobrevivem a interrupções prolongadas. A implantação continua limitada a uma API enquanto as outras fontes e os controles de exposição são migrados.
• A entrada dos feeds fica persistida antes do avanço do checkpoint. Estatísticas, verificação, resultados derivados e confirmação no catálogo são recuperáveis após falha ou reinício. Mensagens antigas mantêm sua idade; filas atrasadas tornam a API indisponível e impedem decisões financeiras com preços desatualizados.
• Virtuais, sorteios e corridas gravam estado e resultados juntos. A cotação final lê a revisão atual do banco e recusa dados vencidos do fornecedor. Consultas concorrentes não sobrescrevem um estado mais novo; a liquidação dos sorteios inclui as combinações confirmadas antes do fechamento. O compromisso RNG publicado fica preservado, e resultados virtuais incompletos são consultados novamente. Controles compartilhados de exposição/compliance e homologação externa ainda impedem declarar prontidão para múltiplas APIs ou dinheiro real.
• Mercados de longo prazo gravam preços, controles e resultados pendentes juntos. Apostas e cash-outs recusam um preço quando seus jogos de referência mudam ou sua atualização expira. Edições independentes preservam bloqueios do operador, e resultados automáticos continuam recuperáveis até a entrega durável. A restrição a uma API permanece.
• Correção sem saldo é recusada para análise, sem saldo negativo, cobrança parcial ou captura de depósitos futuros. Recusas persistidas permanecem definitivas.
• Obrigações financeiras preservam a identidade e seguem ordem por aposta; anteriores não resolvidas impedem correções posteriores.
• Controles de mercado separam bloqueio do operador de restrições do feed/plataforma e são persistidos antes da confirmação.
• Back-office mostra obrigações pendentes separadamente do resultado da aposta e do histórico de callbacks.
• Deduções mensais, repasses e o código de aprovação da fatura independem do fuso da sessão do banco; movimentos de apostas mantêm os limites do período em UTC.
• A inicialização de produção recusa feeds/histórico simulados, a identificação padrão de fornecedor fictício e simuladores de identidade/pagamento habilitados. Staging mantém suas simulações; a homologação de fornecedor e carteira continua necessária.
• Incluídos OpenAPI, homologação e guia do operador.

2026-10-17: sessões pelo ID da plataforma

• Removida a exigência de CPF das sessões integradas, inclusive no perfil BR; a identidade usa tenant + externalPlayerId.
• O campo legado cpf é aceito e ignorado. Não é validado nem armazenado em novas sessões; o exemplo Node não o envia.
• A autorização de apostas dos jogadores integrados não exige CPF nem consulta listas por CPF. Restrições locais e demais controles de apostas continuam aplicáveis.
• Cadastro, CPF, KYC e caixa continuam na plataforma do cliente. IDs e históricos de jogadores existentes são preservados.

2026-10-17: escopo da integração esclarecido

• O OrbiSportbook fornece o sportsbook via iframe; cadastro, validação de CPF, KYC, caixa, depósitos e saques pertencem à plataforma do cliente.
• Removidas a oferta de plataforma completa e a nota sobre situação legal no Brasil. A personalização se aplica ao sportsbook.
• Esclarecidos o status de KYC delegado e a dependência de CPF que existia naquele momento nas sessões do perfil BR. Nenhum comportamento de API, carteira ou tenant foi alterado.

A integração segue a política de versionamento: adições compatíveis dentro de uma versão, uma nova URL do SDK para mudanças incompatíveis.

v1 · 2026-10-16

Primeira versão pública da integração por iframe.

API

• POST /api/v1/integration/sessions também devolve launchToken (uso único, 120 segundos), launchExpiresAt e launchUrl, e aceita path e locale para a URL de abertura.
• Novo POST /api/v1/integration/launch: troca um launch token, uma única vez, pelo token de sessão. Recusas trazem details.reason: launch_token_invalid, launch_token_used, launch_token_expired.
• GET /api/v1/config expõe tenant.embedOrigins.
• As páginas do sportsbook trazem Content-Security-Policy: frame-ancestors a partir dos embedOrigins do tenant.

SDK de incorporação

• /embed/v1.js (global OrbiSportbook) e @bookmaker/embed-sdk (módulo ES com tipos): mount() com launch tokens, tamanhos auto e fill, links diretos, idioma, cada evento como callback e cada comando como método; verificação de origem em toda mensagem.

Protocolo postMessage v1

• Eventos: ready, resize, route, login_required, session_expired, balance_changed, bet_placed, bet_settled, deposit_requested, error.
• Comandos: set_launch_token, navigate, set_locale, refresh_balance, logout.

Obsoleto

• Abrir o sportsbook com o token de sessão na URL (?token=). Continua funcionando; migre para ?launch= ou para o SDK.

Tentativas duráveis e reserva de responsabilidade

Cada tentativa reserva no PostgreSQL a responsabilidade configurada por resultado antes do débito. Repetições mantêm a mesma operação; uma resposta tardia não aceita uma tentativa expirada. Devoluções permanecem pendentes até confirmação, inclusive após reinício. Preço de partida e preço fixo do mesmo corredor compartilham responsabilidade; SP/BOG usam o teto de pagamento na reserva. Isso não certifica controles agregados de risco nem contratos de carteira em produção.