We just shipped a tutorial for a build most monetization guides skip: a paid Chrome extension with login, checkout, subscriptions, billing, and gated access.
The project has two pieces:
- A Manifest V3 Chrome extension that customers install in Chrome.
- A Next.js web app that handles checkout, API routes, Whop access checks, webhooks, documentation, and production deployment.
The important idea is simple. The Chrome extension is the product interface, but Whop decides who has access. If a user has paid or otherwise has access through Whop, the extension unlocks the paid feature. If they do not, the extension keeps the feature locked and sends them to login or checkout.
Why the two piece split
A paid extension needs four things: sign in, checkout, subscription and billing management, and a way to check who has access. Whop provides all four through one API, so you never build or maintain an auth layer, a billing portal, or an entitlement database.
But an extension cannot hold secrets. Anything you ship in the extension bundle is readable by anyone who installs it. So the extension acts as the public client and the Next.js app acts as the trusted backend: the API key, the access checks, and the webhook verification all live server side. The extension asks the backend "does this user have access?" and renders locked or unlocked accordingly.
Both packages live in one pnpm workspace (apps/web plus extension), sharing one Node version and one install step. The extension builds with Vite; a Rollup override enforces a WebAssembly build so it bundles the same on every platform.
What the walkthrough covers
The Chrome flavored OAuth + PKCE flow. Signing in from an extension is its own problem: there is no normal browser redirect back to your app. The tutorial builds the PKCE flow in the extension context, from generating the verifier to landing the tokens safely.
Server side entitlement resolution. The backend asks Whop who has access and answers the extension with a clean yes or no. The extension never talks to Whop directly and never holds anything worth stealing.
Unlock on confirmation only. The popup renders the paid feature only after Whop confirms access. No client side flag that a curious user can flip in DevTools.
The checkout page. The web app hosts checkout; the extension links to it. A user without access lands on the checkout, pays, and comes back to an unlocked extension.
Webhook verification. Signed webhooks keep the backend informed about payments and subscription changes.
The options page, the manifest, and permissions. The pieces that make it a real extension rather than a demo.
Local testing with an unpacked extension. The full loop runs on your machine against the Whop sandbox before anything ships.
The sandbox to production switch. The last part swaps sandbox credentials for the production Whop app, the production web URL, and the published Chrome Web Store extension ID. Build the first version on the sandbox: OAuth, checkout, access checks, billing, and webhooks all behave like production without touching a live customer product.
The pattern generalizes
The shape of this build is the shape of any paid client that cannot hold secrets: a desktop app, a CLI tool, a mobile companion. The public client renders the product and asks the trusted backend for access. The backend asks Whop and answers. All of the sensitive surface (keys, entitlements, billing state) stays on the server, and the client stays as dumb as possible.
Links
- Demo web app: whop-extension-webapp.vercel.app
- Code: github.com/whopio/whop-tutorials/paid-chrome-extension
- Full tutorial: step by step walkthrough on the Whop blog
- Whop developer docs: dev.whop.com
If you have a Chrome extension idea you have been sitting on because the payments side felt like a second project, this is the pattern that collapses it.
Top comments (0)