# Da transação detetada à encomenda reconciliada: confirmações e reorganizações | SwissOctet Insights https://swissoctet.com/pt/insights/confirmations-reorgs-order-reconciliation/ SwissOctet / Informações / Pagamentos em criptomoeda Pagamentos em criptomoeda Avançado · 4 min de leitura Da transação detetada à encomenda reconciliada: confirmações e reorganizações Conceba estados de pagamento em torno de evidência verificada na chain, regras de aceitação explícitas e associação inequívoca à encomenda, em vez de uma afirmação do navegador de que os fundos foram enviados. Por SwissOctet Editorial Guardar guia Copiar ligação NESTA PÁGINA 01 Separe o evento da chain do evento da encomenda 02 Utilize regras de confiança específicas de cada chain 03 Verifique o payload real da transferência 04 Torne a associação à encomenda inequívoca 05 Defina estados que tolerem evidência tardia e variável 06 Torne as repetições seguras e observáveis 07 Saiba o que uma encomenda pendente ainda precisa A sua lista de verificação prática Fontes e leitura adicional Voltar à biblioteca A RESPOSTA DIRETA A deteção de transações, a confirmação na cadeia, a associação a encomendas e a entrega do serviço são passos separados. Verifique a cadeia, o ativo, o destinatário e o montante corretos; aplique uma política de aceitação documentada; e torne a reconciliação idempotente. Uma referência de transação, uma captura de ecrã ou um botão do navegador, por si só, não conseguem estabelecer que uma encomenda específica foi paga. 01 Separe o evento da chain do evento da encomenda Uma carteira que comunica que uma transferência foi enviada é evidência sobre a sua própria ação, não uma decisão completa de pagamento. O backend recetor tem de observar a rede pretendida, verificar a transferência real e associá-la a uma encomenda. Só então a encomenda pode aplicar a sua política de aceitação. A entrega da infraestrutura é outro passo operacional após a aceitação do pagamento. Mantenha estas transições explícitas tanto no código como na linguagem dirigida ao cliente. Um ecrã pode mostrar à espera, detetado ou a confirmar sem declarar a encomenda paga. Não permita que o navegador forneça o montante aceite nem sobrescreva um estado autoritativo. Armazene o orçamento criado pelo servidor e as suas instruções para que a reconciliação posterior possa ser avaliada face à encomenda original e não a um carrinho em alteração. 02 Utilize regras de confiança específicas de cada chain Diferentes redes descrevem a confiança de uma transação de forma diferente. O guia para programadores da Bitcoin explica como os nós selecionam a cadeia com mais prova de trabalho acumulada e como podem ocorrer blocos concorrentes. Uma transação vista recentemente precisa, por isso, de uma política para a profundidade de confirmação e possíveis alterações de cadeia. Não existe um número único de confirmações adequado a todos os ativos e riscos comerciais. A documentação de prova de participação da Ethereum explica a finalidade por checkpoint, enquanto a Solana documenta os estados de compromisso processado, confirmado e finalizado. Não traduza esses termos de forma leviana para uma contagem universal de blocos. Registe a regra específica da rede, a fonte de informação e o comportamento durante a incerteza. O operador deve determinar os limiares de aceitação em função do risco de pagamento e de entrega, e não copiar um número de um checkout não relacionado. 03 Verifique o payload real da transferência Identifique o destinatário, o ativo e o montante na cadeia correta. Os pagamentos de tokens exigem a identidade pretendida do token, e não apenas 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. Analise montantes inteiros com a precisão adequada do ativo em vez de confiar num decimal formatado fornecido pelo navegador. Uma instrução de pagamento tem de permanecer vinculada à sua rota original. Uma transferência noutra rede, um token diferente com o mesmo símbolo ou uma referência de transação não relacionada não a devem satisfazer. O registo de verificação deve explicar o que foi verificado e preservar a evidência necessária para rever a decisão. Este guia descreve princípios gerais de reconciliação de pagamentos e não a implementação de um serviço em particular. 04 Torne a associação à encomenda inequívoca Endereços de receção fixos podem receber várias encomendas com montantes semelhantes. A existência de uma transferência correspondente não prova qual o cliente ou a encomenda que deve ser creditada. 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 utilizador continua a exigir validação de que a mesma transferência ainda não foi atribuída noutro local. Imagine duas faturas com o mesmo montante na mesma rota durante uma janela sobreposta. Um observador vê uma transferência. Marcar automaticamente ambas como pagas está 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 consiga estabelecer uma associação válida. Uma correspondência ambígua é um estado a tratar, não um motivo para fabricar certeza. 05 Defina estados que tolerem evidência tardia e variável Um processo de pagamento beneficia de um pequeno conjunto de estados claros, com a evidência da cadeia separada da decisão de aceitar uma encomenda. Esta tabela ilustrativa explica possíveis fases em vez de descrever os nomes de estado de um serviço em particular. 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 do orçamento e dados de cadeia temporariamente indisponíveis. A expiração não faz desaparecer uma transferência real. 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 segundo a política documentada em vez de tratar cada notificação do observador como verdade irreversível. Estado ilustrativo Significado Próxima decisão A aguardar Nenhuma transferência qualificável verificada Continuar a observar a fatura válida Detetado Transferência relevante observada Verificar a confiança da cadeia e a associação A confirmar Regra de aceitação ainda não cumprida Observar até a política permitir uma decisão Revisão Evidência tardia, parcial ou ambígua Resolver segundo a política do operador Aceite Pagamento verificado e reconciliado Prosseguir para o fluxo de entrega separado 06 Torne as repetições seguras e observáveis Os observadores e as tarefas de reconciliação voltarão a tentar após ligações interrompidas ou reinícios de processos. Use uma identidade de transferência estável, como a cadeia e o identificador adequado 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 nem alterar um orçamento aceite. Distinga um resultado desconhecido de uma operação falhada. Se um pedido a jusante expirar, inspecione o seu resultado autoritativo antes de reenviar. Mantenha registos duradouros das ações aceites e incertas. Restrinja o acesso a tokens de encomenda e evidência interna, mantendo informação suficiente para investigar um pagamento contestado. A fiabilidade aqui diz respeito a decisões repetíveis, não a uma animação fluida no checkout. 07 Saiba o que uma encomenda pendente ainda precisa Uma encomenda pode permanecer pendente porque a transferência não foi observada, porque a confiança de cadeia exigida não foi alcançada ou porque a sua associação à fatura precisa de revisão. Preserve a fatura e a referência pública da transação, verifique as regras de aceitação indicadas e utilize o processo de assistência previsto para a encomenda. Uma atualização de estado atrasada não é, por si só, motivo para enviar outro pagamento. Siga as instruções e o estado verificado da encomenda real. A confirmação de pagamento deve identificar a aceitação da transferência reconciliada, enquanto a entrega do serviço tem um estado separado. Mantenha os tokens de acesso privados e os segredos da carteira fora dos pedidos de ajuda. TRANSFORME ISTO EM AÇÃO A sua lista de verificação prática. ✓ Persistir um orçamento imutável criado pelo servidor. ✓ Verificar a cadeia, o destinatário, o ativo e o montante inteiro. ✓ Documentar regras de aceitação específicas da cadeia. ✓ Tratar colisões de endereços fixos sem adivinhar. ✓ Evitar créditos duplicados e reenvios de tentativas inseguros. ✓ Testar casos tardios, parciais, de rota errada e de evidência alterada. Descarregar lista de verificação PERGUNTAS FREQUENTES Os detalhes que importam. Um hash de transação é suficiente para confirmar o pagamento? + Não. Verifique a transferência na cadeia pretendida, o seu payload e a sua confiança, e depois estabeleça que pertence à encomenda e que ainda não foi creditada. Todas as redes podem usar o mesmo limiar de confirmação? + Não. As redes expõem modelos de confiança e finalidade diferentes. O operador tem de definir e testar uma política de aceitação adequada a cada rota. Um 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 estado de provisionamento a partir do seu próprio processo autoritativo. REFERÊNCIAS PRIMÁRIAS Vá à fonte. Estas referências sustentam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema de produção. Guia para programadores da Bitcoin: Comportamento da blockchain developer.bitcoin.org Ethereum: Prova de participação e finalidade ethereum.org Solana: Compromisso de estado RPC solana.com Orientação editorial da SwissOctet. Os exemplos são ilustrativos. As especificações de serviço, as opções disponíveis e as condições contratuais devem ser verificadas separadamente. LIGUE O CONHECIMENTO Infraestrutura relacionada. Vector VPS Suíça Metal Hyper Suíça Veil Onion Suíça MANTENHA O FIO As suas próximas notas de campo. Explore todos os guias NOTA DE CAMPO / 01 + Cloud e VPS Fundação Como escolher um VPS sem adivinhar Transforme uma ideia de aplicação num orçamento de recursos útil e compare depois CPU, memória, armazenamento e transferência em conjunto. 4 min de leitura Leia o guia NOTA DE CAMPO / 02 + Pagamentos em criptomoeda Fundação Checkout em criptomoeda e os limites da privacidade de pagamento Compreenda o percurso do ativo, da rede e da confirmação e proteja a informação que liga o seu projeto a um pagamento. 4 min de leitura Leia o guia NOTA DE CAMPO / 03 + Pagamentos em criptomoeda Fundação Escolha o ativo e a rede antes de preparar um pagamento em criptomoeda Leia uma rota de pagamento como um par completo de ativo e rede e, em seguida, verifique as instruções da fatura, a identidade do token e o montante entregue antes de autorizar uma transferência. 4 min de leitura Leia o guia