退款中心

把钱收进来是能力，把钱退出去也是本事

这两件事，一正一负，一左一右，看似背道而驰，却总在某个路口不期而遇

退款是一个极为常见的场景，无论是电商业务、家政业务还是外卖业务，都涉及到退款的情况。但需要明确的是，逆向业务是交易的反向流程，而逆向业务中并不必然包含“退款”这一环节，退款只是逆向业务中的一个重要组成部分。我们先从整个逆向业务的概念说起。

1.逆向业务概述

当用户不再需要商品或服务，或商品和服务存在瑕疵时，就会触发“逆向业务”。退单作为逆向业务的一种，可能涉及商品的退回、优惠券的退回以及款项的退回等多个环节。其中，款项的退回是支付的逆向操作，属于退款中心的业务范畴。

要设计一款优秀的“退款中心”，必须从全局视角深入理解“退款业务”，并在此基础上做好退款中心的系统架构设计。逆向业务的处理复杂度与原交易的情况密切相关，比如交易是否使用了优惠券、是否参与了活动、是否涉及多个商家等。同时，逆向业务的处理还受到原交易进程的影响，如支付成功后取消订单、已发货后取消订单、已确认收货后取消订单，以及是全单取消还是仅退部分商品等。具体情形如图1所示。

图片

图1 逆向业务的影响因素

从图1中可以看出，已经完成收货的订单在进行逆向处理时最为复杂，因为平台已经为商家完成了结算，这就涉及到了逆向清结算，使得整个逆向处理链条变得更长。同样地，部分退货的处理比全单退货更为复杂，而使用了优惠券或参与了活动的订单在逆向处理时也更为繁琐，因为需要对优惠进行逆向计算和处理。

此外，不同的订单类型也会影响逆向业务的处理。例如，虚拟商品的逆向处理一般比实物商品更为简单，而打包售卖的订单则比普通订单的处理更为复杂。

整个逆向业务涉及多个环节，就像正向交易一样，每个环节都需要有相应的处理流程。因此，逆向业务也构成了一个漫长的处理链条，具体如图2所示。

图片

图2 逆向业务全链条

逆向交易同样需要进行计价处理。正向计价是为了确定用户应支付的总金额及优惠的分摊情况，而逆向计价则是为了准确计算应退还给用户的金额，包括优惠券、活动优惠等的分摊。全单退款相对简单，基本上是正向交易的逆向操作；但如果是仅退个别商品，计价就会稍显复杂，因为会涉及到优惠的分摊问题。

支付核心中的退款模块或由单独的退款中心来负责处理渠道的退款业务。实现退款的方式有多种，因此需要一个退款产品矩阵来满足不同场景的需求。之所以称为退款产品矩阵，是因为原路退款并不总是可行。当原路退款无法实现时，从业务角度来看，退款又是必须进行的。因此，我们需要一系列退款产品来应对各种情况，常见的退款产品包括：

• 原路退：这是最直接的退款方式，一般在接入支付产品时，会附带退款接口，直接使用该接口即可完成退款。
• 退转付：如果原路退款超过了时效或原退款失败，可以通过退转付方式实现退款。此时需要判断退款时效及原退款失败的原因。
• 退回账户余额：根据实际需要，可以增加退款到用户在平台的虚拟账户中的方式，由用户自主发起提现。
• 其他退款方式：如通过线下支付现金的方式完成退款，或通过赠送卡券和商品服务的方式抵扣退款等。

只要双方能够达成协议，退款的方式就可以非常多样化。因此，在增加一种支付产品时，其退款业务需要兼容到上述的退款产品矩阵中，从而构建出其退款业务能力。

此外，逆向业务还涉及其他环节，如清结算需要撤回已经结算给商家的款项、给合伙人的分成、平台的佣金收入等。这部分内容在此不做详细介绍。

以上是对整个逆向业务从全局视角进行的业务解读。搞懂业务是设计好系统的前提。逆向业务涉及的系统环节众多，包括交易层、支付层、清结算层等；从协作机构来看，也涉及交易平台、支付机构、清算机构、银行等多个组织。

2.退款中心

