Why a successful transaction can leave an order unpaid

Success in a block explorer tells you that a transaction executed successfully. To establish payment, the actual asset, recipient, amount, and network must match the invoice, and the required confirmations must be complete.

Consider a fictional shop order for 100 USDT. The buyer sends an explorer link with a green Success label, but the payment page still shows an unpaid invoice. Before releasing the goods, the shop needs to establish what the transaction did and which purchase it paid for.

What did the successful call actually do?

Start with the action, rather than the colour of the status. An Ethereum receipt reports whether the top-level execution succeeded or failed; that is the boundary defined by EIP-658. The blockchain has no knowledge of the shop’s order or its commercial terms.

A successful approve call illustrates the difference. It grants another address permission to spend tokens, but does not itself transfer them. ERC-20 defines approval and transfer as separate operations. An approval for 100 USDT could therefore be a real successful transaction while leaving our fictional order entirely unpaid. The buyer’s network fee does not change that result.

Which address received the tokens?

The top-level to field needs care on EVM networks. For a call to a token contract, it identifies the contract being called. The token recipient can instead appear in the call arguments and in the event recorded by that contract. Ethereum’s transaction documentation explains the distinction between the transaction destination and its input data.

Compare the payment address with the recipient of the verified token transfer. Input data describes the requested action, so reading it alone does not establish the outcome. A record labelled Transfer also needs its originating contract checked: an event name cannot authenticate the asset. If our 100 USDT reached someone else, Success still describes the execution correctly.

Is the asset really the one on the invoice?

A familiar ticker is insufficient. ERC-20 treats a token’s name and symbol as optional contract metadata, not credentials. Another contract can present a familiar label without representing the token the shop accepts. ERC-20 metadata and methods provide the underlying definitions.

A counterfeit token bearing the letters USDT should not be treated as an accepted asset or promised a merchant-balance credit. Other misleading payment evidence is covered in the guide to crypto payment fraud.

Does this transfer belong to this purchase?

Even a genuine transfer can fail to match the order. For our example, compare the network, asset, recipient, and amount with the current 100 USDT invoice. Check the invoice association as well: a transfer linked to another purchase does not settle this one.

Retain that association through the order workflow. The explorer and payment page can both be correct because they answer different questions: execution on a blockchain, and payment of a specific invoice.

Why can a matching transfer still be confirming?

Execution success and finality are separate properties. Inclusion in a block does not by itself mean that Ethereum has reached the required later confirmation stage. Those stages are described in Ethereum’s transaction lifecycle.

Paymos confirmation requirements depend on the network and payment amount; there is no single completion time for every payment. A matching transfer that is awaiting confirmations does not, by itself, establish fraud or failure. For a closer explanation of that wait, see blockchain confirmations and finality.

Can money arrive without marking the invoice paid?

Yes. In Paymos, another accepted asset, a late transfer, or funds received against an already closed invoice can be credited separately to the merchant balance. That credit does not mark the invoice paid or generate its payment webhook.

Sending the same asset on another network is also not enough to predict the invoice outcome. It depends on whether the relevant payment route is allowed and the transfer is watched for that invoice. Avoid assuming either that the money is lost or that the order is paid. These are balance and invoice questions to reconcile separately, and counterfeit tokens are not examples of accepted assets.

What should trigger fulfilment?

The buyer can follow the payment page. The shop should use the server-side state of the associated invoice or a verified payment webhook. Check the signature before processing the notification, then match its invoice to the order; the Paymos verification documentation explains signature verification.

A browser callback, a return to a thank-you page, and an explorer screenshot do not establish that server-side result. For our fictional purchase, fulfilment follows verified payment of the linked 100 USDT invoice.