Mac App Store reasons for SKPaymentTransactionStateFailed with unknown error? - in-app-purchase

I have a Mac OSX app in production, available for download via the Mac App Store. The app uses in-app-purchase to buy a single non-consumable item (unlocking the Pro version of the app). The purchase mechanism works fine on all my machines (both in testing and also production, I've even spent my own money testing the app on the store!) Many customers successfully purchase the Pro version.
However, several customers have also reported problems when trying to purchase, and looking at the available anonymous usage data suggest a significant percentage of customers may be having trouble. In almost all cases, it seems that
- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions
is called with transaction.transactionState being set to SKPaymentTransactionStateFailed with the corresponding transaction.error set to Domain=SKErrorDomain Code=0 "Unknown Error." NSLocalizedDescription=Unknown Error.
How should one go about debugging this? What are the cases that can lead to this error? It would be great to have a list so that one would know what could be done.
For example, on my machine, trying to buy and then, when prompted for the Apple ID password, if one clicks Cancel this leads to the above error. What are some other reasons? (Since several users have reported problems, and presumably they have not simply decided to cancel their purchase...)
UPDATE: Using the software 'Little Snitch 3' I observed that my app (production app installed from the Mac App Store) contacted the server sandbox.itunes.apple.com (via storeinappd or something similar), in addition to a bunch of other apple servers. Should a production app ever attempt to connect to the sandbox? Is this an indication that something is wrong?
Thanks for any help! I'm new here, but I'll try to be responsive in providing more info (if needed) and responding to comments and answers!

Related

iOS Receipt validation failing for long-term users

With our latest release, we converted our app from paid to in-app subscription purchase. We promised our current users that we would grandfather them into the subscription because they already paid for the app. In our code, we look for a valid receipt with an original application version prior to our first subscription version. It all worked great in our tests.
When we released the new app, we started getting feedback from our long-term users that they were being asked to subscribe (they shouldn't even see the subscribe button). As we researched the issue, we noticed that all of these users purchased our app prior to the app being transferred to a new developer in September of 2014.
Recreating this issue is difficult - how do we simulate an app install in 2014? I may be able to login as one of the affected users, which would involve using their Apple credentials. I'm not very comfortable asking users to share their credentials.
Since I haven't been able to recreate it and our code is pretty simple, my best guess as to what is happening is that we aren't receiving a valid receipt for users that purchased prior to the app transfer in 2014.
So, I have a few questions:
Has anyone else experienced this?
If so, how have you resolved it?
How would you troubleshoot it?
FYI - I've filed an issue with Apple (3045378).
In speaking with Apple Developer Technical Support, we discovered a way to pull the NSLog messages off of the devices using the recently released Unified Logging feature. A couple of our users submit their logs, which clearly showed that they were getting valid receipts, but the originally purchased versions of those receipts are 4 and 2.8.
Given that our current version is 1.7.1, these are strange and non-typical numbers. However, the Original Application Version reported from the receipt is actually the CFBundleVersion (or Build), which can be a completely different string than the App Version reported in the App Store.
I assume that the developer prior to the app transfer was using a different build numbering system than the standard ... scheme.
I refined the version check within my code and re-submitted the app. It was released today, and, so far, all are being grandfathered correctly.

In-App Purchase fails to unlock content on some devices

We have had users reporting that they have paid for our product via in-app purchase but we have failed to unlock the content. The common denominator between these reports is iOS 9 so far. It seems like the purchase with success method does not get called. The IAP seems to work and even says that the purchase has been restored successfully (Apple's own alert), yet it does not deliver the content (unlocks the app).
This is a very odd bug because it works perfectly fine on iOS 10, and there is no reason why it should't work on other older devices. At some point, we had a customer complain of the same issue with iOS 10 as well and we just can't produce the issue. I am using RMStore for my in app purchases but this has not started since we used this library. It has been happening even with standard IAP integration.
Does anyone knows or may have heard of what causes this issue?
Any tips would be great!
I have several apps on the App Store and I'm facing similar issues. For about 1% of the users, the success callback is not called after an in-app purchase. If the users restore their purchases later, the purchased features unlock properly, so the App Store processed the purchase properly, and this is likely a bug in the app. I could never find the issue as I could not reproduce it on any of my devices.
After I just read that you use RMStore, I checked the emails that my users sent me during the last two years about this issue and noticed that this occurs exclusively with apps that use RMStore. While the code of that library looks really clean, I assume that the bug is somewhere hidden in there.
As RMStore hasn't been updated since almost two years, I consider it deprecated and will remove it from my apps in the near future. I will update this answer if the issue persists after the removal.
Update after three months: After the removal of RMStore for the in-app purchase handling from one of my apps, the problems have apparently disappeared.

SKPaymentQueue getting SKPaymentTransactionStateFailed when OFFLINE and for products that no longer exist in the store

I'm adding In-App-Purchase (IAP) to my App. I've followed all the guidelines regarding setting up a test user for the Sandbox and logging OUT of the real App Store account. While testing I was buying and cancelling. At one point the device re-sync'd with iTunes and apparently restored and re-connected me to the production store. I didn't notice this until an attempt to buy didn't produce the normal login dialog, which I cancelled. Since that point I've been getting SKPaymentTransactionStateFailed in:
-(void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions
And the error SKError in the Error object indicates: SKErrorPaymentCancelled which was true but also happened days ago.
I get this regardless of if the device is connected to the internet or not (even if wifi is off). It appears to have cached the fact that the transaction was cancelled someplace and is stuck. Nothing clears it that I have tried including:
Creating a new test user and deleting the old one.
Deleting the App and re-installing.
Deleting the test products that generate this.
Clean and re-build the project including build folder.
Resetting the device and all the other voodoo.
Any ideas what is going on here? How does one clear what is cached? It doesn't appear that I am required to acknowledge that fact to the store in anyway. Furthermore, what I find really odd is that I get these SKPaymentTransaction notifications at launch, EVEN if the device is offline?!
SOLUTION: Well the App Store was caching something on the device and the only solution was to re-install iOS 9 and to NOT restore from a previous backup. Cleaning the project and the build folder did not help, neither did deleting the App from the device or any of the places that iTunes stores it and then re-installing the production App.

Testing In App Purchases - Cannot Connect to iTunes Store

I'm returning to some code I wrote in 2012. Back then, I had created a wrapper for the StoreKit framework that also did receipt validation using the sandbox URL for iTunes.
Since it's been so long, I looked through the StoreKit docs and AFAIK, nothing's changed.
For some reason, I can't test my In App Purchases anymore because I get the above error (Cannot Connect to iTunes Store) and the sandbox servers seem to be down (http://sandbox.itunes.apple.com/).
It's been down for the past 2 days. Is this normal? Or has the process for testing changed since when I first wrote this code?
In most of the cases like this, if you test it out in simulator (iOS 6/7/8) - you will get more about the error using [error localizedDescription].
The reasons can be numerous - most of the time it is caused by nonsandbox user. But it can be caused by reasons like app ID not matching that on itunes connect server too.

In-App-Purchase invalid product id only on release version

I released a new version of an app yesterday which added in app purchases. We did testing with a test account in sandboxed mode and everything worked correctly, however once we download the app from the app store the SKProductsRequestDelegate method:
(void)productsRequest:(SKProductsRequest *)request didReceiveResponse:(SKProductsResponse *)response
returns invalid product id's instead of valid ones. I'm baffled because I've had these types of problems before but only when trying to get them to work in debug mode, never after the app has been released from the app store. I've double checked everything on the list here http://troybrant.net/blog/2010/01/invalid-product-ids/ and none of those are the problem.
Here's another thread which is exactly my problem but no solution here: iOS In App Purchase - "Invalid Product ID" in release, NOT development version
I also encounter this problem and after 22 hours the problem be fixed automated. So I think this is the app store's problem that apple need some time to add your iap ID in their server.
It turns out in app purchases are magic. At around 8 pm we noticed that things started working normally. We had previously filed a request for help from Apple but never received a response so I'm not sure if that's what kicked off the fix or if it was just one of those things we needed to wait on.
I am also suffering with this issue and I went to Apple Developer Forum to get the solution. The problem is might be with Review team's device or environment.
Here is the link of full thread: https://devforums.apple.com/thread/233371

Resources