We are wondering if it is possible to distinguish between purchases made through our app and those made directly from the App Store in the subscription process. Does the API information such as Server notifications v2 and Get All Subscription Statuses contain information that can distinguish between these cases? If not, we are thinking of using the appAccountToken included in JWSTransaction to distinguish between them. We are aware that appAccountToken is set when an appAccountToken or applicationUsername is given to an app when purchasing a subscription. Therefore, we believe that the appAccountToken of JWSTransaction is not set when you purchase a subscription directly from the App Store. We think that by setting the appAccountToken for purchases made through our app, we can distinguish whether the subscription was purchased directly from the App Store or not, but is this an appropriate way to do so? Please let us know if there is a case where the appAccountToken is set even if the subscription was purchased directly from the App Store. https://developer.apple.com/documentation/appstoreserverapi/appaccounttoken

Hello, I studied this and this documents and I find certain contradiction with this discussion. Could you help me out, please? I set up my subscriptions this way: , where Pro (annual or monthly) offers most of the features and Mobile Pro (annual or montly) least of the features. Do I get it right, that: Upgrading: to annual: What happens here? to monthly: [link] The customer’s prorated payment from lower level subscription is refunded to the original payment method. They’re charged for the higher level subscription, which goes into effect immediately. Downgrading: both annual and monthly: [link] They’re charged for the lower level subscription on their next renewal date. They continue using their current subscription until then. Crossgrading: to annual: What happens here? to monthly: [link] ...the crossgrade goes into effect on the customer’s next renewal date. They continue using their current subscription until then. Thanks.

Good Afternoon Apple .... I am developing a takeway app, which allows business owners to register their takeway, then allow customers and staff, and allow their staff access to the account they have created. I would use IAP subscription to allow tiered monthly access, ie $10 for 1 user, $20 for 2, etc. I have a server back-end which would be used to record the IAP subscription to allow the extra staff to log in via web or android. The complication comes in with the case of a 'serial entrepreneur'. I use the model of '1 company, 1 email'. so, my entrepreneur registers 2 accounts, for 2 separate take-aways. Company A has 1 user, company B has 2 users. In this scenario, I would want the entrepreneur to log into company A, purchase a 1-user mobthly subscription, switch to company B, and then purchase a 2-user supscription. the subscriptions would therefore be separate. The registration would use my own login mechanism, so the entrepreneur would be using the same apple Id on the same iPhone. i wish to avoid the scenario 'entrepreneur registers company B, purchases a 2-user monthly subscription, then registers company A, and automatically gets another 2 users. Whilst I could likely code this to work, my questino is whether the app store would accept it ? the guidelines don't really seem to elaborate on this scenario. if necessary i could make the entrepreneur purchas a 3-user monthly subscription that is shared across his 2 logins, but I would like to avoid this if possible. regards, Phil

I am writing to seek assistance with renewing my Apple Developer Membership. Unfortunately, I do not see the renew button in my Apple Developer account, and it is showing the message "Your Apple Developer Program membership has expired." Previously, the payment was made using an Apple ID of a developer who is no longer working with us. As a result, I am unable to renew the membership with the current setup. Could you please assist in mapping the subscription to my preferred Apple ID: [?????????????] ? Your support in resolving this issue would be greatly appreciated.

I am trying to create a subscription with a specific subscriptionPeriod. However, when I try creating a sub, it gives me a 409 "The attribute 'subscriptionPeriod' can not be included in a 'CREATE' request". I have even tried creating a subscription and then updating it https://developer.apple.com/documentation/appstoreconnectapi/subscriptionupdaterequest. But i get the same error.

Hi, I'm currently working on a application on the server-side that is attempting to generate analytics from our application's user's subscription and in-app purchases. One of the pieces of information that we need is the purchaser's zip/postal code for financial reporting. I noticed Google provides this information in their monthly earnings reports, but Apple seems to omit this field. That being said, is possible to obtain a purchaser's postal/zip code through an api, server notifications, or anything?

App rejection : The app uses public APIs in an unapproved manner, which does not comply with guideline 2.5.1. Specifically, your app using configuration profiles to install icons and/or wallpapers. Since there is no accurate way of predicting how an API may be modified and what effects those modifications may have, unapproved uses of public APIs in apps is not allowed. I’m wondering if it’s true that asking users to download a configuration profile doesn’t jive with 2.5.1? How to resolve the problem and what reason ?

We recently reduced the subscription price for new customers in the USA from $9.99 to $4.99. However, existing customers are also seeing the new price of $4.99, but when they attempt to purchase the subscription, they are charged the original price of $9.99. Actual Behavior: Existing Customers: See the price as $9.99 and are charged $9.99. New Customers: See the price as $4.99 and are charged $4.99. Can anyone assist with resolving this issue? Thank you!

