iTunes Connect DAILY reports for our app shows lets say 52 purchases a day... but according to our server logs, there was 55 purchases processed on the same day for which the items were delivered.
How is this possible?
Our server is keeping all the original purchase receipts (all 55 of them) and even now we can re-validate all of them with the apple servers successfully.
We are using "original_purchase_date_pst" in the receipt to identity the date of purchase which we believe what iTunes uses when downloading the DAILY report (We did tried matching with all other "purchase_date" fields in the receipt... but with no success)
The daily report shows NO REFUNDS...
We do have "transaction_id" for all 55 purchases, but there is no way to match them against the DAILY REPORT.
Please help,
UPDATE:
Contacted Apple and got a template response (as expected)...
"Apple Sales and Trends reports are working as expected. We can’t account for any discrepancies between our reports and those of any outside reporting systems.
Let us know if you have additional questions about this information. You can reach me Monday - Friday, from 7:00 AM - 5:00 PM (PST) at 1(877)-206-2092."
I had sent them the full details... but they will not even look at it!
UPDATE:
Ok, considering if its a REFUND (or REVERSAL as #Ricky suggested), how do we check which transaction was refunded? we do have all the transaction_id but the Apple report does't show any.
If you confirmed that there is no Refund. How about a Reversal of an accidental purchase (eg: purchase 2 times)?
If you read Appendix L - Newsstand Report Field Definitions for
https://www.apple.com/itunesnews/docs/AppStoreReportingInstructions.pdf
There is a field Sales/Return:
Can be S or R. R is a refund and not a reversal.
It is reasonable to believe that Apple treats Refund and Reversal differently. I believe that when it is a refund, you will see a negative value under Units on your daily report, but for a reversal, the entire transaction might be cancelled out and not even appear on the report.
I am unable to confirm on that with 100% confidence, I guess you may drop an email to Apple Itunes Connect Support for more info on reading the Sales and Trends and daily report.
Added a Screen shot for Reversal (Apple does not mention Refund):-
So is the Report By Apple treat Refund and Reversal different? You have to ask Apple support.
Add extra screen shot:-
Related
In order to be able to better estimate the revenue income of our app, we implemented a Database function that reliably (we tested it in Sandbox mode) increases a subscription counter for the subscription that was made by one once a subscription has been made.
This function is only triggered once an in-app purchase has been successful (i.e. when we receive the feedback from StoreKit to enable the Premium functions). Now, we have found enormous discrepancies between the data we observed and the data App Store Connect gives us.
For the past two days, upon confirmation of purchase via StoreKit, our app has 13 times enabled premium functions on a monthly subscription basis, and 14 times on a yearly subscription basis.
However, App Store Connect tells us we had one yearly subscription and 5 monthlies.
Furthermore, for the one premium subscription that generated sales of $5.60, Apple has added proceeds of $3.73 - but that's more than 30% commission. That's almost 35%.
The sales that Apple has not accounted for amount to more than $70.
Can anybody explain to me what's going on, why Apple is not showing us subscriptions that definitely happened and takes more commission than agreed?
My bet is that you are not aggregating the prices correctly on your database side. It is extremely complicated thing to do, despite superficially seeming simple.
The second guess is that ItunesConnect revenue is delayed by day or three (they were experiencing delays).
If you want to see know the revenue calculation is done correctly, I recommend hooking yourself to RevenueCat (quite simple process), and to double check numbers.
Regarding the price, don’t forget their is also sales tax/VAT that is deducted too. Eg. Any sales made in the UK will have 20% vat removed, then Apple takes 30% and you get the rest.
I have an app that has a 1-month trial of an in-app auto-renewing subscription. This past week I've been able to get over 300 trial sign ups. What I'm NOT seeing is any cancellations during the trial period, and I find that hard to believe.
Does App Store Connect show cancellations that happen during a trial period or not, because right now I am showing ZERO cancellations? Am I just really fortunate with my numbers here? Or am I flying blind and the numbers aren't telling me the full story yet?
In App Store Connect, under Sales and Trends > Subscriptions > Summary, I am showing the following:
I finally found cancellation ("churn") metrics in App Store Connect.
Go to the Trends module, then in the sidebar under "Subscriptions" click on Summary and Retention — each of those pages has some metrics related to cancellation. In some places they split out conversion rates from trials, promotions, and renewals.
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.
I've been reading the various threads on in-app purchases auto-renewal subscriptions, and I think I've pieced together most of the information I need, but there are a few missing pieces. I'm hoping someone can help me.
The situation:
I have various subscription packages the user can subscribe to (e.g., package A for £1 a month, package B for £2 a month, etc.). I store the user's subscription information in my database. When the user logs in, I check which package he's on and if it's expired or not. My website, android and iOS all use the same database, hence this approach seems to make sense.
Subscribing users via in-app purchase seems straight forward enough. I check paymentQueue and once the payment is cleared, I can update my database.
My questions:
1) My understanding is the user can use iTunes to manage their subscription. Say, they go in to iTunes and cancel their subscription, how can I be notified so I can update my database? Do I need a daemon that checks expired subscriptions to see if the user renewed?
2) If the user wants to upgrade their subscription from Package A to Package B, how do I handle the pricing? Say on Jan 1st, they buy Package A, I charge them £1.00 and set the expiry date to Jan. 31st. On Jan. 15th, they want to upgrade to package B via in-app purchase. Ideally, I would charge them £2 for Package B minus £0.50 of credit they have for Package A and set the new expiry date to feb 14th. However, Apple forces me to associate each package with a tier price. How can I handle this? I don't want the user to wait until the end of the month to put them on a higher tier package...if they upgraded mid-month, it means they want the new content package B will deliver to them immediately.
Any help appreciated!
Thanks!
1) Yes you'll have to reverify your receipt check out the Receipt Validation Programming Guide in the documentation. They mention some important keys:
status - 0 if receipt is valid, or an error code
receipt - JSON response of the receipt
latest_receipt (auto-renewable only) - base 64 encoded receipt for the most recent renewal
latest_receipt_info - JSON version of latest_receipt
With this information, when a purchase is made, send the receipt to your backend for validation, the backend will keep the receipt in the DB and verify with status = 0 that it's a valid receipt. From there, every x days you can validate that receipt with a chron job, daemon, etc. and reverify. The response back each time will have latest_receipt_info that you now need to save to your DB so you have an up-to-date receipt for the next check in x days. This way you will always have the latest receipt. There is no instant notification for telling when a user cancels a subscription, but with this you'll know every x days if they have the subscription still.
2) Pricing like this unfortunately can't be handled. It was not intended for a user to "upgrade" with subscriptions - each subscription is access to it's own exclusive content as of this writing. However, if a customer emails in and complains about it, you could ask for their user name and figure out in your DB if this user has indeed upgraded mid-month and reimburse them appropriately. Very old-school and not feasible for a big user base, but hopefully you won't have that many and can keep them happy.
EDITED
For the second question, Apple's auto-renewable subscription system does not technically offer upgradeable plans between different products.
Every subscription is a stand alone product and it's up to the user to turn on/off subscriptions manually using the Subscription Manager in the iTunes Store.
However if package A and package B offer the exact same content only different duration than what ajay_nasa said is correct, you can create an single auto-subscription product with different duration options. If the user is on 1 month subscription and then the user tries to change to 2-months subscription they will get the following error message asking them go to the App Store's subscriptions manager
So basically the ONLY place the user can actually change the subscription's length is in the App Store. Whether Apple decide to pro-rate the amount left on the old subscription or just append it to the current one is really up to Apple. You need to make sure the user have access to the subscription as long as it's active by reading the Original Purchase Date and Subscription Expiration Date field from each receipt entry and determining the start and end dates of the subscription.
Answering question 1, you can verify subscription receipts in the same way as other IAP, but you'll need to check it periodically to see if the subscription has expired (the verification will tell you if it's expired).
There is more info on the Apple docs here:
http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/RenewableSubscriptions/RenewableSubscriptions.html
Actually, Apple's auto-renewable subscription system does offer upgradeable plans.
To achieve this we simply should add duration in existing Auto-Renewable Subscription. Every Auto-Renewable Subscription could be family of Subscriptions so whenever developer wants to achieve upgradation in subscription he should add duration in existing Auto-Renewable Subscription with different productID.
Whenever, user upgrade his plan in between the month then his upgrade plan will be automatically works from next month.
Answering to your question #1
Recently Apple launched a feature to enable server notification whenever the subscription is renewed. However, the subscription should be in-app.
See the links given below for your reference:
https://help.apple.com/itunes-connect/developer/#/dev0067a330b
&
https://itunespartner.apple.com/en/apps/news/45333106?sc_cid=ITC-AP-ENREC
We Need to Check Cancellation-Date provided in Receipt.