This is slightly unbeknownst to me. In WP8 store, if purchasing consumables, the client has to report fulfillment. Is this when the customer gets billed or do they get billed directly on purchase? i.e. Can the consumables be used like durables if fulfillment is not reported.
The customer gets billed when they purchase. You could choose to leave the IAP unfulfilled if you wanted to, but you'd need to report fulfillment before the customer could purchase that IAP a second time.
If you want to use the IAP as a durable though you should just use a durable. One thing to keep in mind is that if your app is uninstalled, then reinstalled (on same device or different device w/ same Microsoft account) you'll still be able to check for a list of purchased Durable IAPs using the ProductLicenses API. This list will not return info about the Consumable IAPs though, you're expected to fulfill those and track the consumable content through your own means.
Related
I have developed an Win-Phone8 application, Initially for 15 days I am giving my application for trail period and after 15 days the user have to subscribe the application (They can purchase) to use it uninterruptedly rest of the time , I was planning to use third party payment gateways like (Stripe,Paypal) but I think the Platform like Windows only allowing third party payment gateways for selling physical goods like (Books , Electronics items etc. ) But in our case we just going to sell an upgraded App which is a digital content.My Question is can we sell the App Upgrade features through Stripe payment gateway or any third party payment gateway??? IF not I found the platform Windows providing Service API's for In-App Purchase inside the App. So My Question is, Do i need only In-App purchase service for selling App in Windowsstore???
Yes. In-app purchase given by Microsoft is enough for selling apps in windows store. You don't need to worry about third party payment gateway etc.
refer to this link https://msdn.microsoft.com/en-in/library/windows/apps/jj206949(v=vs.105).aspx
examples given on this page are useful.
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 have developed an online ticketing application that uses a simple form integration - it's been running successfully for some years.
I have been asked to extend this so that it can be used for phone payments.
The reason for this is that the ticketing application has a great many options before the final price is arrived at so the people taking the call could use the same software (with minor modifications).
I can't see any options in the integrations for doing anything like this. It's all for customer payments.
Can anybody tell me if this is possible (and if so, how)?
Here's my understanding. It comes down to AccountType when you make your request to Sage Pay.
That accepts three different values:
E - use ecommerce account
M - use MOTO (mail order/telephone order) account
C - use continuous authority account.
Depending on your merchant bank and what you requested when you set up your merchant accounts, you'll have a merchant account for each. Sage Pay will send your request to the correct merchant account. This is key because if you use M, you'll not be expected to use 3D secure for the card - and the expectation is that it will be you processing the card, not the customer.
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.
If user of my App buys consumable product, how much time do I have to send fulfilling of this product? May I do it in, for example, 2 weeks?
According In-app purchase article in MSDN -
Fulfillment is the process of making sure that your customers get the goods they purchased in a timely manner. For an app, this typically means as soon as the purchase has been verified.
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206949(v=vs.105).aspx
see section Fulfilling purchases