CN113344680A - 一种订单处理方法、相关装置、设备及存储介质 - Google Patents

一种订单处理方法、相关装置、设备及存储介质 Download PDF

Info

Publication number
CN113344680A
CN113344680A CN202110753155.2A CN202110753155A CN113344680A CN 113344680 A CN113344680 A CN 113344680A CN 202110753155 A CN202110753155 A CN 202110753155A CN 113344680 A CN113344680 A CN 113344680A
Authority
CN
China
Prior art keywords
payment
order
order number
state
paid
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110753155.2A
Other languages
English (en)
Inventor
邵楠
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Yundy Intelligent Technology Co Ltd
Original Assignee
Yundy Intelligent Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Yundy Intelligent Technology Co Ltd filed Critical Yundy Intelligent Technology Co Ltd
Priority to CN202110753155.2A priority Critical patent/CN113344680A/zh
Publication of CN113344680A publication Critical patent/CN113344680A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G06Q30/0637—Approvals

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请实施例公开了一种订单处理方法、相关装置、设备及存储介质，用于提高对交易过程中出现的支付掉单的处理效率。本申请实施例方法包括：接收失效订单查询请求，从订单记录列表中确定与失效订单号相匹配的目标支付订单号，以及目标支付订单号的支付状态，其中，订单记录列表用于存储订单支付信息，若支付状态为未支付状态，则将目标支付订单号发送至支付服务器，以使支付服务器根据目标支付订单号查询订单状态，若接收到支付服务器发送的查询订单状态为已支付状态，则将目标支付订单号确定为支付掉单号，将订单记录列表中的目标支付订单号的支付状态更新为已支付状态，并生成支付掉单号对应的订单支付成功的提示。

Description

一种订单处理方法、相关装置、设备及存储介质
技术领域
本申请实施例涉及数据处理领域，尤其涉及一种订单处理方法、相关装置、设备及存储介质。
背景技术
随着互联网技术的发展，网络交易广泛存在于人们的日常生活中，用户可以通过电子订单完成对真实商品或虚拟商品进行交易。
然而，在进行订单交易的过程中，接入支付功能的支付调用设备以及提供支付功能的支付渠道需要进行订单相关的信息交互及处理，交互过程中可能会出现如支付调用设备、支付渠道故障或网络出错等情况，导致订单交互出现异常，进而出现支付掉单的问题。支付掉单是指用户支付成功时，但支付调用设备的订单状态还是未支付。而现有技术中，通常是通过定时查询订单状态来处理支付掉单。
但是，由于在订单交易的过程中支付掉单通常是随时或随机出现的，如果定时频繁的查询业务方的订单，可能造成访问数据库的数据压力过大，或因定时查询的间隔过长，导致无法对定时查询的间隔出现的支付掉单进行处理或处理不及时的情况。
发明内容
本申请实施例提供了一种订单处理方法、相关装置、设备及存储介质，用于通过订单记录列表快速获取失效订单号的支付状态，并结合支付服务器反馈的查询订单状态，能够快速确定交易订单是否出现支付掉单，提高确定支付掉单的准确率，并通过更新支付掉单号在订单记录列表中支付状态，及时消除支付掉单，从而提高对支付掉单的处理效率。
有鉴于此，本申请一方面提供一种订单处理的方法，包括：
接收失效订单查询请求，其中，失效订单查询请求包括失效订单号；
从订单记录列表中确定与失效订单号相匹配的目标支付订单号，以及目标支付订单号的支付状态，其中，订单记录列表用于存储订单支付信息；
若支付状态为未支付状态，则将目标支付订单号发送至支付服务器，以使支付服务器根据目标支付订单号查询订单状态；
若接收到支付服务器发送的查询订单状态为已支付状态，则将目标支付订单号确定为支付掉单号；
将订单记录列表中的目标支付订单号的支付状态更新为已支付状态，并生成支付掉单号对应的订单支付成功的提示。
本申请的另一方面提供一种订单处理装置，包括：
接收单元，用于接收失效订单查询请求，其中，失效订单查询请求包括失效订单号；
确定单元，用于从订单记录列表中确定与失效订单号相匹配的目标支付订单号，以及目标支付订单号的支付状态，其中，订单记录列表用于存储订单支付信息；
处理单元，用于若支付状态为未支付状态，则将目标支付订单号发送至支付服务器，以使支付服务器根据目标支付订单号查询订单状态；
处理单元，用于若接收到支付服务器发送的查询订单状态为已支付状态，则将目标支付订单号确定为支付掉单号；
处理单元，还用于将订单记录列表中的目标支付订单号的支付状态更新为已支付状态，并生成支付掉单号对应的订单支付成功的提示。
在一种可能的设计中，在本申请实施例的另一方面的一种实现方式中，
处理单元，还用于若所述支付状态为已支付状态，则将所述目标支付订单号确定为支付掉单号；
处理单元，还用于生成所述支付掉单号对应的订单支付成功的提示。
在一种可能的设计中，在本申请实施例的另一方面的一种实现方式中，
处理单元，还用于实时监测延迟消息队列中各个待支付订单号的延迟时间是否满足超时条件，其中，延迟消息队列用于存储各个待支付订单号，各个待支付订单号来源于支付服务器；
处理单元，还用于若延迟时间满足超时条件，则将满足超时条件的待支付订单号确定为失效订单号。
在一种可能的设计中，在本申请实施例的另一方面的一种实现方式中，
确定单元，还用于从业务列表中确定与失效订单号相匹配的支付订单号，其中，业务列表用于存储支付订单号、与支付订单号对应的原始业务单号，以及原始业务单号对应的支付业务参数；
处理单元，还用于将支付订单号对应的原始业务单号以及支付业务参数，发送至支付服务器，以使支付服务器根据原始业务单号以及支付业务参数更新订单号；
处理单元，还用于接收支付服务器发送的更新订单号，并将更新订单号与原始业务单号对应保存至业务列表。
在一种可能的设计中，在本申请实施例的另一方面的一种实现方式中，
接收单元，还用于接收管理人员输入的待查询订单号；
确定单元，还用于从订单记录列表中确定与待查询订单号相匹配的支付管理订单号，以及支付管理订单号的支付管理状态；
处理单元，还用于若支付管理状态为未支付状态，则将支付管理订单号发送至支付服务器查询订单状态；
处理单元，还用于若接收到支付服务器发送的查询订单状态为已支付状态，则将支付管理订单号确定为支付掉单号，并将支付管理状态更新为已支付状态。
在一种可能的设计中，在本申请实施例的另一方面的一种实现方式中，
接收单元，还用于接收订单退款请求，其中，订单退款请求包括待退款单号；
确定单元，还用于根据待退款单号，从订单记录列表中确定支付待退款单号，以及支付待退款单号的支付状态；
处理单元，还用于若支付待退款单号的支付状态为已支付状态，则将支付待退款单号发送至支付服务器，以使支付服务器根据支付待退款单号查询订单退款状态；
接收单元，还用于接收支付服务器发送的查询订单退款状态；
处理单元，还用于生成查询订单退款状态对应的订单状态提示。
在一种可能的设计中，在本申请实施例的另一方面的一种实现方式中，
接收单元，还用于接收消费查询请求，其中，订单消费请求包括待查询消费单号；
确定单元，还用于根据待查询消费单号，从订单记录列表中确定支付消费订单号，以及支付消费订单号的支付状态和支付消费订单号对应的消费金额；
处理单元，还用于根据支付消费订单号、支付消费订单号的支付状态以及支付消费订单号对应的消费金额生成消费提示。
从以上技术方案可以看出，本申请实施例具有以下优点：
通过从订单记录列表中确定与失效订单号相匹配的目标支付订单号，以及目标支付订单号的支付状态，进而当获取到的支付状态为未支付状态时，将目标支付订单号发送至支付服务器，以使支付服务器根据目标支付订单号查询订单状态，并当接收到支付服务器发送的查询订单状态为已支付状态时，将目标支付订单号确定为支付掉单号，然后，将订单记录列表中的目标支付订单号的支付状态更新为已支付状态，并生成支付掉单号对应的订单支付成功的提示。通过上述方式，实现了通过订单记录列表中快速获取失效订单号的支付状态，并结合支付服务器反馈的查询订单状态，能够快速确定交易订单是否出现支付掉单，提高确定支付掉单的准确率，并通过更新支付掉单号在订单记录列表中支付状态，及时消除支付掉单，从而提高对支付掉单的处理效率。
附图说明
图1是本申请实施例中订单控制***的一个架构示意图；
图2是本申请实施例中订单处理方法的一个实施例示意图；
图3是本申请实施例中订单处理方法的另一个实施例示意图；
图4是本申请实施例中订单处理方法的另一个实施例示意图；
图5是本申请实施例中订单处理方法的另一个实施例示意图；
图6是本申请实施例中订单处理方法的另一个实施例示意图；
图7是本申请实施例中订单处理方法的另一个实施例示意图；
图8是本申请实施例中订单处理方法的另一个实施例示意图；
图9是本申请实施例中订单处理方法的一个原理流程示意图；
图10是本申请实施例中订单处理方法的一个订单支付原理流程示意图；
图11是本申请实施例中订单处理方法的一个订单多次支付原理流程示意图；
图12是本申请实施例中订单处理方法的一个基于业务列表处理订单号的原理流程示意图；
图13是本申请实施例中订单处理方法的一个订单记录列表的示意图；
图14是本申请实施例中订单处理方法的一个基于延迟消息队列处理订单号的原理示意图；
图15是本申请实施例中订单处理装置的一个实施例示意图；
图16是本申请实施例中计算机设备的一个实施例示意图。
具体实施方式
本申请实施例提供了一种订单处理方法，用于通过订单记录列表快速获取失效订单号的支付状态，并结合支付服务器反馈的查询订单状态，能够快速确定交易订单是否出现支付掉单，提高确定支付掉单的准确率，并通过更新支付掉单号在订单记录列表中支付状态，及时消除支付掉单，从而提高对支付掉单的处理效率。
本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
应理解，本申请提供的订单处理方法可以应用于各种通过通过电子订单完成对真实商品或虚拟商品进行支付交易的场景中，作为示例，例如通过电子订单从商品网站中购买家居用品。作为另一个示例，例如通过电子订单从视频应用商城中购买视频应用的会员功能。作为再一示例，例如通过电子订单从电影应用中购买电影票，在上述种种场景中，为了完成支付交易不掉单，现有技术中提供的解决方案为，通过定时查询订单状态来处理支付掉单，但是由于在订单交易的过程中支付掉单通常是随时或随机出现的，如果定时频繁的查询业务方的订单，可能造成访问数据库的数据压力过大，或因定时查询的间隔过长，从而导致无法对定时查询的间隔出现的支付掉单进行处理或处理不及时的情况。
为了解决上述问题，本申请提出了一种订单处理方法，该方法应用于图1所示的订单控制***，请参阅图1，图1为本申请实施例中订单控制***的一个架构示意图，如图所示，支付调用设备从订单记录列表中确定与失效订单号相匹配的目标支付订单号，以及目标支付订单号的支付状态，进而当获取到的支付状态为未支付状态时，将目标支付订单号发送至支付服务器，以使支付服务器根据目标支付订单号查询订单状态，并当接收到支付服务器发送的查询订单状态为已支付状态时，将目标支付订单号确定为支付掉单号，然后，将订单记录列表中的目标支付订单号的支付状态更新为已支付状态，并生成支付掉单号对应的订单支付成功的提示。通过上述方式，实现了通过订单记录列表中快速获取失效订单号的支付状态，并结合支付服务器反馈的查询订单状态，能够快速确定交易订单是否出现支付掉单，提高确定支付掉单的准确率，并通过更新支付掉单号在订单记录列表中支付状态，及时消除支付掉单，从而提高对支付掉单的处理效率。
其中，支付调用设备与支付服务器之间通信连接。具体地，应当理解，图1中示出的支付调用设备以及支付服务器的数量仅为一个示例，不用于限定支付调用设备以及支付服务器的数量，具体应当结合实际情况灵活确定数量。
为了解决上述问题，本申请提出了一种订单处理方法，该方法一般由服务器或终端设备执行，相应地，订单处理的装置一般设置于服务器或终端设备中。
下面将对本申请中订单处理方法进行介绍，请参阅图2以及图9，本申请实施例中订单处理方法一个实施例包括：
在步骤S101中，接收失效订单查询请求，其中，失效订单查询请求包括失效订单号；
在本申请实施例中，如图10所示，当用户想要购买某一真实商品或虚拟商品时，支付调用设备可以接收到客户端发送的根据用户对想要购买的虚拟财产的选择操作生成的订单信息，如订单金额，商品名称等，以及支付服务器发送的订单信息对应的支付订单号，支付调用设备通过对获取到的订单信息和支付订单号进行组装，得到组装后的待支付订单，然后，支付调用设备可以通过该待支付订单打开收银台，以使用户可以获取到收银界面，并通过收银界面完成订单支付。
其中，支付调用设备指的是接入支付功能的调用方，例如，设备Q接入支付渠道P，其中，设备Q为调用方，支付服务器指的是提供支付功能的渠道方，例如，设备Q接入支付渠道P，其中，P为支付渠道方。
但是，在实际订单交易的过程中，为了避免对生成的电子订单长时间不付款，各设备或服务器必须维护电子订单的长时间有效性，易增加设备或服务器的负载，导致资源浪费的情况，故在通过待支付订单打开收银台，以使用户能够通过收银界面进行订单支付，可以通过设置支付时间，使得用户的订单支付要在一定的时间内完成，如果订单在支付时间内已支付，则订单支付完成，如果订单在超出支付时间后还未支付完成，那么订单将会失效关闭，该订单的支付订单号即为失效订单号。
例如，在商城网页中购买零食的支付场景中，支付调用设备可以根据获取到的购买零食的订单信息和支付订单号，组装得到购买零食的待支付订单，然后可以通过该待支付订单打开收银台，并生成相应的支付时间，以使用户能够在该支付时间内，通过收银台提供的收银界面进行订单支付，如果用户超出支付时间后还未支付完成，那么该购买零食的待支付订单将会失效关闭，该购买零食的待支付订单对应的支付订单号即为失效订单号。
进一步地，可以理解的是，如图10所示，未失效订单号可以存在两种情况，包括处于支付时间内，订单未支付的支付订单号和订单已支付的支付订单号，而失效订单号也可以存在两种情况，包括超过支付时间的，订单已关闭(未支付)的支付订单号和订单已支付的支付订单号。
进一步地，在实际订单交易的过程中，为了避免失效订单号出现支付掉单，即支付调用设备的显示该失效订单号的订单状态为超时未支付状态，但是该失效订单号实际上是已支付状态的情况，进而为了对支付掉单不处理或处理不及时的情况，如图9所示，本实施例可以通过接收失效订单查询请求，获取失效订单号，以使后续能够根据失效订单号快速确定是否存在支付掉单，并进行相应的处理，从而在一定程度上提高对支付掉单的处理效率。
在步骤S102中，从订单记录列表中确定与失效订单号相匹配的目标支付订单号，以及目标支付订单号的支付状态，其中，订单记录列表用于存储订单支付信息；
在本实施例中，订单记录列表是用于存储订单支付信息的信息列表，如图14所示，订单记录列表可以将支付订单号、原始业务单号、原始业务id以及支付状态等订单支付信息进行保存，其中，保存操作可以在支付调用设备根据支付订单号打开收银台之前执行，以及订单记录列表还可以对订单支付信息进行删除、查询或更新等操作。
例如，如图14所示，假设一订单记录列表有5条订单支付信息，5条订单支付信息分别为订单A、订单B以及订单C的订单信息，如订单B包括3条订单支付信息，如一条订单支付信息为支付订单号b，原始业务单号b-01，原始业务id为b001，订单日期(订单创建日期)为2021年3月22日15:10:30，以及支付状态为未支付等，如一条订单支付信息为支付订单号c，原始业务单号b-01，原始业务id为b001，订单日期为2021年3月22日15:10:30，以及支付状态为未支付等，如另一条订单支付信息为支付订单号d，原始业务单号b-01，原始业务id为b001，订单日期为2021年3月22日15:09:30，以及支付状态为未支付等。
进一步地，当接收到失效订单查询请求，并获取到失效订单号后，可以根据失效订单号在订单记录列表中进行查询或遍历，以获取与失效订单号相同的支付订单号，即目标支付订单号，然后，根据该目标支付订单号在订单记录列表中获取与该目标支付订单号相对应的支付状态，以使后续能够根据该目标支付订单号以及该目标支付订单号相对应的支付状态快速确认该失效订单号是否存在支付掉单，并对确认的支付掉单进行处理，从而在一定程度上提高处理支付掉单的效率。
具体地，如图9所示，在接收到消费者发送的失效订单查询请求，支付调用设备可以通过获取失效订单查询请求中携带的失效订单号，在如图14所示的订单记录列表中进行查询，可以准确快速地查询到与该失效订单号一致的支付订单号作为目标支付订单号，然后可以通过快速获取该目标支付订单号在订单记录列表中的支付状态，来判断该失效订单号是否存在支付掉单的情况。
在步骤S103中，若支付状态为未支付状态，则将目标支付订单号发送至支付服务器，以使支付服务器根据目标支付订单号查询订单状态；
在本申请实施例中，当获取到的目标支付订单号的支付状态为未支付状态时，可以理解为该失效订单号没有出现支付掉单，但是为了避免在交易过程中支付调用设备由于故障或网络出错等情况，导致支付状态的记录出现异常，从而导致支付掉单的情况，本实施例可以通过将目标支付订单号发送至支付服务器，以使支付服务器根据目标支付订单号查询订单状态，来进一步确认目标支付订单号的订单状态，以使后续能够查询订单状态来快速确认该失效订单号是否存在支付掉单，提高确定支付掉单的准确率，并对确认的支付掉单进行处理，从而在一定程度上提高处理支付掉单的效率。
具体地，如图9所示，当获取到的目标支付订单号的支付状态为未支付状态时，可以理解为该目标支付订单号不存在支付成功的记录，则可以将该目标支付订单号发送至支付服务器，以使支付服务器根据目标支付订单号查询订单状态，其中，在实际交易的过程中，支付服务器可以通过收银台收取到的款项来准确记录每个支付订单号的实际订单状态，故可以在接收到目标支付订单号后，快速查询到与该目标支付订单号相对应的实际订单状态，即查询订单状态，并将该查询订单状态反馈给支付调用设备，以使后续可以根据查询订单状态来快速确认该失效订单号是否存在支付掉单。
例如，假设一个失效订单号对应的目标支付订单号c，该目标支付订单号的支付状态为未支付的状态，则为了避免目标支付订单号c是由于交易过程中支付调用设备的故障或网络出错等情况，导致支付状态的记录出现异常，从而导致支付掉单的情况，则可以将该目标支付订单号c发送至支付服务器，来获取支付服务器反馈的目标支付订单号c的实际订单状态即查询订单状态，来进一步确认该目标支付订单号c是否出现支付掉单。
在步骤S104中，若接收到支付服务器发送的查询订单状态为已支付状态，则将目标支付订单号确定为支付掉单号；
在本申请实施例中，当将目标支付订单号发送至支付服务器后，可以接收到支付服务器发送的查询订单状态，进而，当接收到的查询订单状态为已支付状态时，可以理解为该目标支付订单号的实际支付状态为已支付，但是该目标支付订单号在订单记录列表中的支付状态仍然显示为未支付状态，可以理解为该目标支付订单号出现了支付掉单的情况，则将目标支付订单号确定为支付掉单号，以使后续能够对已确认的支付掉单号进行及时处理，从而提高确定支付掉单的准确率以及提高对支付掉单的处理效率。
具体地，如图9所示，当将不存在支付成功记录的目标支付订单号发送至支付服务器，以使支付服务器查询订单状态后，可以实时接收支付服务器返回的订单支付结果，即当接收到的查询订单状态为已支付状态时，可以确认目标支付订单号出现了支付掉单的情况，则可以将目标支付订单号确定为支付掉单号。
例如，假设一个失效订单号对应的目标支付订单号c，该目标支付订单号的支付状态为未支付的状态，将该目标支付订单号c发送至支付服务器后，假设获取到支付服务器反馈的目标支付订单号c的实际订单状态为已支付状态，则可以确认该目标支付订单号c出现支付掉单，可以将该目标支付订单号c确定为支付掉单号c。
进一步地，当接收到的查询订单状态为未支付状态时，与该目标支付订单号在订单记录列表中的支付状态显示的未支付状态一致，可以理解为该目标支付订单号没有出现支付掉单的情况。
在步骤S105中，将订单记录列表中的目标支付订单号的支付状态更新为已支付状态，并生成支付掉单号对应的订单支付成功的提示。
在本实施例中，在将目标支付订单号确定为支付掉单号后，可以通过将订单记录列表中的目标支付订单号的支付状态更新为已支付状态，来使得目标支付订单号在订单记录列表中的支付状态显示与支付服务器提供的订单的实际支付状态保持一致，以避免订单记录异常，以及避免或消除支付掉单，从而提高对支付掉单的处理效率。
进一步地，在更新订单记录列表中的目标支付订单号的支付状态的同时，还可以生成目标支付掉单号对应的订单支付成功的提示，来及时提示用户，失效订单号实际已支付成功，避免用户因支付掉单而对同一商品进行反复支付，能够在一定程度上提高订单支付的可靠性，其中，支付掉单号对应的订单支付成功的提示具体可以表示为邮件、短信，还可以是及时信息或语音提示等，可以根据实际应用需求进行设置，此处不作具体限制。
具体地，如图9所示，当接收到支付服务器发送的查询订单状态为已支付状态，并将目标支付订单号确定为支付掉单号后，为了避免用户因支付掉单而反复发送支付请求来对同一订单进行重复支付，从而导致用户购买了多个同一商品的情况，本实施例可以将及时将订单记录列表中的目标支付订单号的支付状态更新为已支付状态，并生成支付掉单号对应的订单支付成功的及时信息提示，能够在使得目标支付订单号在订单记录列表中的支付状态显示与支付服务器提供的订单的实际支付状态保持一致，及时消除支付掉单的同时，及时提示用户订单已支付成功，从而提高对支付掉单的处理效率。
本申请实施例中，通过从订单记录列表中确定与失效订单号相匹配的目标支付订单号，以及目标支付订单号的支付状态，进而当获取到的支付状态为未支付状态时，将目标支付订单号发送至支付服务器，以使支付服务器根据目标支付订单号查询订单状态，并当接收到支付服务器发送的查询订单状态为已支付状态时，将目标支付订单号确定为支付掉单号，然后，将订单记录列表中的目标支付订单号的支付状态更新为已支付状态，并生成支付掉单号对应的订单支付成功的提示。通过上述方式，实现了通过订单记录列表中快速获取失效订单号的支付状态，并结合支付服务器反馈的查询订单状态，能够快速确定交易订单是否出现支付掉单，提高确定支付掉单的准确率，并通过更新支付掉单号在订单记录列表中支付状态，及时消除支付掉单，从而提高对支付掉单的处理效率。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的订单处理方法另一个可选实施例中，如图3所示，该方法还包括：
在步骤S301中，若所述支付状态为已支付状态，则将所述目标支付订单号确定为支付掉单号；
在步骤S302中，生成所述支付掉单号对应的订单支付成功的提示。
在本实施例中，当获取到的目标支付订单号的支付状态为已支付状态时，而失效订单号指的是超过支付时间仍未进行支付的订单号，可以理解为该失效订单号可能是由于在交易过程中的网络出错等情况，而导致了出现支付掉单的情况，则可以将目标支付订单号确定为支付掉单号，以使后续能够对已确认的支付掉单号进行及时处理，从而提高确定支付掉单的准确率以及提高对支付掉单的处理效率。
具体地，当获取到的目标支付订单号的支付状态为已支付状态时，可以理解为该目标支付订单号是支付成功的记录，可以确认目标支付订单号对应的失效订单号出现了支付掉单的情况，则可以将目标支付订单号确定为支付掉单号。
进一步地，在将目标支付订单号确定为支付掉单号的同时，还可以生成支付掉单号对应的订单支付成功的提示，来及时提示用户，失效订单号实际已支付成功，提示方式与步骤S105中生成支付掉单号对应的订单支付成功的提示的方式相似，此处不再赘余。
例如，假设一个失效订单号对应的目标支付订单号a，该目标支付订单号的支付状态为已支付的状态，为了避免目标支付订单号a是由于交易过程中网络出错等情况，导致的支付掉单情况，则可以确认该目标支付订单号a出现支付掉单，可以将该目标支付订单号a确定为支付掉单号a，同时，生成支付掉单号a的支付成功提示，以提示用户支付掉单号a对应的失效订单号已支付成功。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的订单处理方法另一个可选实施例中，如图4所示，该方法还包括：
在步骤S401中，实时监测延迟消息队列中各个待支付订单号的延迟时间是否满足超时条件，其中，延迟消息队列用于存储各个待支付订单号，各个待支付订单号来源于支付服务器；
在步骤S402中，若延迟时间满足超时条件，则将满足超时条件的待支付订单号确定为失效订单号。
在本实施例中，在通过支付订单号打开收银台之前，为了能够及时确认支付订单号中得失效订单号，并能够失效订单号是否存在支付掉单的情况进行及时处理，本实施例可以通过实时监测延迟消息队列中各个待支付订单号的延迟时间是否满足超时条件，来快速准确地判断各个待支付订单号中的失效订单号。
其中，如图13所示，延迟消息队列包括生存时间(Time To Live，TTL)队列以及死信(Dead Letter)队列，实时监测延迟消息队列中各个待支付订单号的延迟时间是否满足超时条件具体可以表现为将各个待支付订单号作为需要延时执行的任务，将这些任务添加到延迟消息队列中，并设置好延迟时间，即先通过生存时间转发器将各个待支付订单号添加至生存时间队列中，当超过过期时间之后即转变为死信，可以理解为待支付订单号超过延迟时间后且未完成支付，则可以确定为失效订单号，并可以通过死信转发器将该失效订单号转发至死信队列中，从而通过死信队列将失效订单号转发至消费者。
具体地，如图13所示，支付调用设备可以将支付订单号以及支付订单号的订单日期等订单支付信息添加至延迟消息队列中，来实时监测延迟消息队列中各个待支付订单号的延迟时间是否满足超时条件，其中，超时条件具体表现为将延迟消息队列的预设延迟时间设置为与支付订单号对应的支付时间一致，还可以是其他超时条件，此处不作具体限制，当支付订单号的延迟时间超过预设的延迟时间，即延迟时间满足超时条件，使得延迟消息队列可以及时将超过延迟时间且未完成支付的支付订单号确定为失效订单号，同时，使得延迟消息队列将该失效订单号转发到对应设置的交换机绑定的消息队列，最后转发至消费队列，以使消费者能够通过消费队列中的信息及时获取订单失效的提示，以使后续能够对失效订单号及时确认是否存在支付掉单的情况，并对存在支付掉单的失效订单号进行及时处理，无需通过定时查询来处理失效订单是否存在支付掉单，从而提高处理支付掉单的效率。
其中，消息队列是分布式***中的一个组件，主要用于解决流量削锋等问题，交换机是用于接收信息并且将接收到的信息转发到绑定的队列中，消费队列用于存储消费者的消费信息或订单信息等。
例如，支付订单号a、支付订单号b、支付订单号c、支付订单号d以及支付订单号e以及这些支付订单号对应的订单日期，添加至延迟消息队列中，且将预设延迟时间设置为与支付时间一致，如20分钟，当监测延迟消息队列中的支付订单号b、支付订单号c以及支付订单号d的延迟时间已超过预设延迟时间，即延迟时间满足超时条件，则可以将支付订单号b、支付订单号c以及支付订单号d确定为失效订单号。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的订单处理方法另一个可选实施例中，如图5所示，该方法还包括：
在步骤S501中，从业务列表中确定与失效订单号相匹配的支付订单号，其中，业务列表用于存储支付订单号、与支付订单号对应的原始业务单号，以及原始业务单号对应的支付业务参数；
在步骤S502中，将支付订单号对应的原始业务单号以及支付业务参数，发送至支付服务器，以使支付服务器根据原始业务单号以及支付业务参数更新订单号；
在步骤S503中，接收支付服务器发送的更新订单号，并将更新订单号与原始业务单号对应保存至业务列表。
在本申请实施例中，如图11所示，如果支付订单号超过支付时间还未完成支付，那么该支付订单号对应的订单将会关闭，若这时要让原订单即原始业务单号能够再次支付，支付调用设备可以获取到支付服务器提供的一个新的支付订单号来进行支付，那么此时就会出现一个原始业务单号对应多个支付订单号的情况，如果出现了支付掉单，例如原始业务A订单是使用支付订单号a来打开收银台进行交易支付的，但是由于支付订单号a超过支付时间还未完成支付，则支付订单号a失效关闭，此时变更A订单可以使用新的支付订单号b打开收银台进行交易支付，当支付订单号a出现支付掉单的情况时，即支付订单号a实际已经完成了支付，但支付调用设备中的支付订单号a对应的支付状态还是未支付状态，那么将有可能出现原始业务A订单的多次支付的情况。
进一步地，为了避免出现如原始业务A订单的多次支付的情况，在监测到延迟消息队列中的失效订单号后，可以从业务列表中查找到与失效订单号一致的支付订单号，以及该支付订单号对应的原始业务单号以及支付业务参数，并可以将获取到原始业务单号以及支付业务参数发送至支付服务器，以使支付服务器可以根据原始业务单号以及支付业务参数生成新的支付订单号，即更新订单号，然后，通过接收支付服务器发送的更新订单号，并将更新订单号与原始业务单号对应保存至业务列表，以使后续可以通过业务列表更新订单记录列表，并通过订单记录列表确认获取到的失效订单号是否存在支付掉单的情况，若不存在支付掉单的情况，则可以通过更新订单号打开收银台，以使用户完成订单支付，若存在支付掉单的情况，则无需通过更新订单号打开收银台，以避免同一原始业务单号出现多次支付的情况。
其中，业务列表是支付调用设备的存储的业务订单，用于请求收银台的待支付订单的信息来源，支付业务参数具体可以表现为订单金额，商品名称等，此处不作具体限制，原始业务单号是支付调用设备提供的订单号，可用于在改变了支付订单号之后，还能够打开收银台的订单信息还是原来的订单号。
具体地，如图12所示，在通过支付订单号打开支付收银台之前，本实施例可以将支付订单号，支付订单号的订单日期，原始业务单号，以及原始业务单号的支付业务参数等业务信息对应保存到业务列表中，支付调用设备在下一次使用原始业务单号打开支付收银台之前，可以先通过监测延迟消息队列中支付订单号的延迟时间是否满足超时时间，来确定失效订单号。如果支付订单号未失效，则可以继续使用原来保存的支付订单号打开收银台，如果已经失效，则可以将失效订单号对应的原始业务单号以及支付业务参数发送至支付服务器，以使支付服务器可以根据原始业务单号以及支付业务参数更新订单号，然后，通过接收支付服务器发送的更新订单号，以及将接收到更新订单号的时间作为订单日期，并将更新订单号、订单日期以及原始业务单号对应保存至业务列表。这样能够确保订单支付失效后，原始业务单号还能够再次进行支付，还能够在支付之前，通过业务列表更新订单记录列表，并通过订单记录列表确认获取到的失效订单号是否存在支付掉单的情况，若不存在支付掉单的情况，则可以通过更新订单号打开收银台，以使用户能够再次进行支付，若存在支付掉单的情况，则无需通过更新订单号打开收银台，能够避免同一原始业务单号出现多次支付的情况。
例如，假设一失效订单号在业务列表中对应的支付订单号为d，则将该支付订单号d对应的原始业务单号b-01以及原始业务id以及订单金额、商品名称等支付业务参数，发送至支付服务器，以使根据原始业务单号以及支付业务参数生成新的支付订单号，如支付订单号c，则可以将接收到的更新订单号c、订单日期以及原始业务单号对应保存至业务列表。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的订单处理方法另一个可选实施例中，如图6所示，该方法还包括：
在步骤S601中，接收管理人员输入的待查询订单号；
在步骤S602中，从订单记录列表中确定与待查询订单号相匹配的支付管理订单号，以及支付管理订单号的支付管理状态；
在步骤S603中，若支付管理状态为未支付状态，则将支付管理订单号发送至支付服务器查询订单状态；
在步骤S604中，若接收到支付服务器发送的查询订单状态为已支付状态，则将支付管理订单号确定为支付掉单号，并将支付管理状态更新为已支付状态。
在本实施例中，在业务列表发生变更之后，可以根据接收到待查询订单号，从订单记录列表中查询到与待查询订单号相同的支付订单号，即支付管理订单号，进而可以获取该支付管理订单号的支付管理状态，然后，当支付管理状态为超过支付时间且未支付状态，可以理解为该支付管理订单号为已失效订单，但是为了避免在交易过程中支付调用设备由于故障或网络出错等情况，导致支付状态的记录出现异常，从而导致支付掉单的情况，本实施例可以将支付管理订单号发送至支付服务器，以使服务器能够根据支付管理订单号查询订单状态，来进一步确认支付管理订单号的实际订单状态，以使后续能够查询订单状态来快速确认该支付管理订单号是否存在支付掉单，提高确定支付掉单的准确率，并及时更新订单记录列表，来对确认的支付掉单进行处理，从而在一定程度上提高处理支付掉单的效率。
具体地，在业务列表发生变更之后，管理人员可以获取从业务列表中获取到原始业务单号对应变更前的支付订单号即失效订单号，以及变更后的支付订单号，则为了避免同一原始业务单号出现多次支付的情况，可以将变更前的支付订单号作为待查询订单号，通过如图14所示的请搜索订单号的界面接收待查询订单号，进而可以在订单记录列表中快速查询到与待查询订单号一致的支付管理订单号，然后，可以通过获取该支付管理订单号的支付管理状态来判断该支付管理订单号是否存在支付掉单的情况，当支付管理状态为未支付状态时，为了进一步确认该支付管理订单号是否为支付掉单，则可以将该支付管理订单号发送至支付服务器，以使支付服务器根据支付管理订单号查询订单状态，然后，当接收到查询订单状态为已支付状态时，可以快速确认该支付管理订单号存在支付掉单的情况，则可以将该支付管理订单号确定为支付掉单号，并及时将支付管理状态更新为已支付状态，以使支付管理订单号在订单记录列表中的支付管理状态显示与支付服务器提供的订单的实际支付状态保持一致，从而提高对支付掉单的处理效率。
例如，假设接收到的待查询订单号为d，可以从订单记录列表中快速查询到与待查询订单号d相匹配的支付管理订单号d，以及支付管理订单号d的支付管理状态为未支付状态，则可以将该支付管理订单号d发送至支付服务器查询实际的订单状态，假设获取到的查询订单状态为已支付状态，则可以确认该支付管理订单号d为支付掉单号，并可以将支付管理订单号d对应的支付管理状态及时更新为已支付状态。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的订单处理方法另一个可选实施例中，如图7所示，该方法还包括：
在步骤S701中，接收订单退款请求，其中，订单退款请求包括待退款单号；
在步骤S702中，根据待退款单号，从订单记录列表中确定支付待退款单号，以及支付待退款单号的支付状态；
在步骤S703中，若支付待退款单号的支付状态为已支付状态，则将支付待退款单号发送至支付服务器，以使支付服务器根据支付待退款单号查询订单退款状态；
在步骤S704中，接收支付服务器发送的查询订单退款状态；
在步骤S705中，生成查询订单退款状态对应的订单状态提示。
在本实施例中，当用户通过电子订单购买了某商品之后，发现购买错误或不想购买该商品了，用户可以进行退款操作生成相应的订单退款请求，进而，当接收到订单退款请求时，可以获取到待退款单号，为避免商品卖方的损失，可以通过确认该商品是否已完成支付，再进行相应的退款操作，即可以根据待退款单号，从订单记录列表中确定支付待退款单号，以及支付待退款单号的支付状态，当获取到的支付待退款单号的支付状态为已支付状态，可以确认该商品已完成支付，则可以将支付待退款单号发送至支付服务器，以使支付服务器根据支付待退款单号进行相应的退款操作，并查询订单退款状态，然后，接收支付服务器发送的查询订单退款状态，并生成查询订单退款状态对应的订单状态提示，以使用户能够及时获取商品的退款状态，从而在一定程度上提高订单退款的可靠性。
具体地，当接收到订单退款请求后，可以根据获取到待退款单号，从订单记录列表中快速获取与待退款单号一致的支付订单号，即支付待退款单号，以及支付待退款单号的支付状态，若获取到的支付待退款单号的支付状态为已支付状态，则可以确认该商品已完成支付，又由于退款需要支付后的流水号，则可以从订单记录列表中获取该支付待退款单号对应的流水号，进而可以将支付待退款单号以及流水号发送至支付服务器，以使支付服务器根据流水号进行相应的退款操作，并根据支付待退款单号查询该订单的订单退款状态，然后，可以根据接收到的支付服务器返回的查询订单退款状态生成相对应的订单状态提示，能够及时进行订单退款的同时，还可以使用户能够及时获取商品的退款状态，从而在一定程度上提高订单退款的可靠性。
例如，假设用户通过订单E购买了一支铅笔，但是发现款式买错了，想要进行退款，则可以发起订单E的订单退款请求，假设待退款单号为e，则可以根据待退款单号为e从订单记录列表中获取到待退款单号为e对应的支付待退款单号e，以及支付待退款单号e的支付状态为已支付状态，以及支付待退款单号e的流水号为0003，则可以将支付待退款单号e以及流水号为0003发送至支付服务器，以使支付服务器根据流水号为0003进行退款，退款金额为1.00元，并根据支付待退款单号e查询到该订单的订单退款状态为已退款状态。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的订单处理方法另一个可选实施例中，如图8所示，该方法还包括：
在步骤S801中，接收消费查询请求，其中，订单消费请求包括待查询消费单号；
在步骤S802中，根据待查询消费单号，从订单记录列表中确定支付消费订单号，以及支付消费订单号的支付状态和支付消费订单号对应的消费金额；
在步骤S803中，根据支付消费订单号、支付消费订单号的支付状态以及支付消费订单号对应的消费金额生成消费提示。
在本实施例中，当用户通过电子订单购买多种商品之后，想要查看购买了哪些商品，以及购买的时间，以及花费的购买金额等，用户可以进行对账操作生成相应的消费查询请求，进而，当接收到消费查询请求时，可以获取到待查询消费单号，从订单记录列表中快速查询到与待查询消费单号相同的支付订单号，即支付消费订单号，以及获取到支付消费订单号的支付状态和支付消费订单号对应的消费金额，然后可以根据支付消费订单号、支付消费订单号的支付状态以及支付消费订单号对应的消费金额生成相应的消费提示，其中，消费提示方式与步骤S105中生成支付掉单号对应的订单支付成功的提示的方式相似，此处不再赘余。
具体地，当接收到消费查询请求后，可以根据获取到待查询消费单号，从订单记录列表中快速获取与待查询消费单号一致的支付订单号，即支付消费订单号，支付消费订单号的支付状态，以及支付消费订单号对应的消费金额即订单金额，还可以获取购买的商品数量以及商品名称等，此处不作具体限制，然后，根据支付消费订单号、支付消费订单号的支付状态以及支付消费订单号对应的消费金额按照预设的消费列表模板生成相应的消费列表，并将该消费列表列表以邮件的形式发送给用户，以使用户能够及时详细地获取到消费信息，以避免交易支付不清楚的情况，从而在一定程度上提高电子订单支付交易的可靠性。
例如，假设用户通过订单A购买了一个发夹和订单E购买了一把小刀，想要知道是什么时候购买的或者购买时花费了多少金额，则可以发起订单A以及订单E的分别对应的消费查询请求，假设订单A的待查询消费单号为a，以及订单E的待查询消费单号为e，则可以根据待查询消费单号为a以及待查询消费单号为e，从订单记录列表中快速获取到待查询消费单号a对应的支付消费订单号a，支付消费订单号a的支付状态为已支付状态，支付消费订单号a的消费金额为1.00元，以及待查询消费单号e对应的支付消费订单号e，以及支付待退款单号e的流水号为0003，支付消费订单号e的支付状态为已支付状态，支付消费订单号e的消费金额为1.00元，则可以根据支付消费订单号a，支付消费订单号a的支付状态为已支付状态，支付消费订单号a的消费金额为1.00元与商品名称为小花发夹，商品数量为1个，以及支付消费订单号e，支付消费订单号e的支付状态为已支付状态，支付消费订单号e的消费金额为1.00元与商品名称为玩具小刀，商品数量为1个生成相应的消费提示。
下面对本申请中的配置下发装置进行详细描述，请参阅图15，图15为本申请实施例中订单处理装置的一个实施例示意图，订单处理装置20包括：
接收单元201，用于接收失效订单查询请求，其中，失效订单查询请求包括失效订单号；
确定单元202，用于从订单记录列表中确定与失效订单号相匹配的目标支付订单号，以及目标支付订单号的支付状态，其中，订单记录列表用于存储订单支付信息；
处理单元203，用于若支付状态为未支付状态，则将目标支付订单号发送至支付服务器，以使支付服务器根据目标支付订单号查询订单状态；
处理单元203，用于若接收到支付服务器发送的查询订单状态为已支付状态，则将目标支付订单号确定为支付掉单号；
处理单元203，还用于将订单记录列表中的目标支付订单号的支付状态更新为已支付状态，并生成支付掉单号对应的订单支付成功的提示。
可选地，在上述图15对应的实施例的基础上，本申请实施例提供的订单处理装置的另一实施例中，
处理单元203，还用于若所述支付状态为已支付状态，则将所述目标支付订单号确定为支付掉单号；
处理单元203，还用于生成所述支付掉单号对应的订单支付成功的提示。
可选地，在上述图15对应的实施例的基础上，本申请实施例提供的订单处理装置的另一实施例中，
处理单元203，还用于实时监测延迟消息队列中各个待支付订单号的延迟时间是否满足超时条件，其中，延迟消息队列用于存储各个待支付订单号，各个待支付订单号来源于支付服务器；
处理单元203，还用于若延迟时间满足超时条件，则将满足超时条件的待支付订单号确定为失效订单号。
可选地，在上述图15对应的实施例的基础上，本申请实施例提供的订单处理装置的另一实施例中，
确定单元202，还用于从业务列表中确定与失效订单号相匹配的支付订单号，其中，业务列表用于存储支付订单号、与支付订单号对应的原始业务单号，以及原始业务单号对应的支付业务参数；
处理单元203，还用于将支付订单号对应的原始业务单号以及支付业务参数，发送至支付服务器，以使支付服务器根据原始业务单号以及支付业务参数更新订单号；
处理单元203，还用于接收支付服务器发送的更新订单号，并将更新订单号与原始业务单号对应保存至业务列表。
可选地，在上述图15对应的实施例的基础上，本申请实施例提供的订单处理装置的另一实施例中，
接收单元201，还用于接收管理人员输入的待查询订单号；
确定单元202，还用于从订单记录列表中确定与待查询订单号相匹配的支付管理订单号，以及支付管理订单号的支付管理状态；
处理单元203，还用于若支付管理状态为未支付状态，则将支付管理订单号发送至支付服务器查询订单状态；
处理单元203，还用于若接收到支付服务器发送的查询订单状态为已支付状态，则将支付管理订单号确定为支付掉单号，并将支付管理状态更新为已支付状态。
可选地，在上述图15对应的实施例的基础上，本申请实施例提供的订单处理装置的另一实施例中，
接收单元201，还用于接收订单退款请求，其中，订单退款请求包括待退款单号；
确定单元202，还用于根据待退款单号，从订单记录列表中确定支付待退款单号，以及支付待退款单号的支付状态；
处理单元203，还用于若支付待退款单号的支付状态为已支付状态，则将支付待退款单号发送至支付服务器，以使支付服务器根据支付待退款单号查询订单退款状态；
接收单元201，还用于接收支付服务器发送的查询订单退款状态；
处理单元203，还用于生成查询订单退款状态对应的订单状态提示。
可选地，在上述图15对应的实施例的基础上，本申请实施例提供的订单处理装置的另一实施例中，
接收单元201，还用于接收消费查询请求，其中，订单消费请求包括待查询消费单号；
确定单元202，还用于根据待查询消费单号，从订单记录列表中确定支付消费订单号，以及支付消费订单号的支付状态和支付消费订单号对应的消费金额；
处理单元203，还用于根据支付消费订单号、支付消费订单号的支付状态以及支付消费订单号对应的消费金额生成消费提示。
本申请另一方面提供了另一种计算机设备示意图，如图16所示，图16是本申请实施例提供的一种计算机设备结构示意图，该计算机设备300可因配置或性能不同而产生比较大的差异，可以包括一个或一个以***处理器(central processing units，CPU)310(例如，一个或一个以上处理器)和存储器320，一个或一个以上存储应用程序331或数据332的存储介质330(例如一个或一个以上海量存储设备)。其中，存储器320和存储介质330可以是短暂存储或持久存储。存储在存储介质330的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对计算机设备300中的一系列指令操作。更进一步地，中央处理器310可以设置为与存储介质330通信，在计算机设备300上执行存储介质330中的一系列指令操作。
计算机设备300还可以包括一个或一个以上电源340，一个或一个以上有线或无线网络接口350，一个或一个以上输入输出接口360，和/或，一个或一个以上操作***333，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。
上述计算机设备300还用于执行如图2至图8对应的实施例中的步骤。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的***，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (10)

