I would like to know if it is allowed to offer the user to either unlock the app immediately or partake in a 3-day trial period before making a purchase. I created 2 IAP non-consumable products; 1 for the immediate [which is at a discount] and for the after trial period ends [this is at a higher cost]. Is this something that Apple allows or is frowned upon?

I encountered the following issues while developing in-app purchases; please help me: When attempting to purchase a product that has already been purchased, SKPaymentQueue reports an error instead of a success message: <SKPaymentQueue: 0x134665380>: Payment completed with error: Error Domain=ASDServerErrorDomain Code=3532 "You’re currently subscribed to this." UserInfo={NSLocalizedFailureReason=You’re currently subscribed to this., client-environment-type=Sandbox, AMSServerErrorCode=3532, storefront-country-code=USA} After buying product A on one iPhone using a sandbox account, restoring purchases on another iPhone with the same sandbox account via paymentQueue.restoreCompletedTransactions(withApplicationUsername:) does not return the previously purchased product A data; it directly calls restoreCompletedTransactionsFinished.

https://developer.apple.com/documentation/appstoreserverapi/get-v2-history-_transactionid I would like to inquire about the detailed triggers for updating receipts in this API specification. Recently, I was using this API with sort=DESCENDING&revoked=false to retrieve the expiration date of the most recent receipt and determine the subscription status. However, for some reason, an old receipt with an earlier expiration date appeared as the first receipt, and I would like to know the reason for this. Can you provide information on what specific events or actions trigger the updating of receipts in this API? Also, regarding https://developer.apple.com/documentation/appstoreserverapi/status, will statuses 3 and 4 not be returned in the response unless the billing grace period is enabled in the App Store? -- Japanese こちらのAPI仕様ですが、どのようなトリガーでレシートが更新されるのか詳細に伺いたいです。 先日このAPIを使用してsort=DESCENDING&revoked=falseで一番最初のレシートの有効期限を取得して課金状態か判断していたのですが、どういったわけか一番最初のレシートに古い有効期限のレシートが入ってきたので理由を知りたいです。 また、https://developer.apple.com/documentation/appstoreserverapi/status のステータスはAppleStoreで請求猶予期間を有効化しないと3,4はレスポンスされませんか？

