支付系统是随着电子商务的出现而出现的。 实现各类电子商务经营活动的网上收付交易等功能，并对交易资金进行管理。 它是一个具有一定独立性的内部系统模块。

1.什么是支付系统？

自古以来，一切商业活动都产生货币收支。 纵观人类漫长的历史，记录支付和支付行为的方法不断迭代：古代簿记员手工记账，工业社会通过收银机机械记账……

今天，随着我们进入互联网时代，我们的商业行为也演变为数字化、信息化，成为今天的“电子商务”。

支付系统是随着电子商务的出现而出现的。 实现各类电子商务业务活动的网上收付交易、交易资金管理等功能。 它是一个具有一定独立性的内部系统模块。

平台与业务系统的关系：业务系统以各种交易订单的形式记录用户的购买行为，并交付给支付系统处理，最终由支付系统完成收款和支付。

根据央行现行规定，人民币交易处理仅限于银行和第三方持牌支付机构。 因此，支付系统在实现上述功能时，需要通过外部银行和第三方持牌支付机构完成交易资金处理。 因此，支付系统需要具备：

2、支付系统架构

支付系统主要职责是处理业务系统发起的所有交易请求，包括收银、交易系统、支付核心等模块。 根据各模块功能职责的不同，支付系统可以分为业务层和支付层两部分。

1、业务层

业务层包括收银、交易系统、会员系统三大功能模块：

(1) 收银柜台

收银台是用户进行日常支付前选择渠道的页面。 它是支付平台提供的基本功能之一。 其主要职责是协助业务平台完成支付交易，为用户提供一致的交易体验。 一般情况下，标准化收银台是根据不同的终端类型定制的，并对外调用，以保证各个终端的体验一致，并根据各个终端的具体需求和场景展示不同的支付方式。

①收银员的业务场景（边界）一般分为支付和充值两部分：

②支付渠道的服务模式分为以下几个要点：

服务模式的概念：从支付企业的角度来看，服务模式决定了商户可以使用的交易形式（保收、即时到账等）、支付产品（快递、网银、代扣代缴、POS等）。 ）、合同签订方式、阶段周期（T+0、T+1、T+N等）、费率等核心问题的复杂化；

从电商平台的角度来看，电商企业内部使用的支付系统没有支付机构那么复杂。 通过参考支付公司服务模型，我们可以梳理不同业务、不同交易类型、不同结算周期、不同支付渠道等，针对复杂需求，构建满足业务需求的合理服务模型，例如充值交易、具有商城属性的商户可配置保收、即时支付等交易类型。

服务模式维度：

行业/服务维度：即从业务角度划分支付产品。

例如：蚂蚁金服向行业提供交易、结算、会员、安全等服务，并制定不同服务级别的标准，贯穿于所有内部系统； 普通非支付企业（以电商为例）提供即时支付、担保收单等，基本可以满足大部分业务场景。

产品维度：针对不同行业的交易标的，由于交易价格、成本和利润差异较大，业务层面不同的支付渠道必然有不同的可用标准。

一般情况下，产品本身是与市场或行业挂钩的。 比如喜马拉雅接入微信/支付宝时，业务行业是视频、音频，属于虚拟产品，所以接入费率为1%，结算周期为T+7。

由此可见，支付公司会根据不同商品的特点（如风险等因素）对费率和结算周期进行一定的控制； 同时，对高风险行业的支付方式和渠道进行限制。

市场维度：这里的“市场”是指引导客户使用支付产品和服务的场所。 可能是支付产品本身，也可能是相关公司或平台的网站。 例如，某个集团的子公司、某个公司投资的公司、与该公司无关的外部公司等，可以分为集团、内部、外部维度。

客户维度：这里的“客户”是指服务的具体使用者。 可分为个人客户和企业客户，通过支付系统内的会员制来区分。

付款人维度：付款人在整个业务流程中不具有核心作用。 应根据支付方用户的特点，建立基于支付渠道收款方维度的模型。 例如，付款人的账户模型、安装是否正规、证书级别等因素都遵循付款人的付款流程。

