一次支付意图、两条订单，是重复扣款里最常见的形态。游客的诉求只有一个：退一条。景区这边先要回答的是另一个问题：这两条是怎么长出来的。顺序查错了，会把一次网络重试判成系统故障，顺带把正常的那家渠道也冤枉一遍。

一、先确认是不是两条。同一付款账号、同一票种、金额一致、订单号不同，四条同时满足才叫重复。判据看创建时间差：两条相差 1~3 秒，多半是前端重复提交；相差 5 分钟以上，多半是当事人自己下了两次，这一次不叫重复，叫两笔有效订单，处置路径完全不同。时间差是这个案子唯一的分岔口，先看它，再看别的。

二、查支付侧还是订单侧。先支付侧，区别在流水条数。一条支付流水对应两个订单号，是扣款成功的回调被重复处理，问题在票务系统内部；两条流水对应两个订单，是提交本身就重复，问题在下单入口。流水只有一条而订单有两条，去窗口怎么解释都行；流水有两条而只退一条，账对不上，必须退第二条。

三、幂等落在哪个字段。同一订单号的重复请求要返回同一结果，不新增记录。判据：连续提交两次同样内容的请求，第二条不生成新订单，也不产生新流水。做不到这一点的系统，重复率永远压不下去。判据要按接口层分段测：下单、支付、回调三段各打一次重复请求，看哪一段新增了记录。只测整条流程，出问题时永远不知道缺幂等的是哪一段。

四、退哪一条。只退一条，另一条作废。作废的那条要留下作废原因与经办人，不能只把状态改成两个字。事后有人问为什么账上有两条记录，答案要能自己站住。退款按支付流水走，不按订单号走：两条流水各退一次是两笔应退，一条流水退两次是不可能的操作，按流水对齐就不会退重，也退不错。

五、三道拦截的位置。第一道在下单前：同一账号在 60 秒内已有未支付订单，不再新建；第二道在支付前：按钮点击后置灰到收到结果为止；第三道在回调处理：以支付流水为唯一键。三道都做，重复率基本归零。

六、统计口径。重复率的分母用支付总笔数，不用订单总笔数，也不用入园人数。分母选错，同一个问题会被算成两种严重程度，两边争半天其实是在争分母。区间给三条线：万分之一以内算噪声，不到 1 笔不用查；万分之一到千分之一之间进观察名单，看是否集中在某一入口；连续两天超过千分之一，当天就查接口，不等周报。

七、现场先处理人再处理单。窗口按订单核验先放行，退款事后走，不要在闸机口争论哪一条该留。判据是停留时长：同一笔争议在门口停留超过 3 分钟就转服务台处理，队伍后面的人会跟着一起堵。先放行不等于承认两条都有效，只等于不影响其他游客入园，账的事在系统里慢慢对。

重复率按渠道分栏看，不按全局看。全局正常、某一家单独冒头，多半是它的下单接口在超时之后自行重发，问题在接口调用方，不在票务系统本身。这时候要改的是接口约定，不是窗口流程。