As of about May 2014 this year, searching Google for "ios in app purchase promotion code", yields lots of news sites reporting the same thing - Apple seem to be working on allowing promotion codes for testing in-app purchases as evidenced by a screenshot from EA games.
My question is; does anybody know how to do this yet? I logged into the new iTunesConnect interface but can't find any link and nothing appears in the Apple docs from what I can find.
Ideally I'm looking to create a code for a monthly subscription but they may only be allowed for consumables. With the lack of actual info on IAP promo codes my guess is that the feature hasn't been officially made available yet and that EA games were invited by Apple to test it out.
As #Christoph Wimberge notes this is old news. Apple is now supporting this.
You cannot officially get promo codes for IAP currently. See here https://developer.apple.com/library/prerelease/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/ProvidingPromoCodes.html . If you're testing then you should be creating Sandbox Testers under Users and Roles. Depending on how you handled the IAP this could well serve as a promo code of sorts. So, for instance, if you're using the IAP to set a flag in NSUserDefaults or a plist file then this will work as a promo code. You will have to instruct the user to log in as the test user for the purposes of the purchase. Even if you delete the test user once the flag is set the user can use the IAP so long as they don't completely remove the app and assuming you don't change the way IAPs are handled like using App Store digital receipts to confirm purchases. Of course, if you're worried about crackers then you're probably not going to store successful IAP as a flag especially in User Defaults where anyone can just change the value willy nilly. But for apps that aren't games this probably isn't a huge worry. Hope that helps.
We were told by Apple today that they never allow users to type in codes, use Q-codes, or other gateway key to access anything. Instead, she said we should use a members-only webpage (i.e., login required) to accept redemption codes and associate the content through our backend. When the user returns to the app, the content would be available.
If Apple enabled codes for IAP, you could offer sales of the codes from another platform, which would then unlock the IAP. Apple would be doing all of the work, but reaping none of the rewards. In addition, all of a sudden, you've created a knock off market for promotional codes, like g2a.com does for Steam keys.
While Apple might have the functionality, it seems exclusive to EA for now.
Currently, you'll need to figure out how to support promotional items outside of the app store.
Related
OK I'm working on a app where the user purchases the app from the App Store, gets access to the app for a year, and then after the year has passed they are sent to an In-App Purchase screen where they can purchase a subscription for continued access.
(this is not the subscription model I'd implement if it were up to me, but the client insists that it follow this model)
In order for it to work, though, I need a reliable way to check when the app was purchased, in order to calculate when the first year of access ends. Following the suggestions in one of the answers in...
iOS App Purchase Date
...I've gotten the app receipt and I can find all the data fields that the documentation says there are, but there are also a few others including "original_purchase_date" (not the one in the IAP receipt array; the one for the app receipt itself). This would appear to be what I want. However this field is undocumented.
As far as I can tell, Apple security operates via a form of "Security Through Obscurity/Diversity", so it's been difficult to find further information about these undocumented data fields. My concern is that I might use the data from this field, and then discover that it was only there in sandbox mode and actual receipts don't have it. Worse, what if I reference that field and then Apple releases a new iOS update that completely discards that field from its implementation? Undocumented features are even less reliable than deprecated features, after all.
My question is this: is there a reliable source of information somewhere where I can find out what Apples intends regarding this field? Or better yet, is there another, safer way of achieving the system my client wants?
You have to implement it as a free app that requires a subscription IAP. Paying for an app cannot be its subscription cost.
Check rule 11.12 here: https://developer.apple.com/app-store/review/guidelines/#purchasing-currencies
Apps offering subscriptions must do so using IAP, Apple will share the
same 70/30 revenue split with developers for these purchases, as set
forth in the Program License Agreement
Implementing it the way your client wants will result in rejection.
Have any of you implemented something similar to the below scenario?
Consider an app which provides audiobooks:
The books are maintained dynamically from a web based UI by the authors.
The books become available for users of the iOS app, as in-app purchase items.
By default Apple guidelines suggests using non-consumable IAP, and adding continuously as many IAP items as many books we have. But this is not proper for us, as the authors won’t have access to iTunesConnect, so it cannot be dynamic, “self-serving”.
Therefore we are planning to create a set of generic "consumable" IAP items like “Book worth $0.99”, “Book worth $1.99”, and so on. Then in the app we’ll show the corresponding IAP item for the books as specified by the authors, when they added it to our system.
Of course we store the purchased items on the server side, so the user will always have access to the purchased items -- even if they access it later from another device.
Will Apple approve this implementation?
Does it fit with their IAP policy?
I’ve found some similar quite old topics in the forum but the answers were confusing.
Have you implemented something similar and get approval from Apple?
Apple has accepted our solution, as described in the question.
The point is, as highlighted correctly by #RomOne and #ge0rges that you need to provide the possibility to restore the items later.
As we are storing every purchase in our database, and our users are authenticated (they need to register and log in to purchase), we are able to provide them access to the purchased items forever, even when accessing the app from other device.
We are also storing the associated in-app-purchase's ProductID from iTunesConnect, plus the userID, the price, and the date, to have a detailed register of all purchases.
Important: Apple has rejected our first solution, because they didn't understand how it works, and how a purchase can be restored.
The key to success was describing in detail how the system works and providing a test user access to our web admin site. This allowed the Apple reviewers to see the whole system.
Yeah in my point of view they will accept it. As long as you allow users to retrieve their purchases later on. Your system make me think about a virtual currency I have made where I had to make generic consumable that needed to be actually saved for the user. Apple approved it (and still does) because I was saving all purchases, even if it didn't fit perfectly with IAP policy ;)
The key here is to make sure these purchases are restorable, always. So make sure to store the "IDs" or however you identify the different item in a way that is associated directly to the Apple ID (not account, but Apple ID).
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
We have a print magazine and we're going to release an app with subscription model, sort of kiosk app but with extended functionality.
Well, what we want is to solve the following cases:
Case 1 (complex)
User buys a print issue and discovers a promo code in it. This code should allow user to download free digital copy of this issue from our app.
User launches the app, opens a dialog box where he can enter the promo code.
Voila! User gets his free digital copy of purchased print issue.
Digital issue always remains in his list of purchased issues and is a valid purchased issue with all App Store options available for them (restore, etc.)
Case 2 (simple)
User does not have a print issue. He launches the app and buys the same digital issue using IAP.
So, both issues are the same (i.e. "blablabla magazine", November, 2014) but 1st was downloaded using a promo code, and 2nd was purchased with IAP, and they both should have the same properties and "weight" for App Store.
Problem is I don't know if this model will be approved by Apple. Or, if they do, how do I develop this? AFAIK, list of purchased and non-purchased items is provided by App Store and there's no way to intervene this process.
I didn't find any samples of using 3d party promo codes in iOS apps. Can anyone provide a solution for this, please?
Thanks
To keep a record of the promo code usage, I think the simpliest way to do it is to require an account. Once the user is logged with his account, you can tell a server that the promo code have been used with that account. If the user delete/reinstall your app, you will be able to restore all his promo codes from his account.
For your issue with IAP and promo codes, here is the App Store Review Guidelines
See the 11.16 section:
Apps may enable additional approved features or functionality when
used in combination with specific approved physical products (such as
a toy) as long as the additional features and functionality are either
completely dependent on such hardware (for example an App that is used
to control a telescope) or also available through the App without the
physical products, such as by way of reward for achievement or by use
of IAP
So basically, what you want to do shouldn't be rejected.
But by experience when you do something that borderline with Apple's money (possibility to "undercut" IAP), you should expect a review failure, whatever the guidelines review says.
Keep in mind that the guidelines can be interpreted in your advantage, or in you disadvantage.
Is there a way to offer a purchase free of charge for in-app purchases? I'd like to give a free download as a promotional item and not charge the normal price that is listed in iTunes.
You have to code for this in your app. In my app all purchases are registered on parse.com and sync'd between user's devices. I can add a purchase to the class on parse.com for a user and then they get the IAP for free when the data sync's to their device.
Apple don't have any mechanism for this like they do with app purchases unfortunately. The best way I've found is a custom URL scheme, so you can generated a code/string of your custom URL type ://myApp/123456promoCodeFooBar12999 etc, then your app, in response can connect to your server and check this code off against your database (confirming that it has not been used before, and can't be used again on a diff device) before unlocking the feature. This circumvents needing to get UUID's off people etc (which you can't do in code anymore to check against anyway), you just need an email address, send link, user clicks in it, your app opens and away you go :)
edit addition 28 Feb 2014..
an alternate approach might be to submit an separate paid version of the application in which all upgrades are unlocked because they are paid for upfront at purchase time. You may choose to keep this off the iTunes shelf but occasionally put it up, perhaps at a prohibitively high price, $1000 etc, because you can get the normal promo codes off Apple for this one to give to journalists etc, just explain what you are doing to them in your cover letter and I'm sure they'll be more than happy to play ball