A Solana payment integration can receive a transaction signature from an RPC server before the transaction has been processed by the network. Solana's sendTransaction documentation explicitly distinguishes RPC acceptance from cluster confirmation. That distinction becomes particularly important when a payment appears to stall and an operator considers trying again. Solana RPC reference — sendTransaction ↗
Recent blockhashes create a validity window
The transaction's signature and its validity information form the starting point for a reliable investigation. A browser timeout alone says little about the eventual movement of funds.
An ordinary recent-blockhash transaction includes a blockhash that must remain recent enough for processing. Solana's confirmation guide describes the runtime's age check and explains how a transaction can expire before inclusion. It also notes that stale RPC information can leave less usable time than an application expects. Solana — Transaction Confirmation & Expiration ↗
This is why an interface should avoid converting a rough network timing estimate into an unconditional wall-clock deadline. The application needs the validity information associated with the blockhash it actually used, together with the network state needed to interpret it.
The getLatestBlockhash method returns both a recent blockhash and its lastValidBlockHeight. These values describe the same request context and should remain linked in the application's records. Solana RPC reference — getLatestBlockhash ↗
Confirmation requires a separate observation
The sendTransaction method relays a signed transaction and returns its first signature if the RPC accepts it. Its reference recommends using getSignatureStatuses to check processing and confirmation. A successful send response leaves that later check necessary. Solana RPC reference — sendTransaction ↗
For illustration, suppose a checkout submits a payment, stores the signature and then loses its network connection. A second screen may show no answer, while the first transaction may still reach the network. Building and signing a new payment immediately could create a second independent instruction. The service first needs to establish the original transaction's state to its chosen confirmation standard.
Rebroadcasting the same signed transaction and creating a new signed transaction are operationally different actions. A reconciliation log should make clear which occurred, rather than recording both simply as a retry.
Expiration and past execution must both be checked
Solana's confirmation guide recommends retaining lastValidBlockHeight and monitoring block height when establishing expiry. The important follow-up is whether the transaction had already been processed: expiry prevents a still-unprocessed transaction from later entering under that expired blockhash, but it does not undo a payment that was included earlier. Solana — Transaction Confirmation & Expiration ↗Solana RPC reference — getLatestBlockhash ↗
A payment record can therefore preserve the business reference, network, signature, recipient, asset, amount, blockhash context, last valid block height and observed result. These fields let support distinguish an expired unsent payment from a processed payment whose acknowledgement was lost.
Durable-nonce transactions use an alternative validity mechanism described in Solana's documentation. They require their own state tracking; the ordinary recent-blockhash procedure should not be applied to them without modification. Solana — Transaction Confirmation & Expiration ↗ Clear identification of the transaction type makes recovery more accurate and gives customers a status grounded in network evidence.