Accept USDC across Ethereum, Base, and Solana

Your buyers are USD-native — US businesses, EVM-first treasuries, on-chain teams that already hold a dollar stablecoin and would rather pay in it than wire it. USDC is the asset they reach for. halfin lets you accept it on the three networks where it actually moves at scale — Ethereum as an ERC-20 token, Base for low-cost settlement, and Solana — while you keep pricing in dollars and reconciling against that dollar figure.

What USDC is, and why it suits dollar billing

USDC is a dollar-denominated stablecoin: one unit is intended to track one US dollar. For a merchant that books revenue in USD, that one-to-one anchor removes most of the friction of taking crypto. The number on the invoice and the number that lands on-chain are the same kind of number — dollars — so there is no mental conversion at reconciliation and no rate-watching at month-end.

That makes USDC the natural counterpart to USD-priced invoicing. You quote 49.00 USD; the customer pays roughly 49 USDC; the dollar amount you booked is the dollar amount you settle. The small gap that can appear between a stablecoin and its peg is exactly why halfin still anchors the invoice to fiat and locks the quote at activation — you reconcile against the USD figure you billed, not against whatever the token traded at the second the payment confirmed.

USDC is not a bank, a deposit, or a regulated payment instrument in halfin's copy — it is a dollar-denominated stablecoin, and that is the only claim we make about it. What halfin adds is the rails: detecting the on-chain payment, applying per-chain confirmation thresholds, and crediting your balance in a reorg-aware way.

Three networks, one asset — pick by who is paying

USDC exists on several chains, but halfin accepts it where the deposit gates actually run: Ethereum, Base, and Solana. These are not interchangeable from the payer's point of view — they differ in cost, in the wallets people use, and in how the same dollar of value gets to you. The right answer is usually "whichever one the customer already holds," and an invoice can offer more than one.

Ethereum (ERC-20) is the canonical home for USDC and the path most institutional and EVM-native payers default to. It carries the highest transaction cost of the three, so it suits larger payments where the network fee is a rounding error against the amount.

Base is an Ethereum L2 built for low-cost settlement. The same ERC-20 USDC moves for a fraction of mainnet cost, which makes Base the sensible default for everyday and smaller-ticket dollar payments from EVM wallets. If your buyers are comfortable on Base, steer them there.

Solana settles USDC quickly and cheaply as an SPL token. It suits payers who already live in the Solana ecosystem and want fast, low-fee confirmation. The dollar value is identical; only the rail differs.

How a USDC payment is credited

Accepting a stablecoin is not just reading a balance — it is deciding when an on-chain payment is final enough to act on. halfin handles that per network. A USDC deposit is watched as it appears, then confirmed against the chain's own threshold before the invoice is marked paid, so you are not releasing goods against a transaction that could still be reorganized away.

Crediting is reorg-aware on every supported chain. If a block that carried a payment is unwound by a chain reorganization, that is reflected rather than silently kept — the amount you see as settled is an amount that actually held. Confirmation thresholds are set per chain because finality means different things on Ethereum, on an L2 like Base, and on Solana.

Because the asset is dollar-denominated and the invoice is dollar-anchored, the underpaid and overpaid cases stay legible. If a customer sends slightly less USDC than the invoice expected, the shortfall is recorded against the invoice so you can request a top-up or settle partially under your own policy; if they send more, the excess is recorded and visible instead of vanishing into an unmatched-deposit pile.

• Per-chain confirmation thresholds — Ethereum, Base, and Solana are confirmed against their own finality, not a single global rule.
• Reorg-aware crediting — a transaction unwound by a reorg is reflected, not kept as settled.
• Underpaid and overpaid are first-class — the gap is recorded against the invoice, not discarded.
• Dollar anchor preserved — you reconcile against the USD figure you billed, not the token's spot value at confirmation.

Take a USDC payment with a fiat-anchored invoice

The way you accept USDC is the way you accept any supported asset: create an invoice priced in your fiat currency and let the customer settle in the network they hold. You do not create a "USDC invoice" — you create a dollar invoice, and USDC on Ethereum, Base, or Solana is one of the ways it can be paid. The rate locks at activation, so the payable token amount is fixed for the life of the invoice and a stale quote never re-prices in the background.

Here is a minimal create call against the public API. The amount is a string — monetary values are strings end to end, never floats — and the currency is your fiat anchor. The exact request and response shapes live in the docs and the @halfin/sdk-merchant types; the point here is that one authenticated call gives you a payable invoice that a USDC holder can settle on the network of their choice.

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": "49.00",
    "fiat_currency": "USD",
    "deferred": true,
    "description": "Pro plan — March",
    "idempotency_key": "00000000-0000-4000-8000-000000000001"
  }'

# halfin locks the rate at activation and returns a payable invoice. A USDC
# holder can settle it on Ethereum, Base, or Solana; you reconcile against the
# USD figure. See docs.thehalfin.com for the full request and response schema.

Knowing the payment landed

Once an invoice exists, you track it the same way regardless of which network the USDC arrives on. State changes are observable across the dashboard, the REST API, and signed webhooks, so your backend can fulfill, email, or update records the moment a payment confirms — without polling a block explorer.

The webhook envelope is HMAC-signed. Verify the signature before you take any business action on an event: a verified invoice.paid event is your signal that the USDC payment reached the per-chain threshold and the dollar amount settled to your balance. invoice.underpaid and invoice.overpaid tell you a payment arrived but did not match the expected amount, so you can act on the shortfall or excess deliberately rather than treating it as a failed payment.

USDC alongside the rest of the platform

USDC rarely stands alone. It is one asset on a fiat-anchored invoice that hosted checkout can render for you, or that you can render yourself against the same API. Many merchants pair it with USDT — USDC for US and EVM-native payers, USDT for the regions and exchanges where it dominates — so the same dollar invoice covers both stablecoin audiences without a second integration.

On the settlement side, USDC you take in accrues to a balance you can convert or pay out, and a refund flows back through the refunds primitive. If you want the chain-by-chain view — confirmation behavior, fees, and finality across Ethereum, Base, Solana, and the other supported rails — the networks page is the companion to this one.