Chrome Web Store Payments Replacement: What To Use Now

Chrome Web Store payments are not coming back as the default way to charge for a Chrome extension. Google deprecated the system, then stopped existing Chrome Web Store payments from charging money on February 1, 2021 (Google Chrome for Developers, Chrome Web Store payments deprecation).

That leaves a practical question: what should you use instead? If you are planning Chrome extension monetization, the right answer depends on what you want to own: checkout, tax, user login, entitlement state, support, or all of it.

TL;DR

• In 2021, Google stopped Chrome Web Store payments from charging existing users.
• Stripe gives the most control, but it needs a backend.
• crxbase reduces extension-specific billing work.
• Paddle is strongest when merchant-of-record coverage matters.

What Replaced Chrome Web Store Payments?

Google still points affected developers away from Chrome Web Store payments and toward another payment processor, after ending new paid items on September 21, 2020 and disabling existing charges on February 1, 2021 (Google Chrome for Developers, Chrome Web Store payments deprecation). The replacement is not one product. It is a stack.

The old model bundled purchase, renewal, and license status inside the Chrome Web Store. The new model splits those jobs. A processor collects money. A backend stores access state. Your extension checks that state before enabling paid features. Checkout alone creates revenue events, not a reliable access system.

Google's policy also matters. If basic functionality requires payment, the listing needs to say so. You also need terms of sale, refund language, secure payment-data handling, and a clear seller identity (Google Chrome for Developers, Chrome Web Store Program Policies). For policy details, review whether paid Chrome extensions are allowed before publishing.

Decision Matrix: Which Replacement Fits Your Extension?

Use this matrix if any of those still shape your billing model.

Choose Stripe directly when control is worth the backend. Choose crxbase when you want Stripe plus extension-specific hosted billing and SDK checks. Choose Paddle when tax and merchant-of-record duties matter more than fee minimization. Choose checkout-only only for deliberately simple access.

Option 1: When Should You Build A Custom Stripe Backend?

A custom Stripe backend fits teams that want direct control and can maintain billing code.

The custom route usually means Stripe Checkout, Stripe Customer Portal, your own user table, webhook handlers, and an entitlement table. Your extension should call your backend to ask whether the current user has paid access. It should not store Stripe secret keys or privileged license logic in extension code.

Stripe says Checkout supports one-time and subscription payments with more than 40 local payment methods (Stripe Docs, Use a prebuilt Stripe-hosted payment page). That gets payment out of the extension context. The remaining work is state: cancellations, failed payments, plan changes, refunds, and reinstalls.

Choose custom Stripe if you need unusual pricing, product-specific billing rules, or tight integration with an existing app. Avoid it if your main goal is to charge for a browser extension feature and keep maintenance low. Pair this path with a paid extension checklist before review.

Option 2: When Does crxbase Make Sense?

crxbase supports subscriptions, one-time payments, free trials, a developer dashboard, Stripe Checkout, Customer Portal, webhooks, Connect payouts, and an @crxbase/payments library. It makes sense when you want Stripe-backed payments without building the extension billing layer yourself.

crxbase is not a payment processor. Stripe handles checkout, payment methods, connected accounts, portal behavior, and payment events. crxbase supports the extension-specific layer around that: projects, tiers, hosted pricing pages, login pages, manage pages, webhook synchronization, and SDK access checks.

In practice, a developer creates a project and tiers, connects Stripe, then uses the JavaScript SDK from the extension. Everything is done with methods such as getUser(), openPricingPage(), openCheckoutPage(), openManagePage(), and openLoginPage().

The caveat is that crxbase still inherits payment realities from Stripe. Checkout completion, subscription state, failed payments, portal changes, and payouts depend on Stripe setup and webhook delivery. You still need honest Chrome Web Store listing copy and a paywall UX that does not surprise users.

Option 3: When Should You Use Paddle Or Another Merchant Of Record?

