You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SubscriptionNotification ExpirationIntent field is currently marked as an int, unlike the corresponding receipt field, which is a string. The Apple documentation seems to match this at first, listing expiration_intent as an integer here: https://developer.apple.com/documentation/appstoreservernotifications/responsebodyv1, but upon clicking that link for more information, it indicates that it should be a string similar to the receipt. Furthermore, we have logged the raw json body we are getting from Apple in production, and it appears we are still receiving a string for this field in production (usually "", "1", or "2"). So we are unable to proceed with updating our version of go-iap with this ambiguity because we are unsure if this will introduce parsing errors.
It seems the numericString type may be able to handle this case, so would changing ExpirationIntent to that type be appropriate? (If so it may relate to #185)
The text was updated successfully, but these errors were encountered:
The SubscriptionNotification ExpirationIntent field is currently marked as an int, unlike the corresponding receipt field, which is a string. The Apple documentation seems to match this at first, listing expiration_intent as an integer here: https://developer.apple.com/documentation/appstoreservernotifications/responsebodyv1, but upon clicking that link for more information, it indicates that it should be a string similar to the receipt. Furthermore, we have logged the raw json body we are getting from Apple in production, and it appears we are still receiving a string for this field in production (usually "", "1", or "2"). So we are unable to proceed with updating our version of go-iap with this ambiguity because we are unsure if this will introduce parsing errors.
It seems the numericString type may be able to handle this case, so would changing ExpirationIntent to that type be appropriate? (If so it may relate to #185)
The text was updated successfully, but these errors were encountered: