fxf*_*ure 5 validation sandbox in-app-purchase ios
我按照Ray Wenderlich的教程在我的应用程序中实现收据验证.代码直接从我的应用程序连接到Apple的验证服务器,而不是通过我自己的服务器.
在我将第一个二进制文件提交到AppStore之后,我测试了我的应用程序并且应用内购买无效,因为我已将其从沙箱URL切换到生产URL.
当他们的AppStore评论员测试它并因此被拒绝时,这也会失败吗？我已经阅读过这篇文章,但如果我不使用自己的服务器,我仍然很困惑这是否适用于我.
vig*_*o24 10
解决方案非常简单,并且在WWDC 2012的会话308上进行了解释(该视频可供注册开发人员使用).该会话与订阅相关,但您可以在应用购买中扩展它.
当您开发硬编码应用程序以使用沙箱验证收据时会发生什么.然后,您发送应用程序进行审核,您清楚地对应用程序进行了硬编码,以便使用生产服务器验证收据.
但没有什么能阻止您分两步进行验证:
顺便说一句,这仅在订阅的文档中正式声明,如果您尝试使用生产服务器验证沙箱收据,您将获得特定的状态代码; 还有另一个状态代码,涵盖了使用沙盒服务器验证的生产收据的情况.在所有情况下,沙箱和生产这两个世界总是分开的.
不要忘记,iOS7添加了一种新的更安全的方式来直接从设备管理收据验证:事实上,考虑直接从客户端(您没有完全控制,例如使用越狱设备)的收据验证不如通过您控制的服务器完成收据验证.
始终首先使用生产URL验证收据; 如果您收到21007状态代码,请继续使用沙箱URL进行验证.遵循此方法可确保您在沙盒中测试或查看应用程序时不必在URL之间切换,或者在App Store中进行实时更新.
注意:21007状态代码表示此收据是沙盒收据,但已将其发送到生产服务进行验证.
没有公共API可以调用来区分生产环境和沙箱环境,以便您可以提前决定使用哪个服务器.如果您已实施建议的收据验证过程,则可以在与StoreKit服务器联系的服务器上实施此修复.如果验证尝试的状态代码是21007,请在沙盒服务器上再次尝试.