Bitcoin with your xpub

Accept BTC to fresh addresses from your own wallet's account key, verified on the payer's device.

Bitcoin payments go straight to your own wallet: every BTC invoice gets a fresh receive address derived from your account's extended public key, never reused. Only the public key is ever shared; nobody but you can spend.

Test mode only for now. Live BTC is not offered yet. In test mode BTC runs on testnet4 at a fixed test price.

#The key to provide

Your wallet's account-level extended public key, the one at m/84'/<coin>'/<account>' (native SegWit) or m/86'/<coin>'/<account>' (Taproot):

A master key, a ypub (BIP-49) and anything private (xprv, zprv, …) are refused. The key is registered for your account during early-access onboarding (there is no API for it), and pinned: the same key again changes nothing, a different key is refused.

#How addresses are issued

• Addresses come from the receive chain, …/0/<index>, one new index per invoice.
• Gap limit. Wallets stop looking after 20 unused addresses in a row. If many invoices go unpaid, new addresses would land beyond what your wallet scans; the account can be set to warn or to refuse new BTC invoices at that point. Raise the gap limit in your wallet to match if you issue many.
• BTC invoices are open for 60 minutes with a 15-minute price lock (see late payments), and are credited at 1, 3 or 6 confirmations depending on the amount (finality).

#Let the checkout verify the address

Pin your key in the embed's pins, as bip122:<network>@<your zpub>. The checkout then derives each invoice's address from your key on the payer's device and refuses to show one that does not match. With no pins at all, it shows the server's address without claiming it is verified. If you pass pins for other networks but not for Bitcoin, the BTC option fails its check and the checkout refuses to show any address, so pin your key whenever you pin anything.

BTC refunds are not supported yet: refund claims accept TRON and EVM addresses only.