Solana Pay has no recurring payments, and the reason is in how a request ends.

What is Solana Pay?

Solana Pay is an open standard for putting a payment request inside a URL, so any wallet that reads the URL can pay it. The spec describes itself as "a standard protocol to encode Solana transaction requests within URLs to enable payments and other use cases." It is not a company, a checkout page or a processor, and it charges no fee of its own. It defines two kinds of request:

• A transfer request, in the spec's words, "describes a non-interactive request for a SOL or SPL Token transfer." The URL carries the recipient, the amount and the token, and the wallet builds the transfer itself.
• A transaction request "describes an interactive request for any Solana transaction." The wallet calls the merchant's server, the server returns a transaction, and the wallet validates it "as untrusted" and signs it.

An SPL token is any token issued on Solana's token programs; USDC is one. A wallet signature is the customer's approval of one specific transaction, with its amounts and accounts fixed at the moment of signing.

Why can't Solana Pay take recurring payments?

Solana Pay cannot take recurring payments because every request produces one transaction that the customer signs once, and that signature cannot be replayed next month. Solana's documentation says "a transaction's recent blockhash is valid for 150 slots", so a signed payment either lands soon or expires. There is no field in either request type for a period, a cap or a second charge.

A recurring payment needs something different in kind: a standing permission, stored on chain, that lets a named party move a limited amount from the wallet later without a new signature. Solana Pay never creates one. A merchant using it for a monthly plan has to send a fresh request every month and hope the customer pays it, which is a reminder system, not a subscription.

The comparison below puts the two Solana Pay requests next to the Subscriptions program, the part of Solana that does handle recurring payments.

What do you use for recurring payments on Solana instead?

For recurring payments on Solana you use the Subscriptions program, a public program on Solana at De1egAFMkMWZSN5rYXRj9CAdheBamobVNubTsi9avR44. Solana's docs describe three models, compared in Solana Subscriptions and Allowances, for merchants. A fixed delegation lets another party "spend up to a fixed total amount"; a recurring delegation lets it "spend up to a limit that resets every period"; and a subscription plan lets "a merchant publish billing terms that users can accept."

The plan model is the one built for selling subscriptions, because the merchant writes the terms once and every subscriber accepts the same ones. Fianto uses it: each recurring price gets a plan that fixes the amount per period (the price plus fees), the period (30 or 365 days) and the wallets the money may go to, and names the keys allowed to collect. The customer signs once at checkout; the program refuses any later charge above the cap or to another wallet. The delegation underneath is explained in Solana token delegation explained, and the head-term page on Solana subscriptions covers the fees and the wallets that work.

With Fianto the merchant pays nothing, not even the SOL for renewals. The customer pays 0.01 USDC with each subscription charge today, the Solana fee of the subscribe transaction (under $0.01), and account rent. As of 15 October 2026 that is about 0.00144 SOL for the subscription account, returned when they reclaim it after the subscription ends, and about 0.00119 SOL once on a wallet's first subscription, not returned; Solana is cutting rent in phases, so the checkout shows the exact live amount.

What does a Solana Pay request look like next to a subscription?

A Solana Pay transfer request for 20 USDC is a single URL. The format follows the spec; the recipient and reference here are placeholders, and the token is the USDC mint Circle lists for Solana:

solana:<recipient-wallet>
  ?amount=20
  &spl-token=EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
  &reference=<one-time-public-key>
  &label=Quillfern%20Labs
  &message=Pro%20plan%2C%20October

Everything that request can do is in that line: one transfer of 20 USDC to one wallet. To bill the same customer in November you create a new URL with a new reference, and they scan or click it again.

A Fianto subscription for the same 20 USDC a month asks for one signature too, but the transaction does more. It sets up the wallet's approval for the program if the wallet has none, subscribes the wallet to the plan with a cap of 20.01 USDC per 30 days (the price plus today's 0.01 USDC network fee, with no Fianto fee during the beta), and pays the first period. Two minutes after each 30-day period ends, Fianto's charging key collects the next one. If the wallet is short, Fianto tries again one hour, six hours and a day after the period boundary, and the fourth failure ends the subscription.

How is Fianto's checkout related to a Solana Pay transaction request?

Fianto's one-off checkout borrows two ideas from Solana Pay, but it is not a Solana Pay URL. The first is the server-built transaction. As in a transaction request, Fianto's server builds the payment and the customer's wallet only signs it, here through the Wallet Standard solana:signTransaction feature in a browser rather than through a solana: link. A wallet that can only sign-and-send is refused with wallet_unsupported, because Fianto broadcasts the transaction itself.

The second is the reference key. Solana Pay's spec lets a request add a reference account because "Solana validators index transactions by these account keys", so a merchant can find the payment with the getSignaturesForAddress RPC method. Fianto adds a 32-byte reference to the transfer to the merchant for the same reason, and a sweep finds the payment by that address if anything else misses it.

What Fianto adds is checking. Before broadcasting, the backend decodes the signed bytes the wallet returns and refuses them unless every part matches what it built: the fee payer, the programs, each transfer's mint, source, destination and amount, the reference and the blockhash. Then it waits for the chain. The customer sees success at confirmed, and the order turns PAID, with a signed order.paid webhook, only at finalized; confirmed vs finalized explains the gap. The docs page on the payment lifecycle has each state.

When is plain Solana Pay enough?

Plain Solana Pay is enough when every payment is a one-off and you are happy to confirm payments yourself. It fits well for:

• In-person sales, where a QR code at the counter is faster than any checkout page.
• Tips and donations of whatever amount the payer picks.
• A developer who wants no third party at all and will watch the chain for each reference.

It stops being enough once you need the same customer to pay again without being asked, or you want a hosted page, signed webhooks, a dashboard and a cancel portal around the payment. That is the point to compare it with a hosted checkout; what a hosted USDC checkout does that a wallet address does not walks through the difference, and accepting USDC on Solana covers the one-off setup.