在支付领域，有一个专门的名字叫“更正”，根据百度百科，更正就是“纠正错误的账目”，主要用于银联POS刷卡时。

根据相关标准，当POS刷卡设备发出扣款请求时，如果POS刷卡设备因为各种原因没能得到本次刷卡请求的结果，就需要发出“冲销”请求。冲销就是告诉服务器，如果刚才交易成功了，就取消掉，然后返回冲销成功。如果不成功，或者服务器没有找到，那么就是冲销成功了。当然，如果交易成功了，但是取消失败了，那么服务器就需要返回“冲销失败”。这时候就只能手动处理“退款”了。

从整个交互流程来看，“冲销”其实和退款类似，只不过退款是设备发起的，是自动执行的，对于银行来说，这笔交易可能根本就不会出现在用户的交易记录里（这个我不太确定）；

那么，现在有一个问题，为什么我们需要修正它？

需要反转的原因是“流式系统”（这个名字是我自己起的）。什么是流式系统？就是所有请求都直接处理，就像流水一样。比如POS支付请求进来，POS服务器就会直接开始扣钱。什么叫“不问任何问题”？就是不关心请求是否重复，之前是否失败或成功...

因此，如果扣款过程中请求方与服务器之间出现中断，请求方在不知道是否成功的情况下，可能已经扣款了。如果请求方置之不理，再次发送请求，结果可能是用户被多次扣款，引发投诉。因此，银联的POS标准要求，只要POS设备在请求扣款时没有得到明确结果，就必须发出“撤销请求”。如果没有钱，没关系。如果扣款了，就退钱。至于是否还需要付费，可以再次请求……

另外一个问题是，银联为什么要把支付设计成这种逆转模式？

这是出于分布式系统架构的考虑，对于POS业务来说，卡支付需要安全、准确、稳定、高效、可靠，所以服务商肯定会需要一个大规模的分布式系统来支撑大量的支付请求，而且每个请求都需要快速响应，系统无法顾及是否重复（因为如果要查重复，就要搜索所有的历史请求，太耗资源和时间了）。

如果面临撤销请求，需要搜索近期所有请求，确认是否有处理记录，有则取消，没有则直接返回。当然撤销请求相对于支付请求数量来说非常少，所以即使资源消耗和时间消耗大一些也是可以处理的。

明确了前两个问题之后，我们需要考虑自己的系统是否必须提供反转的功能？什么情况下应该使用反转模式来解决问题？