Bitcoin Point of Sale é uma interface de caixa para vendas presenciais: calcula o preço da compra, cria uma solicitação de pagamento, associa o pagamento recebido e mantém um registro. Pode funcionar em celular, tablet ou terminal; a aparência do aparelho não determina quem controla as moedas.
O atendente seleciona produtos ou digita um valor, verifica a moeda, a gorjeta e o total final. BTCPay Server oferece catálogo, carrinho e teclado numérico. Cada compra deve ser rastreável por pedido e fatura; reabrir a tela não deve criar um segundo registro de venda. [BTCPay Server — Point of Sale app] [BTCPay Server — Invoice lifecycle]
O preço em moeda local é convertido pela fonte de câmbio configurada; o caixa deve mostrar o valor esperado em bitcoin e a validade da oferta. BOLT 11 contém dados da fatura Lightning, incluindo hash de pagamento e expiração; o valor pode ser opcional. Para uma compra específica, é preciso verificar valor real, rede e destinatário. Calcular o preço não significa vender bitcoin por moeda fiduciária. [BTCPay Server — Store rates and policies] [Lightning BOLTs — Invoice protocol]
O código QR apenas transmite dados de pagamento. Uma captura da tela do cliente não substitui o estado no sistema do comerciante. Em BTCPay Server, Processing aguarda as confirmações on-chain escolhidas; Settled significa que a política foi cumprida, mas também pode ser definido manualmente. Um pagamento Lightning bem-sucedido não espera confirmação de bloco. A entrega depende, portanto, de pagamento verificado, não apenas da cor da tela. [BTCPay Server — Invoice lifecycle]
O mesmo tablet pode direcionar recebimentos para uma carteira própria ou usar um provedor custodial. O que importa são chaves, permissões e condições de repasse, não o logotipo Bitcoin. Mesmo receber por chave pública não exclui a substituição de um endereço futuro por um caixa ou servidor comprometido. Separe permissões de atendimento das de alterar o destinatário, administrar a carteira e aprovar reembolsos. [BTCPay Server — Wallet setup] [BTCPay Server — Third-party hosting risks] [BTCPay Server — Lightning setup]
Um nó Lightning próprio exige operação, canais e liquidez de entrada. Um provedor pode assumir parte do trabalho, mas altera custos e confiança. Falha de roteamento ou falta de liquidez não é pagamento bem-sucedido. Antes de trocar de método, o atendente verifica o resultado da tentativa original para evitar dois pagamentos pela mesma compra. [BTCPay Server — Lightning setup] [Lightning BOLTs — Invoice protocol]
Internet, backend ou fonte de câmbio indisponíveis podem impedir uma nova solicitação ou a verificação do recebimento. Um código exibido ou impresso pode continuar legível sem um estado atualizado. O procedimento deve definir conexão de reserva, adiamento da venda e localização posterior do pagamento. Avalie separadamente pagamentos insuficientes, excessivos ou após a expiração; uma alteração manual de estado não muda o histórico da rede. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies]
Devolver fundos exige vínculo com a compra original, valor e moeda acordados, destino verificado e aprovação autorizada. BTCPay Server separa a criação da solicitação de reembolso do envio do pagamento de saída. A transferência original não é apagada. O atendente deve distinguir solicitação criada, pagamento de saída pendente e devolução efetivamente concluída. [BTCPay Server — Refund workflow]
No fim do turno, concilie pedidos, pagamentos recebidos, taxas, reembolsos e possíveis repasses do provedor. BTCPay Server exporta relatórios de pagamentos, produtos vendidos e carteira on-chain; a exportação sozinha não garante cumprir exigências contábeis e fiscais locais. Teste os procedimentos da equipe, falhas e recuperação, limite o acesso a dados de clientes e considere custos de aparelho, conexão e operação. [BTCPay Server — Reporting] [BTCPay Server — Point of Sale app] [BTCPay Server — Third-party hosting risks]
Duas telas, uma compra
No pedido hipotético POS-497, o cliente mostra um pagamento bem-sucedido, mas o tablet do atendente perde a conexão. O atendente não marca automaticamente a compra como não paga nem emite imediatamente outra solicitação. Restabelece a conexão, encontra a fatura original e verifica seu valor e o estado real do recebimento. Só então decide entregar os produtos ou tentar novamente e registra o resultado no mesmo pedido.
Para ter uma visão mais completa, leia este verbete junto com Merchant Adoption, BTCPay Server, Bitcoin Payment Processor, BOLT 11, Confirmação, Bitcoin. Também há referências a este verbete em Merchant Adoption, Bitcoin Payment Processor, BTCPay Server, BTC Map.
01Um código QR basta no caixa?+
O código transmite dados de pagamento, mas não verifica sozinho o recebimento nem associa o pagamento à compra. O caixa precisa de um estado confiável e de um procedimento para valor incorreto, expiração e falta de conexão.
02Um pagamento Lightning sempre significa autocustódia do comerciante?+
Não. O caixa pode usar um nó próprio, outro modelo de serviço ou um provedor custodial. Verifique quem controla as chaves e o saldo, quem garante o recebimento e sob quais condições os fundos podem ser retirados.