概述
支付作为一个开发的系统,为公司内外部系统、各种业务提供支付服务,支付服务本身应该是和具体的业务解耦合。
我们先来看一下用户完成一次购物需要进行那些操作:
通常消费者在手机APP或者网站都会涉及到支付相关的业务场景,用户只需要简单点击支付按钮输入支付密码,就可以完成整个支付过程,那么我就和大家一起来看看一个完整的支付系统有什么功能组成和设计时需要考虑那些问题。
从上图中我们可以看出真实的资金流向。首先当用户产生支付行为时,资金从用户端流向支付系统,退款时则相反,从支付系统回流至用户端。因此在整个交易过程中用户端与支付系统是双向资金的流动方式。对于支付系统而言,资金有进有出。从支付系统到商户端就比较简单了,在清算完成后支付系统负责将代收的资金结算给商户,通常结算的操作可以在线上来完成(采用支付公司代付接口或者银企直连接口来完成),也可以由公司财务通过线下手工转账的方式来完成,因此这种资金流动的方式是单向的。出于资金安全考虑,大多数公司通常这部分采用线下方式实现。
真实的资金流由支付公司按照约定期限(通常 T+1 )结算到平台公司对公账户中,然后再由平台公司再按照交易明细进行二次清算后结算给对应的商户。
01.完整的支付系统包括如下功能:
|
02.核心流程
03.支付流程说明
一般而言支付系统会给商户设置有“可用余额”账户、“待结算”账户;系统在接收到银行返回支付成功信息会进行落地处理,一方面更改对应订单状态,另一方面在商户待结算账户记入一笔金额;该笔金额,系统会根据结算周期从待结算账户--->“可用余额”账户。 |
04.退款流程说明
对于收单金额未结算,还在“待结算”账户的订单,如果出现退款情况,业务流程和上述流程差不多,只是从待结算账户进行扣款。 |
05.支付系统要点
在支付系统中,支付网关和支付渠道的对接是最繁琐重要的功能之一,其中支付网关是对外提供服务的接口,所有需要渠道支持的资金操作都需要通过网关分发到对应的渠道模块上。一旦定型,后续就很少,也很难调整。而支付渠道模块是接收网关的请求,调用渠道接口执行真正的资金操作。每个渠道的接口,传输方式都不尽相同,所以在这里,支付网关相对于支付渠道模块的作用,类似设计模式中的wrapper,封装各个渠道的差异,对网关呈现统一的接口。而网关的功能是为业务提供通用接口,一些和渠道交互的公共操作,也会放置到网关中。 支付系统对其他系统,特别是交易系统,提供的支付服务包括签约,支付,退款,充值,转帐,解约等。有些地方还会额外提供签约并支付的接口,用于支持在支付过程中绑卡。 每个服务实现的流程也是基本类似,包括下单,取消订单,退单,查单等操作。每个操作实现,都包括参数校验,支付路由,生成订单,风险评估,调用渠道服务,更新订单和发送消息这7步,对于一些比较复杂的渠道服务,还会涉及到异步同通知处理的步骤。 01 网关前置 支付网关前置是对接业务系统,为其提供支付服务的模块。它是所有支付服务接口的集成前置,将不同支付渠道提供的接口通过统一的方式呈现给业务方。这样接入方就只需要对接支付网关,增加和调整支付渠道对业务方是透明的。 支付网关前置的设计对整个支付系统的稳定性、功能、性能以及其他非功能性需求有着直接的影响。 在支付网关中需要完成大量的操作,为了保证性能,这些操作都尽量异步化来处理。支付网关前置应保持稳定,尽量减少系统重启等操作对业务方的影响。支付网关也避免不了升级和重启。这可通过基于Nginx的LBS(Load Balance System)网关来解决。LBS在这里有两个作用: 一个是实现负载均衡,一个是隔离支付网关重启对调用的影响。 支付网关也采用多台机器分布式部署,重启时,每个服务器逐个启动。某台服务器重启时,首先从LBS系统中取消注册,重启完成后,再重新注册到LBS上。这个过程对调用方是无感知的。 为了避免接口受攻击,在安全上,还得要求业务方通过HTTPS来访问接口,并提供防篡改机制。防篡改则通过接口参数签名来处理。现在主流的签名是对接口参数按照参数名称排序后,做加密和散列,参考微信的签名规范。 02 参数校验
03 路由选择 根据用户选择的支付方式确定用来完成该操作的合适的支付渠道。用户指定的支付方式不一定是最终的执行支付的渠道。比如用户选择通过工行信用卡来执行支付,但是我们没有实现和工行的对接,而是可以通过第三方支付,比如支付宝、微信支付、易宝支付,或者银联来完成。那如何选择合适的支付渠道,就通过支付路由来实现。支付路由会综合考虑收费、渠道的可用性等因素来选择最优方案 04 风险评估 检查本次交易是否有风险。风控接口返回三种结果:阻断交易、增强验证和放行交易。
05 发送消息 通过消息来通知相关系统关于订单的变更。风控,信用BI等,都需要依赖这数据做准实时计算。 06 更新订单 对于同步返回的结果,需要在主线程中更新订单的状态,标记是支付成功还是失败。对于异步返回的渠道,需要在异步程序中处理。 07 异步通知 其中涉及到调用远程接口,其延迟不可控。如果调用方一直阻塞等待,很容易超时。引入异步通知机制,可以让调用方在主线程中尽快返回,通过异步线程来得到支付结果。对于通过异步来获取支付结果的渠道接口,也需要对应的在异步通知中将结果返回给调用方。 异步通知需要调用方提供一个回调地址,一般以http或者https的方式。这就有技术风险,如果调用失败,还需要重试。而重试不能过于频繁,需要逐步拉大每一次重试的时间间隔。 在异步处理程序中,订单根据处理结果变更状态后,也要发消息通知相关系统。 08 生成交易订单 将订单信息持久化到数据库中。当访问压力大的时候,数据库写入会成为一个瓶颈。 09 交易流水和记账 每一笔交易都需要记录流水,并登记到个人和机构的分户账户上,统计和分析也需要根据交易流水来更新相关数据。 而个人和机构账户总额更新、交易流水记录以及库存的处理,更是需要事务处理机制的支持。 从性能角度, 可以弱化了事务处理的要求,采用消息机制来异步化和交易相关的数据处理。
10 支付路由 支付路由是一个复杂的话题。对支付系统来说,能支持的支付方式越多越好,不能由于支付方式的不支持断了财路。现实中的支付方式多得难以置信。用户随时甩出一张你听都没听说过的卡。如果一个银行卡只有几个用户在用,那针对这个卡开发个对接有点得不尝失。现在第三方支付的爆发,确实给开发支付系统省了不少事。但是公司不可能只对接一个第三方支付,如果这个渠道出问题了,或者闹矛盾了,把链接给掐了,老板还不欲哭无泪。总之,得对接多个渠道。对于交易量大的银行,还得考虑直联。 11 渠道接入 对于支付渠道,首先考虑的是接入哪些渠道。要对接的渠道按优先级有:
|
支付系统是一个繁杂的系统,其中涉及了各种错综复杂的业务流程,以上只是简单介绍了支付系统我们能看见的一些问题和设计,还有后续的系统保障没有写出来,没写出来的才是关键部分,比如:支付系统监控(业务监控分类、渠道监控、商户监控、账户监控)文章只是引子, 架构不是静态的,而是动态演化的。只有能够不断应对环境变化的系统,才是有生命力的系统。所以即使你掌握了以上所有的业务细节,仍然需要演化式思维,在设计的同时,借助反馈和进化的力量推动架构的持续演进。