I'm worry about the refund process on Apple. As I understood, if a customer ask Apple for refund and Apple accept its, the owner of the application is not notified, instead, the owner shall be monitoring the receipt data with Apple to look for the Cancellation Date field in the receipt.
Apples says... "If the field has a date in it, regardless of the subscription’s expiration date, the purchase has been canceled—treat a canceled receipt the same as if no purchase had ever been made" (This is the recommended process)
Now, I'm wondering if it is possible to detect manually a refund from iTunes Connect and obtain the receipt data of the product canceled? I have to say that I don't have access to the Payments and Financial Reports section to check if this is possible, that the reason I'm asking.
Not sure what your goal is, i.e. it is definitely not possible to get information on the customer who got the app refunded.
Here's a way to get more information on the refunds:
Go to > Sales & Trends
Filter by "Transaction Type" and you get an overview of all your refunds (possible to filter by app, via Content "App Name")
You don't have any ways to track refunds explicitly via "App Analytics" (only shows the totals, i.e. downloads/purchases minus refunds) or "Payments and Financial Reports". For the latter, it's the same, they only show you the totals.
Related
We have "try for free" button in our app. I'd like to figure out how to know that trial is available.
I'm a little bit doubt about following text from documentation:
New and resubscribing customers are eligible to pay one discounted price or free trial per subscription group.
What is "resubscribing"? Can customers who has subscription in the past have trial again?
Is it possible to use StoreKit to figure out that trial is available now?
Is it correct to check introductoryPrice property of the SKProduct: https://developer.apple.com/documentation/storekit/skproduct/2936878-introductoryprice?
I also had an idea to ask backend for all the subscription history for current user and show "try for free" if user didn't have trial yet. But as I said I'm not sure about that "resubscribing".
The correct way to check for trial eligibility is to validate the receipt file as outlined by Apple below. Since most would consider this a non-critical validation, there isn't much harm in doing it client-side instead of off a server to save a network call. The worst harm a fake receipt could do is change the text of your button.
Determine Eligibility
To determine if a user is eligible for an introductory price, check
their receipt: Validate the receipt as described in Validating
Receipts With the App Store. In the receipt, check the values of the
Subscription Trial Period and the Subscription Introductory Price
Period for all in-app purchase transactions. If either of these fields
are true for a given subscription, the user is not eligible for an
introductory price on that subscription product or any other products
within the same subscription group. You typically check the user's
eligibility from your server. It's best to determine eligibility
early—for example, on the first launch of the app, if possible.
Based on the receipt, you will find that new and returning customers
are eligible for introductory price or free trial discounts as
follows: New subscribers are always eligible. Lapsed subscribers who
renew are eligible if they haven't previously received an introductory
price for the given product (or any product within the same
subscription group).
To answer your specific questions:
Can customers who has subscription in the past have trial again?
No. This is enforced by Apple for any products in the same subscription group. For example if user starts a trial for "Monthly Product", cancels, then later buys "Yearly Product" they won't be eligible for a free trial.
Is it possible to use StoreKit to figure out that trial is available
now? Is it correct to check introductoryPrice property of the
SKProduct?
No. The SKProduct will always show the same introductory price.
Is there any common field inside of the generated financial report from iTunes connect you can cross reference with the validated in-app receipt you may have stored in your database? For example, the receipts have a transaction ID, but that does not exist in the financial report, so it can't be used to cross reference a record.
Unfortunately not. Apple support wrote me that "a detailed purchase and subscription report with transaction IDs or timestamps currently does not exist within our Sales and Trends reports" . Otherwise it would affect users privacy.
There is randomly generated Subscriber ID in subscriber report (https://help.apple.com/app-store-connect/#/itcf20f3392e) that is unique to each customer and developer, but it is not connected with receipt information.
If subscription volume is small, those reports may help, especially Subscriber event .
I believed that applicationusername can be set and used as Subscriber id, but it can not, it is used only for fraud detection on the Apple side.
I'm trying to pull historical payments per-subscription from Apple, and I've run into some problems. What I'm hoping for is something similar to what I get from Stripe, where I send a subscription ID and receive an array of transactions (including payment date, payment amount, discount, currency, etc.).
Using in-app subscription purchases from React Native, the app receives and store what appear to be "iOS 6 style" receipts (regardless of the actual iOS version).
Validating these with Apple on a regular basis has worked well in order to check the current subscription status, but Apple's documentation suggests that the only way to retrieve historical transactions is to provide an "iOS 7 style" receipt. Even then, the returned receipt objects do not appear to contain information about the amount paid, the currency they were paid in, and whether Apple's cut was 15% or 30%.
First question would be how (or even if) I can transform the "iOS 6 style" receipt into "iOS 7 style" - or whether there's another way to get full history for a given subscription ID? The second would be how to retrieve the actual transaction information, above and beyond a simple "payment of some kind happened at this time"?
To be able to fetch data of user's transactions you need a receipt. Using apple verifyReceipt api you'll able to get all needed information, except prices.
I not sure, but there is no way to convert iOS6 style receipt into iOS7 style. But, I hope it may be done on client-side (device) automatically.
If you just want to get financial information look at Apple Reporter Tool, which allow you to fetch any financial data you want (subscriptions, inapps, application installs, applciations purchases).
Situation:
- User makes an IAP and is awarded some content, we store the users device id to ensure they can access this content whenever they want.
- User decided they do not like the content, so they call Apple and get a refund.
- User can still access the content, even though they have been refunded for their IAP
Problem:
We don't want the user to be able to access this content anymore. This could become a loophole that they would take advantage of. (unlock content, then get refunded and keep their access to said content)
Question:
Is there any way for us to check if a user has been refunded for an IAP with either their transactionId, transactionReceipt, or any other information we may have?
For Reference, I've read the StoreKitGuide, it did not mention this case.
No. There is no way to revoke access to content if they have been refunded. I believe this is by design. It is the same with App Store refunds; if someone buys an app and then asks Apple for a refund, Apple does not stop the user from continuing to use the app.
No. you cannot stop user to access. Apple does not stop user to use that feature after refund
Below a recent answer from the overbearing Apple!!!
At April 11
Hello Joe,
Thanks for your quick reply at first.
I think there were some misunderstandings. We understand that you must protect the user information. And we do not require any user info. We do not require any user's information---- iTunes account, User Name, email address and other information about himself/herself.
We require only one data----- transaction id (named "transactionIdentify" in your code), for example "1000000033409668" (this transaction id is a record at March 13).
A user buys a product from IAP, you will generate a "transaction id" and send it to us. This transaction id is stored in our database then. Now he/she gets refunds from you, so please send the transaction id to us. Let us know which one in the game canceled the IAP.
When a refund occurs, we think you should provide the transaction id to us. With these data, we could make a more fair service for all players. If you do not do it, more and more players will use your refund mechanism to get game items without real payment. You and we will lose money then. We think it is very important.
Regards,
Baibo
At April 12
Hello Baibo,
Thank you for following up with me regarding the refund transaction data.
We will not be able to provide you with the refund transaction data you have requested as it is not a feature or benefit provided to you per the contracts you have agreed to.
To view your paid applications contract and review your membership benefits, please access the contracts, tax and banking module within iTunes Connect:
http://itunesconnect.apple.com
If you are not happy with large refunds, you may want to consider adjusting the price of your in-app purchases as we will not be able to provide you with the refund transaction data in the future.
According to an answer one of my users received from Apple, refunding an app means they will no longer receive updates to the app, but doesn't remove the app from the device. IAP appears to work the same.
I am wondering if there is not a way by using restoreCompletedTransactions to check for the iAP purchase, but this would pop up a request for the user's iTunes password, so its use is limited.
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,