35-尚硅谷-支付宝支付-统一收单线下交易查询

这节课呢，我们再来看一下支付接口当中的这个时序图，那么它呢，是一个完整的支付流程，我们已经完成了下单发起支付请求。登录。确认支付以及返回同步参数和返回异步通知参数的这样的一个过程，那么在返回异步通知参数的过程当中呢，我们做到的呢，是支付宝端给我们的商户端发送一个异步通知，那么来通知我们这次支付宝的支付呢是成功的，那么有一种情况呢，就是当我们的商户端迟迟没有接收到这个通知的时候，那么没有接收到这个通知情况有很多，一个呢是支付宝端可能他没有成功的发送通知，系统出现了问题，第二个呢，就是我们的商户端可能这边的网络出现了问题，没有成功的接收到这个通知，那么这种情况怎么办呢？我们可以主动的向支付宝端发起一个查单请求，来进行订单状态的查询，所以接下来呢，我们就来开发一个查单接口。

好，我们打开支付宝的API哈，那么这个里面呢，有一个叫做统一收单线下交易查询接口，所以呢，接下来我们就要调用这个接口了，那么首先呢，第一个步骤我们在阿里配controller里面呢，去创建一个查询订单的接口，那么这个查询订单的接口呢，实际上我们可以参考之前我们的微信配controller了哈，这个里面有一个查询订单的接口，我们直接把它复制过来就可以了。好，那这边呢，就是我们的查询订单的方式，那么这边呢，我们先不用去抛出这个异常啊。好，那这个位置呢，我们给它改成阿里pay service，那么未来呢，我们将会在阿里配service里面呢，去创建一个query order的方法，然后呢，如果订单查询成功了，我们就把查询到的这个订单的数据呢返回到前端，那我们一会儿呢，先在slide当中对它做一个测试。

那么接下来呢，我们把get map这个URL地址呢，也给他做一个修改，我们统一收单线下交易查询接口，它的名字呢，叫。阿里配trade query，所以我们将这个地址呢改成trade query哈。好，那这是我们的接口的一个定义，接下来呢，我们再来定义我们的业务层，那业务层呢，就是这个query order。好，接下来呢，我们来实现它具体的这个业务层的方法。那我们写一个注释，这个注释呢，就是查询订单。

然后我们呢，把这个。具体的查询订单的这个流程呢，给他做一个实现，那么同样微信配controller这个里面呢，我们当时做的这个查单的接口呢，其实就是整个的这样一个流程了，我们先打印日志，然后呢调用微信端的查单接口，最后呢，把查询出来的这个订单的结果呢，啊返回给我们的controller端，那我们也类似这样去做一个业务的实现，所以我们先把日志这个打印出来，然后中间这一部分调用接口，因为我们调用的是支付宝端的查单接口，所以呢，我们打开支付宝端的这个统一收单线下交易查询。我们打开它的这个。代码案例。复制一下，复制到我们的应用程序当中好。那么我们来看一下，首先阿里pay client和之前一样，不需要我们去创建，所以我们直接把它删掉就可以了，然后接下来这个位置呢，我们创建了一个阿里配trade query request对象，那么这个呢，就是我们的业务参数的组装了，那么我们的业务参数呢，我们来看一下。

在前面的请求参数这个位置呢，业务参数呢，也是两个特殊可选，那么很显然out trade number和trade number二选一就可以了，所以这个地方呢，我们依然选择out trade number，我们可以直接把order number。传入到这个位置，那这样的话呢，我们的业务参数呢，就组装好了，最后呢，我们把业务参数通过阿里pay client提交请求，然后得到结果，那么同样这个execute呢，我们来做一个异常的补货，好在这个位置呢，我们处理一下这异常跟之前一样哈。

我们把这个直接复制过来。好，然后接下来呢，这面的异常呢，我们暂时先抛出来啊，后面我们再看一看，应该具体怎么去处理，然后这面呢，我们需要得到一个结果啊，返回一个订单状态的这么一个字符串，所以呢，我们直接把response掉，Get body呢给它返回到我们的controller，好，这样的话呢，我们的查单接口呢，就写好了，我们重启一下服务器。好，服务器已经启动成功了，那么我们如何进行测试呢？首先我们来看一下我们这个查单功能应该什么时候去调用哈，我们看这个图。

那我们说当我们迟迟接收不到支付宝端给我们发送的内部通知的时候呢，我们就要进行查单，那这个查单呢，并不是我们通过某一个按钮主动调用的，是我们通过一个定时任务主动调用的哈，那比如说我们五分钟内没有接收到支付宝返回的异步通知参数，那么我们呢，就会通过我们的查单接口去实际的查询一下我们的这个订单的状态了，好，那所以呢，这个定时任务呢，我们可以定义为五分钟，好那定时任务一会我们再开发，所以现在呢，我们还没有开发定时任务的前提下呢，我们就直接先用swa来对我们的查单的功能呢进行一个测试，看一看呢，它能不能正常的返回给我们订单状态哈，好，接下来呢，我们来做这个查单的测试，那么我们访问swa。我们后端接口的地址呢，是8090，好，我们找到网站支付宝支付。

