Taking a payment for a Chrome extension looks simple at first.
A user clicks Upgrade, you open a checkout, the payment succeeds, and you mark the user as paid.
That version can work for a while.
Then someone reinstalls the extension. A subscription renewal fails. A customer asks for a refund. You add an annual plan. A team wants five seats. An AI feature needs a monthly usage limit.
Now you are no longer adding a checkout. You are building a billing and access system.
Chrome will distribute the extension, but it will not process the payment, keep the customer’s paid status, or restore access for you. Google stopped processing Chrome Web Store payments in 2021, and its current developer agreement places payment processing and paid-download records outside Google’s responsibilities.
This guide compares Stripe, ExtensionPay, Kelviq, Gumroad, Lemon Squeezy, and Paddle. More importantly, it looks at what you still need to build after choosing each one.
Pricing and product details last checked on July 5, 2026.
Payment and access are separate problems
Imagine you sell a Pro plan for $15 per month.
The plan unlocks:
- Unlimited saves
- Cloud sync
- Five AI summaries per day
- Export to PDF
The payment platform can tell you that the customer paid $15.
Your extension still needs to answer four different questions:
- Is the subscription active?
- Which features does the plan include?
- How much usage remains?
- What happens when the subscription ends?
The first version often looks something like this:
if (user.plan === "pro") {
enablePremiumFeatures();
}
This feels reasonable. There is one paid plan, and every paid customer receives the same access.
Then you add a Team plan. Existing Pro users keep an older limit. One customer gets a custom contract. Another purchases lifetime access before you move to subscriptions.
The condition starts growing:
if (
user.plan === "pro" ||
user.plan === "team" ||
user.hasLifetimeAccess ||
user.hasCustomContract
) {
enablePremiumFeatures();
}
This is usually where the clean first version becomes less clean.
A better model is to treat features and limits as data.
const canExport = await hasAccess(customerId, "pdf-export");
const summariesLeft = await getUsageRemaining(
customerId,
"ai-summaries"
);
The extension asks what the customer can do instead of trying to reconstruct that answer from a plan name.
This distinction matters when comparing payment platforms. Some collect the payment. Some handle tax. Some issue license keys. A smaller number also help connect the purchase to what happens inside the extension.
The first decision is who sells the product
Before comparing transaction fees, decide who should be the legal seller.
There are two common models.
A payment processor moves the money
A payment processor helps your business collect the payment.
Your company remains the seller. That generally leaves you responsible for areas such as:
- Sales tax, VAT, and GST registrations
- Tax collection and filing
- Customer invoices
- Refund policies
- Disputes
- Subscription records
- Product access
Stripe Payments is the clearest example here.
This model gives you control. It also gives you more things to own.
A Merchant of Record becomes the seller
A Merchant of Record, or MoR, becomes the legal seller for the transaction.
The MoR collects the payment, issues the customer invoice, calculates and remits applicable indirect taxes, and handles areas such as refunds and disputes.
Kelviq, Gumroad, Lemon Squeezy, and Paddle operate as Merchants of Record.
Stripe now offers both models. Stripe Payments is its normal payment-processing product. Stripe Managed Payments is a separate Merchant of Record service that adds indirect-tax compliance, invoicing, fraud management, dispute handling, and customer support for supported transactions. Its MoR fee is charged in addition to normal Stripe payment-processing fees.
This choice changes the comparison more than a small difference in the headline fee.
Chrome extension payment platforms compared
| Platform | Model | Published starting fee | Global tax | Extension access |
|---|---|---|---|---|
| Stripe Payments | Payment processor | Starts at 2.9% + 30¢ for US cards | Separate products available | Build it yourself |
| Stripe Managed Payments | Merchant of Record | 3.5% plus Stripe payment fees | Included for supported transactions | Build it yourself |
| ExtensionPay | Extension service connected to Stripe | 5% plus Stripe fees | Seller remains responsible | Paid-status checks and login |
| Kelviq | Merchant of Record | 3.5% + 40¢ | Included | Licenses, entitlements, credits, and usage |
| Gumroad | Merchant of Record | 10% + 50¢ for direct sales | Included | Purchase and license workflows |
| Lemon Squeezy | Merchant of Record | 5% + 50¢ | Included | License keys and customer portal |
| Paddle | Merchant of Record | 5% + 50¢ | Included | Subscription and customer tools |
For readability, this guide uses 3.5% + 40¢ as Kelviq’s comparison rate. Kelviq’s live pricing page includes possible additions based on transaction type. Other providers also apply additional charges in some cases. Always check the current pricing page before making a final cost calculation.
The table gives us the headline.
The more useful question is what remains after the integration.
Stripe gives you control, and the work that comes with it
Stripe Payments is often the first option developers consider.
It supports hosted checkout, subscriptions, payment links, invoices, discounts, refunds, webhooks, and many payment methods. Standard US card pricing currently starts at 2.9% + 30¢, although the rate changes by seller country, payment method, and transaction type.
Suppose your extension already belongs to a larger SaaS application.
You already have:
- User accounts
- A customer database
- Subscription logic
- A backend
- Tax and finance operations
In that case, Stripe may fit naturally. The extension can use the same account and billing system as the web product.
The work becomes larger when the extension is the product.
After a successful Stripe checkout, you still need to decide:
- How the buyer signs in
- How the extension restores a purchase
- What each plan unlocks
- How trials affect access
- How failed payments affect access
- How device limits work
- How usage is counted
- How taxes are registered and filed
Stripe provides products for some of this. Stripe Billing can manage recurring charges, and Stripe Tax can calculate tax. These are separate products with their own pricing and implementation requirements.
This is not necessarily a problem. Some teams want to own the entire system.
But the comparison should not be “2.9% versus 5%.” It should be the payment fee plus everything you still need to build and operate.
Stripe Managed Payments changes the tax side, not the access side
Stripe Managed Payments lets supported businesses use Stripe as the Merchant of Record.
Stripe handles indirect-tax compliance, invoicing, fraud prevention, disputes, and transaction-level customer support. The public MoR fee is currently 3.5% on top of normal Stripe payment-processing fees.
This can make sense if you already use Stripe and want to add Merchant of Record coverage without replacing the rest of your billing system.
It still does not know that your Pro plan should unlock PDF exports, allow three devices, and include 500 AI credits.
That part remains in your application.
ExtensionPay fills the extension-specific gap
A normal Stripe integration does not give a Chrome extension a user login or paid-status check.
ExtensionPay was built to fill that gap.
It connects to your Stripe account and gives the extension a way to check whether someone has paid. It supports subscriptions, one-time payments, free trials, multiple plans, and login across devices and browsers. Its published price is 5% per transaction, with Stripe processing fees charged separately. Funds go directly to the developer’s connected Stripe account.
The integration is attractive because the first version becomes much smaller.
Instead of creating your own authentication and payment lookup system, the extension can ask ExtensionPay whether the current user has paid.
That works well when access is mostly binary:
if (user.paid) {
unlockPro();
}
The limitations appear when the product needs more than paid or unpaid.
For example:
- Pro includes 100 exports
- Team includes 1,000 exports
- One customer has a custom limit
- AI actions use credits
- Some features are sold as add-ons
- A lifetime buyer should not receive a newer paid add-on
You can build those rules around ExtensionPay, but they are no longer part of the simple paid-status check.
ExtensionPay is also not the Merchant of Record. Because the payment runs through your Stripe account, the seller remains responsible for the tax and compliance side.
So ExtensionPay removes much of the extension-specific payment work. It does not remove every part of running a global software business.
Kelviq treats the purchase and the access as one system
Kelviq is a Merchant of Record for software and digital products.
It handles the checkout, global payments, indirect tax, invoices, refunds, and disputes. It also lets the developer connect the purchase to license keys, features, limits, credits, and usage.
That distinction is useful for Chrome extensions because most of the product lives after checkout.
Imagine you have three plans:
| Plan | Price | Access |
|---|---|---|
| Free | $0 | 10 saves per month |
| Pro | $15/month | Unlimited saves, cloud sync, PDF export |
| Team | $49/month | Pro features, five seats, shared workspace |
A payment-only system records that the customer purchased Pro.
An entitlement system also records what Pro means.
Pro
├── unlimited_saves: true
├── cloud_sync: true
├── pdf_export: true
└── team_seats: 1
The extension does not need to know that PDF export belongs to a plan called pro.
It only needs to ask:
const access = await hasAccess(customerId, "pdf-export");
This becomes more useful when pricing changes.
You can introduce pro_v2, keep existing users on pro_v1, or give one customer a custom limit without adding another plan-name condition inside the extension.
Kelviq models entitlements as boolean access, metered limits, or configuration values. Plans can also contain subscriptions, one-time pricing, licenses, and product assets.
A one-time purchase can stay simple
Not every Chrome extension needs subscriptions or usage billing.
Suppose you sell a tab-management extension for a one-time payment.
The flow can be:
- The customer installs the extension.
- They click Buy lifetime access.
- Kelviq opens the checkout.
- The payment succeeds.
- A license key is generated.
- The customer activates the license.
- The extension unlocks the paid features.
Kelviq supports one-time plans that can grant permanent access to an attached license key or digital product.
The extension still has a clear way to validate access, while Kelviq acts as the Merchant of Record for the sale.
Subscriptions use the same access model
Now imagine the extension adds monthly and annual plans.
The features do not need to move into a second system.
The subscription decides which plan is active. The plan grants the entitlements. The extension checks those entitlements.
A renewal, cancellation, refund, upgrade, or downgrade changes the customer’s access without requiring separate plan logic throughout the extension.
This is the main benefit of keeping billing and access close together. You do not have to reconstruct product state from payment events in several different systems.
AI credits fit into the same relationship
AI extensions introduce another problem.
The customer may be paid, but that does not mean every action should run.
A Pro customer might receive:
- 100 summaries per month
- 20 image generations
- 5,000 extracted records
Before the extension starts an expensive request, it can check whether the customer has access and whether enough usage remains.
const result = await checkAccess(customerId, "ai-summary");
if (!result.allowed) {
showUpgradeOrTopUp();
return;
}
await generateSummary();
await reportUsage(customerId, "ai-summary", 1);
Kelviq supports flat fees, subscriptions, credits, seats, usage limits, overages, pay-as-you-go billing, and combinations of these models.
You may begin with a lifetime license. Later, you can add a subscription, a credit pack, or a team plan without replacing the entire payment system.
That flexibility matters because most developers do not know the final pricing model when they ship the first version.
Gumroad makes the checkout easy
Gumroad has a different starting point.
It is designed to help someone create a product page, set a price, and begin selling quickly.
Gumroad’s current direct-sale price is 10% + 50¢. Sales discovered through the Gumroad marketplace are charged at a different, higher rate. Gumroad acts as Merchant of Record and handles indirect-tax collection and remittance for the sales it processes.
For a simple extension, that can be enough.
You could:
- Create a Gumroad product.
- Send the customer to its checkout.
- Email a license key after purchase.
- Validate the license through your own backend.
This works particularly well when the extension has one product and one access level.
The gap is not the checkout. It is what happens after it.
As plans, features, devices, teams, and usage limits are added, you need a separate model for those rules. Gumroad can confirm that a purchase happened, but the extension still needs a reliable way to turn that purchase into current access.
The higher fee may be a fair trade when speed matters more than customization.
It becomes harder to ignore once the extension has recurring revenue and brings most customers through its own website or Chrome listing.
Lemon Squeezy is closer to a software billing system
Lemon Squeezy is also a Merchant of Record, but its product is more directly designed around selling software.
It supports one-time products, subscriptions, license keys, a hosted customer portal, and usage-based billing. Its published base fee is 5% + 50¢. Additional fees can apply for subscription payments, international transactions, PayPal, and other cases.
For a traditional paid extension, the license-key support is useful.
A customer buys a product, receives a license, and activates it inside the extension. Lemon Squeezy can also tie licenses to subscription products, so the license follows the subscription lifecycle.
The developer still needs to decide what the license unlocks.
If the product has one Pro version, this is easy.
If the product has many features and customer-specific limits, you may still need a separate entitlement model around the license.
Lemon Squeezy also supports usage-based subscriptions, including volume and graduated pricing.
This makes it a broader fit than a simple storefront, although the connection between billed usage and real-time feature access remains something the application needs to design.
Paddle starts from SaaS billing
Paddle is a Merchant of Record built around software and SaaS businesses.
Its public pay-as-you-go price is 5% + 50¢ per checkout transaction. Paddle asks sellers with products under $10 or businesses that require invoicing to contact the company for custom pricing.
Paddle includes:
- Subscription billing
- Trials
- Plan changes
- Tax handling
- Fraud protection
- Chargeback management
- Payment recovery
- Customer self-service
This makes it a natural option when the Chrome extension is one surface of a larger SaaS product.
For example, the customer may purchase through the web app, manage the subscription in a customer portal, and then use the same account inside Chrome.
As with the other payment and billing platforms, the application still needs to map Paddle’s products and subscription state to the exact features available inside the extension.
For a larger SaaS product, that mapping may already exist.
For a standalone extension, it is another system you need to build.
Low-priced extensions make fixed fees visible
Many Chrome extensions charge between $5 and $20.
At those prices, the fixed part of the transaction fee can have a noticeable effect.
Consider three common fee structures:
| Product price | 3.5% + 40¢ | Effective rate | 5% + 50¢ | Effective rate | 10% + 50¢ | Effective rate |
|---|---|---|---|---|---|---|
| $5 | $0.58 | 11.5% | $0.75 | 15% | $1.00 | 20% |
| $20 | $1.10 | 5.5% | $1.50 | 7.5% | $2.50 | 12.5% |
| $100 | $3.90 | 3.9% | $5.50 | 5.5% | $10.50 | 10.5% |
The fixed fee matters more on smaller payments.
On a $5 purchase, Kelviq’s 3.5% + 40¢ fee comes to about 11.5% of the transaction. On a $100 purchase, the effective rate falls to 3.9%.
This can influence how you price the extension. A yearly plan may cost less to process than twelve small monthly payments. Credit bundles may also work better than charging for each small action separately.
These examples use the published base fees only. They do not include possible charges for:
- International cards
- Subscription payments
- Currency conversion
- PayPal
- Payouts
- Taxes
- Custom pricing agreements
The final cost depends on the customer’s location, payment method, currency, and billing model.
Your pricing model should follow your costs
Most Chrome extensions begin with a pricing model that is easy to explain.
That does not always mean it is the right model once the product grows.
One-time pricing works when the ongoing cost is low
A one-time purchase fits products such as:
- Screenshot utilities
- Tab managers
- Formatting tools
- Offline productivity extensions
- Local browser tools
The customer pays once and receives lasting access.
This is easy to understand. It also means future updates and support are funded by an old payment.
That may be fine when the extension has little server cost.
It becomes harder when every active customer continues creating cloud or API costs.
Subscriptions fit ongoing value
A subscription is easier to justify when the extension provides:
- Fresh data
- Cloud storage
- Synchronization
- Team features
- Continuous updates
- API access
- Customer support
Monthly billing lowers the initial commitment.
Annual billing brings money forward and reduces the number of payment events.
Neither is automatically better. It depends on how customers discover, evaluate, and continue using the extension.
Credits fit actions with a cost
Credits work well when individual actions consume resources.
For example:
- Generate an image
- Enrich a lead
- Transcribe a recording
- Summarize a document
- Scrape a page
- Export a data set
A subscription could include 100 credits. Customers who need more can buy a top-up.
This prevents a small number of heavy users from consuming an unlimited amount of an expensive service.
Subscription plus usage is often the practical middle
A common model for AI and API-backed extensions is:
- A monthly base price
- Included monthly usage
- A limit or overage after the included amount
- Optional top-ups
For example:
| Plan | Monthly price | Included usage |
|---|---|---|
| Starter | $9 | 50 actions |
| Pro | $19 | 250 actions |
| Team | $49 | 1,000 actions and five seats |
The subscription pays for ongoing product value.
The usage limit protects the developer from open-ended costs.
The important part is not only charging for usage. It is checking the limit before the costly action runs.
Paid access should not live only inside the extension
Chrome extension code runs on the customer’s device.
Users can inspect it. They can change local storage. They can copy values between browser profiles.
This makes local state useful for caching, but a weak final source of truth.
A value such as this should not control paid access on its own:
chrome.storage.local.set({
isPro: true
});
A safer design is:
- The customer signs in or activates a license.
- The extension sends an authenticated request to a trusted backend.
- The backend checks the current subscription, license, or entitlement.
- It returns only the access information needed by the extension.
- The extension caches that response for a limited period.
For AI and API-backed features, the expensive request should usually pass through your backend as well.
Otherwise, private service keys may end up inside extension code, where users can extract and misuse them.
The extension can display the interface. Your backend should make the final decision about paid access and costly actions.
Reinstalling the extension should not erase the purchase
The easiest access system is tied to the current browser installation.
The customer pays, you save a local value, and the extension unlocks.
Then the customer buys a new computer.
Or Chrome clears the extension data.
Or they want to use both Chrome and Edge.
Paid access should belong to an identity, not an installation.
That identity could be:
- An email account
- A workspace account
- A license key
- A customer ID
- A secure login token
After reinstalling, the customer should be able to recover:
- Their active plan
- Their paid features
- Their remaining usage
- Their license
- Their invoices
- Their billing controls
You should also decide what multiple-device access means.
A lifetime utility may allow three activated devices.
A personal subscription may allow one active account across any device.
A team plan may assign access to workspace members instead of machines.
These rules are part of billing, even though no money moves when the customer signs in on a second laptop.
Moving payment platforms is really an access migration
Changing the Upgrade button takes a few minutes.
Changing the system that decides who should have access can take much longer.
Before moving providers, record:
- Existing products
- Current prices
- Monthly and annual plans
- Lifetime customers
- Active trials
- Coupons
- License keys
- Feature rules
- Device limits
- Custom agreements
- Cancelled subscriptions with remaining access
Then create the equivalent state in the new platform.
During the transition, your extension may need to accept access from both systems:
const allowed =
await hasActiveLegacyLicense(customerId) ||
await hasNewEntitlement(customerId, "pro-access");
This is not elegant, but it keeps existing customers working while new customers use the new checkout.
Move new purchases first.
Then test the full lifecycle:
- Purchase
- Renewal
- Failed payment
- Cancellation
- Refund
- Upgrade
- Downgrade
- Reinstallation
- Device activation
- Expired access
- Credit top-up
A successful first checkout proves only that the checkout works.
The first failed renewal often tells you more about the quality of the integration.
Which platform should you choose?
The answer depends on what you already have.
Use Stripe Payments when you want to own the system
Stripe is a reasonable choice when:
- You already use it for a larger SaaS product.
- You have a backend and customer accounts.
- You want complete control over billing.
- You can handle tax and access separately.
- You expect unusual payment workflows.
Use ExtensionPay when the missing piece is extension access
ExtensionPay fits when:
- You want to use your own Stripe account.
- You need a quick paid-status check.
- Your access model is relatively simple.
- You are comfortable remaining responsible for taxes.
Use Kelviq when the sale should control the product
Kelviq fits when:
- You want a Merchant of Record.
- You sell one-time access or subscriptions.
- You need license keys.
- Plans unlock different features.
- You need customer-specific limits.
- You use credits or top-ups.
- You charge based on usage.
- You want payment and access in the same system.
This does not require an AI extension.
A lifetime utility can use a license. A subscription extension can use entitlements. An AI extension can add usage and credits.
Use Gumroad when speed matters most
Gumroad fits when:
- You want a storefront quickly.
- You have one or two products.
- You mainly sell lifetime access.
- You already use Gumroad for other digital products.
- The higher fee is acceptable.
Use Lemon Squeezy when software licenses are central
Lemon Squeezy fits when:
- You want a Merchant of Record.
- License keys match your access model.
- You sell standard software subscriptions.
- You want a hosted customer portal.
- You need basic usage-based billing.
Use Paddle when the extension is part of a SaaS business
Paddle fits when:
- You have an established SaaS product.
- You need mature subscription operations.
- You want Merchant of Record coverage.
- Payment recovery and customer self-service matter.
- The extension uses an existing application account.
Frequently asked questions
Can you charge users for a Chrome extension?
Yes.
You can sell one-time access, subscriptions, lifetime licenses, team plans, credits, and usage-based plans through an external checkout.
The Chrome Web Store does not process those payments for you.
Can a Chrome extension open an external checkout?
Yes.
A common flow is to open a hosted checkout or account page when the user clicks an Upgrade button inside the extension.
The extension should clearly explain which features require payment.
Does Google take a commission on the external payment?
Google does not process the external transaction through the old Chrome Web Store payment system.
The payment provider you choose charges its own processing or platform fees.
Do I need a backend?
You need a trusted place to verify access.
That could be your own backend or a platform that provides license and entitlement checks.
For a very simple license product, you may need only a small validation service. For subscriptions, teams, and usage limits, a proper backend becomes more useful.
Can I use Stripe for a Chrome extension?
Yes.
You can use Stripe Checkout, Payment Links, Billing, and webhooks, then build the account and access system yourself.
You can also connect Stripe through ExtensionPay or use Stripe Managed Payments where supported.
Is Kelviq a Merchant of Record?
Yes.
Kelviq combines Merchant of Record services with subscriptions, usage billing, licenses, and entitlements.
Can Kelviq handle one-time extension sales?
Yes.
Kelviq supports one-time plans and can attach permanent license-key or digital-product access to the purchase.
Can Kelviq handle subscriptions?
Yes.
Plans can use recurring monthly or annual pricing and include feature access, limits, licenses, or product assets.
Can Kelviq handle AI credits and usage?
Yes.
Kelviq supports credits, metered usage, limits, overages, pay-as-you-go charges, and hybrid pricing models.
Should I use license keys or accounts?
License keys are often enough for simple one-time products.
Accounts are usually easier for subscriptions, team access, multiple devices, and usage balances.
Some extensions use both. The customer signs in, while the license or subscription remains attached to the account.
Can the same paid account work on Chrome, Edge, and Firefox?
Yes, if your access is tied to the customer rather than one browser installation.
The exact extension code may need browser-specific changes, but the billing and account system can remain shared.
The payment is the easy event
A customer paid.
That fact is simple.
The harder questions come afterward:
- What did they buy?
- What can they use?
- How much can they use?
- What happens when the plan changes?
- What happens when the payment fails?
- How do they recover access next year?
You can build each answer separately.
That may be the right choice when you already have the systems and want complete control.
But if the extension is the product, it is worth choosing a payment platform based on what happens after checkout, not only what it costs to collect the payment.
Kelviq gives Chrome extension developers one place to manage the sale, global tax, subscriptions, licenses, usage, and product access.

