Bitpay invoices: from quote to accepted payment
BitPay invoices connect a merchant order or an in-app purchase to a cryptocurrency payment request. Each invoice specifies the amount and available payment routes, while its status records payment progress and exceptions.
- Access
- A BitPay payment account with completed BitPay ID verification.
- Acceptance window
- Send payment within 15 minutes. This window does not guarantee blockchain confirmation within that time.
Opening an invoice and fixing the quoted amount
At a merchant checkout, choosing BitPay leads to account sign-in or registration. The invoice is generated after sign-in with an approved account. For an in-app purchase, such as a gift card, the app creates the invoice and requires a linked BitPay account and sufficient funds in the BitPay Wallet.
The invoice instructions updated on October 31, 2026 require BitPay ID verification before continuing. An account that has already completed verification can proceed to the invoice. The payment account is separate from the self-custody wallet: signing in does not give access to the wallet's private keys.
What the 15-minute window covers
BitPay converts the purchase price into the selected cryptocurrency amount. Its rate calculation uses approved exchange prices and accounts for market volatility; market depth can also affect very large invoices. BitPay describes honoring the quoted rate for up to 15 minutes.
The acceptance window governs when payment must be sent. Blockchain congestion can delay on-chain confirmation after submission. A payment sent after the window may be rejected and require a refund, so the timer should not be read as either a confirmation deadline or a promise of completion.
Wallet choice determines how payment details are supplied
- Payment Protocol-compatible wallet
- The BitPay Wallet and other compatible wallets can populate invoice details through the QR code, payment URL, or Pay in Wallet option.
- WalletConnect
- Pairing a compatible wallet fills in the invoice details through the connection.
- Manual peer-to-peer payment
- A wallet without Payment Protocol support can pay using the displayed address and amount. For XRP, include the invoice's Destination Tag; for a Solana network payment, include its Memo. Missing the required tag or memo can prevent a payment-exception refund. This route requires the exact amount due; an amount mismatch can cause rejection and require a refund.
- Coinbase account payment
- BitPay documents this integrated route for U.S. residents. Other payments sent from exchanges are unsupported and are likely to cause a payment error and refund.
Payment Protocol and WalletConnect reduce manual entry, while the peer-to-peer route leaves the payer responsible for copying the exact address, amount, and any required tag or memo. A wallet's ability to send cryptocurrency does not establish that every exchange withdrawal or network is suitable for the invoice.
The asset and network must match the invoice
Available currencies vary with the shopper's or merchant's location. Documented options include BTC on-chain and through Lightning, BCH, LTC, DOGE, XRP, ETH, and supported tokens. Token payment networks include Ethereum, Polygon, Base, Optimism, Arbitrum, and Solana; Solana options include SOL, USDC, and USDT. The choices displayed on the particular invoice determine the supported payment combination.
BitPay invoices do not accept credit or debit cards, ACH, PayPal, Venmo, or Cash App as direct payment methods. Buying cryptocurrency through a partner that accepts traditional payments is a separate service, with its own account, availability, and delivery conditions.
The invoice total and the sending fee cover different costs
For an on-chain BTC payment, the Network Cost shown on the invoice covers BitPay's own cost of combining received transaction outputs and moving those funds. The miner fee charged by the sending wallet pays for the payer's transaction. BitPay displays the invoice Network Cost during currency selection and in the payment total; it varies with network conditions. A merchant may also pass its processing fee to the buyer.
BitPay's Network Cost guidance updated on October 15, 2026 excludes BCH, Ethereum/ERC-20 tokens, and XRP from that invoice charge. Sending still has its own network requirements. An Ethereum token transfer, for instance, requires ETH for gas at the same address as the tokens.
When the balance covers the invoice but not the transfer
The wallet needs enough confirmed spendable BTC for both the invoice total and its sending fee. Consider these hypothetical inputs for an on-chain BTC payment from the BitPay Wallet: invoice total, including any invoice Network Cost, 0.002764 BTC; sending miner fee estimate, 0.000019 BTC; confirmed spendable wallet balance, 0.002780 BTC.
The required balance is
0.002764 BTC + 0.000019 BTC = 0.002783 BTC
. The wallet is short by 0.000003 BTC, even though it holds more than the invoice total. Reducing the amount sent to the invoice would create an underpayment. A change in the sending fee estimate changes the required balance by the same amount without changing the invoice amount due.
Payment progress and exceptions
Submitting a transaction and obtaining a paid invoice are separate events. In the merchant dashboard, Paid can indicate that the full amount has been received while blockchain confirmation is pending; it is not a payment guarantee. The merchant's transaction-speed setting controls when the status becomes Confirmed, while Complete means funds have been credited to the merchant account. A debit in the sending account or a submitted transaction therefore does not, by itself, establish the invoice's final status.
Merchants can inspect the invoice ID, original fiat price and currency, cryptocurrency amount due, amount received, confirmation count, and status in the Payments view. The invoice history distinguishes payment receipt, refund events, and crediting. Those records help separate a payment exception from the later crediting or settlement of merchant funds.
Underpayment, overpayment, and expiry
- Underpayment
- Normally, an underpayment is not credited to the merchant. The shopper can request a refund; retrying requires a new invoice. BitPay's Shopper and Donor Terms, effective August 26, 2026, also allow a merchant arrangement that processes the amount received as an adjusted invoice. In that case, the shopper cannot claim an underpayment refund from the invoice, and the merchant decides whether to invoice the remainder.
- Overpayment
- For an invoice recorded as overpaid, the customer receives an email to claim a refund of the excess, subject to refund fees. An excess smaller than the refund's miner or network fee may be nonrefundable. Merchants can also refund the overpaid portion through payment management.
- Expiry
- An expired invoice has reached the end of its window without an accepted transaction. Payments sent after expiry are treated as orphan payments and cannot be applied to that invoice. A refund must be requested through BitPay Support; expiry is not evidence that a transfer never left the sending wallet or account.
The merchant Payments view groups records into All, Paid, and Unresolved, and supports searches by invoice ID or order ID. The Personal Dashboard provides shoppers with invoice payment history and refund tracking. Matching the merchant order to its invoice helps identify which payment is being investigated.
Geographic limits on invoicing
Merchant acceptance and invoicing have geographic restrictions in addition to the currency choices shown at checkout. BitPay's U.S. availability guide, updated on September 7, 2026, lists Hawaii and Louisiana as exclusions for merchant acceptance and invoicing. This is a specific service restriction; partner buying, selling, and swapping have separate eligibility rules.
For an unresolved invoice payment, BitPay Support handles payment-service questions. The merchant can locate the order's invoice and inspect its exception history, while the shopper's wallet or linked account provides the sending-side record.