Developer payload (external data) in server notifications

You will need to have the app send information, regarding the original purchase, from the user's device to your server. That information could be the entire original receipt or just the originalTransactionIdentifier. You can use the OriginalTransactionIdentifier field in the notifications to align the notification with the user. Alternatively, your server can use the original receipt to obtain from the Apple servers the latest_receipt_information.

I thought about using "Original Transaction Identifier" as a link between user and receipt. Now let's see where this approach leads to:

1. I need to implement additional logic inside at least two different applications (for iOS and macOS). This logic assume sending initial buy request with internal user id to our server.
2. I need to implement additional server-side feature for setting transaction_id for specific user. This normally should calls only once at initial buy (and may be in some other cases).
3. I need to implement protection against multiple uses of same receipt with diffrent user accounts. Obviously I should check if provided transaction_id is not already linked with any other user .
4. I need to implement appropriate server notifications callback, which will find user by transaction_id field and will update account data.

And here is some problems which I see right now:

1. Before initial buy there is no link between user account and receipt data - it means that server callback can fire before application callback. In that case server callback will do nothing, because it will not able to find user account without transaction_id. How should I avoid that?
2. Accoding to docs, server notifications will not fire for normal subscription renewal (only if it was expired). That means server should check subscription state every time when it is near expiration date by sending receipt to App Store API, right?

Thanks for the idea, but I consider this scheme as inadequate complexity for subscriptions architecture.

And yet so many other developers have managed to do what you find too complex.

In it's simplest form, the user's app drives the subscription by pushing the receipt to your server. Your server keeps track of the expiration date for the subscription. If your server thinks the subscription has expired it sends the receipt to Apple's servers to receive the latest_receipt_info and it updates the expiration date. Any user who wants to interact with other devices does that through your server using their username/password on your server. Drop the notification fetish - it only adds 'cancellation date' protection.

> consider this scheme as inadequate complexity

You may have a point. Have you considered a device check layer, instead (note obj-c centric...)?

As well, be sure to confirm your process via the IAP FAQ:

https://developer.apple.com/library/archive/technotes/tn2413/_index.html

Good luck.

Thanks for explanation. So it seems to be server notifications is almost totally useless and developers have to push/poll subscription info manually. How is that possible? I mean Apple is a trillion dollar company without normal product subscription scheme?

You can use the notifications if you wish. They work quite well but are a bit more complicated because they involve an extra 'source' of informatyion. They are described here: https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Subscriptions.html#//apple_ref/doc/uid/TP40008267-CH7-SW6

But you were complaining about complexity so I made it simple.

Notifications add one feature that the receipt does not - an immediate notification of a cancellation. They are very rare but many developers worry about them.

It seems that you can use appAccountToken when create purchase:

• appAccountToken
• create purchase
• server notification

I had the same problem because i've started the implementation of Web+Ios+Android recurring subscriptions with Stripe, and it permits to add extra/optional fields in the purchase phase. For solve this problem in a standard way, you should manage the first purchase-phase in a syncronous way instead of server-server, calling your backend API after you receive the purchase response from apple/google/stripe and store in your backend the original transaction id + extra fields (for example in a DB table). In this way, when you manage subscription renewals with your webhooks using server-server communication, you can extract the original-transaction-id from the notification and query your db table that contain the association between the original transaction id and extra fields that you need to manage the specific services. Hope it will help someone