支付异常的确定方法及装置与流程

文档序号:16039897发布日期:2018-11-24 10:23阅读:546来源:国知局

本说明书涉及支付领域,尤其涉及一种支付异常的确定方法及装置。

背景技术

随着信息技术的快速发展,在线支付交易已经得到了越来越广泛的应用,越来越多的用户通过在线付款或者线上转账。而随着在线支付交易的广泛应用,在线支付的支付平台越来越多,并且在线支付的形式也越来越多样化,如线上交易、线下扫码交易等。

当用户在通过线下扫码进行支付时,一般需要使用收款端设备扫描付款方终端设备所展示的识别码、或者付款方终端设备扫描收款端二维码等多种实现方式。但是,针对收款端设备扫描付款方终端设备的识别码这种情况,在进行扫码时,可能会出现扫码后无反应,导致无法正常进行支付。在这种情况下,对于支付平台而言,无法感知到支付异常信息,从而无法对支付异常的原因进行分析。

因此,有必要提出一种支付异常的确定方法,以便于在出现支付异常时,支付平台可以获知该次支付异常。



技术实现要素:

本说明书实施例的目的是提供一种支付异常的确定方法及装置,当支付页面的打开时长达到设定的支付时长阈值时,若未检测到支付成功,通过询问支付端当前的支付状态,并在未得到支付端当前处于正常支付状态的指示时,从支付端获取当前的支付相关信息,并根据该支付相关信息确定出收款端,并询问收款端当前的支付状态,从而验证对当前支付是否出现异常,通过询问支付端并向收款端进行确认的方法,可以获知支付是否出现异常,便于支付平台及时对支付异常原因进行分析。

为解决上述技术问题,本说明书实施例是这样实现的:

本说明书实施例提供了一种支付异常的确定方法,包括:

若确定出支付端的支付页面的打开时长达到设定的支付时长阈值且支付端未支付成功,则询问所述支付端当前的支付状态;

若未得到处于正常支付状态的指示信息,则获取所述支付端的支付相关信息;其中,所述支付相关信息至少包括支付端当前所处的地理位置信息;

在根据所述支付相关信息确定出收款端后,询问所述收款端当前的支付状态,以验证当前支付是否出现异常。

本说明书实施例还提供了一种支付异常的确定装置,包括:

第一询问模块,若确定出支付端的支付页面的打开时长达到设定的支付时长阈值且支付端未支付成功,则询问所述支付端当前的支付状态;

获取模块,若未得到处于正常支付状态的指示信息,则获取所述支付端的支付相关信息;其中,所述支付相关信息至少包括支付端当前所处的地理位置信息;

第二询问模块,在根据所述支付相关信息确定出收款端后,询问所述收款端当前的支付状态,以验证当前支付是否出现异常。

本说明书实施例还提供了一种支付异常的确定设备,包括:

处理器;以及

被安排成存储计算机可执行指令的存储器,所述可执行指令在被执行时使所述处理器:

若确定出支付端的支付页面的打开时长达到设定的支付时长阈值且支付端未支付成功,则询问所述支付端当前的支付状态;

若未得到处于正常支付状态的指示信息,则获取所述支付端的支付相关信息;其中,所述支付相关信息至少包括支付端当前所处的地理位置信息;

在根据所述支付相关信息确定出收款端后,询问所述收款端当前的支付状态,以验证当前支付是否出现异常。

本说明书实施例还提供了一种存储介质,用于存储计算机可执行指令,所述可执行指令在被执行时实现以下流程:

若确定出支付端的支付页面的打开时长达到设定的支付时长阈值且支付端未支付成功,则询问所述支付端当前的支付状态;

若未得到处于正常支付状态的指示信息,则获取所述支付端的支付相关信息;其中,所述支付相关信息至少包括支付端当前所处的地理位置信息;

在根据所述支付相关信息确定出收款端后,询问所述收款端当前的支付状态,以验证当前支付是否出现异常。

通过本实施例中的技术方案,当支付页面的打开时长达到设定的支付时长阈值时,若未检测到支付成功,通过询问支付端当前的支付状态,并在未得到支付端当前处于正常支付状态的指示时,从支付端获取当前的支付相关信息,并根据该支付相关信息确定出收款端,并询问收款端当前的支付状态,从而验证对当前支付是否出现异常,通过询问支付端并向收款端进行确认的方法,可以获知支付是否出现异常,便于支付平台及时对支付异常原因进行分析。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。

图1为本说明书实施例提供的支付异常的确定方法的应用场景示意图之一;

图2为本说明书实施例提供的支付异常的确定方法的方法流程图之一;

图3为本说明书实施例提供的支付异常的确定方法中,在支付端显示询问信息的界面示意图;

图4为本说明书实施例提供的支付异常的确定方法中,在支付端显示店铺信息列表的界面示意图;

图5为本说明书实施例提供的支付异常的确定方法中,根据支付相关信息确定收款端的方法流程图;

图6为本说明书实施例提供的支付异常的确定方法中,确定支付时长阈值的方法流程图;

图7为本说明书实施例提供的支付异常的确定方法的方法流程图之二;

图8为本说明书实施例提供的支付异常的确定方法的应用场景示意图之二;

图9为本说明书实施例提供的支付异常的确定装置的模块组成示意图;

图10为本说明书实施例提供的支付异常的确定设备的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案,下面将结合本说明书实施例中的附图,对本说明书实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。

本说明书实施例的思想在于,若支付页面的打开时长达到设定的支付时长阈值且所述支付端未支付成功时,首先向支付端询问当前的支付状态,并从支付端未得到处于正常支付状态的指示信息后,再向收款端进行确认,以验证当前支付是否出现异常。基于此思想,本说明书实施例提供了一种支付异常的确定方法、装置、设备及存储介质。下述将一一进行详细介绍。

本说明书实施例提供的支付异常的确定方法的一种具体应用场景可以为通过设置于商家店铺内的收款端扫描用户通过支付端展示的付款码进行收款时,确定该应用场景下是否出现支付异常。

在本说明书实施例中,所提及到的支付端为用户在支付时所使用的客户端,可以为安装有支付客户端的手机、平板电脑等设备;收款端则为收款店铺所使用的客户端。

在一种具体实施方式中,上述收款端可以配备有扫码枪或者二维码读取器等。

图1为本说明书实施例提供的方法的一种具体应用场景示意图,在图1所示场景中,包括支付端110、收款端120以及支付系统130,该支付系统130与支付端110以及收款端120进行通信,以向支付端110以及收款端120询问当前的支付状态。

本说明书实施例所提供的支付异常的确定方法可以应用于支付系统130。其中,本说明书实施例所提及的支付系统也可称为支付平台。

图2为本说明书实施例提供的支付异常的确定方法的第一种方法流程图,图2所示的方法,至少包括如下步骤:

步骤202,当确定出支付端的支付页面的打开时长达到设定的支付时长阈值且该支付端未支付成功时,询问支付端当前的支付状态。

其中,上述支付页面为展示有付款码的页面,该付款码可以为二维码、条形码等。