支付渠道维度：在电商平台上，跳转到支付系统时，收银员根据付款人的参数规则，选择可以用于支付的支付渠道。 例如，当不允许使用信用卡充值账户余额时，收银员在付款人付款时只能显示借记卡等付款方式。 喜马拉雅与支付宝等第三方支付公司进行交互。 订单接口通常包含借方和贷方分离的参数。 该参数的作用是指定付款人，即用户不能使用借记卡或信用卡。

业务渠道维度：业务端使用的入口代表客户或业务方与支付系统的交互方式。 比如通过PC跳转到收银台、通过App跳转到收银台、跳转到纯界面形式等。

多种支付渠道配置：

渠道配置：抽象出收银支付方式的大类（第三方、网银储蓄卡、网银信用卡、信用类（花呗、白条）等），在每个类下配置对应的落地渠道，然后进行分别适用的场景。 匹配（App、H5、PC、公众号等），不同场景应使用不同的支付方式。 渠道参数配置：业务过程中，根据公司具体情况，部分业务可能会独立运作。 因此，财务在独立运营过程中，需要传入独立业务各个支付通道对应的密钥、商户ID等关键参数信息才能满足要求。 商户侧需要支付系统根据不同的商户信息调用相应渠道支付实体的需求。

（二）交易系统

交易系统本身是一个外围系统，处理支付系统外部的业务逻辑。 由于支付核心系统本身不面向业务端且业务逻辑多变且复杂，为了稳定并为业务端提供灵活的支持，支付系统需要构建面向业务端的交易系统处理支付系统外层的交易逻辑。 。 交易系统在业务端处理完各种交易类型后，将业务信息转换为支付系统可以识别的支付指令并导入。

以担保交易为例，C端用户在天猫购买商品。 支付成功后，商家将发货。 用户确认收到商品后，平台将向商家结算货款。 这里设计了“保证交易支付”和“收款确认”链接，对应支付系统内的支付结算步骤：

交易支付成功状态对应用户支付成功； 交易成功状态对应用户确认收到商品后的交易成功状态。

从支付收单救济可以看出，保本收单交易是封装支付系统基础支付能力以支持对外服务的产品。

交易系统职责：

交易系统作为支付系统的入口：

交易系统的场景（边界）：

交易系统的交易类型：

交易系统交易特点分类：

①有效性：

②交易系统支付方式：

③业务类型：

（三）会员制度

会员系统是一个完整的支付平台中最重要的基础模块之一，负责管理支付系统内的交易主体。 会员系统在支付系统中保存客户内部账户的实体信息，为客户建立会员基本信息和以会员ID标识的关系信息（会员与账户、会员与运营商、会员与银行卡）的统一视图。

一般来说，支付系统内会员分为个人会员和企业会员（企业会员默认拥有商户权限）。 以电商平台为例，C端用户为个人会员，B端商家为企业会员：

2、支付层

支付层由支付核心、记账核心和清算核心三部分组成。

(1)支付核心

下面的内容介绍支付核心的职责、边界、系统架构三部分。

支付核心职责：

支付系统的职责是通过支付核心与后端结算、记账、记账系统的统一协作，让前端支付产品更加关注产品本身的逻辑，减少需要后端结算、对账和储值。 服务考虑因素和行动； 同时，通过标准化的支付指令定义，统一前端支付产品的支付请求接口，提供适应各类产品使用的基础支付服务。

支付核心边界：

支付核心系统架构：

如图所示，交易与支付分离的目的主要是为了体现支付系统的核心支付功能，为会员提供丰富的支付服务：支付核心定义了原子支付类型； 服务层提供支付业务能力，如提现、转账、红包、代金券、余额、现金等； 产品层可以更加关注产品本身的逻辑，将后端标准化逻辑交给支付层和清算层，这样就可以做到灵活性和标准化。

（二）会计核心

会计的核心功能是根据前端业务系统的要求，设计匹配的账户类型，管理各类账户，记录账户资金变动等，同时提供反映交易资金变动的核算各账户之间的往来按照公司内部会计规定执行。 数据; 负责将自身记录的记账流水与支付渠道的结算资金、结算流水进行核对，并对对账结果中出现的交易错误进行处理。

(3) 清算核心

清算核心负责维护客户参与交易时的清算结算规则，并按照配置的规则完成交易资金的清算结算操作。

《支付系统设计白皮书》由支付学院（ID：）制作。