I am doing the application with Non renewable subscriptions. I am receiving the Status code 21007, while validating the Receipt , what should i do after receiving that status?
Thanks advance
21007
This receipt is from the test environment, but it was sent to the production environment for verification. Send it to the test environment instead.
Check this page AppStore receipt validation
Related
My organization validates receipts of purchases of our product from the App store using the verify receipt endpoint. Our logs indicate that beginning April 1, 2020, roughly 400 of these verifications failed with status code 503 being returned. This has resulted in these customers not appearing in our database as users of our product. How can I "synchronise" these "missed" users with our database? Ideally we could reverify all those "missed" receipts. Is there something these customers can do to re-send their receipt to our servers so that our servers can call the verify endpoint again?
Out of Apple's status codes for an in-app purchase (in Table 2-1 here), some should obviously be tried again, and some not and should be considered to say that the receipt in invalid.
But what about "21003 - The receipt could not be authenticated."? Is it similar to 21010 or to 21005? I.e. should this be sent again later or considered an invalid purchase?
From my experience, the "21003 - The receipt could not be authenticated." status is related to the App-Specific Shared Secret.
When you validate receipts with the AppStore, the App-Specific Shared Secret is used to set the value of the password field in the JSON request that you sent to the AppStore validation endpoint. (See Validating Receipts with the App Store documentation)
Keep in mind that according to Apple's documentation, this apps-specific shared secret is only necessary when validating receipt for apps that use auto-renewable subscriptions. However, in my experience, it might be worth setting it for any app receipt validation, just to avoid the 21003 error.
I am attempting to validate a receipt in the sandbox environment (https://sandbox.itunes.apple.com/verifyReceipt). The response looks successful and it is showing me the LatestReceiptInfo and any InApp transactions.
The part that is confusing me is that I am able to do it with an invalid secret as well. I am even able to verify with a receipt that was generated from a very different app. It appears as if validation is ignoring the shared secret entirely.
I would expect a status code of 21003 for the valid receipt that wasn't created by my app. I would also expect a 21004 for the invalid secret. In both cases I get a status code of 0 and the receipt is available.
There is something that I am not understanding about how verification works. Is this expected behavior for the sandbox?
Below is the response body that i am sending to verify.
{
"receipt-data": "MyReceiptData",
"password": "FakePassword",
"exclude-old-transactions": true
}
If your purchase item isn't an subscription. then apple will ignore the password.
Only verify the password when it's an subscription.
I've successfully setup my hub to use an SSL certificate per app, but I'd really like to move to the token-based APNs Auth Key approach. I configured my hub with I believe all the right information from the p8 file. For Key ID, I put in the 10-character value from when key was generated. For App ID, I put in my Team ID. For Token, I put in the private key value from the p8 file.
Has anyone had any success with this? Here's what happens when I attempt to send a test message:
When set to sandbox and I do a test send to my device, I get a failed outcome of "The Push Notification System rejected the request because of an invalid credential".
When set to production and I do a test send to my device, I get a failed outcome of "The Token obtained from the Token Provider is invalid"
For production, I think that is because I'm sending to a local app build outside of TestFlight/app store, so it is expecting the "development" or sandbox aps-environment.
Not sure what other troubleshooting I can do.
TIA,
I figured out what was happening for me.
The App Name field in the Azure Portal is critical to how the message gets delivered. Even though an APNs Auth Key can be used across multiple apps, the notification still must set the topic to be for that particular app. It seems like Azure Notification Hubs take the App Name field and put it into the apns-topic. Once I had that set to my app identifier, it worked as expected.
Also as an FYI, here is the link to the official documentation
https://learn.microsoft.com/en-us/azure/notification-hubs/notification-hubs-push-notification-http2-token-authentification
I am creating the backend for an iOSapp that has inapp purchase products in them.
The backend does the content serving stuff and validations of receipts and what not.
What bothers me is that there is no way to be sure that the product identifier entered in the backend is a valid one.
I know there is an API that can be called from the iOS to get a list of product identifiers for a specific app(was it company?), is there anyway to obtain this information from the backend so true validation of the entered identifier can be done?
Thanks in advance.
Once a user makes a valid purchase, you receive an encoded purchase receipt. To check if the purchase is valid, you need to send this receipt to Apple's validation servers. You'll receive a response indicating if the purchase was valid, and if it's valid - details about the purchase (purchase time, product ID, transaction ID, etc...).
I used the example code here and it was pretty easy and straight forward. Use the sandbox url as an endpoint while testing (including with TestFlight), and the production URL once the app is in the app store.
BTW, I would recommend generating a shared secret for your IAP (you can do it in iTunes Connect), and including it in your validation requests under a field called password:
private function encodeRequest() {
return json_encode(array(
'receipt-data' => $this->getReceipt(),
'password' => $sharedSecret));
}