Ping++和BeeCloud的比较

第三方支付集成服务

随着越来越多的移动应用需要集成支付功能，相比于直接与每个支付渠道对接，一些公司提供了第三方支付集成服务，以统一的接口帮助开发者快速地集成多种不同的支付方式，并提供了稳定可靠的云服务和数据管理平台。这里将对其中两个主流的产品进行比较分析。

优势

• 帮助商户更快地成功申请支付渠道。一般初创公司没有对接支付的经验，申请商户号和相关的参数是个极其麻烦的事情，耗费大量的时间。通过第三方支付集成服务商，他们更有经验，更容易申请到。
• 帮助开发者快速接入多种不同的主流支付方式。通过聚合支付接口，隐藏了不同支付方式的接口差异，提供给开发者统一的接口和良好的错误信息。
• 提供聚合的对账查询的管理平台，通过一个平台，查看所有不同支付渠道的数据。

风险

• 信息泄露
  • 支付渠道参数泄露。黑客可能会利用渠道的代扣接口进行恶意代扣或者博彩、洗钱等非法服务，最终导致商家被风控系统监测，被加入黑名单。出现信息泄露问题后，由于商家和第三方支付集成公司都持有支付参数信息，责任边界及损失承担方无法确认。
  • 交易数据泄露。比如，将交易数据泄露给竞争对手。
  • 客户数据泄露。
• 跟不上商户业务的发展需求。
  • 直接对接支付渠道可以及时得到接口更新的信息（例如安全漏洞），但如果依赖于支付集成服务商，会有很多不可控的因素。
  • 商户的业务需求在支付模式上的创新，会依赖于支付集成服务提供商的开发周期，甚至可能无法被满足。
• 支付系统的稳定性和安全性。使用支付集成服务商可能会产生单点故障。第三方支付在防攻击、防钓鱼、容灾能力、信息安全等方面的能力一般来说是强于集成服务提供商的。
• 资金安全风险。

Ping++ vs. BeeCloud

	Ping++	BeeCloud
服务功能	支付系统 支付渠道申请（15天内） 管理平台	支付系统 支付渠道申请 管理平台
支付渠道	支付宝 微信 银联 Visa/MasterCardMasterCard	支付宝 微信 银联 Visa/MasterCardMasterCard PayPal
支付方式	手机app（iOS/Android/H5） PC 网页 QR 扫码	手机app（iOS/Android/H5） PC 网页 QR 扫码
支付场景	支付 查询 退款 红包 企业付款 账户系统（余额、优惠券） 分期支付	支付 查询 退款 红包 企业付款 订阅支付（定时自动扣款） 秒支付button
接入开发	SDK（Client & Server） 提供Test 和Live 模式 https://github.com/PingPlusPlus	SDK 提供Live 和Sandbox模式 https://github.com/beecloud

集成Ping++

1. 分别下载服务端SDK 和客户端SDK。
2. 安装部署服务端SDK，使用服务端SDK 请求交易对象。
3. 安装部署客户端SDK，并请求你的服务端拿到交易对象，调用客户端SDK 完成支付（此步骤仅限支付交易）。
4. 配置服务端Webhooks，接收交易结果的事件通知。
5. 根据具体场景，在指定时间没有获取Webhooks 通知的前提下，通过查询接口获取交易结果。

注意：以上步骤适用于Test 和Live 两种模式。

Ping++ 支付流程

1. 用户在客户端选择商品并提交订单，客户端需要向你的服务端传递支付要素。注意：Ping++ SDK 不涉及你的客户端和你的服务端之间的数据交互，此处请你自定义通信方式。
2. 服务端接收到客户端请求参数，并调用Server-SDK 封装的创建支付Charge 的方法请求Ping++ 。
3. Ping++ 响应你的服务端请求，返回Charge（支付凭据）给你的服务端。
4. 你的服务端响应你的客户端请求，需要将该Charge 对象完整的返回给你的客户端。注意：这里的Charge 返回类型必须是JSON 格式。
5. 客户端拿到支付凭据 Charge 对象后，需要调用 Client-SDK 封装的方法调起支付控件，用户输入密码完成支付。
6. 第三方支付渠道会直接在客户端返回支付结果，此处不要使用客户端的成功结果更新订单的最终状态。
7. 在Ping++ 管理平台配置Webhooks 的charge.succeeded 事件。支付完成时，Ping++ 会主动以POST 方式向你配置在管理平台上的Webhooks 通知地址发送支付结果，服务端的订单状态请根据Webhooks 通知更新。

