CN113129012A - 支付数据处理方法、装置、设备及*** - Google Patents

Abstract

本说明书提供一种支付数据处理方法、装置、设备及***，在支付交易订单生成之前，感知到支付行为开始时，即开始对支付事件进行监听，实现对支付事件的全程监听。能够适用于支付事件支付失败的全部场景，覆盖面广，如：对于刷脸后未确认支付、扫码后输入金额但未确认支付、设备故障导致未收款成功等场景均可以覆盖。在支付事件支付失败后，及时对支付事件进行漏单风险识别，并基于漏单风险识别的结果自动通知收款用户进行漏单核对，实现了支付漏单的自动识别，提高了支付交易的安全性。

Description

支付数据处理方法、装置、设备及***

技术领域

本说明书属于计算机技术领域，尤其涉及一种支付数据处理方法、装置、设备及***。

背景技术

随着计算机互联网技术的发展，选择线上支付的用户越来越多，逐渐替代了现金支付。一般的，用户在支付时可以选择扫码、刷脸等方式提交支付请求，再进行支付金额确认或输入需要支付的金额，安全校验后完成支付。一般的在繁忙时期，或商户为了维护客户，不会仔细核对用户的支付情况，使得这种支付方式可能存在漏单、逃单等问题，如：用户选择确认支付后没有等到支付成功的提示，由于网络等原因，导致支付失败，但用户已经离开支付地点；或者恶意用户在扫码后没有点击确认支付，直接离开。

如何能够及时发现漏单或逃单的支付交易，提高支付交易的安全性，是本领域亟需解决的技术问题。

发明内容

本说明书实施例的目的在于提供一种支付数据处理方法、装置、设备及***，实现了支付漏单的自动识别，提高了支付交易的安全性。

第一方面，本说明书实施例提供了一种支付数据处理方法，所述方法包括：

接收支付行为触发指令，对所述支付行为触发指令对应的支付事件进行监听；

在监听到所述支付行为触发指令对应的支付事件支付失败后，获取所述支付行为触发指令对应的支付交易信息、支付用户信息、收款客户端信息；

基于所述支付交易信息、所述支付用户信息以及所述收款客户端信息对所述支付行为触发指令对应的支付事件进行漏单风险识别，确定出所述支付行为触发指令对应的支付事件的风险识别结果；

根据所述风险识别结果，向所述支付行为触发指令对应的收款用户发送漏单提醒信息。

第二方面，本说明书实施例提供了一种支付数据处理方法，所述方法包括：

接收服务端在监听到支付事件存在异常操作时发送的支付异常风险信息；其中，所述支付事件为所述服务端在接收到所述支付事件的支付行为触发指令后开始对所述支付事件进行监听的；

根据所述支付异常风险信息对应的风险等级，播报对应的支付异常提示信息，其中，所述支付异常提示信息包括：支付异常提示音效、支付异常提示语音、支付异常警示灯中的至少一种。

第三方面，本说明书提供了一种支付数据处理装置，所述装置包括：

支付监听模块，用于接收支付行为触发指令，对所述支付行为触发指令对应的支付事件进行监听；

异常信息获取模块，用于在监听到所述支付行为触发指令对应的支付事件支付失败后，获取所述支付行为触发指令对应的支付交易信息、支付用户信息、收款客户端信息；

异常识别模块，用于基于所述支付交易信息、所述支付用户信息以及所述收款客户端信息对所述支付行为触发指令对应的支付事件进行漏单风险识别，确定出所述支付行为触发指令对应的支付事件的风险识别结果；

风险提醒模块，用于根据所述风险识别结果，向所述支付行为触发指令对应的收款用户发送漏单提醒信息。

第四方面，本说明书提供了一种支付数据处理装置，所述装置包括：

异常信息接收模块，用于接收服务端在监听到支付事件存在异常操作时发送的支付异常风险信息；其中，所述支付事件为所述服务端在接收到所述支付事件的支付行为触发指令后开始对所述支付事件进行监听的；

异常信息播报模块，用于根据所述支付异常风险信息对应的风险等级，播报对应的支付异常提示信息，其中，所述支付异常提示信息包括：支付异常提示音效、支付异常提示语音、支付异常警示灯中的至少一种。

第五方面，本说明书实施例提供了一种支付数据处理设备，包括至少一个处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现上述第一方面或第二方面支付数据处理方法。

第六方面，本说明书实施例提供了一种支付数据处理***，包括：支付服务端、收款提示播报设备，其中：

所述支付服务端中存储有计算机指令，所述指令被执行时实现第一方面所述方法的步骤，用于在接收到支付客户端或收款客户端上报的支付行为触发指令，对所述支付行为触发指令对应的支付事件进行监听，在监听到所述支付事件存在异常操作时，向所述支付行为触发指令对应的收款提示播报设备发送支付异常风险信息，在所述支付事件支付失败后，对所述支付事件进行漏单风险识别；

所述收款提示播报设备上存储有计算机指令，所述指令被执行时实现上述第二方面所述方法的步骤，用于接收所述支付服务端发送的支付异常风险信息，并根据所述支付异常风险信息对应的风险等级，播报对应的支付异常提示信息。

本说明书提供的支付数据处理方法、装置、设备及***，在支付交易订单生成之前，感知到支付行为开始时，即开始对支付事件进行监听，实现对支付事件的全程监听。能够适用于支付事件支付失败的全部场景，覆盖面广，如：对于刷脸后未确认支付、扫码后输入金额但未确认支付、设备故障导致未收款成功等场景均可以覆盖。在支付事件支付失败后，及时对支付事件进行漏单风险识别，并基于漏单风险识别的结果自动通知收款用户进行漏单核对，实现了支付漏单的自动识别，提高了支付交易的安全性。

附图说明

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

图1是本说明书实施例提供的支付数据处理方法实施例的流程示意图；

图2是本说明书一些实施例中收款提示播报设备的支付数据处理方法流程示意图；

图3是针对已经得到支付结果及未支付成功的支付交易进行风险识别；

图4是本说明书实施例中支付交易过程中的监听以及异常播报的流程示意图；

图5是本说明书提供的支付数据处理装置一个实施例的模块结构示意图；

图6是本说明书提供的支付数据处理装置另一个实施例的模块结构示意图；

图7是本说明书一个实施例中支付数据处理服务器的硬件结构框图。

具体实施方式

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

对于支付中的漏单或逃单交易，一般的，需要商户自行查询，再通过致电客服，进行申诉，由客服进行人工审核，客服审核后再发送用户，申诉过程繁琐。并且，这种申诉需要提供订单号，一般的，在接收到用户的支付请求后，才会生成一笔订单，若未完成订单，那么可能没有订单号，如：若用户扫码后没有点击前置页输入金额，并提交支付请求，那么就认为该笔订单没有生成，对于此种情况，可能无法进行申诉。

本说明书实施例，通过在接收到支付行为触发指令开始，即在交易订单生成前，就可以感知到交易行为，并对该支付交易进行监听，在确定支付交易失败后，对该支付事件进行漏单风险识别，基于识别结果通知商户进行申诉，确保支付交易的安全性。

图1是本说明书实施例提供的支付数据处理方法实施例的流程示意图。虽然本说明书提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者部分合并后更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本说明书实施例或附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置、服务器或终端产品应用时，可以按照实施例或者附图所示的方法或模块结构进行顺序执行或者并行执行(例如并行处理器或者多线程处理的环境、甚至包括分布式处理、服务器集群的实施环境)。

