支付校验方法、收银台系统、设备和存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种支付校验方法、收银台系统、设备和存储介质。

背景技术

随着人工智能等科技的发展，日常生活慢慢依托于科技，如通过购物类的系统或平台或应用程序进行各种类型的交易，且交易以及交易过程中的支付环节均在线上直接完成，大大方便了人们的生活。

但目前对于交易支付的安全性不能保证，进而，在系统开发过程中，往往加入支付校验流程。但现有的支付校验流程将支付业务与校验流程绑定在一起，在支付的同时进行安全校验，一旦在支付环节出现问题，容易影响后续的校验流程的正常进行，从而降低了支付以及校验的效率。因此，如何提高支付以及校验的效率是个亟需解决的问题。

发明内容

有鉴于此，为了解决现有技术的问题，本申请提供了一种可应用于如金融科技等领域或其他领域的支付校验方法、收银台系统、设备和存储介质。

第一方面，本申请提供一种支付校验方法，应用于收银台系统，所述支付校验方法包括：

接收来自用户端的预下单信息，基于所述预下单信息生成预支付订单和预付单号；

根据所述预付单号和所述预支付订单，生成场景码；

向所述用户端发送所述预付单号和所述预支付订单，并接收来自所述用户端的支付信息；

根据所述支付信息中的预付单号，查询对应的场景码，并基于所述场景码对所述支付信息进行校验。

在可选的实施方式中，所述基于所述场景码对所述支付信息进行校验，包括：

识别所述场景码的类型，确定所述场景码对应的安全等级，不同类型的场景码对应不同的安全等级；

根据所述安全等级，触发对所述支付信息进行相应类型的校验流程；一个所述安全等级对应一种类型的校验流程；所述校验流程的类型包括密码校验流程、一次性口令校验流程、软令牌认证校验流程。

在可选的实施方式中，所述方法还包括：

若所述支付信息校验通过，则向所述用户端发送支付成功消息，并触发支付资金冻结流程，在成功完成支付资金冻结流程后，修改所述预支付订单的状态为支付成功；

若所述支付信息校验未通过，则向所述用户端发送支付未成功消息，并修改所述预支付订单的状态为支付失败。

在可选的实施方式中，在所述接收来自用户端的预下单信息之前，还包括：

接收来自用户端的用户注册信息，所述用户注册信息包括用户账号；

根据所述用户注册信息，为所述用户账号分配交易权限，所述交易权限包括交易资格、交易类型、交易数目和交易额度。

在可选的实施方式中，所述基于所述预下单信息生成预支付订单和预付单号，包括：

对所述预下单信息对应的用户账户进行交易校验；所述交易校验包括交易类型校验、交易数目校验、交易额度校验；

若通过交易校验，则创建渠道订单；根据所述渠道订单，计算所述预下单信息对应的预下单产品的产品额度以及交易金额；根据所述产品额度和所述交易金额，生成预支付订单及预付单号；

若未通过交易校验，则向所述用户端发送交易校验失败信息。

在可选的实施方式中，在所述基于所述预下单信息生成预支付订单和预付单号之前，还包括：

对所述预下单信息的用户账户进行交易资格校验，所述交易资格校验包括预下单产品校验和用户校验；

若通过交易资格校验，则触发生成预支付订单和预付单号；

若未通过交易资格校验，则向所述用户端发送交易资格校验失败信息。

在可选的实施方式中，所述方法还包括：

实时监控所述支付信息的校验时长，在所述校验时长大于预定校验时长阈值时，向所述用户端发送支付失败信息。

第二方面，本申请提供一种收银台系统，包括：

接收模块，用于接收来自用户端的预下单信息，基于所述预下单信息生成预支付订单和预付单号；

生成模块，用于根据所述预付单号和所述预支付订单，生成场景码；

支付模块，用于向所述用户端发送所述预付单号和所述预支付订单，并接收来自所述用户端的支付信息；

校验模块，用于根据所述支付信息中的预付单号，查询对应的场景码，并基于所述场景码对所述支付信息进行校验。

第三方面，本申请提供一种计算机设备，所述计算机设备包括存储器和至少一个处理器，所述存储器存储有计算机程序，所述处理器用于执行所述计算机程序以实施前述的支付校验方法。