Hi, We have a app with some auto-renewing subscription in a group of subscriptions. When a user upgrade from a subscription to another, the "user receive a refund of the prorated amount of their original subscription" (https://developer.apple.com/app-store/subscriptions/). How is the prorated calculated ? Example : subscription to 14,99$ / month. If subscriber upgrade after 10 days, is the refund calculated 10/30 of 14,99$ (so ~5$) ?

Hi all, I’m testing Subscription in my Flutter app on a real iOS device (iPhone 16 Pro with iOS 18) via TestFlight. I’ve set everything up as required, but I still get this error: flutter: Found products: [] If everything works perfectly when StoreKit configuration is used in Xcode, but not via TestFlight. All my Subscriptions are approved with the same ID.

アプリに課金を実装しようと思うのですが、もし不正利用された場合、アプリ側は基本的にApp Storeを通じて対応するよう案内するのが一般的と思いますが、Apple ID不正利用時とクレジットカード不正利用時で、アプリ側が行う標準的な対応プロセスは変わるのか教えていただきたいです。 また下記内容は標準的な対応プロセスとして問題ないでしょうか？
 ■Apple ID不正利用時 → ユーザー自身がAppleサポートに連絡し、パスワード変更・二段階認証の設定・不正購入の返金申請などを行うよう案内する。 ■クレジットカード不正利用時 → まずカード会社への連絡を促すが、アプリ内決済に関してはAppleのカスタマーサポート経由で返金や調査手続きを案内する 不正利用されたユーザーへの対応に備えて、アプリ側が考慮すべきことがあれば教えてください。

Our app server has subscription feature and processes purchase life cycles based on App Store Server Notification v1. Last year, when users purchased subscriptions during the following timeframe, we received "INITIAL_BUY" notifications with "unified_receipt.Latest_receipt_info.purchase_date" set to future date(approx. 1 hour after the actual purchase). 2024-11-03 08:00:00 - 2024-11-03 09:00:00 Etc/GMT (UTC) For example, we received the following v1 notification at 2024-11-03 08:36:33 Etc/GMT. "notification_type": "INITIAL_BUY" "unified_receipt.latest_receipt_info[].purchase_date": "2024-11-03 09:36:02 Etc/GMT" Our server grants subscription entitlement based on "purchase_date" so the users had to wait 1 hour before the subscription features became available. The timeframe coincided with the end of daylight saving time in the U.S., so we assume that it affected the behavior, but our country doesn't adopt daylight saving time. We have some questions regarding this behavior. In countries without daylight saving time, how should we handle such notifications with future purchase date in order to properly grant subscription entitlement? In App Store Server Notification v2, could purchase date be set to future date at the end of daylight saving time in the U.S., just as in v1 notifications? JWSTransactionDecodedPayload.purchaseDate

Starting around October 12, 2025 at 19:51 UTC, we're seeing intermittent failures when verifying StoreKit transaction JWTs. The issue appears to be related to certificate expiration in the x5c chain in the JWT tokens provided by Apple. What We're Seeing Some JWTs are being signed with different certificates. Some work, some fail certificate validation. Old Certificate (Expired - causing failures): Subject: Prod ECC Mac App Store and iTunes Store Receipt Signing Issuer: Apple Worldwide Developer Relations Certification Authority (G6) Serial: 166451396673336810269824643773700992094 Valid From: 2023-09-12 19:51:53 UTC Valid To: 2025-10-11 19:51:52 UTC ❌ EXPIRED New Certificate (Valid - working): Subject: Prod ECC Mac App Store and iTunes Store Receipt Signing Issuer: Apple Worldwide Developer Relations Certification Authority (G6) Serial: 95385247725814954943813376527885434295 Valid From: 2025-09-19 19:44:51 UTC Valid To: 2027-10-13 17:47:23 UTC ✓ VALID Current Status Most JWTs use the new valid certificate. Some JWTs still use the expired certificate. This appears inconsistent/random. I don't know if it's an issue with some of Apple's servers, or an issue with StoreKit on-device cache, but seems to me like a bug on Apple's side either way. Are we missing something? Is this a known issue? Any guidance or timeline from Apple would be greatly appreciated, as this is blocking legitimate paying users.

I cannot test IAP using sandbox account that I logged on from settings, it keeps show my regular Apple ID when I try to test IAP from TestFlight This issue frustrate me and bunch of my colleagues, we cannot manage our subscription when sandbox account is default choosing Apple ID I've seen people complaining about this issue a lot Any help on resolving this issue would be really appreaciated

How can I get the region region currently used in the macOS App Store? Preferably via Swift libraries, but any command / function will suffice. The following StoreKit property seems to always return the region for the Apple Account associated with my macOS user. await Storefront.current?.countryCode See the Apple docs. My macOS Apple Account region is US; in the App Store, when I sign into a different Apple Account whose region is GB (UK), Storefront.current?.countryCode continues to return US, not GB (or UK). I correctly see prices in pounds instead of in dollars, British spelling instead of American spelling, apps listed in my purchased tab for the UK (not the US) Apple Account, and, in the Account Settings dialog, the UK Apple Account email address, billing address & Country/Region set to United Kingdom. I didn't get any relevant results from the following command lines: defaults find GB defaults find UK defaults find uk-apple-id@example.com defaults find uk-apple-id The following didn't change after I signed into the UK Apple Account in the App Store: $ defaults read com.apple.AppStoreComponents { ASCLocaleID = "en-US@calendar=gregorian"; } Maybe Storefront.current?.countryCode only specifies the country code for the Storefront that will be used for in-app purchases, instead of for purchasing new apps from the App Store; maybe the former is tied to the Apple Account for the macOS user, instead of to the Apple Account for the App Store. If that's the case, what other mechanism can I use to obtain the country code for the App Store storefront?

I am currently using the App Store Server API Get All Subscription Statuses in the app I am in charge of. Please let me confirm the following regarding Get All Subscription Statuses. ■Prerequisites The language used is Objective-c, and I am using both XCode 15 and 16. I also have an App Store Connect account. ■Questions Is it possible to set and test each status of the App Store Server API Get All Subscription Statuses with TestFlight?

What is the expected behavior for App Receipts and ASSN v2 notifications when a subscription is set to "Remove from Sale"? I tried to test this in Sandbox, but the "Remove from Sale" setting in App Store Connect doesn't seem to affect the Sandbox environment. For existing subscribers, what happens in the receipt? Does auto_renew_status change to 0 and is expiration_intent populated immediately? Also, which notificationType is sent via ASSN v2?

hI, I’m looking for some clarity on the rules around in app purchasing, so I play a game with in app purchases that you have random odds of getting items out of loot boxes, they split the loot into sections, so featured, mega rare, rare and common. for each of these sections they give a % chance that they show of what chance you have to get an item out of that section, I.e featured is 1.24% and common is 74% ect. my question is should they then have to display the odds of what each item has in those sections as well or is it good enough just to have the sections with % chance? So each section could have 10 items in, should those items have a % next to as well? any advice you can give with this would be appreciated, if needs be I can send picture examples of what I’m explaining

Hello, I have a question regarding the App Store Server API's getTransactionInfo endpoint. Previously, the official documentation for getTransactionInfo mentioned that: “This endpoint doesn’t support an app transaction. To get information about an app transaction, decode the signed app transaction received from the device.” However, as of June 2025, I can no longer find this sentence in the current documentation (link). Now, the docs state that all in-app purchase transaction IDs are supported (consumable, non-consumable, auto-renewable subscriptions, etc.). But in practice, when I call getTransactionInfo with an AppTransactionId (extracted from a signed App Transaction JWS), I receive this error: apiErrorCode: 4000048 “Invalid request. App transactions aren’t supported by this endpoint.” Is this endpoint supposed to support AppTransactionId now, or is the restriction still in place (but not mentioned in the docs)? Is there any official statement about when this restriction was added/removed? Can you clarify if only in-app purchase transaction IDs (and not AppTransactionIds) are supported for this endpoint, or has the policy changed recently? Any clarification or historical context would be greatly appreciated. Additionally, I would like to know about the behavior of an App Transaction in the event of a refund. If a user receives a refund for the app itself (not an in-app purchase), how can changes to the AppTransaction be detected? Does the App Store Server Notification v2 provide notifications for app-level refunds, or are such events only visible by decoding the latest App Transaction JWS on the device? Is there any way to receive app-level refund information server-side, or must we always rely on the device to provide the updated signed app transaction? Any clarification on this refund flow and notification coverage would also be appreciated. Thank you!

I'm working on an app the has implemented inapp purchases. They have been working so far, and they keep working currently. But just a couple of days ago, a specific user sent us a support ticket stating that when he purchases and item the bank charges it for the purchase, but within the app, the purchase fails and he doesn't receive the item. He sent us screenshots showing: The iOS native modal when a purchases has been finished correctly ("You're all set - Your purchase was successful "). Right after that modal, the app shows an internal modal showing "The purchase failed, please, try again later". Checking the app logs, that failure modal was triggered by "The operation couldn’t be completed. (StoreKit.StoreKitError error 1.)". Reading docs about this error leads me to think about device or user restrictions (parental controls, usage limits, etc...). It seems that in theses cases the bank charge could be issued but refunded later once Apple ultimately declines the purchase. However the user says that he doesn't have any kind of restriction. The only related thing is a "this device is also restricted by a profile" message, but everyone seems to have this message. What could it be causing this issue? In what scenariowould the app show a native OK modal but a storekit error 1? I'm pretty sure the app is well configured because I keep receiving purchases of all kind, from different users with any problem.

My app has in app purchase for subscriptions, available in many countries. When using Sandbox App Store accounts on TestFlight with a locale different from my own in the iOS 26 RC, I'm getting incorrect currency coming back from Product.products(for: identifiers), and so my app displays the wrong price for the locale. However, the actual Apple Pay buy sheet shows the proper currency symbol and currency amount. This did not happen on prior versions of iOS. Is anyone else experiencing this?

I noticed a very weird behavior for refunds. When a user refunds an up-front paid app, they still have access to the app. How can I detect such a case and block access to the app? In general, I think it should be handled by Apple, but for some reason, they don't do it.

In all the illustrations of win-back offers, I see an example of "Get 3 months off, then $X/month", as seen below. First, I'm not exactly clear how each configuration translates into an actual offer in practice: If I want to offer 3 months off on an annual subscription, ie. only if the user pays for the annual offer (basically a 25% discount), is that possible? If I set a "Free" type, of 3 months, I guess that would allow the user to cancel before paying for the annual, correct? If I set a "Pay up front" type, with a 25% discount, how would that show up to the user on the App Store? Secondly, is eligibility to an offer determined by the user elapsing on the same subscription or any subscription in the same subscription group? Thank you

Hi everyone, I’m facing a recurring issue with my macOS app being rejected during App Store review, and I’d really appreciate any guidance. The subscription flow in my app is implemented using StoreKit, and everything works perfectly in our development environment using a StoreKit configuration file. It also behaves as expected in Sandbox testing and TestFlight — I even had few beta testers confirm that the subscription information is displayed correctly and the purchase flow completes without issues. All required subscription details are configured in App Store Connect: • Subscription duration and the description of the services offered • Price and price per unit where applicable • Paid apps agreement and related forms are correctly filled However, when the app is submitted for review, the subscription screen fails to display the expected information. From what I can tell, the product information fails to load from the App Store in the review environment — even though everything is working fine on our side. We’ve already submitted a video to Apple showing the subscription UI working in the Sandbox environment, but the app continues to be rejected under guideline 3.1.2 due to missing subscription info in the binary. Is anyone else experiencing similar behavior during review? Could there be a caching issue or delay in StoreKit syncing for newly configured products? Any help or suggestions are very welcome. Thanks in advance!

アプリ内課金を実装しようとしていますが、サーバサイドのセキュリティに関してについて質問です。 StoreKit２を使えばアプリとApp Store Connect間のレシート検証は不要だが、 購入情報をサーバーで管理する場合は アプリからサーバーに購入情報を渡す際にレシート検証する必要があると考えるがその認識であっているか教えていただきたいです。