支付异常的处理方法、处理装置、存储介质及电子设备与流程

1.本公开涉及支付异常处理技术领域，尤其涉及一种支付异常的处理方法、处理装置、计算机可读存储介质及电子设备。


背景技术：

2.目前的支付业务场景中，主要通过个人用户，商户和第三方服务商完成支付业务。个人用户在商户端提供的业务平台上，与第三方服务商进行支付业务的时候，因为网络或者第三方服务商的稳定性和质量问题等原因会造成支付异常，从而导致个人用户不能及时获取正确的支付状态。
3.因此，需要一种支付异常的处理方法、处理装置、存储介质及电子设备。
4.需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。


技术实现要素：

5.本公开的目的在于提供一种支付异常的处理方法，至少在一定程度上克服支付异常的处理效率不高的问题。
6.本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。
7.根据本公开的一个方面，提供一种支付异常的处理方法，包括：响应于客户端提交的订单，获取订单信息；根据所述订单信息请求支付服务方的支付服务；判断所述支付服务是否请求成功；当所述请求成功时，将所述订单信息存储到订单信息队列中；返回所述订单信息给所述客户端。
8.在本公开一个实施例中，所述订单信息包括所述支付服务方的支付渠道标识和订单号，将所述订单信息存储到所述订单信息队列中包括：把所述支付渠道标识作为键值，将所述订单号存储到所述订单信息队列中。
9.在本公开一个实施例中，所述方法还包括：当所述请求失败时，启动重试机制；获取所述重试机制的预设运行次数；在重试时间内获取所述重试机制的实际运行次数；当所述实际运行次数大于所述预设运行次数时，触发全局阈值报警。
10.在本公开一个实施例中，所述方法还包括：将所述支付渠道标识作为键值，存储所述重试机制的预设运行次数；当所述实际运行次数大于所述预设运行次数时，下架所述支付渠道标识对应的所述支付服务方。
11.在本公开一个实施例中，所述方法还包括：当所述请求成功时，获取所述支付服务方生成的预付单，所述预付单包括所述订单号、所述支付渠道标识和订单状态；发送所述预付单给所述客户端，以便所述客户端向所述支付渠道标识对应的所述支付服务方发送支付请求；所述支付服务方接收所述支付请求，并根据所述支付请求对所述预付单进行支付；所述支付服务方完成所述支付后，更新所述订单状态为支付成功状态，发送支付成功通知。
12.在本公开一个实施例中，所述方法还包括：接收到所述支付服务方发送的支付成功通知；将所述支付渠道标识作为键值，将所述订单号存储到支付成功队列中。
13.在本公开一个实施例中，所述方法还包括：获取所述订单信息队列中的所述订单号；判断所述订单号是否存在于所述支付成功队列中；若所述订单号存在于所述支付成功队列中，在所述订单信息队列中删除所述订单号。
14.在本公开一个实施例中，所述方法还包括：若所述订单号不存在于所述支付成功队列中，查询到所述订单状态；当所述订单状态为支付等待状态时，触发支付报警；当所述订单状态为支付关闭状态时，在所述订单信息队列中删除所述订单号。
15.在本公开一个实施例中，所述方法还包括：基于所述订单信息队列与所述支付成功队列生成支付信息管理界面；利用所述支付信息管理界面监测所述订单信息队列与所述支付成功队列的后台数据。
16.根据本公开的另一个方面，提供一种支付异常的处理装置，包括：订单信息获取单元，用于响应于客户端提交的订单，获取订单信息；支付服务请求单元，用于根据所述订单信息请求支付服务方的支付服务；请求判断单元，用于判断所述支付服务是否请求成功；，用于当所述请求成功时，将所述订单信息存储到订单信息队列中；订单信息返回单元，用于返回所述订单信息给所述客户端。
17.在本公开一个实施例中，所述请求成功单元包括：订单信息队列存储单元，用于把所述支付渠道标识作为键值，将所述订单号存储到所述订单信息队列中。
18.在本公开一个实施例中，所述装置还包括：重试机制启动单元，用于当所述请求失败时，启动重试机制；预设运行次数获取单元，用于获取所述重试机制的预设运行次数；实际运行次数获取单元，用于在重试时间内获取所述重试机制的实际运行次数；触发全局阈值报警单元，用于当所述实际运行次数大于所述预设运行次数时，触发全局阈值报警。
19.在本公开一个实施例中，所述装置还包括：预设运行次数存储单元，用于将所述支付渠道标识作为键值，存储所述重试机制的预设运行次数；支付服务方下架单元，用于当所述实际运行次数大于所述预设运行次数时，下架所述支付渠道标识对应的所述支付服务方。
20.在本公开一个实施例中，所述装置还包括：预付单获取单元，用于当所述请求成功时，获取所述支付服务方生成的预付单，所述预付单包括所述订单号、所述支付渠道标识和订单状态；支付请求发送单元，用于发送所述预付单给所述客户端，以便所述客户端向所述支付渠道标识对应的所述支付服务方发送支付请求；预付单支付单元，用于所述支付服务方接收所述支付请求，并根据所述支付请求对所述预付单进行支付；支付成功通知发送单元，用于所述支付服务方完成所述支付后，更新所述订单状态为支付成功状态，发送支付成功通知。
21.在本公开一个实施例中，所述装置还包括：支付成功通知接收单元，用于接收到所述支付服务方发送的支付成功通知；支付成功队列存储单元，用于将所述支付渠道标识作为键值，将所述订单号存储到支付成功队列中。
22.在本公开一个实施例中，所述装置还包括：订单号获取单元，用于获取所述订单信息队列中的所述订单号；订单号判断单元，用于判断所述订单号是否存在于所述支付成功队列中；订单号删除单元，用于若所述订单号存在于所述支付成功队列中，在所述订单信息
队列中删除所述订单号。
23.在本公开一个实施例中，所述装置还包括：订单状态查询单元，用于若所述订单号不存在于所述支付成功队列中，查询到所述订单状态；支付报警触发单元，用于当所述订单状态为支付等待状态时，触发支付报警；订单号删去单元，用于当所述订单状态为支付关闭状态时，在所述订单信息队列中删除所述订单号。
24.在本公开一个实施例中，所述装置还包括：支付信息管理界面生成单元，用于基于所述订单信息队列与所述支付成功队列生成支付信息管理界面；后台数据监测单元，用于利用所述支付信息管理界面监测所述订单信息队列与所述支付成功队列的后台数据。
25.根据本公开的再一个方面，提供一种如电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述的支付异常的处理方法。
26.根据本公开的又一个方面，提供一种如计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述的支付异常的处理方法。
27.本公开的实施例提供了一种支付异常的处理方法，商户端获取客户端提交的订单信息之后，请求支付服务方的支付服务，在请求支付服务成功之后，将订单信息存储到订单信息队列中，并返回订单信息给客户端。当支付异常时，商户端可以根据存储有订单信息的订单信息队列解决支付异常的问题，提高了支付异常的处理效率。
28.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
29.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
30.图1示出本公开实施例中一种计算机系统的结构示意图；
31.图2示出本公开实施例中一种支付业务的流程图；
32.图3示出本公开实施例中一种支付异常的处理方法流程图；
33.图4示出本公开实施例中又一种支付异常的处理方法流程图；
34.图5示出本公开实施例中另一种支付异常的处理方法流程图；
35.图6示出本公开实施例中再一种支付异常的处理方法流程图；
36.图7示出本公开实施例中再一种支付异常的处理方法流程图；
37.图8示出本公开实施例中一种支付异常的处理装置800的示意图；
38.图9示出本公开实施例中一种电子设备900的结构框图；
39.图10示出本公开实施例中一种用于实现上述方法的程序产品1000的示意图。
具体实施方式
40.现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加
全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。
41.此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
42.附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
43.本发明的发明人发现现有技术中至少存在如下问题，即现有技术中，商户端依赖于支付服务方发送的支付成功通知，无法在发生支付异常时，继续完成支付业务。具体的支付异常情况如下：
44.1)商户端在获取支付服务方的支付信息时，很容易因为网络或者其他原因导致获取失败，导致不确定能否进行支付，若放弃支付，可能会造成商户端的用户流失。
45.2)商户端仅根据支付服务商发送的支付成功通知来得知支付订单的状态。在部分支付场景中，例如，因为网络原因或者支付服务的稳定性和质量问题导致商户端没有收到支付成功通知，此时商户端无法得知支付订单的状态。当用户通过客户端向商户端发起查询支付订单的状态的请求时，商户端无法回应查询请求也无法将支付订单的状态返回给客户端，若用户迟迟无法查询到支付订单的状态，可能会投诉。
46.3)支付服务方在完成支付后，可能因为商户端的网络状态等问题，出现支付订单处于等待状态，导致支付服务方没有发送支付成功通知，当客户端向商户端发送查询请求时，商户端由于未接收到支付成功通知，无法响应客户端的查询请求。此时针对支付订单出现等待状态或订单关闭状态的情况并没有相应的处理办法，造成用户在交易过程中体验感差的问题。
47.基于以上问题，本公开实施例提出了一种支付异常的处理方法、处理装置、存储介质及电子设备，可以在一定程度上克服支付异常的处理效率不高的问题。以下对本公开实施例进行详细的说明。
48.图1示出本公开实施例中一种计算机系统的结构示意图。如图1所示，图1提供了一个示例性实施例的计算机系统的结构示意图。该系统包括：若干个用户端120、商户端130和支付服务方140。
49.用户端120可以是手机、游戏主机、平板电脑、电子书阅读器、智能眼镜、mp4(movingpicture experts group audio layer iv，动态影像专家压缩标准音频层面4)播放器、智能家居设备、ar(augmented reality，增强现实)设备、vr(virtual reality，虚拟现实)设备等移动用户端，或者，用户端120也可以是个人计算机(personal computer，pc)，比如膝上型便携计算机和台式计算机等等。
50.其中，用户端120可以安装有让用户端120与商户端130进行交互的应用程序。
51.用户端120与支付服务方140之间通过通讯网络相连。在一些实施例中，通讯网络是有线网络或无线网络。
52.商户端130包括商户客户端与商户服务器，商户客户端是一个虚拟化平台，利用商户服务器集成可视化页面，在可视化页面中提供商户信息。商户服务器可以是一台或多台服务器。
53.支付服务方140是一台服务器，或者由若干台服务器组成，或者是一个虚拟化平台，或者是一个云计算服务中心。支付服务方140用于为提供支付服务的应用程序提供后台服务。在一些实施例中，支付服务方140承担主要计算工作，用户端120承担次要计算工作；或者，支付服务方140承担次要计算工作，用户端120承担主要计算工作；或者，用户端120和支付服务方140之间采用分布式计算架构进行协同计算。
54.在一些实施例中，支付服务方140用于存储支付服务方的支付渠道的信息。
55.在一些实施例中，支付服务方140还与服务器系统142相连，支付服务方140将商户端提供的交易信息和/或交易记录存储在服务器系统142中。在一些实施例中，支付服务方140本身也可以作为服务器系统中的一个节点运行和存储数据。
56.在一些实施例中，支付服务方140包括逻辑服务器(图1未示出)和支付服务器(图1未示出)。其中，逻辑服务器用于实现应用程序的逻辑控制，比如，进行商品交易的请求处理、账号资源管理、界面内容管理等，支付服务器作为服务器系统142的一部分，用于实现各个用户端120的交易信息和/或交易记录的存储，以及重要功能的决策管理，比如，可以实现对支付请求的决策。
57.需要说明的是，上述逻辑服务器和支付服务器可以属于同一个计算机设备，或者，上述逻辑服务器和支付服务器也可以分属于不同的计算机设备。
58.在一些实施例中，不同的用户端120中安装的应用程序是相同的，或两个用户端120上安装的应用程序的客户端是不同控制系统平台的同一类型的应用程序的客户端。基于用户端平台的不同，该应用程序的客户端存在不同的具体形态，比如，该应用程序的客户端可以存在于手机用户端平台、pc(personal computers，私人电脑)用户端平台或者全球广域网(world wide web，web)用户端平台等。
59.本领域技术人员可以知晓，上述用户端120的数量可以更多或更少。比如上述用户端可以仅为一个，或者上述用户端为几十个或几百个，或者更多数量。本技术实施例对用户端的数量和设备类型不加以限定。
60.在一些实施例中，该系统还可以包括管理设备(图1未示出)，该管理设备与支付服务方140之间通过通讯网络相连。在一些实施例中，通讯网络是有线网络或无线网络。
61.在一些实施例中，上述的无线网络或有线网络使用标准通信技术和/或协议。网络通常为因特网、但也可以是任何网络，包括但不限于局域网(local area network，lan)、城域网(metropolitan area network，man)、广域网(wide area network，wan)、移动、有线或者无线网络、专用网络或者虚拟专用网络的任何组合)。在一些实施例中，使用包括超文本标记语言(hyper text mark
‑
up language，html)、可扩展标记语言(extensible markuplanguage，xml)等的技术和/或格式来代表通过网络交换的数据。此外还可以使用诸如安全套接字层(secure socket layer，ssl)、传输层安全(transport layer security，tls)、虚拟专用网络(virtual private network，vpn)、网际协议安全(internet protocolsecurity，ipsec)等常规加密技术来加密所有或者一些链路。在另一些实施例中，还可以使用定制和/或专用数据通信技术取代或者补充上述数据通信技术。
62.下面，将结合附图及实施例对本示例实施方式中的支付异常的处理方法的各个步骤进行更详细的说明。
63.图2示出本公开实施例中一种支付业务的流程图。如图2所示，图2提供了一种支付业务的方法流程。该方法包括但不限于以下步骤：
64.在s210中，下单。客户端向商户端发送下单请求。
65.在s220中，商户端生成订单，请求支付信息。商户端接收下单请求，生成订单，向支付服务方请求订单的支付信息。
66.在一个实施例中，支付服务方可以为具有国家颁发的支付业务许可证的技术服务商，例如微信和支付宝。
67.在s230中，支付服务方发送支付信息。支付服务方接收到商户端发送的请求后，将订单的支付信息发送给客户端。
68.在s240中，客户端接收支付信息。客户端接收支付信息后，选择用于支付订单的支付服务方。
69.在s250中，客户端向支付服务方发送支付请求。
70.在s260中，支付服务方接收到支付请求，完成订单的支付过程。
71.在s270中，支付服务方异步发送支付通知。支付服务方在支付订单成功后，向商户端异步发送支付成功通知。
72.在s280中，商户端异步接收支付通知。商户端接收到支付成功通知后，继续进行订单的后续业务操作，例如打包商品，安排商品发货等。
73.本公开实施例提供了一种支付异常的处理方法。在本公开实施例中提供的方法可以由任意具备计算处理能力的电子设备执行，例如如图1中的商户端130和/或支付服务方140。在下面的举例说明中，以商户端130为执行主体进行示例说明。
74.图3示出本公开实施例中一种支付异常的处理方法流程图。如图3所示，图3提供了一种在支付异常场景下的处理方法。该方法包括但不限于以下步骤：
75.在s310中，响应于客户端提交的订单，获取订单信息。客户端向商户端提交订单，商户端响应订单并获取订单信息。
76.在s320中，根据订单信息请求支付服务方的支付服务。商户端根据订单信息，向支付服务方发送支付服务请求，用于请求该订单的支付服务。
77.在s330中，判断支付服务是否请求成功。支付服务方接收商户端的支付服务请求，生成预付单，预付单包括支付服务方的支付渠道标记。向商户端发送预付单。若商户端接收到预付单，说明支付服务请求成功。若商户端没有接收到预付单，说明支付服务请求未成功。
78.在s340中，当请求成功时，将订单信息存储到订单信息队列中。商户端接收到预付单后，将订单信息存储到订单信息队列中，订单信息可以包括订单号、商品信息、地址信息、时间信息、金额信息和其他信息。
79.在一个实施例中，订单信息包括支付服务方的支付渠道标识和订单号，将订单信息存储到订单信息队列中包括：把支付渠道标识作为键值，将订单号存储到订单信息队列中。在本公开实施例中，订单信息还可以包括支付渠道标记，不同的支付服务方具有不同的支付渠道标记，根据支付渠道标记能够获取不同支付服务方的支付服务。基于数据库，将支
付渠道标记作为键值，将订单号存储到订单信息队列中。数据库包括关系型数据库和非关系型数据库。非关系型数据库可以包括键值数据库、宽列存储数据库、图形存储数据库等。在本公开实施例中，以redis(remote dictionary server，远程字典服务)数据库为键值数据库为例，使用redis数据库将订单号存储到订单信息队列中。
80.在s350中，返回订单信息给客户端。商户端将得到的订单信息返回给客户端。
81.图4示出本公开实施例中又一种支付异常的处理方法流程图。如图4所示，图4提供了一种在支付异常场景下的处理方法。该方法包括但不限于以下步骤：
82.在s410中，客户端提交订单。用户通过客户端提交订单到商户端。
83.在s420中，商户端获取订单信息，根据订单信息请求支付服务方的支付服务。商户端将订单信息和订单数据进行组合，然后向支付服务方请求支付服务。
84.在s430中，判断支付服务是否请求成功。若为是，则进入s440，若为否，则进入s460。
85.在s440中，当请求成功时，将订单信息存储到订单信息队列中。
86.在s450中，返回订单信息给客户端。商户端将订单信息返回给客户端。
87.在s460中，重试一次。当支付服务没有请求成功时，商户端重新请求支付服务。
88.在s470中，进行全局阈值报警。
89.在一个实施例中，当请求失败时，启动重试机制；获取重试机制的预设运行次数；在重试时间内获取重试机制的实际运行次数；当实际运行次数大于预设运行次数时，触发全局阈值报警。在本公开实施例中，启动重试机制代表商户端重新请求支付服务方的支付服务。可以使用定时器来计时，在重试时间内，如果重试机制的实际运行次数大于重试机制的预设运行次数，进行全局阈值报警。本公开实施例可以通过进行重试机制排除网络不好对支付业务的影响，从而解决了因为网络或者其他原因导致支付业务失败，可能造成的用户流失的问题。
90.在本公开实施例中，实现定时器的技术框架可以包括分布式任务调度框架，例如elastic
‑
job(弹性工作)调度框架。
91.在一个实施例中，将上述支付渠道标识作为键值，存储上述重试机制的预设运行次数；当上述实际运行次数大于上述预设运行次数时，下架上述支付渠道标识对应的上述支付服务方。基于键值数据库，将支付渠道标记作为键值，存储重试机制的预设运行次数。当重试机制的实际运行次数大于预设运行次数时，在商户端下架支付渠道标识对应的支付服务方，令人工介入，查找支付服务方支付服务失败的原因并解决支付服务失败的问题。
92.图5示出本公开实施例中另一种支付异常的处理方法流程图。如图5所示，图5提供了一种在支付异常场景下的处理方法。该方法包括但不限于以下步骤：
93.在s510中，当上述请求成功时，获取上述支付服务方生成的预付单，上述预付单包括上述订单号、上述支付渠道标识和订单状态。在本公开实施例中，商户端向支付服务方请求支付服务。支付服务方接收到该请求，生成预付单并将预付单发送给商户端，预付单中包括订单号，支付服务方的支付渠道标记和订单状态。
94.在s520中，发送上述预付单给上述客户端，以便上述客户端向上述支付渠道标识对应的上述支付服务方发送支付请求。在本公开实施例中，商户端包括商户应用软件与商户服务器。支付服务方包括支付软件与支付服务器。其中，商户应用软件和支付软件都安装
在客户端上。用户可以通过操作商户应用软件以便访问商户服务器，也可以通过操作支付软件与支付服务器进行业务交易。商户端将收到的预付单发送给商户应用软件以便商户应用软件根据预付单为用户提供不同的支付软件。当用户使用客户端上的商户应用软件上选定支付软件之后，客户端根据该选定支付软件对应的支付渠道标记，向对应的支付服务方发送支付请求。
95.在s530中，上述支付服务方接收上述支付请求，并根据上述支付请求对上述预付单进行支付。支付服务方接收到来自客户端的支付请求，完成预付单的支付。
96.在s540中，上述支付服务方完成上述支付后，更新上述订单状态为支付成功状态，发送支付成功通知。在本公开实施例中，支付服务方完成对支付预付单的支付后，将预付单中的订单状态更新为支付成功状态，向商户端发送支付成功通知。
97.根据s510
‑
s540中提供的实施例，当支付服务方由于网络等原因无法提供支付服务时，可以解决商户端向支付服务方的请求支付服务失败的问题。
98.图6示出本公开实施例中再一种支付异常的处理方法流程图。如图6所示，图6提供了一种在支付异常场景下的处理方法。该方法包括但不限于以下步骤：
99.在s610中，当上述请求成功时，获取上述支付服务方生成的预付单，上述预付单包括上述订单号、上述支付渠道标识和订单状态。
100.在s620中，发送上述预付单给上述客户端，以便上述客户端向上述支付渠道标识对应的上述支付服务方发送支付请求。
101.在s630中，上述支付服务方接收上述支付请求，并根据上述支付请求对上述预付单进行支付。
102.在s640中，上述支付服务方完成上述支付后，更新上述订单状态为支付成功状态，发送支付成功通知。
103.其中，s610
‑
s640可以参照s510
‑
s540中的实施例。s650
‑
s660的说明如下：
104.在s650中，接收到上述支付服务方发送的支付成功通知。商户端接收支付成功通知后，可以得知订单状态为支付成功状态。
105.在s660中，将上述支付渠道标识作为键值，将上述订单号存储到支付成功队列中。基于键值数据库，商户端将支付渠道标记作为键值，将订单号存储到支付成功队列中。
106.在一个实施例中，获取上述订单信息队列中的上述订单号；判断上述订单号是否存在于上述支付成功队列中；若上述订单号存在于上述支付成功队列中，在上述订单信息队列中删除上述订单号。在本公开实施例中，商户端获取到订单信息队列中的订单号，判断该订单号是否在支付成功队列中。如果该订单号在支付成功队列中，说明预付单支付成功，商户端接收到支付服务方发送的支付成功通知，接下来在订单信息队列中删除订单号。
107.在本公开实施例中，订单信息队列中的订单号可以是一个或多个。商户端一次可以取一个订单号，判断该订单号是否存在于上述支付成功队列中。
108.在一个实施例中，若上述订单号不存在于上述支付成功队列中，查询到上述订单状态；当上述订单状态为支付等待状态时，触发支付报警；当上述订单状态为支付关闭状态时，在上述订单信息队列中删除上述订单号。当商户端从订单信息队列中获取到的订单号不存在于支付成功队列中时，说明该预付单没有支付成功，支付服务方没有发送支付成功通知。商户端主动向支付服务方发起查询订单状态的请求，支付服务方接收到商户端的请
求，将订单状态发送给商户端。订单状态包括支付等待状态和支付关闭状态。订单状态为支付等待状态时，说明订单可能因为网络延迟等原因正在等待支付。订单状态为支付关闭状态时，说明订单可能因为订单过期、用户放弃支付或者订单失效等原因而导致关闭，此时商户端删除订单信息队列中的订单号。根据本公开实施例提供的技术方案，可以针对不同的订单状态作出相应的处理。商户端在支付服务方没有成功发送支付成功通知时，主动向支付服务方发起查询订单状态的请求，支付服务方响应商户端的请求将订单状态发送给商户端。商户端根据不同的订单状态进行相应的处理，并将订单状态发送给客户端，令用户可以掌握订单状态，进一步解决了用户在商户端的交易过程体验感差的问题。
109.在一个实施例中，可以使用定时器来实现商户端定时向支付服务方发送查询订单状态的请求。
110.在一个实施例中，基于上述订单信息队列与上述支付成功队列生成支付信息管理界面；利用上述支付信息管理界面监测上述订单信息队列与上述支付成功队列的后台数据。在本公开实施例中，当支付异常时，商户端可以通过固定规则的日志监控信息、订单信息和订单信息队列与支付成功队列的变化情况，生成支付信息管理界面。在支付信息管理界面上，可以监控商户端向支付服务方请求支付服务的响应时间，响应频率，系统性能消耗情况等后台数据。
111.图7示出本公开实施例中再一种支付异常的处理方法流程图。如图7所示，图7提供了一种在支付异常场景下的处理方法。通过客户端、商户端和支付服务方能够实现支付异常的处理方法。支付服务方可以包括微信、支付宝和银联官方软件。在本公开实施例中，支付服务方为微信。该方法包括但不限于以下步骤：
112.在s701中，发送下单请求。用户在客户端上点击链接或者使用客户端扫描二维码以便打开商户的订单页面，以发送下单请求。
113.在s702中，商户端生成订单，订单中包括订单号、商品信息、地址信息、时间信息、金额信息和其他信息。
114.在s703中，商户端请求支付服务。商户端将订单信息与支付服务方的支付渠道标记组合在一起，根据订单向支付服务方请求支付服务。
115.在s704中，微信生成预付单。微信接收到商户端发送的支付服务的请求，生成预付单。
116.在s705中，微信返回预付单，包括预付单号、订单号、订单状态以及支付渠道标记。微信将预付单发送给商户端。
117.在s706中，商户端将订单信息存入订单信息队列。商户端将订单信息存入订单信息队列。
118.在s707中，商户端将预付单返回给客户端。
119.在s708中，客户端发送支付请求。客户端接收到预付单后，根据支付渠道标记向微信发送支付请求。
120.在s709中，微信接收到客户端发送的支付请求，对预付单进行支付。
121.在s710中，微信获取支付结果。
122.在s711中，微信将得到的支付结果发送给客户端。
123.在s712中，微信根据支付结果更新订单状态。如果支付成功，将订单状态更新为支
付成功状态。如果订单为等待支付，将订单状态更新为支付等待状态。如果订单关闭，将订单状态更新为支付关闭状态。
124.在s713中，微信发送支付成功通知。当订单状态为支付成功状态时，微信向商户端发送支付成功通知。微信可以使用同步发送的方式发送支付成功通知，也可以使用异步发送的方式发送支付成功通知，本公开对发送方式不做限定。
125.在s714中，商户端在接收到支付成功通知后，将订单信息存入支付成功队列。在一个实施例中，订单信息在通讯网络上通过密文的形式进行传输。商户端接收到支付成功通知后，对支付成功通知中的订单信息进行解密验签校验，即用约定好的加密方式和解密方式对订单信息进行判断校验，并将经过校验的订单信息存入支付成功队列。
126.在s715中，商户端判断订单信息队列中的订单信息是否存在于支付成功队列中。若为是，进入s716。若为否，进入s717。
127.在s716中，商户端删除订单信息队列中的订单信息。当订单信息队列中的订单信息存在于支付成功队列中时，商户端删除订单信息队列中的订单信息。
128.在s717中，商户端发送查询订单状态的请求。当订单信息队列中的订单信息不存在于支付成功队列中时，商户端向微信发送查询订单状态的请求。
129.在s718中，微信接收查询订单状态的请求。
130.在s719中，微信返回订单状态。微信接收商户端发送的查询订单状态的请求后，将查询到的订单状态返回给商户端。
131.在s720中，商户端接收订单状态。
132.在s730中，客户端查询订单状态。客户端接收到支付结果后，向商户端发送查询订单状态的请求。
133.在s731中，商户端返回订单状态。商户端接收客户端发送的查询订单状态的请求后，将查询到的订单状态返回给客户端。
134.在s732中，户端查看订单状态。客户端可以查看订单状态。
135.在s701
‑
s732中提供的实施例中，商户端主动向支付服务方发起查询订单状态的请求，能够获得订单状态的动态变化，这样当客户端向商户端发起对支付订单的状态的查询请求时，商户端可以及时回应查询请求并将支付订单的状态返回给客户端，进一步，解决了用户投诉商户端的问题。
136.需要注意的是，上述附图仅是根据本发明示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。
137.图8示出本公开实施例中一种支付异常的处理装置800的示意图。如图8所示，一种支付异常的处理装置包括订单信息获取单元810，支付服务请求单元820，请求判断单元830，请求成功单元840和订单信息返回单元850。
138.订单信息获取单元810，用于响应于客户端提交的订单，获取订单信息。
139.支付服务请求单元820，用于根据上述订单信息请求支付服务方的支付服务。
140.请求判断单元830，用于判断上述支付服务是否请求成功。
141.请求成功单元840，用于当上述请求成功时，将上述订单信息存储到订单信息队列中。
142.在一个实施例中，请求成功单元840包括订单信息队列存储单元，用于把上述支付渠道标识作为键值，将上述订单号存储到上述订单信息队列中。
143.订单信息返回单元850，用于返回上述订单信息给上述客户端。
144.所属技术领域的技术人员能够理解，本发明的各个方面可以实现为系统、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。
145.下面参照图9来描述根据本发明的这种实施方式的电子设备900。图9显示的电子设备900仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
146.如图9所示，电子设备900以通用计算设备的形式表现。电子设备900的组件可以包括但不限于：上述至少一个处理单元910、上述至少一个存储单元920、连接不同系统组件(包括存储单元920和处理单元910)的总线930。
147.其中，上述存储单元存储有程序代码，上述程序代码可以被上述处理单元910执行，使得上述处理单元910执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。例如，上述处理单元910可以执行如图3中所示的s310，响应于客户端提交的订单，获取订单信息；s320，根据上述订单信息请求支付服务方的支付服务；s330，判断上述支付服务是否请求成功；s340，当上述请求成功时，将上述订单信息存储到订单信息队列中；s350，返回上述订单信息给上述客户端。存储单元920可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(ram)9201和/或高速缓存存储单元9202，还可以进一步包括只读存储单元(rom)9203。
148.存储单元920还可以包括具有一组(至少一个)程序模块9205的程序/实用工具9204，这样的程序模块9205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
149.总线930可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。
150.电子设备900也可以与一个或多个外部设备970(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备900交互的设备通信，和/或与使得该电子设备900能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口950进行。并且，电子设备900还可以通过网络适配器960与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器960通过总线930与电子设备900的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备900使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
151.通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd
‑
rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算
设备(可以是个人计算机、服务器、用户端装置、或者网络设备等)执行根据本公开实施方式的方法。
152.在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当上述程序产品在用户端设备上运行时，上述程序代码用于使上述用户端设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。
153.参考图10所示，描述了根据本发明的实施方式的用于实现上述方法的程序产品1000，其可以采用便携式紧凑盘只读存储器(cd
‑
rom)并包括程序代码，并可以在用户端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
154.上述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd
‑
rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
155.计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
156.可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、rf等等，或者上述的任意合适的组合。
157.可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，上述程序设计语言包括面向对象的程序设计语言—诸如java、c 等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
158.应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
159.此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现
期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。
160.通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd
‑
rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动用户端、或者网络设备等)执行根据本公开实施方式的方法。
161.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本技术旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。