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.
Related
I am working with the Inapp purchases in my current app. After successfull purchase i save the "receipt" of the product on my server. I am aware about the "Financial Reports" provided on iTunes Connect at monthly intervals. Now my question is what should i have to do to validate a particular transaction with the Financial report provided by apple. I see some sample Financial reports but couldn't find any such parameter which give the transaction Id or any other unique field.
Also, if there is any way of attaching some payload during the Payment request and get that payload back in the receipt and the Financial report?. This might solve the problem from me.
Correlate an Inapp transaction with the Financial report
#Hotwheels - did you find any way to do it ? i have similar requirement
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.
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).
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.
We are developing one iOS application for iPhone which will free features as well app will have premium features with 4 in app purchase auto-renewable subscription options as below:
Single monthly subscription
Single yearly subscription
Family monthly subscription
Family yearly subscription
We will have one store screen inside the application which will have options to subscribe to various subscriptions which our app provides.
We found that user can go to device settings and manage their In-app purchase subscriptions.
We are also planning to provide options like user can upgrade from one subscription to other and user should also be able to down grade their subscription which would be all of the same options in reverse and back to the free version
Possible upgrading option:
Free to Any 4 subscription options
Single monthly to single yearly
Single monthly to family monthly
Single monthly to family yearly
Family monthly to family yearly
Possible down grading options:
Family yearly to family monthly
Family yearly to single monthly
Family monthly to single monthly
Single yearly to single monthly
From any 4 subscription options to Free version
Note:
According to Apple we can not use Apple family sharing option to share In App purchases so we are developing our own family sharing option in application. (Reference: https://support.apple.com/en-in/HT203046)
Queries:
We have some doubts how we can manage the subscription in our iOS application?
How device settings options will show our 4 In App Purchase options for upgrading and degrading form one option to other?
What are the consideration we need to task care as an iOS developer for restoring the auto renewable subscription? we are not clear with the possible scenario if user try to restore using iTunes account with multiple user accounts in our app, what are the preventions we can take care which apple allows while user buy subscription one time and try to restore on multiple user account?
Apple will reject custom family sharing option using auto renewable subscription option?
What are the points we need to take care at our end which apple will not handle if we can go with above features?
What are the possibilities of violating the apple guidelines and app rejection if we are going with above features with iOS application?
It will be great help to us if any one can share their views or provide some guidance on which way we should go or if we are going off track from the apple policy.... all those kind of your feedback will help us to get things moving over here.
Thanks
We have some doubts how we can manage the subscription in our iOS application?
Because you are using your own user management system, you should persist the state of a subscription associated to the user in your database. When the user creates a purchase in the app, the app should send this receipt on to your API which will then proceed to validate it.
Once persisted, enqueue a scheduled process to run on the Subscription Expiration Date to update the record and ad infinitum until the expiration date is no longer in the future.
Your app should query your API when the user opens the app to determine their subscription status. Don't rely on the receipt locally in the app as your user's family member devices will not have this purchase associated.
How device settings options will show our 4 In App Purchase options for upgrading and degrading form one option to other?
If all products listed in iTunes Connect are of the same "Subscription Family", they will appear in the Subscription Management page in the users iTunes account.
When a user switches between products a transaction will be created and a SKPaymentTransactionStatePurchased event will be added to the SKPaymentQueue. This will be a new transaction with the same Original Transaction Identifier as the first purchase made with a product from the same Subscription Family with the Product Identifier reflecting the new product.
For this reason, you want to have your transaction observer in your app running in the background to receive any new transactions. When a new transaction is received you can either a) send the whole receipt to your API or b) inform your API that a new transaction has been received and re-validate the receipt that was persisted.
Going with (a) may become problematic as the receipts will become larger over time requiring more bandwidth from the user each time.
Going with (b) also has it's drawbacks because you can get into trouble with edge cases like the user switching iTunes accounts. A solution for this is to store the apps identifierForVendor with the receipt, and require the app to send the whole receipt if it does not match. Most of the time you will just be informing the API that a transaction has occurred, and on the few occasions that the identifier doesn't match it will send along a new receipt.
What are the consideration we need to task care as an iOS developer for restoring the auto renewable subscription? we are not clear with the possible scenario if user try to restore using iTunes account with multiple user accounts in our app, what are the preventions we can take care which apple allows while user buy subscription one time and try to restore on multiple user account?
When restoring, a new transaction with a new transaction ID will be created, the original transaction ID will be the same though. If you create a transactions table in your database, you can ensure a transaction and it's original transaction is only ever associated to a single user, thus preventing users restoring purchases on other devices with a different user and gaining access to the subscription.
A restored transaction will be pushed onto the queue with SKPaymentTransactionStateRestored and so when this happens simply I advise sending the receipt to your API and process the receipt normally; associating any new transactions to the original user.
Apple will reject custom family sharing option using auto renewable subscription option?
I doubt it, but I am not Apple so don't take my word for gospel. Spotify have a similar scheme called "Spotify Family" where a user can share their Spotify account with their family, not sure if this is enabled for their iTunes app though.
What are the points we need to take care at our end which apple will not handle if we can go with above features?
You need your own API with user management and family association
Your users need to sign-in/register on your app
You will need to prevent family users from purchasing if their parent account already has a purchase.
Persist receipts and the identifierForVendor in the database.
Handle receipt validations using the validation API.
Persist a table of transactions and consider this table self-referential so that a transaction can belong to an original transaction through the original_transaction_id. Ensure the transaction_id column is unique.
Validate the receipt each time a transaction is due for renewal.
What are the possibilities of violating the apple guidelines and app rejection if we are going with above features with iOS application?
I see nothing in the guidelines except for section 17.2:
Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
I think this one is a little contradictory, since in 17.5 it states:
Apps that include account registration or access a user’s existing account must include a privacy policy or they will be rejected
I guess by this, it means a user must be able to use the app without requiring registration, but I know of many examples of apps that do exactly this.