Notifications missing signedTransactionInfo

We have started seeing v2 notifications coming in - various types/subtypes - that contain a signedRenewalInfo JWT, but no signedTransactionInfo JWT. This is new, we haven't seen it before. What's happening, what do we do with these? Is this a bug or has there been a change to the spec? There is no expire date and other information that is needed to properly process subscription updates.

According to your documentation, this is not supposed to happen: https://developer.apple.com/documentation/appstoreservernotifications/data

Our code is written to expect the data structure described in the documentation, and has worked fine for a long time, but this is now causing errors; please advise us on what we are expected to do here.

Post not yet marked as solved Up vote post of pnicoFP Down vote post of pnicoFP
979 views
Posted by
pnicoFP
Reply
Add a Comment

Replies

Since last few days we also noticed increase of notifications that do not have signedTransactionInfo set. It is mostly for events "DID_RENEW" and "DID_CHANGE_RENEWAL_STATUS".

Posted by
keko003
Up vote reply of keko003 Down vote reply of keko003
Add a Comment

same here. Started on Jan 04 2023

Posted by
igorborovica
Up vote reply of igorborovica Down vote reply of igorborovica
Add a Comment

Same here, first odd error in DID_RENEW event, after investigation found out that signedTransactionInfo was missing from the notification.

Posted by
Iloac
Up vote reply of Iloac Down vote reply of Iloac
Add a Comment

When I fetch the notification history, it's also missing there. We can refetch the data to get some of the missing details such as expire date - in fact we are usually doing this anyway, which is probably an abuse of the appstore server API - but our code is expecting the documented format, and we had always planned to get rid of the re-fetch step, and we keep logs of the other details in the transaction info so it's still not ideal.

Posted by
pnicoFP
Up vote reply of pnicoFP Down vote reply of pnicoFP

  • Yes, the history repeats the notification payload as it naturally should. This means that Apple should actually re-issue the notifications with invalid payload. Not holding my breath for that. Without that I think the only way to return to stabile operations for the purchases affected is to implement the API workaround you describe.

    —
    Iloac
Add a Comment

Just now noticed there was a previous thread about this, apologies https://developer.apple.com/forums/thread/718661

Edit: from the data they attached, this could be a different issue actually although it's similar.

I created a ticket in feedback assistant: FB11938220

Posted by
pnicoFP
Up vote reply of pnicoFP Down vote reply of pnicoFP
Add a Comment