Flutter实现微信支付和iOS IAP支付

// ① 弹出支付框后使用系统返回键关闭；
// ② 进入微信支付密码框后不输入使用系统导航切回app或者系统返回键返回；
// ③ 进入微信后直接返回桌面再回到应用；
// ④ 弹出支付框后锁屏再开屏；
// ⑤ 弹出支付款后下拉任务栏；
// ⑥ 输入密码成功后，直接返回桌面或者使用系统导航或者使用返回键返回app
// ⑦ 退出微信登录，进行支付后直接登录微信，在登录过程中回到app
// ⑧ 在系统应用管理中双开微信后，调起支付后不点击任一个微信端，而是点击取消

现在主流的做法是再支付页面监听app的生命周期，即由后台切回前台的时候，检测下状态，若还在支付中，直接进入查询结果页面，由后台去检验订单，拿到结果显示即可。（后台主动查询理论上还是存在微信服务端延时的问题，因此后台进行查询的时候，建议采取轮询机制，若是没有支付成功的话，延时5秒后再确认下更保险）

class _XXXPageState extends State with WidgetsBindingObserver {
@override
void initState() {
super.initState();
WidgetsBinding.instance.addObserver(this); //添加观察者
}

@override
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；
但是应用支付成功后收到的回调中，applicationUs