Anyone else having issues with sandbox receipt validations today? (Apr 6)

Same here, same dates, same older receipt

It turns out that iTunes Production Support is aware of this problem. While I can't explain the cause of the problem, when an applicationReceipt generated in the sanbox environment is validated against the production Validation server, status result 21002 will be returned. iTunes Production Support is investigating a fix to this issue. This "unexpected" result only occurs with processing sandbox applicationReceipts with the production validation server.

I'm told that at some point, the validation of sandbox applicationReceipts against the production validation servers will result in the expected result - 21007. I have not been provided a date as to when this correction will occur. I've informed those that I report to that this is a big deal and affects all developers of applications with in app purchases who implement receipt validation.

One workaround for this situation is to see that the 21002 result is being returned when validating the applicationReceipt against the production server, and to treat this status result the same as 21007. Then the receipt validation process should attempt to validate the receipt with the sandbox Receipt Validation server. If status 21002 is returned from the sandbox server, then there is likely an actual base64 coding issue with the receipt.

One note - while this is clearly a "bug" with the receipt validation process, the issue is somewhat eased if the server receipt validation process were implemented as described in the Receipt Validation Program Guide

<https://developer.apple.com/library/ios/releasenotes/General/ValidateAppStoreReceipt/Introduction.html>

In the section regarding receipt validation with the App Store, the recommendation is to implement a trusted server which the app communicates with to pass along the base64 encoded receipt. The trusted server then forwards the receipt first to the production receipt validation server. If the validation attempt returns status 21007, the base64 encoded receipt is forwarded to the sandbox validation server. With this design, it would be a temporary change to check the status from the production validation server for the 21002 status and to retry the validation process with the sandbox server. When this issue gets fixed, the trusted server process can then be restored to the original validation code path. With such a receipt validation design, the issue is moved to the trusted server to be addressed rather than within the application code.

One final note, it is expected that once the application passes App Review, the application processing the production applicationReceipt against the iTunes production Receipt Validation server, should have the receipt validated as expected.

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

What is an "applicationReceipt"? Are you confirming that this is a problem with the deprecated transaction.transactionReceipt or is it more extensive?

It seems to be fixed now

Are you now reporting that a transaction.transactionReceipt now works (returns a 21007) or that a new receipt works?

Hi folks - my devs are telling me that the old format receipt is still failing as described (receiving 21002 instead of 21007).

The applicationReceipt is the one accessed by

NSURL *receiptURL = [[NSBundle mainBundle] appStoreReceiptURL];

The issue has to do with the fact that a different signing certificate is now used in the production environment. The signing certificate has not been updated in the sandbox environment. When the sandbox receipt is passed to the production vaidation server, the signing certificate doesn't match, so status 21002 is returned instead of status 21007.

I've sent requests to DTS management to request that iTunes move forward with the signing certificate update in the sandbox environment so that the two environments use the same certificate.

I haven't tried to validate a sandbox transactionReceipt with the production server, but if the same issue occurs, the workaround would be the same.

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

Interesting; no one in this thread seems to be complaining about 21002 coming from a new receipt, only from old receipts. I haven't tried either in awhile.

This is fixed for us too, sandbox seems to work again when we tried yesterday. We use the old style receipts (SKPaymentTransaction.transactionReceipt).

Well, I created a new sanbox test account, then succeed.

Rich we are still getting this issue. Just started 2 days ago. Everything was working fine. Now same error for every IAP in testing. Also had an app waiting for review that was tested and worked perfectly last week. Now it is rejected for this issue because the reviewer can't test it either. What do you suggest? Are we just stuck until Apple decides this is important enough to fix? Thanks.

Which error are you referring to? The 21002 coming from old receipts? The 21002 coming from the new receipts? Or something else? In ALL of those cases (except for the 'something else') the solution is quite simple and stated above - if you get a 21007 or a 21002 from a receipt tested against the Production server then send it to the Sandbox server to see if it is a sandbox receipt. A more elegant solution would be that if you get a 21002 or 21007 check your website to see if you are still in the approval mode and if not reject the receipt.

And if the answer is 'something else' then perhaps this thread will be relevant:

https://forums.developer.apple.com/thread/47218

If the failure started occurring 2 days ago - have you taken a look at the following forum posting

<https://forums.developer.apple.com/thread/47218>

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

I'm having the same issue (21002) in sandbox test account. It happens randomly.

Will the approved app will make users experience the same thing?

I thought the cause is belong to base64_encode.

@pwinterhalder Have you fixed it?