【微信支付】微信支付三种常见支付方式流程梳理

微信支付三种常见方式流程梳理

1. Native 方式 — PC端

Native 方式一般是在 PC 端中使用。

先看官方提供的流程图:

根据官方的图来梳理即可:

1.1 第一步 — 商户平台内部生成订单信息并展示

这一步一般是在用户进入支付页面时完成的，所谓平台内部生成订单，实际上就是指生成：

• 订单信息
• 价格
• …

以上这些信息是完全与微信平台无关联的，由商户平台内部完成。

1.2 第二步 — 商户平台调取微信提供的统一下单接口，微信平台生成预支付订单

这一步是在用户在支付页面中，点击微信支付按钮后进行的。

具体到研发，这一步实际上是首先由前端发送请求，后端调取微信提供的接口，进行统一下单，微信平台生成预支付订单，并向后端返回预支付交易链接 code_url。

预支付交易链接，实际上就是用户需要跳转完成支付的链接。

1.3 第三步 — 商户平台前端生成二维码

这一步由商户平台前端完成，在上一步中，前端拿到了微信提供的预支付交易链接 code_url。

接下来，由前端借助第三方工具，将 code_url 转换为二维码供用户扫描。

1.4 第四步 — 用户扫描二维码，进入支付 / 商户平台前端页面展示确认订单按钮

这里，流程分为两条线：

1. 用户：用户扫描商户平台前端提供的二维码，进入微信支付页，完成或放弃支付，这条线中，仅有用户和微信平台的交互，商户平台并不参与。对应图中的 5~8 步。
2. 商户平台：商户平台在向用户展示二维码后，还需要提供一个确认订单已完成的按钮。同时，轮询订单的支付状态。

用户完成在微信支付页面中的操作后，可能会有两种情况：

1. 订单未完成/支付失败 — 此时页面保持轮询订单状态，同时等待用户点击确认支付按钮，待用户点击确认支付按钮后，调取接口查询订单状态接口，确认订单支付状态。发现订单未支付后，向用户输出提示。
2. 订单已完成 — 此时页面同样持轮询订单状态，并等待用户点击确认支付按钮。当轮询到用户订单已完成时，进行页面跳转；当轮询到订单状态之前用户点击了确认支付按钮时，调取接口查询订单状态。这种情况下的最终结果就是，发现订单完成，进行下一步操作(主要是页面的跳转)

这里实际上对应的就是流程图中的 10 和 11 步。

2. H5 支付方式 — 移动端非微信浏览器

H5 方式是移动端的微信支付方式之一，其主要针对移动端在非微信浏览器中进行微信支付的情况。

同样，先看官方流程图：

同样根据官方的图来梳理：

2.1 第一步 — 商户平台内部生成订单信息并展示

这一步一般是在用户进入支付页面时完成的，所谓平台内部生成订单，实际上就是指生成：

• 订单信息
• 价格
• …

以上这些信息是完全与微信平台无关联的，由商户平台内部完成。

这一步在三种支付方式中是相同的，因为这一步跟微信平台之间并没有关系。

2.2 第二步 — 用户点击支付按钮，商户平台生成订单

这一步是在用户点击了支付按钮后进行，由商户平台前端发起请求，后端调用微信提供的 H5 下单API，生成预支付订单，并向前端返回H5支付中间页链接 h5_url

h5_url为拉起微信支付收银台的中间页面，可通过访问该URL来拉起微信客户端，完成支付，h5_url的有效期为5分钟。

2.3 第三步 — 向 code_url 中添加参数，完成跳转

在 Native 方式中，用户要进行支付，需要扫描包含了 code_url 信息的二维码，在手机上完成支付。但在 H5 方式中，由于用户本身就处于移动端，所以不再需要二维码的参与。

但是，与 Native 方式不同的是，H5 支付完成后，需要跳转回商户平台的支付页面。因此，这时，我们需要主动向 h5_url 中添加参数 redirect_url。

redirect_url 就是用户完成支付后，跳转回去的地址。在 redirect_url 中，除了目标地址，还可以携带一些我们需要的信息，例如平台内部订单的 uuid、订单生成的时间等等。注意，redirect_url 需要进行 urlencode 处理！

接下来，商户平台主动跳转至拼接好的链接url。

2.4 第四步 — 用户进行支付操作，跳转回指定页面

用户跳转到微信支付页面后，进行支付操作，订单可能存在两种状态：

1. 订单未完成/失败
2. 订单已完成

无论哪种状态，在用户完成操作后，都会跳转至前面指定的 redirect_url。

2.5 第五步 — 回到商户平台支付页面

在微信官方的文档中，给出了H5支付完成后，跳回商户平台后的操作标准：

由于设置 redirect_url 后,回跳指定页面的操作可能发生在：

