How to convert crypto to a stable settlement asset

You took payment in whatever your customers held — native SOL, ETH on mainnet, USDT on three networks, a little BTC — and now your balance is a mixed bag you have to price and reconcile. The usual ask is "convert it to fiat." This guide shows what halfin actually does for that: convert held crypto into a stable settlement asset, automatically as payments land or manually when you decide. It is also honest about the one thing halfin does not do — turn crypto into a bank balance. That last hop is a fiat off-ramp; it lives outside halfin, and this guide marks exactly where the handoff is.

First, the honest scope: 'to fiat' means a USD-stable asset

Get this straight before you build anything, because it changes the whole flow. halfin is digital-asset payment infrastructure. Balance conversion moves value between the crypto assets you already hold on the platform — it can take the SOL a customer paid with and settle it into USDC, or consolidate USDT scattered across Tron and Ethereum into one position. What it does not do is sell your crypto for dollars and wire them to your bank. There is no fiat off-ramp inside halfin.

So when people say "convert crypto to fiat," what halfin gives you is the part that removes price volatility: settling into a USD-denominated stablecoin like USDC or USDT. Your balance stops drifting with the market and starts reading like a dollar figure your finance team can manage. That is the high-value move for most businesses, because the daily problem is rarely "I need cash in a bank today" — it is "I do not want a week of revenue exposed to BTC's price chart."

The actual bank cash-out — taking that stablecoin and turning it into fiat your bank settles — is a separate step you arrange off-platform: an exchange, an OTC desk, or an off-ramp provider you already use. halfin's job ends at handing you a clean, stable, auditable balance. The rest of this guide builds the in-platform half of that flow and marks exactly where the off-platform half begins.

• halfin converts between crypto assets you hold — it does not cash out to a bank.
• "Convert to fiat" here means settle into a USD-stable asset (USDC / USDT), removing volatility.
• The bank off-ramp is a separate, off-platform step you run after halfin hands you a stable balance.

Step 1 — Decide your reference settlement asset

Every conversion strategy starts with one decision: what asset do you want to hold? Most businesses pick a single USD stablecoin as their reference asset, because it is the one position that lines up with how the books are kept. The asset a customer paid with is the customer's choice; the asset you keep should be yours, and conversion is how you reconcile the two.

Pick the stablecoin and the network with your downstream in mind, not just acceptance. If you mostly pay suppliers and affiliates over Tron, holding TRC-20 USDT means your payout run funds cheaply from the same balance. If your obligations are EVM-native, USDC on Base or Ethereum may fit better. The same logical dollar lives in several places, and where it sits decides what it costs to spend — so choose the place you will actually spend from.

You do not have to pick only one. A common shape is a primary stablecoin for the bulk of revenue plus a second held asset for a specific corridor. The point of this step is to make the decision deliberately, once, rather than discovering at month-end that revenue settled into whatever mix the last hundred invoices happened to produce.

Step 2 — Turn on automatic conversion for steady revenue

Automatic conversion is the path most teams turn on first, because it removes the daily cleanup entirely. You nominate the reference asset you chose in Step 1, and when an invoice is paid in something else, the incoming balance is converted toward that target as part of the credit flow. A customer pays an invoice in native SOL against a USDC target; what lands in your balance is USDC. No manual step, no end-of-day batch to remember, no window where the asset sits un-managed.

There is one behavior to understand so it does not surprise you later: automatic conversion only fires when a supported conversion route exists between the asset received and your target. When no route applies, the original asset is credited as-is and stays fully visible in your balance — nothing is lost or hidden. That fail-open design is deliberate: the system never blocks a legitimate payment because a conversion could not run. You handle the leftover with a manual conversion in Step 3.

Because automatic conversion runs at credit time, it pairs naturally with the rest of your integration. The signed webhook that tells you an invoice was paid, and the balance you read back from the API, already reflect the converted result — you are not stitching a separate conversion ledger onto your accounting. Verify the webhook's HMAC signature before you act on it, as always, then trust that the balance behind it is denominated the way you set.

• Set the target settlement asset once; incoming payments convert toward it on credit.
• A SOL payment against a USDC target lands in your balance as USDC — no manual step.
• No route available? The original asset is credited untouched and waits for a manual conversion.
• Webhooks and the balance API reflect the converted result — no parallel ledger to reconcile.

Step 3 — Use manual conversion for the deliberate moves

