In this article
An onchain payment works by recording the transfer directly on a public blockchain: the payer signs a transaction with a private key, the network checks it, a validator includes it in a block, and after a short wait the block becomes final and the payee's balance has changed for good. No bank ledger sits in between. The blockchain itself is the ledger, and both parties read the same record.
A business about to send or receive its first onchain payment needs the parts in order: what a wallet and a key are, what exactly moves, who pays the fee, how long "done" takes, and what you keep for the file. This article is the map. It uses Ethereum as the reference network, because Ethereum publishes its rules in open documentation, and it quotes that documentation for every figure about timing and fees. Other networks follow the same logic with their own numbers.
The article is general information for a business reader. It is not legal, tax or investment advice.
Figures read in the Ethereum Foundation's developer documentation for the Ethereum main network.
What does "onchain" mean for a payment?
An onchain payment is a payment whose record is a transaction written to a public blockchain, a shared ledger that thousands of independent computers keep in identical copies. The payment is not an instruction sent to a bank that then updates its own books; the transaction is the payment, and once it is recorded the balances have changed.
In a bank transfer, each bank keeps a private ledger, and the two banks settle between themselves through a payment system that neither customer sees. What you receive as a customer is a message about the ledger, such as a statement line, never the ledger itself.
Onchain, there is one ledger and everyone reads it. The payer, the payee, an accountant and an auditor all look at the same entry, identified by the same reference, and anyone can look the transaction up independently.
Three consequences follow, and the rest of this article develops them. First, authority comes from a cryptographic key, not from an account opened in your name. Second, the network runs every hour of every day, since no single institution's opening hours govern it. Third, no participant has the power to reverse a recorded payment, which protects the payee and puts the full burden of accuracy on the payer.
What do you need before you can pay or be paid onchain?
You need an account on the network, which in practice means a wallet that holds a private key, plus the address derived from that key. The payee needs only an address to receive; the payer needs an address, the asset to send, and a little of the network's native coin to pay the fee.
The Ethereum Foundation's documentation describes two kinds of account. An externally owned account is controlled by whoever holds its private key. A contract account is a program deployed on the network and controlled by its code. A person or a business normally pays from the first kind, and may pay to either.
The private key is a long secret number; the documentation describes it as 64 hexadecimal characters. From it a public key is computed, and from the public key the address is derived, by taking the last 20 bytes of a hash of the public key and adding a prefix. The address is what you give to someone who must pay you. The private key is never shared: it is what signs transactions, and whoever holds it controls the funds.
A wallet is the software or device that stores the key, shows balances read from the network and builds transactions for you to approve. A wallet does not contain the money in the way a purse does. The balances live on the blockchain; the wallet holds the key that can move them. Whether your business keeps its own keys or uses a custodian is a separate decision; it changes who signs, not how the network processes the payment.
What actually moves in an onchain payment?
Either the network's native coin moves from one account balance to another, or a token moves, which means a contract updates the balances it keeps. A dollar stablecoin is a token, so most business payments in dollars are of the second kind.
The native coin of Ethereum is ether. Every account has an ether balance recorded by the network itself, and a payment in ether simply lowers the sender's balance and raises the recipient's.
A token is different in a way that matters for understanding your records. A token is a contract, a program with its own address, that keeps a table of who owns how many units. The ERC-20 standard, published as an Ethereum Improvement Proposal, defines the common functions such a contract offers: one that returns the balance of an account, and one that transfers an amount of tokens to an address and must emit a transfer event when it does. When you "send 18,400 dollars in a stablecoin", your transaction is addressed to the token contract and calls its transfer function. The contract reduces your line in its table and increases the payee's line. No coin travels anywhere; a balance changes inside a contract.
This explains what surprises first-time users. The transaction's destination, read on the network, is the token contract and not the payee, whose address appears inside the transfer details. The amount is stored as a whole number of the token's smallest unit, with a number of decimals the contract declares, so the same payment can appear as a very long integer in raw data. And the token is only as reliable as the contract and the issuer behind it: some token contracts give their issuer administrative functions, and a token with a familiar name is the real one only if its contract address is the one the issuer publishes.
| Native coin | Token, such as a dollar stablecoin | |
|---|---|---|
| Where the balance is kept | In the account itself, by the network | In a table inside the token contract |
| What the transaction is addressed to | The payee's address | The token contract, with the payee named inside |
| Value against the dollar | Moves with the market | Designed to track the dollar, depending on its issuer |
| What pays the network fee | The native coin | The native coin as well |
What happens, step by step, from signature to finality?
A payment goes through six stages: the wallet builds the transaction, the payer signs it, the network checks it and holds it as pending, a validator includes it in a block, other validators vote for that block, and the block is finalized. On Ethereum the first inclusion takes seconds and finality takes about a quarter of an hour.
The sequence below follows the description of transaction execution in the Ethereum Foundation's documentation on proof of stake.
- The wallet builds the transactionThe wallet assembles the destination, the amount or the contract call, a counter that numbers the account's transactions in order, and the fee the payer is prepared to pay.
- The payer signsThe private key produces a signature over that exact content. Changing a single character of the destination or the amount would make the signature invalid, so nobody can alter the payment after it is signed.
- The network checks itThe signed transaction is submitted to a node, which verifies that the signature is valid and that the account can cover the fee, then adds it to its list of pending transactions and passes it on to other nodes.
- A validator includes it in a blockTime is divided into slots of 12 seconds. In each slot one validator is chosen to propose a block, and it picks pending transactions to include. The payment now has a place in the ledger.
- Other validators attestValidators check the block and send a vote for it, called an attestation. Each new block built on top adds a confirmation, and wallets usually show the payment as confirmed from this stage.
- The block is finalizedSlots are grouped into epochs of 32 slots. When checkpoints at the start of epochs attract votes from at least two-thirds of the total staked ether, earlier blocks are finalized.
The timing follows from those two numbers. A slot of 12 seconds and an epoch of 32 slots give an epoch of 384 seconds, or 6.4 minutes, and finality is determined across two epochs, which is 12.8 minutes of protocol time. The Ethereum Foundation rounds the practical figure to about 15 minutes for a block to finalize.
Between inclusion and finality the payment is confirmed but, in theory, still open to reorganization if the network disagreed about recent blocks. After finality, the documentation states that reverting the block would require an attacker to commit to losing at least one-third of the total staked ether. For a business, the working rule is simple: treat an included transaction as seen, and a finalized one as received. "Sent", "confirmed" and "final" are three different states.
Who pays the fee, and what does it depend on?
The payer pays the network fee, in the native coin, and the fee depends on how much computation the transaction needs and how busy the network is, not on the amount of money being sent. A payment of 184 dollars and one of 1,840,000 dollars cost the same to process if they are the same kind of transfer.
The unit of computation is gas. The Ethereum Foundation's documentation gives the calculation as units of gas used multiplied by the sum of a base fee and a priority fee, both quoted per unit of gas in gwei, where one gwei is one-billionth of an ether. A standard transfer of ether requires 21,000 units. A token transfer runs code in the token contract, so it uses more, and the exact quantity depends on the contract.
The base fee is set by the protocol for each block and rises or falls with demand, by a maximum of 12.5% from one block to the next according to the same documentation. It is burned, meaning removed from circulation. The priority fee is a tip that goes to the validator. The payer also sets a maximum fee; the difference between that maximum and what was actually charged is refunded.
The chart shows what this means in practice for one token transfer at four levels of network demand. The assumptions are illustrative: 55,000 units of gas for the transfer, a priority fee of 1 gwei, and ether at 3,000 dollars.
Illustrative figures, not market data. The fee is the same whatever the amount transferred; it excludes any charge made by a wallet provider, a custodian or an exchange.
Two practical points follow. The payer must hold some of the native coin even when paying in a stablecoin, because the fee cannot be paid in the token itself in a standard transfer; a wallet with 25,000 dollars in tokens and no ether cannot send anything. And the documentation is explicit that the fee is paid whether the transaction succeeds or fails, because the validators did the work either way. A failed transaction moves no money but still costs its fee.
The payee pays nothing to receive. If the parties want the payee to bear the cost, that is a commercial arrangement between them, such as a deduction agreed on the invoice, not something the network does.
Why can a payment to the wrong address not be undone?
A payment to the wrong address cannot be undone because the network executes exactly what was signed and no operator has the authority to reverse it. Only the holder of the receiving key can send the funds back, and if nobody holds that key the funds stay where they are.
A bank can investigate a misdirected transfer and sometimes recover the money, because institutions control both ledgers. Onchain, the protocol has no function for "this was a mistake". The signature proved that the account owner authorised that destination and that amount, and that is all the network verifies.
An Ethereum address is a string of 42 characters with no name attached to it. Nothing in the address tells you it belongs to your supplier. The network will not warn you that the address has never been used, belongs to someone else, or is a contract that cannot send tokens back out. A valid format is the only thing it checks.
The same care applies to the network and the asset. An address can exist on several networks, and a token sent on a network the payee does not use, or a token different from the one invoiced, may arrive somewhere the payee cannot easily reach. A payment request that states the network, the token and the address removes that ambiguity before anyone signs.
What do the payer and the payee each see and keep as a record?
Both parties see the same transaction on the public ledger, identified by a transaction hash, and each keeps that hash together with the commercial documents that explain it. The hash proves that a transfer happened; it does not say what the transfer was for.
When the payer's wallet submits the transaction it returns the hash, a unique reference derived from the transaction's content. Anyone who has it can look the payment up in a block explorer, a public website that reads the ledger and displays it. The entry shows the status, the block and its time, the sending address, the destination, the token and amount transferred, and the fee paid.
The payer's side shows two movements: the token balance falls by the amount paid, and the native coin balance falls by the fee. The payee's side shows one: the token balance rises by the amount paid. Neither side receives a document from an institution.
What the ledger does not contain is context. There is no invoice number, no customer name and no description of the goods, unless the payment went through a contract or a service that attaches a reference. For accounting, the transaction hash is the equivalent of a bank reference, and it has to be matched to an invoice in your own books. The value in your reporting currency and the tax treatment depend on your jurisdiction.
How does an onchain payment compare with a bank transfer and a card payment?
An onchain payment settles directly between two addresses on a shared ledger and is final within minutes, a bank transfer moves through one or more institutions on rules that depend on the rail, and a card payment is authorised at once but settled later and can be disputed by the cardholder. The three are built for different jobs.
| Onchain payment | Bank transfer | Card payment | |
|---|---|---|---|
| Where the record lives | A public blockchain both parties can read | The private ledgers of each bank | The ledgers of the card network, issuer and acquirer |
| Who authorises | The payer, by signing with a private key | The payer, by instructing the bank | The cardholder, approved by the issuer |
| When it is final | After finality, about 15 minutes on Ethereum | Depends on the rail; some are final once processed | Later than authorisation; disputes can follow |
| Who usually bears the fee | The payer, to the network | Either or both, to the banks | The merchant, to the processor |
| Can it be reversed | No; only the payee can send it back | By recall or return under the rail's rules | Yes, by chargeback under card network rules |
| Identity of the parties | Not on the ledger; established separately | Verified account holders | Verified cardholder and merchant |
The bank column needs one qualification, because "bank transfer" covers very different systems. The Federal Reserve describes its Fedwire Funds Service as a real-time gross settlement system whose payments are immediate, final and irrevocable once processed, during its published operating hours. Batch systems, by contrast, settle later and allow returns under their own rules. Finality is therefore not unique to blockchains. What is distinctive onchain is that finality, a public record and round-the-clock operation come together.
Banks and card processors also do work the network does not: they identify customers, screen payments and handle disputes, which is why a consumer purchase by card is protected in ways an onchain payment is not.
What does an onchain payment not do by itself?
An onchain payment does not identify the parties, does not refund itself, and does not turn into money in a bank account. Each of those needs a process or a provider around the payment.
Identity comes first. The ledger shows addresses, not names. Knowing that an address belongs to your counterparty is a matter of verification on your side: a signed agreement that states the address, a confirmation through a known contact, or a test payment. Any customer due diligence duties your business has apply whatever the payment method.
Refunds are the second gap. There is no chargeback and no recall. A refund is a new payment, sent by the payee, at the payee's decision or under the contract between the parties. If your commercial terms include a return right or a deposit that may come back, write the refund terms into the agreement, including which address the refund goes to and who bears the fee.
Conversion is the third. A stablecoin balance is not a bank balance. Turning it into dollars or euros in an account means using a regulated provider such as an exchange, a broker or a payment institution, which will have its own onboarding, fees, limits and timing. Set that route up and test it before the payment arrives.
Two more limits are worth naming. A plain transfer carries no conditions: it does not wait for delivery or an inspection, so holding money against a condition is the job of an escrow arrangement. And a plain transfer pays one address. Paying several parties means several transfers, each with its own fee and its own risk of error, unless a contract does the distribution.
That last case is where a contract changes the shape of a payment. Shaka is an example: it is a payment router, in which each party's share of a deal is set as a percentage and can be signed by each recipient before the client pays. The client then pays once, and every party receives its share at the same moment, in one transaction. Shaka routes the payment and never holds the funds, and a deal has at most 20 recipients. It is not an escrow service, and it does not add identity, refunds or conversion to what the network provides.
What does one payment look like from request to record?
A complete onchain payment has four moments: the request that fixes the terms, the signature, the confirmation, and the record matched to the invoice. The example below follows one payment through all four with illustrative figures.
A consulting firm, the payee, invoices a client 18,400 dollars, payable in a dollar stablecoin on Ethereum. The invoice states the network, the token, the firm's address and the amount. The client verifies the address by phone with its usual contact at the firm, sends a small test, and receives confirmation that it arrived.
Before the payment, the client's wallet holds 25,000.00 tokens and 0.05 ether. The firm's wallet holds 3,150.00 tokens. The token uses six decimals, so the contract records the amount as 18,400,000,000 of its smallest unit. The example assumes the transfer uses 55,000 units of gas, with a base fee of 8 gwei, a priority fee of 1 gwei and ether at 3,000 dollars.
The client's wallet proposes a gas limit of 70,000 units and a maximum fee of 20 gwei per unit, which sets the most the transaction could cost at 1,400,000 gwei, or 0.0014 ether, 4.20 dollars. The client signs. A validator includes the transaction in the next block. The amount actually charged is 55,000 units at 9 gwei, which is 495,000 gwei, or 0.000495 ether: 1.49 dollars, of which 440,000 gwei is the burned base fee and 55,000 gwei is the validator's tip. The unused gas and the gap up to the maximum fee are never charged.
| Before | Change | After | |
|---|---|---|---|
| Client, token balance | 25,000.00 | −18,400.00 | 6,600.00 |
| Client, ether balance | 0.05 | −0.000495 | 0.049505 |
| Firm, token balance | 3,150.00 | +18,400.00 | 21,550.00 |
| Firm, ether balance | Unchanged | 0 | Unchanged |
The firm received the full 18,400.00 tokens; the fee came out of the client's ether, not out of the payment. Against the amount paid, a fee of 1.49 dollars is about 0.008%. The same fee on a payment of 184 dollars would be about 0.8%, which is why a fixed network fee weighs on small payments and almost disappears on large ones.
The firm's finance lead sees the incoming transfer within seconds of the block, waits for the block to be finalized, roughly a quarter of an hour later, and then marks the invoice as paid. The record filed against the invoice holds the transaction hash, the block time, the sending and receiving addresses, the token and amount, and the dollar value used in the books. The client files the same hash against its payable, with the fee recorded as a separate cost of 0.000495 ether.
If the two sets of books are ever compared, they point to the same line on the same ledger. What the ledger cannot supply is the layer around the payment: the contract, the verified address and the route back to bank money.
