Transaction Receipt

Overview

A transaction receipt is created after the network executes a transaction. Nodes expose it through methods such as eth_getTransactionReceipt. Before inclusion, the receipt is normally unavailable, so a submitted transaction hash alone does not establish execution.

Receipt fields commonly include transactionHash, blockHash, blockNumber, transactionIndex, status, gasUsed, cumulativeGasUsed, effectiveGasPrice, logs, and logsBloom. Contract-creation transactions can also include the created contract address. Exact fields vary with client, transaction type, and protocol version.

The status field distinguishes successful execution from a reverted transaction, but both outcomes can consume gas and appear in a canonical block. Logs should be processed only with their transaction and block context. A receipt returned from a block that is later reorganized may no longer describe canonical history.

Payment systems should store the receipt alongside the original request, expected recipient, asset, amount, and order identifier. Token transfers often require decoding event logs rather than relying only on the transaction’s top-level value. Duplicate callbacks should update the same payment record idempotently.

A receipt is strong execution evidence but not a complete business decision. Applications still need network-specific finality requirements, reorganization monitoring, and a recovery scan after provider outages. Multiple providers can be compared when receipt data conflicts, but canonical chain rules determine the accepted result.

In practice, a payment service should store the network, transaction hash, block hash, receipt status, gas used, relevant logs, and confirmation state together. Unlike a successful RPC submission, a receipt records execution after block inclusion; even then, the block can remain subject to reorganization. This distinction prevents fulfillment based only on mempool acceptance, an API response, or logs from a failed transaction.