在本说明书实施例中,确定支付端的支付页面的打开时长是否达到设定的支付时长阈值且支付端是否支付成功,至少可以通过如下两种方式实现。

方式一、由支付端检测其是否在支付页面的打开时长达到设定的支付时长阈值前支付成功,若是支付端检测到其支付页面的打开时长在达到设定的支付时长阈值时,还未支付成功,则触发支付系统询问该支付端当前的支付状态,具体的,可以是触发支付系统上的移动端服务器询问支付端当前的支付状态。

具体的,支付端可以通过如下过程检测其是否在支付页面的打开时长达到设定的支付阈值前支付成功:

在支付端上预先存储有上述支付时长阈值,当支付端检测到用户打开支付页面后,开始倒计时,其中,倒计时的时长为上述支付时长阈值,并在倒计时的过程中检测是否出现支付成功,若是在倒到计时结束前,检测到支付端支付成功,则结束整个流程;若是在倒计时结束时,还未检测到支付端支付成功,则触发支付系统询问支付端当前的支付状态。

或者,在另外一种具体实施方式中,在支付平台上预先存储有上述支付时长阈值,当支付端检测到用户打开支付页面后,开始计时,所计时的时间长度则为支付页面的打开时长。然后,在计时的过程中检测支付端是否支付成功,若是在计时的时长达到上述支付时长阈值之前,检测到支付成功,则结束整个流程;若是在计时的时长达到上述支付时长阈值时,还未检测到支付成功,则触发支付系统询问支付端当前的支付状态。

方式二、由支付系统检测支付端是否在支付页面的打开时长达到设定的支付时长阈值支付成功,若是支付系统检测到支付端在支付页面的打开时长达到设定的支付时长阈值时还未支付成功,则询问支付端当前的支付状态。

具体的,支付系统可以通过如下过程检测支付端是否在支付页面的打开时长达到设定的支付阈值前支付成功:

当支付端检测到用户打开支付页面后,向支付系统发送计时请求,其中该计时请求中携带有支付页面的开启时刻,当支付系统在接收到支付端发送的支付请求后,从支付页面的开启时刻开始计时,并在计时的过程中不断检测支付端是否支付成功,若是在计时的时间长度达到上述支付时长阈值前,检测到支付端支付成功,则结束流程;若是在计时的时间长度达到上述支付时长阈值时,还未支付成功,则询问支付端当前的支付状态。

当然,上述只是列举了几种可能的确定方式,确定支付端在支付页面的支付时长达到设定的支付阈值时是否支付成功的具体实现方式并不局限于此。

在上述步骤202中,询问支付端当前的支付状态可以通过向支付端发送询问消息的方式实现。

在具体实施时,支付系统向支付端发送的询问信息的具体内容可以为“是否支付异常”,当支付端接收到该询问信息后,在当前所显示的支付页面上以消息框的形式展示该询问信息。支付端在当前所显示的支付页面上显示上述询问信息的一种界面示意图如图3所示,用户可以通过点击图3所示界面上的“是”或者“否”按钮向支付系统回复当前的支付状态。支付系统根据支付端返回的信息确定支付端当前的支付状态。

但是,在某些情况下,用户可能并不会回复,这时用户可能会点击消息框右上角的“关闭”按钮关闭该消息框,或者用户直接在支付端执行返回操作,还或者,执行关闭支付端的操作等。在上述这些情况下,支付系统无法从支付端获取到当前的支付状态。

步骤204,若未得到处于正常支付状态的指示信息,则获取上述支付端的支付相关信息;其中,该支付相关信息至少包括支付端当前所处的地理位置信息。

在具体实施时,上述步骤202中询问用户当前的支付状态,可以是向支付端发送询问消息;其中,该询问消息用于询问支付端当前是否处于异常支付状态。

因此,在本说明书实施例中,上述步骤204中,未得到支付端当前处于正常支付状态的指示,可以包括如下两种情况:接收到支付端指示当前处于支付异常状态的信息;或者,在设定时间长度内未接收到支付端的指示信息。

在具体实施时,若是支付系统接收到反馈的支付异常或者支付正常的指示信息时,则可以从支付端确定当前的支付状态。若是,支付端用户反馈当前支付状态正常,则可以结束整个流程。

在本说明书实施例中,若是支付系统接收到支付端指示当前处于支付异常状态的信息;

则在执行上述步骤204中,获取支付端当前的支付相关信息之前,本说明书实施例提供的方法还包括:

将支付端当前所处的地理位置周围设定范围内的店铺信息发送给支付端,以使支付端用户选择当前进行支付的收款端。

在具体实施时,若是支付端接收到用户输入的指示信息为指示当前支付状态异常,向支付系统发送获取店铺信息列表的请求,当支付系统接收到支付端发送的请求后,支付系统以支付端当前所处的地理位置处为中心,搜索与该地理位置之间的距离小于或等于设定距离的范围内的店铺信息。其中,该店铺信息可以包括店铺名称、店铺与支付端之间的距离、店铺的地理位置信息等。

在搜索到上述店铺信息后,按照与支付端之间的距离从小到大的顺序对上述店铺进行排序,得到上述店铺信息列表,并将该上述店铺信息列表发送给支付端。

当支付端接收到支付系统返回的店铺信息列表后,按照该店铺信息列表中各个店铺的排序显示上述店铺信息。其中,支付端显示上述店铺信息列表的一种界面示意图如图4所示,在图4所示情况中,用户可以点击任意一个店铺左边的按钮,以选择相应的店铺,该店铺则为收款方,并点击“确定”按钮,将所选择的店铺信息发送给支付系统。

若是用户从上述店铺信息列表中执行了选取店铺的操作信息,则在该种情况下,支付端将用户选择的店铺信息作为支付端。因此,上述步骤204中,获取支付端当前的支付相关信息,包括:

获取支付端用户所选取的店铺信息和支付端当前所处的地理位置信息。

支付端在接收到用户的选取操作后,将用户选取的店铺信息和用户当前所处的地理位置位置信息作为支付相关信息发送给支付系统。因此,支付系统可以获取到支付端当前的地理位置信息以及交易的店铺信息。

在一种具体实施方式中,在该种情况下,获取的一种具体支付相关信息,可以包括:支付端用户的唯一标识、收款端店铺标识、收款端店铺所属的区域标识、支付端所处的经纬信息、支付端所处的纬度信息、收款端店铺名称、其它与收款端店铺相关的信息以及该支付相关信息的创建时间等。

在另外一种实施例中,若是上述步骤204中未得到支付端当前处于正常支付状态的指示信息,属于在设定时间长度内未接收到收款端的指示信息这种情况。则在该种情况下,上述的支付端当前的支付相关信息,可以包括:支付端的地理位置信息,该地理位置信息可以为支付端所处的经度信息和纬度信息。

在一种具体实施方式中,若是支付端在设定时间长度内未接收到用户输入的指示信息,则可以认为未得到支付端当前处于正常支付状态的指示信息,在该种情况下,支付端则将其当前所处的地理位置信息作为支付相关信息发送给支付系统。

