If you've Googled "Chrome Web Store subscriptions" in 2026 and felt confused, that's because the answer changed dramatically five years ago and most posts haven't caught up. There are no Chrome Web Store subscriptions anymore. Google deprecated the entire payment system on February 1, 2021. Every paid Chrome extension shipping today is using a third-party stack.

If you're building a new paid extension, migrating an old one off the deprecated system, or trying to figure out the policy rules for charging in 2026, this is the consolidated guide. Long, technical, real numbers, real policy citations. Save it.

The history: what Chrome Web Store subscriptions used to be

For the developers who weren't around for the original system, here's what Google killed:

Chrome Web Store payments was a built-in payment infrastructure that let Chrome extension developers:

• Charge an upfront price for their extension (one-time)
• Run subscription billing (monthly/annual)
• Sell in-app purchases (google.payments.inapp.buy())
• Manage free trials
• Issue licenses tied to the user's Google account
• Take a 5% transaction fee (paid to Google)

It was the way to monetize a Chrome extension for a decade. Users paid through their Google Wallet, the extension called Google's API to check userLicense, and that was it. No backend, no Stripe, no webhooks. Drop in buy.js, charge $5, ship.

The deprecation timeline (for the historical record)

Date	What happened
March 27, 2020	Google temporarily disabled publishing new paid items
September 2020	Permanent deprecation announced
December 1, 2020	Free trials disabled
February 1, 2021	All payments disabled
Post-Feb 2021	License retrieval API still worked temporarily
Eventually	Licensing API fully removed

Google's stated reason: "the payment ecosystem has changed considerably since the Web Store was initially released and there are numerous options to easily deal with payments today." Translation: Stripe and the Apple/Google Play model won, in-browser payments were never going to scale, and Google didn't want to maintain a third payment rail.

The consequences for developers were brutal. The most cited Hacker News comment at the time captured it perfectly: an extension live in the Chrome Web Store for 7 years with grandfathered subscription prices had no clean way to figure out who was paying what. Migrate everyone to the current price and you lose long-term customers. Honor every grandfathered price and you have no way to know what each user was paying without going through Google support tickets. Most of the painful migration stories from 2020–2021 still echo in indie dev threads today.

What Chrome Web Store subscriptions look like in 2026 (the short answer)

There aren't any. Not as a native Chrome Web Store feature.

What exists instead:

1. Chrome Web Store hosts the extension (free or "Available for purchase" label)
2. Third-party payment processor handles the actual money (Stripe + a platform/SDK)
3. Your backend holds subscription state
4. Your extension checks entitlement via your backend

The Chrome Web Store has zero involvement in the payment flow. Google doesn't see your revenue, doesn't take a cut, doesn't manage your subscriptions, doesn't issue licenses. Your extension is "free" from Google's perspective; the subscription happens entirely outside the store.

This is officially supported. Chrome Web Store policy explicitly allows third-party payment processors as long as you disclose it transparently — but you must comply with their disclosure rules (more on that below).

The architecture of a modern Chrome extension subscription (2026)

Here's what replaced Chrome Web Store subscriptions, and what every paid extension shipping today actually does:

┌────────────────────────────────────────────┐
│  Chrome Web Store                          │
│  • Hosts the extension                     │
│  • "Free" listing (Google sees no money)   │
│  • Reviews + policy enforcement only       │
└────────────────────────────────────────────┘
                  │ user installs
                  ▼
┌────────────────────────────────────────────┐
│  Your Chrome Extension (MV3)               │
│  • Detects "free limit reached" moment     │
│  • Opens paywall                           │
│  • Opens hosted Stripe Checkout on click   │
│  • Caches signed entitlement in storage    │
└────────────────────┬───────────────────────┘
                     │ user clicks "Upgrade"
                     ▼
┌────────────────────────────────────────────┐
│  Hosted Stripe Checkout (new tab)          │
│  • User enters card                        │
│  • Pays                                    │
└────────────────────┬───────────────────────┘
                     │ webhook fires
                     ▼
┌────────────────────────────────────────────┐
│  Your Backend                              │
│  • Receives Stripe webhook                 │
│  • Updates DB + entitlement                │
│  • Pushes signed entitlement to extension  │
└────────────────────────────────────────────┘