Hi all. Our application uses server-side validation of user subscriptions. After purchasing a subscription, the server keeps track of the subscription renewal statuses. But for the second week already, when requesting information on subscriptions, the server receives 403 Forbidden error. At first we decided that our ip was blocked somewhere and tried to change the ip to a new one. But changing the ip address did not give any results. We keep getting 403 Forbidden error on all requests to check subscriptions from our server. The request goes to the following address /verifyReceipt This method is deprecated and it is necessary to change the method of verification to a new one, but it can't be done quickly. At the moment, there is no information when verifyReceipt will be disabled. And we need to verify subscriptions. Maybe someone has encountered a similar problem? Thanks for the help!

I know this isn’t the place to report this, but I’m in a Catch 22 situation. You meed to access the app to send a bug report to developers, but I can’t load the app on IOS 18, so I’m reporting it here. The NY Times News App does not open under IOS 18 or iPadOS 18. The subsidiary apps, Games, Cooking, and Audio do.

Anyone else seeing renewals show up as activations for auto-renewing subscriptions in App Store Connect? Our app is almost 2 months old on the App Store and we have had monthly subscriptions starting to sell almost on day one so we've had one full subscription monthly cycle go by for a bunch of our paid users. We noticed though that after 4-5 weeks, there was only one subscription renewal shown but we also were't seeing cancellations or a drop in our subscriber numbers. We just kept seeing more activations. Now at the 8 week mark we are very sure that renewals are showing as activations instead since our subscriber numbers aren't tanking, but instead slowly climbing, and we've only had a handful of renewals or cancellations. We'll see say 10 subscription activations in a day but then our total paid subscriber numbers only go up by 5, so once again, assuming 5 are actually renewals and not activations. We do see refunds but at the exact same time as a longer subscription period sells so assuming an upgrade and the total paid subscribers doesn't go down. Supposedly our retention rate is 2% but that doesn't seem to match our subscriber numbers at all. Assume this is due to renewals being counted as activations instead. We are NOT using server side validation or tracking of sales, using StoreKit to validate on device and unlock features. So all of this is from the App Store Connect web site. None of this is really an issue right this moment but longer term we'd like to better understand how our retention is going vs new sales. Are we just misunderstanding what the categories mean? We assume this isn't an issue with how we implemented StoreKit in the app but maybe it is? Thanks! Colin

I recently had a request from a Product Owner to implement capability like Netflix has to enable users to switch their payment method from App Store Subscription to Credit Card on our website, as per capability that Netflix has in their account management portal. We tested it today with a colleague who was paying for Netflix through iOS in-app subscription: In the Netflix account management pages it showed that he was currently paying via In App Subscription He updated his payment method to Credit Card in their website's account management portal. Almost immediately after adding his Credit Card in his iOS Subscription Management settings (we could see the the subscription had been set to no longer renew, with an expiry date) How is this done - I can't see any API in App Store Server API documentation that gives us a way of cancelling / preventing renewal of subscriptions on behalf of a user... But Netflix can clearly do it somehow...

Hi I'm from India, My apple developer account has expired, also I have removed my previous payment method UPI because which is my friend's UPI, now I have added a new payment method but while renew my plan it is showing error like Your Purchase could not be completed. Please someone help me.

I have an APP. After User A (Apple ID) subscribes, the user switches to User B (Apple ID) in the App Store. I want to cancel the subscription. If the user switches back to User A (Apple ID) in the App Store, I want to restore the subscription. How can I achieve this? According to the official documentation, it is not recommended to call the restore function frequently.

I'm working in Apple's Sandbox environment to implement in-app purchase of an auto-renewable subscription. I followed the instructions at this link in order to Enable Billing Grace Period: https://developer.apple.com/help/app-store-connect/manage-subscriptions/enable-billing-grace-period-for-auto-renewable-subscriptions. However, when I receive an App Store Server Notification for when the user's billing method fails (DID_FAIL_TO_RENEW), it includes no information about the gracePeriodExpiresDate and we never get a GRACE_PERIOD_EXPIRED notification. Logs showing App Store Server Notification not reflecting Grace Period Enabled. I enabled grace period in App Store Connect like three weeks ago, so it's not a delay there. What can I do to test out Billing Grace Period? Is this just an Apple bug?

Hi! I'm trying to set up a test account in the App Connect Sandbox for testing payments and I'm getting this error: "Something Went Wrong. Try again later." Steps to repro: Login to App Store Connect Go to Users and Access Go to Sandbox Go to Test Accounts - Note: I see the same error here before even starting to add an account Click Add Test Account button Fill out form Click Create button Result: I receive the "Something Went Wrong. Try again later." error with no test account created. Expected result: A test account created that I can use to test payment flows in the sandbox before submitting app for review. Any help here would be awesome so we can test before we submit this app! 🙏

In my application I have 3 types of monthly auto-renewing subscriptions. Pro 3.99$ Premium 2.99$ Standard 1.99$ A user who is already having a standard subscription plan, plans to upgrade to Premium after 15days of usage. In this case who is responsible for refunding the remaining amount on usage charge. If its developers responsibility what is the API to use and how to calculate refund.