在该种情况下,在具体实施时,支付端的支付相关信息可以包括支付端用户的唯一标识、支付端所处的经度信息、支付端所处的维度信息、该交易信息的唯一标识以及该制度相关信息的创建时间等信息。

在具体实施时,可以通过运营商的无线电通讯网络,如全球移动通信系统网(globalsystemformobilecommunication,gsm)或码分多址网(codedivisionmultipleaccess,cdma)等获取支付端当前的地理位置信息,或者还可以通过全球定位系统(globalpositioningsystem,gps)定位的方式获取支付端当前的地理位置信息。

具体的,在本说明书实施例中,支付系统从支付端获取支付相关信息,具体的,可以是在支付端未得到用户的输入的处于正常支付状态的指示信息时,将该支付相关信息主动发送给支付系统;也可以是在支付端未得到处于正常支付状态的指示信息时,将当前未得到处于正常支付状态的指示信息这一情况告知支付系统,由支付系统主动从支付端获取支付相关信息。

步骤206,在根据上述支付相关信息确定出收款端后,询问该收款端当前的支付状态,以验证当前支付是否出现异常。

其中,上述收款端一般指的是收款端店铺。

具体的,在上述步骤206中,根据支付相关信息确定支付的收款端的步骤包括:

判断支付相关信息中是否存在店铺标识信息;若是,则将该店铺标识信息所对应的店铺确定为收款端;否则,将位于支付端当前所处的地理位置信息处的店铺确定为收款端。

需要说明的是,若是位于支付端当前所处的地理位置信息处存在店铺,则将该店铺确定为收款端,若是位于支付端当前所处的地理位置信息处不存在店铺,则不再继续后续流程,直接在支付异常信息列表中存储由支付端确认的支付异常信息。

图5示出了本说明书实施例中根据支付相关信息确定收款端的流程示意图,图5所示的流程图,至少包括如下步骤:

步骤302,检测支付相关信息中是否存在店铺标识;若存在,则执行步骤304;否则,执行步骤306;

步骤304,将该店铺标识所对应的店铺确定为收款端。

步骤306,检测上述支付相关信息中是否存在支付端的经纬度信息;若是,则执行步骤308;否则,执行步骤312。

步骤308,判断上述经纬度信息所对应的位置处是否存在店铺;若是,则执行步骤310;否则,执行步骤312。

步骤310,将该经纬度信息所对应位置处的店铺确定为收款端。

步骤312,存储第二支付异常信息;

其中,上述第二支付异常信息为由支付端确认的支付异常信息,具体的,可以是将该第二支付异常信息存储的数据库的支付异常信息表中。

另外,上述步骤206中,询问收款端当前的支付状态,可以是向收款端发送询问信息,所发送询问信息的具体形式可参考向支付端发送的询问信息,此处不再详述。

在具体实施时,由于频繁的向收款端发送询问信息,可能会使得收款端店铺体验较差,因此,在本说明书实施例中,在询问收款端当前的支付状态之前,本说明书实施例提供的方法,还包括:

确定当前时刻距离前一次向收款端发送询问信息的时间间隔;并判断该时间间隔是否大于预设时间间隔。

在本说明书实施例中,可以预先设置一个时间间隔,例如,可以为半小时、一个小时等,两次向收款端店铺发送询问信息的时间间隔需要大于或等于上述预设设置的时间间隔。

即在当前时刻距离前一次向收款端发送询问信息的时间间隔大于或等于预设的时间间隔时,则向收款端发送询问信息;若是当前时刻距离前一次向收款端发送询问信息的时间间隔小于上述预设的时间间隔,则存储第二支付异常信息,并结束整个流程,即不向收款端发送询问信息。

在另外一种具体实施方式中,可以建立数据存储库,在该数据存储库中存储有店铺信息列表,在店铺信息列表中存储的则是距离上次发送询问信息未达到设定时间间隔的店铺信息。具体的,该店铺信息可以是店铺的标识信息。

因此,在向收款端发送询问信息之前,可以查找该数据库存储库中是否存储有该收款端店铺,若是存在,则不向该收款端店铺发送询问信息,直接将支付端确认的第二支付异常信息存储在支付异常信息表中即可;若是在上述数据存储库中不存在该收款端店铺,则向该收款端店铺发送询问信息。

其中,上述所提及到的数据存储库可以是tair存储系统。

需要说明的是,在具体实施时,支付系统可以通过设置于该支付系统上的商户端服务器向收款端发送询问信息,并通过商户端服务器从收款端接收确认信息。

在本说明书实施例中,若是支付系统接收到收款端店铺返回的确认当前处于支付异常状态,则确定当前支付异常,此时,将该支付异常信息存储到支付异常信息表中,具体的,可以将该支付异常信息记为第一支付异常信息;或者,若是在设定时间长度内未接收到收款端店铺返回的信息,在而将该支付异常信息记为第二支付异常信息;还或者,所示收款端店铺返回的信息为确认当前未出现支付异常,则将该支付异常信息记为第二支付异常信息。

在具体实施时,上述第一支付异常信息可以包括店铺信息、支付端用户信息以及交易状态信息。由于第一支付异常信息为由支付端和收款端共同确认为异常的支付,因此,第一支付异常信息中确认类型(confirm_type)可以表示为confirm_type=b|c,其中,b表示支付端用户,c表示收款端店铺。

在一种具体实施方式中,存储在支付异常信息表中的第一支付异常信息具体可以包括交易异常信息的唯一标识(uuid)、店铺唯一标识(shop_id)、用户唯一标识(uid)、该异常支付信息在支付端的创建时间、交易号、确认类型等信息,一种具体形式如下所示:

uuid|shop_id|uid|biz_create|交易号|confirm_type…

其中,uuid为交易异常信息的唯一标识,由支付端生成;shop_id:为店铺唯一标识;uid:表示用户唯一标识;biz_create:该异常支付信息在支付端的创建时间。

另外,上述交易号指的是交易的唯一流水号,若是不存在,上述交易号所对应位置处可以为空。

在具体实施例中,上述第二异常支付信息的具体形式可以与第一支付异常信息相同,只不过,第二支付异常信息中confirm_type=b,表征该支付异常信息为支付端确认的支付异常信息。

在本说明书实施例中,上述设定的支付时长阈值可以是人为设定的,也可以是根据历史支付数据计算出来的。

若是上述支付时长阈值是根据历史支付数据计算出的,则在采用本说明书实施例提供的方法确定当前是否支付异常之前,本说明书实施例提供的方法还包括如下步骤一、步骤二和步骤三:

步骤一、获取设定时间段内的历史支付数据集合;其中,该历史支付数据集合包括每次支付的支付时间信息;该支付时间信息为从支付页面开启到支付成功所对应的时间长度;

步骤二、根据历史支付数据集合中每次支付的支付时间信息,计算上述支付时长阈值;

步骤三、向支付端发送上述支付时长阈值。

需要说明的时,在历史支付数据集合中包括设定时间段内每次支付的支付数据,每个支付数据包括该次支付的支付时间信息以及该次支付的地理位置信息。

