Years ago, back when Volko Audio was my whole business, someone suggested I move to a platform that would handle my checkout and my licensing together. One account, one integration, one invoice. I remember my reaction clearly, because it had nothing to do with features: I wouldn’t want them bundled — what if I want to change payment one day?
That instinct took me years to articulate properly. This post is the articulated version, because the question now confronts every plugin maker choosing a stack: should the system that takes the customer’s money and the system that controls whether your plugin runs be one product — or two?
The short answer: bundling is a reasonable stage-one answer and an expensive stage-two answer — and the cost of getting it wrong is invisible until the day you need to move.
Two jobs, one package
First, let’s be precise about what “bundled” means, because the marketing blurs it.
Payments is the job of taking money: checkout, refunds, chargebacks, payout — and often tax, through a merchant of record (MoR): a provider that resells your product under its own name and handles global VAT and sales tax for you. Licensing is the job of controlling execution: issuing licenses, activating machines, enforcing trials, handling transfers when a customer buys a new laptop.
These are different jobs with different failure modes, different regulatory surfaces, and different lifetimes. A payment relationship lasts as long as a transaction. A license relationship lasts as long as the customer runs your plugin — often a decade or more.
A bundled stack fuses both jobs into one product: the platform that sells your plugin also issues and validates its licenses — one contract, one price, one account, one data model. A separated stack keeps the two jobs in two independent layers: a payment provider (Stripe, PayPal, a merchant of record, your dealer network) takes the money, and a licensing layer issues the license — connected at a small, well-defined set of events: the sale, the refund, the cancellation, the failed renewal.
Note what the distinction is not: it is not about how many vendors you have. One vendor can sell you two genuinely independent products, each priced and cancelable on its own. The test that actually matters is this: can you replace either layer without touching the other? If yes, your stack is separated — whoever the logos belong to. If no, it is bundled, however the pricing page describes it.
Full disclosure, as always in this series: I build Keyzy, a licensing service designed to sit in a separated stack next to whatever payment setup you already have. So I have a position. The way I’ll keep this honest is the same way as in the licensing-model comparison: argue the category trade-offs, including the cases where the bundled option is genuinely the right call.
What bundling actually buys you
Let’s give the bundled stack its due, because it is not a trick — it solves real problems.
If you are a solo founder shipping your first plugin, a bundled platform removes an entire category of decisions. You don’t choose a payment processor, don’t set up tax handling, don’t wire a webhook from checkout to license issuance. The bundle gives you a storefront, a checkout, tax compliance, and license keys in an afternoon. That is genuine value, and pretending otherwise would be dishonest.
The bundled pitch usually comes with a phrase like “we fade into the background so you can focus on your product.” And for stage one — first product, no existing payment relationships, revenue too small to negotiate anything — the pitch is broadly true.
The problem is not what bundling does in stage one. The problem is what it quietly becomes in stage two.
Two leashes, tied together
Here is the structural issue, independent of any specific vendor’s pricing or quality: when your revenue pipe and your license enforcement are sold as one inseparable package, you cannot leave one without leaving both.
Think about what that does to every future decision:
- You cannot stage a migration one layer at a time. With a separated stack, you can switch payment providers this quarter and not touch licensing, or vice versa. With a bundle, any move is a full move — checkout, customer accounts, and every issued license, all at once, with no intermediate state that works.
- You cannot negotiate from leverage. When your payment provider raises fees, the normal response is to quote a competitor. But if leaving your payment provider also means re-issuing every license your customers hold, the vendor knows your threat is hollow. The lock-in on one layer subsidizes pricing power on the other.
- Your risk is correlated. A pricing change, an acquisition, a pivot, a deprecation — any single event now hits both of your critical systems on the same day. (Two separable products from one vendor soften this but don’t remove it: the shock still lands together — the difference is you can respond one layer at a time.)
I call this the two leashes problem: two leashes tied into a single knot. Each leash looks reasonable on its own. The trouble is that you can’t slip one without slipping both — and the knot is the package, not the hand holding it. A vendor who sells the two jobs as genuinely independent products, each one usable and cancelable alone, hasn’t tied the knot; a vendor who folds licensing “into” the payment plan has, whatever the brochure says.
This is not hypothetical: the Lemon Squeezy lesson
In July 2024, Stripe acquired Lemon Squeezy, a merchant-of-record platform that many small software makers used for checkout — and some used for licensing too, because Lemon Squeezy offered license keys as a bundled feature.
Whatever you think of the acquisition itself, look at what happened to the two groups of sellers on that day:
Sellers who used Lemon Squeezy for payments only faced a bounded question: “do I want to stay on a Stripe-owned MoR, or move checkout somewhere else?” Annoying, but shoppable. Their licenses, customer entitlements, and product activation were somewhere else and did not care who owned the checkout.
Sellers who had bundled faced the same uncertainty on their license infrastructure — the system that decides whether their customers’ installed products keep working. Pricing, roadmap, deprecation timelines: all of it suddenly depended on an acquirer’s integration plans.
The audio world has a documented example of how these moves actually go: one plugin company publicly migrated four thousand users off Lemon Squeezy — into another bundled commerce-plus-licensing platform. Which means the next migration, if it ever comes, will be even more expensive: more customers, more issued licenses, and a tighter bundle than before. That is the pattern worth noticing — the path of least resistance out of one bundle is usually a deeper bundle, and each hop raises the exit cost.
None of this required anyone to behave badly. Acquisitions, pivots and pricing changes are normal corporate weather. Architecture is how you decide how much of that weather reaches you.
Every category unbundles as it matures
If you zoom out from audio, this movie has played before.
Early marketing stacks bundled email with CRM — one tool did both, and for small teams that was the right call. As companies matured, the stacks unbundled into dedicated layers, because each layer’s requirements outgrew the generalist bundle. E-commerce followed the same arc: storefront, payments and analytics started as one product and matured into separate, swappable layers.
The pattern is consistent: categories bundle early, when buyers are new and the priority is fewer decisions — and unbundle as they mature, when buyers know their requirements and the priority becomes control.
Commerce-plus-licensing for plugins is currently early on that curve, and the bundled platforms are winning stage-one customers, exactly as bundled products always do. The question is not whether the bundle is good today — it is which stage your business is in, and whether you are signing a stage-one contract with stage-two consequences.
What leaving actually costs
The bundled pitch says integration is easy. It rarely mentions that dis-integration is the hard part. If you ever migrate off a fused commerce-and-licensing platform, here is the actual inventory of what moves:
- Checkout pages and storefront URLs — every “buy” link on your site, in your emails, on dealer pages and in old forum posts points at the platform’s domain or your subdomain of it.
- Customer accounts — your buyers have accounts there, not with you. Password resets, purchase history, download pages: all of it lives on infrastructure you are leaving.
- Issued licenses — every active license was issued and is validated by the platform. Migrating means re-issuing or re-validating the entire installed base, and every plugin binary you ever shipped contains their validation endpoint, not yours.
- The sale-to-license wiring — trials, upgrade paths, bundle entitlements, dealer allocations: business logic encoded in the platform’s model, which will not map one-to-one onto the next system’s model.
- Refund and chargeback history — your risk profile with card networks doesn’t automatically follow you; a fresh payment relationship starts partly from zero.
- Tax registrations and invoicing continuity — if the platform was your merchant of record, the paper trail of who sold what, where, changes shape mid-year.
A separated stack does not make migration free — but notice how much of that list simply drops out. Licensing already lives in its own layer, so items 3 and 4 don’t move at all when you change payment providers, and items 1, 2, 5 and 6 don’t move when you change licensing. Each layer’s exit cost stays the size of that layer.
There is also a subtler cost, and it is my honest answer to the “fade into the background” promise: what fades into the background stops being monitored, and what stops being monitored is what costs the most to move on the day you finally need to. The invisible system is precisely the one whose migration surface grows unattended — until an acquisition headline makes it very visible, all at once.
So which one should you choose?
Honest decision matrix. Bundled is the right answer when most of these are true:
- You are shipping your first product and have no existing payment relationships to preserve.
- You genuinely want zero involvement in tax handling, and MoR economics beat hiring an accountant at your current volume.
- Your revenue is small enough that per-sale platform fees cost less than the setup time they save.
- You accept lock-in knowingly, as the price of fewer decisions right now — and you write down what leaving would take, so future-you isn’t surprised.
Separated is the right answer when any of these are true:
- You might ever renegotiate or switch payment processors — for fees, for a checkout experience you control, or to sell direct with your own branding.
- You want the customer relationship to be yours: your accounts, your emails, your download page, not a third-party storefront’s.
- You sell through more than one channel — direct, dealers, marketplace bundles — and need one consistent license layer across all of them.
- You sell into regions your platform cannot serve, so some revenue must flow through other rails anyway.
- You have (or want) enterprise customers — schools, studios, institutions that pay by purchase order, net-30 invoice, ACH or wire. Some payment platforms handle these; many make them painful or impossible. The day yours doesn’t, a bundle leaves you no route — a separated license layer doesn’t care how the money arrived, so you can bolt on whatever rails the deal requires.
- You already know licensing is long-lived infrastructure for your catalog, and you want its lifecycle decoupled from whoever happens to process cards this year.
One clarification, because it is the most common misreading of this argument: separated does not mean anti-MoR. If a merchant of record earns its fee for you — global VAT and sales-tax handling alone can justify it — keep one, for payments. The sellers who came through the Lemon Squeezy acquisition unscathed were exactly that group: MoR for checkout and tax, licensing elsewhere. The line I am drawing is not “avoid payment platforms”; it is don’t let your licenses live inside the payment plan.
If the first list describes you, use the bundle with open eyes — it is the right stage-one tool, and this article will still be here when your second product ships. If the second list describes you, keep the two jobs in two layers.
And let me price the separation honestly, because “just add a webhook” would be underselling it: the seam between the two layers is the set of events where money changes state — sale issues a license, refund or chargeback revokes one, a subscription lapse suspends one. That is real integration work, and it needs to keep working. But notice what kind of work it is: maintaining a small, explicit interface between two systems you can each replace. The bundled alternative is not less work — it is the same wiring, done invisibly inside the platform, in exchange for the two layers becoming inseparable. You are choosing between maintaining an interface and marrying a data model. Interfaces are the cheaper long-term relationship.
The quiet decision
Pricing gets compared in spreadsheets. Features get compared in demo calls. Architecture rarely gets compared at all — it gets inherited from whatever was easiest in week one, and it surfaces years later as either optionality or a hostage situation.
The plugin makers I have watched navigate twenty years of this industry — platform shifts, format wars, distributor collapses, acquisition seasons — the ones who came through with their catalogs intact were consistently the ones whose critical systems could be replaced one at a time.
Your licensing will outlive your current payment setup.
Choose a structure where that sentence is an observation, not a problem.
This post is part of the Audio Plugin Business Reality series — how to actually build, ship, and sustain an indie audio plugin business. The companion post on the pricing side of merchant-of-record platforms (the per-sale math over three years) is coming later in the series. If you want the separated-stack model with a licensing layer that connects to any payment setup, that’s what Keyzy does.