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.
Related
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 am testing my in-app purchases, I uploaded my app to the windows store as beta and made an in-app product.
I tried it out and noticed a bug, I want to reset the in app purchase(it is hide ads) but I am not sure how to do this.
I want it so it is like the user account that bought the in-app never actually bought it.
I am going to assume that you are talking about a durable in app purchase, since consumable purchases can be bought as many times as one wants.
Once a durable purchase is made, it is permanent to the account. A user could call customer service to have this reversed, but it is not common (I have done this).
However it is unlikely that a rep would reverse a free in app purchase for a beta app to assist in testing.
If you would like to test your app without having to deal with those issues, Microsoft has provided guidance in how to test in app purchases.
So far as i know, if someone bought something through store, he cannot actually get the money back. If you're releasing app, you should pre-test it to be 100% sure it's working. If you're not sure how is the in-app purchase working, there is a plenty of forum threads about how to do this efficiently. Long story short, if someone already bought this in-app feature, either you cannot block it to him or refund his money.
I'd recommend testing In App Purchases through the emulator. Every time you restart the emulator it's like booting up a fresh device, so you'll be able to purchase IAPs again.
I am developing an windows phone 8 application and want to maintain two versions of my app - free and paid. So that my app appear in both free and paid app sections.
Since these two applications will have different Product IDs, is it possible to buy paid app from inside the free app.
I know that if we use Trial API of WindowsPhone, we can purchase paid version from app itself and can unlock the features using IsTrial of LicenseInformation. But in this case your app doesn't appear in free section.
I want to allow user to buy paid app from free version say by clicking BUYNOW button in app and get the free version replaced by paid one automatically.
This is the exact scenario that Microsoft wants to avoid. They don't want to see duplicate apps in the market because it destroys the consistent user experience. Instead, you need to either use the Trial Library or release it for free and put an in app purchase to remove ads or add functionality.
Your only option is to maintain 2 apps one that limits functionality using IsTrial and the other with an in app purchase.
Some people have suggested this isn't allowed, but I've yet to find anything in the requirements documentation that says you can't do this. There's also quite a lot of examples of apps already in the store doing this.
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.
I have to architect a commercial vehicle fleet tracking system.
Each vehicle (a few 100, max a few 1,000) will have a GPS and satellite transmitter and will periodically report its position. Positions will be stored in a database and used to create a Google Map.
There will of course be other functionalities. Security, log in, etc and probably lots of interaction with other corporate databses (drivers start/stop time for salary purposes, etc).
Question: pure GoogleMaps is probably best implemented as a browser based app (Php & MySql?), but with the additional functionality of a commercial vehicle fleet tracking system, would it be better doing something PC based (Windows/Linux)?
Any other advice? Thanks
I think with the capabilities of modern browsers, along with various mature client-side frameworks, we are witnessing an always thinning distinction between web and desktop interfaces.
You may want to take into consideration that a web application automatically solves some important problems for you:
Distribution: No need to distribute your application. Simply provide a URL.
Updates: Upgrading and fixing problems in your software will be easier and quicker if you distribute it through a web interface.
Security: Deriving from the above, you are able to fix security vulnerabilities more promptly.
Compatibility: Your application will be able to work on any operating system that can launch a web browser.
Last but not least, remember that the Google Maps API is not free for this type of application. Article 10.9.C of Google Maps API Terms and Conditions explicitly restrict using the standard Google Maps API for fleet management and asset tracking. You would need the Google Maps API Premier to legally use Google Maps for your application.
According to one unofficial source (dated April 2008), this would cost USD 10,000 per year, which entitles you to track 100 vehicles. If you exceed the 100 vehicles, you would need to add USD 24 per additional vehicle per year.
Implement solution for the domain problems first. It means data storage, data transmission between vehicles and your system, methods of data analysis, aggregation and visualisation.
These will likely to sit as a head-less system on a server and provide access to it remotely, in both directions: to input data and to query data.
Now, PC or Web is more related to presentation on a client side. You can make both if you like. Web client as well as desktop application can serve as a client to remote data and operational server.
Don't forget that you can always host a web control in a thick client app. This is actually trivial with .Net on the Windows platform with the IE control. You can also access the browser's DOM this way and do some neat things. So just because there's a strong web component to what you're doing you're not necessarily "stuck" writing a pure web app.
One big question is what kind of hardware you'll be able to put in the vehicles. Will they be laptops or small PCs with full fledged OSs or something more mobile like CE or a pared-down Linux distro?
Google Maps is JavaScript based so you can do most things with it, e.g browser based, widgets, etc. However due to the licensing Google won't allow you to use it in anything other than an Internet environment unless you use there Enterprise License.
In terms of integrating it into other systems, its really difficult to say what's best without knowing what other software you are using, what protocols they use, are web services available, etc. I agree with Daniel though in that any distributed system not implemented in a browser better have some good reasons not to, simply because the benefits are substantial. You'll need to weight them up though with a full break down of all the different systems you will need to interact with and work out what fits best.
The great thing is that with it being JavaScript based you have a lot of flexibility in what you can do with it.
This is more an extension to #Daniel Vassallo's answer. Although a web based application would solve most problems there may be the small potential issue of bandwidth usage and reception for internet access. This may or may not be an issue for the fleet management, depending on how that is tackled on the hardware side of things.
An offline solution may assist with this issue but then a clever architect could find a way to create an initial web based solution which can be accessed with an offline application which can pick up the slack and/or provide predictive reasoning until a connection is re-established.