Setting Up Subscriptions and Recurring Payments on Solana

A customer approves a USDC renewal once, then your backend wakes up on billing day and discovers that every payment still needs a wallet signature. The product works, but the subscription experience feels like a sequence of crypto invoices. You're left choosing between custom smart-contract logic, fragile timers, or a centralized payment processor.

Solana's native Subscriptions and Allowances program changes that architecture. Recurring authorization can now be expressed through a shared onchain primitive, while the surrounding billing system still handles invoices, retries, entitlements, notifications, and reconciliation. The important distinction is simple: onchain authorization solves permissioned recurring transfers, not the entire subscription business.

Why Crypto Subscriptions Finally Work on Solana

Before native subscriptions, a developer building a crypto membership often had to ask the customer to approve every renewal. A creator might sell access in USDC, but the customer would still need to return to a payment page, connect a wallet, and sign again when the next period started. That friction undermined the basic promise of recurring revenue, especially for SaaS products and API services where access should continue until the customer cancels.

On June 2, 2026, Solana introduced native Subscriptions and Allowances, turning recurring billing from a custom smart-contract pattern into a first-class blockchain feature. The announcement describes Recurring Delegations, where a user authorizes a delegate to pull up to a defined amount on a repeating cadence, such as $500 every two weeks, with the cap resetting each cycle. Solana's native Subscriptions and Allowances announcement explains the protocol-level design and its bounded authorization model.

Three ways to authorize crypto payments

The program gives developers three useful models:

• Allowances set a total spending cap, with an optional expiry. This fits a bounded wallet permission or a limited purchasing budget.
• Recurring delegations authorize a delegate to pull up to a specified amount during each period. The payer controls the amount, cadence, start time, and expiry.
• Subscription plans let a merchant publish billing terms that a customer accepts once. An approved merchant or collector can then collect during each billing period.

That separation matters. A creator membership might use a fixed subscription plan, while an AI agent could receive a recurring USDC budget. A usage-based API may prefer a recurring delegation with a cap, then draw smaller charges as the customer consumes service.

Solana's payment activity also gave this feature a practical foundation. CoinGate's 2024 to 2025 Solana payments report recorded a 66% year-over-year increase in SOL-denominated payments and a 94% year-over-year increase in payments processed on the Solana network. Solana reached 8.4% of CoinGate payments at its September peak and represented 3.2% across the full period. In 2025, 68% of payments on the Solana network used SOL, 28% used USDC, and 4% used USDT, showing that both native SOL and stablecoins already formed part of active payment behavior.

Practical rule: Use the chain to enforce consent and spending boundaries. Keep customer lifecycle logic in the billing application.

That division is what makes predictable revenue for founders realistic for crypto products. Solana handles the authorization and transfer constraints, while your application decides who receives access, when an invoice is due, and what happens after a failed collection.

Choosing Between On-Chain and Off-Chain Scheduling

The subscription program doesn't wake up by itself when a billing period begins. Someone still has to submit the collection transaction. Your first architectural decision is therefore whether the recurring authorization should carry most of the billing responsibility, or whether an off-chain worker should manage the schedule and use the authorization only when a charge is due.

Start with the payment rule rather than the infrastructure.

Choose recurring delegation for bounded recurring charges

A recurring delegation works well when the payer defines a straightforward limit. Consider a crypto payroll arrangement where a contractor can pull an agreed token amount during each period. The onchain account can express the period amount, period length, start time, and expiry without storing your application's entire invoice history.

This design reduces trust in your backend. The delegate can't exceed the authorized amount or continue beyond the allowed lifecycle. It also suits a creator membership with a fixed USDC price, provided your worker still submits the transfer when the period is due.

The trade-off is operational complexity. You must detect when a period is available, submit the transaction, handle insufficient balances, and reconcile ambiguous outcomes. Onchain constraints protect the funds, but they don't decide whether a customer should receive a grace period.

Use off-chain scheduling when billing depends on business state

A hybrid design is usually better for usage-based crypto billing. Suppose an API customer has a recurring cap but the final charge depends on metered requests, discounts, credits, or an upgrade. Your billing worker can calculate the amount, check account state, and submit a pull that remains within the customer's authorization.

This approach gives you familiar controls for invoices and entitlements, but it introduces infrastructure that must stay reliable. Store an idempotency key for every billing attempt, record the intended amount before submission, and reconcile the result from chain data instead of treating an RPC response as final business truth.

