Is it possible to purchase an in-app product outside the app? The scenario is that we would like to offer two in-app products:
Premium
Premium Free
Both of the products provide the same features, but the "Premium Free" is limited to few selected users. We don't want that the other users are able to purchase the "Premium Free" product.
If the app doesn't provide the purchase link to the "Premium Free" product, is it possible for the users to somehow purchase that product?
Update:
The idea is to provide both the "Premium" and "Premium Free" through the app. But "Premium Free" is limited to users who provide a correct code. So:
App shows page "Get premium pack"
The page includes a coupon code field
If user provides coupon code, she is directed to "Premium Free" product (app's in-app product on the Windows Phone Store).
If no coupon code is provided, user is taken to "Premium" product (app's in-app product on the Windows Phone Store).
The fear is that users find a way to acquire "Premium Free" pack without the coupon code. From outside the app. For example, if the product has a direct link (URL, I don't know if in-app product's have them) on Store and the user opens the link with phone, she can get the product "outside" the app.
The steps described above should be OK if the only way to access an in-app product is through the app.
It's not possible to do what you've described (make an IAP outside an app) but you could do something very similar.
Rather than trying to offer something to certain users outside the app, you could, instead, have something within the app that is only available to certain users.
There is nothing in the marketplace certification guidelines that stop you from implementing this. Obviously how this is implemented will be dependent upon your app. If the app in question allows (or requires) users to log in then a setting could be added to the account details to control which IAP options are made available. If the app in question doesn't support or have user accounts you'll need to indicate the special options are available to them. One such option may be to allow entry of an unlock code somewhere in the app which could allow access to the special IAP options. Of course if the aim is to offer free items via IAP you could just make them available in the app when the unlock code is entered.
Update No, products defined for IAP cannot be purchased outside your app. Originally I thought the question was hoe to do it.
Related
I have a chrome extension that im looking to monetize with subscription and free trial.
I have followed all the guide detailed here: https://developer.chrome.com/webstore/one_time_payments
Everything works, its all good, just now I need to know how to actually trigger the payment flow when a user decides they want to pay for my extension.
I can see that there is a "buy.js" for in-app purchases but im not sure how you are supposed to do it for one-time payments.
The only way I can see of doing it is by opening a new tab to my chrome store page and then somehow educating the user that they need to press the orange button...
Theres got to be a better way of doing it than that tho, surely??
If you want your extension to be paid using Chrome Web Store Payments, you have to follow Chrome Web Store Payments rules, which include fixed price tiers and the fact that payment must be initiated by Chrome Web Store. The in-app purchases work differently.
So yes, your users will have to subscribe using the orange button in your extension's Chrome Web Store entry. Usually they need not to be "educated" to do that: after all, that is the page they installed your extension from, and the orange button was already there.
Depending on which kind of free trial experience you offer, you can display relevant reminders to your users.
For example, if your free trial limits some functionality of the extension, you can prompt the users to subscribe when they try to use one of the premium functions, and/or display a Subscribe button in a visible part of your extension that links to your Chrome Web Store entry.
If your free trial is time-limited, you can display a counter of how many free-trial days your users have remaining, and the Subscribe button mentioned above. When the trial period is over you can automatically alert the users and open the Chrome Web Store entry of your extension. This latter approach (time limited free trial period) is the one I am currently using in my extensions and so far I've had no problems with the users or confusion on their part.
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.
I am creating an app with a Pro-feature which can be unlocked via in-app purchasing.
Is it possible to use the Windows Phone 8.1 Wallet API for creating a Voucher?
(As example for Reviewers or tester)
How can I ensure that the voucher can be used only by one person?
(maybe: can only be used for a particular LiveID)
Some recent changes here it seems. Microsoft now have a promo code system for Windows Phone, check this page : https://msdn.microsoft.com/library/windows/apps/mt297660.aspx
And it works for IAPs as well !
There isn't currently any voucher or promo-code system available for Windows Phone apps.
You could implement this yourself along with using the existing in-app purchase system. Check the code yourself and then enable the feature if either the code is present or if the in-app purchase was made.
Tying it to a login such as the LiveID would be a good way to lock it down to one person, especially if your app already has a login requirement. Another option would be to make the code one-use and then roam the unlocked status once it was set. That would let the first user to use the code use it on multiple devices so long as the app wasn't fully uninstalled or was used often enough to keep the roamed data alive.
Prepaid codes are frequent request on the Windows Platform Dev Feedback site. You can add your vote at http://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/2118985-prepaid-codes-for-wp-apps-promo-codes-for-review
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.
If a user makes an in-app purchase (durable product) on an app and then changes her phone, is the purchase still available for her when she launches the same app on her new phone?
In other words, are the products licensed by phone or by user's Microsoft Account? If by the account, does the CurrentApp.LicenseInformation.ProductLicenses automatically contain the product on her new phone or does she have to go through the purchase screen (RequestProductPurchaseAsync) to reactivate the product?
As #kookiz said purchase is tied to the user level than device. End user experience is varies on new phone based on your implementation/license querying to unlock the items.
I saw few apps, where the license check is not happened until the purchase experience window is triggered. Probably, developer is not checking the durable IAP license every time - probably saving the IAP purchase state in IsoStore etc.