Handling Subscription Status Updates with Apple Notification V2

Question

Created Jul ’24

Replies 1

Boosts 0

Participants 2

We are using Apple Notification V2 and supporting only one subscription service per user (e.g., Netflix with Basic, Premium plans). In Notification V1, we could fetch the latest subscription information using the /verifyReceipt API. However, the documentation for Notification V2 suggests using SignedDataVerifier to decode the data locally.

This raises a concern that the data received via notification might not always be up-to-date. For example, if a user cancels a subscription but the server fails to process the notification for some reason, and later the user upgrades and resumes the subscription, the new notification succeeds. In this scenario, the previously failed cancellation notification will be resent after some time. How should the backend server handle this?

Should we always use APIs like get all subscription statuses to fetch the latest data instead of solely relying on the decoded data from each notification?

Boost

Answer 1

App Store Commerce Engineer OP

Apple

Jul ’24

@hoomin As you mentioned, we do not recommend calling the App Store Server API in response to the notification. The notification is basically a snapshot of the latest status of a transaction. Now as you said, notifications may come out of order due to one notification being a retry, and the other not. In this case, use the signedDate field of the notification to determine when the notification was created. For a retry, say 1 hour after the initial creation, the signedDate will therefore be 1 hour in the past. If you receive notification A and later notification B for the same transaction but B has a signedDate earlier than A, you would know that A was the most recent status for the subscription. You still might to know the information, but could then accurately slot it into the timeline for what is happening for the subscription or purchase. Does this answer your question?

0