How to Accept Bitcoin and Crypto on Your Online Store in 2026

Accepting Bitcoin on a website used to mean either running your own node stack or handing coins to a custodial processor. In 2026 the useful middle path is a non-custodial invoice at checkout: the store creates a payment request, the customer pays an address you control, and software watches the chain so your order system can move on.

TheyPaid is built for that path. This article is the merchant checklist — plugins versus API, which coins to turn on, and how to avoid the usual “paid but order still pending” mess.

If you want the model behind the checkout, start with the non-custodial payment gateway guide. This page is the storefront version.

Pick an integration path

You have three honest options. Choose one on purpose.

Dashboard invoices. Create a payment request in the merchant dashboard, send the customer the invoice, and fulfil when status is paid. This is enough for custom quotes, invoices, and low-volume stores.

E-commerce plugins. TheyPaid ships prebuilt plugins so a store can add crypto next to card checkout without designing a payment page from scratch. Configuration is an API key, the coins you accept, and the usual “when to mark the order paid” rule.

API or SDK. Custom apps, native checkouts, and platforms without a plugin use the HTTP API (merchant base URL https://merchant.theypaid.io, apiKey header) or the official theypaid-sdk package. Typical calls are create invoice, fetch invoice, list invoices, and list enabled assets.

If a plugin exists for your platform, use it. If you are inventing checkout UI anyway, use the SDK and keep the dashboard for operations.

What to show the customer

Copy the three-step buyer flow TheyPaid already documents, and do not add extra mystery.

1. Coin picker — only assets you enabled, with the network name visible (USDT is not “Bitcoin”).
2. Exact amount + address / payment URI + QR — customers paying from mobile wallets should be able to scan once.
3. Waiting state — “we are watching the network” is better than a spinner with no copy. Underpayments and expiry need their own screens.

Do not ask the buyer to create a TheyPaid account. They pay from a wallet they already have. Your job is to make the amount, asset, and destination unambiguous.

Coins to offer on a real store

More coins is not more conversion if support tickets eat the margin. TheyPaid’s marketing site lists BTC, BCH, LTC, BSV, XRP, DOGE, USDT, and GRAM (TON). A shop that prices in dollars often starts with:

• BTC for recognition.
• USDT when you want the paid amount to stay close to the sticker price.
• One extra chain your customers already use.

Turn assets on from the dashboard rather than in code. Your plugin or API should read the enabled list so a coin you disable does not still appear at checkout.

When to mark the order as paid

Crypto checkout fails in operations more often than in cryptography. Decide the rule before the first sale:

• Paid — detected amount meets the invoice. Fulfil or start fulfilment according to your risk tolerance for that asset’s confirmations.
• Insufficient — customer sent too little. Do not ship. Show the shortfall and a single next action.
• Expired — monitoring window ended without a valid payment. Offer a new invoice rather than recycling the old address in your own UI unless the gateway says that is safe.

TheyPaid can notify you via callbackUrl when status changes. Treat that payload as a hint: look up the invoice ID on your side and compare amounts before you fulfil. There is no HMAC on the documented webhook helper — verification against your database is the control.

For the operator view of those same states, see Inside the TheyPaid dashboard.

Pricing the checkout, not just the product

TheyPaid charges a processing fee from invoice amount on a published percentage ladder (0.65% on the smallest invoices down to 0.35% on very large ones). There is no monthly plan on that page. New accounts get a starting credit (currently $10) so you can test checkout without a procurement cycle.

Two costs you should not mix up:

• TheyPaid’s processing fee — based on invoice size.
• Network fees — paid by the customer’s wallet to miners/validators.

If you round prices in USD and let the gateway quote the exact crypto amount, say so at checkout. Exact-amount invoices fail when the UI shows “about $49.00” and the wallet sends a rounded satoshi count.

Plugin setup, without folklore

The plugin documentation on TheyPaid is deliberately generic because platforms differ, but the merchant steps do not:

1. Create a TheyPaid account and API key.
2. Install the plugin from the platform’s add-on flow.
3. Paste the key, select cryptocurrencies, and map paid/expired to order status.
4. Place a tiny live payment to your own wallet on the live network you intend to use. Testnets and mainnets are not interchangeable in customer wallets.

If you get stuck, the API docs are the source of truth for fields the plugin is wrapping.

Refunds, accounting, and the parts software will not do

Non-custodial checkout means you already have the coins. A refund is you sending from that wallet, not clicking “reverse” on a card acquirer. Build a manual refund SOP: verify the original tx, send back on the same network, and record it in your books.

You also remain responsible for taxes, consumer rules, and who you sell to. TheyPaid is invoicing and monitoring software, not a bank, exchange, or escrow.

Go live in one afternoon

A working 2026 setup is smaller than it looks:

1. Register on TheyPaid and complete merchant setup for the assets you will accept.
2. Connect a plugin or create your first API invoice.
3. Pay it yourself. Confirm the coins arrived in your wallet and the order or invoice flipped to paid.
4. Only then open it on the storefront.

Create a TheyPaid account and run that loop on a $1–scale invoice before you advertise “we take Bitcoin” on the homepage.