Crypto Subscription Billing Is Broken. Here's the First Real Fix

The short answer: almost everything marketed as "crypto subscriptions" today is a payment reminder dressed up as billing — at renewal time, the customer gets an email or wallet ping and has to manually pay again. That's not recurring billing; that's recurring asking. Real subscription billing means charges happen automatically, on schedule, without the customer doing anything — and doing that on a blockchain, without taking custody of anyone's funds, is a genuinely hard problem. This article explains why it's hard, how the fake versions work, and the architecture that finally makes recurring crypto payments real: customer-funded vaults whose terms are welded into the address itself. (Prefer seeing to reading? The sandbox runs the whole lifecycle with zero real money.)

Why recurring billing is fundamentally hard on-chain

Card billing works because cards are a pull system: the merchant (via Stripe) holds an authorization and pulls money on schedule. Crypto is a push system: nothing moves unless the key holder signs. There is no "authorization to charge me monthly" primitive on any major chain.

So everyone building crypto subscriptions faces a trilemma:

1. 1Ask the customer to push every cycle → not billing, just reminders (churn every single month)
2. 2Take custody — hold customer deposits centrally and deduct on schedule → real automation, but now you're a custodian: customers must trust you, regulators see client funds, and the "crypto" part is reduced to a deposit method
3. 3Unlimited token approvals — have customers grant a contract (or worse, a backend wallet) open-ended spending rights → automation with a security profile that has produced some of the ugliest exploits in the industry

Every "crypto subscription" product you've seen picks one of these. Most pick #1 and call the email a webhook.

What the fake versions look like (a field guide)

• The reminder model: at renewal, the platform fires a webhook/email; the customer must click and pay a fresh one-time invoice. Merchant-side churn management becomes a part-time job. If the customer is asleep, the subscription is over.
• The custodial balance model: customer tops up a balance held by the platform; the platform deducts monthly. It works — exactly the way a Web2 wallet works — and inherits every custody risk crypto was supposed to remove. The platform can freeze it, lose it, or be ordered to hand it over.
• The unlimited-approval model: a contract with open allowance pulls monthly. Better than custody, but the allowance is a standing attack surface, and the customer can't reason about the worst case ("what's the most this can take?" — answer: everything approved).

The real fix: a vault whose terms are the address

Finality's subscriptions are built on one idea: put the money where only the customer controls it, and weld the billing terms into the account's identity.

Here's the full lifecycle:

1. Subscribe = create a personal vault. The customer signs one transaction that creates a dedicated on-chain vault and deposits the first cycle (plus any prepayment they choose). Crucially, the vault's address is derived from the subscription terms themselves — amount per cycle, cycle length, recipients and their splits, promo pricing, total cycle cap. Change any term and you get a different address. The terms aren't stored in a database the platform could edit; they are the account's identity.

2. Charges happen automatically — but can only do one thing. A keeper process triggers each charge when it's due, paying the gas. The keeper has exactly one power: execute the charge as welded. It cannot change the amount, the schedule, or the destination — the on-chain program recomputes everything from the terms and refuses anything else. If the keeper disappeared, anyone could trigger charges permissionlessly; if the keeper turned malicious, it could do nothing but the agreed charge.

3. The customer stays in full control the whole time. The vault balance belongs to the customer. Withdraw anytime. Cancel anytime. Closing a subscription is one transaction that stops billing, returns the remaining balance, and refunds the account's rent deposit — on Solana, even the ~0.004 SOL the network requires to open the accounts comes back. There is no exit fee, because the deposit was never our money.

4. Merchant gets Stripe-grade ergonomics. subscription.active, subscription.charged, subscription.canceled webhooks; an overview API with MRR, active counts, and per-subscriber renewal health (vault balance, cycles remaining); customer-specific subscribe links; coupons and trial pricing. Your integration reads like subscription billing, because it is.

5. Upgrades and downgrades don't require trusting our math. Changing plans mid-cycle needs proration — and proration is where billing systems quietly cheat. Here, the backend proposes a credit, and the on-chain program recomputes it from first principles and reverts on mismatch. A dishonest platform (or a buggy one) cannot overcharge a plan change; the chain checks the arithmetic.

"What if the customer's vault runs dry?"

Then the subscription behaves the way both sides would want: a grace period (merchant-configurable, default 7 days) during which a top-up automatically resumes billing; past that, the subscription expires on-chain — the charge instruction itself refuses to execute. No zombie states, no "we'll keep trying your card for a month". The merchant sees an insufficient_balance event with enough lead time to run a retention play; the customer is never charged for a service window they've walked away from. (Grace, top-up, resume — all three flows are rehearsable in sandbox before you wire a single webhook.)

Compared honestly: Stripe Billing and the custodial "subscriptions"

Stripe Billing is excellent software, and if your customers pay by card, use it. What it cannot give you: settlement in minutes (card money takes days), freedom from chargebacks (subscription businesses eat disproportionate dispute volume), or custody-free flow of funds. Fees stack past 3% once billing tooling is included.

