Accept Bitcoin Payments: The Complete Merchant Guide
A non-custodial Bitcoin checkout that settles straight to your wallet, routes to the cheapest chain, and lets you receive any supported asset.
- Apa is non-custodial: Bitcoin payments settle directly to your own wallet, and Apa never holds or freezes your funds.
- Pay-in and payout are independent — a customer can pay in BTC while you receive USDC, USDT, or BTC on the chain you choose.
- A cheapest-route settlement engine automatically minimizes network fees, and Apa's per-payment fee sits well below the typical ~2.9% + fixed card fee.
- Bitcoin payments are push payments: once confirmed on-chain they are final, so there are no chargebacks and no months-long dispute windows.
- Integrate with hosted checkout, shareable payment links, or a developer API — and self-host the stack when you want maximum sovereignty.
How Accepting Bitcoin Payments Actually Works
Accepting Bitcoin is fundamentally different from taking a card. A card payment is a pull: you request funds from the customer's bank, an issuer and a network sit in the middle, and the money can be clawed back later. A Bitcoin payment is a push. The customer initiates an on-chain transaction from their own wallet directly to an address, with no card network or acquiring bank involved. There is no request to approve, no interchange to split, and no intermediary that can reverse the transfer after the fact. That single structural change is why Bitcoin acceptance removes chargebacks and shrinks fraud exposure.
To keep every payment attributable to the right order, Apa generates a unique payment address and matching QR code for each checkout session. When a shopper reaches checkout they see the exact BTC amount due and an address that belongs to that one order. Because the address is session-specific, Apa reconciles the incoming transaction against the invoice automatically — no manual amount matching and no guessing which customer paid. The buyer scans the code with any Bitcoin wallet, confirms, and broadcasts.
From there the payment moves through a predictable lifecycle: broadcast to the network, entry into the mempool where it waits to be included, confirmation once a miner adds it to a block, and settlement to the merchant's wallet. Apa tracks each stage and surfaces the status so you always know where an order stands. Bitcoin is a bearer asset — value moves with the coins themselves, controlled by whoever holds the keys — so settled funds are genuinely yours the moment they land, without the reversibility and reserve risk baked into card rails.
Pay-in and payout are also fully independent. The asset the customer pays with does not have to be the asset you receive. A customer can pay in BTC while you receive USDC, USDT, or another supported asset in your own wallet — a separation that underpins almost everything useful about the setup, from volatility handling to clean accounting.
Bitcoin Settlement: Chains, Confirmations, and Finality
Native Bitcoin settlement happens on Bitcoin's Layer 1. Confirmations are simply the number of blocks mined on top of the block that contains your transaction, and because Bitcoin targets roughly one block every ten minutes, confirmation timing follows that cadence. A single confirmation means the transaction is in a block; each additional confirmation makes reversing it exponentially harder. Apa monitors this depth and decides when a payment crosses the threshold you've set to be treated as final.
Apa's cheapest-route settlement engine evaluates the lowest-cost path for each payment automatically. Across Apa's supported assets and chains — BTC, ETH, SOL, USDC, USDT, POL, BNB, AVAX, and TRX on Bitcoin, Ethereum, Base, Arbitrum, Solana, Polygon, Avalanche, BNB Chain, Optimism, and Tron — network fees vary enormously, and the engine selects the route that costs the least with no configuration from you. For a merchant who accepts BTC and takes a stablecoin payout, this is where a lot of the savings quietly happen.
When a payment is considered 'final' is a genuine trade-off rather than a fixed answer. Zero confirmations (0-conf) offer instant perceived settlement but carry the small risk that a transaction is dropped or replaced before it lands in a block, which is acceptable for low-value or digital goods. One confirmation (1-conf) is a common middle ground that balances speed against certainty. Six confirmations (6-conf) is the conservative, high-value standard, giving near-certainty at the cost of roughly an hour of waiting. Choosing the right threshold means matching the value at risk to how long you're willing to wait.
- 0-conf: fastest UX, small reversal risk — suited to low-value or digital purchases
- 1-conf: balanced default — the transaction is in a mined block
- 6-conf: conservative, high-value standard — deep, effectively irreversible finality
Handling Bitcoin's Price Volatility: Settle in Stablecoins
The classic objection to accepting Bitcoin is volatility: BTC can move meaningfully between the moment an invoice is created and the moment the transaction confirms. If you price in Bitcoin and hold the coins, you inherit that movement whether you want it or not. For most merchants selling ordinary goods and services, that exposure is a distraction rather than a feature.
Apa's pay-in versus payout independence is the clean solution. You accept BTC from the customer, but the funds that land in your wallet can be USDC or USDT — stablecoins pegged to the dollar. The customer pays with the asset they hold; you receive dollar-denominated value in your treasury. Stablecoin payouts can settle across chains such as Ethereum, Base, Arbitrum, Polygon, and Tron, so you pick the network that fits your wallet setup and cost preferences, with the cheapest-route engine steering the economics.
Merchants who actually want Bitcoin exposure are not left out. You can choose to receive BTC directly, which suits Bitcoin-native businesses, treasury strategies that intentionally accumulate BTC, and brands whose customers expect them to hold the asset. The point is that it's a deliberate choice, not a default you're stuck with. Because pay-in and payout are decoupled, you set your own currency-risk posture.
To close the loop on pricing, Apa lets you denominate the invoice in fiat — USD or EUR — and have the customer pay the exact BTC equivalent calculated at checkout time. The amount owed is expressed in the currency you actually run your business in, the BTC figure is fixed at the moment of payment, and your books stay clean regardless of where BTC trades that afternoon.
The Fee Advantage: Bitcoin vs Card Networks
The baseline to beat is the card network. Roughly 2.9% plus a fixed fee per transaction is the familiar starting point, and that headline rate understates the real cost of acceptance. On top of the percentage you can face chargeback fees when disputes are raised, rolling reserves that hold back a slice of your revenue, and the operational overhead of fighting fraud. The advertised rate and the effective rate are rarely the same number.
Apa's per-payment fee is structured to sit well below the card-network equivalent. Instead of paying interchange to issuers and assessments to networks, you pay a lean processing fee, and the cheapest-route settlement engine minimizes the on-chain network cost automatically — no configuration and no fee-optimization homework. The result is a flatter cost of acceptance where what you're quoted is close to what you actually pay.
The more honest comparison is total cost of acceptance, not just the sticker fee. On cards that means percentage fees plus fraud losses plus chargeback overhead plus the working-capital drag of reserves. With Bitcoin it means a flat, final settlement with no reversal risk and no reserve. When you add up the pieces, the gap widens for the businesses that suffer most from the hidden costs.
Some merchant categories benefit disproportionately. High-ticket sellers save real money on every percentage point avoided. Thin-margin businesses see payment fees eat a large share of profit, so any reduction moves the needle. International sellers dodge cross-border and FX surcharges. And subscription businesses, which pay fees on every recurring charge, compound the savings over a customer's lifetime.
No Chargebacks: Why Bitcoin Payments Are Final
A chargeback is a card-network mechanism that lets a cardholder's bank forcibly reverse a completed payment. It exists to protect consumers, but for merchants it is a structural cost and a fraud vector. 'Friendly fraud' — where a customer receives goods and then disputes the charge — is a well-known problem, and even winning a dispute costs time and fees. The reversibility that makes cards feel safe for buyers makes them risky for sellers.
Bitcoin flips this. Because it is a push payment initiated by the customer, no third party can reverse it once it has been confirmed on-chain. There is no issuing bank standing behind the transaction with the power to claw it back. 'Final' here means cryptographic finality — the transaction is embedded in the blockchain and secured by proof of work — rather than the contingent 'final unless disputed' state of a card payment, where the dispute window can stretch across months.
This does not mean customers lose the ability to get their money back for legitimate reasons. Refunds still happen; they just happen the right way. When a refund is warranted, the merchant sends a voluntary on-chain refund back to the customer. You stay in control of when and how much to return, rather than having funds pulled from your account by an external process. It's a deliberate, auditable action instead of an involuntary reversal.
The industries that gain the most are exactly the high-chargeback verticals: travel, electronics, digital goods, gaming, and other categories where dispute rates and friendly fraud run chronically high. For these merchants, moving even part of their volume to Bitcoin materially changes the fraud economics, because the single most expensive failure mode — the involuntary reversal after fulfillment — simply doesn't exist.
Security, Self-Custody, and Why Non-Custodial Matters
Non-custodial has a precise meaning: Apa never holds your funds. Settlement goes directly to the wallet address you control, and at no point does the money sit in an Apa-owned account waiting to be paid out. That is the opposite of a custodial processor, which receives your revenue first and then forwards it to you on its own schedule.
The distinction matters because custodial arrangements introduce counterparty risk. If a custodial processor is hacked, becomes insolvent, freezes withdrawals, or gets caught up in a regulatory action, your money can be trapped or lost even though you did nothing wrong. Crypto's recent history is full of cases where funds held by an intermediary evaporated. With direct-to-wallet settlement there is no intermediary balance to seize, freeze, or lose — the payment goes from customer to you.
Setting this up is straightforward. You configure your own Bitcoin wallet address, along with your chosen payout addresses for other assets and chains, inside Apa, and you retain full control of the keys. Apa routes payments to those addresses but never has custody of them. For merchants who want maximum sovereignty, Apa's stack is self-hostable, so you can run the infrastructure yourself rather than relying on a hosted service in your payment path.
There is also a compliance dimension. Because Apa never custodies funds, the regulatory surface tied to holding customer money is narrower for you than it would be with a processor that pools and holds balances. You should always take your own regulatory advice for your jurisdiction and business, but the architecture itself keeps you close to a simple 'money moves directly to my wallet' posture.
Integration Options: Hosted Checkout, Payment Links, and API
Apa offers three ways to integrate so you can match the effort to your setup. Hosted checkout is the drop-in option: a ready-made UI handles address generation, QR display, confirmation tracking, and webhook callbacks, so you add crypto acceptance with minimal code. The heavy lifting of watching the mempool and counting confirmations is done for you, and the buyer gets a clean, familiar checkout experience.
Shareable payment links require no website at all. You generate a Bitcoin payment link for an invoice, a social-commerce sale, or an email, send it to the customer, and they pay. This suits freelancers, service businesses, and anyone who bills ad hoc rather than through a storefront. The developer API sits at the other end of the spectrum, giving you full programmatic control for custom checkout flows, multi-currency routing logic, and back-end settlement handling when you want the payment experience embedded directly in your own product.
Across all three, webhook events keep your systems in sync in real time. Your backend receives status updates as a payment moves from pending to confirmed to settled, which lets you automate fulfillment — release a digital download, provision a SaaS account, or mark an order paid — the instant the payment reaches your chosen finality threshold. No polling, no manual reconciliation.
- Hosted checkout: fastest to launch; ideal for e-commerce platforms and standard storefronts
- Payment links: no site required; ideal for freelancers, invoicing, and social commerce
- Developer API: full control; ideal for SaaS billing, custom flows, and POS integrations
- Webhooks: real-time pending, confirmed, and settled events to automate fulfillment
Who Should Accept Bitcoin Payments (and Who Might Not)
The best-fit merchants tend to share a few traits. International sellers avoid FX middlemen and cross-border surcharges. High-ticket sellers save the most from lower fees and eliminated chargebacks. Digital-product businesses fulfill instantly and want fast, final settlement. And privacy-conscious customers and Bitcoin-native communities actively prefer paying in BTC, so offering it meets real demand rather than manufacturing it.
High-chargeback verticals deserve special mention. Travel, electronics, adult, and gaming businesses lose a disproportionate amount to disputes and friendly fraud, and for them Bitcoin acceptance changes the risk calculus outright, since the involuntary reversal after fulfillment goes away. The cross-border case is equally strong: Bitcoin acts as a shared settlement layer that works the same in every country, without SWIFT delays, correspondent-bank hops, or FX conversion cutting into the amount you receive.
Bitcoin is not the right fit for every situation, and it's worth being candid about that. Merchants in heavily regulated industries should confirm their obligations before enabling crypto. Businesses that need instant fiat in a bank account may prefer to pair crypto acceptance with an off-ramp, though settling to a stablecoin already removes most of the volatility concern. And very high-volume, razor-thin-margin retail should model the numbers carefully, even though lower fees usually help rather than hurt.
Finally, offering Bitcoin checkout is a differentiator. It signals that a brand is forward-looking, and it tends to attract a loyal, high-intent buyer segment that specifically seeks out merchants who accept crypto. For many businesses the customer-demand signal alone — 'do you take Bitcoin?' — is reason enough to add it alongside existing payment methods.
Getting Started: Accept Bitcoin with Apa in a Few Steps
Standing up Bitcoin acceptance with Apa is deliberately fast because there is no custody to configure, no underwriting to wait on, and no reserve to negotiate. You connect the wallet you already control, decide how you want to be paid, choose an integration style, and go live. The steps below cover the full path from account to first settled payment.
Most merchants can complete this in a single sitting. The two decisions that matter most are your payout asset — a stablecoin for stability or BTC for exposure — and your confirmation threshold, which sets how much finality you need before you fulfill an order. Get those right for your business and the rest is configuration.
- Create your Apa account and open the merchant dashboard.
- Add the Bitcoin wallet address you control, plus any payout addresses for the assets and chains you want to receive on.
- Choose your payout asset and chain — for example, take BTC from customers but receive USDC on Base — and set your invoice currency (USD or EUR) so amounts are priced in fiat.
- Set your confirmation and finality threshold (0-conf, 1-conf, or 6-conf) to match the value and risk profile of your orders.
- Pick an integration: enable hosted checkout, generate a shareable payment link, or wire up the developer API for a custom flow.
- Configure webhooks so your backend receives pending, confirmed, and settled events to automate fulfillment.
- Run a small test payment end to end and confirm settlement lands in your own wallet.
- Go live and start accepting Bitcoin — with funds settling directly to you and the cheapest-route engine minimizing fees automatically.