从业这么多年，出过很多可以拖出去祭天的故障，好在老板人好，保住我小命一条，踩着公司的线上故障一步步成长。
大约十年前，当时年轻，公司人少，有支付经验的人更少，基本等于没有，因为我是团队里唯一一个有过支付行业从业经验的人，而我以前做的是余额扣款业务，没有外接过渠道。
说是草台班子一点也不过分，非常名符其实。
我接入的第一个外部渠道终于来了，吭哧吭哧前后忙活了差不多2个月，终于上线，开量，稳定运行，非常开心。
有天财务小妹找到我，说我接的那个渠道有几千笔支付订单对账出了短款，大几十万，表象就是：我们的支付单是成功的，但是渠道给的对账文件没有这些记录。
因为渠道已经跑了很长一段时间，觉得应该是渠道的问题，于是开始悠闲地翻日志和数据库的记录。
突然脑袋嗡的一声，感觉人都傻了：渠道用的是短号，最长6位，到了999999之后，需要先调用重签接口，然后再从0开始往上循环使用。当时到了999999之后，系统出了BUG，没有做重签，导致之后的支付交易实时接口全部返回“订单号重复”，然后系统自动调用查询接口，这时查的全部是以前的老交易，所以查询结果全部返回：支付成功，订单也对应推进到成功，平台给用户发货。
应急过程省略一万字。如果有兴趣了解细节，欢迎评论区留言。
当时心里的慌张和无助，依旧历历在目，毕竟我一年也挣不到那么多钱。不过最后还是想办法把用户的钱给扣回来了，因为平台也给用户发了货，所以也没有客诉。老板最终也没有按资损几十万给我定故障等级，算是平安落地，否则早就被迫转行，那你们今天就看不到我有机会说这故事了。
至于如何防短号资损，可参考前段时间发布的文章“支付资损防控指南精华版”，里面讲得很清楚，资损是什么，防哪些场景，怎么防，深入到细节。
那个开荒的年代，真的是无知者无畏。
有时候也不禁感慨：多少线上故障，才能成就一个成熟的架构师。
深耕境内/跨境支付架构设计十余年，欢迎关注并星标公众号“隐墨星辰”，和我一起深入解码支付系统的方方面面。
