You built an extension people love. Now you want it to pay for itself. The good news: monetizing a browser extension in 2026 is far simpler than it was a few years ago. The hard parts (billing, taxes, license checks) are now solvable with a drop-in SDK.

The bad news: most extension developers still get two things wrong. They pick a monetization model that doesn’t match how people use their extension, and they ignore sales tax until it becomes a real liability. This guide covers both, plus the practical mechanics of collecting money from inside an extension.

One piece of history worth knowing: the Chrome Web Store used to have its own built-in payments system. Google shut it down in 2021 and never replaced it, so every paid extension today brings its own billing. That is why this guide exists, and why the tooling around extension payments has matured so quickly since.

The monetization models that actually work

Not every model fits every extension. Pick based on how people use yours, not on what you’d like to earn.

One-time license

Best for utilities with a clear “unlock the full version” moment: a screenshot tool, a tab manager, a formatter. The user pays once and owns the upgrade.

Pricing that works in practice: most successful one-time extension licenses land between $10 and $50. Below $10 you’re leaving money on the table for anything genuinely useful; above $50 buyers start expecting a desktop-app level of polish and support.
Why it’s attractive: easy to reason about, no churn to manage, no recurring-value obligation. Support load stays predictable.
The trade-off: revenue only grows with new installs. Once you saturate your niche, income flattens. Some developers add a paid “v2 upgrade” every couple of years to re-monetize the existing base; that works, but plan it honestly so buyers don’t feel baited.

Subscription

Best for extensions that deliver ongoing value: sync across devices, AI features that cost you inference money, continuously updated data, or anything with server-side costs that scale with usage.

Pricing that works in practice: $3 to $10 per month is the sweet spot for individual users; the most common successful price point is $4.99/mo with a discounted annual plan at roughly ten months’ price. Teams and B2B use cases can support several times that.
Why it’s attractive: predictable recurring revenue that compounds with install growth instead of resetting every month.
The trade-off: you owe continuous value. A subscription for a static utility gets angry reviews and refund requests. If your extension would work fine offline forever, sell a license instead.

Freemium

A free tier for reach, a paid tier for power users. This is the default for most successful extensions in 2026, and it pairs with either model above (a freemium one-time unlock or a freemium subscription).

Where to draw the line: the free tier must be genuinely useful, not a crippled demo, because installs and Chrome Web Store ranking are your top of funnel. Gate the features that correlate with heavy or professional use: higher limits, bulk operations, export, sync, advanced settings.
Conversion expectations: free-to-paid conversion for extensions typically runs between 1% and 5%. That means the math only works with meaningful install volume, which is exactly what the free tier is for.
The trade-off: you support a large free user base that never pays. Budget your support time accordingly.

Usage-based

Charge per action: API calls, AI generations, documents processed. Fair for compute-heavy tools where your own costs scale with usage, and increasingly common for AI extensions.

Where it works: credit packs (“500 generations for $9”) are easier for buyers to accept than a metered bill, and they pre-pay your inference costs.
The trade-off: metering adds product complexity, and users dislike unpredictable bills. A hybrid (subscription that includes a generous usage allowance) usually beats pure pay-per-use.

Choosing between them

Three questions settle it in most cases:

Does the value repeat? Ongoing value → subscription. One-time unlock → license.
Do you have per-user costs? Server or AI costs → subscription or usage-based, never a one-time license that obligates you to pay for a user forever.
Is your niche big? Small, professional niche → higher one-time price or B2B subscription. Large consumer niche → freemium with a cheap subscription.

The part everyone underestimates: tax

Once you sell to users worldwide, you are on the hook for VAT, GST, and sales tax in dozens of jurisdictions. The EU wants VAT from the first euro of B2C digital sales. The UK is the same. Australia and India have GST regimes; Canada has federal GST plus provincial rules; in the US, dozens of states now tax SaaS and digital goods once you cross their economic-nexus thresholds.

Handling this yourself means registering with each tax authority, charging the right rate per buyer location, filing returns on each authority’s calendar, and keeping evidence of where every buyer was. For a solo developer earning a few thousand dollars a month, that is not a Saturday project; it’s the reason many extension developers historically just didn’t charge money, or charged it non-compliantly and hoped.

