Guide
How to Price an Embeddable Widget: 5 Models Compared
Short answer: price an embeddable widget from what one use costs you. Use a subscription for a steady, everyday tool; credit packs or pay per use when each use has a real cost, like an AI call; and a free tier only with a cap per host. Then give the host a share big enough that adding your widget beats building the feature themselves.
Why is pricing a widget different from pricing your app?
On your own site, people arrive looking for you. A widget lives inside someone else's product, in front of users who never chose you and may not know your name. Three things change because of that.
- The user meets you mid-task. They opened the host product to do something, and your widget is one step of it. The price has to make sense at that moment, in a small box, without a pricing page next to it.
- Someone else brought them. The host built the integration, answers the first support question and put its users in front of you. If the host gets nothing from a sale, the next host won't bother.
- You don't control the traffic. A host with ten thousand active users can add you on a Tuesday. If every use calls a paid model, that is your bill, not theirs.
So a widget's price answers three questions at once: what the user pays, what the host keeps, and what stops a free tier from becoming a cost you can't see coming.
What are the five ways to price an embeddable widget?
These are the five price models Ordana supports for a listed widget. They also cover nearly every widget we've seen described anywhere else.
| Model | Fits when | The trap |
|---|---|---|
| Free, capped per host | The widget's job is to bring people to your main product | No cap, so a host's success becomes your bill |
| Subscription | A steady tool people use every day, with a low cost per use | Occasional users won't subscribe to something they touch twice a month |
| Credit packs | Each use has a real, variable cost: AI output, documents, checks | A first pack so big it feels like a commitment |
| Subscription + credit packs | Your users split into regulars and occasional users | Two prices to explain in one small box |
| Pay per use | Usage is spiky or hard to predict | An open meter scares people if the price per use isn't plain |
1. Free, with free uses capped per host
Free is a distribution choice, not a business model. It fits when the widget is a taste of a bigger product: a free audit that leads to the paid tool, a calculator that leads to the service. Set a number of free uses per month and keep it per host, so one very successful host can't spend the whole allowance.
2. Subscription
A monthly price for unlimited or generous use. It fits a tool that becomes part of someone's routine inside the host product, where the cost of one use to you is close to nothing. It is the easiest model for a user to understand and for a host to explain. Its weakness is the occasional user, who will happily pay for three uses and will not sign up for a monthly plan to get them.
3. Credit packs
The user buys a bundle of uses up front and spends them. This fits when each use costs you something real, such as a summary from a paid AI model or a generated document, because the money arrives before the cost does. Keep the first pack small (on Ordana the minimum is €5) so buying it feels like trying, not committing.
4. Subscription and credit packs together
Offer both and let the user pick: a plan for the people who live in it, a pack for the people who drop by. It catches more of the users a host puts in front of you, at the cost of a slightly busier paywall.
5. Pay per use
A price per use, or per batch of uses ("say €1 per 100 summaries"). On Ordana it is sold as a metered subscription: nothing is charged up front, the card is charged once a month for the uses made, and sooner if the bill reaches 20.00. An unpaid bill stops the uses straight away, so the most anyone can run up unpaid is about one threshold. It fits usage nobody can predict, and it is the fairest model for an expensive AI feature. The trap is presentation: show the price per use exactly where the user decides, or the open meter feels like a risk.
How do you choose the right model?
Walk through three questions in order.
- What does one use cost you? If it's close to zero, a subscription or a capped free tier is fine. If it's real money, the price has to scale with use: credits or pay per use.
- How often does one person use it? Every day points to a subscription. A few times a month points to credits or pay per use. Both kinds of people points to offering both.
- What is the widget for? If it exists mainly to bring people to your main product, keep it free and capped and charge where they end up.
Whatever you pick, keep the free taste. Most people will not pay for a feature they met five seconds ago inside another product. A few free uses is how they find out it's worth it.
How much of each sale should the host keep?
More than feels natural. The host wrote the integration, takes the first support question and gave you its users. Its alternative is to build a rougher version of your feature with its own coding agent in a weekend and keep everything. Your share to the host has to beat that, which is the same argument as in build vs buy for SaaS features.
On Ordana the widget owner sets what the host keeps, anywhere from 10% to 90%, and every host sees it before adding the widget. Ordana's fee is 10% of each sale, and it comes out of the owner's side, never the host's. As an illustration only: on a sale of say €9 a month with the host keeping 30%, the host's 30% and Ordana's 10% are worked out on what remains after VAT and the card fee, and the owner keeps the rest. The money is split and paid out automatically.
The host's share is the part most owners get wrong, usually by treating it like an affiliate commission. It isn't one. A host doesn't pass you a lead and walk away; your feature now runs inside its product, every day, under its name. That's also why integration partners who get nothing stop maintaining the integration, as we argue in integration partnerships that share revenue.
Why should free uses be capped per host?
Because every free use costs you, and you don't decide how many hosts add you or how big they are. On Ordana your server asks before each use whether this person may use the widget right now, and the answer comes from the offer you confirmed: free uses within the caps, then credits, then the paywall. The caps sit per user and per host, with an optional cap across all hosts. If one host still grows faster than you can afford, you can throttle that host's free uses or pause new hosts while you raise prices. Paying users keep their access either way.
The point is that a host's success should never be a bad day for you. A cap is what lets you say yes to a big host without reading its user count first.
What happens when you change the price?
Hosts build around your price; changing it under them is how you lose them. On Ordana every change to the terms becomes a new version of the offer. Hosts already using the widget get 30 days' notice, or can accept the new version early, and a subscription that's already running keeps the price it started on. New hosts get the new terms straight away.
What if the host has its own accounts and checkout?
Some hosts already sign their users in and already charge them, and won't put a second sign-in and a second checkout in front of them. For those, the host can sign its users into your widget itself and charge them at its own price, buying access from Ordana per user at a wholesale price: your subscription price minus the host's share. The host saves one card and is charged for the users it turns on. Today that works for subscription-priced widgets; hosts without their own billing use Ordana's checkout inside the widget, as before.
When should you not charge at all?
When the widget's real job is to start a relationship. If the money is in your main product and the widget is the door into it, a capped free tier with a clear "open the full product" path may earn more than any price inside the host. That is a legitimate choice, as long as it's a choice and not a default you never revisited. If you're still working out what the widget even is, start with what a widget integration is.
Frequently asked questions
How do I monetize an embeddable widget?
Charge the people who use it inside the host product, and give the host a share of every sale. Pick the price model from what one use costs you: a subscription for a steady, everyday tool, credit packs or pay per use when each use has a real cost, and a capped free tier either way.
Should my widget be free?
Only if its job is to bring people to your main product, and even then with a cap on free uses per host. A free widget with no cap turns a host's success into your bill, especially when each use calls a paid AI model.
What share should the host product keep?
Enough that adding your widget beats building the feature themselves. The host does the integration, takes first-line support and puts its users in front of you. On Ordana the owner sets the host's share anywhere from 10% to 90%, and Ordana's fee comes out of the owner's side, never the host's.
Is pay per use better than a subscription for an AI widget?
Often, when usage is spiky or hard to predict. Each use carries its own price, nothing is charged up front, and an unpaid bill stops the uses, so you are never owed much. If people use it every day at a steady pace, a subscription is simpler for them to understand.
Can I change my widget's price later?
Yes. A change becomes a new version of the offer, and hosts already using the widget get 30 days' notice or can accept it early. Subscriptions that are already running keep the price they started on.
On Ordana, your coding agent proposes the price model, the free uses and the host's share while it packages your widget, and you confirm them before anything is listed. Ordana runs the sign-up and checkout inside the widget and splits every sale automatically. List your SaaS as a widget, or browse the guides in widget integrations.
Related reading:
- How to Sell a SaaS Feature as a Widget — packaging one feature and setting its terms.
- How to Get Other SaaS Products to Integrate Yours — finding the hosts and asking them.
- How to Build an Embeddable Widget for Your SaaS — the technical side.