一、主题分享

一、退款流程

20180603_213320

1、流程概述:

第一类:商户发起的退款

  1. 商户对第三方支付公司发起退款请求,
  2. 业务层请求清算中心的退款接口(也就是扣账)。
  3. 清算中心请求账务/账户的退款/扣账接口。成功后,清算中心通知业务层扣账成功。
  4. 业务层在得知扣账成功后,请求退款中心执行退款操作。
  5. 若退款中心未给业务层报错,则向业务层承诺可以告知商户退款成功。
  6. 按照支付接口的退款属性,执行接口退款、打款退款、上传文件退款、线下退款,或其他组合方式。
  7. 次日对账阶段,对账中心取退款中心的退款数据(只取提交状态为提交成功的)与银行的清算文件执行对账,并对退款中心进行状态回写(退款成功失败与否以对账中心的回调为准)。

第二类:差错退款

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

  1. 业务层请求退款中心差错退款业务接口
  2. 后续流程与正常的交易退款一致。但,不支持部分退款

二、退款方式

1、接口退款

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

2、打款退款

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

3、上传文件退款

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

4、线下退款

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

三、总结

1、退款速度方面

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

2、应用场景方面

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


二、 Q&A

分账退款能介绍下吗?

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

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

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

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

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

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

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

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

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


本文档来自支付产品技术交流群的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。