Ciclo de vida do bilhete de loteria: aceitação, liquidação e recuperação
Um bilhete de loteria é mais do que uma linha no histórico de compras do jogador. Ele conecta um produto, um sorteio, uma operação financeira e o direito a um resultado. Quando esses registros divergem, o atendimento não consegue explicar se a compra foi concluída, o financeiro não consegue conciliar o saldo e o operador […]
Um bilhete de loteria é mais do que uma linha no histórico de compras do jogador. Ele conecta um produto, um sorteio, uma operação financeira e o direito a um resultado. Quando esses registros divergem, o atendimento não consegue explicar se a compra foi concluída, o financeiro não consegue conciliar o saldo e o operador pode liquidar a mesma transação duas vezes.
Este guia para operadores explica o ciclo de vida do bilhete, da seleção à liquidação. Use-o para definir requisitos de uma plataforma de loteria e transformar uma demonstração comercial em testes concretos de aceitação.
Defina o bilhete antes de definir seus estados
Documente o jogo, o identificador do sorteio, a seleção, o valor, a moeda, o canal de venda e a versão das regras aplicáveis. O bilhete deve ter um identificador estável vinculado à operação financeira. Diferencie um bilhete com várias linhas de cada participação individual; caso contrário, uma compra parcialmente rejeitada será difícil de representar.
O sistema de referência também precisa definir o encerramento das vendas, o relógio oficial e qual registro de horário determina a aceitação. Uma solicitação recebida antes do encerramento não é necessariamente uma participação aceita. Essa distinção deve aparecer na interface e nos procedimentos operacionais, não apenas na documentação técnica.
Crie uma matriz de estados e movimentações financeiras
Os rótulos devem descrever o que aconteceu, quem pode agir depois e o que aconteceu com o dinheiro. O exemplo abaixo define requisitos, não uma nomenclatura obrigatória.
| Estado | Visão do jogador | Tratamento financeiro | Evidência necessária |
|---|---|---|---|
| Rascunho | Seleção ainda não comprada | Sem débito | Seleção e preço apresentado |
| Enviado | Confirmação pendente | Reserva, se o desenho a utilizar | ID da solicitação e horário de envio |
| Aceito | Participação no sorteio indicado | Débito da compra registrado | ID do bilhete, sorteio e horário de aceitação |
| Rejeitado | Participação não aceita | Liberar reserva; estornar qualquer débito associado | Motivo e ajuste financeiro vinculado |
| Liquidado | Resultado e prêmio disponíveis | Crédito do prêmio quando aplicável | Versão do resultado e ID da liquidação |
| Cancelado | Participação sem validade | Reembolso conforme as regras aplicáveis | Autorização, motivo e referência do reembolso |
Não substitua a compra pelo reembolso. Preserve a operação original e um ajuste vinculado. A arquitetura de pagamentos deve mostrar essa relação durante a conciliação.
Cenário: a compra expira perto do encerramento do sorteio
O jogador envia uma compra, o servidor a aceita, mas a resposta de confirmação se perde. O jogador tenta novamente após o encerramento. Um desenho seguro precisa responder explicitamente a cada etapa:
- A nova tentativa usa a mesma chave de operação e recupera o resultado existente, sem criar outro bilhete.
- O bilhete aceito mantém seu sorteio e horário de aceitação originais; a nova tentativa não o transfere para outro sorteio.
- A carteira mostra um único débito de compra, com qualquer reserva temporária resolvida.
- A interface apresenta o resultado final e o atendimento pode consultar a sequência de eventos sem alterá-la.
Peça ao fornecedor que demonstre essa sequência, incluindo a solicitação rejeitada. Uma imagem de uma compra bem-sucedida não testa a recuperação.
Testes de aceitação que o operador deve solicitar
- Uma solicitação repetida não cria participações ou débitos duplicados.
- Uma compra com várias linhas parcialmente rejeitada tem preço e resultado explicáveis.
- O cancelamento de um sorteio segue o reembolso aprovado sem apagar o histórico.
- Um resultado corrigido gera um ajuste de liquidação rastreável, não uma substituição invisível.
- Web, aplicativo e pontos de venda aplicam as mesmas regras de aceitação e apresentam estados consistentes.
Inclua permissões, responsáveis por escalonamento e retenção de evidências na lista de segurança e serviço. Conecte mudanças de resultado à integridade dos sorteios e trilhas de auditoria.
Especifique evidências de integração e entrega
Documente identificadores de solicitações, consultas de estado, entrega de eventos, novas tentativas e exportações de conciliação nos requisitos da API de loteria. Defina como localizar solicitações não resolvidas e quem pode resolvê-las. Em uma migração de plataforma, preserve identificadores de bilhetes, referências históricas de sorteios e obrigações pendentes; migrar apenas os saldos não basta.
Perguntas sobre o ciclo de vida do bilhete
Confirmar o pagamento significa aceitar o bilhete?
Não necessariamente. Pagamento e aceitação são eventos distintos, a menos que a arquitetura documentada os una em uma operação controlada.
Todas as plataformas devem usar esses nomes?
Não. Os nomes podem variar, mas aceitação, rejeição, liquidação e cancelamento precisam ter significados inequívocos.
Um administrador pode alterar um bilhete?
Defina ações permitidas, aprovações e evidências de auditoria. Nenhuma mudança deve ocultar o registro original aceito.
O que uma demonstração técnica deve incluir?
Uma compra normal, uma nova tentativa, uma rejeição por encerramento, um cancelamento e uma correção de resultado, ligados aos registros financeiros.
Converse sobre seu fluxo de bilhetes
Prepare tipos de jogos, canais, regras de encerramento e limites atuais de integração. CONTATO com a WhiteLotto para discutir o ciclo de vida necessário e as evidências a solicitar em uma demonstração.