• 支付系统架构设计(上)

    /2019-09-26 14:02:39/

  • \

    本文描述的支付系统作为整个电商系统的一部分,也可以作为独立的支付系统对接多个前端业务系统。各公司应根据自身业务发展和规划进行取舍,不可照搬。

    综述

    支付是任何商业模式变现的最后一公里,是业务流程闭环的关键一环。

    本文涉及的支付系统沿袭《电商系统:对账设计》第一节的描述,支付系统和业务系统解耦处理。业务系统关注商品、库存、交易流程、运营服务等。而支付系统要关注支付流程的完整性、业务合规性以及技术可实现性

    因为支付行业有各种监管规定,尤其是涉及跨境电商更加复杂。支付系统要兼并合规性、易用性、安全性为一体,在前期设计时一定要综合考虑。

    \

    上图为通用支付系统的架构参考。不同的业务模式和需求可以按照不同的维度分层和功能划分。(关键在于根据实际需求取舍,不可照搬)下面将对各个层级做详细介绍。

    前台应用层

    这一层主要是面向客户,由业务系统的类型决定。通俗说法就是客户支付的场景是什么样的。不同的支付渠道会有各自的支付产品来满足各种场景。

    如:微信渠道提供的支付产品【JSAPI支付】就可以满足线下扫码、公众号、PC网站(web)三种场景。

    移动应用(安卓、IOS)场景下,微信和支付宝分别提供有APP支付产品。(详情点击图片)

    \

    \

    前台应用层的主要目的是帮助产品在设计支付系统时,理清业务所涉及的收款场景和系统类型。

    API接入层:

    这一层主要是面向各个业务系统。比如接口权限、数据权限、紧急止付、快速冻结等。

    当业务系统和支付系统非一个网段内,是不是要考虑白名单,以及控制不同应用只能操作应用范围内的商户。尤其是中国人民银行于今年(2019)下发《关于进一步加强支付结算管理防范电信网络新型违法犯罪有关事项的通知》(银发[2019]85号)后,这一块尤其关键。

    这一层可以参考银联、微信支付、支付、连连支付等公司开放平台的技术规范。

    接入服务层

    这一层的核心在于梳理清楚对外(业务系统)输出的能力范围。

    通俗理解为api功能,当然也可以通过微服务的服务注册来实现。

    \

    商户服务

    入网:

    商户签约流程(入网、建档、进件):线上还是线下,需要哪些资料,是否需要签合同盖章等;如果商户入网需要和支付渠道直接签约,那此处的入网能力就没有,直接提供页面给商户,录入支付参数信息即可。(目前服务商版微信APP支付需要商户自己去微信申请)

    结算、提现:

    担保交易场景下,就会涉及针对订单的指令清算(类似确认收货后订单才完成)。有些支付渠道给商户结算的资金并非直接到商户的银行卡,而是结算到商户在渠道开的钱包。很多时候大家所说的结算,本质上是提现流程中的结算,而非交易流程的结算。因为交易流程的结算在资金到钱包时已经完成。

    充值:

    当支付系统涉及B2B支付场景,比如租金缴纳、供应链金融等,会涉及付款方商户充值。有些企业2B业务比较多,通过企业钱包(一般通过银行托管账户实现)使付款充值到钱包,收款方主动(自动或者手动)划扣,达到线上核销。(B2B场景后续会专题讨论,此为业财一体化核心环节)

    还有一种场景就是商户入住平台需要交纳保证金。商户充值后,平台方冻结该笔资金。

    账单:

    此处账单泛指可以根据商户需要,同步商户的支付订单、订单流水、资金流水等信息。(请参考:《电商系统:记账设计之订单管理、流水管理》)

    分账:

    分账在此暂不介绍,后续文章专题讨论。

    应用服务

    应用服务比较简单,一般涉及如下几点:

    支付渠道管理:参考下文【网关服务】。

    支付产品选择:取决于业务系统类型和支付渠道,参考【前台应用层】。

    应用参数管理:支付渠道校验业务系统的有效性,确保通道不被滥用。

  • APP支付需要配置微信开放平台注册申请的appid或者支付宝开放平台的APPID;
  • 小程序、公众号需要配置微信公众平台的appid;
  • 公众号需要配置支付目录;
  • PC网站、手机H5 需要提交备案域名;
  • 等……
  • 商户层级管理:有些应用会涉及多商户,应用需要维护商户层级关系。

    个人服务

    如果支付系统不涉及钱包服务,就不会有充、提、转、支、收,借贷、白条这个服务也不好承载。常见钱包可以分为实体钱包和虚拟钱包(通俗叫法)。

    实体钱包(支付渠道管理钱包及其账务):

    通过接口提交资料在支付渠道侧开设钱包,前提是支付渠道必须有相关牌照。目前市场上钱包多种形式,一般有如下几种类型:

  • 实名制预付卡包装成线上钱包(也可以是内部两个账户打通)。需要有预付卡牌照和互联网支付牌照,很多商场、园区APP即是这种,和实体一卡通打通。
  • 虚拟账户(美团、支付宝余额、微信余额)
  • 银行托管账户开设子账户(摩拜、P2P产品)
  • 银行二类户、三类户包装(华为钱包、部分券商软件余额)
  • \

    余额宝、微信零钱通,不属于余额,属于购买的基金理财产品。其性质和券商软件的股票资产、P2P持有资产类似,属于最广义的货币供应量(M3)。

    实体钱包在开户时会根据实名验证的强度对钱包的额度、用途、范围、时效等有所限制。

    虚拟钱包(本地系统管理钱包及其账务):

    这种只适用于公司内部充值、消费使用。比如有些食堂、连锁餐厅、理发、健身房等,皆是如此,在用户充值时,钱已到了商家的结算卡。这种钱包一般是无法提现的。

    总结

    做支付系统一定不能脱离实际业务场景,更不能照搬其他公司方案。核心在于理清业务场景(决定支付产品的选择)、商户类型(决定入网流程、分账需求、结算类型),然后选择合适的支付渠道。可以选择微信、支付宝直连通道、可以选择其服务商、聚合支付供应商。

    对接银行或者银联商务的快捷支付、认证支付也是选择之一。如果没有精力做一整套的支付系统,市场上有可选择的“第四方支付”提供的SAAS服务。

    接下来将分享分账、业务服务、网关服务、清算&账务服务,以及支付中心运营管理平台(web后台)的设计。

    <
    上一篇: 电商系统:记账设计之订单管理、流水管理 下一篇: 支付系统架构设计(中):分账

    联系我们

    一个新的需求,从这里开始。欢迎填写表格或发送合作邮件至: 25909395@qq.com 25909395@qq.com 加微信: 13765801787

    13765801787
    在线留言