Não existe “melhor modelo de carteira” fora da arquitetura da plataforma. A escolha entre carteira única e carteira de transferência depende do sistema atual de saldo, do tratamento de exceções, do processo de conciliação e do nível de mudança aceitável.
Este artigo explica critérios de avaliação e arquitetura. Ele não contém endpoints, protocolo de callback, assinatura, credenciais nem configurações de produção.
O que é carteira única
A carteira única também é conhecida como seamless wallet. Em termos simples, o saldo principal do jogador continua sob gestão da plataforma, enquanto consultas de saldo, débitos, créditos, cancelamentos e outras interações relacionadas aos jogos seguem o fluxo acordado entre as duas partes.
Na avaliação, é importante confirmar:
- se a interface da carteira da plataforma atende às necessidades de integração em tempo real;
- como serão tratadas as solicitações duplicadas e com falha;
- como saldo, transações e registros dos jogos serão conciliados;
- quem avalia e escala problemas na plataforma ou no fornecedor.
Carteira única não significa automaticamente “risco zero” ou “sem alterações”. Ela exige critérios mais claros para estabilidade da interface, processamento duplicado e responsabilidade por exceções.
O que é carteira de transferência
Na carteira de transferência, o saldo normalmente é transferido da plataforma para o fornecedor do jogo antes da sessão e, ao sair, volta ou tem seu restante tratado conforme o fluxo acordado.
Na avaliação, é importante confirmar:
- como são registrados a entrada, a saída e o status do saldo;
- como o fluxo se recupera após interrupção ou falha;
- como conciliar o saldo da plataforma com o saldo no fornecedor;
- se o caminho do jogador e a experiência atual da plataforma aceitam etapas adicionais.
A carteira de transferência também não significa automaticamente “mais simples”. Ela transfere parte da complexidade para o movimento de saldo, o controle de estado e a conciliação.
O que comparar entre os dois modelos
| Item | Foco da carteira única | Foco da carteira de transferência |
|---|---|---|
| Arquitetura atual | Se a carteira da plataforma colabora de forma estável | Se já existe gestão madura de transferências e estados |
| Tratamento de exceções | Duplicidade, timeout, falha e consistência do saldo | Interrupção, estado desconhecido e recuperação da transferência |
| Conciliação | Registros de transação, rodada e saldo | Saldo e movimentações na plataforma e no fornecedor |
| Caminho do usuário | Experiência de integração em tempo real durante o jogo | Se entrada e saída de saldo afetam a experiência |
| Escopo técnico | Requisitos de callback e idempotência | Requisitos de transferência de saldo e máquina de estados |
A tabela organiza a conversa técnica e não representa compromisso da AG com uma implementação, desempenho ou automação específicos.
O que os testes devem abranger
Independentemente do modelo escolhido, não se deve validar apenas o caminho de sucesso. Recomendamos confirmar, no mínimo:
- início normal e fluxo normal de transações;
- saldo insuficiente, falha de solicitação ou sessão anormal;
- solicitação duplicada ou repetição de estado;
- forma de conciliar diferenças de registro, rodada ou saldo;
- materiais do problema, responsáveis e forma de escalonamento.
O que um artigo público não pode decidir
Protocolo completo da interface, domínio do ambiente, assinatura, campos de callback, credenciais, lista de permissões, latência, capacidade, estabilidade, condições de mercado e termos comerciais devem ser confirmados em um processo de projeto controlado.
O que a AG pode confirmar hoje é que os materiais de negócio existentes abrangem carteira única e carteira de transferência. A compatibilidade específica, o ambiente de testes e o escopo de entrega ainda dependem da arquitetura da plataforma e da confirmação do projeto.
Precisa transformar estas orientações em um plano de projeto?
Este artigo apoia a avaliação do projeto e não substitui a validação técnica, contratual, de certificação ou da legislação local.