IOSOR

IOSOR Guias

Ordem de eventos versus lançamento no ledger

Eventos DLR e MO fora de ordem não devem quebrar as regras de débito pré-pago — a sequência de chegada não é lei financeira.

As redes entregam retornos fora de ordem. Um DLR atrasado, um MO precoce ou uma inversão de status antes da liquidação não devem inventar um segundo débito ou reescrever uma linha liquidada. Esta página é o contrato de ordem de lançamento: as regras do ledger sobrevivem à reordenação — não é um guia de ID de correlação nem um ensaio de faturamento MO versus MT.

A ordem de chegada não é lei no ledger

A chegada HTTP é um acidente de transporte. O dinheiro é lançado sob retenção → liquidação → atualização de resultado, e não pelo último retorno recebido. Um valor flexível de USD 1,000/month trata a reordenação como um incidente financeiro quando o produto mostra sucesso enquanto o ledger se move duas vezes. USD 20 prova que um DLR tardio forçado nunca abre um débito paralelo. Replays do mesmo ID: Webhook duplicado não deve gerar um segundo débito.

O que a desordem parece na prática

Padrão de chegada Lançamento seguro Reação insegura
DLR antes da liquidação Pendente; liquidar uma vez sob retenção Débito apenas pelo DLR
Falha e depois entregue Atualizar resultado no local Segunda cobrança pela inversão
MO antes do MT correlacionar Arquivar na caixa de entrada; unir na liquidação Cobrar MO como saída
Status após reembolso Sem dinheiro novo; anotar Re-liquidar intenção liberada
Dois terminais, uma intenção Uma linha de dinheiro Duas linhas de débito .

Regras de lançamento que resistem à reordenação

Gere chaves de retenção e idempotência antes dos efeitos colaterais (Contrato de webhook antes do primeiro envio). Liquide uma vez por intenção faturável; eventos posteriores apenas atualizam o resultado. Nunca abra um débito paralelo para DLR ou MO precoce ou tardio. Rejeite ou estacione fora da janela assinada — sem sucesso inventado. Exporte junções por intenção, e não por carimbo de data/hora de chegada.

A latência é normal; dinheiro duplicado não é

As redes móveis falham. As filas atrasam durante as horas de calmaria e esvaziam de uma só vez. Quando os eventos chegam com horas de atraso, o ledger não deve recalcular saldos ativos com dados desatualizados. Valide sempre a janela de tempo antes de mexer no saldo.

Lista de verificação para a ordem de eventos

Exija que seu fornecedor prove que um DLR tardio não gera uma segunda cobrança. Verifique se a reconciliação agrupa por ID de intenção e não pela hora de chegada do servidor web. Garanta que as chaves de idempotência bloqueiem replays mesmo quando os status chegam invertidos.

Comece com IOSOR

No console: Event order vs ledger posting must reconcile by shared id.. Nomeie o dono e os gates antes de escalar.

Relacionado: duplicate webhook no second debit webhook consumer ops at volume.

Resumo IOSOR

A disciplina operacional exige que cada transação siga o fluxo rigoroso de governança. No console, identifique o proprietário responsável e valide a passagem pelo gate de segurança antes de qualquer registro. Jamais tente pular o gate ou ignorar os protocolos de validação no ledger, pois a ordem dos eventos deve refletir fielmente a exportação em UTC para auditoria. Siga as diretrizes em /learn/ledger-basics para garantir a integridade dos dados e evitar inconsistências no fechamento financeiro.

Este guia foi útil?

Guias relacionados