Accepting Ethereum means letting a customer pay in ETH from their own wallet while you receive the funds on your merchant balance. This guide is for the merchant who has to decide which network to switch on, how much a transfer actually costs on a given day, and how long to wait before releasing an order. You get network-selection rules, a dated on-chain cost measurement, and confirmation depth tied to order size — not a list of who accepts ETH.
Who pays in ETH, and why they’re your customer
Ethereum holders are one of the largest funded-wallet segments in crypto: ETH sits at rank two by market capitalisation, and a wallet holding ETH already carries a spendable balance and a paying habit. When you turn on ETH, you open the door to buyers who hold the asset directly and would rather spend it than convert to card first.
Two things are worth knowing before you build a page around it. First, most people asking what can I buy with ethereum are looking for places that already take it, so a checkout that visibly supports ETH is itself the answer to that search. Second, the same wallet that holds ETH usually holds stablecoins on the same network — the buyer can pay in USDT or USDC over Ethereum instead. That gives you a second rail on identical infrastructure, which matters later when the exchange-rate question comes up.
The buyer profile shapes the two things that follow in this guide. Someone paying from an ETH wallet is comfortable with an on-chain transfer and expects it to settle in seconds to minutes, not the days a card refund takes — so the friction you’re removing is conversion, not speed. And because they can switch between ETH and a stablecoin on the same network without changing wallets, the decision of which to accept sits with you and your pricing, not with a technical limit. Neither point holds for a buyer arriving with a card, which is why an ETH checkout is designed around a different set of defaults.
The practical read: ETH acceptance widens the funded-buyer pool, and it comes bundled with a stablecoin option on the same chain at no extra integration. You are switching on a network, not a single coin.
Mainnet or Layer 2: where to accept
Accept ETH on the network your buyer already uses, and let the order size decide the default. Speend routes Ethereum acceptance over Ethereum mainnet plus three Layer-2 networks — Polygon, Arbitrum, and Base. Mainnet is the universal rail every wallet reaches; Layer 2 is the cheaper, steadier lane for high-frequency or small-ticket checkouts.
Mainnet is the safe default because every ETH wallet can reach it without bridging. On mainnet a native ETH transfer confirms in roughly one to three minutes, and settlement is final once the block is buried under enough confirmations (covered below). The trade-off is that mainnet fees track network demand: cheap when the chain is quiet, several times higher during a congestion spike, and you cannot predict at checkout which one your buyer will hit.
A Layer-2 network settles transactions off the main chain and posts them back in batches, which collapses the per-transfer fee and — the point that matters more — flattens its variance. On Base, Arbitrum, or Polygon a transfer costs a fraction of a cent whether the network is quiet or busy. For a subscription box, a top-up wallet, or any checkout doing many small orders, that predictability is worth more than shaving the last fraction of a cent off an already-cheap mainnet median.
Rule of thumb by ticket size:
- Small, high-frequency orders (sub-$50, many per day): default to a Layer 2. The fee is negligible and, more importantly, it stays negligible under load.
- Occasional or large orders: mainnet is fine — the fee is a rounding error against the order value, and you avoid asking the buyer to hold funds on an L2 they may not use.
- B2B invoices where the client already holds ETH or USDT on mainnet: accept on mainnet and skip the bridge friction entirely.
You do not have to choose one network for the whole store. Speend surfaces the available networks at checkout and the buyer picks the one their wallet is on, so the same product can settle over mainnet for one customer and Base for the next.
What a transfer really costs
An ERC-20 transfer on Ethereum mainnet had a median cost of about $0.015 on 4 September 2026, but under a load spike the same transfer ran to roughly $0.34 — a twenty-fold gap inside a three-hour window. That spread, not the headline level, is the real cost story for a merchant. The median is trivial; the ceiling is what breaks a same-price-at-checkout promise.
Here is the measured window. Method: eth_gasPrice and eth_feeHistory over 1,024 blocks (base fee plus priority at the 50th and 90th percentile) on public RPC endpoints; spot ETH ≈ $2,521, dated 4 September 2026.
| Network | ERC-20 transfer (~65k gas), median | Under load (p90) | Native transfer (21k gas) |
|---|---|---|---|
| Ethereum mainnet | ≈ $0.015 | ≈ $0.34 | ≈ $0.005 |
| Base (L2) | ≈ $0.001 | — | ≈ $0.0003 |
| Arbitrum One (L2) | ≈ $0.003 | — | ≈ $0.001 |
| Polygon | ≈ $0.002 | — | ≈ $0.0005 |
The number behind the spread: mainnet base fee held steady across the window (median 0.071 gwei, p90 0.092), but the effective gas price including priority reached 2.08 gwei at p90 — about twenty times the median. When the chain is contended, buyers bid priority fees to get included, and that bidding, not the base fee, is what moves the cost. On a Layer 2 there is no comparable bidding war, so the fraction-of-a-cent figure holds regardless of load.
For context beyond a single measurement: CoinPaprika’s gas analysis of 27 January 2026 put average Ethereum gas near 0.5 gwei — down about 93% year-on-year — with mainnet transfers landing in a $0 to $0.33 band and Layer 2 near $0.001. Different day, same shape: a low floor and a ceiling several times higher.
One detail in the table is easy to miss and worth acting on. A native ETH transfer costs about a third of an ERC-20 transfer at the same moment — roughly $0.005 against $0.015 on mainnet — because it burns 21,000 gas instead of the ~65,000 a token transfer needs. In practice the buyer’s wallet decides this, not you: someone paying in ETH sends a native transfer and pays the lower figure, while someone paying in a stablecoin sends an ERC-20 transfer and pays the higher one. It’s a reason the fee gap between ETH and a stablecoin on the same network runs the opposite way to what people expect — the volatile asset is the cheaper one to move.
Two practical consequences follow. On mainnet, quote the buyer a total that already covers the network fee rather than exposing raw gas, because the figure they see at 3 a.m. and the figure at a congestion peak will not match. And if you run enough volume that even rare spikes add up, a Layer 2 removes the variance from the equation instead of just lowering the average. On Speend the network fee passes through at blockchain cost with no markup, so what you optimise is which chain the fee is denominated on, not a platform surcharge.
Why Ethereum fees spike when they do
Ethereum fees rise when block space is contested, not on a fixed schedule. Each block holds a limited amount of computation, priced in gas; when more transactions want in than fit, senders raise the priority fee they’ll pay a validator to be included first. A quiet chain clears at the base fee alone — hence the copeck-level median. A busy one turns inclusion into an auction, which is why the same transfer can cost twenty times more three hours later. This is also why a Layer 2, which batches transactions off the main chain, escapes the auction: it isn’t competing for the same scarce block space.
How long to wait: confirmations by order size
Match confirmation depth to order value: release small orders on the first confirmation, hold large ones deeper. A confirmation is one block mined on top of the block that contains the payment; each additional block makes a reversal exponentially less likely. Waiting is a risk decision, not a fixed rule — the cost of a reversed cheap order is trivial, the cost of a reversed five-figure one is not.
For how many confirmations to require, scale the depth to what a reversal would cost you:
Want to accept crypto payments on your website?
Fast setup and KYC/KYB, fee starts from 0.5%
Contact Us| Order size | Confirmations to wait | Rough time on Ethereum mainnet |
|---|---|---|
| Under ~$100 (digital goods, top-ups) | 1 | ~15–45 seconds |
| ~$100–$1,000 | 2–3 | ~1–2 minutes |
| ~$1,000–$10,000 | 6+ | ~2–3 minutes |
| Above ~$10,000 | 12+ | ~3–5 minutes |
The times are short because Ethereum produces a block roughly every 12 seconds and reaches economic finality quickly; the depth, not the wait, is what protects a large order. Layer-2 confirmations arrive faster still, though for a high-value settlement many merchants wait for the transaction to finalise on the underlying chain rather than trusting the L2’s own soft confirmation.
You don’t manage this by hand. Speend’s checkout tracks the payment through its lifecycle — seen, confirming, paid — and only marks the order paid once the required depth is reached, so the confirmation rule runs on your behalf against whatever threshold you set.
ETH or a stablecoin on the same network
Take ETH when the buyer wants to spend ETH; steer toward a stablecoin when the price between checkout and settlement matters to either side. Both settle over the same Ethereum network with the same wallets and the same confirmation mechanics — the only difference is whether the amount is denominated in a volatile asset or a dollar-pegged one.
ETH’s price moves. Between the moment a buyer confirms an order and the moment the payment finalises, the ETH amount is fixed but its dollar value can drift. Over a minute or two on a small order that drift is noise. On a large invoice, or in a market that ran 30% in a month, it’s a real number someone absorbs. A USDT or USDC transfer on Ethereum removes that drift entirely: the buyer sends dollars-on-chain, you receive dollars-on-chain, and the ERC-20 transfer confirms in the same one-to-three-minute window as native ETH.
If you’d rather accept ETH but hold a stable balance, Speend can auto-convert incoming ETH into a stablecoin the moment it lands. That conversion carries a 1% fee on ETH (it is not free the way a Bitcoin-to-stablecoin conversion is on Speend), so treat it as a deliberate choice: pay 1% to close the exchange-rate window, or hold ETH and carry the price exposure yourself. For a merchant who prices in fiat and doesn’t want a crypto treasury position, the 1% is usually cheaper than the swing it removes.
The decision in one line: same network, same speed, different risk. Take ETH from buyers who hold ETH; convert or accept stablecoins when the dollar figure has to hold.
How the payment looks and what happens to the rate
A buyer picks Ethereum at checkout, gets a payment request with an address and a locked amount, and sends from their wallet; the rate is fixed the moment that request is created. From there the outcomes are few and the system handles each one, so nobody has to reconcile a mismatch by hand.
The rate lock is the part merchants ask about most. When Speend generates the payment, it converts your fiat price to an ETH amount at that instant and holds it for the life of the invoice — a window you set, from one hour up to twelve, with two hours as the default. The buyer sees a fixed ETH figure to send. If ETH moves during that window, the buyer still owes the quoted amount, so the price you set is the price you get, provided they pay before the invoice expires.
Three edge cases cover almost everything that goes wrong at a crypto checkout, and each has a defined path:
- Underpayment — the buyer sends less than the invoice. The order waits for the remainder rather than completing, and the buyer can top up to the full amount.
- Overpayment — the buyer sends more. The order is marked paid and the surplus is credited; no order stalls because someone rounded up.
- Expiry — the invoice window closes before payment arrives. The request is cancelled and any reserved stock is released, and the buyer starts a fresh request at the current rate.
For a store on WooCommerce this runs through the Speend plugin: the customer stays on your checkout, the plugin talks to Speend over webhooks, and order status updates automatically as the payment moves from seen to confirmed to paid. You configure the invoice lifetime and the confirmation threshold once; the checkout applies them to every ETH order after that.
FAQ
Which network should I accept ETH on — mainnet or Layer 2?
Default to a Layer 2 (Base, Arbitrum, or Polygon) for small, high-frequency orders, where the fee is a fraction of a cent and stays there under load. Use mainnet for occasional or large orders and for B2B clients who already hold ETH there. You can offer both and let the buyer’s wallet decide.
How much does it cost to accept a payment in ETH?
On 4 September 2026, an ERC-20 transfer on Ethereum mainnet had a median cost near $0.015, rising to about $0.34 under a load spike; Layer-2 transfers ran around $0.001 to $0.003. Speend passes the network fee through at blockchain cost with no markup. Fees change with demand — re-check current figures before relying on a specific number.
How many confirmations should I wait for?
Scale the depth to the order value: one confirmation for orders under ~$100, two or three up to ~$1,000, six or more above that, and twelve-plus for five-figure settlements. On Ethereum mainnet each confirmation is roughly 12 seconds, so even a deep wait is a few minutes.
ETH or USDT on Ethereum — which should I take?
Take ETH from buyers who want to spend ETH. Prefer a stablecoin (USDT or USDC on Ethereum) when the dollar value has to hold between checkout and settlement — large invoices, volatile markets, or a merchant who prices in fiat. Both use the same network and confirm in the same one-to-three-minute window.
What happens to the ETH price at checkout?
The rate is locked when the payment request is created and held for the life of the invoice — one to twelve hours, two by default. The buyer owes the quoted ETH amount regardless of price moves during that window. To avoid holding ETH afterward, Speend can auto-convert it to a stablecoin on receipt for a 1% fee.
Do I need a separate wallet for each network?
No. Speend provides the merchant balance and surfaces the supported networks at checkout, so you accept ETH across mainnet and its Layer 2s without provisioning a wallet per chain. The buyer pays on whichever network they’re on, and the funds land on the same balance.
Before you go live
The decision comes down to two settings and one habit. Pick the default network by your typical ticket size — Layer 2 for small and frequent, mainnet for large and occasional — and set a confirmation threshold that matches what a reversed order would cost you. The habit: because gas figures move, treat any specific fee number as dated and re-check it before you quote it to a customer or publish it. The structure holds — low median, higher ceiling, steadier L2 — even when the exact cents change.
