Hey there! We've started to receive duplicated notifications though we responded with 200 HTTP Status Code. AFAIK there's no way to uniquely identify notification from its properties. We decided to get a hash of the notification body and use this value as a unique ID. However, unified_receipt.latest_receipt_info seems to be different. Moreover, seems like this is not a valid base64 value. Could you please help with the issue?

When calling the SKPaymentQueue.default().presentCodeRedemptionSheet() method on live appstore app it will present redemption sheet and after entering the promo code in it is displaying 'Cannot connect' screen as seen in attached picture and this is after entering the offer code. instead of showing me code benefits associated with subscription plan it is displaying 'Cannot connect' screen . What could be the reason for this and what solutions can be found to solve the problem? please some one help it is really frustrating. https://i.ibb.co/BChSQgq/IMG-52-EDEB1596-F8-1.jpg

I have been trying to use several open source libraries to verify the JWS in the signedPayload I have tried auth0, jose4j, jsonwebtoken and have even tried raw java signature validation. None work on the tokens getting sent from the sandbox If i create the JWT locally using the private/public configured for my account. I can verify with ALL of the different methods. I am not getting any wrong algorithm or invalid key issues... its just saying the signature fails validation. Does anyone have this running in Java that can share some tips?? -john

Steps to replicate User purchases an auto renewable subscription User decides to cancel subscription User wants to repurchase the subscription **What I expected to happen: ** When repurchasing the autorenewable subscription, go through the same process as the first purchase. **What actually happened: ** Purchasing the autorenewable subscription again restores the transaction. This also doesn't receive anything from the App Store Server Notification.

HI. After changing notifications v2 We received "REFUND_DECLINED" notifications But, we didn't do anything about refund. Also, we didn't send consumption information. Below is description of "REFUND_DECLINED" REFUND_DECLINED Indicates that the App Store declined a refund request initiated by the app developer. Can I know when we are getting this notification?

We are preparing "send consumption information". However, there are many items and it is difficult to organize. What are the important factors influencing the refund decision? I'd like to know more about how it works.

Are there any libraries or specifications to generate Java code for this API? I can only see the html documentation on the site. Is there an actual spec?

I'm implementing the v2 server notifications, according to responsebodyv2 documentation , "The signedPayload is a string of three Base64 URL-encoded components, separated by a period.", however in all the notifications I got, there's a datetime value, which includes a dot, for example: "GRlRRWFJKUl2022-08-25T07:01:44.031817718Z", which brings the number of periods from expected 2 - to 3, and the number of expected string chunks to 4 instead of 3, can you please let me know what is the best practice recommended in this case? Do you search for a date time pattern and remove it before processing, or merge 2 chunks into 1, or I'm getting some not-normal notifications?

Is there a way to track this and where can I view it?

We have enabled Billing Grace Period in one of our subscription apps. It has been almost a month since we have enabled the feature but we are still not seeing any users in Billing Retry State with grace_period_expires_date fields in the Pending Renewal Info. How long after enabling this feature in App Store Connect should we begin to see users in Billing Retry state with grace period information? Thanks!

I'm trying to ascertain if either the "webOrderLineItemId" or "transactionId" in the notification type v2 webhooks stay the same for the life cycle of each renewal. Ie: The auto-renewing subscription attempt is made and billing fails, additional attempts are made until payment succeeds. Until payment succeeds or subscription is cancelled do either of these attributes stay the same? Another question, I may be misunderstanding the "webOrderLineItemId", does this represent a successful renewal?

Whenever subscription changes apple sends the notifcation to our server using jws token. In the jws token we see the header has "alg":"ES256" but when we do signature verification, the validation failed by throwing below error

Getting error message when sending test notification request. Sandbox notification is configured properly. I have tried to delete and add it again, tried with both v1 and v2. Getting same message anyways. When I do same request to production API URL it works fine. I can also get notifications history for sandbox but obviously it is empty: {"notificationHistory"=>[], "hasMore"=>false}

Hi Team, We are trying to connect with our .pem file to apple, for testing pushnotification and here our UseCase Send - Connection Send -> Block a few minutes later Send -> Connection Send -> Block where Block = connection refused, so it failed to even "connect" to apple We also notice that the DNS resolved to many different IP addresses. Some work, some block some IP addresses send us reset packets which means we get connection refused and some complete the TCP handshake and work. When is the old SSL push notification supported up to before we have to swap to HTTP2? we are trying to work out IF this is still supported? any help would be appreciated Thanks in advance.

In Auto-renewable subscriptions Auto-renewals fail due to credit card errors, expiration, etc. When Apple is retrying for 60 days, what does the What does the Subscriptions screen in the Settings app show? If you have not updated your credit card error Will I be able to re-purchase a subscription or purchase another subscription from the Settings app? Will the Settings app not show a list of subscriptions that can be re-purchased or another subscription purchased? *I am assuming no grace period. When you renew your credit card, your subscription will be renewed immediately and you will receive the following notification on the server Is the following notified to the server? notification_type: DID_RENEW subtype: BILLING_RECOVERYnotification_type

We have non-renewing and consumables items that we're selling on our app. When an in-app purchase completes successfully, does apple trigger any notification to the server? Because it's not working in our case. We've added server notification URL for both sandbox and live, but when an in-app purchases happens the provided URL is not hit. Are there any webhooks or events I can listen to to update server state when an in-app purchase happens? Thank you.

I have configured my app and my servers correctly as documented to receive S2S notifications for Sign-In With Apple and yet, I am not receiving any notification at all. Of course I have verified that the endpoints are reachable. I have noticed a similar issue with S2S notifications for subscriptions, which made me introduce a hack in my environment that allows TLS 1.2 for that, although I can see that Apple clients negotiate TLS 1.3 occasionally (really weird). Has anyone faced a similar issue and found a solution other than to revert to TLS 1.2? For me, these S2S notifications are the only clients to my servers that would need this. As a side note: it would be really helpful in troubleshooting to see some form of feedback in the developer account for the notification endpoint configuration (e.g. if there was an error registered by Apple and if so, which one). Without it, we're completely blind and don't know anything. Other providers with such a remote integration provide feedback or at least have a "test" option that can be used for verification and/or troubleshooting. IDK why Apple is so closed up here, really.

The notification webhook is marketed as a way to get server-side updates on changes to in-app subscriptions. In the normal case, you can use that information to know the current state of a subscription. However, the retry system means that a notification may come up to 72hrs after the actual state change occurred and that also means that notification may be out-dated (another state change occurred between the time it was intended to be sent and the time it actually got successfully sent). How are we supposed to ensure that a received notification is the current state of a subscription? Can we used the signedDate to determine the order of notifications? (ie. when a notification fails to be sent and is resent, is the signedDate not altered so it can be used to order the notifications?) Or do we need to always make a request to the /inApps/v1/subscriptions/ endpoint to get the latest state and not rely on the contents of the notification?