Network choice at a glance
| If this describes the sale | A practical starting choice | Why | Check before selecting |
|---|---|---|---|
| Customers already hold supported USDC on Base | Base, if the receiving and later deposit routes support it | Avoid moving assets only to fit another network | Wallet and sponsorship compatibility; full L2 + L1 fee |
| Customers already use Solana wallets | Solana, with a prepared recipient account | Keeps the customer on a familiar supported route | USDC mint, recipient account and sponsor policy |
| Customers use native Polygon USDC | Polygon PoS, if both ends accept the native asset | Avoid an unnecessary exchange or bridge | Native USDC rather than another representation |
| A large remote invoice must use Ethereum mainnet | A product that explicitly accepts Ethereum USDC | Fits the agreed route if both parties need it | Current PayIn does not offer this network; compare complete quotes |
Published network timing, not checkout promises
Official-source snapshot checked November 9, 2026. These are different protocol stages, not a fastest-checkout ranking.
| Network | Published block/slot or inclusion parameter | Stronger confirmation/finality information | What the number does not include |
|---|---|---|---|
| Base | About 200ms L2 inclusion | About 2 minutes L1 batch inclusion; about 20 minutes L1 batch finality | QR opening, human approval, service verification and staff notification |
| Solana | Current upgrade material describes 200ms slots | Alpenglow page states roughly 150ms target finality after a block is proposed | Time to submit and include a transaction, wallet interaction or a retail SLA |
| Polygon PoS | June 2026 update describes 1.5-second blocks | The update describes near-instant finality; no new numeric end-to-end figure is inferred here | A guaranteed maximum payment time or measured merchant handover |
| Ethereum | 12-second slots; a slot can be missed | Finality is a separate consensus stage, not the next block | A promise of confirmation in exactly one slot |
Sources: Base finality, Solana slot-time update, Solana Alpenglow, Polygon network update and Ethereum blocks. Solana's older confirmation tutorials still contain older slot/finality assumptions; the figures above are attributed to the newer upgrade pages, not a payment test performed by PayIn.
Quantify fee components without inventing a transfer quote
| Network | Reproducible cost basis | Useful number or formula | Still excluded |
|---|---|---|---|
| Base | Official minimum-fee example: 200,000 gas, 0.005 gwei, assumed ETH price $2,000 | 0.000001 ETH, or $0.002 of L2 execution in that example | L1 security fee, priority fee and whether your actual USDC operation uses that gas amount |
| Solana | 5,000 lamports per signature | One signature: 0.000005 SOL; two signatures: 0.000010 SOL before priority fees | Priority fees and any account-creation cost; no current SOL/USD price assumed |
| Polygon PoS | Actual gas used × effective gas price, paid in POL | Example arithmetic: 100,000 gas × an assumed 30 gwei = 0.003 POL | Both inputs are teaching assumptions, not a current USDC fee estimate |
| Ethereum | Actual gas used × effective gas price, paid in ETH | Example arithmetic: 100,000 gas × an assumed 10 gwei = 0.001 ETH | Both inputs are teaching assumptions, not a current USDC fee estimate |
Sources: Base network fees, Solana fees, Polygon POL and Ethereum gas. The examples deliberately show their inputs and incomplete scope; they are not same-transaction measured network quotes and should not be used to rank total costs. Use the wallet/provider's current estimate for the exact supported operation, then add the merchant service and conversion costs.
For actual checkout timing, record scan-to-request, approval, submitted-to-verified-result and staff notification separately. No end-to-end benchmark was run for this article. The customer's existing supported balance and a prepared receiving route can be more decisive than a sub-second protocol statistic.
The best USDC network for a payment is one the customer can use, your checkout accepts, your wallet can receive, and your next destination supports. Choosing the network with the shortest advertised block time does not fix a customer's unsupported wallet or an unavailable deposit route.
For the wider decision, start with the merchant payment series. This comparison covers network selection; the linked setup guides cover individual receiving steps.
Compare the entire route
Circle lists native USDC deployments for the networks below. Use the directory to identify the asset, not a token's name or logo.
| Network | Native fee asset for ordinary self-funded transactions | Merchant checks | Current PayIn checkout |
|---|---|---|---|
| Base | ETH | Supported wallet, native USDC, receiving address and later deposit route | Supported USDC |
| Solana | SOL | Correct mint, wallet support and receiving USDC token account | Supported USDC; prepare the recipient account first |
| Polygon PoS | POL | Native USDC versus bridged versions, correct chain and receiving route | Supported USDC |
| Ethereum mainnet | ETH | Customer's fee estimate, confirmation policy and intended payout route | Not currently offered |
The fee-asset column describes ordinary network transactions. A supported sponsored checkout can fund fees separately; it does not eliminate the chain's cost. See the official fee explanations for Ethereum, Solana and Polygon.
Ask what the customer already has
Imagine an 18 USDC counter purchase. If the customer's only spendable balance is on Solana, an EVM-only checkout adds a problem before payment begins. Conversely, asking a Base user to move assets to Solana during a queue may be less convenient than receiving on Base.
For a remote invoice, there is more time to agree the route. State the exact asset, network and amount before the customer withdraws from an exchange. Verify that the payment flow supports the payer's method: a self-custody wallet signing a request is not the same as an exchange withdrawal to an address.
Distinguish fast feedback from finality
Base documents several confirmation stages. A fast inclusion signal and stronger finality are different concepts. Other networks and payment services also have their own confirmation policies; a block-time statistic is not an end-to-end retail benchmark.
Measure the merchant flow in separate parts: opening the QR, connecting the wallet, reviewing the request, signing, settlement verification and staff notification. The counter-speed guide explains where preparation can reduce delays without promising a fixed arrival time.
Prepare the recipient before opening the queue
On Solana, the current PayIn flow checks whether the merchant's USDC receiving token account exists before asking the payer to sign. Do not assume that every facilitator will create the account or cover its setup cost. Follow the receiving-account guide.
For Base, follow the payment-link setup guide. For Polygon, confirm the native USDC asset in your wallet and conversion service; the existence of USDC.e or another representation does not prove it is accepted by the request. Read native versus bridged USDC.
Check the exit as carefully as the entry
A network can work well for customer payments while being inconvenient for the merchant's bank conversion route. Check deposit asset/network, minimums, fees, eligibility and operational availability before selecting it for a large invoice.
Do not compare only the customer's transfer fee. Include any later conversion, bridge or withdrawal you genuinely need. The full-cost worksheet gives a consistent way to record those charges without assuming every merchant needs every step.
A practical selection rule
For a counter, choose the supported route requiring the least preparation from the customers you actually serve, and prepare the receiving device and account in advance. For a larger online invoice, agree the route explicitly and test configuration without moving production funds. For multi-network collection, keep receipts and network labels distinguishable through reconciliation.
There is no measured universal winner in this article. Use receipt verification for handover and after-receipt planning for the next step.