干货分享：退款系统，看这篇就够了

⼲货分享：退款系统，看这篇就够了

退款，是⼀个易造成的业务产品。原因是商户对于退款的要求务必退款成功、⾼效、快，⽽且⼜得很好地⽀撑业

负体验

务，否则就容易招来吐槽。

退款，⼀个看似简单，但充满复杂性的产品。

要想做好退款系统，我们必须深⼊的了解业务发展趋势，将客户诉求与现状业务结合起来；同时还需站在服务客户的⾓度，尽可能让客户降低操

作，这样才有希望将退款系统打造好。

因此，笔者根据在⽀付公司独⾃负责退款系统的经验，让⼤家避免踩坑，向⼤家分享如何从0-1打造厉害的退款系统。

本⽂将从需求背景、需求分析，以及产品设计三个层⾯来阐述退款系统。

⼀、需求背景

在我接⼿退款系统之前，公司的退款系统是这样的：

1. 只⽀持订单全额退款；不⽀持部分退款；

2. 退款不退回交易⼿续费;

3. 退款请求的成功率超级低，不超过50%；

4. 上游通道不给⼒，内部系统也不给⼒，经常⽹络波动就退款失败，或者当⽇交易不⾜就退款失败，只能打回给商家，让其⼆次发起。

在以前允许直连模式的情况下，通道会有以下情况：

1）不提供退款接⼝；但有通道提供的商户后台；

2）提供退款接⼝，当⽇交易⾦额⼩于退款⾦额，则通道退款失败；有些细分到具体某个⽀付产品（如）的当

⽇交易⾦额⼩于退款⾦额，就退款失败；

⽹络原因波动，则通道没接收，则退款失败；

3）若风险订单，通道有时会先⾏扣款，再通知我们，因此我们需要让客户发起，但不经过上游渠道；

4）通道对账单与订单状态不⼀致，例如对账单成功，但是接⼝返回失败；

5. 给商户的退款接⼝不⽀持返回失败原因；

6. 经常性的遭到客户投诉退款效率问题；

7. 每次退款订单不⽀持系统⾃动审核，均需要⼈⼯审核。

所以当时接⼿这样的退款系统，内⼼是有点⼩崩溃的，感觉旧退款系统真是⼀⽆所能。

举⼏个栗⼦：举⼏个栗⼦

1) 作为电商平台，购买两双鞋，对其中⼀双鞋不满意进⾏退款，然后我们不⽀持；

2) 客户做秒杀拼团活动，⼀做拼团，退款的并发不⽀持；不能退回⽀付⼿续费，平台含泪亏钱；

3)正常的全额退款订单，明明在⽀付公司申请成功，但是莫名之间将退款订单打回来，原因是

⽀付公司与上游通道不稳定。作为客户的认知是⽆法理解的，“明明退款申请成功，却为何退款失败回来呢？？Are you kidding me？”

尽管知道是个坑，但还得义⽆反顾，因为作为产品经理，岗位职责就是得解决问题；⽽且越能体现产品经理的价值就是解决棘⼿的问题，就是

对异常问题的深⼊思考。

产品经理的核⼼，不在于原型画的有多好，不在于需求⽂档写的多清晰，⽽在于对异常问题的深⼊思考。

因此，在我接到这个需求之后，多次经过需求分析，以及需求调研。最终发现要想做好退款需求，主要是理解好商户、⽀付公司，以及财务对

账的需求。

对于商户，最核⼼的要保证退款成功率、快速到账，⽀撑退⼿续费、部分退款等业务情况；

对于⽀付公司，主要是满⾜商户需求，以及提⾼退款的灵活性，能够⽀持业务的异常性；对财务对账，通道退款⼿续费与

通道保持⼀致。

⼆、需求分析

做好需求分析，需要我们换位思考客户对⼀个需求的实际诉求；需求分析，也是⼀个理清思路的过程。

本⽂从商户、⽀付公司、财务三个对象中分别梳理他们对退款的需求。

1. 商户对退款的诉求

商户对于退款的需求，主要体现在能够⽀撑商户的业务需求，例如部分退款、多次退款、接⼝全⾯性等等，那么针对以下⼏种进⾏单独分析。

1）提供多种⼿续费模式

① 需⽀持不退回⼿续费；⽬的是保证公司现有利益，尽量对外不退⼿续费；

② 需⽀持退回⼿续费。⽬的是提供优质商户的客户体验。

这⾥的退款⼿续费计算是⼀个难点，因为⼀笔具体的⽀付⾦额对外收费存在三种情况

1）按⽐例收费；

