First, the thing that does not change: it is the same dollar
It is worth being precise, because the naming invites confusion. USDC on Ethereum and USDC on Base are the same stablecoin — a dollar-pegged token — issued natively on each network. A customer paying you 50 USDC on Base and a customer paying you 50 USDC on Ethereum are sending the same value; the fiat anchor on your invoice does not move because of which rail they chose. What differs is the road the payment travels, not the cargo.
That matters for how you reason about the choice. You are not picking between two assets with different prices or different risk; you are picking between two settlement rails for one asset. So the comparison is entirely operational: confirmation feel, the gas your customer pays to send, and which wallets and balances can reach you. Get those three right and the dollar takes care of itself.
A second clarifier: Base is an Ethereum Layer 2, not a separate chain in the way Solana or Tron are. It settles back to Ethereum and speaks the same EVM, so addresses look the same shape and the same wallet software handles both. But an address that holds USDC on Base cannot be paid on Ethereum, and vice versa — the network is part of where the money lives. On halfin, the invoice names the network alongside the asset for exactly this reason.
The three axes a merchant actually feels
Ignore the chain-maximalist arguments. From behind a checkout, the difference between these two rails comes down to three practical things: how the payment confirms, what it costs the customer to send, and how broadly the rail is reachable. The table frames each rail on those axes qualitatively — halfin does not publish fee numbers, and network gas is a property of the chain, not of halfin.
Read the table as 'what does the customer experience, and what does that imply for my flow', not as a scoreboard. Neither rail is wrong. Ethereum is the most universally supported and the one every serious EVM wallet reaches; Base is the same EVM experience optimized so the gas to move a stablecoin is a low-cost characteristic of the L2 rather than a deterrent.
| Axis | USDC on Ethereum (mainnet) | USDC on Base (L2) |
|---|---|---|
| What it is | USDC issued natively on Ethereum, the original ERC-20 rail. | USDC issued natively on Base, an Ethereum Layer 2. |
| Network fee characteristic | Mainnet gas; the cost to send rises and falls with Ethereum demand. | Built as a low-cost rail — sending a stablecoin is cheap relative to mainnet. |
| Confirmation feel | Per-chain confirmation threshold on mainnet; deliberate, not instant. | Faster, lower-cost transfers; still credited under a per-chain threshold. |
| Reach | Reachable by essentially every EVM wallet and exchange withdrawal. | Growing support; every modern EVM wallet, but not yet everywhere mainnet is. |
| Best when the payer… | Already holds USDC on mainnet or withdraws from an exchange to Ethereum. | Already lives on Base or is cost-sensitive on smaller amounts. |
When Ethereum mainnet is the right rail to accept
Ethereum is the lowest-friction rail for reach. If your customers fund payments by withdrawing from a large exchange, mainnet USDC is the path most of those withdrawals take by default, and the address you give them is one their wallet has handled a thousand times. For larger payments — where the network fee to send is a small fraction of the amount and reliability matters more than shaving cents — mainnet is the unremarkable, safe choice.
The trade you are accepting is gas. On a busy day, sending USDC on Ethereum costs the customer more than sending it on Base, and on a small payment that cost is proportionally annoying — a customer paying you a modest amount may balk at a network fee that feels large next to the total. That is a customer-experience tax on small tickets, not a halfin cost, but it is real and it is the reason Base exists.
- Larger ticket sizes where the network fee is immaterial next to the amount.
- Customers who withdraw from exchanges that default to Ethereum mainnet.
- Maximum wallet and tooling compatibility with the least explanation needed.
- You value 'it just works everywhere' over squeezing the per-transaction cost.
When Base is the right rail to accept
Base earns its place on small and frequent payments. Because it is built as a low-cost L2, the gas a customer pays to send USDC is a minor characteristic rather than a deterrent, so a small payment does not arrive with an outsized fee attached. If you run a high-volume, low-average-ticket flow — a SaaS plan, a creator tip, a marketplace micro-settlement — Base keeps the customer's send cost from eating into a payment that was small to begin with.
It is also the same EVM experience your Ethereum-savvy customers already know. The wallet UI is familiar, the address shape is familiar, and a payer who lives on Base can settle without bridging back to mainnet first. The one caveat is reach: Base support is broad and growing among modern wallets, but it is not yet as universal as mainnet, so a customer on an older or exchange-bound setup may not have a Base balance to pay from. That is precisely why you do not have to choose.
- High-volume, low-average-ticket flows where send cost matters proportionally.
- Customers who already hold USDC on Base and would rather not bridge.
- EVM-native payers who want a familiar wallet flow at a lower network cost.
- You want a cheap rail to send on without leaving the USDC stablecoin.
The real answer: accept both on one invoice
The framing 'Base or Ethereum?' assumes you have to commit a whole storefront to one rail. You do not. A halfin invoice carries a single fiat-anchored amount, and it can present more than one supported network and asset; the customer settles in whichever one they actually hold. Offer USDC on both Base and Ethereum and the customer with a mainnet balance pays on mainnet, the customer who lives on Base pays on Base, and your books see the same dollar figure either way.
This is the durable answer because it removes the bet. You are not predicting which rail your customers prefer and stranding the ones who guessed differently; you are letting each payer use the rail their value already sits on. The fiat anchor stays fixed regardless of the network chosen, so reconciliation is identical whether a given payment came in over Base or Ethereum — you match the confirmed amount back to the figure you billed, tagged with the asset and the network it arrived on.
Create the invoice with the fiat amount and currency and let halfin compute the payable USDC; the customer then selects their rail at the point of payment. The minimal create call below is the same call you already use for any fiat-anchored invoice — there is no separate endpoint per network. Amounts are sent as strings end to end, never floats, and an idempotency_key in the body makes a retried request a no-op rather than a duplicate invoice.
# One fiat-anchored invoice; the customer chooses USDC on Base or Ethereum
# at payment time. The fiat anchor is the source of truth either way.
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": "50.00",
"fiat_currency": "USD",
"deferred": true,
"description": "Pro plan — June",
"idempotency_key": "00000000-0000-4000-8000-000000000002"
}'
# halfin locks the rate at activation, pins the payable USDC amount, and
# presents the supported rails the customer can settle on. A confirmed
# payment maps back to this 50.00 USD figure regardless of the network.
# See docs.thehalfin.com for the full response schema.Pin a single rail only when you have a reason to
There are cases where you do want to constrain the network rather than offer both. If your own treasury operations are simpler holding USDC on exactly one rail — because that is where your payout flow or your conversion routing expects it — pinning the invoice to that network keeps everything on one rail end to end and avoids you accumulating dust balances on a chain you do not otherwise touch.
When you do pin, name the network explicitly on the invoice and make sure your checkout copy tells the customer which rail to send on. The most common avoidable support ticket on EVM stablecoins is a customer sending USDC on the network you did not ask for — the funds are real but they landed on a rail your invoice was not watching. Being explicit about 'USDC on Base' versus 'USDC on Ethereum' at the moment of payment prevents the mismatch before it happens.
- Pin when your payout or conversion flow expects USDC on one specific rail.
- Pin to avoid scattering small balances across networks you don't otherwise use.
- Whenever you pin, state the network in the checkout copy, not just the invoice.
- Default to offering both unless one of the above gives you a concrete reason.
What stays the same across both rails
Whichever rail a payment arrives on, the parts of halfin you build against do not change. Crediting is reorg-aware and respects each chain's confirmation threshold, so a USDC payment on Base and one on Ethereum are both marked paid only after the network-appropriate depth — you are never acting on an optimistic first-seen on either rail. Underpaid and overpaid amounts are tracked the same way on both networks, so a customer who sends slightly too little on Base surfaces exactly as one who does it on Ethereum.
The integration surface is identical too. The same signed webhook events — invoice.confirming, invoice.paid, invoice.underpaid, invoice.overpaid, invoice.expired — fire regardless of the rail, and your handler verifies the HMAC over the raw bytes before acting in both cases. You write the payment flow once; the rail is a detail in the payload, not a fork in your code. That is the whole point of accepting both: more reach for your customers, no extra branches for you.