本说明书实施例中提供的支付数据处理方法可以应用在客户端、服务器等终端设备中，如：智能手机，或PC(Personal Computer，个人计算机)终端或智能穿戴设备终端中，如图1所示，所述方法可以包括如下步骤：

步骤102、接收支付行为触发指令，对所述支付行为触发指令对应的支付事件进行监听。

在具体的实施过程中，本说明书实施例中，可以在接收到支付行为触发指令开始对支付事件进行监听，支付行为触发指令可以理解为支付事件开始的操作，可以在支付订单提交前触发该支付行为触发指令，如：在支付用户通过刷脸、刷指纹、或利用客户端进行扫码或通过客户端出示图形码由商户的收款终端扫码进行支付等行为可以理解为支付事件的开始，触发对支付事件的监听操作。其中，对支付事件进行监听可以理解为对支付事件的各个流程或操作进行监听，如：监听该支付事件中各个操作是否与正常支付流程一致，监听从触发监听动作到完成支付的时间等，可以通过支付用户的客户端中的支付应用程序对支付用户的支付操作进行监听，还可以通过收款用户的收款客户端或收款设备对收款账户进行监听，具体监听方式和监听内容本说明书实施例不做具体限定。

本说明书一些实施例中，所述接收支付行为触发指令包括：

接收收款客户端上报的生物图像扫描信息或图形码扫描信息；

或，接收支付客户端上报的图形码扫描信息。

在具体的实施过程中，商户及收款用户可以通过收款客户端扫描支付用户的支付图形码，当收款客户端扫描到支付用户出示的图形码后，可以向服务端发送扫描到的图形码扫描信息，该图形码扫描信息可以理解为支付行为触发指令。服务端接收到该支付行为触发指令后，可以获取扫码用户即支付用户的用户信息如：通过支付用户的支付图形码获取支付用户的账户信息等，并开始监听该笔支付事件。或者，一些收款客户端可以提供刷脸或刷指纹等生物识别验证的支付方式，即用户可以预先将自己的支付账户与自己的生物图像绑定，在支付时，可以直接通过收款客户端扫描自己的生物图像信息触发支付请求。当收款客户端接收到用户的生物图像扫描信息或收款客户端的生物图像扫描收款操作被触发后，收款客户端可以将扫描到的生物图像扫描信息如：支付用户的脸部图像或指纹图像等作为支付行为触发指令，发送至服务端。服务端接收到该支付行为触发指令后，可以获取支付用户的用户信息，如：可以通过生物图像扫描信息获取到支付用户的账户信息，并开始监听该笔支付事件。

在另一些实施例中，商户或者收款用户可以通过收款客户端如：智能手机或收款设备等出示收款图形码，或者商户也可以将自己的收款图形码打印粘贴在店铺，当支付用户通过支付客户端如智能手机或智能手表等扫描商户提供的图形码后，获得图形码扫描信息，该图形码扫描信息可以作为支付行为触发指令通过支付客户端发送给服务端。支付客户端可以通过支付应用程序向服务端发送支付行为触发指令，服务端在接收到支付客户端发送的支付行为触发指令后，可以基于支付客户端中的支付应用程序获取支付用户信息如：支付账户信息等。

本说明书实施例，通过支付设备或支付客户端或收款客户端独有的感知能力，在支付交易行为开始，触发对支付事件的监听，实现对支付事件的完整跟踪，以及时发现支付过程中是否有异常问题，及时提醒收款用户，确保支付交易的安全性。

步骤104、在监听到所述支付行为触发指令对应的支付事件支付失败后，获取所述支付行为触发指令对应的支付交易信息、支付用户信息、收款客户端信息。

在具体的实施过程中，在对支付行为触发指令对应的支付事件进行监听时，若监听到支付事件对应的支付事件支付失败后，可以获取对应的支付交易信息(如：支付金额、支付请求提交时间、支付失败原因等)、支付用户信息(如：支付用户的账户信息)、收款客户端信息(如：收款客户端的设备标识、收款信息等)。

其中，本说明书一些实施例中，所述支付行为触发指令对应的支付事件支付失败的确定方法包括：

若接收到所述支付行为触发指令后第一指定时间内未收到支付结果，则确定所述支付行为触发指令对应的支付事件支付失败；

或，若接收到所述支付行为触发指令对应的支付事件支付失败提示信息，则确定所述支付行为触发指令对应的支付事件支付失败。

在具体的实施过程中，若从支付交易开始第一指定时间如20秒，没接收到支付结果，支付用户可能在扫码或刷脸后长时间停留在支付前置页，没有进行下一步的操作，那么该笔支付交易可能存在漏单的风险。若在接收到支付行为触发指令后的第一指定时间内没有接收到支付结果，则确定支付行为触发指令对应的支付事件支付失败，需要进行漏单风险识别。若接收到支付行为触发指令对应的支付事件的支付结果为支付失败，如：账户余额不足或密码错误等导致支付失败，可以认为该笔支付交易已经结束，但是商家并没有收到支付金额，那么该笔支付交易可能存在漏单的风险。可以在接收到支付失败提示信息后，确定该笔支付交易支付失败，需要进行漏单风险识别。通过对支付事件进行监听，在监听到支付事件的支付结果为支付失败或长时间没有收到支付结果，则可以对该支付事件进行漏单风险识别，以及时发现存在风险的支付交易，确保支付交易的安全性。

本说明书一些实施例中，所述支付用户信息包括支付用户的历史交易信息，所述收款客户端信息包括收款客户端在第二指定时间内的设备网络信息以及所述收款客户端在第三指定时间内收款的数量。

在具体的实施过程中，支付用户信息可以包括支付用户的历史交易信息如：可以获取支付用户在过去一个月或一周或半年内的支付失败交易信息以及支付失败原因，或者获取支付用户的支付成功率或支付失败率等，作为该支付用户的历史交易信息。结合支付用户的历史交易信息对当前支付事件进行漏单风险识别，实现对支付用户的风险评估，以提高风险识别的准确性。收款客户端信息可以包括收款客户端在第二指定时间内的设备网络信息以及收款客户端在第二指定时间内收款的数量，其中，第二指定时间可以根据实际需要进行设置可以为当前时间之前的一小时或当前时间之前一天或一周等，本说明书实施例不做具体限定，设备网络信息可以理解为评估收款客户端的网络稳定性，若网络不稳定，那么支付交易失败的可能性就比较高。收款客户端在第三指定时间内收款的数量可以理解为收款用户的繁忙程度，期中第三指定时间一般可以为当前时间之前的1小时、2小时、3小时等，通过分析收款客户端的收款密度可以确定出收款用户的繁忙程度，若在当前的支付交易期间收款用户比较忙，收款用户可能无法及时确认支付交易是否成功，使得一些恶意用户进行逃单，那么支付失败的支付交易可能存在比较大的风险。

本说明书实施例结合支付用户的历史交易信息、收款设备的网络情况以及收款用户的繁忙程度来对支付失败的支付交易进行漏单风险识别，实现了对漏单的自动识别，提高了支付交易的安全性。

