Arquitetura de carteira e conciliação de loteria: checklist para operadores
Uma carteira de loteria é mais do que o saldo exibido ao jogador. A escolha da plataforma precisa considerar o registro de transações por trás desse saldo, a liquidação das compras e dos prêmios e como a área financeira identifica diferenças entre sistemas. Este checklist aborda esses limites operacionais. Escolher um provedor de pagamentos é […]
Uma carteira de loteria é mais do que o saldo exibido ao jogador. A escolha da plataforma precisa considerar o registro de transações por trás desse saldo, a liquidação das compras e dos prêmios e como a área financeira identifica diferenças entre sistemas.
Este checklist aborda esses limites operacionais. Escolher um provedor de pagamentos é outra decisão: consulte o guia da arquitetura de pagamentos de loteria para comparar métodos, processadores e acordos comerciais. Aqui, a pergunta é se cada movimento pode ser explicado e conciliado.
Defina o significado de cada saldo
Solicite um dicionário de saldos antes de analisar telas. Diferencie dinheiro disponível, valores reservados, saldos promocionais e saques pendentes. Especifique a moeda de cada valor, a política de conversão quando aplicável e o sistema que é a fonte oficial de cada estado.
- O suporte consegue explicar por que o saldo disponível difere do saldo do registro contábil?
- Quais ações reservam, liberam, debitam ou creditam valores, e quem pode iniciá-las?
- A exportação inclui saldo inicial, movimentos e saldo final com referências estáveis?
Mapeie o ciclo do bilhete e da liquidação
Defina o comportamento esperado antes de aprovar uma integração. Uma notificação de pagamento, um bilhete aceito e o resultado final do sorteio são eventos diferentes: especifique como se relacionam.
| Evento | Pergunta de aceitação |
|---|---|
| Compra aceita | Existe uma ligação rastreável entre o bilhete, o débito e seu estado final? |
| Compra rejeitada | Os valores reservados são liberados sem emitir um bilhete válido para jogar? |
| Cancelamento ou reembolso | A reversão está ligada ao lançamento original e a um motivo autorizado? |
| Liquidação do prêmio | Cada crédito pode ser rastreado até o sorteio, bilhete e versão de liquidação? |
Combine o tratamento de novas tentativas e exceções
HTTP não torna qualquer repetição segura: a RFC 9110 distingue métodos idempotentes. Combine o tratamento de duplicidades em compras, pagamentos e notificações na aplicação; não o deduza de uma resposta bem-sucedida da API.
- Repita a mesma referência de compra e verifique que não produz outro débito ou bilhete indesejado.
- Interrompa a resposta após o envio e demonstre como recuperar o estado final da operação.
- Defina o tratamento de notificações atrasadas, duplicadas ou fora de ordem, com escalonamento quando a recuperação automática falhar.
Planeje a conciliação para finanças, não só para desenvolvimento
Para um registro de dinheiro e uma moeda, concilie saldo inicial mais créditos contabilizados menos débitos contabilizados com o saldo final. Defina todas as categorias de lançamento e o corte do relatório: essa verificação, isoladamente, não concilia o provedor de pagamentos nem o banco.
Compare separadamente os registros da plataforma com liquidações do processador e registros bancários pertinentes. Documente tarifas, reembolsos, chargebacks, diferenças cambiais e de prazo. Cada exceção precisa de responsável, evidência, estado e histórico de resolução. O guia de integração de API de loteria ajuda a definir os dados trocados entre sistemas.
Controle ajustes e proteja a trilha de auditoria
Estabeleça aprovações para ajustes manuais, reembolsos e acesso às exportações. Exija responsável, momento, motivo e identificadores de transação vinculados em cada alteração. A OWASP recomenda excluir ou proteger credenciais e dados sensíveis de pagamento nos logs.
Inclua acesso às exportações e resposta a incidentes na avaliação de segurança e SLA. Ao trocar de plataforma, combine como comprovar saldos iniciais e bilhetes pendentes durante a migração de plataforma, sem reconstruí-los depois do lançamento.
Use quatro casos de aceitação na demonstração
Peça o histórico de eventos, os lançamentos e a exportação financeira de cada caso. Avalie o fluxo completo, não uma imagem do saldo final. Registre os casos não suportados e o trabalho necessário antes de assinar.
- Uma compra normal seguida do resultado do sorteio e de uma liquidação rastreável, com ou sem prêmio.
- Uma compra rejeitada seguida da liberação da reserva, sem débito duplicado após nova tentativa.
- Um cancelamento ou reembolso com referência original, responsável autorizado e exportação consistente.
- Uma diferença de conciliação deliberada em ambiente de teste, atribuída a um responsável e resolvida com evidências.
Inclua os limites operacionais no escopo
Compare os módulos da plataforma e o escopo de entrega com as responsabilidades de registro contábil, processador e finanças de que precisa. Especifique quem configura regras, monitora exceções, aprova mudanças e fornece exportações. Inclua essas entregas no plano de implantação, em vez de deixar a conciliação para depois do lançamento.
Referências técnicas
- RFC 9110: semântica HTTP e métodos idempotentes (em inglês)
- OWASP: orientações sobre logs (em inglês)
Converse sobre carteira e conciliação
Traga seu fluxo de pagamentos, moedas, responsabilidade pelo registro contábil e requisitos atuais de relatórios. A WhiteLotto pode discutir o escopo da plataforma e as questões de integração do seu projeto.