扫码支付

扫码支付除 isv_wap 外只需要服务端,不需要客户端 SDK,各场景描述如下:

  • 用户主扫
    • 动态码:商户针对每一笔订单/商品单独生成二维码显示在终端,用户使用手机 APP(比如微信、支付宝、云闪付)进行扫码支付。 注: 该二维码分渠道,支付宝只能扫支付宝对应产生的二维码,微信只能扫微信对应产生的二维码。此方式支持的渠道 channel 包含:alipay_qr、wx_pub_qr、cb_alipay_qr、cb_wx_pub_qr、upacp_qr、ccb_qr、isv_qr,对应的名称可参考 支付渠道属性值
    • 固定码:商户展示一个固定码(实际就是支付页面的链接)在终端,用户使用微信/支付宝扫码,进入一个支付页面,在该支付页面输入金额(此步可省略),点击支付按钮之后,如果使用微信扫码的就直接调起微信支付,使用支付宝扫码的就直接调起支付宝支付。此方式支持的渠道为:isv_wap注: 此渠道需要 服务端 SDK 和客户端 H5 SDK。接入流程与 支付 类似,你也可以点击【固定码】标题来参考下方的接入说明。
  • 用户被扫:用户展示支付宝/微信中的付款码,商户使用扫描设备扫描用户的付款码。此方式支持的渠道 channel 包含:alipay_scan、wx_pub_scan、cb_alipay_scan、cb_wx_pub_scan、upacp_scan、isv_scan
一、用户主扫
  • ① 动态码

拿到二维码链接后的流程由商户自行设计,可参考以下流程:

qr_paymentflow

  1. 服务端调用 Server-SDK 封装的创建支付 Charge 的方法请求 Ping++。
  2. Ping++ 响应你的服务端请求,返回支付 Charge 对象,在 Charge 对象中有 credential 字段,该字段中包含可以生成二维码的链接,如:http://sissi.pingxx.com/mock.php?ch_id=ch_1aDuv98Gy5S8fP8GKO4Wb1GG&channel=alipay_qr
  3. 你需要截取出 credential 中包含的链接并自行生成二维码,显示在你的 PC 端或任意你需要展示二维码的平台。
  4. 在 Ping++ 管理平台配置 Webhooks 的 charge.succeeded 事件。支付完成时,Ping++ 会主动以 POST 方式向你配置在管理平台上的 Webhooks 通知地址发送支付结果,服务端的订单状态请根据 Webhooks 通知更新。
  5. 同时,建议在处理逻辑中添加主动查询机制:如果在可接受的时间范围内没有收到 Webhooks 通知,你也可以调用 Server-SDK 封装的查询方法,主动向 Ping++ 发起请求来获得订单状态,该查询结果可以作为交易结果。
返回顶部
  • ② 固定码

isv_wap_paymentflow

  1. 商户首先需要在前端页面展示一个固定码(实际就是支付页面的链接),用户使用微信/支付宝扫码,进入一个支付页面,在该支付页面输入金额(此处可省略),点击支付按钮之后,你的客户端需要向你的服务端传递支付要素。 注意: Ping++ SDK 不涉及你的客户端和你的服务端之间的数据交互,此处请你自定义通信方式。
  2. 服务端接收到客户端请求参数,并调用 Server-SDK封装的创建支付 Charge 的方法请求 Ping++ 。
  3. Ping++ 响应你的服务端请求,返回 Charge(支付凭据)给你的服务端。
  4. 你的服务端响应你的客户端请求,需要将该 Charge 对象完整的返回给你的客户端。 注意: 这里的 Charge 返回类型必须是 JSON 格式,你可以参考:服务端应传递怎样的支付凭证给前端?
  5. 客户端拿到支付凭据 Charge 对象后,需要调用 H5 SDK 封装的方法调起支付控件,用户输入密码完成支付。
  6. 在 Ping++ 管理平台配置 Webhooks 的 charge.succeeded 事件。支付完成时,Ping++ 会主动以 POST 方式向你配置在管理平台上的 Webhooks 通知地址发送支付结果,建议订单状态的更新对比客户端的渠道同步回调信息和服务端的 Ping++ Webhooks 通知来确定是否修改。
  7. 同时,建议在处理逻辑中添加主动查询机制:如果在可接受的时间范围内没有收到 Webhooks 通知,你也可以调用 Server-SDK 封装的查询方法,主动向 Ping++ 发起请求来获得订单状态,该查询结果可以作为交易结果。
返回顶部
二、用户被扫

isv_scan_paymentflow

  1. 用户展示支付宝/微信 / 银联中的付款码,商户使用扫描设备扫描。
  2. 你的服务端获取到你的客户端传递的支付信息后,调用 Server-SDK 封装的创建支付 Charge 方法请求 Ping++ 。
  3. Ping++ 响应你的服务端请求,返回带有支付结果的 Charge 对象。 注: 当用户因为免密次数限制或者其他特殊原因,导致同步返回的 Charge 未支付时,需要 5 秒间隔调用 Charge 查询接口更新订单状态。
  4. 在 Ping++ 管理平台配置 Webhooks 的 charge.succeeded 事件。支付完成时,Ping++ 会主动以 POST 方式向你配置在管理平台上的 Webhooks 通知地址发送支付结果,服务端的订单状态请根据 Webhooks 通知更新。
  5. 同时,建议在处理逻辑中添加主动查询机制:如果在可接受的时间范围内没有收到 Webhooks 通知,你也可以调用 Server-SDK 封装的查询方法,主动向 Ping++ 发起请求来获得订单状态,该查询结果可以作为交易结果。
返回顶部

注意事项

  1. Ping++ 没有针对二维码扫码提供客户端 SDK ,所以请不要将服务端拿到的 Charge 传给 Ping++ 的 Client-SDK ,会出现报错 no_such_channel
  2. 支付完成后,第三方渠道不会给你的客户端任何结果,所以你需要设计客户端主动轮询服务端查询扫码的支付结果。
  3. 请勿直接使用客户端支付结果作为最终判定订单状态的依据,由于 Ping++ 没有参与你的客户端和第三方渠道的交互,无法保证客户端支付结果的安全性,建议订单状态的更新对比客户端的渠道同步回调信息和服务端的 Ping++ Webhooks 通知来确定是否修改。

下一步撤销