I have implemented in app purchase in my iPhone application.
But first time while buying product during payment transaction phase I get an error:
cannot connect to iTunes store and it results in unsuccessful payment transaction.
Main thing is that it is occurring randomly means in subsequent attempts transaction gets completed successfully and again after 2 or 3 transactions it gives me the same error.
Weird behaviour?
I have tried all online available solutions like resetting, "Log out" from iTune account and creating new test user account but none is working.
I am trying to solve this problem since last three days(was waiting if problem is from iTune server) but no luck at all.
Before this I have successfully submitted no. of apps having in app purchase. Facing this issue first time.
Please do suggest some solution.
Thanks
In my case the error was because of "TimeOutInterval:".
In my In app purchase implementation workflow, in between there was a call to our local server to make entry of subscription in database.
Later I found, because of slow server I was getting late response from server resulting into "requestTimeout".
To solve this problem I increased the timeoutInterval while making request to server. And It worked for me.
Related
I have a user who is getting this error when they try to start a subscription (auto-renewing with free trial for one week) of my app. I have existing subscribers and this is the first I've heard of it so I don't (think) that it's widespread, but would possibly could be causing it on this users end? They tried to make the purchase several times in different WIFI/Cellular environments? There are older posts on this issue but they are primarily when testing IAPs in the sandbox (as opposed to production) and have no clear answer or cause.
That is the error code for payment cancelled, but I've also seen it occur for users when trying to buy a subscription that they already have access to.
Have the user check if they are already subscribed (here's the manage subscription url)
See if they are able to restore purchases within your app to get access to subscription
I have implemented IAP in my app. It consist of 3 plans(monthly, semi annual, yearly) in 1 group and same level. Its working fine in sandbox for first time purchase. But if am trying to change the plan it will show the confirmation alerts then the transaction will fail with "Cannot connect to iTunes store" error(But in store that purchase will be in success mode. If we try it again then we will get the receipt).
Noticed so many questions on the same error but ma case is plan switching. Can anyone confirm it occurs in only sandbox mode or not?.
I have removed the real accounts from settings, restarted the test device, rechecked with multiple test accounts. Couldn't find the solution.
Finally i have solved this case with a workaround. Even if we got the error or not the receipt will be available, try to validate the receipt. If the subscription plan changed it will get in receipt validation. Don't need to consider the "buyProduct" failed state. No need to display the error just we can try receipt validation if that also failed then the purchase is not done actually.
I am using the InAppBillingPlugn https://jamesmontemagno.github.io/InAppBillingPlugin/PurchaseSubscription.html
I have cut and pasted the code for the subscription part from the above link and replaced my in app purchases info in the applicable places,etc.
The app is released in the app store and if there are any exceptions running the subscription code I log it to my database and I also log successful purchases to my database.
I am seeing over 95% of the entries are exceptions with the following exception 'Cannot connect to itunes store', while ~5% of the subscriptions succeed.
Does anybody know why the failure rate is so high? I don't know if it is an issue with the inappbilling, Apple, or the users?
Initially I thought it could be a localization issue, but I don't think that is it. I have a question to apple support but haven't heard back from them yet.
I have also read other threads with this same type of error, but it was usually around testing or the subscription wasn't setup. I have verified the subscription works there just seems to be a very high failure rate with users.
Thanks in advance for any help
I've set up a test user in iTunes Connect and have signed out of the App Store on my device but when I go to query the in app purchases for my app I'm getting a 503.
Additionally, the site at http://sandbox.itunes.apple.com/ says the service is unavailable (and has been so for nearly 24 hours). Is this normal or does it make IAP integration impossible until the service comes back?
It seems that its merely a matter of playing the waiting game for either:
The IAP product or
The test user
to fully register on iTunes Connect.
I made no changes and it's working fine now even though http://sandbox.itunes.apple.com/ still returns a 503.
I am working with auto-renewable subscriptions. When the app has successfully finished a transaction, it sends the receipt to our server to validate it and to check that the last transaction identifier exists in the receipt.
From time to time, our server returns an error saying that the transaction identifier is not found in the receipt. I have confirmed that locally, in the app. Even after refreshing the receipt, sometimes the transaction identifier can't be found.
Also, the purchase has succeeded because trying to buy again the same subscription prompts an iOS pop up saying that the subscription is currently active.
Obviously this strange behaviour is happening in the sandbox environment. Also note, that I am using up to 3 test users switching back and forth between them.
Has anyone experienced a similar problem?
Any ideas about what is going on?
For the last 2 days I've been testing our code with one single iTunes test user, and I haven't come across that problem anymore. Not even once.
I am almost sure the problem is caused by switching between iTunes test users in the sandbox environment. Somehow, in that scenario, the app receipt is not always consistent.
No way to prove it though :(