When a store looks at the processing rate, it sees one percentage. In practice, before the payment lands on the right account, it goes through several stages: network execution, matching with an order, conversion, storage, compliance monitoring, treasury operations and operational visibility. Each stage has its own cost. Some costs are directly stated in the contract, others depend on the market and network load, and some can be included in the overall price without a separate line.
This article looks at what the real cost of one crypto payment is made up of, where differences between the stated rate and the actual amount credited appear, and what questions to ask a provider before signing a contract.
One payment goes through seven layers, and cost does not only appear at the moment of acceptance
For the buyer, the process looks simple: they choose to pay in crypto, send the funds, and the store gets the money. Inside, the payment goes through a longer path:
- The buyer sends the transaction to the network
- The network confirms the transaction
- The system links the payment to a specific order or checkout session
- If needed, the asset is converted to another one, for example a stablecoin
- The asset is credited to a wallet or internal balance
- The transaction goes through screening and risk checks
- The funds are moved to treasury, cold storage or another circuit
Cost can increase at any of these steps. This is why a public processing rate rarely shows the full cost of a payment.
| Layer | What happens | Where cost appears |
|---|---|---|
| Network execution | The transaction is published and confirmed on the blockchain | Network fee, which depends on the network, load and type of operation |
| Attribution | The payment is linked to an order | Manual checking or infrastructure for automatic linking |
| Conversion | The incoming asset is changed into the target asset | Service fee, spread, slippage, routing cost |
| Storage and protection | Funds are held in a wallet | Security infrastructure: MPC-based wallet technology, policy controls |
| Monitoring | Screening, alerts, sanctions checks | API, data updates, alert handling |
| Treasury movement | Sweep, consolidation, rebalance, payout | Separate network fees after acceptance |
| Operational visibility | Dashboard, API, webhooks, reports | Provider infrastructure, without which it is hard to explain differences |
The network fee depends on load, the type of operation and the structure of the transaction
There is no single fixed price for a transaction on the blockchain. For an incoming payment, the fee is usually paid by the buyer, because they are the one sending the transaction to the network. After acceptance, other operations appear: sweep from deposit addresses, consolidation, payouts, topping up gas wallets and moving funds to cold storage. These costs fall on the store, the processor or the infrastructure provider.
The network fee cannot be removed from the model entirely. It can be shown separately, included in the overall price, or passed to another party.
Bitcoin. The fee depends not on the transfer amount, but on the size of the transaction in bytes. If a store receives many small deposits, UTXOs build up, and the following sweep becomes more expensive. Batching and UTXO consolidation help reduce future costs.
TRON. The cost of a TRC20 transfer depends on Energy, Bandwidth, the TRX price and the state of the specific contract. If there is no Energy available in advance, the transfer burns TRX at market price. Because of this, TRON can be cheap, but it does not always give a predictable final cost.
Ethereum and EVM networks. The cost depends on gasUsed, base fee and priority fee. A regular transfer and a smart contract operation need different amounts of gas, so an ERC20 transfer, sweep or treasury operation can cost differently even on the same network.
Auto-conversion adds a separate layer to the cost of crediting
If a store accepts one asset but wants to hold its balance in another, conversion appears between the payment and the final credit. For example, the buyer pays in BTC, but the store needs a balance in USDT or another asset.
Conversion always has market and service components. This is normal: an exchange does not happen at some abstract "clean" price. The final amount can be affected by the conversion fee, spread, slippage and the conditions under which the deal is executed. The question is not whether these components exist, but whether they are hidden.
| Component | What it is | What matters to the store |
|---|---|---|
| Conversion fee | The fee for carrying out the exchange | Should be clear in advance |
| Spread | The difference between the market price and the execution price | Should not be hidden in the rate without explanation |
| Slippage | The deviation of the actual price from the expected one | It should be clear that it relates to market and liquidity |
| Result after conversion | The amount that lands on the balance after the exchange | Should be checkable in the Back Office or a report |
In Finassets, Auto-Convert can be set up as a separate rule: which asset to convert, which asset to move funds into, and at what minimum amount to trigger the exchange. An auto-convert fee applies to the operation and is taken from the amount of the asset being converted.
For the store, the main point is not that conversion should be "free". The main point is that it should be clear which asset was accepted, what it was converted into, what fee applied and what amount resulted after the exchange. Then auto-conversion stays a manageable layer of cost, not a hidden gap between the payment and the credit.
Managing balances needs separate infrastructure with its own cost
After acceptance, funds do not just stay "in one wallet". They need to be managed, moved between internal circuits, and prepared for further use: payouts, exchange, or withdrawal to an external address.
In Finassets, this is done through sweep: moving funds from a deposit address to a chosen destination.
Sweep also has its own cost. Before the operation, the system shows the available balance, the chosen destination, the network fee level, the estimated sweep fee and the estimated receive amount. The cost depends on the network, current blockchain load and the chosen fee level.
This matters for the store because costs need to be visible in the interface, not lost inside the overall processing rate.
Finassets covers this layer through the Back Office: the team sees deposit addresses, available balances, the sweep destination, the fee calculation and the final amount received. All sweep operations are kept in the transaction history, so the finance team can check not only that funds arrived, but also how the balance moved afterwards.
Without a breakdown by layer, the store sees the result but not the reason for the difference
Operational visibility is not only for a dashboard. The main thing it should give the store is a clear breakdown of fees.
If the system only shows the final credited amount, the finance team cannot see what made up the difference. The difference could come from a service fee, network fee, sweep fee, exchange fee or another operation after the payment was accepted.
In Finassets, this is handled through Export with merged fees. The store can download a CSV file where fees are shown separately by transaction:
| Component | What it shows |
|---|---|
| Service Fee | The fee for using the platform |
| Network Fee | The cost of processing the transaction on the blockchain |
| Sweep Fee | The fee for moving funds from a deposit address |
| Exchange Fee | The fee for exchange operations |
This kind of export is needed for reconciliation, accounting and internal control. Instead of one final amount, the store gets a file showing which fee relates to which operation and why the final credited amount differs from what was expected.
The other Back Office tools help find a specific operation quickly: search by ID or hash, filters by asset, status, type, account and period, and Details for each transaction.
Finassets: cost layers are fixed in the contract and visible in the Back Office
When a provider only shows the rate for accepting payments, the store cannot see how much went to sweep, conversion, network fee or service fee. At Finassets, the key cost components are fixed in advance, and actual operations can be checked in the Back Office.
- Transparent fee: progressive scale 0.40% → 0.30% → 0.25% → 0.20%, other rates are fixed separately in the contract
- TRC20 network fees up to 50% lower: pre-purchased Energy helps fix the cost of a TRC20 transfer before confirmation and can reduce costs by up to 50%+ compared to the burn model, depending on Energy availability and network conditions; individual outcomes vary
- Back Office: Transactions shows deposits, withdrawals, sweeps, conversions, network fees, sweep fees, exchange fees, service fees and autoconvert operations. CSV with merged fees can be exported for reconciliation
Start creating an account, and the Finassets team will get in touch to go through the cost for your volume, networks and use case.
