一、背景

由于网络异常或者系统的波动，可能会导致用户支付成功，但是商户侧未能成功接收到支付结果通知，进而显示订单未支付的情况。商户侧的订单状态更新不及时，容易造成用户投诉，甚至是重复支付的情况发生。

更好的帮助微信支付合作伙伴避免、发现和及时处理这类情况，本文档提供了系统实现指引、对账发现及处理、客诉发现及处理的实践指引。

二、使用对象

包括微信支付合作机构的开发人员，产品经理，业务运营人员，以及为机构开发收单系统的系统提供商。

三、事前规避

部分单边账是由于机构或商户系统设计存在一定缺陷而导致，此章节介绍接入微信支付 API 的最佳实践，通过最佳逻辑设计规避单边账问题的产生。

1、查单设计说明

1.1 什么是查单

微信支付提供了查询订单的能力，机构或商家可以通过调用查询订单 API 来主动获取订单的支付状态，以及与该订单关联的信息。

1.2 什么时候需要使用查单

当用户使用微信支付在商家侧完成一笔支付后，只有商家从微信支付一侧收到明确的支付成功的结果才能够将商品提供给商户。

微信支付提供了多种获取订单状态的方式，如付款码支付场景下的同步返回，以及其他支付场景下的异步支付结果通知。

但在某些极端情况下，通过以上方式可能无法获得订单支付结果，商户/机构就可以通过查询订单接口来获取订单状态。

1.3 没有查单能力的 bad case

Case 1:

机构 A 接入微信支付的 Native支付后完全依赖支付结果通知来确认订单状态，某日由于机构A 接收支付回调的服务出现故障，导致故障期间所有用户支付成功的订单商家都处理为超时，因而产生了大量用户投诉。

Case 2：

机构 B 接入微信支付的 Quick Pay 后并未对接查单能力，某日用户在机构下某商户消费时购买了高客单价的商品而触发验密场景，用户输入完密码完成扣款后，商户收银机始终显示 Pending 直到订单超时，导致用户投诉产生。

1.4 查单设计建议

微信支付有付款码支付和收银台支付（包括 Native支付，JSAPI支付，小程序支付，APP支付以及 H5 支付）两个主要的支付模型，两个模型的查单设计有较大的区别。

1.4.1 付款码支付查单设计建议

【方案一】

当付款码支付订单的金额小于 3000 人民币，且当日用户使用付款码支付的次数少于 10 次，付款码支付的订单都是免密的，机构可以根据请求付款码支付 API 返回的成功结果直接更新订单状态。

以上两个条件任意一个不满足时，就会要求用户输入密码来验证支付，此时付款码支付 API 会同步返回 USERPAYING 的状态，在此情况下，机构需要轮询调用查询订单 API 直到获取到订单状态或订单超时。

注意：轮询次数及间隔可由商户的业务情况来决定，通常建议轮询间隔在 3-5s，轮询时长为 45-50s，以上建议仅做参考。

除了密码验证的场景外，如果付款码支付API 返回了不确定的状态，比如 NOTPAY，PAYERROR，或商户侧没有收到返回的情况下，也同样需要发起查单，查单轮询间隔与轮询时长与 USERPAYING的情况相同。

另外，对于支付网关和 POS 收银系统之间的交互，我们建议如下两种方式

第一种方式是查询订单的逻辑全部包装在网关侧

另一种模式为查单逻辑包装在 POS 系统

商户或机构可根据自身的实际情况来进行选择

【方案二】

触发查单的条件与方案一相同，但仅在商户设置的订单有效期内发起一次查单，通常设置在订单超时的前一秒，系统自动发起一次查单。

【方案三】

手动查单，即由前端收银人员手动发起订单查询，当方案一中触发查单的条件达成时，前端 POS 系统提示收银员需要发起查单，由收银员手动点击按钮发起查单，查单次数和间隔均由收银员决定。

