无锡市无锡市住房和城乡建设局网站,网站开发的配置过程,公司活动策划方案怎么做,在家有电脑怎么做网站本文主要是从支付架构、支付流程分析、支付核心逻辑、支付基础服务、支付安全五个方面来详细讲述支付系统架构 #xff08;1#xff09;、架构的定义#xff1a;架构一定是基于业务功能来展开的#xff0c;主要是制定技术规范、框架#xff0c;指导系统落地#xff1b;好…本文主要是从支付架构、支付流程分析、支付核心逻辑、支付基础服务、支付安全五个方面来详细讲述支付系统架构 1、架构的定义架构一定是基于业务功能来展开的主要是制定技术规范、框架指导系统落地好的架构是需要不断演变和进化而来的。 2、架构需要关注的基础核心点主要是安全、稳定、可扩展。 3、构建架构时需要关注的点目标客户是谁、主要场景有哪些、流程是怎样的、模型、职责有哪些、边界在哪里以及设计。其中比较难以理解的点是困难及模型这两块。 4、架构与业务需求的关系架构的产生来自于业务需求业务需求进一步抽象形成架构架构指导后续研发研发最终成果解决业务需求的问题。整体是一个正向循环的关系。 一、支付架构 二、支付流程分析 第一步用户选择支付渠道进入商户客户端 第二步商户客户端发送支付要素到商户服务端 第三步商户服务端发起支付请求到渠道个别渠道如支付宝是不需要此步骤 第四步渠道返回支付凭证到商户服务端 第五步商户服务端返回支付凭证到商户客户端 第六步用户调用支付宝控件完成支付。 第七步一般渠道是采用异步通知方法来通知商户但是有些企业是在第六步支付完成之后在C端会同步通知支付成功。如果以此结果来判断支付是否成功其实是不严谨会出问题的应当调用渠道的支付接口来进行核查然后以渠道返回的结果为准。 在日常工作中许多企业在选择第四方服务商或者渠道的时候会着重关注「并发」这个点认为并发量需要达到上万级才可以满足日常需求但实际上这个量级非常大其实并没有必要的。 若直接对接渠道可能会遇到的问题 1、接口文档升级、变更能及时得到通知 2、有些业务没有异步通知 3、同一业务在不同渠道表现不一样 4、各种渠道的各自异常。 商户的要求 1、清晰的 API 、SDK 文档 2、安全 3、所有应用接口统一标准的异步通知 4、保证出口 IP 稳定安全。 在系统架构设计时需要注意的一些要点 1、提供规范的 API、SDK 2、安全通讯安全、数据安全 3、稳定 4、异步通知统一 5、各渠道的异常 6、及时了解渠道接口调整。 三、支付核心逻辑 这里讲一下支付成功之后我们会把订单信息同步到财务系统在账务系统里我们设计了诸如转账、汇款等功能在前期设计时会设计好账务的生成规则例如一笔支付的请求会生成多笔账务对其字段进行区分这样方便管理和维护。
3.1、支付网关 此处特指API网关支付网关的功能 限流最好不要放到业务流程中做会影响用户的体验。
支付网关的内容 1、唯一的请求入口 2、统一的身份认证、签名、加解密、流控 3、API 调用计费 4、API 的监控、报警分析 5、API 发布管理 6、熔断 7、API 聚合 8、协议转换 上述内容除了必要意外其他不放在业务层做也是为了更好的用户体验。
3.2、支付逻辑 主要是根据请求的参数进行静态检验和业务逻辑校验避免系统异常。 1、适配渠道的参数校验长度、类型、格式 2、订单的支付状态是否支付 3、订单的有效期等等。 要点 一般商户是不需要做支付路由大部分都是指定了最终的某个支付渠道。 但也有些没有指定了某个最终的渠道比如银行卡的支付可以选择哪个第三方支付来完成支付还有微信线上线下的封装这个时候就涉及到支付路由规则配置。
支付路由规则配置 1、费率单笔费率、总额费率、阶梯费率 2、营销活动固定时间单笔优惠、单笔满减、单笔这款、直接补贴 3、额度限制单笔额度、时间范围内总额度 4、服务指标失败率、平均响应时间、异常率、TPS 5、特殊配置特殊要求比如某渠道能快速结算。 3.3、支付风控 要点梳理清楚业务风险分析风险原因制定风险防范规则。 1数据来源
内部数据 1、用商户信息 2、交易数据 3、账户数据 4、黑名单 5、设备、位置信息 6、日志数据 外部数据 1、第三方购买 2、央行征信 3、芝麻信用 4、合作数据 2风控流程
事前 1、入网审核 2、风险评估 3、单笔限额设置 4、单日限额设置 5、频次设置 事中 1、实时分析 2、多维度判断 3、拒绝 4、拦截 – 进一步验证– 人工介入 5、延迟操作例如用户大额提现需要时间段进行复核 事后 1、数据分析 2、巡查、警告 3、降低评级 4、升级防范措施 5、逻辑完善 6、反馈至事前、事中规则中 3.4、账务系统 1、账务生成 2、内部对账 3、原始账单下载 4、生成标准账单 5、对账 6、差错处理 账务生成后首先进行内部对账后进行原始账单下载再生成标准账单进行对账之后进行差错处理。
内部流程如图 订阅交易信息 根据交易事件查询生成账务的规则。 交易事件支付、退款、转账等等。 1、根据规则生成账务明细 2、将账务明细落地。 对账流程 内部对账 1、保证账务和交易信息配对 2、一条交易信息有多条账务信息 渠道账单下载 1、下载 2、账单标准化对账字段统一 3、落地标准化账单。 对账 1、账务和标准账单对账双向对账 2、差错处理。 对账部分 1、获取核对文件 2、以账务系统为准来逐笔比对以某个字段为准进行比对 3、数据一致标记成功数据不一致标记差错。 反向操作 1、以渠道账单为准来逐笔比对 2、数据一致标记成功数据不一致标记差错。 账单下载 这里提一句在做异常处理这部分工作时有的研发朋友写代码时遇到过类似的问题例如订单在周末下单但账单周一才能查询等到周一时发现查询不到选择立即重试 X 分钟后重试就结束了。 这样是不行的因为银行有的是 8 点之后可以查询到有的是 9 点之后所以要选择递增时间重试然后标记人工处理。
3.5、差错处理 1、本地丢失渠道账单的数据未在账务中查找到。 2、渠道丢失账务中的数据未在渠道账单中查找到。 3、数据差错账务与渠道某些对账字段未能对上。 此处需要注意的是针对差错都需要向渠道查询每笔订单信息再次确认同时有些渠道的交易成功时间本来就是有错误的。一般来说是件不会差错很大一般出现在跨日交易中例如当天交易无账单先标记为差错第二天再改正。
四、支付基础服务 1、Webhook 2、公共推送服务 3、主动查询 4、补偿 5、链路监控 4.1、Webhook 4.2、公共推送服务 异步延时调用 场景 1、订单创建成功的时候会向服务推送主动查询信息如果订单支付成功会通知服务取消后续的主动查询否则在过期时间点向渠道主动查询订单是否支付目的是避免渠道异步通知服务的异常。 2、退款创建成功的时候会向服务推送主动查询信息该服务会在一定的时间范围内多次查询渠道直到有明确的结果返回有些渠道没有异步通知。 3、转账也是类似的逻辑但某些渠道只提供重试的功能要注意幂等性。 补偿 1、协调保证各模块间数据的一致性 2、一般会跟重试、回滚、兜底来协调使用 3、使用条件系统异常、业务异常 4、补偿失败报警人工干预。 4.3、链路监控 展示信息应用、URL、调用方、调用时间、调用次数、调用失败次数、本地平均耗时、总平均耗时、调用失败平均耗时 、错误率、依赖度。
关注Cache、SQL、HTTP、TCP
基本信息 依赖度 五、支付安全
5.1、数据安全 1、防窃听、防越权防抵赖、防破坏、防篡改、防重放、防泄漏。 2、使用范围网络、系统、应用、业务等。 5.2、数据安全要点 1、加密通讯防窃听 2、双向签名防抵赖、防篡改 3、敏感数据加密存储防泄漏 4、密钥管理通过认证接口获取只允许加载到内存不允许直接写入配置文件 5、权限控制防越权-非法访问 6、数据的完整性放篡改- 数据被恶意修改、非法篡改 5.3、其他 1、内部接口认证。 2、避免内部代码未经审核发布到托管平台 3、数据异常分析。 4、安全机构合作。 5.4、注意点 1、使用 HTTPS 加密传输 2、传输的数据使用签名 3、提交的数据是符合规则并且是不存在或者是未支付的 4、支付成功以服务端异步通知为准。
