App Store Server Notifications

How do we find out User information form Apple server notifications?

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.

Posted

by

Pratheepa

verifyReceipt returns tons of errors 21104 and 21107

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

Posted

by

pdcgomes

App Store Notifications v2 - Verifying a signature

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.

App Store Server Notifications

Posted

by

Mr. Brightside

ordering transactions and renewal state from notifications

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?

App Store Server Notifications

Posted

by

magnawut

we received "REFUND_DECLINED" 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?

App Store Server Notifications

Posted

by

kuookuoo

What is the significance of an App Store Server Notification that has no signedTransactionInfo?

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

Posted

by

PatrickRogers

how to identify transaction is in free trial period in notification v2

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 ?

App Store Server Notifications

Posted

by

daz2yy

How to calculate 'Active paid subscriptions' using subscription event data

As per the display in "App Store Connect > Sales and Trends > Subscriptions > Summary", I'm wanting to understand how to calculate the 'Active paid subscriptions' figure for a particular period using only the subscription event data. This is for further analysis and calculation outside of App Store Connect. For example, if at the start of April I have 500 active paid subscriptions, then at the end of April I have 550 active paid subscriptions, what are the calculation of Subscription events that would make up this figure? I'd presume the formula would be: End of period subscriptions = start of period subscriptions + activations (includes trials) + conversions to standard price + reactivations - refunds - trial only activations - cancellations However when I compare the above calculation against what is reported by 'Active paid subscriptions' at the start and end of a period in App Store Connect it is not the same. What is the calculation of events across a period that determines the current 'Active paid subscriptions' figure?

Posted

by

bentocorp

Server to server notification

Hi All, We are trying server-to-server notifications for in-app purchases. This is the first time we are configuring in-app purchases for the app, so configurations are still for test apps and in-app purchases being tested by sandbox accounts. For server-to-server notification, we configured the url as mentioned in the doc, but still, our server url is not being called after a successful in-app purchase. Could you please help if anything more is required for config?

Posted

by

pankaj_propertyguru

Request for assistance with expired certificates in server-to-server notification payload from App Store

I am writing to seek your assistance in resolving a problem I am facing with the server-to-server notification payload from the App Store. I have noticed that the certificate verification is failing when I receive the server-to-server notification payload. Upon investigation, I discovered that the payload contains expired certificates. This is causing an issue for me as it is preventing me from verifying trusted notifications from the App Store. I would greatly appreciate your guidance on what I should do to address this problem. Is there any way to renew the certificates or any other solution to resolve this issue? Thank you for your attention and I am looking forward to your prompt reply.

App Store Server Notifications

Posted

by

Charly_LEE

Free Trial Billing Errors

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!

Posted

by

healthycaterpillar1

App Store Server Notifications not always sent to my server

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

Posted

by

seanodonnell

INTERACTIVE_RENEWAL notification is sent while user resubscribed to another SKU

