Bitcoin Payment

Overview

A payment request commonly specifies a Bitcoin address, amount, expiration, and optional label or message. The payer’s wallet selects UTXOs, constructs recipient and change outputs, calculates a fee, and signs the transaction.

The merchant can detect the transaction in a mempool, but zero-confirmation acceptance carries replacement and double-spend risk. After block inclusion, additional confirmations increase settlement confidence. The appropriate threshold depends on value and fulfillment reversibility.

Matching should inspect the exact output sent to the merchant. A transaction can contain several outputs, and the total transaction value does not represent the payment amount. Address reuse can make attribution ambiguous, so invoice-specific addresses improve reconciliation.

Payment exceptions need defined policies. A customer can send too little, too much, after expiration, or with an insufficient fee. Refunds require a new Bitcoin transaction and a verified refund address; the apparent input address may not be controlled by the customer.

Fees are normally paid by the sender but can affect the intended amount if the wallet subtracts fees from the output. Price volatility also requires a defined exchange-rate quote and expiration when goods are priced in fiat.

A Bitcoin payment is both a native blockchain transaction and a commercial event. Reliable processing links protocol evidence to the invoice without treating detection, confirmation, and fulfillment as the same state.

For fiat-priced invoices, the merchant should preserve the exchange-rate source, quote time, expiration, and accepted tolerance. A later support agent should be able to explain why an amount was considered paid, underpaid, or late. This prevents current market price from being applied incorrectly to historical payment decisions.