# Dynamic Pricing at Checkout: Pay What You Want and Beyond for SaaS > Use dynamic pricing checkout to support pay what you want, programmatic amounts, and quote based deals on a single product. Implementation patterns and pitfalls. - **Author**: Ayush Agarwal - **Published**: 2026-05-16 - **Category**: Checkout, Pricing - **URL**: https://dodopayments.com/blogs/dynamic-pricing-checkout-saas --- Most checkout flows assume the price is fixed before the buyer arrives. The product has a price, the cart has a total, and the form just collects payment for that amount. That model breaks down for a surprising number of real flows. Pay what you want pricing, donations, custom quotes, dynamic upsells, multi seat purchases where the seat count is chosen at the last moment, all of these need the price to be set when the checkout is created, not when the product is created. Dynamic pricing checkout solves this by letting a single product carry a variable amount that is set at checkout creation time, optionally with bounds. This article walks through what dynamic pricing actually means in this context, where it earns its keep, and how to implement it without creating support headaches for yourself. ## What dynamic pricing checkout actually is The conventional model has each product carrying a fixed price. If you have three price points, you have three products. If the buyer can choose any of ten amounts, you might have ten products, or you push the choice into your application and have it call a different price each time. Either way, the catalog grows fast and managing it gets painful. Dynamic pricing checkout flips this. A single product is configured to accept a variable amount. The product carries metadata, tax category, name, description, and so on, but not a fixed price. When you create a checkout session, you either pass the amount programmatically or let the buyer choose during checkout. Optional minimum and maximum bounds keep the buyer inside a sensible range. This is a one to many relationship between product and price. One product configuration handles many price points without creating new products for each one. The compliance and tax handling stay attached to the product, and the price varies on top. A common pattern is pay what you want. The product configuration sets a minimum, optionally a maximum, and optionally a suggested amount. The buyer enters their own price during checkout. The platform validates against the bounds and processes the payment. This was popularised by independent creators and digital product sellers and now appears across many SaaS niches as well. ## Where dynamic pricing earns its keep Several scenarios push teams toward dynamic pricing checkout. Recognising the pattern in your own product saves you from building workarounds. ### Quote based or sales assisted purchases Sales reps negotiate a price with a prospect. The deal is for a specific amount that is not on the public price page. You need to send the buyer a checkout link for that specific amount without creating a new product for every deal. Dynamic pricing handles this cleanly. The rep generates a checkout session with the negotiated amount, sends the link, and the buyer pays. ### Custom packages and configurations A buyer picks twelve seats and three add ons during a configuration step. The total is calculated by your application. Rather than mapping every possible combination to a product, you create one base product with dynamic pricing, calculate the total in your code, and pass it as the amount when creating the checkout. ### Pay what you want and donation models Independent sellers, side projects, and certain SaaS niches use pay what you want as a marketing or community pricing strategy. The buyer enters an amount within the seller's bounds and pays. Dynamic pricing with the buyer entering the amount supports this directly. ### Top up packs with variable amounts A user is buying credits or capacity. The pack size is whatever they pick. Rather than five fixed pack sizes as five separate products, one credits product with dynamic pricing handles any pack size at all. ### Coupon codes with non standard discounts Most coupon flows reduce a fixed price by a percentage or fixed amount and the platform handles the math. Some discount programs are more complex, where the final price depends on customer attributes that are evaluated in your code. Dynamic pricing lets your code calculate the final number and pass it directly. ### Tip jars and supporters A few products bolt on a tip jar where the user can pay extra to support the maker. This is a micro purchase with a buyer chosen amount, and dynamic pricing makes it a one product setup rather than a long list. The thread connecting all of these is that the amount is decided per transaction rather than per product. If your application has any flow that fits this shape, dynamic pricing checkout is the cleanest implementation. ## How it works in practice on Dodo Payments The flow has three steps. Configure the product, decide how the amount is determined, and create the checkout session. ### Configure the product In the dashboard you create a one time product and enable pay what you want pricing. You set a minimum amount, which is required and protects you from zero or negative payments. You optionally set a maximum amount, which caps the buyer's choice and prevents accidental large payments. You optionally set a suggested amount, which is displayed to the buyer as a recommended price and tends to anchor their choice. Subscriptions are not supported with dynamic pricing today. The model is for one time payment products. If you need recurring with variable amounts, the right pattern is on demand subscriptions, where the recurring price is fixed and you fire ad hoc charges for the variable portion. ### Decide how the amount is set Two modes are available. In programmatic mode, your code passes the amount when creating the checkout session, and the buyer sees that amount on the checkout page. In buyer choice mode, your code omits the amount and the buyer enters it on the checkout page within your configured bounds. Programmatic mode is for sales quotes, calculated totals, and any case where your application has decided the price. Buyer choice mode is for pay what you want and similar flows where the buyer is the one choosing. ### Create the checkout session The checkout session create call takes the product identifier, optionally the amount in the product cart, the customer information, and the success URL. The platform produces a checkout URL or an inline session, the buyer pays, and the platform fires a webhook on success. The webhook payload includes the actual amount paid, which you record against the buyer in your application. The full reference for the create call lives in the [dynamic pricing checkout guide](https://docs.dodopayments.com/developer-resources/dynamic-pricing-checkout). This article gives you the framing and the patterns. The doc has the request and response shapes. ## Patterns that work well A few implementation patterns make dynamic pricing reliable in production. ### Always validate amounts in your code before creating the session Even though the platform enforces minimum and maximum bounds, your code should also validate. This catches bugs early and gives you clearer error messages for buyers and operators. If the calculated amount is outside the expected range, abort and log it rather than passing it through. ### Use idempotency keys Sales reps double click. Application bugs cause retries. Without an idempotency key, you can end up creating multiple checkout sessions for the same logical purchase, which confuses everyone. Pass a stable key per logical session attempt. ### Show the amount clearly to the buyer If the amount is set programmatically, the buyer should see it on the checkout page before they pay. The hosted and inline checkout surfaces handle this automatically, but if you have any custom flow that wraps a checkout, make sure the amount is visible. Surprise amounts are the leading cause of refund requests. ### Pick suggested amounts thoughtfully for pay what you want If you let the buyer choose, the suggested amount strongly anchors their decision. A higher suggested amount tends to lift average order value, but pushing it too high reduces conversion. Test a few values and pick the one that maximises revenue per visitor, not the highest amount or the most comfortable amount. ### Set a maximum to protect against accidental high amounts If you do not set a maximum and the buyer enters their own amount, you occasionally get someone who types the wrong number of zeros. The refund follow up is awkward. A reasonable maximum prevents this. ### Record actual amount paid in your data model Because the amount is variable per transaction, your customer record needs to capture the actual amount paid for each checkout. If you assume a fixed amount based on the product, you will be wrong. The webhook payload tells you the actual amount, and that is the source of truth. ## Patterns to avoid A few mistakes show up repeatedly in dynamic pricing implementations. Setting the minimum to zero or a very low number. Zero amount checkouts are not useful and in some configurations are not even allowed. A minimum of one dollar or one rupee or the equivalent in your currency is the lowest you should go, and even that is rarely the right choice. Pick a minimum that reflects the floor of what you actually want to sell. Calculating the amount on the client and passing it. Your client side code can be tampered with. The amount should be calculated on your server, validated, and passed to the checkout session create call from there. Anything else lets a determined buyer pay an arbitrary amount. Using dynamic pricing for products that should be subscriptions. If the customer relationship is recurring, dynamic pricing is the wrong tool. Use a subscription product with a fixed price plus on demand charges for the variable portion. Trying to fit recurring into dynamic pricing one time products causes more problems than it solves. Skipping the suggested amount when buyers are choosing. Without an anchor, buyers default to the minimum or to round numbers below the minimum, which they then bump up grudgingly. With an anchor, buyers tend to pay closer to your target. The anchor is doing real work and skipping it leaves money on the table. Treating the amount as static after creation. Once a checkout session is created, the amount is locked. If your code later realises the amount should be different, create a new session. Trying to mutate an existing session is not supported and will not behave the way you expect. ## Where dynamic pricing fits in your billing surface Dynamic pricing is a checkout level capability. It does not change anything about your subscription products, your usage based products, your tax handling, or your refund flow. It just lets one product carry a variable amount. In a typical SaaS or AI product, dynamic pricing usually shows up in a few specific places. Sales tools that send checkout links for negotiated deals. Top up flows that let users buy credits in arbitrary amounts. Pay what you want offers for early adopters or community supporters. Custom configuration flows where the total is calculated by your application before the buyer hits checkout. Most of your billing surface can stay on fixed price products and subscriptions. Dynamic pricing earns its keep on the surfaces that genuinely need variable amounts. ## How Dodo Payments fits Dodo Payments supports dynamic pricing checkout natively as a configuration on one time products. The platform handles the validation against your minimum and maximum bounds, the tax calculation at the actual amount paid, the settlement, and the webhook with the final amount. As a Merchant of Record it also handles compliance and global tax remittance for whatever amount the buyer ended up paying. The integration follows the same patterns as standard checkout. The only differences are enabling pay what you want on the product configuration and optionally passing an amount when creating the session. For implementation reference see the [dynamic pricing checkout guide](https://docs.dodopayments.com/developer-resources/dynamic-pricing-checkout) and the [checkout session reference](https://docs.dodopayments.com/developer-resources/checkout-session) for the session create call. ## Closing thought Dynamic pricing checkout is one of those features that does not come up until you need it, and once you need it the alternatives are painful. Creating ten or a hundred products to represent ten or a hundred prices, building a parallel pricing system in your application, hacking around with line items, all of these are workable but expensive. A single product that carries a variable amount, with optional bounds and an optional buyer choice, collapses the surface into something maintainable. If your product has any flow where the amount is decided per transaction rather than per product, this is the right tool. If your product is uniformly fixed price, you can ignore it. The cost of having dynamic pricing in your toolbox is essentially zero, and the cost of not having it when you need it is real. ## FAQ ### Can I use dynamic pricing for subscriptions? No. Pay what you want and dynamic pricing checkout are for one time payment products only. If you need recurring billing with variable amounts, the right pattern is on demand subscriptions, where the recurring portion is a fixed price and you fire ad hoc charges for the variable portion against the same subscription. ### What stops a buyer from paying a tiny amount? Your configured minimum. The minimum is required at product creation time and the platform refuses checkout sessions below it. Set the minimum to whatever floor protects your unit economics. A higher minimum is usually fine for SaaS and digital products. Too low a minimum invites abuse. ### Can I change the amount after creating a checkout session? No. The amount is fixed at session creation time. If your code needs to update the amount, create a new session and discard the old one. Mutating a session is not supported. ### How does tax work with dynamic pricing? Tax is calculated on the actual amount paid. If the buyer pays fifty dollars and the applicable tax rate is twenty percent, the platform calculates ten dollars in tax on top of the fifty. As a Merchant of Record the platform also remits the tax. You do not need to do anything different from a fixed price product. ### Can I use dynamic pricing with inline checkout? Yes. Dynamic pricing is a product configuration, not a checkout surface. Both inline and hosted checkout support it. The amount is set the same way in either case, by passing it during session creation or letting the buyer choose during checkout. --- - [More Checkout articles](https://dodopayments.com/blogs/category/checkout) - [All articles](https://dodopayments.com/blogs)