Every fiat-anchored invoice we ship looks like a simple thing on the surface: enter $1,000, customer pays the equivalent in USDT or USDC, you book $1,000. The mechanics underneath are not simple, and the difference between getting them right and getting them sloppy is the difference between flat margin and silent leakage.
The four-quadrant problem
Every invoice has to answer four questions, in this order:
- What rate is this invoice priced at?
- When is that rate locked?
- How long before the rate has to be re-quoted?
- What tolerance for slippage does the merchant accept?
The 90-second TTL
Our default time-to-live for the rate window is 90 seconds. Why 90?
- Too short (under 30s): the customer can't actually click "pay" in time, especially on mobile wallets.
- Too long (over 5 minutes): rate drift exceeds the merchant's tolerance for swing on volatile assets.
- Just right (60–120s): the customer has time to confirm, and the merchant's exposure stays inside the natural settlement variance.
90 was the result of running A/B tests across 12 merchant cohorts. The conversion curve flattens above 90s; the FX-loss curve climbs. The crossover is somewhere between 75 and 105.
The TTL is configurable per-merchant. The default is good for most. The default is not law.
What "rate locked" actually means
When the customer activates the invoice, we quote a rate from a weighted average of three liquidity sources. We hold that rate for the TTL. If the customer pays inside the window, we settle at the locked rate.
If the customer pays outside the window because they are late by a few seconds or the payment confirms slowly, we re-quote at settlement. The merchant sees both numbers in the dashboard, and the difference is recorded as a rate_drift line item.
Slippage tolerance
By default we settle if the on-chain amount is within ±0.5% of the locked-rate quote. Outside that band, the invoice goes to a manual review queue.
The 0.5% tolerance accommodates:
- Block fees that the customer's wallet rounds slightly
- Network-level rate volatility for non-stablecoin payments
- Off-by-one rounding in third-party wallets
It does not accommodate:
- A customer paying $980 against a $1,000 invoice (manual review)
- A customer paying $1,500 against a $1,000 invoice (held, refunded if not reconciled)
What we don't do
We don't run a pricing book. We don't take FX risk on behalf of the merchant. We don't subsidize rate drift. The locked rate is the rate; the customer pays it; the merchant receives it.
Anyone who tells you they can lock a rate for 30 minutes without taking risk is lying or running a pricing book. Both are fine, but you should know which.
Operating rule
A fiat-anchored invoice is a four-variable problem. The defaults we ship are the result of running the experiment at scale. The variables are configurable for merchants who know exactly why they're configuring them.
If you're still using "60-minute lock" as your default, you are paying for the privilege.
halfin product team