It is in sandbox environment, and our serice is using v1 Base on this doc, the INTERACTIVE_RENEWAL notification would be sent: Subscription is active; customer upgraded to another SKU Subscription has expired; customer resubscribed to another SKU (upgrade or downgrade) { "environment": "Sandbox", "receipt": { "receipt_type": "ProductionSandbox", "bundle_id": "co.appeconomy.alarm", "receipt_creation_date": "2023-04-26 10:13:24 Etc/GMT", "request_date": "2023-04-26 10:17:11 Etc/GMT", "original_purchase_date": "2013-08-01 07:00:00 Etc/GMT", "original_application_version": "1.0" }, "latest_receipt_info": [ { "quantity": "1", "product_id": "co.appeconomy.alarm.monthly", "transaction_id": "2000000320391970", "original_transaction_id": "2000000320390725", "purchase_date": "2023-04-26 10:11:53 Etc/GMT", "original_purchase_date": "2023-04-26 10:09:59 Etc/GMT", "expires_date": "2023-04-26 10:16:53 Etc/GMT", "web_order_line_item_id": "2000000026088214", "is_trial_period": "false", "is_in_intro_offer_period": "false", "in_app_ownership_type": "PURCHASED", "subscription_group_identifier": "20906883" }, { "quantity": "1", "product_id": "co.appeconomy.alarm.monthly", "transaction_id": "2000000320390725", "original_transaction_id": "2000000320390725", "purchase_date": "2023-04-26 10:09:53 Etc/GMT", "original_purchase_date": "2023-04-26 10:09:59 Etc/GMT", "expires_date": "2023-04-26 10:11:53 Etc/GMT", "web_order_line_item_id": "2000000026088213", "is_trial_period": "true", "is_in_intro_offer_period": "false", "in_app_ownership_type": "PURCHASED", "subscription_group_identifier": "20906883" } ], "pending_renewal_info": [ { "auto_renew_product_id": "co.appeconomy.alarm.monthly", "is_in_billing_retry_period": "0", "product_id": "co.appeconomy.alarm.monthly", "original_transaction_id": "2000000320390725", "auto_renew_status": "0" } ], "status": 0 } these is the response from verifyReceipt api Can notice that I request at '2023-04-26 10:17:11 Etc/GMT' and latest receipt shows that subscription is expired at '2023-04-26 10:16:53 Etc/GMT'. So obviously this subscription is expired already But when I resubscribed the same sku(in this case is co.appeconomy.alarm.monthly) in the Setting > App Store > Edit Subscription. My server can still receive INTERACTIVE_RENEWAL notification. { "bid": "co.appeconomy.alarm", "bvrs": "2", "environment": "Sandbox", "unified_receipt": { "status": 0, "environment": "Sandbox", "latest_receipt_info": [ { "quantity": "1", "product_id": "co.appeconomy.alarm.monthly", "expires_date": "2023-04-26 10:23:47 Etc/GMT", "purchase_date": "2023-04-26 10:18:47 Etc/GMT", "transaction_id": "2000000320398679", "is_trial_period": "false", "in_app_ownership_type": "PURCHASED", "web_order_line_item_id": "2000000026088350", "original_transaction_id": "2000000320390725", "is_in_intro_offer_period": "false", "subscription_group_identifier": "20906883" }, { "quantity": "1", "product_id": "co.appeconomy.alarm.monthly", "expires_date": "2023-04-26 10:16:53 Etc/GMT", "purchase_date": "2023-04-26 10:11:53 Etc/GMT", "transaction_id": "2000000320391970", "is_trial_period": "false", "in_app_ownership_type": "PURCHASED", "web_order_line_item_id": "2000000026088214", "original_transaction_id": "2000000320390725", "is_in_intro_offer_period": "false", "subscription_group_identifier": "20906883" }, { "quantity": "1", "product_id": "co.appeconomy.alarm.monthly", "expires_date": "2023-04-26 10:11:53 Etc/GMT", "purchase_date": "2023-04-26 10:09:53 Etc/GMT", "transaction_id": "2000000320390725", "is_trial_period": "true", "in_app_ownership_type": "PURCHASED", "web_order_line_item_id": "2000000026088213", "original_transaction_id": "2000000320390725", "is_in_intro_offer_period": "false", "subscription_group_identifier": "20906883" } ], "pending_renewal_info": [ { "product_id": "co.appeconomy.alarm.monthly", "auto_renew_status": "1", "auto_renew_product_id": "co.appeconomy.alarm.monthly", "original_transaction_id": "2000000320390725" } ] }, "auto_renew_status": "true", "notification_type": "INTERACTIVE_RENEWAL", "auto_renew_product_id": "co.appeconomy.alarm.monthly", "original_transaction_id": 2000000320390725 } From the product_id and subscription_group_identifier can recognize that I really resubscribed the same sku, so why? Does I miss any exceptional case in document?

App Store Server Notifications

Posted

by

daydaylw3

After completing the trial period, the user successfully renewed their subscription. However, the App Store server did not send us a notification regarding the type of renewal.