2）按单笔固定⾦额收费；

3）按固定⾦额+⽐例收费。

那么应该如何处理⼿续费呢？如何才能保障双⽅利益呢？尽可能的将⼿续费退完，并且同时有便于商家理解？其实有两种

简单的实现⽅式：① 按⽐例退回⼿续费① 按⽐例退回⼿续费，即退款⼿续费=退款⾦额*⽀付⾦额*⽀付⼿续费；② 按⽀付费率退回⼿续② 按⽀付费率退回⼿续

费，即退款⼿续费=退款⾦额*⽀付费率。若固定⾦额收⼿续费，则每退⼀次，退回⼀次固定⾦额费率。

经过权衡，我们选择了按⽐例退回⼿续费模式，更加简单易懂。

2）⽀持任意⾦额退款

① ⽀持订单全额退款；

② ⽀持部分退款。

举例：在⽹上买两双鞋，然后对其中不满意只退其中⼀双，⽽不想两双都退。

3）⽀持多次退款

① ⽀持⼀次退款；

② ⽀持多次退款。

场景：消费者在⽹上⼀次性购买⼗件⾐服，由于是陆续到货，收到货物之后不满意，则进⾏退款，那么这⾥就会出现多次

的部分退款。

4）提供全⾯的退款接⼝

① 接⼝的全⾯性：单笔退款接⼝、批量退款接⼝、以及接⼝⾥⾯的请求、应答、异步通知、查询接⼝等等均需满⾜；① 接⼝的全⾯性

② 错误码的全⾯性：对于商户对接⽽⾔，假如出现退款失败，则需要将具体失败原因返回，⽅便进⾏排查问题，以及联系消费者。② 错误码的全⾯性

由于⼀家⽀付机构会接⼊多家上游渠道，⽽且每家渠道均不⼀样，甚⾄错误码存在问题。因此不能直接将通道错误码返回

给商家，必须做到错误码的过滤，建⽴⼀套错误码转译机制，提⾼⽤户体验。

5）⽀持退款到账快

由于商户也是为消费者⽽服务的，对于消费者，⼀旦申请退款，则系统资⾦⽴马到账；如果资⾦迟迟不到账，⽽会降低消费者对商家的好

感，从⽽也会降低商家对⽀付公司的好感。因此基本⼀旦发起退款，希望分钟级到账处理。

⾸先分析退款的路径，商户发起退款后，处于待⽀付公司审核，⽀付公司审核之后进⼊其上游银联审核，那么作为

⽀付公司所能做的就是降低退款订单在⽀付公司的滞留时间，简单系统⾃动判断订单⽆风险就⾃动审核通过。

2. ⽀付公司对退款的诉求

作为⽀付公司本⾝，在基本满⾜商户对于退款诉求之外，还有更⾼的指标要求；主要表现在要尽可能的提⾼退款成功率、保证退款安全性、

保证退款的灵活性，以及易⽤性。

接下来从产品视⾓的来分析应该如何满⾜这些需求。

1）尽可能保证退款成功率

① 更新退款处理：⼀般通道直接返回退款失败的订单，不⽤直接告诉商户重新发起，⽬的是降低对于商户的体验⼲扰。⽽是⽀付公司将内部的退① 更新退款处理

款流⽔号更新，⼆次请求上游通道，这样对于上游通道⽽⾔，这是⼀笔新的退款；退款成功之后，再更新告知商户退款的成功结果。

说明：商户请求⽀付公司的单号，⼀般是商户订单号，⽀付公司会相应⽣成退款流⽔号进⾏标记，同时将退款流⽔号作为

请求上游单号请求银⾏，银⾏会返回银⾏流⽔号。我们只需将请求银⾏的退款流⽔号进⾏更新即可，这样区分退款应答层

和请求层，更加层次分明。

② 打款退款处理：通道⽆退款接⼝，或者多次响应失败；特别是对于快捷⽀付的产品，可以选择退款调⽤代付打款接⼝，通过接⼝打款给原消费② 打款退款处理

者卡号中，这样间接实现退款，保证退款成功率；做到尽⼀切可能提⾼体验。

③ 退回消费者余额：若消费者开⽴了钱包账户，则提供退回消费者钱包余额的功能，这样将极⼤提⾼退款效率。③ 退回消费者余额

④ 建⽴反查机制：在系统内部建⽴定时反查机制。针对处理中的订单进⾏查询退款状态，⼀旦反查结果成功，则更新退款状态，避免通道没有退④ 建⽴反查机制：

款接⼝，或者异步应答出现问题的情况。

