我的应用内购买工作正常，我正在进行服务器验证路线。服务器需要知道我是否在沙盒中，所以现在我只是发送一个“＆amp; sandbox = 1”参数。当然，当应用程序的完整版本出来时，我将不会发送此参数。
我宁愿在我的应用程序中没有这个硬编码，因为这将使测试在将来变得困难，并且在向Apple提交构建之前记住更改是一件大事。
如果我在沙箱中，有没有办法可以询问StoreKit，那么我可以确定是否需要将此参数发送到我的服务器？或者，是否还有其他最佳实践来处理服务器验证？
考虑到这一点，我应该让服务器先检查实时系统，然后再检查沙箱吗？如果在实时和沙箱系统之间隔离苹果ID，那么它会不会造成任何伤害吗？
感谢。
答案 0 :(得分：63)
经过一番挖掘后，我发现了Apple的Technical Note TN2259：
如何验证收据（iOS）？
请务必先使用生产网址验证收据;如果您收到21007状态代码，请继续使用沙箱URL进行验证。遵循此方法可确保您在沙盒中测试或查看应用程序时无需在URL之间切换，或者在App Store中进行实时更新
所以看起来我应该完全扼杀&sandbox参数并且就这样做。我真的不得不去挖掘这个答案，所以我在这里发帖，希望别人能碰到它！
答案 1 :(得分：9)
我遇到了同样的问题，我的应用程序被拒绝，因为我提交的应用程序的“生产”版本是硬编码连接到我的服务器上的PHP脚本，验证了真实AppStore服务器的收据（而我的开发）构建指向另一个验证沙盒服务器收据的PHP脚本。然而，在与Apple工程师进行了一些交流之后，我发现他们使用沙盒用户帐户来测试提交的应用程序，这解释了他们出错的原因。
不是有条件地将我的应用程序构建为指向一个脚本或另一个脚本，而是使用单个脚本首先尝试生产服务器，然后如果收到21007状态代码则回退到沙盒服务器，如上所述！
非常感谢！
答案 2 :(得分：6)
请务必先使用生产网址验证收据;如果收到21007状态代码，请继续使用沙箱URL进行验证。
不幸的是，技术说明未提及这仅适用于自动续订订阅！
正如{7}中提到的In-App Purchase Programming Guide：
重要信息此处的非零状态代码仅适用于恢复有关自动续订订阅的信息。在测试其他类型产品的响应时，请勿使用这些状态代码。
对于非续订订阅，生产服务器不会返回状态代码，而是返回正确的收据。
如果您被迫使用非续订并实施自己的订阅过期逻辑，可能的解决方案是将您的应用版本发送到您的服务器，并跟踪当前正在开发的版本，因此您可以重定向到sandbox.itunes服务器以验证适当的收据，并模拟订阅的x分钟到期时间（如sandbox.itunes用于自动续订），以便在服务器上进行开发。