针对弱联网的订单处理方法、电子设备和存储介质与流程

1.本技术涉及数据处理技术领域，尤其涉及一种针对弱联网的订单处理方法、电子设备和存储介质。

背景技术：

2.在弱联网游戏环境中可能会遇到用户在支付时与支付服务器断连或者用户强制退出游戏的场景，在这种情况下，可能会存在漏单、逃单等问题。因此能够及时发现漏单、逃单等问题，提高用户游戏支付体验，是本领域需要解决的问题。

技术实现要素：

3.有鉴于此，本技术的目的在于提出一种针对弱联网的订单处理方法、电子设备和存储介质。
4.作为本技术的第一个方面，提供了一种针对弱联网的订单处理方法，通过客户端实现，包括：
5.响应用户针对所述客户端的启动操作，确定所述客户端中是否存在订单存档信息，若存在所述订单存档信息，则进一步确定所述订单存档信息的类型；
6.若所述订单存档信息为第一类订单存档信息，则向支付服务器发送获取所述第一类订单存档信息对应的第一支付结果信息的请求；
7.若所述订单存档信息为第二类订单存档信息，则向配给服务器发送获取所述第二类订单存档信息对应的配给结果信息的请求。
8.可选的，所述方法还包括：
9.响应用户的支付操作，构建所述第一类订单存档信息，并向所述支付服务器发送获取所述第一类订单存档信息对应的第一支付结果信息的请求；
10.接收所述支付服务器发送的所述第一支付结果信息，若所述第一支付结果信息为支付成功信息，则构建所述第二类订单存档信息，删除所述第一类订单存档信息，并向所述配给服务器发送执行所述第二类订单存档信息对应的配给的请求，若所述第一支付结果信息为支付失败信息，则删除所述第一类订单存档信息；
11.响应接收到所述配给服务器发送的所述配给结果信息，删除所述第二类订单存档信息。
12.作为本技术的第二个方面，提供了一种针对弱联网的订单处理方法，通过支付服务器实现，包括：
13.接收客户端发送的获取第一类订单存档信息对应的第一支付结果信息的请求，查询所述第一类订单存档信息对应的订单是否支付成功并生成所述第一支付结果信息，向所述客户端发送所述第一支付结果信息。
14.可选的，所述方法还包括：
15.接收配给服务器发送的获取第二类订单存档信息对应的第二支付结果信息的请
求，查询所述第二类订单存档信息对应的订单是否支付成功并生成所述第二支付结果信息，向所述配给服务器发送所述第二支付结果信息。
16.作为本技术的第三个方面，提供了一种针对弱联网的订单处理方法，通过配给服务器实现，包括：
17.接收客户端发送的获取第二类订单存档信息对应的配给结果信息的请求，查询所述第二类订单存档信息对应的订单是否配给成功并生成所述配给结果信息，向所述客户端发送所述配给结果信息。
18.可选的，所述方法还包括：
19.接收所述客户端发送的执行所述第二类订单存档信息对应的配给的请求，向支付服务器发送获取所述第二类订单存档信息对应的第二支付结果信息的请求，接收所述支付服务器发送的所述第二支付结果信息，若所述第二支付结果信息为支付成功信息，执行所述第二类订单存档信息对应的配给，并向所述客户端发送为配给成功的配给结果信息，若所述第二支付结果信息为支付失败信息，向所述客户端发送为配给失败的配给结果信息。
20.作为本技术的第四个方面，提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时可以实现本技术所提供的上述订单处理方法。
21.作为本技术的第五个方面，提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行本技术所提供的上述订单处理方法。
22.从上面所述可以看出，本技术提供的针对弱联网的订单处理方法、电子设备和存储介质，能够通过对用户支付信息的校验，进一步提高订单处理的准确性。
附图说明
23.为了更清楚地说明本技术或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
24.图1a为本技术实施例所提供的一种针对弱联网的通过客户端实现的订单处理方法示意图；
25.图1b为本技术实施例所提供的又一种针对弱联网的通过客户端实现的订单处理方法示意图；
26.图1c为本技术实施例所提供的客户端构建订单信息存档示意图；
27.图1d为本技术实施例所提供的一种支付界面示意图；
28.图2a为本技术实施例所提供的一种针对弱联网的通过支付服务器实现的订单处理方法示意图；
29.图2b为本技术实施例所提供的又一种针对弱联网的通过支付服务器实现的订单处理方法示意图；
30.图3a为本技术实施例所提供的一种针对弱联网的通过配给服务器实现的订单处理方法示意图；
31.图3b为本技术实施例所提供的又一种针对弱联网的通过配给服务器实现的订单处理方法示意图；
32.图4为本技术实施例所提供的一种针对弱联网的订单处理方法电子设备结构示意图。
具体实施方式
33.为使本技术的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本技术进一步详细说明。
34.需要说明的是，除非另外定义，本技术实施例使用的技术术语或者科学术语应当为本技术所属领域内具有一般技能的人士所理解的通常意义。本技术实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。
35.在游戏环境中，常见的漏单原因有两个：第一，当用户拟购买虚拟道具时，通常会将用户的支付存档信息上传到云端，但在弱联网环境中，可能会遇到用户在支付时与支付服务器断连，导致用户无法将存档信息正确上传到云端，因此游戏运营商在读取云端存档时可能会造成进度错误的情况；第二，用户在支付过程中强制主动杀死app使得再此启动时无法受到订单监听而导致漏单，给使用者造成不便。因此，因为通常情况下人工审核订单需要的时间过长，有的游戏运营商为了保障客户权益，通常会将游戏道具下发给客户，以此在还可能造成存在逃单的情况。
36.针对上述问题，本技术实施例提供了一种显针对弱联网的订单处理方法、电子设备和存储介质，该方法可能会在弱联网环境下减少产生漏单或者逃单的情况，增加用户的游戏体验。
37.图1a示出了本技术实施例所提供的一种针对弱联网的通过客户端实现的订单处理方法示意图。
38.图1b示出了本技术实施例所提供的又一种针对弱联网的通过客户端实现的订单处理方法示意图。
39.如图1a所示，在一些实施例中，用户打开游戏app，启动客户端100后，客户端100会进入unity iap模块初始化，unity iap模块初始化完成后，用户可以正常开始游戏。客户端100进入unity iap模块初始化的同时，也会启动订单校验程序s102，如图1b所示，客户端100的订单校验程序包括如下步骤：
40.s1022：响应用户针对所述客户端100的启动操作，确定所述客户端中是否存在订单存档信息，若存在所述订单存档信息，则进一步确定所述订单存档信息的类型；
41.s1024：若所述订单存档信息为第一类订单存档信息，则向支付服务器200发送获取所述第一类订单存档信息对应的第一支付结果信息的请求；
42.s1026：若所述订单存档信息为第二类订单存档信息，则向配给服务器300发送获取所述第二类订单存档信息对应的配给结果信息的请求。
43.在一些实施例中，客户端可以为用户提供游戏服务，支付服务器可以是官方支付程序或第三方支付平台，配给服务器可以是游戏运营商的游戏服务器。
44.可以理解的是，在游戏环境中，尤其是在弱联网环境中，客户端常常因为网络延迟等原因无法收到支付服务器返回的支付结果信息，或者用户还未收到配给服务器的配给结果时与配给服务器断联。因此在下次重连或重启游戏时，设置一个订单校验程序，能够有效监听支付结果，保障用户的权益。
45.图1c示出了本技术实施例所提供客户端构建订单信息存档示意图。
46.在一些实施例中，用户在游戏中可能会产生购买行为，如图1a所示，因此在用户发起支付操作时，客户端100会启动相应的支付程序，如图1c所示，客户端100的支付程序包括以下步骤：
47.s1042：响应用户的支付操作，构建所述第一类订单存档信息，并向所述支付服务器200发送获取所述第一类订单存档信息对应的第一支付结果信息的请求；
48.s1044：接收所述支付服务器200发送的所述第一支付结果信息；
49.s1045：若所述第一支付结果信息为支付失败信息，则删除所述第一类订单存档信息；
50.s1046：若所述第一支付结果信息为支付成功信息，则构建所述第二类订单存档信息，删除所述第一类订单存档信息，并向所述配给服务器300发送执行所述第二类订单存档信息对应的配给的请求；
51.s1047：响应接收到所述配给服务器300发送的所述配给结果信息，删除所述第二类订单存档信息。
52.作为一个可选实施例，如图1c所示，客户端100进行支付后就会修改客户端存档为第一类订单信息存档，并向支付服务器发送支付结果请求，并接受所述支付服务器200发送的所述第一支付结果信息，所述支付结果信息可以是支付服务器200发送的“支付成功”或“支付失败”的信息提示。当客户端100因为网络延迟等原因未成功支付或接收到支付服务器200发送的“支付失败”的信息，则默认支付结果为支付失败，则直接删除第一类订单信息存档。客户端100接受支付服务器发送的“支付成功”信息提示可以是如图1d所示的“支付成功”的显示；当客户端100已经成功获取支付成功的请求后就默认不再接受支付服务器发送的多条相同订单的支付结果信息，并且就相同订单的支付结果只进行一次订单信息存档的修改，就是将第一类订单信息存档改为第二类订单信息存档，并删除第一类订单信息存档，并向配给服务器300发送第二类订单存档信息对应的配给的请求。当接收到所述配给服务器发送的所述配给结果信息，删除所述第二类订单存档信息。若客户端100因为网络延迟与支付服务器200断联或者在支付时强制杀死游戏app，则客户端100会在下次游戏启动或重连时启动订单校验程序。
53.图2a示出了本技术实施例所提供的一种针对弱联网的通过支付服务器实现的订单处理方法示意图。
54.如图1c所示，在一些实施例中，客户端100在启动支付程序时，会启动支付服务器200开启支付流程。如图2a所示，支付服务器200的支付流程包括：
55.s202：接收客户端100发送的获取第一类订单存档信息对应的第一支付结果信息的请求；
56.s204：查询所述第一类订单存档信息对应的订单是否支付成功并生成所述第一支付结果信息，向所述客户端100发送所述第一支付结果信息。
57.作为一个可选实施例，如图2a所示，当支付服务器200接收到客户端100发送支付结果请求时，支付服务器200会对订单队列中的支付结果依次进行查询核验。当确认客户端100已经成功支付时，向客户端200发送“支付成功”信息；当确定客户端200没有成功支付时，向客户端100发送“支付失败”信息。
58.在一些实施例中，在弱联网环境下，当客户端100与支付服务器200断联，无法收到支付服务器200的支付结果信息时，支付服务器200会持续向客户端100发送对应订单查询的支付结果，直到客户端100与支付服务器200重连并接收成功。
59.图2b示出了本技术实施例所提供的又一种针对弱联网的通过支付服务器实现的订单处理方法示意图。
60.如图2b所示，在一些实施例中，支付服务器200对于配给服务器300的校验步骤包括：
61.s206：接收配给服务器300发送的获取第二类订单存档信息对应的第二支付结果信息的请求；
62.s208：查询所述第二类订单存档信息对应的订单是否支付成功并生成所述第二支付结果信息，向所述配给服务器300发送所述第二支付结果信息。
63.作为一个可选实施例，如图2b所示，当支付服务器200接收到配给服务器300发送的支付结果请求时，支付服务器200会对第二类订单信息对应的订单支付结果进行查询，当确认第二类订单存档信息对应的订单成功支付时向配给服务器300发送“订单真实”的信息，当确认第二类订单存档信息对应的订单支付失败时向配给服务器300发送“订单虚假”的信息。
64.图3a示出了本技术实施例所提供的一种针对弱联网的通过配给服务器实现的订单处理方法示意图。
65.如图3a所示，在一些实施例中，配给服务器300对于客户端100的校验流程为：
66.s302：接收客户端100发送的获取第二类订单存档信息对应的配给结果信息的请求；
67.s304：查询所述第二类订单存档信息对应的订单是否配给成功并生成所述配给结果信息，向所述客户端100发送所述配给结果信息。
68.作为一个可选实施例，如图3a所示，在配给服务器300接受到客户端100发送的第二类订单存档信息对应的配给结果信息的请求时，向支付服务器发送对应订单的支付结果请求，查询所述第二类订单存档信息对应的订单是否配给成功并生成所述配给结果信息发送给客户端100。若查询到配给服务器300已经成功发货，则提醒客户端删除存档；若查询到配给服务器300没有发货，则向客户端发货后并提醒客户端删除存档。
69.图3b示出了本技术实施例所提供的又一种针对弱联网的通过配给服务器实现的订单处理方法示意图。
70.如图3b所示，在一些实施例中，配给服务器300对于支付服务器200的的校验流程还包括：
71.s302：接收客户端100发送的执行所述第二类订单存档信息对应的配给的请求；
72.s306：向支付服务器200发送获取所述第二类订单存档信息对应的第二支付结果信息的请求，接收支付服务器100发送的所述第二支付结果信息，若所述第二支付结果信息
为支付成功信息，执行所述第二类订单存档信息对应的配给，并向所述客户端100发送为配给成功的配给结果信息，若所述第二支付结果信息为支付失败信息，向所述客户端发送为配给失败的配给结果信息。
73.作为一个可选实施例，当所述配给服务器300接收到支付服务器200发送的对应支付结果信息为“订单真实”时，向所述客户端100发货并提醒客户端删除存档；当所述配给服务器300接收到支付服务器200发送的对应支付结果信息为“订单虚假”时，则拒绝给客户端100发货并提示客户端100删除存档。
74.作为一种实现方式，当客户端执行支付时会优先在本地修改存档为第一类订单存档信息，并向支付服务器发送第一支付结果请求。当客户端收到来自支付服务器返回的“支付成功”时，修改本地存档为第二类订单存档信息，并向配给服务器发送校验请求，配给服务器针对客户端发送的校验请求会向支付服务器求证订单的真假，如果订单为真，则向客户端发货。在弱联网换环境中，因为客户端会自动向配给服务器发送订单校验请求，因此无论是断联还是在支付过程中强制杀死app都不会导致有漏单或者逃单等行为，有效的保障了客户的游戏权益。
75.基于同一技术构思，与上述任意实施例方法相对应的，本技术还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上任意一实施例所述的订单处理方法。
76.图4示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。
77.处理器1010可以采用通用的cpu(central processing unit，中央处理器)、微处理器、应用专用集成电路(application specific integrated circuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。
78.存储器1020可以采用rom(read only memory，只读存储器)、ram(random access memory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。
79.输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
80.通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。
81.总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。
82.需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口
1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。
83.上述实施例的电子设备用于实现前述任一实施例中相应的订单处理方法，并且具有相应的方法实施例的有益效果，在此不再赘述。
84.基于同一技术构思，与上述任意实施例方法相对应的，本技术还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一实施例所述的订单处理方法。
85.本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。
86.上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的订单处理方法，并且具有相应的方法实施例的有益效果，在此不再赘述。
87.所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本技术的范围(包括权利要求)被限于这些例子；在本技术的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本技术实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。
88.另外，为简化说明和讨论，并且为了不会使本技术实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(ic)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本技术实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本技术实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本技术的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本技术实施例。因此，这些描述应被认为是说明性的而不是限制性的。
89.尽管已经结合了本技术的具体实施例对本技术进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态ram(dram))可以使用所讨论的实施例。
90.本技术实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本技术实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本技术的保护范围之内。

技术特征：

1.一种针对弱联网的订单处理方法，其特征在于，通过客户端实现，所述方法包括：响应用户针对所述客户端的启动操作，确定所述客户端中是否存在订单存档信息，若存在所述订单存档信息，则进一步确定所述订单存档信息的类型；若所述订单存档信息为第一类订单存档信息，则向支付服务器发送获取所述第一类订单存档信息对应的第一支付结果信息的请求；若所述订单存档信息为第二类订单存档信息，则向配给服务器发送获取所述第二类订单存档信息对应的配给结果信息的请求。2.根据权利要求1所述的方法，其特征在于，所述方法还包括：响应用户的支付操作，构建所述第一类订单存档信息，并向所述支付服务器发送获取所述第一类订单存档信息对应的第一支付结果信息的请求；接收所述支付服务器发送的所述第一支付结果信息，若所述第一支付结果信息为支付成功信息，则构建所述第二类订单存档信息，删除所述第一类订单存档信息，并向所述配给服务器发送执行所述第二类订单存档信息对应的配给的请求，若所述第一支付结果信息为支付失败信息，则删除所述第一类订单存档信息；响应接收到所述配给服务器发送的所述配给结果信息，删除所述第二类订单存档信息。3.一种针对弱联网的订单处理方法，其特征在于，通过支付服务器实现，所述方法包括：接收客户端发送的获取第一类订单存档信息对应的第一支付结果信息的请求，查询所述第一类订单存档信息对应的订单是否支付成功并生成所述第一支付结果信息，向所述客户端发送所述第一支付结果信息。4.根据权利要求3所述的方法，其特征在于，所述方法还包括：接收配给服务器发送的获取第二类订单存档信息对应的第二支付结果信息的请求，查询所述第二类订单存档信息对应的订单是否支付成功并生成所述第二支付结果信息，向所述配给服务器发送所述第二支付结果信息。5.一种针对弱联网的订单处理方法，其特征在于，通过配给服务器实现，包括：接收客户端发送的获取第二类订单存档信息对应的配给结果信息的请求，查询所述第二类订单存档信息对应的订单是否配给成功并生成所述配给结果信息，向所述客户端发送所述配给结果信息。6.根据权利要求5所述的方法，其特征在于，所述方法还包括：接收所述客户端发送的执行所述第二类订单存档信息对应的配给的请求，向支付服务器发送获取所述第二类订单存档信息对应的第二支付结果信息的请求，接收所述支付服务器发送的所述第二支付结果信息，若所述第二支付结果信息为支付成功信息，执行所述第二类订单存档信息对应的配给，并向所述客户端发送为配给成功的配给结果信息，若所述第二支付结果信息为支付失败信息，向所述客户端发送为配给失败的配给结果信息。7.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至2任意一项所述的方法、权利要求3至4任意一项所述的方法或者权利要求5至6任意一项所述的方法。8.一种非暂态计算机可读存储介质，其特征在于，所述非暂态计算机可读存储介质存
储计算机指令，所述计算机指令用于使所述计算机执行权利要求1至2任一所述方法、权利要求3至4任一所述方法或者权利要求5至6任一所述方法。

技术总结

本申请提供一种针对弱联网的订单处理方法、电子设备和存储介质，该方法包括：响应用户针对客户端的启动操作，确定所述客户端中是否存在订单存档信息，若存在所述订单存档信息，则进一步确定所述订单存档信息的类型；若所述订单存档信息为第一类订单存档信息，则向支付服务器发送获取所述第一类订单存档信息对应的第一支付结果信息的请求；若所述订单存档信息为第二类订单存档信息，则向配给服务器发送获取所述第二类订单存档信息对应的配给结果信息的请求。本申请能够有效监控在弱联网环境下的丢单情况，实现在弱联网环境下也能使用户拥有良好的支付体验。拥有良好的支付体验。拥有良好的支付体验。