Automatic conversion handles the steady stream. Manual conversion is the deliberate counterpart for the moves that are a decision, not a default. Instead of converting every payment as it arrives, you hold balances as received and convert when it suits the business — to consolidate the leftover assets automatic conversion left behind, to fund an upcoming payout run in the right currency, or to act on a treasury decision your team made off-platform.

A manual conversion is an explicit operation: you choose the source asset, the target asset, and the amount, and the platform records the result against your balance with full history. That makes it auditable the same way every other money movement in halfin is — a recorded event with provenance, not an opaque adjustment that appears in your books from nowhere. When finance asks why the USDC balance jumped on the 30th, you can point to the exact conversion that produced it. Teams commonly run both modes together: automatic settles the bulk of revenue with no effort, manual handles the periodic judgment calls — consolidating dust at month-end or rebalancing across networks before a large batch payout. The two are not alternatives; they are the steady-state lane and the manual override of the same primitive.

Step 4 — Rebalance across networks before you pay out

Holding one logical asset still means holding it in specific places. USDT exists as TRC-20, ERC-20, and Solana SPL; USDC exists as ERC-20, Solana SPL, and on Base. Where your stablecoin sits decides what it costs to move it — a Tron payout and an Ethereum payout draw from different balances and carry very different network fees. Convert into the wrong network and you have a dollar you cannot spend cheaply.

Rebalancing is using manual conversion to shift held value toward the asset and network your upcoming obligations need, before you need them. If a payout run will go out over TRC-20 but most of your stablecoin accumulated as ERC-20, address that before the run, not mid-batch. The mistake to avoid is discovering at submission time that the balance is on the wrong rail and the batch stalls because the right liquidity is not where the payout draws from.

Read this as operational predictability, not market timing. Conversion is not a trading desk and this guide is not advising you to chase rates. It is keeping treasury in a deliberate shape — a known settlement asset, positioned on the networks you actually pay and receive on — so the routine money movements fund cleanly instead of reacting to whatever mix last week produced.

Step 5 — Read the converted balance from the API

Conversion is observable the same way the rest of halfin is, which means you reconcile it against the balance you already read — not a separate integration. Balances are read through the REST API at api.thehalfin.com/api/v1, the same place you read invoice and payout state, so your accounting system can see held assets without extra wiring. Treat conversion results as changes to those balances rather than as a parallel ledger you have to merge.

The call below reads your current balances after conversions have settled. Each entry reports the asset, the network it sits on, and the amount you hold. The amounts come back as JSON strings, never floating-point numbers — keep them as strings end to end, and if you do arithmetic on them in your own code, use a decimal library or integer minor units. A converted balance must not round or drift a fraction of a cent because someone parsed it into a JavaScript number.

Make the API balance your single source of truth for what you hold. Webhooks notify you of payment and payout activity; balances reflect the converted result. With both in place the picture is complete: money lands, it settles into your reference stablecoin, and the number your finance team manages is already denominated the way they manage it.

# Read current merchant balances after conversions have settled.
curl https://api.thehalfin.com/api/v1/balances \
  -H "X-API-Key: $HALFIN_API_KEY"

# Each entry reports the asset, the network it sits on, and the amount held.
# Amounts are JSON strings — never parse them as floating-point numbers.
# See docs.thehalfin.com for the full balances response schema.

Step 6 — The bank cash-out: where halfin hands off

This is the step the original question was really asking about, and the honest answer is that it happens outside halfin. Once you hold a clean USD-stable balance, taking that stablecoin and turning it into fiat your bank settles is a fiat off-ramp — selling crypto for fiat and receiving a bank transfer. halfin does not do that. It is digital-asset payment infrastructure, not an exchange or a money-services off-ramp, and pretending otherwise would be the wrong thing to tell you.

In practice the handoff is clean precisely because you converted first. You move the stablecoin to whatever off-ramp you already use — an exchange account, an OTC desk, or a fiat off-ramp provider — and that counterparty does the crypto-to-bank conversion under its own terms and its own compliance. Because halfin gave you a single, stable, auditable asset to move rather than a dozen volatile ones, the off-ramp step is one transfer of one known asset, not a cleanup project.

Treat the boundary as a feature, not a gap. halfin owns the payment rail, the conversion, and a full audit trail up to your held balance; your off-ramp provider owns the bank settlement and the obligations that come with it. None of this is legal, tax, or financial advice — which provider you use, and what rules apply to cashing out where you operate, are decisions for your business and your advisors.