iOS应用内购的优惠码兑换功能上线后，一个高频反馈是：用户在兑换界面输入优惠码并且看到“兑换成功”的提示，但客户端这边既没有触发购买回调，也没有解锁对应权益。问题的根源大多不在兑换流程本身，而在于对presentCodeRedemptionSheet的完成处理程序以及交易通知机制理解不到位。这篇文章把整个链路拆开讲清楚，并给出可直接落地的代码方案。
一、先弄清楚presentCodeRedemptionSheet的回调机制
presentCodeRedemptionSheet是SKPaymentQueue提供的一个实例方法，用于弹出系统级的优惠码兑换界面。它的方法签名里确实带有一个completionHandler，但很多开发者误以为这个回调会在“兑换成功”时被调用并携带交易信息，这恰恰是第一个误区。
实际上，这个完成处理程序只负责告诉你“兑换界面是否成功弹出”或者弹出过程是否出错，它不承载任何兑换结果。换句话说，当用户真正输入优惠码并完成兑换后，系统走的是标准的交易流程：一笔新的交易会被投递到支付队列，由你注册的队列观察者接收。如果你把业务逻辑写在完成处理程序里，自然什么都收不到。
// 只能感知弹窗是否成功，拿不到兑换结果
[[SKPaymentQueue defaultQueue] presentCodeRedemptionSheet:^(NSError * _Nullable error) {
if (error) {
NSLog(@"兑换界面弹出失败: %@", error.localizedDescription);
} else {
NSLog(@"兑换界面已弹出，等待用户操作");
}
}];
Swift版本同理。注意这个方法的调用前提是设备支持该功能（iOS 14.1以上），在不支持的系统上调用会直接返回错误码。所以在做入口按钮的显隐判断时，建议先检查系统版本，避免老设备用户点了没反应。
二、StoreKit 1方案：交易靠队列观察者接收
如果项目还在使用StoreKit 1，优惠码兑换产生的交易和普通购买走的是同一条路：SKPaymentQueue投递SKPaymentTransaction。你要做的就是确保在应用启动的最早期注册观察者，这也是苹果官方反复强调的最佳实践。
一个常见的坑是：观察者注册得太晚。用户完成兑换后交易已经进入队列，如果此时观察者还没挂上，交易就会被延迟处理；更糟糕的情况是，开发者在回调里没有正确调用finishTransaction，导致交易反复投递，形成“每次启动都收到回调”的诡异现象。正确的写法应该把addTransactionObserver放在application(_:didFinishLaunchingWithOptions:)里第一行执行。
class IAPManager: NSObject, SKPaymentTransactionObserver {
override init() {
super.init()
// 必须尽早注册，最好在启动方法里完成
SKPaymentQueue.default().add(self)
}
func paymentQueue(_ queue: SKPaymentQueue,
updatedTransactions transactions: [SKPaymentTransaction]) {
for transaction in transactions {
switch transaction.transactionState {
case .purchased, .restored:
handleSubscription(transaction)
queue.finishTransaction(transaction) // 务必调用
case .failed:
queue.finishTransaction(transaction)
default:
break
}
}
}
private func handleSubscription(_ t: SKPaymentTransaction) {
// 优惠码兑换成功后，这里会收到 .purchased 状态的交易
// 校验transactionIdentifier和originalTransaction后解锁权益
}
}
还有一个容易被忽略的细节：优惠码兑换的交易，其payment属性可能为nil（因为不是由应用主动发起的SKPayment），所以不要在回调里强解包transaction.payment，判断状态时以transactionState为准，否则会直接崩溃。
三、StoreKit 2方案：监听Transaction.updates才是正解
iOS 15以后推荐使用StoreKit 2。新API下没有队列观察者的概念，取而代之的是Transaction.updates这个AsyncSequence。优惠码兑换成功后，新交易会从这个流里吐出来，你要做的是在应用生命周期的起点就启动监听，并保持这个Task存活。
@main
struct MyApp: App {
var body: some Scene {
WindowGroup { ContentView() }
}
init() {
// 启动即监听，确保兑换交易不遗漏
Task.detached {
for await update in Transaction.updates {
if case .verified(let transaction) = update {
await unlockEntitlement(transaction)
await transaction.finish()
}
}
}
}
private func unlockEntitlement(_ t: Transaction) async {
// 优惠码兑换的订阅在这里处理权益发放
}
}
兑换入口在SwiftUI环境下可以用offerCodeRedemption(isPresented:onCompletion:)修饰符，它的onCompletion同样只报告弹窗层面的结果（是 dismissal 还是 failure），真正的交易仍然只能从Transaction.updates或当前待处理列表里拿。除了监听增量流，还应该在界面进入前台时调用Transaction.currentents遍历一遍未finish的交易，做一次兜底，这样即使用户兑换后直接杀掉了应用，下次启动也能恢复权益。
四、排查清单与沙盒环境的特殊性
如果代码结构看起来都对，还是收不到回调，按下面几条逐项排查。第一，确认沙盒账号在设备上已经登录（设置里App Store登录沙盒账户），优惠码兑换在未登录状态下会静默失败。第二，沙盒环境下兑换码的到账有明显延迟，有时要等一两分钟交易才投递，不要以为立即没有回调就是失败。第三，检查证书环境：TestFlight构建无法使用开发环境的优惠码，本地调试要用Xcode运行的StoreKit配置文件或者真机沙盒。
第四，检查finishTransaction是否遗漏。未finish的交易在沙盒里会导致后续交易排队阻塞，表现就是新兑换的交易“看起来没回调”，实际上被卡在队列前面那笔未完成交易后面。可以在-paymentQueue:removedTransactions:里打日志确认队列消化情况。第五，服务端如果依赖App Store Server API的通知，别忘了配置App Store Server Notifications V2，客户端回调和服务端通知双保险，才是生产环境的稳妥做法。
总结一下核心结论：presentCodeRedemptionSheet的完成处理程序只管弹窗，不管结果；兑换成功后的交易一律通过支付队列观察者（StoreKit 1）或Transaction.updates（StoreKit 2）接收。把监听注册提前到应用启动、处理好未finish交易的兜底逻辑，再结合沙盒环境的排查要点，这个“兑换成功无回调”的问题就能彻底解决。
iOS内购presentCodeRedemptionSheet优惠码兑换修改时间：2026-09-07 21:47:02