// ① 弹出支付框后使用系统返回键关闭;
// ② 进入微信支付密码框后不输入使用系统导航切回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. 添加