CN117236962A - 一种开放式的预约电子支付系统及方法 - Google Patents

Abstract

本公开是一种开放式的预约电子支付系统及方法，该系统包括：用户终端、支付终端和发布平台。支付终端向发布平台公开自身信息并接受用户终端的预约，用户终端在发布平台上确定支付终端信息并向支付终端发起预约，支付终端接受用户终端发起的预约并将预约结果反馈至用户终端。用户以预约方式发起支付操作，支付终端将支付信息与预约信息进行匹配，并最终完成支付操作。本公开中支付终端是对外开放的而不是封闭的，避免支付终端设备无法认证和识别，支付操作过程不透明的情况，加强了支付系统的安全性。预约的支付方法为支付风控系统的分析处理预留出了时间，提高了交易实时完成的效率。

Description

一种开放式的预约电子支付系统及方法

技术领域

本公开涉及电子支付技术领域，尤其涉及一种开放式的预约电子支付方法、系统及存储介质。

背景技术

随着支付方式的不断演化，支付渠道的逐渐拓宽，新型支付方式的不断推广，扫码支付得到广泛应用。但是，在付款方在进行扫码支付时，付款方无法识别收款方的身份，从而无法确保交易行为的安全性，进而可能支付终端设备无法认证和识别，支付操作过程不透明的情况。以及，在现有的支付流程中，需要收付款方双方在有限的时间内完成支付，由此收付款双方可能无法对交易流程进行安全认证，从而使得交易可能存安全性问题，或者，付款方需要排队等待收款方结账，导致人群聚集，增加了现场交易的时间，降低了交易完成效率。

发明内容

为克服相关技术中存在的问题，本公开提供一种开放式的预约电子支付系统、方法、电子设备及计算机可读存储介质。

根据本公开实施例的第一方面，提供一种开放式的预约电子支付系统，用户终端，支付终端和发布平台，其中，

所述用户终端用于向所述支付终端发送预约信息，其中，所述用户终端基于终端信息在发布平台上确定所述支付终端，所述终端信息是所述支付终端在所述发布平台上进行注册后对外开放发布的；

所述支付终端用于接收所述用户终端发送的所述预约信息，并将所述预约信息发送至风控系统进行评估，将所述风控系统发送的预约结果反馈至所述用户终端；

所述支付终端，还用于获取触发支付操作时的支付信息，在所述支付信息与所述预约信息匹配的情况下，将所述支付信息发送至支付系统以完成支付操作。

根据本公开实施例的第二方面，提供一种开放式的预约电子支付方法，应用于支付终端，包括：

接收用户终端发送的预约信息，其中，所述用户终端基于终端信息在发布平台上确定所述支付终端，所述终端信息是所述支付终端在所述发布平台上进行注册后发布的；

将所述预约信息发送至风控系统进行评估，并将所述风控系统发送的预约结果反馈至所述用户终端；

获取触发支付操作时的支付信息，并在所述支付信息与所述预约信息匹配的情况下，将所述支付信息发送至支付系统以完成支付操作。

根据本公开实施例的第三方面，提供了一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为实现前述第一方面中所述的方法。

根据本公开实施例的第四方面，提供了一种非临时性计算机可读存储介质，所述计算机存储介质存储有计算机可执行指令；所述计算机可执行指令被处理器执行后，能够实现前述第一方面中所述的方法。

本公开的实施例提供的技术方案可以包括以下有益效果：

本公开提出的一种开放式的预约电子支付系统及方法中，该系统包括：用户终端，支付终端和发布平台，其中，用户终端用于向支付终端发送预约信息，其中，用户终端基于终端信息在发布平台上确定支付终端，终端信息是支付终端在发布平台上进行注册后发布的；支付终端用于接收用户终端发送的预约信息，并将预约信息发送至风控系统进行评估，将风控系统发送的预约结果反馈至用户终端；支付终端，还用于获取触发支付操作时的支付信息，在支付信息与预约信息匹配的情况下，将支付信息发送至支付系统以完成支付操作。由此，本公开中用户可以在发布平台上查找和确定支付终端，以使得用户终端可以识别支付终端的终端信息，从而使得支付终端是对外开放的而不是封闭的，进而避免支付终端设备无法认证和识别，支付操作过程不透明的情况。同时，用户可以主动发起预约支付流程，无需进行排队等待，且用户在进行预约和支付的过程中均对支付终端进行验证，并在验证成功的情况下与支付终端进行支付交易，从而确保了支付过程的安全性，提高了交易完成效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是根据本公开的一些实施例示出的一种开放式的预约电子支付系统的结构示意图；

