How can I make a browser extension payments system? [closed]
Asked Answered
G

1

9

I've found today in my inbox an email from google where they announce that CWS payments API is deprecated

I'm working to create a Chrome extension that I want to release with the in-app payments support to let the user purchase a license to unlock full features. I was oriented to the CWS native payments API, but Google's decision to deprecate the API is a very bad news.

At the moment I've found a nice Wordpress plugin that will manage licensing, I'm thinking of using it to create a licenses backend but I'm not sure about it because it's mainly focused to be used for wordpress themes or plugins, so to implement it on client side for an extension would require some workarounds.

How do you will manage your in app purchases and licensing for Chrome extensions or Electron apps?

Goulette answered 22/9, 2020 at 10:11 Comment(9)
I'm in the same situation. I haven't looked into all of the different possibilities, but I'm thinking of setting up a simple user system manually on my PHP backend and collecting payments with Stripe. I'll stay tuned to this thread to see what others recommend.Lasso
I'm looking for Stripe as a possible alternative, but also paypal can be a nice choice. The problem will be with the client side code, but using SSR the licensing check will not be a big dealGoulette
I own 4 paid chrome extensions, and will also have to migrate (big thanks, Google). Heard about Paddle for collecting payments, perhaps you can also look into it. My biggest concern is the existing users and migrating their licenses.Sorrow
@Sorrow They have posted some guidelines about licenses migration in their api deprecation page. Just a technical question, how do you unlock features to your users after they paid for it? Any suggestion?Goulette
@Goulette none so far, sorry. I have no idea how to set up something like this, I was satisfied with using the chrome api system. Will have to study this.Sorrow
@Goulette Very basically, you would have to generate a unique identifier for every user, which can be stored in the client-side (in chrome.storage for example) and stored in the backend's database to identify the user. Then, on page load (and ideally, whenever a premium-action is taken), you could make a request to the backend to check if the user is premium or not. Obviously, there are a lot of security measures to take, but that's the gist of it. You'd probably need the user's email for billing, security and support purposes.Lasso
I'm thinking to use the Identity api to login users and get the email, I'm testing server side rendering with vue and php to serve the app from a remote server but this isn't the best way because probably it will make impossible to use chrome / browser extension native APIGoulette
I was planning on preparing the entire user account / subscription flow for my extension tonight, so if no one has added a good solution on here by then, I'll make an answer with that information tonight once I've gone over everything.Lasso
It will be very useful for all developers who need some help with this situation. At the moment I'm looking for a way to avoid using conditional rendering on the client side, this because I don't want to bundle all the features into the extensions and I want a secure way to provide the paid features to the users who have purchased it.Goulette
L
16

Alright, so as I am in the same situation as you are, I did a little bit of research. Here is a summary of my findings and comments on the matter.

There are three things to think about before you get started with the implementation:

  1. The type of payment processing service you want to use;
  2. The way you want to limit features for the free version (and for multiple tiers of plans);
  3. The security of your users information through your extension.

Let's go through each of these one at a time.


1. Type of payment processing

There are two main types of service providers that will allow you to collect payments in you extension. Payment processing platforms are the first type: they allow you to process payments and will generate receipts, but they won't manage the different taxes and regulations of different countries. If you operate solely in one country, or in a few countries where taxes and regulations are the same, this won't affect you.

However, if you have users around the world, especially in Europe, implementing the rules to handle all of the different taxes and regulations can get really complicated and messy. But you have to do it, otherwise you put yourself in a situation where you are at risk of getting fined. That is where the second type comes in: the merchants of record. These are companies that will charge the users on your behalf, removing all of the complexities of taxes and regulations from your plate. They're essentially acting as a reseller of your products. Of course, they take a small cut from your revenue to pay for the weight that they're taking off your shoulders and putting onto their own.

Payment processing platforms will be cheaper (ex.: 2.9% + 0.30$ per transaction for Stripe), while merchant of records take a bigger cut (ex.: 5% + 0.50$ for Paddle). However, if you deal internationally, the 2.1% higher price is likely more advantageous for you, just because it saves you a lot of time and development work.

