扫码支付除 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。

一、用户主扫

• ① 动态码

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

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++ 发起请求来获得订单状态，该查询结果可以作为交易结果。

返回顶部

• ② 固定码

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++ 发起请求来获得订单状态，该查询结果可以作为交易结果。

返回顶部

二、用户被扫

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. 支付完成后，第三方渠道不会给你的客户端任何结果，所以你需要设计客户端主动轮询服务端查询扫码的支付结果。isv_scan、isv_wap、isv_qr 渠道的订单建议增加间隔为5s的查询接口轮询，直到查询到支付成功应答或者超过一定时间，建议轮询总时长设置为60s，超过轮询时间后，调用取消接口关闭订单。
3. 请勿直接使用客户端支付结果作为最终判定订单状态的依据，由于 Ping++ 没有参与你的客户端和第三方渠道的交互，无法保证客户端支付结果的安全性，建议订单状态的更新对比客户端的渠道同步回调信息和服务端的 Ping++ Webhooks 通知来确定是否修改。