Receipt Validation, Shared secret regenerated, Production and Sandbox use different Shared secrets

Question

yurii.s OP

Created Mar ’18

Replies 4

Boosts 0

Views 5.5k

Participants 3

Dear Apple Developer community,

Could anybody advice on the following situation.

Background:

There is an app published in the App Store with auto-renewable subscription available.

Receipt verification process is set up on backend side. The verification process utilizes master shared secret specified in iTunes Connect account.

(Mistakenly) the app’s master shared secret was regenerated. Currently in iTunes Connect account there is only this new shared secret.

Concerns:

1. Should previous shared secret still be valid?

The question comes from the fact that in production verification process succeeds with previous shared secret but fails with the new one (code 21004). At the same time in sandbox only new shared secret is accepted. Could it be expected behavior? May verification process be somehow dependent on build version when selecting shared secret?

2. How regeneration of new shared secret influences existing subscriptions in general? Is it sufficient to update shared secret on backend side?

3. Is it possible to revert to previous shared secret?

The main concern is that currently production and sandbox are using different shared secrets. Hence whether the previous shared secret can be relied on.

I would be very grateful for your help!

Answer 1

PBK OP

Mar ’18

One option is to do the same thing with 21004 as is done with 21007. Submit receipt with one shared secret. If it fails with 21004 submit it again with the other shared secret.

Answer 2

yurii.s OP

Mar ’18

Thank you for reply!

This approach will really backup an app in case of production switch to new shared secret. I'll ask my backend team for help.

Meanwhile I suppose I should direct this question to Code-Level Support.

Answer 3

yurii.s OP

Mar ’18

Addressed Code-Level Support. The shared secret on prod is updated to the new one.

Answer 4

OP

Apple

Mar ’18

This is a bug report. I had the same issue submitted to DTS last week. I think it took a day to fix the issue. Here's the instructions

The issue which you’ve submitted for support is a bug report. Please follow these instructions to submit the report.

1. Collect an appStoreReceipt from both environments and base64 encode each.

2. Go to the Apple Developer Bug Report web page and create a new bug report - http://bugreport.apple.com

3. Select the product “Other”

4. In the bug report, include the application ID

5. Include a text file which shows the base64 encoded appStoreReceipts for the sandbox and for the production environments.

Include the “old” and the “new” shared secrets

6. Describe the issue in the bug report description as you’ve described the issue here.

You can use the curl command-line tool in a terminal window to see the problem - where yyyy is the shared-secret and xxxx is the base64 encoded contents of the appStoreReceipt

user$ curl -d '{ "exclude-old-transactions": true "password":"yyyy" "receipt-data": "xxxx"}' https://sandbox.itunes.apple.com/verifyReceipt

user$ curl -d '{ "exclude-old-transactions": true "password":"yyyy" "receipt-data": "xxxx"}' https://buy.itunes.apple.com/verifyReceipt

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI