业财一体化之支付系统

本文主要是介绍业财一体化之支付系统，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

在当今时代，大家对于支付系统都不算陌生，但对于企业而言，支付诉求是由所属行业、商业模式和服务客户确定，不同企业支付述求各不相同。下面这篇文章是笔者整理分享的关于企业如何拥有支付能力，企业支付系统应该如何建设的相关知识，大家一起来看看吧！

企业是以盈利为目的，为客户提供商品或服务，通过商品或服务这个过程就是交易，常言道一手交钱一手交货，可见交易是支付基础，支付使交易行程闭环，对于企业来说支付诉求是由所属行业、商业模式和服务客户确定，不同企业支付述求各不相同。

小微企业通过主流支付平台标准化支付产品实现交易支付支持；中型企业对支付需求非常朴素，拥有支付能力满足业务发展述求，在业务初期对支付牌照并没有特别强述求；大型平台企业对支付要求极高，丰富支付渠道满足不同场景支付述求，对支付渠道交易费率，稳定性，风险控制和支付合规都极高要求。

另外，大型企业强烈的金融情结，构建金融帝国，通过拥有支付牌照，尤其是互联网支付牌照，拥有互联网金融的入场券，从业务到金融，全方位服务客户，获取更高价值。

本文笔者将从自己过往经历和业务理解角度去阐述企业如何拥有支付能力，企业支付系统应该如何建设。

一、企业支付系统建设目标

将企业各个业务线的交易、财务对支付能力述求沉淀到中台行成支付中心，主要实现以下三个目标：

为交易订单、支付、财务建立统一体系，支付能力进行抽象和封装公共处理逻辑，同时业务感知渠道差异，形成统一的基础服务，降低业务的接入难度和成本，节省重复研发成本；
建立安全、可靠、易于可扩展的支付系统，能够开始支持业务拓展与创新。灵活可配支持业务追求快和支付要求稳定和安全之间的矛盾；
沉淀交易链路支付核心数据，为交易分析、支付营销、风控、财务分析、金融服务等提供数据支撑。

二、企业支付核心诉求

确认企业支付需求需要了解商业模式、梳理业务流程、分析支付特点，根据企业实际情况确认支付需求，分析需求价值和优先级。

三、如何满足企业支付述求

1. 竞品分析

分析行业主要竞品主要选择业务模式和规模比较接近企业，作为竞品，了解其为客户提供哪些支付方式和支付规则。

主要全业务流程涉及支付行为分析：

面向客户：开户、销户、冻结、解冻、充值、支付、提现、签约、解约、绑卡、解绑。

面向商家：开户、销户、冻结、解冻、充值、支付、收款、退款、提现、付款、对账。

2. 标杆对照

如果企业在快速发展阶段友商的竞品也不是特别成熟，不妨对标类似行业龙头企业支付产品设计。

举例：

电商对标淘宝或京东

PASS对标阿里云或华为云

3. 支付渠道产品接入

国内能够提供支付产品渠道主要有两类：银行和第三方支付。

1）银行

招行和平安银行在企业支付服务方面做的不错，招行一网通支付，CBS跨行资金管理系统，平安见证宝等都是不错产品，应用最为普通的是银企直连系统。

下面重点介绍一下银企直连：

银企直连：实现企业ERP或财务管理系统与银行系统集成，企业可以通过网络（公网或专线）直接快速的处理银行相关业务（不限于支付业务，换包含存贷款、投资理财等）。

2）第三方支付

①支付宝：

②微信：

③银联：

四、支付系统建设和优化

笔者曾经就职A企业业务模式为O2O，主要实现交易撮合，赚取交易佣金，业务发展初期市场竞争激烈，快速接入移动支付（支付宝），让交易行程闭环，满足最基本的业务收款需求，入账商家提现需求接入银企直连批量付款能力。

随后为了满足用户支付多样化需求又接入了微信支付，后续接入了招行一网通，随着业务发展，从一条业务线向多个业务线扩展，支付能力下沉行成中台能力，满足多业务线支付述求，对多个外部渠道支付能力进行封装行程，统一管理业务接入。

一次性接入多个渠道，大大提升接入效率，方便后续拓展，随着业务发展和成熟已经在行业站稳脚跟，逐步发展到行业龙头，交易量暴增支付交易成本对企业来说不菲开支，通过接入多个渠道（免密支付，预付卡，资金授权），提升支付体验，支付路由降低支付成本。

另外，把支付安全一直非常关注，支付风控系统随之建立起来，随着监管趋严，平台合规运营摆在面前急需解决问题，通过收购支付公司，规避二清，发展供应链金融，增加平台收入。

1. 支付系统架构

2. 支付系统功能介绍

上图是比较完整支付系统架构，限于篇幅，本文对主要主要模块功能进行概述，不详细展开探讨，后续内容分模块进行详细说明。

1）会员平台

会员平台主要实现用户准入到注销，支付交易服务支撑。主要分为三部分用户、商户、账户通常讲的三户模型。是支付系统直接面向会员服务的平台，主要功能包括C端或B端会员注册，实名认证，账户开通、冻结、解冻、余额管理、交易明细查询与下载，账户充值、提现、转账、付款和对账。

2）业务层

业务层不属于支付系统，它是支付系统上游，支付系统主要面向各类业务场景提供支付支持，支持服务业务全交易流程支付需求，不限于：

买家：预付、下单支付（担保交易或即时到账）、货到付款、消费分期等。
卖家：交易取消退款、退货退款（部分退款/全额退款）、补偿付款等。
平台：交易分账、交易抽佣、货款结算、营销收费、保证金扣款等。

3）基础信息

集中管理支付系统主数据，为支付系统其他子系统或模块提供处理过程中所需的基础数据，保障数据来源唯一性、准确性、记录数据变更日志，所有数据创建、修改、删除可追溯。

常用主数据包括：支付渠道信息、银行信息、支付产品参数信息、会员基本信息、产品签约信息、产品解约信息、账户信息（银行、第三方支付、内部户）、银行信息、电子联行信息、卡BIN信息、币种、汇率等。

4）支付核心

支付网关：

为业务系统接入支付服务提供统一入口，屏蔽不同渠道支付产品的差异、统一支付请求处理、交易通知、查询等服务机制，业务系统只需关注业务本身逻辑处理无需关注支付系统底层处理逻辑、系统解耦各自专注擅长领域。

3. 主要功能

交易信息加解密、数字签名、签名验证防止交易数据过程数据按照，防篡改、防抵扣；熔断限流：当交易请求流程多大时，保障服务可用性对交易请求进行限流，支付系统对交易系统支付请求参数进行校验，组装转化成各个具体渠道参数，根据支付请求所涉及支付方式进行支付编排安排具体路由，当某个外部渠道不可用是会进行降低处理。

渠道支付产品封装，企业会接入多个支付产品或渠道不同渠道支付产品，请求参数处理机制不尽相同，按照实现功能统一封装产品，方便业务接入，覆盖交易全生命周期支付所需主要包括签约、解约、认证、鉴权、代扣、快捷支付、网银支付、扫码支付、余额支付、虚拟币支付、话费支付、分账、退款等。

统一交易请求和通知机制，一般支付过程会涉及支付请求创建、请求结果查询、请求撤销或关闭、请求成功通知（回调），支付重试（需遵守幂等性）防止重复支付，支付状态补偿（有时由于网络原因发生掉单需要查询支付结果根据结果更新支付请求状态）。

1）收银台

是支付系统与付款用户交互业务，用户交易终端和业务属性，确定不同支付方式，支持用户完成支付。