目录
引子
分析
应对
小结
引子
在开发和实施微信 JSAPI 支付的应用后，我们遇到了一些问题，订单的状态更新不正常，当然我们首先需要从自身寻找原因和完善解决问题的办法和方案。在支付的过程中，客户会给我们一些反馈，应用系统的订单状态与微信手机端支付状态不一致，即信息状态更新异常。其中一个客户给我我们提供了手机截图，我们根据用户提供的订单号，登录微信支付商户平台，交易中心，按订单号进行查询，如下图，查询后的结果却显示“查询失败:操作失败，请稍候重试”...
分析
一般的情况下，查询订单会有两种结果，一、查不到，二、查得到。
一、查询不到订单号的显示如下图：
点击查询按钮后，系统显示“查询失败：商户订单号输入不正确”。
二、查询得到订单，如下图：
但第三种情况，某些存在且更新异常的订单，仍然提示 “查询失败:操作失败，请稍候重试”，则比较让人疑惑，如果按照字面的稍候重试去理解，则永远的答案都会是显示这一句话。客服咨询的回复和社区的求助目前也没有太理想的答案，这也在预期之中。
如引子里提供的订单号为：3328e4bae5ee40f5b6ff2fcd2782d5d8 的订单，则属于更为极端的一种情况，根据客户的反馈，通过系统其它的信息比对及排查（如支付时间、支付银行等），最终确定订单号为：3aa33681f24a41139a79e6ce431adf82，这种情况就难以解释了。
应对
目前来看，查询订单的结果无非这三种情况，无论何种情况，我们需要以下几点应对方案：
（1）建立日志跟踪机制是必不可少的，我们以 MS SQL SERVER 举例建立类似如下表：
| 序号 | 字段名 | 类型 | 说明 |
|---|---|---|---|
| 1 | project_cid | uniqueidentifier | 项目ID，连接项目活动表 |
| 2 | projectName | [nvarchar](100) | 项目名称（冗余字段） |
| 3 | per_cid | uniqueidentifier | 个人ID，连接个人详情表 |
| 4 | payName | [nvarchar](50) | 交费项目名称 |
| 5 | price | [money] | 交费金额 |
| 6 | orderid | [nvarchar](50) | 订单号 |
| 7 | ordertime | [datetime] | 订单交易时间 |
| 8 | openid | [nvarchar](50) | 微信个人openid标识 |
| 9 | err_msg | [nvarchar](500) | 微信支付API返回消息 |
| 10 | status | [nvarchar](50) | 支付状态，可设置消费交易成功、消费交易失败、待支付等 |
| 11 | paytime | [datetime] | 支付时间 |
| 12 | paytype | [nvarchar](10) | 支付类型，可包括消费、退款 |
| 13 | nickname | [nvarchar](100) | 个人微信昵称（冗余字段，便于排查） |
| 14 | rorderid | [nvarchar](50) | 微信返回的退款订单号 |
| 15 | cid | uniqueidentifier | 日制记录唯一标识 |
（2）建立对帐排查功能
如下图登录微信支付商户平台，进入交易中心、交易订单、批量订单查询、输入或选择交易时间范围，点击查询
我们可以下载 Excel 格式的文件，如下图：
下载的文件为CSV格式，我们可以根据实际需求转存为XLSX格式，通过读入EXCEL数据或导入数据库，与自己的业务表（如交易表、交易日志表）进行关键字比对（如订单号、微信用户openid）等，以排查异常数据进行提醒与处理。
（3）实现手工更新功能，手动更新是最后的处理方式，可以根据前面所述的排查结果单一或批量进行更新，更新的时候可以做好日志记录及标记标注等操作。
（4）对于示例中所叙述的极端情况，我们尽量还是要创建有意义的可用于后期可排查的订单号，微信订单号要求是32位数字，我们可以基于这个规则进行分段拼接，如连接个人信息表中的ID，加项目编号 加 时间戳信息，以免被动的无法主动跟踪交易信息，无法联系交易当事人的情况。
小结
在微信支付交易开发的过程中，我们会遇到很多种情况，需要不断的根据问题反馈来完善我们的应用系统 ，相关开发可参考我的文章：
《C# 实现微信退款及对帐》
《C# 微信支付接口V2版本回调开发实践》
以上是本人的一些体会与实践，再次感谢您的阅读，欢迎讨论、指教！
)
（更新中……）)
