Código-fonte de uma plataforma iGaming.
Não é acesso a uma plataforma. É uma cópia do código, e é sua.
Esta página descreve o que abrange a compra da Callisto como código-fonte: o que é entregue, o que a sua equipa pode fazer com isso, o que continua sob a sua responsabilidade e como rever o código antes de qualquer decisão.
Tudo o preciso para construir sem nós.
Numa entrega de código-fonte o que conta não é o volume mas a completude: se a sua equipa consegue construir, fazer deploy e alterar a plataforma sem intervenção do fornecedor.
Uma cópia completa, com as bibliotecas partilhadas
Todos os serviços e as bibliotecas transversais que os sustentam — contratos de mensagens, acesso a dados, logging, autenticação — entregues como código e não como pacotes compilados vindos de um feed alojado por nós. O vosso build não fica, assim, dependente de infraestrutura que controlamos.
Cada serviço compila por si só
Cada serviço traz o seu Dockerfile, as suas migrações de base de dados, os seus testes unitários e de integração e o seu README. Um serviço pode ser tomado isoladamente e posto a correr de forma autónoma — é assim que se verifica a completude da documentação.
Deploy pelo seu próprio CI/CD
Os workflows de GitHub Actions e os ficheiros de Docker Compose fazem parte da entrega. Aponte-os ao seu registry e aos seus servidores: nada passa por infraestrutura que controlemos e não há passo de build que só nós saibamos correr.
A partir daí o histórico é vosso
A cópia entra no vosso próprio Git e, a partir desse ponto, o registo de commits pertence à vossa equipa: os vossos ramos, as vossas revisões, os vossos lançamentos. O repositório da própria Callisto fica connosco, porque a Callisto é um produto que continua a ser desenvolvido — é também por aí que as melhorias vos chegam enquanto mantiverem o suporte, como alterações que escolhem levar e não uma versão para a qual são empurrados.
A plataforma inteira, a funcionar.
Aproximadamente o que um comprador vê na primeira passagem técnica. O âmbito exacto fica no contrato: é o que está de facto a pagar e não pertence a uma página de marketing.
Para o jogador
- Front web do casino
- Carteira e caixa do jogador
- Registo, login e fluxos de KYC
- Portal de agentes
Operação
- Callisto Operator OS (backoffice)
- Gestão de jogadores, clientes e skins
- Revisão de pagamentos e lançamentos manuais
- Balcão de suporte
- Relatórios e dashboards
- Extratos, faturas e faturação
Serviços centrais
- Jogador, carteira, pagamentos, transacções
- Clientes, moedas, utilizadores e perfis
- Jogos, fornecedores de jogo e de casino
- Agentes, carteira de agente, afiliação
- Bónus e motor de bónus
- Jackpots progressivos
Conformidade e risco
- Serviço de jogo responsável
- KYC e revisão documental
- Alertas de conformidade e risco
- Trilhos de auditoria
- Regras de risco configuráveis
- Casos de revisão de conformidade
Envolvimento
- Hub de comunicação (in-app, email, push)
- Campanhas de marketing e audiências
- Site builder
- Webhooks de saída
- Web analytics e segmentos
- Telegram Mini App por skin
- Content Studio
Apoio de engenharia
- Migrações de base por serviço
- Suites de testes unitários e de integração
- Workflows de CI/CD
- Simuladores de fornecedores e de pagamento
Os simuladores merecem menção própria: permitem exercitar depósitos, apostas e pagamentos de ponta a ponta antes da assinatura de contratos com fornecedores — normalmente meses antes de tal teste ser possível de outra forma.
Ler, alterar, operar.
As três perguntas que as equipas técnicas colocam com mais frequência, respondidas antes da primeira reunião.
Alterar o que quiser, sem pedir
Todas as regras que tocam em dinheiro são legíveis e alteráveis pela sua equipa. Não há pedido de funcionalidade a abrir nem ciclo de lançamento alheio a aguardar.
Operar quantas marcas quiser
É para isso que existe o modelo de skins: um backend, muitas marcas, cada uma com o seu domínio, tema, moedas, métodos de pagamento e definições de jogo responsável. A arquitectura não prevê qualquer taxa por marca.
Continuar a operar se nos separarmos
Fica com o código, os contentores e a documentação. Suporte e actualizações são um serviço que pode deixar de comprar; não são uma verificação de licença que pare a plataforma. É a principal diferença face a um contrato white-label, e recomendamos que fique por escrito — connosco ou com qualquer outro fornecedor.
Os limites estão no contrato
Ser dono do código não equivale ao direito de revender a plataforma como produto concorrente. O que é concedido e o que fica reservado consta do contrato, em termos claros, antes da assinatura.
O que não está incluído.
Cada ponto abaixo é necessário à operação e não faz parte da entrega — nem da nossa, nem da de outros fornecedores de plataforma. Indicamo-los aqui para que sejam contemplados no planeamento e não descobertos durante a implementação.
A licença de jogo
A licença de cada mercado onde opera é sua. Nós damos os controlos, os bloqueios e os trilhos de auditoria por que um regulador pergunta; não emitimos, patrocinamos nem partilhamos licenças — nenhum fornecedor de software o pode fazer.
O conteúdo de jogo
A plataforma é uma camada de agregação com integrações de fornecedores. Os jogos são licenciados junto dos estúdios que os produzem, nas condições comerciais que acordar com eles.
Os contratos com prestadores de pagamento
Os prestadores ligam-se atrás de uma interface comum, mas a conta de comerciante, o underwriting e a reserva rotativa são entre si e o prestador. É habitualmente a rubrica mais longa de um calendário de lançamento.
Alojamento e operação
Auto-alojado significa que a operação fica do vosso lado: servidores, backups, monitorização e as equipas de prevenção. Podemos ajudar a montar tudo; a infraestrutura continua a ser vossa.
Aconselhamento jurídico e regulatório
Que controlos o seu mercado exige é questão para os seus consultores de conformidade. O que podemos dizer é exactamente como cada controlo está implementado, porque pode lê-lo.
Recomendamos pedir a lista equivalente a qualquer fornecedor que esteja a comparar.
Reveja o código antes de o comprar.
O código-fonte pode ser examinado por completo antes de qualquer decisão. Consideramos isso parte normal da avaliação e não uma concessão; a sequência abaixo é a que propomos.
- 1
Demonstração técnica da plataforma a correr
Um sistema em funcionamento em vez de slides: o backoffice, o front do casino e um depósito processado de ponta a ponta.
- 2
Uma sessão de revisão de código com os seus engenheiros
Percorremos a arquitectura com a sua equipa técnica e abrimos os ficheiros que pedirem: a carteira sob concorrência, os callbacks de pagamento, a aplicação das regras de jogo responsável. Sugerimos concentrar a revisão nesses três pontos: são os que concentram maior risco operacional.
- 3
A vossa própria due diligence no que importa
Cobertura de testes, histórico de migrações, tratamento de segredos, como os serviços se autenticam entre si, o que acontece quando um callback de fornecedor chega duas vezes. Sobre cada um destes pontos fornecemos evidências mediante pedido.
- 4
Âmbito e condições por escrito
Que repositórios, que direitos, como é o suporte depois e o que acontece se pararem. Acordado antes da assinatura, não descoberto depois.
Sair de um acordo de partilha de receita.
A razão mais frequente para chegarem aqui. A plataforma raramente é a parte difícil — os dados e os contratos é que são.
O cálculo económico
Uma partilha de receita cresce consigo e nunca pára. Ser dono do software converte uma percentagem sem fim num custo fixo mais a sua própria engenharia: pior em volume baixo e melhor, muitas vezes bastante, acima de certo ponto. Recomendamos determinar o vosso ponto de equilíbrio antes de avaliar propostas.
Os seus jogadores e os saldos deles
Contas de jogador, saldos, histórico de transacções e estados de KYC são migráveis, e o quão limpo isso corre depende inteiramente do que o fornecedor actual aceitar exportar. Essa pergunta deve ser colocada cedo: pesa no calendário mais do que o trabalho técnico.
Os fornecedores têm de ser recontratados
As integrações de jogo e de pagamento passam a estar em nome vosso depois da saída. Alguns fornecedores acompanham sem atrito, outros renegoceiam. É trabalho contratual em paralelo com a migração técnica — e é normalmente ele que fixa a data de lançamento.
Podem manter os dois durante algum tempo
Nada obriga a um corte único. É comum lançar primeiro uma marca nova na plataforma própria, aprender com ela e migrar a existente quando a operação estiver provada.
Perguntas sobre o código-fonte.
Estas perguntas surgem quando a conversa chega ao próprio código, e já não à plataforma em geral.
Entrega a sério. Escrow é um terceiro guardar o código e libertá-lo se o fornecedor falhar: não recebe nada enquanto nada correr mal, e nunca viu o que receberia. Aqui a cópia é entregue no início do trabalho: na vossa infraestrutura, no vosso Git e acessível aos vossos engenheiros de imediato. Se, além disso, o vosso departamento jurídico quiser cláusulas de escrow por razões próprias, isso é conversa de contrato, não um obstáculo técnico.
Sim, e isso é o desenho, não uma concessão. Suporte, correcções e módulos novos são um serviço que pode deixar de comprar. Nada «telefona para casa», nenhuma chave de licença expira e nenhum passo de build corre na nossa infraestrutura — não existe alavanca para puxar se saírem.
É uma plataforma a sério: mais de 35 serviços, e ninguém a tem toda na cabeça, nós incluídos. O que a torna assumível é os serviços serem pequenos, uniformes e com deploy independente — a mesma arquitectura e a mesma organização em cada um, pelo que quem percebe um conhece a forma de todos. Uma equipa de vários engenheiros aguenta-a; uma pessoa sozinha, não — e preferimos dizê-lo antes de a questão se tornar prática.
A Callisto é um produto e não um desenvolvimento à medida, por isso o mesmo código pode ser vendido a mais do que um comprador: nada na forma como é vendido o reserva a um só. Cada instalação corre na sua própria infraestrutura e com os seus próprios dados, e nenhuma instalação vê outra. A exclusividade num mercado é uma questão comercial e não técnica; se lhe importa, levante-a antes de assinar em vez de assumir qualquer das respostas.
É a plataforma que operamos, não uma implementação de referência feita para vender. Isto tem consequências nos dois sentidos: por um lado carga real e prestadores de pagamento reais; por outro, áreas em desenvolvimento activo visíveis no código. A revisão cobre o que pedirem para ver.
Depende do âmbito — módulos isolados, a plataforma completa, ou a plataforma com os nossos engenheiros ao lado da vossa equipa —, por isso um número numa página web seria ficção para a maioria dos leitores. Uma chamada chega para dimensionar o âmbito, e se a Callisto não servir, diremos isso.
Traga os seus engenheiros.
A forma mais rápida de avaliar uma plataforma entregue em código é a vossa equipa técnica lê-la com a nossa à frente. Diga-nos o que opera hoje e o que quer mudar.
Respondemos no prazo de um dia, normalmente no próprio.