Subscription billing on Solana: build it or use Mesub
The Solana Subscriptions program already moves the money and enforces the limits. It is open source, audited, and it guarantees that a customer is never charged more than the plan's amount in a period.
What it does not do is run your billing. This page lists that work, item by item, so you can decide whether to build it. Sometimes you should.
The case for building it
The program is free to use and MIT licensed. Your wallet owns the plan and receives the money. Helius, the Solana RPC provider, is integrating it to bill its own API plans.
If your team already runs scheduled jobs it trusts, has someone on call when they stop, and wants full control of every rule, building is a reasonable choice. The list below is what you would sign up for.
What you would build
1. A scheduler that never misses a period
Something must wake up when each payment is due and send it. The program never does.
- When exactly is each subscription due? The period on chain moves only when a payment lands, so your records and the chain can disagree by a period.
- What if your job runs twice? Here the program protects you: it refuses a second payment above the amount for the period.
- What if your job is down for a day? Then a payment is late. If it is down for a whole period, that period is gone. The program never collects a past period, only the current one.
2. A key that may collect, and SOL to pay for it
Only the plan's owner, or one of the four pullers listed on the plan, can sign a payment.
- That key lives on a server that runs all day. Where do you keep it, and who can use it?
- Every payment costs a network fee, paid in SOL by a fee payer wallet. When it runs dry, every payment of every plan stops at once. You will want an alert well before that.
3. Telling a short wallet from a broken subscription
The program has no "late" state: a subscription reads as active even when the payment cannot go through (why).
- A wallet that is short of funds can pay later: retry.
- A wallet whose approval was replaced by another app cannot pay until it approves the authority again: retrying before that wastes fees.
- A wallet whose authority was closed will never pay on this subscription again: the customer has to start a new one.
- How many retries, how far apart? They must all fit inside the period: once it ends, its payment can no longer be collected.
4. Telling the customer
- Before a renewal, read the customer's wallet and warn them if the payment will not go through.
- When a payment fails, email them with what to do. A wallet gives you no email address: you have to ask for one, and keep it.
5. Deciding who has access
Your app needs one answer: may this customer use the paid feature right now?
- The account on chain cannot answer it alone, for the reason in item 3.
- A customer who cancels keeps access until the end of the period they paid for.
- A customer whose payment failed: on or off while you retry? You decide, and every route of your app must agree.
6. Keeping your records true to the chain
- A payment you recorded as failed can still land: a Solana transaction can still land for about 150 blocks after it was built, around half a minute.
- A customer can close a subscription and subscribe again. The new one lives at the same address as the old one, and your records must tell them apart.
- Your server can crash in the middle of a payment. When it comes back, it must know whether the money moved.
7. Telling the rest of your stack
- Webhooks when a subscription starts, renews, fails, is cancelled or ends: signed, retried when your endpoint is down.
- A history your support team can read when a customer writes "I was charged twice".
8. The sharp edges of Solana itself
- A token account has one delegate. If the customer approves another app on the same account, every subscription in that token stops being collectable, silently, until the wallet approves the authority again.
- A wallet that removed its approval by hand can bring it back without a new signature on your plan, and its old subscriptions become collectable again.
How we tested ours
Each item above is a part of Mesub, and several came from tests on devnet with real wallets. One example: on October 18, 2026, in the middle of a payment, we killed the server that sends it. When it came back, there was one transfer on chain, not two, and our records caught up when the five-minute lease that guards each payment ran out. Mesub also compares the chain with its records every day.
Who notices a billing mistake, and when?
Before you build, ask what each of these would cost you, and who would see it first:
| Mistake | Who notices | When |
|---|---|---|
| A payment is never sent | Nobody | Maybe never. The period cannot be collected later |
| Access stays on for someone who stopped paying | You | When you count the money |
| Access is cut for someone who paid | The customer | At once, in an email to support |
| The fee payer runs dry | Nobody, at first | Every payment stops, and each period without one is lost |
If your team would catch all four quickly, build it. If not, that is the work Mesub does.
Build it yourself if
- billing is part of your product, and you want every rule in your own code;
- you need something Mesub does not offer, such as the program's fixed or recurring delegations instead of plans;
- you already run reliable scheduled jobs, with someone on call.
Use Mesub if
- you want to charge your first subscriber this week;
- you have no one on call for a payment job;
- you need retries, warnings, access and history on top of the payment.
What you keep either way
- Your plans are yours. Your wallet owns them on chain. Mesub is one of the plan's pullers. If you leave, your subscriptions stay where they are: as the owner, you can add your own puller and collect with your own code.
- The money goes to your wallet. Mesub holds no funds. To make sure only your wallets can ever receive, list them as the plan's destinations when you create it.
- The price is flat. Free: $0, 1 plan, 30 subscribers, no automatic retries. Dev: 20 USDC every 30 days, 3 plans, 150 subscribers, with automatic retries. Business: custom. Not a percentage of what you collect.
Ready to try? Accept USDC subscriptions in your app takes an empty project to a first paying subscriber.
Sources: the Subscriptions program at build 364a419 (README, ADR-002, transfer_validation.rs for the period rule); the Solana Foundation announcement, June 2026, for Helius; docs.mesub.io for Mesub's behavior and prices.