On this page
- A transaction is a signed bundle of instructions; Solana runs all of them or none, and caps a legacy transaction, the kind Fianto builds, at 1,232 bytes.
- A one-off Fianto payment during the beta is two compute-budget instructions plus one USDC transfer straight to the merchant's token account, signed only by the customer.
- Fianto checks every instruction of the signed transaction before it sends it, and counts the payment only once the transaction is finalized.
What is a blockchain transaction, in plain terms?
A blockchain transaction is a request, signed by the people whose money or data it changes, that the network records in its shared ledger once validators accept it. Think of it as a cheque that carries its own proof: the signature shows the owner approved it, and every node can check that signature without asking a bank. Other payment terms are defined in the crypto payment glossary.
Solana's documentation puts it in one line: a transaction "includes one or more instructions, the signatures of accounts that authorize the changes". It adds the rule that matters most to a merchant: "The network processes all instructions in a transaction together." Either the whole payment happens or none of it does. There is no state where the price left the customer but never reached you. Source: Solana docs, transactions, read on 15 October 2026.
An instruction is one call to a program, the code that lives on chain and decides what a call may do. The USDC transfer in a payment is an instruction to the Token program, one of the two programs behind SPL tokens. How programs differ from the smart contracts of other chains is the subject of programs, not smart contracts.
What is inside a Solana transaction?
A Solana transaction has five parts, and each one has a job you can see in a payment:
| Part | What it is | In a Fianto one-off payment |
|---|---|---|
| Fee payer | The account that pays the network fee; it must sign | The customer's wallet. Fianto signs nothing and pays nothing in this transaction |
| Recent blockhash | A hash of a recent block; Solana docs say it "is valid for 150 slots" | Fetched by Fianto when it builds the transaction, so the payment expires if it is not signed and sent in time |
| Accounts | Every address an instruction reads or writes | The customer's USDC token account, the USDC mint, the merchant's USDC token account, the customer's wallet, a reference key, and the Compute Budget and Token programs |
| Instructions | Calls to programs, run in order | Two compute-budget settings and one USDC transfer (two transfers when a Fianto fee applies) |
| Signatures | One 64-byte Ed25519 signature per signer | One: the customer's. It also becomes the transaction's ID on an explorer |
A legacy transaction, the format Fianto builds, must fit in 1,232 bytes, so it holds a handful of instructions, not a shopping cart's worth; Solana's newer v1 format raises the limit to 4,096 bytes. Each address in the table is a Solana address, a public key written in base58; what a Solana address is covers the formats.
What does a real USDC payment look like, instruction by instruction?
A one-off 25.00 USDC payment to the made-up shop Quillfern Labs, built by Fianto's checkout during the beta, runs three instructions in this order. The list comes from the backend file that builds every one-off payment, payment-transaction..
- Set the compute unit limit to 60,000. Compute units measure the work a transaction may do. A USDC transfer needs far less; the limit is set with room to spare so the transaction still lands.
- Set the compute unit price to 1,000 micro-lamports. This is the priority fee: what the customer offers per unit of work on top of the base fee. How Fianto raises it for renewals when the network is busy is in payments during Solana congestion. A lamport is the smallest unit of SOL, one billionth of a SOL, and a micro-lamport is a millionth of a lamport.
- Transfer 25,000,000 base units of USDC. The instruction is the Token program's transferChecked, from the customer's USDC token account to the merchant's, with the USDC mint and its 6 decimals named so the program can refuse a wrong token or a wrong scale. USDC has 6 decimals, so 25.00 USDC is 25,000,000 base units; USDC decimals and Solana units explains the conversion. The customer's wallet signs as the owner of the source account: no delegate and no approval is involved.
One extra account rides on the transfer: a reference, 32 random bytes written as an address, generated for each checkout session. The Token program ignores it. Fianto uses it to find this exact payment on chain later, even if the checkout page was closed before the result came back.
When the Fianto fee is above zero, after the beta, a fourth instruction transfers the fee to Fianto's treasury in the same transaction. During the beta the fee is zero, and the code then adds no fee transfer and names no treasury account at all. Subscriptions are different: their checkout transaction also sets up the subscription on chain and pays the first period, and it needs rent, which a one-off payment never does.
How much does this transaction cost, and who pays?
The customer pays 5,060 lamports, 0.00000506 SOL, in network fee for the transaction as Fianto builds it, and the merchant pays nothing. Solana's fee rules charge "a base fee of 5,000 lamports per signature" and a priority fee of "ceil(compute_unit_price * compute_unit_limit / 1,000,000) lamports" (read 15 October 2026). With one signature, a 60,000 limit and a price of 1,000 micro-lamports:
| Item | Calculation | Lamports |
|---|---|---|
| Base fee | 1 signature x 5,000 | 5,000 |
| Priority fee | ceil(1,000 x 60,000 / 1,000,000) | 60 |
| Total | 5,060 |
A wallet may raise the priority fee before the customer signs; Fianto lets it, because the customer is the fee payer and a higher priority fee only spends the customer's own SOL. The checkout page shows the network fee as paid by the customer and under $0.01. The wallet also has to keep its own minimum SOL balance, so the checkout tells the customer the exact SOL amount to hold; why you need SOL to send USDC explains that minimum.
What does Fianto check before it sends a signed transaction?
Fianto reads every instruction of the signed transaction and refuses to broadcast it unless each one is something it asked for. The wallet only signs and hands the bytes back; Fianto sends them to the network itself. A wallet may re-encode what it signed, so the check compares meaning, not bytes. The validator in payment-transaction. refuses a transaction when:
- the blockhash is not the one Fianto issued, or the fee payer is not the customer's wallet;
- any instruction calls a program other than the compute-budget program or the Token program;
- there is an extra transfer, a missing one, or one to an account Fianto did not name;
- a transfer moves another mint, another decimals value, from another account, or a different amount;
- the reference is missing from the transfer to the merchant;
- the customer's signature is missing or does not verify.
A refusal means nothing was sent, which is the same as the customer not being charged. Compute-budget instructions are the one thing left unchecked, for the reason in the previous section: they can only spend the signer's own SOL.
See what the customer sees while this transaction is built, signed and sent.
How the hosted checkout worksWhen is a blockchain transaction final?
A Solana transaction is final once it is finalized, the commitment level at which the network will not roll it back. Before that it can be confirmed, meaning a supermajority of stake has voted on its block: very likely final, but not yet certain. Fianto uses both states. The customer's checkout page shows success at confirmed. The order turns paid, and your server receives order. and checkout., only at finalized.
Until Alpenglow activates on mainnet, scheduled for 21 October 2026, finality takes about 12.8 seconds; Solana's Alpenglow page says the upgrade "targets roughly 150 milliseconds" and that "confirmed and finalized become the same thing". The difference between the two states, and what to do in each, is in confirmed vs finalized. The docs page on how money moves shows the same path from the merchant side.
Final also means irreversible. There is no chargeback on a finalized transfer, and there is no refund button: a refund is a new transaction, sent by you from your own wallet back to the customer.