其中,在步骤一中,上述获取设定时间段内的历史支付数据集合,可以是获取当前日期前一天或者前几天的支付数据,作为历史支付数据集合。由于在不同的时间段内,可能会受到网络状况等因素的影响,导致支付时所耗费的时间长度存在差别,因此,为了提高得到的支付时长阈值的准确性,可以每间隔一段时间重新计算一次支付时长阈值,并更新支付端的支付时长阈值。

具体的,在步骤三中,向支付端发送上述支付时长阈值,可以是在每天的设定时刻向支付端发送最新计算出的支付时长阈值,以使支付端根据该最新的支付时长阈值进行检测。

在某些具体实施方式中,若是支付端在某天未接收到支付时长阈值,则在执行本说明书实施例提供的方法时,可以采用上一次接收到的支付时长阈值。

当然,上述支付时长阈值可每天定时向支付端发送,也可以是两天发送一次或者三天发送一次,本说明书实施例并不对向支付端发送支付时长阈值的时间间隔进行限定。

在某些情况下,由于不同的区域网络状态可能会存在差别,因此,在不同的地理区域支付所耗费的时间长度可能会存在较大的差别,为了提高所计算的支付时长阈值的准确性,在本说明书实施例中,可以计算不同地理区域所对应的支付时长阈值,根据支付端当前所处的地理位置信息向支付端发送与该地理位置信息相匹配的支付时长阈值。

因此,上述支付历史数据集合中包括每次支付时支付端所处的地理位置信息;

相应的,上述步骤二中,根据历史支付数据集合中每次支付的支付时间信息,计算支付时长阈值,包括:

根据每次支付的地理位置信息,将上述历史支付数据集合划分为多个历史支付数据子集合;其中,每个历史支付数据子集合中所有支付数据所对应的地理位置属于同一个地理区域;根据每个历史支付数据子集合中每次支付的支付时间信息,计算该历史支付数据子集合所对应地理区域的支付时长阈值。

例如,上述历史支付数据集合可以为某个城市所对应的支付数据,则相应的,历史支付数据子集合可以对应该城市的各个区,即将该城市的一个区作为一个地理区域;或者,上述历史支付数据集合可以为某个省所对应的支付数据,则相应的,历史支付数据子集合可以对应该省的各个市,即将该省的一个市作为一个地理区域。其中,上述地理区域的具体范围可以根据实际应用场景进行设置,本说明书实施例并不对此进行限定。

通过上述过程,则可以确定出各个地理位置区域所对应的支付时长阈值,向支付端发送支付时长阈值,包括:

向支付端发送与支付端当前所处地理位置信息相对应的支付时长阈值。

具体的,在向支付端发送支付时长阈值之前,可以获取支付端当前所处的地理位置信息,确定该地理位置信息所属的地理区域,并将该地理区域所对应的支付时长阈值发送给支付端。

在某些情况下,若是无法获取支付端当前所处的地理位置信息,则可以将该支付端经常所处的地理区域所对应的支时长阈值发送给支付端。

在具体实施时,支付端用户可能会发生移动,即支付端的地理位置会发生变化,因此,为了保证支付端所使用的支付时长阈值的准确性,当检测到支付端所处的地理位置信息发生变化时,确定支付端当前所处地理位置所属的地理区域,将该地理区域所对应的支付时长阈值发送给支付端。

具体的,上述根据每个历史支付数据子集合中每次支付的支付时间信息,计算该历史支付数据子集合所对应地理区域的支付时长阈值,包括如下步骤(a1)和步骤(a2);

步骤(a1)、针对每个历史支付数据子集合,根据该历史支付数据子集合中每次支付的支付时间信息,计算该历史支付数据子集合所对应的支付时间平均值和支付时间标准差;

步骤(a2)、根据该历史支付数据子集合所对应的支付时间平均值和支付时间标准差,确定该历史支付数据子集合所对应地理区域的支付时长阈值。

其中,在上述步骤(a1)中,可以通过如下公式1计算每个历史支付数据子集合所对应的支付时间平均值:

其中,在公式1中,μi表示第i个历史数据子集合所对应的支付时间平均值,xi表示第i个历史数据子集合所对应的总支付时间,即第i个历史支付数据子集合中所有支付数据中支付时间的总和,pi表示的是第i个历史数据子集合中支付数据的个数。

通过如下公式2计算每个历史支付数据子集合所对应的支付时间标准差:

其中,在上述公式2中,σi表示第i个历史数据子集合所对应的支付时间标准差,pi表示第i个历史数据子集合中支付数据的个数,xij表示第i个历史数据子集合中的第j个支付数据中的支付时间,μi表示第i个历史数据子集合所对应的支付时间平均值。

在上述步骤(a2)中,根据历史支付数据子集合所对应的支付时间平均值和支付时间标准差,确定该历史支付数据子集合所对应地理区域的支付时长阈值,包括:

根据历史支付数据子集合所对应的支付时间平均值和支付时间标准差,通过公式3计算该历史支付数据子集合所对应地理区域的支付时长阈值;

si=μi+ni*σi公式3

其中,在上述公式3中,si表示第i个历史支付数据子集合所对应地理区域的支付时长阈值,μi表示第i个历史支付数据子集合所对应的支付时间平均值,σi表示第i个历史支付数据子集合所对应的支付时间标准差,ni表示第i个历史支付数据子集合所对应的系数。

在具体实施时,若是在每个历史支付数据子集合中所含支付数据的个数较多的情况下,数据量较大,从而导致支付时长阈值的计算量较大。因此,为了减少计算支付时长阈值时的计算量,在本说明书实施例中,可以从每个历史支付数据子集合中抽取设定数量个支付数据,作为该历史支付数据子集合的历史支付样本数据集合,并使用该历史支付样本数据集合计算该地理区域的支付时长阈值。因此,在本说明书实施例中,根据每个历史支付数据子集合中每次支付的支付时间信息,计算该历史支付数据子集合所对应区域的支付时长阈值,包括如下步骤(b1)和步骤(b2);

步骤(b1)、从每个历史支付数据子集合中进行抽样,得到该历史支付数据子集合所对应的历史支付样本数据集合;

步骤(b2)、根据历史支付样本数据集合中每次支付的支付时间信息,计算该历史支付数据子集合所对应地理区域的支付时长阈值。

其中,在上述步骤(b1)中,可以随机从历史支付数据子集合中选取设定数量个支付数据,作为该历史支付数据子集合所对应的历史支付样本数据集合。

或者,还可以按照某种设定规则,从历史支付数据子集合中进行抽样。例如,可以将历史支付数据所对应的时间段划分为多个时间子区间,然后从每个时间子区间内选取相同数量个支付数据作为历史样本支付数据。

在具体实施时,为了满足尽量所抽取的历史支付样本数据集合包括各个时间子区间内的支付数据。在抽取样本之前,可以根据历史支付数据子集合中各个支付数据所对应的支付时刻,将该历史支付数据子集合中的所有支付数据按照支付时刻从前到后或者从后到前的顺序进行排序。在排序后,可以每间隔几个支付数据抽取一个支付数据,得到该历史支付数据子集合所对应的历史支付样本数据集合。

