Ping++ 和 BeeCloud 等聚合支付公司都是学习 Stripe 的公司，解决的核心问题是初创企业接支付的难题

聚合支付的优点

1. 商户入网麻烦

一般初创公司的人都没有接支付的经验，申请商户号和相关的参数是个极其麻烦的事情 ，可能会耗费大量的时间，ping++把这个事情帮创业者做了，他们更有经验，更容易申请到，而且不要费用

2. 技术开发麻烦

现在做个APP，至少得有个支付宝和微信吧，再多点加个银联、易宝、快钱、京东支付、百度钱包、PayPal、Apple Pay等，要是创业者真的自己去调这些接口并设计多渠道的技术方案，会耽误大量的时间来做自己不擅长的事情，这种聚合类接口，把各个支付公司接口的差异化自己屏蔽掉了，开发者只需要接一个接口就能完成支付的介入

3. 对账查询麻烦

以前接多个支付通道，你需要到各个平台去查自己的交易和退货等，接了聚合类的支付，只需要到一个地方去查询了

总的来说，对于初创者来讲，用这类集合支付绝对能让你省不少的时间和精力出来。

聚合支付的弊端

1. 数据泄露问题，毕竟你的交易数据都在别人那里，心里还是虚的，出去吹个几倍的交易量还担心被人捅破呢

2. 单点依赖，万一这类平台系统挂了，你就只能呵呵了

3. 高并发问题，他们也都是创业公司，没有经历过支付宝双11那种并发，万一想搞个抢购啥的，会不会把他们搞挂呢，即使你不搞抢购，万一别人搞抢购把聚合支付搞挂了呢？就会遇到第二个问题

聚合支付的盈利模式

1. 服务费，以前两家都要满足一定量才收，现在都去掉了，全免费，我猜测以前的收费规则，基本上就没有客户达到过，干脆取消算了

2. 分润，其实支付行业一直都有代理这一说，支付公司按照标准费率向客户收取手续费，但是会将一部分收益分给代理商，用于代理商拓展商户的报酬

3. 定制开发，例如大客户定制、业务增值、征信数据等，都可以yy，关键是，现在的情况下，他们都赚不了钱，看谁能撑到最后。

4. 胆子大点，也是最赚钱的，例如小额贷款、理财产品、货币基金等金融产品。

Ping++ 官方

谢题主的问题，我们是 Ping++，作为国内最早的一家做第三方支付集成的公司，这类问题其实我们在其它地方有过阐述，现在我们还是希望能在此和大家分享一下。

使用第三方支付集成有何风险？

这其实也几乎是每个商户在使用前必问的一个题目。支付本身的风险不必再提，我们想说的是：使用第三方支付集成公司的产品后，与你直接去使用支付渠道相比，增加了哪些风险？

首先介绍一下 APP 直接接入支付需要经过的流程。

申请渠道参数，接入各渠道 SDK，根据渠道参数构建支付凭据（请求渠道接口和加密渠道参数），客户端调起支付控件，处理渠道的支付异步通知。

再介绍下 APP 使用第三方支付集成公司接入支付需要经过的流程（以 Ping++ 为例）

申请渠道参数，在 Ping++ 管理平台填写商户信息，接入 Ping++ SDK，发起支付请求， 客户端通过 Ping++ SDK 调起支付控件，处理 Ping++ SDK 的支付成功的异步通知。

从流程对比来看，Ping++ 在构建支付凭据、调起支付控件以及异步通知等处做了封装处理，商户不需要关心各渠道支付的参数，请求地址，加密方式，流程的区别，简化了商户的接入成本。但这也是使用第三方支付集成公司可能增加风险的几个地方，主要体现在以下 2 个方面：

a. 安全性

支付最应该保障的是安全性，安全性的风险主要涉及资金、支付要素信息和商户身份信息三方面。商户通过第三方支付集成公司接入支付渠道，均为真实身份，交易资金直接由支付渠道清算到商户账户，所有支付要素信息也均是相应的渠道的支付控件采集，所以第三方支付集成公司不会也不可能接触到支付要素信息。最大的风险是在商户身份信息（即支付渠道参数）泄露这个层面。