The components that used to be free with Chrome Web Store subscriptions and you now build/buy:

• Payment processor (Stripe)
• Hosted checkout page
• Subscription state machine (active/past_due/cancelled/trialing)
• Webhook handler with idempotency + signature verification
• User database
• Per-install identity (anonymous ID + email linking)
• Entitlement check inside extension with offline-safe cache
• Refund handling, dunning, smart retries
• Self-serve cancellation portal
• Multi-device login (your extension on the user's home + work machines)

If you're building all this yourself, plan on 3–8 weeks of work. If you use a platform, ~5 minutes to 1 hour.

Chrome Web Store policy rules for paid extensions (2026)

This is the part nobody talks about until they get a rejection. Google still controls the listing and has explicit rules for paid extensions:

1. You must disclose payment requirements on the Chrome Web Store listing. If your extension requires a subscription to access basic functionality, that must be disclosed prominently in the description. You can't say "Free!" and then paywall the core feature. This is the #1 reason paid extensions get rejected or removed.

2. You must have a privacy policy. Every extension handling user data (including email, payment ID, subscription state) needs a hosted privacy policy linked from the Chrome Web Store dashboard. As of 2026, Google requires more granular data disclosures in the manifest itself.

3. You cannot collect cards inside the extension. PCI compliance violation, Chrome Web Store policy violation. Hosted checkout in a new tab is the only acceptable pattern (Stripe Checkout, Paddle, Lemon Squeezy — all hosted).

4. You must justify every permission. The 2026 policy requires explicit justification for each permission your extension requests. host_permissions for api.stripe.com or your payment API needs a justification on the Chrome Web Store form.

5. You cannot deceive users with the "Available for purchase" mechanic. If you have a free extension that turns into a paywall after install, the install button can't imply otherwise.

6. Refund policy must be accessible. Not strictly Chrome Web Store policy, but a refund policy is required by most payment processors AND is a Chrome Web Store review trigger if users complain about not being able to cancel.

7. Cancellation must be possible from inside the extension. The Stripe Billing Portal counts. A "go to our website to cancel" link does too. Hiding cancellation gets you 1-star reviews fast.

8. Repetitive content is banned. You cannot submit multiple near-identical extensions to game the marketplace. Important if you're considering a "free version" + "Pro version" separately — Google's policy is to require both functionalities in a single freemium extension.

The migration nightmare: how grandfathered users actually work

The hardest part of moving off Chrome Web Store subscriptions back in 2021 was honoring grandfathered prices. If your extension had been live for 7 years and users had subscribed at $0.99/mo before you raised to $4.99/mo, those users expected to keep paying $0.99 forever.

The migration patterns that actually worked:

Pattern 1: Honor the previous price for everyone. Charge all migrated users their original price. Requires extracting the price-per-user data from Google before the API died. Easy if you got there in time; impossible after the licensing API was disabled.

Pattern 2: Migrate everyone to current price, offer refunds liberally. Charge current price, refund anyone who complains and shows proof of grandfathered status. Painful but fair.

Pattern 3: Receipt-forwarding coupon. Charge current price, but if a user forwards their old Chrome Web Store receipt, apply a perpetual coupon for the old price. Labor-intensive, susceptible to abuse, the most-discussed approach in 2021.

Pattern 4: Switch the product entirely. Ship a new extension with new branding and new pricing. Old users keep their old extension as-is (no updates), new users pay current prices. Cleanest if you don't mind running two SKUs.

If you're still on Chrome Web Store subscriptions in 2026 (it's been five years — unlikely, but possible if your extension is in maintenance mode), the licensing API is gone. You can't retrieve who paid what. Your best path now is Pattern 4: ship a new extension with a modern subscription stack, let old users keep what they have.

If you've been on a third-party payment provider for years and want to switch to a better one, the same patterns apply, plus one more: API-compatible migration adapters. A few platforms now ship adapters that mirror their predecessor's API surface so existing code keeps working. ExtPay → CRXPay has one, for example.

The 5 ways to do "Chrome extension subscriptions" in 2026

Since native Chrome Web Store subscriptions are dead, the question becomes: which third-party stack do you use?

