I want users to buy a product as many times as they want. e.g gold coins, bonus points etc. Is it possible to specify the the LicenseDuration="0" so that as soon as the user buys it the points are added to users account and the product is ready to be bought again. I'm doing it the following way, it works fine in the simulator mode:
<Product ProductId="sp75" LicenseDuration="0">
<MarketData xml:lang="en-us">
<Name>ServerPoints75</Name>
<Price>1.99</Price>
<CurrencySymbol>$</CurrencySymbol>
<CurrencyCode>USD</CurrencyCode>
</MarketData>
</Product>
Consumables are not supported by the built-in in-app purchase support at this time.
You may be able to accomplish what you want with a 3rd party commerce provider. May be worth doing a search on Bing for some of the major payment providers.
Hope that helps.
For more info on Windows Store app development, register for Generation App.
You are limited in the number of in-app purchases, so that's not even a viable workaround if you were considering it : )
Check out the PayPal API for consumables, subscriptions, etc. There's a specific Win8 wrapper on github for it:
http://paypal.github.com/Windows8SDK/
Related
I'm finding it difficult to get a concrete answer on this, either I'm finding the wrong info or not comprehending what I am finding.
Our app will be available on the Play Store and App Store, as well as being accessible via Web App. We planned on using our website for customers to sign up, subscribe, pay, etc. The app will be a free download on the mobile app stores, with the free features active, only requiring a subscription for the advanced features.
Would this scenario (using Stripe for subscriptions, without any use of Google IAB or Apple IAP) break any developer agreements as they stand?
You will be rejected from the app store if you do this. Guidelines:
3.1.1 In-App Purchase: If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game
currencies, game levels, access to premium content, or unlocking a
full version), you must use in-app purchase. Apps may not include
buttons, external links, or other calls to action that direct
customers to purchasing mechanisms other than IAP.
If you don't want to bother integrating IAP, you can just exclude the payment stuff on the mobile client and let people do it on the web. Then, you can use your own verification mechanism to give people that have subscribed the correct content once they log into your app.
Spotify does something similar as described on their website. As far as how much of that they reveal in the app itself, you'd have to download it and see as I am not sure offhand. Your app may be rejected if it directly instructs users to go subscribe on your site.
The relevant info for the Play store is here.
Developers offering products within another category of app downloaded
on Google Play must use Google Play In-app Billing as the method of
payment, except for the following cases: Payment is solely for
physical products.
Payment is for digital content that may be consumed
outside of the app itself (e.g. songs that can be played on other
music players).
According to this, you are not required to use In-app Billing on Android since your content will technically be available on iOS and web as well.
Case:
Our iOS app offers selling of custom made recipe packages that would be created for each user specifically. For example - user buys package of recipes, but for each user this package would be created individually, based on users preferences and needs, by someone from the app team. This package should be created in 5 days for example. If app team fails to create this package and deliver to end user in 5 days, automatic refund should be triggered and end user should receive money back that he spent on this in app purchase, thus invalidating purchased custom package.
Problem:
Is this kind of scenario even possible in Apple / iOS world? Can app developer trigger refund process of one specific purchase that end user made? If user isn't satisfied with specific purchase, could app developer trigger this is refund process if he has reference to transaction receipt?
P.S. We aren't really selling custom recipe packages, this was just an example scenario to help to understand this refund scenario case. ;)
EDIT:
If such scenario isn't possible via Apple refund, are there some examples of this kind of purchase model, implemented in some other way? It's hard to wrap my mind that only way for end user to get refund for something is to write Apple and that also needs to be done by user itself.
If you get paid using Apple services (in-app purchases) then NO, it isn't possible for an Apple Developer (business or individual) to refund App Store customers.
The only option is to direct customers to iTunes Store Customer Support as officially stated in the iTunes Connect screenshot below:
To increase the chances for your customers in getting refunded you could provide them with an e-mail stating that you would like them to receive a refund which they could show to the iTunes Support employee.
As a colleague stated, an option would be to use an external payment processor like PayPal which would allow you to manage refunds, but I think this will greatly increase the work needed since you will need to manage almost everything regarding payments on your own.
Also note that this option is highly restricted by Apple to only physical services or goods and sometimes Apple does not approve apps providing services through third-party payment processors. So.. you should be very careful what path you choose to take.
If the recipes you're providing to your customers are in digital format and users receive them in your app, you can be 100% sure that Apple will force you to use the in-app purchase system.
If such scenario isn't possible via Apple refund, are there some
examples of this kind of purchase model, implemented in some other
way?
In some cases you can use payment through PayPal (for example). We did it in our application where we had to take money of users and return it after a certain period. Check if you case is suitable for using third-party payment systems. Because (for example) Apple will restrict your app if you want to sell in-game content via Paypal, not with in-app purchase.
One very simple alternative would be to have your users buy virtual currency in your app that they can then spend on their recipe-package-orders. Since you are managing their virtual currency account balance, you can easily refund, give volume-discounts, etc. as you please. The only thing that will still be hard then is to have users return their virtual currency to get back their actual money.
There is no api for allowing users to refund a purchase (otherwise guess what can happen).
More info here
is this okay to implement payment system on ios apps? I would like to make an app that can browse products on my e-commerce website then let people buy products on my app. I'm asking this question because i've heard it is violating apple's policy.
It apparently depends on the what is being sold. The definitive answer can only be gotten from your lawyer's reading of the Apple agreement, of course, but I can speak from a little experience.
Apple themselves say that: if a product is sold in-app, it must use Apple's IAP (which gives Apple their 30% cut), and not be offered for less through other channels. However, there is an extensive list of things that are not eligible for purchase with IAP at all. Chief among these are: physical products; and services performed outside the application.
I have worked on two apps, both free, that are clients for fee-based web services (continuing education classes in one case, an employee scheduling service in the other). Neither used IAP, just linked to a purchasing web page. Both were accepted by Apple without comment. It seems that since the products were (arguably) not eligible for IAP, using an alternative purchase method was permitted. I'm sure it helps that Apple itself does not compete with either of these services.
Bear in mind Apple has also rejected apps that are just "wrappers" for web sites and offer no real app functionality; or for any of a long list of sillier reasons. (e.g.: I had one app rejected for using the word "Sample" in the name; but a change to "Free", with identical functionality, made it OK.) So consult a lawyer before taking any risk predicated on the developer agreement.
[edited to add:]
For dev program members, the relevant legalese is to be found here (login required), "iOS Developer Program License Agreement", attachment 2 (about 2/3 through the document.) A few relevant phrases from the Jun 12 2012 version, emphases mine:
You may not use the In-App Purchase API to offer goods or services to be used outside of Your Application.
You may not enable end-users to purchase Currency of any kind through the In-App Purchase API, including but not limited to any Currency for exchange, gifting, redemption,
transfer, trading or use in purchasing or obtaining anything within or outside of Your Application.
Rentals of content, services or functionality through the In-App Purchase API are not allowed
You may not use the In-App Purchase API to send any software updates to Your Application or otherwise add any additional executable code to Your Application. (not that this is even physically possible. --R.)
[except] as permitted under Section 3.3.23 (In-App Purchase API), an Application may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store or VPP/B2B Program Site.
By my reading, this means that anything besides unlocking functionality within an app is fair game for an alternative purchase mechanism, and forbidden categories of items require such. But ask a real lawyer.
[edited to add, much later:]
After a fun update fiasco with one of the above mentioned apps, these anecdotes are not entirely true anymore. Apple booted one of them because of a tenuous link to a signup web page for some paid services. So be careful, and be prepared for Apple to yank things arbitrarily if you wander anywhere close to the line.
You must use In-App Purchase via StoreKit or your app will be rejected. Implementing your own payment system violates a couple of the review guidelines, most directly:
Apps utilizing a system other than the
In App Purchase API (IAP) to purchase
content, functionality, or services in
an app will be rejected
This of course only applies to content, functionality, or services within the app, as long a the purchase is only relevant to things outside of the app they have no stake in the purchase.
Pretty sure Apple won't allow that, especially if the App is free. They are putting up the money to distribute your app, provide the development tools, etc, so they'd like to take their cut off everything you make as a result of that.
Here is App Store Review Guidelines.
Read 3.1.1.
While aware of the appstore guidelines, specifically IAP usage.
Our company is developing an app that would offer downloadable content [music, video, etc]
There are several challenges but one of the first is IAP on iOS.
After reading all the docs and questions [on stackoverflow], I am 100% sure we need to implement Apple's APIs to process payments and we cannot use our own.
But there exist several apps currently available on the appstore that offer products without using IAP.
one of the examples is goDaddy application where you can use the iOS app and buy a domain using a CC without IAP.
I would like suggestions if possible on how the above can be accomplished?
Put very briefly:
If the purchased item is to be 'consumed' on the device, such as music, extra levels for a game or whatever then iAP must be used. If the purchased item is not consumed on the device then iAP does not have to used. For example paying a gas bill, buying something on eBay, buying dvds or physical books from amazon; or to use your example a domain name from Go Daddy.
I'm building kind of a mobile marketplace on which users can offer and buy services that are only valid for a short time (for example, 5 hours).
Is there a possibility to implement a in-app payment method (in iOS/Android) for that? The problem is that in "normal" in-app purchases you have specific, pre-defined goods or services that are bought in the app. In my marketplace, user can offer lots of different services themselves (various products, prices, etc.) so specific products wouldn't help.
Thanks in advance and kind regards,
Clemens
I can only speak for the iPhone
And as you have figured out already, it is not possible. You have to create all your in-app-purchase products in iTunes Connect, and they all have to be reviewed by apple.
And if you mean physical goods when you say "various products" then it isn't allowed anyway.
IAP is only allowed for stuff that is used inside your app.
This answer is about the iOS app store, from what I understand the Android marker is basically the wild west.
The obvious solution is to sell people "tokens" of some sort in the app, then let them trade those tokens to other users for their products/goods/services. Then you need a way to redeem people's tokens for cash, presumably keeping a modest cut "for the house". I don't see anything in the App Store TOS that would outlaw that.