作者简介:小明java问道之路,专注于研究 Java/ Liunx内核/ C++及汇编/计算机底层原理/源码,就职于大型金融公司后端高级工程师,擅长交易领域的高安全/可用/并发/性能的架构设计与演进、系统优化与稳定性建设。
热衷分享,喜欢原创~ 关注我会给你带来一些不一样的认知和成长。
InfoQ签约作者、CSDN专家博主/后端领域优质创作者/内容合伙人、阿里云专家/签约博主、51CTO专家
如果此文还不错的话,还请关注 、点赞 、收藏三连支持一下博主~
本文导读
一、 资损防控系统设计资损防控规范
二、服务接口类设计概述
三、收单类服务常见资损风险
1、服务描述不清楚、不规范
2、金额参数单位乱用
3、幂等参数不明确、不合理
4、接口参数长度或类型不明确
5、请求参数合法性校验不严密或未校验
6、接口的错误码或返回码定义不明确
四、收单服务接口设计规范
1、接口描述规范
2、金额单位规范 金额参数必须以“元”为单位
3、幂等控制
4、收单服务的参数类型与长度必须明确且设计合理
5、对于商户的接口权限与接口参数做好权限控制与合法性校验
6、对于错误码或返回码需要清晰定义
7、对外服务接口规范需要遵从最新的“文档规范说明.docx”
总结
大型互联网金融公司是如何保证资金万无一失的?本文从系统架构层面整体的资损防控的规范,详细介绍收单类服务资损防控需要的注意事项。
从系统架构层面整体来看,支付公司的系统可以抽象为如下结构:
一、对外部商户提供收单服务类的系统
二、连通支付公司与各金融渠道的网关类系统
三、支付公司的内部业务处理系统
四、消息、调度等中间件系统
五、数据库、缓存等存储平台
从系统架构与业务架构上来讲,各个结构连接的地方最容易出现资损。因此我们将从接口服务层面与系统设计层面对资损进行分析并总结相关规范。
按照上述系统抽象架构所示,支付公司接口服务可以分为三类服务:
1、渠道网关类服务
2、收单类服务
3、内部系统接口服务结果。
下面按照各类服务风险又高到底进行分类介绍。
对于商户接口类服务,服务接口、数据交互描述不清楚或不规范,导致商户错用接口,进而导致商户资损。
在收单服务接口的所有与出入参数里,金额单位的约定是极易出错的地方,分、元、忽的使用一定要明确,否则会导致金额扩大或缩小100、1000000倍。
收单服务的幂等性控制参数一定要明确指出,否则容易造成商户。如接口调用时,对同一笔业务进行多次服务调用,导致业务重复处理,造成资损;支付公司结果通知(同步或异步)时,商户没有幂等处理,对同一笔也处理多次导致资损。
收单服务对外出入参数中,各参数的类型长度约定不明确,将引发数据库超长、数据转换与截断等问题,严重时将导致资损。
对外提供的接口,没有对参数进行合法性校验或缺乏明确的校验规则。如收到外部请求,传入未签约的支付方式,没有签订手续费费率,可能导致漏收手续费。
错误码、返回码对于异常、超时、幂等等结果不明确,会导致商户重复针对同一笔业务进行多次调用或将可以判定为成功的业务而判断为失败。
另外,外部响应结果如果包含多层状态(通讯状态、业务状态等),需要明确业务状态是由哪个状态或者哪几个状态组合决定,判断错误会导致严重资损。
接口服务能力描述简洁明了,对于服务能力、功能、数据交互有一个清晰的描述。关键的资金处理业务需要由流程图表达。
金额单位规范 金额参数必须以“元”为单位,同时精度要求小数点后两位。禁止以分或厘为单位(线下收单行业规范可以以分为单位)。
幂等控制需要约定好幂等控制的参数是哪个参数(如外部交易单号)或哪些参数(如交易日期+交易流水号)组成,对于幂等控制的方式双方需要达成一致。
任何一个参数都要明确其类型与数据长度范围,该范围需要确保在个体系内有效。 另外,对于关键的控制类参数(如幂等控制的参数)需要设计为字符串,减少不必要的转换。
对于商户的接口权限与接口参数做好权限控制与合法性校验。
返回的结果中需要明确成功失败状态的含义:业务成功,操作成功,双成功。明确错误码的含义,准确识别出成功、失败、处理中、超时处理、重复处理、不做任何等重要处理结果;对于各种异常处理(如超时重发等),不能缺少。
对外服务接口规范需要遵从最新的“文档规范说明.docx”。
大型互联网金融公司是如何保证资金万无一失的?本文从系统架构层面整体的资损防控的规范,详细介绍收单类服务资损防控需要的注意事项。