User's receipt information: { "environment": "Production", "receipt": { "receipt_type": "Production", "adam_id": xx, "app_item_id": xx, "bundle_id": "com.xxxxx", "application_version": "4.9.0", "download_id": xxxx, "version_external_identifier": xxxx, "receipt_creation_date": "2023-02-20 10:34:24 Etc/GMT", "receipt_creation_date_ms": "1676889264000", "receipt_creation_date_pst": "2023-02-20 02:34:24 America/Los_Angeles", "request_date": "2023-05-23 08:18:49 Etc/GMT", "request_date_ms": "1684829929749", "request_date_pst": "2023-05-23 01:18:49 America/Los_Angeles", "original_purchase_date": "2023-01-06 09:49:26 Etc/GMT", "original_purchase_date_ms": "1672998566000", "original_purchase_date_pst": "2023-01-06 01:49:26 America/Los_Angeles", "original_application_version": "4.9.0", "in_app": [ { "quantity": "1", "product_id": "com.***.xxxvip.year.autorenew", "transaction_id": "340001130126198", "original_transaction_id": "340001130126198", "purchase_date": "2023-02-20 10:34:22 Etc/GMT", "purchase_date_ms": "1676889262000", "purchase_date_pst": "2023-02-20 02:34:22 America/Los_Angeles", "original_purchase_date": "2023-02-20 10:34:24 Etc/GMT", "original_purchase_date_ms": "1676889264000", "original_purchase_date_pst": "2023-02-20 02:34:24 America/Los_Angeles", "expires_date": "2023-02-27 10:34:22 Etc/GMT", "expires_date_ms": "1677494062000", "expires_date_pst": "2023-02-27 02:34:22 America/Los_Angeles", "web_order_line_item_id": "340000522616394", "is_trial_period": "true", "is_in_intro_offer_period": "false", "in_app_ownership_type": "PURCHASED" } ] }, "latest_receipt_info": [ { "quantity": "1", "product_id": "com.***.xxxvip.year.autorenew", "transaction_id": "340001135819586", "original_transaction_id": "340001130126198", "purchase_date": "2023-02-27 10:34:22 Etc/GMT", "purchase_date_ms": "1677494062000", "purchase_date_pst": "2023-02-27 02:34:22 America/Los_Angeles", "original_purchase_date": "2023-02-20 10:34:24 Etc/GMT", "original_purchase_date_ms": "1676889264000", "original_purchase_date_pst": "2023-02-20 02:34:24 America/Los_Angeles", "expires_date": "2024-02-27 10:34:22 Etc/GMT", "expires_date_ms": "1709030062000", "expires_date_pst": "2024-02-27 02:34:22 America/Los_Angeles", "web_order_line_item_id": "340000522616395", "is_trial_period": "false", "is_in_intro_offer_period": "false", "in_app_ownership_type": "PURCHASED", "subscription_group_identifier": "20530539", "app_account_token": "a5axxxxxxxxx84e7e" }, { "quantity": "1", "product_id": "com.***.xxxvip.year.autorenew", "transaction_id": "340001130126198", "original_transaction_id": "340001130126198", "purchase_date": "2023-02-20 10:34:22 Etc/GMT", "purchase_date_ms": "1676889262000", "purchase_date_pst": "2023-02-20 02:34:22 America/Los_Angeles", "original_purchase_date": "2023-02-20 10:34:24 Etc/GMT", "original_purchase_date_ms": "1676889264000", "original_purchase_date_pst": "2023-02-20 02:34:24 America/Los_Angeles", "expires_date": "2023-02-27 10:34:22 Etc/GMT", "expires_date_ms": "1677494062000", "expires_date_pst": "2023-02-27 02:34:22 America/Los_Angeles", "web_order_line_item_id": "340000522616394", "is_trial_period": "true", "is_in_intro_offer_period": "false", "in_app_ownership_type": "PURCHASED", "subscription_group_identifier": "20530539", "app_account_token": "a5axxxxxxxx4e7e" } ], "latest_receipt": "xxxxxx", "pending_renewal_info": [ { "auto_renew_product_id": "com.***.xxxvip.year.autorenew", "product_id": "com.***.xxxvip.year.autorenew", "original_transaction_id": "340001130126198", "auto_renew_status": "1" } ], "status": 0 } We are still using App Store Server Notifications 1.0,We have received App Store Server notifications: { "unified_receipt": { "latest_receipt": "xxxxx", "pending_renewal_info": [ { "original_transaction_id": "340001130126198", "product_id": "com.***.xxxvip.year.autorenew", "auto_renew_status": "1", "auto_renew_product_id": "com.***.xxxvip.year.autorenew" } ], "environment": "Production", "status": 0, "latest_receipt_info": [ { "expires_date_pst": "2023-02-27 02:34:22 America/Los_Angeles", "purchase_date": "2023-02-20 10:34:22 Etc/GMT", "in_app_ownership_type": "PURCHASED", "purchase_date_ms": "1676889262000", "original_purchase_date_ms": "1676889264000", "app_account_token": "a5axxxxxx84e7e", "original_transaction_id": "340001130126198", "quantity": "1", "expires_date_ms": "1677494062000", "original_purchase_date_pst": "2023-02-20 02:34:24 America/Los_Angeles", "product_id": "com.***.xxxvip.year.autorenew", "subscription_group_identifier": "xxxxx", "transaction_id": "340001130126198", "web_order_line_item_id": "340000522616394", "expires_date": "2023-02-27 10:34:22 Etc/GMT", "is_in_intro_offer_period": "false", "original_purchase_date": "2023-02-20 10:34:24 Etc/GMT", "purchase_date_pst": "2023-02-20 02:34:22 America/Los_Angeles", "is_trial_period": "true" } ] }, "environment": "PROD", "auto_renew_status": "true", "bvrs": "4.9.0", "bid": "com.xxxxx", "original_transaction_id": 340001130126198, "auto_renew_product_id": "com.***.xxxvip.year.autorenew", "notification_type": "INITIAL_BUY" } We only received the initial purchase notification mentioned above. Why wasn't a notification sent for the successful renewal payment?

