一、官方收据验证方法 #

Apple提供的服务器端收据验证API是验证用户凭证真实性的唯一可靠途径（客户端验证不可信），具体操作如下：

• 要求用户提供完整交易凭证：比如从App Store账户「购买记录」导出的收据文件，或Apple发送的交易确认邮件中的收据附件（需包含transactionId、receipt-data等核心字段）
• 服务器端执行验证：
  1. 优先调用生产环境验证接口，若返回「沙箱环境收据」错误，再切换到沙箱接口重试
  2. 将base64编码后的receipt-data作为参数发送至接口
  3. 解析返回结果时重点核对：
     • status字段为0（验证通过）
     • 交易的product_id与你应用内的付费产品ID一致
     • transaction_id/order_id与用户提供的信息匹配
     • is_in_retry_period为false（无退款或撤销记录）
     • 购买时间与用户反馈的交易时间吻合

二、丢单问题的最佳实践 #

针对用户未点击确定就退出、网络故障导致receipt未发送的情况，核心方案是脱离用户交互，本地持久化+后台重试：

• 监听支付成功回调：在SKPaymentTransactionObserver的paymentQueue:updatedTransactions:方法中，只要交易状态变为.purchased，立即将receiptData持久化到本地（推荐用Keychain，避免应用卸载丢失），同时触发服务器发送逻辑
• 取消系统弹窗依赖：Apple的成功提示框是系统级交互，用户点击「确定」仅关闭弹窗，不代表交易未完成——交易状态变为.purchased时，已属于支付成功，无需等待用户操作弹窗
• 启动自动重试：每次应用启动时，检查本地是否存在未成功发送的receiptData，自动触发发送逻辑
• 指数退避重试：若发送失败，设置指数退避的重试间隔（如1分钟、5分钟、15分钟），避免频繁请求服务器，超过重试阈值则标记为待人工处理

三、用户反馈后的处理流程 #

当用户提供收据申请补加积分时，遵循以下流程：

• 收集必要信息：除收据外，还要收集用户账户ID、交易时间、购买产品名称，方便后续核对
• 服务器端验证：按上述官方方法验证收据真实性，同时检查该transactionId是否已被处理（避免重复发积分）
• 验证通过操作：给用户账户添加对应积分，在服务器端记录该transactionId的处理状态并生成操作日志
• 验证失败处理：告知用户收据无效，引导其重新提供正确凭证，或建议联系Apple支持查询交易状态

内容的提问来源于stack exchange，提问作者Tuấn Anh Nguyễn