Receipt Validation on iOS In-App-Purchase Returns Multiple Transaction

Receipt validation on iOS In-App-Purchase returns multiple transaction

I think you have implemented auto renewable in app purchase.
Your response is proper.

Why I am getting multiple transaction on same ID

As in your response transaction performed for auto renew product at every 5 minutes(Sandbox environment renew product in 5 minutes instead of 1 month in App Store).

Whether this response is correct or not

Yes

If it is correct, which ID to validate

You have to get all the transaction for your product id tfc.premium.subscription and then grab last object and use it as your latest/last transaction.

Read this Apple Document for proper understanding.

The behavior of auto-renewable subscriptions differs between the
testing environment and the production environment.

In the testing environment, subscription renewals happen at an
accelerated rate, and auto-renewable subscriptions renew a maximum of
six times per day. This enables you to test how your app handles a
subscription renewal, a subscription lapse, and a subscription history
that includes gaps. See Testing Auto-Renewable Subscriptions in the
In-App Purchase Configuration Guide for iTunes Connect to learn about
the subscription durations for testing.

Because of the accelerated expiration and renewal rates, a
subscription can expire before the system tries to renew the
subscription, leaving a small lapse in the subscription period. Such
lapses are also possible in production for a variety of reasons—make
sure your app handles them correctly.

When should i validate in-app purchase transaction receipt?

Scenario 2.
If the internet blows up, you won't get to -finishTransaction.
But that's cool, cause you can retry (NSTimer) and your app will be given the unfinished transaction on start up.
And that's exactly how StoreKit is designed to work (even though it's not obvious from reading the docs).

StoreKit comes with transactions, for a good reason. The user can simply quit the app right after purchasing, and you still have to recover from that.
And that's why Apple recommends to set your transaction observer as soon as possible in the app lifecycle.

Don't ever finish the transaction before providing the content, you'll have to implement your own transaction system on top of StoreKit, and you don't want to do that, believe me (I've seen it done, it was a disaster).

Edit: in all honesty, the eventually of a user turning the internet off after purchase and before you validate is ridiculously low. The guy was on they internet a second ago, nobody just goes out to cut the internet in the middle of a purchase.
But it's possible that the user gets interrupted at that the moment and send your app to the background.
Your app can then get killed for whatever reason iOS deems appropriate.
And when you're apps starts again, well your app won't remember having a purchase to start with, and store kit won't be of big help, since you've already finished the transaction.

Apple In-App Purchase and Receipt Refresh

After many tests and after I sent my app in production, I'm now able to answer my questions properly:

1. When a user restores their purchase, does the receipt get refreshed?

YES, this is immediate as for Sandbox, BUT the problem is that the receipt DOESN'T include non-consumable purchases.
This means in other words that the receipt will include the purchased subscriptions, but you won't find purchases of non-consumable products.
However, when the user restores or purchases, you get the transactions in return, and you can extract the non-consumable products, and store this info somewhere like UserDefaults or Keychain, so you can use them when the user opens your app.
For the rest, the best approach is to always validate and check the receipt when the app is opened.

2. Does the refresh receipt request trigger an alert asking for the Apple ID's password in production?

YES. For sure it does the first time.

Thank you to Daniel and enc for their answers that can still be useful.

---

Related Topics