退款作为原支付的逆向操作，通常被视为与支付处理属于同一维度的支付业务。在许多企业中，退款中心可能并未被独立成一个系统或产品部门，而是作为正向交易和支付的一个子模块来实现。在这种情况下，退款处理能力相对单一，主要以原路退款为主，付款退回为辅。

随着退款业务需求的不断增长，原支付处理模块中的退款能力已经难以满足业务的实际需求。因此，退款业务逐渐从支付处理中独立出来，形成了单独的“退款中心”系统或产品部门，这在以纯支付业务为主的支付机构中尤为常见，如图3所示。

图片

图3 退款处理子系统的位置

独立出来的退款中心，能够更贴近退款的业务特点进行架构设计，并抽象出更多样化的退款能力。除了原路退款外，还支持付款退回、线下退款、退回至余额等多种退款方式。同时，退款中心还提供接口、MQ（消息队列）、文件等多种退款请求方式，并支持单笔退款、批量退款等退款模式。

2.1.产品架构

从产品架构的角度来看，退款中心是围绕各退款产品为主线进行构建的。不同的退款产品在退款处理流程上存在差异。例如，原路退款是基于原支付，调用原支付通道提供的退款服务；而退转付则是基于原退款请求，调用可用的付款通道来处理退款业务，并且需要额外进行用户账户的采集等处理环节。退款中心产品架构如图4所示。

图片

图4 退款中心产品架构

退款中心可以分为退款接入层、退款处理引擎、退款产品层和退款渠道处理层。

退款接入层提供多种接入方式，如接口、MQ、文件上传和人工操作等。原路退款可以通过接口和MQ接入，同时内部运营人员也可以通过手动操作，如填写原支付单号来进行退款。接入层还提供多种退款方式，类似于收款收银台的支付方式，包括单笔退款、批量退款、POS退款等。每种退款方式都通过下层的退款产品来实现。例如，如果业务选择的退款类型是“补偿退款”，且该退款产品仅支持退回余额，那么退款就只能选择退回用户的平台余额账户。

退款处理引擎是退款处理的核心模块，负责处理和解析退款申请，校验退款信息的完整性和规范性，选择可用的退款方式，创建退款任务和退款申请记录等。

退款产品层用于并行建立各种退款处理模块，如原路退模块、退转付模块、网银退模块、退回余额模块和抵扣式退款等。每个退款模块都有独立的退款处理单据，与上层的退款单相关联，并拥有该退款产品独特的处理环节。例如，网银退款需要生成文件数据，并提供给内部人员下载。这些文件数据可以直接上传到网银渠道进行退款，无需人为进行二次加工，从而极大地提高退款处理效率。

退款渠道处理层主要为退款产品提供退款处理通道，负责退款处理的提交和退款结果的接收等，以完成最终的退款处理。

2.2.退款产品化

我们对支付产品都很熟悉，同样的概念也适用于退款产品。在设计一款退款产品时，应该关注以下几个维度，并在这些维度上给出定义和方案选择，如图5所示。

图片

图5 退款产品相关维度分析

• 退款产品维度：产品维度是最高层次的组合抽象，每一款退款产品都是一系列方案的组合。总的来说，只要平台、商家、用户等多方能够达成一致，退款方式的选择就非常灵活多样。
• 发起方式维度：退款发起方式多种多样，最常见的是通过接口发起，也可以通过MQ、文件上传或后台操作等方式发起。
• 退款类型维度：退款类型包括全额退款、部分退款以及按商品退款等。
• 原路退款时效维度：原路退款时效需考虑两个限制因素，一是平台提供给用户的退款售后时效；二是原支付渠道的退款时效，这取决于渠道的政策，如微信支付的1年退款时效。渠道的退款时效相对更重要，因为它决定了退款中心原路退款能够支撑的最长时效。平台的售后时效由业务层控制，而渠道的退款时效则是退款中心必须遵循的限制。
• 退款手续费处理维度：退款时，需考虑渠道是否退回手续费以及如何退回，这部分主要针对原路退款的手续费政策。

通过上述退款维度的组合，可以构建出非常丰富的退款能力。例如，图6所示的一种退款方式，就是多个维度组合而成的结果。

图片

图6 某退款产品组合属性

