Flutter实现微信支付和iOS IAP支付，高薪程序员必会

void dispose() {
WidgetsBinding.instance.removeObserver(this); //销毁观察者
super.dispose();
}

/// 应用状态监听
@override
void didChangeAppLifecycleState(AppLifecycleState state) {
switch (state) {
case AppLifecycleState.resumed:
{
if (Platform.isAndroid && _isPaying) {
_isPaying = false;
// 监听到时安卓设备并且支付还在进行中，程序员要根据业务做一下处理
break;
}
default:
break;
}
super.didChangeAppLifecycleState(state);
}
}

到此，微信支付很愉快的解决了，以上代码是抽象出来的工具类，可以直接使用；但是不涉及任何业务流程的开发，这个需要使用者自己去补充。 综上，微信支付流程主线可简单粗暴总结为：服务端生成订单 → 客户端调起支付 → 客户端通知服务端核验订单 → 客户端拿到最终结果 → 客户端final支付。 整个过程形成闭环，有理有据，数据都由后端去操作安全合理。(最重点是前端工作量简直不要太少)。

可是，iOS就不一样了，简直不要太恶心！

iOS IAP应用内支付

• IAP，即in-app Purchase，苹果推出的App内购买虚拟商品的方式，基于AppStore账户的支付方式。由于iOS整个体系都是基于自己的一套系统的（不像上面的微信支付，是第三方支付平台），因此在开发之前，我们需要到Apple开发者中心完成以下步骤：

1. 签署协议和银行业务 2. 在后台创建App内购买项目，这里所有的价格都是Apple规定好的，我们只有选择的资格，没办法自定价格。创建完成后，每个项目会有sku和productId 3. 添加沙盒测试员Apple 以上步骤参考内容引自站内大神：Geniune

• 支付流程：应用通过sku向服务端获取商品列表 → 列表中取出对应产品请求支付 → 进入appStore支付 → 页面监听支付回调拿到验证票据 → 业务后台拿到应用接收到的票据后去Apple官网进行校验即可。

流程很简单，简单到几乎不用跟业务后台打交代，但是坑却随之而来：

① 支付数据完全依赖前端应用，很难跟业务后台的订单系统一一对应；
② 针对①的问题，IAP支付支持传递skPayment对象，里面的applicationUsername经常用来保存系统的OrderId；
但是应用支付成功后收到的回调中，applicationUsername却偶尔会出现为null的情况，没有了对应关系，就没办法核销业务系统中的订单从而为用户充值；
③ iOS支付回调非常不稳定，有时延迟严重；且没有任何注定查询的方法；
④ iOS应用内支付有很多异常情况要处理，最常见的就是没有登录、没有同意最新的iOS支付协议等，都会发送给app支付失败的回调；
但是当用户登录或是同意后，iOS系统又会触发新的支付，导致旧的附带业务订单号的支付无效，莫名又多出一个没有订单号的新支付；
⑤ 国内网上资料极度缺乏，基本都是19年以前的，Flutter的文章更是少的可怜，可参考性不强。
⑥ 测试文档对于中断购买的测试流程有巨坑，后面菜单一定不要错过~

通过查看文档和不断调试，我们发现：

① 支付错误的回调，基本能马上收到； ② 上面流程说到IAP支付需要手动结束支付流程。同时iOS规定不能对同一个skuId重复发起多次支付的，只要当前skuId有没有final的支付，再次发起都会失败； ② 无论支付成功或失败，只要app没有主动对当前支付进行final，每次启动app后，app都会收到这个支付信息的通知； ③ 关于applicationUsername，只有在支付完成马上收到回调的情况下，回调信息才会有这个信息；到②中的情况，肯定不会返回applicationUsername； ④ 没有applicationUsername就意味着订单对不上，因此我们需要进行凑单机制。

综上，我们对异常处理有了确定方案：

① app发起支付后，需要将业务OrderId和skuId进行持久化存储（即卸载应用都不会删除的数据）； ②只要持久化存储不