Como lidar com faturas cripto pagas a menos ou a mais

Uma fatura paga a menos não deve gerar entrega automática; uma paga a mais não deve gerar reembolso automático. Primeiro confirme rede, contrato genuíno, destinatário, status e valor. Depois aplique uma política escrita que registre a diferença e resulte em uma resolução inequívoca.

No GramPayBot, o valor esperado é exato. Uma transferência menor é classificada como parcial; uma maior, como overpaid. Nenhuma se torna silenciosamente uma fatura normalmente paga.

Tabela de decisão

Resultado verificado	Decisão	Próxima etapa
Valor exatamente igual	Pode corresponder após confirmação	Entregar quando paid
Valor menor	Pagamento parcial	Registrar a diferença e orientar o comprador
Valor maior	Pagamento excedente	Decidir entre aceitar, creditar ou devolver
Várias transferências relacionadas	Caso ambíguo	Verificar cada hash manualmente
Rede, token ou destinatário incorreto	Não é pagamento desta fatura	Seguir o fluxo de rota errada

Se a rede estiver errada, siga o guia de investigação e recuperação de rede incorreta. Se a diferença envolver uma fatura vencida ou substituta, use o fluxo para faturas não pagas, tardias e vencidas antes de solicitar outro pagamento.

O BTCPay Server também separa estados parcialmente pagos e overpaid de uma fatura liquidada normalmente. A documentação da Stripe acompanha saldo restante e excesso separadamente. Isso não define sua política, mas mostra por que exceções de valor precisam de estado próprio.

Por que ocorre pagamento a menos

• arredondamento em vez de copiar o valor completo;
• interpretação incorreta de taxa da carteira ou exchange;
• envio de teste presumindo soma automática;
• uso de instrução antiga ou fatura vencida;
• erro de decimais na integração;
• mais de uma pessoa tentando pagar o pedido;
• retenção deliberada por disputa comercial.

O comportamento das taxas varia e pode mudar. A Binance, por exemplo, informa que as taxas de saque são dinâmicas e aparecem na tela de retirada. Portanto, não existe a regra universal “a rede sempre desconta do valor recebido”. O comprador precisa conferir no resumo final quanto chegará ao destinatário.

Por que ocorre pagamento a mais

As causas incluem copiar o preço fiat como quantidade de token, somar a taxa ao valor do destinatário quando ela é cobrada à parte, pagar duas vezes, enviar o valor inteiro após um teste ou errar unidades e casas decimais.

Embora a interface mostre decimais, a blockchain representa transferências em unidades inteiras mínimas. O exemplo oficial da Circle mostra USDC com seis casas decimais. A integração deve converter unidades de forma determinística, não comparar aproximações de ponto flutuante.

Verifique a transferência antes de resolver

1. Abra o hash no explorer da rede da fatura.
2. Confirme sucesso e nível de confirmação.
3. Verifique contrato ou mint, não só o símbolo.
4. Compare o endereço completo do destinatário.
5. Leia o valor no evento de transferência ou balance change.
6. Compare com todos os dígitos do checkout.
7. Veja se outra transação já está atribuída ao pedido.
8. Compare horário do bloco e vencimento.

Se o contrato estiver errado, o ativo está errado; não é somente diferença de valor. Use o guia de verificação de contratos USDT e USDC.

Depois da verificação, associe cada hash aceito a exatamente uma fatura e um pedido. O guia de correspondência entre pagamentos e pedidos explica como preservar essa relação sem depender de capturas ou username de chat.

Correspondência exata no GramPayBot

Rede, token, destinatário e valor são definidos antes do pagamento. O valor atual do checkout usa no máximo quatro casas decimais e pode incluir um sufixo identificador. Se ele mostra 180.0134 USDT, envie o número inteiro, não 180 USDT arredondados. USDT ou USDC pode usar seis casas de unidade-base on-chain; isso não significa que o GramPayBot mostre um sufixo de invoice com seis casas.

Uma transferência confirmada exata pode pagar; uma menor é partial; uma maior é overpaid; várias candidatas ou uma transferência reutilizada não formam correspondência limpa. O matcher normal não soma uma segunda transferência aleatória como “complemento”. Oriente o comprador a não enviar novamente até receber uma solução explícita.