在本说明书实施例中,根据历史支付样本数据集合中每次支付的支付时间信息计算支付时长阈值的具体过程,与根据历史支付数据子集合中每次支付的支付时间信息计算支付时长阈值的具体过程相同,因此,可参考上述根据历史支付数据子集合中每次支付的支付时间信息计算支付时长阈值的具体过程,此处不再赘述。

具体的,若是根据历史支付数据子集合中每次支付的支付时间信息计算支付时长阈值,则上述系数ni则根据第i个历史支付数据子集合确定;若是根据历史样本支付数据集合中每次支付的支付时间信息计算支付时长阈值,则上述系数ni则根据第i个历史支付样本数据集合确定。

下述将以根据历史样本支付数据集合确定上述系数ni为例,介绍本说明书实施例中上述ni的确定过程。

由于在每个历史支付样本数据集合中包括多个支付数据,每个支付数据包括该次支付所对应的时间信息,其中,该时间信息可以为支付时所花费的支付时间。按照支付时间从小到大的顺序将第i个历史样本支付数据集合中所有的支付数据进行排序,从排序后的历史支付样本数据集合中,选取前w%个历史支付数据,例如,w的取值为95时,则表示从历史支付样本数据集合中选取前95%个支付数据。

在选取了前w%个历史支付数据后,从所选取的前w%个历史支付数据中确定最大的支付时间,将该支付时间记为ti,令

μi+ni*σi≥ti公式4

通过上述公式4可以计算出ni的取值范围,并从ni的取值范围中选取一个最小的整数,作为ni的取值。

其中,上述w的取值可以95,也可以为其它数值,w的具体取值可以根据实际应用场景进行限定,本说明书实施例并不对上述w的具体取值进行限定。

为便于理解本说明书实施例中,支付时长阈值的计算过程,下述将通过具体实施例介绍。图6示出了本说明书实施例中,设定支付时长阈值的具体方法流程图,图6所示的方法,至少包括如下步骤:

步骤402,获取当前支付前一天的历史支付数据集合;其中,该历史支付数据集合中包括每次支付的支付时间信息、支付的地理位置信息以及支付的时刻。

步骤404,根据每次支付所对应的地理位置信息,将该历史支付数据划分为多个历史支付数据子集合。

其中,每个历史支付数据子集合中所有支付数据所对应的地理位置属于同一个地理区域。

步骤406,根据每个历史支付数据子集合中每次支付的时刻分别将每个历史支付数据子集合中的支付数据按照支付时刻从前到后的顺序进行排序。

步骤408,按照设定规则从排序后的历史支付数据子集合中进行抽样,得到每个历史支付数据子集合所对应的历史支付样本数据集合。

步骤410,针对每个历史支付样本数据集合,根据该历史支付样本数据集合中每次支付的支付时间信息,计算该历史支付样本数据集合所对应的支付时间平均值和支付时间标准差。

步骤412,根据该历史支付样本数据集合所对应的支付时间平均值和支付时间标准差,计算该地理区域所对应的支付时长阈值。

其中,图6所对应流程图中各个步骤的具体实现过程可参考上述实施例,此处不再赘述。

图7为本说明书实施例提供的支付异常的确定方法的第二种方法流程图,图7所示的方法,至少包括如下步骤:

步骤502,支付端接收到支付页面打开操作后,开始倒计时。

步骤504,支付端检测是否支付成功;若是,则流程结束;否则,执行步骤506。

步骤506,支付端判断倒计时的时长是否达到设定的支付时长阈值;若是,则执行步骤508;否则,继续执行步骤504。

步骤508,向支付系统发送提示信息。

其中,上述提示信息用于提示支付系统,当前支付页面的打开时长已经达到设定的支付时长阈值,但是支付端仍未支付成功,以触发支付系统向支付端发送支付状态询问信息。

步骤510,支付系统向支付端发送询问信息。

其中,该询问信息用于询问支付端当前的支付状态,在具体实施时,该询问信息可以为“是否交易异常”等信息。

步骤512,支付端在当前页面上以消息提示框的形式显示上述询问信息。

在具体实施时,支付端可以直接在当前的支付页面上以消息提示框(toast)的形式显示上述询问信息。并在该toast上还设置有“是”、“否”等按钮,便于用户对该询问信息进行回馈。

步骤514,支付端检测是否接收到用户的回馈信息;若是,则执行步骤516;否则执行步骤526。

步骤516,支付端判断用户的回馈信息是否指示当前支付状态异常;若是,则执行步骤518,否则结束。

步骤518,支付端检测是否从支付系统获取店铺信息列表;若是,则执行步骤520;否则,结束。

其中,上述店铺信息列表中存储有支付端当前所处地理位置信息周围设定范围内的店铺信息。

步骤520,支付端在当前界面上显示上述店铺信息列表。

具体的,在当前界面上显示店铺信息列表的目的是让支付端用户从上述店铺信息列表中选择当前正在交易的收款端。

步骤522,支付端检测是否接收到用户的选取操作;若是,则执行步骤524;否则,执行步骤526。

步骤524,支付端获取用户所选择的店铺信息,以及获取当前所处的地理位置信息,将该信息作为支付相关信息发送给支付系统。

步骤526,支付端获取当前所处的地理位置信息,将该信息作为支付相关信息发送给支付系统。

步骤528,支付系统接收支付端发送的支付相关信息。

步骤530,支付系统检测上述支付相关信息中是否存在店铺标识信息;若是,则执行步骤532;否则,执行步骤534。

步骤532,支付系统将该店铺标识信息所对应的店铺确定为收款端。

步骤534,支付系统判断上述支付相关信息中是否存在地理位置信息,若是,则执行步骤536,否则,执行步骤548。

步骤536,支付系统判断该地理位置信息处是否存在店铺;若是,则执行步骤538,否则,执行步骤548。

步骤538,支付系统将该地理位置处所对应的店铺确定为收款端。

步骤540,支付系统判断当前时刻距离前一次向该收款端发送询问信息的时间间隔是否大于设定时间间隔;若是,则执行步骤542;否则,执行步骤548。

步骤542,支付系统向上述收款端发送询问信息。

步骤544,支付系统接收收款端返回的信息,若是该信息指示当前支付异常,则确定当前支付异常。

步骤546,支付系统将当前支付的第一支付异常信息存储在异常支付信息数据库中,其中,第一支付异常信息为支付端和收款端均确定为异常的异常支付信息。

步骤548,支付系统将当前支付的第二支付异常信息存储在异常支付信息数据库中,其中,第二支付异常信息为支付端确定为异常的异常支付信息。

其中,图7所对应实施中各个步骤的具体实现过程与图1至图6所对应实施例中各个步骤的具体实现过程相同,可参考图1至图6所对应实施例中各个步骤的具体实现过程,此处不再赘述。

图8为本说明书实施例提供的支付异常的确定方法的应用场景示意图之二,图8所示的应用场景示意图,包括:支付端110、收款端120、支付系统130以及数据库140;