图2是根据本公开的一些实施例示出的一种开放式的预约电子支付方法的流程示意图；

图3是根据本公开的一些实施例示出的一种开放式的预约电子支付方法的流程示意图。

具体实施方式

这里将详细地对本公开一些实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。本文所描述的方法、系统和/或系统的各种改变、变型及等同物将在理解本公开之后变得显而易见。例如，本文所描述的操作的顺序仅仅为示例，且并非受限于本文中所阐述的那些顺序，而是除了必须以特定顺序进行的操作之外，如在理解本公开之后变得显而易见的那样可进行改变。另外，为提升清楚性和简洁性，对本领域中已知的特征的描述可被省略。

以下本公开的一些实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的系统和方法的例子。

在一些实施例中，“A或B”等记载方式，根据情况可以包括以下技术方案：在一些实施例中A（与B无关地执行A）；在一些实施例中B（与A无关地执行B）；在一些实施例中从A和B中选择执行（A和B被选择性执行）。当有A、B、C等更多分支时也类似上述。

在一些实施例中，“响应于……”、“响应于确定……”、“在……的情况下”、“在……时”、“当……时”、“若……”、“如果……”等术语可以相互替换。

本公开实施例中的“第一”、“第二”等前缀词，仅仅为了区分不同的描述对象，不对描述对象的位置、顺序、优先级、数量或内容等构成限制，对描述对象的陈述参见权利要求或实施例中上下文的描述，不应因为使用前缀词而构成多余的限制。例如，描述对象为“字段”，则“第一字段”和“第二字段”中“字段”之前的序数词并不限制“字段”之间的位置或顺序，“第一”和“第二”并不限制其修饰的“字段”是否在同一个消息中，也不限制“第一字段”和“第二字段”的先后顺序。再如，描述对象为“等级”，则“第一等级”和“第二等级”中“等级”之前的序数词并不限制“等级”之间的优先级。再如，描述对象的数量并不受序数词的限制，可以是一个或者多个，以“第一装置”为例，其中“装置”的数量可以是一个或者多个。此外，不同前缀词修饰的对象可以相同或不同，例如，描述对象为“装置”，则“第一装置”和“第二装置”可以是相同的装置或者不同的装置，其类型可以相同或不同；再如，描述对象为“信息”，则“第一信息”和“第二信息”可以是相同的信息或者不同的信息，其内容可以相同或不同。

在一些实施例中，装置和设备可以解释为实体的、也可以解释为虚拟的，其名称不限定于实施例中所记载的名称，在一些情况下也可以被理解为 “设备（equipment）”、“设备（device）”、“电路”、“网元”、“节点”、“功能”、“单元”、“部件（section）”、“系统”、“网络”、“芯片”、“芯片系统”、“实体”、“主体”等。

在一些实施例中，“终端（terminal）”或“终端设备（terminal device）”可以被称为“用户设备（user equipment，UE）”、“用户终端（user terminal）”、“移动台（mobilestation，MS）”、“移动终端（mobile terminal，MT）”、订户站（subscriber station）、移动单元（mobile unit）、订户单元（subscriber unit）、无线单元（wireless unit）、远程单元（remote unit）、移动设备（mobile device）、无线设备（wireless device）、无线通信设备（wireless communication device）、远程设备（remote device）、移动订户站（mobilesubscriber station）、接入终端（access terminal）、移动终端（mobile terminal）、无线终端（wireless terminal）、远程终端（remote terminal）、手持设备（handset）、用户代理（user agent）、移动客户端（mobile client）、客户端（client）等。

在一些实施例中，可以在得到用户同意后获取数据、信息等。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

图1是根据本公开的一些实施例示出的一种开放式的预约电子支付系统的结构示意图，如图1所示，该系统包括：用户终端，支付终端和发布平台，其中，

用户终端用于向支付终端发送预约信息，其中，用户终端基于终端信息在发布平台上确定支付终端，终端信息是支付终端在发布平台上进行注册后对外开放发布的；

所述支付终端用于接收所述用户终端发送的所述预约信息，并将所述预约信息发送至风控系统进行评估，将所述风控系统发送的预约结果反馈至所述用户终端；

所述支付终端，还用于获取触发支付操作时的支付信息，在所述支付信息与所述预约信息匹配的情况下，将所述支付信息发送至支付系统以完成支付操作。

