Um ledger regista movimentos financeiros com regras verificáveis.
Um ledger regista movimentos financeiros com regras verificáveis. O saldo apresentado é uma vista desses movimentos, por vezes com reservas e valores pendentes. Um único campo editável dificulta explicar alterações e recuperar operações interrompidas.
Definir os montantes do produto
Descreva disponível, pendente, reservado e liquidado com autorizações expiradas, capturas parciais e reembolsos posteriores. Determine o que o cliente pode gastar e o que cada relatório mostra. Represente moeda e precisão explicitamente com aritmética exata adequada. Evite interpretações diferentes do mesmo estado em cada ecrã.
Proteger identidade e concorrência
Cada movimento pretendido precisa de uma identidade estável. Os lançamentos relacionados devem preservar invariantes mesmo perante solicitações simultâneas. Se adotar partidas dobradas, verifique equilíbrio na moeda e âmbito definidos. Uma projeção de saldo deve poder ser reconstruída sem repetir a operação externa. A identidade financeira não é equivalente à referência de entrega de uma mensagem.
Testar correções e reconstrução
Registe estornos ou ajustes com referência ao original, motivo e aprovação. Teste gastos concorrentes, repetições e interrupções num conjunto conhecido. Compare saldo calculado e projeção no mesmo instante de referência. Um ledger equilibrado não substitui reconciliação do prestador nem validação contabilística; fornece movimentos explicáveis para esses controlos. Investigue diferenças em vez de alterar silenciosamente o histórico até os totais coincidirem.
Um exemplo para validar
Duas solicitações simultâneas podem tentar reservar o mesmo saldo disponível. Verifique que o limite acordado se mantém após ambas as respostas, nos movimentos e no ecrã. Reconstrua depois a projeção desde os registos e compare resultados. A reconstrução não deve chamar o prestador para movimentar dinheiro outra vez. Registe reservas pendentes e operações recusadas. Este ensaio mostra se a verdade financeira está em dados duradouros ou depende acidentalmente de uma atualização de cache que se pode perder durante um reinício do serviço.
- Serviço relacionado
- Reembolsos e contestações: preparar os casos de falha
- Auditar pagamentos: cobranças duplicadas e operações em falta
Perguntas frequentes
Um saldo já é um ledger?
Não. Não explica sozinho os movimentos e correções.
Partidas dobradas são obrigatórias?
Depende do modelo; quando adotadas, os invariantes devem ser implementados e verificados.
Podemos colocar saldos em cache?
Sim, se a projeção for controlada e reconstruível a partir dos registos de referência.
Como gerir várias moedas?
Separe valores e defina conversões, sem somar diretamente moedas diferentes.
Como corrigir um erro?
Com ajuste ou estorno rastreável, relacionado com o original e aprovado.
Da ideia a um âmbito que se consegue executar
Partilhe o percurso do utilizador, integrações e condições de lançamento. Podemos preparar uma estimativa com pressupostos e exclusões.
Leitura complementar
Reembolsos e contestações: preparar os casos de falha
Pedir um reembolso, obter aceitação e concluir o movimento de dinheiro são estados diferentes.
Auditar pagamentos: cobranças duplicadas e operações em falta
Uma página de confirmação não prova que o pagamento foi tratado de ponta a ponta.
Idempotência de webhooks: impedir efeitos de pagamento duplicados
A idempotência garante o efeito pretendido de uma operação lógica mesmo quando a entrega ou execução se repete.