一、退款流程

1、流程概述:

第一类：商户发起的退款

商户对第三方支付公司发起退款请求，

业务层请求清算中心的退款接口（也就是扣账）。

清算中心请求账务/账户的退款/扣账接口。成功后，清算中心通知业务层扣账成功。

业务层在得知扣账成功后，请求退款中心执行退款操作。

若退款中心未给业务层报错，则向业务层承诺可以告知商户退款成功。

按照支付接口的退款属性，执行接口退款、打款退款、上传文件退款、线下退款，或其他组合方式。

次日对账阶段，对账中心取退款中心的退款数据（只取提交状态为提交成功的）与银行的清算文件执行对账，并对退款中心进行状态回写（退款成功失败与否以对账中心的回调为准）。

第二类：差错退款

差错退款场景：重复支付退款，超过有效期退款等场景。

业务层请求退款中心差错退款业务接口。

后续流程与正常的交易退款一致。但，不支持部分退款。

二、退款方式

1、接口退款

业务层请求退款中心，退款中心查得该支付通道支持接口退款后，每隔一定时间执行一次定时请求银行子系统（子系统对接银行提供的退款接口），根据子系统回调对账变更退款状态（非终态）。

2、打款退款

业务层请求退款中心，退款中心查得该支付通道支持打款退款后，实时请求打款中心执行打款退款操作，打款中心目前每隔一定时间执行一次定时请求银行。该种方式需保证支付公司能够获取打款要素（卡号、姓名等），否则100%失败。

3、上传文件退款

退款中心每天生成退款方式为上传文件退款的退款记录，记录一般为EXCEL格式，且该格式由银行规范，一般不变，结算部同事每个工作日，将该EXCEL上传至对应的官方网站。

4、线下退款

退款中心每天生成退款方式为线下退款的退款记录，记录一般为EXCEL格式，且该格式由银行规范，一般不变，结算部同事每个工作日，将该EXCEL使用传真、电子邮件或纸质形式传递至银行对接方（比较原始）。

三、总结

1、退款速度方面

打款退款为0-30分钟到账（持卡人收钱）、接口退款一般为0-7个工作日不等（大银行稍快），上传文件、线下退款只能在工作日由人工操作、效率最低。

2、应用场景方面

接口退款一般应用于网银、聚合通道。打款退款一般应用于快捷、代扣通道；上传文件、线下退款一般为银联通道。

Q&A

分账退款能介绍下吗?

其实。分账退款跟我刚才聊的这些在逻辑上是一致的。在分账退款的时候要把原来你分到哪些账户的金额。给他从相应的账户扣减。

然后在对退款中做个请求，那么对于支付公司来讲，这是松耦合的关系。关于分账的账务处理，应该放在清算和账户账务那一块儿。

对于托管中心来讲，我需要得到的就是说。给哪笔订单做退款，退多少钱，我只需要这个信息。

所以说在分账那块是有清算中心、账户和账务他们来做个账户的操作。这个操作就是按照原始的订单，然后你做一些相应的处理。

最近也在设计全流程退款，在产品设计上，你觉得有必要设计退款失败的流程么，就是也不打款也不走上传，由财务或者运营人员确认失败？

我觉得做退款这样的事情最大的问题就是说要保证资金安全。防止重复退款出现这种资金风险的事情。然后在这个底线的前提下，各个系统啊，我觉得要设计这种耦合，每个系统有每个系统的定位。那是定位呢，就是依赖于他这个系统应该具有哪些功能。然后通过这个度来看，来设计整个产品的这个交互还是比较合适的。

细节却实多，交易类型（担保交易，即时交易），分销（代销）的分润退款，预存款退款，手续费问题，时间问题（比如超过第三方支付退款时间，交易关闭），异常退款（用户账号丢失，银行卡注销），退款营销卡券是否退还，还有退款又退货处理。

支付公司内部订单成功，到随后银行回调支付失败吧，这样银行要配合追款喽，或者银行强制扣减持卡人账户的钱(因为支付公司回调商户，商户可能已发货)。支付公司超级怕这个，持卡人未扣款，但回调商户订单成功，人家发货。追款成本特高。这样的风险事件可能还得上报央行。

退单不付是针对付款场景说的，系统通知业务成功但是银行退回交易款，系统将资金返还到商户现金账户;付款本来应该付成功的，也返回商户成功，结果银行又给退回来。这笔钱可能商户已经通过其他方式付过，所以我们就加了这个状态，把资金还给商户。

-----------------------------分割线----------------------------

我是支付界胡歌

人帅话不多