2.3.退款主处理流程

退款主流程始于退款请求的提交，终于退款中心向渠道提交退款申请并获得处理结果应答。之所以称之为主流程，是因为它剔除了退款渠道的差异化处理，以退款中心的标准处理流程为核心结构。主流程的框架如图7所示。

图片

图7 退款中心主处理流程架构

将上述退款流程架构进行细化，可以得到如图8所示的退款处理详细流程图。

图片

图8 退款处理流程

退款流程的起始是接收和解析退款请求。系统接收来自外部系统的退款申请，并解析请求报文或推送的退款文件。接着，系统会校验退款请求的完整性，检查参数是否符合规范，同时核实原支付单是否成功，是否存在退款记录，以及退款是否超过时效等一系列条件。

校验通过后，系统会生成退款主单据，记录退款的相关业务信息。基于这份退款单，系统会判断可用的退款方式，如原路退款、退转付、退回余额或网银退款等。因为不同的退款方式所使用的退款通道和需要补全的数据不同，所生成的退款处理记录也会有所差异。

如果退款涉及到商家结算问题，系统会先扣除商家结算账户余额，然后再发起退款。在此过程中，需要考虑是否涉及垫资问题。例如，当商家账户余额不足时，电商平台往往会执行平台垫资退款，而支付机构则通常不会为商家垫资，商家账户余额不足会直接导致退款失败。如图9所示，展示了这一处理流程。

图片

图9 账户余额不足时的不同退款处理

2.4.退款单据设计

退款单是退款中心中非常重要的单据，可以将其设计为三层结构。第一层为基础退款单，用于记录退款的基本业务信息和主要处理信息。第二层为退款方式差异化信息层，记录所选择的退款方式特有的退款信息，如原路退款时的相关信息、退转付的退款单据等。第三层为退款渠道请求记录层，记录向退款渠道发起的请求信息。这三层结构共同构成了退款中心最核心的单据体系。

退款单应详细记录退款的全部信息，包括单据号、最终执行的退款产品、退款通道信息、金额信息、时间信息等，如图10所示。

图片

图10 退款单的信息结构

2.5.退款通道属性与配置

原支付渠道通常在通道属性信息中配置相关信息，如“是否支持退款”、“退款时效”、“是否退手续费”以及“手续费率”等，如图11所示。这些信息在发起支付退款时会被使用到。

图片

图11 支付渠道的退款信息配置

2.6.全渠道的退款能力分析

不同平台接入的支付通道不同，因此退款政策也会有所差异。这就需要我们去分析接入的各类通道的退款能力。同时，不同的组织接入的通道所属机构也不同，例如，普通电商平台会接入第三方支付机构，第三方支付机构再接入网联或银联，而网联或银联则接入人民银行的大小额支付系统。这一关系如图12所示。

图片

图12 全渠道退款能力

如果你是一个普通的电商平台，那么你会更关注微信支付、支付宝支付、快捷支付等支付方式的退款能力建设。而如果你是一家支付机构，那么你接入的通道可能是网联或银联。通过网联或银联执行的支付，在退款时可以通过请求网联或银联提供的退款通道来执行退款。支付机构可以通过网联提供的退款申请报文来发起退款申请，如图13所示。

图片

图13 支付机构通过网联的退款处理

3.退转付

退款操作受退款时效限制，一旦超过此时效，原支付方式将不再支持通过原渠道进行退款。然而，在企业业务实践中，存在超出渠道退款时效的退款需求。平台退款协议中所约定的可退款时间，往往长于渠道的退款时效。以家政行业为例，有的客户一次性签约三年，其中包含的客户服务费在三年内均可申请退款。若客户在两年半时要求退还剩余半年的服务费，此时显然已超过了渠道的退款时效。但出于业务需求，企业仍需进行退款处理。

3.1.把退款转成付款

基于退款的本质是将资金退回给付款人，我们自然而然地想到了一个新思路——通过构建一个新的退款产品“退转付”。该产品的核心功能是将超过退款时效的退款申请，转变为付款操作，将资金支付给收款人。