步骤106、基于所述支付交易信息、所述支付用户信息以及所述收款客户端信息对所述支付行为触发指令对应的支付事件进行漏单风险识别，确定出所述支付行为触发指令对应的支付事件的风险识别结果。

在具体的实施过程中，在确定监听的支付事件支付失败后，可以基于获取到的支付交易信息、支付用户信息以及收款客户端信息对支付事件进行漏单风险识别。漏单风险识别的方法可以采用智能学习算法或专家策略等方式，如：可以根据历史支付交易以及历史支付交易的漏单结果作为标签，进行模型训练，构建出漏单风险识别模型，其中模型的结构或算法可以基于实际需要进行选择如：可以选择随机森林算法、神经网络模型等。再利用构建出的漏单风险识别模型对当前支付事件进行风险识别，可以将当前支付事件的支付交易信息、支付用户信息以及收款客户端信息输入到漏单风险识别模型中，进而获得当前支付事件的风险识别结果。其中，风险识别结果可以为支付事件的风险等级或存在风险概率等，具体可以根据实际需要进行设置，本说明书实施例不做具体限定。

步骤108、根据所述风险识别结果，向所述支付行为触发指令对应的收款用户发送漏单提醒信息。

在具体的实施过程中，在确定出当前的支付事件的风险识别结果后，可以根据风险识别结果，向支付行为触发指令对应的收款用户发送漏单提醒信息，其中，漏单提醒信息中可以包括存在风险的支付交易信息如：支付交易的订单号、支付金额、支付交易时间等，以及支付用户信息如：支付用户的账户等，还可以包括该笔风险支付交易的风险等级，以供收款用户及时进行核对。

此外，还可以根据支付事件的风险识别结果中的风险等级，选择向收款用户发送漏单提醒信息的时间以及方式，如：若风险等级比较高，则可以尽快并且能够确保收款用户及时收到的方式如：电话或短信或服务信息等，向收款用户发送漏单提醒信息，以确保收款用户能够及时进行核对。若支付事件的风险等级比较低，那么发送时间可以适当延后，并且采用对用户打扰较低的方式如：邮件或在支付应用程序中推送提示信息等，以降低对用户的打扰。

本说明书一些实施例中，所述根据所述风险识别结果，向所述支付行为触发指令对应的收款用户发送漏单提醒信息包括：

若所述风险识别结果的风险等级大于预设等级，则将所述漏单提醒信息发送至所述收款用户的客户端；

若所述风险识别结果的风险等级小于或等于所述预设等级，则将所述漏单提醒信息保存至支付交易平台的漏单信息列表中，以供所述收款用户查看。

在具体的实施过程中，若支付事件的风险等级大于预设等级，级该支付事件存在比较大的概率为漏单事件，则可以直接将漏单提醒信息发送至收款用户的客户端如：智能手机，具体可以通过电话、短信、客户端服务信息、邮件等方式发送，本说明书实施例不做具体限定。若支付事件的风险等级小于或等于预设等级，即该支付事件存在漏单风险的概率比较低，那么可以不直接向收款用户的客户端推送漏单提醒信息，而是将漏单提醒信息保存在支付交易平台的漏单信息列表中，收款用户可以通过客户端中的支付应用程序或通过登录支付交易平台的方式查看漏单支付交易信息。当然，漏单信息列表中可以不仅仅包括风险等级低的支付交易信息，还可以包括风险高的或者全部支付失败存在漏单风险的支付交易信息，以便商家查看。这样可以确保对于风险程度高的支付交易商户能够及时核对，对于风险程度不高的支付交易商户可以在空闲时自行查看并核对，既确保了风险支付交易能够及时告知商户，以使得商户能够及时进行追诉，又避免给商户造成过多的打扰，提升用户体验感。

此外，本说明书一些实施例中，所述方法还包括：

根据所述风险识别结果，将各个支付事件对应的支付交易信息进行风险标记，并将标记好的支付事件的支付交易信息以及对应的收款用户存储到区块链中，以供所述收款用户通过区块链查询漏单信息。

在具体的实施过程中，本说明书实施例可以根据各个支付事件对支付交易信息进行风险标记，将存在风险的支付交易标记上对应的风险标识，再将标记好的支付交易信息以及对应的收款用户存储到区块链中，以避免不法用户篡改支付交易信息，使得存在风险的支付交易被篡改为安全交易，给收款用户带来损失。当收款用户需要进行漏单信息查询时，可以通过区块链下载自己关联的支付交易信息，并对其中存在风险标识的支付交易进行重点核对，提升了支付交易的安全性。

本说明书实施例提供的支付数据处理方法，在支付交易订单生成之前，感知到支付行为开始时，即开始对支付事件进行监听，实现对支付事件的全程监听。能够适用于支付事件支付失败的全部场景，覆盖面广，如：对于刷脸后未确认支付、扫码后输入金额但未确认支付、设备故障导致未收款成功等场景均可以覆盖。在支付事件支付失败后，及时对支付事件进行漏单风险识别，并基于漏单风险识别的结果自动通知收款用户进行漏单核对，实现了支付漏单的自动识别，提高了支付交易的安全性。

在上述实施例的基础上，本说明书一些实施例中，所述方法还包括：

接收所述收款用户在接收到所述漏单提醒信息后发送的漏单申诉请求，所述漏单申诉请求中包括支付用户信息；

根据所述漏单申诉请求，向所述支付用户信息对应的支付客户端发送漏单核对信息。

在具体的实施过程中，实际支付场景比较复杂，本说明书实施例在识别到支付交易存在风险后，可以向收款用户发送漏单提醒信息，收款用户在接收到服务端发送的漏单提醒信息后，可以自行核对该笔支付事件是否确实是漏单交易，以保证风险识别的结果准确性，避免用户在当前的支付中支付失败后选择其他支付方式如：现金、朋友代付、切换支付方式等继续完成该笔交易，但被误识别成漏单支付交易的情况。若收款用户确认漏单提醒信息中的支付交易确实为漏单交易，则可以向服务端发送漏单申诉请求，如：可以通过收款用户的客户端中的支付应用程序或直接登录服务端或通指定的应用程序向服务端发送漏单申诉请求，该漏单申诉请求中可以包括申诉金额、申诉原因、联系方式以及申诉涉及的支付交易信息(如：支付用户信息等)等。服务端在接收到收款用户提交的漏单申诉请求后，可以向对应的支付用户的支付客户端发送漏单核对信息，漏单核对信息中可以包括支付交易的订单信息、支付金额、交易时间、交易商品、收款用户的账户信息以及收款用户的联系方式等，以供支付用户核对自己是否需要补款。若支付用户确认需要进行补款，则可以直接向收款账户转入对应的金额，或与收款用户联系补款事宜，若支付用户有疑问也可以与收款用户联系沟通协调。

本说明书实施例可以实现漏单的自动识别，并辅助用户进行漏单申诉，作为中间桥梁代为联系支付用户，避免收款用户和支付用户直接沟通可能导致支付用户的反感而拒绝沟通，提升了漏单申诉的效率以及成功率，确保了支付交易的安全性。

此外，本说明书一些实施例中，所述方法还包括：

根据所述漏单申诉请求对所述收款用户进行风险识别，在所述收款用户风险识别通过后向所述支付用户信息发送漏单核对信息。