在本公开实施例中，上述支付终端为收款方用于进行收款的终端，如销售终端（point of sale，POS）机或者支付收款应用程序（Application，App）。以及，在本公开实施例中，收款方需要在发布平台上完成对应支付终端的注册，使得收款方对应的支付终端是对外开外的，从而使得用户可以通过发布平台识别支付终端的终端信息，进而避免支付终端设备无法认证和识别，支付操作过程不透明的情况。

具体地，在本公开实施例中，收款方终端向发布平台发送支付终端的终端信息，以完成支付终端在发布平台上的注册。其中，在本公开实施例中，上述支付终端的终端信息可以包括：包括终端类型（如POS机或者支付收款App）、支付终端标识（ID）号、商户名称、商家营业执照号、地址、商户类型。

以及，在本公开实施例中，发布平台接收到收款方终端发送的支付终端的终端信息后，可以对支付终端的终端信息进行核对，核对成功后完成该支付终端在发布平台上的注册并向收款方终端发送注册成功，同时由发布平台进行签名、加密和发布，发布信息可以包括终端信息；核对失败后，该支付终端不能在发布平台上进行注册并向收款方终端发送注册失败。

在本公开实施例中，其中，该用户终端例如可以是用户所在终端，该用户终端并不特指某一固定终端。用户可以为收款方或者付款方，以及上述用户终端可以为收款方对应的收款方终端或者付款方对应的付款方终端。其中，在本公开实施例中，用户终端可以在发布平台上确定支付终端。具体地，用户终端例如可以通过主动发现搜索或者通过当前位置区域范围在发布平台上确定支付终端。

其中，在本公开的实施例之中，支付终端是指带有预约功能和支付功能的终端。

其中，在本公开实施例中，用户终端通过主动发现搜索在发布平台上确定支付终端的方法具体可以包括：用户终端通过公开网络、地图、物流网、相关电子商务网站和其它相关网络的方式获取收款方信息，然后利用支付终端在发布平台上主动搜索和查找该支付终端，以确定该支付终端。

以及，在本公开实施例中，用户终端通过当前位置区域范围在发布平台上确定是否存在目标收款方的方法具体可以包括：用户终端在发布平台上展示出的当前位置区域范围内已注册的终端信息确定支付终端。其中，在本公开实施例中，上述当前位置区域范围可以根据需要进行设定，示例的，当前位置3公里以内的区域范围。以及，在本公开实施例中，上述通过用户的位置信息动态的确定支付终端，使得用户终端可以随时确定支付终端并对确定的支付终端进行预约，提高了支付的便利性。

进一步地，在本公开实施例中，用户终端在发布平台上确定支付终端后，在通过用户终端向该支付终端发送预约信息之前，用户终端还需要对支付终端进行验证和风险识别，以对支付终端的身份进行核查，确认支付终端的终端信息。具体地，在本公开实施例中，用户终端对支付终端进行验证和风险识别的方法具体可以包括：获取支付终端的签名信息，利用签名信息对支付终端的终端信息进行风险识别，其中，签名信息是用户终端从发布平台上获取的。

在本公开实施例中，若上述验证和风险识别成功后，用户终端可以向该支付终端发送预约信息。其中，在本公开一个实施例之中，上述预约信息可以包括但不限于：用户信息、预约支付时间、预约支付金额、预约支付渠道和预约支付验证方式。示例的，上述用户信息可以包括用户标识（Identity Document，ID）（如2000301），预设支付时间可以包括具体某个时间（如14:00），预约支付金额可以为具体支付金额（如200元），预约支付渠道可以包括具体支付渠道如银行借记卡，预约支付验证方式可以包括具体的支付验证方式（如密码），则上述预约信息可以为：用户标示ID为“2000301”的用户，在14：00通过银行卡xx，密码***，支付200元。

以及，在本公开一个实施例之中，上述预约信息可以包括但不限于：用户信息、预约支付时间段、预约支付额度区间、预约支付规范和预约支付方式中的一种或多种。

示例的，在本公开实施例中，上述用户信息可以包括用户标示ID（如2000301），预约支付时间段可以包括某个时间段（如14:00-18:00）或者某段时间（如某月的某几天），预约支付额度区间可以为支付金额的范围（如200元-1000元），预约支付规范可以包括支付的额度、收款方类型与确认方式的一种组合，例如：20元以下、交通运输、无密码支付；100元以下、公共缴费、自动扣款；500元以上、餐饮、要短信确认；1000元以上、便利店购物、需要验证码；2万元以上、商场购物、要生物特征识别，预约支付方式可以是支付渠道，例如零钱、交通卡、电子现金、银行借记卡、银行信用卡。

