Ethereum payment acceptance involves more than displaying a hexadecimal address. A merchant may receive native ETH or a token transferred by a smart contract, and the customer may interact through a wallet, exchange, layer-two network, or compatible chain. The system must identify the exact chain and asset, observe the correct event, and apply a clear confirmation and risk policy.
Distinguish native ETH from token transfers
Native ETH moves as the value field of an Ethereum transaction. A token such as an ERC-20 asset is usually transferred by calling a contract, which emits event data that indexers use to identify the recipient and amount. A transaction hash alone does not tell the merchant which token moved or whether the intended transfer succeeded.
The payment record should store the chain ID, asset type, token contract when applicable, decimals, recipient, amount, transaction hash, and relevant log index. The log index matters because one transaction can contain several token transfers. A canonical asset registry should list approved contracts for each chain. Symbols and names are display fields, not security identifiers, because an unrelated token can copy a familiar symbol.
Make chain selection explicit
Many EVM-compatible networks use similar address formats. A customer can send an asset to the same-looking address on a different chain while the merchant monitors only one network. The checkout should show the network name, chain-specific wallet request, and a warning near the address.
Wallet connection flows can request a chain switch, but the user should still see the selected chain in text. If the user rejects the switch, return to method selection without losing the order. Internally, chain ID should be required in every payment object and webhook. Settlement and reconciliation systems must preserve the chain as well as the token.
Understand gas without charging the wrong amount
Ethereum transactions require gas, which represents computational work. The sender pays the network fee in the chain’s native asset. The merchant’s requested token amount should not be reduced by that fee. Customers using an exchange withdrawal may see a separate fee or receive a net amount, so the payment system needs a short-payment policy.
The Ethereum.org transaction documentation describes transactions as signed instructions and explains gas-related fields. For merchants, the practical lesson is that fee conditions can change and the customer’s wallet controls submission. A customer may hold the payment token but not enough native asset to pay gas, so checkout support content should explain the requirement without requesting private wallet information.
Observe execution, not just inclusion
A transaction can be included in a block but fail during execution. For token payments, the gateway should verify the transaction status and the expected transfer event. It should not credit a payment merely because the transaction hash exists and targets the token contract.
Contract-based checkout flows may emit custom events or route through aggregators. The merchant must know which event constitutes payment and whether the contract can be upgraded or paused. Indexers can lag or miss events during outages, so a reconciliation process should re-query open payments. Event processing must be idempotent because rescans can deliver the same transfer more than once.
Set a confirmation and finality policy
A payment can move from observed to confirmed to accepted. The threshold should depend on the chain, transaction value, product, and merchant risk. A high-value shipment may wait longer than a low-value digital service. Document and version the rule rather than hiding it in code.
Layer-two networks and sidechains can have different settlement and withdrawal models from Ethereum mainnet. A fast local confirmation does not necessarily mean the same thing as final settlement on the base layer. If the merchant accepts those networks, the asset registry and policy should describe their behavior. Customer-facing status should distinguish “transaction included” from “order approved.”
Use exact arithmetic and validate token behavior
ERC-20 contracts represent token amounts as integers with a declared decimal convention. The gateway should use exact integer arithmetic, never floating-point math, when creating and matching amounts. Display formatting can round for readability, but the stored expected amount must remain precise.
Some tokens have unusual decimals or transfer behavior. Fee-on-transfer, rebasing, pausable, blacklistable, or upgradeable tokens can complicate acceptance. Merchants should restrict support to assets whose behavior their provider and accounting process understand. Underpayment tolerance should be defined in exact units or invoice value, and overpayments should become a visible credit or refund case.
Design wallet requests carefully
A wallet request can prefill the recipient, amount, token contract, and chain. The customer should review those details before signing. The checkout should not request broad token approvals when a simple transfer will do. Unlimited approval requests create unnecessary risk and can damage trust.
If a smart contract is used, explain what the customer is signing in plain language. Avoid mixing payment with unrelated permissions. Provide a manual option where appropriate and maintain a server-side payment status. The wallet’s “submitted” message means the transaction was broadcast, not that the merchant accepted it. The merchant should observe the network independently.
Secure provider and webhook integration
Payment providers should sign webhooks and include event IDs, timestamps, chain IDs, token contracts, amounts, and resource identifiers. The merchant should verify signatures, reject replayed events, and fetch the current payment object before fulfillment. A duplicate event must not create duplicate goods or access.
Credentials should be scoped. A front-end checkout may create payment intents through the merchant backend, but it should not have provider secrets or treasury permissions. Refunds and payouts require stronger controls, destination validation, and approval thresholds. Monitor changes to the asset registry and settlement addresses because altered configuration can redirect value without attacking Ethereum itself.
Plan settlement and refunds
The merchant may hold ETH or tokens, convert them, or settle through a processor. Conversion should record the source asset, chain, amount, fees, rate, destination currency, and provider. Treasury policy should define balance limits and approved counterparties.
Refunds are new transactions. Verify the destination and chain rather than sending automatically to the original transaction sender, which might be an exchange or smart contract. If refunding a token, ensure the treasury wallet has enough native asset for gas. Wrong-chain transfers require a documented response, and recovery should never be promised before technical and custody feasibility are confirmed.
Test the whole EVM matrix
A launch test should include native ETH, each approved token, each supported chain, several wallet categories, insufficient gas, rejected chain switch, failed contract execution, delayed indexing, underpayment, duplicate events, refund, and settlement. Small real transactions often reveal differences that testnets do not.
Keep the initial matrix small. Every additional token-chain pair is a distinct rail with its own contract, liquidity, wallet, monitoring, and incident dependencies. Ethereum payments can be flexible and programmable, but dependable acceptance requires precise chain and asset identity, exact arithmetic, execution checks, explicit confirmation policy, and secure configuration.
Assign an owner to network and token configuration. Contract additions, confirmation changes, provider failover, and emergency pauses should follow reviewed change procedures, with a test transfer and documented rollback. Operations also needs a current runbook for congestion, failed token events, delayed indexing, unexpected contract behavior, and customer claims that a transaction succeeded. Configuration discipline is part of payment security because an incorrect contract or chain setting can send valid transactions outside the merchant’s supported path.
