iOS应用内购接入流程中，收据验证是保证交易真实性的最后一道关卡。但在沙盒测试阶段，大量开发者会遇到验证失败的问题：有的返回21002错误，有的返回21007，还有的HTTP状态码明明是200却依然验证不通过。这篇文章将围绕沙盒环境URL、共享密钥以及状态码200的假成功陷阱三个核心问题，详细讲解排查思路与解决方案。
一、沙盒环境与生产环境的验证URL到底该用哪个
苹果提供了两个收据验证接口：https://buy.itunes.apple.com/verifyReceipt用于生产环境，https://sandbox.itunes.apple.com/verifyReceipt用于沙盒环境。这两个端点的请求格式完全一致，但它们验证的收据来源不同。一个常见错误是：测试阶段使用沙盒账号购买了商品，却把收据发到了生产环境URL去验证，结果苹果返回status为21007，提示该收据是沙盒收据。
实际上，status等于21007并不算真正的故障，而是一个明确的提示信号。推荐的工程化做法是：首先将收据发送到生产环境验证，如果返回21007，再自动转发到沙盒环境重新验证。这种双端点验证策略的好处是，应用无需关心当前用户处于沙盒还是生产环境，因为沙盒账号在生产环境的审核阶段（App Review使用沙盒环境测试）也可能被触发。下面是一段典型的服务端验证代码：
func verifyReceipt(receiptData: Data, completion: @escaping (Bool) -> Void) {
let receiptString = receiptData.base64EncodedString()
let body: [String: Any] = ["receipt-data": receiptString,
"password": SHARED_SECRET]
// 先请求生产环境，失败且返回21007时回退到沙盒环境
requestVerify(url: "https://buy.itunes.apple.com/verifyReceipt",
body: body) { status in
if status == 21007 {
self.requestVerify(url: "https://sandbox.itunes.apple.com/verifyReceipt",
body: body) { sandboxStatus in
completion(sandboxStatus == 0)
}
} else {
completion(status == 0)
}
}
}
需要特别注意的一点是：本地收据验证（通过NSBundle的appStoreReceiptURL获取）在沙盒和真机上行为一致，但如果在模拟器上测试，旧版本的Xcode模拟器没有收据文件，必须使用真机或新版模拟器进行测试，否则连收据都拿不到，更谈不上验证。
二、共享密钥配置错误导致的21002与21003
共享密钥（Shared Secret）是一个32位的十六进制字符串，在App Store Connect中的应用信息页面生成。它的作用是为自动续期订阅类商品的验证请求提供身份凭证。如果你的应用包含订阅类内购，验证请求的body中必须携带password字段，值为这个共享密钥。
21002错误表示收据数据无法解析或格式非法，常见原因有两个：一是Base64编码环节出了问题，比如对已经是Base64字符串的数据又做了一次编码；二是共享密钥格式错误，苹果收到非法的password字段时也可能返回这个码。21003则表示收据无法通过真实性验证，通常发生在收据被篡改或签名不匹配的场景。排查时可以按以下顺序检查：
- 确认共享密钥是从App Store Connect正确复制的完整32位字符串，没有多余空格和换行符
- 确认请求的Content-Type为application/json，body是合法的JSON结构
- 确认receipt-data字段是对原始收据二进制数据做的一次性Base64编码
- 确认生产与沙盒使用的是同一个共享密钥，密钥不区分环境
另一个容易被忽略的细节是，如果验证的是消耗型商品且不涉及订阅，理论上可以不带password字段。但为了统一处理逻辑，建议所有验证请求都携带共享密钥，这样后续增加订阅商品时无需改动验证模块。此外，共享密钥属于敏感信息，必须存放在服务端，绝不能硬编码在客户端二进制中，否则可能被逆向提取并用于伪造验证请求。
三、状态码200却验证失败：读懂body中的status字段
这是最具有迷惑性的一个陷阱。verifyReceipt接口无论验证成功与否，HTTP状态码几乎总是返回200。真正的验证结果藏在响应body的status字段中：status等于0才表示收据有效，其他任何值都代表不同类型的失败。如果客户端代码只判断了HTTP状态码而没有解析body，就会产生验证通过的假象。
常见的status值含义整理如下：
| status值 | 含义 | 处理建议 |
|---|---|---|
| 0 | 收据验证成功 | 解析收据内容，发放商品 |
| 21000 | App Store无法处理请求 | 重试，多为临时故障 |
| 21002 | 收据数据格式非法 | 检查Base64编码与请求结构 |
| 21003 | 收据无法通过验证 | 收据可能被篡改，拒绝交易 |
| 21007 | 沙盒收据发到了生产环境 | 转发到沙盒URL重新验证 |
| 21008 | 生产收据发到了沙盒环境 | 转发到生产URL重新验证 |
| 21010 | 用户账户不存在（仅限自动续期订阅） | 引导用户重新订阅 |
除了status字段，响应中的latest_receipt_info数组在订阅场景下也十分关键，它包含所有有效的交易记录。验证通过后应该遍历该数组，根据product_id判断用户当前的订阅状态，而不是只看单条交易。同时建议开启exclude-old-transactions参数，让苹果只返回最新的续订记录，减少无意义的数据传输。
四、沙盒测试的其他注意事项
沙盒环境与生产环境在行为上存在若干差异，测试时要有心理预期。第一，沙盒环境的自动续期订阅周期被大幅压缩，一个月的订阅在沙盒中几分钟就会自动续订多次，随后苹果会主动取消订阅，这是正常现象。第二，沙盒账号必须先在设备上登录App Store设置中的沙盒账户，且不能与真实Apple ID混用，如果系统弹出的是真实账号登录框，说明当前处于生产环境交易。第三，沙盒收据在生产环境验证会返回21007，反之生产收据在沙盒环境验证会返回21008，这两个状态码是实现自动切换验证端点的依据。
最后需要提醒的是，苹果已经在推动新的App Store Server API与StoreKit 2，新的验证方案基于JWS签名的本地验证，不再依赖verifyReceipt接口。对于新项目，建议优先采用StoreKit 2的Transaction.currentEntitlements进行本地验证，服务端则配合App Store Server API查询用户订阅状态。但理解传统的verifyReceipt验证机制依然有价值，因为存量项目和技术排查都离不开这套体系。掌握沙盒URL选择、共享密钥配置和status错误码解读这三个核心点，内购验证的绝大多数问题都能迎刃而解。