I am currently exploring the implementation of win-back offer in my app to encourage lapsed subscribers to re-subscribe. I plan to use the automatic win-back offer sheet that display to eligible customers upon app launch, as described in the documentation. However, I am unclear about the specific iOS version requirements needed to support this feature effectively. Could someone clarify the minimum iOS, iPadOS, and macOS versions required for these automatic win-back offer sheet?

Hello folks. Hope you have a great day. I have a question on your Get Notification History API. Reference : https://developer.apple.com/documentation/appstoreserverapi/get_notification_history According to NotificationHistoryRequest document( https://developer.apple.com/documentation/appstoreserverapi/notificationhistoryrequest ) startDate parameter allows past 180 days from current date. However my test result is little bit different. Could you help me this case? I'll give detailed request/response during testing. Request body {"startDate":1714364482159,"endDate":1729048882326,"notificationType":"REFUND","notificationSubtype":null,"transactionId":null,"onlyFailures":null} Response Header server: daiquiri/5 date: Wed, 16 Oct 2024 03:21:38 GMT content-type: application/json content-length: 110 x-apple-jingle-correlation-key: SBDV5UOM7YGOJCYS2M4S2X67IE x-apple-request-uuid: 90475ed1-ccfe-0ce4-8b12-d3392d5fdf41 b3: 90475ed1ccfe0ce48b12d3392d5fdf41-06ee3a4acafcff41 x-b3-traceid: 90475ed1ccfe0ce48b12d3392d5fdf41 x-b3-spanid: 06ee3a4acafcff41 apple-seq: 0.0 apple-tk: false apple-originating-system: CommerceGateway x-responding-instance: CommerceGateway:20104::: apple-timing-app: 8 ms strict-transport-security: max-age=31536000; includeSubDomains x-daiquiri-instance: daiquiri:47578001:st44p00it-hyhk15014801:7987:24RELEASE221:daiquiri-amp-commerce-clients-ext-002-st body {"errorCode":4000012,"errorMessage":"Invalid request. The start date is earlier than the allowed start date."} As you see, request sent at Wed, 16 Oct 2024 03:21:38 GMT, and start date is 1714364482159 which is Mon, 29 April 2024 04:21:22 (milli second). The difference between the two dates is 170 days. Could you help me this this case? If I misunderstood on your API, please let me know. Thank you.

We are utilizing the StoreKit external purchase link within the app and have configured the necessary keys in the entitlements according to the documentation. The Info.plist file has also been updated with the required key and a single destination URL, following the guidelines from this documentation. However, when we click the link in the app, it redirects to the default browser, and the in-app system disclosure sheet does not appear. Should the in-app disclosure sheet appear automatically, or do we need to design and implement it ourselves?

What happens after 12 renewals? Does the subscription expire completely? The next day when I try to manage settings for my sandbox account it says it cannot connect. I cannot see the status of subscription in: Settings-> App Store -> Sandbox Account -> Manage Logging out and logging in of my regular account does not fix that. When I login with a different non-testflight sandbox account I can finally edit those settings. There are some missing details in documentation explaining testflight sandbox accounts. Do these accounts stop working after 12 auto-renewals? I need more specific details in order to ensure subscriptions will work properly during production.

We are currently upgrading our server to IPv6, and when we tested it, we found that the following API, which verifies receipts when charging, resulted in an error. verifyReceipt API https://buy.itunes.apple.com/verifyReceipt https://sandbox.itunes.apple.com/verifyReceipt This is currently a deprecated API, so when we tried curling the URL to the "App Store Server API" and using nslookup, we also got an error. App Store Server API https://api.storekit.itunes.apple.com https://api.storekit-sandbox.itunes.apple.com The error was that the address could be retrieved from the domain in IPv4, but the address could not be retrieved in IPv6. "https://www.apple.com" and other sites could be retrieved without any problems in IPv6. Is this API not compatible with IPv6? If this is not possible, the only way to verify receipts and the legitimacy of charges seems to be to perform verification on the device, but as this requires a lot of work, I would like to know if there is a better way.

