在支付系统中,支付网关和支付渠道的对接是最核心的功能。其中支付网关是对外提供服务的接口,所有需要渠道支持的资金操作都需要通过网关分发到对应的渠道模块上。一旦定型,后续就很少,也很难调整。而支付渠道模块是接收网关的请求,调用渠道接口执行真正的资金操作。每个渠道的接口,传输方式都不尽相同,所以在这里,支付网关相对于支付渠道模块的作用,类似设计模式中的wrapper,封装各个渠道的差异,对网关呈现统一的接口。而网关的功能是为业务提供通用接口,一些和渠道交互的公共操作,也会放置到网关中。 功能概述支付系统对其他系统,特别是交易系统,提供的支付服务包括签约,支付,退款,充值,转帐,解约等。有些地方还会额外提供签约并支付的接口,用于支持在支付过程中绑卡。 每个服务实现的流程也是基本类似,包括下单,取消订单,退单,查单等操作。每个操作实现,都包括参数校验,支付路由,生成订单,风险评估,调用渠道服务,更新订单和发送消息这7步,对于一些比较复杂的渠道服务,还会涉及到异步同通知处理的步骤。这里详细介绍这些步骤的实现要点。 1. 执行参数校验 所有的支付操作,都需要对输入执行参数校验,避免接口受到攻击。
2. 根据支付路由寻找合适的支付服务 根据用户选择的支付方式确定用来完成该操作的合适的支付渠道。用户指定的支付方式不一定是最终的执行支付的渠道。比如用户选择通过工行信用卡来执行支付,但是我们没有实现和工行的对接,而是可以通过第三方支付,比如支付宝、微信支付、易宝支付,或者银联来完成。那如何选择合适的支付渠道,就通过支付路由来实现。支付路由会综合考虑收费、渠道的可用性等因素来选择最优方案。 3. 评估交易风险 检查本次交易是否有风险。风控接口返回三种结果:阻断交易、增强验证和放行交易。
4.生成交易订单 将订单信息持久化到数据库中。当访问压力大的时候,数据库写入会成为一个瓶颈。 5. 调用支付渠道提供的服务 所有的支付服务都需要第三方通道来完成执行。一般银行渠道的调用比较简单,可以直接返回结果。一些第三方支付,支付宝,微信支付等,会通过异步接口来告知支付结果。 6. 更新订单 对于同步返回的结果,需要在主线程中更新订单的状态,标记是支付成功还是失败。对于异步返回的渠道,需要在异步程序中处理。 7. 发送消息 通过消息来通知相关系统关于订单的变更。风控,信用BI等,都需要依赖这数据做准实时计算。 8. 异步通知 如上述流程,其中涉及到调用远程接口,其延迟不可控。如果调用方一直阻塞等待,很容易超时。引入异步通知机制,可以让调用方在主线程中尽快返回,通过异步线程来得到支付结果。对于通过异步来获取支付结果的渠道接口,也需要对应的在异步通知中将结果返回给调用方。 异步通知需要调用方提供一个回调地址,一般以http或者https的方式。这就有技术风险,如果调用失败,还需要重试。而重试不能过于频繁,需要逐步拉大每一次重试的时间间隔。 在异步处理程序中,订单根据处理结果变更状态后,也要发消息通知相关系统。 整体架构整体软件参考架构如下所示: 支付网关前置支付网关前置是对接业务系统,为其提供支付服务的模块。它是所有支付服务接口的集成前置,将不同支付渠道提供的接口通过统一的方式呈现给业务方。这样接入方就只需要对接支付网关,增加和调整支付渠道对业务方是透明的。 支付网关前置的设计对整个支付系统的稳定性、功能、性能以及其他非功能性需求有着直接的影响。 在支付网关中需要完成大量的操作,为了保证性能,这些操作都尽量异步化来处理。 支付网关前置应保持稳定,尽量减少系统重启等操作对业务方的影响。支付网关也避免不了升级和重启。这可通过基于Nginx的LBS(Load Balance System)网关来解决。LBS在这里有两个作用: 一个是实现负载均衡,一个是隔离支付网关重启对调用的影响。 支付网关也采用多台机器分布式部署,重启时,每个服务器逐个启动。某台服务器重启时,首先从LBS系统中取消注册,重启完成后,再重新注册到LBS上。这个过程对调用方是无感知的。 为了避免接口受攻击,在安全上,还得要求业务方通过HTTPS来访问接口,并提供防篡改机制。防篡改则通过接口参数签名来处理。现在主流的签名是对接口参数按照参数名称排序后,做加密和散列,参考微信的签名规范。 交易流水和记账每一笔交易都需要记录流水,并登记到个人和机构的分户账户上,统计和分析也需要根据交易流水来更新相关数据。 而个人和机构账户总额更新、交易流水记录以及库存的处理,更是需要事务处理机制的支持。 从性能角度, 可以弱化了事务处理的要求,采用消息机制来异步化和交易相关的数据处理。
风控模块风控对支付的重要性怎么强调都不过分。有些系统在风控出问题时可以旁路风控,但是在支付系统中,风控出问题必须停止交易。 整体上,风控可以分为数据采集,数据分析,实时计算,规则配置,实时拦截等模块。风控本身是个大话题,以后专门讨论。又欠一个债。 但风控和交易的接口比较简单。对每一次交易,风控一般返回三个结果:拦截,增强验证,通过。通过指交易没有问题,可以直接放行。拦截则是阻止本次交易。增强验证则是交易存疑,需要用户进一步核实身份才能继续,比如输入手机号或者身份证号,一般用于身份被盗用的场景。而人工核实则是对交易有疑问,一般用于个人恶意消费满场景。 支付路由支付路由是一个复杂的话题。对支付系统来说,能支持的支付方式越多越好,不能由于支付方式的不支持断了财路。现实中的支付方式多得难以置信。用户随时甩出一张你听都没听说过的卡。如果一个银行卡只有几个用户在用,那针对这个卡开发个对接有点得不尝失。现在第三方支付的爆发,确实给开发支付系统省了不少事。但是公司不可能只对接一个第三方支付,如果这个渠道出问题了,或者闹矛盾了,把链接给掐了,老板还不欲哭无泪。总之,得对接多个渠道。对于交易量大的银行,还得考虑直联。 支付路由的作用是定义对用户选用的银行卡或者其他支付方式,使用什么渠道来完成支付。 一般来说,银行会提供两种支付途径:无跳转的快捷支付接口和带跳转的网银接口。前者在绑卡,支付的时候,不需要跳到银行页面上去处理,后者则需要在银行的网银页面上完成。显然前者对用户来说体验要好多了,用户流程不会被打断。快捷支付要求支付系统在本地保存用户的支付信息,如卡号,登记手机。系统要确保这些信息不被泄漏。风险非常好,所以大部分银行要求接入方必须经过ADSS检验才能够接入快捷支付。 这种固定方式的接入有单点故障的问题,一旦某个渠道出问题,绑定的支付方式就无法使用。改进策略是为每个支付方式定义多个渠道,第一个渠道出问题即选择第二个,以此类推。 当然,更进一步,可以为候选渠道定义权重,按照权重来选择支付方式。当渠道出问题,自动调整权重。 路由实现上还会更复杂,对同一张银行卡,运营上会要求在不同的系统上,比如android,iOS,windows上,或者不同地区,如大陆,台湾,香港,北美等,甚至不同业务上,采用不同渠道来支付。 支付渠道如果采用微服务来实现,整体设计上,可以考虑将支付渠道分离、支付网关前置分离。支付渠道的微服务实现有两种策略,一种是按照服务来拆分,一种是按照渠道来拆分。
渠道拆分按照服务来拆分的一个典型案例是大众点评网的早期实现。 大众点评支付渠道网关系统的实践之路。 每个支付服务接口实现为一个独立的子系统,独立部署,通过支付网关前置来对外提供服务。 这篇文章里面也提到这种方式存在的问题,
接入渠道对于支付渠道,首先考虑的是接入哪些渠道。要对接的渠道按优先级有:
这篇文章对支付系统整体设计做一个概要描述,后续会逐步补充内容并完善。其实每个模块都是一个大坑,有很多的技术细节。 欢迎大家提提意见,一起探讨。 修订记录
感谢您对本文的关注,如需要及时收到凤凰牌老熊的最新作品,或者有相关问题探讨,请扫码关注“凤凰牌老熊”的微信公众号,在公众号里留言或者回复,可以尽快处理,谢谢。
|
|