App Store Server Notifications V2 always retries five times

Question

kyoboit OP

Created May ’24

Replies 3

Boosts 0

Views 1k

Participants 2

Hi, Our app that implemented in-app payment has been reviewed and passed and is currently in operation.

However, there is a problem with the App Store server notification V2.

According to the url <https://developer.apple.com/documentation/appstoreservernotifications/responding_to_app_store_server_notifications>, it is written as follows.

"When you set up the endpoints on your server to receive notifications, configure your server to send a response. Use HTTP status codes to indicate whether the App Store server notification post succeeded:

Send HTTP 200, or any HTTP code between 200 and 206, if the post was successful.

Send HTTP 50x or 40x to have the App Store retry the notification, if the post didn't succeed.

The system considers all other HTTP codes an unsuccessful post. Your server isn’t required to return a data value.

If the App Store server doesn’t receive a success response from your server after the initial notification attempt, it retries as follows:

For version 2 notifications, it retries five times, at 1, 12, 24, 48, and 72 hours after the previous attempt."

We are sending an HTTP status code to the Apple server by 200 or 40x or 50x when we receive an Apple notification from the server as per the document.

Nevertheless, Apple Server continues to send us 5 times App Store server notifications for each transaction.

I would appreciate it if you could share how we can do it. Also, we can provide the implementation code of our server through code-level support.

Thank you for your support.

Answered by App Store Commerce Engineer in 789022022

@kyoboit So retries always have the same notificationUUID (https://developer.apple.com/documentation/appstoreservernotifications/notificationuuid). Those CONSUMPTION_REQUEST notifications aren't going to have the same notificationUUID because those actually aren't retires. We will keep sending new CONSUMPTION_REQUEST notifications periodically over the open refund period until that refund is closed. This is a specific feature of the CONSUMPTION_REQUEST notification. You can also see this because they show up as separate entries in the Notification History endpoint (indicating they are different notifications).

Also, if you receive a retried notification that does have the same notificationUUID, we recommend to respond with 200 even if you believe it is a duplicate, because we may not have received, due to a timeout or similar, on the first. While your server is aware the first was successful, ours may not be, and if you respond with 500 on subsequent calls, we will just run through the full retry flow.

Boost

Answer 1

App Store Commerce Engineer OP

Apple

May ’24

Hello, question, what was is the failure reason shown in the Notification History endpoint of the App Store Server API? It should provide a general reason.

0

Answer 2

kyoboit OP

May ’24

Hi, here is the data as a result of calling api Notification History endpoint.

notificationhistory.json

First of all, when our server receives a notification for the first CONSUMPTION_REQUEST, it responds with 200. After that, if the same notification comes in, it is treated as a duplicate reception and responds with 500.

The initial CONSUMPTION_REQUEST notification attempt for a particular transactionid results in "sendAttemptResult": "SUCCESS."

And Apple try the same notification after we get the results, so the data comes like this "sendAttemptResult": "UNSUCCESSFUL_HTTP_RESPONSE_CODE"

May I know why Apple are retrying 5 times even though i received the notification data sent by Apple successfully?

Thank you for your reply.

0

Answer 3

App Store Commerce Engineer OP

Apple

May ’24

Accepted Answer

@kyoboit So retries always have the same notificationUUID (https://developer.apple.com/documentation/appstoreservernotifications/notificationuuid). Those CONSUMPTION_REQUEST notifications aren't going to have the same notificationUUID because those actually aren't retires. We will keep sending new CONSUMPTION_REQUEST notifications periodically over the open refund period until that refund is closed. This is a specific feature of the CONSUMPTION_REQUEST notification. You can also see this because they show up as separate entries in the Notification History endpoint (indicating they are different notifications).

Also, if you receive a retried notification that does have the same notificationUUID, we recommend to respond with 200 even if you believe it is a duplicate, because we may not have received, due to a timeout or similar, on the first. While your server is aware the first was successful, ours may not be, and if you respond with 500 on subsequent calls, we will just run through the full retry flow.

2