【云闪付商家收款码 开通全过程视频！】     

               

上面就是云闪付商家收款码的申请全过程 ！您学会了吗？     

          

云闪付服务商官网是：ysffws.com，进入云闪付服务商官网可以直接联系上服务商，服务商可以帮助您完成二 次认证，解决申请过程出现的任何问题，是您申请收款码的好帮手哦！~     

   

---

                  

前言：什么是中泰？

在进入正题之前，我们首先要讨论一下什么是中台。 根据网上搜集的资料，有人说中间平台是技术中间平台，比如微服务开发框架、平台、PaaS平台、容器云等； 有人说中台是微服务业务平台，比如最常见的各种微服务的用户中心、订单中心、配送中心，被称为“业务中台”； 有人说，中台是组织的业务。 如果组织架构调整，也可称为“组织中台”； 有人说，中台是一个想法、一个系统，可以快速聚合后端数据和能力。 因此，不同的人对中国和台湾有不同的理解。

去年三湘银行做中台项目的时候，我们在网上找到了一个定义：中台是企业级的能力复用平台。 这是我们去年同意的一个概念，原因如下：

去年我们主要用这个定义来描述我们对中国的认识。

但以上概念真的能解释中泰吗？ 中泰项目完成后，我又重新思考了这个问题。 如果我们按照上面的定义，还不太清楚什么是中间平台。 因为传统SOA架构、微服务架构、标准化、平台化的一些改造都可以称为“中台”，所以中台的概念还不是很明确。

我们看一个中台演进的例子，这里指的是阿里巴巴架构的演进。 假设有一家电商公司，最初创建了中蓝食品电商平台，实现一些订单、产品、用户、支付等功能。 食品电商平台对应的业务部门为食品事业部。

后来，随着公司业务的发展，成立了医药事业部，并复制食品电商平台的模式创建了相应的医药电商平台。 事实上，这个新平台所使用的功能与食品电商平台的功能类似。 但由于两个平台销售的商品存在差异，因此两个平台并未合并。 不管公司有多大，它都是一个汽车电商平台。 最后，三个平台各自独立开发自己的服务架构和内部业务管理。

在支付功能方面，公司不同的电商平台可能会与不同的支付机构合作实现交易功能。 三个电商平台都有相应的用户管理和支付功能。 由于三者处于竞争关系，支付渠道无法统一。

基于这些问题，公司不得不开始搭建中间平台。 三大电商平台集中负责用户管理的人力，成立用户开发部，创建用户中台，实现用户管理和营销功能。 同样，公司还成立了支付结算部门，打造支付中台。 当企业建立用户中间平台和支付中间平台时，可以统一其用户管理和支付管理能力，整合资源。 这是中间平台演变的一个粗略例子。

基于这个例子，我提出了一个新的中间平台概念。 中台是基于企业资源整合的需求，通过运营模式变革、组织架构调整、IT架构重构等形成的企业级服务复用能力。

1、为什么要建中泰？

说完中间平台的概念，我们来思考一下银行为什么需要建设中间平台。

大多数银行的组织结构与该图类似。 银行的组织架构本身就区分了前、中、后台系统：营业部、分行、金融市场部等做具体客户业务开发的部门属于银行前台部门； 对于一些业务部门来说，风险管理部、授信审批部等管理和产品设计部门属于银行的中台部门； 而银行的内部管理机构，如办公室、人力资源部以及其他为银行业务服务的部门，则属于银行的后台部门。

我们看一下传统银行的IT架构设计。 最上面是银行的渠道端，是面向客户的系统和一些综合服务平台； 中间部分属于银行的金融产品运营系统。 由于银行的金融产品种类很多，相应的系统也很多； 后台有银行核心系统，包括互联网核心系统、银行核心系统和账户系统； 最底层是BI系统。 从架构图可以看出，银行的系统数量非常多。 对于三湘银行这样的小银行来说，系统数量实际上超过了140个。

由于银行IT系统较多，银行通常存在以下问题：

从推出新产品的实施周期来看，银行与新兴互联网企业之间会有很多差距。 金融科技公司一般需要一个月以内，传统商业银行通常需要三个月以上，大型银行可能需要半年到一年。

至此我们就明白为什么银行要建设业务中台了。 事实上，银行建设业务中台的动力并非来自于营业部。 对于商业银行来说，其业务运营和组织架构是前端、中台、后端的模式，符合中台的设计理念。 业务部门对中台建设的需求不迫切，缺乏动力。 即使没有搭建中间平台，其业务流程依然顺畅。 事实上，银行的中台项目主要是由技术驱动的。 随着互联网金融竞争的加剧，业务对需求的响应时间要求逐渐与互联网公司接轨。 传统的银行应用架构无法支持如此快速的响应和快速的上线变更。 因此，技术部门迫切希望通过中台项目来改变IT的交付效率。 这是银行建设中端项目的最大动力。

