Confirmed or finalized: when a Solana payment is really final.

What do processed, confirmed and finalized mean on Solana?

Commitment is how settled a block must be before a Solana node reports it, and there are three levels: processed, confirmed and finalized. Many RPC calls take a commitment parameter, which Solana's RPC documentation describes as how finalized a block must be "before the node returns data or sends a notification." A slot is the short window in which one validator, the leader, may produce a block. Other terms on this page are defined in the crypto payment glossary.

If a call leaves the parameter out, the docs say the default is "typically finalized." A payment climbs the levels in order. Its transaction executes in a block (processed), validators vote on that block (confirmed), and enough later votes pile up on top of it that no competing block can replace it (finalized).

How long does a Solana payment take to finalize?

Until Alpenglow activates (scheduled for 21 October 2026), a Solana block takes about 12.8 seconds to finalize, while confirmation arrives in about one slot; after activation, solana.com targets roughly 150 milliseconds to finality. The figures come from the Alpenglow upgrade page on solana.com, which explains that under TowerBFT, the consensus Solana runs until Alpenglow replaces it, validators vote by sending transactions and "a block is final once enough of those votes have stacked up over 32 slots."

For developers the gap shows up in a second place: transaction expiry. Every Solana transaction carries a recent blockhash and lapses once that blockhash is more than 151 blocks old (why a Solana payment expires). Solana's confirmation guide notes "typically at least a 32 slot difference between the most recent confirmed block and the most recent finalized block" (true under TowerBFT), so a blockhash fetched at finalized is already old when you use it. The guide says the confirmed level "should almost always be used for RPC requests."

Fianto's backend follows that advice for building transactions. It fetches blockhashes, checks block height and sends with preflightCommitment: 'confirmed' (in platform/solana/rpc-solana-gateway.service.ts). Only the decision about money waits for finalized.

Can a confirmed Solana payment be rolled back?

A confirmed Solana payment can in principle still be rolled back, but the record says it has never happened. The Alpenglow page puts both halves in two sentences:

So the answer depends on who is asking. For a customer watching a checkout, confirmed is as good as done. For a business that ships goods, opens an account or books revenue on the event, confirmed is a very strong signal and finalized is a guarantee. Processed is weaker than both: a processed block can sit on a fork the cluster abandons, and Fianto treats even an error reported at processed as undecided, because a later vote can supersede it.

Once a payment is finalized, nothing in the network can pull it back, and there is no card network to file a dispute with either. Chargebacks vs crypto refunds covers what replaces the dispute.

Which commitment does Fianto wait for before a payment counts?

Fianto waits for finalized before it treats any payment as paid. The rule lives in the backend's chain transaction tracker, backend/src/modules/checkout/services/chain-transaction-tracker.ts, which looks at every payment in flight every two seconds and acts on the status Solana reports:

The quoted descriptions are the dashboard's own status card on the Payments page. On Fianto's hosted checkout the customer's wallet broadcasts nothing: it signs, and Fianto sends the transaction to Solana, rebroadcasts it while its blockhash is still valid, and follows it until it finalizes or fails.

At finalized the tracker makes one more check before settling. It reads the finalized transaction and compares the balance changes with what Fianto built: the amount to the merchant, any fee to Fianto's treasury, and the USDC mint. A mismatch fails the payment, but only at finalized. Below that level a mismatch may be one RPC provider's partial answer, so the tracker waits for a finalized read rather than fail a good payment for ever.

Renewals follow the same rule. The customer signs nothing at renewal: Fianto's charging key signs the charge, and subscription.renewed is sent only once that charge finalizes.

Why show the receipt at confirmed but send webhooks at finalized?

Fianto splits the two because the customer and the merchant need different things from the same transaction. The customer needs to know the payment went through, so they stop waiting and do not pay twice. A receipt about a slot after the block lands does that, and no confirmed block has ever failed to finalize.

You need a fact you can act on and never undo, such as sending a licence key or recording revenue. Waiting for finality costs about 12.8 seconds until Alpenglow activates, and solana.com expects a fraction of a second after it. Either way it is cheap. How that compares with card settlement is in how long a USDC payment takes to settle.

The cost of the split is a short window in which the customer's screen says paid and your system does not know yet. If your success page reads your own database, the customer can land there before order.paid does. Plan for it: show "Payment received, setting things up" and refresh when the webhook arrives, instead of an error.

Deduplicating events and granting access from them is covered in the guide to webhooks for access. How to tell that a payment arrived when you are not using a processor at all is in how a merchant knows a crypto payment arrived.

Which commitment should your own code use?

Until Alpenglow activates, use confirmed for anything you can redo and finalized for anything you cannot. In practice:

• Building and sending a transaction: confirmed for the blockhash, and the same level as preflightCommitment when you send or simulate, as Solana's guide recommends.
• Showing a customer progress: confirmed.
• Showing a balance on a screen: confirmed is fine.
• Granting access, shipping, crediting an account or reconciling your books: finalized. On Fianto, the webhooks already wait for it.

If you read the chain yourself, add one rule: never decide that a payment failed because it is missing. A transaction that has not landed can still land until its blockhash expires. Fianto's tracker keeps rebroadcasting until then, never marks a payment dropped while it could still land, and never drops on its own a transaction that any RPC provider ever reported as confirmed. A person on the support side decides those.

The status table and every webhook are in the Finality page of the Fianto docs.

What does Alpenglow change for Solana payments?

Alpenglow is a new consensus protocol for Solana, and once it is active, confirmed and finalized describe the same state. The Alpenglow page says it activates on mainnet in epoch 1064, scheduled to start on 21 October 2026 at about 15:00 UTC, and targets finality of roughly 150 milliseconds, down from the 12.8 seconds TowerBFT needs.

The page adds that the 150 ms "is an expectation, not a constant": it depends on how stake is spread across validators and on whether a block finalizes in one round of voting or two. Its advice to developers is to point new code at finalized only once Alpenglow is live, because "on TowerBFT, finalized still means waiting 12.8 seconds", and it says confirmed "will be deprecated and removed in a later release."

For a Fianto merchant nothing needs to change. Fianto already waits for finalized, so if Alpenglow performs as targeted, order.paid should trail the customer's receipt by about the tracker's two-second interval plus delivery time, instead of twelve seconds or more. That follows from how the tracker works; it is not yet a measurement.

Execution does not change either. The page says transactions, programs and fees stay the same, so a USDC payment looks and costs the same after activation as before it.