Proving you paid: transaction IDs and payment proof
"I sent it." "It never arrived." Most crypto payment disputes come down to those two sentences. The good news is that a blockchain payment leaves a public record anyone can check, and the key to that record is a single string: the transaction ID. Here's what it is, where to find it in SSP, and how the other side should verify it.
What a transaction ID is
Every transaction on a blockchain has a unique identifier, called a transaction ID (txid), transaction hash or, on Solana, a signature. It is a fingerprint computed from the transaction itself, so it points to exactly one payment on exactly one chain.
The txid is public and safe to share: it reveals nothing that isn't already on the chain, and nobody can use it to move your funds.
Where to find it in SSP
When a payment is approved on SSP Key and broadcast, both SSP Wallet and SSP Key show a "Transaction Sent" window with the txid, a QR code of it, a copy button and a Show in Explorer button that opens the transaction on the chain's block explorer.
If you closed that window, open the transaction in your activity history. The expanded row shows the date and time, the TXID with a copy button, the receiving address, the fee, the number of confirmations (or block height) and any note you added, plus the same Show in Explorer link.
Copy the txid rather than retyping it. Keeping records of your crypto covers what else is worth saving.
How the recipient verifies it
Send the recipient (or an exchange's support team) the txid, the network you used, and the address you sent to. They should paste the txid into a block explorer for that chain and check four things:
- The chain. A Bitcoin txid won't exist on Litecoin's explorer, and an Ethereum hash won't exist on BSC. If the explorer finds nothing, the first question is whether they're looking at the right network.
- The recipient address. One of the outputs (UTXO chains) or the transfer destination (EVM, Solana) must match the address they gave you, character for character.
- The amount. For tokens, look at the token transfer line, not the native-coin value, which is often zero.
- Confirmations. A pending transaction can, rarely, be replaced or dropped, so many services wait for several confirmations before crediting.
How to read a block explorer walks through each of these fields.
A screenshot isn't proof. A screenshot of a wallet saying "sent" proves only that someone had an image. It can be edited in seconds, or show a transaction that later failed or went to the wrong address. Ask for the txid instead: the explorer record can't be faked. Someone who sends a screenshot but won't give a txid is a warning sign.
EVM vaults: transaction hash vs user operation hash
SSP's EVM accounts are ERC-4337 smart accounts. Your approved payment is a user operation, and a service called a bundler includes it in an ordinary blockchain transaction. That gives two identifiers:
- the user operation hash, which identifies your operation, and
- the transaction hash of the bundler's transaction that carried it.
After broadcasting, SSP Key waits for the operation to be included and shows the transaction hash. If that wait fails, it falls back to the user operation hash, which a normal transaction search won't find; in that case, check your activity history once it updates, since history entries use the transaction hash.
On the explorer, the transaction's "From" is the bundler and "To" is the EntryPoint contract, not your vault. Point recipients to the internal-transaction or token-transfer section, where your vault address appears as the sender, with the amount and their address.
Proving you control the sending address
Sometimes a recipient wants proof that a payment came from you, not just from some address. The classic answer is signing a message with the sending address's key; signing a message explains what that proves.
Be aware of SSP's limits here. SSP's built-in message signing signs with your SSP Wallet identity, not with your 2-of-2 multisig sending address, and a multisig address on Bitcoin-style chains can't produce a standard single-key signed message. On EVM chains, a dApp connected through WalletConnect can ask your vault to sign a message: SSP Wallet and SSP Key both sign, and the result can be checked against the smart account itself (ERC-1271) once that account has been deployed. Where none of that fits, the practical fallback is a small agreed payment from the same address, which proves control in a way any explorer can show.
Common "not received" disputes
When the recipient insists nothing arrived, it is usually one of these:
- Wrong network. The same address format works on several EVM chains. Funds sent on BSC won't appear in an Ethereum-only account.
- Missing memo or tag. Exchanges that use a shared deposit address need the memo or destination tag to credit you. See memos, destination tags and missing deposits.
- Not yet confirmed. The payment is real but still waiting for the confirmations the service requires.
- Wrong address. The explorer will show where the funds went. If that address isn't theirs, no one but its owner can move them.
In each case, the txid is what support needs to investigate.
The honest summary
The txid is your proof of payment: share it, along with the network and the destination address, and anyone can verify the chain, recipient, amount and confirmations themselves. Screenshots prove nothing. SSP shows the txid with copy and explorer buttons after every send and in your history, and on EVM chains it shows the bundler's transaction hash, where your vault appears in the transfer details rather than as the sender. Proving control of a multisig address by signed message is limited in SSP today, so a small test payment is often the simplest answer.
