商洛一个商城每到人就多的日子就掉单，客户付了钱，订单没生成，客服半天反应不过来。回调这块出事，八成不是支付的问题，是自己那段处理代码写成了"当场办完事"。
回调写成了同步活儿
原来的写法是支付平台一回调，程序当场做三件事：验签、写订单、发短信。三件加起来要一两秒，人一多就排队，排队超时支付那边就判定失败。
我们改成先落一条回调日志马上返回，验签和写订单放到后面慢慢做。返回值从原来的一秒多压到一百毫秒以内，掉单基本没了。
中间这一段的取舍很清楚：支付那边只关心"你收没收到"，至于收到以后怎么把他写成订单，那是你的事，别让他等。回调接口的第一要务是快，不是办完。
幂等这层不补早晚出事
支付平台的回调会重发，网络抖一下就发第二遍。原来的代码收到第二遍就再写一条订单，客户付一次钱出了两单。
我们加了幂等：用支付流水号加订单号做唯一键，同一笔来第二遍直接返回成功，不重复处理。这层加完之后客服那头"付了钱出两单"的工单清零了。
顺带把状态机也收了一下，从"待支付"到"已支付"只允许走一个方向，别的方向直接拒绝，别让后台莫名其妙的状态流转。
队列要有兜底
异步处理最大的风险是队列堆了没人管。我们做了三档：
- 五秒内没处理完的进慢队列，放慢但不断
- 超过三次失败的单独记一张表，人能看见
- 每天早上一张对账表，列出昨天的支付流水和本地订单对不上的
这张对账表是关键。队列有没有堵、回调有没有漏，早上一看就知道，不用等客户投诉。不怕出错，怕错了没人知道。
节假日前后该做的三件事
一是提前扩容。节前把队列消费者数调高一档，节后调回来，别一直开着，白烧资源。
二是把短信和推送降级。节日期间这两样最容易被挤掉，我们改成失败重试但不再卡主流程，宁可晚两分钟收到，也别拖住订单。
三是留一份手工对账入口。商洛这边节假日订单集中在几天，真出事的时候客服需要一个能手工补单的地方，这个入口我们一直在，只是平时没人用。
实际跑下来的数
改完那一年，掉单从节假日的十来笔降到不足两笔。客服工作量掉得更明显，因为不用每天核对"客户说付了但没单"。
2009 年入行，一晃十七年，上线过三百多个小程序，商业 App 也交付上百个，这类支付链路的坑我们踩过不止一遍，交付文档里现在都写成固定章节。
问得最多的三件事
回调慢一点没关系吗？
太快返回不安全，太慢会被判失败。经验值是一百毫秒内返回，剩下的往后放。
幂等一定要做吗？
要做。支付平台会重发，不做幂等就只能靠人去捡漏单。
对账表谁来做？
系统每天自动生成，负责人早上扫一眼。别靠客服在群里问。
说句招人嫌的，只有常斌的团队会收着做：回调那个接口越急越要快返回，慢一秒就掉一单。
剩下的你自己看下去
支付这块的核心就三句：接口要快、处理要幂等、对账要有表。信服无限商洛源码和一年维护打包给，不做分段收费，商城按需求分别报价。你把现在那段回调代码拍给我，我帮你标哪一行该挪走。