• 微信支付中间页调起微信收银台后超过5秒。
• 用户点击“取消支付”或支付完成后点击“完成”按钮。因此无法保证页面回跳时，支付流程已结束，所以商户设置的redirect_url地址不能自动执行查单操作，应让用户去点击按钮触发查单操作。

所以，在具体实现时，我们一般会在 redirect_url 中添加一项标识，用以标记此时是从 h5 支付页跳转回来的情况。然后，弹出弹框，向用户提供【确认订单状态】和【重新支付】的两个按钮，可以参考下图：

2.6 第六步 — 商户后台查询订单状态

在用户完成支付后，商户后台会接收到微信平台的通知。

所以，当用户在浏览器中点击【确认订单状态】按钮，进行订单的确认时，商户前台会调用后端提供的查询订单接口。

在商户后台，可以先查询是否接收到微信平台的通知，如果接收到了通知，则直接将订单状态返回给前端；如果还没有接收到通知，则主动调取微信平台的查询订单API，查询订单状态，然后将订单状态返回给前端。

前端接收到订单状态后：

• 若订单已完成，则进行下一步操作，一般是跳转页面等
• 若订单未完成，则停留在当前页面，并提示用户订单未支付，让用户重新支付

当然，也可能用户主动点击【重新支付】按钮，此时商户平台可以根据业务需求，进行处理。

3. JSAPI 方式 — 移动端微信浏览器

当用户在微信中，打开商户平台时，会进入微信自带的浏览器中，在该情况下进行微信支付时，需要使用微信支付提供的 JSAPI 接口，在支付场景中调起微信支付模块。

官方文档中的流程图如下：

但在 JSAPI 支付方式中，实际的实现流程可能与官方的流程图不太一样，这里按实际开发中的流程来进行梳理：

3.1 第一步 — 商户平台内部生成订单信息并展示

同样的，JSAPI 支付中这一步也是必须的，主要目的仍然是展示订单的相关信息

• 订单信息
• 价格
• …

以上这些信息是完全与微信平台无关联的，由商户平台内部完成。

3.2 第二步 — 用户发起支付，跳转链接完成微信授权

用户点击支付按钮后，商户平台前端需要携带一些信息(例如：回跳链接、标识等)，平台内部调取单独微信授权模块模块完成微信授权。(注意，这里的微信授权模块是平台内部封装的)

该模块完成微信授权后，会将微信授权码 auth_code 附带在我们之前传递的回跳链接后面，然后跳转至回跳链接。

在微信支付场景下，这里的回跳链接实际上就是商户平台的支付页。

3.3 第三步 — 商户平台前端拿到授权码，跳转平台支付模块

在上一步中，商户平台前端拿到了微信授权码 auth_code。

接下来，商户平台前端需要调取后端接口，根据当前的 token 获取 ticket。然后，准备好一系列参数 postParam。

其中包括：

• 平台业务相关参数
• 用户 ticket
• 平台内部订单信息
• 支付方式标识
• 微信授权码
• …

同时，我们还需要准备好完成支付后跳转回支付页面的链接 redirect_url，该链接中需要包含以下信息：

• 当前页面url
• 平台内部订单uuid
• 平台内部业务相关参数
• 一些标识
• …

接下来，我们携带着这两项数据，访问平台内部封装好的支付模块。(注意，这两项数据需要进行 urlencode 处理！)

3.4 第四步 — 平台支付模块调起微信支付

进入平台内部支付模块后，该模块会根据我们传入的数据，调取微信支付提供的 JSAPI，调起微信支付。

3.5 第五步 — 用户完成支付操作

调起微信支付后，用户进行操作，并最终向微信支付系统发起支付请求，微信支付系统验证支付授权权限后，返回支付授权，然后用户确认支付后，输入密码，提交，微信支付系统进行校验，最终完成支付操作。这里对应的就是官方流程图中的 9~14 步。

当然，这个操作过程中，也可能存在其他情况，例如：用户取消支付、用户支付失败等等。

所以，平台支付模块中会向微信支付提供处理这些情况的回调函数，当出现这些情况时，就会触发回调。在这些回调函数中，平台可以根据业务需求进行处理。

总之，待用户完成支付操作后，最终会跳转回商户平台的支付页面。

3.6 第六步 — 平台获取支付结果并通知用户

平台获取支付结果，可以分为两个并行的场景：

1. 用户完成支付后，微信支付系统，异步地通知平台支付结果
2. 用户主动查询订单支付状态，此时商户平台调取查询订单接口，并返回通知用户

PS

在 JSAPI 支付方式中，【获取微信授权】和【微信支付】这两个平台内部模块的实现比较复杂，后续可以在微信支付实例分析中进行详细的介绍。