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.
Related
I have a web app with following 3-step flow using Twilio Verify for email verification:
Creating verification code with Verify
Checking verification code with Verify
Create user account in my web api
After a successful Twilio Verify verification code check (step 2), I need to be able to do another Twilio Verfy call to ensure that the email was verified before a user account is actually created in my web api (step 3). But since the SID is deleted after successful email verification, I get following answer for a GET request to:
https://verify.twilio.com/v2/Services/{ServiceSid}/Verifications/{Sid}
{
"code": 20404,
"message": "The requested resource /Services/VAxxx/Verifications/VExxx was not found",
"more_info": "https://www.twilio.com/docs/errors/20404",
"status": 404
}
Now, for the Frontend, it's easy: I move to the final account creation step only if the email was verified successfully.
But, for a true stateless Backend, after accepting the Frontend request I first need to double-check with Twilio if the email was actually already verified.
True stateless in the sense that I do not want to store in a DB if an email was already verified or not. (This is already done by Twilio)
How can I do that? I didn't find the right API in the Twilio documetaion.
Twilio developer evangelist here.
I understand that you would like to get the information that appears available in the logs, however that is not available through the API. Once a verification has succeeded (or timed out after 10 minutes, or reached the maximum number of incorrect attempts) it is deleted and you can no longer access it through the API. I assume this is to prevent replay attacks, but I’m not on that team, so don’t know all the reasons behind it.
The result of this is that you cannot call on the verification check more than once from your code.
You will have to store the state within your own system because the API will not store that state for you. Much like during login with 2FA you would need to store the state that a password had been successfully entered.
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'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 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
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));
}