2.银行业务中台架构设计

中央平台的建设有多种不同的设计。 主要以三湘银行中台设计为例，供大家参考。

首先我们来说说建设商务中心需要解决的问题。 银行建设中心平台最大的问题主要是解决新产品推出成本高、周期长两个问题。

这张图是一个简单产品在银行的流通示意图。 左侧是通道系统。 中间的两个是产品系统A和产品系统B，负责提供产品服务。 右侧是银行账户系统，如传统核心和互联网核心。 还涉及第三方支付系统。 可以看到，如果我们想要购买一个产品，渠道系统必须连接到各个产品系统来展示产品并发起产品购买交易。 通常银行会把一些产品扣款和一些支付功能放在产品系统上，产品系统会连接到银行的核心，银行相应的支付系统会实现资金扣款。

每次创建产品时，每个渠道系统都必须实现同一组接口。 看图中右侧列出的五个主要接口。 事实上，实际情况下的接口数量会比图中的数量更多。

对于产品系统来说，除了提供渠道系统接入的接口外，还需要实现一些与行业核心系统、支付系统对接的功能。 可以看到，产品系统越多，渠道系统需要连接的接口就越多。

另外，产品系统还需要与银行内部的一些系统进行对接。 以接入核心系统为例，假设我们有两个核心系统，一个是银行核心，另一个是互联网核心，那么产品系统必须实现两个核心系统之间的连接。 。 如果是支付系统，每个支付渠道必须接受一次。 例如，中国人民银行拥有大额支付、小额支付、超级网银三种支付渠道，再加上微信、支付宝等其他第三方支付渠道。 同时，产品系统还必须实现记账、支付的异常处理功能。 如果这些规则处理不当，很容易造成银行的短付款和会计问题。 这就是银行在现有传统架构中创建新产品成本高昂且耗时的原因。 建立中泰的目的就是为了解决这样的问题。

针对以上问题，对应的业务中台设计目标有四个：

基于以上四个目标，三湘银行去年建设业务中台时，选择了银行最基础的六大业务能力来建设相应的中台，这也是第一阶段业务中台的六大核心功能。企业中台建设项目。 ：用户中心、账户中心、支付中心、记账中心、交易中心、产品中心。

我们认为业务中台的定位是：作为产品系统与渠道系统、账户系统、支付系统、会计系统之间的桥梁，利用传统银行应用架构中的现有系统，通过标准的业务模型实现系统之间的解决方案。 耦合。 这个业务中台的概念其实和平台标准化或者SOA的概念很相似，但是也涉及到业务模式的调整。 因此，三湘银行的业务中心还是不同于纯粹的IT项目。

1. 用户中心

我们先来说说用户中心。 用户中心实际上需要解决五个问题：客户管理、生命周期管理、电子渠道互通、客户信息集成、合同管理。

设计用户中心就是为了解决以上五个问题。

对于用户中心来说，首先要解决的就是用户生命周期问题。 您可能还有疑问，为什么叫用户中心而不是客户中心？

我们在做以用户为中心的设计时就思考过这个问题。 事实上，用户和客户的定义是不同的。 在传统银行，他们通常只给已经开户的客户打电话，银行基本不关心其他用户。 和游客一样，银行基本上不会登记游客的信息。 但互联网公司则不同。 互联网公司会收集和管理游客、注册用户、实名用户、实体用户的信息，包括登录信息和浏览信息，以便更好地营销客户，改善客户体验。 我们把互联网公司的设计模式放到了用户中心。

我们要求对从游客到实体用户的四类用户进行管理。

对于这四类用户，需要在用户中心进行统一管理，包括用户信息管理、用户行​​为登记等。

在用户中心，还将设计统一的登录功能。 例如，用户可以在三湘银行所有电子渠道上通过用户名、手机号码、账户邮箱登录，即可以通过所有电子渠道登录。 是一致的。 同时还可以使用一些设备验证方式，如人脸登录、指纹登录、手势、扫码登录方式。 还可以支持一些第三方登录方式，比如微信、支付宝授权登录。 这些登录方式在我们的用户中心是支持的。

第二块是统一签约。 为了统一签约，我们将在用户中心管理所有用户的合约数据。 同时，所有的签约和取消操作都将在用户中心得到支持，从而保证用户的所有合同内容都可以在用户中心找到。 ，并为所有用户实现签约和解约的动作。