第四方面，本申请提供一种计算机存储介质，其存储有计算机程序，所述计算机程序被执行时，实施根据前述的支付校验方法。

本申请实施例具有如下有益效果：

本申请实施例提供了一种支付校验方法，用于收银台系统，该方法包括：接收来自用户端的预下单信息，基于预下单信息生成预支付订单和预付单号；根据预付单号和预支付订单，生成场景码；向用户端发送预付单号和预支付订单，并接收来自用户端的支付信息；根据支付信息中的预付单号，查询对应的场景码，并基于场景码对支付信息进行校验。本申请实施例实现了交易过程中的支付校验，提高了支付的安全性，且基于预下单信息生成预支付订单进而生成场景码，从而后续可基于场景码对支付信息进行校验，以将校验流程与支付业务区分开，降低支付与校验的耦合度，提高支付以及校验的效率，进而提高支付校验的可靠性。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对本申请保护范围的限定。在各个附图中，类似的构成部分采用类似的编号。

图1示出了本申请实施例中支付校验方法的第一个实施方式示意图；

图2示出了本申请实施例中支付校验方法的第二个实施方式示意图；

图3示出了本申请实施例中支付校验方法的第三个实施方式示意图；

图4示出了本申请实施例中支付校验方法的第四个实施方式示意图；

图5示出了本申请实施例中支付校验方法的第五个实施方式示意图；

图6示出了本申请实施例中支付校验方法的第六个实施方式示意图；

图7示出了本申请实施例中收银台系统的结构示意图。

具体实施方式

下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。

通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

在下文中，可在本申请的各种实施例中使用的术语“包括”、“具有”及其同源词仅意在表示特定特征、数字、步骤、操作、元件、组件或前述项的组合，并且不应被理解为首先排除一个或更多个其它特征、数字、步骤、操作、元件、组件或前述项的组合的存在或增加一个或更多个特征、数字、步骤、操作、元件、组件或前述项的组合的可能性。

此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

除非另有限定，否则在这里使用的所有术语(包括技术术语和科学术语)具有与本申请的各种实施例所属领域普通技术人员通常理解的含义相同的含义。术语(诸如在一般使用的词典中限定的术语)将被解释为具有与在相关技术领域中的语境含义相同的含义并且将不被解释为具有理想化的含义或过于正式的含义，除非在本申请的各种实施例中被清楚地限定。

实施例1

请参照图1，本申请实施例提供了一种支付校验方法，应用于收银台系统，下面对该方法进行详细说明。

S10，接收来自用户端的预下单信息，基于预下单信息生成预支付订单和预付单号。

本实施例中，收银台系统为一个独立的组件，可以同时对接多个跨境业务或其他业务，如转账汇款、货币兑换、基金购买/赎回等。

当用户通过用户端接入收银台系统后，进入预下单产品对应的下单页面，并从收银台系统获取可选卡列表，填入金额、币种等信息，从而对应生成预下单信息，用户端将所生成的预下单信息发送至收银台系统；收银台系统在接收到来自用户端的预下单信息后，基于该预下单信息对应生成该用户端对应的预支付订单以及该预支付订单的预付单号。

在一实施方式中，如图2所示，在步骤S10之前，本实施例还具体包括如下步骤：

S51，接收来自用户端的用户注册信息，用户注册信息包括用户账号。

S52，根据用户注册信息，为用户账号分配交易权限，交易权限包括交易资格、交易类型、交易数目和交易额度。

可选的，用户端如果需要使用支付功能，需要预先在收银台系统中注册，从而实现支付业务的统一管理。收银台系统接收来自用户端的用户注册信息，该用户注册信息包括但不限于用户账户、用户的基本身份信息等，而后根据用户注册信息为对应的用户账号分配交易权限，该交易权限包括该用户账号可进行交易的交易资格、交易类型、交易数目和交易额度等，不同的用户账号对应不同的交易权限，其交易权限的具体分配可基于用户注册信息的完整性等进行分配，或是基于其他分配规则进行交易权限的分配，本实施例对此不做限定。其中，该收银台系统可进行多种产品的交易，该产品类型包括如金融产品等无形的产品以及如生活产品等有形的产品，如基金、股票等；进而该交易资格即是为该用户账号分配可进行交易的产品类型；该交易类型包括但不限于即期交易、远期交易、掉期交易和择期交易等；交易数目即是该用户账号当前可进行交易的数量；交易额度即是用户账号可进行交易的金额额度。