这个API列表，然后在这个里面呢，找到刚才我们创建的。查询订单这样的一个接口，那么我们需要在这个地方呢，输入一个订单号，这个测试呢，我们来创建一个全新的订单号，我们点击购买课程啊，这次我们买一个UI的课程吧，然后我们选择支付宝，选择确认支付。好，这个时候呢，他已经展示了一个支付宝的二维码，那么我们分别呢，测试几种不同的情况，我们先测试这种情况，这个时候他展示完支付宝的二维码之后，我还并没有进行扫码支付，根据我们之前学习关闭订单接口的时候的啊，我们获取到的这个信息呢，我们知道在我们本地。有一个订单呢，已经生成了，我们来看一下数据库，那就是这个UI课程哈，他的订单号呢，是4760这个订单号，那这是我们本地的订单，他的订单状态呢，是未支付的状态，好，但是因为我还没有进行扫码，那我呢也没有进行账户名的登录，所以支付宝端呢，其实并没有这个订单，那因此呢，我们查询订单的时候呢，应该是订单不存在的，所以呢，我们来试验一下是不是这样的一个结果，我们把这个订单号复制一下。

复制到我们的sla的。测试的这个窗口当中，接下来我们点击try it out。那么我们会发现它就报告了错误啊，是500错误，然后呢，Internal so I哈，那这个呢，其实是我们已知的这样的一个可能会发生的问题，我们来看一下这个日志，他说。调用失败返回码呢是40004，返回描述呢是business field，然后上面呢，它也给我们返回了，和之前我们调用关单接口一样，同样的一个错误信息，就是交易不存在，那所以呢，我们可以在我们的业务代码当中，对这个查询订单的这个业务呢，进行一个简单的修改，那么刚才报告交易部存在的这个位置呢。

是167行哈，这块else这块我们呢，其实应该把它改成查单接口调用时代，但是呢，实际上这个位置呢，我不想让他抛出一个异常啊，那我呢是想如果是查单接口调用失败的话呢，就说明订单不存在，那如果是订单不存在的话呢，那么我这边呢，就返回一个量值哈，表示的是订单不存在，好，那下面这款如果开的过程当中出现异常了，那么我们在这个地方呢，也给它改成查单接口调用失败。好，接下来呢，我重新启动一下这个应用程序。

那我在这边的返回值这块，我给它做一个标注啊，返回应该查询结果如何，返回了则表示支付宝端尚未创建订单，好。那接下来我们再对我们刚才修改的这个版本的代码呢，进行一个测试，所以呢，我们再来到我们的slo这一端，然后我们点击try it out，我们会发现呢，这个时候它返回的就是lunch了，表示支付宝端尚未创建这个订单，那其实呢，也就意味着订单不存在哈，好，那接下来呢，我对刚才咱们的这个二维码呢进行一个扫码，扫码呢暂时不支付，我们来看一看我们的查看结果，所以呢，我还是打开支付宝的杀方版。

好，我已经进行了一个扫码了啊，那这个地方呢，显示扫码成功，但是呢，我没有付款，那我们来到Spark UI，你点击try it out看一下它查询的结果，那么这面呢，查询结果当中呢，有一个字段，这个字段呢是我们来找一下哈，叫trade status，它的值呢是wait by pay，就是等待。买家付款，我们来看一下支付宝的文档，统一收单线下交易查询接口的响应参数，响应参数里面呢，有一个参数就是trade status，那么wait better pay，它确实就是交易已创建了，但是呢在等待买家付款这样的一个情况，那接下来呢，我呢把这个订单关闭掉，我们看一看我们查询的结果是不是trade close的哈，好，那么我们来到。

我们的系统的订单列表页面，然后我们把刚才这个UI课程的这笔订单呢，给它取消掉。好，这个时候呢，是用户已取消的状态，接下来呢，我们再对这笔订单进行一个查询，好查询成功我们再来看一下。我们的订单状态trade status，那么现在呢，这个订单状态呢，就是trade closed，那么对应我们的文档就是这第二个值了trade closed，好，最后呢，我们来测试一下trade success。我们打开我们的支付案例，还是选择UI课程，选择支付宝，这回呢，我们发起一笔支付哈，我们来进行付款操作。好，我打开我的支付宝沙箱法进行扫码。

稍等一下啊好，那这边呢，已经提示我立即付款了，那我现在呢，点击立即付款。输入密码六个一。好，现在呢，我已经支付成功了。好，那我们看到我们的页面呢，也发生了跳转。好，这个时候呢，它就会返回到我们的商户页，我们等待它返回吧。因为是沙箱版哈，不是我们的正式的系统，所以呢，它支付宝这边呢，响应的速度呢也慢一些，那现在呢，我们已经展示了支付成功，我们来看一下我的订单，我们的本地订单呢，它的状态呢，已经变成了支付成功，好，那接下来呢，我们来查询这笔订单，这笔订单呢是一个新的订单，我们把这个订单号呢复制一下，然后来到我们的WERUI当中，将这个订单号复制过来，我们点击try it out。

那我们来看一下这笔订单的订单状态。我们会发现呢，这个订单的订单状态呢，就是去的success好，我们。再对比一下这个文档，那文档当中呢，第三个状态就是trade success，那么还有一个状态呢，是trade finish，那我们的电脑网站支付目前为止呢，是交易可退款的情况哈，所以呢，它不存在这种去finish的这种状态啊，那也就是说不可能会有这种状态出现，所以说呢，这个状态我们就不去做测试了，好，那以上呢，就是我们对之前我们开发的统一收单线下交易查询接口的一个具体的测试。