Crypto payments for online stores and marketplaces

An online store wants to take crypto without rebuilding its checkout, its order system, and its finance reporting around a new payment method. halfin gives you a hosted checkout you redirect the customer to, an invoice tied to each order, and a signed webhook that tells your store when the money has actually arrived on-chain. Cards bring chargebacks and acquirer rules; a confirmed crypto payment is final, and the customer can pay from anywhere in USDT, USDC, or Bitcoin.

The problem: crypto has to fit the order, not the other way around

Stores already have a checkout, an order table, an inventory hold, and a finance process that reconciles what was charged against what was fulfilled. Adding crypto usually means one of two bad outcomes: a bolted-on widget that shows an address and hopes the customer pays the right amount, or a heavy integration that asks your team to learn block confirmations, wallet quirks, and reorg behaviour for every chain you accept.

The store does not want to own any of that. It wants the same thing it has with cards: a customer pays, the order flips to paid, fulfilment starts, and finance can close the books. The difference with crypto is that the failure modes are new — a customer can send slightly too little, pay on a network you do not accept, or close the tab and come back an hour later expecting the same address to work.

halfin's job is to make a crypto payment behave like an order event. You create an invoice anchored to the order total, send the customer to a page that handles every wallet and network detail, and your store learns the outcome through one signed webhook. The on-chain complexity stays on halfin's side; your store keeps its existing order model.

How halfin maps onto the store's order flow

The flow follows the order, not the chain. At checkout you create an invoice for the order total, quoted in the fiat currency your prices are already in — USD, EUR, or whatever your catalogue uses. The quote and rate are locked when the invoice activates, so the customer pays a fixed crypto amount and a moving market does not turn a $120 order into an underpayment.

You redirect the customer to the hosted checkout page. They pick a network they already hold funds on, see the exact amount, a QR code, and the deposit address. halfin watches the chain, applies that chain's confirmation threshold, and credits the payment in a reorg-aware way — a payment shown as confirmed has actually settled under that chain's rules, not just been seen in the mempool.

When the invoice resolves, your server receives an HMAC-signed webhook. That webhook is the source of truth: verify the signature, then mark the order paid and release fulfilment. The customer's redirect back to your success page is for their eyes; the webhook is for your database. If you ever need to return funds, refunds run as a first-class flow against the original invoice rather than an ad-hoc manual send.

• Create an invoice for the order total, anchored in your catalogue currency.
• Rate locks at activation — the customer owes a fixed crypto amount, expiry enforced.
• Redirect to hosted checkout; halfin handles wallet, QR, network choice, and live status.
• Reorg-aware crediting with per-chain confirmation thresholds before a payment is final.
• Signed webhook flips the order to paid; refunds run against the original invoice.

Settlement, conversion, and payouts behind the storefront

Acceptance is only half of a store's money flow. Once payments land in your halfin balances, you decide what they should become. Balance conversion handles treasury rebalancing — automatically on a policy you set, or manually when you want to consolidate a spread of incoming assets into the stablecoin you hold reserves in. A store taking BTC, SOL, and several stablecoins does not have to manage each balance by hand.

On the outbound side, the same account pays your suppliers, marketplace sellers, affiliates, and refunds. Single payouts cover a one-off send to one destination with operator review. Mass payouts batch many destinations into one idempotent run — the same batch submitted twice does not pay twice — which is what a marketplace needs when it settles dozens or hundreds of sellers on a schedule.

For automated commerce — a subscription system, a top-up wallet, a service that bills another service — machine-to-machine settlement moves value programmatically without a human-facing checkout page in the loop. Static deposit addresses give you a persistent receive address per account or customer when you would rather hand out one address than mint an invoice each time.

Where stores reach for halfin

These are the patterns stores reach for most often. Find the one that matches how you already sell, and the rest of this page maps it onto invoices, hosted checkout, and payouts.