支付渠道参数泄露后，并不是不会对商家造成影响，因为这些参数会被其它人利用，用来发起交易并进行退款操作。比如某商户的微信支付参数被泄露给了 A，A 可以在商户的 App 里发起交易，并在收到货时发起退款操作，此时，商户就承担了一些风险。

所以在最初设计 Ping++ 时，安全性也是我们一直非常重视的问题。包括不会要求商户提供任何可能导致商户资金风险的安全信息，用于标示商户身份的信息及数字证书均加密存储在数据库中，交易报文均通过 https 进行传输，这些都可以用来最大程度保证商户身份安全。

在数据安全层面，Ping++ 已于 2016 年 10 月 10 日通过 PCI DSS 国际安全认证（Ping++获 PCI DSS认证 领跑聚合支付数据安全）。PCI DSS 认证是全球公认的支付领域系统数据安全和产品安全标准，Ping++ 也是截至目前国内聚合支付行业为数不多的获得认证的企业。PCI 认证是国际范围内支付卡数据安全领域最严苛的安全认证标准，企业接入 Ping++ 支付系统不仅能节省高昂的认证费用、繁琐的技术升级流程，也保证了系统的稳定性和并发承受能力。

b. 稳定性

稳定性更多考量的是一家公司对异常情况的处理能力。比如支付渠道故障，订单异常，高并发时服务器负载的压力。商户若自行接入支付，原本只需要依赖商户和支付渠道本身的服务器，现在中间增加了一层第三方支付集成公司，从表面上是增加了出现异常的可能，但实际上使用 Ping++ 在稳定性上，是降低了风险的。

渠道故障：前段时间支付宝萧山区某工地光纤被挖断，不少用户在数小时内无法使用支付宝，这类支付渠道自身造成的故障无法避免。但在这一点上，作为第三方支付集成的公司也是有必要告诉商户问题出在哪里。Ping++ 针对这类故障专门设计了支付服务状态监控，实时监控所有支付渠道的稳定性，商户可以在第一时间知道是支付渠道的问题，还是 Ping ++ 的问题。

订单异常： 每个支付渠道的都有不同的错误类型，相关的文档也不是很详细，没有支付经验的开发人员往往会在出现这些错误时踩坑，而 Ping++ 做好了良好的接口封装，将可能的错误情况以清晰友好的格式返回给商户。

并发问题：在业务量突然暴增时，若是自行接入，可能在服务器在处理这些问题没有很好的经验，导致订单的流失。Ping++ 对于并发处理做了很好的优化，例如使用缓存来减轻数据库负载等，异步处理一些事务等。

技术支持：Ping++ 目前已经服务了 14000 多家商户（数字于 2016.10 更新），对于各类异常问题都能在最快时间定位，并做技术解答，而这也是在自行接入支付渠道时无法获得的支持。

为什么需要第三方支付集成公司的存在？

作为第三方支付集成公司，除了单纯的做支付接入外，更多的是要给商户比支付渠道更好的服务，不然商户就完全没有使用我们的意义。

2014 年整年，Ping++ 在帮商户做支付接入上，2016 年，我们更多的是在帮商户提升用户的支付体验，以此帮商户提高支付转化率。而在很多商户看不见也感知不到，但在 Ping++ 看来会给商户支付带来问题的地方，我们也做了很多优化处理，包括系统安全性的不断巩固升级，PCI DSS 国际安全认证的通过等等。

更重要的是，作为聚合支付解决方案提供商，区别于其它 To B 类型的互联网公司的一个很重要的一点，就是你在支付行业的经验，设计产品是从支付产品考虑，而不仅仅是个互联网产品。在支付系统基础之上，2016 年 9 月，我们新上线了用户账户系统和多级商户系统，账户系统全面支持充值、优惠券、提现、余额账户的功能，多级商户系统是针对平台类商户，提供了子商户管理、分成结算、财务对账等功能，这些功能都更加贴近商户的业务本身，也让商户的支付系统更加完整及安全。

