background
Recently before the APP was released, when testing a sandbox account to return to iOS in-app purchases, it was discovered that the corresponding rights and interests were not issued after the subscription items and consumption-type items were successfully purchased. Then through the interface log, it was found that it was the Apple ticket verification interface and returned 21003
an error code.
{
"environment":"Sandbox", "status":21003}
Looking through Apple's documentation , you can see 21003
the explanation of the error code:
21003
The system couldn’t authenticate the receipt.(系统无法验证票据)
Chasing the cause
Through analysis, the only recent change to in-app purchases is automatic renewal, because automatic renewal requires generating共享秘钥
The master shared key is the unique code used to receive receipts for all your auto-renewable subscriptions. To test or offer auto-renewable subscriptions, you must have a master shared key or generate an app-specific shared key for each app.
But Apple clearly said that it is required for automatic renewal projects 共享秘钥
, so we subconsciously think that consumable projects and non-renewing subscription projects do not require 共享秘钥
verification. But through testing we found out. Once we generate it 共享秘钥
, if the server does not pass the newly generated iPA package or the newly run package when verifying the ticket with the Apple server, then 共享秘钥
all the tickets in the in-app purchase will not pass the verification. .
solve
Through the Apple documentation, when our server verifies the ticket with the Apple server, it needs to 共享秘钥
pass password
the parameters so that the Apple server can verify it.
After adding 共享秘钥
it, all ticket verifications passed.