1.一种订单处理方法，其特征在于，包括：
接收失效订单查询请求，其中，所述失效订单查询请求包括失效订单号；
从订单记录列表中确定与所述失效订单号相匹配的目标支付订单号，以及所述目标支付订单号的支付状态，其中，所述订单记录列表用于存储订单支付信息；
若所述支付状态为未支付状态，则将所述目标支付订单号发送至支付服务器，以使所述支付服务器根据所述目标支付订单号查询订单状态；
若接收到所述支付服务器发送的所述查询订单状态为已支付状态，则将所述目标支付订单号确定为支付掉单号；
将订单记录列表中的所述目标支付订单号的支付状态更新为已支付状态，并生成所述支付掉单号对应的订单支付成功的提示。
2.根据权利要求1所述的方法，其特征在于，所述从订单记录列表中确定与所述失效订单号相匹配的目标支付订单号，以及所述目标支付订单号的支付状态之后，所述方法还包括：
若所述支付状态为已支付状态，则将所述目标支付订单号确定为支付掉单号；
生成所述支付掉单号对应的订单支付成功的提示。
3.根据权利要求1所述的方法，其特征在于，所述接收失效订单查询请求之前，所述方法还包括：
实时监测延迟消息队列中各个待支付订单号的延迟时间是否满足超时条件，其中，所述延迟消息队列用于存储所述各个待支付订单号，所述各个待支付订单号来源于所述支付服务器；
若所述延迟时间满足所述超时条件，则将满足所述超时条件的所述待支付订单号确定为所述失效订单号。
4.根据权利要求3所述的方法，其特征在于，所述将满足所述超时条件的所述待支付订单号确定为所述失效订单号之后，所述方法还包括：
从业务列表中确定与所述失效订单号相匹配的支付订单号，其中，所述业务列表用于存储支付订单号、与所述支付订单号对应的原始业务单号，以及原始业务单号对应的支付业务参数；
将所述支付订单号对应的原始业务单号以及所述支付业务参数，发送至所述支付服务器，以使所述支付服务器根据所述原始业务单号以及所述支付业务参数更新订单号；
接收所述支付服务器发送的所述更新订单号，并将所述更新订单号与所述原始业务单号对应保存至所述业务列表。
5.根据权利要求4所述的方法，其特征在于，所述将所述更新订单号与所述原始业务单号对应保存至所述业务列表之后，所述方法还包括：
接收管理人员输入的待查询订单号；
从订单记录列表中确定与待查询订单号相匹配的支付管理订单号，以及所述支付管理订单号的支付管理状态；
若所述支付管理状态为未支付状态，则将所述支付管理订单号发送至支付服务器查询订单状态；
若接收到所述支付服务器发送的查询订单状态为已支付状态，则将所述支付管理订单号确定为支付掉单号，并将所述支付管理状态更新为已支付状态。
6.根据权利要求4所述的方法，其特征在于，所述将所述更新订单号与所述原始业务单号对应保存至所述业务列表之后，所述方法还包括：
接收订单退款请求，其中，所述订单退款请求包括待退款单号；
根据所述待退款单号，从订单记录列表中确定支付待退款单号，以及所述支付待退款单号的支付状态；
若所述支付待退款单号的支付状态为已支付状态，则将所述支付待退款单号发送至支付服务器，以使所述支付服务器根据所述支付待退款单号查询订单退款状态；
接收所述支付服务器发送的所述查询订单退款状态；
生成所述查询订单退款状态对应的订单状态提示。
7.根据权利要求4所述的方法，其特征在于，所述将所述更新订单号与所述原始业务单号对应保存至所述业务列表之后，所述方法还包括：
接收消费查询请求，其中，所述订单消费请求包括待查询消费单号；
根据所述待查询消费单号，从订单记录列表中确定支付消费订单号，以及所述支付消费订单号的支付状态和所述支付消费订单号对应的消费金额；
根据所述支付消费订单号、所述支付消费订单号的支付状态以及所述支付消费订单号对应的消费金额生成消费提示。
8.一种订单处理装置，其特征在于，包括：
接收单元，用于接收失效订单查询请求，其中，所述失效订单查询请求包括失效订单号；
确定单元，用于从订单记录列表中确定与所述失效订单号相匹配的目标支付订单号，以及所述目标支付订单号的支付状态，其中，所述订单记录列表用于存储订单支付信息；
处理单元，用于若所述支付状态为未支付状态，则将所述目标支付订单号发送至支付服务器，以使所述支付服务器根据所述目标支付订单号查询订单状态；
所述处理单元，还用于若接收到所述支付服务器发送的所述查询订单状态为已支付状态，则将所述目标支付订单号确定为支付掉单号；
所述处理单元，还用于将订单记录列表中的所述目标支付订单号的支付状态更新为已支付状态，并生成所述支付掉单号对应的订单支付成功的提示。
9.一种计算机设备，其特征在于，包括：存储器、收发器、处理器以及总线***；
其中，所述存储器用于存储程序；
所述处理器用于执行所述存储器中的程序时实现如权利要求1至7中任一项所述的方法；
所述总线***用于连接所述存储器以及所述处理器，以使所述存储器以及所述处理器进行通信。
10.一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如权利要求1至7中任一项所述的方法。
CN202110753155.2A 2021-07-02 2021-07-02 一种订单处理方法、相关装置、设备及存储介质 Pending CN113344680A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110753155.2A CN113344680A (zh) 2021-07-02 2021-07-02 一种订单处理方法、相关装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110753155.2A CN113344680A (zh) 2021-07-02 2021-07-02 一种订单处理方法、相关装置、设备及存储介质

Publications (1)

Publication Number Publication Date
CN113344680A true CN113344680A (zh) 2021-09-03

Family

ID=77482457

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110753155.2A Pending CN113344680A (zh) 2021-07-02 2021-07-02 一种订单处理方法、相关装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN113344680A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115797001A (zh) * 2022-11-14 2023-03-14 首约科技(北京)有限公司 报警方法、装置、电子设备及存储介质

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106127476A (zh) * 2016-06-30 2016-11-16 乐视控股（北京）有限公司 一种目标对象处理方法和装置
CN107392722A (zh) * 2017-07-27 2017-11-24 福建中金在线信息科技有限公司 订单处理方法、装置、电子设备及存储介质
CN107730366A (zh) * 2017-10-30 2018-02-23 江西博瑞彤芸科技有限公司 一种支付订单管理的信息处理方法
WO2018219047A1 (zh) * 2017-06-02 2018-12-06 口碑(上海)信息技术有限公司 一种支付方法、设备及装置
US20190139049A1 (en) * 2016-07-06 2019-05-09 Alibaba Group Holding Limited Order Information Processing Methods, Apparatuses and Systems
CN110706069A (zh) * 2019-09-25 2020-01-17 口碑(上海)信息技术有限公司 订单支付请求的异常处理方法、设备、服务器及***
CN110706071A (zh) * 2019-09-25 2020-01-17 口碑(上海)信息技术有限公司 订单支付请求的异常处理方法、设备、服务器及***
CN110706105A (zh) * 2019-09-19 2020-01-17 北京三快在线科技有限公司 差错标记方法、装置、计算机设备及存储介质
CN111192113A (zh) * 2019-12-30 2020-05-22 广州酷狗计算机科技有限公司 订单处理方法、装置、设备及存储介质
CN111507724A (zh) * 2019-01-31 2020-08-07 上海哔哩哔哩科技有限公司 一种支付验证方法及***
CN112052262A (zh) * 2020-10-09 2020-12-08 云账户技术(天津)有限公司 支付订单处理线路展示的方法、装置和电子设备
CN112150126A (zh) * 2019-06-28 2020-12-29 北京京东尚科信息技术有限公司 信息处理方法、装置、电子设备及介质
CN112200634A (zh) * 2020-10-19 2021-01-08 平安国际智慧城市科技股份有限公司 订单处理方法、装置、电子设备及存储介质
CN112396420A (zh) * 2020-12-11 2021-02-23 四川长虹电器股份有限公司 自动处理重复支付的***及方法

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106127476A (zh) * 2016-06-30 2016-11-16 乐视控股（北京）有限公司 一种目标对象处理方法和装置
US20190139049A1 (en) * 2016-07-06 2019-05-09 Alibaba Group Holding Limited Order Information Processing Methods, Apparatuses and Systems
WO2018219047A1 (zh) * 2017-06-02 2018-12-06 口碑(上海)信息技术有限公司 一种支付方法、设备及装置
CN107392722A (zh) * 2017-07-27 2017-11-24 福建中金在线信息科技有限公司 订单处理方法、装置、电子设备及存储介质
CN107730366A (zh) * 2017-10-30 2018-02-23 江西博瑞彤芸科技有限公司 一种支付订单管理的信息处理方法
CN111507724A (zh) * 2019-01-31 2020-08-07 上海哔哩哔哩科技有限公司 一种支付验证方法及***
CN112150126A (zh) * 2019-06-28 2020-12-29 北京京东尚科信息技术有限公司 信息处理方法、装置、电子设备及介质
CN110706105A (zh) * 2019-09-19 2020-01-17 北京三快在线科技有限公司 差错标记方法、装置、计算机设备及存储介质
CN110706071A (zh) * 2019-09-25 2020-01-17 口碑(上海)信息技术有限公司 订单支付请求的异常处理方法、设备、服务器及***
CN110706069A (zh) * 2019-09-25 2020-01-17 口碑(上海)信息技术有限公司 订单支付请求的异常处理方法、设备、服务器及***
CN111192113A (zh) * 2019-12-30 2020-05-22 广州酷狗计算机科技有限公司 订单处理方法、装置、设备及存储介质
CN112052262A (zh) * 2020-10-09 2020-12-08 云账户技术(天津)有限公司 支付订单处理线路展示的方法、装置和电子设备
CN112200634A (zh) * 2020-10-19 2021-01-08 平安国际智慧城市科技股份有限公司 订单处理方法、装置、电子设备及存储介质
CN112396420A (zh) * 2020-12-11 2021-02-23 四川长虹电器股份有限公司 自动处理重复支付的***及方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115797001A (zh) * 2022-11-14 2023-03-14 首约科技(北京)有限公司 报警方法、装置、电子设备及存储介质
CN115797001B (zh) * 2022-11-14 2024-01-26 首约科技(北京)有限公司 报警方法、装置、电子设备及存储介质