Solana Tracker's Datastream WebSocket feeds can support either architecture by delivering wallet activity and token-transfer events to the billing service. Its low-latency RPC is useful when the worker needs current account state before creating a transaction. The key is not to confuse fast data with a complete scheduler. You still need durable jobs, retry policy, and a clear state machine.

Billing requirement	Better starting point	Main trade-off
Fixed recurring amount	Onchain recurring delegation	Simpler authorization, harder retry handling
Metered API usage	Hybrid worker and delegation	Flexible billing, more off-chain responsibility
Merchant-defined tiers	Subscription plans	Clear consent, immutable plan migration
Payroll or contractor pull	Recurring delegation	Strong bounds, recipient-driven collection

Implementing Recurring Delegation with Solana Tracker

The recurring-delegation flow is deliberately explicit. A client starts with the user signer and subscriptions plugin, derives the relevant accounts, initializes the authority when needed, and creates the recurring authorization with its billing parameters.

Build the authorization in a safe order

Use this sequence:

1. Create the client with the user signer and subscriptions plugin. The user must sign the authority setup and delegation approval.
2. Derive the user token account. The billing asset must already have a usable token account.
3. Derive the Subscription Authority PDA. This authority is associated with the user and token mint.
4. Derive the recurring-delegation PDA. Treat this account as the independent state record for that recurring relationship.
5. Fetch before initializing. If the Subscription Authority already exists, reuse it instead of submitting a duplicate initialization transaction.
6. Create the delegation. Supply the period amount, period length, start time, and expiry.
7. Persist identifiers. Store the delegation PDA, mint, customer, merchant, and your internal subscription ID together.

The core client pattern looks like this:

client = createClient(userSigner)
  .use(subscriptionsPlugin)

userTokenAccount = deriveUserTokenAccount(user, billingMint)
authorityPda = deriveSubscriptionAuthority(user, billingMint)
delegationPda = deriveRecurringDelegation(authorityPda, delegate)

if authorityPda does not exist:
  initializeSubscriptionAuthority(userTokenAccount)

createRecurringDelegation(
  periodAmount,
  periodLength,
  startTime,
  expiry
)

The exact helper names depend on the client version you adopt, so pin your package versions and validate the generated instruction accounts against the current Solana documentation. The official recurring-delegation implementation flow establishes the required derivations and parameters.

Keep token routing separate from authorization

A customer may hold SOL while your plan accepts USDC. Don't hide that conversion inside the subscription authorization. Use a swap transaction before enrollment, or let the customer fund the billing token account through your normal wallet flow.

If your product needs programmatic conversion, Solana Tracker's Raptor Swap API can route a token swap across Solana liquidity venues. The subscription program should still authorize only the billing mint and bounded amount. That separation makes pricing, slippage handling, and payment consent easier to audit.

Before collection, query the customer's token balance and the subscription account. Solana Tracker's Data API can provide indexed wallet and token-account data for the billing worker, while RPC remains the authority for final onchain reads and transaction submission. Its low-latency RPC and Shredstream-oriented infrastructure can help reduce the delay between detecting a due payment and tracking confirmation, but your worker should still treat confirmation and reconciliation as separate states.

Handling Stateful Billing Edge Cases

The happy path is short: create a plan, accept it, collect the amount, and grant access. Production billing breaks in the space between those actions. Price changes, missed jobs, insufficient balances, refunds, and cancellation timing all create state transitions that a basic transfer example doesn't model.

Plan changes require migration logic

Solana subscription plans are immutable. If a merchant changes the price, billing period, or other fixed terms, the old plan must be sunset and a new plan must be created. Existing subscribers don't automatically inherit the new price, which protects consent but forces your application to manage migration.

A safe migration flow looks like this:

• Publish the replacement plan with the new crypto billing terms.
• Notify the customer and show the exact change before asking for approval.
• Preserve the old entitlement until its current period ends.
• Create the new subscription only after the customer accepts it.
• Cancel or expire the old authorization according to your product policy.
• Record both PDAs against one internal subscription history.

Don't delete the old record from your database. It explains why a historical invoice used the previous amount and gives support staff a reliable audit trail.

Missed pulls need an explicit policy

The program authorizes a pull, but it doesn't create a retry queue. If your worker is offline or a transaction fails, decide whether the customer owes the missed period, whether you skip it, or whether you create an ordinary open invoice.