在具体的实施过程中，服务端在接收到收款用户的漏单申诉请求后，还可以对收款用户进行风险识别，如：可以获取历史指定时间段内收款用户的漏单申诉信息，分析收款用户是否为恶意申诉。若收款用户风险识别通过，则向支付用户的客户端发送漏单核对信息。通过对漏单申诉的收款用户进行风险识别，确保漏单申诉的真实性，避免给支付用户带来不必要的打扰，提升漏单申诉的安全性。

本说明书另一些实施例中，所述漏单申诉请求中包括漏单时间，所述根据所述漏单申诉请求，向所述支付用户信息对应的支付客户端发送漏单核对信息，包括：

若所述漏单时间与当前时间之间的时间差在指定漏单时间范围内，则采用外呼方式向所述支付用户信息对应的支付客户端发送漏单核对信息，否则，采用短信提醒或服务信息提醒的方式向所述支付用户信息对应的支付客户端发送漏单核对信息。

在具体的实施过程中，收款用户向服务端提交的漏单申诉请求中可以包括漏单时间，漏单时间可以理解为漏单支付交易的交易时间，服务端在接收到漏单申诉请求后，可以计算漏单时间和当前时间之间的时间差，若时间差在指定漏单时间范围如30分钟或10分钟内，此时，支付用户比较大的可能性仍在支付地附近，能够返回与收款用户协商补款事宜。对于这种申诉方式，则可以采用外呼即直接拨打电话的方式向支付用户信息对应的支付客户端发送漏单核对信息，以便商家和顾客能够及时对漏单的支付交易进行核对，提升漏单补款的效率和成功率。若计算出的漏单时间和当前时间之间的时间差大于该指定漏单时间范围，则可以采用短信提醒或服务信息提醒的方式向支付用户信息对应的支付客户端发送漏单核对信息。

例如：用户A在中午12点通过刷脸触发了支付行为触发指令，服务端对用户A当前的支付事件进行监听，发现用户A刷脸后未确认支付，并对该笔支付交易进行漏单风险识别，确定该笔支付交易存在风险后，向收款用户B发送了漏单提醒信息。收款用户B接收到该漏单提醒信息后当天及时进行核对，确认该笔支付交易确实为一笔漏单，并在中午12点15分向服务端提交了漏单申诉请求。服务端接收到收款用户B发送的漏单申诉请求后，发现该笔申诉请求涉及的交易为15分钟之前发生的，在对收款用户B风险识别通过后，即拨打用户A的电话，告知其在12点发生了一笔交易，但该笔交易未支付成功，提示用户A进行核对，确定是否需要补款。因交易时间据当前时间较短，用户A很大可能还在付款底附近，可以及时与商家进行沟通，提高了漏单追诉的效率和成功率。

此外，本说明书一些实施例中，所述对所述支付行为触发指令对应的支付事件进行监听，包括：

在监听到所述支付事件存在异常操作时，向所述支付行为触发指令对应的收款提示播报设备发送支付异常风险信息，以使得所述收款提示播报设备播报对应的支付异常提示信息。

在具体的实施过程中，服务端在接收到支付行为触发指令并对支付事件进行监听时，可以监听支付事件中的各个支付流程，若发现支付事件存在异常操作即支付事件的某个或某几个支付流程与正常的操作流程不同，则向支付行为触发指令对应的收款提示播报设备发送支付异常风险信息。其中，收款提示播报设备可以为收款播报音响或能够对收款成功或失败进行语音播报的设备，支付异常风险信息中可以包括支付异常的原因如：支付时间过长、支付页面关闭等，支付异常操作，还可以包括支付异常涉及的交易金额以及交易时间等，具体可以根据实际需要进行设置，本说明书实施例不做具体限定。收款提示播报设备接收到服务端发送的支付异常风险信息后，可以根据支付异常风险信息的异常原因或风险等级播报对应的支付异常提示信息。其中，不同的支付异常操作可以播报不同的支付异常提示信息。本说明书实施例中的所述支付异常提示信息可以包括：支付异常提示音效、支付异常提示语音、支付异常警示灯中的至少一种。一般的，支付异常提示音效可以选择比较引人注意的音效，支付异常提示语音一般可以包括漏单的金额，支付异常警示灯可以根据不同的异常操作行为设置为不同闪烁频率或不同颜色的警示灯，实现对用户的提醒，通过声、光以及语音播报结合的方式，实现对异常交易操作及时提醒的作用，并给逃单用户一定的心理压力，以减少逃单支付交易的数量，提高支付交易的安全性。

通过对支付事件进行全程监听，对于不同异常操作向收款提示播报设备发送不同的支付异常风险信息，以使得收款提示播报设备可以针对不同的异常操作播报不同的支付异常提示信息，提醒商家以及支付用户及时关注，以保障支付交易能够正常完成。

本说明书一些实施例中，所述支付事件中的异常操作包括：

所述支付事件中支付前置页关闭、收银台页面关闭、支付应用程序切换至后台、支付失败切换支付方式、在支付前置页或收银台页面停留时间大于第四指定时间中的任一项。

支付前置页一般为输入金额的页面，有些恶意用户在支付前置页输入金额给商户查看后关闭该页面，不继续支付，误导收款用户，以达到逃单的目的，或者忘记支付，造成漏单。收银台页面一般为确认密码页面，若用户支付事件进行到该页面后关闭该页面，会导致支付取消，直接获得支付失败的交易结果。若在支付过程中支付用户的客户端收到其他信息如：电话、邮件或社交信息等，可能会随手将支付应用切换至后台，之后忘记支付，导致该笔支付交易没有正常完成。若支付用户的账户余额不足或支付账户出现问题，可能会选择切换支付方式，那么需要重新监听新的支付事件。若支付用户在在支付前置页或收银台页面停留时间大于第四指定时间，即长时间停留没有进行支付操作，也可能会存在漏单情况。本说明书实施例可以通过支付应用程序对支付事件进行全程监听，对于一些异常的支付操作可以通过收款提示播报设备对支付用户以及收款用户进行及时的提醒，避免漏单，提升交易的安全性。

本说明书一些实施例中，所述在监听到所述支付事件存在异常操作时，向所述支付行为触发指令对应的收款提示播报设备发送支付异常风险信息，包括：

预先将支付事件中不同的异常操作设置风险等级，根据监听到的所述支付事件中出现的异常操作对应的风险等级，向所述收款提示播报设备发送不同等级的支付异常风险信息，以使得所述收款提示播报设备播报对应的支付异常提示信息。

在具体的实施过程中，可以预先给不同的异常操作设置风险等级，在坚挺到支付事件中出现异常操作后，向收款提示播报设备发送不同等级的支付异常风险信息，收款提示播报设备可以根据支付异常风险信息的风险等级播报不同的异常提示信息。例如：对于支付前置页关闭、支付应用程序切换至后台、支付失败切换支付方式、在支付前置页或收银台页面停留时间大于第四指定时间的异常操作可以设置为同一个风险等级，风险等级相对较低，收款提示播报设备可以播报提示顾客“请及时支付”的语音提示信息。对于收银台页面关闭的异常操作，其风险等级比较高，收款提示播报设备可以播报“音效+顾客取消支付N元”，同时警示灯“红灯闪烁”。当然，根据实际需要，还可以采用其他的风险等级以及播报设置方式，本说明书实施例不做具体限定。

本说明书一些实施例中，所述方法还包括：