具体的,在支付系统上设置有移动端服务器131、商户端服务器132、数据仓库133、支付异常咨询决策子系统134以及tair存储子系统135。支付系统通过移动端服务器131与支付端之间进行通信,如,通过移动端服务器向支付端发送支付时长阈值、通过移动端服务器接收支付端发送的支付相关信息等。支付系统通过商户端服务器132与收款端120之间进行通信,如,通过上述端服务器向收款端发送支付异常询问信息、通过移动端服务器接收收款端发送的支付异常确认信息等。

另外,上述支付异常咨询决策子系统134,则用于通过移动端服务器131向支付端发送支付时长阈值、从移动端服务器获取支付端发送的支付相关信息、确定与支付端进行交易的收款端商家、通过商户端服务器向收款端发送询问信息、从商户端服务器接收收款端发送的支付异常确认信息以及向异常支付信息表中存储支付异常信息等。

另外,在数据库140中存储有支付数据信息表、店铺信息数据表以及异常支付信息表。在具体实施时,可以将支付数据信息表、店铺信息数据表以及异常支付信息表分别存储在数据库140中的一个子数据库中。

在本说明书实施例中,数据仓库133从数据库140所存储的支付数据信息表中读取历史支付数据集合,并根据该历史支付数据集合计算支付时长阈值,然后将计算的支付时长阈值发送给支付异常咨询决策子系统134,由支付异常咨询决策子系统134将该支付时长阈值通过移动端服务器131发送给支付端110。

另外,在支付页面的打开时长达到上述支付时长阈值时,还未支付成功,则由支付异常咨询决策子系统134通过移动端服务器131向支付端110发送询问信息,以询问支付端110当前的支付状态。

若是支付端未接收到支付状态正常的指示信息,则将支付相关信息发送给移动端服务器131,由移动端服务器131将该支付相关信息发送给支付异常咨询决策子系统134。

支付异常咨询决策子系统134根据该支付相关信息确定当前交易的收款端,并检查tair存储子系统135是否存储有该店铺信息,若存在,说明当前时刻距离上一次向该店铺发送询问信息的时间间隔未达到设定时间间隔,这时则不向该店铺发送询问信息,并将第二支付异常信息存储在数据库140中的异常支付信息表。其中,第二支付异常信息包括支付端异常信息。

若是在tair存储子系统135中未查找到该店铺信息,则说明当前时刻距离上一次向该店铺发送询问信息的时间间隔已经达到设定时间间隔,则支付异常咨询决策子系统134通过商户端服务器132向该店铺发送询问信息。

若是支付异常咨询决策子系统134通过商户端服务器132接收到店铺返回的异常确认信息,则确定当前支付出现异常,并将第一支付异常信息存储在数据库140中的异常信息表中。其中,第一异常支付信息包括支付端异常信息和收款端异常信息。

另外,在本说明书实施例中,支付异常咨询决策子系统134从数据库140中的店铺信息表中获取位于支付端当前所处地理位置设定范围内的店铺信息,并在接收到支付端返回的支付异常的指示信息时,通过移动服务器131将该店铺信息返回给支付端110。

本说明书实施例提供的支付异常的确定方法,当支付页面的打开时长达到设定的支付时长阈值时,若未检测到支付成功,通过询问支付端当前的支付状态,并在未得到支付端当前处于正常支付状态的指示时,从支付端获取当前的支付相关信息,并根据该支付相关信息确定出收款端,并询问收款端当前的支付状态,从而验证对当前支付是否出现异常,通过询问支付端并向收款端进行确认的方法,可以获知支付是否出现异常,便于支付平台及时对支付异常原因进行分析。

对应于图1至图8所对应的方法实施例,基于相同的思路,本说明书实施例还提供了一种支付异常的确定装置,该装置可以应用于支付系统,用于执行本说明书实施例提供的支付异常的确定方法,图9为本说明书实施例提供的支付异常的确定装置的模块组成示意图,图9所示的装置,包括:

第一询问模块901,若确定出支付端的支付页面的打开时长达到设定的支付时长阈值且支付端未支付成功,则询问上述支付端当前的支付状态;

第一获取模块902,若未得到处于正常支付状态的指示信息,则获取上述支付端的支付相关信息;其中,上述支付相关信息至少包括支付端当前所处的地理位置信息;

第二询问模块903,在根据上述支付相关信息确定出收款端后,询问上述收款端当前的支付状态,以验证当前支付是否出现异常。

可选的,本说明书实施例提供的装置,还包括:

第二获取模块,获取设定时间段内的历史支付数据集合;其中,上述历史支付数据集合包括每次支付的支付时间信息;上述支付时间信息为从支付页面开启到支付成功所对应的时间长度;

计算模块,根据上述历史支付数据集合中每次支付的支付时间信息,计算上述支付时长阈值;

第一发送模块,向上述支付端发送上述支付时长阈值。

可选的,上述历史支付数据集合包括每次支付时支付端所处的地理位置信息;

上述计算模块,具体用于:

根据每次支付所对应的地理位置信息,将上述历史支付数据集合划分为多个历史支付数据子集合;其中,每个上述历史支付数据子集合中所有支付数据所对应的地理位置属于同一个地理区域;根据每个上述历史支付数据子集合中每次支付的支付时间信息,计算上述历史支付数据子集合所对应地理区域的支付时长阈值;

相应的,上述第一发送模块,具体用于:

向上述支付端发送与上述支付端当前所处的地理位置信息相对应的支付时长阈值。

可选的,上述计算模块,还具体用于:

针对每个上述历史支付数据子集合,根据该历史支付数据子集合中每次支付的支付时间信息,计算该历史支付数据子集合所对应的支付时间平均值和支付时间标准差;根据上述历史支付数据子集合所对应的支付时间平均值和支付时间标准差,确定该历史支付数据子集合所对应地理区域的支付时长阈值。

可选的,上述计算模块,还具体用于:

根据上述历史支付数据子集合所对应的支付时间平均值和支付时间标准差,通过如下公式计算该历史支付数据子集合所对应地理区域的支付时长阈值;

si=μi+ni*σi

其中,在上述公式中,si表示第i个历史支付数据子集合所对应地理区域的支付时长阈值,μi表示第i个历史支付数据子集合所对应的支付时间平均值,σi表示第i个历史支付数据子集合所对应的支付时间标准差,ni表示第i个历史支付数据子集合所对应的系数。

可选的,上述计算模块,还具体用于:

从每个上述历史支付数据子集合中进行抽样,得到该历史支付数据子集合所对应的历史支付样本数据集合;根据上述历史支付样本数据集合中每次支付的支付时间信息,计算该历史支付数据子集合所对应地理区域的支付时长阈值。

可选的,上述第一询问模块901,具体用于:

向上述支付端发送询问消息;其中,上述询问消息用于询问上述支付端当前是否处于支付异常状态;

相应的,上述未得到上述支付端当前处于正常支付状态的指示,包括:

接收到上述支付端指示当前处于支付异常状态的信息,或者,在设定时间长度内未接收到上述支付端的指示信息。

可选的,若接收到上述支付端指示当前处于支付异常状态的信息;

上述装置还包括:

第二发送模块,将上述支付端当前所在地理位置周围设定范围内的店铺信息发送给上述支付端,以使上述支付端用户选择当前进行支付交易的收款端;

