Crypto apps have been great at one-off transfers. They have been awkward at boring business payments. Subscriptions, spending limits, payroll, API billing, and agent budgets usually push teams back to Stripe-like rails or custom custody logic.
Solana just made that gap smaller. On June 2, 2026, the Solana Foundation announced that Subscriptions and Allowances are live on mainnet as a shared onchain program. Moonsong Labs, which built the program with the foundation, says the new primitive supports recurring billing, delegated spending, and agentic payment flows without every app building its own payment layer.
For developers, that is the actual story. This is less about another payment demo and more about whether Web3 apps can finally handle normal billing flows without duct tape.
What Solana launched
The new Subscriptions Delegation Program lets users approve future token transfers with limits. The docs describe it as a way for developers to let users authorize payments where they should not have to sign every transfer manually.
The problem comes from how Solana token accounts work. A token account can approve another authority, but only one approved authority at a time. That is fine for a simple payment. It gets messy when the same wallet wants a monthly subscription, a spending cap for an AI agent, and a merchant billing agreement at the same time.
Solana’s program adds a program-controlled Subscription Authority for each user and token mint pair. The user approves that authority once. After that, the program checks every transfer against separate records that define who can pull funds, how much they can pull, and when that permission expires or resets.
That sounds dry. Good. Payment infrastructure should sound a bit dry.
The three payment patterns
Solana’s announcement groups the feature into three models:
| Model | Best fit |
|---|---|
| Fixed allowance | One-time delegated spending with a cap and optional expiry |
| Recurring delegation | Payroll, contractor payments, API billing, repeat charges |
| Subscription plan | SaaS, media, membership, merchant billing |
The fixed allowance model is probably the one developers will underestimate. It fits a growing pattern in Web3 apps: users want agents, bots, or embedded services to act for them, but only inside a budget.
That is a saner model than asking users to sign every tiny action or handing over too much control.
Why developers should care
The usual Web3 payment flow breaks as soon as money movement becomes repeated. Users get signature fatigue. Apps add backend workarounds. Teams rebuild the same approval logic. Security reviewers then have to inspect a custom pile of contracts and cron jobs.
A shared program changes the default. If wallets, payment providers, and app developers use the same primitive, the behavior becomes easier to explain and easier to audit.
Moonsong’s launch post says launch partners are using it for API tier subscriptions, onchain checkout from wallets, and stablecoin invoice collection. Those examples matter because they are not casino use cases. They look like boring invoices and developer bills.
That is where stablecoin payments can actually stick.
The AI agent angle is real, but be careful
The spicy part is agentic commerce. Solana links the launch to agent budgets, and the announcement points to a subscription intent specification in the MPP specs repo.
The safe version is simple: a user gives an agent a capped allowance, the agent spends inside that limit, and the permission expires. That is much better than a bot with broad wallet access.
But teams should not treat allowances as a magic security layer. You still need clear UI, warnings for recurring pulls, sane defaults, logs users can read, and a fast way to revoke permissions. If the app hides the spending rule behind vague copy, the chain primitive will not save the user.
What to check before integrating it
Start with the official Solana docs, then read the program repository before wiring it into production. The GitHub repo is public under solana-foundation/subscriptions, and at launch it describes itself as a Solana program for third-party asset delegations.
A practical checklist:
- Pick the smallest payment model that fits the product.
- Show the amount, cadence, delegate, token, and expiry in plain language.
- Add revoke controls where users can find them.
- Test failed pulls, expired permissions, low balances, and token-account edge cases.
- Do not market an allowance as “safe” if the spending cap is too high.
The boring edge cases are where payment products usually get cooked.
The bigger point
Solana is trying to make onchain payments feel less like a transaction terminal and more like an app platform. MoneyGram joining the Solana Developer Platform in June 2026 tells the same story from the enterprise side: payments teams want APIs, compliance paths, and reliable infrastructure, not just wallet popups.
Subscriptions and allowances will not make every app better overnight. Some teams will overbuild. Some will ship confusing permission screens. But the primitive is useful because it maps to how real software already charges money.
If you build a Web3 app with paid plans, usage-based billing, stablecoin invoices, or agent wallets, this is worth testing now. Not because it is shiny. Because it removes one of the dumbest reasons Web3 products still feel unfinished.
Sources
- Solana Foundation: Solana Now Has Native Subscriptions & Allowances
- Solana Docs: Payments Subscriptions Overview
- Moonsong Labs: Building the Infrastructure Behind Subscriptions & Allowances on Solana
- GitHub: solana-foundation/subscriptions
- Solana Foundation: MoneyGram Joins Solana Developer Platform
