世界上有几个国际结算系统

世界上共有**三个**国际结算系统，它们是SWIFT、CHIPS和CHAPS。

SWIFT，即环球同业银行金融电讯协会，是一个连接全球银行和市场的跨境通信网络，是各国银行合作的一个典范，其提供的服务旨在使日均余额超过100万美元的客户的国际支付更为高效。

CHIPS是纽约清算所银行同业支付系统，为美国和与其有业务往来的他国银行提供服务。

CHAPS是伦敦自动清算所银行同业支付系统，其运行时间更长，可以处理英国、澳大利亚和新加坡等其他地点的国际支付。

这三大国际清算系统在金融行业发挥着重要作用。

第三方支付平台转账功能实现逻辑

1.交易系统的场景

1)? 下单

2)修改金额

3)退款

4)查询

5)通知

6)算费(算手续费)

2.交易系统的交易类型

1)即时到账交易

2)担保收单交易

3)下订交易

4)合并支付交易

5)收单退款交易

6)提现

7)普通转账交易

8)冻结解冻

9)充值

3.支付系统的业务层

支付层包括支付核心，场景核心和清算核心等三部分组成。

支付核心的边界：

1)支付接口的封装

2)对每类支付业务类型定义流程

3)支付协议，定义收付款协议

4)根据协议得出支付指令。

4.财务核心

账户及资金变更记录

5.收银台设计

其中组合支付的流程设计

生成两条支付方式的请求：一条为余额支付请求，一条为第三方支付请求。转换到支付前置后，前置系统生成一笔组合支付的订单，且对应着两条支付指令(一条充账，一条转账)，当充值的指令成功后去执行转账的指令，两笔都成功的话则通知上层系统变更业务状态。

6.会员系统

分为个人和企业。

7.支付核心

支付流程举例：用户在电商网站购买一本书价格100元，通过支付宝付款，交易类型为担保交易，在交易核心生成一笔担保支付的订单，调用支付核心系统时支付系统判断该业务调用方对应已经配置了《收单支付协议》，且根据对应协议生成一笔业务类型为第三方支付的支付订单，基于此订单生成了第一条充值的支付指令，该指令在根据支付类型去调用服务流程时，先通过流程编排生成清算指令(先生成清算指令目的是需要调用外部支付渠道，把钱收进来)，用户付款成功后再生成财务指令并调用财务核心，执行内部财务入账。

8.账户及账务流水

账户类型：内部账户和外部账户。

内部账户：如余额账户和营销账户。

外部账户：用户的渠道支付账户，平台渠道结算账户，商户结算银行卡账户。

每个账户包括真实余额账户，赠送余额账户，在途余额账户等。

账务流水：

一笔交易流水可以包含多个账户流水，如一笔支付宝收款的交易流水，会包含一笔渠道支付的账务流水和一笔渠道手续费的流水。

9.对账：

核心工作是将财务流水记录与支付渠道的对账单进行逐一核对。

10.清分

清分规则是客户的交易资金结算比例，结算规则是客户的交易资金结算周期。

举例：

实时清分：用户A通过销售人员B在卖家c处，购买了100元的商品。用户使用了10元的优惠券，通过支付宝实际支付了90元，平台对每笔交易收取5％的手续费，销售人员B可以按每笔交易获得20％的提成。

解析：

在该笔交易中，平台向卖家收取的5元手续费，销售人员获取的20元提成，由清算核心进行处理交易资金；平台的优惠券垫款10元与卖家余额账户的90元，由账务核心进行处理；卖家C余额账户收到的100元中，分别向平台收入账户支付5元，和销售B的余额账户支付20元。在财务核心中，会生成一条平台手续费类型的账务和一条资金分润的账务。

异步清分：交易完成后，不能立即确认该笔交易参与资金清分的客户。

举例：

快递交易需要按订单金额的1％分配快递费，在用户支付成功后，并不能知道快递配送方，等卖家进行快递发货后，平台收到快递信息后，更新交易订单的快递方，此时再由清算核心完成快递费的清分。

最近接到了一个来自公司内部通讯软件产品组需求，即在通讯软件内嵌转账到账户的SDK。

再此之前，已打通通讯账户和支付平台账户。为什么会有这样的需求？因为我们内部的通讯APP打算外放，作为通讯软件推向市场，同时我们的第三方支付平台在部分地区已经有一定的用户基础。以上就是这个需求的简单背景，下面具体说一下在聊天软件内置转账SDK的处理逻辑。

首先是订单处理系统，用户发起一笔转账即生成一笔转账订单，来记录转账的金额、流程状态、订单号、付收款人信息等等。其次因为涉及到资金安全，转账尤其是大额转账必须要求用户实名，所以会用到会员信息系统，来查询用户的实名状态和实名等级（初级实名、高级实名等，和转账限额有关）。确认了用户已实名，我们就可以根据付款方的意愿，调用收银台，给用户选择支付渠道进行支付扣款。然后会进入资金系统和清结算系统，进行资金扣取，结算，记账等操作。最后收款方就会收到一条通知，收到一笔转账。通知是订单处理系统同步通讯软件订单状态以后，做的通知。当然，在整个流程里面还会穿插风控系统，来验证账户是否安全，转账是否符合风控规则等等。

