Accept Solana payments — SOL and SPL stablecoins

Solana is the rail customers reach for when they want a transfer to land in seconds without paying a noticeable network fee. halfin accepts native SOL and SPL tokens — including USDC and USDT issued on Solana — so a payer who keeps their balance in a Phantom or Solflare wallet can settle an invoice in one tap. You still bill in dollars, the rate still locks at activation, and the deposit is still credited only after Solana confirms it.

What you can accept on Solana

Solana is a single-chain account model, not an EVM clone, so the asset list is shaped by it. There is one native coin — SOL — and everything else is an SPL token: a mint deployed on Solana with its own address, held in a per-owner token account. halfin runs a real Solana gate, which means it watches for both native SOL transfers and the SPL token transfers that matter for stablecoin billing.

For most merchants the stablecoins are the headline. USDC and USDT both have first-party SPL mints on Solana, and a payer holding either can settle a fiat-anchored invoice directly — no bridging, no wrapping, no detour through another chain. SOL itself is accepted for customers who would rather pay from their native balance, and the invoice still resolves to the dollar amount you billed.

One thing to keep clear: the same ticker can live on more than one chain. USDC on Solana is a different mint from USDC on Ethereum or Base, and a payer has to send the one your invoice is scoped to. halfin presents the network alongside the amount and address so the customer is told plainly which rail to use — sending the right token on the wrong chain is the most common way a self-directed crypto payment goes missing, and the checkout exists to head that off.

• SOL — Solana's native coin, paid from the customer's main wallet balance.
• USDC on Solana — a dollar-denominated stablecoin, issued as an SPL mint.
• USDT on Solana — the SPL build of Tether, for payers who already hold it there.
• Other SPL tokens settle through the same gate; stablecoins are the common case.

Fast, low-fee settlement — and why that helps the checkout

Speed and fee are properties of the Solana network, not a halfin rate — but they change how a payment feels for your customer. A Solana transfer confirms quickly and costs a fraction of a cent in network fee, so a payer is not watching a spinner for ten minutes or deciding whether the gas is worth it. For a checkout, that lands as fewer abandoned payments: the window between "I clicked send" and "the invoice says paid" is short.

The low fee matters most on small-ticket payments. On a high-fee chain, a few-dollar invoice can carry a network cost the customer resents; on Solana that friction largely disappears, which makes it a sensible default rail to offer for low-value top-ups, micro-purchases, and pay-per-use flows. None of this is a claim about what halfin charges — pricing is separate and qualitative. It is a claim about the chain your customer is paying on.

halfin does not turn that speed into a shortcut on safety. A fast confirmation is still a confirmation, and crediting waits for Solana's per-chain threshold before an invoice is marked paid. You get the perceived speed without crediting money that has not actually settled.

Confirmations and reorg-aware crediting

Every chain has a different idea of "final," and halfin applies a per-chain confirmation threshold rather than a single universal number. A deposit on Solana progresses from seen on the network, through accumulating confirmations, to credited once the Solana-appropriate threshold is met. Until then the invoice is explicitly in flight, not paid — so your fulfillment logic never releases goods against an unconfirmed transfer.

Crediting is reorg-aware across every gate, Solana included. If the network reorganizes and unwinds a transaction that had been seen, halfin reflects that rather than leaving a phantom credit on the books. The amount you see as settled is an amount that held. The table below sets Solana next to the other rails halfin runs so you can see where it sits on speed and finality.

Bill in fiat, let the customer settle in SOL or an SPL stablecoin

You price in dollars; your customer pays in whatever they hold. A halfin invoice carries the fiat amount you actually care about and the payable token amount derived from it, and the rate locks when the invoice activates — not when you draft it. A customer who pays in SOL inside the payment window settles the exact token amount they were shown; the dollar figure that reconciles to your ledger is the one you billed.

Stablecoins on Solana shorten that path even further. Because USDC and USDT are already dollar-denominated, a USD-anchored invoice paid in Solana USDC moves a near-identical amount, with the rate lock absorbing only the small spread. SOL, being a volatile asset, is where the activation-time lock earns its keep: the payable SOL amount is pinned for the life of the invoice, so neither you nor the customer is exposed to a price move between presentation and payment.

Underpaid and overpaid amounts are handled as first-class outcomes rather than silent failures. If a customer sends slightly less SOL than quoted — a stale quote, an exchange withdrawal fee — the invoice records the shortfall so you can request a top-up or settle partially under your own policy. An overpayment is recorded too, visible and accountable instead of disappearing into an unmatched-deposit pile.

• Rate locks at activation — the payable SOL or SPL amount is fixed, not recalculated mid-payment.
• Bounded expiry — every invoice has a payment window, so a stale Solana quote never settles.
• Underpaid / overpaid amounts are recorded against the invoice, never stranded.
• USDC and USDT on Solana keep a USD-anchored invoice close to a one-to-one transfer.

Where Solana fits in a halfin integration

Adding Solana is not a separate integration. A Solana invoice is the same invoice object as any other, so the network is something the customer selects on the payment page rather than a parallel code path you maintain. Hosted checkout renders the SOL or SPL invoice — address, amount, network, and countdown — and handles the wallet-side detail, including the SPL token-account nuance that trips up hand-rolled flows. If you render your own UI with self-hosted checkout, you read the same fields off the same API.

State changes reach your backend the same way they do for every chain: a signed webhook fires when an invoice activates, is paid, comes in under or over, or expires. Verify the HMAC signature before you act on a Solana payment, then fulfill, email, or update your records. Settled balances — whether they arrived as SOL, Solana USDC, or any other asset — accrue to a balance you can convert or pay out, and a refund flows back through the refunds path. The single fiat-anchored primitive plugs Solana in without re-modeling money for the chain.

Create a Solana-payable invoice with one call

Invoicing is spec-first REST. You authenticate with a scoped API key and post the fiat amount and currency; halfin computes the payable asset amount and returns an invoice you can present through hosted checkout or render yourself. Pass an idempotency key so a retried request never creates a duplicate invoice.

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 customer then chooses Solana on the payment page. The exact request and response fields are defined in the docs and the @halfin/sdk-merchant types — treat docs.thehalfin.com as the schema source of truth rather than the shape implied here.

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": "25.00",
    "fiat_currency": "USD",
    "deferred": true,
    "description": "Wallet top-up",
    "idempotency_key": "00000000-0000-4000-8000-000000000001"
  }'

# halfin locks the rate at activation and returns a payable invoice.
# The customer picks Solana on the checkout and pays in SOL or an SPL
# stablecoin (USDC / USDT). Track it via signed webhook events.
# See docs.thehalfin.com for the full request and response schema.