Paddle lists pay-as-you-go pricing at 5% + 50 cents per Checkout transaction and includes tax compliance, billing, fraud protection, and payment-related customer support in that model (Paddle, All-in-One Pricing, No Hidden Costs). A merchant of record fits global selling more than extension-specific access checks.

Paddle can be attractive if you do not want to manage sales tax registration, remittance, compliant invoices, billing support, and parts of chargeback operations yourself. Its developer docs describe Paddle as the merchant of record for digital products, handling payments, tax, fraud, and global compliance (Paddle Developer Docs, Paddle for digital products).

For Chrome extensions, the missing piece is entitlement. Paddle can sell the product and fire webhooks, but your extension still needs to map a Paddle customer or transaction to paid access. Also check seller wording: an MoR checkout may present the provider as legal seller, while Chrome Web Store copy still needs clear payment disclosure.

Option 4: Is External Checkout-Only Safe?

Stripe Checkout can redirect users to a Stripe-hosted page or embed a form on your site, and its lifecycle depends on a checkout.session.completed webhook for fulfillment (Stripe Docs, How Checkout works). A checkout-only setup is safe only when fulfillment and access checks are intentionally simple.

This path often starts as a payment link, Gumroad-style product, Lemon Squeezy-style checkout, or Stripe-hosted page. A user pays outside the extension. You email a license key, unlock manually, or store access in a small database. That can work for validation, but subscriptions usually expose the gaps.

Policy risk comes from surprise, not from using an external page by itself. Do not hide paid access until after install, mimic the Chrome Web Store, require unrelated actions, or expose payment information inside the extension unless you can meet the security and disclosure requirements.

Choose checkout-only if you are testing willingness to pay, selling a simple lifetime key, or serving a tiny customer base manually. Move to a real entitlement system before trials, refunds, plan switching, or multi-device login become normal support issues.

Migration Checklist For Replacing Chrome Web Store Payments

In 2020, Google said there was no way to bulk export existing Chrome Web Store user licenses, so affected developers needed users to help with migration (Google Chrome for Developers, Chrome Web Store payments deprecation). That constraint should shape the migration plan before you pick a processor.

1. Audit how the extension currently knows a user has paid.
2. Choose the new seller model: self-merchant with Stripe, hosted extension billing, or merchant of record.
3. Create a new entitlement record that is independent from Chrome Web Store licensing.
4. Build or adopt login so the same user can regain paid access after reinstalling.
5. Route new purchases through the replacement checkout.
6. Sync payment events into entitlement state through signed webhooks.
7. Publish a version that explains the migration and directs paid users to the new flow.
8. Update the Chrome Web Store listing, terms, privacy policy, and support contact.
9. Test cancellation, failed payment, refund, reinstall, multi-device login, and plan switching.
10. Keep the old license check in read-only mode until the migration window closes.

Migration copy should say what changes, what stays unlocked, who processes payment, who provides support, and what happens to old purchases.

For a policy-first review pass, use the paid extension checklist before release. It is easier to fix disclosure text before review than after a rejection.

Frequently Asked Questions

What replaced Chrome Web Store payments?

No single Google product replaced it. In 2021, Google stopped existing Chrome Web Store payments from charging money, so developers now use Stripe, hosted extension billing services, merchant-of-record providers, or external checkout flows.

Are third-party payments allowed for Chrome extensions?

Yes, but the implementation must follow Chrome Web Store policies. Google's payment section lists five requirements, including secure handling, clear terms, paid-functionality disclosure, and seller identification.

Is Stripe enough by itself?

Stripe is enough for checkout, but not for the whole extension access model. Stripe Checkout supports one-time and subscription payments, but you still need identity, webhooks, entitlement storage, and access checks.

Evaluate crxbase for Your Replacement Stack

If you want Stripe-backed checkout, hosted billing pages, and extension-specific entitlement checks in one setup, crxbase supports the layer Chrome Web Store payments no longer provides: connecting payment events to paid access in your extension.