以及，在本公开实施例中，假设上述支付终端的商户类型为超市，则上述预约信息可以为：用户标示ID为“2000301”的用户，每天18:00-20:00，支付额度区间在100元-1000元，200元以下免密支付，200-1000之间密码支付，超过1000元脸型识别。

需要说明的是，在本公开实施例中，上述预约信息可以是通用的，也可以是对应具体支付终端的。其中，若上述预约信息是通用时，预约信息中可以包括商户类型，也即是预约信息中可以对不同类型商户设置对应的支付规范和支付方式，基于此，用户终端进行预约时不用进行具体设置；若上述预约信息是对应具体支付终端时，预约信息中可以设置应用于该支付终端的支付规范和支付方式，基于此，用户进行预约时需要进行具体设置。

以及，在本公开实施例中，用户终端可以向预设距离范围内的多个支付终端发送预约信息，也可以是对单个支付终端终端发送预约信息。

进一步地，在本公开实施例中，支付终端接收用户终端发送的预约信息后，需要基于预约信息对用户终端和收款方进行风险评估，以确定预约交易是否存在风险。其中，在本公开实施例中，支付终端获取用户终端发送的预约信息后，可以将该预约信息发送至风控系统，以便通过风控系统进行风险评估，并得到风控系统输出的预约结果。

在本公开实施例中，若支付终端接收到的预约信息是通用的，也即是上述预约信息包括不同商户类型对应的支付规范和支付方式，则支付终端可以根据终端信息的商户类型确定该用户终端适用的目标支付规范和目标支付方式，并将适用的目标支付规范和目标支付方式保存至预约信息中。

在本公开实施例中，风控系统获取支付终端发送的预约信息后，可以利用风险评估模型对预约信息进行风险评估，得到预约结果，并向支付终端发送预约结果。具体地，在本公开实施例中，风控系统可以根据发送预约请求的支付终端获取对应的终端信息，并将终端信息和预约信息输入至风险评估模型中，可以控制风险评估模型基于终端信息和预约信息，以及预约信息中用户对应的交易历史记录和终端信息中支付终端的交易历史记录进行风险评估，得到预约结果。其中，在本公开实施例中，上述预约结果可以包括用户特征码或预约失败。具体地，若风险评估模型确定用户终端与支付终端进行交易不存在风险，说明用户终端预约成功，此时预约结果包括用户特征码；若风险评估模型确定用户终端与支付终端进行交易存在风险，说明用户终端预约失败，此时预约结果包括预约失败。

示例的，在本公开实施例中，风险评估模型基于终端信息和预约信息确定用户终端与支付终端进行交易不存在风险，基于此预约结果可以为基于预约信息生成的预存用户特征码。具体地，在本公开实施例中，上述用户特征码可以包括用户特征码、用户标示ID、手机号码、用户人脸特征、用户指纹中的一种或者多种。示例的，假设上述用户特征码为用户特征码，则该用户特征码设为u1A2000301。

示例的，在本公开实施例中，风险评估模型基于终端信息和预约信息确定用户行为异常，如用户交易历史记录中无游戏充值记录，但是终端信息对应为游戏账户，此时用户终端与支付终端进行交易则存在风险，基于此预约结果为预约失败。

其中，在本公开实施例中，上述通过风控系统中的风险评估模型对预约信息进行风险评估，以确定预约交易是否存在风险，从而提前识别出潜在风险，进而可以保证后续支付过程的安全性。

以及，在本公开实施例中，支付终端接收风控系统发送的预约结果后，响应于预约结果为用户特征码时，可以将在预约信息中加入终端信息进行保存，并将预约结果反馈至用户终端。其中，在本公开实施例中，响应于预约结果为用户特征码时，说明用户终端可以基于预约信息中的约定方式向支付终端进行支付。基于此，当用户需要向支付终端进行支付时，可以通过用户终端或支付终端触发支付的操作。具体地，在本公开实施例中，上述用户终端还用于，响应于用户终端上的第一触发支付操作，将第一触发支付操作对应的支付信息发送至支付终端，以及，在本公开实施例中，上述支付终端还用于，响应于支付终端上的第二触发支付操作，获取第二触发支付操作对应的支付信息。

其中，在本公开的一个实施例之中，第一触发支付操作和第二触发支付操例如可以是用于区分在不同终端上进行的触发支付操作。其中，第一触发操作和第二触发操作对应的具体操作本公开实施例并不作限定。例如，第一触发操作可以是语音触发操作，第一触发操作例如还可以是点击触发操作。

其中，在本公开实施例中，上述用户终端检测到用户触发支付的操作后，需要基于支付终端的终端信息与预约信息进行验证和风险识别，以防止收款方随意更改终端信息。

具体地，在本公开实施例中，用户终端基于支付终端的终端信息与预约信息进行验证和风险识别的方法可以包括：用户终端基于支付终端的终端信息向支付终端查询用户终端对应的预约信息，若查询结果中包括预约信息，说明终端信息与预约信息中的信息一致，则验证和风险识别成功；若查询结果中不包括预约信息或查询结果为查询失败，说明终端信息与预约信息中的信息不一致，也即是，当前支付终端的终端信息可能存在更改，则验证和风险识别失败，此时用户与终端设备无法进行预约支付。

进一步地，在本公开实施例中，当验证和风险识别成功后，用户终端可以基于预约信息生成支付信息，并向支付终端发送支付信息，以进行支付交易。其中，在本公开一个实施例中，上述支付信息可以包括用户特征码。以及，在本公开的另一个实施例中，上述预约信息包括用户信息、预约支付时间段、预约支付额度区间、预约支付规范和预约支付方式中的一种或者多种，上述支付信息可以包括用户特征码和支付参数，其中支付参数可以包括支付时间、支付金额、支付渠道和支付验证方式中的一种或者多种。

在本公开实施例中，上述支付终端获取支付信息后，需要将支付信息与预约信息进行匹配，以确定该支付信息是否符合预约信息，从而确定是否完成支付交易。其中，不同的支付信息对应的匹配方法也有所不同。

具体地，在本公开实施例中，上述支付信息中包括用户特征码时，在支付信息与预约信息匹配的情况下，将支付信息发送至支付系统以完成支付操作之前，还包括：若确定用户特征码和基于预约信息生成的预存用户特征码匹配，则确定支付信息与预约信息匹配。具体例如可以是：基于预设信息生成预存用户特征码。在获取到基于预设信息生成的预存用户特征码时，可以确定用户特征码和基于预约信息生成的预存用户特征码是否匹配；若匹配，则确定支付信息与预约信息匹配；否则，支付信息与预约信息不匹配。

以及，在本公开实施例中，上述支付信息中包括用户特征码和支付参数时，则上述将支付信息与预约信息进行匹配的方法具体可以包括：若用户特征码和基于预约信息生成的预存用户特征码匹配，则确定支付参数和预约信息中的支付参数是否匹配；若支付参数和预约信息中的支付参数匹配，则确定支付信息与预约信息匹配。具体例如可以是：确定用户特征码和基于预约信息生成的预存用户特征码是否匹配；若用户特征码和基于预约信息生成的预存用户特征码匹配，则进一步确定支付参数和预约信息中的支付参数是否匹配；若支付参数和预约信息中的支付参数匹配，则确定支付信息与预约信息匹配；否则，支付信息与预约信息不匹配。

示例1，在本公开实施例中，假设预约信息中支付额度区间为（200，500），支付信息中的支付金额为800，此时支付金额不在支付额度区间内，基于此，确定支付参数和预约信息中的支付参数不匹配。

示例2，在本公开实施例中，假设预约信息中预约支付时间段为（18:00，20:00），支付信息中的支付时间为19:30，此时支付时间在预约支付时间段内，且其它支付参数均符合，基于此，确定支付信息与预约信息匹配。

以及，在本公开实施例中，在上述确定支付信息与预约信息匹配之后，方法还包括：若支付参数不满足支付条件，则支付终端获取所输入的附加支付参数，并基于附加支付参数对支付参数进行补充以补充后的支付信息满足支付条件。具体例如可以是：支付终端还需要确定支付信息中的支付参数是否满足支付条件，以确定是否接收用户输入的附加支付参数。具体地，在本公开实施例中，在上述确定支付信息与预约信息匹配之后，上述支付终端还用于确定支付参数是否满足支付条件；若支付参数不满足支付条件，则接收用户输入的附加支付参数，并基于附加支付参数对支付参数进行补充。

