支付系统架构如何设计?描述支付系统作为整个电商系统的一部分

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

综述

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

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

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

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

前台应用层

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

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

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

API接入层：

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

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

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

接入服务层

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

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

商户服务

入网：

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

结算、提现：

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

接入服务层

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

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

商户服务

入网：

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

结算、提现：

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