# On-Demand Subscriptions: A Hybrid Billing Model that Works > On-demand subscriptions combine recurring billing with on-demand charges so you can run trials, upsells, and tiered upgrades on a single saved payment method. - **Author**: Ayush Agarwal - **Published**: 2026-05-14 - **Category**: Subscriptions, Billing - **URL**: https://dodopayments.com/blogs/on-demand-subscriptions-hybrid --- Subscription billing started simple. Customers signed up, picked a plan, paid every month, and either stayed or cancelled. That model still works for a lot of products, but it leaves money and flexibility on the table once a SaaS or AI business grows past the basics. Trials need a way to capture a card without charging it. Upgrades need to charge a difference immediately rather than waiting for the next cycle. Add ons and one time top ups need to flow through the same saved payment method without making the customer reauthenticate. On-demand subscriptions are the cleanest way to model this. The recurring contract still exists, but you can also fire one off charges against the same customer mandate whenever the business logic calls for it. This article walks through what on-demand subscriptions are, the kinds of flows they unlock, and how to implement them in practice on Dodo Payments. ## What an on-demand subscription actually is A standard subscription has a single recurring charge tied to a plan. Every billing cycle, the platform pulls the agreed amount from the saved payment method. There is no concept of charging the same customer for something else outside of that schedule, and there is no concept of starting the subscription without an immediate charge. An on-demand subscription extends that model in two directions. First, the initial charge becomes optional. You can capture a payment method and start a subscription record without billing anything yet, which is the standard pattern for free trials and freemium upgrades. Second, you gain the ability to fire ad hoc charges against the saved mandate at any point, billed in the customer's currency and going through the same compliance and tax flow as the recurring portion. The result is a single object that represents the customer relationship, with a recurring rhythm plus the freedom to charge for anything that happens outside that rhythm. From the customer perspective, it is one card on file and one billing relationship. From the merchant perspective, it is one subscription identifier that powers trials, upsells, top ups, overage, and plan changes. ## What this unlocks for SaaS and AI products The reason on-demand subscriptions matter is that real product flows almost never fit a pure recurring model. A few patterns show up over and over. ### Free trials without an upfront charge The classic trial flow needs to capture the card, verify it works, and start a clock. No money should move on day one. With a flat recurring subscription you have to either delay the subscription start, run a fake charge and refund it, or rely on a separate authorization product. With on-demand subscriptions you create the subscription with a zero amount initial charge, validate the payment method, and let the recurring schedule kick in when the trial ends. If the user upgrades early, you fire an immediate charge. ### Plan upgrades and downgrades A user moves from a basic plan to a pro plan halfway through the cycle. With pure recurring you either wait until the next cycle, which feels slow, or you cancel and recreate the subscription, which loses history and confuses dunning. With on-demand subscriptions you charge the prorated upgrade amount immediately, switch the plan, and the next regular cycle just runs at the new rate. ### Add ons and overage A customer is on a base plan that includes a quota. They consume more than the quota during the month. The clean pattern is to fire a one off charge against their saved payment method for the overage as it happens or at the end of the cycle, separate from the base subscription charge but on the same relationship. The accounting stays clean and the customer sees a single invoice with line items. ### Soft paywalls and tip jars Some products want a recurring base with optional pay what you want top ups during the cycle. On-demand subscriptions handle this naturally because you can fire arbitrary charges at any point against the existing mandate. ### Top up packs and credit purchases Many AI products sell credit packs alongside a subscription. Fifty dollars buys a thousand credits, and credits drain as the user consumes the product. Each credit pack purchase is an on-demand charge against the subscription, with the subscription itself acting as the customer container. The common thread across all of these is that the recurring contract and the ad hoc charges live on the same object. You do not need separate one time payment integrations, separate refund flows, or separate tax handling. The on-demand subscription is the unit of customer relationship. ## How an on-demand subscription works on Dodo Payments The implementation pattern follows two phases. First, you create the subscription with the on-demand flag set. Second, whenever you want to fire an ad hoc charge, you call a charge endpoint with the amount and a reason, and the platform handles authentication, settlement, tax, and invoicing. ### Creating the subscription The subscription create call accepts a flag that says this is an on-demand subscription. You also pass an initial charge amount, which can be zero. A zero initial charge starts the relationship without billing the customer, and the first real charge happens either when the trial ends, when you fire an ad hoc charge, or when the recurring cycle hits its first paid period. You set the recurring price as part of the linked product or pass it inline. You decide the cycle length, the currency, and the metadata you want attached. The platform issues a subscription identifier, and you store that against the customer record in your application. ### Firing an ad hoc charge After the subscription exists, any time you want to charge for something extra, you call a charge endpoint passing the subscription identifier, the amount, the currency, and an idempotency key. The platform authorises and captures the charge against the saved payment method, applies the right tax for the customer's region, and produces an invoice line item attached to the same subscription. If the saved payment method has expired or the issuer declines, the charge fails like any other and you get a failure response with the standard reason codes. You can retry, prompt the customer for a new card, or surface the failure in the user interface, the same way you would for any one off charge. ### Handling lifecycle events Webhooks fire for every relevant event. Subscription created, subscription activated when the trial ends, subscription renewed for each recurring cycle, ad hoc charge succeeded, ad hoc charge failed, subscription cancelled. Your application listens to the ones it cares about and updates the local state accordingly. The clean way to model this on your side is to treat the subscription as the single source of truth for the customer relationship, with charges as line items inside it. That mirrors what the platform already does and avoids the bug class where your local view drifts from the billing system. ## Practical patterns Two patterns come up so often they are worth describing in full. ### The trial then convert pattern Create the subscription with the on-demand flag, an initial charge of zero, a fourteen day trial, and the eventual recurring price. The customer enters the trial without paying. On day fourteen the recurring schedule kicks in, the platform charges the saved payment method, and the subscription becomes active. If the user cancels before day fourteen, the subscription ends without any charge ever happening. If the user wants to upgrade on day three, you fire an ad hoc charge for the upgrade amount and switch the plan, and the recurring continues. The reason this works better than a free trial without a card is that you have already validated the payment method, captured the relationship, and removed friction at the conversion moment. The user does not need to enter card details again when their trial ends. ### The base plus consumption pattern The customer is on a thirty dollar base plan that includes a quota. Your application tracks consumption as it happens. At the end of the cycle, your code calculates the overage and fires a single ad hoc charge against the subscription for that amount. The customer sees one invoice with the base subscription line and the overage line. If you want overage to be charged immediately rather than at cycle end, you can fire ad hoc charges as consumption crosses thresholds. Some products do this in chunks, charging for each block of overage as the user consumes it, which protects you from a single very large bill at the end of the month and gives the customer earlier visibility. The mechanics are the same in both cases. The subscription holds the recurring contract. Ad hoc charges represent the variable portion. The platform stitches them into clean invoices. ## Where on-demand subscriptions fit alongside other models On-demand subscriptions are not the right tool for every billing scenario. A few comparisons help place them. If your product is purely recurring with no overage, no trial, and no plan changes, a simple recurring subscription is enough. Adding on-demand capabilities to a model that does not need them just adds surface to maintain. If your product is purely transactional with no recurring component, individual checkout sessions or payment links are the right tool, not subscriptions. The subscription concept only earns its weight when there is a continuing relationship. If your product has a recurring contract plus any of the patterns described above, trials, upgrades, add ons, overage, top ups, then on-demand subscriptions are the right shape. They give you a single customer object that handles all of those flows without spawning parallel integrations. The full reference for the create and charge calls lives in the [on-demand subscriptions guide](https://docs.dodopayments.com/developer-resources/ondemand-subscriptions). That document has the request and response shapes. This article gives you the framing and the patterns. ## Common pitfalls A few traps come up when teams first integrate on-demand subscriptions. Forgetting idempotency keys on ad hoc charges. If your code retries on a network error without an idempotency key, you risk double charging the customer. Always pass a stable key per logical charge attempt. Treating ad hoc charges as separate from the subscription in your data model. The whole point is that they are part of the same relationship. Store them as children of the subscription record so reporting and cancellation flows work correctly. Not handling failed ad hoc charges. The recurring portion has automatic retries and dunning. Ad hoc charges fire once. If they fail, you need to surface that and either retry on your own schedule or prompt the customer. Skipping the trial start hook. If you start a subscription with an initial charge of zero and a trial, your application needs to know when the trial converts so it can switch the user from trial state to paid state. That is what the subscription activated webhook is for. Hard coding currency. If you support multiple regions, the ad hoc charge currency needs to match the subscription currency. Pass it explicitly rather than relying on a default. ## Closing thought The pure recurring subscription was a reasonable model for a simpler era of SaaS. Modern AI and software products have trials, plan changes, add ons, overage, and top ups, often all on the same customer. Modelling each of those as a separate billing primitive turns into a pile of integrations and edge cases. On-demand subscriptions collapse them into a single object with a recurring rhythm and the freedom to charge ad hoc against the same mandate. The cost of adoption is small. The flexibility you gain is large. If you are designing or refactoring a billing surface for a SaaS or AI product right now, this is the shape to aim for. ## FAQ ### Is an on-demand subscription a single product or two products? It is a single subscription record with a recurring price and the ability to fire ad hoc charges against the same payment mandate. From the customer perspective they have one relationship and one card on file. From your data model perspective there is one subscription identifier with charges as line items. ### Can I start an on-demand subscription with no charge at all? Yes. Set the initial charge amount to zero when creating the subscription. The platform validates the payment method, creates the subscription record, and the first real charge happens either when the recurring schedule starts paying, when a trial ends, or when you fire an ad hoc charge. ### Do ad hoc charges go through the same tax and compliance flow? Yes. Every charge under the subscription, recurring or ad hoc, runs through the platform's tax calculation and compliance pipeline. You do not need to handle VAT, GST, or sales tax separately for ad hoc charges. The Merchant of Record model means tax is calculated and remitted on every charge automatically. ### What happens if the saved payment method fails on an ad hoc charge? The charge returns a failure with a standard decline reason. The platform does not automatically retry ad hoc charges the way it does recurring renewals. Your application decides whether to retry, prompt the user for a new card, or surface a payment failure. The recurring portion of the subscription is not affected unless the next cycle also fails. ### Can I migrate existing recurring subscriptions to on-demand? If your existing subscriptions were created without the on-demand flag, you typically cancel and recreate them as on-demand at the next cycle boundary. The exact path depends on the platform configuration. Plan the migration alongside a billing review so you do not surprise customers with new charges they did not expect. --- - [More Subscriptions articles](https://dodopayments.com/blogs/category/subscriptions) - [All articles](https://dodopayments.com/blogs)