Bitcoin Payment Processor creates payment requests, matches incoming payments to orders and supports recordkeeping. It can be self-hosted or provided as a service. It is not a Bitcoin consensus rule, and the label processor does not identify who controls the funds.
The shop creates an order and its server requests an invoice with an amount and currency from the processor. It stores the link between its internal order number and the invoice identifier. The customer receives a payment page or QR code, and the processor monitors receipt. Without this link, a payment cannot reliably be assigned to the order it fulfils; returning to the browser alone is not proof of payment. [BTCPay Server — eCommerce integration]
BTCPay Server can derive receiving addresses from an existing wallet’s public data without its private key. This differs from a hot wallet stored on the server and from access to a Lightning node’s funds. A provider may hold funds until payout. Assess actual key possession, permissions and withdrawal capability, rather than just the product name or the word non-custodial. [BTCPay Server — General FAQ] [BitPay — Configuring settlements]
A normal BTCPay Server invoice locks the exchange rate for a limited period. Expiry does not mean that a later transfer cannot arrive. Underpayments, overpayments and late payments have different statuses and require follow-up procedures. Keep the original amount and the exchange rate used; if the price changes, a newly issued request may not ask for the same number of satoshis. [BTCPay Server — Invoice lifecycle]
BTCPay Server distinguishes Processing, which awaits the configured confirmations, from Settled; successful Lightning payments become Settled without waiting for a block. Other providers’ status names cannot simply be equated: BitPay explicitly warns that paid is not a payment guarantee. The shop needs a fulfilment rule for the specific status and payment method. Manually changing a status does not create a network confirmation. [BTCPay Server — Invoice lifecycle] [BitPay — Invoice webhooks]
BTCPay verifies a webhook using HMAC-SHA256 over the original body bytes and a shared secret. BitPay describes unsigned IPNs: a notification prompts an API query for the invoice status, rather than itself providing trustworthy evidence. Notifications may arrive repeatedly. An integration must therefore reliably recognise a redelivered event and prevent a second shipment for the same order; after an outage, stored statuses must be reconciled with the processor. [BTCPay Server — Webhook validation example] [BitPay — Invoice webhooks]
Confirmation of the customer’s payment need not coincide with a payout from the provider. BitPay allows a settlement currency and a bank account or cryptocurrency address to be configured; a change may require approval. Check available currencies, limits, timing, fees and control of funds before payout. Direct receipt into your own wallet does not automatically use this provider-payout model. [BitPay — Configuring settlements] [BTCPay Server — General FAQ]
A refund requires another payout and verification of the recipient; it does not alter the original bitcoin transaction. Separate the order dispute, the decision about the refund amount and the actual transfer of money. Retain order–invoice–payment links, exchange rates, fees and refunds. Exporting a report helps recordkeeping but does not by itself resolve every local accounting obligation or a dispute about delivery. Even a confirmed transfer does not by itself settle a transaction’s legal finality: check disputes, any chargeback mechanism and obligations for the payment rail, contract and jurisdiction. [BTCPay Server — Refunds] [BTCPay Server — Reporting] [BitPay — Merchant and shopper terms]
Test successful, incomplete, late and repeatedly notified payments, as well as recovery after an outage. Give an API key only the permissions it needs and restrict it to the relevant store. Do not put unnecessary customer information in metadata. Budget for hosting, updates, liquidity and support; free software does not mean zero operating costs. Service availability, key custody and integration correctness are separate requirements. [BTCPay Server — eCommerce integration] [BTCPay Server — Lightning operations]
The same notification is not another purchase
In a hypothetical integration, order OBJ-101 has its invoice identifier stored. Once settlement has been verified, the system creates a shipment once. When a repeated notification of the same event arrives later, it associates it with the already fulfilled order and does not create another shipment. Simply displaying a thank-you page must not trigger this transition.
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 Alza Bitcoin payments, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.
01Does every payment processor hold my bitcoin?+
No. Some solutions only create requests and monitor receipt into your wallet; others manage funds until payout. Even the same software can use different wallet models. Keys, permissions and the actual flow of funds matter, rather than the processor label alone.
02Can a shop ship after the customer returns from the payment page?+
The return alone is insufficient. The shop must verify the corresponding invoice and its status using that processor’s procedure. Notifications are verified according to the documentation, and redelivery must not trigger another fulfilment. Goods are released according to the chosen payment-confirmation conditions.