注意：由于该方案强依赖收银员的操作，故通常不建议采用该方案，仅在没有其他方案可选的情况下选择。

注意：对于已经有自动查单能力的商户，我们也建议增加手动查询的能力，以防止 POS 终端因各种原因未收到自动轮训结果的情况下可以由收银员手动触发一次查单。

1.4.2 收银台支付查单设计建议

收银台支付就是指需要通过统一下单获取 prepay_id 或 mweb_url，然后拉起微信支付收银台的支付方式，包括 Native 支付，JSAPI 支付，小程序支付，APP 支付，H5 支付。

【方案一】

一般情况下，当支付完成时，微信支付会向商户/机构的回调通知地址发送支付成功通知。商户/机构在收到回调后，需要返回指定的内容并更新订单状态到订单数据库当中，如下所示：

注意：若收到回调后返回内容不合法，或未返回内容，微信支付会认定本次回调失败，并多次重试回调。

但当发生系统或网络抖动，以及商户回调地址不可用的情况时，商户/机构需要通过主动调用查询API来获取订单状态。

机构/商户可以在订单业务有效期终止（订单过期）时触发一次查单，以保证订单过期时所记录的状态为正确状态。这样可以保证对未支付成功的订单进行关单，对已支付成功的订单发起退款。故而避免了单边账的产生。具体逻辑如下图所示：

但此方案的查单失效仍然存在一定的延迟，可能导致用户等待时间过长而产生投诉，因此在条件允许的情况下，我们建议参考方案二进行优化。

【方案二】

等待回调部分的逻辑与方案一相同，但对于查询订单逻辑的设计，我们建议机构/商户建立两条查单链路，一条通过前端回调触发，另一条则在下单时即触发进入任务队列。

当商户/下单时，订单数据即写入商户订单数据库，同步开始将订单加入查单队列，按照一定频率调用微信支付查询订单API来查询订单状态，如下所示。

注意：有关查单队列调用微信支付查询API的频率及次数，商户/机构可根据自身的业务情况来决定，微信支付官方不提供细节建议。

对于存在前端页面或应用回调的场景（包括APP支付/小程序支付/H5支付/JSAPI支付），当用户完成支付后跳回商户/机构的APP/小程序/网页时，机构/商户会收到前端返回（调用JSAPI，或SDK的返回），商户/机构可根据前端返回来判断用户是否取消了支付。若前端返回为fail，则确认用户取消支付，可将该订单直接从查单队列中移除，即不再需要查单；若前端返回为success，则确认用户未取消支付，但支付最终是否成功则需要依赖后台的回调或查询订单结果。

若确认用户未取消支付，则此时触发一次商户/机构内部的订单查询服务，即商户/机构查单模块在后台数据库内查询订单当前的状态。此时商户/机构若已成功收到回调，则查询订单数据为success，查询服务模块可将订单状态同步到前端，在商户/机构的业务页面上展示支付成功信息；若此时回调尚未触达，或因为其他原因导致无法收到回调，则该订单状态需通过查单队列的结果确认，如下图所示：

2、订单闭环处理

2.1 什么是订单闭环

订单闭环，指在订单业务时间内订单状态达到最终态，最终状态包括 SUCCESS，REVOKED，CLOSED 以及 REFUND，其中 REFUND 的状态是通过对已支付订单发起退款才能达成，因此在交易环节，订单需要最终达到SUCCESS，REVOKED，CLOSED这 3个状态。

2.2 闭环设计建议

1、有哪些闭环 API

微信支付提供了实现订单闭环处理的 API，包括 撤销接口 Revoke API 以及关单接口 Close Order API供机构实现订单的闭环处理。

其中撤销接口 Revoke API 仅可在付款码支付 Quick Pay 场景下使用，其他支付场景实现订单闭环仅可使用关单接口 Close Order API。

2、闭环 API 实现的效果

对于付款码支付的场景，商户一旦调用撤销接口，订单就会被冲正，也意味着如果当前订单还未被支付，则订单会被关闭。而如果当前订单已经支付完成，则订单会被发起退款。

