Why a customer pays USDC on Solana
If a customer's USDC lives on Solana, asking them to move it to Ethereum before they can pay you is friction you don't need. They would have to bridge the token, pay to do it, and wait — and every one of those steps is a place the payment can stall or fall apart. Accepting USDC natively on Solana lets that customer pay from the wallet they already have open, with the dollar balance they already hold, in one transfer.
Solana's appeal for a dollar payment is speed and cost. The network settles transfers quickly, and a small SPL transfer carries a low network fee, so a customer paying a modest invoice isn't watching a confirmation crawl or losing a noticeable slice of the payment to fees. For a merchant whose audience skews toward the Solana ecosystem — on-chain apps, trading tools, anything where the customer is already transacting on Solana — this is the rail a meaningful share of that volume will arrive on.
USDC itself is a dollar-denominated stablecoin: one unit is intended to track one US dollar. You are not taking a position on its price. On Solana specifically, you get that dollar-stable unit as an SPL token on a fast, cheap rail — which is exactly what a Solana-native payer reaches for when they want to spend dollars on-chain. halfin treats it as a settlement asset, never a speculative one, and anchors your invoice to the fiat amount so any small live drift between the token and its peg is halfin's problem to map, not yours to absorb at reconciliation.
How halfin handles an SPL USDC payment
You don't run a Solana-specific integration. Accepting USDC on Solana is the ordinary halfin invoicing flow: you create a fiat-anchored invoice, and SPL USDC is one of the networks the customer can settle it on. halfin generates the Solana deposit address, watches the chain for the payment, and credits it once it has held to Solana's confirmation threshold.
Crediting is reorg-aware. halfin does not treat a freshly-seen transfer as final the instant it appears — it waits for Solana's per-chain confirmation threshold before the invoice is marked paid, so a transaction that is later unwound is reflected rather than counted prematurely. The figure you fulfill against is one that actually stuck.
Because the invoice is anchored to fiat and the asset is dollar-denominated, the number on the invoice and the number on-chain are the same kind of number — dollars. halfin maps your USD figure to the payable SPL USDC amount and locks it when the invoice activates, so the amount the customer is shown to send doesn't drift while they open their wallet and confirm. The dollar amount that lands in your ledger is the dollar amount you billed, not a raw token figure you have to convert later. Underpaid and overpaid cases stay legible: a shortfall is recorded against the invoice so you can request a top-up or settle under your own policy, and an overpayment is recorded and visible rather than vanishing into an unmatched-deposit pile.
- Fast settlement — Solana clears transfers quickly, so a payer isn't waiting on a slow confirmation.
- Low network fees — a small SPL transfer stays cheap for the payer, protecting completion rates on low-ticket dollar payments.
- Reorg-aware credit — the invoice is marked paid only after Solana's confirmation threshold, not on first sight.
- Dollar anchor preserved — you reconcile against the USD figure you billed, not the token's spot value at confirmation.
Solana next to the other USDC rails
USDC on halfin settles on three networks, and Solana is one choice among them. They are the same dollar token issued on different chains and are not interchangeable mid-payment — a payment sent on Solana arrives on Solana. The table below places SPL next to the other two so you can see what picking it actually means, and what a customer who holds USDC elsewhere would use instead. The dollar value is identical across all three; only the rail differs.
| Network | Token standard | Character | Reach for it when |
|---|---|---|---|
| Solana | SPL | Fast, low-fee settlement. | Payers already holding USDC in the Solana ecosystem. |
| Base | ERC-20 (Base L2) | Low-cost settlement on an Ethereum L2. | Everyday and smaller-ticket dollar payments from EVM wallets. |
| Ethereum | ERC-20 | Most broadly integrated; variable network fees. | EVM-native or institutional payers holding USDC on mainnet. |
Take an SPL USDC payment with one API call
There is no Solana-specific endpoint. You post a fiat amount and currency to the public REST API with a scoped API key, and halfin returns a payable invoice the customer can settle in USDC on Solana — alongside the other supported networks — through hosted checkout or a checkout you render yourself. You don't pin the network when you create the invoice; the customer chooses Solana at the point of payment, and a Solana-native payer simply sends from the wallet they already use.
Below is a minimal create call. The amount is a string — monetary values are strings end to end, never floats — and the currency is your fiat anchor. The only request headers are X-API-Key and Content-Type. The idempotency_key field in the request body makes a retried request safe: the same key never creates a second invoice. Track the invoice through signed webhook events such as invoice.confirming and invoice.paid, and verify the HMAC signature before acting on any of them. The exact response fields are defined in the docs and the @halfin/sdk-merchant types.
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": "30.00",
"fiat_currency": "USD",
"deferred": true,
"description": "Credits top-up — USDC accepted",
"idempotency_key": "00000000-0000-4000-8000-000000000003"
}'
# halfin locks the rate at activation, pins the payable USDC amount, and
# returns an invoice the customer can settle as SPL USDC on Solana among
# the supported networks. Watch invoice.confirming then invoice.paid via
# signed webhooks; verify the HMAC signature before acting. Full response
# schema at docs.thehalfin.com.Paying out USDC on Solana, not just accepting it
Solana's speed and low fees cut the other way too. If you owe a stablecoin to a partner, affiliate, or supplier on Solana, single and mass payouts send USDC back out as an SPL transfer — and the same per-transfer economics that make Solana attractive to your customers make it attractive for disbursing. A mass payout batch is idempotent, so a retried batch doesn't double-send.
If a customer is owed money back, refunds return value on a supported rail. And a balance that arrived as SPL USDC does not lock you into SPL USDC — balance conversion lets you rebalance into another asset or onto another network when your treasury needs it, so receiving on Solana does not commit you to disbursing on Solana. Many merchants pair USDC for US and EVM-native payers with USDT for the regions and exchanges where it dominates; on Solana you can take both stablecoins on the same fast rail under one fiat invoice, without a second integration. Accepting, refunding, paying out, and converting all run against the same fiat-anchored balance, so SPL USDC sits in the same ledger as USDC on Ethereum and Base, the USDT rails, and the native chain assets.