Hello, We’re implementing subscription validation on our server using Apple’s latest APIs and have run into a few issues and uncertainties. We are transitioning away from the deprecated /verifyReceipt endpoint and are now using the /inApps/v1/subscriptions/{transactionId} API. However, we have questions about how to handle transaction validation, particularly around older transactions and notification behavior in the sandbox environment. Additionally, we are facing challenges with Apple Server Notifications, especially regarding when we should expect to be notified of subscription cancellations or expirations. Below are the specific questions we hope the community can help us with: Question 1: We are using the inApps/v1/subscriptions/{transactionId} API to retrieve the subscription status and validate subscriptions on our server side, since the /verifyReceipt endpoint has been deprecated. This API always returns the last transaction for a subscription. Should we only validate the latest transaction, and is it guaranteed that even if we provide an older transaction ID, the API will always return the most up-to-date transaction information? https://developer.apple.com/documentation/appstoreserverapi/get_all_subscription_statuses/ https://developer.apple.com/documentation/appstorereceipts/verifyreceipt Question 2: In the sandbox environment, we encountered an empty response when trying to validate a transaction ID. We are attempting to validate older transactions made by the user to keep our system and store subscriptions in sync. Could you provide guidance on why this might be happening and how we can validate older transactions? Question 3: We are using Apple Server Notifications to track subscription renewals and changes. However, when a user disables auto-renewal, we do not receive a webhook notification when the subscription actually expires or is canceled. We only get notified when the user changes their renewal preferences. Should we expect a separate notification when the subscription fully expires or is canceled, or is this behavior expected? https://developer.apple.com/documentation/appstoreservernotifications/notificationtype

