What happens to a payment when Solana is congested or down.

What is the difference between congestion and an outage on Solana?

Congestion means Solana is producing blocks but more transactions compete for them than fit, so some wait and some are never processed; an outage means blocks stop being produced or finalized, so nothing new is processed at all. The two look alike from a wallet, where a payment just sits there, but they end differently.

Under congestion the leader, the validator whose turn it is to build the block, picks which transactions go first. Solana's fee documentation says: "The prioritization fee increases the likelihood that the current leader schedules your transaction ahead of competing ones." That fee is an optional extra, priced in micro-lamports (millionths of a lamport, the smallest unit of SOL) per compute unit, the measure of work a transaction may use. Solana computes it as the price times the compute unit limit, divided by 1,000,000 and rounded up, in lamports.

Congestion also loses transactions in transit. Solana's retry guide says of dropped transactions: "This most often occurs during periods of network congestion, when an RPC node fails to rebroadcast the transaction to the leader." Its advice to anyone sending payments is direct: "To prepare for times of network congestion, application developers should customize their own rebroadcasting logic."

An outage is a different event. Anza's report on the February 2024 halt opens: "On 2024-02-06 at 09:53 UTC Solana Mainnet Beta block finalization halted." No priority fee helps then; the only question is what a payment system does while it waits.

When has Solana mainnet stopped processing transactions?

Solana mainnet has stopped processing transactions several times, most recently on 6 February 2024, according to Solana's status page as read on 15 October 2026. Its incident list goes back to January 2022; the table shows the incidents it rates critical or major that describe a halt, in its own words. The rest are slowdowns, such as 22 January 2022, when it reported that "Solana mainnet beta is experiencing high levels of network congestion."

Anza's root cause report on the 2024 incident puts its length at "approximately five hours" and traces it to the program cache. We make no forecast about the next one. The Alpenglow upgrade, scheduled to activate on mainnet on 21 October 2026, replaces how validators vote; Solana's page says of its first phase: "It tolerates 20% of adversarial stake plus 20% of offline stake while still reaching consensus." That is a design property, not a promise about uptime.

What happens to a checkout payment while Solana is slow?

A checkout payment that Solana is slow to process stays pending on Fianto's side, and the checkout will not take a second payment for the same session while the first can still land. The wallet only signs; Fianto sends the signed transaction itself and keeps resending it while no provider has seen it, until the chain is 150 blocks past the transaction's last valid block height. How that window works is in why a Solana payment says "blockhash not found".

Three rules in the code matter when the network misbehaves:

• Expiry is counted in blocks, not minutes. The tracker compares the current block height with the payment's last valid block height. If block production halts, the height stops too, so a halt never turns a waiting payment into a "dropped" one by the clock.
• One live payment per checkout session. A second submit while one is in flight is refused with payment_in_progress, so a payer who presses Pay again on a slow day cannot pay twice through that session.
• A one-off payment is built with a fixed priority price of 1,000 micro-lamports per compute unit and a 60,000 compute unit limit, so its priority fee is 60 lamports. The payer's wallet signs it and pays the Solana fee, and some wallets change those values before signing.

The payer sees the receipt once the payment is confirmed, and the order turns paid, with order.paid, only at finalized. Until Alpenglow activates on 21 October 2026, Solana's page puts finality at about 12.8 seconds, with a target of about 150 milliseconds after it; during an incident it takes as long as the incident. The two levels are explained in confirmed vs finalized Solana payments.

How does a renewal get through a congested network?

A Fianto renewal gets through congestion by bidding more on every attempt that actually went out: 1,000 micro-lamports per compute unit on the first send, 15,000 more for each send before it, and never above 50,000. The count includes sends that were dropped, so the bid does not fall back to the floor after a congestion drop, which is the moment a higher bid is needed.

A renewal for a typical subscriber is built with a 40,000 compute unit limit. Fianto measured a renewal with one pull at 6,331 units on the mainnet program binary on 5 October 2026, so the limit has room to spare. At that limit the priority fee works out as follows:

The cap exists so that one congested hour cannot cost more in fees than the subscription's network fee brings in. Fianto's charging key signs every renewal and its SOL comes from that key. The merchant pays none of it; the customer's flat network fee, 0.01 USDC per charge today on plans created since 6 October 2026, goes toward these costs. Before anything is signed, the renewal is simulated, so a charge the program would refuse is not broadcast.

Does a Solana outage count as a failed renewal?

A Solana outage does not count as a failed renewal. A renewal gets four counted attempts, at the period boundary and then about one hour, six hours and a day after it, and only four reasons use one up: insufficient funds, a revoked delegation, a frozen token account and a closed token account. A network error, a dropped charge or a fault on Fianto's side is retried without counting, and it does not make the subscription past due.

Two more rules protect the subscriber. When a delay that was not the payer's doing has pushed the schedule into the past, each retry after a counted failure keeps its gap from the one before instead of all falling due at once. And no charge is built in the last five minutes of a period, because a charge sent then could land in the next one. If a whole period passes uncollected, it is not billed later: Fianto never back-bills.

An unbroken run of network errors on one period for half an hour raises an alert to Fianto. What the merchant and the customer see while a renewal is retried is in failed renewals and retries, and the counted reasons are listed in the subscription lifecycle docs.

What happens to a transaction nobody can account for?

A transaction whose fate Fianto cannot establish from the chain is held as undecidable and handed to a person; it is never failed automatically. That matters most during an incident, when RPC providers lag, restart or stop answering.

1. Once the blockhash is past its last valid block plus 150, the tracker asks every RPC provider Fianto is configured with, each on its own.
2. If any provider knows the signature, the chain decides: the payment settles or fails on what that provider reports.
3. If a provider stays silent, nothing is decided. "Unknown everywhere" has to be an answer from every provider, not a silence.
4. If every provider says it has never seen the signature and none ever reported it confirmed, the payment is dropped and the customer may pay again.
5. If a provider once reported it confirmed and every provider has since forgotten it, the payment is held. Dropping it could reopen a session whose money already moved.
6. A row still undecidable 30 minutes after it passed that 150-block margin raises an alert. A person checks the chain by hand and records an outcome with an audited support command that takes a ticket and the operator's name; the tracker applies it only while every provider still says unknown.

The difference between a transaction that never landed and one that landed and failed is in dropped vs failed Solana transactions.

What should a merchant do while Solana is down?

While Solana is down, a merchant should wait for the network and for Fianto's webhooks rather than act on what a customer reports. Concretely:

1. Check status.solana.com to see whether the incident is Solana-wide.
2. Grant access from webhooks, not from a customer's screenshot. A payment counts when order.paid or subscription.renewed arrives, and a webhook that cannot be delivered is retried for about 28 hours.
3. Do not refund or ask for a second payment while a payment is pending. Refunds are USDC you send back from your own wallet, and a pending payment may still land.
4. Afterwards, open Needs attention in the dashboard. It lists past-due subscriptions and orders with an unmatched transfer, such as a customer who paid twice.

None of this needs a setting. Renewal retries are fixed, and how one renews from a single approval is on the stablecoin auto-renewal page.