I am wondering whether to implement in-app purchase refunds (in case a user refunds). None of the in-app purchase tutorials seem to show how to do it, so I am wondering if that is for a particular reason.
By the way, the in-app purchase is a non-consumable (PRO version).
A big problem I can see with refunds for example, is that you shouldn't remove the PRO features if they don't have connection, but then someone can just use no connection with the app to never get PRO revoke.
My question is: Is there a seamless way to integrate refunds for non-consumables, and do many other apps handle refunds or not?
Thanks.
I believe the only way for a user to get a refund is to request it from Apple. If granted, the onus is on you to determine this condition. You will have to check receipts actively.
https://developer.apple.com/library/archive/technotes/tn2413/_index.html#//apple_ref/doc/uid/DTS40016228-CH1-RECEIPT-HOW_DO_I_USE_THE_CANCELLATION_DATE_FIELD_
This states:
The Cancellation Date (cancellation_date) field is designed for use
with auto-renewable subscription, non-consumable and non-renewing
subscription products. This field is set when a customer contacts
Apple customer support for a refund and the transaction is canceled.
Depending on if your app has a backend or not will dictate a strategy to handle this. If you have a backend, a good method is to periodically check for receipt status (at some time interval of your liking). Note that if you have a large user base, you probably want to divide up the user pool piecewise to do this type of check.
If you don't have this as your option, then you need to make your app make this check.
Or ... you accept that this will happen. I've done work for a company that had a large subscription base and they never ran that check for cancellation/refund (I let them know about that weakness in the system).
Related
Is there any way to implement conditional logic for payments in Swift? For example:
Say the user has agreed to have 10$ withdrawn from his bank account he connected to his app account if, on a specific day, he has not fulfilled a condition that can be tracked with the app.
If he fulfills the condition until 23:59, no money will be withdrawn. If he doesn't, at 00:00 on the next day, the 10$ are automatically withdrawn from his bank account.
I don't know of any app that does this and I'm not even sure whether an app like this would be permitted on the app store. I'm not even sure whether that's technically possible.
Would be thankful for any helpful input!
Using the in-app payments system (a.k.a. iOS in-app purchases which utilise the StoreKit2 or StoreKit API) this not feasible.
Explaining how in-app purchases work would be a bit tedious.
However, to put it simply, you can basically initiate either a one-time payment request, or a recurring payment request.
In each of these scenarios, the user may obviously either make the payment or decline, about which you would get updated in code.
The closest the system comes to what you are asking for is recurring payments (technically called the auto-renewable subscriptions).
However there is no way to ask Apple to conditionally deduct money based on whether the user has performed some action or not.
I'm pretty sure you should not be looking at the iOS in-app purchase system as a way to do what your are looking for.
You could use 3rd-party payments.
However, whether Apple allows this, would depend on what kind of condition you expect the user to fulfil. If it relates to a real world service or material, then you may be able to justify it to Apple, however, if it is a digital service, lets say an app based activity, such as opening the app a given number or times, or viewing the app for a given amount of time, then I'm pretty sure this would be in violation of the Apple App Store Guidelines and they would reject your app when you submit it for review.
To be honest without understanding the use-case a little more clearly it is a bit difficult to advise you on the technical feasibility.
I am having a programmer code my iOS app, which he has done great. However, due to a new competitor we have decided to change from our current revenue model with In-App Purchases as subscription based to just having users pay a one-time fee. He tells me it'll take a lot of hours to make that change. Is it really true that there is no easy way around changing the code from having renewable purchases to simply have one-time purchases?
Well, this is a very objective question. It's impossible to tell you with any certainty without reviewing the actual code, but here are a few of the obstacles your developer may face:
The methods to buy a subscription is slightly different to buying a non-consumable product, however the app will need to continue to provide content users who are currently paying for a subscription. There is no way to change a subscription to a non-consumable product in iTunes Connect, and you may need to, or should ask and remind the user to cancel their subscription to prevent further renewals (you can't do this yourself or in the app, you can only link to the subscriptions page in their iTunes settings).
The app will need to check for either the subscription product (active or expired) or the non-consumable product has been purchased in order to provide the content. Support for this will need to be on the start of the app, purchase of a product and on the restore in-app purchases function.
There may be further complexities too, particularly if your app uses a backend API that syncs purchase information with a user account.
In conclusion, it's non-trivial, if your developer says it will take a lot of hours, I would be inclined to believe him.
I'm working on an iOS app that will use Apple's in-app purchasing framework to let the user create auto-renewing subscriptions.
I want my server to check periodically that none of the subscriptions have expired. Apple's Receipt Validation Programming Guide describes a verifyReceipt web service that appears to validate a single receipt.
However, if I want to bulk-verify my entire database every few days, is there a better way to do that than a storm of individual verifyReceipt calls?
You don't need to need to bulk-verify your entire database. A subscription is valid for a fixed duration. If the user cancels their subscription then this takes effect at the next renewal period, not immediately.
Apple customer service can refund a subscription if a user has a case (wrong product purchase is one example they give) but this would be a pretty low figure - and your app should also check for a valid subscription when it starts.
So you should only need to verify subscriptions that are known to be expiring "today".
To my knowledge there's no way to send multiple receipts in one bulk request to validate them in the iTunes servers... You have to send one by one. (Multiple requests)...
I don't know if how you are planing to solve this is the best approach. Apple has extended documentation on how to handle auto renewal subscriptions, most of the times you check the validity of the subscription in the app itself.
Check the in-app purchase documentation. It's a very good read if you plan to depend on in-app subscriptions for your business model:
https://developer.apple.com/library/ios/technotes/tn2259/_index.html
I'm implementing an iOS app with non-renewing subscription. Not much relevant information was available online; so I seek your guidance.
A use case which worries me the most is when a user purchased the subscription once and then immediately after purchase it again to extend the duration of service (see such scenario here). What if that user were to refund the first purchase, leaving the second one intact? Is this even possible in practice, or am I just too paranoid?
Assuming the above case is possible, my app will run into a problem because, as far as I know, verifyReceipt only returns the latest, good receipt (watch Managing Subscriptions with In-App Purchase in WWDC'12).
I find nowhere Apple provides relevant information about refunding policies.
(Auto-renewable subscription seems to rule out this case as a renewing action is taken care by iTunes automagically and it seems not possible to extend this type of subscription until iTunes allows it.)
verifyReceipt will not only return the latest good receipt, it will also tell you if the receipt you submitted for verification is good. So if you're concerned that a user may have cancelled* a transaction, then submit every receipt you're questioning.
*But what do you mean by "cancel" the first purchase? Do you mean when they tap "cancel" instead of "buy?" Well then the transaction won't go through and you won't even get a receipt.
Or do you mean when they request a refund? I don't know any other way they can cancel a purchase.
Edit:
If you're referring to refunds, there's no way for a developer to tell if a user has been issued a refund. The assumption is that Apple expects you to continue to deliver services to that user regardless of the fact that they received a refund. Your receipts will probably all verify correctly regardless of the status of a refund.
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,