Fluxo para pagamento a menos

1. Calcule a diferença verificada

Calcule em unidades do token:

diferença = valor exato da fatura − valor recebido verificado

2. Mantenha a entrega suspensa

Não marque o pedido como pago apenas porque a maior parte chegou. Isso evita decisões inconsistentes entre clientes.

3. Escolha uma resolução escrita

Escolha uma opção:

• aceitar manualmente a diferença como desconto ou perda;
• criar nova fatura separada para o saldo;
• cancelar a entrega e reembolsar o valor verificado;
• encaminhar para suporte ou compliance.

Se cobrar o saldo, vincule a nova fatura ao pagamento original nos registros. Não prometa que a fatura antiga somará automaticamente as duas transações.

4. Confirme o resultado ao comprador

Informe valor recebido, diferença, decisão e referência da nova fatura ou do reembolso.

Fluxo para pagamento a mais

1. Descarte duplicidade ou transferência alheia

Primeiro descarte duplicidade e transação de outro pedido.

2. Separe o valor da fatura do excesso

Registre:

excesso = valor recebido verificado − valor exato da fatura

Não altere a fatura retroativamente para fazer os números coincidirem.

3. Aplique uma política

Conforme os termos, devolva o excesso, transforme-o em crédito acordado, aceite como gorjeta/compra adicional ou devolva tudo e emita outra fatura.

A documentação de pagamentos parciais da Stripe é um exemplo tradicional de por que saldos e excessos precisam de regras explícitas.

4. Confirme separadamente o endereço de reembolso

Não reembolse automaticamente o remetente on-chain. Uma exchange pode ter enviado de carteira compartilhada. Autentique o cliente no pedido original, confirme um endereço de reembolso na mesma rede, explique taxas e registre o novo hash. Reembolso é nova transferência, não reversão.

Política a definir antecipadamente

• existência e cálculo de tolerância para diferença;
• permissão para faturas de saldo;
• mínimo econômico para reembolso após taxas;
• suporte a crédito do cliente;
• responsáveis por aprovação manual e reembolso;
• tratamento de duplicidades;
• retenção dos registros de exceção.

Se houver tolerância, aplique-a de modo consistente e não a esconda dentro da correspondência exata quando a integração não oferecer essa regra.

Instruções preventivas ao comprador

Abra a fatura atual, escolha token e rede exatos, copie todas as casas decimais, confira se a exchange reduz o valor do destinatário, envie uma vez e guarde o hash. Se já enviou teste ou a fatura venceu, pare e fale com o lojista.

Veja o fluxo completo em como pagar uma fatura com USDT ou USDC.

Modelo de registro da exceção

Para cada pagamento insuficiente ou excessivo, guarde:

• IDs da fatura e do pedido;
• rede, token, destinatário e valor exato esperados;
• todos os hashes relacionados;
• valor verificado e estado de confirmação de cada hash;
• diferença ou excesso em unidades do token;
• vencimento da fatura e horários de bloco;
• método de autenticação do cliente;
• resolução, aprovador e horários;
• referência da fatura de saldo, crédito ou reembolso.

Esse registro evita contar a mesma transferência duas vezes e permite que outra pessoa reproduza a decisão.

Perguntas frequentes

Um segundo pagamento completa automaticamente a fatura parcial?

Não presuma isso. O matcher normal espera uma transferência exata e não soma pagamentos parciais arbitrários. Aguarde nova fatura de saldo ou instrução clara.

Posso arredondar o valor do checkout?

Não. Envie todos os dígitos; o sufixo pode identificar a fatura.

Fatura paga a mais fica automaticamente paid?

Não. É uma exceção para análise manual.

Devo devolver ao endereço remetente?

Não automaticamente. Confirme cliente e endereço de reembolso, sobretudo quando a origem for uma exchange.

Uma transferência USDT real prova que o pedido foi pago?

Não por si só. Rede, contrato do token, destinatário, valor, janela de pagamento e identidade da transação precisam coincidir com a fatura, e a transferência deve estar confirmada.