Detecção de transação, confirmação na cadeia, associação ao pedido e entrega do serviço são etapas separadas. Verifique a cadeia, o ativo, o destinatário e o valor corretos; aplique uma política de aceitação documentada; e torne a reconciliação idempotente. Uma referência de transação, captura de tela ou botão do navegador sozinho não pode estabelecer que um pedido específico foi pago.
Separe o evento da cadeia do evento do pedido
Uma carteira informar que uma transferência foi enviada é evidência sobre sua própria ação, não uma decisão completa de pagamento. O backend de recebimento deve observar a rede pretendida, verificar a transferência real e associá-la a um pedido. Só então o pedido pode aplicar sua política de aceitação. A entrega da infraestrutura é outra etapa operacional após a aceitação do pagamento.
Mantenha essas transições explícitas tanto no código quanto na linguagem para o cliente. Uma tela pode mostrar aguardando, detectado ou confirmando sem chamar o pedido de pago. Não deixe o navegador fornecer o valor aceito ou sobrescrever um status autoritativo. Armazene a cotação criada pelo servidor e suas instruções para que a reconciliação posterior possa ser avaliada em relação ao pedido original, e não a um carrinho em mudança.
Use regras de confiança específicas de cada cadeia
Redes diferentes descrevem a confiança em uma transação de maneiras diferentes. O guia do desenvolvedor da Bitcoin explica como os nós selecionam a cadeia com mais prova de trabalho acumulada e como blocos concorrentes podem ocorrer. Uma transação vista recentemente, portanto, precisa de uma política para profundidade de confirmação e possíveis mudanças de cadeia. Não há uma contagem única de confirmações adequada a todos os ativos e riscos comerciais.
A documentação de proof-of-stake da Ethereum explica a finalidade de checkpoint, enquanto a Solana documenta os estados de compromisso processed, confirmed e finalized. Não traduza esses termos casualmente para uma contagem universal de blocos. Registre a regra específica da rede, a fonte de informação e o comportamento durante a incerteza. O operador deve determinar os limites de aceitação em relação ao risco de pagamento e entrega, não copiar um número de um checkout não relacionado.
Verifique o payload real da transferência
Identifique o destinatário, o ativo e o valor na cadeia correta. Pagamentos de tokens precisam da identidade do token pretendido, não apenas de uma transação bem-sucedida para um endereço. Verifique o sucesso de execução relevante e a evidência de transferência de acordo com o modelo da cadeia. Faça o parsing de valores inteiros na precisão adequada do ativo em vez de confiar em um decimal formatado fornecido pelo navegador.
Uma instrução de pagamento deve permanecer vinculada à sua rota original. Uma transferência em outra rede, um token diferente com o mesmo símbolo ou uma referência de transação não relacionada não deve satisfazê-la. O registro de verificação deve explicar o que foi verificado e preservar as evidências necessárias para revisar a decisão. Este guia descreve princípios gerais de reconciliação de pagamentos, não a implementação de um serviço específico.
Torne a associação ao pedido inequívoca
Endereços de recebimento fixos podem receber vários pedidos com valores semelhantes. A existência de uma transferência correspondente não prova qual cliente ou pedido deve receber o crédito. Defina o método de associação antes de aceitar pagamentos reais e inclua o tratamento de colisões. Uma referência de transação fornecida pelo usuário ainda exige validação de que a mesma transferência não foi atribuída a outro lugar.
Imagine duas faturas do mesmo valor na mesma rota durante uma janela sobreposta. Um observador vê uma transferência. Marcar automaticamente ambas como pagas é errado; escolher uma sem evidência suficiente também é inseguro. Mantenha a transferência não alocada ou em revisão até que a política do operador possa estabelecer uma associação válida. Uma correspondência ambígua é um estado a ser tratado, não um motivo para fabricar certeza.
Defina estados que tolerem evidências tardias e mutáveis
Um processo de pagamento se beneficia de um pequeno conjunto de estados claros, com a evidência da cadeia separada da decisão de aceitar um pedido. Esta tabela ilustrativa explica estágios possíveis em vez de descrever os nomes de status de um serviço específico. Cada transição deve ter um motivo verificado, e a aceitação do pagamento deve permanecer distinta da entrega da infraestrutura.
Inclua transferências tardias, parciais e em excesso, expiração de cotação e dados de cadeia temporariamente indisponíveis. A expiração não faz uma transferência real desaparecer. Um pagamento tardio pode exigir revisão em vez de aceitação ou rejeição automática. Se um evento de cadeia observado anteriormente mudar, reavalie o estado sob a política documentada em vez de tratar cada notificação do observador como verdade irreversível.
| Estado ilustrativo | Significado | Próxima decisão |
|---|---|---|
| Aguardando | Nenhuma transferência qualificável verificada | Continuar observando a fatura válida |
| Detectado | Transferência relevante observada | Verificar confiança na cadeia e associação |
| Confirmando | Regra de aceitação ainda não atendida | Observar até que a política permita a decisão |
| Revisão | Evidência tardia, parcial ou ambígua | Resolver conforme a política do operador |
| Aceito | Pagamento verificado e reconciliado | Prosseguir para o fluxo de entrega separado |
Torne as novas tentativas seguras e observáveis
Observadores e tarefas de reconciliação tentarão novamente após conexões interrompidas ou reinicializações de processos. Use uma identidade de transferência estável, como a cadeia e o identificador apropriado de transação ou transferência, para evitar créditos duplicados. Persista o progresso e as decisões para que o mesmo evento possa ser processado novamente sem provisionar um segundo serviço ou alterar uma cotação aceita.
Distinga um resultado desconhecido de uma operação falhada. Se uma solicitação downstream expirar, inspecione seu resultado autoritativo antes de reenviar. Mantenha registros duráveis de ações aceitas e incertas. Restrinja o acesso a tokens de pedido e evidências internas, mantendo informações suficientes para investigar um pagamento contestado. Confiabilidade aqui se trata de decisões repetíveis, não de uma animação fluida no checkout.
Saiba do que um pedido pendente ainda precisa
Um pedido pode permanecer pendente porque a transferência não foi observada, a confiança exigida na cadeia não foi alcançada ou sua associação com a fatura precisa de revisão. Preserve a fatura e a referência pública da transação, verifique as regras de aceitação declaradas e use o processo de assistência pretendido do pedido. Uma atualização de status atrasada não é, por si só, motivo para enviar outro pagamento.
Siga as instruções e o status verificado do pedido real. A confirmação de pagamento deve identificar a aceitação da transferência reconciliada, enquanto a entrega do serviço tem um status separado. Mantenha tokens de acesso privados e segredos de carteira fora de solicitações de ajuda.
Sua lista prática.
- Persista uma cotação imutável criada pelo servidor.
- Verifique cadeia, destinatário, ativo e valor inteiro.
- Documente regras de aceitação específicas de cada cadeia.
- Lide com colisões de endereços fixos sem adivinhar.
- Evite créditos duplicados e envios de novas tentativas inseguros.
- Teste casos de transferências tardias, parciais, de rota errada e de evidência alterada.
Os detalhes que importam.
Um hash de transação é suficiente para confirmar o pagamento?+
Não. Verifique a transferência na cadeia pretendida, seu payload e sua confiança e, em seguida, estabeleça que ela pertence ao pedido e ainda não foi creditada.
Todas as redes podem usar o mesmo limite de confirmação?+
Não. As redes expõem modelos diferentes de confiança e finalidade. O operador deve definir e testar uma política de aceitação adequada a cada rota.
Pagamento confirmado significa que o servidor está provisionado?+
Não. A aceitação do pagamento e a entrega são eventos de fluxo de trabalho separados. Comunique o status de provisionamento a partir de seu próprio processo autoritativo.
Vá à fonte.
Estas referências apoiam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema em produção.
- Guia do desenvolvedor Bitcoin: Comportamento da blockchain developer.bitcoin.org
- Ethereum: Proof of stake e finalidade ethereum.org
- Solana: Compromisso de estado RPC solana.com
Orientação editorial da SwissOctet. Os exemplos são ilustrativos. Especificações de serviço, opções disponíveis e condições contratuais devem ser verificadas separadamente.