I am trying to test my in app purchases using a test account. The first time I try to purchase an in app auto renewable subscription, everything goes smooth, no errors and the transaction is complete as expected with the transaction state updated to "SKPaymentTransactionStatePurchased". But, when I test for the scenario of a user trying to purchase the subscription again, I keep getting the above error. Even though the store kit framework displays a dialog saying that the user is already subscribed, my observer sees the transaction as failed in the state(SKPaymentTransactionStateFailed).
The storekit documentation clearly says
"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".
In my case here, I keep getting the transaction state as "failed" when I do the purchase again.
Any ideas? This is in the sandbox test environment.
This is the expected behavior. You still receive a transaction, it just marks it in a failed state because it does not represent a new, successful purchase. Repurchasing a subscription they already subscribe to (presumably to restore a purchase after a fresh install) is not a journey you should encourage your users to take, they should be directed towards the restore purchases function.
Arguably you might want to interrogate your failed purchases every time to see if this is what the user was trying to do, but then you'd have to do a fair amount of messing around to try and distinguish which ones were genuine failures and which one's were erroneous restores. but I'd say it's much easier to have a big 'restore' button and direct people towards that.
If you log out from the app store application, it seems to be working when you purchase again. But problem continues if your user try to purchase the same product twice.
I was getting this when the Sandbox servers were down and/or broken. Check on Apple's developer forum to see if anyone else is getting the same thing.
[Developer Login Required]
http://devforums.apple.com/community/ios/integration/storekit
Related
I am integrating iPhone app with PayPal. I am transferring money from one account to other.
For now i am testing it in sandbox mode. When i transfer from account1 to account2 and even i don't have sufficient money in account1. I thought it would give me error something like "No sufficient balance", But it doesn't . It completes transection.
what would happen in this type of scenarios when my app will go live?
I have also face the same problem a month ago.You are right it completes the transaction without any error.But one thing you have to notice that
account amount in which you are transferring the money.You have no
change/effect on that.
When your app go online ,it will show the error or notification
That was done in my case.Just i put my app online.
We are three guys, who have made a free game for iPhone, which has been available on the App Store for almost a year.
The app is a board game, where you create a user or login using your Facebook credentials. You are able to log out of the game and log back in with another account.
Now we have updated the app with the ability to upgrade the user to a premium user. Allowing personal and global game statistics.
But Apple is giving us a headache in the approval process, and refuses to accept our In-App Purchase. First they would not approve it, as it had no restore button. Then when we told them, a restore button was not required, as it was a consumable purchase, they now demand we change it to a non-consumable and add the restore button.
Consider this scenario if purchase was non-consumable.
User logs in.
User upgrades account to premium
User logs out.
User logs in with a different account.
User restores the previous purchase.
This would allow you to upgrade two accounts to premium, but with just one purchase.
Apple's argument is, that our users need to be able to restore purchases, if a new device is setup, or a device is restored.
But that is not the way it works. Users upgrade their accounts to premium accounts. Now when they buy a new device or restores an existing device, they just log in with their existing game account, and the upgrade will be available, because we on the server-side has marked the account as a premium account.
So my question is basically. Were we totally wrong, when we choose to use a consumable instead of a non-consumable. And if so, how should a non-consumable be implemented in order to be (potentially) purchased more than once with different game accounts on the same device?
And secondly, if we are correct about the usage of a consumable in-app purchase, what should we say to convince Apple, that we are on the right path?
If your premium account is something that your users have to buy only once then Apple is definitely right to ask you to switch to non-consumable in-app.
The scenario you described is quite possible (i had to face it too) but if you add server-side verification of in-app receipts before unlocking the premium feature (saving all transactions associated to a user) you have the chance to verify that the purchase is new or restored checking the fields original_transaction_id and original_purchase_date in the receipt data. This way you can see if the user restoring the purchase is the same that originally bought it (maybe checking its facebook user id).
Anyway, experience showed me that the chance of this happening is not really high and i wouldn't recommend implementing this check (although server side validation is almost always a must ;-) )
According to the 'Restoring Transactions' section of the In-App Purchase Programming Guide:
If your application supports product types that must be restorable, you must include an interface that allows users to restore these purchases.
If your app contains non-consumable purchase, and if you don't include a restore button apple will not approve your app.
This has been made necessary by apple after June 2012.
So to answer your question: No, it seems that you must use restoreCompletedTransactions.
Hope it helps you.
I'm currently implementing a non-renewable in-app purchase and am a little concerned over the following scenario (or variation thereof):
User purchases my non-renewing in-app purchase. I save the receipt to NSUserDefaults, but before I have sent it to my own server for verification (and account functionality activation) the user loses signal/my server is down and in the meantime breaks their device/uninstalls my app (thus erasing the stored NSUserDefaults).
As far as I can tell you cannot restore a non-renewable purchase as with other types of IAP, so the user has lost the money they spent on that purchase as there is no way for me to know that it was ever made.
Am I missing something here, or am I to assume the above scenario is unlikely enough that I needn't worry about it?
Thanks
Ok, after some further reading it appears that the solution is to not call finishTransaction on the SKPaymentTransaction until I have had confirmation from my server. This way, the transaction should remain in the transaction queue across devices/installations until I have registered it within my own system.
I am selling apps via In-App within my App, currently what I am doing is, when anyone has already purchased the In-App item, then at the time of update it ask for purchase it again, it doesn't charge any money but it asks each time for log in and password, Is any way to skip this log in progress, I want it should be updated without asking for purchase and log in password.
You'll have to cache the user's purchase history on disk somehow in order to prevent this from happening, otherwise you'll have to ask the user to authenticate with Apple at least once (through running a transaction restore or by re-purchasing your products).
I was looking to this thread.
It's stated that the App Store calls the paymentQueue and posts a transaction with transaction.transactionState==SKPaymentTransactionStateRestored.
But I'm not getting those calls. I'm testing
with sandbox accounts/subscriptions, that expire and are auto-renewed every 3 minutes;
WITHOUT verifying receipts.
This way, my updatedTransaction method is never called after the first buy.
Anyway, if I later on restore completed transactions, I get all the receipts.
Any experience with sandbox? Also, the point 2) is needed or (as I think) it's optional?
The state: SKPaymentTransactionStateRestored is only determined if you have the receipt on the user's device and you use it to make the transaction. If you do not have the receipt, then you will need to call restoreCompletedTransactions to decide whether to apply the auto-renewed subscription.
The situation when you won't have a receipt is when the user buys an auto-renewable subscription, then deletes the app or installs the app on a different device. In other cases, you can safely store the receipt on the device.
The issue is detecting the case when the user has purchased an auto-renewing subscription and needs to have the content activated. Without a receipt, if you trigger the transaction, it will fail with the state SKPaymentTransactionStateFailed. Looking at the error code, you will see SKErrorPaymentCancelled. This, as far as I can tell, is a bug on Apple's part. You will need to make the best decision for your app to deal with it :/