引言
在使用 Apple 提供的 StoreKit 框架集成应用内购（In-App Purchase, 简称 IAP）时，理解其完整的购买流程对于构建一个稳定的支付系统至关重要。不少开发者在初期只关注“购买成功”的正向流程，却忽略了整个交易链条中可能出现的失败、中断或异常情况。
尤其是涉及虚拟商品、会员订阅等场景时，一旦支付流程中断或状态未同步，可能导致“用户已付费但没有获得商品”的严重问题，俗称 漏单。
“漏单”是指用户在 App Store 成功付款，但由于客户端或服务端某个环节处理失败，订单状态未能正确同步，导致商品未到账。这种情况在实际开发和运营中并不少见，常见原因包括：
用户付款后强退 App网络波动导致回调未执行票据验证失败或超时客户端与服务端之间的通信异常
为了提升用户体验并避免投诉甚至退款，在流程设计中引入完整的“漏单处理机制”是非常必要的。
苹果支付的基本流程简述
在实际项目开发中，iOS 内购（IAP）通常需要客户端与后端服务协同配合，确保订单流程闭环、支付安全可靠。一个典型的支付流程通常包含以下几个步骤：
1.创建订单（服务端）
用户在客户端选择购买商品后，首先需要请求后端生成一笔待支付订单。此订单可包含商品 ID、用户标识、订单号等基础信息，便于后续追踪。
2.发起支付（客户端）
客户端通过 StoreKit 接口发起苹果支付请求，系统弹出支付界面，用户进行指纹、人脸或密码验证后完成付款。
3.获取收据（客户端）
支付成功后，系统会生成一段 Base64 编码的交易收据（receipt），可通过 Bundle.main.appStoreReceiptURL获取。
4.验单（服务端）
客户端将收据传给后端，由后端调用苹果的验证接口（Sandbox 或 Production 环境）校验支付有效性，确认订单真实性和金额合法性。
5.发放商品或服务（服务端）
验证通过后，后端更新订单状态并向客户端反馈支付成功，客户端再完成商品发放或权限开通等操作。
通过这种“客户端发起 + 服务端验证”的模式，既满足苹果支付的合规要求，也增强了安全性和业务可控性。
漏单处理
然而，即使流程设计合理，实际运行中仍可能出现漏单问题。所谓“漏单”，是指用户在 App Store 完成付款，但客户端或服务端未能正确记录或处理该笔交易，导致商品未发放、服务未开通，影响用户体验甚至引发投诉。
下面我们将从常见漏单原因出发，结合实际开发经验，深入探讨漏单的成因与应对方案。
一、漏单的常见成因
1.支付完成后 App 被强退或崩溃
用户在完成支付后尚未走完票据上传或发放流程时，强行关闭 App，导致收据未被提交，订单未完成。
2.网络异常或中断
在上传收据或等待服务端响应的过程中发生网络中断，导致验单失败，客户端未做重试处理。
3.客户端未持久化收据
某些项目未对交易票据进行本地缓存，重启 App 后丢失支付信息，造成无法恢复处理。
4.服务端验单逻辑不完善
服务端未处理幂等、验签、状态更新等逻辑，或未记录失败验单进行补偿，导致订单卡死。
5.使用非消耗型商品但未调用 finishTransaction
客户端未调用 SKPaymentQueue.default().finishTransaction(_:)，导致苹果系统保留该交易，造成后续混乱。
二、客户端漏单应对方案
针对漏单问题，客户端层面可以采取以下两种策略进行补偿处理，确保支付流程闭环：
1. 检查未完成支付流程的订单
在某些情况下，用户完成了支付，但由于 App 崩溃或网络异常，未能正常触发收据上传或验单流程。此时应在 App 启动或合适的时机，主动检查本地是否存在未处理的订单记录：
ZMLogHepler.debug(content: "检查漏单1 orderId:\(orderId)", context: "ZMPayHepler")
ZMAppPayManager.shared.checkOrder { [weak self] result, error in
guard let self = self else { return }
guard let result = result, !result.isEmpty else {
ZMLogHepler.error(content: "无漏单", context: "ZMPayHepler")
return
}
ZMLogHepler.debug(content: "检测到漏单1", context: "ZMPayHepler")
self.requestVerifyOrder(orderId: orderId, receipt: result)
}
/// 校验漏单
func checkOrder(resultBlock: @escaping((_ result: String?,_ error: Error?) -> Void)) {
// 监听购买结果
SKPaymentQueue.default().add(self)
self.payCompletion = resultBlock
ZMLogHepler.debug(content: "检查漏单", context: "ZMAppPayManager")
}
这里的 checkOrder 方法可以理解为对本地订单缓存和 StoreKit 队列中未完成交易的巡检，发现“已支付但未验单”的订单后，重新提交至服务端验单处理。
2. 检查已完成支付但收据未上传的情况
另一种漏单场景是：收据已生成，但由于网络或逻辑错误未及时提交至服务端。此时可在本地缓存收据，例如使用 UserDefaults 持久化存储，并在适当时机（如 App 启动、用户登录等）进行补偿性验单：
ZMLogHepler.debug(content: "检查漏单2 orderId:\(orderId)", context: "ZMPayHepler")
var receipt = UserDefaults.standard.string(forKey: "receipt" + userId)
if receipt == nil || receipt?.isEmpty == true {
ZMLogHepler.debug(content: "收据为空", context: "ZMPayHepler")
clearOrderInfo()
return
}
ZMLogHepler.debug(content: "检测到漏单2", context: "ZMPayHepler")
self.requestVerifyOrder(orderId: orderId, receipt: receipt)
这种方式保证了即使在验单失败或用户断网的情况下，也能在后续重试中完成补单操作。
结语
漏单问题虽然在苹果支付流程中不是常态，但一旦发生，对用户体验和产品口碑都会造成直接影响。我们无法避免所有异常，但可以通过合理的本地缓存、异常检测与补偿机制，在客户端构建起一道安全网。
建议在开发中始终秉持以下原则：
所有交易收据必须持久化存储支付流程必须具备重试与幂等逻辑日志与监控应完整记录每一笔支付的状态变迁对于未完成订单，应在 App 启动或关键场景中进行自动补单
只要流程闭环、机制健全，哪怕支付链条中某个环节出现问题，也能最大程度地保障用户权益、降低损失。希望本文的思路和实践代码，能为你的漏单处理方案提供借鉴。