在前面文章里，作者从逆向业务说起，详细分析了退款的场景。这篇文章里，作者接着阐述如何设计退款中心。一起来看看本文的梳理。
在文章《全局视角看，“退款中心”的设计》中从业务层面详细分析了退款的场景，本文将解析如何设计一款能力强劲的退款中心。
退款作为原支付的逆向，我们一般认为退款处理和支付处理属于同一个维度的支付业务。
可能很多企业不会将退款中心独立成一个系统，或者说一个独立的产品部门，在这种情况下，退款往往作为正向交易、正向支付的一个子模块实现，此时的退款处理能力也比较单一，以原路退款为主，付款退回为辅助。
随着对退款业务处理的要求增加，退款处理模型种类的增加，耦合在原支付处理模块不能很好的满足业务对退款的诉求。
逐渐的退款业务独立出“退款中心”单独的系统或者产品部门，这在以纯支付业务为主的支付机构尤为常见。
独立出来的退款中心，更能够按照退款的业务特点进行架构的设计，以及抽象出更加丰富的退款能力。
例如除了原路退以外，还可以实现付款退、线下退、退回余额等方式，以及可以提供接口、MQ、文件等的退款请求方式，并可以实现单笔退款、批量付款等退款模式。
从产品架构上，退款中心以各退款产品为主线进行构建，每一种退款产品在退款处理流程上存在差异。
例如原路退和退转付，前者是基于原支付调用原支付通道提供的退款服务，而后者是需要基于原退款调用可用付款通道处理退款业务，并且需要进行用户账户的采集等处理环节。
从上图的架构看得出来，退款中心可以分退款接入层、退款主处理引擎、各退款产品的处理模块、退款提交和接收层，其中：
（1）退款接入层
提供多种接入方式，如接口、MQ、文件上传、人工操作等，原路退可以通过接口和MQ接入，同时也会给内部运营人员提供手动操作原支付退回的能力，比如通过填写原支付单号进行退款操作。
接入层还会提供多种退款方式，就像收款收银台的支付方式一样，如单笔退款、批量退款、POS退款等等。
每一种退款方式其实依赖下层的退款产品实现，例如补偿退款仅仅支持退回余额的退款产品，这时候如果业务选择的退款种类是“补偿退款”，那么就只能选择退回用户的平台余额账户中。
（2）退款处理引擎
处理和解析退款申请，校验退款信息是否完整规范，选择可用的退款方式，创建退款任务，创建退款申请记录等一系列的退款处理。
（3）退款产品层
该层将并行建立各种退款处理模块，如原路退模块、退转付模块、网银退模块、退回余额模块、抵扣式退款等。
每一个退款模块都有独立的退款处理单据，关联上层的退款单，有该退款产品独特的处理环节。
如网银退款需要生成文件数据，并提供给内部人员下载，这一步可以按照网银渠道生成直接可用的文件数据，下载下来以后可以直接上传到网银渠道进行退款，无需人为进行二次加工，这将极大地提高退款处理效率。
（4）退款渠道处理
为退款产品提供退款处理通道，以及退款处理的提交，退款结果的接收等，完成最终的退款处理。
我们对支付产品都不陌生，同样的概念适合退款产品，关于退款产品我们应该关注以下几个维度，在设计一款退款产品时，可以在这几个维度给于定义和方案的选择。
（1）退款产品维度
产品维度是最高的一个组合抽象，每一款产品都是一系列方案的组合，比较常见的产品如下：
总体来说，只要平台、商家、用户等多方能够达成一致，退款方式的可选择性非常大。
（2）发起方式维度
最常见的是接口发起，也可以通过MQ发起。或者通过文件上传进行退款的发起、后台操作。
（3）退款类型
如全额退、部分退、按商品退等。
（4）原路退款时效
这部分要有2个限制维度，一个是平台提供给用户的退款售后时效，例如7天内可退，另一个是原支付渠道的退款时效，这部分要依赖于渠道的政策，如微信的1年退款时效。
渠道的退款时效相对更重要，平台的售后时效由业务层控制，而渠道的退款时效是退款中心原路退能够支撑的最长时效周期。
更长的业务售后承诺需要更强的渠道退款时效，二者是需求和满足的关系。
（5）退款手续费处理
退款时渠道是否退回手续费，如何退，这部分主要针对原路退的手续费政策。
因此，通过上图退款方式的模型，可以组合出非常丰富的退款能力，例如下面的退款方式。
退款主流程是从退款请求提交进来开始到退款中心提交渠道并获得退款处理结果应答结束的退款全流程。
之所以说是主流程，还是要剔除退款渠道的差异化处理，以标准的退款中心主处理为结构，主流程框架如下图所示：
将上述的退款框架进行细化，可以得到如下的退款处理流程：
退款请求的接收和解析，接收来自外部系统的退款申请，并解析请求的报文或者推送过来的退款文件。
校验退款请求是否完整，参数是否符合规范，以及判断原支付单是否成功，是否有存在的退款记录，退款是否超过时效等一系列的判断。
然后生成退款主单据，记录退款的业务信息。
基于退款单，判断可用的退款方式，是原路退、退转付、退回余额还是网银退款，因为不同的退款方式可用的退款通道和需要补全的数据不一样，以及生成的该通道下的退款处理记录也不一样。
如果退款涉及到了商家结算问题，此时需要先扣除商家结算账户余额，然后再发起退款，这里要考虑是否涉及到垫资问题，例如商家账户余额不足是否允许继续退款。
电商平台往往会执行平台垫资退款，而如果是支付机构往往不会为商家垫资，商家账户余额不足会直接退款失败。
如上图所示，电商平台和支付机构在处理退款时，对商户的账户余额是否充足的处理策略会存在差异，支付机构往往不会为商户垫资退款，而电商平台往往会垫资退款给用户，因为用户的体验更加受到重视。
退款中心一个非常重要的单据就是退款单，我们可以将退款单设计成3层，第一层是基础退款单，记录退款的业务信息以及退款处理的主要信息。
第2层是选择的退款方式的差异化退款信息，例如原路退时的退款信息、退转付的退款单据等。
第3层是请求退款渠道的请求记录单据，以此形成退款中心最核心的单据结构。
（1）基础退款单
如下图所示，记录最完整的退款信息，包括全部单据号，最终执行的退款产品，退款通道信息，金额信息，时间信息等。
（2）原路退款单
执行原路退回的补充记录部分，可以更新到基础单据中，也可以执行单据的按照退款方式设定的子单据中。
（3）退转付单
退转付是在原路退超过退款时效，或者就是无法退款成功时选择的退款方式，建立在原退款单的基础上。
（4）网银退款单
网银退款是一种线下退款方式，线上的退款处理无法实现时，或者某些特殊的支付业务退款，没有接入通道的线上退款接口，而是通过线下登录网银执行退款处理的退款方式。
此时，系统需要将线上的退款请求记录生成网银退款批次，并生成网银退款文件提供给内部人员下载，人工登录网银操作执行退款。
网银退款成功以后需要返回退款中心，进行退款结果的复核和确认。
（4）退回余额单
将要退的金额，直接退回用户的账户余额，这部分要执行请求账户中心进行入账，如果用户没有余额账户时，需要进行开户的申请。
（5）资产抵扣单
这是最后的兜底手段，将要退款的金额通过其他资产进行抵扣，例如发给用户优惠券，一次商品服务等等方式。
该种方式需要优先获得用户的确认，对该退款方案无异议以后在线上进行确认，然后平台进行执行。
原支付渠道，往往在通道属性信息中配置“是否支持退款、退款时效、是否退手续费、手续费率”等信息。
不同平台接入的通道不同，那么退款政策也不同，就需要去分析接入的各类通道的退款能力。
当然，不同的组织接入的通道所属组织也不同，普通电商平台接入三方支付机构，三方支付机构接入网联银联，网联银联接入人行大小额系统。
那么他们所面临的渠道的退款能力和退款政策是不同的，这一点要在退款中心的设计上体现出来。
（1）三方支付的退款能力
如果你是一个普通的电商平台，那么更多关注的是微信支付、支付宝支付、快捷支付的退款能力建设。
微信退款能力：
微信原路退款是绝大部分电商平台都需要构建的能力，从微信开放平台可以调研到微信的退款处理政策，其退款时效、退款类型等等。
下图是退款的接口说明。
下图是微信退款的部分政策，包含产品层的也包含技术层的内容。
支付宝退款能力：
支付宝退款关于退款时效和手续费的政策。
支付宝退款相关接口：
快捷支付退款：
假如你接入了一款快捷支付产品，那么其原路退的退款能力建设可以看对应机构提供的退款能力，如下图是易宝支付快捷支付的退款能力。
根据其API的传参和处理要求，设计退款中心的退款单据和处理流程。
（2）网联和银联等清算机构的退款能力
如果你是一家支付机构，那么通道接入的是网联或者银联，通过网联或者银联执行的支付。
在退款时可以通过请求网联银联提供的退款通道执行退款。
支付机构通过网联提供的退款申请报文发起退款申请。
这里就不再详细列举报文参数要求了，在网联的结算文件中或者清算文件中可以看到退款的数据。
（3）人行的退款类业务类型和报文
网联和银联怎么处理支付机构的退款业务呢？当然是通过人行最终实现退款资金的清算，这部分就不再详细介绍了，因为距离大家比较远，感兴趣的朋友可以自己去找一下相关资料。
专栏作家
陈天宇宙，微信公众号：陈天宇宙，人人都是产品经理专栏作家。多平台支付领域专栏作者，十年资深产品；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。