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

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

参考

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

你可能感兴趣的:(Ping++和BeeCloud的比较)