进一步地，(1)即期交易。又称“现汇交易”，一般是指须在当日结清的交易。一些地区的银行间的即期交易，多在第二个营业日结算。另一些地区的即期交易通常是在交易后的两个营业日以内结算。(2)远期交易。又称“期汇交易”，是指在买卖契约成立时买卖双方不需立即支付本国货币或，而是预先约定在将来某特定日期进行结算的交易。一般情况下，大额的买卖多以远期交易方式进行。期汇交易的主要功能有套期保值和投机。套期保值是指卖出或买入金额相等于一笔外币资产或负债的，使这笔外币资产或负债以本币表示的价值避免遭受汇率变动的影响；而投机则是指根据对汇率变动的预期，有意持有的多头或空头，期望利用汇率变动来从中赚取利润。(3)掉期交易。是指在买进某种的同时卖出金额相同的该种货币，但买进和卖出的交割日期不同的交易。一般有以下几种形式：①即期对远期。即买进或卖出一笔现汇的同时，卖出或买进一笔期汇。这是掉期交易最常见的形式。比如，某银行手头的资金暂时多余，但将来又有支付需要，就可用即期交易方式把暂时多余的资金卖给其他银行，同时又以远期方式将其买回。②远期对远期。即在买进或卖出某货币较短的远期的同时，卖出或买进该货币较长的远期。好处是可以利用有利的汇率机会。③明日对次日。即成交后第二个营业日(明日)交割，第三个营业日(次日)再作反向交割。常用于银行同业的隔夜资金拆借。(4)择期交易。择期的含义是买方可以在将来的某一段时间(通常是一个半月内)的任何一天按约定的汇率进行交割，因此，择期买卖是一种交割日期不固定的买卖，属于远期买卖的范畴。择期交易的优点是：为企业、进口商提供买卖的灵活性，保证货到付款或单到付款时，能及时付汇，可以避免远期买卖交割日期确定不变的缺点。缺点是：由于银行通常是按可交割的最后一天计算贴水，择期越长，客户损失就越多，客户要取得择期便利，就要以多损失一些贴水为代价。

在一实施方式中，如图3所示，本实施例在步骤S10中“基于预下单信息生成预支付订单和预付单号”之前，还具体包括如下步骤：

S61，对预下单信息的用户账号进行交易资格校验，交易资格校验包括预下单产品校验和用户校验。

S62，若通过交易资格校验，则触发生成预支付订单和预付单号。

S63，若未通过交易资格校验，则向用户端发送交易资格校验失败信息。

在本实施例中，收银台系统同时具有前端和后台的服务，前端作为JS SDK独立发布，同时支持UMD和ESM两种引用模式，后端通过Restful API插件提供生成预支付订单、获取卡列表、交易密码加解签等功能。

进而，当收银台系统接收到来自用户端的预下单信息后，对该预下单信息对应的用户账号进行交易资格校验，以判断该用户账号是否具备相应的交易资格。其中，该交易资格校验包括预下单产品校验以及用户校验。预下单产品校验即是确定该用户账号是否具备下单该交易产品的交易权限。用户校验即是校验该用户账号是否合法，即该用户账号对应的基本身份信息是否与用户注册信息一致。

也即是，获取预下单信息对应的用户注册信息，通过该用户注册信息中所分配的交易权限判断该用户账号是否具备下单该产品的交易资格，即判断用户账号是否被分配有下单该产品类型的交易资格；通过该用户注册信息判断该用户账号对应的用户身份是否合法，即判断该用户账户的基本身份信息是否与用户注册信息中的基本身份信息一致。若预下单产品校验以及用户校验均通过，则确定通过交易资格校验，触发生成预支付订单和预付单号，即触发收银台后端基于该预下单信息，锁定预下单信息对应的相应数量的产品，生成预支付订单和预付单号。若预下单产品校验和用户校验中的任一项未通过，则确定未通过该交易资格校验，向用户发送交易资格校验失败信息，从而对应删除该预下单信息。

在一实施方式中，如图4所示，步骤S10中“基于预下单信息生成预支付订单和预付单号”具体包括如下步骤：

