作为补充，上一篇文章很多同学对冲正非常感兴趣，那么我就谈谈在支付业务过程中，冲正交易的作用和场景。
我们来看看百度百科上关于冲正的定义：
即一笔交易在终端已经置为成功标志，但是发送到主机的帐务交易包没有得到响应，即终端交易超时，所以不确定该笔交易是否在主机端也成功完成，为了确保用户的利益，终端重新向主机发送请求，请求取消该笔交易的流水，如果主机端已经交易成功，则回滚交易，否则不处理，然后将处理结果返回给终端。
冲正，就为系统认为可能交易失败时采取的补救手法。
学术上这么解释也许够了，但还是不够严谨的，因为冲正交易不光要求对已有交易进行回滚，语义上他还要求应答系统对该交易流水进行幂等控制——将该交易流水插入幂等表，即便后续该交易报文再抵达，也予以拒绝交易。
如果不加上上面我补充的这段，那么这个冲正交易的实现是有逻辑漏洞的。
虽然概率极低，但由于各链路节点处理信息的效率不一致，所以也有可能出现冲正交易先抵达目标系统，正常交易晚抵达的情况，假使该目标系统的冲正交易未作以上逻辑判断，那就会引起用户纠纷。
那么，我们用通俗一点的语言来描述一下冲正交易，就是：
哥把一个流水号告诉目标系统，告诉它这个号码来的，都是大大滴不好，你先去检查一下现在系统里有没有。如果有的话，把他干掉，别让他存在；如果没有，你让手下的看牢了，万一过会来了，就把它拿下，死啦死啦滴……
至于冲正交易在系统内的实现，由于不是本次我要谈的重点，所以略过，后面有机会再谈谈他的本质和实现。
最后，我们来看看冲正交易的使用场景。
通常，目前国内线上支付系统鲜有冲正交易（除非部分快捷支付接口，银行当时是使用信用卡无磁无密网关包装出来的，会保留冲正接口），大多数的场景发生在线下。
例如：
你去商场购买了一个驴牌的包包，价值5万元，刷信用卡消费。
POS机在发送交易报文的时候……不幸掉单了，恩，就是那么不幸，pos机无论如何收不到来自于收单系统的回执单据。经过漫长的等待，pos机忍不住了，自动给收单系统发了一笔冲正交易……收单行回执，冲正交易处理成功，事件完毕。
这个时候，你会发现服务员又笑眯眯地找你，要你重新刷一下卡……
或许有同学会问，那万一的冲正交易也掉单了呢……
是的，会有这种奇葩情况，通常系统会对冲正交易重发N次，N次后如果还没应答就算了，概率太低了，等用户来投诉吧——很多时候人工保障比你动脑筋想异常中的异常如何系统自动处理来得反而高效和低成本。
或许还有同学会问，那pos机上的撤销交易和冲正是什么关系呢？
其实两个接口的内部实现可以说是类似的，业务场景上，撤销交易更偏向于由人工发起对原单据的撤销，可以理解为业务行为；冲正更类似于系统保障机制，可以不由业务人员感知到，仅此而已。
今天差不多了，先这些。
— 完 —
本文作者：天顺
【知乎日报】
你都看到这啦，快来点我嘛 Σ(▼□▼メ)