相应的,上述第一获取模块,具体用于:

获取上述支付端用户所选取的店铺信息和上述支付端当前所处的地理位置信息。

可选的,本说明书实施例提供的装置,还包括:

第一确定模块,确定当前时刻距离前一次向上述收款端发送询问信息的时间间隔;

第一判断模块,判断上述时间间隔是否大于设定时间间隔。

可选的,本说明书实施例提供的装置,还包括:

第二判断模块,判断上述支付相关信息中是否存在店铺标识信息;

第二确定模块,若上述支付相关信息中存在店铺标识信息,则将上述店铺标识信息所对应的店铺确定为上述收款端;否则,将位于上述支付端当前所处的地理位置处的店铺确定为上述收款端。

本说明书实施例提供的支付异常的确定装置,当支付页面的打开时长达到设定的支付时长阈值时,若未检测到支付成功,通过询问支付端当前的支付状态,并在未得到支付端当前处于正常支付状态的指示时,从支付端获取当前的支付相关信息,并根据该支付相关信息确定出收款端,并询问收款端当前的支付状态,从而验证对当前支付是否出现异常,通过询问支付端并向收款端进行确认的方法,可以获知支付是否出现异常,便于支付平台及时对支付异常原因进行分析。

进一步地,基于上述图1至图8所示的方法,本说明书实施例还提供了一种支付异常的确定设备,如图10所示。

支付异常的确定设备可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上的处理器1001和存储器1002,存储器1002中可以存储有一个或一个以上存储应用程序或数据。其中,存储器1002可以是短暂存储或持久存储。存储在存储器1002的应用程序可以包括一个或一个以上模块(图示未示出),每个模块可以包括对支付异常的确定设备中的一系列计算机可执行指令。更进一步地,处理器1001可以设置为与存储器1002通信,在支付异常的确定设备上执行存储器1002中的一系列计算机可执行指令。支付异常的确定设备还可以包括一个或一个以上电源1003,一个或一个以上有线或无线网络接口1004,一个或一个以上输入输出接口1005,一个或一个以上键盘1006等。

在一个具体的实施例中,支付异常的确定设备包括有存储器,以及一个或一个以上的程序,其中一个或者一个以上程序存储于存储器中,且一个或者一个以上程序可以包括一个或一个以上模块,且每个模块可以包括对支付异常的确定设备中的一系列计算机可执行指令,且经配置以由一个或者一个以上处理器执行该一个或者一个以上程序包含用于进行以下计算机可执行指令:

若确定出支付端的支付页面的打开时长达到设定的支付时长阈值且上述支付端未支付成功,则询问上述支付端当前的支付状态;

若未得到处于正常支付状态的指示信息,则获取上述支付端的支付相关信息;其中,上述支付相关信息至少包括支付端当前所处的地理位置信息;

在根据上述支付相关信息确定出收款端后,询问上述收款端当前的支付状态,以验证当前支付是否出现异常。

可选的,计算机可执行指令在被执行时,还可以实现如下步骤:

获取设定时间段内的历史支付数据集合;其中,上述历史支付数据集合包括每次支付的支付时间信息;上述支付时间信息为从支付页面开启到支付成功所对应的时间长度;

根据上述历史支付数据集合中每次支付的支付时间信息,计算上述支付时长阈值;

向上述支付端发送上述支付时长阈值。

可选的,计算机可执行指令在被执行时,上述历史支付数据集合包括每次支付时支付端所处的地理位置信息;

上述根据上述历史支付数据集合中每次支付的支付时间信息,计算上述支付时长阈值的步骤,包括:

根据每次支付所对应的地理位置信息,将上述历史支付数据集合划分为多个历史支付数据子集合;其中,每个上述历史支付数据子集合中所有支付数据所对应的地理位置属于同一个地理区域;

根据每个上述历史支付数据子集合中每次支付的支付时间信息,计算上述历史支付数据子集合所对应地理区域的支付时长阈值;

上述向上述支付端发送上述支付时长阈值的步骤,包括:

向上述支付端发送与上述支付端当前所处的地理位置信息相对应的支付时长阈值。

可选的,计算机可执行指令在被执行时,上述根据每个上述历史支付数据子集合中每次支付的支付时间信息,计算上述历史支付数据子集合所对应地理区域的支付时长阈值的步骤,包括:

针对每个上述历史支付数据子集合,根据该历史支付数据子集合中每次支付的支付时间信息,计算该历史支付数据子集合所对应的支付时间平均值和支付时间标准差;

根据上述历史支付数据子集合所对应的支付时间平均值和支付时间标准差,确定该历史支付数据子集合所对应地理区域的支付时长阈值。

可选的,计算机可执行指令在被执行时,上述根据上述历史支付数据子集合所对应的支付时间平均值和支付时间标准差,确定该历史支付数据子集合所对应地理区域的支付时长阈值的步骤,包括:

根据上述历史支付数据子集合所对应的支付时间平均值和支付时间标准差,通过如下公式计算该历史支付数据子集合所对应地理区域的支付时长阈值;

si=μi+ni*σi

其中,在上述公式中,si表示第i个历史支付数据子集合所对应地理区域的支付时长阈值,μi表示第i个历史支付数据子集合所对应的支付时间平均值,σi表示第i个历史支付数据子集合所对应的支付时间标准差,ni表示第i个历史支付数据子集合所对应的系数。

可选的,计算机可执行指令在被执行时,上述根据每个上述历史支付数据子集合中每次支付的支付时间信息,计算上述历史支付数据子集合所对应地理区域的支付时长阈值的步骤,包括:

从每个上述历史支付数据子集合中进行抽样,得到该历史支付数据子集合所对应的历史支付样本数据集合;

根据上述历史支付样本数据集合中每次支付的支付时间信息,计算该历史支付数据子集合所对应地理区域的支付时长阈值。

可选的,计算机可执行指令在被执行时,上述询问上述用户当前的支付状态的步骤,包括:

向上述支付端发送询问消息;其中,上述询问消息用于询问上述支付端当前是否处于支付异常状态;

相应的,上述未得到上述支付端当前处于正常支付状态的指示,包括:

接收到上述支付端指示当前处于支付异常状态的信息,或者,在设定时间长度内未接收到上述支付端的指示信息。

可选的,计算机可执行指令在被执行时,若接收到上述支付端指示当前处于支付异常状态的信息;

上述获取上述支付端当前的支付相关信息之前,还可以实现如下步骤:

将上述支付端当前所在地理位置周围设定范围内的店铺信息发送给上述支付端,以使上述支付端用户选择当前进行支付交易的收款端;

相应的,上述获取上述支付端当前的支付相关信息的步骤,包括:

获取上述支付端用户所选取的店铺信息和上述支付端当前所处的地理位置信息。

可选的,计算机可执行指令在被执行时,上述询问上述收款端当前是否出现支付异常之前,还可以实现如下步骤:

确定当前时刻距离前一次向上述收款端发送询问信息的时间间隔;并判断上述时间间隔是否大于设定时间间隔。

可选的,计算机可执行指令在被执行时,通过以下步骤根据上述支付相关信息确定上述收款端:

