Setting Up Ether Acceptance: Where the Payment Flow Breaks
The payment flow breaks not at cryptography but at the junctions. The payment address is reused: the client receives the same address as in a previous order, and if the amount differs, the payment can no longer be matched to a specific invoice.
Manual reconciliation in a spreadsheet hides this for a while, but the discrepancy with the actual balance accumulates and surfaces at the moment when sorting it out is most expensive.
Further down the chain — a transfer after invoice expiry: crediting payments turns into a manual operation where someone searches for the transaction and returns the order to work.
If such a path is not described, support resolves each case anew, and some transfers become lost payments: funds are debited, the order is not activated.
A separate category is transaction confirmations: crediting based on the transfer appearing in the network causes false positives, while waiting too long keeps the order pending.
Here what is needed is not "maximum reliability" but an explicit policy: how many confirmations we consider sufficient, what we do with a transfer that arrives later, how we mark partial payment.
Setting up Ether acceptance in Ethereum begins with separating these scenarios — a separate address for each invoice, timing rules, and automatic reconciliation instead of manual. Below — how this is closed at the service level.
What Automated Ether Acceptance Provides
Automation of crediting is built on one hierarchical wallet: each client is allocated a separate address derived from a common mnemonic phrase, so addresses do not overlap between orders, and there is still only one backup.
A network scanner checks incoming Ethereum transfers at short intervals and matches them against the registry — crediting occurs as soon as the transfer has accumulated the specified number of confirmations.
Crediting time stops depending on who is on duty at the statement. A network event reaches the accounting system in minutes, not after manual review in the morning; night and weekend receipts are processed in the same order as daytime ones.
The confirmation threshold is configured to match risk: lower — we issue the order faster, higher — more resistant to chain rollback.
Separately, a class of failures caused by manual processing is removed: a missed transfer, a double credit, a payment without a link to the client, a lost "amount — order" association.
Reconciliation of operations is based on the blockchain statement, so a discrepancy is detected immediately and closed before the client writes to support.
Payment accounting is maintained in a single registry: address, transfer hash, amount in ether, rate at the moment of confirmation, status, and number of confirmations.
The registry is exported to accounting and billing, and the balance on each address is visible in one summary — manual consolidation of spreadsheets is no longer required.
Payment Acceptance Modes: From a Single Address to an HD Wallet
The acceptance scheme determines how receipts enter accounting: the more payers, the more important it is that the address is assigned automatically and crediting is confirmed without manual reconciliation. Below are four working options and what limits each one.
| Acceptance scheme | When it fits | Scheme limitations |
|---|---|---|
| One shared address | Single receipts, the flow is easy to sort out manually | Payments from different clients are mixed, a transfer cannot be matched to an order, the balance cannot be separated |
| Dedicated address per client | A small number of counterparties, personalized accounting is needed | Addresses are reserved and stored manually, routine grows as the base grows, keys must be protected separately |
| Address pool from an HD wallet | Mass top-ups, an address needs to be issued automatically | Network monitoring and address index control are needed, the master key is a point of failure, an index error breaks recovery |
| Acceptance via an external custodian | They do not want to hold their own keys | Dependence on a third-party service, delays and withdrawal limits, part of the logic is outside our control |
What to Choose in Practice
For mass crediting, an HD wallet is usually chosen: the address pool is derived deterministically from one master key, so there is still only one backup, and recovery does not depend on the number of clients.
The price for this is monitoring discipline: without accounting for confirmation depth and reprocessing blocks, a credit can easily be counted twice or missed.
Hence the conclusion: the acceptance scheme is chosen not by the convenience of issuing addresses, but by which limitations you are prepared to keep under control. Next we examine how receipt monitoring and reconciliation with internal accounting are structured.
How We Deploy Payment Acceptance: Work Stages
Each payment in ether is not "turn on a wallet" but an agreed route: an address linked to an application, confirmations in the network, crediting in the accounting system, and a clear procedure in case a transaction hangs or a block rolls back.
The work proceeds in fixed stages — this way, at each step it is visible what has already been checked and what has not.
- Payment scheme audit. We analyze how money currently arrives: how addresses are matched to applications, where operations are done by hand, which events are logged at all. The output is a map of fund movement and a list of risks: lost nonces, duplicate credits, unprocessed stuck transfers.
- Acceptance design. We choose the address model — a shared wallet, a separate deposit address per application, or an HD wallet with a unique derivation index. We fix at what number of confirmations a payment is considered final and how transaction replacement is handled.
- Infrastructure setup. We set up a block observer, configure an event queue and a backup data source, and separate a hot wallet for payouts from cold storage for the bulk of funds.
- Integration with the accounting system. The address, event, and database record are linked by an idempotent key: repeated event delivery does not create a second credit. We configure reconciliation — it matches the network state daily.
- Test runs. We run scenarios on the test network and with small amounts on mainnet: underpayment, overpayment, block rollback, stuck transaction, payment after invoice expiry.
- Handover to support. We provide the flow diagram, configurations, incident response regulations, and a dashboard with balance, confirmation delay, and the number of unreconciled operations. After that — support and targeted improvements.
Configurations, Accesses, and Regulations: What Stays with You
After launching ether acceptance, the team is left not with a single working wallet but with a set of artifacts that your engineer or another contractor can use to support acceptance without contacting us.
We put everything into your repository and knowledge base: configurations, diagrams, and regulations sit side by side and are updated as a single set.
- Acceptance configuration — descriptions of address issuance services, connection parameters to network nodes, confirmation thresholds, and limits per transaction. From these files, deployment is reproduced on a clean environment.
- Fund movement diagram — the path from receipt to the client address to crediting to the accumulation account: where the intermediate addresses are, at what moment confirmation is recorded, how refunds and underpayments are handled.
- Access matrix — which employee can do what: issue addresses, sign payouts, view balances, edit monitoring rules. Roles are separated, keys from different contours do not overlap.
- Documentation — service descriptions, receipt notification formats, instructions for manual operations, and analysis of typical failures with checkpoints.
- Support regulations — what to do in case of a missed event, stuck transaction, or reconciliation discrepancy: who responds, within what timeframes, along which escalation branch.
- Rotation and recovery procedure — how signing keys are changed, how the service is restored from backup, what to do if compromise is suspected.
- Daily reconciliation — the procedure for matching address balances with internal entries and a report template that makes a discrepancy visible before a failure.
Case: A Service's Payment Flow Before and After Implementation
What It Was Before
Payment acceptance hung on one shared wallet, and an operator matched each incoming transfer to an application manually. Reconciling a batch took 40–50 minutes, on peak days it was done twice, and it still lagged behind the flow.
Some receipts got stuck: when amounts from two clients matched, the review was postponed until a confirmation email, and during that time the client saw an unpaid invoice.
What We Changed
We allocated an address pool: a separate address is issued for each application, and the "address → application" link lives in the database, so matching no longer depends on the transfer amount.
Monitoring is subscribed to Ethereum network blocks, waits for the required number of confirmations, and sends an event to billing via webhook with an idempotent key — repeated delivery does not create a double credit.
What It Became
The share of payments requiring manual intervention fell from 12% to 1% — these are disputed transfers and refunds.
The crediting time after confirmations decreased from 3–4 hours to 5–15 minutes, and stuck receipts almost disappeared: the event arrives once and with an unambiguous link to the application. The operator's freed-up hours went to handling client inquiries rather than reconciling statements.
What to Do If Payment Is Already Going to One Permanent Address?
While there are few payments, a permanent address looks convenient: one wallet, one statement, everything in sight. At scale it becomes a bottleneck — all receipts merge into one feed, and the ownership of a payment by a specific client has to be determined by amount and time.
As soon as two payments match in size, manual reconciliation begins, and a disputed payment may be credited to the wrong customer.
Such an address cannot be turned off overnight: already issued invoices and the entire transaction history depend on it. Therefore, migration of the acceptance scheme proceeds in parallel operation mode.
The permanent address remains under observation and continues to accept payments for old invoices, while new invoices receive addresses from the pool — one per document.
The separation works like this: each address in the pool is derived from a common secret by sequence number, so the entire pool is restored from one backup phrase, and a receipt is unambiguously linked to an invoice without manual review.
The old flow is tagged by invoice numbers and time windows, and reconciliation closes automatically.
Transition risks are also closed in advance. The main one is loss of history: if the permanent address is retired earlier than the last invoices settle, receipts will stop being linked to orders. The second is double crediting when keys are moved.
Therefore, we keep the old address in watch-only mode until the last invoice closes, and we make the switch in stages with a log: first new invoices, then acceptance, and only then the archive.
Technical Questions Asked Before Work Starts
Before the start, the customer usually checks five scenarios: confirmation threshold, payment after invoice expiry, chain reorganization, key storage, and project handover. Below is what we build into the configuration when setting up ether acceptance, not verbal promises.
How many confirmations should be waited for before crediting?
The threshold is a configuration parameter, not a constant in code. We start with a value after which the block is practically not reorganized: crediting takes several minutes under normal network operation. For large amounts the threshold is higher, for small ones lower, so as not to slow down issuance.
A payment arrived after invoice expiry — what happens to it?
The transaction is already in a block; it cannot be canceled. Monitoring records the transfer and moves the application to the "late payment" status: the customer decides whether to credit it at the current rate or process a refund. The scenario is automatic and does not require manual review.
What happens during a chain reorganization?
For each credit we store the block height and hash. If the branch rolls back, the status returns to "awaiting confirmation" and is restored when the transaction re-enters the main chain. No phantom receipts remain on the balance.
Where are private keys stored?
On the application server — only the public part needed to generate addresses. Signing is moved to an external key custodian; withdrawing funds requires a separate role. Compromise of the web part does not give access to funds.
What will remain if the team changes?
Configurations, the address scheme, database migrations, status descriptions, and incident action procedures — in the repository, not in chat. Key material lives outside the service infrastructure, so transferring access to a new team does not require moving the recovery phrase.
Let's Discuss Your Payment Scheme and Implementation Procedure
To evaluate ether acceptance for your environment, the entire project is not needed — a few inputs are enough. The more specific the input, the fewer assumptions in the work estimate and the more realistic the timelines in the implementation plan.
- Crediting scheme: one address per client, an HD wallet with derivation by index, or a separate invoice for each payment.
- Network and asset: production environment, test bench for debugging, whether token acceptance is needed in addition to ether itself.
- Source of block data: own node, external provider, or both with failover.
- Where state is written: accounting database, internal service, back office — and how crediting confirmations are transmitted.
- Confirmation requirements: how many blocks to wait before crediting, whether automatic chain reorganization handling is needed.
- Key storage: where the seed is located, who has access, whether there is a hardware module or external signing service.
- Monitoring: where notifications about stuck transactions and insufficient funds on withdrawal addresses go.
After discussing the task, we will return with an estimate and implementation plan: break the work into stages, specify the person responsible for each, note what we do first and what runs in parallel, and where data is needed from your side.
We will agree on the start order so that the first payment goes through the test environment before production launch.