支付架构体系
2023-05-04 23:14:39 2 举报AI智能生成
支付平台架构设计
作者其他创作
大纲/内容
支付业务预支付架构简介
支付牌照
1. 支付牌照的诞生
以前所有支付公司都可以对接银行，可以实现资金留存。存在很多跑路的。 所以后面只有由支付牌照的公司才可以提供资金清算和管理服务
2. 有支付牌照/无支付牌照的支付机构业务流程
中国支付清算体系
发展阶段
阶段1：镖局和票号
阶段2：中国支付清算系统的前身——EIS（1989-2005）：EIS是人民银行专门用于处理异地（包括跨行和行内）资金清算和资金划拨的系统
NPC（National Process Center，国家金融清算总中心）
CCPC（City Clearing Processing Center，城市处理中心）
阶段3：央行支付清算系统（CNAPS）：各家商业银行的内部联网系统纷纷建成投产，银行内部资金划转都可以通过自己的核心系统解决了。这意味着各大行都可以做电子化的行内清算了，行内异地转账就不用再依赖EIS。
大额实时支付系统（HVPS）2002年至今
金额：没有金额限制
时间：大额系统是工作日的 8:30 ~ 17:00，所以在节假日经常会收到银行通知说某些业务暂停了经常就是因为央行在节假日对大额系统做维护。
业务：大额是每笔交易都实时发送，实时清算的，所以基本上能实时到账，跨行资金零在途。
场景：大额系统侧重于资金转移的时效性，主要用于资本市场、货币市场交易和大额贸易资金结算。
小额批量支付系统（BEPS）2005年至今
金额：上限是5w
时间：7*24小时工作
业务：小额系统是在收集若干笔交易后打一个包统一处理，定时清算。所以，用小额系统转账经常要几分钟甚至半个小时才能到账，银行间头寸交割也是非实时的，尽管理论上跨行转账业务不管用大额还是小额，一般在几分钟内都能到账，但是因为要经过央行，所以在这一时期基本没有银行敢向客户承诺资金多久能到账。
场景：小额系统对数据吞吐量要求较高，主要用于小额贸易支付和个人消费服务。
阶段3：二代支付系统（2013年10月6日）
1.接入机构不再限于银行。支付宝、财付通等第三方支付也可以接入
2. 7*24小时实时到账，单笔上限5万元
中国银联
中国网联
支付业务架构
1. 简版业务架构图
架构演进
解决问题：传统单体项目，所有模块都在一个项目中，很有可能因为一个其他非主要业务接口，如查询订单等将系统资源用完，导致正常支付业务不可用。
业务拆分：将模块按照业务进行拆分：
2. 微服务版业务架构图
架构图：
支付时序图
1. 支付网关：所有对外服务在网关进行统一接入，鉴权等。 所有服务由网关进行分发
2. 商户中心：商户入驻平台，管理商户营业执照，法人信息，收款账户信息，费率，结算方式等。在支付和结算时使用
3. 支付核心：只是负责支付，不存在和业务相关性的代码。商户信息，支付渠道，记账都需要调用其他微服务。
4. 账务系统： 管理商户账务记录，和相关资金管理账户
5. 清结算系统： 负责将收到的资金结算给商户
6. 计费系统：负责计算，并收取渠道的手续费
7. 渠道系统： 支付机构通过银联/网联 对接第三方渠道
8. 运营平台： 就是管理后台，负责配置相关参数，查询交易记录。
相关术语：
清分：是清算的数据准备阶段，主要是将当日的全部网络交易数据按照各成员行之间本代他、他代本、贷记、借记、笔数、金额、轧差净额等进行汇总、整理、分类。 可以理解为记账
清算：主要是指不同银行间的货币收付，可以认为是结算进行之前，发起行和接收行对支付指令的发送、接收、核对确认，其结果是全面交换结算工具和支付信息，并建立最终结算头寸。 可以理解为，计算应该给A转多少钱，给B转多少钱。
结算： 清算过程产生的待结算头寸分别在发起行、接收行进行相应的会计处理，完成资金转移，并通知收付双方的过程，也就是正儿八经的付钱
头寸：意即款项。旧时中国商业、银钱业惯用语。银行、钱庄和企业为了保证收支平衡，每日要对可以收进或需要支出的款项进行预测估算，看能否平衡。这种预算活动称为“轧头寸”。如预计当日全部收入大于支出，即为“多头寸”，亦称“多单”；如需支付的款项大于收入款项，即为“缺头寸”，亦称“缺单”。头寸经轧算后有“多头寸”，可把收大于支的余额出借；如“缺头寸”，则应设法拆进或借入款项 (俗称“调头寸”)，以资轧平。
轧差：指通过降低必须支付的金额来降低信用风险。如果支付到期，A欠B的金额大于B欠A的金额，A向B支付所欠金额之差。举例来说，如果A欠B10万元，B欠A4万元，则A对B的净欠额为6万元。没有轧差，B需要向A支付4万元，而A需向B支付10万元。假设B在向A支付4万元的过程中没有意识到A会违约，如果A已经得到B支付的4万元，则B可能无法收回其10万元，那么其信用损失将大于轧差后的6万元。
支付网关
需要具备的能力
减轻下游系统压力：对基础参数进行校验，不合格的就不转发。
系统更安全：不符合标准的请求都挡在了网关层外
容错能力强：下游某个系统故障时，直接将交易挡在网关层，防止交易堆积。
统一接入：不管客户使用哪一种支付方式，上游只需要对接一个接口即可
参数校验
加签/验签： 请求报文的加签，验签
加密/解密：请求报文，发送报文的的加密解密，敏感信息的加密解密
协议转换：参数校验，验签，解密通过后哦，根据相关字段，将请求转发到某个系统，如是需要请求商户信息，则可能直接RPC 协议，如果是请求支付核心则可能是HTTP还需要加密解密。
结果反馈：将下游系统的结果反馈给上游。
功能模块
架构图
加签/验签
目的：防止报文被拦截并篡改
流程图
MD5加密实现
排序实现
RSA加密实现
参数校验
注意事项
一般采用注解校验，正则校验，代码校验。 三者可同时使用
@NotNull 不能为null，但是可以为empty，@NotBlank 只能用于判断String
示例
加密/解密
虽然RSA 算法安全，但是计算量大，效率很低。 所以一般用来在网络中传输 AES，MD5 等加密所需的密钥。
RSA加密/解密流程
1. 通讯甲乙双方交换公钥，生成公钥私钥的工具
2. 甲使用乙的公钥加密数据，并发送给乙
3. 乙接收到数据，用自己的私钥解密。并把处理结果用甲的公钥加密返回给甲
4. 甲接收到数据，使用自己的私钥解密
AES 对称加密/解密
高可用
动态路由： gateway + nacos 或 zuul + eureka + config-server
负载均衡
网关负载均衡，使用Ribbon
Nginx 负载均衡
线程池隔离/ 信号量隔离
限流与熔断
限流
令牌桶
漏桶
计数器
滑动窗口
实现： 单机用RateLimiter， 分布式用Sentinel，或redis + lua
熔断和降级
支付核心
具备的能力：支付核心主要提供预支付，支付，退款，支付结果查询，退款结果查询等接口。
功能模块
架构图
支付核心在支付系统中的地位
API 接口层：提供对外支付的接口，如微信支付，银行卡支付等。以银行卡支付为例，有银行卡预签约接口（4/6要素验证），银行卡签约接口，银行卡支付接口，银行卡绑卡验证码，银行卡绑卡支付，银行卡解绑，退款申请，退款查询等。
业务处理层
概念：主要是提供各种支付能力，并提供查询支付结果的接口。
设计要点
全局ID生成：在支付系统中，每一笔订单都有支付订单号，订单号贯穿整个业务始终，所以订单号的设计尤为重要。
自增ID
优点：实现简单，查询，插入速度快。
缺点：分布式环境在实现复杂，主从复制容易出现问题
UUID
优点：实现简单
缺点：可读性差，性能差，且高并发下可能重复
雪花算法
优点：可读性好，对数据库性能支持较好
缺点：实现复杂，存在服务器时间回拨问题
推荐：百度UidGenerator，美团Leaf生成（解决了上述问题）
分库分表
解决的问题： 当业务量起来的时候，支付系统每天的量非常大，这么多的订单都保存到一张表里，且支付记录至少要保存一年的数据，上亿级别的数据都存在一张表里，查询和更新都会成为瓶颈，所以需要做到分库分表。不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，导致连接数用完。所以我们需要使用分库分表来缓解数据库的压力问题。当然我们说的分库前提是分出来的库一定要在不同的机器上，不然起不到效果。
场景
水平分库
使用场景：绝对并发量增加，数据库当前最大活跃连接数已经不能在往上调整。(当绝对并发量上来， 也就是交易量上来，假如数据库连接是10,有点不够用了。但是计算机资源还很充足，这时候可以调大数据库相关参数，假如计算机资源已经利用的很充足了，那么就需要再拿一台服务器部署一台数据库来减轻压力。)
好处：比如原来单库500的QPS，现在两个库了，单库就降到了250QPS。
方法：根据主键类型，采用HASH，取余等将一个库中的数据拆分到多个库中。
结果：每个库中的数据结构一致，每个库中的数据不一样，没有交集，所有数据库合并便为全部数据
水平分表
使用场景：系统绝对并发量没有增加，只是单表的数据积累的太多了，影响SQL 的效率，加重了CPU的负担，以至于成为性能瓶颈。
好处：单表数据量减少，单次SQL执行效率较高，减轻了CPU的负担，另外拆分的表多了，单个表的数据查询量会成倍的减少。
方法：根据主键类型，采用HASH，取余等将一个表中的数据拆分到多个表中
结果：每个表的结构一样，每个表的数据都不一样，没有交集，所有表的并集是全量数据。
垂直分库
使用场景：系统的绝对并发量增加，单库无法承担并发量，且并发分布在不同的业务时，可以将不同的业务模块抽出来形成新的库，如果集中在同一业务中，那就只能使用水平分库。
好处：将不同业务的库分开，各个业务间不影响，各个业务模块独立开发，独立维护，这也是现在很多微服务用的模式
方法：以表为依据，将每个表拆分到不同的库里面。
结果：每个库的结构不一样，每个库的数据也不一样，没有交集。
垂直分表
使用场景：系统绝对并发没有增加，表的记录也不是很多，但是表的字段过多，超过200个甚至过多，在查询时，单行数据所需的存储空间过大，以至于数据库缓存的数据行减少，查询时需要读磁盘的数据，从而产生大量的磁盘IO，出现IO瓶颈。
好处：增加查询速度，将非热点数据分开之后，这样更多的热点数据能被缓存下来。
方法：商户信息表有很多字段，我们可以将高频字段分开，在列表查询时可以只展示高频字段，需要看详细信息的时候，在去点击查看详情，点击的时候再去查询。注意查询的时候不能用join，join 不仅增加了CPU负担，而且会将两个表耦合在一起（查询的返回必须要写一个数据库实例接收），应该在业务层实现数据的关联或者拼接。
结果：每个表的数据结构不一样，每个表的数据不一样，每个表的字段至少有一列有交集，一般用主键来关联数据。
技术选型
ShardingSphere
Sharding-JDBC 标准的数据分片
Sharding-Proxy 分布式事务
Sharding-Sidecar 数据库治疗功能
TDDL（TaoBao Distributed Data Layer）
非主键列的查询问题：
问题：根据partition key 实现插入，删除，查询，更新都是非常高效的。但是非partition key的查询会稍微复杂一些。
解决方式
1. 比如要根据商户号查询：维护一个商户 和 partition key 的关系，根据商户查询时然后得到相关的订单。
2. 将数据通过binlog 或者 MQ 同步到，离线数仓或者ES
渠道路由
具备的能力：为支付系统对接第三方系统，提供出金和入金的能力。
支付渠道
中国银联
概念：2002年3月，中国人民银行（简称央行）批准成立，由各个金融机构共同出资联合成立的中国银行卡联合组织。
银联业务框架
银联之前存在的问题
1. 针对银行，资金清算业务操作繁琐，跨行，跨地区，跨进交易的清算人工成本高，时间长。
2. 针对消费者和商户，消费者出门需要带多张不同的银行卡，在不同的地方，根据不同的POS机使用不同的卡进行消费。商户也要安装多个银行的POS机，以满足不同客户的刷卡需求。
3. 针对第三方支付机构，三方支付机构需要对接不同的银行，每一个银行都需要对接，对接工作量大。
4. 针对监管部门，由于交易分散，对每个支付机构的监管耗时耗力，并且监管效果甚微。
银联解决的问题
1. 统一清算能力，提供了银行卡的标准，解决了跨行，跨地区，跨境消费的问题
2. 提供统一支付接口，第三方支付只需要对接一家
3. 为监管部门提供了便利的监管条件
4. 消费者可以在任何ATM，POST机上操作。 商家POS机也可以刷任何银联卡。
针对第三方机构提供的接口
机构入网
统一支付入口
交易清算：银联计算好要结算的资金后，央行给你计算结构结算到支付机构的备付金账户中。
对账文件下载
差错处理：通常通过线下邮件的方式来处理
中国网联
概念：由中国支付清算协会按照市场化方式组织非银行支付机构以“共建，共有，共享”原则共同参股出资，与2017年8月在北京注册成立。
和银联的区别：网联成立之初解决的是针对网络支付业务以及我们说的线上支付业务的资金清算，而银联针对的主要业务是线下收单。但目前银联和网联的线上业务并没有太大的界限，对于第三方机构来说，都可以作为统一支付的入口和清算机构来使用。
核心理念：为非银行支付机构提供统一支付清算支持，实现非银行支付机构及商业银行一点接入。
解决的问题
可以对支付机构进行监管
在支付宝，微信支付走出国门之后，在国际竞争中以合规的角度得到国家的背书
针对第三方机构提供的接口
协议支付：网联建成狗，根据央行发文要求，支付机构和银行的支付协议必须保持一致，从而实现了从银行卡端发起解约交易，以往都需要在各个支付软件中取消协议。
认证支付：认证支付至客户无须实现或在首笔交易时与支付机构及银行签约，每笔交易时均输入身份信息（手机号，银行卡，姓名，身份证号等）、银行账户及动态信息（一般指验证码），并由客户账户所属银行负责对上诉信息校验后进行扣款的交易。认证支付业务主要为无支付账户体系或支付账户体系应用较少的支付机构开展网络支付业务时使用。
网关支付
商业委托代扣：代收，代扣
非银行支付机构
微信
支付交互流程
微信商户入驻流程
支付模式
H5支付：移动端非微信内部的网页
小程序支付：只能在小程序中使用
JSAPI支付：用户在微信中打开商户的H5页面进行支付
在商户公众号中打个某个页面完成支付
在朋友圈，聊天窗口等分享商户页面链接，用户打开商户页面，完成支付
将商户页面转换为二维码，用户扫描二维码后在微信浏览器打开完成支付。
Native支付; 商户按照微信支付协议生成支付二维码，用户在用微信扫一扫进行支付。 一般用于PC端网页，实体店，订单支付，媒体广告支付。如百度云盘扫描付款，爱奇艺pc端扫描付款。
付款码支付：用户展示微信钱包内的条码或二维码，商户系统扫描后完成支付，用于线下门店
APP支付：在移动端应用APP中集成开发SDK，支付时调起微信应用内的支付模块。
支付宝
支付交互流程和微信类似不做说明
微信商户入驻流程和微信类似不做说明
支付模式
当面付
付款码支付：商户使用扫码枪或其他扫描机器扫描用户出示的付款二维码
扫码支付：商户提供收款二维码，通过用户支付宝扫描
H5支付：在手机浏览器中调起支付宝客户端支付
PC端支付：在PC端网页跳转到支付宝PC网站收银台
APP支付
刷脸付
互联网平台支付通：为电商等专门打造的支付，结算，分账一体化解决方案，支持多个商户的订单合并支付，并结算时直接结算给对于的商户。
渠道路由设计
考虑的因素
渠道稳定性：如果交易成功率低，稳定性差，但是费率低，我们可以适当的降低权重，如果费率都没有竞争力直接关闭。
成本：每个渠道的费率不一样，同一个渠道的不同行业类型收取的费率也不一样。
概念
入金：收款，将C端客户的资金受到三方支付机构的备付金账户中
出金：从三方支付机构的备付金账户中结算资金到商户的银行账户中
渠道路由总体架构设计
入金路由设计
路由筛选条件
支付场景payScene
online 线上
offline 线下
支付工具 payMedium
wx 微信支付
aliPay 支付宝支付
band_card 银行卡支付
渠道机构 channelInst
union 银联
net_union 网联
wexin 微信
aliPay 支付宝
支付模式
applet 小程序
h5
wap
jsApi 公众号
protocol 协议支付
no_card 无卡支付
all_channel 全渠道支付
商户号选取条件
费率
可用性
入金路由架构图
出金路由设计
鉴权通道：由于出金就是把商户的钱，从备用金账户结算到商户绑定接受资金的银行卡中，所以在绑定是需要校验四要素的正确性。
路由筛选条件
商户限额
绑定的银行卡
出金路由架构图
说明：支付内部系统发起结算，结算一般与T+1日开始，会由定时任务触发，渠道系统收到请求报文后进行参数校验，每一笔出金请求都会落库记录，以备后续对账。
业务路由：负责过滤商户，如果有商户被风控，或有洗钱嫌疑则会暂停出金，每个商户针对不同的银行会有额度，次数限制
渠道路由：每个渠道所支持的银行不一样，如果渠道支持的某家银行在某个时间段正在维护，如网联支持的北京银行正在维护，那么需要过滤网联-北京银行这个渠道
出金渠道:调用银联，网联进行出金成功后，会异步通知支付内部系统。
备付金管理：出金需要映射备用金账户，如果资金不足，应及时向备付金账户及时备款。
智能渠道护航
概念：渠道护航负责发现异常专线网络和异常渠道，发现异常专线和渠道需要经历数据收集，数据分析，结果反馈几个阶段，渠道护航系统检测出渠道异常，吧异常信息反馈到路由系统之后，路由系统会切换相关的专线或者支付渠道。
模块
数据收集：收集网络检测数据和支付业务结果
数据分析：如果网络检测成功率低于95%则关闭该专线的指令。
结果通知：将切换专线或渠道的指令发送到各个业务方。
渠道切换
渠道回切：当成功率大于95%时，则恢复渠道。一般通过查询交易状态的接口来验证渠道是否正常，因为查询类交易不影响正常业务。
渠道护航架构图
渠道切换流程图
收银台
收银台架构设计
概念：PC ，手机端消费者支付的入口。 主要分为内嵌页面收银台和独立页面收银台
职责
前端
判断支付环境，并在请求时传给后端
展示支付列表，供客户选择
收集商品信息进行下单（下单在后台就是保持订单）
发起预支付，也就是拉起支付页面
完成支付，展示支付结果。一般为轮询查后端支付结果
后端
预下单接口，也就是保持订单信息
支付配置管理，也就是该商户支持什么支付方式。 每次交易都要返回给前端支付方式列表
支付
架构图
收银台流程处理
阶段一：预下单
1.客户选好商品，填好收货地址收，点击提交订单，这时候前端手机客户的商品信息和金额信息上送到收银台后端
2. 收银台收到预下单请求后，首先落库，然后上送信息到支付核心，支付核心落库成功后返回结果。
阶段二：支付方式列表查询
1. 收银台前端收到结果后，调用后端拉起支付列表接口，收银台后端收到支付列表请求之后经过一系列筛选最终选出可用的支付列表返回给前端
2. 前端收到支付列表后展示给客户，供客户选择。
阶段三：预支付
1. 客户选好支付方式后进行支付
2. 前端把之前下单的订单号传到后端进行支付
3. 调用支付核心进行支付
4. 如果是微信支付宝，则主要返回Deeplink 给前端。
阶段四：输入密码完成支付
1. 前端收到Deeplink后拉起微信或者支付宝客户端进行支付
子主题
收银台SDK设计
收银台接口定义原则
1. 接口职责要单一，哪怕两个接口的请求参数只差一个，也要写成两个实体接收参数，写成两个接口
2. 接口参数要尽量少，能自身获取的就不要用接口上送
3. 参数一定要进行规则校验，和业务校验
4. 名称要见名思意
6. 参数在每个接口的名称要统一，比如在支付接口叫pay_amount，那么在查询接口就不能叫pay_money
收银台接口定义实践
预下单接口：用来收集订单信息，在支付的时候用来和支付接口上送的信息进行对比，要保证两次上送的信息一致
请求参数
返回参数
支付方式查询
请求参数
返回参数
预支付接口：为什么叫预支付不是支付，因为很多支付模式分两个阶段，第一个阶段是上送支付信息到微信，支付宝，第二个阶段是输入密码，第一个阶段叫预支付，第二个阶段叫支付。
请求参数
返回参数
收银台SDK 架构图
收银台路由设计
收银台可配置维度
业务场景
支付
充值
渠道维护
渠道限额
渠道是否维护
商户维度
商户签约支付方式
商户已开启支付方式
用户维度
是否开通该支付方式
各支付方式余额是否充足
商品维度
商品类目
商品ID
支付环境
微信小程序
支付宝小程序
h5支付
浏览器环境
收银台路由架构
支付方式初始化：根据支付场景，筛选出所有支付方式列表。支付场景分支付和充值。
支付方式筛选：根据支付环境，渠道维度，商户维度，商品维度进行筛选
支付方式结果输出：筛选出来后，如果第三方机构和渠道有相关的协议，可能会使用费率优惠的支付渠道，比如微信支付比银行卡支付费率低，我们通常把微信支付放在第一个，既推荐位。 也可以根据费率进行排序
清结算和计费
业务简介
概念：三方支付机构的清结算系统和央行的支付清算体系不在一个层级，央行支付清算体系负责清算银行与银行之间的资金清算。我们的清结算系统负载清算商户的资金结算。
银行系统中清算和结算的意思
清算：银行系统中清算是清算中心的工作内容，清算包括清分和资金划拨，清分用于登记流水和轧差汇总，资金划拨是在各个银行之间进行资金调拨。
结算：是指银行按照结算周期，对其直连商户的资金进行核算，了结。
支付机构中的清结算的意思：这里的清只有清分的意思，也就是记账，轧差。结算就是将资金付款给商户。
清结算系统
架构图
步骤
1.清分：支付成功和计费成功后，落清分记录。可以采用异步通知，或者消息队列解耦。
2.清算：将清分记录，用商户作为筛选条件进行抓取
3. 轧差：将支付和退款进行轧差。 退款和支付订单需要看类型
4.结算：将轧差金额上送银联/网联，最后由央行进行资金划拨，完成结算
计费系统
业务简介
概念
渠道手续费：每一笔通过银联、网联完成的交易都需要支付手续费，我们称为渠道手续费。根据行业性质不同收取的手续费不同。 交易医疗一般是0.2%，电商游戏按照0.6%收取。
支付机构手续费：商户通过支付机构进行支付，支付机构所收取的渠道服务费。
支付计费的方法论
概念：如何收取商户的收取费，如何让商户更愿意交手续费，如何收取更多的手续费，这是产品设计层面一个值得深思的问题。
为何收费：我们提供了一个便利的聚合支付渠道，所以需要收取一些渠道维护费。有了维护费才能支持更多的银行，更多的支付方式。
什么费用
利用支付收银台收取广告费
收取渠道费
收取如理财产品的服务费， 水电气代缴的手续费，信用卡还款的手续费
何时收费
最传统的方式，在商户结算是收取手续费
也可以让商户提前充值手续费，给予一定的减免，如果商户量交易量巨大的话，商户绝对会考虑
谁来收/付费
收付费的账户，是银行卡账户还是余额，需要提前约定
在哪收费：如广告费，营销费，手续费等都可以让商户提前预存，提前获得资金，还可以留住商户。
如何计费：根据商户行业类目，交易量等签订费率
计费系统架构设计
设计原则
计费系统不能影响支付主流程
计费系统要有很好的扩展性，以应对更重活动，各种场景下的计费
计费策略
阶梯计费：支付金额在100万时 0.65%， 100-500万 0.6%， 500以上 0.38%
预存费用：商户缴存费用到计费账户，针对预存的手续费，可以进行优惠。可以帮助支付机构吸引商户预存资金。可以提前变现，留存商户
架构设计
商户中心
业务简介：为商户提供入驻接口，提供交易查询，对接服务。
商户入驻
概念：审核商户的入驻条件，利用三方支付机构的支付功能做生意必须是个体工商户，企业，党政机关及事业单位。
入驻所需材料
资质信息
主体信息
营业执照
注册号
商户名称
注册地址
营业执照照片
组织结构代码
组织结构代码
组织结构代码证照片
有效期
营业期限
经营者姓名
法人信息
证件类型
证件照片
证件号码
证件持有人姓名
证件有效期
结算信息
账户类型
开户名称
开户银行
开户支行
银行账号
其他信息
经营信息
客服电话
商户简称
经营类目
教育
医疗
电商
结算规则信息
结算规则
T+1
D+1
实时
费率
0.2%
0.38%
0.6%
如需要享受低费率政策，需要提供其他补充材料
商户入驻微信示例
概念：当商户使用三方支付机构的支付功能时，需要上送相关的资质。同样通过三方支付机构开通微信，支付宝支付时也需要上送资质到微信支付宝，只不过三方支付机构把这个动作给封装了。对你来说，你要同时注册微信，支付只需要在三方支付机构操作一次就可以了。
流程图
系统架构设计
商户中心系统架构
认证系统架构
财务系统
概念：主要职责为记录系统中交易，然后登记入账。
账户体系
分类
按服务对象
B端账户：针对支付机构服务的商户开设的账户。
C端账户：C端消费者在支付机构下可以支配资金的账户，如预付款，余额
按是否结算
内部户：内部用于资金过渡的账户
外部户：开设给B端商户的资金账户
备付金账户：支付机构在央行开设的账户，钱都是存央行的，防止支付机构跑路
B端账户
概念：针对支付机构服务的商户开设的账户，商户入职支付机构的时候，支付机构给商户开设对应的账户，在清结算的时候根据账户的资金进行结算。
分类
清算账户：每天发起定时任务清算，假如2笔100元的支付单和一笔100元的退款单，那么清算账户记100元。清算账户作为内部过渡账户，为结算提供结算依据。
结算账户：清算任务完成后，进行结算任务，通常在T+1结算。如清算资金100，手续费0.6，那么将99.4结算到商户账户中。
营销账户：一般用户商户返现到C端消费者余额，或微信红包的形式。因为商户的账户中需要先有资金才能发放，所以商户需要在开设的营销账户中充值。通过支付机构发给消费者。
保证金账户：如淘宝的商家需要交纳保证金。就是这个保证金账户
跨境余额账户：如果有海外商品的支付，海外的商户对接支付机构，如果要把钱结算到对方的海外银行账户，就需要开通跨境账户
C端账户
概念：类似于理发店的开卡，支付机构也可以有预付卡，预付卡需要申请预付卡支付牌照。C端消费者充值后，可以在不同的商户店铺使用。 如储值账户，礼品卡。如京东卡，天猫卡
分类
余额
礼品卡
会计账户
备付金账户
账务系统架构设计
核对体系
支付机构的信息流和资金流
对账业务简介
对账架构设计
总体架构设计
关键步骤实现细节
跨境支付
0 条评论
下一页