在接收到所述支付行为触发指令时，向所述收款提示播报设备发送支付提醒信息，以使得所述收款提示播报设备播报支付开始提示信息。

在具体的实施过程中，当用户刷脸或扫码等触发支付行为并向服务端发送支付行为触发指令后，服务端可以向收款提示播报设备发送支付提醒信息，以提示收款提示播报设备有一笔支付交易开始。收款提示播报设备接收到服务端发送的支付提醒信息后，可以播报支付开始提示信息，其中，支付开始提示信息可以为特定的提示音效，如：“bibi”的音效，以提示商家顾客开始支付，避免支付用户只是拿出客户端对准收款终端或收款码并没有进行实际的支付行为，商家没有及时发现，造成的逃单问题。

本说明书一些实施例中，所述方法还包括：

将支付异常风险信息和支付到账提示信息通过双通道分别发送至所述收款提示播报设备，以使得所述收款提示播报设备在同一时间接收到支付异常风险信息和支付到账提示信息后，采用支付异常提示音效和支付到账信息的混合播报方式。

在具体的实施过程中，服务端可以将支付异常风险信息和支付到账提示信息通过双通道分别发送至收款提示播报设备，改善了由于单通道下发导致的“支付到账提示信息”和“支付异常风险信息”串行播报，导致“支付异常风险信息”播报延迟，商家无法及时发现漏单交易的问题。并其，通过双通道发送支付异常风险信息和支付到账提示信息，还可以使得收款提示播报设备在同一时间接收到支付异常风险信息和支付到账提示信息后，能够采用支付异常提示音效和支付到账信息的混合播报方式。例如：若收款提示播报设备在同一时间接收到支付异常风险信息和支付到账提示信息，在进行支付信息播报时，支付异常风险信息可以仅播报“支付异常提示音效”，并且与“支付到账信息”混音播放(硬件+驱动层支持混音算法)，实现支付到账和支付异常的同时播报，提示用户在正常接收支付到账信息的同时能够及时发现支付异常行为。

图2是本说明书一些实施例中收款提示播报设备的支付数据处理方法流程示意图，该方法可以应用在收款提示播报设备如：收款播报音箱中，如图2所示，该方法可以包括：

步骤202、接收服务端在监听到支付事件存在异常操作时发送的支付异常风险信息；其中，所述支付事件为所述服务端在接收到所述支付事件的支付行为触发指令后开始对所述支付事件进行监听的。

步骤204、根据所述支付异常风险信息对应的风险等级，播报对应的支付异常提示信息，其中，所述支付异常提示信息包括：支付异常提示音效、支付异常提示语音、支付异常警示灯中的至少一种。

在具体的实施过程中，参见上述实施例的记载，服务端在接收到支付行为触发指令并对支付事件进行监听时，可以通过客户端中的支付应用程序监听支付事件中的各个支付流程，若发现支付事件存在异常操作即支付事件的某个或某几个支付流程与正常的操作流程不同，则向支付行为触发指令对应的收款提示播报设备发送支付异常风险信息。支付异常风险信息中可以包括支付异常的原因如：支付时间过长、支付页面关闭等，支付异常操作，还可以包括支付异常涉及的交易金额以及交易时间等，具体可以根据实际需要进行设置，本说明书实施例不做具体限定。支付事件中的异常操作可以包括：所述支付事件中支付前置页关闭、收银台页面关闭、支付应用程序切换至后台、支付失败切换支付方式、在支付前置页或收银台页面停留时间大于第四指定时间中的任一项。

收款提示播报设备接收到服务端发送的支付异常风险信息后，可以根据支付异常风险信息的异常原因或风险等级播报对应的支付异常提示信息。其中，不同的支付异常操作可以播报不同的支付异常提示信息。本说明书实施例中的所述支付异常提示信息可以包括：支付异常提示音效、支付异常提示语音、支付异常警示灯中的至少一种。一般的，支付异常提示音效可以选择比较引人注意的音效，支付异常提示语音一般可以包括漏单的金额，支付异常警示灯可以根据不同的异常操作行为设置为不同闪烁频率或不同颜色的警示灯，实现对用户的提醒，通过声、光以及语音播报结合的方式，实现对异常交易操作及时提醒的作用，并给逃单用户一定的心理压力，以减少逃单支付交易的数量，提高支付交易的安全性。

其中，收款提示播报设备的播报方式可以参考上述实施例的记载，此处不再赘述。

本说明书实施例，通过对支付事件进行全程监听，对于不同异常操作向收款提示播报设备发送不同的支付异常风险信息，以使得收款提示播报设备可以针对不同的异常操作播报不同的支付异常提示信息，提醒商家以及支付用户及时关注，以保障支付交易能够正常完成。

图3是本说明书一个场景示例中支付数据处理方法的原理框架示意图，下面结合图3具体介绍本说明书实施例中支付数据处理方法的过程，如图3所示，支付数据处理过程主要可以包括用户的交易行为感知、漏单风险识别以及申请补款，其中：

1、交易行为感知

a)交易行为感知：利用IoT(Internet of Things，物联网)设备独有的感知能力，支付用户在设备上产生交易行为开始，即产生了一笔交易记录。结合真实交易判定模型，对无效交易进行去重。同时，锁定支付用户的身份，用于后续联系支付用户时使用。

b)跟踪本笔交易的支付进展，更新已生成的订单的支付状态。针对未支付成功的订单，记录其最终状态，并标记失败原因。

2、漏单风险识别

a)针对支付未成功的订单，可以将交易信息实时导入“漏单风险识别模型”，进行实时风险分析。

b)结合支付用户的历史交易分析以及交易时商家繁忙度、设备网络稳定性等变量因素，由“漏单风险识别模型”产出风险等级。

3、申请补款流程

a)感知到新订单产生时，根据其风险等级，决策是否立即通知商户。

b)如风险等级很高，会采用消息推送方式+服务提醒方式，及时告知商户。

c)商户收到消息后，查看消息详情，决策是否需要申请补款。

d)确认为漏单，填写申请金额、联系方式、申请原因等信息，对该笔申诉进行风险评估。

e)风险评估通过后，结合申请时间，决策以何种方式，联系支付用户。如：触达方式可以有：智能外呼、短信、服务提醒、消息push；触达形式可以有：急速模式(丢单后30分钟内申请)、正常模式。

f)支付用户收到信息后，决策是否要补款，如有疑问，可直接联系商家。

g)支付用户完成补款后，相关数据可以作为样本导入到漏单风险识别模型进行模型优化训练，提高后续模型识别精度。

本说明书实施例中，服务端可以最为商家漏单提醒以及漏单补款的辅助，一些场景示例中，商家还可以通过投保的方式，保障漏单金额能够补回。如：商家提出申请，通过风险审核，确认为真实漏单后，服务端还可以先行赔付，再联系支付用户，如果支付用户拒绝付款，费用有承保方承担费用。

