What a fiat-anchored invoice actually is
There are two ways to denominate a crypto invoice. The first is to price it directly in a crypto asset — bill the customer 0.0021 BTC — and accept whatever that turns out to be worth in dollars or euros when it clears. The second is to price it in fiat — bill 100 EUR — and let the system compute how much crypto that is at payment time. The second is a fiat-anchored invoice: the source of truth is the fiat figure, and the crypto amount is derived from it.
Two fields carry that intent. The amount is a fiat amount and the currency is a fiat currency, so the invoice always represents a fixed fiat sum regardless of which asset or network the customer chooses to pay with. The payable crypto amount is then quoted from the live market rate and pinned, so the customer sees a concrete crypto figure rather than one that drifts while they reach for their wallet.
The defining feature is the rate lock. When the invoice is activated, the fiat amount is converted to the payable crypto amount at the current rate and that rate is frozen for the life of the invoice. The customer pays the locked crypto amount; the merchant is owed the fiat amount. Movement in the market rate between activation and payment is absorbed by the system, not by either party to the sale.
Why it matters for a merchant
Crypto prices move. If an invoice were denominated in the asset itself, the merchant would be taking a position on that asset for as long as the invoice stayed open — a 100 EUR sale could clear as 96 or 104 EUR of value depending on where the market went in the minutes before the customer paid. That is foreign-exchange and price risk bolted onto a routine transaction, and it makes reconciliation and accounting awkward.
A fiat-anchored invoice removes that. The merchant quotes, sells, and books the same fiat figure they would on any other payment method. The crypto amount the customer transfers is the implementation detail, not the price. Because the figure recorded against the sale is the fiat amount, ledgers, refunds, and reporting all line up with how the business already thinks about money.
It also keeps the invoice quotable to the customer. Locking the rate at activation means the customer is shown an exact crypto amount to send, with a clear expiry, instead of a target that keeps moving. That removes a common source of underpayment — a customer sending an amount that was correct a few minutes ago but no longer covers the bill.
Fiat-anchored invoices on halfin
halfin invoices are fiat-anchored by design. You set a fiat amount and a fiat currency; halfin maps that to the payable crypto amount using the live rate and locks the rate when the invoice activates. The invoice carries an expiry, after which an unpaid invoice lapses and a new rate would be needed. The customer pays in whichever supported asset and network they hold, and every payment settles back to the fiat figure you billed.
Settlement is built around the same anchor. Crediting is reorg-aware and respects each chain's confirmation threshold before the invoice is marked paid, and halfin distinguishes the outcomes that matter for a fiat figure: an invoice can be paid exactly, underpaid, or overpaid against the locked amount, and your webhooks reflect which of those happened. Because the bill is a fiat sum rather than a crypto sum, those comparisons are made against the amount you actually quoted.
Downstream, everything stays anchored to that figure. Native assets and stablecoins credit into one balance, each payment reconciled against the fiat amount you billed, and from there you can convert between assets, send funds out through single or mass payouts, or return money to a customer through refunds — all reconciled to the fiat numbers your books already use.
- Denominated in fiat — a fiat amount in a fiat currency is the source of truth, not the crypto amount.
- Rate locked at activation — the payable crypto amount is fixed for the life of the invoice, so the customer sees an exact figure.
- Merchant books the fiat figure — price swings between activation and payment are absorbed by the system, not the sale.
- Underpaid / overpaid handling — payment is compared against the locked amount, with the outcome surfaced in webhooks.