2）尽可能保证退款安全性

① 根据通道情况配置是否系统⾃动审核① 根据通道情况配置是否系统⾃动审核。由于通道渠道的质量千差万别的，对于良好运⾏的上游渠道，则可以配置⾃动审核，则会降低退

款订单的停留时间；对于质量差的不稳定的渠道，则⼈⼯审核。如果出现系统故障时，出现交易堵塞引发批量退款时，也可以紧急关闭⾃动审核功

能，保证安全性；

② 通道先⾏扣款，则⼈⼯审核 ② 通道先⾏扣款，则⼈⼯审核。对于有些风险订单，通道实⾏先⾏扣款机制（尽管不合理），为了对账的⼀致性，我们需要商户重新发起，

但是需拦截请求通道，因此可以针对这些订单对应的上游渠道进⾏⼈⼯审核，直接作退款成功处理。

3）尽可能保证退款的灵活性

① 增加强制退款成功操作：如果和通道对账发现，订单在对账单显⽰成功，但是系统中仍为未成功的状态，因此需要将这些订单强制更正为 ① 增加强制退款成功操作

退款成功。

② 增加强制退款失败操作 ② 增加强制退款失败操作：由于前⾯聊到通道退款失败，我们将不直接置为失败，⽽是更新处理，那么假设消费者卡号注销呢？则只能强制

置为失败。

③ 降低耦合性③ 降低耦合性：由于退款系统属于⽀付收单的逆向流程，很容易与收单进⾏强耦合在⼀起，因此有必要将收单的关键字段同步到退款系统，

⽆需频繁调⽤收单数据。降低耦合性有助于为后续的⼦商户退款、分账退款作铺垫。因此⼀旦涉及分账退款，其退款逻辑的复杂性远远⾼于基础退

款。

④ 建⽴异常订单机制 ④ 建⽴异常订单机制。 主要有如下情况：⼀旦发起重复订单⽀付，可以系统⾃动触发调⽤退款的模式进⾏处理；有风控系统主动触发退款的

模式进⾏处理；有⽀付⾦额⼩于订单⼿续费的⼊账异常，⾃动触发发起退款。

4）尽可能保证退款的易⽤性

① 接⼝返回失败原因① 接⼝返回失败原因，由于⽀付公司上游会有很多通道，各家的错误码不⼀致，甚⾄现有的银联⽹联不⼀致，也不规范，作为普通商家很难

看懂。因此需要建⽴⼀层错误码转译机制，⽬的是建⽴⽀付公司内部统⼀错误码机制，实现标准化，同时将上游通道难以理解的错误码简化为简单

易懂的错误码。

② 失败订单⾃动化处理② 失败订单⾃动化处理，前期可以根据通道的返回的错误码，进⾏⼈⼯⼆次处理，后期则可以根据通道具体的错误码进⾏⾃动化处理，⽬的

是在保证退款成功率的同时⼜降低⼈⼯操作成本。

举个例⼦：通道错误码返回：“该卡为作废卡，订单状态:01”，则说明卡号本⾝为废卡，因此⽆论怎么处理都将失败，

可以⾃动化置为失败；⼜例如返回：“你的操作过于频繁，请稍后再试”，这可以系统⾃动化的更新退款流⽔号重新处

理。

3. 财务对于退款的诉求

财务的⽇常⼯作之⼀，是进⾏通道对账，⽬的是将上游通道的订单计费情况，与内部系统保持⼀致。由于⽀付公司的上游-银联/⽹联，在通道退款

接⼝不会返回退款⼿续费的值，因此需要⽀付公司⾃⾏计算退款⼿续费，以保持与通道⼀致性。

1）保证退款⼿续费⽆误

上游的订单计费，对于⽀付公司来讲就是⽀出的成本，因此每个渠道⼊⽹，都会有个成本规则配置（这个规则要有很强的灵活性来⽀撑不同收费模

式），需要根据通道情况，增加“是否退回⼿续费，以及⼿续费规则”。这样的⽬的是保证双⽅规则的统⼀性，降低对账的障碍。

具体如下图所⽰：

三. 产品设计

在进⾏产品设计的时候，我们需要确⽴产品设计的原因，以退款系统为例：

⾸先，要进⾏解耦，各模块之间可以采取必要的相互调⽤原则，不影响其他功能模块的设计；

其次，退款的账户扣款要明确账户扣款的路径；

第三，要明确退款的各模块的定义、标准，例如状态流，审核流、退款⽅式、退款来源；

最后，要梳理出各板块的业务逻辑，并通过产品架构串联起来。