BeeCloud 的黄总也在回复中提到了社会需要分工，没必要大家都重复造轮子。这种「共享经济」的理念我们很赞同，Ping++ 也在几个月前提到过，在此也可把网易科技报道的 Ping++ CEO 金亦冶的文章分享给大家看看 金亦冶：为什么说这个世界终究是属于那些2B公司?

最后，欢迎大家来 Ping++ 官网体验产品： https://pingxx.com/

BeeCloud 官方

我是BeeCloud的创始人，这个问题我很关注，因为我是技术出身，写代码也10多年了，所以我试着站在一个程序员的角度，给出一个比较详尽而客观的回答：

使用第三方支付集成，风险有没有？确实有，主要在几方面：

1、 服务的稳定性

使用了第三方的支付服务，势必会涉及与第三方的服务器通讯。比如BeeCloud的做法是把后端完全打包，客户端通过一个统一的REST API与BeeCloud通讯，BeeCloud负责与微信，银联，支付宝的服务器通信，这样开发者完全不用写后端的代码了。但是如果第三方支付集成的服务器挂掉，那支付就会受到影响。

2、支付参数的安全性

如果使用第三方支付集成，难免涉及到与我们共享一些支付的参数，比如微信的AppID和AppSecret等。不用多说，任何一个提供我们类似服务的企业都会尽全力防止这类参数泄漏，就像所有的网站都会保护好自己用户的密码信息一样。这些参数即使被偷，能够多大坏处，也要分情况讨论，下面会详述。

3、客户端的bug

如果是iOS和Android，需要引入第三方支付集成的客户端SDK，这个SDK中如果有一些bug，比如iOS里调用了一个nil对象的方法，Android里的NPE都会导致app崩溃，第三方SDK导致app crash是引入第三方SDK的最常见的问题之一。

需要澄清的一点，因为在

@西弗伦斯

的回答中有提到，资金安全方面，BeeCloud完全在资金的闭环之外，完全不参与资金的清算，钱直接从用户的账户到商户在微信支付宝银联的账户里，我们没有做代理清算。做了代理清算是不是不安全有待商榷，但是我们这样完全不做代理清算的话，资金安全由支付宝、微信、银联直接保证的。

回到主问题，既然使用第三方支付集成存在这些风险，那么是否表示一定不能用这类第三方服务呢？、

我觉得不然，即使是站在一个客观的角度。

节省开发周期，节约开发的时间和人工成本，快速接入，这些都是显而易见的好处，我暂且放下不说。针对我刚才提到的3点风险，我做一个分析：

1、服务端稳定性

支付的服务是需要backend的支持的，比如算签名，比如从支付渠道那里接收支付结果的回调，比如记录支付结果，这一类的服务都需要云端的服务器的支持，因为这些事情是客户端不可能做到的。有了云端的服务器，就会有稳定性的风险，那这个选择就在于你是希望自己来take care一切，还是把其中的一部分（比如支付）的稳定性的保障交给一些人（比如BeeCloud）来take care？我回国之前就在美国硅谷上班，那里各种第三方技术服务的使用习惯很好，一个网站或者一个app基本都是各种第三方服务拼装起来的，我们的榜样Stripe就是这个例子。国内目前对这个第三方服务的接受度也是在逐步提高的。我永远都不会说BeeCloud是完美的，但是我们一直在努力解决我们遇到的各种问题，比如如果一台服务器故障，如何保障服务不会宕掉，比如突发的高并发如何处理。无论是稳定性，还是性能都是影响终端用户付款体验的重要部分，无论是否使用第三方的集成服务，如果你们产品交易量不小的话，我建议都需要找一个专业的团队设计实现支付的后端架构，因为支付毕竟是产品的各种组件中至关重要的一个部分，如果出问题会带来直接的经济损失。

2、支付参数的安全性

首先讨论下黑客拿到某个商户A的支付参数可以用来做什么？拿支付宝的即时到帐产品举例吧。

第一，收款

黑客可以用这些参数开发一个自己的网站，以商户A的名义通过支付宝即时到帐产品收款。从资金层面，黑客并没有办法收到钱，因为钱直接被付到商户A的对公支付宝账号里。但是这也存在一些隐患，比如黑客的目的不是金钱，而是损害商户A，使用商户A的支付参数在非法的网站上进行收款服务，就有可能导致商户A的支付宝账户被封禁。

