第三方支付平台

个人支付接口现状分析--如何选择一个靠谱的支付接口本篇文章的目的，是向正在寻求个人支付方案的开发者朋友们提供一些信息，希望能给他们一定的帮助，结合自己的使用环境、业务领域和应用场景自行选择。对提到的所有第三方支付工具、第四方聚合支付工具绝无恶意贬低。如何选择一个靠谱的个人支付服务方？选择标准1.var 标准 = 安全性 && 稳定性 && 结算周期 && 费率2.var EFS = 使用环境 + 业务领域 + 应用场景服务方分类互联网支付方式有很多种，基本上将网上支付服务分为几种：1.原生网银支付2.国内主流第三方支付3.其他第三方支付4.第四方聚合支付网银支付想要接入银行，需要一家家的去谈，资质不足的话一般是不可以申请网银的，涉及到企业资格，承诺、合同、不菲的保证金，就个人来说还是不要考虑了，不现实第三方支付1.原生支付宝支持电脑网站支付，手机网站支付，APP支付和当面付，但是接入需要网站备案，需要有营业执照，不管怎么说还是要企业资质。2.微信支持公众号支付，APP支付，扫码支付，刷卡支付和微信买单，使用扫码支付，需要先注册公众号，然后提交企业资质认证，验证通过后，才能接入，还是需要企业资质才能直接接入。以上两种想一下都不是一个简单的工程，对大多数人而言，以上两大主流方式行不通。其他第三方支付PayPal有些人可能不熟悉，这是一个全球支付的工具，主打境外收付款，那么对于做外贸的朋友来说是一个不错的选择。有网站，无网站，B2B商家，个人收款都适用。用户注册后，可以在网站商获取一个PayPal账户，当客户付款后，款项会打到用户的PayPal的账户中，但是，提现到国内的银行，需要手续费的，算下来差不多近5%的手续费，而且PayPal比较偏向买家，如果买家有任何不满意而产生的争议，卖家将拿不到钱。有赞通过有赞微商城支付接口收款。需手动提现，不免费，费用6800/年起，一旦风控资金很难取出。云付通Passpay支持个人和企业接入。个人接入需要实名认证，企业认证需要企业资质，收款存入银行或者微信、支付宝平台上，平台不留存资金，支持的付款方式丰富，但是手续费颇高，提现有门槛。第四方聚合支付Ping++所谓聚合支付 ，实际上是简化了平台接入的流程而已，适合对多个系统对接的需求，个人开发者仍然需要去申请所需接口的使用权限，所以，企业资质也是需要的。美团 & 支付宝口碑通过美团商家码收款，通过支付宝口碑掌柜收款。支付转化率并不高，可能随时被风控通过金额通过技术手段监听通知栏，判定支付宝通知，获取金额信息，本质上依然是采用挂机监听的策略，成本高，配置麻烦，需24小时挂台安卓手机，不免费，PaysApi、虎皮椒，支付吧等移动端hook基于virtual xposed hook相关技术，可自动生成任意备注金额收款码 成本高，配置麻烦，需24小时挂台安卓手机，潜在风险系数高，被风控的概率会非常之高。微米富，greenyep等paybob专业为个人支付而生的支付接口，支持微信、支付宝。为个人开发者/个体户/小微企业，提供安全稳定，正规快捷的收款服务。支持NATIVE/JSAPI/收银台/小程序等支付方式。稳定原生回调（毫秒级），成功率100%，资金直接到个人。个人资质就可开通，一次开通永久使用。可免费开通针对特定行业0%的手续费。市场上面的方案，看起来好像很多，但总结一下主要是下面两类代收结算主要缺点：资金安全难以保障，代收结算天然的额外成本带来的高费率。App挂机监听类主要缺点：首先也是安全性， 能监听支付信息就可以监听其他信息， 稳定性差 ， 比如通知延时，漏单等等。对于个人支付来说，到底有没有正儿八经的个人支付接口呢？大家可以看一下最后提到的 paybob支付，这里有一张详细的个人支付对比表，看过之后可能会有一个更清晰的认识.个其实每个产品都有自己的特性，并不是说哪个好，哪个不好，看自身的实际情况去选择以上只是个人见解，不足之处欢迎拍砖。