关键词：订单处理系统、会员信息系统、收银台、资金系统、清结算系统、风控系统、通讯软件

大家可能对微信转账的流程比较熟悉，A给B转账一笔钱，首先是点击转账按钮，输入转账金额，确认转账，选择支付方式（零钱、零钱通、银行卡支付、添加新的银行卡），支付密码校验，点击支付，付款方的这笔转账就生成了，但是需要收款方点击收款，这笔金额才会结算到收款用户的零钱里面，如果24小时内未收款，资金会被退回。当收款用户领取转账以后，付款方也会收到一个提醒。如果，付款用户在收款用户还未领取上一笔转账就进行第二次转账时，微信也会提醒付款方已有一笔转账还未领取，是否需要继续执行第二笔转账。整体来说，体验还是一如既往的不错。

我们和微信的情况不太一样，我们希望在不对原有的支付平台内的转账流程做较大改动的情况下，完成通讯软件内转账SDK的开发。所以，这里讨论的转账处理流程可能就会比较直接。（钱我给你了，你就拿着吧，别不好意思！）

转账流程其实分为两个子流程，比较大的子流程自然是转账流程，比较小的是不满足转账条件时的退款流程。先来详细说一下转账流程，转账流程会把上述的所有系统全部涵盖，简单的几步转账操作，背后却都是大系统在支撑。

1）A想要向B进行转账，首先A会在B的聊天界面内，点击转账按钮。

2）我们的主系统知道了A的指令，首先需要验证一下A是否已经绑定支付账户，如果没有，麻烦先去绑定，绑定了支付账户，我们还要验证A是否已经实名，如果没有，请去实名。对付款用户，要求就是这么严苛！我们必须知道A是谁，是你本人在操作，才能放心帮你转账。

3）然后我们也会查看B是否已经绑定支付账户，如果没有绑定，我们会让A邀请B赶紧去绑定支付账户。这边并不需要B一定要实名，当然最后想拿到这笔钱还是必须要实名的。

4）A已绑定已实名，B已绑定，我们还需要调用风控系统查一下你们的账户是否都安全，是否存在异地登录，不常用的设备登录等等一系列的规则验证（各家的风控介入时机和验证规则都不一样，这边只做参考）。一旦发现异常，首先通知A，您的这笔转账有风险，再根据风险等级判断转账操作是否还能够继续。

5）假设A和B都是正常的，主系统会返回收款方的支付账户信息，在通讯软件内就对应转账页面，A能够看到B支付账户的头像、用户名、账户（隐位处理）等等信息，来确认一下这就是我要转账的账户。

6）然后A会输入转账金额和备注，主系统收到信息，调用收银台SDK。

7）收银台给出A支付账户下绑定的支付渠道还有不同渠道的限额说明（一般就是零钱账户、理财账户、银行卡账户），如果A发现这几个支付渠道的钱都不够用，也可以绑定新的银行卡进行支付。这边就属于支付收银台SDK的范畴了，不做详细描述。

8）此外，收银台也会调用风控系统，对限额和转账次数等做风控规则的校验，有可能会需要用户进行短信密码校验啊什么的。。。风控真的是时不时就要来一下~

9）收银台最后会把支付结果返回给主系统，用来更新订单状态，同时通知资金系统进行支付账户的扣款操作，再由清结算系统结算至B的收款账户。

10）结算到收款账户时，还会判断B的收款账户是否已经实名，如果已经实名，那么没问题，转账成功！如果还没有实名，那么这笔钱会被冻结一段时间，需要B在这段时间内完成实名，否则钱会被退回到A的扣款账户。

11）结算系统把转账结果告诉主系统，主系统更新了订单状态，再告诉通讯软件，通讯软件同时通知A和B。

上述就是目前我们在做转账时的处理逻辑，可能还比较粗糙，没有太注重用户体验。尤其是在一款通讯软件内做的转账功能，必须注重体验。但是，毕竟我们还是完成了转账功能的开发，原来支付平台内的这个转账流程的转账成功率也一直保持在99%以上，对于用户体验的提升，还是希望通过市场验证来有针对性的做一下提升。

B想要拿到这笔钱，必须实名，但是什么时候进行实名，在很大程度上影响着双方的用户体验，也关乎这我们一些运营同事的KPI。如果我们在A进行转账之前就要求B实名，那么B可能会这么想好麻烦，钱还没拿到呢，先要我绑定身份信息（初级实名），还要绑定银行卡（高级实名），算了算了，支付宝吧~那么，我们可能会失去2个用户。

作为我们，必须要求A在转账之前就实名，确认A的身份，确认是本人在操作，我们才放心进行扣款和后面的转账。但是对于B，我们大可以在B收到这笔钱以后进行冻结，然后B可以通过实名来解冻这笔转账。这时候B可能会想我账户上有笔钱被冻结了？不行不行，我得赶紧实名解冻！这样的话，既不影响A的转账体验，也能提高B的实名动力同时完成KPI。