S11，对预下单信息对应的用户账号进行交易校验；交易校验包括交易类型校验、交易数目校验、交易额度校验。

S12，若通过交易校验，则创建渠道订单；根据渠道订单，计算预下单信息对应的预下单产品的产品额度以及交易金额；根据产品额度和交易金额，生成预支付订单及预付单号。

S13，若未通过交易校验，则向用户端发送交易校验失败信息。

在触发生成预支付订单和预付单号之前，还需要对预下单信息对应的用户账号进行交易校验，该交易校验包括交易类型校验、交易数目校验和交易额度校验。也即是，对该用户账号预下单的产品的数量以及下单时所采用的交易类型以及交易额度进行校验。

具体地，获取预下单信息及其对应的用户注册信息，通过该预下单信息及注册信息，判断该用户账号的预下单信息中的交易类型、交易数目和交易额度是否符合用户注册信息中所分配交易权限的交易类型、交易数目和交易额度，即判断该用户账号对应的预下单信息中交易类型是否属于用户注册信息中所分配交易权限的交易类型；预下单信息中交易数目和交易额度是否未超出用户注册信息中所分配交易权限的交易数目和交易额度。

若交易类型校验、交易数目校验和交易额度校验均通过，则确定该用户账号通过交易校验，从而根据该预下单信息创建渠道订单；并根据渠道订单，计算预下单信息对应的预下单产品的产品额度以及交易金额；根据产品额度和交易金额，生成预支付订单及预付单号。其中，产品额度即是预下单该产品的数量，交易金额即是预下单该相应数量的产品所需支付的金额；预支付订单包括产品类型、产品额度以及交易金额。而若交易类型校验、交易数目校验和交易额度校验中的任一项未通过，则确定未通过交易校验，从而向该用户账号对应的用户端发送交易校验失败信息，以取消该预下单信息。

S20，根据预付单号和预支付订单，生成场景码。

收银台系统规定不同业务通过场景码(sceneNo)作为区分，不同的场景码对应不同的安全验证；从而方便后续通过场景码调取对应的后台服务，唤起对应的安全验证流程，并提供对应的功能。不同的产品类型、交易金额、交易类型对应不同的场景码，进而该场景码对应不同的交易安全等级，每个交易安全等级对应一个安全校验流程。也即是，为各个产品类型或交易金额或交易类型等匹配一个场景码，收银台根据该场景码触发对应的安全校验流程，具体的对应关系和匹配规则在此不做限定。

收银台系统在生成相应的预付单号和预支付订单后，根据该预付单号和预支付订单，生成与该预下单信息对应的场景码，收银台系统后续可根据和预付单号或预支付订单，查询对应的场景码并触发与该场景码对应的安全验证流程。该场景码可以为二维码、一组数字字符串等，本实施例在此对其场景码的形式不做限定。

S30，向用户端发送预付单号和预支付订单，并接收来自用户端的支付信息。

向用户端发送所生成的预付单号和预支付订单，用户可在用户端根据该预支付订单和预付单号进行交易确认和支付，收银台系统进而接收来自用户端的支付信息。

S40，根据支付信息中的预付单号，查询对应的场景码，并基于场景码对支付信息进行校验。

收银台系统根据该支付信息中的预付单号，查询与该预付单号对应的场景码，从而根据与该场景码对应的安全校验流程，对该支付信息进行校验，即向用户端发起对应的支付校验流程。

在一实施方式中，如图5所示，步骤S40具体包括如下步骤：

S41，识别场景码的类型，确定场景码对应的安全等级，不同类型的场景码对应不同的安全等级。

识别场景码的类型，从而根据该场景码的类型，确定对应的安全等级，即每个类型的场景码对应一个安全等级，从而可根据支付信息对应的场景码的类型对应确定安全等级。其中，该安全等级可分为安全性高、中、低三个等级或其他多个等级，具体在此不做限定。

S42，根据安全等级，触发对支付信息进行相应类型的校验流程；一个安全等级对应一种类型的校验流程；校验流程的类型包括密码校验流程、一次性口令校验流程、软令牌认证校验流程。

