碰到这种事，客户总要问，支付对接难在哪？我说下单那一段不难，难的是付完钱之后那个回调。回调处理不好，客户付了钱订单却没到。
回调为什么要快速返回
支付平台通知你「客户付款了」，你的接口要尽快回一个「收到」。回慢了，平台以为你没收到，会一遍遍重发。
我们的做法是回调接口先把收到的信息存下来。立刻返回成功，真正处理订单的逻辑放到后台慢慢做。先接住，再处理，这个顺序很关键。
如果回调接口里又查数据库又发消息又对接物流。处理时间长，平台等不及就会重发，结果一笔订单被处理好几次。
重复回调要能识别
同一个支付通知收到多次是正常的，不是异常。你的系统要能识别出「这个通知我处理过了」，而不是再处理一遍。
常见的做法是用支付平台的订单号或者交易号做唯一标识。处理前先查一下有没有记录。有记录就直接返回成功，不再重复处理。
这一步叫幂等。听起来像技术词，实际解决的问题很朴素：客户只付了一次钱，系统不能给他发两批货。
回调失败怎么补
网络抖动、系统升级都可能让回调失败。不能只依赖平台重发，自己也要有一个主动查询的机制。
我们的建议是定时去支付平台查一遍未完成的订单状态。发现已经付款但本地没处理的，补上处理。
还有一个兜底是人工处理入口。真有处理不了的订单，运营能手动在后台标记，把客户的钱和货对上，别让客户一直等。
还有一个细节是金额的校验。回调里的金额要和本地订单的金额对一遍，对不上要拦下来人工看。金额不做校验，被人改了通知内容就麻烦了。
支付回调上客户最常问的几个问题
回调要返回什么
按平台的约定返回成功标识。关键是快速返回，不要在回调里做耗时操作。
重复回调怎么防
用交易号做唯一标识，处理前先查询。重复的只返回成功，不再处理业务。
回调一直失败怎么办
加定时查询补漏，再留一个人工处理入口。两条腿走，才不会卡住订单。
常斌常挂嘴上的一句话：回调那个接口越急越要快返回，慢一秒就可能掉一单。
先把回调测透
我的建议是上线前把回调的几种异常情况都测一遍：超时、重复通知，再加上处理失败。平时测透了，真出事才不会慌。
我们交出去 100 多个商业应用之后，哪条路稳当早就摸清了。信服无限做支付对接时，会把回调处理当成重点来测。开始之前，告诉我你接的是哪家支付通道，各家回调的规则略有不同，我们按你的通道来。