Payments for Chrome extensions look simple until you try to build them. You've decided to charge for a Chrome extension — maybe you read the pricing guide and picked freemium or a subscription — and now you need to actually collect money and gate a feature behind it. That's a different problem than picking a price: it's an architecture problem first, a payment-processor decision second, and a licensing problem third. This post covers all three, in the order you'll hit them.
The architecture
The first thing to understand is what a Chrome extension cannot do: it cannot take payment inside itself. There's no in-extension checkout API and no Web Store billing you can hook into for your own product, and stuffing a card form into a popup would be a security and PCI-compliance mess even if Chrome allowed it. Extensions run in a sandboxed content-script and background-worker environment built to interact with web pages, not to process payments.
So payment has to happen somewhere else, and the extension has to find out about it. The pattern that works is the one most paid extensions quietly use: a SaaS + extension setup, built from:
- A web checkout page — a normal webpage, hosted wherever your marketing site lives, where card entry and subscription creation actually happen.
- Auth — a way to identify a user across the web checkout and the extension, usually an account (email + password, magic link, or OAuth) tied to a user ID in your database.
- A backend that knows entitlement state — your server records who paid, for what, and until when, driven by webhooks from your payment processor.
- The extension talking to that backend — on startup, and periodically after, it calls an API endpoint to check "is this user entitled to the paid feature," and gates the UI accordingly.
This is more infrastructure than "just add a paywall" sounds like, but there's no way around it: the extension is a client, and clients can't be trusted to decide their own entitlement — that decision has to live on a server. You don't have to build it all from scratch: Stripe and Paddle both provide hosted checkout pages, and Firebase, Supabase, or a lightweight Node/Express API can serve as the thin backend that stores entitlement and answers the extension's check.
Stripe vs Paddle
Once you have the SaaS-plus-extension shape in place, the actual payment processor is a swappable piece. The two most common choices are Stripe and Paddle, and they represent genuinely different trade-offs — not just different pricing.
Stripe is a payment processor. It handles the mechanics of charging a card, running a subscription, and sending you webhooks when things happen — but it does not handle sales tax or VAT for you. As the seller, you're the merchant of record, responsible for figuring out which jurisdictions you owe tax in, registering where required, calculating the right rate, and remitting it. Stripe has tooling (Stripe Tax) that can calculate and collect tax on top of the base product, but the compliance obligation is still yours. It's the more flexible, more hands-on option, suited to developers who want fine-grained control over checkout UX and are willing to own the tax question, or who sell into few enough jurisdictions that it isn't a heavy lift.
Paddle is a merchant of record. When you sell through Paddle, Paddle is legally the seller to your customer, and it handles sales tax and VAT calculation, collection, and remittance across the jurisdictions it supports. You give up some control over the checkout flow in exchange for offloading a genuinely painful compliance problem, and merchant-of-record providers like Paddle generally charge a higher processing fee than a plain processor like Stripe for that work — exact numbers vary and are worth checking directly on each provider's pricing page.
The practical way to choose: if you're selling to individuals across many countries and don't want to become a part-time tax accountant, a merchant of record is worth the higher fee. If you're comfortable owning (or delegating) tax compliance yourself, Stripe is a reasonable starting point — you can migrate later, though moving subscribers between processors is real work worth planning for up front.
ExtensionPay is worth a specific mention because it's built for exactly this use case — handling Stripe integration, licensing checks, and the extension-side SDK for you, so you're not building a SaaS backend from scratch just to gate one feature. It trades some flexibility for a much faster path to a working paywall, a reasonable starting point if your needs are straightforward.
Licensing and gating
However you handle payment, the extension still needs a reliable way to check "should I unlock the paid feature for this user right now." That's the licensing question, separate from the payment question. Two common approaches:
License keys. After payment, your backend generates a key tied to the purchase. The user enters it into the extension (or it's fetched automatically if logged in), and the extension validates it against your server. This suits one-time purchases and doesn't require tracking an ongoing session.
Auth tokens. For subscriptions, it's more common to have the user log in inside the extension (or link their account from the web checkout), with the extension holding a token it presents to your backend to check current entitlement — this reflects live subscription state, handling renewals and cancellations more naturally than a static key.
Whichever approach you pick, a few things matter regardless:
Verify server-side, not just client-side. The entitlement check should hit your backend, not just read a flag stored in chrome.storage — anyone with DevTools open can edit local storage, but a signed server response is much harder to fake.
Don't ship secrets in the bundle. Extension code is fully inspectable — anyone can unzip a .crx or read the unpacked source. Never embed API secret keys or database credentials in your extension's JavaScript. Only public, client-safe pieces (a publishable key, a public API endpoint) belong in the bundle; everything that verifies payment belongs on the server.
Build in an offline grace period. Extensions don't always have a live connection when they check entitlement — the user might be offline, or your API might have a bad moment. Cache the last known state locally and allow continued access for a reasonable grace window (a day or a week, depending on how sensitive the feature is) rather than locking users out the instant a network call fails.
Handling churn and refunds
Getting payment wired up is necessary, but it's not the end of the story — paid users still churn, and still ask for refunds, at rates that surprise a lot of first-time extension developers. A subscription that's easy to buy and easy to cancel will see both directions of that traffic.
Make sure your webhook handling actually revokes access when a subscription lapses or a refund is issued (both Stripe and Paddle support cancellations and refunds natively) — an entitlement check that only updates on successful payment, and never on cancellation, will happily keep serving a paid feature to someone who no longer pays for it.
But the more useful lever is understanding why paying users cancel, not just processing the cancellation. Chrome gives you almost no visibility into this by default — no cancellation survey, no uninstall context tied to your billing system. That's a separate problem from picking the right price in the first place, which the pricing guide covers in more depth. UserFeed is built for the churn side of that gap — structured uninstall and cancellation feedback, so a canceled subscription tells you something instead of nothing.
Payments are also just one piece of turning an extension into revenue — if you haven't settled on a monetization approach yet, the broader guide to monetizing a Chrome extension covers the options (ads, affiliate, licensing, paid tiers) above this post's payments-plumbing focus.
Getting started
If you're building payments into a Chrome extension for the first time, the pragmatic path is smaller than the full architecture above might suggest:
- Pick a processor. To avoid tax compliance entirely, start with Paddle or ExtensionPay. If you're comfortable owning tax yourself, or volume is small enough it's not urgent yet, start with Stripe.
- Stand up the smallest backend that can answer one question — a single endpoint checking "is this user's subscription active," backed by your processor's webhooks, is enough to start gating a feature.
- Build a minimal web checkout. A single hosted checkout page (Stripe Checkout or Paddle's hosted checkout) that creates the subscription and redirects back is enough; skip the custom pricing page on day one.
- Wire the extension's entitlement check. Have the extension call your backend on load, cache the result, and gate the paid feature behind it, with the offline grace period described above.
- Add webhook handling for cancellations and refunds before you launch, not after the first refund request arrives — the piece most likely to be skipped under time pressure, and most likely to bite you if it is.
None of this needs to be perfect on day one. Start with the minimum version that can charge a card and correctly gate a feature, then add licensing and churn-visibility refinements once you have real paying users to learn from — UserFeed's own pricing page shows one working example of a free tier plus a paid upgrade for a developer-facing product.
Last updated: August 2026