Anyone who has built subscription billing on cards has a working vocabulary: card on file, retries, dunning, chargebacks, proration. None of it maps one-to-one onto a network where the customer holds their own keys — and that's the part that makes teams hesitate. The good news is that every term has a crypto-native counterpart, a couple of them get simpler, and one of them disappears entirely. This is the translation guide, term by term, for billing subscriptions in USDT or USDC.
Cards pull. Wallets push.. On a card network, a merchant can take money from a customer once the customer has handed over the card. On a blockchain, nobody can take funds from a wallet unless its owner has explicitly authorised something to do so. Every difference below — and every design decision — follows from that single fact.
Term 1 — Card on file: Becomes a standing authorisation
A subscription that bills itself needs permission to move money later, without the customer present. On cards, that permission is the stored card. On-chain, the equivalent is a one-time authorisation the customer signs: they allow a specific contract to debit their wallet on a schedule, up to terms they can see. The common building block behind this on EVM networks is the token allowance — approve once, then the contract can spend within the approved limit.
CPAY's recurring billing is built around that idea. A merchant creates a plan — a payee address that receives the funds, a price in a given token, a period type that sets how often the customer is debited, and an owner wallet that publishes the plan to the blockchain. A plan can be saved as a draft or published; once it's live you copy the plan's link and give it to customers, who subscribe from there. The authorisation is the customer's, the terms are public, and neither side is trusting a screenshot of a card number.
Term 2 — Billing cycle: Becomes the plan's price and period
On cards, the billing date lives in your billing system and gets re-sent to a processor every month. Here, the schedule is part of the plan itself: price, token and period are published together, which makes the terms visible to the customer and checkable by anyone. Two practical consequences follow. Pricing in a stablecoin means the amount is stable in dollar terms for the subscriber, so there is no monthly FX variance to explain. And because the plan is published, treat its terms as fixed — if you need a different price, plan for a new plan rather than an edit, and confirm the current behaviour in your dashboard before promising grandfathering to anyone.
Term 3 — Retries & dunning: Becomes "check, remind, grace"
This is where the mental model has to change most. With a card, a failed charge is a thing you retry: try again tomorrow, try again in three days, send an email. With a wallet, nothing is "declined" by a bank — the debit simply can't happen if the balance is too low or the authorisation has run out, and no number of retries creates money that isn't there. The job shifts from retrying to noticing early and talking to the customer.
The failure list is short and worth designing for on day one:
- Insufficient balance. The wallet holds less than the plan's price on the due date.
- Exhausted authorisation. The approval the customer signed has been used up or revoked.
- Wrong network or token. Funds sit on a chain or in an asset the plan doesn't use.
- A wallet that can't authorise contracts. Some custodial and exchange wallets can send transfers but can't sign the approval a subscription needs.
Say who this is for before you sell it. Recurring billing from a wallet works best for customers who hold their own keys — the same people already comfortable paying in crypto. If a segment of your customers pays from an exchange account, offer them a manual renewal link or keep a card option next to it. Hiding that limit until the first failed renewal is the fastest way to create a support queue.
Term 4 — Chargebacks: Become a policy, not a process
On-chain settlement is final. That removes a real cost — disputed-payment fees and the fraud-by-dispute category — and it moves a responsibility onto you: if a customer is unhappy, the remedy is your refund policy, not a bank's arbitration. In practice that means stating renewal terms clearly at sign-up, sending a reminder before each charge, and making cancellation easy to find. A subscription business that does those three things loses very little by having no chargeback safety net.
The less a customer can do to you after the fact, the more you owe them before it. (A rule of thumb, not a quote.)
Term 5 — Cancel & audit: Become events on a public record
Every subscription in CPAY has an id, a next payment time, the amount per period, the plan name and — usefully — a history: an ordered list of events, each with a type, an amount, a timestamp and the transaction hash that proves it. A new subscription and a cancellation both show up there, and the plan itself can be read back through the same API. That's a better audit trail than most card setups give you, and you don't have to build it.
It also gives you what you need to decide, in your own code, whether a customer should currently have access. The one field to watch is nextPaymentTime:
Treat that as a starting point, not a finished entitlement engine: the exact way nextPaymentTime and the history behave after a successful period is worth confirming once on a test plan before you build a policy on top of it. Pay one period, read the subscription again, and see what moved.
Term 6 — Proration & plan changes: Become plan design
Mid-cycle upgrades, partial refunds and prorated credits are card-world conveniences that depend on being able to adjust a stored charge at will. With published plans, the cleaner pattern is structural: offer distinct plans (monthly, annual, tiers), let a customer cancel one and subscribe to another, and handle any credit as a business decision rather than a billing-engine feature. It's less flexible and far easier to reason about — a trade a lot of subscription products turn out to like.
Fit check: When recurring crypto is the right call
- Good fit: your customers already hold stablecoins — developer tools, SaaS sold across borders, communities, creator and membership products, B2B services paid by crypto-native companies.
- Good fit: card fees, cross-border declines or chargeback exposure are a real line in your P&L, so the fixed, final settlement is worth the extra explanation at checkout.
- Add, don't replace: offer crypto beside cards, with a clear label and the same renewal reminder you'd send anyway. It's a new payment method, not a migration.
- Keep cards: for mass-market consumer plans where most payers pay from an exchange, can't sign contract approvals, or expect to dispute through their bank.
- Pilot first: one plan, one network, one stablecoin, a few dozen subscribers. Measure renewal rate and the number of "my payment didn't go through" tickets before you widen it.
FAQ — Common follow-ups
Can customers subscribe from an exchange account?
Usually not for automatic renewals. Recurring debits need the customer's wallet to authorise a contract, and many exchange and custodial wallets can send transfers but can't sign that approval. For those customers, offer a manual renewal link or a card option alongside crypto.
What happens if the customer's balance is too low on the due date?
The debit can't complete, and retrying doesn't change that. Detect it through the subscription's nextPaymentTime, notify the customer, and apply your own grace period before access ends. Sending a reminder before the due date prevents most of these.
Can I change the price for existing subscribers?
Treat a published plan's terms as fixed. A plan is published to the blockchain with its price and period, so a different price generally means a new plan and a deliberate move of subscribers. Confirm the current behaviour in the dashboard before you promise anyone a price lock or a forced increase.
How do I prove a payment happened?
Each event in a subscription's history carries a transaction hash. Store it with your invoice record: it is a public, timestamped proof of the payment that anyone can verify, without relying on your processor's statement.
Which tokens and networks can I use for plans?
Plans are tied to a specific token on a specific network, and the documentation's example uses a BEP-20 stablecoin on a test network. Check the current list of supported networks and tokens in the recurring-billing documentation, and start with one stablecoin on one network rather than offering everything.
Ready to try it? The Recurring Billing documentation covers plan creation, and the API reference covers plan and subscription lookups. The CPAY team is a call away.
Sources: EIP-20, CPAY Recurring Billing, Using API for recurring billing.
