The App Store Connect Review team would reject the submission because they deem the behavior described above as violations of "5. 1.1 Legal: Privacy - Data Collection and Storage" for attempting to collect user data or "Guideline 2.1 - Performance - App Completeness" when they refuse to enter the AppleID credentials and fail the validation. The App Store Review team rejects the submission and insists that we must change the app. We had to go through a 3 week back and forth appeal to get on the phone with a representative to eventually pass the review. We implemented Receipt Validation through SKReceiptRefreshRequest according to When beta tester and App Store Connect Review team download our app for the first time from TestFlight or the Review team internal channel, and when the app calls SKReceiptRefreshRequest, the user will be prompted to manually enter their Apple ID and Password. I have submitted a feedback through Feedback Assistant, but I want to share my experience here in case any other developers suffer the same experience we did: How can I obtain it?Ĭan I somehow call App Store Connect API?
APP FOR RECEIPTS CODE
The used code doesn't seem to be included in the latest receipt. Test Offer Code | xadz | zzz | 31-07-2022 | t | f
Reference_name | code | url | expires_at | used | reserved I would be able to identify the Reference name by the code, if it was provided, because I have the following table in my app's backend: (expected was sth like offer_code_ref_name="JFFDS61SBJDBJ5BXJS4BX") Instead I received the Reference name in the payload from the App Store Server Notification in the field offer_code_ref_name="Test Offer Code". I was able to redeem the code and everything works, but I was expecting to receive the used code. I just configured a Test Offer Code (Reference name), which contains 500 codes (Offer Codes) to buy a 1-month subscription for 0,49€. I would like to programmatically keep track of offer codes that have been used. We could mitigate this by returning something like a failure status to our own client's request, but how are we supposed to test our code for parsing the response object when a receipt is valid? What's going on?
APP FOR RECEIPTS PASSWORD
We are sending a valid sandbox receipt (validated locally on device already), along with the shared secret / password parameter, and not getting any receipt info back, just this bogus status that should only be returned by the production URL. Following this approach ensures that you do not have to switch between URLs while your application is tested, reviewed by App Review, or live in the App Store.
Verify your receipt first with the production URL proceed to verify with the sandbox URL if you receive a 21007 status code. Similar to what appears to have happened last year, the Sandbox verifyReceipt endpoint is returning the 21007 status code that should only be returned by the production URL and indicates that the receipt in question should instead be sent.
0 kommentar(er)
