No chargebacks: final on-chain settlement for online stores

A card payment can be pulled back weeks after you have shipped the order. The customer opens a dispute, the issuer reverses the charge, and you are out the goods, the money, and a dispute fee — with a scorecard hit that can raise your costs or cost you the merchant account. A crypto payment that halfin has confirmed on-chain does not reverse. Once the network's confirmation threshold is met, the funds have settled and stay settled. That removes forced reversals from your revenue and turns returns into something you decide to do — a deliberate refund against the original invoice — rather than something an issuer does to you.

The problem: a card sale is not final until the dispute window closes

When a card customer pays, the money lands in your account, but the sale is conditional for months. The issuer can claw the charge back on the cardholder's say-so: a stolen card, buyer's remorse dressed up as 'item not received', or plain friendly fraud where the customer got the product and disputed anyway. You are presumed wrong until you assemble evidence and win the dispute, and even a win costs staff time.

For some stores the exposure is structural rather than occasional. Sell digital goods, top-ups, game credit, or anything delivered the moment payment clears, and there is nothing to ship back if the charge later reverses — the value is already in the customer's hands. The chargeback is a clean loss plus a fee.

There is a second cost that outlasts any single dispute. Card networks score your chargeback rate. Cross a threshold and you land in a monitoring program with higher per-transaction costs, mandatory remediation, and the standing risk that your acquirer drops you. For a 'high-risk' category the bar is lower and the relationship is more fragile. The dispute you lose today shapes what you pay — or whether you can accept cards at all — tomorrow.

Why a confirmed crypto payment is final

A crypto transfer settles on the blockchain itself, not inside a card network that can administratively unwind it. There is no issuer in the middle holding a reversal button, and no cardholder-initiated dispute mechanism. Once a payment is confirmed, the value has moved.

halfin's part is to define 'confirmed' honestly. It does not credit an invoice the instant a transaction shows up in the mempool — that transaction could still be dropped or reorganized out. It waits for the per-chain confirmation threshold, and its crediting is reorg-aware: if a chain reorganizes and unwinds a transaction before it was final, that is reflected rather than ignored. So the invoice does not flip to paid until the payment has actually held under that chain's rules.

The practical consequence for the store: when you act on a paid invoice, you are acting on settled money. There is no later 'the issuer reversed it' event waiting in the wings. The asymmetry that defines card payments — money now, possible reversal later — is gone.

• No issuer, so no issuer-initiated reversal — the mechanism that produces a chargeback does not exist.
• Crediting waits for the per-chain confirmation threshold, not a single mempool sighting.
• Reorg-aware crediting — a transaction unwound by a reorg before finality does not falsely mark an invoice paid.
• A paid invoice means the funds settled on-chain and stay settled.

Card chargeback vs. confirmed crypto payment

The contrast is not 'crypto is cheaper' — pricing is its own conversation. It is a different risk profile: who can reverse the money, and when.

Returns still happen — they become a deliberate refund, not a dispute

Removing chargebacks does not remove the legitimate need to give a customer their money back. A customer cancels, a product is genuinely faulty, or you want to make a goodwill gesture. The difference is that the store is now in control of that decision instead of reacting to a reversal it cannot stop.

You handle it through the refund flow, which runs as a first-class action against the original invoice rather than an ad-hoc manual send to whatever address someone pasted into a ticket. Tying the refund to the invoice keeps the audit trail intact: there is a clear record of which order the original payment belonged to and which refund settled against it, which is exactly what your finance team needs at reconciliation and what you want if a customer or a counterparty ever asks you to show your work.

This is the trade the store is actually making. You give up the false comfort that a card 'protects' the buyer with reversals, and in exchange you decide every return on your own terms and timeline. For most stores that is the better deal — the long tail of friendly-fraud disputes on already-delivered goods simply disappears, and the genuine refunds you do want to make are a button you press, not an outcome imposed on you.

• Refunds are issued by you, on your policy, when you decide a return is warranted.
• Each refund runs against the original invoice, preserving the order-to-payment audit trail.
• No issuer deadline or evidence-submission process — you are not defending a case.
• Partial and full refunds are a deliberate action, not a forced full reversal.

Who feels the chargeback relief most

Every store benefits from final settlement, but a few patterns feel it as a step change rather than a nicety. If you recognize your business below, the no-chargeback property is probably the reason crypto is on your roadmap at all.

• Digital goods and downloads — software, licences, e-books, game assets: delivered instantly, with nothing to recover if a card payment later reverses.
• Top-ups and account credit — wallets, in-app currency, prepaid balances: value is in the customer's account the moment it is bought.
• High-risk categories — businesses that card acquirers treat as high-risk live closest to the chargeback-rate threshold and gain the most from a rail with no scorecard.
• Cross-border sellers — international card payments fail and get disputed at higher rates; a confirmed stablecoin payment sidesteps both.
• Low-margin, high-volume stores — where a handful of disputes plus fees can wipe out the profit on a run of legitimate orders.

How it fits your existing checkout

Nothing about this requires you to rebuild your store. You add crypto as a payment option, create an invoice for the order total anchored in your catalogue currency, and send the customer to the hosted checkout page where halfin handles wallet choice, network, the exact amount, and live payment status. The rate locks when the invoice activates, so the customer owes a fixed crypto amount and a moving market does not turn the order into an underpayment.

Your store learns the outcome through one HMAC-signed webhook. Treat the customer's redirect back to your success page as cosmetic and the webhook as authoritative: a customer can pay and close the tab before the redirect fires, but the signed webhook still arrives. Verify its signature, then mark the order paid and release fulfilment. Because that webhook only fires for a confirmed, settled payment, the order you fulfil is one you will not be asked to un-fulfil through a reversal later.

The create call is a single authenticated request. The customer settles in the asset they pick on the hosted checkout page; you reconcile against the fiat figure you billed.

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": "74.00",
    "fiat_currency": "USD",
    "idempotency_key": "order-90412"
  }'

# The fiat amount anchors the order. The customer settles in the
# asset they choose on the hosted checkout page returned in the
# response. Only act on a paid invoice after you verify the signed
# webhook — and once it is paid, it is final, with no card-style
# reversal to come. Full request and response schema at
# docs.thehalfin.com.