![\"\"](\"https:\/\/nownodes.io\/blog\/wp-content\/uploads\/2026\/10\/image-89-960x1024.png\")
<\/figure>\n\n\n\nSolana Pay is a specification for encoding a payment request inside a URL that starts with Because the request is just a URL, it fits inside a QR code. A shop can print one next to the register, a website can show one at checkout, and an invoice can carry one in an email. The reference implementation is the open-source Solana Pay defines two request types, and the choice shapes how much control you have over the payment.<\/p>\n\n\n\n A transfer request<\/strong> is the simpler one. It is a non-interactive request to move SOL or an SPL token straight to your address. You set the A transaction request<\/strong> is interactive and more flexible. Instead of describing a transfer, the URL points to an endpoint you control. The wallet calls that endpoint, sends the customer’s public key, and your server returns a fully built transaction encoded in base64. The wallet then asks the customer to sign it. This lets you do things a plain transfer can’t, like splitting a payment, adding a fee, minting a receipt NFT, or gating the purchase behind a rule. The full field list is in the Solana Pay specification<\/a>.<\/p>\n\n\n The practical reasons are cost and speed. Solana’s base fee is 5,000 lamports per signature, which is 0.000005 SOL, a fraction of a cent at typical prices (Solana docs<\/a>). For a merchant that usually means the network cost of accepting a payment is negligible, even on small purchases where card fees would eat the margin.<\/p>\n\n\n\n Settlement is also fast. Solana produces a new block roughly every 400 milliseconds, and a payment is usually safe to treat as confirmed within about half a second, with full deterministic finality taking longer (Helius<\/a>). The Alpenglow consensus upgrade, rolling out across the network in 2026, is designed to push median finality down to around 150 milliseconds, closing most of the remaining gap with traditional card authorization.<\/p>\n\n\n\n There is a trade-off worth naming. Crypto payments are final once they land, so there is no built-in chargeback. That protects the merchant from fraudulent reversals, but it also means refund logic is your responsibility, not the network’s.<\/p>\n\n\n The standard was built for commerce, so the users are mostly people selling something.<\/p>\n\n\n\n A common thread is stablecoins. Since a transfer request can specify any SPL token mint, most real-world checkout flows accept USDC instead of SOL, which removes price swings between the moment a customer pays and the moment a merchant books the revenue.<\/p>\n\n\n At a high level, accepting a single payment follows the same sequence whether it is in a shop or on a web page. Here is the flow using the The reference trick matters because your server never receives the transaction signature directly. The customer’s wallet submits the transaction, not you.<\/p>\n\n\n You confirm a payment by watching for the reference key you attached, then checking the transaction details. The library’s How certain you need to be depends on the purchase. Solana exposes commitment levels, This is the layer where infrastructure choice starts to matter, since both submitting transactions and monitoring for confirmations run through a Solana node endpoint.<\/p>\n\n\n Solana Pay does not do subscriptions. A payment request is a one-time event: the customer approves one transfer and nothing more happens on its own. Recurring billing needs a way for a merchant to pull a payment later, on a schedule, with the customer’s prior consent and no second signature each time.<\/p>\n\n\n\n On Solana that consent comes from token delegation<\/strong>. A token owner can approve another account to move a limited amount of their tokens. The official Subscriptions Delegation Program<\/a> builds a structured billing system on top of this idea, with code published in the solana-program\/subscriptions<\/a> repository and an audit by Cantina.<\/p>\n\n\n\n The design works around one Solana rule: a token account can only have a single approved authority at a time. To avoid clashes, the program gives each user-and-token pair a program-controlled “Subscription Authority” that the user approves once. That authority can’t move funds on its own. Every charge has to match an active authorization the user created, with its own limits.<\/p>\n\n\n The program supports three authorization models, and the right one depends on how predictable the charges are.<\/p>\n\n\n\n In code, these map to calls like The controls are deliberately tight, which is what makes delegated billing safe to offer customers.<\/p>\n\n\n\n That last point is the main operational difference from a card subscription. The blockchain guarantees the limits, not the timing. You run the clock.<\/p>\n\n\n Every part of this, broadcasting a signed payment, watching for the reference, and submitting recurring charges on schedule, depends on a connection to the Solana network. Running and syncing your own validator to do that is heavy, so most teams use a managed endpoint instead.<\/p>\n\n\n\n This is where NOWNodes<\/a> fits. It provides Solana RPC endpoints<\/a> for reading state and sending transactions, WebSocket subscriptions for watching address activity without constant polling, and gRPC streaming for continuous updates with commitment-level choices (processed, confirmed, or finalized) that line up directly with how you confirm a payment. For a recurring-billing backend, that steady access is what keeps collectors charging on time across many subscribers.<\/p>\n\n\n\nsolana:<\/code>. A wallet reads that URL, shows the customer what they are about to pay, and submits the transaction to the network. It does not add new blockchain features. It reuses Solana’s existing signing and transfer rules and agrees on a common format so any compatible wallet behaves the same way.<\/p>\n\n\n\n@solana\/pay<\/code><\/a> JavaScript library, which generates these requests, renders the QR codes, and helps you match an incoming payment back to the right order.<\/p>\n\n\nWhat’s the Difference Between a Transfer Request and a Transaction Request?<\/h3>\n\n\n
recipient<\/code> (your public key) and usually an amount<\/code>, plus optional fields like spl-token<\/code> for the mint, a reference<\/code> key, and a human-readable label<\/code> and message<\/code>. The wallet builds the transfer from those parameters alone.<\/p>\n\n\n\nWhy Accept Payments on Solana in the First Place?<\/h2>\n\n\n
Who Actually Uses Solana Pay?<\/h2>\n\n\n
\n
How Do You Set Up a Solana Payment Request?<\/h2>\n\n\n
@solana\/pay<\/code> library.<\/p>\n\n\n\n\n
reference<\/code>. This is not a signer; it is a marker attached to the transaction so you can find it later. One reference per order keeps your payments distinct.<\/li>\n\n\n\nencodeURL<\/code> turns these into a solana:<\/code> URL.<\/li>\n\n\n\ncreateQR<\/code>, which produces a scannable code. The default size is 512 pixels, and you can set the background and foreground colors.<\/li>\n\n\n\nHow Do You Confirm a Payment Went Through?<\/h3>\n\n\n
findReference<\/code> helper looks up a transaction by its reference, and under the hood it uses the standard getSignaturesForAddress<\/code> method. Once you have the signature, you validate that the recipient, amount, and token mint match what you expected before marking the order paid.<\/p>\n\n\n\nprocessed<\/code>, confirmed<\/code>, and finalized<\/code>, that trade speed for certainty. A coffee can ship on confirmed<\/code>; a high-value transfer is better held until finalized<\/code>. Polling works for low volume, but a busy checkout is better served by a persistent connection that pushes updates as they happen, which is where a WebSocket or streaming interface fits.<\/p>\n\n\n\nHow Do Recurring Payments Work on Solana?<\/h2>\n\n\n
Fixed, Recurring, or Subscription Plan: Which Model?<\/h3>\n\n\n
![\"\"](\"https:\/\/nownodes.io\/blog\/wp-content\/uploads\/2026\/10\/image-90-1024x683.png\")
<\/figure>\n\n\n\nModel<\/th> What it allows<\/th> Good for<\/th><\/tr><\/thead> Fixed delegation<\/strong><\/td> Spend up to a fixed total, with an optional expiry<\/td> Prepaid caps, metered or usage-based billing<\/td><\/tr> Recurring delegation<\/strong><\/td> An allowance that resets every period (daily, weekly, monthly)<\/td> Flat-rate subscriptions<\/td><\/tr> Subscription plan<\/strong><\/td> A merchant publishes billing terms; approved collectors charge each enrolled subscriber per period<\/td> SaaS-style billing across many customers<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n transferFixed<\/code>, transferRecurring<\/code>, and transferSubscription<\/code>. The program also supports Token-2022 transfer hooks, so tokens with extra on-chain logic still work inside a subscription.<\/p>\n\n\nWhat Are the Limits and Risks?<\/h3>\n\n\n
\n
amountPerPeriod<\/code> sets the most a collector can pull in one period. The allowance resets when the next period begins, so a charge that exceeds the remaining allowance is rejected.<\/li>\n\n\n\nexpiryTs<\/code> is a firm stop. After it passes, transfers fail, and the documentation notes there is no grace period.<\/li>\n\n\n\nReliable Solana Access for Payments and Billing<\/h2>\n\n\n