To receive server notifications from the App Store, follow the instructions in Enabling App Store Server Notifications. If your server doesn’t receive any notifications, check your server logs for any incoming web request issues, and
confirm that your server supports the Transport Layer Security (TLS) 1.2 protocol or later. If you implement version 2 of App Store Server Notifications, call the Get Notification History endpoint. If there is an issue sending a notification, the endpoint returns the error the App Store received from your server.
If your issue persists, submit a Feedback Assistant report with the following information:
The bundleId or appAppleId of your app
The date and time your issue occurred
The raw HTTP body of your notification
The affected transactionId(s) if applicable
The version of App Store Server Notifications (i.e., Version 1 or Version 2)
The environment (i.e., Production or Sandbox)
To submit the report, perform these steps:
Log into Feedback Assistant.
Click on the Compose icon to create a new report.
Select the Developer Tools & Resources topic.
In the sheet that appears:
Enter a title for your report.
Select “App Store Server Notifications” from the “Which area are you seeing an issue with?” pop-up menu.
Select “Incorrect/Unexpected Behavior” from the “What type of feedback are you reporting?” pop-up menu.
Enter a description of your issue.
Add the information gathered above to the sheet.
Submit your report.
After filing your report, please respond in your existing Developer Forums post with the Feedback Assistant ID. Use your Feedback Assistant ID to check for updates or resolutions. For more information, see Understanding feedback status.
App Store Server Notifications
RSS for tagMonitor subscription events in real time with server notifications from the App Store using App Store Server Notifications.
Posts under App Store Server Notifications tag
84 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
Please allow me to confirm the Server Notifications V2 specification.
I am aware that if withdrawal an Apple account that has a subscription, the subscription will eventually be cancelled.
Regarding Server Notifications V2 notifications with a notificationType of EXPIRED, am I correct in thinking that they will be sent when the subscription expires even if the Apple account is withdrawal?
Hello,
We've integrated App Store Server Notifications V2 in our system. We are heavily relying on the ONE_TIME_CHARGE notification type to handle Consumable purchases, but this notification type is available only for Sandbox. And this is for a while now - starting with June 10th 2024 ( https://developer.apple.com/documentation/appstoreservernotifications/app-store-server-notifications-changelog#June-10-2024 ).
Can you please provide a timeline for when the ONE_TIME_CHARGE notification type will be available in Production ?
Thank you!
I've noticed that CONSUMPTION_REQUEST notifications sometimes have a signedTransactionInfo which corresponds not to the latest transaction, but to an earlier transaction in a subscription.
Is this expected? I thought signedTransactionInfo was always the latest subscription information?
Are there any other notification types for which signedTransactionInfo can be out of date?
Hello,
I would like to ask about how to handle subscription refund notifications.
Here’s what I’ve done.
Environment: Sandbox
Steps to reproduce
1.Subscribe.
2.Request a refund using beginRefundRequest.
3.Receives App store server notifications.
I expected to receive the EXPIRED notification immediately after receiving the REFUND notification, but I have confirmed that the EXPIRED notification is received on the renewal date.
We plan to restrict access to premium content when receiving the EXPIRED notification.
If a user starts an annual subscription in January and requests a refund after 3 months, will the EXPIRED notification be received in January of the following year?
If so, what is the optimal time to restrict access to premium content?
Additionally, is there a possibility of a partial refund?
Thank you in advance for your support!
https://developer.apple.com/documentation/appstoreservernotifications/app-store-server-notifications-changelog#June-10-2024
ONE_TIME_CHARGE notify type running in a sandbox environment for almost a year, the feature is not yet available for production environment.
The notification is already available in Google subscriptions.
Our services often miss orders because of the absence of this notification.
Can you give us an approximate time range?
Hi,
Regarding the announcement about the Apple Push Notification Service (APNs) Server Certificate Update, I wanted to clarify whether it will impact my app’s push notification setup.
I use Firebase Cloud Messaging (FCM) to send push notifications to iOS devices, and in my Firebase project settings, I have configured an APNs Authentication Key under the Apple app configuration tab (Firebase Console > Project Settings > Cloud Messaging > iOS app configuration).
The authentication key I am using was generated from Apple Developer > Certificates, Identifiers & Profiles > Keys.
Since I am using this authentication method instead of APNs certificates, are there any changes I need to be aware of due to the APNs server certificate update, and do I need to update anything in my current configuration to ensure push notifications continue to work?
Thanks in advance!
Inquire the types of notifications that can occur in a SANDBOX environment
Hello, WWDC 2024 is trying to conduct a test to receive notifications related to ONE_TIME_CHARGE, CONNSUMPTION_REQUEST, CONMSUMPTION_INFO, REFUND, and REFUND_DECLINED as described in the example of purchasing consumables, but as a result of the continuous search, I found that it is difficult to occur except for
ONE_TIME_CHARGE.
So, in order to verify only the business logic as shown below, we are testing only the business logic without actually calling the API after purchasing the test and saving the signaled Payload that we received in response to ONE_TIME_CHARGE. Can we actually request a refund for the test purchase and receive the corresponding notification and actually send the response?
public void handleSignedNotification(String signedNotification) throws Exception {
ResponseBodyV2DecodedPayload payload = signedDataVerifier.verifyAndDecodeNotification(signedNotification);
NotificationTypeV2 type = payload.getNotificationType();
//For Apple Server Notification, only ONE_TIME_CHARGE notifications are enabled in the test environment, so for testing, change them as below to test whether they are running business logic
type = NotificationTypeV2.REFUND;
log.info("Apple NotificationType : {}", type);
switch (type) {
case CONSUMPTION_REQUEST:
handleConsumptionRequest(payload);
break;
case REFUND:
handleRefund(payload);
break;
case REFUND_DECLINED:
handleRefundDeclined(payload);
break;
// For other necessary notifications, just take a log
default:
log.info("Unhandled notification: {}", type);
}
}
Regarding the call of 'CONSUMPTION_INFO', which is the response of 'CONSUMPTION_REQUEST'
Is there a value that WWDC 2024 must include when sending CONMSUMPTION_INFO, which is the response to CONNSUMPTION_REQUEST described in the refund example? I'm going to call the API with only sample provision and consumption like the sample code you introduced in the video.
I was told to submit my refund preference within 12 hours, but can I submit it as UNDECLARED at first and use the method to express my intention? When I receive the notification, I will save it in the DB and save it in the administrator page of the service so that the administrator can choose.
2-1. Some of the materials I looked for are told that Apple can proceed with the refund even 12 hours ago, and to express your opinion as soon as I receive the notification, but I wonder if this is correct.
If you get a notification as below, you should write whether you used it or not by referring to the consumption information. I think the customer said to check whether the data was provided when applying for a refund. Should I take it out of decodedTransaction, check the value, and just call it NO_PREFERENCE? I'd appreciate it if you could give me some advice.
Below is a part of the code I implemented.
private void handleConsumptionRequest(ResponseBodyV2DecodedPayload notification) throws Exception {
// 1. transaction ID get
String signedTransactionInfo = notification.getData().getSignedTransactionInfo();
JWSTransactionDecodedPayload decodedTransaction = signedDataVerifier.verifyAndDecodeTransaction(signedTransactionInfo);
String transactionId = decodedTransaction.getTransactionId();
// 2. Extract the relevant transaction (The following example is an in-app payment and will be accumulated in two types of DBs, stored in one of the two)
Sample sample = sampleService.findByAppleTransactionId(transactionId);
Example example = exampleService.findByAppleTransactionId(transactionId);
Boolean canRefund = false;
// 3. Check consumption information
if (sample != null) {
canRefund = checkSampleStatusForApplePurchaseRefund(sample);
} else if (example != null) {
canRefund = checkExampleStatusForApplePurchaseRefund(example);
}
// 4. Create Refund Preferences
RefundPreference refundPreference = determineRefundPreference(canRefund);
// 5. Creating a ConsumptionRequest Object
ConsumptionRequest request = new ConsumptionRequest()
.refundPreference(refundPreference)
.sampleContentProvided(true);
log.info("forTest~ canRefund: {}", canRefund);
log.info("forTest~ sample: {}", sample.toString());
log.info("forTest~ example: {}", example.toString());
log.info("forTest~ refundPreference: {}", refundPreference);
log.info("forTest~ request: {}", request);
// 6. Transfer to App Store (annotated with dummy requests that only confirm current business requests are going right)
// appStoreServerAPIClient.sendConsumptionData(transactionId, request);
}
App Store Server Notifications Not Working in Production Environment
Environment
App Bundle ID: com.fanmuay.app
Environment: Production
Implementation Date: 28/01/2025
Last Successful Sandbox Test: 29/01/2025
Issue Description
I'm experiencing issues with App Store Server Notifications in the production environment. The notifications work perfectly in sandbox, but they stop working completely after moving to production.
What Works
Server notifications are properly received in sandbox environment
All purchase events successfully trigger notifications in sandbox
Notification payload is correctly processed by our server in sandbox
What Doesn't Work
No notifications are being received from production environment
No error messages are being logged
Same implementation that works in sandbox yields no responses in production
Questions
Are there any additional configuration steps needed when moving from sandbox to production for server notifications?
Is there a different certificate or authentication process required for production notifications?
Is there a way to verify if our production endpoint is correctly registered?
Are there any common issues that could cause notifications to work in sandbox but fail silently in production?
Technical Details
Our server is properly configured to receive notifications and can successfully process them in the sandbox environment. The same exact setup is used for production, but we receive no responses. We've verified our server is running and accessible.
Any guidance or suggestions would be greatly appreciated. If you need any additional information, please let me know.
Thank you for your help!
I encountered a scenario involving a subscription and need to determine if it's a problem or an expected outcome. Here are the details:
My service received a notification from Apple of type DID_CHANGE_RENEWAL_STATUS with subtype AUTO_RENEW_DISABLED. The status field received on the payload was equal to 1 - Active. (2024-12-19T15:34:53.801)
My service again received a DID_CHANGE_RENEWAL_STATUS with subtype AUTO_RENEW_DISABLED. But the status field received was 2 - Expired. (2024-12-19T23:34:57.527)
My service received an EXPIRED with subtype VOLUNTARY notification. (2024-12-19T23:35:01.669)
Is the event 2 an inconsistent event? Since we are receiving a notification that means the auto renew was disabled when the subscription was already expired.
As part of ConsumptionRequest fields there's a bit of unclarity. In my case I am only concerned with subscriptions, as they give some premium features in the app.
The fields and the questions are the following:
playTime: is this the time used in the app in total or just the time the app has been used while using the subscription?
consumptionStatus: does this relate only to the user using the premium features he/she paid for? or the fact that the user had access to those features only?
Thanks!
Hello everyone,
I have some questions regarding the behavior of the offerIdentifier property in the TransactionPayload from App Store Server Notifications.
When a user redeems an Offer Code, the offerIdentifier field is populated with the respective identifier. However, I am unsure how this field behaves in different scenarios, and I would appreciate any insights or clarification:
Does the offerIdentifier persist throughout the subscription lifecycle (from the initial purchase to expiration)?
Does it become null once the Offer Code benefits expire?
Is it only present at the time of purchase and omitted in subsequent notifications?
Additionally, I would like to understand the behavior of the offerIdentifier in the following scenario:
A user purchases a lower-tier subscription using an Offer Code. Later, they upgrade to a higher-tier plan, causing the Offer Code benefits to effectively expire.
What happens to the offerIdentifier in the transaction for the upgrade?
Will it still appear in transactions after the upgrade, or will it be null?
I couldn't find explicit details about these situations in the official documentation, so I hope someone here might have experience or knowledge to share.
Thank you in advance for your help!
We integrated App Store Server notification, to get notified about CONSUMPTION_REQUESTS and REFUND notifications.
In the data, we noticed same transactionId have multiple REFUND decisions, usually REFUND_DECLINED and then REFUND. Why is that? Did user contact customer support ?
For the second (or later) REFUND decision, CONSUMPTION_REQUEST notifications are usually not sent, but thats not always the case. Sometimes, REFUND decision are the same. Sometimes, we get even 3 or more REFUND related notifications for same transactionId, e.g:
2024-12-02: REFUND_DECLINED
2024-12-05: REFUND_DECLINED
2024-12-12: REFUND
Do user request refund again ? Do they contact customer support ? But I can not explain why sometimes status it REFUND at first, but then later REFUND_DECLINED.
Thank you already in advance:)
Dear Apple Support,
We are currently in the process of migrating from Apple Server Notifications v1 to v2. As you know, once we switch from v1 to v2 in App Store Connect, this change is irreversible. Our team needs to ensure that our backend environment, developed in Python with Django and using the app-store-server-library==1.5.0, is fully prepared to handle all possible notification types before making that final switch.
While we can receive a basic test notification from Apple, it doesn’t provide the range of data or scenarios (e.g., INITIAL_BUY, RENEWAL, GRACE_PERIOD, etc.) that our code must be able to process, store in our database, and respond to accordingly. Without comprehensive, example-rich raw notification data, we are left guessing the structure and full scope of incoming v2 notifications.
Could you please provide us with a set of raw, fully representative notification payloads for every notification type supported in v2? With these examples, we can simulate the entire lifecycle of subscription events, verify our logic, and confidently complete our migration.
Thank you very much for your assistance.
I encountered a scenario involving a subscription and need to determine if it's a problem or an expected outcome. Here are the details:
My service received a notification from Apple of type DID_CHANGE_RENEWAL_STATUS with subtype AUTO_RENEW_DISABLED. The status field received on the payload was equal to 1 - Active. (2024-12-19T15:34:53.801)
My service again received a DID_CHANGE_RENEWAL_STATUS with subtype AUTO_RENEW_DISABLED. But the status field received was 2 - Expired. (2024-12-19T23:34:57.527)
My service received an EXPIRED with subtype VOLUNTARY notification. (2024-12-19T23:35:01.669)
Is the event 2 an inconsistent event? Since we are receiving a notification that means the auto renew was disabled when the subscription was already expired.
Hello everyone,
I recently received an email from Apple titled "Notification of Apple Developer Program License Agreement (“DPLA”) violation:" stating that I may have violated Section 11.2 (Termination) of the agreement. The specific clause mentioned relates to engaging in or encouraging misleading, fraudulent, improper, or dishonest acts, such as manipulating App Store rankings or reviews.
I’m unsure what triggered this notification as I have always adhered to Apple’s guidelines. Recently, I ran a promotional campaign for my app, where it was made temporarily free, leading to a significant spike in downloads. I suspect this may have raised a flag, but everything was done transparently and without intent to violate any rules.
I’ve reached out to Apple Support for clarification, but I wanted to ask here if anyone has experienced something similar or could provide insights into resolving this.
I value my membership in the Apple Developer Program and want to ensure everything is compliant. Any advice would be greatly appreciated!
This documentation describes what kind of data we should be sending to Apple server, once we are receiving CONSUMPTION_REQUEST
https://developer.apple.com/documentation/appstoreserverapi/consumptionrequest
But, it doesn't describe what kind of data we are receiving, when we are receiving CONSUMPTION_REQUEST?
May I know, is such a document available?
Thank you.
Apple In-App Purchase sandbox environment can receive App Store Server Notifications v2, but the production environment is not receiving any notifications. I have verified that the configured URL is correct and it appears that Apple is not pushing messages in the production environment. Is there anyone who knows how to troubleshoot this issue
The documentation mentions the following:
Verify your receipt first with the production URL; then verify with the sandbox URL if you receive a 21007 status code. This approach ensures you don’t have to switch between URLs while your app is in testing, in review by App Review, or live in the App Store.
This way, you can use one server environment to handle both Sandbox and Production environments. It is necessary to pass App Review.
However, I'm not manually hitting these URLs - I'm using Apple's libraries.
Specifically, the environment is used in SignedDataVerifier and AppStoreServerAPIClient.
(I can't link to these because, for some reason, the domain apple.github.io is not allowed. The documentation for these is only found there. You can find it quickly by searching these terms and the domain.)
Here is how SignedDataVerifier is being used:
const verifier = new SignedDataVerifier(
appleRootCertificates,
APPLE_ENABLE_ONLINE_CHECKS,
APPLE_ENVIRONMENT,
APPLE_BUNDLE_ID,
APPLE_APP_ID
)
const verifiedNotification: ResponseBodyV2DecodedPayload = await verifier.verifyAndDecodeNotification(signedPayload)
if (!verifiedNotification)
{
// Failure
return
}
Here is how AppStoreServerAPIClient is being used:
const appStoreServerAPIClient = new AppStoreServerAPIClient(
SIGNING_KEY,
APPLE_IAP_KEY_ID,
APPLE_IAP_ISSUER_ID,
APPLE_BUNDLE_ID,
APPLE_ENVIRONMENT
)
const statusResponse: StatusResponse = await appStoreServerAPIClient.getAllSubscriptionStatuses(originalTransactionId, [Status.ACTIVE])
In the source code for SignedDataVerifier.verifyAndDecodeNotification, I can see that it throws a VerificationException(VerificationStatus.INVALID_ENVIRONMENT) error .
So for SignedDataVerifier is it as simple as wrapping my code in a try/catch and checking that the error's status code is 21007? I'm unsure about this because if you scroll to the bottom of the linked source code file, you can see the enumeration VerificationStatus, but it's unclear if this member has a value of 21007.
The source code for AppStoreServerAPIClient only says that it throws an APIException if a response could not be processed, so I'm not too sure about how to handle this one.
i m integrate App Store Server Notifications for External Purchase Server API
The documentation says:
For external purchase tokens that are unreported after 10 days, Apple sends a server notification to your server
https://developer.apple.com/documentation/externalpurchaseserverapi#Receive-notifications-for-unreported-tokens
I have a doubt.
After I'm generating an external purchase token (sandbox), apple notify me 4 times in next 2-3h, even they say, they will notify me after 10 days for unreported tokens.
Mention: Response for notification call was 200
token_create: 13:18
notification_1: 13:58
notification_2: 14:38
notification_3: 15:08
notificaiton_4: 15:38
"notificationType": "EXTERNAL_PURCHASE_TOKEN",
"subtype": "UNREPORTED",
I have no clue what's happening