ETH Payment

 

 

Ethereum's Account Model vs. Bitcoin's UTXO Model

 

Ethereum and Bitcoin take fundamentally different approaches to tracking balances. Bitcoin uses UTXO (Unspent Transaction Output) model: your 'balance' is the sum of all unspent outputs previously sent to your addresses, and spending requires referencing specific UTXOs as inputs. Ethereum uses an account model: each address has a persistent balance field that is updated directly with each transaction, similar to a bank account balance rather than a pile of coins.

For payment gateways, this distinction has practical implications. Monitoring for incoming Bitcoin payments requires watching for UTXOs sent to specific addresses. Monitoring for incoming ETH requires watching for transactions with a non-zero value field sent to a monitored address. Monitoring for incoming ERC-20 tokens requires watching for Transfer events emitted by token contract addresses. A gateway monitoring for all three must implement three different detection patterns even for the same Ethereum address.

 

Native ETH Payments vs. ERC-20 Token Payments

 

Ethereum supports two distinct payment types: native ETH transfers and ERC-20 token transfers. They share the same address format and often the same user wallets, but their technical mechanics differ significantly. A native ETH transfer sends ETH directly in the transaction's value field — simple, requiring no contract interaction. An ERC-20 transfer calls the token contract's transfer function, updating the contract's internal ledger without ETH changing hands (except for the gas fee, which is always paid in ETH even for ERC-20 transfers).

For merchant payment gateways, ERC-20 token payments are more operationally prevalent than native ETH payments because USDT and USDC — the primary stablecoins — are ERC-20 tokens. Merchants accepting 'Ethereum payments' typically mean ERC-20 stablecoin payments rather than native ETH, particularly in B2B and settlement contexts where price stability is important.

 

Layer 2 Networks and Their Role in Ethereum Payment Adoption

 

Ethereum's programmability and its ecosystem's depth make it a natural platform for payment innovation, but mainnet gas fees create an economic ceiling on viable payment values. A €10 payment on Ethereum mainnet with a €5 gas fee represents a 50% cost overhead — commercially impossible. The Layer 2 ecosystem addresses this by providing Ethereum-equivalent execution environments with dramatically lower fees, while inheriting Ethereum's security guarantees.

 

L2 Network

Fee for ERC-20 Transfer

TVL (2024)

Notable Payment Use Cases

Arbitrum One

$0.10–$0.50

$18B+

DeFi; institutional settlement; gaming

Optimism

$0.10–$0.50

$8B+

Coinbase integration; public goods funding

Base

$0.05–$0.30

$7B+

Coinbase consumer products; USDC native

Polygon PoS

< $0.01

$1B+

Consumer apps; gaming; NFT markets

zkSync Era

$0.05–$0.20

$3B+

ZK-proof security; gaming; DeFi

Starknet

$0.10–$0.30

$1B+

High-security ZK applications

 

Smart Contract Functionality for Payment Logic

 

Ethereum's smart contract capability enables payment logic that is impossible on Bitcoin or simple account-model blockchains. Payment contracts can enforce conditions — releasing funds only when certain criteria are met, splitting incoming payments automatically between multiple parties, enabling subscription streaming, implementing multi-party approval requirements, or creating escrow arrangements that release on delivery confirmation. This programmability makes Ethereum the platform of choice for complex payment structures beyond simple invoice-and-pay flows.

For a crypto payment gateway, smart contract integration is most relevant for batch settlement (using a multisend contract to distribute funds to many recipients in one transaction), escrow payment flows (where funds are held on-chain pending delivery confirmation), and subscription streaming protocols (like Superfluid, which streams tokens continuously between addresses). These features extend what a gateway can offer merchants well beyond the basic receive-confirm-settle workflow.

 

 

Compliance Note: This glossary entry is provided for general educational purposes only and does not constitute financial, investment, legal, or tax advice. Industry terminology may vary across jurisdictions and providers; definitions herein may not directly reflect the specific features, terms, or specifications of Finassets' services. For details on Finassets' offerings, please refer to official product documentation or contact our team directly.