CN113222701A - 订单状态查询方法、装置及存储介质 - Google Patents

订单状态查询方法、装置及存储介质 Download PDF

Info

Publication number
CN113222701A
CN113222701A CN202110536764.2A CN202110536764A CN113222701A CN 113222701 A CN113222701 A CN 113222701A CN 202110536764 A CN202110536764 A CN 202110536764A CN 113222701 A CN113222701 A CN 113222701A
Authority
CN
China
Prior art keywords
order
commodity
payment
probability
information
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
CN202110536764.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.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen 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 Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202110536764.2A priority Critical patent/CN113222701A/zh
Publication of CN113222701A publication Critical patent/CN113222701A/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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • 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/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • 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/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • G06Q30/0202—Market predictions or forecasting for commercial activities
    • 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/0623—Item investigation

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Databases & Information Systems (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Data Mining & Analysis (AREA)
  • Game Theory and Decision Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请公开了一种订单状态查询方法、装置及存储介质，商户服务器未接收到支付系统返回的支付结果通知，不是直接查询支付系统中订单的支付状态，而是先由商户服务器从订单中的用户购买该商品的购买概率、该商品被购买的概率，以及根据网络环境状况判断该订单出现异常的概率，综合评估该订单出现支付状态不一致现象的概率，只有支付状态不一致概率大于等于查单预设阈值的订单才会继续查询支付系统；而支付状态不一致概率小于查单预设阈值的订单不再查询支付系统，因此减少支付系统的订单查询数量，进而降低了订单查询的资源开销成本，同时提升订单查询响应速度。

Description

订单状态查询方法、装置及存储介质
技术领域
本申请涉及计算机技术领域，尤其涉及订单状态查询方法、装置、终端及存储介质。
背景技术
用户在电商平台选择需要购买的商品或服务后进行付款，支付系统会通知电商平台该订单的支付结果通知，如支付成功或支付失败。但是，在系统或网络环境出现异常的情况下，会出现用户已经支付订单，但电商平台收不到支付结果通知，此时，电商平台会将该订单标记为未支付，而在支付系统中该订单为已支付状态，从而导致电商平台中的订单支付状态与支付系统中的订单支付状态不一致，进而影响电商平台对该订单进一步处理。
发明内容
有鉴于此，本申请提供了一种订单状态查询方法、装置及存储介质，以解决相关技术无法快速确定出电商平台中订单支付状态与支付系统中的订单支付状态不一致的技术问题，其公开了如下技术方案：
为实现上述目的，一方面，本申请提供了一种订单状态查询方法，所述方法包括：
获取待查询订单的订单信息及当前网络环境的网络状态信息，所述订单信息包括商品信息及购买订单中商品的用户的用户信息；
根据所述商品信息、所述用户信息和所述网络状态信息，获得所述待查询订单的支付状态不一致概率，所述支付状态不一致表征用户已支付订单且订单为未支付状态；
在所述待查询订单的支付状态不一致概率大于等于查单预设阈值的情况下，查询支付系统中所述待查询订单的支付状态，得到所述待查询订单的订单状态结果。
在一种可能的实现方式中，所述根据所述商品信息、所述用户信息和所述网络状态信息，获得所述待查询订单的支付状态不一致概率，包括：
根据所述商品信息和所述用户信息，获得所述用户支付所述待查询订单的概率；
根据所述网络状态信息获得所述待查询订单的支付过程出现异常的概率；
根据所述用户支付所述待查询订单的概率及所述待查询订单的支付过程出现异常的概率，确定所述待查询订单的支付状态不一致概率。
在另一种可能的实现方式中，所述根据所述商品信息和所述用户信息，获得所述用户支付所述待查询订单的概率，包括：
将所述商品信息和所述用户信息输入购买率预测模型，获得所述用户购买所述商品的购买概率；
将所述商品信息输入商品热度预测模型，获得所述商品被购买的概率；
根据所述用户购买所述商品的购买概率及所述商品被购买的概率，获得所述用户支付所述待查询订单的概率。
在又一种可能的实现方式中，所述将所述商品信息输入商品热度预测模型，获得所述商品被购买的概率，包括：
所述商品是历史商品，获取所述商品的首次上架时间；
将所述首次上架时间和当前时间发送至历史商品热度预测模型，获得所述商品被购买的概率，其中，所述历史商品热度预测模型由所述商品的历史数据训练得到。
在另一种可能的实现方式中，所述将所述商品信息输入商品热度预测模型，获得所述商品被购买的概率，包括：
所述商品为新上架商品，获取所述商品分别在至少两个不同时间段对应的支付数据；
将所述支付数据发送至新上商品热度预测模型，获得所述商品被购买的概率，其中，所述新上商品热度预测模型包括各个时间段对应的权重系数及平均支付数据。
在又一种可能的实现方式中，所述方法还包括：
所述待查询订单的支付状态不一致概率小于所述查单预设阈值的情况下，不触发查询所述支付系统中所述待查询订单的支付状态的步骤。
在另一种可能的实现方式中，所述方法还包括：
根据订单支付状态不一致的订单数量及订单查询总数，获得有效查单率；
若所述有效查单率大于预设值，减小所述查单预设阈值；
若所述有效查单率小于所述预设值，增大所述查单预设阈值。
在又一种可能的实现方式中，确定待查询订单的过程，包括：
将未接收到支付系统返回的支付结果通知的订单，确定为待查询订单。
另一方面，本申请还提供了一种订单状态查询装置，包括：
处理器和存储器；
其中，所述处理器用于执行所述存储器中存储的程序；
所述存储器用于存储程序，所述程序至少用于：
获取待查询订单的订单信息及当前网络环境的网络状态信息，所述订单信息包括商品信息及购买订单中商品的用户的用户信息；
根据所述商品信息、所述用户信息和所述网络状态信息，获得所述待查询订单的支付状态不一致概率，所述支付状态不一致表征用户已支付订单且订单为未支付；
所述待查询订单的支付状态不一致概率大于等于查单预设阈值的情况下，查询支付系统中所述待查询订单的支付状态，得到所述待查询订单的订单状态结果。
又一方面，本申请提供了一种存储介质，所述存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现如上任一项所述的订单状态查询方法。
再一方面，本申请还提供了一种计算机程序产品，当在电子设备上执行时，适于执行初始化有上述任一项所述的订单状态查询方法。
本申请提供的订单状态查询方法，由服务器获取待查询订单的订单信息，其中，订单信息包括商品信息及购买订单中商品的用户的用户信息；以及，获取当前网络环境的网络状态信息；进一步，根据商品信息、用户信息及网络状态信息获得待查询订单的支付状态不一致概率，其中，支付状态不一致是指用户已支付订单但订单为未支付状态；对于支付状态不一致概率大于等于查单预设阈值的订单，才进一步查询支付系统中该订单的支付状态得到待查询订单的订单状态结果。由上述过程可知，该方案在向支付系统查询订单的支付状态之前，先获得订单的支付状态不一致概率，并过滤掉概率小于查单预设阈值的订单，进一步只对概率大于查单预设阈值的订单，向支付系统查询该订单的状态，可见，该方案降低了向支付系统查单的订单数量，因此降低了订单查询的资源开销成本，进而提高了订单查询的响应速度。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1是本申请实施例提供的一种订单查询系统的示意图；
图2是本发明实施例提供的分布式系统应用于区块链系统的一个可选的结构示意图；
图3是本发明实施例提供的区块结构一个可选的示意图；
图4是本发明实施例提供的一种订单状态查询方法的流程图；
图5是本发明实施例提供的另一种订单状态查询方法的流程图；
图6是新旧方案的有效查单率的对比示意图；
图7是本申请实施例提供的一种订单状态查询方法的流程图；
图8是本申请实施例提供的一种订单状态查询装置的结构示意图；
图9是本申请实施例提供的又一种订单状态查询装置的结构示意图；
图10是本申请实施例提供的一种终端的结构示意图。
具体实施方式
相关技术中，在系统或网络环境出现异常的情况下，可能会出现用户已经支付订单，但未收到支付系统返回的支付结果通知，此种情况下，电商平台在无法获知订单支付结果，可能会频繁地向支付系统发起订单查询请求，从而增加订单查询的资源开销成本，而且，查询的订单中可能包括很多无效查询，如支付失败的订单，进而极大地影响了电商平台和支付系统中状态不一致的订单确定的速度。为了解决上述技术问题，本申请提供了一种订单状态查询方法，该方案根据订单中的商品信息和用户信息，以及网络状态信息获得该订单的支付状态不一致概率，该概率大于等于查单预设阈值后才进一步查询支付系统中该订单的状态，从而减少订单查询数量，进而降低了订单查询的资源开销成本，同时提升订单查询响应速度。
为了便于理解本申请的订单查询方法，下面对于本申请的订单查询系统进行介绍。
请参见图1，示出了本申请实施例提供的一种订单查询系统的示意图，该系统包括商户客户端1、商户服务器2、支付服务器3。
其中，商户客户端1可以是运行在智能手机、平板电脑、智能穿戴设备等移动终端上的应用程序，或者，可以是运行在个人计算机等终端设备上的程序。
商户服务器2是与客户端1进行交互为用户提供商品或服务的服务器，如，商户服务器。
商户客户端1与商户服务器2之间通过网络1进行交互通信，商户服务器2与支付服务器3之间通过网络2进行交互通信，其中，网络1和网络2均为互联网，为了清晰表示商户服务器2分别与商户客户端1、支付服务器3之间传递的信息不同，固将网络表示为网络1和网络2。
支付服务器3是提供支付服务的服务器或云服务。
本申请中的服务器可以是独立服务器或多台独立服务器构成的服务器集群。
用户可以通过商户客户端1选择需要购买的商品(如，实际物品或虚拟物品)并下单，用户确定结算订单后，商户客户端1的显示界面会进入结算界面并跳转至支付系统的支付页面。在商户客户端1的显示页面跳转至支付页面后，用户在支付页面输入支付密码等支付信息并发送至支付系统(即，支付服务器3)。
其中，支付系统可以是能够提供支付服务的任一系统，例如，微信支付系统或其他支付系统。
支付服务器3接收用户的支付信息后发起扣费，并向商户服务器2返回支付结果通知，但是，在支付系统异常或网络异常等异常情况下，商户服务器2无法接收到支付系统返回的支付结果通知。当商户服务器在向支付系统发送支付信息后的预设时长内未接收到支付系统返回的支付结果通知，则记录该订单的状态是未支付状态。
对于未支付状态的订单，商户服务器2会根据订单信息及当前网络环境的网络状态信息，获得该订单的支付状态不一致概率，对于支付状态不一致概率大于等于查单预设阈值的订单，才会进一步查询支付系统中该订单的支付状态。其中，支付状态不一致指用户已支付订单但在商户服务器中该订单为未支付状态。
本发明实施例涉及的系统可以是由客户端、多个节点(接入网络中的任意形式的计算设备，如服务器、用户终端)通过网络通信的形式连接形成的分布式系统。
以分布式系统为区块链系统为例，参见图2，图2是本发明实施例提供的分布式系统100应用于区块链系统的一个可选的结构示意图，由多个节点(接入网络中的任意形式的计算设备，如服务器、用户终端)和客户端形成，节点之间形成组成的点对点(P2P，Peer ToPeer)网络，P2P协议是一个运行在传输控制协议(TCP，Transmission Control Protocol)协议之上的应用层协议。在分布式系统中，任何机器如服务器、终端都可以加入而成为节点，节点包括硬件层、中间层、操作系统层和应用层。
参见图2示出的区块链系统中各节点的功能，涉及的功能包括：
1)路由，节点具有的基本功能，用于支持节点之间的通信。
节点除具有路由功能外，还可以具有以下功能：
2)应用，用于部署在区块链中，根据实际业务需求而实现特定业务，记录实现功能相关的数据形成记录数据，在记录数据中携带数字签名以表示任务数据的来源，将记录数据发送到区块链系统中的其他节点，供其他节点在验证记录数据来源以及完整性成功时，将记录数据添加到临时区块中。
例如，应用实现的业务可以包括：
2.1)钱包，用于提供进行电子货币的交易的功能，包括发起交易(即，将当前交易的交易记录发送给区块链系统中的其他节点，其他节点验证成功后，作为承认交易有效的响应，将交易的记录数据存入区块链的临时区块中；当然，钱包还支持查询电子货币地址中剩余的电子货币；
2.2)共享账本，用于提供账目数据的存储、查询和修改等操作的功能，将对账目数据的操作的记录数据发送到区块链系统中的其他节点，其他节点验证有效后，作为承认账目数据有效的响应，将记录数据存入临时区块中，还可以向发起操作的节点发送确认。
2.3)智能合约，计算机化的协议，可以执行某个合约的条款，通过部署在共享账本上的用于在满足一定条件时而执行的代码实现，根据实际的业务需求代码用于完成自动化的交易，例如查询买家所购买商品的物流状态，在买家签收货物后将买家的电子货币转移到商户的地址；当然，智能合约不仅限于执行用于交易的合约，还可以执行对接收的信息进行处理的合约。
3)区块链，包括一系列按照产生的先后时间顺序相互接续的区块(Block)，新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链系统中节点提交的记录数据。
参见图3，图3是本发明实施例提供的区块结构(Block Structure)一个可选的示意图，每个区块中包括本区块存储交易记录的哈希值(本区块的哈希值)、以及前一区块的哈希值，各区块通过哈希值连接形成区块链。另外，区块中还可以包括有区块生成时的时间戳等信息。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了相关的信息，用于验证其信息的有效性(防伪)和生成下一个区块。
下面将结合图4对商户服务器向支付系统查询订单的支付状态的过程进行详细介绍。
参见图4，图4是本发明实施例提供的一种订单状态查询方法的流程图，如图4所示，该订单状态查询方法包括：
S110，商户服务器获取待查询订单的订单信息及当前网络环境的网络状态信息。
其中，订单信息包括商品信息及购买订单中商品的用户对应的用户信息。
在一示例性实施例中，待查询订单是商户客户端提交到商户服务器的所有订单中，未接收到支付系统返回的支付结果通知的订单。
S120，商户服务器根据商品信息、用户信息和网络状态信息，获得待查询订单的支付状态不一致概率。
其中，支付状态不一致表征用户已支付订单且订单为未支付状态。
在一示例性实施例中，获得订单的支付状态不一致概率的过程可以包括以下步骤：
1)根据商品信息和用户信息，获得用户支付待查询订单的概率。
在一示例性实施例中，获得用户支付订单的概率的过程可以包括以下步骤：
11)将商品信息和用户信息输入购买率预测模型，获得用户购买该商品的购买概率。
12)将商品信息输入商品热度预测模型，获得该商品被购买的概率。
某个商品的热度越高则该商品被购买的概率也越高。
13)根据用户购买商品的购买概率及商品被购买的概率，获得用户支付待查询订单的概率。
用户支付某个订单的概率与商品被购买的概率，以及用户购买该商品的购买概率正相关，例如，该用户购买该商品的购买概率越高，且该商品被购买的概率越高，则该用户支付该商品订单的概率也越高。
2)根据网络状态信息获得待查询订单的支付过程出现异常的概率。
其中，网络状态信息包括但不限于：某个地区在一段时间内出现网络故障的总时长、商户服务器某个时间对应的网络负载率，以及，某区域内出现网络故障的信息。
例如，可以利用某个地区在一段时间内出现网络故障的总时长可以获得该地区的网络出现故障的概率。可以利用某区域内出现网络故障的信息获得该区域的网络出现故障的概率。对于某个区域(其中，区域的范围小于地区)，根据该区域所属地区的网络出现网络故障的概率、商户服务器此时的网络负载率，以及该区域出现网络故障的概率获得该区域内的用户在支付过程中出现异常的概率。
3)根据用户支付待查询订单的概率及待查询订单的支付过程出现异常的概率，确定待查询订单的支付状态不一致概率。
其中，订单的支付状态不一致概率与用户支付订单的概率及订单的支付过程出现异常的概率正相关，例如，用户支付订单的概率越高，且该订单在支付过程中出现异常的概率越高，则该订单的支付状态不一致概率越高。
进一步，商户服务器根据订单的支付状态不一致概率决定是否向支付系统发起查单请求。
S130，在待查询订单的支付状态不一致概率大于等于查单预设阈值的情况下，查询支付系统中该待查询订单的支付状态，得到该待查询订单的订单状态结果。
查单预设阈值可以根据实际需求设定，如查单预设阈值的初始值可以根据有效次试验获得，而且，后续可以根据有效查单率更新查单预设阈值。
商户服务器向支付系统发起查单请求的订单必然是未收到支付系统返回的支付结果通知的订单，而商户服务器会将此类订单的支付状态标记为未支付状态。
如果支付系统中该订单为支付成功，则确定该订单在商户服务器的状态与支付系统中的状态不一致，而且，以支付系统中的支付状态作为该订单的最终支付状态。
如果支付系统中该订单为支付失败，则确定该订单在商户服务器和支付系统中的状态一致，且最终支付状态为支付失败。
在本申请的其他实施例中，如果订单的支付状态不一致概率小于查单预设阈值，初步确定该订单为无效订单(如，用户没有支付的订单)，不会向支付系统发起查单请求，可见，该方案减少了无效订单的查询数量。
本实施例提供的订单状态查询方法，由商户服务器获取待查询订单的订单信息，其中，订单信息包括商品信息及购买订单中商品的用户对应的用户信息；以及，获取当前网络环境的网络状态信息；进一步，根据商品信息、用户信息及网络状态信息获得待查询订单的支付状态不一致概率，对于该概率大于等于查单预设阈值的订单，才进一步查询支付系统中该订单的支付状态得到待查询订单的订单状态结果；其中，支付状态不一致是指用户已支付订单但订单为未支付状态。由上述过程可知，该方案在向支付系统查询订单的支付状态之前，先获得订单的支付状态不一致概率，并过滤掉概率小于查单预设阈值的订单，进一步只对概率大于查单预设阈值的订单，向支付系统查询该订单的状态，可见，该方案降低了向支付系统查单的订单数量，因此降低了订单查询的资源开销成本，进而提高了订单查询的响应速度。
参见图5，图5是本发明实施例提供的另一种订单状态查询方法的流程图，本实施例将着重介绍商户服务器获取订单的订单状态结果的过程。如图5所示，该方法主要包括如下步骤：
S210，商户服务器获取待查询订单的订单信息，以及当前网络环境的网络状态信息。
其中，订单信息包括商品信息和用户信息。网络状态信息表征服务器所处的网络环境的稳定性。
S220，商户服务器根据商品信息、用户信息，以及网络状态信息，获得待查询订单的支付状态不一致概率。
在本发明的一个实施例中，订单的支付状态不一致概率可以从以下两个维度进行衡量，分别是：用户支付订单的概率、订单支付过程出现异常的概率；其中，用户支付订单的概率与用户购买概率及商品被购买的概率正相关。而且，订单支付过程出现异常的概率主要与当前网络环境的网络状态信息有关。因此，订单的支付状态不一致概率可以从用户购买概率、商品被购买的概率及网络环境状况三个维度衡量。
1)用户购买概率(F1)
订单信息中通常包括用户所购买的商品信息以及用户信息，如商品信息可以包括商品唯一标识(如itemid)，用户信息包括用户标识(如uin)。通过用户信息和商品信息判断该用户购买该商品的概率F1，例如，某游戏用户，该用户购买一个皮肤和最新是否玩过这个游戏以及最近对局是否出现过这个皮肤正相关。
用户购买这个商品的概率可以调用商品推荐数据平台中的接口获得，其中，商品推荐数据平台中部署有购买率预测模型，通过调用该平台的接口将商品信息和用户信息输入购买率预测模型，通过该购买率预测模型获得该用户购买该商品的概率，并通过上述接口返回给商户服务器，其中，F1的数值范围是[0,1]。
2)商品被购买的概率(F2)
不同商品的热度不一样，例如优惠商品和返场商品的热度大于等于冷门商品的热度。一个热度高的商品被购买的概率大于冷门商品，因此，可以通过分析商品的热度确定该商品被购买的概率。
在本发明的一个应用场景中，用户购买的商品是历史商品，即已上架一段时间且具有一定数量的销售数据的商品。此种应用场景下，商户服务器通过调用历史商品热度预测模型获得订单中的商品被购买的概率，其中，商品热度预测模型可以采用公式1表示：
F2(today,pubdate)＝m*e-(pubdate-today) (式1)
其中，today表示当前时间，pubdate表示商品首次上架时间，m为拟合系数，m的具体数值可以通过该商品在上架后每个周期(例如，每天、每周)的销售数据拟合得到。其中，F2的数值范围是[0,1]。
在本发明的另一个应用场景中，用户购买的商品是新上架商品，即没有销售数据的商品。此种应用场景下，商户服务器可以调用新上商品热度预测模型获得订单中商品被购买的概率，其中，新上商品热度预测模型可以采用公式2表示：
F2(itemid)＝a*PV_i/i+b*PV_j/j+...+c*PV_k/k (式2)
公式2中，F2的数值范围是[0,1]，该数值越大表示该商品被用户购买的概率越高。
PV_i表示i个周期时间段内不同用户针对某一商品(itemid对应的商品)的支付次数，例如PV_1表示1个周期内的支付次数，以此类推，PV_30表示30个周期内针对该商品的支付次数，其中，周期可以应用需求自行设定，例如，1个周期是1天，又如，1个周期可以是少于1天或多于1天的时长。
在一种可能的实现方式中，可以从后台系统的支付交易信息中获得一段时间内该商品的支付交易次数。
PV_i/i表示i个周期内每个周期某商品(itemid对应的商品)的平均支付次数，例如，PV_3/3表示3个周期内该商品的平均支付次数，以此类推，PV_30/30表示30个周期内该商品的平均支付次数；其中，i、j、……、k的数值可以根据应用需求设定，兼顾短期和长期数据即可，例如，某个商品已上架10天，则从这10天中分别选择1、3、5、7、10这几天的支付数据按照公式2计算得到该商品被购买的概率。
例如，PV_3＝210表示3个周期内该商品的支付次数是210次，PV_3/3＝70表示这3个周期内平均每个周期支付70次。
a、b、……、c，分别表示不同周期对应的加权支付因子，各个加权支付因子的具体数值可以根据实际应用需求设定，其中，各个加权支付因子需要满足如下约束条件：a+b+……+c＝1。
例如，分别取某商品在1、3、5、7、10、15、20、30个周期内的支付数据，按照公式3计算得到该商品的被购买的概率：
Figure BDA0003069939080000121
上述的新上商品热度预测模型结合短期和长期的因素综合判断商品的热度，防止单一周期内异常的支付带来的偏差，例如，某个用户3天内支付了200次，但最近30天只支付了200次，并不代表该用户近期对该商品有偏爱。
3)网络环境评估
如果支付下单量比较大则出现订单的支付状态不一致概率较大，同理，如果网络状况较差，则出现订单的支付状态不一致概率较大。因此，可以从用户所在地区、商户服务器的负载和网络状况综合评估商户服务器的网络环境，进而评估订单的支付状态不一致概率。
在本发明的一个实施例中，订单出现异常的概率可以采用公式4表示：
Figure BDA0003069939080000122
公式4中，F3表示用户的网络出现故障的概率，其数值范围是[0,1]，数值越大表示该用户的订单出现异常的概率越大；其中，X(area)表示用户所在地区的网络故障的概率，可以利用用户所在地区在一段时间内出现网络故障的总时长除以该段时间的时长得到；Y(load)表示商户服务器的网络负载率，该参数的数值可以从商户服务器的监控数据中直接获得；Z(networkStatus)表示某个区域内出现网络故障的概率，其中区域范围小于地区，与X(area)的获取过程相似，利用用户所处区域在一段时间内出现网络故障的总时长除以该段时间的时长得到；a、b、c分别表示X(area)、Y(load)和Z(networkStatus)的加权因子，其中，a、b、c的具体数值满足约束条件：a+b+c＝1，a、b、c的具体数值可以根据实际网络环境设定，例如，a＝0.1、b＝0.5、c＝0.4。
最后，根据上述三个维度的概率获得订单的支付状态不一致概率，如公式5所示：
F＝m*F1+n*F2+o*F3 (式5)
公式5中，F表示某个订单的状态不一致的概率，F的数值范围是[0,1]，F的数值越大表示订单出现不一致的概率越高，反之，数值越小订单出现不一致的概率越低。
F1表示该订单对应的用户购买该订单中的商品的概率，F2表示该订单中的商品被购买的概率，F3表示订单出现异常的概率。其中，对于上架时间超过预设时间的商品，采用公式1获得F2的数值；如果上架时间短于预设时间的商品，采用公式2获得F2的数值。
其中，m、n、o分别表示F1、F2、F3的加权因子，且满足约束条件：m+n+o＝1，m、n、o的数值可以根据实际支付数据拟合得到，例如，m＝0.3，n＝0.2，o＝0.5。
S230，在待查询订单的支付状态不一致概率大于查单预设阈值的情况下，商户服务器向支付系统发起待查询订单的查单请求。
查单预设阈值可以根据实际应用需求设定，例如，查单预设阈值的初始值可以根据有效次试验获得。
在一种应用场景中，商户服务器只针对概率大于查单预设阈值的订单，向支付系统发起查单请求。
在另一种应用场景中，例如，用户支付订单后一直未收到支付结果通知，此种情况下，用户可以在商户客户端上进行订单查询操作，向商户服务器发起订单查询请求，商户服务器接收到该订单查询请求后，可以直接向支付系统发起查询请求。
S240，商户服务器接收支付系统返回的待查询订单的支付状态。
支付系统接收到商户服务器发送的订单查询请求，该订单查询请求中携带该订单的信息，如订单中的商品信息、用户信息、订单的唯一标识等信息，支付系统根据订单信息查询获得该订单的支付状态(如，支付成功或支付失败)并反馈至商户服务器。
S250，商户服务器比较待查询订单在商户服务器和支付系统中的支付状态是否一致；如果不一致，则执行S260；如果一致，则执行S270。
商户服务器向支付系统发起查单请求的订单必然是未收到支付系统返回的支付结果通知的订单，而商户服务器会将此类订单的支付状态标记为未支付状态。因此，如果支付系统返回的支付状态是支付失败，则确定该订单的支付状态一致；如果支付系统返回的支付状态是支付成功，则确定该订单的支付状态不一致。
S260，商户服务器确定待查询订单的支付状态为支付成功。
待查询订单在商户服务器中的支付状态与其在支付系统中的支付状态不一致，以支付系统中的支付状态作为该待查询订单的支付状态。此外，商户服务器还可以向商户客户端返回订单支付成功的通知。进一步，商户服务器还可以直接触发商户统一补发货系统针对该订单进行补发货，并向商户客户端发送订单发货通知，商户客户端在显示界面上显示该订单发货通知，以提醒用户该订单的最新状态。
S270，商户服务器确定待查询订单的支付状态为支付失败。
进一步，商户服务器向商户客户端返回订单支付失败的通知，商户客户端在显示界面上显示支付失败的通知，以便提醒用户该订单的最新状态。
在本发明的一个实施例中，如图5所示，该方法还可以包括以下步骤：
S280，商户服务器根据支付状态不一致的订单数量与订单查询总数，获得有效查单率。
其中，有效查单率是支付状态不一致的订单数量与订单查询总数的比值。S290，商户服务器根据有效查单率调整查单预设阈值。
若有效查单率大于预设值，减小查单预设阈值；若有效查单率小于预设值，增大查单预设阈值。
其中，预设值可以根据实际需求自行设定。如果有效查单率大于预设值，表明所查订单中的支付状态确实不一致的订单的数量较多，因此，可以适当减小查单预设阈值，以避免漏查。
如果有效查单率较小，如小于最小预设值，表明查单中存在较多无效查询，此种情况下需要适当增大查单预设阈值，从而减少查单数量。
此外，还可以利用有效查单率和漏查比例来评估商户服务器的查单效果。
漏查比例＝对账查找订单数量/查单总数；对账查找订单数量是指通过对账结算发现商户服务器和支付系统中订单的支付状态不一致的订单数量。漏查比例越接近于零，表明商户服务器的查单效果越好，反之，商户服务器的查单效果越差。
经验证，采用本发明提供的订单状态查询方案后，有效查单率比较高，漏查比例接近于零。
参见图6，示出了新旧方案的有效查单率的对比示意图，曲线1为采用本发明提供的订单状态查询方案获得的有效查单率，曲线2是采用传统的查单方案获得的有效查单率。如图6所示，曲线1中各个点的数值均大于曲线2中各个点的数值，可见，本发明提供的方案的效果优于传统的查单方案。
本实施例提供的订单状态查询方法，商户服务器未接收到支付系统返回的支付结果通知，不是直接查询支付系统中的支付状态，而是先由商户服务器从订单中的用户购买该商品的购买概率、该商品被购买的概率，以及根据网络环境状况判断该订单出现异常的概率，综合评估该订单出现支付状态不一致现象的概率，只有支付状态不一致概率大于等于查单预设阈值的订单才会继续查询支付系统；而支付状态不一致概率小于查单预设阈值的订单不再查询支付系统，因此减少支付系统的订单查询数量，进而降低了订单查询的资源开销成本，同时提升订单查询响应速度，因此利用该方案能够快速确定出订单的支付状态不一致的订单。此外，本实施例提供的订单状态查询方法还统计有效查单率，并根据有效查单率调整查单预设阈值，利用调整后查单预设阈值进行查单判断，进一步提高了查单的准确度。
下面将结合图7所示的示例介绍本发明提供的订单状态查询方法的流程，其中，图7中的商户支付系统、商户发货系统订单MQ、商户统一补发或系统、支付分析系统和商户结算系统均是商户服务器内的系统。
如图7所示，订单状态查询方法可以包括以下步骤：
S310，用户在商户客户端上选择所要购买的商品并下单结算。
S320，商户支付系统将订单存入订单队列中。
用户下单结算的信息发送至商户支付系统，商户支付系统将接收到的订单信息存储至订单MQ中。
S330，商户支付系统调用支付渠道方的接口，获取支付渠道方的支付URL。
支付渠道方是支付服务提供商，即支付系统服务器。
S340，商户支付系统将支付URL返回给商户客户端，商户客户端的显示页面跳转至支付页面，用户输入支付信息，支付渠道方后台发起扣费。
S350，用户支付成功后，支付渠道方通知商户发货系统支付成功。
S360，商户发货系统进行发货操作。
S370，商户发货系统向商户客户端发送发货通知。
S380，商户发货系统会将支付流水发送至商户结算系统。
商户结算系统用来与支付渠道方进行对账结算操作。
S390，订单MQ向商户统一补发货系统发送待查询订单的信息。
S3100，商户统一补发货系统将待查询订单的信息发送至支付分析系统，支付分析系统分析订单的支付状态不一致概率。
S3110，当概率大于等于查单预设阈值时，触发商户统一补发货系统向支付渠道方发起查单。
S3120，当概率小于查单预设阈值时，商户统一补发货系统放弃查单。
S3130，商户统一补发货系统接收支付渠道方返回的订单的支付状态，并当支付状态不一致时，触发商户发货系统进行补发货。
S3140，商户发货系统向商户客户端发送发货通知。
在本实施例中，该发货通知即上述的订单状态结果。
S3150，商户发货系统向商户结算系统发送该订单的支付流水。
商户发货系统进行补发货后，向商户结算系统发送该订单的支付流水，以便商户结算系统与支付系统进行对账结算。
本实施例提供的订单状态查询方法，在向支付渠道方查询订单的支付状态之前先由支付分析系统分析订单的状态与支付渠道方的支付状态不一致概率，当该概率值大于等于查单预设阈值时才进行查单，否则放弃查单，因此，降低了查单频率，进而降低了查单的开销成本。
另一方面，本申请还提供了订单状态查询装置，参见图8，示出了本申请的订单状态查询装置的一种结构示意图，如图8所示，该装置可以包括：
第一获取模块110，用于获取待查询订单的订单信息，订单信息包括商品信息和用户信息。
第二获取模块120，用于获取当前网络环境的网络状态信息。
订单状态分析模块130，用于根据商品信息、用户信息，以及网络及负载状况信息，获得待查询订单的支付状态不一致概率。
在本申请的一个实施例中，订单状态分析模块130包括：
支付订单概率确定子模块，用于根据商品信息和用户信息，获得用户支付待查询订单的概率。
支付异常概率确定子模块，用于根据网络状态信息获得待查询订单的支付过程出现异常的概率。
支付状态不一致概率确定子模块，用于根据用户支付待查询订单的概率及待查询订单的支付过程出现异常的概率，确定待查询订单的支付状态不一致概率。
在一示例性实施例中，支付订单概率确定子模块可以包括：
购买概率确定子模块，用于将商品信息和用户信息输入购买率预测模型，获得用户购买商品的购买概率；
商品被购买概率确定子模块，用于将商品信息输入商品热度预测模型，获得商品被购买的概率；
支付概率确定子模块，用于根据用户购买商品的购买概率及商品被购买的概率，获得用户支付待查询订单的概率。
在不同应用场景下，商品被购买概率确定子模块的功能有所不同：
1)商品为历史商品，此种场景下，商品被购买概率确定子模块，具体用于：
获取商品的首次上架时间，并将首次上架时间和当前时间发送至历史商品热度预测模型，获得商品被购买的概率；其中，历史商品热度预测模型由商品的历史数据训练得到。
2)商品为新上架商品，此种应用场景下，商品被购买概率确定子模块，具体用于：
获取商品分别在至少两个不同时间段对应的支付数据；
将支付数据发送至新上商品热度预测模型，获得商品被购买的概率，其中，新上商品热度预测模型包括各个时间段对应的权重系数及平均支付数据。
订单查询模块140，用于在待查询订单的支付状态不一致概率大于查单预设阈值的情况下，查询支付系统中待查询订单的状态得到待查询订单对应的订单状态结果。
本实施例提供的订单状态查询装置，商户服务器未接收到支付系统返回的支付结果通知，不是直接查询支付系统中该订单的支付状态，而是先由商户服务器从订单中的用户购买该商品的购买概率、该商品被购买的概率，以及根据网络环境状况判断该订单出现异常的概率，综合评估该订单出现支付状态不一致现象的概率，只有支付状态不一致概率大于等于查单预设阈值的订单才会继续查询支付系统；而支付状态不一致概率小于查单预设阈值的订单不再查询支付系统，因此减少支付系统的订单查询数量，进而降低了订单查询的资源开销成本，同时提升订单查询响应速度，因此利用该方案能够快速确定出订单的支付状态不一致的订单。参见图9，图9是本申请实施例提供的又一种订单状态查询装置的结构示意图，本实施例提供的订单状态查询装置在图8所示实施例的基础上还包括：
有效查单率确定模块210，用于根据订单的支付状态不一致的订单数量及订单查询总数，获得有效查单率。
阈值减小模块220，用于当有效查单率大于预设值时，减小查单预设阈值。
阈值增大模块230，用于当有效查单率小于预设值时，增大查单预设阈值。
本实施例提供的订单状态查询装置，统计获得有效查单率，并根据有效查单率调整查单预设阈值，利用调整后查单预设阈值进行查单判断，进一步提高了查单的准确度。
又一方面，本申请还提供了一种终端，如参见图10，图10是本申请的终端的一种组成结构示意图，本实施例的终端可以包括：处理器310和存储器320。
可选的，该终端还可以包括通信接口330、输入单元340和显示器350和通信总线360。
处理器310、存储器320、通信接口330、输入单元340、显示器350、均通过通信总线360完成相互间的通信。
在本申请实施例中，该处理器310，可以为中央处理器(Central ProcessingUnit，CPU)，特定应用集成电路，数字信号处理器、现成可编程门阵列或者其他可编程逻辑器件等。
该处理器可以调用存储器320中存储的程序。具体的，处理器可以执行以下消息发送方法的实施例中应用服务器侧所执行的操作。
存储器320中用于存放一个或者一个以上程序，程序可以包括程序代码，程序代码包括计算机操作指令，在本申请实施例中，该存储器中至少存储有用于实现以下功能的程序：
获取待查询订单的订单信息及当前网络环境的网络状态信息，订单信息包括商品信息及购买订单中商品的用户的用户信息；
根据商品信息、用户信息和网络状态信息，获得待查询订单的支付状态不一致概率，支付状态不一致表征用户已支付订单但订单为未支付状态；
在待查询订单的支付状态不一致概率大于等于查单预设阈值的情况下，查询支付系统中待查询订单的支付状态，得到待查询订单的订单状态结果。
在一种可能的实现方式中，根据商品信息、用户信息和网络状态信息，获得待查询订单的支付状态不一致概率，包括：
根据商品信息和用户信息，获得用户支付待查询订单的概率；
根据网络状态信息获得待查询订单的支付过程出现异常的概率；
根据用户支付待查询订单的概率及待查询订单的支付过程出现异常的概率，确定待查询订单的支付状态不一致概率。
在另一种可能的实现方式中，根据商品信息和用户信息，获得用户支付待查询订单的概率，包括：
将商品信息和用户信息输入购买率预测模型，获得用户购买商品的购买概率；
将商品信息输入商品热度预测模型，获得商品被购买的概率；
根据用户购买商品的购买概率及商品被购买的概率，获得用户支付待查询订单的概率。
在又一种可能的实现方式中，将商品信息输入商品热度预测模型，获得商品被购买的概率，包括：
商品是历史商品，获取商品的首次上架时间；
将首次上架时间和当前时间发送至历史商品热度预测模型，获得商品被购买的概率，其中，历史商品热度预测模型由商品的历史数据训练得到。
在另一种可能的实现方式中，将商品信息输入商品热度预测模型，获得商品被购买的概率，包括：
商品为新上架商品，获取商品分别在至少两个不同时间段对应的支付数据；
将支付数据发送至新上商品热度预测模型，获得商品被购买的概率，其中，新上商品热度预测模型包括各个时间段对应的权重系数及平均支付数据。
在又一种可能的实现方式中，方法还包括：
待查询订单的支付状态不一致概率小于查单预设阈值的情况下，不触发查询支付系统中待查询订单的支付状态的步骤。
在再一种可能的实现方式中，方法还包括：
根据订单支付状态不一致的订单数量及订单查询总数，获得有效查单率；
若有效查单率大于预设值，减小查单预设阈值；
若有效查单率小于预设值，增大查单预设阈值。
在另一种可能的实现方式中，确定待查询订单的过程，包括：
将未接收到支付系统返回的支付结果通知的订单，确定为待查询订单。
在一种可能的实现方式中，该存储器320可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、以及至少一个功能(比如图像播放功能等)所需的应用程序等；存储数据区可存储根据计算机的使用过程中所创建的数据，比如，用户数据及图像数据等等。
此外，存储器320可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。
该通信接口330可以为通信模块的接口，如GSM模块的接口。
本申请还可以包括显示器340和输入单元350等等。
当然，图10所示的终端的结构并不构成对本申请实施例中终端的限定，在实际应用中终端可以包括比图10所示的更多或更少的部件，或者组合某些部件。
再一方面，本申请还提供了一种商户服务器，该商户服务器包括存储器和处理器，存储器内存储有程序指令，处理器用于调用存储器内的程序指令以实现如下方法步骤：
获取待查询订单的订单信息及当前网络环境的网络状态信息，订单信息包括商品信息及购买订单中商品的用户的用户信息；
根据商品信息、用户信息和网络状态信息，获得待查询订单的支付状态不一致概率，支付状态不一致表征用户已支付订单但订单为未支付状态；
在待查询订单的支付状态不一致概率大于等于查单预设阈值的情况下，查询支付系统中待查询订单的支付状态，得到待查询订单的订单状态结果。
在一种可能的实现方式中，根据商品信息、用户信息和网络状态信息，获得待查询订单的支付状态不一致概率，包括：
根据商品信息和用户信息，获得用户支付待查询订单的概率；
根据网络状态信息获得待查询订单的支付过程出现异常的概率；
根据用户支付待查询订单的概率及待查询订单的支付过程出现异常的概率，确定待查询订单的支付状态不一致概率。
在另一种可能的实现方式中，根据商品信息和用户信息，获得用户支付待查询订单的概率，包括：
将商品信息和用户信息输入购买率预测模型，获得用户购买商品的购买概率；
将商品信息输入商品热度预测模型，获得商品被购买的概率；
根据用户购买商品的购买概率及商品被购买的概率，获得用户支付待查询订单的概率。
在又一种可能的实现方式中，将商品信息输入商品热度预测模型，获得商品被购买的概率，包括：
商品是历史商品，获取商品的首次上架时间；
将首次上架时间和当前时间发送至历史商品热度预测模型，获得商品被购买的概率，其中，历史商品热度预测模型由商品的历史数据训练得到。
在另一种可能的实现方式中，将商品信息输入商品热度预测模型，获得商品被购买的概率，包括：
商品为新上架商品，获取商品分别在至少两个不同时间段对应的支付数据；
将支付数据发送至新上商品热度预测模型，获得商品被购买的概率，其中，新上商品热度预测模型包括各个时间段对应的权重系数及平均支付数据。
在又一种可能的实现方式中，方法还包括：
待查询订单的支付状态不一致概率小于查单预设阈值的情况下，不触发查询支付系统中待查询订单的支付状态的步骤。
在再一种可能的实现方式中，方法还包括：
根据订单支付状态不一致的订单数量及订单查询总数，获得有效查单率；
若有效查单率大于预设值，减小查单预设阈值；
若有效查单率小于预设值，增大查单预设阈值。
在另一种可能的实现方式中，确定待查询订单的过程，包括：
将未接收到支付系统返回的支付结果通知的订单，确定为待查询订单。
另一方面，本申请实施例还提供了一种存储介质，所述存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现如上任意一个实施例中商户服务器侧所执行的订单状态查询方法。
另一方面，本申请实施例提供了一种计算机程序产品，当其在服务器上执行时，适于执行初始化有上述任意一个实施例中商户服务器侧所执行的订单状态查询方法的程序。
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
以上仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种订单状态查询方法，其特征在于，所述方法包括：
获取待查询订单的订单信息及当前网络环境的网络状态信息，所述订单信息包括商品信息及购买订单中商品的用户的用户信息；
根据所述商品信息、所述用户信息和所述网络状态信息，获得所述待查询订单的支付状态不一致概率，所述支付状态不一致表征用户已支付订单且订单为未支付状态；
在所述待查询订单的支付状态不一致概率大于等于查单预设阈值的情况下，查询支付系统中所述待查询订单的支付状态，得到所述待查询订单的订单状态结果。
2.根据权利要求1所述的方法，其特征在于，所述根据所述商品信息、所述用户信息和所述网络状态信息，获得所述待查询订单的支付状态不一致概率，包括：
根据所述商品信息和所述用户信息，获得所述用户支付所述待查询订单的概率；
根据所述网络状态信息获得所述待查询订单的支付过程出现异常的概率；
根据所述用户支付所述待查询订单的概率及所述待查询订单的支付过程出现异常的概率，确定所述待查询订单的支付状态不一致概率。
3.根据权利要求2所述的方法，其特征在于，所述根据所述商品信息和所述用户信息，获得所述用户支付所述待查询订单的概率，包括：
将所述商品信息和所述用户信息输入购买率预测模型，获得所述用户购买所述商品的购买概率；
将所述商品信息输入商品热度预测模型，获得所述商品被购买的概率；
根据所述用户购买所述商品的购买概率及所述商品被购买的概率，获得所述用户支付所述待查询订单的概率。
4.根据权利要求3所述的方法，其特征在于，所述将所述商品信息输入商品热度预测模型，获得所述商品被购买的概率，包括：
所述商品是历史商品，获取所述商品的首次上架时间；
将所述首次上架时间和当前时间发送至历史商品热度预测模型，获得所述商品被购买的概率，其中，所述历史商品热度预测模型由所述商品的历史数据训练得到。
5.根据权利要求3所述的方法，其特征在于，所述将所述商品信息输入商品热度预测模型，获得所述商品被购买的概率，包括：
所述商品为新上架商品，获取所述商品分别在至少两个不同时间段对应的支付数据；
将所述支付数据发送至新上商品热度预测模型，获得所述商品被购买的概率，其中，所述新上商品热度预测模型包括各个时间段对应的权重系数及平均支付数据。
6.根据权利要求1-5任一项所述的方法，其特征在于，所述方法还包括：
所述待查询订单的支付状态不一致概率小于所述查单预设阈值的情况下，不触发查询所述支付系统中所述待查询订单的支付状态的步骤。
7.根据权利要求1-5任一项所述的方法，其特征在于，所述方法还包括：
根据订单支付状态不一致的订单数量及订单查询总数，获得有效查单率；
若所述有效查单率大于预设值，减小所述查单预设阈值；
若所述有效查单率小于所述预设值，增大所述查单预设阈值。
8.根据权利要求1-5任一项所述的方法，其特征在于，确定待查询订单的过程，包括：
将未接收到支付系统返回的支付结果通知的订单，确定为待查询订单。
9.一种订单状态查询装置，其特征在于，包括：
处理器和存储器；
其中，所述处理器用于执行所述存储器中存储的程序；
所述存储器用于存储程序，所述程序至少用于：
获取待查询订单的订单信息及当前网络环境的网络状态信息，所述订单信息包括商品信息及购买订单中商品的用户的用户信息；
根据所述商品信息、所述用户信息和所述网络状态信息，获得所述待查询订单的支付状态不一致概率，所述支付状态不一致表征用户已支付订单且订单为未支付；
所述待查询订单的支付状态不一致概率大于等于查单预设阈值的情况下，查询支付系统中所述待查询订单的支付状态，得到所述待查询订单的订单状态结果。
10.一种存储介质，其特征在于，所述存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现如上权利要求1至8任一项所述的订单状态查询方法。
CN202110536764.2A 2021-05-17 2021-05-17 订单状态查询方法、装置及存储介质 Pending CN113222701A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110536764.2A CN113222701A (zh) 2021-05-17 2021-05-17 订单状态查询方法、装置及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110536764.2A CN113222701A (zh) 2021-05-17 2021-05-17 订单状态查询方法、装置及存储介质

