Bitcoin Point of Sale is a bitcoin checkout for in-person sales. It helps price a purchase, request payment and establish that it arrived. It may be an app on a phone or tablet, or a separate terminal. The device alone does not tell you whether the merchant controls the money or a provider holds it for them.
The cashier selects a coffee or enters its price, then checks the currency, tip and final total. BTCPay Server, for example, offers a catalogue, cart or simple keypad. It creates an invoice: a payment request linked to a particular purchase. That connection makes it possible to identify what an incoming payment was for. Reloading the screen must not add another coffee to the sales records. The order and its payment record should remain traceable. [1] [2]
A café may price coffee in Czech crowns while the checkout converts that price to bitcoin using its chosen rate source. Before sending, the customer should see the amount and request validity, and check the recipient and payment network. BOLT 11 is a Lightning request format. It contains a payment hash, a cryptographic fingerprint involved in proving payment, and an expiry; the amount can be left unspecified. Scanning the code is therefore not enough: check the actual requested amount for the purchase. Displaying a price in crowns does not by itself mean the café receives crowns in a bank account. [3] [4]
A QR code conveys payment details, not proof of receipt. A screenshot from the customer is no substitute for verification by the café. BTCPay Server uses Processing for a fully paid request whose settlement conditions, such as required block confirmations, remain outstanding. Settled indicates those conditions were met. Manual marking is also possible, but does not create an actual payment or confirmation. A successful Lightning payment normally does not wait for a block. Release goods according to verified receipt and store policy, not the colour of somebody else’s screen. [2]
A checkout may receive into the merchant’s own wallet or use a service that holds funds for them. Private spending keys, permissions and withdrawal conditions matter, not the Bitcoin logo. Public wallet information may be enough to generate receiving addresses. Even then, a compromised checkout can show customers an attacker’s address for future payments. Cashiers need not have the same rights as administrators: selling coffee is a different task from changing the recipient or approving a refund. [5] [6] [7]
Lightning routes payments through connected payment channels. Your own node, the software participating in that network, must be available and have inbound liquidity: room in the channels to receive funds. A service can handle some of this work, but changes both the costs and whom you trust. A missing route or insufficient liquidity is not a successful payment. Before the customer tries another method, check the outcome of the original attempt so they do not pay twice for one coffee. [7] [4]
The tablet may lose internet access, the server may stop responding, or the exchange rate may fail to load. The checkout might then be unable to create a request or verify receipt. A printed QR code remains readable, but that does not prove the system is working. Staff need an agreed procedure, such as backup connectivity, postponing the sale and tracing the payment later. An outage alone does not mean the customer has not paid. Assess partial, excess and expired-request payments individually; a manual record change does not rewrite network history. [2] [3]
Returning money means making another payment linked to the original purchase. Agree the amount and currency, verify the destination and obtain authorised approval. BTCPay Server, for example, separates creating a refund request from actually sending the payout. Giving the customer a link does not mean the money has reached them. Staff distinguish a prepared request, a pending payout and a completed refund; the original transfer remains in the history. [8]
At the end of a shift, reconcile orders, receipts, fees, refunds and any provider payouts. BTCPay Server can export payments, products sold and on-chain wallet movements, meaning transfers involving the Bitcoin chain directly. Reports help with records but do not fulfil every local accounting or tax obligation. Before going live, rehearse a normal sale, an outage and recovery. Restrict access to customer data as needed, and include equipment, connectivity and maintenance in the costs. [9] [1] [6]
A coffee, a paid phone and an offline tablet
For the illustrative order POS-497, the customer shows a successful payment just as the cashier’s tablet disconnects. The cashier neither immediately issues a second request nor marks the purchase unpaid. They reconnect, find the original invoice and compare the amount with actual receipt. Depending on the result, they complete the sale or handle another attempt. Everything stays linked to the same order so neither payment nor sale is counted twice.
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 on the counter enough?+
A code can convey payment details, but cannot itself tell whether money arrived or which purchase it belongs to. Staff need trustworthy receipt verification and a procedure for an incorrect amount, an expired request or lost connectivity.
02Does Lightning mean the café holds its own money?+
Not automatically. It may run its own node or use a service with different permissions, including a custodial provider. Check who controls the keys and balance, who handles receiving and under what conditions the café can withdraw.