创意金融

标题: 付出系统计划白皮书：付出系统的概念与架构 [打印本页]

作者: 人人都是产品经理 时间: 2019-3-6 11:32
标题: 付出系统计划白皮书：付出系统的概念与架构

支付系统陪同着电子商务的出现而出现，为各类电子商务经营活动实现在线收付款生意业务，以及管理生意业务资金等功能，是具有一定独立性的内部系统模块。

一、什么是支付系统

自古以来，所有的商业活动都会产生钱币的收款与付款行为。在人类漫长的历史长河中，记载收付款行为的方式不断迭代：古代的账房先生通过手工记账，工业社会通过收银机机械记账……
今天，进入了互联网时代的我们，商业行为也一同举行了数字化与信息化的演变，成为今天的「电子商务」。
支付系统陪同着电子商务的出现而出现，为各类电子商务经营活动实现在线收付款生意业务以及管理生意业务资金等功能，是具有一定独立性的内部系统模块。

平台：开展电子商务经济活动的主体。
业务系统：实现平台用户注册、商品定价、营销活动等相关功能。

平台与业务系统的关系：业务系统将用户购买行为通过各种生意业务订单的形式举行记载，并交付支付系统举行处理，终极由支付系统完成收款与付款。
根据央行的现行规定，人民币生意业务处理仅限于银行及第三方持牌支付机构，因此支付系统在实现上述功能时，需要通过外部银行、第三方持牌支付机构完成生意业务资金处理。因此，支付系统需要具备：

统一封装处理的生意业务接口，以对接外部生意业务渠道，为业务系统实现生意业务订单处理的功能。
根据业务系统设置的资金分配规则，在一笔生意业务有多个收款方到场的环境下根据资金分配规则完成生意业务资金的主动化清分与结算，而后通过已对接的外部生意业务渠道完成划付。
账务数据记载功能，上述的生意业务、清分、结算形成的资金变动信息，需要支付系统通过账务数据记载功能加以记载，对生意业务资金举行统计并完成生意业务资金查对等财会工作。

二、支付系统架构

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

业务层负责为业务系统提供收付款的操纵界面以及处理业务系统提交的生意业务请求；
支付层负责通过支付渠道及时处理完成资金的收付款、记载到场生意业务的账户间资金流转环境并按照预定规则对账户所属资金举行拆分与合并。

1. 业务层

业务层包含收银台、生意业务系统以及会员系统三个功能模块：
（1）收银台
收银台即用户一样平常付款前选择渠道的页面，是支付平台提供的基本功能之一，重要职责是协助业务平台完成支付生意业务，向用户提供一致的生意业务体验。一般环境下，根据不同终端类型定制尺度化的收银台给到外部举行调用，包管各终端体验一致且针对各端特定需求、场景来展现不同的支付方式。
①收银台的业务场景（边界）一般分为付款与充值两部门：

付款即通过各类支付方式针对业务订单发起付款，例如：用户在天猫店购买一件衣服，确认订单后主动跳转至支付宝，引导用户选择对应的方式（余额、花呗、银行卡等）举行付款。
充值即用户对账户举行余额充值，例如：用户登录支付宝、微信或其他商户自有钱包系统对账户余额举行充值。

②支付渠道的服务模型，分为以下几个要点：
服务模型的概念：从支付公司角度来看，服务模型是决定商户可以使用的生意业务形式（担保收单、即时到账等）、支付产物（快捷、网银、代扣、POS 等）、签约方式、阶段周期（T+0、T+1、T+N 等）以及费率等核心题目的综合体；
从电商平台角度来看，电商公司内部使用的支付系统与支付机构相比复杂度较低，可通过参考支付公司服务模型，梳理不同业务、不同生意业务类型、不同结算周期以及不同支付渠道等复杂需求，搭建公道且满意业务需求的服务模型，例如充值类生意业务，具有商城属性的业务可配置担保收单或即时到账等生意业务类型。
服务模型的维度：

行业/服务维度：即从业务角度出发对支付产物举行划分。
例如：蚂蚁金融面向行业输出生意业务、结算、会员、安全等服务，且为不同的服务等级划定尺度，贯穿所有内部系统；普通非支付公司（以电商为例），提供即时到账、担保收单等，基本上能满意大多数的业务场景。

商品维度：针对不同行业的生意业务标的，由于生意业务代价、成本与利润差别大，因此在业务层面不同的支付渠道要有不同的可用性尺度。
一般环境下，商品本身与市场或行业挂钩，例如喜马拉雅在接入微信/支付宝时，业务所在行业为视频影音属于虚拟商品，因此接入费率为 1%，结算周期为 T+7。
由此可得，支付公司针对不同商品本身的特性（例如风险等因素）在费率和结算周期上会举行一定的控制；同时，针对高风险行业会在支付方式、渠道层举行限制。