示例3，在本公开实施例中，支付信息与预约信息匹配之后，假设支付参数中没有设置支付方式，此时支付参数不满足支付条件，基于此支付终端还需要接收用户输入的附加支付参数（例如电子现金），并将附加支付参数对支付参数进行补充，利用补充之后的支付参数完成后续支付操作。

示例4，在本公开实施例中，支付信息与预约信息匹配之后，假设支付验证方式中包括密码或其他验证码，支付参数中没有对应的密码或其他验证码，此时支付参数不满足支付条件，基于此支付终端还需要接收用户输入的附加支付参数（密码或其他验证码），并将附加支付参数对支付参数进行补充，利用补充之后的支付参数完成后续支付操作。

进一步地，在本公开实施例中，在支付信息与预约信息匹配时，支付终端可以将支付参数对应的支付金额、支付渠道和支付验证方式发送至支付渠道对应的支付系统完成支付操作。

进一步地，在本公开实施例中，上述支付终端向支付系统发送支付信息后，支付系统可以对支付信息进行核对和验证，验证通过后支付系统基于支付验证方式从支付渠道中扣除支付金额，并向支付终端和用户终端发送支付回执信息，以完成支付操作。

其中，在本公开实施例中，上述方法通过提前预约的方式，使得支付信息可以被预先处理，从而有充足的时间对支付过程中的风险进行识别行为分析，使得可以对预约方的身份和支付信息进行核验和分析。缓解了系统需要在短时间内处理临时形成的支付信息的压力，提高了支付过程安全性。

以及，在本公开实施例中，在支付终端完成支付操作后，支付终端可以将支付信息对应的用户特征码和支付参数或用户特征码发送至风控系统，以丰富风控系统中的历史数据，从而使得风险评估模型可以不断地进行学习，进而使得风险评估模型可以学习到用户的行为（如付款方付过的最大笔的交易，付款方是否有游戏消费习惯，收款方的最大笔交易和频率），以使得通过风险评估模型得到的预约结果更加准确，降低用户进行交易的风险。

需要说明的是，在本公开实施例中，若支付信息与预约信息不匹配时，则收款方与付款方不能进行支付交易，基于此，支付终端可以向用户终端发送的支付失败信息和失败原因。

在本公开一个或多个实施例中，开放式的预约电子支付系统包括：用户终端，支付终端和发布平台，其中，用户终端用于向支付终端发送预约信息，其中，用户终端基于终端信息在发布平台上确定支付终端，终端信息是支付终端在发布平台上进行注册后发布的；支付终端用于接收用户终端发送的预约信息，并将预约信息发送至风控系统进行评估，将风控系统发送的预约结果反馈至用户终端；支付终端，还用于获取触发支付操作时的支付信息，在支付信息与预约信息匹配的情况下，将支付信息发送至支付系统以完成支付操作。由此，本公开中可以在发布平台上查找和确定支付终端，可以识别支付终端的终端信息，从而使得支付终端是对外开放的而不是封闭的，进而避免支付终端设备无法认证和识别，支付操作过程不透明的情况。同时，通过主动发起预约支付流程，无需进行排队等待，且在进行预约和支付的过程中均对支付终端进行验证，并在验证成功的情况下与支付终端进行支付交易，从而确保了支付过程的安全性，提高了交易完成效率。

图2是根据本公开的一些实施例示出的一种开放式的预约电子支付方法的流程图，应用于支付终端，如图2所示，该方法可以包括以下步骤：

在步骤201中，接收用户终端发送的预约信息，其中，用户终端基于终端信息在发布平台上确定支付终端，终端信息是支付终端在发布平台上进行注册后发布的；

在步骤202中，将预约信息发送至风控系统进行评估，并将风控系统发送的预约结果反馈至用户终端；

在步骤203中，获取触发支付操作时的支付信息，并在支付信息与预约信息匹配的情况下，将支付信息发送至支付系统以完成支付操作。

在本公开一个实施例中，上述支付信息包括用户特征码；在支付信息与预约信息匹配的情况下，将支付信息发送至支付系统以完成支付操作之前，还包括：

若确定用户特征码和基于预约信息生成的预存用户特征码匹配，则确定支付信息与预约信息匹配。