注意：请勿直接使用客户端支付结果作为最终判定订单状态的依据，由于Ping++ 没有参与你的客户端和第三方渠道的交互，无法保证客户端支付结果的安全性，建议使用Webhooks 通知的结果去更新你的订单状态。

Ping++ 退款流程

Ping++ 退款Refund 功能只需要服务端SDK，所以需要你在客户端为用户设计退款入口。

1. 服务端调用Server-SDK 封装的发起退款方法请求Ping++ 。
2. Ping++ 响应你的服务端请求，返回退款Refund 对象，请求是否成功可以根据返回的Refund 中的failure_msg 来判断。如果该字段为空则代表退款请求成功，不代表退款已经成功到账。
3. 在Ping++ 管理平台配置Webhooks 的refund.succeeded 事件。退款成功时，Ping++ 会主动以POST 方式向你配置在管理平台上的Webhooks 通知地址发送退款结果。
4. 在你服务端没有收到Webhooks 的通知或退款失败时，你也可以调用Server-SDK 封装的查询方法，主动向Ping++ 发起请求来获得退款状态。

集成BeeCloud

BeeCloud 移动端支付流程

1. App 端发送订单信息。做完这一步之后就会跳到相应的支付页面（如微信app 中），让用户继续后续的支付步骤。
2. App 端处理同步回调结果。付款完成或取消之后，会回到客户app 中，在页面中展示支付结果（比如弹出框告诉用户“支付成功”或“支付失败”）。同步回调结果只作为界面展示的依据，不能作为订单的最终支付结果，最终支付结果应以异步回调为准。
3. 客户服务端处理异步回调结果（Webhook）。付款完成之后，根据客户在BeeCloud 后台的设置，BeeCloud 会向客户服务端发送一个Webhook 请求，里面包括了数字签名，订单号，订单金额等一系列信息。客户需要在服务端依据规则要验证数字签名是否正确，购买的产品与订单金额是否匹配，这两个验证缺一不可。验证结束后即可开始走支付完成后的逻辑。

BeeCloud 网页端支付流程

1. 网页服务器端发送订单信息。
2. 收到BeeCloud 返回的渠道支付地址（比如支付宝的收银台）
   • 微信扫码返回的内容不是和支付宝一样的一个有二维码的页面，而是直接给出了微信的二维码的内容，需要用户自己将微信二维码输出成二维码的图片展示出来。
3. 将支付地址展示给用户进行支付。
4. 用户支付完成后通过一开始发送的订单信息中的return_url 来返回商户页面。
   • 微信没有自己的页面，二维码展示在商户自己的页面上，所以没有return_url 的概念，需要商户自行使用一些方法去完成这个支付完成后的跳转（比如后台轮询查支付结果）
   • 此时商户的网页需要做相应界面展示的更新（比如告诉用户“支付成功”或“支付失败”）。不允许使用同步回调的结果来作为最终的支付结果，因为同步回调有极大的可能性出现丢失的情况（即用户支付完没有执行return_url，直接关掉了网站等等），最终支付结果应以下面的异步回调为准。
5. 商户后端服务端处理异步回调结果（Webhook）。付款完成之后，根据客户在BeeCloud 后台的设置，BeeCloud 会向客户服务端发送一个Webhook 请求，里面包括了数字签名，订单号，订单金额等一系列信息。客户需要在服务端依据规则要验证数字签名是否正确，购买的产品与订单金额是否匹配，这两个验证缺一不可。验证结束后即可开始走支付完成后的逻辑。

参考

使用第三方支付集成有何风险 - 梁川的回答
Ping++, BeeCloud 这类集合支付服务产品的商业模式盈利模式是什么 - 陈龙的回答