Hello, I have a question about subscription groups in in-app purchases. Suppose I create a subscription group like this: Subscription Group A Subscription Item A1 (one month) Subscription Item A2 (one week) Subscription Item A3 (one year) The documentation mentions, "A subscription group is made up of subscriptions with different access levels, prices, and durations so people can select the option that best fits their needs. Since people can only buy one subscription within a group at a time." Does this mean that if a user purchases Subscription Item A1 in Subscription Group A, they can only purchase other subscription items in Subscription Group A after the one-month period ends, when that subscription expires?

Hello, I have a question about server notifications. Let's say a user purchases a consumable item in-app. After successful payment, App Store sends a ONE_TIME_CHARGE notification to my server (assuming ONE_TIME_CHARGE is currently applicable in the production environment). This ONE_TIME_CHARGE notification contains detailed transaction information. If my server receives the ONE_TIME_CHARGE notification but fails to process it successfully, responding with an HTTP status code of 500, the App Store server will resend the ONE_TIME_CHARGE notification to my server after 1 hour. Suppose during this 1-hour interval, the user requests a refund and App Store approves the refund request. Will the transaction information in the next ONE_TIME_CHARGE notification sent by App Store to my server change? Will it be the same as the data in the first notification sent by App Store, or will it use the most up-to-date values?

Hello, I am currently encountering an issue while using the server-side API for in-app purchase integration. Suppose a user has already purchased a product, and the App Store returns a transactionId of 1. After some time, the user repeats the purchase for some reason, and the App Store returns a transactionId of 2. However, when I use the Get Transaction History interface to query the transaction information for transactionId 2, I see that the data returned by the App Store does not include the transaction data for transactionId 2; it only contains the transaction data for transactionId 1. In this situation, my guess is that when the user makes a repeat purchase, the App Store recognizes that the user has already purchased the item and has not executed a refund. Therefore, the App Store generates a new transactionId for this request (the user's purchase) and associates it with the previous purchase's transaction data. This is my inference. If this user has made 5 repeat purchases, when the user successfully requests a refund, if I query the transaction information through the Get Transaction History interface, will the revocationDate for all 5 transactions in the App Store's official database be modified to the same date? Additionally, after the user successfully refunds and makes another purchase, will the new transactionId still be associated with the previous transaction data?