根据产品设计原则，同时基于以上的需求分析的情况，本⽂只挑选三个重要板块进⾏产品设计分析：

1）如何确⽴退款业务流；

2）退款⼿续费的计算准确；

3）更新退款的业务逻辑。

1. 退款业务流

⼀个好的退款状态流能够很好的体现退款订单所进⾏的步骤。⽽且，退款⼜是⼀个⾮常有严谨的业务，有时⼜特别需要审核环节，因此为了将退款

流程更加清晰，将流程分为退款状态流和审核流。

1）退款状态流

2）退款审核流

这⾥审核状态之所以不加⼊银⾏审核状态，是因为完全没有必要，作为下游机构⽆需知道其审核机构，只需知道处理状态即可。

3）退款状态的变动流程

2. 退款⼿续费计算逻辑

由于允许多次退款，因此需要标记⼀笔退款订单的剩余可退的⾦额，以及剩余可退⼿续费，避免商户钻空⼦导致公司亏钱，因此逻辑必须严谨。

计算公式，

剩余可退⾦额=订单⾦额-累计已退款⾦额；如果是初次退款，则剩余可退⾦额=订单⾦额‘’剩余可退⾦额=订单⾦额-累计已退款⾦额；

剩余可退⼿续费=⽀付⼿续费-累计已退⼿续费。

计算逻辑

举例为证：假设交易⾦额为100的订单，其⽀付⼿续费为0.5元；交易⾦额为1000元的订单，其⽀付⼿续费为4元。

字母含义：试算⼿续费=A，剩余可退⼿续费=B，此次实际退款的⼿续费=C；剩余可退⾦额=D。

从中我们可以知道，由于退款存在近似值的情况，会存在⼀定的误差。

例如下表中100元的订单，在未完全退款之前，就存在把退款⼿续费扣完的情况；因此我们要设定剩余可退⾦额与试算的退款⼿续费⽐较，

避免亏损。

但也存在下表中1000元订单的情况，在完全退款之后，其⼿续费存在退不了的情况，⽽这种情况对于⽀付公司并未有过多损失，因此允许

这种发⽣。

3. 更新订单逻辑

当通道返回退款失败的结果之后，往往并不是这笔订单⼀定不能再处理的，⽽是在这次的请求是不能处理失败的。因此，我们需要千⽅百计

尽可能重新处理，但是更新订单并未盲⽬，否则会造成超额退款的情况。

所以，更新退款需要基于以下判断：

1) 先反查通道退款状态 1) 先反查通道退款状态，如果反查通道的状态实际为“已创建”，即通道未接受，则⽤原退款流⽔号重新请求即可；若反查成功，则系

统⾃动更新退款流⽔号重新请求，直⾄成功；

2) 不反查直接更新退款 2) 不反查直接更新退款，有⼀种请求属于通道反查失败，⼀直报错，但是基于通道对账单发现并未处理成功，可以认定为通道本⾝的问

题，因此可以不反查直接更新，由于这个操作具有风险性，故仅部分退款时需谨慎操作。

4. 其他

在产品设计中，需要将退款各种情况考虑全⾯，因此为了让⼤家更好的理解设计退款的全貌，我将剩余的产品功能核⼼部分展⽰⼀下，⽅便理解。

1）商户⼊⽹

① ⽀撑商户的每个⽀付产品退⼿续费、不退⼿续费；

② ⽀持商户的特殊计费不退⼿续费，普通计费退⼿续费。

2）通道⼊⽹

① ⽀持⼀个通道的不同规则退⼿续费与不退⼿续费；

② 允许每个通道的退款⼿续费算法不⼀样的配置。

3）对外接⼝

① 提供单笔退款接⼝、批量退款接⼝、查询单笔退款接⼝、查询所有退款接⼝；

② 打造退款响应码机制。

4）退款逻辑

① 基于通道情况，可配置⾃动审核/⼈⼯审核；

② 基于退款失败订单，进⾏更新处理；

③ 打造通道错误码⾃动化处理机制，降低⼈⼯操作；

④ ⽀持异常订单的退款处理。

5）升级退款能⼒

① ⽀持⼦商户退款；

② ⽀持打款退款，若⽆法原路退款，可采取打款退款处理；

③ ⽀持分账退款。允许订单分账前退款，以及订单分账后退款。

四. 总结

打造好退款系统，不仅要⽀撑现有客户对于部分退款、退⼿续费等功能的需求；⽽且要升级思维，加强对异常情况的考虑——这样才能够让

产品持续屹⽴不倒，打造出⼀个厉害的退款系统。