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.

Hi, Sometimes I get tons of errors 21104 and 21107 in a row when I try to validate new subscriptions and renew existing subscriptions from our server side by using the endpoint verifyReceipt: POST https://buy.itunes.apple.com/verifyReceipt https://developer.apple.com/documentation/appstorereceipts/verifyreceipt The response of this endpoint doesn't give any extra information: { 		"environment": "Production", 		"status": 21107, 		"is_retryable": true } I noticed that those subscriptions are renewed on the second try after waiting a bit (in a different hour/day). The documentation only indicates that the status codes 21100-21199 are internal data access errors but it doesn't specify each one: https://developer.apple.com/documentation/appstorereceipts/status I understand that it's an error on the Apple side so there is nothing I can do but if someone could give us more information about those errors (21104 and 21107).

I have started implementing support for the new App Store Server notifications (version 2): https://developer.apple.com/documentation/appstoreservernotifications/receiving_app_store_server_notifications I am not sure how to prevent a possible mad-in-the-middle attack when using those notifications. The decoded header that I get for notifications in the Sandbox environment is missing the "kid" field that is used to identify the key used to generate a signature. Yes, I understand the the whole entire certificate chain is available in the "x5c" field and it could be verified by itself. However, this does not guarantee that a notification was signed by Apple. This approach (with no specific key, with a certificate chain in x5c) works fine when verifying a receipt on device with StoreKit 2 but it does not work when getting a notification on a server.

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?

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 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         ) )

In notification version1, there is an field called is_trial_period, is useful for us to identify this transaction is in free trial, and we can judge the user's payment status and recomand some feature for him. but, in notification version2 the filed is not appear, in this scenari, how can I identify this user is in free trial period ?

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!

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).

