Bitcoin Payment Processor cria solicitações de pagamento, associa pagamentos recebidos aos pedidos e ajuda a manter registros. Pode ser autogerido ou oferecido como serviço. Não é uma regra do consenso do Bitcoin, e o nome processador não informa quem controla os fundos.
A loja cria um pedido e seu servidor solicita ao processador uma fatura com valor e moeda. Guarda o vínculo entre o número interno do pedido e o identificador da fatura. O cliente recebe uma página de pagamento ou código QR, e o processador acompanha o recebimento. Sem esse vínculo, não é possível determinar com segurança qual pedido o pagamento atende; o simples retorno no navegador não comprova pagamento. [BTCPay Server — eCommerce integration]
BTCPay Server pode derivar endereços de recebimento dos dados públicos de uma carteira existente sem sua chave privada. Isso difere de uma carteira quente armazenada no servidor e do acesso aos fundos de um nó Lightning. Um provedor pode reter os fundos até o repasse. Avalie a posse efetiva das chaves, permissões e capacidade de saque, não apenas o nome do produto ou a palavra non-custodial. [BTCPay Server — General FAQ] [BitPay — Configuring settlements]
Uma fatura comum do BTCPay Server fixa a taxa de câmbio por tempo limitado. O vencimento não impede que uma transferência posterior chegue. Pagamentos insuficientes, excessivos e atrasados têm estados distintos e exigem procedimentos subsequentes. Guarde o valor original e a taxa aplicada; se o preço mudar, uma nova solicitação pode exigir outra quantidade de satoshis. [BTCPay Server — Invoice lifecycle]
BTCPay Server diferencia Processing, que aguarda as confirmações configuradas, de Settled; pagamentos Lightning bem-sucedidos passam a Settled sem esperar um bloco. Os nomes de estado de outros provedores não são automaticamente equivalentes: BitPay alerta expressamente que paid não garante pagamento. A loja precisa de uma regra de entrega para o estado e o método de pagamento específicos. Alterar manualmente um estado não cria uma confirmação da rede. [BTCPay Server — Invoice lifecycle] [BitPay — Invoice webhooks]
BTCPay verifica o webhook usando HMAC-SHA256 sobre os bytes originais do corpo e um segredo compartilhado. BitPay descreve IPN sem assinatura: a notificação motiva uma consulta ao estado da fatura via API, não sendo por si só uma prova confiável. Notificações podem chegar repetidas vezes. A integração deve reconhecer com segurança um evento reenviado e impedir um segundo despacho do mesmo pedido; após uma interrupção, é necessário reconciliar os estados salvos com o processador. [BTCPay Server — Webhook validation example] [BitPay — Invoice webhooks]
A confirmação do pagamento do cliente pode não coincidir com o repasse do provedor. BitPay permite configurar a moeda de liquidação e uma conta bancária ou endereço de criptomoeda; uma mudança pode exigir aprovação. Confira moedas disponíveis, limites, prazos, taxas e controle dos fundos até o repasse. Receber diretamente em sua própria carteira não utiliza automaticamente esse modelo de repasse pelo provedor. [BitPay — Configuring settlements] [BTCPay Server — General FAQ]
Um reembolso exige outro pagamento e a verificação do destinatário; não altera a transação original de bitcoin. Separe a reclamação do pedido, a decisão sobre o valor reembolsado e o envio efetivo do dinheiro. Preserve os vínculos pedido–fatura–pagamento, taxas de câmbio, tarifas e reembolsos. Exportar um relatório ajuda no registro, mas não resolve sozinho todas as obrigações contábeis locais nem uma disputa sobre a entrega. Mesmo uma transferência confirmada não resolve sozinha o caráter juridicamente definitivo da operação: confira reclamações, possíveis mecanismos de chargeback e obrigações conforme a via de pagamento, o contrato e a jurisdição. [BTCPay Server — Refunds] [BTCPay Server — Reporting] [BitPay — Merchant and shopper terms]
Teste pagamentos bem-sucedidos, incompletos, atrasados e notificados repetidamente, além da recuperação após uma interrupção. Conceda à chave API apenas as permissões necessárias e restrinja-a à loja correspondente. Não transmita dados desnecessários do cliente nos metadados. Considere hospedagem, atualizações, liquidez e suporte; software gratuito não significa custos operacionais nulos. Disponibilidade do serviço, posse das chaves e correção da integração são condições distintas. [BTCPay Server — eCommerce integration] [BTCPay Server — Lightning operations]
A mesma notificação não é outra compra
Em uma integração hipotética, o pedido OBJ-101 tem o identificador da fatura salvo. Após verificar sua liquidação, o sistema cria um despacho uma única vez. Quando chega uma notificação repetida do mesmo evento, ele a associa ao pedido já atendido e não cria outro despacho. A simples exibição de uma página de agradecimento não deve provocar essa transição.
Para ter uma visão mais completa, leia este verbete junto com BTCPay Server, Bitcoin Point of Sale, Merchant Adoption, Lightning Network, Bitcoin. Também há referências a este verbete em Alza Bitcoin payments, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.
01Todo processador de pagamentos guarda meus bitcoins?+
Não. Algumas soluções apenas criam solicitações e acompanham o recebimento em sua carteira; outras administram fundos até o repasse. Até o mesmo software pode usar modelos diferentes de carteira. O que importa são as chaves, as permissões e o fluxo real dos fundos, não apenas o nome processador.
02A loja pode despachar depois que o cliente volta da página de pagamento?+
O retorno sozinho não basta. A loja deve verificar a fatura correspondente e seu estado conforme o procedimento do processador. As notificações são verificadas de acordo com a documentação, e a repetição não pode iniciar outra entrega. A liberação dos produtos segue as condições escolhidas de confirmação do pagamento.