微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。 老司机倾囊相授，带你一路进阶，来不及解释了快上车！我在前一家公司的第一个任务是开发统一支付平台，由于公司的业务需求，需要接入多个第三方支付，之前公司的支付都是散落在各个项目中，及其不利于支付的管理，于是聚合三方支付，统一支付平台的任务就落在我手上，可以说是完全从 0 开始设计，经过一翻实战总结，我得出了一些架构设计上的思考，之前就一直很想把自己的架构设计思路写出来，但一直没动手，前几天在技术群里有人问到相关问题，我觉得有必要把它写出来，以帮助到更多需要开发支付平台的开发人员。 组件模式由于公司业务在很多地区都有，需要提供多种支付途径，以满足业务的发展，所以设计的支付平台需要接入多种第三方支付渠道，如：微信支付、支付宝支付、PayPal、IPayLinks 等等，我们都知道，每个第三方支付，都有自己一套对外 API，官方都有一套 SDK 来实现这些 API，我们应该如何组织这些 API 呢？ 由于第三方支付渠道会随着业务的发展变动，所以组织这些 SDK 就需要在不影响支付平台整体架构的前提下可灵活插拔，这里我使用了组件的思想，将支付 API 拆分成各种组件支付组件、退款组件、订单组件、账单组件等等，那么这样就可以当引入一个第三方支付 SDK 时，可灵活在组件上面添加需要的 API，架构设计如下： 通过 Builder 模式根据请求参数构建对应的组件对象，将组件与外部分离，隐藏组件构建的实现。组件模式 + Builder 模式使得支付平台具备了高扩展性。 多账户体系在接入各种第三方支付平台，我们当时又遇到一个账户的问题，原因是公司当时的小程序与 APP 使用的是不同的微信账号，因此会出现微信支付会对应到多个账户的问题，而我当时设计支付平台时，没有考虑到这个问题，当时第三方支付只对应了一个账户，而且不同的第三方支付的账户之间相互独立且不统一。 于是我引入了多账户体系，多账户体系最重要的一个核心概念是以账户为粒度，接入多个第三方支付，统一账户的参数，构建了统一的支付账户体系，支付平台无需关心不同支付之间的账户差异以及第三方支付是否有多少个账户。 此时我在支付平台架构图加上账户层： 前端只需要传递 accountId，支付平台就可以根据 accountId 查询出对应的支付账户，然后通过 Builder 模式构建支付账户对应的组件对象，完全屏蔽不同支付之间的差异，在多账户体系里面，可以支持无限多个支付账户，完全满足了公司业务的发展需求。 统一回调与异步分发处理做过支付开发的同学都知道，目前的第三方支付都有一个特点，就是支付/退款成功后，会有一个支付/退款回调的功能，目的是为了让商户平台自行校验该笔订单是否合法，比如：防止在支付时，客户端恶意篡改金额等参数，那么此时支付成功后，订单会处于支付中状态，需要等待第三方支付的回调，如果此时收到了回调，在校验时发现订单的金额与支付的金额不对，然后将订单改成支付失败，以防止资金损失。回调的思想是只要保证最终的一致性，所以我们调起支付时，并不需要在此时校验参数的正确性，只需要在回调时校验即可。 讲完了回调的目的，那么我们如何来设计支付平台的回调呢？ 由于支付平台接入了多个第三方支付，如果此时每个第三方支付设置一个回调地址，那么将会出现多个回调地址，由于回调的 API 必须是暴露出去才能接受第三方的回调请求，所以就会有安全问题，我们必须在 API 外层设置安全过滤，不然很容易出现一些非法暴力访问，所以我们需要统一回调 API，统一做安全校验，之后再进行一层分发。 分发的机制我这里建议用 RocketMQ 来处理，可能有人会问，如果用 RocketMQ 来做分发处理，此时怎么实时返回校验结果到第三方支付呢？这个问题也是我当时一直头疼的问题，以下是我对回调设计的一些思考： 公司的系统是基于 SpringCloud 微服务架构，微服务之间通过 HTTP 通信，当时有很多个微服务接入了我的支付平台，如果用 HTTP 作分发，可以保证消息返回的实时性，但也会出现一个问题，由于网络不稳定，就会出现请求失败或超时的问题，接口的稳定性得不到保障。由于第三方支付如果收到 false 响应，就在接下来一段时间内再次发起回调请求，这么做的目的是为了保证回调的成功率，对于第三方支付来说，这没毛病，但对于商户支付平台来说，也许就是一个比较坑爹的设计，你想一下，假设有一笔订单在支付时恶意篡改了金额，回调校验失败，返回 false 到第三方支付，此时第三方支付会再重复发送回调，无论发送多少次回调，都会校验失败，这就额外增加了不必要的交互，当然这里也可以用幂等作处理，以下是微信支付回调的应用场景说明： 基于以上两点思考，我认为返回 false 到第三方支付是没必要的，为了系统的健壮性，我采用了消息队列来做异步分发，支付平台收到回调请求后直接返回 true，这时你可能会提出一个疑问，如果此时校验失败了，但此时返回 true，会不会出现问题？首先，校验失败情况，订单必定是处于支付失败的状态，此时返回 true 目的是为了减少与第三方支付不必要的远程交互。 ...