订单处理方法、装置、设备及计算机可读存储介质与流程

1.本公开的实施例涉及智慧交通技术，尤其涉及一种订单处理方法、装置、设备及计算机可读存储介质。


背景技术：

2.随着网络的发展，网约车逐渐走进了大众的生活，乘客可以在网约车平台上进行车辆的呼叫、预约等操作。当行程结束后，由于部分区域的乘客在网约车平台上没有绑定线上支付渠道，因此，仅能够采用现金支付的方式完成对行程的结算操作。但是，部分乘客可能由于某些原因无法完成支付，导致司机无法得到相应的酬劳。
3.为了解决上述问题，现有技术中一般都是由网约车平台垫付司机端的车费。具体地，若司机超过预设的时间没有收到乘客支付的车费，则可以对该乘客发起投诉信息，网约车平台在接收到该投诉信息之后，可以对该司机进行赔偿。
4.但是，采用上述方法进行订单处理的过程中，一方面司机可能存在对乘客的恶意投诉，导致了网约车平台不必要的损失。另一方面，上述方法无法有效地约束乘客进行结算操作。


技术实现要素：

5.本公开的实施例提供一种订单处理方法、装置、设备及计算机可读存储介质，用以解决现有的订单处理方法无法识别恶意投诉导致的订单处理精度不高的技术问题。
6.一方面，本公开的实施例提供一种订单处理方法，包括：
7.当检测到乘客调用目标应用时，判断所述乘客是否存在待支付订单，所述待支付订单是根据司机触发的投诉请求生成的；
8.若所述乘客存在待支付订单，则在预设的数据服务器中查询所述乘客在预设的时间范围内被投诉的次数；
9.根据所述乘客在预设的时间范围内被投诉的次数，控制所述乘客的终端设备显示不同的操作界面，以使所述乘客在不同的操作界面上对所述待支付订单进行支付操作或者发起车辆呼叫请求。
10.另一方面，本公开的实施例提供一种订单处理装置，包括：
11.判断模块，用于当检测到乘客调用目标应用时，判断所述乘客是否存在待支付订单，所述待支付订单是根据司机触发的投诉请求生成的；
12.查询模块，用于若所述乘客存在待支付订单，则在预设的数据服务器中查询所述乘客在预设的时间范围内被投诉的次数；
13.处理模块，用于根据所述乘客在预设的时间范围内被投诉的次数，控制所述乘客的终端设备显示不同的操作界面，以使所述乘客在不同的操作界面上对所述待支付订单进行支付操作或者发起车辆呼叫请求。
14.另一方面，本公开的实施例提供一种订单处理设备，包括：存储器和处理器；
15.所述存储器用于存储程序指令；
16.所述处理器用于调用所述存储器中的程序指令执行如第一方面所述的订单处理方法。
17.另一方面，本公开的实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序；所述计算机程序被执行时，实现如第一方面所述的订单处理方法。
18.另一方面，本公开的实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现如第一方面所述的订单处理方法。
19.本公开的实施例提供的订单处理方法、装置、设备及计算机可读存储介质，通过当检测到乘客调用目标应用时，判断乘客是否存在待支付订单。如果该乘客存在待支付订单，则在预设的数据服务器中查询该乘客在预设的时间范围内被投诉的次数，并根据该被投诉的次数，控制乘客的终端设备显示不同的操作界面，从而可以使乘客在不同的操作界面上对待支付订单进行支付操作或者发起车辆呼叫请求。通过针对不同的被投诉次数，控制乘客的终端设备显示不同的操作界面，进而能够有效地约束乘客对待支付账单进行支付操作，从而能够有效地避免用户多次完成订单后不付款给网约车以及司机带来的损失。
20.本公开的各种可行实施例及其技术优势将在下文详述。
附图说明
21.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
22.图1为本公开基于的网络架构示意图；
23.图2为本公开实施例一提供的订单处理方法的流程示意图；
24.图3为本公开实施例提供的显示界面示意图；
25.图4为本公开实施例提供的界面交互示意图；
26.图5为本公开实施例提供的又一交互界面示意图；
27.图6为本公开实施例提供的又一显示界面示意图；
28.图7为本公开实施例提供的又一界面交互示意图；
29.图8为本公开实施例四提供的订单处理装置的结构示意图；
30.图9为本公开实施例五提供的订单处理装置的结构示意图。
31.通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。
具体实施方式
32.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
33.针对上述提及的现有的订单处理方法无法识别恶意投诉导致的订单处理精度不
高的技术问题，本公开提供了一种订单处理方法、装置、设备及计算机可读存储介质。
34.需要说明的是，本公开提供订单处理方法、装置、设备及计算机可读存储介质可运用在各种网约车订单处理的场景中。
35.由于部分乘客在使用网约车之后，不会及时结算，从而会导致网约车平台和司机承受不必要的经济损失。为了解决上述技术问题，现有技术中一般都是由司机对未及时计算的订单发起投诉，网约车平台在接收到投诉信息之后，向司机垫付费用。但是，上述方法往往会造成网约车平台的损失，且无法约束乘客进行付费。
36.在解决上述技术问题的过程中，发明人通过研究发现，在用户触发目标应用时，可以根据乘客的历史评价信息，向用户展示不同的操作界面，从而用户可以根据不同的操作界面进行不同的订单处理操作，从而能够有效地约束乘客对待支付账单进行支付操作，进而能够有效地避免用户多次完成订单后不付款给网约车以及司机带来的损失。
37.下面对本公开实施例的订单处理方法对应的网络架构图进行说明。
38.图1为本公开基于的网络架构示意图，如图1所示，该网络架构包括：终端设备1、服务器2以及数据服务器3，其中，服务器2中设置有订单处理装置。该订单处理装置可采用c/c++、java、shell或python等语言编写；终端设备1则可例如台式电脑、平板电脑等。数据服务器3则可为云端服务器等。服务器2分别与终端设备1以及数据服务器3通信连接，从而能够分别与终端设备1以及数据服务器2进行信息交互。
39.下面以具体地实施例对本公开的实施例的技术方案以及本公开的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本公开的实施例的实施例进行描述。
40.实施例一
41.图2为本公开实施例一提供的订单处理方法的流程示意图，如图1所示，该方法包括：
42.步骤101、当检测到乘客调用目标应用时，判断所述乘客是否存在待支付订单，所述待支付订单是根据司机触发的投诉请求生成的。
43.本实施例的执行主体为订单处理装置，该订单处理装置可耦合于服务器中。服务器可以与乘客的终端设备通信连接，从而能够与终端设备进行信息交互。
44.在本实施方式中，当乘客想要选择网约车出行时，可以在终端设备上调用目标应用进行车辆的呼叫。具体地，订单处理装置当检测到乘客调用目标应用时，可以判断该乘客是否存在待支付订单，其中，该待支付订单具体可以为根据司机触发的投诉请求生成的。
45.步骤102、若所述乘客存在待支付订单，则在预设的数据服务器中查询所述乘客在预设的时间范围内被投诉的次数。
46.在本实施方式中，当乘客完成一次网约车的使用之后，若乘客没有支付车费，司机可以触发对该乘客的投诉请求。
47.因此，订单处理装置在判断出乘客存在待支付订单之后，可以根据该待支付订单中的乘客标识信息，在预设的数据服务器中查询该乘客在预设的时间范围内被投诉的次数。其中，该数据服务器中存储有全部乘客对应的被投诉的次数信息。
48.此外，预设的时间范围可以为一周、一个月或是其他合适的时间范围，本公开实施
例在此不作限定。
49.步骤103、根据所述乘客在预设的时间范围内被投诉的次数，控制所述乘客的终端设备显示不同的操作界面，以使所述乘客在不同的操作界面上对所述待支付订单进行支付操作或者发起车辆呼叫请求。
50.在本实施方式中，在获取到乘客在预设的时间范围内被投诉的次数之后，可以根据该乘客在预设的时间范围内被投诉的次数控制乘客的终端设备显示不同的操作界面，以使乘客在不同的操作界面上对待支付订单进行支付操作或者发起车辆呼叫请求。
51.举例来说，若乘客在预设的时间范围内被投诉的次数较少，则该乘客的终端设备显示的操作界面可以允许该乘客发起车辆呼叫请求。若乘客在预设的时间范围内被投诉的次数较多，则该乘客的终端设备显示的操作界面不允许该乘客发起车辆呼叫请求，但可以允许该乘客对待支付订单进行支付操作。
52.本实施例提供的订单处理方法，通过在当检测到乘客调用目标应用时，判断乘客是否存在待支付订单，并根据该待支付订单查询该乘客在预设的时间范围内被投诉的次数，从而后续可以根据该乘客在预设的时间范围内被投诉的次数控制乘客的终端设备显示不同的操作界面，以使乘客在不同的操作界面上对待支付订单进行支付操作或者发起车辆呼叫请求。通过针对不同的被投诉次数，控制乘客的终端设备显示不同的操作界面，进而能够有效地约束乘客对待支付账单进行支付操作，从而能够有效地避免用户多次完成订单后不付款给网约车以及司机带来的损失。
53.实施例二
54.为了进一步说明本公开实施例一提供的订单处理方法，具体地，在实施例一的基础上，步骤103具体包括：
55.若所述乘客在预设的时间范围内被投诉的次数不超过预设的第一阈值，则控制所述乘客的终端设备显示预设的第一操作界面，所述第一操作界面上设置有支付图标以及投诉图标，以使所述乘客在所述第一操作界面发起车辆呼叫请求。在本实施例中，如果乘客在预设的时间范围内被投诉的次数不超过预设的第一阈值，则表明该乘客的信用较高，大部分的订单都已完成了支付，此时，订单处理装置可以控制该乘客的终端设备显示预设的第一操作界面。
56.具体地，该第一操作界面上设置有支付图标以及投诉图标，从而使该乘客在该第一操作界面完成支付后，便可发起车辆呼叫请求。其中，该预设的第一阈值可以为运维人员根据实际需求进行设置。
57.图3为本公开实施例提供的显示界面示意图，如图3所示，若乘客在预设的时间范围内被投诉的次数不超过预设的第一阈值，则表征该乘客大部分的订单都已完成了支付。因此，针对这类信用较高的乘客，可以基于该类乘客多种选择。因此，可以在显示界面上显示支付图标以及投诉图标。
58.通过上述方式，可以为信用较高的乘客提供能够发起车辆呼叫请求的第一操作界面，从而有效保证信用较高的乘客的用车需求。
59.进一步地，在上述任一实施例的基础上，所述控制所述乘客的终端设备显示所述乘客的终端设备显示预设的第一操作界面之后，还包括：
60.响应于所述乘客对所述支付图标的触发操作，在所述显示界面上显示预设的合并
支付图标以及立即支付图标；响应于所述乘客对所述合并支付图标的触发操作，在所述显示界面上显示第三操作界面，以使所述乘客在所述第三操作界面上发起车辆呼叫请求，并将所述待支付订单的费用支付给所述车辆的司机；响应于所述乘客对所述立即支付图标的触发操作，在所述显示界面上显示绑定支付渠道的提示信息，以使所述乘客根据所述提示信息完成支付渠道的绑定，在检测到所述乘客完成支付渠道的绑定后，通过所述支付渠道对所述待支付订单进行处理，在检测到所述乘客完成对所述待支付订单的支付操作之后，在所述显示界面上显示第三操作界面，以使所述乘客在所述第三操作界面上发起车辆呼叫请求。
61.具体地，图4为本公开实施例提供的界面交互示意图，如图4所示，若检测到乘客点击了支付图标，则可以根据乘客的触发操作，在显示界面上显示预设的合并支付图标以及立即支付图标。
62.图5为本公开实施例提供的又一交互界面示意图，如图5所示，由于该类乘客的信用较好，因此，可以允许该类客户将未支付车费合并至下一笔订单一起支付。当检测到用户触发合并支付图标之后，可以将该待支付行程的未支付车费信息以现金的形式支付给司机，由司机进行代收。当检测到用户触发立即支付，则可以选择线上支付的方式对该待支付行程的未支付车费信息进行支付。
63.具体地，订单处理装置可以在显示界面上显示绑定支付渠道的提示信息，以使乘客根据提示信息完成支付渠道的绑定，在检测到乘客完成支付渠道的绑定后，可以通过该支付渠道对待支付订单进行处理。在检测到该乘客完成对该待支付订单的支付操作之后，订单处理装置可以控制显示界面上显示第三操作界面，以使该乘客在第三操作界面上发起车辆呼叫请求。
64.进一步地，在实施例二的基础上，所述控制所述乘客的终端设备显示所述乘客的终端设备显示预设的第一操作界面之后，还包括：
65.响应于所述乘客对所述投诉图标的触发操作，在所述显示界面上显示第三操作界面，以使所述乘客在所述第三操作界面上发起车辆呼叫请求；对触发所述投诉请求的司机在预设的时间范围内被投诉的次数进行分析，获得分析结果；根据所述分析结果对所述待支付订单进行处理。
66.在本实施例中，为了避免司机为了获取网约车平台的垫付款而对用户进行恶意投诉，当检测到用户对投诉图标的触发操作之后，可以对触发该投诉请求的司机在预设的时间范围内被投诉的次数进行分析，并获得分析结果。可选地，若司机在预设的时间范围内多次被乘客投诉，则可以通过触发投诉图标实现对司机的投诉。此外，还可以直接根据订单处理请求为该乘客呼叫车辆。
67.进一步地，在上述任一实施例的基础上，所述对触发所述投诉请求的司机在预设的时间范围内被投诉的次数进行分析，获得分析结果，包括：判断所述司机在预设的时间范围内被投诉的次数是否超过预设的第二阈值；若所述司机在预设的时间范围内被投诉的次数超过预设的第二阈值，则判定所述投诉请求为恶意投诉请求，获得所述分析结果；若所述司机在预设的时间范围内被投诉的次数不超过预设的第二阈值，则判定所述投诉请求为正常投诉请求，获得所述分析结果。
68.在本实施例中，为了准确判断投诉请求为恶意投诉请求还是正常投诉请求，订单
处理装置可以判断司机在预设的时间范围内被投诉的次数是否超过预设的第二阈值。相应地，如果该司机在预设的时间范围内被投诉的次数超过预设的第二阈值，说明有很多乘客对该司机进行过投诉，则判定该司机的投诉请求为恶意投诉请求，并获得分析结果。相反，如果该司机在预设的时间范围内被投诉的次数不超过预设的第二阈值，说明只有少量乘客对该司机进行过投诉，则判定该司机的投诉请求为正常投诉请求，并获得分析结果。
69.其中，该预设的第二阈值可以为运维人员根据实际需求进行设置。
70.进一步地，在上述任一实施例的基础上，所述根据所述分析结果对所述待支付订单进行处理，包括：若所述投诉请求为恶意投诉请求，则删除所述乘客对应的待支付订单；若所述投诉请求为正常投诉请求，则在所述乘客下一笔订单结束后，通过调用预设的收银台接口，获取所述乘客对应的待支付金额，所述待支付金额包括待支付订单对应的金额以及下一笔订单对应的金额，控制所述乘客的终端设备显示所述待支付金额，使得所述乘客将所述待支付金额支付给所述下一笔订单的司机。
71.在本实施例中，如果订单处理装置判断出司机的投诉请求为恶意投诉请求，则说明该乘客对应的待支付订单，为该司机为了获取网约车平台的垫付款而对用户进行恶意投诉，进而产生的无效待支付订单，因此订单处理装置可以删除该乘客对应的待支付订单。
72.如果订单处理装置判断出司机的投诉请求为正常投诉请求，则说明该乘客对应的待支付订单为有效的待支付订单，因此，为了保证该乘客可以尽快对该待支付账单进行支付，并避免该乘客再次逃单，从而造成司机与网约车平台的损失，在该乘客下一笔订单结束后，可以通过调用预设的收银台接口，获取该乘客对应的待支付金额，并控制该乘客的终端设备显示该待支付金额，使得该乘客可以将该待支付金额支付给下一笔订单的司机。具体地，该待支付金额可以包括待支付订单对应的金额以及下一笔订单对应的金额。
73.需要说明的是，乘客可以选择线上支付或者现金支付。当选择现金支付时，乘客可以将该待支付金额的现金支付给司机，由司机进行代收。获取司机终端设备触发的支付完成指令，根据该支付完成指令，从司机的账户中对待支付订单、未支付行程对应的金额进行扣除。并且根据该预估车费，按照预设的分账比例将司机应得的目标车费转账给司机的账户。
74.本实施例提供的订单处理方法，通过判断乘客在预设的时间范围内被投诉的次数，控制乘客的终端设备显示预设的操作界面，并根据乘客对投诉图标的触发操作的响应，判断投诉请求是否为恶意投诉请求，进而对乘客的待支付账单做出不同处理，从而既避免了乘客重复支付账单，又能够有效地约束乘客对待支付账单进行支付操作，进一步避免了司机与网约车平台的损失。
75.实施例三
76.为了进一步说明本公开实施例一提供的订单处理方法，具体地，在实施例一的基础上，步骤103还包括：
77.若所述乘客在预设的时间范围内被投诉的次数超过预设的第一阈值，则控制所述乘客的终端设备显示预设的第二操作界面，所述第二操作界面中设置有立即支付图标，以使所述乘客在所述第二操作界面对所述待支付订单进行支付操作。
78.在本实施例中，若乘客在预设的时间范围内被投诉的次数超过预设的第一阈值，也即该乘客多次因为未支付车费被司机投诉，则表征该乘客的信用较差，因此，为了避免不
必要的损失，当接收到该类乘客触发的订单处理请求时，为了保证该乘客能够正常用车，订单处理装置可以控制该乘客的终端设备显示预设的第二操作界面。只有乘客通过点击该支付图标完成对未支付行程的支付操作，才能够进行下一步的用车。
79.具体地，该第二操作界面中设置有立即支付图标，以使乘客可以在该第二操作界面对待支付订单进行支付操作。
80.图6为本公开实施例提供的又一显示界面示意图，如图6所示，若乘客在预设的时间范围内被投诉的次数超过预设的第一阈值，表征该乘客在预设的时间范围内可能多次未进行订单的支付，因此，需要在该乘客完成对未支付行程的支付操作之后，再对该乘客的订单处理请求进行处理操作。因此，可以控制终端设备显示第二操作界面，其中，该第二操作界面中仅包括支付图标。乘客可以通过点击该支付图标完成对未支付行程的支付操作。
81.进一步地，在上述实施例三的基础上，所述控制所述乘客的终端设备显示预设的第二操作界面之后，还包括：响应于所述乘客对所述立即支付图标的触发操作，在所述显示界面上显示绑定支付渠道的提示信息，以使所述乘客根据所述提示信息完成支付渠道的绑定；在检测到所述乘客完成支付渠道的绑定后，通过所述支付渠道对所述待支付订单进行处理；当检测到所述乘客完成对所述待支付订单的支付操作之后，在所述显示界面上显示第三操作界面，以使所述乘客在所述第三操作界面上发起车辆呼叫请求。
82.图7为本公开实施例提供的又一界面交互示意图，如图7所示，当检测到用于触发立即支付图标之后，可以在显示界面上显示绑定支付渠道的提示信息，以使乘客根据提示信息完成支付渠道的绑定，在检测到所述乘客完成支付渠道的绑定后，便可通过该支付渠道对待支付订单进行处理，进一步地，当检测到乘客完成对待支付订单的支付操作之后，在显示界面上显示第三操作界面，以使乘客可以在第三操作界面上发起车辆呼叫请求。
83.进一步地，在上述任一实施例的基础上，所述在检测到所述乘客完成支付渠道的绑定后，通过所述支付渠道对所述待支付订单进行处理，包括：通过预设的收银台调用接口，获取所述未支付行程对应的费用信息，在所述显示界面上显示所述未支付车费信息；通过所述支付渠道支付所述未支付车费信息。
84.在本实施例中，为了能够使用户更加直观地对需要支付的费用的查看，在控制显示界面显示第二操作界面之后，可以通过预设的收银台调用接口，获取该乘客未支付行程对应的未支付车费信息。当检测到乘客对支付图标的触发操作之后，可以根据该触发操作，在显示界面上显示该未支付车费信息。进而乘客可以通过该支付渠道支付未支付车费信息。本实施例提供的订单处理方法，通过判断乘客在预设的时间范围内被投诉的次数超过预设的第一阈值，则在该乘客完成对未支付行程的支付操作之后，再对该乘客的订单处理请求进行处理操作，从而能够有效地避免乘客不对历史订单进行支付的问题，通过限制用车实现对乘客的约束，极大地避免了司机与网约车平台的损失。
85.进一步地，在上述任一实施例的基础上，所述在所述显示界面上显示第三操作界面之后，还包括：获取所述乘客在所述第三操作界面上输入的行程信息，所述行程信息包括出发地以及目的地；根据所述行程信息生成所述车辆呼叫请求。
86.在本实施例中，在显示界面上显示第三操作界面之后，订单处理装置可以获取乘客在第三操作界面上输入的行程信息，其中，该行程信息可以包括出发地和目的地。因此，当获取到用户触发的车辆呼叫请求之后，可以根据该车辆呼叫请求为乘客呼叫车辆，并根
据行程信息预估出乘客本次行程对应的预估车费。
87.本实施例提供的订单处理方法，通过获取乘客在第三操作界面上输入的行程信息为乘客呼叫车辆，从而保障了乘客的准确出行，提高了用户体验。
88.实施例四
89.图8为本公开实施例四提供的订单处理装置的结构示意图，如图8所示，该装置包括：判断模块51、查询模块52以及处理模块53，其中，判断模块 51，用于当检测到乘客调用目标应用时，判断所述乘客是否存在待支付订单，所述待支付订单是根据司机触发的投诉请求生成的；查询模块52，用于若所述乘客存在待支付订单，则在预设的数据服务器中查询所述乘客在预设的时间范围内被投诉的次数；处理模块53，用于根据所述乘客在预设的时间范围内被投诉的次数，控制所述乘客的终端设备显示不同的操作界面，以使所述乘客在不同的操作界面上对所述待支付订单进行支付操作或者发起车辆呼叫请求。
90.进一步地，在实施例四的基础上，所述处理模块用于：若所述乘客在预设的时间范围内被投诉的次数不超过预设的第一阈值，则控制所述乘客的终端设备显示所述乘客的终端设备显示预设的第一操作界面，所述第一操作界面上设置有支付图标以及投诉图标，以使所述乘客在所述第一操作界面发起车辆呼叫请求。
91.本实施例提供的订单处理装置，通过当检测到乘客调用目标应用时，判断乘客是否存在待支付订单。如果该乘客存在待支付订单，则在预设的数据服务器中查询该乘客在预设的时间范围内被投诉的次数，并根据该被投诉的次数，控制乘客的终端设备显示不同的操作界面，从而可以使乘客在不同的操作界面上对待支付订单进行支付操作或者发起车辆呼叫请求。通过针对不同的被投诉次数，控制乘客的终端设备显示不同的操作界面，进而能够有效地约束乘客对待支付账单进行支付操作，从而能够有效地避免用户多次完成订单后不付款给网约车以及司机带来的损失。
92.进一步地，在实施例四的基础上，所述订单处理装置还包括：显示模块 54，用于响应于所述乘客对所述支付图标的触发操作，在所述显示界面上显示预设的合并支付图标以及立即支付图标；响应于所述乘客对所述合并支付图标的触发操作，在所述显示界面上显示第三操作界面，以使所述乘客在所述第三操作界面上发起车辆呼叫请求，并将所述待支付订单的费用支付给所述车辆的司机；响应于所述乘客对所述立即支付图标的触发操作，在所述显示界面上显示绑定支付渠道的提示信息，以使所述乘客根据所述提示信息完成支付渠道的绑定，在检测到所述乘客完成支付渠道的绑定后，通过所述支付渠道对所述待支付订单进行处理，在检测到所述乘客完成对所述待支付订单的支付操作之后，在所述显示界面上显示第三操作界面，以使所述乘客在所述第三操作界面上发起车辆呼叫请求。
93.进一步地，在上述任一实施例的基础上，所述显示模块还用于，响应于所述乘客对所述投诉图标的触发操作，在所述显示界面上显示第三操作界面，以使所述乘客在所述第三操作界面上发起车辆呼叫请求。
94.所述处理模块还用于，对触发所述投诉请求的司机在预设的时间范围内被投诉的次数进行分析，获得分析结果；根据所述分析结果对所述待支付订单进行处理。
95.进一步地，在上述任一实施例的基础上，所述处理模块具体用于，判断所述司机在预设的时间范围内被投诉的次数是否超过预设的第二阈值；若所述司机在预设的时间范围内被投诉的次数超过预设的第二阈值，则判定所述投诉请求为恶意投诉请求，获得所述分
component，简称为pci)总线或扩展工业标准体系结构(extended industry standard architecture，简称为eisa)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
108.可选的，在具体实现上，如果存储器61和处理器62集成在一块芯片上实现，则存储器61和处理器62可以通过内部接口完成相同间的通信。
109.本公开又一实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现如上述任一实施例所述的方法。
110.本公开又一实施例还提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现如上述任一实施例所述的方法。
111.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开的实施例旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求书指出。
112.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。