本说明书实施例基于IoT场内感知优势，将交易感知提前至从以往的技术层面的“收到支付请求，生成订单”，提前至用户行为层面的“从顾客支付开始”，完整的复原交易全过程。如果由于支付中间环节发生问题，仍然可以为商家提供资金找回服务，可以适用于刷脸后未确认支付、扫码后输入金额但未确认支付、isv(Independent Software Vendors，独立软件开发商)***故障未收款成功等应用场景。并且，利用IoT场内感知优势，结合多维度信息，综合评估交易漏单的风险，及时预警，实现了漏单支付交易的及时发现。还可以为商户提供漏单查询平台漏如：漏单查询小程序或漏单查询应用程序，商户通过扫描收款设备中的二维码，即可查看收款设备上的全量交易，针对风险交易订单会重点标明。商户找到漏单，在漏单查询小程序中申请补款，服务端会代为联系顾客，由顾客确认是否补款，如果有疑问可以主动联系商家沟通协调。实现了漏单补款的快速申请，深度解决商家“漏单、丢单”的痛点。

图3是针对已经得到支付结果及未支付成功的支付交易进行风险识别，确定是否为支付漏单，若是，及时告知商家并未商家提供补款申请方案，实现了漏单的自动识别以及漏单补款的快速申请。此外，本说明书实施例在支付用户支付的过程中，还可以对支付事件的操作过程进行实时监听，在监听到有异常操作时，及时通知收款播报设备进行异常播报，提示商家和顾客。图4是本说明书实施例中支付交易过程中的监听以及异常播报的流程示意图，如图4所示，本说明书一些场景示例中，对于支付交易的监听以及异常播报过程可以参考如下：

1、对顾客即支付用户扫码(或刷脸)后，可能发生的异常行为/逃单意向行为，进行全场景监听，及时上报。

2、异常操作消息广播：服务端结合业务方申请、审批结果，将支付操作异常的信息发送给对应的收款提示播报设备。

3、消息监听/消息过滤：只监听已经绑定了收款提示播报设备的商户的异常操作消息。

4、播报逻辑处理：消息聚合播报。针对用户反复操作或同类型的操作进行合并播报，避免打扰，如：若在很短的时间间隔内收到3笔支付到账通知，则可以将该3笔支付到账通知进行聚合播报，可以播报“已到账2元、5元、10元”。

5、个性化设置加载：商户可根据个人喜好自定义设置播报的方式，如：

a)防逃单提示：开/关

b)播报模式：极简(仅音效)/正常(音效+顾客取消支付N元)

c)异常指示灯：开(红灯闪烁)/关(无效果)。

具体的，如图4所示，针对图4中的“1、异常操作监听”环节，从用户扫码开始，对所有的支付异常行为进行监听：

1-1：顾客扫码成功，收款提示播报设备可以发出“bibi”音效，提示顾客已开始支付。针对图4中1-2、1-4、1-5、1-6场景收款提示播报设备可以播报“请及时支付”的语音以提示顾客。针对图4中1-3场景收款提示播报设备可以播报“音效+顾客取消支付N元”，同时设备指示灯“红灯闪烁”，以提示商家及时关注。图4中1-1～1-6等场景的异常提示播报主要是面向给商户和顾客的提示、引导方式，根据实际需要还可以采用其他的异常提示播报方式，本说明书实施例不做具体限定。例如：可以在异常发生时，针对提示方式做优化，如：a)利用LED灯+透明玻璃，在光源警示方面做加强，弱化声音提示的作用。b)在播报音箱基础上，增加面向商户的小屏，通过屏幕色彩+形象动销，做提示加强。

其中，收款提示播报设备的播报内容均以保护顾客隐私为大前提，播报内容，不涉及任何顾客账户、身份等信息。声光提示，主要目标在于引导商户及时关注，避免发生漏单。

本说明书实施例，从扫码开始到支付未完成，全过程感知顾客的异常交易行为，并增加了“支付开始提示音”，从顾客扫码开始，第一时间感知顾客的支付行为，解决了商户只能尴尬等待支付结果，将商户的漏单感知提前到了全过程。覆盖面广，如：可以覆盖支付应用程序切换后台、更换付款方式、手机锁屏、页面长时间停留等异常操作场景，对影响支付正常完成的异常操作进行监控(脱敏)。还可以利用数据技术，对商户现场客情进行分析，根据输出的风险等级，决策提示方式。此外，对于“支付到账音”即支付到账提示信息和“漏单提示音”即支付异常风险信息采用双通道下发+混音播放，改善了由于单通道下发导致的“支付到账音”和“漏单提示音”串行播报，导致“漏单提示音”播报延迟。面对“支付到账音”和“漏单提示音”并发场景，进行了方案优化，如：单独“漏单提示音”时，漏单提示为：“漏单音效”+“顾客取消支付X元”；并发播报时，漏单提示仅播报“漏单音效”，并且与“支付到账音”混音播放(硬件+驱动层支持混音算法)。解决了交易高峰时期，既想关注到账提示，又想关注漏单的痛点。同时，对于异常播报采用“声”+“光”结合的方式，双手段漏单预警，在给商户清洗语音提示同时，结合光电效应，加强警示作用，给予逃单人员足够的心理压力，降低了逃单的概率和数量。

本说明书中上述方法的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参考即可，每个实施例重点说明的都是与其他实施例的不同之处。相关之处参考方法实施例的部分说明即可。

基于上述所述的支付数据处理方法，本说明书一个或多个实施例还提供一种用于支付数据处理的装置。所述装置可以包括使用了本说明书实施例所述方法的装置(包括分布式***)、软件(应用)、模块、插件、服务器、客户端等并结合必要的实施硬件的装置。基于同一创新构思，本说明书实施例提供的一个或多个实施例中的装置如下面的实施例所述。由于装置解决问题的实现方案与方法相似，因此本说明书实施例具体的装置的实施可以参考前述方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

具体地，图5是本说明书提供的支付数据处理装置一个实施例的模块结构示意图，如图5所示，本说明书中提供的支付数据处理装置可以包括：

支付监听模块51，用于接收支付行为触发指令，对所述支付行为触发指令对应的支付事件进行监听；

异常信息获取模块52，用于在监听到所述支付行为触发指令对应的支付事件支付失败后，获取所述支付行为触发指令对应的支付交易信息、支付用户信息、收款客户端信息；

异常识别模块53，用于基于所述支付交易信息、所述支付用户信息以及所述收款客户端信息对所述支付行为触发指令对应的支付事件进行漏单风险识别，确定出所述支付行为触发指令对应的支付事件的风险识别结果；

风险提醒模块54，用于根据所述风险识别结果，向所述支付行为触发指令对应的收款用户发送漏单提醒信息。

本说明书实施例在支付交易订单生成之前，感知到支付行为开始时，即开始对支付事件进行监听，实现对支付事件的全程监听。能够适用于支付事件支付失败的全部场景，如：刷脸后未确认支付、扫码后输入金额但未确认支付、设备故障导致未收款成功等。在支付事件支付失败后，及时对支付事件进行漏单风险识别，并基于漏单风险识别的结果自动通知收款用户进行漏单核对，实现了支付漏单的自动识别，确保支付交易的安全性。

图6是本说明书提供的支付数据处理装置另一个实施例的模块结构示意图，该装置可以应用在上述实施例中的收款提示播报设备中，如图6所示，本说明书中提供的支付数据处理装置可以包括：

异常信息接收模块61，用于接收服务端在监听到支付事件存在异常操作时发送的支付异常风险信息；其中，所述支付事件为所述服务端在接收到所述支付事件的支付行为触发指令后开始对所述支付事件进行监听的；

