第三方支付平台：BeeCloud和Ping++对比

前言

最近刚忙完手头上关于web的活，于是找了点感兴趣的事情研究一下。

之前有朋友说想要研究一下第三方支付，当时我给的说法是直接用企业资质去支付宝、微信或是银联申请官方的接口。

今天查了一点相关资料，发现现在第三方支付接口开发变的容易了很多，对于客户端来讲，如果想要简单的集成一个支付的功能，很可能加载sdk后寥寥几行代码就能实现。

研究了一下，目前主流的第三方支付接口：BeeCloud和Ping++。按照项目前期可行性分析的大致思路，对两个接口分别进行简单的说明。

交易流程

BeeCloud交易流程：

Ping++交易流程：

交易流程说明：

1. 应用需要有选择渠道付款的页面，用户选择渠道发起付款请求时，客户端传递订单信息到应用服务器。
2. 服务器接收订单信息后，调用 Ping++Server SDK 发起支付请求。
3. 请求完成后会获得 Ping++ 返回的 Charge 对象，由于这里的 Charge对象用于客户端调起支付控件，所以我们称之为支付凭据。
4. 服务器获得支付凭据后，将支付凭据返回给客户端，返回类型必须是 JSON 格式。
5. 客户端接收到服务器返回的 JSON 格式的支付凭据后，使用 Client SDK 调用支付控件完成支付，用户在控件中完成付款。
6. 在用户付完款后，Client SDK 会把支付结果返回给调用页面，客户端根据返回结果提示用户支付结果。
7. 与此同时，Ping++ 会主动以POST 方式给你配置在管理平台上的 Webhooks 通知地址发送支付结果。支付结果是 Event 对象，我们称之为 Webhooks通知，订单状态需要以 Webhooks 通知为准。

易用性

两款软件就上手难度来说，都算是比较容易的。一般只需要集成SDK，然后通过各种Key调用接口就可以。

唯一需要说明的是，BeeCloud更侧重于客户端的体验，因此在客户端支付体验上下了很大工夫，最成功的一点在于提供的关于“扫码”支付结算接口。

• 客户端SDK加载：难度相当
• 服务端SDK加载：ping++更麻烦一些，需要处理支付数据的转发操作。但也正是基于这一点，Ping++的服务器端能够更灵活的处理支付数据，而BeeCloud只能根据异步返回的报文记录相关结果信息。
• 通信：难度相当
• 管理平台：BeeCloud提供的功能更多样化，而Ping++额外在管理平台上提供了“联调”这一程序员神器，可谓各有利弊。

可扩展性

BeeCloud的所有扩展性，都必须基于官方提供的各类API。而Ping++支持企业用户在自有服务端进行业务扩展。因此Ping++的可扩展性更高一些。

当然，如果你的应用场景和应用需求都比较简单的话，两者在使用上基本保持了一致。

可维护性

可维护性上Ping++做的更好一些，因为所有的支付数据都是通过企业自有服务端进行转发，因此一些统一的改动就无需变动客户端代码，只需要升级服务器即可。减少了必要的运营成本。

而BeeCloud就需要改动客户端代码，因为每个客户端所使用的开发语言和开发包都不一样，所以可能改动的工作量会很大。

相关费用

BeeCloud的收费标准如下：

Ping++的收费标准如下：

相对而言，Ping++的收费标准更高一些。就后续的服务收费而言，二者基本上都是参照各渠道的官方收费标准，因此不做对比。

其他

第三方支付托管

如果想要实现像淘宝那样的第三方支付托管，客户在购买商品后，将金额交付到托管平台，等确认收到货后再将钱赚到具体商户的账户中。

目前据我浅陋的分析，只能通过Ping++实现。如同前文所述，Ping++的支付结算数据是通过企业服务端进行转发的，因此可操作的余地就会很大。如果需要使用BeeCloud实现第三方支付托管，可能会需要很大的工作量。

后记

通过两个平台分析能看出来，BeeCloud更多的针对单一用户，如游戏、小型电商。而Ping++可能支持的范围更广一些，完全可以基于Ping++平台开发一套电商平台，引进多商户模式。

更好玩的是，从平台架构上分析，BeeCloud的老板很可能以前是做需求的，而Ping++的老板估计是个程序员。因此Ping++对程序员要求更高一些，但给与的支持力度也不是BeeCloud能比的。BeeCloud则尽可能的减少开发工作量，适用于小微型团队。

PS: 经查，Ping++老大金亦冶果然是技术出身，虽然披着斯坦福的外皮，但实实在在的吾辈中人。而出乎马仔预料，BeeCloud创始人黄君贤竟然是美国密歇根大学计算机博士，有过Google总部工作经验~~

吾辈不孤也~