Bitcoin Payment Processor is software or a service that creates payment requests, monitors incoming payments and matches them to orders. It helps a shop fulfil sales and retain records. It does not set Bitcoin’s network rules or necessarily hold customer funds: control of keys and the route money takes depend on the setup.
Imagine a customer ordering a book online. The shop asks the processor for an invoice: a payment request specifying the amount and currency. It saves the invoice identifier alongside the order number. The customer opens a payment page or scans a QR code and pays; the saved link lets the shop match the money to the purchase. Without it, merely detecting that bitcoin arrived somewhere is insufficient. Returning to a “Thank you for your order” page is not proof that the shop received payment either. [1]
BTCPay Server can generate receiving addresses from an existing wallet’s public data without obtaining the private keys that allow spending. This differs from a hot wallet with keys on the server, or access to funds in a Lightning node handling fast payments. With a service, the provider may control funds before payout. The label non-custodial, meaning keys are not entrusted to the provider, is therefore insufficient by itself. Check actual permissions, who can send the money and whether getting it requires someone else’s approval. [2] [6]
A book may be priced in a conventional currency while the customer sends bitcoin. BTCPay Server fixes an amount and exchange rate in the payment request for a limited period. Expiry does not prevent a later transfer from arriving; the shop must handle it correctly. Underpayments and overpayments also need attention. The original amount and rate remain in the records for reconciliation. A new request at a different rate can require a different number of satoshis, bitcoin’s smallest units, even though the book’s price has not changed. [3]
In BTCPay Server, Processing means the requested amount has been paid but settlement conditions are still outstanding, such as transaction confirmations in blocks. Settled means those conditions are met; Lightning payments normally do not wait for block confirmations. Other services define their own statuses. BitPay explicitly warns that paid is not a payment guarantee. A shipping rule must therefore follow the chosen service’s documentation and payment method. Manually marking an order paid cannot replace checking the actual payment. [3] [5]
The processor reports status changes through a webhook, an automatic message between servers. The shop must verify its origin and contents. For BTCPay, HMAC-SHA256 is calculated over the original message bytes using a shared secret; this is an authentication code, not a Bitcoin network confirmation. BitPay does not sign its IPN notification: it should merely trigger a lookup of the actual state through the API, an interface through which programs communicate. Messages can arrive again. The shop records fulfilment so another notification cannot cause another shipment. After an outage it reconciles saved states with the processor. [4] [5]
Receiving the customer’s payment and receiving a service payout are different events. BitPay supports configuring a settlement currency and a bank account or cryptocurrency address; changes may require approval. Merchants also check timing, limits, fees and who controls funds before payout. Direct receipt into their own wallet may have no such intermediate step. The sales system should distinguish the arrangements so that “paid” does not create a false impression of money already available. [6] [2]
A refund does not erase the original Bitcoin transaction. The shop first handles the customer’s request, determines the amount and currency, verifies the recipient and arranges a new payment. A link to claim a refund does not yet mean the money has been sent. Records retain the order, payment request, receipt, exchange rate, fees and refund. Exported reports help an accountant but do not by themselves satisfy every local obligation. A network confirmation neither resolves a delivery dispute nor removes contractual or statutory duties in handling a complaint. [7] [8] [10]
One successful test purchase is not enough before launch. Test underpayments, late payments, repeated notifications and recovery after an outage. An API key is a program’s access credential: give it only the permissions needed for the relevant shop. Attached information should exclude unnecessary customer details. Self-hosting involves hosting, updates and support; Lightning also needs liquidity management, meaning funds and room in channels for payments. Free software does not mean free operation. Availability, key protection and correct shop integration require separate checks. [1] [9]
A paid book and a repeated message
The shop links a payment request to order OBJ-101. After verifying payment and meeting its shipping conditions, it sends the book and records fulfilment. The same notification arrives later. The system recognises the fulfilled order and creates no further parcel. Simply opening the thank-you page would not have been enough to trigger shipment.
For the clearest picture, read this entry together with BTCPay Server, Bitcoin Point of Sale, Merchant Adoption, Lightning Network, Bitcoin. The reverse links also lead from Bitcoin Payment at Alza, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.
01Must I entrust bitcoin to the processor?+
Not always. Software can monitor payments into your wallet without spending keys. A server hot wallet, access to a Lightning node or a service that pays you later involve different conditions. Assess actual control of money and permissions, rather than just the non-custodial label.
02Can I ship as soon as the customer returns to the shop?+
No. Returning in the browser is just a page interaction. The shop needs a verified state for the specific payment and a fulfilment rule suited to that method. Repeated messages about the same payment must not trigger repeated shipments either.