异常信息播报模块62，用于根据所述支付异常风险信息对应的风险等级，播报对应的支付异常提示信息，其中，所述支付异常提示信息包括：支付异常提示音效、支付异常提示语音、支付异常警示灯中的至少一种。

本说明书实施例通过对支付事件进行全程监听，对于不同异常操作向收款提示播报设备发送不同的支付异常风险信息，以使得收款提示播报设备可以针对不同的异常操作播报不同的支付异常提示信息，提醒商家以及支付用户及时关注，以保障支付交易能够正常完成。

需要说明的，上述所述的装置根据对应方法实施例的描述还可以包括其他的实施方式。具体的实现方式可以参照上述对应的方法实施例的描述，在此不作一一赘述。

本说明书实施例还提供一种支付数据处理设备，包括：至少一个处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现上述实施例的支付数据处理方法，如：

接收支付行为触发指令，对所述支付行为触发指令对应的支付事件进行监听；

在监听到所述支付行为触发指令对应的支付事件支付失败后，获取所述支付行为触发指令对应的支付交易信息、支付用户信息、收款客户端信息；

基于所述支付交易信息、所述支付用户信息以及所述收款客户端信息对所述支付行为触发指令对应的支付事件进行漏单风险识别，确定出所述支付行为触发指令对应的支付事件的风险识别结果；

根据所述风险识别结果，向所述支付行为触发指令对应的收款用户发送漏单提醒信息。

或，接收服务端在监听到支付事件存在异常操作时发送的支付异常风险信息；其中，所述支付事件为所述服务端在接收到所述支付事件的支付行为触发指令后开始对所述支付事件进行监听的；

根据所述支付异常风险信息对应的风险等级，播报对应的支付异常提示信息，其中，所述支付异常提示信息包括：支付异常提示音效、支付异常提示语音、支付异常警示灯中的至少一种。

本说明书一些实施例中，还提供了一种支付数据处理***，所述支付数据处理***包括：支付服务端、收款提示播报设备，其中：

所述支付服务端中存储有计算机指令，所述指令被执行时实现上述实施例中服务端侧执行的方法的步骤，用于在接收到支付客户端或收款客户端上报的支付行为触发指令，对所述支付行为触发指令对应的支付事件进行监听，在监听到所述支付事件存在异常操作时，向所述支付行为触发指令对应的收款提示播报设备发送支付异常风险信息，在所述支付事件支付失败后，对所述支付事件进行漏单风险识别；

所述收款提示播报设备上存储有计算机指令，所述指令被执行时实现上述实施例中收款提示播报设备执行的方法的步骤，用于接收所述支付服务端发送的支付异常风险信息，并根据所述支付异常风险信息对应的风险等级，播报对应的支付异常提示信息。

需要说明的，上述所述的设备或***根据方法实施例的描述还可以包括其他的实施方式。具体的实现方式可以参照相关方法实施例的描述，在此不作一一赘述。

本说明书提供的支付数据处理装置、设备，也可以应用在多种数据分析处理***中。所述***或服务器或终端或设备可以为单独的服务器，也可以包括使用了本说明书的一个或多个所述方法或一个或多个实施例***或服务器或终端或设备的服务器集群、***(包括分布式***)、软件(应用)、实际操作装置、逻辑门电路装置、量子计算机等并结合必要的实施硬件的终端装置。所述核对差异数据的检测***可以包括至少一个处理器以及存储计算机可执行指令的存储器，所述处理器执行所述指令时实现上述任意一个或者多个实施例中所述方法的步骤。