第三部分是统一视图，在用户中心展示所有与客户相关的信息，包括客户的基本信息、客户的私人资产和负债信息、客户的交易流程和一些行为。 这就是统一视图的概念。

事实上，用户中心的整体功能包括六个部分：

下图是用户中心的总体功能示意图。 除了刚才介绍的客户管理、统一视图等功能外，它还具有关联的能力。 无非就是将客户的收藏夹、收款人名单、收款人地址等信息放在全渠道共享，让用户在银行的各个终端都能获取到他的信息，提升客户体验。

因此，整个用户中心相当于传统银行的几个系统的集合。 一是ECIF，二是实时CRM，可以实时获得用户360°的视图，加上对用户全渠道运营和体验的渠道支持。 这就是传统银行用户管理能力的整合。

2、产品中心

产品中心需要解决产品目录、产品管理、产品查询、产品上下架四个问题。

对于产品中心，我还想解释几个概念：

我们打造的产品中心是狭义上的产品管理体系。

上图是我们产品中心的整体功能架构。

左侧是被管理产品的基本属性，包括产品的基本信息和销售属性，例如在哪个渠道销售、销量等； 促销信息，某种产品可以在一定期限内打折，或者可以通过优惠券等方式减免手续费； 收费信息，购买产品需要对应的手续费，与上面类似的是基本产品信息的管理。

但实际上，还是会有一些信息需要从各个产品系统同步。 相当于产品中心一方面会从传统核心系统同步回产品，并在产品中心维护一定的产品信息。 还可以将这些信息反向同步到产品系统，实现相应产品的创建。 这是产品中心的产品属性管理功能。

产品中心属于产品渠道和门店的管理。 事实上，我们在设计产品中心的时候，就考虑过将产品中心作为统一的销售管理功能。 在产品渠道上，我们设计了门店和机构的概念，并在门店（机构）下设置了品类。 然后所有品类的产品都会上架和下架。

例如，类目中有推荐或热销的产品类目，您可以在产品中心配置，将产品放在对应的产品类目中上架。 对于渠道系统，您可以直接看到这些类别中的产品列表和产品信息。 同时，产品中心会缓存所有的产品信息，因此可以支持高并发的产品查询。 因此，所有渠道系统不再需要接入特定的产品运营系统，相当于手机银行不需要接入核心系统来获取相应的产品信息。 所有您要销售的产品都可以直接从产品中心获取。

同时，产品中心还将具有过滤产品的功能。 渠道系统可以将查询到的产品对应的渠道和客户标签发送至产品中心。 产品中心可以通过产品设置的销售渠道和可销售的客户群体来确定哪些产品可以在渠道上看到。

例如，客户登录手机银行查看可以购买的产品，产品中心会根据客户可以看到的产品返回相应的产品信息。 渠道系统无需过滤相应的产品信息。 这样就可以实现针对数千人的产品销售展示功能。

3、会计中心

三湘银行今年才开始建设会计中心。 去年建设商务中心时，还没有建设会计中心。

这是建设会计中心需要解决的四个问题。 要了解这四个会计中心的问题，我们先来说说银行的会计处理流程。 事实上，银行的会计处理通常是这样的：客户可能在银行的交易系统上发生了一笔交易。 这笔交易可能是购买产品，交易实际上会实时传输到核心系统进行产品购买。 客户产品帐户的借方和贷方。

例如，客户在购买金融产品时，需要实时扣除购买该金融产品所花费的资金。 同时为客户生成一个金融产品账户，并将其持有的金融产品份额发送至其账户。 这部分交易需要实时实现。 在我行称为“客户账户”，即与客户相关的账户。

其实银行里的账户还有一部分，叫总账，就是银行账户。 银行账户一般是银行内部使用的，用于执行银行会计报表、资产负债表等信息。 这些账户不要求实时，所以通常是晚上在银行批量处理。

因此，会计中心的建立就是为了解决刚才提到的四个问题。 分为核算规则配置、批量过账、实时过账三个功能：

这是我们设计核算中心的大流程图：

如左图所示，当您实时处理一笔交易时，交易系统不需要生成这部分账户用于银行记账。 它不需要关心银行会计规则，只需要实现银行客户账户的扣除和产品的录入。 就这样做吧。 然后交易系统可以将这些交易数据及其交易流程直接发送到会计引擎。 记账引擎会将交易流接口映射为银行内部标准交易格式，然后与配置的记账集关联起来。 。 例如，一笔交易会包含多少笔贷款条目，贷款金额如何计算？ 这些都是通过相应的配置来实现的。 最后，记账引擎会生成银行账户的具体贷款分录，然后将分录转换成实时发送到总账进行记账。 这形成了我们的实时会计功能。

