退款业务实战--幂等的“基本操作”

产品大哥在需求评审的时候对这个小功能“一嘴带过”，而我竟然也简单地以为这个小需求可能只需要几个小时就搞定了

他的描述大概是这样的:"用户填写了支付宝账号密码之后，将退款金额打到用户的支付宝里面。好，我们看下一个功能点"。

。。。。。。这难道不是，开局一张图，结局全靠编吗！！！

在接口设计的时候，觉得此事不简单。找了之前对接过支付宝的同事沟通了一下，里面还是有很多门道

流程设计上，应该是这样的

1. 用户发起退款时，校验用户实际退款金额是否超过可操作余额，校验用户历史退款到支付宝总金额+本次退款金额是否操作500RMB
2. 校验通过之后，创建退款单记录流水，标记退款状态为退款中，（暂扣金额，关联业务无法使用该笔金额）调用支付宝接口发起退款操作，此时直接响应前端“已经发起退款操作，请等待结果”
3. 等待支付宝回调。。。wating。。。
   1. 回调成功，查看回调状态是否为已回调，若已回调，直接返回。若未回调，改为已回调，修改退款状态为退款成功，将关联业务数据更新（实扣金额），短信通知客户“已经成功退款，请查看支付宝”；
   2. 回调失败，查看回调状态是否为已回调，若已回调，直接返回。若未回调，改为已回调，修改退款状态为退款失败，将关联业务数据更新（暂扣的金额回退，业务可使用该笔金额），短信通知客户“退款失败，可稍后重试哦”
4. 告诉支付宝，回调成功　

　　　　退款流程是这样的

　　　　回调过程是这样的

流程图发给了产品大哥，让他确认了一下，满足需求。

开始coding。。。

总结 : 梳理过路程图之后，其实发现也并不是太复杂，是很常用的设计。有几个点要注意

1. 在用户发起退款之后，业务需要将这笔钱暂扣，业务上是不能再使用的。这一点容易忽略
2. 支付宝回调有延时，不能立刻返回给用户结果，所以需要其他的通知手段，短信或者推送都可以。
3. 一般都会成功，只有少数情况会失败（账号密码错误），失败需要将暂扣的金额回退，使业务正常进行
4. 因为有回调重试机制，所以需要设定一个回调状态来标记此次请求已经被处理