市场维度：此处「市场」指的是指引客户使用支付产物服务的场合，它可能是支付产物本身，亦可能为相关公司或平台的网站。例如某团体子公司、某公司投资的公司以及与该公司无关的外部公司等等，可分为团体、内部以及外部等维度。

客户维度：此处「客户」指的是服务的详细使用者。可分为个人客户及企业客户，通过支付系统内的会员系统举行区分。

付款方维度：付款方在整个业务过程中未核心脚色，针对付款方用户的特征应建立以支付渠道收款方维度的模型，例如付款方的账户模型、安装是否正式、证书等级等要素都决定着付款方的付款流程。

支付渠道维度：在电商平台，跳转到支付系统是，收银台根据付款方的参数规则，进而对该笔支付在收银台内可使用的支付渠道举行选择。例如充值账户余额不允许使用信用卡时，收银台在付款方付款时仅可展现借记卡等支付方式，喜马拉雅在于支付宝等第三方支付公司交互式，下单接口里一般含有做借贷分离的参数，该参数起到的作用就是可以指定付款方即用户不可使用借记卡或信用卡。

业务渠道维度：业务端使用的入口，代表着客户或者业务方和支付系统的交互方式。例如通过 PC 端跳转到收银台、通过 App 跳转到收银台以及纯接口形式跳转等等。

支付渠道各类配置：

渠道配置：抽象收银台支付方式大类（第三方、网银储蓄卡、网银信用卡、信用类（花呗、白条）等），对应每个大类下配置对应的落地渠道，再分别对实用场景举行匹配（ App、H5、PC 端、公众号等等），不同的场景下应对应不同的支付方式。
渠道参数配置：在业务举行中根据公司的详细环境，部门业务可能独立运营，因此在独立运营过程中财务需要就独立业务传入各支付渠道对应的密钥及商户 ID 等关键参数信息，以满意业务方需要支付系统根据不同商户信息调用对应渠道收款主体的需求。

（2）生意业务系统
生意业务系统本身是作为支付系统外部处理业务逻辑的外围系统。由于支付核心系统本身并非面向业务端且业务逻辑的多变性与复杂性，支付系统为了兼顾稳固并可以或许为业务端提供灵活支持，因此需要在支付系统外层搭建面向业务端处理生意业务逻辑的生意业务系统。生意业务系统处理业务端的各种生意业务类型后，将业务信息转化为支付系统可识别的支付订单并导入。
以担保生意业务为例，C 端用户在天猫购买一件商品，成功支付后商家举行发货，用户确认收货后平台将货款结算给商家。此处设计到「担保生意业务支付」以及「确认收货」环节，与支付系统内部的支付与结算步骤一一对应：

用户付款成功后对应生意业务的付款成功状态；
用户确认收货后对应生意业务的成功状态。

从支付和收货缓解可以看出，担保收单生意业务就是讲支付系统的支付底子能力包装后对外支持业务的一款产物。
生意业务系统的职责：
生意业务系统作为支付系统的入口：

首先需要对接上层业务系统；
其次将支付系统的支付能力抽象出来，对外提供各类生意业务方式，例如下单、支付、修改金额、确认结算、退款、关闭生意业务以及查询等能力；
最后，生意业务系统需要对各种生意业务类型举行定义，例如担保生意业务、即时到账、充值、提现等类型。

生意业务系统的场景（边界）：

下单：生成生意业务订单，确定生意业务到场；
退款：针对已支付的订单举行退款，退款金额不得大于现实支付金额，积分的退款退回原积分账户，同时针对退款生意业务类型，会生成生意业务订单号，关联入款订单；
修改金额：修改生意业务金额，对应生成新的支付订单；
查询：查询生意业务结果、支付结果；
关照：关照上层业务系统生意业务状态；
算费：通过算费子系统盘算每笔订单的手续费。

生意业务系统的生意业务类型：

即时到账生意业务：买家在电商平台选择购买商品下单，付款成功后金额直接入卖家支付账户或者卖家银行账户；
担保收单生意业务：买家在电商平台选择购买商品下单，有部门金额为担保金额，买家付款成功后，担保部门进入平台方中心担保账户，未担保金额直接入卖家支付账户或者卖家银行账户；
收单退款生意业务：买卖两边在达成退款协议后，可针对及时到账生意业务，订金下定等已支付生意业务由商户平台发起退款请求；
普通转账生意业务：当平台方需要对会员举行转账时，通过此接口实现金额的转移；
合并支付生意业务：多笔生意业务订单合并（并笔）付款，实用于购物车针对不同商家生成订单的场景；
下订生意业务：卖家和买家达成购买协议，先行支付部门订金，该部门订金在终极付款的时候可以被使用；
提现：客户将支付账户的余额提到客户绑定的银行卡账户，基于支付账户单笔或者批量付款；
冻结解冻：在生意业务前通过冻结能力将用户的部门资金冻结，保障生意业务能正常举行，也可以由于某些原因（账户被盗、司法案件、反洗钱等），冻结用户资金操纵，包管用户的资金安全；
充值：基于支付账户做余额充值，将用户的银行卡账户资金充到用户的支付账户余额。

