支付系统架构支付系统架构
大部分公司,只要想赚钱,就得上支付系统,让用户或者客户有地方交钱。 当然,公司发展的不同阶段,对支付系统的定位
和架构也不同。整体上来说,我们可以把一个公司的支付系统发展分为三个阶段:
1、支付系统:支付作为一个(封闭)的、独立的应用系统,为各系统提供支付功能支持。一般来说,这个系统仅限于为公司
内部的业务提供支付支持,并且和业务紧密耦合。
2、支付服务:支付作为一个开发的系统,为公司内外部系统、各种业务提供支付服务。支付服务本身应该是和具体的业务解
耦合的。
3、支付平台:支付作为一个可扩展的平台, 公司内外部的用户可以在此基础上定制开发自己的服务。
这个划分有点勉强。简单说,支付系统是仅供内部使用的, 支付服务是支持公司内外部来调用的,支付平台是可以在服务的
基础上定制各种场景支持的。
支付业务流程
区分两个概念:支付和交易。支付是交易的一部分。一个简单的交易过程包括:客户下订单,客户完成支付,商家接收订单,商
家出货。这里仅考虑下订单的流程。从软件工程的角度, 我们首先需要明确下几个参与者。
电商系统,指提供在线购物服务的系统。用户在这个系统中完成交易。
支付系统,可以是电商系统的一个模块,或者是个独立的系统。这是本文的主角,用来完成支付过程。
用户,在电商系统中败家的那位。如果使用银行卡做交易,那也被称为持卡人。
用户使用银行卡交易时,发行这个银行卡的机构称为发卡行,或者发卡机构。
商家也需要一张卡,就是大家在淘宝开网店的时候要登记的银行卡,最终需要把用户给的钱打到这张卡上。
和发卡机构相对应的,大家听到最多的是收单机构。如支付宝,微信等第三方支付公司,介绍业务的时候总少不了互联网收单
的工作。它们把用户订单收起来,找发卡行要钱,就有了收单业务。
主演都有了,下面就是如何演出支付这场大戏了。正常的流程应该是这样:
1、用户提交订单到电商系统,电商系统对订单进行检验,无问题则调起支付接口执行支付。注意这里支付接口是在服务器端
调起的。一般支付接口很少从客户端直接调起。为了安全,支付接口一般要求用HTTPS来访问,并对接口做签名。关于支付
接口的设计,我将另起博文介绍。
2、支付系统检查参数有效性,特别是签名的有效性。
3、根据用户选择的支付方式,以及系统支付路由设置,选择合适的收单机构。这里涉及三个概念,支付方式,支付路由。这
又是一个槽点。简单说,用户可以选择各种银行卡支付,比如宁波银行卡,但是你的支付系统没有对接宁波银行,那对这种
卡,可以选择你接入的,支持这个卡的收单机构来执行支付,如用微信或者支付宝等等第三方支付,或者银联支付等系统支持
的方式来执行。这就是支付路由,根据用户提供的银行卡来选择合适的收单机构去执行支付。常用支付方式还包括第三方支
付,如微信支付宝等,这种情况下就不需要支付路由了。
4、调用收单接口执行支付。这是支付系统的核心。每个公司的收单接口都不一样,接入一两个收单机构还好,接入的多了,
如何统一这些接口,就是一个设计难点。
5、支付成功,收单机构把钱打到商户的账户上了。 商家就准备发货了。 怎么发货,不是本文的重点。 这里关注的要点是,
商家能收到多少钱? 比如100块钱的商品,用户支付了100块钱(运费、打折等另算),这100块钱,还要刨去电商系统的佣
金、支付通道的手续费,才能最终落到商家手里。
这是个Happy流程,一切看起来都很美好,但实际上步步都是坑,一旦有地方考虑不周全,轻者掉单频发,重者接口被盗刷,
损失惨重。
如何避免攻击者修改支付接口参数, 比如100块钱的东西,改成10块钱?
调用收单接口来执行最终实际支付时,如果支付失败了,比如卡上没钱了,怎么办?
收单接口把账户上的钱扣走了,但是通知支付系统的时候出错了(比如网络闪断,或者支付系统重启了),支付系统不知道这
笔交易已经达成了,怎么处理?
还有好多问题….
和钱打交道,在任何公司,都跑不掉财务部门。 那财务部门会关注哪些内容? 当然,最重要的是账务信息。 所有的交易都要
记账,按要求公司都需要定期做审计,每一笔帐都不能出错。这当然不能等到审计的时候再去核对,而是每天都需要对账,确
保所有的交易支出相抵,也就是所说的把账给平了。 这就有三种情况:电商系统和商家对账;电商系统和支付系统对账;支
付系统和收单机构对账。最为支付系统,我们仅关注后两者的情况。
评论0
最新资源