本说明书实施例所提供的方法实施例可以在移动终端、计算机终端、服务器或者类似的运算装置中执行。以运行在服务器上为例，图7是本说明书一个实施例中支付数据处理服务器的硬件结构框图，该计算机终端可以是上述实施例中的支付数据处理服务器或支付数据处理装置。如图7所示服务器10可以包括一个或多个(图中仅示出一个)处理器100(处理器100可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的非易失性存储器200、以及用于通信功能的传输模块300。本领域普通技术人员可以理解，图7所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，服务器10还可包括比图7中所示更多或者更少的插件，例如还可以包括其他的处理硬件，如数据库或多级缓存、GPU，或者具有与图7所示不同的配置。

非易失性存储器200可用于存储应用软件的软件程序以及模块，如本说明书实施例中的支付数据处理方法对应的程序指令/模块，处理器100通过运行存储在非易失性存储器200内的软件程序以及模块，从而执行各种功能应用以及资源数据更新。非易失性存储器200可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，非易失性存储器200可进一步包括相对于处理器100远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输模块300用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端的通信供应商提供的无线网络。在一个实例中，传输模块300包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输模块300可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本说明书提供的上述实施例所述的方法或装置可以通过计算机程序实现业务逻辑并记录在存储介质上，所述的存储介质可以计算机读取并执行，实现本说明书实施例所描述方案的效果，如：

接收支付行为触发指令，对所述支付行为触发指令对应的支付事件进行监听；

在监听到所述支付行为触发指令对应的支付事件支付失败后，获取所述支付行为触发指令对应的支付交易信息、支付用户信息、收款客户端信息；

基于所述支付交易信息、所述支付用户信息以及所述收款客户端信息对所述支付行为触发指令对应的支付事件进行漏单风险识别，确定出所述支付行为触发指令对应的支付事件的风险识别结果；

根据所述风险识别结果，向所述支付行为触发指令对应的收款用户发送漏单提醒信息。

或，接收服务端在监听到支付事件存在异常操作时发送的支付异常风险信息；其中，所述支付事件为所述服务端在接收到所述支付事件的支付行为触发指令后开始对所述支付事件进行监听的；

根据所述支付异常风险信息对应的风险等级，播报对应的支付异常提示信息，其中，所述支付异常提示信息包括：支付异常提示音效、支付异常提示语音、支付异常警示灯中的至少一种。

所述存储介质可以包括用于存储信息的物理装置，通常是将信息数字化后再以利用电、磁或者光学等方式的媒体加以存储。所述存储介质有可以包括：利用电能方式存储信息的装置如，各式存储器，如RAM、ROM等；利用磁能方式存储信息的装置如，硬盘、软盘、磁带、磁芯存储器、磁泡存储器、U盘；利用光学方式存储信息的装置如，CD或DVD。当然，还有其他方式的可读存储介质，例如量子存储器、石墨烯存储器等等。

本说明书实施例提供的上述支付数据处理方法或装置可以在计算机中由处理器执行相应的程序指令来实现，如使用windows操作***的c++语言在PC端实现、linux***实现，或其他例如使用android、iOS***程序设计语言在智能终端实现，以及基于量子计算机的处理逻辑实现等。

本说明书实施例并不局限于必须是符合行业通信标准、标准计算机资源数据更新和数据存储规则或本说明书一个或多个实施例所描述的情况。某些行业标准或者使用自定义方式或实施例描述的实施基础上略加修改后的实施方案也可以实现上述实施例相同、等同或相近、或变形后可预料的实施效果。应用这些修改或变形后的数据获取、存储、判断、处理方式等获取的实施例，仍然可以属于本说明书实施例的可选实施方案范围之内。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字***“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

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

为了描述的方便，描述以上平台、终端时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或插件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参考即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参考方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

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

Claims (20)

1.一种支付数据处理方法，所述方法包括：

接收支付行为触发指令，对所述支付行为触发指令对应的支付事件进行监听；

在监听到所述支付行为触发指令对应的支付事件支付失败后，获取所述支付行为触发指令对应的支付交易信息、支付用户信息、收款客户端信息；

基于所述支付交易信息、所述支付用户信息以及所述收款客户端信息对所述支付行为触发指令对应的支付事件进行漏单风险识别，确定出所述支付行为触发指令对应的支付事件的风险识别结果；

根据所述风险识别结果，向所述支付行为触发指令对应的收款用户发送漏单提醒信息。

2.如权利要求1所述的方法，所述接收支付行为触发指令包括：

接收收款客户端上报的生物图像扫描信息或图形码扫描信息；

或，接收支付客户端上报的图形码扫描信息。

3.如权利要求1所述的方法，所述支付行为触发指令对应的支付事件支付失败的确定方法包括：

若接收到所述支付行为触发指令后第一指定时间内未收到支付结果，则确定所述支付行为触发指令对应的支付事件支付失败；

或，若接收到所述支付行为触发指令对应的支付事件支付失败提示信息，则确定所述支付行为触发指令对应的支付事件支付失败。

4.如权利要求1所述的方法，所述支付用户信息包括支付用户的历史交易信息，所述收款客户端信息包括收款客户端在第二指定时间内的设备网络信息以及所述收款客户端在第三指定时间内收款的数量。

5.如权利要求1所述的方法，所述方法还包括：

接收所述收款用户在接收到所述漏单提醒信息后发送的漏单申诉请求，所述漏单申诉请求中包括支付用户信息；

根据所述漏单申诉请求，向所述支付用户信息对应的支付客户端发送漏单核对信息。

6.如权利要求5所述的方法，所述方法还包括：

根据所述漏单申诉请求对所述收款用户进行风险识别，在所述收款用户风险识别通过后向所述支付用户信息对应的支付客户端发送漏单核对信息。

7.如权利要求5所述的方法，所述漏单申诉请求中包括漏单时间，所述根据所述漏单申诉请求，向所述支付用户信息对应的支付客户端发送漏单核对信息，包括：

若所述漏单时间与当前时间之间的时间差在指定漏单时间范围内，则采用外呼方式向所述支付用户信息对应的支付客户端发送漏单核对信息，否则，采用短信提醒或服务信息提醒的方式向所述支付用户信息对应的支付客户端发送漏单核对信息。

8.如权利要求1所述的方法，所述根据所述风险识别结果，向所述支付行为触发指令对应的收款用户发送漏单提醒信息包括：

若所述风险识别结果的风险等级大于预设等级，则将所述漏单提醒信息发送至所述收款用户的客户端；

若所述风险识别结果的风险等级小于或等于所述预设等级，则将所述漏单提醒信息保存至支付交易平台的漏单信息列表中，以供所述收款用户查看。

9.如权利要求1所述的方法，所述方法还包括：

根据所述风险识别结果，将各个支付事件对应的支付交易信息进行风险标记，并将标记好的支付事件的支付交易信息以及对应的收款用户存储到区块链中，以供所述收款用户通过区块链查询漏单信息。

10.如权利要求1所述的方法，所述对所述支付行为触发指令对应的支付事件进行监听，包括：

在监听到所述支付事件存在异常操作时，向所述支付行为触发指令对应的收款提示播报设备发送支付异常风险信息，以使得所述收款提示播报设备播报对应的支付异常提示信息。

11.如权利要求10所述的方法，所述支付事件中的异常操作包括：

所述支付事件中支付前置页关闭、收银台页面关闭、支付应用程序切换至后台、支付失败切换支付方式、在支付前置页或收银台页面停留时间大于第四指定时间中的任一项。

12.如权利要求10所述的方法，所述在监听到所述支付事件存在异常操作时，向所述支付行为触发指令对应的收款提示播报设备发送支付异常风险信息，包括：

预先将支付事件中不同的异常操作设置风险等级，根据监听到的所述支付事件中出现的异常操作对应的风险等级，向所述收款提示播报设备发送不同等级的支付异常风险信息，以使得所述收款提示播报设备播报对应的支付异常提示信息。

13.如权利要求10所述的方法，所述方法还包括：

在接收到所述支付行为触发指令时，向所述收款提示播报设备发送支付提醒信息，以使得所述收款提示播报设备播报支付开始提示信息。

14.如权利要求10所述的方法，所述方法还包括：

将支付异常风险信息和支付到账提示信息通过双通道分别发送至所述收款提示播报设备，以使得所述收款提示播报设备在同一时间接收到支付异常风险信息和支付到账提示信息后，采用支付异常提示音效和支付到账信息的混合播报方式。

15.如权利要求10所述的方法，所述支付异常提示信息包括：支付异常提示音效、支付异常提示语音、支付异常警示灯中的至少一种。

16.一种支付数据处理方法，所述方法包括：

接收服务端在监听到支付事件存在异常操作时发送的支付异常风险信息；其中，所述支付事件为所述服务端在接收到所述支付事件的支付行为触发指令后开始对所述支付事件进行监听的；

根据所述支付异常风险信息对应的风险等级，播报对应的支付异常提示信息，其中，所述支付异常提示信息包括：支付异常提示音效、支付异常提示语音、支付异常警示灯中的至少一种。

17.一种支付数据处理装置，所述装置包括：

支付监听模块，用于接收支付行为触发指令，对所述支付行为触发指令对应的支付事件进行监听；

异常信息获取模块，用于在监听到所述支付行为触发指令对应的支付事件支付失败后，获取所述支付行为触发指令对应的支付交易信息、支付用户信息、收款客户端信息；

异常识别模块，用于基于所述支付交易信息、所述支付用户信息以及所述收款客户端信息对所述支付行为触发指令对应的支付事件进行漏单风险识别，确定出所述支付行为触发指令对应的支付事件的风险识别结果；

风险提醒模块，用于根据所述风险识别结果，向所述支付行为触发指令对应的收款用户发送漏单提醒信息。

18.一种支付数据处理装置，所述装置包括：

异常信息接收模块，用于接收服务端在监听到支付事件存在异常操作时发送的支付异常风险信息；其中，所述支付事件为所述服务端在接收到所述支付事件的支付行为触发指令后开始对所述支付事件进行监听的；

异常信息播报模块，用于根据所述支付异常风险信息对应的风险等级，播报对应的支付异常提示信息，其中，所述支付异常提示信息包括：支付异常提示音效、支付异常提示语音、支付异常警示灯中的至少一种。

19.一种支付数据处理设备，包括：至少一个处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现权利要求1-15任一项或权利要求16所述的方法。

20.一种支付数据处理***，包括：支付服务端、收款提示播报设备，其中：

所述支付服务端中存储有计算机指令，所述指令被执行时实现权利要求1至15中任一项所述方法的步骤，用于在接收到支付客户端或收款客户端上报的支付行为触发指令，对所述支付行为触发指令对应的支付事件进行监听，在监听到所述支付事件存在异常操作时，向所述支付行为触发指令对应的收款提示播报设备发送支付异常风险信息，在所述支付事件支付失败后，对所述支付事件进行漏单风险识别；

所述收款提示播报设备上存储有计算机指令，所述指令被执行时实现权利要求16所述方法的步骤，用于接收所述支付服务端发送的支付异常风险信息，并根据所述支付异常风险信息对应的风险等级，播报对应的支付异常提示信息。

Images