判断上述支付相关信息中是否存在店铺标识信息;

若存在,则将上述店铺标识信息所对应的店铺确定为上述收款端;否则,将位于上述支付端当前所处的地理位置处的店铺确定为上述收款端。

本说明书实施例提供的支付异常的确定设备,当支付页面的打开时长达到设定的支付时长阈值时,若未检测到支付成功,通过询问支付端当前的支付状态,并在未得到支付端当前处于正常支付状态的指示时,从支付端获取当前的支付相关信息,并根据该支付相关信息确定出收款端,并询问收款端当前的支付状态,从而验证对当前支付是否出现异常,通过询问支付端并向收款端进行确认的方法,可以获知支付是否出现异常,便于支付平台及时对支付异常原因进行分析。

进一步地,基于上述图1至图8所示的方法,本说明书实施例还提供了一种存储介质,用于存储计算机可执行指令,一种具体的实施例中,该存储介质可以为u盘、光盘、硬盘等,该存储介质存储的计算机可执行指令在被处理器执行时,能实现以下流程:

若确定出支付端的支付页面的打开时长达到设定的支付时长阈值且上述支付端未支付成功,则询问上述支付端当前的支付状态;

若未得到处于正常支付状态的指示信息,则获取上述支付端的支付相关信息;其中,上述支付相关信息至少包括支付端当前所处的地理位置信息;

在根据上述支付相关信息确定出收款端后,询问上述收款端当前的支付状态,以验证当前支付是否出现异常。

可选的,该存储介质存储的计算机可执行指令在被处理器执行时,还可以实现如下流程:

获取设定时间段内的历史支付数据集合;其中,上述历史支付数据集合包括每次支付的支付时间信息;上述支付时间信息为从支付页面开启到支付成功所对应的时间长度;

根据上述历史支付数据集合中每次支付的支付时间信息,计算上述支付时长阈值;

向上述支付端发送上述支付时长阈值。

可选的,该存储介质存储的计算机可执行指令在被处理器执行时,

上述历史支付数据集合包括每次支付时支付端所处的地理位置信息;

上述根据上述历史支付数据集合中每次支付的支付时间信息,计算上述支付时长阈值的步骤,包括:

根据每次支付所对应的地理位置信息,将上述历史支付数据集合划分为多个历史支付数据子集合;其中,每个上述历史支付数据子集合中所有支付数据所对应的地理位置属于同一个地理区域;

根据每个上述历史支付数据子集合中每次支付的支付时间信息,计算上述历史支付数据子集合所对应地理区域的支付时长阈值;

上述向上述支付端发送上述支付时长阈值的步骤,包括:

向上述支付端发送与上述支付端当前所处的地理位置信息相对应的支付时长阈值。

可选的,该存储介质存储的计算机可执行指令在被处理器执行时,上述根据每个上述历史支付数据子集合中每次支付的支付时间信息,计算上述历史支付数据子集合所对应地理区域的支付时长阈值的步骤,包括:

针对每个上述历史支付数据子集合,根据该历史支付数据子集合中每次支付的支付时间信息,计算该历史支付数据子集合所对应的支付时间平均值和支付时间标准差;

根据上述历史支付数据子集合所对应的支付时间平均值和支付时间标准差,确定该历史支付数据子集合所对应地理区域的支付时长阈值。

可选的,该存储介质存储的计算机可执行指令在被处理器执行时,上述根据上述历史支付数据子集合所对应的支付时间平均值和支付时间标准差,确定该历史支付数据子集合所对应地理区域的支付时长阈值的步骤,包括:

根据上述历史支付数据子集合所对应的支付时间平均值和支付时间标准差,通过如下公式计算该历史支付数据子集合所对应地理区域的支付时长阈值;

si=μi+ni*σi

其中,在上述公式中,si表示第i个历史支付数据子集合所对应地理区域的支付时长阈值,μi表示第i个历史支付数据子集合所对应的支付时间平均值,σi表示第i个历史支付数据子集合所对应的支付时间标准差,ni表示第i个历史支付数据子集合所对应的系数。

可选的,该存储介质存储的计算机可执行指令在被处理器执行时,上述根据每个上述历史支付数据子集合中每次支付的支付时间信息,计算上述历史支付数据子集合所对应地理区域的支付时长阈值的步骤,包括:

从每个上述历史支付数据子集合中进行抽样,得到该历史支付数据子集合所对应的历史支付样本数据集合;

根据上述历史支付样本数据集合中每次支付的支付时间信息,计算该历史支付数据子集合所对应地理区域的支付时长阈值。

可选的,该存储介质存储的计算机可执行指令在被处理器执行时,上述询问上述用户当前的支付状态的步骤,包括:

向上述支付端发送询问消息;其中,上述询问消息用于询问上述支付端当前是否处于支付异常状态;

相应的,上述未得到上述支付端当前处于正常支付状态的指示,包括:

接收到上述支付端指示当前处于支付异常状态的信息,或者,在设定时间长度内未接收到上述支付端的指示信息。

可选的,该存储介质存储的计算机可执行指令在被处理器执行时,若接收到上述支付端指示当前处于支付异常状态的信息;

上述获取上述支付端当前的支付相关信息之前,还可以实现如下步骤:

将上述支付端当前所在地理位置周围设定范围内的店铺信息发送给上述支付端,以使上述支付端用户选择当前进行支付交易的收款端;

相应的,上述获取上述支付端当前的支付相关信息的步骤,包括:

获取上述支付端用户所选取的店铺信息和上述支付端当前所处的地理位置信息。

可选的,该存储介质存储的计算机可执行指令在被处理器执行时,上述询问上述收款端当前是否出现支付异常之前,还可以实现如下流程:

确定当前时刻距离前一次向上述收款端发送询问信息的时间间隔;并判断上述时间间隔是否大于设定时间间隔。

可选的,该存储介质存储的计算机可执行指令在被处理器执行时,通过以下步骤根据上述支付相关信息确定上述收款端:

判断上述支付相关信息中是否存在店铺标识信息;

若存在,则将上述店铺标识信息所对应的店铺确定为上述收款端;否则,将位于上述支付端当前所处的地理位置处的店铺确定为上述收款端。

本说明书实施例提供的存储介质所存储的计算机可执行指令在被处理器执行时,当支付页面的打开时长达到设定的支付时长阈值时,若未检测到支付成功,通过询问支付端当前的支付状态,并在未得到支付端当前处于正常支付状态的指示时,从支付端获取当前的支付相关信息,并根据该支付相关信息确定出收款端,并询问收款端当前的支付状态,从而验证对当前支付是否出现异常,通过询问支付端并向收款端进行确认的方法,可以获知支付是否出现异常,便于支付平台及时对支付异常原因进行分析。

在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(programmablelogicdevice,pld)(例如现场可编程门阵列(fieldprogrammablegatearray,fpga))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(hardwaredescriptionlanguage,hdl),而hdl也并非仅有一种,而是有许多种,如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等,目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)与verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit,asic)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中,计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(ram)和/或非易失性内存等形式,如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitorymedia),如调制的数据信号和载波。

还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1