应用内购买验证证书问题
我得到的答复如下。
{"status":21002, "exception":"java.lang.NullPointerException"}
我仅使用 Base64 对收据进行编码。
我正在沙箱中测试它。
会出现什么问题呢？谁能帮助我吗？
I am getting the response as below.
{"status":21002, "exception":"java.lang.NullPointerException"}
I am encoding the receipt using Base64 only.
I am testing it in sandbox.
What will be the problem? Can anyone help me?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
大家好，我得到了解决方案，
只需在使用键“receipt-data”将收据数据编码为 64 位 json 后发送即可
hi all i got the solution
just send the receipt data after encoding into base 64 as json with key "receipt-data"
VIP 值得注意的是，21002 也是您在尝试验证通过 root iTunes 黑客软件（如 Urus 应用程序）发起的交易时收到的消息。
我们在服务器端验证所有交易，因此不依赖于设备，唯一获得 21002 响应的交易都不是真正的付款。
一种简单的方法来发现它，查看 Urus 返回的交易 id 给出 com.urus.iap.XXXXXXX （x 是随机数），其他方法包括返回包名称作为完成的交易 id，所有这些都与您获得的 id 非常不同来自各个 iTunes 服务器。
我不能建议每个人都在一个您可以控制、测试和证明的环境中验证服务器端，并且该环境不能被操纵（除非您被黑客攻击）。如果这不是一个选项，则不要对 21002 响应进行支付。
在 java 环境中验证 21002 的 json 响应将是：
json: {"status":21002,"Exception":"java.lang.ClassCastException"}
VIP Worth noting that 21002 is also the message you get back when trying to verify a transaction that was initiated via rooted iTunes hack software like the Urus app.
We verify all transactions server side, so are not device dependant, the only transactions that get the 21002 response are ALL not real payments.
an easy way to spot it to look at the transaction id returned Urus gives com.urus.iap.XXXXXXX (x being random numbers), other ones include returning the pack name as the completed transaction id, all very different to the id's you get from the various iTunes servers.
I can't recommend more that everyone verifies server-side in an environment you can control, test and prove, that cant be manipulated (unless your hacked). If this is not an option, then do not pay out on a 21002 response.
verifying in a java environment the json response for the 21002 will be:
json: {"status":21002,"exception":"java.lang.ClassCastException"}
我们遇到了同样的问题 - 直到我们发现我们没有在请求中包含帖子正文，而只发送了一个空请求。
We had the same problem - until we discovered that we didn't include the post body in the request and only sent an empty request.
经过两天的头撞墙后，唯一对我有用的选择：
在沙箱中测试
注意苹果的这个建议
“重要提示请勿在“设置”应用程序中使用您的测试帐户登录。”
在编码为 Base 64 之前，请确保在测试设备上您已退出“测试”Apple Store 帐户。
The only option that work for me after 2 days of hitting my head against the wall:
Testing in the sandbox
Pay attention to this advice by apple
"Important Do not sign in with your test account in the Settings application."
Make sure on the test device you are signed out of the "test" apple store account before encoding to base 64.