How to read a Solana payment on Solscan or Solana Explorer, field by field.

What is a Solana transaction signature, and is it a receipt?

A Solana transaction signature is the 64-byte Ed25519 signature that the first signer puts on a transaction, written as a long base58 string, and it doubles as the transaction's ID. Solana's glossary defines the transaction ID as "The first signature in a transaction, which can be used to uniquely identify the transaction across the complete ledger." Anyone who has the signature can look the transaction up on a public explorer.

A signature proves that a transaction exists. It does not, by itself, prove what the transaction did: a failed transaction has a signature too. Treat it as the receipt number, and the explorer page as the receipt. Fianto puts the signature in three places:

• The checkout receipt, in the row labelled Transaction, as the full signature linking to Solscan. Until the signature is known, the row reads "confirming".
• The merchant dashboard, on each payment under On chain, with links to Solscan.
• Webhooks, as payment.signature in the event payload, next to amounts written in base units ("25000000" is 25 USDC, because USDC has six decimals).

What do the summary fields on Solscan and Solana Explorer mean?

Both explorers open a transaction with a summary block that answers "did it work, who paid, and when", before any detail. The labels differ slightly. The table uses the labels in Solscan's transaction-details documentation and in Solana Explorer's source code, both read on 15 October 2026.

The fee deserves a closer look. Solana's fee documentation sets a base fee of 5,000 lamports per signature (a lamport is a billionth of a SOL), plus an optional priority fee of the compute unit price times the compute unit limit, divided by 1,000,000. A one-off Fianto payment has one signature, so its base fee is 5,000 lamports, or 0.000005 SOL; anything above that on the Fee line is the priority fee the transaction asked for.

Which instructions does a Fianto payment contain?

A one-off Fianto payment is built with four instructions at most, in a fixed order, and Fianto refuses to broadcast a signed transaction that adds anything but compute-budget instructions. An instruction is one call to a program, naming the accounts it reads or changes. Scroll past the summary to the instruction list and you should find:

1. Compute Budget: set the compute unit limit. How much computation the transaction may use.
2. Compute Budget: set the compute unit price. The priority fee per unit. A wallet may add compute-budget instructions of its own; Fianto accepts them, because only the customer pays for them.
3. Token program: transferChecked to the merchant. Source: the customer's USDC token account. Destination: the merchant's USDC token account. Authority: the customer's wallet. The amount is the price in base units, with six decimals. One more account rides on this instruction: the reference.
4. Token program: transferChecked to the treasury. The Fianto service fee, from the same source. This instruction exists only when the fee is above zero. There is no Fianto fee during the beta, so a one-off payment today has no fourth instruction.

transferChecked is the Token program's transfer that also states the mint and its decimals, so a payment of the wrong token fails instead of moving something else. On mainnet the mint must be USDC, EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v. We read that account on 15 October 2026: it belongs to the original Token program and has 6 decimals. How to spot an imitation token is in real USDC on Solana.

A worked example: a 25.00 USDC payment

Say a customer pays 25.00 USDC for a one-off order during the beta. Solana Explorer's Tokens card lists the token accounts in the transaction with each one's change, its Owner, its address (Addr) and the Token. You would see two rows: the customer's USDC account down 25 and the merchant's USDC account up 25. Solscan summarises the same move under Main Actions. The Fee line shows SOL only, paid by the customer's wallet. The amount inside the instruction reads 25000000, the same figure the webhook carries.

One detail confuses people: the transfer goes to a token account, not to the wallet address you gave Fianto. A token account is the account that holds one wallet's balance of one token. Explorer prints the wallet as the token account's Owner, so check the Owner line against your receiving wallet.

What is the extra account on the USDC transfer?

The extra account on the merchant transfer is the payment reference: 32 random bytes that Fianto generates for each checkout session and adds to the transfer as a read-only, non-signing account. The Token program ignores it. It holds no balance, so an explorer may show it as an account with nothing in it.

The idea comes from the Solana Pay specification, which has wallets add reference values "in the order provided as read-only, non-signer keys" and notes that, because validators index transactions by account keys, a reference can be found with the getSignaturesForAddress RPC method. Fianto does exactly that: every 60 seconds while a session is open, and for 24 hours after it closes, it looks for transfers that carry the session's reference. That is how it notices a payment a wallet sent on its own, or a customer who paid twice.

The reference is random. It is not your order ID, the customer's email or anything else from your records, so a stranger reading the transaction learns nothing about the order from it. What a stranger can learn from your wallet as a whole is covered in privacy on a public blockchain.

How does a subscription charge look on an explorer?

A subscription charge calls the Solana Foundation's Subscriptions program (De1egAFMkMWZSN5rYXRj9CAdheBamobVNubTsi9avR44) instead of transferring directly, so the instruction list names that program. Two kinds of transaction appear over a subscription's life:

Because every renewal carries the session's reference, one subscription's charges can be found together. A treasury transfer appears on every charge of a plan created since 6 October 2026, because the customer pays a flat 0.01 USDC network fee with each charge today. The cap and the checks the program applies are explained in Solana token delegation explained.

What does a failed or missing payment look like?

A failed payment shows Error in the Status line on Solana Explorer, with the reason beside it, and a failed result on Solscan; a payment that never landed is not found at all. Those are different situations. A failed transaction ran and moved no USDC, but its fee was still taken: Solana's fee structure page says "If the transaction fails, the fee is still charged." A dropped one never reached a block, so nothing happened and nothing was spent. Dropped vs failed Solana transactions goes through both.

The explorer is also where you settle the opposite case: a payment Fianto marked Failed even though money arrived, for example one that finalized after a newer checkout session had replaced its own. The dashboard then says "This payment failed, but a transfer reached your wallet. Check it on Solscan before you contact the customer." Open the signature, read the Tokens rows, and you know what reached your wallet. How such records reach Needs attention is in paid twice, or paid after a failure, and how your server should learn about payments without opening an explorer at all is in how a merchant knows a crypto payment arrived.

The full layout of what the customer signs is on the how money moves page of the docs.