The application has changed from paid purchase to free use. We need to obtain the previous player's purchase records to unlock the paid content. //Here is the code for the client to obtain the player's payment information: NSURL * receiptURL = [[NSBundle mainBundle] appStoreReceiptURL]; if ([[NSFileManager defaultManager] fileExistsAtPath:[receiptURL path]]){ NSData *receiptData = [NSData dataWithContentsOfURL:receiptURL]; NSString *receiptUrlString = [receiptData base64EncodedStringWithOptions:NSDataBase64EncodingEndLineWithLineFeed]; NSLog(@"requestAppStoreReceipt receiptUrlString = %@", receiptUrlString); } else { // 如果凭证为空，则再发一次凭证请求 SKReceiptRefreshRequest *refreshReceiptRequest = [[SKReceiptRefreshRequest alloc] initWithReceiptProperties:@{}]; refreshReceiptRequest.delegate = self; [refreshReceiptRequest start]; NSLog(@"requestAppStoreReceipt 如果凭证为空，则再发一次凭证请求！"); } //The following is the server-side parsing code: Path filePath = Path.of("SubscriptionKey_ABCDEFGHIJ.p8"); String encodedKey = Files.readString(filePath); Environment environment = Environment.SANDBOX; AppStoreServerAPIClient client = new AppStoreServerAPIClient(encodedKey, keyId, issuerId, bundleId, environment); String appReceipt = "MIIcs..."; ReceiptUtility receiptUtil = new ReceiptUtility(); String transactionId = receiptUtil.extractTransactionIdFromTransactionReceipt(transactionReceipt); System.out.println(transactionId); if (transactionId != null) { long now = System.currentTimeMillis(); TransactionHistoryRequest request = new TransactionHistoryRequest() .sort(TransactionHistoryRequest.Order.DESCENDING) .revoked(false) .productTypes(List.of(TransactionHistoryRequest.ProductType.CONSUMABLE)); HistoryResponse response = null; List<String> transactions = new LinkedList<>(); do { String revision = response != null ? response.getRevision() : null; response = client.getTransactionHistory(transactionId, revision, request, GetTransactionHistoryVersion.V2); transactions.addAll(response.getSignedTransactions()); } while (response.getHasMore()); Set<InputStream> rootCAs = Set.of( new FileInputStream("AppleComputerRootCertificate.cer"), new FileInputStream("AppleIncRootCertificate.cer"), new FileInputStream("AppleRootCA-G2.cer"), new FileInputStream("AppleRootCA-G3.cer") ); Long appAppleId = 1234567899L; // appAppleId must be provided for the Production environment System.out.println(transactions.size()); SignedDataVerifier signedPayloadVerifier = new SignedDataVerifier(rootCAs, bundleId, appAppleId, environment, true); for (String notificationPayload : transactions) { try { AppTransaction payload = signedPayloadVerifier.verifyAndDecodeAppTransaction(notificationPayload); System.out.println(payload); } catch (VerificationException e) { e.printStackTrace(); } } } //Return result analysis: JWSTransactionDecodedPayload{originalTransactionId='2000000641683476', transactionId='2000000641683476', webOrderLineItemId='null', bundleId='', productId='', subscriptionGroupIdentifier='null', purchaseDate=1719566962000, originalPurchaseDate=1719566962000, expiresDate=null, quantity=1, type='Consumable', appAccountToken=null, inAppOwnershipType='PURCHASED', signedDate=1728885967093, revocationReason=null, revocationDate=null, isUpgraded=null, offerType=null, offerIdentifier='null', environment='Sandbox', storefront='CHN', storefrontId='143465', transactionReason='PURCHASE', price=6000, currency='CNY', offerDiscountType='null', unknownFields=null} We have develop according to the following document on our end： https://developer.apple.com/documentation/foundation/nsbundle/1407276-appstorereceipturl#4098404 https://developer.apple.com/documentation/appstoreserverapi/get_transaction_info/ https://developer.apple.com/documentation/appstoreserverapi/data_types We would like to know if the solutions in the document can be used to solve the problems we encountered? Is there a problem with our method of parsing bills that prevents us from obtaining the necessary information?

<SKPaymentQueue: 0x30217e480>: Payment completed with error: Error Domain=ASDServerErrorDomain Code=3904 "优惠已不再提供" UserInfo={storefront-country-code=CHN, AMSServerErrorCode=3904, client-environment-type=Sandbox, NSLocalizedFailureReason=优惠已不再提供}

I want to sell the same subscription in multiple apps so that if someone subscribes in one they show up as having a subscription in the other. Apple's documentation states "To get started, use App Store Connect to create a separate and equivalent auto-renewable subscription for each app that offers the multi-app subscription so that users can subscribe from any app." (https://developer.apple.com/documentation/storekit/in-app_purchase/original_api_for_in-app_purchase/subscriptions_and_offers/offering_a_subscription_across_multiple_apps) But I'm unable to create two subscriptions with the same Product ID. I could create two subscriptions that are equivalent but with different Product IDs that are treated as the same by our server, which would accomplish the main goal, but I believe this risks someone subscribing to both subscriptions if they do so directly through the App Store, for example using a promo code link, because they're still two different subscriptions to Apple. Thanks!

I am working on the integration of subscriptions in my OSX application. The subscription flow works perfectly but after the purchase it is not creating _MASReceipt folder in Contents folder of application so I cannot send the receipt to apple to verify this purchase. when I checked the logs it showing below error. Anyone who is familiar to this issue please help. Error writing receipt (13401 bytes) using privileged service to /private/var/folders/xw/yd038cts3b94qmtvlxzb1sy80000gp/T/AppTranslocation/9B8BB321-1C16-4F41-93EA-E27675791E79/d/test.app Error Domain=NSCocoaErrorDomain Code=642 "You can’t save the file “_MASReceipt” because the volume “9B8BB321-1C16-4F41-93EA-E27675791E79” is read only." UserInfo={NSFileOriginalItemLocationKey=file:///private/var/folders/xw/yd038cts3b94qmtvlxzb1sy80000gp/T/AppTranslocation/9B8BB321-1C16-4F41-93EA-E27675791E79/d/Advanced%20Uninstall%20Manager.app/Contents/_MASReceipt, NSURL=file:///private/var/folders/xw/yd038cts3b94qmtvlxzb1sy80000gp/T/AppTranslocation/9B8BB321-1C16-4F41-93EA-E27675791E79/d/abc.app/Contents/_MASReceipt, NSFileNewItemLocationKey=file:///System/Library/Caches/com.apple.appstored/abc.app/_MASReceipt/, NSUnderlyingError=0x7fdc618ded90 {Error Domain=NSCocoaErrorDomain Code=642 "You can’t save the file “_MASReceipt

We are currently experiencing an issue where our server is not receiving Apple’s server notification (webhook) for in-app purchase confirmations. This notification is critical as it helps us confirm the purchase status and fulfill the corresponding services to the users. Despite the successful completion of purchases within the app, the lack of webhook notifications prevents us from tracking and processing these payments on our backend. In addition to resolving this issue, we are also concerned about the security aspect of receiving server notifications. Specifically, we want to ensure that any requests or notifications we receive are indeed coming from Apple, and not subject to potential man-in-the-middle (MIM) attacks. We are looking for information or best practices on how to validate that the request originates from a legitimate Apple source, ensuring the integrity of the communication and safeguarding our system from spoofed or malicious requests. Key questions: Server Notification Issue: Why might we not be receiving Apple's payment confirmation notifications, and what steps can we take to troubleshoot this issue? Request Validation: What security mechanisms or validation techniques can we implement to confirm that the server notifications are genuinely from Apple, ensuring no interference from MIM attacks? Does Apple provide any headers, tokens, or signatures in the server notification that we can use to verify the origin? Are there any known methods or configurations to ensure secure receipt of in-app purchase confirmations? We are looking for guidance and possible solutions to ensure a secure and reliable payment validation process for our in-app purchases. Any support in this regard would be highly appreciated.

I have got from App Review Team this same feedback during several months: Guideline 2.1 - Performance - App Completeness We are unable to complete the review of your app because one or more of your in-app purchase products have not been submitted for review. Next Steps To resolve this issue, please be sure to take action and submit your in-app purchases and upload a new binary in App Store Connect so we can proceed with our review. I am unable to understand and implement what is meant by the feedback: … take action … What "action" to take? … submit your in-app purchases … How to "submit in-app purchases"? I know how to submit my app but how "submitting in-app purchases”? My app contains no separate in-app purchases but several pathways through the app. The app's code contains three flags that act as signposts on user’s way through the app (Basic, Standard, Premium). The signposts are not extra content and features distributed on the App Store. They are existing parts in the app from the very beginning. They are activated according to the model user chooses (Basic, Standard, Premium) and loads down from the App Store. I try to solve the problem since several months - without success. Links offer no solution. Links say what one can do but not how to do it. What is missing are a couple of lines of code I can adapt and integrate into my app's Objective-C code. Best regards gefa

When testing In-App Purchases in Xcode with a .storekit file, I can delete past purchase transactions, so I can re-test the purchase experience. I've switched to using a Sandbox tester and made purchases. However, I cannot find how to delete previous purchase transactions made in the sandbox so I can re-run the tests. Is this possible?

Hello! Since October 2, we have observed a problem with the renewal of subscriptions. We have not changed anything, but the receipts no longer have the information whether a valid subscription exists after the subscription was actually automatically extended. The subscription status can then be queried correctly via verify Receipt. Has anything been changed to the receipts from Apple? PS: we know that StoreKit1 is deprecated and we should switch to StoreKit2 asap.

I work as QA and we develop mobile farm game. Inside our game we have shop where user can buy coins or special prem.coins. And interface shows price with Apple Tax. Also we have battle pass, and when user want to buy battle pass the price shows without Apple tax. Anybody knows what is wrong? Pass price inside game > 9.99$ Price when user want to buy it > 11.99

Hi, we had a case where one of our users wanted us to stop renewing his subscription in our app since he was unable to do it himself. Is there a way for us to stop the auto renewal? Kind regards Ondřej Leitmančík

I have 2 subscriptions, monthly and year first：DID_CHANGE_RENEWAL_PREF + DOWNGRADE： Customer downgrades a subscription within the same subscription group； The current subscribe is year；if i change to month；when the subscribe year was expire，Automatic renewal will change to month second：DID_CHANGE_RENEWAL_PREF+UPGRADE： Customer upgrades a subscription within the same subscription group. The current subscribe is month；if i change to year；I need to pay for the annual subscription immediately；and The subscription immediately switches to the annual third：DID_CHANGE_RENEWAL_PREF subtype is None Customer reverts to the previous subscription, effectively canceling their downgrade. what this mean? This is Test Env，month is five minutes；year is one hour ①My current subscription is an annual， startTime：2024-10-02 15:04:58 ，expireTime：2024-10-02 16:04:58 ②first DOWNGRADE to month，at 2024-10-02 15:14:16 ②after 38 minutes，I change to the annual subscribe；at 2024-10-02 15:52:00 in the end，the Notification purchaseDate 2024-10-02 15:52:00；expiresDate 2024-10-02 16:52:00； So When I get NotificationType=DID_CHANGE_RENEWAL_PREF，NotificationSubType=None，Do I need to create a new subscription for the users？ Is it the latest notice of purchaseDate and expiresDate, for a year？ The appleNotification Payload as follows： JWSTransactionDecodedPayload( originalTransactionId='2000000731045285', transactionId='2000000731088945', webOrderLineItemId='2000000076096676', bundleId='app.xxxx', productId='com.xxxx.365', subscriptionGroupIdentifier='21514251', purchaseDate=1727855520000, 2024-10-02 15:52:00 originalPurchaseDate=1727852699000, 2024-10-02 15:04:59 expiresDate=1727859120000, 2024-10-02 16:52:00 quantity=1, type=<Type.AUTO_RENEWABLE_SUBSCRIPTION: 'Auto-Renewable Subscription'>, rawType='Auto-Renewable Subscription', appAccountToken='fa37b7a2-2b0b-43cb-8fda-a1fb21168efe', inAppOwnershipType=<InAppOwnershipType.PURCHASED: 'PURCHASED'>, rawInAppOwnershipType='PURCHASED', signedDate=1727855526632, 2024-10-02 15:52:06 revocationReason=None, rawRevocationReason=None, revocationDate=None, isUpgraded=None, offerType=None, rawOfferType=None, offerIdentifier=None, environment=<Environment.SANDBOX: 'Sandbox'>, rawEnvironment='Sandbox', storefront='CAN', storefrontId='143455', transactionReason=<TransactionReason.PURCHASE: 'PURCHASE'>, rawTransactionReason='PURCHASE', currency='CAD', price=14990, offerDiscountType=None, rawOfferDiscountType=None) JWSRenewalInfoDecodedPayload( expirationIntent=None, rawExpirationIntent=None, originalTransactionId='2000000731045285', autoRenewProductId='com.xxxx.365', productId='com.xxxx.365', autoRenewStatus=<AutoRenewStatus.ON: 1>, rawAutoRenewStatus=1, isInBillingRetryPeriod=None, priceIncreaseStatus=None, rawPriceIncreaseStatus=None, gracePeriodExpiresDate=None, offerType=None, rawOfferType=None, offerIdentifier=None, signedDate=1727855526632, 2024-10-02 15:52:06 environment=<Environment.SANDBOX: 'Sandbox'>, rawEnvironment='Sandbox', recentSubscriptionStartDate=1727852698000, 2024-10-02 15:04:58 renewalDate=1727859120000, 2024-10-02 16:52:00 currency='CAD', renewalPrice=14990, offerDiscountType=None, rawOfferDiscountType=None, eligibleWinBackOfferIds=None)

We are facing a issue of transaction mismatch between App Store server notification and subscription status api because of this we are not able to activate the expected subscription for user. User has successfully purchased a subscription from application. On our server we got the notification with below transaction : { **  "transactionId": "170001503839428",   "originalTransactionId": "170001503839428",**   "webOrderLineItemId": "170000681682289",   "bundleId": "com.*****",   "productId": "com.**.*",   "subscriptionGroupIdentifier": "21020104",   "purchaseDate": 1668398097000,   "originalPurchaseDate": 1668398098000,   "expiresDate": 1699934097000,   "quantity": 1,   "type": "Auto-Renewable Subscription",   "appAccountToken": "2d98c4f1-3af9-4965-89ca-0495940d1a58",   "inAppOwnershipType": "PURCHASED",   "signedDate": 1669031276395,   "environment": "Production" } We tried to validate the transaction using originalTransactionId (170001503839428) through subscription status api. We got below latest transaction from api having different originalTransactionId: {  ** "transactionId": "170001466326163",   "originalTransactionId": "170001466326163",**   "webOrderLineItemId": "170000661796452",   "bundleId": "com.*****",   "productId": "com.**.",   "subscriptionGroupIdentifier": "21020104",   "purchaseDate": 1665113844000,   "originalPurchaseDate": 1665113845000,   "expiresDate": 1665718644000,   "quantity": 1,   "type": "Auto-Renewable Subscription",   "inAppOwnershipType": "PURCHASED",   "signedDate": 1669036686044,   "offerType": 1,   "environment": "Production" } Because of this mismatch our validation is getting failed at our server. How is it possible to get different transaction when we are providing different originalTransactionId as api parameter? Dear team, please look into this.

This is re-posted from this Stack Overflow post. I am looking at validating the purchase of a paid app from Mac AppStore. Based on this WWDC video about StoreKit 2, I am attempting to this with AppTransaction. I have not found meaningful high-level documentation about this specific use case beyond that. My approach is to first get the "cached" AppTransaction by calling AppTransaction.shared. If that is not there I proceed to getting it from Apple, via AppTransaction.refresh(). If they don't have it, or when the network is down, the user automagically gets the familiar "log in to your store account" UI that has been around as long as the Mac AppStore. Once I have the AppTransaction I use it to verify we are on the right device, using code like this, where the returned Bool represents validation success: guard let deviceVID = AppStore.deviceVerificationID?.uuidString.lowercased() else { return false } let nonce = appTransaction.deviceVerificationNonce.uuidString.lowercased() let combo = nonce + deviceVID let digest = SHA384.hash(data: Data(combo.utf8)) return (digest == appTransaction.deviceVerification) My first question is: Does that look like the right approach? Is there something else I should do, or check? My second question is around testing this approach. Refreshing the AppTransaction in the sandbox invariably yields a valid item, even if the app version does not yet exist in AppStoreConnect. This is also the case when I log out in the App Store app on the Mac. This makes me think it is using my AppleID which I am logged into in System Settings. Does that sound right? I would like to be able to remove / delete the cached AppTransactions - where might I find those on the system? Thanks for everyone's help!

Hello, I have a customer who keeps getting an "app is damaged" error for a freshly downloaded app from the Mac App Store. The logs show the following lines: standard 12:58:40.390872+0200 storeuid Receipt Validation (at.EternalStorms.Yoink) Signature Check: PASS Bundle ID Check: PASS Bundle Version Check: PASS GUID Check: PASS Expiration Check: PASS standard 12:58:40.391649+0200 storelegacy StoreLegacy: Failed to perform in-line receipt renewal for application at path /Applications/Yoink.app : '(null)' The Mac in question is running macOS 12 Monterey - curiously, the customer has another Mac with that same system version and there it works just fine. What can be done to make this work again? Thank you, – Matthias