支付系统设计

目录结构:

  1. 支付系统架构

  2. 核心交易

  3. 支付风控

  4. 财务对账及结算

  5. 监控与告警


1 支付系统架构

1.1 支付系统架构-分层

支付系统设计

1.2 支付系统架构-应用

支付系统设计

1.3 支付系统设计

支付服务由一套完成的业务系统组成,包括以下功能:

1. 业务接入: 同时支持公司多个收款业务系统对接。

2. 商户接入: 支持商户入驻,商户需要向平台方提供相关的资料备案。

3. 渠道管理: 支持微信、支付宝、银联、第三方支付等多种渠道。

4. 账户管理: 渠道账户管理,支持个人、商户及自有账户。

5. 支付交易: 生成预支付订单、提供退款服务。

6. 对账系统: 实现支付系统的交易数据与第三方支付渠道交易明细的自动核对(通常T+1),确保交易数据的准确性和一致性。

7. 清算管理: 计算收款交易中商户的应收与支付系统收益。

8. 结算管理: 根据清算结果,将资金划拨至商户对应的资金帐户中。

1.4 支付产品

支付系统设计

支付产品模块是按照支付场景来为业务方提供支付服务。这个模块一般位于支付网关之后,支付渠道之前。它根据支付能力将不同的支付渠道封装成统一的接口,通过支付网关来对外提供服务。

1.4.1 快捷支付

用户在完成绑卡之后,在支付的时候,不需要再输入卡或者身份信息,仅需要输入支付密码就可以完成支付。对于小额度的支付,甚至可以开通小额免密,直接完成支付。这种支付方式不会打断用户的体验,是目前主要的在线支付方式。一般快捷支付产品是通过封装银行或者第三方支付平台提供的快捷支付接口或者代付接口来实现的。

1.4.2 网银支付

用户在支付的时候,需要跳转到银行网银页面来完成支付。在网银页面,需要输入用户的卡号和身份信息。这种支付方式会中断用户当前的体验,一般仅用于PC Web上的支付。网银支付是封装银行提供的网银支付来实现。

1.4.3 第三方支付

使用微信、支付宝等第三方支付平台来完成支付。使用时,一般需要用户预先安装支付平台系统(手机上),注册并登录到第三方支付平台,并且已经在该平台上完成绑卡等操作。由于微信、支付宝已经被大量使用,用户也产生对这些平台的信任,支付往往是电商公司的主要支付方式。

1.4.4 信用支付

如京东的白条,蚂蚁花呗等,指使用信用账户进行透支,类似信用卡支付。

1.5 支付网关

支付系统设计

支付网关是对外提供服务的接口,所有交易相关操作都需要通过网关分发到后端对应的渠道模块上。而支付渠道模块是接收网关的请求,调用渠道接口执行真正的支付相关操作。每个渠道的接口,传输方式、参数都不尽相同,在这里,支付网关封装各个渠道的差异,而且支付网关的功能是为业务提供通用接口,一些和渠道交互的公共操作,也会放置到网关中。


支付系统设计

限流:

(1)熔断,熔断请求判断算法、熔断恢复机制、熔断报警

(2)计数器方法

(3)队列

(4)令牌桶

支付路由:

(1)节省成本

(2)提升容错率

(3)提升用户体验

签名验签:

防篡改

鉴权:

(1)请求身份验证,ip白名单、Token身份验证、Token+AppKey签名验证等

(2)支付产品状态、有效性等

(3)请求头验证

1.6 支付渠道对接

前提:根据自身的业务需求选择合适的支付渠道及支付产品

支付系统设计

1、所需要的支付产品不要选错,然后一般要申请商户后台权限,技术对接相关权限(商户号、秘钥申请、开通接口使用权限)。

2、获取渠道服务方提供的对接文档,配置账号、权限、秘钥等。

3、对接支付相关的 API ,按照自己内部支付模块以及支付渠道的对接开发文档对接开发即可。