It's important to note however that merchant of records are unlikely to take on a brand new project, especially for Chrome extensions. That's because the amount of revenue those extensions generate on average is pretty low, and often not really worth it for them. Still, I suggest you hit up a few of them before deciding do go the classic payment processing way, just in case you can get in touch with a salesperson who sees potential in your project and is willing to take you on.

Here are a few merchant of records:

  • Cleverbridge
  • 2Checkout (offers both MoR and basic payment processing services)
  • Paddle (does not support new Chrome extensions at the moment)
  • FastSpring (does not support Chrome extensions anymore, as of 2021)

Here are a few payment processing platforms:

  • Stripe
  • Paypal (from my experience, Paypal is a lot less developer friendly than Stripe)

2. Limiting features for free or tiered plans

The way features are limited for non-paying users will differ from one extension to the other.

If the features you want to limit in your extension already rely on a backend, to fetch or process data for example, it would make sense to implement the limitations on the server side. You would simply pass the user's ID, which could be stored in chrome.storage, to each request made to the backend. In addition to that, you could also disable the related elements on the client side, such as hiding or greying out buttons, tabs or fields, to make it clear to the user that those features are locked. You'll want to make sure the limitations are in place on the backend as well however, because otherwise a user could just inspect your extension and enable premium features without paying.

If your extension mostly or only operates on the client-side, then you will have to render the interface conditionally, based on the user's plan. The scripts or interfaces that will be added will most likely have to be returned by a backend, as pretty much anything that is done only on the client-side could potentially be inspected and exploited. In that case, any backend technologies or platforms you are most familiar with can probably be used to set things up.

Keep in mind that most of the payment processing and MoR listed above have APIs and guides on how to implement them securely in apps and websites. However, if you know Wordpress well and can set up a secure communication between your Wordpress and your extension, go ahead. If you want to use an online service like Zapier to link existing authentication and licensing services together, go ahead and do that!

There could be a lot more details in this section - there is a ton of material to cover, so I suggest you look for articles and tutorials online to help guide you in this process if you don't have much experience in the matter.


3. Security

This section won't be long, but it is very important one. No matter which payment processing platform you decide on or how you limit access to features in your extension, it is crucial that you make sure that your users information can never fall into the hands of another user. That includes reverse engineering and exploits of your system.

The more things you decide to handle yourself, the more risk there is, especially if you are not experienced. Keep that in mind when making your decision(s).


That's all for me. I hope that helps a bit!

I know it's probably a lot of information without any detailed "how-to", but without having in-depth knowledge of your product and situation, it is impossible to say what you should do exactly.

P.S.

If that can offer any guidance, here's what I will be doing for my own extension. Seeing as it's already very reliant on a PHP backend, I will add a few features to the backend in order to communicate with the Paddle API. So all of the limitations will be implemented on the backend, and I will add messages and visual indicators on the frontend to inform the free users of what they can and cannot do.

[Edit]
I just received a message from Paddle indicating that they do not support new Chrome extensions at the moment. Sorry for the misleading there.

[Edit: June 2021] After an update earlier this year, FastSpring has updated their security standards, which makes it unusable within Chrome extensions. After I enquired, their support agents informed me that they do not support Chrome extensions anymore (and that it was only "accidentally" supported before).

Linotype answered 23/9, 2020 at 1:23 Comment(2)
This was amazingly helpful. Thankyou. Do you know why so many don't support chrome extensions?Wilbur
@DaledeSilva I don't know for sure, but there are additional complexities in browser extensions that aren't present in regular websites and web applications. For example, you can't use webhooks to send data to the browser extension, as it isn't handled by a server. Plus, just about everything is client-side in browser extensions by default, so security can be a concern unless the developers really know what they are doing. These are a few good reasons to put off support of browser extensions for a while if you have limited development resources and little demand.Lasso

© 2022 - 2024 — McMap. All rights reserved.