Greetings, for the past 2+ weeks I have been going back and forth with the Apple Review team regarding the App Completeness rule. We are using React-Native-IAP package for our in-app purchases and have an issue where in the development environment using sandbox user the purchases show up without issues however when the project goes to review the review team is unable to see these purchases. We have tried explaining that you need to use a physical device as react-native IAP purchases do not work on simulators but have not reached a resolution. For example if we make a production build and run it on a physical IOS devices with sandbox users the purchases show up without issues. Can anyone advise what should be done, so it goes through the review? Even if you do not use react-native any help is welcome! Because this is devastating.

Hello, I'm trying to understand what happens when a subscribed customer of a subscription A purchases a promotional offer for the same subscription A. Let's say the product is a yearly subscription priced at $100. When the month 7 starts (6 months remaining in the regular subscription period), I send the user a promotional offer for the same product but priced at $25 for the first year (100$ afterwards) and he accepts the offer. Is the promotional offer started only at the end of the current year (after the 6 remaining months) or is it started immediately and he gets a pro-rata refund for the 6 remaining months? Thanks.

Hello, I am currently implementing server-side handling for in-app subscription payments and using App Store Server Notifications V2 to receive notifications with a TestFlight account. However, I am not receiving EXPIRED notifications, although I am successfully receiving other notifications such as SUBSCRIBED, DID_RENEW, and DID_CHANGE_RENEWAL_PREF. Here are some details of my observations: Until a certain point, I was receiving EXPIRED notifications without any issues, but they stopped coming in after that point. Each subscription renews every 3 minutes in TestFlight account, and I receive DID_RENEW notifications 7 to 12 times. According to the official documentation, the subscriptions should renew up to 12 times, but I am not receiving exactly 12 DID_RENEW notifications. This inconsistency might be related to the issue. Other notifications (SUBSCRIBED, DID_RENEW, DID_CHANGE_RENEWAL_PREF) are received without any issues. Could anyone provide insight into why this might be happening and suggest any alternative methods to handle subscription expirations in case the EXPIRED notifications are not reliable? Thank you for your assistance. Relevant Official Documentation App Store Server Notifications V2 App Store Server Notifications V2_notificationType Testing in-app purchases with sandbox Current Server Implementation Below is the Kotlin Spring Boot server code currently implemented for handling App Store Server Notifications V2: @RestController class ProductIosController( private val productIosService: ProductIosService, private val appStoreNotificationService: AppStoreNotificationService, ) : BaseController { @PostMapping("/api/v1/ios-products/app-store-notifications-v2") fun handleNotification(@RequestBody @Valid notification: AppStoreNotificationRequest): CustomResponse { appStoreNotificationService.processNotification(notification) return CustomResponse.ok() } } @Service class AppStoreNotificationService( @Qualifier("appStoreClient") private val appStoreServerAPIClient: AppStoreServerAPIClient, @Qualifier("signedVerifier") private val signedDataVerifier: SignedDataVerifier, ) { @Transactional fun processNotification(notification: AppStoreNotificationRequest) { logger.info("signedPayload: ${notification.signedPayload}") val decodedPayload = verifyAndDecodeSignedPayload(notification.signedPayload) val notificationType = decodedPayload.notificationType val signedTransactionInfo = decodedPayload.data.signedTransactionInfo val transaction = signedDataVerifier.verifyAndDecodeTransaction(signedTransactionInfo) val (user, product) = fetchUserAndProduct(transaction) when (notificationType) { SUBSCRIBED -> processSubscriptionPurchase(user, product, decodedPayload, transaction) DID_CHANGE_RENEWAL_PREF -> processSubscriptionGradeChange(user, product, decodedPayload, transaction) DID_CHANGE_RENEWAL_STATUS -> processRenewalStatusChange(transaction) OFFER_REDEEMED -> processOfferRedeemed(transaction) DID_RENEW -> processSubscriptionRenewal(user, product, decodedPayload, transaction) EXPIRED -> processSubscriptionExpiration(user, product) DID_FAIL_TO_RENEW -> processFailedRenewal(transaction) GRACE_PERIOD_EXPIRED -> processSubscriptionGracePeriodExpiration(transaction) PRICE_INCREASE -> processPriceIncrease(transaction) REFUND -> processSubscriptionRefund(transaction) REFUND_DECLINED -> processRefundDeclined(transaction) CONSUMPTION_REQUEST -> processConsumptionRequest(transaction) RENEWAL_EXTENDED -> processRenewalExtension(transaction) REVOKE -> processSubscriptionRevocation(transaction) TEST -> processTestNotification(transaction) RENEWAL_EXTENSION -> processRenewalExtension(transaction) REFUND_REVERSED -> processRefundReversed(transaction) EXTERNAL_PURCHASE_TOKEN -> processExternalPurchaseToken(transaction) else -> logger.warn("Unsupported notification type: ${notificationType.value}") } }