Bitcoin Point of Sale

O atendente escolhe o café ou digita o preço e confere moeda, gorjeta e total. O BTCPay Server oferece, por exemplo, catálogo, carrinho ou teclado numérico. Em seguida cria uma invoice: uma solicitação de pagamento ligada à compra. Essa ligação permite descobrir a que se refere cada recebimento. Recarregar a tela não deve registrar outro café vendido. Pedido e registro do pagamento precisam continuar identificáveis. [1] [2]

A cafeteria pode definir preços em coroas tchecas e convertê-los em bitcoin usando a fonte de cotação escolhida. Antes de enviar, o cliente deve ver o valor e a validade, além de conferir destinatário e rede. BOLT 11 é um formato de solicitação Lightning. Contém um hash de pagamento, uma impressão digital criptográfica ligada à comprovação do pagamento, e um prazo; o valor pode ficar sem especificar. Portanto, escanear não basta: confira o montante realmente pedido nessa compra. Mostrar coroas não significa que a cafeteria receberá coroas na conta bancária. [3] [4]

Um QR transmite dados de pagamento, não prova de recebimento. Uma captura do cliente não substitui a verificação da cafeteria. No BTCPay Server, Processing indica o valor integral pago, mas com condições de conclusão pendentes, como confirmações em blocos. Settled indica condições cumpridas. Também existe marcação manual, que não cria pagamento nem confirmação reais. Um pagamento Lightning bem-sucedido normalmente não espera um bloco. Entregue o produto conforme o recebimento verificado e as regras da loja, não pela cor da tela de outra pessoa. [2]

O caixa pode receber na carteira do comerciante ou usar um serviço que guarda fundos por ele. Importam as chaves privadas de gasto, permissões e condições de saque, não o logotipo Bitcoin. Dados públicos da carteira podem bastar para gerar endereços de recebimento. Mesmo assim, um caixa comprometido pode mostrar o endereço de um invasor para pagamentos futuros. O atendente não precisa dos mesmos direitos do administrador: vender café é diferente de mudar o destinatário ou aprovar um reembolso. [5] [6] [7]

Lightning encaminha pagamentos por canais conectados. Um nó próprio, o programa que participa da rede, precisa estar disponível e ter liquidez de entrada: espaço nos canais para receber fundos. Um serviço pode assumir parte do trabalho, mas altera custos e relações de confiança. Falta de rota ou liquidez não é pagamento concluído. Antes de tentar outro método, o atendente confere o resultado anterior para não cobrar o mesmo café duas vezes. [7] [4]

O tablet pode perder internet, o servidor parar ou a cotação não carregar. Talvez não seja possível criar uma solicitação ou verificar o recebimento. Um QR impresso continua legível, mas isso não prova que o sistema funciona. É preciso combinar uma rotina: conexão alternativa, venda adiada ou consulta posterior do pagamento. A interrupção sozinha não prova falta de pagamento. Avalie valores insuficientes, excedentes e pagamentos após o prazo individualmente; alterar um registro à mão não reescreve o histórico da rede. [2] [3]

Devolver dinheiro significa fazer outro pagamento ligado à compra original. Combine valor e moeda, verifique o destino e obtenha a aprovação de quem tem autoridade. O BTCPay Server separa a criação do pedido de reembolso do envio efetivo. Entregar um link ao cliente não significa que ele já recebeu o dinheiro. A equipe distingue pedido preparado, pagamento de saída pendente e reembolso concluído; a transferência original continua no histórico. [8]

Ao fim do turno, concilie pedidos, recebimentos, taxas, reembolsos e eventuais repasses do provedor. O BTCPay Server exporta pagamentos, produtos vendidos e movimentos da carteira on-chain, que opera diretamente na cadeia Bitcoin. Os relatórios ajudam nos registros, mas não cumprem sozinhos todas as obrigações contábeis e tributárias locais. Antes de começar, ensaie uma venda normal, uma interrupção e a recuperação. Limite o acesso aos dados dos clientes e inclua equipamento, conexão e manutenção nos custos. [9] [1] [6]