在本公开另一个实施例中，上述预约信息包括用户信息、预约支付时间段、预约支付额度区间、预约支付规范和支付方式中的一种或者多种；支付信息包括：用户特征码和支付参数；上述将支付信息与预约信息进行匹配的方法可以包括：若用户特征码和基于预约信息生成的预存用户特征码匹配，则确定支付参数和预约信息中的支付参数是否匹配；若支付参数和预约信息中的支付参数匹配，则确定支付信息与预约信息匹配；否则，支付信息与预约信息不匹配。

在本公开一个实施例中，上述用户特征码可以包括用户特征码、用户标示ID、手机号码、用户人脸特征、用户指纹中的一种或者多种。

在本公开一个实施例中，在接收用户终端发送的预约信息之前，上述方法还包括：

通过支付终端的签名信息接受用户对支付终端的终端信息进行验证和风险识别，其中，签名信息是用户从发布平台上获取的。

在本公开一个实施例中，该方法还包括：将支付信息发送至风控系统。

关于本公开实施例中的其他内容的相关介绍可以参考上述实施例中的详细介绍，本公开实施例在此不做赘述。

在本公开一个或多个实施例中，接收用户终端发送的预约信息，其中，用户终端基于终端信息在发布平台上确定支付终端，终端信息是支付终端在发布平台上进行注册后发布的；将预约信息发送至风控系统进行评估，并将预约结果反馈至用户终端；接收用户触发支付操作时发送的支付信息，将支付信息与预约信息进行匹配；若支付信息与预约信息匹配，将支付信息发送至支付系统以完成支付操作。由此，本公开中付款方可以在发布平台上查找和确定目标收款方，以使得付款方可以识别收款方的用户信息，从而使得收款方是对外开放的而不是封闭的，进而避免支付终端设备无法认证和识别，支付操作过程不透明的情况。同时，付款方可以主动发起支付流程，无需进行排队等待，且付款方在进行预约和支付的过程中均对收款方进行验证，并在验证成功的情况下与收款方进行支付交易，从而确保了支付过程的安全性，提高了交易完成效率。

图3是根据本公开的一些实施例示出的一种开放式的预约电子支付方法的流程图，应用于支付终端，如图3所示，该方法可以包括以下步骤：

在步骤301中，接收用户终端发送的预约信息，其中，用户终端基于终端信息在发布平台上确定支付终端，终端信息是支付终端在发布平台上进行注册后发布的；

在步骤302中，将预约信息发送至风控系统进行评估，并将风控系统发送的预约结果反馈至用户终端；

在步骤303中，接收用户触发支付操作时发送的支付信息，将支付信息与预约信息进行匹配，其中支付信息中包括支付参数；

在步骤304中，若支付信息与预约信息匹配，且支付参数不满足支付条件，则获取所输入的附加支付参数，并基于附加支付参数对支付参数进行补充以补充后的支付信息满足支付条件；

在步骤305中，将补充后的支付信息发送至支付系统以完成支付操作；

在步骤306中，将补充后的支付信息发送至风控系统。

关于步骤301～步骤306的相关介绍可以参考上述实施例中的详细介绍，本公开实施例在此不做赘述。

在本公开一个或多个实施例中，接收用户终端发送的预约信息，其中，用户终端基于终端信息在发布平台上确定支付终端，终端信息是支付终端在发布平台上进行注册后发布的；将预约信息发送至风控系统进行评估，并将风控系统发送的预约结果反馈至用户终端；获取触发支付操作时的支付信息，并在支付信息与预约信息匹配的情况下，将支付信息发送至支付系统以完成支付操作。由此，本公开中付款方可以在发布平台上查找和确定目标收款方，以使得付款方可以识别收款方的用户信息，从而使得收款方是对外开放的而不是封闭的，进而避免支付终端设备无法认证和识别，支付操作过程不透明的情况。同时，付款方可以主动发起支付流程，无需进行排队等待，且付款方在进行预约和支付的过程中均对收款方进行验证，并在验证成功的情况下与收款方进行支付交易，从而确保了支付过程的安全性，提高了交易完成效率。

为了实现上述实施例，本公开还提出一种计算机存储介质。

本公开实施例提供的计算机存储介质，存储有可执行程序；所述可执行程序被处理器执行后，能够实现如图2至图3任一所示的方法。

为了实现上述实施例，本公开还提出一种计算机设备。

本公开实施例提供的计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序；所述处理器执行所述程序时，能够实现如图2至图3任一所示的方法。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、 “示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (15)

1.一种开放式的预约电子支付系统，其特征在于，包括：用户终端，支付终端和发布平台，其中，