4、上线结果通知:双方确认上线时间,上线前处理好生产环境相关的配置,上线后通知渠道方配置验收测试。

5、关联模块功能更新:渠道参数的更新、维护、API等变动时商户侧也需要配合做更新。

支付系统设计

支付系统设计

支付系统设计

支付系统设计

1.7 支付路由

设计目标

1、节省成本,这是支付路由选择支付通道的最主要的规则。哪个通道省钱,基本会优先考虑这个通道。

2、提升支付产品的QOS。这体现在系统的可靠性、稳定性、性能和可用性上。通过屏蔽掉无法连接、不稳定、性能低的通道来提升这些指标。

3、支持营销。通过优先选择有优惠活动的通道,可以帮助业务提升付费客户量。

4、降低运营成本。一个设计良好的支付路由,可以大大降低运营投入。

支付系统设计

规则:路由规则是支付路由的核心,在规则设置上,需要结合公司的业务来综合考虑。

支付系统设计

2 核心交易

2.1 支付

支付系统设计

2.2 退款

支付系统设计


支付系统设计

2.3 充值

支付系统设计

2.4 提现

支付系统设计

3 支付风控

要点:梳理清楚业务风险,分析风险原因,制定风险防范规则。

支付系统设计

3.1 账户风险

支付系统设计

3.2 交易风险

支付的交易风险主要是交易过程中的各种恶意行为,包括自动刷单、人工批量下单、异常大额订单等场景。

秒杀场景:

在秒杀的时候, 由于其价格有很大的优惠力度, 黄牛会采用机器批量注册账号、机器抢购等方式来争取秒杀商品,普通消费者很难享受到秒杀的实惠,使得秒杀活动效果大打折扣。

盗刷场景:

持卡人在信用卡未丢失、支付密码未告知他人的情况下、资金被完全陌生的第三方冒名消费、转账提现

刷单场景:

主要的风险在于小号刷单、刷虚拟物品。不少商家使用刷单、刷评价的方式来以非正常途径提升销量,积分,信誉等,甚至通过刷单的方式来套取补贴,帮助套现。

3.3 洗钱风险

这些支付机构提供的服务,存在未落实实名制、风控措施不严格等问题,被犯罪分子所利用。主要手段包括:通过一些第三方支付平台发行的商户POS机虚构交易套现;将诈骗得手的资金转移到第三方支付平台账户,在线购买游戏点卡、比特币、手机充值卡等物品,再转卖套现;利用第三方支付平台转账功能,将赃款在银行账户和第三方支付平台之间多次切换。

3.4 套现风险

我国法律明确禁止使用信用卡套现,使用信用卡套现是违法的。但是在线支付系统中,使用信用卡进行套现,几乎是不需要成本的。信用卡套现的手段也很多,比如:

虚假购买,客户通过信用卡购买某商品后,商品并未实际发货,商家将购买的款项打回给客户,完成套现。

退货套现:或者通过信用卡来购买商品,然后退货,将退款返回到借记卡或者其他可提现的渠道,也能完成套现。

自买自卖:商家通过信用卡购买自己的商品,将货款打入到借记卡中,完成套现。

上述的套现手段,很难识别。套现很难完全杜绝,除了要求退款资金必须原路返回外,还可以通过数据分析手段来减少发生的频率。

3.5 操作风险

操作风险主要是指那些由于用户支付终端操作失误、工作人员违规操作、内控机制失灵等人员操作上的原因引致损失的风险,或者说是外部风险、员工风险和流程风险。

员工风险指的是支付机构的员工不遵守职业道德,违法违规或违章操作,单独或参与骗取、盗用机构资产和客户资金,工作疏忽等行为导致的损失。在缺乏成熟培训机制的互联网公司中,这类问题往往更加突出。

欺诈行为:员工同外部人员相勾结,通过挪用资金、职务侵占等方式非法占有公司财产或者泄露出卖公司商业秘密的行为。