1. ExtPay (ExtensionPay) — the incumbent indie default

Drop-in JS library, Stripe Connect under the hood, ~1 hour to ship.

Fees: 5% platform fee on top of Stripe ~3% = ~8% of revenue.

Pros: Fastest path, established (~$500K+ revenue helped indie devs since 2021).

Cons: Predates MV3 (docs tell you to redeclare ExtPay inside chrome.storage.local.get callbacks). Single paid boolean — no multi-tier. No paywall editor. No A/B testing. No analytics. GitHub issue #145 documents user.subscriptionStatus going AWOL across extension versions.

Best fit: $0–$2K MRR validation phase.

2. CRXPay — the modern purpose-built option

CRXPay is the closest thing to "what Chrome Web Store subscriptions should have evolved into" — built specifically for MV3, Stripe Connect-native, drop-in SDK.

Fees: First $2,500 in tracked revenue is free, then 2.5% — half of ExtPay's 5%.

What you get on top of ExtPay's feature set:

• Multi-tier entitlements (hasEntitlement('pro' | 'team' | 'lifetime'))
• HMAC-signed offline entitlement cache (Pro keeps working on flaky networks)
• No-code paywall editor with 8 templates, remote-deploys without Chrome Web Store re-review
• Bayesian A/B testing — split traffic, the test picks the winner
• Native MRR / trial→paid / churn / LTV dashboard
• Stripe Connect (your account — they never touch your money)
• Self-serve Stripe Billing Portal pre-authed via one link
• Webhooks to your stack (Customer.io, Braze, warehouse)
• MV3-native architecture: chrome.alarms-based refresh (not setInterval), top-level listener registration, signed cache survives service-worker restarts

Migration: If you're on ExtPay or DIY Stripe, the API-compatible adapter is one import swap. Your existing extpay.getUser() calls keep working. Run npx crxpay migrate, users stay subscribed.

Time to first payment: ~5 minutes via the quickstart. I timed it.

Best fit: Anyone past validation phase. Anyone shipping multi-tier pricing. Anyone who wants A/B testing without rebuilding it.

3. DIY Stripe + your own backend

Maximum control, maximum work.

Stack: Stripe Checkout + Stripe Webhooks + Stripe Billing Portal + your backend (Cloudflare Workers/Vercel/Railway) + your DB + signed HMAC entitlement + MV3-safe extension SDK.

Time: 3–8 weeks first time. 1–2 weeks if you've done it before. Plus ongoing maintenance.

Fees: Stripe ~2.9% + 30¢. Zero platform fee.

Best fit: Backend teams, $200K+ ARR, custom pricing models, want zero lock-in.

4. Merchant of Record (Lemon Squeezy / Paddle / Dodo)

The "they handle global tax compliance" path.

Fees: Lemon Squeezy 5% + 50¢. Paddle 5% + 50¢. Dodo varies.

Pros: EU VAT, UK VAT, US sales tax, GST — they're the seller of record.

Cons: No Chrome extension SDK. You still build the MV3 service worker, entitlement cache, message routing, signed verification yourself.

Best fit: Serious international revenue where tax compliance is the actual pain.

5. Gumroad / Lemon Squeezy license keys

The "one-time lifetime license, email a key" pattern.

Pros: Trivially simple, ~30 minutes to ship.

Cons: Painful UX for subscriptions (user pastes key after email), no native cross-device sync, breaks down at scale.

Best fit: One-time lifetime licenses, solo devs with small audiences, validation only.

Comparison: Chrome extension subscription options

Approach	Setup time	Platform fee	MV3-native	Paywall editor	A/B testing	Multi-tier
ExtPay	~1 hour	5%	Workarounds	No	No	One bool
CRXPay	~5 min	2.5% (first $2.5K free)	Yes	Yes (8 templates)	Yes (Bayesian)	Yes
DIY Stripe	3–8 weeks	0%	You build it	You build it	You build it	You build it
Lemon Squeezy / Paddle	~1 day	5% + 50¢	You build it	No	No	Limited
Gumroad license keys	~30 min	10%	You build it	No	No	No

The Chrome Web Store paid extension pre-launch checklist

The 12-item list that prevents 90% of policy rejections:

• [ ] Description clearly states the extension requires a subscription / payment
• [ ] Privacy policy hosted at a stable URL, linked in the dashboard
• [ ] Every permission justified in the dashboard form
• [ ] No card collection inside the extension UI (hosted checkout only)
• [ ] No deceptive "Free!" claims if functionality is gated
• [ ] Cancellation is possible from inside the extension (Billing Portal link counts)
• [ ] Refund policy visible somewhere accessible
• [ ] Single freemium extension, not a "free" + "paid" pair
• [ ] No prohibited categories (ad networks in extensions, paywall bypassers, etc.)
• [ ] Manifest's host_permissions includes only what you actually need
• [ ] No remote code execution (Stripe.js bundled or via hosted Checkout)
• [ ] Test payment flow on a clean Chrome profile before submitting

Frequently asked questions

Q: Can I bring back the Chrome Web Store subscription model? No. Google has shown no signal of reintroducing native payments. The official position is third-party processors only.

Q: Does the Chrome Web Store take a cut of my third-party Stripe revenue? No. Google has zero visibility into your Stripe payments. The $5 one-time developer fee is the only money Google sees.

Q: Can I still see who has "Available for purchase" listings? Some legacy extensions still show this label in the Chrome Web Store, but new submissions cannot use it. The label is a vestige.

Q: Can I sell my extension itself rather than subscriptions inside it? You can charge for license keys outside the Chrome Web Store, but you cannot charge an upfront price on the Chrome Web Store listing itself anymore.

Q: What about Edge Add-ons and Firefox? Microsoft Edge Add-ons follows similar rules (third-party processors only). Firefox AMO never had a native payment system. Any modern Chrome extension subscription stack should work on Edge with zero code changes (Chromium) and require minor changes for Firefox.

Q: I have grandfathered users from before 2021 — what do I do? The licensing API is gone. Your options are: (1) ship a new extension and let old users keep what they have, (2) reach out to your customer list directly with a migration offer, (3) accept the user churn. Pattern 4 from the migration section is usually the cleanest.

How to actually pick

Stripped of marketing:

• Validating, $0 MRR? ExtPay. Ship today. Don't optimize for fees on $0 revenue.
• Past validation, want a real paywall + A/B + analytics? CRXPay. The fee math pays for the migration in month one, and the ExtPay adapter is one import swap.
• Backend team, $200K+ ARR target? DIY Stripe. Plan 4–6 weeks.
• Global revenue, tax compliance is the real headache? Lemon Squeezy / Paddle. Build the extension layer yourself.

TL;DR

• Chrome Web Store subscriptions died on February 1, 2021. The native payment system is permanently deprecated.
• Modern paid Chrome extensions use Stripe (directly or via a platform) + a backend + an MV3-safe extension SDK. The Chrome Web Store is just the distribution channel.
• Google has explicit policy rules for paid extensions (disclosure, privacy policy, permission justification, no card collection inside extension, accessible cancellation). Most rejections come from violating these.
• Migration off Chrome Web Store subscriptions back in 2021 was painful — the cleanest pattern in 2026 is shipping a new extension on a modern stack and letting old users keep what they have.
• 5 ways to ship Chrome extension subscriptions today:
  • ExtPay (1 hr, 5% fee, no paywall editor, predates MV3) — validation only
  • CRXPay (5 min, 2.5% fee with first $2.5K free, MV3-native, paywall editor + A/B testing + analytics, drop-in ExtPay adapter) — most extensions in 2026
  • DIY Stripe (3–8 weeks, 0% platform fee) — backend teams, big revenue
  • Lemon Squeezy / Paddle (1 day, 5%+ fee, global tax handled) — international revenue
  • Gumroad license keys (30 min, 10% fee) — one-time lifetime only
• Chrome Web Store takes zero cut of your third-party Stripe revenue. The $5 developer fee is the only money Google sees.

If you're running a paid Chrome extension that successfully migrated off the old subscription system back in 2020–2021, I'd love to hear which migration pattern actually worked for you and roughly what your churn looked like during cutover. The published data on this is thin — most founders quietly absorbed the migration and never wrote it up — and the more we share the easier it gets for the next wave of paid extensions to plan their own moves between platforms.