Similar Documents

Publication Publication Date Title
US8612348B1 (en) Systems and methods for interfacing merchants with third-party service providers
CN110458562B (zh) 票据报销方法、装置和设备及计算机存储介质
KR101804346B1 (ko) 보증 및 그 밖의 제품 정보를 관리하기 위한 클라우드 서비스 및 제품 관리 시스템
US20100299230A1 (en) Recurring transaction processing
US20180082319A1 (en) Systems and methods for providing credit to financial service accounts
CN106096926B (zh) 事件处理方法、装置、电子装置和存储介质
EP4358000A1 (en) Digital currency-based payment method, platform, terminal, and payment system
CN112308552A (zh) 医保药品的下单方法和装置
EP3485447A1 (en) System, device, and method for capturing and managing point of sale transaction related data
KR102136976B1 (ko) 토큰화된 모바일 상품권 서비스 방법 및 이를 이용한 서비스 제공 장치
CN111353841B (zh) 单据数据处理方法、装置及***
US20090299793A1 (en) System and method for automating a business process of a service provider
US20150235187A1 (en) Real-Time Data Capture and Distribution System for E-Commerce Payment Transactions
CN113344680A (zh) 一种订单处理方法、相关装置、设备及存储介质
CN112241866A (zh) 业务处理方法及装置、计算机可读介质和电子设备
CN112990871A (zh) 一种单据处理方法及相关设备
CN111274255B (zh) 业务数据监控方法及***、监控架构、设备、存储介质
KR20220082514A (ko) 오픈마켓과 연동하는 재고 관리 서버
CN112561672A (zh) 账务数据处理***、方法、装置、设备、计算机可读介质
US20200065782A1 (en) Recipient management in computer network initiated data transfers
WO2014008392A1 (en) Clearinghouse for electronic coupons
CN113487413A (zh) 一种账务处理方法、装置、电子设备及计算机可读介质
CN116433304A (zh) 业务对象取价方法、计算机设备及计算机存储介质
CA2986818A1 (en) Payment system based on different funds servers, and payment method, device and server therefor
CN114155107A (zh) 消息处理方法、装置、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination