I have an application that has a requirement for a user to be able to purchase an e-card. This is a digital image. The user is then permitted to share this e-card as many times as they wish within a 48 hour period (So, the card is visible in a 'My Cards' menu) It then disappears.
I'm looking through the apple documentation for IAP, and cant figure out if this should be a consumable, or a non-renewing subscription. I currently handle all the persistence and expiry myself within the app.
The problem with the latter is that it seems every card would need its own ProductID (Rather than me just having a product for 'A Card' and the app being aware of which one it is. There's over 200 cards so this doesn't seem feasible, but the methods one must implement don't seem to work like this. For example, a user may have 10 cards, all purchased at different times.
Does anyone know the correct type of purchase this should be, and the best way to implement it?
This answer Floored by new rejection on non renewable subscription type in app purchases in iphone? , rather old (2012), claims that subscriptions must last for at least 7 days. Apart from that, iTunes Connect has no problem with 200 different products.
A non-renewing subscription might work but the 7 day issue is a problem for you. A non-renewing subscription can be purchased many times so there is no problem with duplicate cards - as long as you keep track of that.
A consumable would work except a consumable can't 'expire in time' it can only 'expire when used'. So if I purchase a card as a consumable I must be allowed to keep it on my device for a long time until I want to use it. You could let the user do that - they keep the card but can't use it. When they want to use it then it gets consumed and for the next 48 hours they can use it as often as they want. You may need to explain to App Review that this is a consumable that does not expire but that can be used for a continuous 48 hour period once it finally gets consumed.
Related
I need to combine two types of the app-purchases in one item -- for example my purchase should be:
5 bananas / 6 months
So I can buy 5 bananas in my app, but I can eat/use them only for 6 months.
How can I implement this? Is it a normal usage of the purchases? Thx.
I don't think this is possible. It seems like you will have to pick one of the two because your plan seems to violate some of Apple's guidelines.
According to Apple:
Because a non-renewing subscription requires a user to renew each time the subscription ends, your app must contain code that recognizes when the subscription is due to expire and prompt the user to purchase a new subscription.
So if your consumable cannot extended then it will be rejected.
Additionally, consumables
are used one time
You cannot allow it to expire before it is used.
I want to create an Auto-renewable subscription for my app to enable the feature of removing the ads. (one year period)
Is is possible? Would it be approved?
A non-renewable can work as well but I don't want to manage users and subscriptions on my own server, I would like to have a subscription attached to an apple id.
Thanks
I've previously applied to use an auto-renewing subscription for a business app, and was rejected (I've seen reports from others that this has been the case well). Even though the guidelines list the 'business' usage is acceptable, Apple are clearly aiming them at periodicals only.
There are other issues with them to consider as well.
The way I handle it at the moment is by using multiple in-app purchases for various time periods (1 month / 3 months / 12 months etc), hold an expiry date on the device and check that on each app launch. When it has passed, the users are then presented with a re-purchase screen. They can also purchase multiple time-packs which further extends the expiry date.
Sorry but I am bit confuse on implementing non renewable subscriptions.
Basic concept of app is user can post item to sell within the app. For each item to post he has to pay $.99. This item will remains there for 20 days.
As per apple documentation this kind of In App Purchase should be non renewable subscription with expiration logic to be implemented on Server side. I am done with everything like creating non-renewable IAP and integrating with app. Server maintains the expiration for each item.
Now my query is since user can post as many item he wants, how should the IAP ids should be maintain.
User Case #1:
- User A posted one item after he pay $.99 for that. So far so good.
- When he try to post next item, he is shown with the message "You have already purchase this, tap to renew or extend it" instead it should be something "Do you want to buy one xxx for $0.99"
Am I missing something here?
Use Case #2: Now say item is expired (after 20 days), For renewing shall I use the same IAP id (Product ID in IAP) to renew? or I need to create different IAP id?
Please guide me on this so that Apple shall not reject the app.
Thanks in advance!!
OK I used following:
non renewable subscription with expiration logic implemented on Server side.
Same Product ID works for me for Buying for first time and renewing after 20 days expiration.
And application got approved!
What I would suggest to you would be using Consummable in-app purchases.
Once the user owns the purchase, manage on your side how long should the registration last (server-side if the user has an account or NSUserDefaults if everything is local).
Once the subscription time is Over, just lock the functionality. During the subscription time, you can either disable the purchase button, or let them own new ones and stack the durations :)
As stated above, I would like to recommend consumable in-app. You have to maintain a database based on post id and date of purchase when user purchases a post.
You'll have to maintain this database such that it can be restorable for example if still 5 days are remaining. So user will be happy.
To maintain this data you can use your server if you have, or else you can use iCloud, any way this is a simple data sheet. Or you can use any third party library which gives free cloud storage.
Last but not least you can save locally, but I would recommend server, iCloud method. So users can restore their purchases.
So this way you can handle multiple subscription logically.
I'm about to take my first foray into In-App purchases, and I'm not quite sure how to handle my situation. At top is my situation, with some actual questions in bold at the bottom. Any advice would be appreciated.
I'm designing an app that will have a LOT of in-app purchase content. Every day, around 20 or 30 new items will be generated for sale. 3 or 4 days worth of items will be for sale at any given time, and after that they go away.
So we're talking a lot of items. Way too many to add to submit to Apple for a unique ProductID each day.
Of all these hundred items, there are actually only 4 or 5 different types of item. So I'm thinking I'll need to make 1 SKProduct for each type. Under the hood (and invisible to the user) the will actually be buying a credit good for 1 item of type X. After the transaction goes through, I send the receipt AND the requested item to our server. Our server stores that and sends the file back. If they want a 2nd file, they need to buy a 2nd credit and repeat the process. Of course to the user it will be presented like they're buying Item 1, Item 2, and Item 3 directly.
To make this even more complicated, we also want to offer a 3 month subscription (at a significantly higher tier) for those who don't want to buy their items ala carte.
1. Does this sound like a good approach?
Will Apple be okay with this? If not, what possible alternatives do I have?
2. Optimally we'd like to allow people to re-download items they've already paid for.
Would a good approach be to make each credit non-consumable, and since I've already stored the receipt info on the server I can match it to whatever item they should get? If this is too complicated or against Apple's rules, we may just make the item consumable since the item is only good for a few days anyway...
3. Is there anything else I'm overlooking here?
Thanks for any insight you guys can provide.
Take a look about what the iOS Development Program License Agreement says about treating In App Purchases like credits:
2.1 You may not use the In App Purchase API to enable an end-user to set up a pre-paid account to be used for subsequent purchases of
content, functionality, or services, or otherwise create balances or
credits that end-users can redeem or use to make purchases at a later
time.
2.2 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. “Currency”
means any form of currency, points, credits, resources, content or
other items or units recognized by a group of individuals or entities
as representing a particular value and that can be transferred or
circulated as a medium of exchange.
Correct me if I'm wrong, but if your approach does not unlock/add functionality or change the behavior of the app by buying an In App Purchase, my guess is that this could be problematic when trying to get Apple's approval.
Hope this helps,
From the StoreKit guide:
If the user attempts to purchase a nonconsumable product or a renewable subscription they have already purchased, your application receives a regular transaction for that item, not a restore transaction. However, the user is not charged again for that product. Your application should treat these transactions identically to those of the original transaction.
This presents a huge problem in an app I am working on. We have licensed a large body of content from a publisher for sale through in-app purchase. They require that every time we sell a piece of this content (i.e. user pays us), our server calls an API on their servers to report the transaction. This is for accounting purposes and ultimately used to determine how much we pay them at the end of the month, per our agreement with them.
I have read several suggestions on SO and elsewhere about calling restoreCompletedTransactions rather frequently and maintaining a local understanding, on the device, of what the user has already purchased so they cannot be allowed to purchase it again. This to me seems like something that should be able to be implemented on the server side. However, the receipts that we are getting back from the Apple servers are exactly the same for a buy and a re-buy, as promised by the StoreKit guide.
If payment callbacks from StoreKit cannot be trusted as a valid accounting mechanism in this kind of situation ("you got paid" vs. "you didn't get paid"), what other real-time insights into transaction traffic are available? I don't think the publisher we are working with is going to be happy if we tell them we have to wait 45 days after the end of the month to get the REAL paid dollar amount out of iTunes Connect.
I have recently looked into the same problem. In my case, I wanted to implement accurate revenue tracking using Mobile App Tracking to track revenue generated from different customer acquisition campaigns.
Fortunately enough, there is a way to do it. It should be noted that SKPaymentTransactionStatePurchased vs. SKPaymentTransactionStateRestored solely depends on the initating action, e.g. whether you initiated a restore or a (re-)purchase, so that doesn't work.
What does work instead is checking for SKPaymentTransaction.originalTransaction which will be != nil for restores and re-purchases. The latter is unfortunately undefined behavior (docs). I'd consider a null check fair enough though.
Another option is to validate the transaction-receipt of transactions with SKPaymentTransactionStatePurchased and check that the original_transaction_id property in the returned, validated receipt matches the transaction_id.
The bad news is: In the current iOS version (4.3.x) there's no way to distinguish between a buy and a re-buy of non-consumable products.
To ease the situation I would recommend two things:
First
After a successful purchase, store the product identifier of the purchased product in the NSUserDefaults on the device. You can then hide the already purchased products from the user and thus handle a re-buy situation.
The NSUserDefaults are backed up by iTunes when the user synchronizes his device. So your stored purchase information is not lost when the user gets a new device.
Second
Store the receipt data together with the device ID on your server. Analyze the receipt's product identifier and the device ID.
If you receive another receipt with the same product identifier and device ID combination, then assume a re-buy. At least this would allow you to cover most of the re-buy cases.
Assuming that an ordinary iPhone user switches his device every 1-2 years, you will at least cover most of the re-buy cases and maybe apple will fix this in the future.
I have one solution,
Configure the product as consumable.
this will solve the problem - (They require that every time we sell a piece of this content (i.e. user pays us)).
Next you need to implement a logic in product buy option. It is in a way that once the user purchase a product the buy option need to remove otherwise the user may happendly go purchase and lost is cash once again for same product in same device.
you can use NSUserdefaults for this purpose.
thanks,