For insufficient USDC, a bounded retry policy is safer than endlessly resubmitting transactions. Check the balance, wait for a meaningful customer action such as a top-up, and prevent duplicate collection with an idempotency record. For a refund, keep the original charge immutable and create a separate outbound refund transaction with its own status.

The chain can prove whether a transfer happened. It can't decide whether a failed renewal deserves access, a retry, or a refund.

Validate entitlement against onchain time. Solana's guide recommends checking expiresAtTs against onchain time rather than relying only on an off-chain timer, which prevents an expired subscription from continuing to serve paid access or being charged after its validity ends. The Solana refund guidance can sit alongside this workflow when your product needs a customer-facing refund path.

Datastream wallet activity can help detect failed attempts, balance changes, and later top-ups. Your reconciliation worker should compare those events with internal invoices, then move each invoice to a clear state such as paid, failed, awaiting funding, canceled, or refunded.

Security and UX Best Practices for Crypto Billing

A recurring authorization is powerful because it removes repeated signatures. That same convenience makes the consent screen, spending limit, destination rules, and cancellation path part of your security boundary.

Before attempting a charge, validate the operational prerequisites:

• Receiving account: The merchant must have a receiving USDC token account, and it must match an approved destination.
• Customer balance: The subscriber must hold enough of the billing asset for the requested pull.
• Authorization state: Confirm the subscription PDA is active, unexpired, and within its current period allowance.
• Mint consistency: Reject transactions that use a different mint or token program than the accepted terms.
• Collector permissions: Restrict collection to the merchant or explicitly approved pullers.

Use bounded exposure by default. A recurring delegation should have a period cap and an expiry, even if your application expects the relationship to continue. Give the customer a prominent revoke or cancel action, explain whether cancellation ends access immediately or at the current period's end, and display the authorized token, amount, cadence, and recipient in plain language.

A crypto invoice can offer two payment modes. Manual mode asks the user to approve every renewal, which is appropriate for high-value or irregular charges. Automatic mode asks for one wallet authorization, then lets the approved collector charge each invoice in USDC without another signature. A Solana billing example from Helius' crypto payment documentation demonstrates this distinction directly.

Token safety also belongs in the payment flow. Use Rugcheck scoring before accepting unfamiliar tokens, especially when your product supports assets beyond an established stablecoin. Wallet monitoring can add another signal for suspicious behavior, but don't turn risk scores into an invisible denial system. Explain why a payment was blocked and provide a controlled recovery path.

Operational communication matters too. A failed wallet charge should produce a useful email and dashboard message, not a generic “payment error.” Teams improving lifecycle messaging can also review password reset email delivery fixes, because the same principles apply to renewal notices, funding reminders, and cancellation confirmations.

Monitoring and Reconciling Subscription Payments

Treat every renewal as a small accounting workflow, not a single transaction call. Create an internal payment attempt before submission, attach the subscription PDA and expected amount, then update the record only after indexed chain data confirms the result.

A practical reconciliation loop has four stages:

1. Schedule: Identify subscriptions whose period and expiresAtTs make them eligible.
2. Preflight: Check the billing mint, customer balance, destination account, and remaining allowance.
3. Submit: Send the collection transaction and store its signature with the invoice attempt.
4. Reconcile: Match confirmed token transfers against the expected payer, recipient, mint, amount, and billing period.

Solana Tracker's Datastream WebSocket feeds can stream wallet activity and token transfers into this process. Its Data API exposes 70+ endpoints for indexed token, wallet, trade, price, and risk data, which can support dashboards for active subscriptions, recognized revenue, failed collections, and churn. Use RPC for authoritative account checks and indexed data for operational search and reporting.

Network congestion and failed transactions require a distinction between “not confirmed yet” and “did not happen.” Don't issue a second charge merely because the first RPC request timed out. Query the signature and inspect the resulting transfer before retrying. Wallet Tracker can add context around balance changes and transaction patterns, while Rugcheck risk scoring can flag suspicious assets or wallets before a payment is accepted.

For acquisition reporting, connect the wallet subscription record to your application's signup metadata. Teams that need to identify signup sources with SourceLoop can use the same principle for crypto subscriptions, preserving source data alongside the wallet address and internal customer ID without putting marketing state onchain.

---

Solana Tracker combines low-latency RPC, real-time Datastream feeds, indexed Data API endpoints, Raptor Swap routing, wallet monitoring, and Rugcheck risk analysis for subscription payment operations. Visit Solana Tracker to evaluate the infrastructure, then build your billing worker around explicit authorization, durable payment states, and reconciliation from confirmed Solana data.