Bitcoin Address Types Explained for US Merchants

When a customer wants to pay you in bitcoin, the first thing your payment setup generates is an address. That string of letters and numbers looks like gibberish, but every character follows a precise format that determines network fees, wallet compatibility, and whether a QR code scanner can pre-fill the checkout amount automatically.

There are three address formats in widespread use today. Understanding which one your processor generates, and why, helps you troubleshoot failed scans, choose the right tool, and have an informed conversation with your accountant or compliance counsel about how transactions are recorded on-chain. If you are new to how the payment flow works end-to-end, start with how Bitcoin payments work step by step before continuing here.

The Three Bitcoin Address Formats

Bitcoin addresses have evolved through three generations, each improving on the last in terms of fees and error resistance. All three remain valid on the network today.

Legacy (P2PKH) Addresses

Legacy addresses start with the number 1 and follow the Pay-to-Public-Key-Hash (P2PKH) script format. Example: 1A1zP1eP5QGefi2DMPTfTL5SLmv7Divf.

These were the only format available for the first several years of Bitcoin's existence, so every wallet and exchange ever built supports them. The compatibility ceiling is essentially 100%. The drawback is transaction weight: P2PKH inputs are larger than newer formats, which means higher network fees when the bitcoin network is congested.

For US merchants processing a handful of in-person transactions per week, the fee difference is usually a few cents. For high-volume processors settling hundreds of payments daily, it adds up.

SegWit Wrapped (P2SH-P2WPKH) Addresses

Addresses that start with 3 use the Pay-to-Script-Hash format. Most commonly, a 3... address wraps a SegWit script inside a legacy-compatible envelope, a scheme sometimes called P2SH-P2WPKH.

This format was introduced as a compatibility bridge after the 2017 SegWit activation. Wallets that did not yet support native SegWit could still send to a 3... address without any code changes on their end. Fees for the merchant's future spending are lower than P2PKH because the script logic moves partly to the witness data section of the transaction.

The trade-off is that 3... addresses are also used for multi-signature wallets and other smart contract-like scripts, so a 3... address alone does not tell an observer whether SegWit is involved.

Native SegWit (Bech32 / P2WPKH) Addresses

Native SegWit addresses start with bc1q and use the Bech32 encoding defined in BIP 173. Example: bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq.

This format is the current standard for new implementations. Bech32 addresses are case-insensitive (all lowercase by convention), which eliminates the O-vs-0 and I-vs-l ambiguity that trips up manual entry. They also carry a built-in checksum that can detect and sometimes correct transcription errors before a transaction is broadcast.

Network fees for spending from a native SegWit address are lower than either earlier format because the witness data receives a fee discount at the protocol level. The only compatibility gap is very old wallet software, most of which has been updated in the years since Bech32 launched.

A newer encoding called Bech32m (used for Taproot / P2TR addresses starting with bc1p) exists but is not yet the default output format for most US payment processors as of mid-2026.

Which Format US Payment Processors Use by Default

Most processor defaults have shifted toward native Bech32 over the past few years, but the landscape is not uniform.

