Bitcoin Point of Sale is a checkout interface for in-person sales: it prices a purchase, creates a payment request, matches the received payment and keeps a record. It can run on a phone, tablet or terminal; the device's appearance does not determine who controls the coins.
The cashier selects products or enters an amount, checks the currency, tip and final total. BTCPay Server offers a catalogue, cart and numeric keypad. Each purchase should be traceable through an order and invoice; reopening the screen must not create a second sales record. [BTCPay Server — Point of Sale app] [BTCPay Server — Invoice lifecycle]
A local-currency price is converted using the configured rate source; the checkout must show the expected Bitcoin amount and the offer's validity. BOLT 11 carries Lightning invoice data including a payment hash and expiry; the amount can be optional. For a specific purchase, verify the actual amount, network and recipient. Converting the price does not mean selling bitcoin for fiat. [BTCPay Server — Store rates and policies] [Lightning BOLTs — Invoice protocol]
A QR code only conveys payment details. A screenshot from the customer is no substitute for the merchant's system status. In BTCPay Server, Processing waits for the chosen on-chain confirmations; Settled means the policy has been met, but can also be set manually. A successful Lightning payment does not wait for a block confirmation. Releasing goods therefore depends on a verified payment, not just the colour of a screen. [BTCPay Server — Invoice lifecycle]
The same tablet can direct receipts to a merchant's own wallet or use a custodial provider. Keys, permissions and payout terms matter, not the Bitcoin logo. Even receiving through a public key does not rule out a compromised checkout or server substituting a future address. Separate cashier permissions from changing the recipient, managing the wallet and approving refunds. [BTCPay Server — Wallet setup] [BTCPay Server — Third-party hosting risks] [BTCPay Server — Lightning setup]
Running your own Lightning node requires operations, channels and inbound liquidity. A provider can take over part of the work but changes costs and trust. A routing failure or insufficient liquidity is not a successful payment. Before switching payment methods, the cashier checks the original attempt's outcome to avoid two payments for one purchase. [BTCPay Server — Lightning setup] [Lightning BOLTs — Invoice protocol]
Unavailable internet, backend or rate source can prevent a new request or verification of receipt. A displayed or printed code may remain readable without an up-to-date status. The operating procedure should define backup connectivity, postponing a sale and tracing a payment later. Assess underpayments, overpayments and payments after expiry individually; a manual status change does not change network history. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies]
Returning funds requires a link to the original purchase, an agreed amount and currency, a verified destination and authorised approval. BTCPay Server separates creating a refund request from sending the payout. The original transfer is not erased. Staff must distinguish a created request, a pending payout and an actually completed refund. [BTCPay Server — Refund workflow]
At the end of a shift, reconcile orders, received payments, fees, refunds and any provider payouts. BTCPay Server exports payment, product-sales and on-chain wallet reports; an export alone does not guarantee compliance with local accounting and tax requirements. Test staff procedures, outages and recovery, restrict access to customer data and account for device, connectivity and operating costs. [BTCPay Server — Reporting] [BTCPay Server — Point of Sale app] [BTCPay Server — Third-party hosting risks]
Two screens, one purchase
For the hypothetical order POS-497, the customer shows a successful payment, but the cashier's tablet loses its connection. The cashier does not automatically mark the purchase unpaid and immediately issue a second request. They restore connectivity, find the original invoice and verify its amount and actual receipt status. Only then do they decide whether to release the goods or try again, recording the outcome against the same order.
For the clearest picture, read this entry together with Merchant Adoption, BTCPay Server, Bitcoin Payment Processor, BOLT 11, Confirmation, Bitcoin. The reverse links also lead from Merchant Adoption, Bitcoin Payment Processor, BTCPay Server, BTC Map.
01Is a QR code enough at the checkout?+
The code conveys payment details but does not itself verify receipt or match a payment to a purchase. The checkout needs a trustworthy payment status and a procedure for incorrect amounts, expiry and lost connectivity.
02Does a Lightning payment always mean the merchant has self-custody?+
No. The checkout can use its own node, a different service model or a custodial provider. Check who controls the keys and balance, who handles receipt and under what conditions the funds can be withdrawn.