根据该安全等级，触发收银台系统进行相应类型的校验流程，即发起对用户端的用户账号所发送的支付信息的安全校验流程，一个安全等级对应一种类型的校验流程，该校验流程的类型包括但不限于密码校验流程、一次性口令校验流程、软令牌校验流程，具体在此不做限定。

例如，密码校验流程为将用户注册信息中用户账号所设定的密码与支付信息中的密码进行比对，校验其是否一致。

在成功通过对应的校验流程时，确定该用户账号通过支付信息校验。

进而，本实施例中，收银台系统将安全校验与具体的支付业务单独区分开，解开了业务与安全校验的耦合度；用户端如果需要使用支付功能，需要先在收银台注册，达到支付业务统一管理的目的。同时，在开发角度，安全验证环节可以根据安全等级的不同来进行自定义的配置，如果支付业务发生改变，只需要通过修改安全等级来达到自动切换的效果，不需要对过去的开发代码进行重构，大大减小了针对于用户端的开发成本，可以更快的满足市场需求。另外，整个安全校验环节交由收银台系统完成，流程对用户端不可见，提升了支付及其校验的安全性。

在一实施方式中，若确定该支付信息校验通过，则向用户端发送支付成功信息，并触发支付资金冻结流程，以确认及冻结用户端所支付的交易资金，在成功完成了支付资金冻结流程后，修改预支付订单的状态为支付成功，指示该预支付订单成为已支付订单。

若确定该支付信息校验未通过，则向用户端发送支付未成功信息，并修改预支付订单的状态为支付失败，指示该预支付订单成为未成功支付订单。后续用户端可对该未成功支付订单发起再次支付申请，以再次进行支付信息校验，直至通过支付信息校验。

在一实施方式中，如图6所示，本实施例还具体包括如下步骤：

S70，实时监控支付信息的校验时长，在校验时长大于预定校验时长阈值时，向用户端发送支付失败信息。

收银台系统在接收到来自用户端的支付信息后，实时监控和统计支付信息的校验时长，并在检测到当前的校验时长大于预定校验时长阈值时，向用户端发送支付失败信息，表示当前支付失败，需要重新发起支付申请。从而通过实时监控支付校验时长，保证支付和交易的安全性。

本申请实施例，第一方面实现了交易过程中的支付校验，提高了支付的安全性；第二方面，基于预下单信息生成预支付订单进而生成场景码，从而后续可基于场景码对支付信息进行校验，以将校验流程与支付业务区分开，降低支付与校验的耦合度，提高支付以及校验的效率，进而提高支付校验的可靠性；第三方面，在开发角度，安全验证环节可以根据安全等级的不同来进行自定义的配置，如果支付业务发生改变，只需要通过修改安全等级来达到自动切换的效果，不需要对过去的开发代码进行重构，大大减小了针对于用户端的开发成本，可以更快的满足市场需求；第四方面，整个安全校验环节交由收银台系统完成，其校验流程对用户端不可见，提升了支付及其校验的安全性。

实施例2

请参照图7，本申请实施例提供了一种收银台系统，该系统包括：

接收模块100，用于接收来自用户端的预下单信息，基于所述预下单信息生成预支付订单和预付单号；

生成模块200，用于根据所述预付单号和所述预支付订单，生成场景码；

支付模块300，用于向所述用户端发送所述预付单号和所述预支付订单，并接收来自所述用户端的支付信息；

校验模块400，用于根据所述支付信息中的预付单号，查询对应的场景码，并基于所述场景码对所述支付信息进行校验。

上述的收银台系统对应于实施例1的支付校验方法；实施例1中的任何可选项也适用于本实施例，这里不再详述。

本申请实施例还提供了一种计算机设备，所述计算机设备包括存储器和至少一个处理器，所述存储器存储有计算机程序，所述处理器用于执行所述计算机程序以实施上述实施例的支付校验方法。

存储器可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据计算机设备的使用所创建的数据(比如预付单号、场景码等)等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有机器可运行指令，所述计算机可运行指令在被处理器调用和运行时，所述计算机可运行指令促使所述处理器运行上述实施例的支付校验方法的步骤。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统和方法，也可以通过其它的方式实现。以上所描述的系统实施例仅仅是示意性的，例如，附图中的流程图和结构图显示了根据本申请的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，结构图和/或流程图中的每个方框、以及结构图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块或单元可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或更多个模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是智能手机、个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。