Self-custodial processors (those that generate addresses from your own wallet's extended public key) typically output whatever format your wallet uses. If you connect a hardware wallet configured for native SegWit, you get bc1q... addresses. If your wallet is set to legacy mode, you get 1... addresses. The processor itself does not override your wallet's derivation settings.

Custodial processors control address generation on their end. Most major US-facing services now default to native Bech32 for new merchant accounts because it reduces their own settlement fees. Some older accounts provisioned before 2021 may still show P2SH wrapped addresses unless the merchant explicitly regenerated their payment configuration.

Point-of-sale integrations that connect directly to the Bitcoin network, rather than routing through a hosted service, inherit the address format from the underlying node or wallet daemon configuration.

The practical takeaway: check your processor's documentation or account settings to confirm the output format. If you see 1... addresses, ask whether upgrading to native SegWit is available, particularly if you are processing enough volume that fee savings matter. For a side-by-side look at which US processors offer self-custodial vs. custodial address generation, see custodial vs. self-custodial Bitcoin payment tools.

BIP21 URIs: Bundling Address, Amount, and Memo

An address alone tells a customer's wallet where to send bitcoin. It does not tell the wallet how much to send, which means the customer has to manually type the invoice amount in their wallet app, creating room for error.

BIP21 solves this with a standardized URI format that bundles address, amount, and optional metadata into a single string:

bitcoin:bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq?amount=0.00123456&label=Order-4821&message=Coffee%20and%20pastry

Breaking that down:

• bitcoin: is the URI scheme, registered with IANA, so the operating system knows to hand it to a Bitcoin wallet app.
• The address follows immediately after the colon.
• amount= is denominated in BTC, not satoshis or USD. Your processor converts the USD invoice total to BTC at the moment of payment request generation.
• label= is a short identifier visible in the customer's wallet history.
• message= is a human-readable note that does not go on-chain but helps the customer confirm what they are paying for.

When a customer's wallet receives a BIP21 URI (by scanning a QR code or tapping a payment link), it pre-fills all fields and shows a confirmation screen. The customer taps "Send" rather than entering an address and amount by hand. This reduces the chance of keying errors and speeds up the checkout flow at a physical register.

Note that BIP21 is a wallet-to-wallet convention, not a protocol rule. A wallet that does not support BIP21 will simply see an address string it does not understand. All major mobile Bitcoin wallets released after 2015 support the standard, but if you run into an older or specialty wallet that stalls on a BIP21 link, providing the raw address and amount separately as a fallback is good practice.

QR Codes at the Point of Sale

A QR code is just a visual encoding of a BIP21 URI (or, for simpler setups, the raw address). The QR generator in your payment processor encodes the URI string, and the customer's wallet camera decodes it.

A few practical points for in-person use:

Screen brightness matters. A dimly lit phone screen displaying a QR code is the most common source of failed scans in retail settings. Ask the customer to raise screen brightness, or display the code on your own terminal screen where you control lighting.

Code density scales with URI length. Native Bech32 addresses are 42 characters. Adding an amount, label, and message can push the full URI past 100 characters. More data means a denser QR grid, which requires better camera focus. Most modern phones handle this without trouble, but cheap barcode scanners sometimes struggle. Test your setup with the longest URI your processor generates before going live.

Do not reuse addresses across transactions. Each payment request should generate a fresh address so you can match a payment to a specific order on-chain. Most processors handle address rotation automatically, but if you are running a manual setup, address reuse creates reconciliation headaches and reduces privacy for both you and your customers.

For a deeper look at configuring a physical checkout flow, including hardware options and network connectivity requirements, see accepting Bitcoin at the point of sale. For a comparison of which US processors handle BIP21 generation natively, see the best Bitcoin payment processors for US businesses.

Frequently Asked Questions

Can I accept payments to a Legacy address if my customers have newer wallets?

Yes. All three address formats are valid receive destinations on the Bitcoin network today. A customer using a Bech32-native wallet can send to your Legacy 1... address without any issues. The address format affects fees and error resistance, not network compatibility between sender and receiver.

Does the address format affect how IRS reporting works?

The address format itself has no bearing on tax treatment. The IRS treats bitcoin received in exchange for goods or services as ordinary income at fair market value on the date received, regardless of whether the on-chain address starts with 1, 3, or bc1q. What matters for recordkeeping is the USD value at the time of receipt and the subsequent cost basis when you dispose of the bitcoin. Tax rules can change and vary by situation, so verify current requirements with a tax professional or IRS guidance rather than relying solely on this article.

What is the difference between a BIP21 URI and a Lightning invoice?

A BIP21 URI points to an on-chain Bitcoin address. A Lightning invoice is a separate payment request format (BOLT 11) used on the Lightning Network, which is a second-layer payment system that settles off-chain. Some wallets and processors support Unified QR codes that embed both a BIP21 URI and a Lightning invoice in a single QR code, letting the payer's wallet choose the payment method automatically.

Why does my processor show a new address for every invoice?

This is intentional. Generating a unique address per transaction lets your processor match an incoming payment to a specific order, which is necessary for automated payment confirmation. It also means on-chain observers cannot trivially link all of your transactions to a single address. Most processors derive fresh addresses from a hierarchical deterministic (HD) wallet, so address rotation does not require manual key management on your end.

Do I need to register with FinCEN to accept Bitcoin payments as a retailer?

This depends on your business model and transaction volume. Retailers that accept bitcoin as direct payment for goods or services occupy a different regulatory category than businesses that exchange currencies for customers. FinCEN guidance distinguishes between accepting bitcoin as a payment method and acting as a money services business (MSB). The rules are nuanced and evolve, so consult a compliance attorney or review the current FinCEN guidance for your business type before drawing conclusions.