资损资损防控的系统规范-收单类服务设计
Posted 小明java问道之路
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了资损资损防控的系统规范-收单类服务设计相关的知识，希望对你有一定的参考价值。
📫 作者简介：小明java问道之路，专注于研究 Java/ Liunx内核/ C++及汇编/计算机底层原理/源码，就职于大型金融公司后端高级工程师，擅长交易领域的高安全/可用/并发/性能的架构设计与演进、系统优化与稳定性建设。
📫 热衷分享，喜欢原创~ 关注我会给你带来一些不一样的认知和成长。
🏆 InfoQ签约作者、CSDN专家博主/后端领域优质创作者/内容合伙人、阿里云专家/签约博主、51CTO专家 🏆
🔥 如果此文还不错的话，还请👍关注 、点赞 、收藏三连支持👍一下博主~
本文目录
7、对外服务接口规范需要遵从最新的“文档规范说明.docx”
本文导读
大型互联网金融公司是如何保证资金万无一失的？本文从系统架构层面整体的资损防控的规范，详细介绍收单类服务资损防控需要的注意事项。
一、 资损防控系统设计资损防控规范
从系统架构层面整体来看，支付公司的系统可以抽象为如下结构:
一、对外部商户提供收单服务类的系统
二、连通支付公司与各金融渠道的网关类系统
三、支付公司的内部业务处理系统
四、消息、调度等中间件系统
五、数据库、缓存等存储平台
从系统架构与业务架构上来讲，各个结构连接的地方最容易出现资损。因此我们将从接口服务层面与系统设计层面对资损进行分析并总结相关规范。
二、服务接口类设计概述
按照上述系统抽象架构所示，支付公司接口服务可以分为三类服务：
1、渠道网关类服务
2、收单类服务
3、内部系统接口服务结果。
下面按照各类服务风险又高到底进行分类介绍。
三、收单类服务常见资损风险
1、服务描述不清楚、不规范
对于商户接口类服务，服务接口、数据交互描述不清楚或不规范，导致商户错用接口，进而导致商户资损。
2、金额参数单位乱用
在收单服务接口的所有与出入参数里，金额单位的约定是极易出错的地方，分、元、忽的使用一定要明确，否则会导致金额扩大或缩小100、1000000倍。
3、幂等参数不明确、不合理
收单服务的幂等性控制参数一定要明确指出，否则容易造成商户。如接口调用时，对同一笔业务进行多次服务调用，导致业务重复处理，造成资损；支付公司结果通知（同步或异步）时，商户没有幂等处理，对同一笔也处理多次导致资损。
4、接口参数长度或类型不明确
收单服务对外出入参数中，各参数的类型长度约定不明确，将引发数据库超长、数据转换与截断等问题，严重时将导致资损。
5、请求参数合法性校验不严密或未校验
对外提供的接口，没有对参数进行合法性校验或缺乏明确的校验规则。如收到外部请求，传入未签约的支付方式，没有签订手续费费率，可能导致漏收手续费。
6、接口的错误码或返回码定义不明确
错误码、返回码对于异常、超时、幂等等结果不明确，会导致商户重复针对同一笔业务进行多次调用或将可以判定为成功的业务而判断为失败。
另外，外部响应结果如果包含多层状态（通讯状态、业务状态等），需要明确业务状态是由哪个状态或者哪几个状态组合决定，判断错误会导致严重资损。
四、收单服务接口设计规范
1、接口描述规范
接口服务能力描述简洁明了，对于服务能力、功能、数据交互有一个清晰的描述。关键的资金处理业务需要由流程图表达。
2、金额单位规范 金额参数必须以“元”为单位
金额单位规范 金额参数必须以“元”为单位，同时精度要求小数点后两位。禁止以分或厘为单位（线下收单行业规范可以以分为单位）。
3、幂等控制
幂等控制需要约定好幂等控制的参数是哪个参数（如外部交易单号）或哪些参数（如交易日期+交易流水号）组成，对于幂等控制的方式双方需要达成一致。
4、收单服务的参数类型与长度必须明确且设计合理
任何一个参数都要明确其类型与数据长度范围，该范围需要确保在个体系内有效。 另外，对于关键的控制类参数（如幂等控制的参数）需要设计为字符串，减少不必要的转换。
5、对于商户的接口权限与接口参数做好权限控制与合法性校验
对于商户的接口权限与接口参数做好权限控制与合法性校验。
6、对于错误码或返回码需要清晰定义
返回的结果中需要明确成功失败状态的含义:业务成功，操作成功，双成功。明确错误码的含义，准确识别出成功、失败、处理中、超时处理、重复处理、不做任何等重要处理结果;对于各种异常处理(如超时重发等)，不能缺少。
7、对外服务接口规范需要遵从最新的“文档规范说明.docx”
对外服务接口规范需要遵从最新的“文档规范说明.docx”。
总结
大型互联网金融公司是如何保证资金万无一失的？本文从系统架构层面整体的资损防控的规范，详细介绍收单类服务资损防控需要的注意事项。
资损业务产品分析资损防控规范
📫作者简介：小明java问道之路，专注于研究 Java/ Liunx内核/ C++及汇编/计算机底层原理/源码，就职于大型金融公司后端高级工程师，擅长交易领域的高安全/可用/并发/性能的架构设计与演进、系统优化与稳定性建设。
📫 热衷分享，喜欢原创~ 关注我会给你带来一些不一样的认知和成长。
🏆 InfoQ签约作者、CSDN专家博主/后端领域优质创作者/内容合伙人、阿里云专家/签约博主、51CTO专家 🏆
🔥如果此文还不错的话，还请👍关注、点赞、收藏三连支持👍一下博主~
本文目录
前言
业务产品分析资损防控规范21业务产品分析支付公司的大部分业务都涉及到资金 的流转，对于每一笔的资金业务，往往既涉及信息流的变化，也会涉及资金流的变化。在我们做业务的需求分析设计的时候，如果和业务方未能理解一致或者分析不全，将会从业务源头上产生资损风险
一、 资损防控系统设计资损防控规范
从系统架构层面整体来看，支付公司的系统可以抽象为如下结构:
一、对外部商户提供收单服务类的系统
二、连通支付公司与各金融渠道的网关类系统
三、支付公司的内部业务处理系统
四、消息、调度等中间件系统
五、数据库、缓存等存储平台
从系统架构与业务架构上来讲，各个结构连接的地方最容易出现资损。因此我们将从接口服务层面与系统设计层面对资损进行分析并总结相关规范。
二、常见业务产品分析资损风险
1、资金流、信息流、业务流等和理解和业务产品方不一致。
2、只分析了信息流的处理，遗漏了资金的处理，或遗漏了某些阶段的资金处理。比如基金类商户的出款类交易迁移的时候没有考虑商户不需要直正的出款。
3、资金需求中，对资金结算模式等理解不一致。比如退款成功的理解不一致；是退到商户户还是退到个人户的理解不一致。
4、业务产品设计的时候，部分支付产品充退接口设计不完整，尤其资金流设计不完整。执行充退逻辑时异常考虑不完备会有资损。
5、系统业务设计未能遵守先借记后贷记的原则。
6、业务缺少资金平衡检查。
7、正反交易资金流不一致容易资损。
8、内部户的使用不当。比如挂销机制不合理。
9、内部作业人员操作界面未设置合理的限制条件。如营销平台的卡券发放等。
三、常见业务产品分析资损防控点
1、需求分析中对信息流、资金流的分析要完整全面。业务需求中要包括完整的信息流和资金流（业务系统还需要包括相关的物流等业务流），不但要包括正向的完整描述，也要包括反向的描述；不但包括正常情况的描述也要包括异常情况下的处理描述。
2、业务迁移过程中，要梳理出新旧业务全面的信息、资金流流向。验证过程中，要核对业务信息、支付信息、渠道信息、银行账户流水信息等。
3、新支付产品需求分析的时候，要对支付产品的信息流和资金流做完整分析。有其是反向资金流。尤其是内部业务系统包装的渠道，尤其注意冲退逻辑的实现是否完备。
4、资金结算模式的理解。需求分析过程中，要与业务方梳理出清晰完整的资金结算模式形成双方认可的资金结算的流向图，流转到具体的资金账户。
5、业务设计的时候遵从先借记后贷记原则。
6、要保证正反交易的资金流向一致。对于正方交易资金流向不一致的场景（如冲退转代发部分支付产品冲退退余额），设计与系分的时候要着重评审，并重点测试验证。
7、收单、渠道、支付等系统都需要设计相关的资金平衡检查。如渠道冲退的金额不能大于原交易流水的金额、收单商户退款的金额不能大于可退金额等。
8、内部账户的使用。必须由业务方和运营财务人员沟通后申请，技术人员不可自行配制；要有挂销机制；要有相关的业务和技术核对机制。
9、内部作业系统设置合理的业务条件限制。不允许有无限制条件的输入输出。
如OMS查询可以限制为一个月；营销平台的卡券发放一个人可以设置上限1000个等
四、业务参数调整资损风险
1、常见的业务参数调整资损风险
1、商户参数调整。业务自行调整合同业务参数影响其他收单商户。
2、渠道参数调整。
3、结算规则调整。
4、通过数据修订等方式进行业务参数调整。
2、常见业务参数调整资损防控
1、可以验证的业务参数，需要在测试环境等验证过进行调整。
2、风险较大的业务参数调整的时候，可以通过限流等措施在产线上逐步开放。
3、系统在设计的时候，要避免可能引起业务作业人员误解的配置，避免商户间的串用、滥用、误用。
4、业务类参数的调整要平台化，不要通过数据修改等方式进行参数调整。
总结
业务产品分析资损防控规范21业务产品分析支付公司的大部分业务都涉及到资金 的流转，对于每一笔的资金业务，往往既涉及信息流的变化，也会涉及资金流的变化。在我们做业务的需求分析设计的时候，如果和业务方未能理解一致或者分析不全，将会从业务源头上产生资损风险。
以上是关于资损资损防控的系统规范-收单类服务设计的主要内容，如果未能解决你的问题，请参考以下文章