Hope everyone is well.
I have read the Chrome Web Store Developer Agreement which I believe has provided clarity on the matter, but just wanted to check with others who may have been down the same route...
Am I correct in thinking if building a paid Chrome Extension that you don't have to accept payment via the Chrome Web Store payment processing?
I ask, not because I want to avoid their 5% fee, but rather, I was looking at using a 'Merchant of Record' such as Paddle, 2Checkout or Fastspring as these services not only act as a payment processor but also obviously act as a reseller and in doing so take on all liability in regards charging, collecting and remitting the necessary sales tax, VAT & GST, therefore making things much easier for me in that regard.
I would greatly appreciate if anybody had any experience with this and could confirm this is possible as I currently believe it is.
Many thanks in advance.
Related
I wanted to add Facebook and Google login to the customer login page or in sign up in Shopify so tell me how I can implement it?
I will assume by the type question you made that you are new to programing. I apologize if that is a wrong assumption.
Do you want to implement it? Does that mean you want to develop your own plugin from scratch? Then you have to learn how to make Shopify extensions first. You should probably start with "hello world" types of example and only then try to approach something complex like 0auth for customers.
If you want it just working here somebody's else implementation:
https://apps.shopify.com/oxi-social-login?surface_detail=store-design-customer-login&surface_inter_position=1&surface_intra_position=4&surface_type=category
As you notice, it's not trivial to do it and they can sell this feature at a price and have happy customers. Yet another hint that's it's not feasible to start learning programing on complex projects and skipping the first baby steps and the necessary learning steps.
I'm including a paid extension as my recommendation because you didn't specify anything in your question and therefore paid extensions might be valid solution for you.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
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?
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:
The type of payment processing service you want to use;
The way you want to limit features for the free version (and for multiple tiers of plans);
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).
I'm making a desktop app for a company, and they would like to get it featured in the windows app store for Windows 10 users.
The app will likely only work on desktop computers, it's not designed for mobile. What it does is perform lookups on lists of cell phone numbers, and outputs a spreadsheet with carrier info, and it requires a credit for each cell phone number looked up. The credits are bought in bulk through the company's sales team, there is no automated method to purchase them.
Because there is no automated system, it would be difficult to set up in-app purchases, also if Microsoft takes a cut of in-app payments then it wouldn't be feasible due to the tiny profit margin of the credits. But according to this (section 10.8.1), if the app consumes anything that has to be purchased then it needs to use the in-app purchasing api.
Does anyone know if there's some way around this? Or if it only applies to regular apps and not desktop only ones, which I understand are a different type of listing?
I realise I can get a developer account and go through this with them but I don't really want to spend this company's money on the dev account if Microsoft are just going to say no.
Thanks :)
That section of the policy refers to payments taken within the application.
It doesn't sound like what your application will do though. Your application is allowing the allocation (spending) of credits bought separately.
It's a small distinction but an important one. You may have seen other applications work around such limitations by requiring the user to go to a website to buy something and then return to the app to use it.
When submitting the app there is a declaration for "This app allows users to make purchases, but does not use the Windows Store commerce system." You can read more about this declaration at https://msdn.microsoft.com/en-us/library/windows/apps/mt148523.aspx but this shouldn't apply to your scenario.
There are potential legal implications here and if the company has any concerns about entering a legal agreement with Microsoft regarding financial matters then they should seek appropriate legal council. Having a developer ask other developers about legal matters is likely only suggest asking a lawyer.
First time post here, so forgive me for any bad etiquette/format.
I will preface by saying:
I have (over the last few months) been developing an iOS app for work. To be more specific, I am developing an inventory app to track bar inventory (liquor, beer, wine, etc). I can give more specifics on request if needed. I have most of the functionality done, only a couple more things I would like to implement. Eventually I will be porting it to Android as well.
At the moment, I have the model objects being archived to the local filesystem for saving and loading of data. However, my goal would be to database the model objects with the ability to display the information on a webpage. My logic is that no matter where the user is, he/she will be able to sign in to a service using a username and password, and view correctly formatted current/past inventories online. This is to allow the ability for a bartender to record the inventory, and have the bar manager view the inventory instances without having to have the physical device that recorded the inventory in his/her possession.
So here is my question:
Without being too general, what kind of service would I need to pull this off? I have a good amount of relevant front-end experience, specifically with iOS, Objective-C, HTML and CSS. However, I have ZERO experience on the back-end. I have researched around the internet, and I am aware of things such as cloud databases, web hosting and MySQL, etc. However, I cannot seem to find a definitive answer without asking my specific question. I suppose I would just like to be pointed in the right direction before investing money and time into a service that may prove useless to my cause.
Any resources and help would be greatly appreciated. Thank you!
There's not a definitive answer and you have a lot of options.
For me, the simplest is to set up a server with a database incorporated (mysql for example) and with a web service (written in PHP for example) that manages the database and queries on that.
Online you can find tons of guide on how to write a script in PHP that manages a database:
http://www.freewebmasterhelp.com/tutorials/phpmysql/2
For the iOS part you can follow also this guide:
http://www.techrepublic.com/blog/software-engineer/create-your-own-web-service-for-an-ios-app-part-one/
Good luck!
I’m developing an app for Google Chrome and I would like to know how I can charge for it.
The problem is that I live on Brazil and on this link it tells that it doesn’t support the Chrome Web Store Payments. There is other way I can charge for that without the Chrome web store payment?
https://developers.google.com/chrome/web-store/docs/pricing#seller
My initial idea is to create a hosted app that is free (but limited) and the customer pays and can use it fully. Or the other idea is to give 30 days to try and the costumer need to pay only onetime if he likes it and can use it fully.
Do you guys know how to do that living in a country not supported by Chrome Web Store Payments?
Did you notice the text on https://developers.google.com/chrome/web-store/docs/pricing#seller which says "In the future, we expect to support sales to the following additional regions: Argentina, Brazil, India, Mexico, and Poland. Buyers in unsupported regions might be able to purchase apps, but they can't pay in their local currency and might have to pay international transaction fees."? Not sure if that means it would work for you or not.
Otherwise I'm pretty sure you're allowed to use other payment processors other than Chrome Web Store Payments (see https://ssl.gstatic.com/chrome/webstore/intl/en/dev_tos_text.html and https://ssl.gstatic.com/chrome/webstore/intl/en/program_policies.html), so you might see if other services like PayPal, Amazon payments, etc. are a better option for you.