• Accept crypto in an online store — add a crypto option to an existing card checkout without replacing your order system.
• USDT and USDC checkout — let customers pay in the stablecoin they already hold, on Tron, Ethereum, Solana, or Base, while you keep prices in fiat.
• No chargebacks — a confirmed on-chain payment is final, removing card-dispute reversals from your revenue.
• Cross-border payments — a customer abroad pays in stablecoins without card-issuer geography rules, currency conversion at the gateway, or a failed international card.
• High-risk merchants — businesses that card acquirers treat as high-risk get a payment rail that does not depend on an acquirer relationship, while keeping their own onboarding and controls.
• Marketplace settlements — collect from buyers, hold balances, then settle sellers in idempotent mass-payout batches.
• Digital goods and downloads — instant, final settlement for software, top-ups, and licences where there is nothing to ship back if a card payment later reverses.

Why no chargebacks changes the economics

Card payments can be reversed weeks after fulfilment. For a store selling digital goods, top-ups, or anything shipped quickly, a chargeback often means the product is gone and the money is clawed back, plus a dispute fee and a hit to the acquirer scorecard that can raise costs or threaten the merchant account itself.

A confirmed crypto payment does not work that way. Once halfin has credited a payment under the chain's confirmation threshold, it is settled — there is no issuer-initiated reversal. That removes a category of fraud and operational overhead from the store. It also shifts responsibility: because the payment is final, the store handles returns and goodwill as deliberate refunds it chooses to issue, using the refund flow against the original invoice, rather than reacting to forced reversals.

This is exactly why digital-goods sellers, software vendors, and high-risk merchants look at crypto first. It is not a discount on payments — pricing is its own conversation — it is a different risk profile, where the store is no longer exposed to the long tail of card disputes on already-delivered goods.

Networks and assets a customer can pay with

The customer pays on a rail they already hold funds on, chosen from the networks you enable. Every option below is a real on-chain gate — there is no placeholder network on the page that quietly does nothing. Stablecoins are the common case for e-commerce because the customer and the store both know the dollar value will not move between checkout and confirmation.

Integrating without ripping out your checkout

The store side stays small. You create an invoice from your order, redirect the customer to the returned hosted checkout URL, and wait for the signed webhook before you mark the order paid. There is no official CMS plugin to install — the integration is the same REST API and hosted checkout regardless of platform, so a custom store and a popular storefront wire it the same way.

Treat the redirect as cosmetic and the webhook as authoritative. A customer can pay and then close the tab before the success redirect fires; the signed webhook still arrives, and that is what should flip the order to paid and release fulfilment. Always verify the webhook signature before acting on it.

curl -X POST https://api.thehalfin.com/api/v1/invoices \
  -H "X-API-Key: $HALFIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount_fiat": "120.00",
    "fiat_currency": "USD",
    "idempotency_key": "order-58213"
  }'

# The fiat amount anchors the order; the customer settles in the
# crypto asset they pick on the hosted checkout page returned in
# the response. Redirect the customer there, then verify the
# signed invoice webhook before releasing the order. See the full
# request and response schema at docs.thehalfin.com.

Compliance: a payment rail, not a licence

A store accepting crypto still owns its own obligations. halfin is payment infrastructure: it collects payments, executes payouts, keeps payment records, and exposes status through dashboard data and signed webhooks. It does not take over the store's customer onboarding, its tax handling, or any approvals required for the goods it sells.

Onboarding to halfin involves KYB — verifying the business behind the merchant account — and the platform operates with AML awareness as a process. The travel rule, which concerns information that travels with certain transfers, is an educational concept to understand as you design flows, not a certificate halfin issues to you. None of this makes halfin a regulator or a substitute for the store's own controls.

For higher-risk segments — adult goods, certain digital services, regions card acquirers avoid — the practical pattern is to keep your own identity checks, your own counterparty and wallet screening, and your own record of which order each invoice and payout belongs to. halfin gives you the payment primitives and the audit trail; the merchant keeps the decisions about who it serves and what it sells.

• KYB onboarding verifies the business behind the merchant account.
• AML awareness is a process, not a status halfin grants.
• Travel rule is described as an educational concept, never a certification.
• Keep your own customer KYC, screening, and per-order records as the source of truth.