What a transaction hash actually is
A transaction hash is the output of running the transaction's own contents through a cryptographic hash function. Every detail that makes the transaction what it is — the inputs or sender, the outputs or recipients, the amount, the fee, the nonce — is fed in, and the function returns a fixed-length string that is effectively unique to that transaction. Change a single byte of the transaction and the hash changes completely, so the txid doubles as a tamper-evident fingerprint: it both names the transaction and commits to its exact contents.
Because it is derived from the data rather than assigned by a central authority, two parties who hold the same transaction will independently compute the same hash. That is what makes a txid a safe thing to quote in a support ticket, an invoice record, or a webhook payload — anyone with access to the chain can resolve it to the same single transaction.
The format differs by chain. Bitcoin and most EVM chains present a txid as a 64-character hexadecimal string, often shown with a leading 0x on Ethereum-style networks. Solana uses a base58 transaction signature in the same role. XRP Ledger and Tron have their own representations. They are not interchangeable across chains, and the same payment on two different networks has two unrelated hashes.
What a txid is not
A transaction hash is not an address. An address is a destination that can receive many transactions over time; a txid identifies one specific transaction, once. A deposit address might collect a dozen payments, and each of those payments has its own distinct hash.
A txid is also not a wallet, a balance, or an account number, and it is not a halfin invoice or payout identifier. halfin assigns its own internal IDs to invoices, deposits, and payouts so it can track them through their lifecycle; the transaction hash is the chain's identifier for the underlying on-chain movement. One halfin invoice can map to one txid in the simple case, or to several — for example when a customer underpays and then tops up, each top-up is a separate transaction with its own hash.
How transaction hashes show up in halfin
When a customer pays an invoice or funds a deposit address, the transaction they broadcast carries a hash the moment it is signed and accepted into the mempool. halfin watches the relevant chains, matches incoming transactions to the addresses it is monitoring, and records the txid against the invoice or deposit it belongs to. As blocks build on top of that transaction, halfin counts confirmations against the per-chain threshold for the asset and credits the balance once the threshold is met, in a reorg-aware way.
The same hash surfaces wherever you reconcile a payment: in the dashboard view of an invoice or deposit, in the API representation of that record, and as a field in the webhook events that announce a payment's progress. Because it is the chain's own identifier, the txid is the one value that lets you cross-check halfin's record against an independent source of truth — a public block explorer — without trusting any single party's database.
- Look up a payment independently — paste the txid into a block explorer for that chain to see the transaction exactly as the network recorded it.
- Reconcile your books — the hash ties a halfin invoice or deposit to a specific on-chain movement, so finance can match received funds to the chain.
- Support a customer — a buyer who says they paid can hand you a txid; you can confirm it landed, see how many confirmations it has, and explain where it sits.
- Audit a payout — a completed payout carries the hash of the transaction halfin broadcast, which proves the funds left and where they went.
Why it matters to a merchant
The transaction hash is the anchor for every reconciliation conversation. When a payment is delayed, disputed, or simply needs explaining, the txid is the precise reference that removes ambiguity: it points at one transaction, on one chain, with a state anyone can verify. Quoting it in a support reply or a finance export is far more useful than describing an amount and a rough timestamp, which can match several payments.
It also sets a realistic expectation about timing. Seeing a txid means the transaction exists and has been broadcast — it does not yet mean the payment is settled. halfin only treats a payment as confirmed after enough blocks have built on top of it, because early blocks can be reorganized away. The hash gives you something to watch while those confirmations accrue, and a stable handle to record once they have.