Merchant Adoption means shops and service providers introduce bitcoin payments that customers can actually use. It covers physical businesses and online stores. Accepting bitcoin is not the same as holding it long term: a merchant can receive funds directly or use a service that pays out another currency under agreed terms.
Imagine a shop listed as accepting Bitcoin, but today’s staff do not know how to start a payment. The listing is little help to the customer. Verification needs a specific location, supported payment method and check date. BTC Map therefore relies on local contributors and repeated checks of existing places. A successful test purchase shows the process works at that moment. It does not yet tell us how many people use it regularly; that requires actual purchases observed over a defined period. [1]
A merchant can receive bitcoin in a wallet whose keys it controls. Those keys authorize spending, so their backup needs protection too. Alternatively, a provider can process the payment and offer settlement in a supported local currency. BitPay documents such arrangements. The customer pays bitcoin, but the merchant need not remain exposed to its exchange rate. Check who controls the funds before payout, when they are released, and what conditions and limits apply. Choosing a payment method and choosing custody are separate decisions. [2] [3]
The checkout connects a purchase to an amount and payment method. BTCPay Server calls this an invoice: a payment request fixing the amount and exchange rate for a limited time. Customers can see what to send for their order. An expired request, underpayment or overpayment needs separate handling. Before sending, verify the amount, recipient and correct network. A QR code merely transfers details into the wallet; it does not guarantee their accuracy or link the payment to the right order by itself. [4]
A customer shows a screen saying a payment was sent. Staff still check their own system. In BTCPay Server, Processing means the requested amount was paid but settlement conditions remain outstanding, such as transaction confirmations in blocks. Settled means those conditions were met. Lightning payments normally do not wait for block confirmations. Goods are released according to the store’s policy, payment method and purchase value. Manually changing a status does not prove network confirmation; an unusual payment must first be verified. [4]
Lightning Network enables fast payments through payment channels: connections established between participants in advance. Receiving requires connectivity and inbound liquidity, meaning room for additional funds to arrive through those channels. That is not the same as the money the merchant already owns. Running a node, a computer with payment-processing software, entails channel management and ongoing attention. A service can simplify the work, but the merchant depends on its operation and, depending on the model, may entrust it with funds too. [2]
Choosing a solution involves more than comparing one advertised rate. Besides network and service fees, a cost can sit in the exchange rate: the difference between the applied rate and the reference used for comparison. Include inbound liquidity, equipment, maintenance and staff time. Self-management gives control and responsibility for keeping things running. A simpler service can introduce limits and the risk of provider outage or failure. The next shift must also know the procedure, including handling outages or incorrect amounts. [2] [4]
Reconciliation needs a retained connection between the order, payment, exchange rate, fees and any provider payout. BTCPay Server can export reports, but those alone do not guarantee compliance with local accounting obligations. A refund is a new payment, not deletion of the original transaction. Decide its currency and calculation method in advance, and verify the customer’s receiving details. In the documented BTCPay process, creating a refund link is not enough: after the customer submits a destination, the payout still needs processing. [5] [6]
The useful question is not only “How many places did we add?” but also “Can people still pay there, and do they return?” Track operational locations, successful purchases, repeat use and payment problems separately. Compare consistent periods and definitions, and record closures and outdated information. Local help and regular checks keep the option usable. Locations are not a customer count, and accepting Bitcoin alone guarantees neither increased sales nor a rise in its price. [1] [5]
Coffee paid for, questions still open
At a hypothetical café, staff create a request for a specific order. The customer scans it and pays through Lightning Network. Staff verify actual receipt in their own system and complete the sale; a picture from the customer’s phone is insufficient. This purchase demonstrates a working process at that moment, not the number of regular customers. Whether the café keeps bitcoin or receives another currency from its provider is recorded separately.
For the clearest picture, read this entry together with Bitcoin Point of Sale, Bitcoin Payment Processor, BTC Map, Lightning Network, Medium of Exchange, Grassroots Bitcoin Adoption. The reverse links also lead from Bitcoin Pizza Day, Paralelní Polis, Bitcoin Coffee, BTC Prague.
01Must a merchant hold the bitcoin received?+
No. It can manage it directly or use a provider offering settlement in a supported local currency. The merchant needs to know fees, payout conditions and who controls funds until then. “The customer paid bitcoin” does not reveal the currency the merchant ultimately receives.
02Is a sticker or map enough to verify acceptance?+
They show an announced or recorded option that may be outdated. Check the specific location and whether the whole payment process works there today. A conclusion about lasting use also needs data on actual and repeated purchases. One successful test cannot replace that evidence.