对于其他支付场景，微信支付提供了关单接口，该接口仅可对未支付成功的订单进行调用，一经调用，订单立刻被关闭将无法再进行支付。如果订单已支付成功，则无法被关闭，调用关单接口会直接报错 ORDERPAID。

3、订单闭环设计建议

对于付款码支付场景，当订单发生超时，或 POS 终端对订单状态不明时，我们建议对订单发起撤销申请，但撤销不宜调用过快也不宜过久，建议在发起支付 30 秒到 1 分钟之间调用。

对于关闭订单接口，前面有提到对支付成功的订单调用关单接口会返回错误 ORDRPAID，订单无法被关闭，我们建议商户遇到该类情况时按订单支付成功来处理。如果此时 POS 已认为订单被撤销无法将状态更新已支付的话，则需要对该订单发起退款。我们建议系统可按照如下建议设计。

四、事中发现

一旦单边账产生，机构或商户可以通过 T+1 日提供的账单进行对账时发现单边账记录。本章节介绍如何进行对账以及主动发现单边账情况。

1、事前准备

2、对账流程

2.1 明细对账

• 对账目的：明细对账的目的是发现机构/商户自身和微信支付之间的交易明细的差异（discrepancies）

• 对账方法：将微信支付提供的交易账单中'Vendor order number'一列中所有的单号去匹配机构/商户自身系统中的交易明细。匹配后可能发生如下2种异常情况：

2.2 资金对账

• 对账目的：核对微信支付承诺结算的金额与实际结算的金额的一致性

• 对账方法：

五、事后处理

单边账产生后，用户可能会通过微信进行投诉，商户可通过微信支付商户后台或API 获取并处理用户投诉。通过查看用户投诉的内容，机构/商户能够及时发现单边账问题。

发现单边账问题后，机构/商户需及时为用户操作退款/提供对应的商品服务，解决用户问题；同时，也需要结合具体的 case 反查定位支付系统的开发问题并进行优化（结合上文），保障用户后续支付体验。

5.1 用户投诉入口说明

支付成功后，用户才可以在微信App的账单详情页z，点击“对订单有疑惑”查看常见交易问题。若用户问题仍未得到解决，用户可以提交投诉。

5.2 商家处理入口

用户提交投诉后，微信支付客服会将单边账投诉筛选出来，并标记为Priority Complaints，商家可以通过商户平台或客诉 API 获取处理。

1. 商户平台

登录商户平台后，按以下路径找到操作入口：

（1）机构入口Institution- Consumer Complaints

（2）普通服务商入口Service Provider - Consumer Complaints

（3）直连/普通服务子入口Transaction - Consumer Complaints

2. 客诉API文档

也可以选择通过 API对接获取处理消费者投诉，开发文档：境外消费者投诉API文档

5.3 单边账投诉发现及调研

以下以商户平台为例介绍如何查看用户单边账投诉。

1. 登录商户平台，并找到消费者投诉处理页面，点击“Priority Complaints”，即可看到相关投诉。

2. 可根据投诉对应的交易单号(Merchant Transaction ID)和用户投诉描述，按照以下顺序，调研各系统中交易单的状态是否一致：

（1）机构自身支付系统，交易是否成功

（2）商家自身支付系统，交易是否成功

（3）商家终端收款设备（POS/网页/App等），交易是否成功

若上述任意环节，查询到交易失败或查询不到对应交易，说明支付系统开发存在问题，可联系微信支付技术支持排查并制定优化方案。

5.4 单边账投诉处理

收到用户单边账投诉后，主要处理思路如下：

（1）操作退款，退款到帐后，投诉单自动完结

（2）为用户补发相应的产品服务，则补发前后需要通过商户平台/api 与用户沟通，并在协商一致后手动点击投诉已处理完成。

详细操作指引见：境外消费者投诉商户平台处理指引