同时，对于批量来说，其实和实时记账非常相似。 批量的情况下，系统可以准实时地采集一批账户，也可以每天晚上采集所有账户并发送给计费引擎。 记账引擎也利用刚刚处理过的方法快速生成相应的交易数据。 登录并发送至总账进行批量计算。 这是一个大规模的流程设计。

4. 账户中心

账户中心需要解决四个问题：账户能力重复、跨系统核算复杂、账户能力参差不齐、缺乏统一的账户视图。

在账户中心的设计中，我们提出了三个理念：产品与账户分离、媒体与账户分离、账户与账户分离。

刚才讲产品中心的时候，其实讲的是产品的概念。 产品属于操作规则的集合。 将产品与其帐户分离有什么好处？ 例如，在传统的核心系统上，有一个产品实现了一套规则。 该规则假设它可以用于 I 类家庭，但不能用于 II 类家庭。 如果我们要实现同样的产品规则，就必须花时间重新开发。 例如，如果我们以后遇到积分系统要实现类似的功能，我们就必须在积分系统上实现相应的规则。

如果账户和产品可以分离，那么一套产品规则自然可以应用于不同的账户。 就像刚才提到的存款利息收取功能可以放在I类账户，II类账户，甚至一些积分账户也可以按照相应的规则进行处理。

第二个理念是媒体与账户的分离。 这里主要是要区分媒介的概念。 媒介是银行向客户提供的证明客户身份的凭证。 媒介本身不具备金融属性。 真正具有金融属性的是与媒介绑定的账户。 将媒体与帐户区分开来有很多好处。 例如，如果客户丢失卡并换卡，则只需更换介质即可。 他只需重新绑定原来的账号即可。 另外，账号与媒体分离后，一个账号可以绑定多个媒体。 。

最后一个概念是账户分离。 这实际上相当于在设计上把所有账户放在同一层级，账户之间的关系是通过账户中心的合约管理来实现的。 关系。 账户之间可以通过合约来实现各种账户级别的关系支持，扩展性会比较高。 这也是账户中心的设计理念。

我们在设计账户中心的时候，也设计了账户的基本模型：

该基本账户模型包括账户基本信息、计费信息、冻结/止付信息、余额信息、扩展信息、合约关系、媒体绑定等。 我们将所有的账户抽象成这样一个模型，所有的账户都会按照这个模型进行管理和访问。 对于账户，我们也会提供一些标准的基础功能，比如账户限额管理、合约管理、智能路由、睡眠账户管理等。

其次，我们也将账户的基本功能标准化为几个最基本的原子服务：所有账户操作无非就是开户、注销和记账（存款/取款/冲销）、冻结与解冻/止付与注销，损失报告、查询和信息变更。 这些功能对于所有帐户都是相同的。 账户服务标准化后，可以采用这种统一的模式在银行进行账户处理，包括记账、冻结等操作。

您可能对账户中心刚才提到的合约概念不太清楚。 事实上，我们把合约定义为账户之间的关系，通过合约，我们可以管理账户之间的资金流向。 该图提出了 5 个账户流的管理：

各种账户关系实际上都是通过合约类型来支持的，并且合约类型未来还可以不断扩展。

在账户中心的建设中，我们也考虑了成本的问题。 不可能说在建设账户中心的时候，原有的账户系统全部被淘汰，账户全部迁移。 因此，在建设账户中心时，必须考虑到账户中心本身具有账户功能，但也可以实现原有账户的整合。 系统直接连接。 例如，如果我们要连接传统核心I类账户，我们可以通过适配接口将传统核心连接到账户中心。

至于外围产品体系，未来将不再直接接入传统核心。 而是所有账户中心操作的处理都会通过账户中心的标准服务接入，实现所有账户的处理。 通过这种模式，所有渠道、产品系统都可以使用同一个模式来操作账户，并且全部通过账户中心来实现。 未来如果我们要重构某些系统，自然可以将相应的账户迁移到账户中心来实施。 这种模式可以大大降低数据迁移的成本，避免比较大的实施风险。

5.支付中心

所有银行都有统一的支付理念。 支付中心需要解决的问题其实和统一支付的概念类似：

我们对支付中心的设计提出了一些理念：

我们也把银行一级账户的借方放在支付中心，涉及到的资产的动向账户我们都放在支付中心。

下图就是刚才提到的支付中心的总体功能图。