然而，将退款转为付款首先面临的一个难题就是：钱应该付到哪里？原渠道退款具有一个天然优势，即它知道用户是用哪个账户付款的，因此可以直接退回该账户。但是，当我们需要主动付款给用户时，问题就变得复杂了，因为我们并不总是掌握用户的收款账户信息。因此，将退款业务转换为付款业务的第一步，就是“采集用户的收款账户信息”。

为了解决这个问题，可以采取两种方式：一是客服人工采集银行卡信息；二是在用户订单中心增加提示，告知用户已超过原路退款的时效，需要提交银行卡信息，平台将在3个工作日内将款项打入该卡中。这样，原来的难题就转化为了一个具体的、可落地的需求——采集用户收款信息。

那么，如何发起这个采集动作呢？当后台点击“退转付”按钮时，即可触发这一操作。这个动作的发起既可以是人为的，也可以是系统自动的。当退款失败的原因是“超过退款时效”，且用户退款协议约定仍可退款时，系统可自动触发这一退款路径，如图14所示。

图片

图14 退款转付款操作弹窗

当然，在发起采集时，可以先判断平台是否已保存用户的收款卡信息。如果存在，就可以选择相应的付款通道将款项支付出去。一旦触发转付款流程，就会在原退款订单的基础上生成一笔新的付款单，这笔付款单被明确标记为“退转付”，并与原退款单紧密关联。付款类型则被定义为“退款转付款”。

此外，还有一个至关重要的问题需要解决，那就是付款与原退款在信息上的强关联性，尤其是它们状态的联动。因为退款业务受到原支付单的严格限制，总退款金额不得超过原支付金额。而且，退转付付款的发起前提是原退款单因超时效而失败。如果退转付付款业务不受这些条件的约束，就可能导致资金损失，产生超额退款，如图15所示。

图片

图15 退款转付款业务的相互限制关系

基于上述控制关系，退款状态与付款状态之间应建立联动机制。当退转付操作进行时，其状态应更新原退款失败的退款单状态，从而促使原退款单状态开始新的状态流转。这一流转关系如图16所示。

图片

图16 退转付状态与退款单状态联动关系

最后需要明确的是，退转付的付款操作应当归类于“退款”模块，或者更准确地说，是退款业务的一部分，而非单纯的付款业务。为了更精确地描述这一功能，我们可以称之为“基于付款功能的退款产品”。

3.2.退转付流程分析

首先确定全局流程，整个流程图由三部分组成。左边是退款业务的发起方，右边是退款渠道，中间则是支付核心系统的退款处理流程，如图17所示。

图片

图17 退转付流程组成

接下来确定退款流程的分支。退款处理流程部分同样包含三个子流程：超过退款时效的退款处理、退款主流程以及正常退款处理。其中，两个子流程（即超过退款时效的退款处理和正常退款处理）之间有一条通路，通过判断退款失败是否超时效来连接，如图18所示。

图片

图18 退转付的流程图简化结构

最后，对流程图进行进一步细化。基于上述的设计框架，通过详细展开各个部分，可以得到完整的流程图，如图19所示。

图片

图19 退转付详细流程图

• 退款发起：业务系统发起退款申请，当用户取消订单、申请退货或进行售后等一系列业务操作时，会产生退款业务。退款请求随后被提交至支付核心系统。
• 退款主流程：支付核心系统接收到退款请求后，在退款模块中创建退款单，并判断退款是否已超时效。这一判断是分化出两个子流程的关键节点。
• 正常退款处理子流程：若退款未超时效，则判定为正常退款，直接通过原付款通道申请退款。需特别注意的是，对于退款失败的情况，需再次判断是否因超时效所致，从而可能有一条从正常退款流程转入退转付流程的通路。
• 超过退款时效的退转付处理子流程：若最初判断退款已超时效，则创建退转付订单。完成收款账号信息获取后，发起付款申请。
• 退款结果通知：对于成功的退款或付款结果，及时通知业务方。
• 失败业务处理：对于失败的付款或退款，根据失败原因进行相应处理。若是可调整的问题，则调整后继续发起；若不可调整，则将失败结果通知业务方。例如，若退转付失败原因为收款账户信息有误，则返回用户进行修改后重新发起；若付款账户余额不足，则进行充值后再次发起。