A Merchant of Record (MoR) solves it: the MoR is the legal seller, so it collects and remits tax for you. Providers like Polar, Paddle, Lemon Squeezy, Creem, and Dodo Payments all operate this way. You get paid, they handle compliance, and the tax authorities have no claim on you personally because you were never the seller of record.

The tools, compared honestly

Three SDK-level tools target extension payments directly in 2026. They look similar in a code sample; the differences are in fees and in who owns the tax problem.

	ExtensionBill	ExtPay	BrowserBill
Fee model	Flat monthly fee (free tier available)	5% of revenue	5% of revenue
Tax / VAT handled	Yes — via your connected Merchant of Record	No — tax stays with you	No — tax stays with you
Backend required	No	No	No
Checkout & billing	Your choice of MoR (Polar, Paddle, Lemon Squeezy, Creem, Dodo)	Stripe under the hood	Hosted checkout
Revenue at $5,000/mo	Your flat plan fee	$250/mo	$250/mo

ExtPay deserves real credit: it proved the no-backend extension-payments model, it’s open source, and its 5% fee is simple. Its two structural gaps are the ones above: the fee scales with your success forever, and because Stripe is the processor and you are the merchant of record, worldwide tax registration and filing remain your problem. BrowserBill follows the same model with the same trade-offs.

ExtensionBill was built to keep the integration simplicity and close those two gaps: a flat fee instead of a percentage, and a Merchant of Record in the loop so tax is handled from the first sale. For a deeper tool-by-tool comparison including Paddle, Lemon Squeezy, Stripe, and Dodo Payments directly, see ExtPay alternatives, compared.

Collecting payments without a backend

Historically, gating a feature meant standing up a server: a license database, checkout webhooks, an API your extension calls to verify status, and all the uptime and security obligations that come with it. That is a lot of infrastructure for a feature flag.

The modern approach is an SDK that talks to a hosted billing service. In your extension you write something like:

import ExtensionBill from 'extensionbill'

const extpay = ExtensionBill('your-extension-id')
extpay.start()

const user = await extpay.getUser()
if (user.paid) {
  unlockProFeatures()
} else {
  extpay.openCheckout()
}

No server, no database, no webhook plumbing on your side. The SDK checks the user’s status against the hosted verification layer and opens a checkout page when needed. It also plays correctly with Manifest V3’s service-worker lifecycle, where a persistent background page no longer exists and anything stateful has to survive the worker being killed and restarted.

Two implementation rules save the most debugging time:

Treat the SDK’s answer as the source of truth. Don’t mirror paid into chrome.storage and read the mirror; stale or user-edited storage is the most common cause of “my paywall stopped working.”
Initialize in the service worker, at the top level. Event-driven workers restart constantly; top-level initialization re-registers your listeners on every wake.

The full walkthrough, from npm install to reacting to a completed checkout with onPaid, is here: How to Add Payments to a Chrome Extension (2026 Guide).

Realistic revenue math

Before you invest a month in monetization, sanity-check the numbers your niche can support. The arithmetic is simple and worth doing explicitly.

Say your extension has 20,000 weekly active users, you launch a freemium subscription at $4.99/mo, and you convert at the midpoint of the typical range (about 2.5%). That’s 500 paying users and roughly $2,500/mo before fees. On a 5%-of-revenue tool you’d hand over $125 every month, growing with you forever; on a flat-fee plan the cost stays fixed no matter how the subscriber count grows.

Now run your own numbers pessimistically: assume 1% conversion and the annual plan cannibalizing a chunk of monthly revenue at a discount. If the pessimistic case still pays for the time you’ll invest, monetize. If it only works at 5% conversion, either your audience is too small or your paid feature isn’t valuable enough yet — fix that before you build billing.

Two levers move these numbers more than anything else:

Annual plans. Offering a yearly price at roughly ten months’ cost typically shifts 30-50% of subscribers to annual, which slashes churn and pulls cash forward. Always offer one.
The upgrade moment. Conversion doubles when the paywall appears at the exact moment of need (the user clicks the pro feature) rather than as a banner. Design the prompt around intent, not visibility.

Refunds, chargebacks, and the support you’ll actually get