事实上，我们把支付、核算、产品渠道三件套交给了统一支付。 这个支付模型和我们后面要讲的支付订单模型有关。 支付理念的改变是我们这次中台工作的一个比较大的特点。

6. 交易中心

此前银行很少提及交易中心。 交易中心解决的主要问题是：

根据刚才的问题，我们提到了中间平台订单的概念，相当于我们用电商订单模型来创建银行的交易流程。 现在如图所示，就是我们交易中心的订单模型。

对于渠道系统来说，它每次发起一次产品购买行为，实际上都是创建了一个订单，然后订单中的信息就和电商的非常相似。 首先会有订单最基本的信息——订单日期、货币类型、总金额、执行参数等信息； 第二个是产品发货清单信息——产品信息、购买数量、支付金额、扩展信息。 这个发货清单可以放多个产品； 第三个是费用调整清单，涉及到我处理这个订单需要的费用或者促销或者折扣的调整，以及需要支付的总体金额的调整。 这可以通过费用调整来实现； 最后就是这个订单应该使用什么样的支付工具。 进行付款，例如通过 I 类账户或 II 类账户，或通过第三方账户付款。 订单中可以支持多种支付工具，相当于一个订单同时使用多种支付方式进行支付。

这是一个订单模型，和电商模型非常相似。

下图是一个订单的处理流程：

一开始，在渠道系统中，我们会为客户创建一个订单，其中会包含刚才提到的付款和发货信息，然后走一个付款流程。 支付流程也通过统一支付来执行相应的支付动作。 支付的内容其实可以支持很多类型。 例如，客户可以通过基金或股权来支付。 比如积分是一种权益，代金券也是一种权益。 甚至据说顾客可以通过持有的产品来支付订单。 例如，如果客户有金融产品，他可以通过该金融产品的分成来支付订单。 当支付成功后，就是银行将资产交付给客户的过程。

说到发货，其实和刚才也差不多。 例如，对于贷款交易，银行会将钱交付给客户； 对于某些产生权益的交易，银行会将权益交付给客户； 例如，对于产品购买，银行会将钱交付给客户。 金钱被交易给客户。 其实大家可以看到，支付、发货都是通过统一支付来实现的。 这就是为什么我们刚才提到支付中心的时候，提到了三个方面：包括会计、产品、第三方支付。 其实都是统一支付的。 这也是原因。 。 通过统一支付支持的所有资产交易类型，我们可以保证整个模型的简单性。

同时，我们也对订单模式做了一些演练。 事实上，订单模式旨在支持所有银行产品的处理，包括一些特殊场景。

对于贷款交易，也可以通过订单模式来实现。 就像我们的贷款支付一样，这是我们的采购订单。 客户支付给银行的实际上是负债。 客户付给银行的钱可以理解为欠条。 然后银行将资金交付给客户，将贷款资金发放给客户。 还款情况则恰恰相反。

因此，银行的所有业务都可以基于该订单模型进行处理。

根据我们刚刚谈到的六个中心，该图解释了为什么我们可以通过这六个中心快速将某些银行产品在线携带，从而可以减少我们所做的开发量。

最左边的通道系统将无法直接与产品系统连接。 通道系统仅需要根据三个中心进行标准接口连接：用户中心，产品中心和交易中心。 连接完成后，无需修改它。 假设我们现在创建一个新产品系统。 产品系统只需要遵循六个中心的标准接口即可同步相应的产品信息，实现相应的交付接口并实施相应的会计功能。 目前，产品系统可以嵌入我们的整个系统中。 在商业中心系统中。 目前，通道系统可以在本地访问该产品的功能，并实现相应产品的销售和操作管理。 因此，总的来说，推出新产品非常快。

该图是商业中心的总体描述。 这里最大的观点是，我们可以看到商业中心最重要的事情是解决将通道系统和产品系统解耦的问题。

让我们回顾最初提到的中间平台的概念。 中间平台具有通过操作模型更改，组织结构调整，IT架构重建等形成的企业级服务可重复使用能力。在我们当前的业务中心构建中，除了调整组织结构外，我们还经历了操作模型的一些变化。 。 当然，此操作模型是指在IT级别进行业务处理的操作模型。 其次，我们还重组了IT架构。 因此，在此业务中间平台的构建中，我们实际上使用了三种型号，即货架模型，订单模型和付款模型，以实现渠道系统和产品系统的解耦。 产品系统只需要实施产品规则，而无需处理付款即可； 通道系统无需修改； 中端业务系统配置或轻量级修改可以支持新功能，以支持产品的新发布。 这是构建业务中间平台后的效果。