Custodial crypto "subscription" products can automate deductions — from balances they hold. You inherit account-freeze risk on top of whatever your customers think about depositing money with a third party. And products built on the reminder model aren't billing systems at all; they're CRMs for chasing renewals.

The vault model is the only architecture we know of that delivers all three simultaneously: automatic recurring charges, zero custody, and terms no one can alter after the fact. That's why we call it the first real crypto subscription billing — not the first to use the word, the first where the word means what it means.

What this looks like to integrate

# Create a plan
curl -X POST https://finality.money/v1/subscriptions/plans \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Pro Monthly",
    "amount": "9.99",
    "cycle": "monthly",
    "pricing_mode": "usd",
    "chain": "solana",
    "token": "USDC"
  }'
# → returns a shareable checkout URL for the plan

Handle two webhooks (subscription.active to provision, subscription.charged for renewals) and you're live. A sandbox plan with a "simulate payment" button lets you rehearse the entire lifecycle without moving money. Full details in the subscription docs; every endpoint is testable in the API explorer.

FAQ

What is a crypto subscription, exactly?

An arrangement where a merchant charges a customer's crypto automatically on a schedule — as opposed to sending a payment request each cycle. Under the vault model, it's a customer-controlled on-chain account whose billing terms are fixed at creation.

How do crypto subscriptions work?

The customer funds a vault only they control; billing terms live in the vault's address; a keeper triggers each charge on schedule, and the chain rejects anything that deviates from the committed terms. Full mechanics are the body of this article.

Can crypto payments be recurring? Is there recurring billing for crypto at all?

Yes — but only with architecture, because no chain has a native "charge me later" primitive. Recurring crypto payments require either custody, standing approvals, or the vault model described here; only the last one automates billing without holding customer funds.

How to accept recurring crypto payments as a merchant?

Create a plan (one API call or dashboard form), share the plan's checkout link, and handle two webhooks — subscription.active and subscription.charged. The sandbox lets you rehearse before going live.

How to set up recurring crypto payments as a customer?

Open the merchant's subscribe link, sign one transaction to set up crypto subscription vault and first deposit, done. No wallet allowance, no custodian, and you can withdraw or cancel anytime.

Do crypto subscriptions auto renew?

Under the vault model, yes — renewals charge automatically while the vault holds balance. There's no crypto auto-renew trick behind it: the charge executes exactly per the welded terms, and stops the moment the customer cancels or the balance runs out past grace.

Can you subscribe with crypto the way you would with a card?

Yes — one signature at the start instead of entering card details, then charges run on their own. The difference in your favor: you hold the balance, not the merchant or a processor.

Can customers pay a subscription with crypto but keep custody?

That's precisely the point of the vault design: the customer pays their subscription with crypto from an account only they control. The merchant never holds a balance; neither do we.

Are automatic crypto payments safe?

Safer than the alternatives, structurally: automatic recurring crypto charges under this model can't exceed the welded amount, can't change destination, and can't outlive a cancellation — the chain enforces all three. Compare that with unlimited token approvals, where the worst case is "everything".

Can you charge a crypto wallet automatically?

Not a plain wallet — that's the whole problem, and the honest answer to why most "subscriptions" are reminders. What can be charged automatically is a purpose-built vault with pre-committed terms, which is exactly what the customer creates when subscribing.

Does this work with USDT?

Yes — a USDT subscription works the same as USDC: pick the token when creating the plan. Where USDT matters most, it's often the right default.

Can I bill in USDC on a schedule?

Yes — USDC recurring payments are the most common configuration: dollar-priced plans, USDC-settled charges, no volatility conversation.

What about stablecoin recurring payments generally?

Stablecoin recurring payments are the sane default for subscriptions: the amount the customer approved is the amount they pay, every cycle, with no exchange-rate surprises in either direction.

Is there a Solana subscription option specifically?

Yes — Solana is the flagship chain for vault subscriptions: sub-cent charge costs make monthly billing economical, and the rent deposit comes back on close.

What makes an on-chain subscription non-custodial?

The balance never leaves the customer's control. Non-custodial recurring billing means the platform can trigger charges per the committed terms but cannot hold, redirect, or freeze the funds — a subscription without custody at any step.

How is this different from a payment reminder?

A reminder asks; a subscription charges. The crypto subscription vs payment reminder distinction is the entire article above: if the customer must act each cycle, it's not billing — whatever the marketing says.

Does the customer need to keep funds in the vault forever?

No — only enough for upcoming cycles. Many customers prepay a few cycles; the balance is withdrawable at any moment.

What chains does this work on?

Solana and the supported EVM chains (Ethereum, Base, BNB Chain), stablecoin or native-coin pricing per plan.

Can I offer trials and promo pricing?

Yes — free trials and discounted first cycles are part of the plan terms (and therefore welded into the vault derivation like everything else).

What happens to my existing subscribers if I change the plan?

Nothing — terms are snapshotted per subscription at creation. New terms apply to new subscribers; plan changes for an existing subscriber run through the zero-trust migration flow.