作为产品经理,设计支付模块是绕不开的必修课。而微信支付作为国民级支付工具,其背后的交互逻辑和系统设计值得每一位产品人深入学习。今天,我们就通过一张详细的时序图,带你彻底搞懂微信支付的完整流程,以及产品经理需要关注的核心要点。
一、为什么产品经理要懂支付时序图?
支付是电商、O2O、金融等产品的核心闭环。理解支付时序图,能帮助你:
- 设计更合理的支付流程:避免遗漏关键状态,提升支付成功率。
- 与开发高效沟通:用技术语言对齐需求,减少扯皮。
- 规避资金风险:清晰定位异常场景,设计补偿机制。
- 优化用户体验:识别耗时环节,针对性优化。
而微信支付作为最主流的支付渠道之一,其异步通知、对账、退款等机制极具代表性。掌握它,其他支付渠道(支付宝、银联)也能触类旁通。
二、微信支付核心角色
在展开时序图之前,先明确参与方:
- 用户:发起支付的人。
- 商户APP/小程序/H5:用户操作的前端载体。
- 商户服务器:商户后台,负责生成订单、调用微信支付API。
- 微信支付系统:微信的支付网关、核心支付系统。
- 微信客户端:用户手机上的微信APP,用于授权和确认支付。
三、微信支付完整时序图(以APP支付为例)
提示:如果你在小程序内支付,流程略有差异(无需跳转微信APP),但核心逻辑一致。
用户 商户APP 商户服务器 微信支付系统 微信客户端
| | | | |
| 1.选择商品,点击支付 | | | |
|----------------->| | | |
| | 2.请求生成订单 | | |
| |----------------->| | |
| | | 3.创建商户订单 | |
| | |----------------->| |
| | | 4.返回预支付交易会话ID | |
| | |<-----------------| |
| | 5.返回支付参数(包含prepay_id等)| |
| |<-----------------| | |
| | 6.调起微信支付 | | |
| |---------------------------------------------------->|
| | | | | 7.用户确认支付
| | | | |-------+
| | | | |<------+
| | | | 8.支付结果通知(异步) |
| | |<------------------------------------|
| | | 9.返回接收成功 | |
| | |----------------->| |
| | | | 10.支付结果通知(异步) |
| | |<-----------------| |
| | | 11.返回接收成功 | |
| | |----------------->| |
| | 12.查询支付结果 | | |
| |----------------->| | |
| | | 13.主动查询或依赖回调 | |
| | |----------------->| |
| | | 14.返回支付结果 | |
| | |<-----------------| |
| | 15.更新订单状态并返回 | | |
| |<-----------------| | |
| 16.展示支付结果 | | | |
|<-----------------| | | |
| | | | 17.回调商户(可选) |
| | |<------------------------------------|
| | | 18.返回处理结果 | |
| | |----------------->| |
流程说明:
- 用户下单:在商户APP选择商品,点击支付。
- 商户服务器创建订单:商户后台生成内部订单号,记录金额、商品信息。
- 调用统一下单API:商户服务器向微信支付系统发送请求(包括openid、金额、回调地址等),微信返回预支付交易会话标识prepay_id。
- 返回支付参数:商户服务器将prepay_id与其他参数(如时间戳、随机串、签名)打包返回给商户APP。
- 调起微信支付:商户APP将支付参数传递给微信客户端(SDK)。
- 用户确认支付:用户在微信内完成密码/指纹验证,微信客户端将支付请求发送至微信支付系统。
- 异步通知商户:微信支付系统处理支付成功后,向商户服务器发送异步通知(结果通知)。商户服务器必须返回成功应答,否则微信会重试。
- 商户处理通知:商户服务器验证签名、更新订单状态、触发后续业务(如发货、发积分)。
- 前端展示结果:商户APP可通过查询订单状态或等待前端回调(微信客户端会返回结果给APP)来展示支付成功页。
注意:实际的时序中,异步通知可能先于前端返回,也可能后到有延迟。因此产品设计必须以后端收到异步通知并处理成功作为支付成功的最终依据。
四、产品经理必须关注的6个关键点
1. 支付结果的双重确认机制
前端返回的结果仅用于展示,不可作为业务依据。因为可能被篡改、或网络中断未收到。务必依赖后端异步通知或主动查询。
2. 异步通知的幂等处理
微信可能重复发送同一笔支付的通知。商户系统必须做去重,避免重复加余额、重复发货。通常使用订单号+支付状态做唯一约束。
3. 签名与验签
所有与微信支付交互的数据都要签名,防止篡改。商户需妥善保管API密钥。
4. 支付超时与未支付订单处理
用户可能中途放弃支付。需设置订单超时时间,并定时关单。微信支付也提供关闭订单API。
5. 退款流程
退款是反向流程:商户发起退款 -> 微信支付系统处理 -> 异步通知退款结果。同样要处理异步通知和幂等,且退款到账时间有差异(零钱实时,银行卡1-3天)。
6. 对账
每日下载微信对账单,与商户订单核对,发现异常可及时处理。产品经理应推动后端监控与告警。
五、常见异常场景及产品方案
- 支付成功但商户未收到通知:定期主动查询(如每30秒轮询,共5分钟),或依赖微信的多次重试(微信通知频率:15s, 15s, 30s, 3m, 10m, 20m... 共8次)。
- 用户支付后直接杀进程:前端回到商户APP时需重新查询订单状态。
- 重复支付:用户可能对同一订单支付两次。产品上限制单笔订单只能支付一次,后端根据订单状态拒绝重复支付。若发生重复,需退款并通知用户。
产品经理应针对这些异常设计兜底逻辑,并在后台提供手动补单、人工退款等运营工具。
六、
微信支付时序图不仅是技术实现,更是产品设计的镜子。作为产品经理,你不需要写代码,但必须理解每个节点背后的业务含义和潜在风险。希望本文能帮你构建支付模块的全局观,在下次需求评审中更有底气!
如果你对支付宝、银联的支付流程也感兴趣,欢迎留言告诉我,后续可以继续拆解。