Dropped vs failed Solana transactions: what happened, and what it cost.

What is the difference between a dropped and a failed transaction?

The difference between a dropped and a failed transaction is whether a validator processed it. Everything else follows from that one fact:

Solana's transactions documentation explains the revert: "If any instruction fails, the entire transaction fails and all state changes are reverted." The fee is the exception, because the network has already done the work. An explorer shows a failed one with its error; how to read a Solana payment on an explorer walks through both screens.

Why do Solana transactions get dropped?

Solana transactions get dropped when they never reach the leader that is producing blocks, or reach it too late, which happens most during network congestion. Solana's guide to retrying transactions opens with: "On some occasions, a seemingly valid transaction may be dropped before it is included in a block." It then lists the causes: lost network packets, the simplest one, overloaded validators, RPC nodes that are ahead of or behind each other, and temporary forks.

From the sender's side a dropped transaction simply vanishes: there is no error to read, because the signature never appears in a block. The same guide says RPC nodes keep forwarding a transaction to leaders every two seconds, until it is finalized or its blockhash expires; the expiry rule is explained in "blockhash not found".

Does a failed Solana transaction still cost a fee?

A failed Solana transaction still costs its full fee. Solana's fee structure page, read on 15 October 2026, says it in one line: "If the transaction fails, the fee is still charged." The same page explains when: "The total fee is deducted from the fee payer before execution begins." The learning page on transaction fees gives the reason: "Yes, because validators still process them."

For a USDC payment the amount is small. A one-off payment through Fianto costs 5,060 lamports, about 0.000005 SOL; the breakdown of every Fianto transaction is in how much a Solana transaction costs. Account rent is different: it is not taken by a failed transaction, because the accounts it would have opened are never created.

How do you avoid paying for a transaction that will fail?

You avoid paying for a failing transaction by simulating it before you send it. A simulation runs the transaction against current state without including it in a block, so a transfer that would fail shows its error for free. Wallets run the same kind of dry run to preview a transaction, and warn when it fails, as wallet transaction warnings explains. Sending with preflight on does this automatically: Solana's retry guide recommends keeping skipPreflight set to false.

Fianto checks at three points before a fee is at stake:

1. Before your wallet opens, the checkout reads your USDC account, your SOL and the merchant's USDC account, and refuses a payment that could not succeed. You have signed nothing, so nothing is charged.
2. After you sign, Fianto's first broadcast runs with preflight on. If the simulation fails inside an instruction, Fianto stops rebroadcasting that transaction, because sending it again without preflight would only let a validator charge you a fee for a transfer that cannot happen.
3. Before each subscription renewal, Fianto simulates the unsigned charge. A renewal the simulation shows would fail is not signed or sent, which saves the fee.

Simulation cannot catch everything: state can change between the simulation and the block, so a transaction that simulated cleanly can still land and fail. It catches the common cases, such as an empty balance, before any fee is at stake.

How does Fianto decide whether a payment was dropped or failed?

Fianto decides whether a payment was dropped or failed from the chain alone, with a tracker that looks at every payment in flight every two seconds. A payment that has landed with an error is marked failed at once. A payment no node has seen is never called dropped early, because it might still land:

1. While the blockhash is valid, the tracker rebroadcasts the signed transaction and waits. If the main RPC provider still has not seen it after ten seconds, the tracker also asks the others.
2. It waits until the chain is 150 blocks past the transaction's lastValidBlockHeight, a margin on top of the expiry, so a lagging node cannot cause a false drop.
3. It then asks every RPC provider it is configured with. Only if every one answers that it has never seen the signature is the payment marked dropped. If any provider stays silent, nothing is decided.
4. A transaction any provider ever reported as confirmed is never dropped automatically, even if every provider later forgets it. It stays open and raises an alert for a person to check.

A payment still undecided 30 minutes after its blockhash died raises an alert, and support can settle it with an audited command after checking the chain by hand, as dropped or failed, never as a success. If a payment written off as dropped later turns up on chain, Fianto reopens it, settles it from the chain and records that in its audit log. These rules exist because the costly mistake is calling a payment dropped when the money did move: that would reopen the checkout and invite the customer to pay twice.

What happens to a Fianto payment that was dropped or failed?

A Fianto payment that was dropped or failed is marked failed, and the checkout stays payable while its link is still open, unless the USDC reached the merchant anyway, in which case the session closes. Neither sends order.paid, so a merchant whose server waits for that webhook never fulfils an order that did not settle. The customer reads: "This payment did not complete. Check your wallet's recent activity first: if the USDC left your account, do not pay again, and contact [merchant name]. If it did not, press Pay to try again."

The one case the merchant should look at is a payment marked failed whose USDC reached the merchant's wallet anyway. The dashboard's Needs attention page lists failed payments whose money landed, so you can refund them from your own wallet or fulfil them by hand.

Dropped and failed subscription renewals

Renewals treat the two differently. A dropped renewal says nothing about the customer's wallet, so it does not count toward the four attempts Fianto makes before a subscription ends; it is simply tried again. A failure counts only when the customer caused it: not enough USDC, the wallet approval revoked, or a USDC account that is frozen or closed. Fianto reads the customer's accounts before it sends a renewal, so most of these are caught without any transaction. The SOL fee of a renewal is drawn from Fianto's charging key, the fee payer on chain, and the customer contributes through the flat 0.01 USDC network fee charged today with every subscription charge on plans created since 6 October 2026; the merchant pays neither. The full retry schedule is in failed renewals and retries.