We followed all step given in Docs but getting authenticate error for other apple account that I am using Below is details of error my command: curl -v -H 'Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjNCQzczUjlEV0MifQ.eyJpc3MiOiI2OWE2ZGU4ZS1iNGZhLTQ3ZTMtZTA1My01YjhjN2MxMWE0ZDEiLCJhdWQiOiJhcHBzdG9yZWNvbm5lY3QtdjEiLCJpYXQiOjE2ODc4NDIwNjA4NDksImV4cCI6MTY4Nzg0NTY2MDg0OSwiYmlkIjoiY29tLm9uZmVyZW5jZS5vbmZlcmVuY2VhcHAifQ.W8_vaEPZoinC-80bBq-g3XLkohb_FSPzGN4a4YfqJ_V1UnmBmrtz2GtBPHhlQRB1VJ7NE3n3BNAWUMJrD5AuEA' "https://api.storekit.itunes.apple.com/inApps/v1/transactions/340001235870976" Error gettings Trying 17.56.138.9... TCP_NODELAY set Connected to api.storekit.itunes.apple.com (17.56.138.9) port 443 (#0) ALPN, offering h2 ALPN, offering http/1.1 successfully set certificate verify locations: CAfile: /etc/ssl/cert.pem CApath: none TLSv1.2 (OUT), TLS handshake, Client hello (1): TLSv1.2 (IN), TLS handshake, Server hello (2): TLSv1.2 (IN), TLS handshake, Certificate (11): TLSv1.2 (IN), TLS handshake, Server key exchange (12): TLSv1.2 (IN), TLS handshake, Server finished (14): TLSv1.2 (OUT), TLS handshake, Client key exchange (16): TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): TLSv1.2 (OUT), TLS handshake, Finished (20): TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): TLSv1.2 (IN), TLS handshake, Finished (20): SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 ALPN, server accepted to use h2 Server certificate: subject: businessCategory=Private Organization; jurisdictionCountryName=US; jurisdictionStateOrProvinceName=California; serialNumber=C0806592; C=US; ST=California; L=Cupertino; O=Apple Inc.; CN=commercegateway.itunes.apple.com start date: May 16 16:44:52 2023 GMT expire date: Nov 12 16:54:52 2023 GMT subjectAltName: host "api.storekit.itunes.apple.com" matched cert's "api.storekit.itunes.apple.com" issuer: C=US; O=Apple Inc.; CN=Apple Public EV Server RSA CA 2 - G1 SSL certificate verify ok. Using HTTP2, server supports multi-use Connection state changed (HTTP/2 confirmed) Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 Using Stream ID: 1 (easy handle 0x7f9bed010800) GET /inApps/v1/transactions/340001235870976 HTTP/2 Host: api.storekit.itunes.apple.com User-Agent: curl/7.64.1 Accept: / Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjNCQzczUjlEV0MifQ.eyJpc3MiOiI2OWE2ZGU4ZS1iNGZhLTQ3ZTMtZTA1My01YjhjN2MxMWE0ZDEiLCJhdWQiOiJhcHBzdG9yZWNvbm5lY3QtdjEiLCJpYXQiOjE2ODc4NDIwNjA4NDksImV4cCI6MTY4Nzg0NTY2MDg0OSwiYmlkIjoiY29tLm9uZmVyZW5jZS5vbmZlcmVuY2VhcHAifQ.W8_vaEPZoinC-80bBq-g3XLkohb_FSPzGN4a4YfqJ_V1UnmBmrtz2GtBPHhlQRB1VJ7NE3n3BNAWUMJrD5AuEA Connection state changed (MAX_CONCURRENT_STREAMS == 1024)! < HTTP/2 401 < server: daiquiri/3.0.0 < date: Tue, 27 Jun 2023 05:34:00 GMT < content-type: text/plain < strict-transport-security: max-age=31536000; includeSubDomains < x-apple-jingle-correlation-key: Z4AC6TLUWQRJHHYNLGGL5L2EZA < x-daiquiri-instance: daiquiri:15824002:mr85p00it-hyhk03174701:7987:23RELEASE91:daiquiri-amp-commerce-clients-ext-001-mr < Unauthenticated Request ID: Z4AC6TLUWQRJHHYNLGGL5L2EZA.0.0 Connection #0 to host api.storekit.itunes.apple.com left intact Closing connection 0

The problem that I am experiencing is that the subscription is successful even if i try to subscribe once more it will say that i am already subscribed, but if i try to cancel it, in my sandbox account there is no subscriptions. Not sure it is related but the other issue that i am experiencing is that the webhook is not called

I am planning to use the Get Notification History API to receive refund notifications for consumable in-app purchases. In order to receive notification data from this API, do I need to set up an HTTPS URL in App Store Connect to receive App Store Server Notifications?

I am trying to understand the correct flow for a mobile app/server app - auto-renewable subscriptions. Since verifyReceipt has been marked as deprecated, I am struggling with how I should link an App Store Server Notification v2 message with a user in the database. Currently, the process is as follows: First, the mobile application calls our server with receipt-data. Second, the server calls verifyReceipt to validate the receipt. Then, I am able to match the user's subscription/transaction with their data (using an internal JWT with user data from the first step and originalTransactionId from decoded verifyReceipt response). If we omit the first step, how would I determine who should receive the App Store Server Notification v2 message?

Hello everyone! I have some doubts on the use cases and triggers related to the REFUND_REVERSED notification type. I would like to better understand which real customer actions example would trigger this notification to be sent. Does the developer gets back the amount refunded to the user? Quoting the documentation: If your app revoked content or services as a result of the related refund, it needs to reinstate them. This applies only to a REFUND_REVERSED associated to a REFUND of the latest possible renewal right? Since we receive REFUND_REVERSED also several weeks after the REFUND and so for long expired subscriptions. We don't have to get access again to the user in the latter case, do we? Thank you very much to whoever will take time to answer!

I have a non-renewable subscription set up in my app and I also have App Store Server Notifications enabled, with URLs for both the production server and the sandbox server to receive version 2 notifications. I can simulate payment subscription in my app with sandbox tester, however I am not getting any notification from the app store server. Is there anything else I need to configure?

My app is develop using react native and i use react-native-iap package for ios IAP. I have 1 non-consumable IAP products, and i need to receive callback from Apple Server to Our Server, but it still didn't coming yet, how i supposed to check this? I have already setup the url on Sandbox Server URL, and have already successfully send the notification test using https://api.storekit-sandbox.itunes.apple.com/inApps/v1/notifications/test the response from notification test is below: { "testNotificationToken": "19d-8f54-41cd-84cf-e9265df_16***4897" } ASAP, Thankyou

Based on this site https://support.apple.com/en-us/HT202039 the subscription can be cancelled & re-subscribe by user on iPhone devices. I'm asking for the payment lifecycle included with subscription status when subscription is canceled, re-subscribe, or subscription is EXPIRED. Please explain billing lifecycle to our bank account based on subscription status. Thankyou.

I have been experiencing with my app's subscription renewal process. When a user successfully renews their subscription, the App Store sends an event to my backend server. However, in some cases, the backend server is receiving an event that says the renewal failed, even though the user's subscription was successfully renewed. I have been working on this bug for several days and I have not been able to find a solution. I would appreciate any help that you can provide.

We are attempting to monitor subscription events via App Store Server Notifications. The URL we have configured (with v1 or v2) continually gets invoked with GET requests instead of POST requests, we do not get any POST with request data at all and cannot process subscription changes. Why might this be happening? What could we have misconfigured? configuration: requests:

Cause in sandbox env I notice a receipt like this { "environment": "Sandbox", "unified_receipt": { "status": 0, "environment": "Sandbox", "latest_receipt_info": [ { "quantity": "1", "product_id": "3monthplan", "expires_date": "2023-07-25 04:50:29 Etc/GMT", "purchase_date": "2023-07-25 04:41:29 Etc/GMT", "transaction_id": "2000000375156349", "expires_date_ms": "1690260629000", "is_trial_period": "false", "expires_date_pst": "2023-07-24 21:50:29 America/Los_Angeles", "purchase_date_ms": "1690260089000", "purchase_date_pst": "2023-07-24 21:41:29 America/Los_Angeles", "in_app_ownership_type": "PURCHASED", "original_purchase_date": "2023-07-25 03:20:41 Etc/GMT", "web_order_line_item_id": "2000000032603282", "original_transaction_id": "2000000375122102", "is_in_intro_offer_period": "false", "original_purchase_date_ms": "1690255241000", "original_purchase_date_pst": "2023-07-24 20:20:41 America/Los_Angeles", "subscription_group_identifier": "20572434" }, .... { "quantity": "1", "product_id": "3monthplan", "expires_date": "2023-07-25 04:03:49 Etc/GMT", "purchase_date": "2023-07-25 03:54:49 Etc/GMT", "transaction_id": "2000000375136003", "expires_date_ms": "1690257829000", "is_trial_period": "false", "expires_date_pst": "2023-07-24 21:03:49 America/Los_Angeles", "purchase_date_ms": "1690257289000", "purchase_date_pst": "2023-07-24 20:54:49 America/Los_Angeles", "in_app_ownership_type": "PURCHASED", "original_purchase_date": "2023-07-25 03:20:41 Etc/GMT", "web_order_line_item_id": "2000000032600544", "original_transaction_id": "2000000375122102", "is_in_intro_offer_period": "false", "original_purchase_date_ms": "1690255241000", "original_purchase_date_pst": "2023-07-24 20:20:41 America/Los_Angeles", "subscription_group_identifier": "20572434" }, { "quantity": "1", "product_id": "monthlyplan", "expires_date": "2023-07-25 03:38:37 Etc/GMT", "purchase_date": "2023-07-25 03:35:37 Etc/GMT", "transaction_id": "2000000375127458", "expires_date_ms": "1690256317000", "is_trial_period": "false", "expires_date_pst": "2023-07-24 20:38:37 America/Los_Angeles", "purchase_date_ms": "1690256137000", "cancellation_date": "2023-07-25 04:38:50 Etc/GMT", "purchase_date_pst": "2023-07-24 20:35:37 America/Los_Angeles", "cancellation_reason": "0", "cancellation_date_ms": "1690259930000", "cancellation_date_pst": "2023-07-24 21:38:50 America/Los_Angeles", "in_app_ownership_type": "PURCHASED", "original_purchase_date": "2023-07-25 03:20:41 Etc/GMT", "web_order_line_item_id": "2000000032600434", "original_transaction_id": "2000000375122102", "is_in_intro_offer_period": "false", "original_purchase_date_ms": "1690255241000", "original_purchase_date_pst": "2023-07-24 20:20:41 America/Los_Angeles", "subscription_group_identifier": "20572434" }, ... ] }, "auto_renew_status": "false", "cancellation_date": "2023-07-25 04:38:50 Etc/GMT", "notification_type": "CANCEL", "cancellation_date_ms": "1690259930000", "auto_renew_product_id": "3monthplan", "cancellation_date_pst": "2023-07-24 21:38:50 America/Los_Angeles", "web_order_line_item_id": "2000000032600434", "original_transaction_id": 2000000375122102 } plan is keeping renew. What if I refund in prod env, and after refund agree, is that my subscription would auto turn off?