越权行为:员工未经授权、或超越工作权限导致的损失,比如开发人员私自修改数据库给人送优惠券。

错误操作:员工在具体业务操作过程中的失误造成的错误操作。

3.6 资金风险

主要体现在沉淀资金,有两种形式:

在途资金

指买卖双方在确认交易后,完成结算前尚未到达卖方账户的资金。在买方没有最终确认收货之前,资金暂时交由第三方支付进行保管。这样在买卖双方从开始交易到最终完成货款两清的这段时间差内,这些存在于第三方支付平台内部的资金,被称为在途资金。

留存资金:

对采用交易担保型账户的支付机构,客户需要开立虚拟账户来完成交易。机构也会吸引客户进行充值操作,即留存一些资金用于交易。比如微信支付和支付宝的钱包。当有交易需求时,可以直接从这里进行扣款。这些留存于虚拟账户中的资金也是沉淀资金的一部分。

资金沉淀,有跑路或挪作他用的风险,后来央行出台了《支付机构客户备付金存管办法》,其中明确要求第三方支付机 构对于客户的备付金要进行严格的区分管理,这一定程度上限制了沉淀资金风险的发生。也就是说,沉淀资金是客户的钱,支付公司不能挪用。支付公司可以获得沉淀资金的利息收益,但是不能够用这个资金来进行投资或者公司内部的消费。对这笔资金进行合理监控避免出现风险,也是支付系统需要考虑的问题。

3.7 合规风险

合规风险指机构因未能遵守相关的法律法规从而导致机构可能受到处罚、声誉受损的风险。

目前国家认可第三方支付的地位并执行监管,合规风险是国内第三方公司一个无法规避的风险,在企业发展过程中,需要密切关注央行的动向,减少合规带来的负面影响。

支付系统设计

支付系统设计

支付系统设计

4 财务对账及结算

对账目的:

为了保证交易记录的真实性、完整性、准确性。使得各方(支付渠道、自身、商户)之间的账务一致

支付记录对账:

(1)长款:本地未支付,支付渠道已支付。这主要是本地未正确接收到渠道下发的异步通知导致,一般处理是将本地状态修改为已支付,并做响应的后续处理,比如通知业务方等。

(2)短款:本地已支付,但是支付渠道中无记录;或者本地无记录,支付渠道有记录。在排除跨日因素外,这种情况非常少见,需要了解具体原因后做处理。

(3)金额不一致:本地已支付,支付渠道已支付,但是金额不同,这个需要人工核查。

退款记录对账:

(1)本地未退款,支付渠道已退款,则以支付渠道为准,修改本地为已退款状态,并触发后续处理流程。

(2)本地已退款、支付渠道已退款,但是金额不同,需要人工核查;

(3)本地已退款,但是支付渠道无记录;或者支付渠道有记录,但是本地没有。在排除跨日因素外, 这种情况非常少见,需要了解具体原因后做处理。

支付系统设计

支付系统设计

结算:

根据费率配置、账期配置,系统按照设定好的清结算规则自动将钱款结算给商户。

支付系统设计

5 监控与告警

支付系统设计

监控项目

数据源

系统监控

zabbix agent默认采集

Prometheus+grafana

JVM监控

JMX

自定义监控脚本,如结合jinfojstackjstatjmap

其他可视化监控工具

服务监控

NGINX日志、应用服务器访问日志

业务监控

应用日志

告警方式

描述

短信SMS

核心业务、机器存活状态的告警,成本较大

邮件

通用,PC端、手机端均可接收,注意:防止被邮件服务器拦截标记为垃圾邮件

飞信

飞信公众号:短信群发、消息推送

钉钉

添加机器人,调用api接口,每分钟限制20

原文始发于微信公众号(小新成长之路):支付系统设计

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/238671.html

(0)
小半的头像小半

相关推荐

发表回复

登录后才能评论
极客之音——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!