所述用户终端用于向所述支付终端发送预约信息，其中，所述用户终端基于终端信息在发布平台上确定所述支付终端，所述终端信息是所述支付终端在所述发布平台上进行注册后对外开放发布的；

所述支付终端用于接收所述用户终端发送的所述预约信息，并将所述预约信息发送至风控系统进行评估，将所述风控系统发送的预约结果反馈至所述用户终端；

所述支付终端，还用于获取触发支付操作时的支付信息，在所述支付信息与所述预约信息匹配的情况下，将所述支付信息发送至支付系统以完成支付操作。

2.如权利要求1所述的系统，其特征在于，所述用户终端还用于，响应于所述用户终端上的第一触发支付操作，将所述第一触发支付操作对应的支付信息发送至所述支付终端；或者，

所述支付终端还用于，响应于所述支付终端上的第二触发支付操作，获取所述第二触发支付操作对应的支付信息。

3.如权利要求2所述的系统，其特征在于，所述用户终端将所述第一触发支付操作对应的支付信息发送至所述支付终端之前，所述用户终端还用于：

采用所述支付终端的终端信息与所述预约信息进行验证和风险识别。

4.如权利要求1所述的系统，其特征在于，所述用户终端向所述支付终端发送预约信息之前，所述用户终端还用于：

获取所述支付终端的签名信息，其中，所述签名信息是所述用户终端从所述发布平台上获取的；

利用所述签名信息对所述支付终端的终端信息进行验证和风险识别。

5.如权利要求1所述的系统，其特征在于，所述支付终端还用于：

将所述支付信息发送至所述风控系统。

6.如权利要求1所述的系统，其特征在于，所述系统还包括风控系统，所述风控系统用于：

获取所述支付终端发送的预约信息；

利用风险评估模型对所述预约信息进行风险评估，得到预约结果；

向所述支付终端发送所述预约结果。

7.一种开放式的预约电子支付方法，其特征在于，应用于支付终端，包括：

接收用户终端发送的预约信息，其中，所述用户终端基于终端信息在发布平台上确定所述支付终端，所述终端信息是所述支付终端在所述发布平台上进行注册后发布的；

将所述预约信息发送至风控系统进行评估，并将所述风控系统发送的预约结果反馈至所述用户终端；

获取触发支付操作时的支付信息，并在所述支付信息与所述预约信息匹配的情况下，将所述支付信息发送至支付系统以完成支付操作。

8.如权利要求7所述的方法，其特征在于，所述支付信息包括用户特征码；所述在所述支付信息与所述预约信息匹配的情况下，将所述支付信息发送至支付系统以完成支付操作之前，还包括：

若确定所述用户特征码和基于所述预约信息生成的预存用户特征码匹配，则确定所述支付信息与所述预约信息匹配。

9.如权利要求7所述的方法，其特征在于，所述支付信息包括：用户特征码和支付参数；所述将所述支付信息与所述预约信息进行匹配，包括：

若所述用户特征码和基于所述预约信息生成的预存用户特征码匹配，则确定所述支付参数和所述预约信息中的支付参数是否匹配；

若所述支付参数和所述预约信息中的支付参数匹配，则确定所述支付信息与所述预约信息匹配。

10.如权利要求9所述的方法，其特征在于，在所述确定所述支付信息与所述预约信息匹配之后，还包括：

若所述支付参数不满足所述支付条件，则获取所输入的附加支付参数，并基于所述附加支付参数对所述支付参数进行补充以补充后的支付信息满足所述支付条件。

11.如权利要求9或10所述的方法，其特征在于，所述用户特征码包括用户特征码、用户标示ID、手机号码、用户人脸特征、用户指纹中的一种或者多种。

12.如权利要求7所述的方法，其特征在于，所述方法还包括：

将所述支付信息发送至所述风控系统。

13.如权利要求7所述的方法，其特征在于，在所述接收用户终端发送的预约信息之前，所述方法还包括：

通过所述支付终端的签名信息对所述支付终端的终端信息进行验证和风险识别，其中，所述签名信息是所述用户终端从所述发布平台上获取的。

14.一种电子设备，其特征在于，包括:

至少一个处理器；以及

与所述至少一个处理器的通信连接的存储器，其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求7-13中任一项所述的方法。

15.一种非临时性计算机可读存储介质，所述计算机存储介质存储有计算机可执行指令；所述计算机可执行指令被处理器执行后，能够实现权利要求7-13中任一项所述的方法。