1

I'm creating an iOS app with an auto-renewal subscription. I've been reading a lot of tutorials and documentation but I'm a bit confused about how to handle certain scenarios.

Here's how my app works:

  1. User installs app
  2. User creates account within signup flow
  3. User is asked to select a plan and pay within signup flow
  4. The payment receipt is uploaded to my server and I activate their account in my database.
  5. My server polls the /verifyReceipt endpoint on regular basis to renew the user's account or deactivate it depending on what the latest info from apple. (or use Apple's new Status Update Notification, both serve the same purpose to get me the latest subscription info on my server)

After a month when the subscription renews I know a transaction will appear on the SKPaymentQueue on the user's device. Because of this a lot of tutorials/documentation recommend having your AppDelegate implement the SKPaymentTransactionObserver protocol so that you can handle a transaction at any time.

But, I didn't use AppDelegate. I used the view controller in signup where the user picks their plans to implement SKPaymentTransactionObserver.

My reasoning is that since I'm getting info on the backend do I need to care about the transactions that will show up in the queue in the client each month when the subscription renews? Can't I just ignore these transactions, or will I need to call queue.finishTransaction on them?

I also read some things about restoring transactions when the user deletes the app and re-installs or gets a new phone. Again, do I need to worry about this? Because I should still know about the subscription on the backend and all the user has to do when they get a new phone is log in to their account for my service and it'll check the backend to see if their subscription is active.

I guess my larger question is: When you have a backend to handle IAP auto-renewal subscriptions, can you ignore some of the stuff happening on the client with the payment queue because that feature was built for apps that don't have a backend.

Adam Langsner
  • 1,276
  • 1
  • 15
  • 23
  • If you don't complete those transactions on the device, they will just sit there in the queue. They will be presented the next time you create a queue observer and you will need to deal with them, even if it is just to mark them finished. If you call `verifyReceipt` then you need to pass it a receipt to verify; this can only be obtained from the device. The verifyReceipt endpoint does not have the same functionality as the status update notification. – Paulw11 Feb 26 '19 at 21:53
  • You could rely on status update notifications, but what if your server is down or there is a network problem and the notification isn't delivered? The transaction delivered to the device is the most reliable way of receiving renewal notifications. Handling things on your backend is optional/supplementary. Some processing of the transactions on the device is mandatory. – Paulw11 Feb 26 '19 at 21:57

1 Answers1

2

It's best practice to implement the observer immediately in the AppDelegate in case something goes wrong between the user being charged by Apple and you upgrading their account - if they close the app or it crashes you may lose that transaction.

Also, I think I've had cases where I forgot to call finishTransaction and that annoying iTunes login prompt kept popping up, not sure if that was a Sandbox only event though.

Like @Paulw11 said. Don't rely on the Status Notifications. At time of writing, they don't provide enough info to update a user's status, namely any sort of user identifier. Refreshing receipts from the backend is the way to go. If a new receipt is posted to the SKPaymentQueue (say on a renewal), you can handle it like any other receipt refresh for the user on your server.

Here's a good blog post that provides more detail on what should be happening exactly on the server: iOS Subscriptions are Hard

For your restore logic, you don't need to use the StoreKit restore method if you've implemented your own restore functionality through an account based system. If that's the route you want to go, you should definitely listen to SKPaymentQueue in the AppDelegate to avoid as many edge cases as possible where you could lose track of someone's subscription status. The good 'ol "Restore Purchases" button is a great way to fix some slightly flawed in-app purchase code :)

I guess my larger question is: When you have a backend to handle IAP auto-renewal subscriptions, can you ignore some of the stuff happening on the client with the payment queue because that feature was built for apps that don't have a backend.

Don't ignore the payment queue. You can ignore the "Restore Transactions" if you have your own account based restore system.

enc_life
  • 4,973
  • 1
  • 15
  • 27