CODEWITHSUNDEEP
iossubscription
ORStudios
ORStudios

Reputation: 3233

Apple Auto Renewable Subscriptions - Validating User Against Receipt

I am a little confused about the process involved in the validation of receipts from users who have subscribed to my app.

At the minute a user joins and then purchases the subscription, the receipt is then base64 encoded and sent to my server. At midnight each night the server sends off the receipt stored in my db to Apple to be validated and the expiry date updated.

Now i'm a bit confused about how a receipt is updated each month. Please take a look at the following flow and let me know if this is correct.

  1. The user registers and subscribes to my app.( Lets say January).
  2. The original receipt is sent to my server and then validated with Apple, the expiry date is returned and set on my server.
  3. A month later in February on the expiry date I send the original (January) receipt to Apple again to see if the subscription has been renewed and then I can set the new expiry date.

Is this flow correct? Because I am sending the original (January) receipt each month will it still contain the latest renewal information or do I somehow have to refresh the receipt each month when the user logs in or opens the app?

Upvotes: 2

Views: 342

Answers (1)

Jacob Eiting
Jacob Eiting

Reputation: 1004

Yes, your understanding is more or less correct. When a user's first renewal occurs a couple of things will happen:

  1. The next time the user launches the app, your SKPaymentQueue delegate will receive a new SKPaymentTransaction for the new transaction. You need to be ready to observe this transaction with your delegate and finish it. If you don't, transactions will just continue to pile up over the months.

  2. The verifyReceipt response received from Apple for the first receipt will update the latest_receipt_info key to include the most update version of the receipt data. latest_receipt_info will originally just be a copy of the receipt.in_app field, but after the first renewal it will contain the most up to date transactions. You should use these latest_receipt_info transactions to update the expiration date.

My suggested behavior is that when you receive the new SKPaymentTransaction you send it to your server anyway (although you technically don't need to) and you use it to verify and update the expiration date before finishing the transaction. You can overwrite the old receipt with the new one.

You can have a look at the RevenueCat iOS framework source code to see how I handle it. (You should also make sure you trigger a fetch receipt request if the receipt data is missing, which I do in the code.)

If you are interested in an out of the box solution, RevenueCat is a service I started to handle all these and many more edge cases automatically.

Upvotes: 3

Related Questions