Publications (1)

Publication Number Publication Date
CN113222701A true CN113222701A (zh) 2021-08-06

Family

ID=77092520

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110536764.2A Pending CN113222701A (zh) 2021-05-17 2021-05-17 订单状态查询方法、装置及存储介质

Country Status (1)

Country Link
CN (1) CN113222701A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114648369A (zh) * 2022-05-20 2022-06-21 华南理工大学 电子商务数据处理方法及系统

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114648369A (zh) * 2022-05-20 2022-06-21 华南理工大学 电子商务数据处理方法及系统

Similar Documents

Publication Publication Date Title
US8626535B2 (en) System and method for providing shipping insurance as a service
US20160253650A1 (en) Methods and systems for providing mobile services between mobile network providers
US20100005004A1 (en) System and method to guarantee a selling price of a product
US20090287592A1 (en) System and method for conferring a benefit to a thrid party from the sale of leads
US20170126903A1 (en) Systems and methods for mobile device data accounting
US20190080350A1 (en) Conducting dynamic media lift studies concurrently with operating online advertising campaigns
US8719127B2 (en) Network commerce system with lead-based feedback
CN110992162A (zh) 一种资源处理方法、装置、设备及系统
WO2015020842A1 (en) Personal merchandise cataloguing system with item tracking and social network functionality
US11893613B2 (en) Systems, manufacture, and methods for controlling access to resources
EP4149046A1 (en) Systems and methods for blockchain network congestion-adaptive digital asset event handling
CN112102036A (zh) 信息推荐方法、装置及存储介质
CN113312527B (zh) 采购数据处理方法、装置、计算机设备和存储介质
US20100299269A1 (en) Method of soliciting an aggregate purchase
US20140370848A1 (en) Systems and methods for exchanging data related to unconsumed cellular time
CN113222701A (zh) 订单状态查询方法、装置及存储介质
CN105469258A (zh) 一种基于图像下单的网购系统和相应方法
US20180305905A1 (en) Personal merchandise cataloguing system with item tracking and social network functionality
WO2020242339A1 (ru) Система и способ поиска с автоматизированным предоставлением контента
CN112990811B (zh) 一种基于区块链的仓单处理方法及仓单处理系统
US20110313875A1 (en) System and method of organizing secured purchasing groups for buyers of similar interests
US8719109B1 (en) Facilitating transactions involving items by notifying selected users of demand for items
TWI784383B (zh) 用於調控線上商品連結活動的系統以及方法
KR101607669B1 (ko) 결제대행 서비스 제공사 선택 시스템, 결제대행 서비스 제공사 선택 방법, 및 컴퓨터 판독 가능한 기록 매체
US11875388B2 (en) Methods and systems for referrer-based payment system selection for internet-based merchants

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40052208

Country of ref document: HK

SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination