1. 背景
微信支付提供了查询订单API作为合作商户/机构确认订单状态的兜底能力。当出现网络抖动或回调通知服务异常时，商户/机构需要主动调用查询订单API以获取订单状态。
2. 影响
• 商户/机构口碑：若商户/机构没有在系统内实现查询订单的能力，支付结果通知（支付回调）将成为商户/机构唯一实时获取订单状态的渠道。若回调通知地址出现服务异常，会导致异常时间内所有订单的状态均无法在系统内同步，进而导致商家大面积无法使用微信支付，引起用户投诉，最终严重影响机构，商户及微信支付的口碑；
• 单边账投诉：若因网络抖动或短时间回调异常导致商户/机构系统未能同步订单状态，且商户/机构没有在系统内实现查单逻辑。则可能导致用户实际已发生扣款，而商户/机构系统却长时间认定订单尚未支付，不能向用户发货，最终导致用户单边账投诉。
3. 目标
无论是哪一类影响，都会导致用户对机构/商户服务质量及微信支付服务稳定性的怀疑和负面认知。因此机构/商户都需要在收单系统内实现查询订单的功能逻辑，即使在无法接收回调通知的情况下，也能够及时获取到订单状态，以此提高系统服务的稳定性。
4. 查单逻辑实现建议
注意 本查单逻辑建议仅针对除付款码支付之外的其他支付场景，即native支付，JSAPI支付，APP支付场景下的查单策略建议。
我们提供两套查单方案供机构优化系统参考：
方案一
一般情况下，当支付完成时，微信支付会向商户/机构的回调通知地址发送支付成功通知。商户/机构在收到回调后，需要返回指定的内容并更新订单状态到订单数据库当中，如下所示：
注意 若收到回调后返回内容不合法，或未返回内容，微信支付会认定本次回调失败，并多次重试回调。
但当发生系统或网络抖动，以及商户回调地址不可用的情况时，商户/机构需要通过主动调用查询API来获取订单状态。
机构/商户可以在订单业务有效期终止（订单过期）时触发一次查单，以保证订单过期时所记录的状态为正确状态。这样可以保证对未支付成功的订单进行关单，对已支付成功的订单发起退款。故而避免了单边账的产生。具体逻辑如下图所示：
但此方案的查单失效仍然存在一定的延迟，可能导致用户等待时间过长而产生投诉，因此在条件允许的情况下，我们建议参考方案二进行优化。
方案二
等待回调部分的逻辑与方案一相同，但对于查询订单逻辑的设计，我们建议机构/商户建立两条查单链路，一条通过前端回调触发，另一条则在下单时即触发进入任务队列。
当商户/下单时，订单数据即写入商户订单数据库，同步开始将订单加入查单队列，按照一定频率调用微信支付查询订单API来查询订单状态，如下所示。
注意 有关查单队列调用微信支付查询API的频率及次数，商户/机构可根据自身的业务情况来决定，微信支付官方不提供细节建议。
对于存在前端页面或应用回调的场景（包括APP支付/小程序支付/H5支付/JSAPI支付），当用户完成支付后跳回商户/机构的APP/小程序/网页时，机构/商户会收到前端返回（调用JSAPI，或SDK的返回），商户/机构可根据前端返回来判断用户是否取消了支付。若前端返回为fail，则确认用户取消支付，可将该订单直接从查单队列中移除，即不再需要查单；若前端返回为success，则确认用户未取消支付，但支付最终是否成功则需要依赖后台的回调或查询订单结果。
若确认用户未取消支付，则此时触发一次商户/机构内部的订单查询服务，即商户/机构查单模块在后台数据库内查询订单当前的状态。此时商户/机构若已成功收到回调，则查询订单数据为success，查询服务模块可将订单状态同步到前端，在商户/机构的业务页面上展示支付成功信息；若此时回调尚未触达，或因为其他原因导致无法收到回调，则该订单状态需通过查单队列的结果确认，如下图所示：
5. 订单闭环处理
我们建议机构或商户在最后一次查单获取交易状态非SUCCESS情况下，立即调用关单接口，中间切勿留有时间差。
注意 关闭订单接口仅可针对未支付成功的订单进行调用。
6. 事后兜底处理
商户在T+1日上午10点以后，调用《微信支付对账单下载接口》，或者登录微信商户平台手工下载T日交易账单，然后根据对账单中的订单数据，逐笔与商户系统中的订单核对。
核对时有如下几种情况：
1) 订单匹配成功，并且状态都是支付成功：正常情况，对账成功。
2) 订单匹配成功，但是商户侧状态非支付成功：商户根据自身业务情况，决定是否把订单状态更新为支付成功并给用户发货，或者是给用户发起退款。
3) 订单匹配失败，对账单中的单号在商户系统未找到记录：异常情况，需要商户排查系统是否出现数据异常。
4) 订单匹配失败，商户系统中成功的订单在对账单中未找到记录：异常情况，需要商户排查是否订单处理逻辑有bug。
页面导航