生意业务系统的生意业务特性归类：
①实效性：

全额及时到账：即时到账类生意业务，付款后及时到账；
部门确认支付、部门即时到账：担保收单类生意业务，这里分为部门担保的场景，只有指定金额部门需要确认结算；
全额确认支付：全额担保生意业务，电商生意业务场景下需用户确认收货后才会将全部货款结算给卖家。

②生意业务系统的支付形式：

单笔支付生意业务：单笔支付行为，用户基于一笔订单发起付款；
合并支付生意业务：多笔合并支付行为，用户基于多笔订单发起合并付款；

③业务类型：

收单生意业务：支付入款类型生意业务，付款人收款人分别是两个脚色；
充值生意业务：账户充值类生意业务，付款人和收款人都是同一个人，由外部账户到内部账户；
出款生意业务：基于账户做提现，付款人和收款人都是同一个人，由内部账户到外部账户；
退款生意业务：收单入款生意业务的反向流程。

（3）会员系统
会员系统是完备的支付平台内极其重要的底子模块之一，负责管理支付系统内部的生意业务主体。会员系统生存了客户在支付系统内部账号的实体信息，为客户建立了统一的、以会员 ID 为标识的会员基本信息、关系信息（会员和账户、会员和操纵人、会员与银行卡）视图。
一般环境，会员在支付系统内部门为个人会员和企业会员（默认企业会员有商户权限），以电商平台为例，C 端用户为个人会员，B 端商户为企业会员：

通常，企业会员会配置一定的业务参数，比如结算周期、接口权限、支付方式配置等（开通商户权限的环境下）；
在大多数互联网公司，支付系统仅需要对接支付渠道的模块，在没有独立平台化的环境下，不太会出现需要独立的账户体系。

2. 支付层

支付层包含支付核心、账务核心以及清算核心三个部门。
（1）支付核心
下方的内容介绍了支付核心的职责、边界以及系统架构三个部门。
支付核心的职责：
支付系统的职责为通过支付核心与后端清结算、会计、账务等系统的统一协作，让前端支付产物可以更关注产物本身的逻辑，而减少对清分、对账、储值等后端服务的考量及动作；同时通过尺度化的支付指令定义，统一前端支付产物的支付请求接口，提供适应各类产物使用的底子支付服务。
支付核心的边界：

支付服务：负责对后端支付系统的接口举行业务包装，同时实现使用多个支付方式举行组合支付的功能；
支付服务流程：对各支付类型的支付服务流程举行定义，详细定义为充值、提现、内转支付（转账）、退款等原子类型，并实现对底子服务的流程编排；
支付指令：发起订单后，通过协议和协议明细项加工得出支付指令，需具备举行后续操纵处理的全部要素信息；
支付协议：根据产物设立支付协议，因此支付协议的关键要素包含产物码及支付编码，定义着产物的处理流程、收付款信息、对应的支付渠道信息。

支付核心的系统架构：

如图，将生意业务和支付分开，重要是为了体现出支付系统的核心支付功能，可以或许为会员提供丰富的支付服务：支付核心定义原子支付类型；服务层提供支付业务能力，例如出款、转账、红包、代金券、余额、现金等；产物层可以或许更加关注产物本身的逻辑，将后端尺度化的逻辑交由支付层和清算层来处理，如许就能做到灵活和尺度兼顾。
（2）账务核心
账务核心的功能为，根据前端业务系统的要求设计相匹配的账户类型、管理各类账户、记载账户资金变动等，同时，按照公司内部的财会规范提供反映各账户间生意业务资金变化环境的会计数据；并且负责将自身记载账务流水与支付渠道结算资金和结算流水举行查对，对对账结果中出现的差错生意业务举行差错处理。
（3）清算核心
清算核心负责维护客户到场生意业务时的清分、结算规则，并按照已配置的规则完成生意业务资金的清分与结算操纵。
《支付系统设计白皮书》由 PingPlusPlus支付学院（ID：pingxxpi）出品。
本文由 @支付学院原创发布于人人都是产物司理，未经允许，禁止转载。
题图来自 Unsplash，基于CC0协议。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

欢迎光临创意金融 (https://www.vipjinron.com/)