Begin with the business decision
Decide why Bitcoin payments are useful for the business and its customers. Possible reasons include customer demand, international settlement, fewer card intermediaries or learning to hold a small bitcoin balance.
Choose in advance whether receipts will be held as bitcoin, converted to local currency or split between both. This decision affects volatility exposure, accounting, liquidity and which payment provider or wallet is appropriate.
Choose on-chain, Lightning or both
On-chain payments settle on Bitcoin's base layer. Fees and confirmation times vary with network demand, so a business needs a written policy for when an unconfirmed payment is acceptable and how many confirmations are required for higher-value sales.
Lightning is often better suited to small, fast payments. It also introduces operational choices around channel liquidity, wallet availability, backups and custody. A hosted service is simpler but requires trust; a self-managed Lightning node gives more control and more responsibility.
Design a payment and verification flow
Generate a fresh invoice or address for each sale, display the amount and expiry clearly, and verify payment status in the merchant's own wallet, point-of-sale system or node. A customer screenshot is not proof of payment.
Define what staff should do when the amount is wrong, an invoice expires or an on-chain transaction remains unconfirmed. Test the full workflow with small payments before making it customer-facing.
Separate checkout funds from long-term holdings
A checkout wallet should contain only the amount needed for routine operations. Move larger balances to a more secure treasury arrangement with documented access, backups and recovery testing.
Use role-based access where possible. Staff who create invoices may not need permission to export backups or move treasury funds. Never place seed words, private keys or unrestricted node credentials in a point-of-sale device or shared document.
Prepare records, refunds and customer communication
Record the local-currency value, timestamp, bitcoin amount, network fee and transaction or invoice reference for each sale. Tax and consumer-law treatment varies by jurisdiction, so confirm requirements with a qualified local adviser rather than relying on wallet history alone.
Publish a clear refund policy. A refund is a new Bitcoin payment, so confirm a refund address through a trusted channel and never assume the original sending address belongs to the customer. Decide whether refunds use the original bitcoin amount or the current local-currency equivalent.
Launch as a controlled pilot
Start with a limited product range, location or payment limit. Train staff, monitor failed or delayed payments and review whether the chosen custody and conversion model still fits the business.
Keep a fallback payment method while the process is new. A reliable customer experience matters more than accepting Bitcoin in every situation from day one.
Visual recap
A merchant payment from quote to records
Each stage should have an owner, a verification method and a fallback procedure.
Price the sale
Create invoice
Customer pays
Merchant verifies
Deliver goods
Record and secure
Key takeaways
- Choose the payment rail and treasury policy before choosing software.
- Verify payments in merchant-controlled systems rather than from screenshots.
- On-chain confirmation and Lightning liquidity require different operating procedures.
- Separate day-to-day checkout access from long-term treasury security.
- Document records, refunds, staff actions and fallback procedures before launch.
Lesson recap
Check what you learned
Reveal each model answer, then honestly mark whether you understood it or need another review.
1 of 3
Recall
Why should a merchant not send a refund automatically to the transaction's input address?
References