Money brings a class of support work extensions never see while free, and it’s worth knowing who absorbs it in each setup.

Refunds. Digital-goods buyers expect a no-questions refund window; 14 days is the de facto standard (and an EU expectation for consumers). With a Merchant of Record, the refund button, the money movement, and the receipt correction happen on the MoR’s side — you just set the policy. Rolling your own Stripe integration means building refund handling and reconciling it against your license state yourself.
Chargebacks. A disputed card payment costs a fee (typically $15-25) plus the sale, and repeated disputes can threaten a merchant account. As merchant of record, an MoR eats the dispute process, represents the transaction with its own evidence, and absorbs the account risk. Solo developers are terrible at winning disputes; this is quietly one of the biggest reasons to use an MoR beyond tax.
Payment support email. “I paid but it didn’t unlock,” “my card was declined,” “I need an invoice with my VAT number” — expect a steady trickle. Hosted checkout plus MoR-issued invoices eliminates most of the invoice and card questions; the unlock questions are why you keep the SDK’s paid check as the single source of truth instead of a cached copy.

Budget an hour or two a week for payment-adjacent support once revenue is real. It’s manageable, but it isn’t zero, and percentage-fee tools don’t do any of this work for you despite taking a cut sized like they do.

A sensible launch plan

Ship a genuinely useful free tier and grow install count. Installs are your funnel, your Chrome Web Store ranking signal, and your review source. Don’t gate anything until the free product stands on its own.
Identify the one feature power users would pay for. Read your reviews and support emails; the feature people ask for insistently is usually the one they’ll pay for. Resist gating five things at once — one clear upgrade reason converts better than a feature matrix.
Add the paid tier behind a license check with the SDK above. This is an afternoon of work, not a quarter. Keep the free tier’s behavior unchanged so existing users never feel a rug-pull.
Connect a Merchant of Record so tax is handled from day one. Retrofitting compliance after a year of non-compliant sales is much more painful than starting clean.
Watch conversion, then iterate on pricing. Measure free-to-paid conversion and checkout abandonment. Price changes are cheap experiments: most developers underprice, and a 50% price increase that costs you a quarter of conversions is still a revenue win.

Chrome Web Store rules that touch monetization

Payments don’t exempt you from store policy; a few rules bite monetized extensions specifically:

Say what’s paid in your listing. If core functionality requires payment, the listing must make that clear. Surprise paywalls right after install are a common trigger for user flagging and review-team attention.
The single-purpose rule still applies. You can’t bolt an unrelated paid feature onto an existing extension to monetize it; the paid tier has to be the same purpose, deeper.
No deceptive urgency. Fake “50% off, 10 minutes left” countdowns inside the extension UI fall under deceptive-behavior policy. Real, honest launch discounts are fine.
Keep checkout outside the store’s chrome. Hosted checkout pages (what every SDK in the table above uses) are standard practice; injecting payment forms into third-party sites your extension modifies is not.

None of these are hard to satisfy, but a takedown while you’re earning is far more expensive than reading the policy up front.

Common mistakes to avoid

Subscriptions on static utilities. If the extension delivers the same value offline forever, a subscription reads as rent-seeking and earns one-star reviews. Sell a license.
Gating the core feature. The thing that made people install must stay free; monetize depth, not entry.
Ignoring tax “until it matters.” Thresholds arrive faster than expected, and some jurisdictions (the EU in particular) have no minimum threshold for B2C digital sales. If you’re not using an MoR, you’re accruing obligations from sale one.
Building a license server “properly” first. Developers lose months to auth, webhooks, and database plumbing before earning their first dollar. The SDK route gets you to revenue in a day; you can always build custom infrastructure later if you outgrow it.
Percentage fees on autopilot. A 5% cut sounds small at $200/mo and feels very different at $10,000/mo. Do the arithmetic at the revenue you’re aiming for, not the revenue you have.

The bottom line

Pick the model that matches how your extension delivers value. Charge more than feels comfortable. Let a Merchant of Record own the tax problem from day one. And don’t build a backend for a feature flag.

Want the shortcut? ExtensionBill gives you a clean, no-backend SDK plus your choice of Merchant of Record, so you can go from free to paid in an afternoon. Start with the step-by-step payments tutorial.