Post not yet marked as solved
I am facing this issue.
I create curl command with jwt token like this
import jwt from "jsonwebtoken"
import { readFileSync } from "fs"
import {bid, iss, kid, p8FilePath} from "./values.js"
const currentDate = Math.floor(new Date().getTime() / 1000);
const expiryDate = currentDate + (10 * 60);
const header = {
typ: "JWT",
alg: "ES256",
kid: kid,
};
const payload = {
iss: iss,
aud: "appstoreconnect-v1",
iat: currentDate,
exp: expiryDate,
bid: bid,
};
const privateKey = readFileSync(p8FilePath);
const token = jwt.sign(payload, privateKey, {
algorithm: "ES256",
header,
});
// curl command
console.log(`curl -v -H 'Authorization: Bearer ${token}' -X POST "https://api.storekit-sandbox.itunes.apple.com/inApps/v1/notifications/test"`)
and curl responds always
* Trying 17.36.202.8:443...
* Connected to api.storekit-sandbox.itunes.apple.com (17.36.202.8) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* ALPN: server accepted h2
* Server certificate:
* subject: businessCategory=Private Organization; jurisdictionCountryName=US; jurisdictionStateOrProvinceName=California; serialNumber=C0806592; C=US; ST=California; L=Cupertino; O=Apple Inc.; CN=api.storekit-sandbox.itunes.apple.com
* start date: Oct 17 19:50:08 2023 GMT
* expire date: Oct 16 20:00:08 2024 GMT
* subjectAltName: host "api.storekit-sandbox.itunes.apple.com" matched cert's "api.storekit-sandbox.itunes.apple.com"
* issuer: C=US; O=Apple Inc.; CN=Apple Public EV Server ECC CA 1 - G1
* SSL certificate verify ok.
* using HTTP/2
* h2 [:method: POST]
* h2 [:scheme: https]
* h2 [:authority: api.storekit-sandbox.itunes.apple.com]
* h2 [:path: /inApps/v1/notifications/test]
* h2 [user-agent: curl/8.1.2]
* h2 [accept: */*]
* h2 [authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ilc1QjVRNzJONUwifQ.eyJpc3MiOiI2OWE2ZGU3Yy0yMmFlLTQ3ZTMtZTA1My01YjhjN2MxMWE0ZDEiLCJhdWQiOiJhcHBzdG9yZWNvbm5lY3QtdjEiLCJpYXQiOjE2OTkyMjE2MTIsImV4cCI6MTY5OTIyMjIxMiwiYmlkIjoiY29tLm1pcmFpamEudGVzdCJ9.xLDfV6oDmx0RM6soUix7XMM-ilzV3YtSjrbGXe3ZzAj8jbEpGoFLafhPtRYEnEoSYWAY6GZmFPSzxQxO2i60MA]
* Using Stream ID: 1 (easy handle 0x7ff1d000b800)
> POST /inApps/v1/notifications/test HTTP/2
> Host: api.storekit-sandbox.itunes.apple.com
> User-Agent: curl/8.1.2
> Accept: */*
> Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ilc1QjVRNzJONUwifQ.eyJpc3MiOiI2OWE2ZGU3Yy0yMmFlLTQ3ZTMtZTA1My01YjhjN2MxMWE0ZDEiLCJhdWQiOiJhcHBzdG9yZWNvbm5lY3QtdjEiLCJpYXQiOjE2OTkyMjE2MTIsImV4cCI6MTY5OTIyMjIxMiwiYmlkIjoiY29tLm1pcmFpamEudGVzdCJ9.xLDfV6oDmx0RM6soUix7XMM-ilzV3YtSjrbGXe3ZzAj8jbEpGoFLafhPtRYEnEoSYWAY6GZmFPSzxQxO2i60MA
>
< HTTP/2 401
< server: daiquiri/3.0.0
< date: Sun, 05 Nov 2023 22:07:20 GMT
< content-type: text/plain
< strict-transport-security: max-age=31536000; includeSubDomains
< x-apple-jingle-correlation-key: MDKTT2CACBWVV4F4V37D6QV6KI
< x-daiquiri-instance: daiquiri:45824002:st44p00it-hyhk15104701:7987:23RELEASE169:daiquiri-amp-commerce-clients-ext-001-st
<
Unauthenticated
Request ID: MDKTT2CACBWVV4F4V37D6QV6KI.0.0
* Connection #0 to host api.storekit-sandbox.itunes.apple.com left intact
how can I fix this????
Post not yet marked as solved
We have an App Store Server Notification endpoint. Our app offers an in app subscription. Most notifications have all of the expected fields, but in a small number of cases the decoded signedTransactionInfo and signedRenewalInfo fields are empty.
I can't see anything about these fields being optional in the documentation, and without the transaction information I can't get the transaction id of the user, so I can't tell how this notification relates to others for the same original transaction id.
Are these notifications expected? Should I be handling them in a special way? Or should I just ignore them?
For example, a normal transaction will have the following fields:
responseBodyV2DecodedPayload (
[notificationType] => DID_RENEW
[notificationUUID] => …
[version] => 2.0
[signedDate] => 1660947328849
[data] => (
[bundleId] => com.playpokpok.playroom
[bundleVersion] => 9
[environment] => Sandbox
[signedTransactionInfo] => JWSTransactionInfo
[signedRenewalInfo] => JWSRenewalInfo
)
)
But one of these unexpected requests will have the following form:
responseBodyV2DecodedPayload (
[notificationType] => EXPIRED
[subtype] => VOLUNTARY
[notificationUUID] => …
[version] => 2.0
[signedDate] => 1662661854606
[data] => (
[appAppleId] => 1550204730
[bundleId] => com.playpokpok.playroom
[bundleVersion] => 6
[environment] => Production
)
)
Post not yet marked as solved
Hi everyone!
I recently launched a hard paywall in my app and have had a fair few people each day sign up to the 3 day free trial.
Around 55% of users remain after the 3 day trial but I am finding that when it ends around 20-25% of the users are running into 'billing errors' meaning they end up not paying at the end of the trial despite never cancelling.
The information coming through from Apple ranges from 'insufficient credit', 'incorrect details' and 'unknown' - but the % is way higher than
Has anyone come across this issue before at such a high % and if so, is there anything we can do to try and improve this number?
Thank you!
Post not yet marked as solved
We set up a server for the v1 endpoint. However, we experienced a server backend issue for several days and realized we lost several days' worth of notification data. It wasn't a server response failure but an issue on our end.
So we tried to findout how to recover notification data.
Get All Subscription Statuses API and Get Refund History API require a transaction id, and I'm not sure how to retrieve the lost data.
And Get Notification History API this seems to only work for Notification V2. It only returns empty data when I request.
Is there any other way to recover App Store server notification v1?
Post not yet marked as solved
same issue urgent problem,
How to I can match subscriptions from same apple id to products by registering different user info.
Post not yet marked as solved
How do we find out User information from Apple server notifications?
I have created a user and purchased an In app product from Apple . I have received a INITIALBUY notification from the App store.
Apple ID : xxxx@gmail.com
User : ABC (User id :111)
The JSON receipt contains the following fields.
"latestreceiptinfo": {
"transactionid": "1000000657540200",
"originaltransactionid": "1000000657537943",
"quantity": "1",
"subscriptiongroupidentifier": "20623048",
"isinintroofferperiod": "false",
"purchasedatepst": "2020-04-27 23:41:05 America/LosAngeles",
"istrialperiod": "false",
"expiresdateformattedpst": "2020-04-27 23:46:05 America/LosAngeles",
"productid": "com.***.iap1.5",
"weborderlineitemid": "1000000052078939",
"uniquevendoridentifier": "xxxxxx-xxxxxxx"
},
I have created one more user from the same Apple id and purchased the same product.
Apple ID : xxxx@gmail.com
User : XYZ (User id :222)
"latestreceiptinfo": {
"transactionid": "1000000657540202",
"originaltransactionid": "1000000657537943",
"productid": "com.***.iap1.5",
"weborderlineitemid": "1000000052078942",
"uniquevendoridentifier": "xxxxxx-xxxxxxx"
},
I have store user information based on productid-
originaltransaction_id =>user
xxxx@gmail.com - com.***.iap1.5 - 1000000657537943 -ABC
xxxx@gmail.com - com.***.iap1.5 -
1000000657537943 -XYZ
In this case I could not track the user information.Duplication will come
From the same Apple id ,2 different users buy the same product Apple will give the same original transaction Id.
Is there any other field to differentiate transactions to find users ?
Is there any option to include User name on JSON server notification from App store.
We have implemented an auto-renewing subscription as an in-app-purchase for our iOS application. We are consuming the App Store Server Notifications for subscription transactions in order to update the user's account (and thereby maintain their 'Pro' access to our application). Sometimes those notifications never come to our server, and there is no evidence that they were even attempted to be sent to us.
We have had some users report to our Customer Support team that they have successfully made a purchase of the subscription, but that they were not granted 'Pro' access.
For the large majority of users this is not happening and all is well, but for some users the notifications just never come from the App Store Server API.
We keep a record of all notifications that we receive from the App Store, and for these users we never received the "SUBSCRIBED" event. We have checked the Notification History API and there are no reports of any failure to send notifications to our server.
We have checked our server logs for any sign of failure to receive incoming web requests, and there is no sign of these missing notifications. We have verified that our server supports ATS.
We are keeping the transaction.originalID for all our users who are subscribed to the auto-renewing subscription. We have used this value to do some lookups into the transaction history and subscription status of the users who are being affected. Here is an example of our findings from those lookups:
From the transaction history endpoint, we received an error: “Invalid transaction identifier”.
From the subscription status endpoint, we received a response with the information for that user's active, valid subscription.
We never received any App Store Server Notifications about this user’s subscription, and the transaction history API tells us it is an invalid transaction ID.
We believe that the fact that the subscription status API returned the information showing that this user’s subscription is active and valid, and that the notification history API shows no sign of a failure to send us notifications about that subscription, shows that the App Store Server API never attempted to send us any notification for this user’s subscription. The same is true for a significant number of other users of our service.
Can anyone help us determine what is going on, and how to best support these customers? It seems as though there was never an attempt to send these notifications to our server, but our users provide proof that they do in fact have an active subscription, for which they have paid (receipt email from Apple with a valid order ID).
Post not yet marked as solved
Hello
We have App Store Server Notifications v2 enabled for our app (we're selling renewable subscriptions), but recently some notifications of type SUBSCRIBED:INITIAL BUY have been missing (not reaching our endpoint).
However, we get DID_CHANGE_RENEWAL_STATUS notifications for these users later and we get SUBSCRIBED notifications for other users, currently this thing looks pretty random.
We've had several cases in the last few days. Example originalTransactionId: 110001866285315. We'd appreciate if Apple engineers could check it, or maybe anyone could share a similar experience. Thanks!
Post not yet marked as solved
I received the following notifications (in this order) for the subscription:
date, type, subtype
2023-10-09 10:49:17,SUBSCRIBED,INITIAL_BUY
2023-10-16 03:46:44,DID_CHANGE_RENEWAL_STATUS,AUTO_RENEW_DISABLED
2023-10-16 10:49:19,DID_FAIL_TO_RENEW,GRACE_PERIOD
2023-10-16 13:14:36,EXPIRED,BILLING_RETRY
What do these mean? Why is there a DID_FAIL_TO_RENEW GRACE_PERIOD notification when the user already disabled auto-renew? Why did it expire in 2.5 hours? Why isn't there a GRACE_PERIOD_EXPIRED notification?"
Post not yet marked as solved
Hi,
I'm trying to implement App Store Server Notifications V2 for my application. At first, I wanted to test the notification using the "Get Test Notification Status" method. I got testNotificationToken from the "Request a Test Notification" method, the response code is 200 and signedPayload after decoding it looks like this:
{
"notificationType": "TEST",
"notificationUUID": "***",
"date": {
"bundleId": "***",
"environment": "Sandbox"
},
"version": "2.0",
"signedDate": 1697535213846
}
it is missing the most important thing for me, signedTransactionInfo in data. According to the documentation, I should get something like this: https://developer.apple.com/documentation/appstoreservernotifications/data
What could be the reason for an incomplete response? Could this be the correct answer after all?
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?
Post not yet marked as solved
I have two apps with bundle IDs 'com.my.ios.stage' and 'com.my.tvos.stage'.
(Not a real ID)
The subscription groups are test.com.ios.subs and test.com.tvos.subs respectively.
When I create a subscription for the test.com.ios.subs group on ios, the receipt is generated well and the app store notification is also working well and notifications are coming.
The subscription created with test.com.tvos.subs does not receive any notifications.
However, when I create a subscription for the test.com.tvos.subs group on tvos, the receipt is generated well, but the notification is not coming.
For both subscriptions, if I parse the receipt and look up transactionHistory with transactionId, there is information about the previously purchased subscription.
I tried to get the notification history of each app with get_notification_history.
In com.my.ios.stage, I can see all the subscription information, including the notification I created with request_test_notification.
In com.my.tvos.stage, I only see the notification created with request_test_notification.
I'm testing in a sandbox. What is the issue?
Post not yet marked as solved
Hi,
We are testing subscriptions and out of a sudden, we stopped getting notifications.
Notifications are not sent both for subscription events and when we request test notifications. In both cases sendAttemptResult is UNSUCCESSFUL_HTTP_RESPONSE_CODE.
What we tested so far and it did not help:
Made sure the webhook host is reachable from the Internet and no IP is filtered
Changed URL to an alternative
Also history of notifications is incomplete at /inApps/v1/notifications/history. It misses notifications from the past 5 hours.
Thanks
Post not yet marked as solved
Hello everyone guys, we have created offer codes for our app, and my question is:
Are we, as developers, obligated to finish somehow these offer codes, like we do with subscription, for example, with App Store Server Notifications? Or Apple makes sure that everything is being proceeded on the backend?
While testing to use offer codes, we have noticed that expiration date of introductionary offer of subscription doesn't change when we fetch info from api.storekit.itunes.apple.com/inApps/v1/subscriptions , even though the offer code was used. (the offer code is configured to be "customers can redeem both an introductory offer and this code"). Is it intended to be like this, or we miss on something?
Thank you in advance!
Post not yet marked as solved
Hey, we've added two endpoints for receiving AppStore Server notifications. One for v1, and for v2. While testing the flow, we've triggered beginRefundRequest() on the client. And we realised that we do get notified on our v2 endpoint. But when we updated AppStoreConnect with our v1 endpoint, and selected to receive v1 notifications. Calling beginRefundRequest() doesn't trigger the the v1 notification at all. Is this expected? Will calling beginRefundRequest() only trigger v2 notifications and not v1?
Post not yet marked as solved
I am developing a mobile app that has a paid subscription. I am interested in triggering a push notification when users change their subscription status in the App Store - for example, if they were to turn off auto-renew on their subscription, that would trigger a push notification using APNS to offer a discount.
How would I go about sending a notification to a specific user based on the Server Notification payload? It is unclear which, if any, of the response body payload can be used to identify the user. Furthermore, I need a way to associate this identification with a device token so I can send an APNS push notification to the user.
I have had the notification toggle available on launch for a while. If I understand correctly, users toggling "Allow/Deny" for registerForRemoteNotifications() notifications only changes their local settings. My first instinct was to start storing user data when they consent or decline notifications on launch - I could store [some kind of user ID, notifications_allowed (bool), and the APNS device token]. That way, when receiving an App Store Server Notification, I can reference this table, then fetch their device token and send a push notification if they have agreed to notifications. However, this seems somewhat fallible because it doesn't track users who change their notification settings in their own setting later.
To summarize, my questions are the following:
How can I identify a user from an App Store Server Notification payload?
How could I store an identifier along with the APNS device token when users consent or decline push notifications that can later be used to associate their device with an App Store Server Notification?
Post not yet marked as solved
Why doesn't Apple send notifications when a user purchases a Non-Renewing Subscription type product ?
Sending server-to-server (S2S) notifications is industry practice which is provided by many leading payment service providers like PayPal, Stripe etc.
Sending S2S calls for all products would increase the reliability of the service. Even if the app fails to notify a purchase of NRS product, Merchant's servers would be notified by Apple's S2S notification.
Please enable notifications for all types of products and give Merchant/Developer option to opt-in or opt-out of notifications for a product type.
Post not yet marked as solved
We have a Mac application that we're migrating to the App Store, and we're testing App Store server notifications and running in Sandbox. We've set up all of the appropriate URL's in App Store Connect, and testing by using the https://api.storekit-sandbox.itunes.apple.com/inApps/v1/notifications/test link works great. We get the notification at our server with a notificationType of TEST.
However, we then go through our application and do a Sandbox test purchase. It finishes fine, BUT the only notification we EVER get at our server is notificationType TEST. We assumed that in the Sandbox environment we would get SUBSCRIBED or similar, but that's not happening. Always TEST.
A few notes.... our app is Objective C (rewriting in Swift really isn't an option currently), and it's using the original Storekit. We have set up App Store Connect to send V2 notifications since V1 is deprecated.
All the normal processes work from the app, from logging in our Sandbox tester, to completing the purchase. Our app itself receives a successful SKPaymentTransaction.
We set up the Sandbox User to do a monthly renewal every 5 minutes. We are getting notifications every 5 minutes for 12 total, but they're ALL notificationType TEST.
Is there some sandbox testing setup we're missing to get actual notifications like SUBSCRIBED and EXPIRED (albeit with the data-environment set to Sandbox)?
Post not yet marked as solved
When sending notification messages, the Apns package is used to send them.
I set only the title and body without any additional settings and sent a notification message, but an error occurred in some iPhone devices where multiple messages with the same content were received.
Has anyone experienced something like this? How can this be confirmed and processed to resolve this?
This situation occurred in iPhone 12, 12maxpro, 14, and 14pro.
Post not yet marked as solved
My app is in "Pending Developer Release" status, and I have created Promo codes for app download and for auto-renewable subscriptions. When I recently redeemed one of the subscription codes I did not receive an app store server notification to my server.
Does anyone know whether promo code redemption triggers an app store server notification or not? What are the conditions that must be met for an app store server notification to happen for promo code redemption?
Thanks
miraija.