Posted

by

yangyiyi

signedRenewalInfo keeps null

We have an App Store Server Notification V2 endpoint and we are testing our app subscription in sandbox environment. Here's the problem: when we receive JWS from sandbox, we found the payload of data.signedRenewalInfo filed is always null, including first buy, renew... When will signedRenewalInfo field contains any information? Greate appreciate!

Posted

by

st_kalecgos

Linking Subscription Notification back to a unique AppleId / User

I'm currently using App Store Server Notifications which is fine I have an endpoint and i am receiving data. I can see that in the message the originalTransactionId looks to be a unique Id based on a subscription for a user. My issue is if the App is uninstalled and then reinstalled with the same Apple Account, then they subscribe to the App this will give me a different originalTransactionId, which I need to be able to link this to the same user somehow? Is there way this can be done? I need some sort of global unique Id for a apple user which will be the same no matter if they uninstall and reinstall. thanks, James

Posted

by

Taity180

App Store server notification after subscription started with offer code converts

Hello, We're working on an offer code implementation and we're now looking for some clarification around App Store server notifications. What notification type and subtype would we receive once a subscription that was started by using an offer code converts to using a real payment method? For example, someone starts a subscription with an offer code and we receive notification of the type OFFER_REDEEMED and subtype INITIAL_BUY. After that, it isn't very clear what type and subtype the notification would contain once the subscription converts.

App Store Server Notifications

Posted

by

edrobotij31

Unauthenticated 403 error while accessing any app store server api

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

Posted

by

sandeepkudale14

Successful subscriptions do not appear in the sandbox

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

Posted

by

llgoforit

Can I use the Get Notification History API without setting an HTTPS URL for notifications?

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?

Posted

by

sngi

Posts under App Store Server Notifications tag