What automatic conversion does
Automatic conversion runs at the point a payment is credited to your balance. You choose a target settlement asset — most teams pick a stablecoin — and when an invoice or checkout payment arrives in something other than that asset, the incoming balance is converted toward the target before it settles. The held balance that results is in your reference asset, not in whatever the customer happened to send.
The asset a customer pays with is the customer's choice. The asset you keep should be yours. Automatic conversion is the primitive that makes the second statement true without a daily cleanup step, an exchange round-trip, or a treasury operator watching the balance screen.
It is the conversion mode most teams turn on first, precisely because it removes work rather than adding it. Once a target is set, steady invoice and checkout revenue settles into one asset on its own, and the line items your finance team reconciles stop multiplying across networks and tickers.
Why volatility exposure is the real problem
Accepting many assets is good for conversion at the till and bad for the balance sheet. A week of payments can leave you holding a little BTC, some ETH, a chunk of SOL, and USDT spread across three networks. Each of those is a separate position with its own price, and the volatile ones drift in value between the moment they arrive and the moment you do something with them.
That drift is exposure you did not ask for. You priced and sold something; you did not decide to take a position in ether or solana. Automatic conversion settles the volatile inflow toward a stable reference asset as it lands, so the window where an un-managed asset can move against you is closed at credit time rather than left open until someone reacts to it.
Note the boundary: this is asset-to-asset conversion, not a fiat off-ramp. Settling "in USD" here means settling into a USD-denominated stablecoin such as USDC or USDT — a crypto asset whose value tracks the dollar — not into a bank-settled fiat balance. halfin is digital-asset payment infrastructure; it does not turn your held crypto into money in a bank account.
Setting a target and the route requirement
You set a target settlement asset once, and from then on incoming payments are converted toward it on credit. There is no per-invoice flag to remember and no end-of-day batch to run — the behavior applies to the steady-state revenue stream as it arrives.
Conversion only fires when a supported route exists between the asset received and your target. Routes cover the assets and networks halfin settles, but not every conceivable pair. When no route applies, the incoming asset is credited as-is and stays visible in your balance — nothing is lost, nothing is hidden, and you can convert it later as a manual conversion. That fail-open behavior is deliberate: the system never blocks a legitimate payment because a conversion could not run.
- Set a target settlement asset once; incoming payments convert toward it on credit, with no per-payment action.
- Conversion fires only when a supported route exists between the asset received and the target.
- If no route applies, the original asset is credited untouched and stays available for a later manual conversion.
- A payment is never blocked because a conversion could not run — the asset still credits.
What happens to each incoming asset
The table reads as a routing guide for a single target. Assume a finance team has set USDC as its settlement asset; the rows show how different inflows resolve at credit time. The same logic holds for any supported stablecoin target.
| Payment arrives in | Route to target? | What lands in your balance |
|---|---|---|
| USDC on the same network as the target | Already the target | Credited as-is — no conversion needed |
| USDT on Tron, Ethereum, or Solana | Yes | Converted toward USDC on credit |
| Volatile asset (BTC, ETH, SOL) with a supported route | Yes | Converted toward USDC on credit — exposure closed at settlement |
| An asset with no available route to the target | No | Credited untouched; convert it later as a manual conversion |
Reading the converted result
Automatic conversion is observable the same way the rest of halfin is. You do not poll a separate conversion ledger — you read your balances. Once a payment has settled, the converted result is simply the balance you hold, readable through the same REST API at api.thehalfin.com/api/v1 that you use for invoice and payout state.
Authenticate with an API key in the X-API-Key request header and read the balances endpoint. Each entry reports the asset, the network, and the amount you currently hold. After auto-conversion has settled, the entry you care about is denominated in your target asset. Treat the API balance as the single source of truth for what you hold, and treat conversion as the thing that keeps that number in the asset your team manages.
# Read merchant balances after auto-conversion has settled
curl https://api.thehalfin.com/api/v1/balances \
-H "X-API-Key: $HALFIN_API_KEY"
# Each entry reports asset, network, and the amount you currently hold.
# With a stablecoin target set, settled revenue reads back in that asset.
# Amounts are JSON strings — never parse them as floating-point numbers.Where automatic conversion fits, and where manual takes over
Automatic conversion handles the bulk: high-volume, steady revenue from invoices and checkout that you want settling into one asset with zero effort. It is the default for the part of your treasury that runs on its own.
It is not the tool for judgment calls. Periodic, intentional moves — consolidating leftover assets at month-end, or rebalancing held value toward a specific network before a payout run — are explicit operations you trigger yourself. Those belong to manual conversion and to treasury rebalancing. Most teams run both: automatic for the steady stream, manual for the deliberate moves. The two share one balance and one history, so the result reconciles as a single account rather than two parallel systems.
Like every money movement on the platform, an automatic conversion is recorded against your balance history with provenance. The controls around it are the same controls that apply everywhere on halfin — scoped API keys, operator permissions, and a full audit trail — and nothing beyond signing, permissions, and audit should be read into it as a custody guarantee.