第二，退款

黑客可以利用退款参数，对已经支付过的某一笔订单发起退款，当然需要首先知道一笔已经支付成功的订单的订单号，其次商户A必须同意这一笔退款，例如支付宝的话，还需要登陆支付宝商户后台输入支付密码才能完成退款。其他评论中有提到一些第三方支付的代扣接口，这些参数如果丢失，可能导致更严重的后果，不过如果如果仅仅依赖于支付参数而没有其他的风控措施的话，这些接口本身的安全性也是值得诟病的。

3、客户端的bug

我觉得这个问题和1是一样的，还是那个选择的问题，你是愿意自己take care这些bug的处理（因为你就算自己实现，也有可能引入各种bug），还是把支付的客户端业务交给第三方的SDK提供方来take care。其实换一个角度，因为一个SDK被各种不同的客户用过，有各种bug肯定会被各种客户发现然后修正，经过了一段时间的积累，SDK的那部分代码出错的可能会远小于自己去从头实现一套自己的客户端。

总结一下就是，我觉得社会需要分工，一些工作（比如接入支付宝，微信，银联这些技术开发集成），如果有人做过，就没必要大家都重复去造轮子，节约下来的时间人力物力还有程序员的脑力可以为祖国的四个现代化建设做很多事情，BeeCloud就是我基于这样的一个理念创立的。

注1：本评论在2015/7/15修正过，主要是修正了对支付参数安全性的一些不太确切的描述。

爱贝云计费

爱贝云计费，从2009年开始就在做在线计费和在线支付集成方案的公司，初创团队是最早在移动梦网时代就作计费平台的产品研发人员。

很多人都从技术方面和安全方面去分析使用第三方支付集成方案的必要性，其实这也是国内外互联网行业的一个很重要的差异。

1、从技术上来说

专业的事情专业的人来做，第三方的支付集成商专注在这个领域中，像前面的兄弟所说的，该踩的坑，能踩的坑都基本上趟得差不多了。例如：前段时间某个支付通道方切换DNS服务，造成北方服务的不稳定，像爱贝，会进行南北异地机房的服务切换，而一般的开发者是不会专门只是为了支付去作多机房服务热备的。降低了开发者的开发成本，这个大家应该都是能体会到的。除了接入时的开发成本以外，当支付平台方有作变动的时候，也都由集成商对这些变动作了兼容，而减少了开发者需要强更客户端等的风险。同时，在作多平台的兼容的时候，使用集成商的服务也更有优势，大部分平台都会覆盖ios、android、h5、pc，像爱贝还覆盖了wins，同时考虑到pad和6'屏以上的大屏手机的用户交互问题，还单独出HD版本来进行适配，以提高用户付费的转化率（互联网上的消费，大部分时候是冲动消费，如何快速的进行转化为实际消费很重要）

2、安全性

第一：技术上的安全性，像爱贝的所有接口都是要作对称加密的，包括服务端之间的回调等，信息泄漏上面本身不存在问题。

第二：服务端泄漏商户的敏感信息，包括帐号信息和交易数据等。正因为支付集成公司是做跟计费支付相关的，跟钱很近的业务，所以这方面的管控比一般的公司都要严格很多，爱贝云计费的在线支付集成服务上线6年了，服务几千家商户，都从未发生过这种信息泄漏问题，所以目前百度、中国移动、酷派云商店等这样大型互联网公司、互联网渠道方和电信运营商都在使用爱贝的服务。

3、其他的增值服务

第三方的支付集成商，一般都会提供其他的增值服务，这块对于大部分的开发团队来说都是隐性的成本。像爱贝会提供7x24小时的客服座席服务，来处理用户支付过程中的问题，包括用户的投诉，支付掉单的补单等，多维度的数据统计分析来帮助日常的运营决策等。

我也从事了十几年的互联网产品研发，在重复造轮子的问题上，国内的公司，都很容易陷入到大而全，小而全的循环中去，在互联网公司中会尤为突出，技术上确实没有不可实现的，但是管理者需要考虑开发成本和时间成本。市场化的公司应该专注在擅长和主营的业务中去，特定的领域采用专业公司的服务，自身轻装上阵，在互联网这种快鱼吃慢鱼的环境中业务会更有竞争力。

最后，在那些体量已经很大的公司中，确实是会做闭环，但是大家都会发现支付部门都是独立于业务部门存在的团队，从一定程度上来说，业务部门其实也是在使用第三方提供的支付服务。

付钱拉

这个问题看了楼上的回答，包括同行的两家业界翘楚，除了前面给出的答案，我也来说说我的理解。

首先是业务方面。

支付的专业性较强，小企业资源有限，使用第三方支付集成商可以降低企业成本，将有限的资源及精力放到自身的核心业务上。

1. 互联网企业使用支付主要进行收款

除商户密钥外，所有信息的采集均在第三方支付公司，第三方支付公司的账号密码都在商户自己手中，第三方支付集成商不能发起提现，即便是跑路，钱也乖乖的趴在第三方支付公司账户上。

2. 怎样才算真正支付了

真正发起了一笔交易？这其中的信息流为：商户端（例如app）－ 第三方支付集成商 － 第三方支付公司－银行，走第三方支付集成商的企业的信息流和企业直接接第三方支付公司比起来，只多了一步集成商而已。资金流为：客户银行卡 － 第三方支付公司备付金账户 － 商户银行卡，这个资金流与企业是否接入第三方支付集成商毫无关系。至于说到第三方支付集成商，真正的风险是系统宕机，这块在技术方面再详细说。

3. 运营咨询

支付的坑（这一部分楼上都没有提到）不仅仅在于支付接入上，在后续的业务运营当中，不断的有新的问题发生。这些问题对于小企业都很难快速定位，在最短的时间内给用户一个满意的答案。例如用户拒付了怎么办、支付公司对某笔交易调单了怎么办、用户重复支付了怎么办、对账发生差异了怎么办等一系列的问题，如果使用专业的的第三方支付集成商，这些问题都可以得到很好的解决。

其次是技术方面。技术层面的很多风险都可以通过处理进行解决。

1. 操作风险

支付系统和钱打交道，风险的控制和一般互联网系统是完全不一样的，所以操作风险是其中非常严重的一个风险之一。常见的有上线风险、配置风险、测试风险和运营风险。

上线风险，指在上线过程中因为操作问题到导致，最好的解决方案是实现完全的灰度发布，彻底隔离用户数据；

配置风险，指证书、响应码等等的配置错误导致的风险，这块最好的解决方案是通过严格的自动化流程控制，去除人工化操作；

测试风险，指测试过程疏忽导致的资金风险，这块也需要严格的自动化流程控制；

运营风险，指的是比如路由切换等造成的风险，这里只能通过审核来控制，没有特别好的方法，因为有的地方是必须人参与、不可自动化的部分。

2. 程序风险

常见的有并发风险，状态设置错误风险，核对风险，查询风险等。

并发风险，指分布式环境下，由于并发导致的资金多付少付，多扣少扣风险，这块最好的方案是有限状态机加影响条数来解决；

状态设置错误风险，是指所有的第三方支付集成都是对接三方的响应码，响应码管理是非常复杂的事情，如果状态翻译错误，那么就会导致资金风险，所以方案是统一响应码+状态保守原则，即非明确失败的状态一定是处理中，后续通过查询查回结果；

核对风险，是指第一次查询结果和第二次查询结果可能不一致，这个常常是由于三方和银行某些特殊错误导致的，所以一定需要核对查询；

查询风险，常见的就是查询速度过快导致订单不存在，所以针对不同的三方，都需要设置不同的查询时间。

总结

除了becloud的黄总和pingxx说的没必要大家都重复造轮子，选择专业的第三方支付集成集成商，可以帮助小企业规避支付风险。

最后，我们也来分享下付钱拉的故事，付钱拉：基于聚合支付展开的金融服务，如此多样

官网：付钱拉_首页 | 创业者的支付之道

参考推荐：

Ping++ 和 BeeCloud 比较

2016年第三方支付公司排名

聚合支付的核心价值是什么

支付宝、财付通、网银、快钱、百度、京东接口费率