CN111815326B - 一种飞行状态下的支付方法及其装置、设备和存储介质 - Google Patents
一种飞行状态下的支付方法及其装置、设备和存储介质 Download PDFInfo
- Publication number
- CN111815326B CN111815326B CN201910290481.7A CN201910290481A CN111815326B CN 111815326 B CN111815326 B CN 111815326B CN 201910290481 A CN201910290481 A CN 201910290481A CN 111815326 B CN111815326 B CN 111815326B
- Authority
- CN
- China
- Prior art keywords
- payment
- information
- verification
- certificate
- identification code
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 101
- 238000012795 verification Methods 0.000 claims abstract description 189
- 238000004891 communication Methods 0.000 claims description 27
- 238000004590 computer program Methods 0.000 claims description 8
- 238000012011 method of payment Methods 0.000 claims 6
- 238000010586 diagram Methods 0.000 description 20
- 230000008569 process Effects 0.000 description 19
- 238000010200 validation analysis Methods 0.000 description 7
- 230000008859 change Effects 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000013475 authorization Methods 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000013499 data model Methods 0.000 description 1
- 238000013524 data verification Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005242 forging Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/405—Establishing or using transaction specific rules
-
- 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/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本申请实施例提供一种飞行状态下的支付方法及其装置、设备和存储介质,其中,所述方法包括:当在飞行状态下商户收单***未与支付***建立连接时,所述商户收单***获取用户的支付信息;对所述支付信息进行验证,得到第一验证结果;如果所述第一验证结果为验证通过,基于所述支付信息生成订单信息,并基于所述订单信息完成与所述用户之间的交易;在所述商户收单***与所述支付***建立连接时,将所述订单信息发送给所述支付***,以使得所述支付***发起对所述用户的扣费。
Description
技术领域
本申请涉及计算机技术领域,涉及但不限于一种飞行状态下的支付方法及其装置、设备和存储介质。
背景技术
随着移动通信技术以及电子商务的发展,人们的工作、生活以及娱乐也发生了翻天覆地的变化。人们在购物、娱乐时不再仅仅依赖现金支付或刷卡支付,而扫码支付成为应用越来越广泛的支付方式。
扫码支付可以是买家扫描商户提供的收款二维码,然后由用户输入支付金额以进行支付。当然也可以是商户扫描买家出示的付款二维码,由商家输入收款金额,进行收款。但是这两种方式一般情况下需要商户或买家与发码平台、支付***建立有通信连接,以能够进行订单信息的确认或者生成付款二维码。但是例如飞机在航行过程中,用户处于无网环境下,又想要进行扫码支付。因此如何在飞行状态所处的无网环境下提供一种安全的支付方法成为目前亟待解决的技术问题。
发明内容
有鉴于此,本申请实施例期望提供一种飞行状态下的支付方法及其装置、设备和存储介质,能够在商家收单***和支付***在断开连接的情况下,如果商家收单***对支付信息验证通过,则能够完成交易,从而实现安全支付。
本申请实施例提供一种飞行状态下的支付方法,所述方法包括:
当在飞行状态下商户收单***未与支付***建立连接时,所述商户收单***获取用户的支付信息;
对所述支付信息进行验证,得到第一验证结果;
如果所述第一验证结果为验证通过,基于所述支付信息生成订单信息,并基于所述订单信息完成与所述用户之间的交易;
在所述商户收单***与所述支付***建立连接时,将所述订单信息发送给所述支付***,以使得所述支付***发起对所述用户的扣费。
本申请实施例提供一种飞行状态下的支付方法,所述方法包括:
支付***接收商户收单***发送的订单信息;
对所述订单信息进行校验;
当所述订单信息校验通过后,将所述订单信息发送给发码平台,以通知发码平台进行扣款;
基于接收到的扣款成功消息,所述支付***进行对账和资金结算。
本申请实施例提供一种飞行状态下的支付方法,所述方法包括:
发码平台接收支付***发送的订单信息,所述订单信息至少包括订单号、支付金额、离线支付标识码信息;
对所述订单号和所述离线支付标识码信息进行验证;
如果所述订单号和所述离线支付标识码信息验证通过,基于所述支付金额,对所述订单信息对应的用户账户进行扣款;
将扣款成功消息发送给所述订单信息对应的终端和支付***。
本申请实施例提供一种支付装置,所述支付装置包括:第一获取模块、第一验证模块、第一生成模块和第一发送模块,其中:
所述第一获取模块,用于当在飞行状态下自身未与支付***建立连接时,获取用户的支付信息;
所述第一验证模块,用于对所述支付信息进行验证,得到第一验证结果;
所述第一生成模块,用于如果所述第一验证结果为验证通过,基于所述支付信息生成订单信息,并基于所述订单信息完成与所述用户之间的交易;
所述第一发送模块,用于在自身与所述支付***建立连接时,将所述订单信息发送给所述支付***,以使得所述支付***发起对所述用户的扣费。
本申请实施例提供一种支付装置,所述支付装置包括:第一接收模块、第一校验模块、第二发送模块和结算模块,其中:
所述第一接收模块,用于接收商户收单***发送的订单信息;
所述第一校验模块,用于对所述订单信息进行校验;
所述第二发送模块,用于当所述订单信息校验通过后,将所述订单信息发送给发码平台,以通知发码平台进行扣款;
所述结算模块,用于基于接收到的扣款成功消息,进行对账和资金结算。
本申请实施例提供一种支付装置,所述支付装置包括:第二接收模块、第二验证模块、扣款模块和第三发送模块,其中:
所述第二接收模块,用于接收支付***发送的订单信息,所述订单信息至少包括订单号、支付金额、离线支付标识码信息;
所述第二验证模块,用于对所述订单号和所述离线支付标识码信息进行验证;
所述扣款模块,用于如果所述订单号和所述离线支付标识码信息验证通过,基于所述支付金额,对所述订单信息对应的用户账户进行扣款;
所述第三发送模块,用于将扣款成功消息发送给所述订单信息对应的终端和支付***。
本申请实施例提供一种计算机设备,所述计算机设备至少包括:
存储器、通信总线和处理器,其中:
所述存储器,用于存储计算机程序;
所述通信总线,用于实现处理器和存储器之间的连接通信;
所述处理器,用于执行存储器中存储的计算机程序,以实现本申请实施例提供的支付方法中的步骤。
本申请实施例提供一种存储介质,所述存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如上所述的支付方法的步骤。
本申请实施例提供一种飞行状态下的支付方法及其装置、设备和存储介质,其中,首先当在飞行状态下商户收单***未与支付***建立连接时,所述商户收单***获取用户的支付信息并对所述支付信息进行验证,得到第一验证结果,如果所述第一验证结果为验证通过,基于所述支付信息生成订单信息,并基于所述订单信息完成与所述用户之间的交易;在所述商户收单***与所述支付***建立连接时,将所述订单信息发送给所述支付***,以使得所述支付***发起对所述用户的扣费;如此,能够在飞行状态商家收单***和支付***在断开连接的情况下,实现无网支付,并且由于在交易前对支付信息进行了验证,从而实现无网场景下的安全支付。
附图说明
图1为本申请实施例飞行状态下支付方法的应用场景示意图;
图2为本申请实施例飞行状态下支付方法的实现流程示意图;
图3为本申请实施例飞行状态下支付方法的一个实现流程示意图;
图4为本申请实施例飞行状态下支付方法对应的***架构图;
图5为本申请实施例飞行状态下支付方法的一实现流程示意图;
图6A为本申请实施例用户请求开通机上支付的界面示意图;
图6B为本申请实施例开通免密支付的界面示意图;
图6C为本申请实施例对用户身份进行验证的界面示意图;
图6D为本申请实施例机上支付开通成功的界面示意图;
图6E为本申请实施例生成离线支付二维码的界面示意图;
图7为本申请实施例发码平台进行扣款的实现流程示意图;
图8为本申请实施例支付装置的组成结构示意图;
图9为本申请实施例计算机设备的组成结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对发明的具体技术方案做进一步详细描述。以下实施例用于说明本申请,但不用来限制本申请的范围。
除非另有定义,本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的,不是旨在限制本申请。
在以下的描述中,涉及到“一些实施例”,其描述了所有可能实施例的子集,但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集,并且可以在不冲突的情况下相互结合。
需要指出,本申请实施例所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象,不代表针对对象的特定排序,可以理解地,“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序,以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。
图1为本申请实施例支付方法的应用场景示意图,如图1所示,在该应用场景中,包括:终端101、商家收单***102、支付***103和发码平台104。其中,终端101可以是移动电话(手机)、平板电脑、笔记本电脑等具有无线通信能力的移动终端。终端101中可以安装能够扫码支付的支付应用程序(Application,App),用户可以通过这些App生成支付二维码,使得商家通过扫码进行收款。商家收单***102可以包括扫描设备和收单设备,其中,扫描设备用于对用户付款时出示的支付二维码进行扫描,以获取支付信息,并且将支付信息发送给收单设备,收单设备基于支付信息生成订单信息,再将订单信息发送给支付***103,支付***103可以认为是商家的结算中心;支付***会将订单信息发送给发码平台104,以通知发码平台104进行扣款。发码平台104除了进行扣款外,还会为终端提供生成支付二维码的证书数据,以使得终端能够基于证书数据生成支付二维码。
本申请实施例提供的支付方法是应用在飞行状态下用户想要通过支付二维码进行付款时,收单***和终端都与发码平台和支付***没有建立连接的场景中,由于用户是事先了解在支付时不能联网的,因此用户在飞机起飞之前,可以预先通过发码平台104生成离线支付二维码,以供商家收单***进行扫描收款。在本申请实施例中,为了防止恶意消费,商家收单***中存储有能够对用户的身份信息以及二维码信息进行验证的信息,例如,可以存储有用户的准确身份信息、验证所需的公钥、加解密算法等,以对用户的身份信息和二维码的真实性、有效性进行验证,在验证通过后,生成并保存订单信息,完成交易。商家收单***102会在与支付***103建立连接后,再将订单信息发送给支付***103,以使支付***103对订单进行校验,并将订单信息发送给发码平台104进行扣款。
结合图1所示的应用场景示意图,以下对飞行状态下的支付方法及支付装置、设备的各实施例进行说明。
本申请实施例提供一种支付方法,图2为本申请实施例飞行状态下支付方法的实现流程示意图,如图2所示,所述方法包括以下步骤:
步骤S201,当飞行状态下商户收单***未与支付***建立连接时,所述商户收单***获取用户的支付信息。
这里,飞行状态是指飞机在航行过程中所处的状态。当在飞机航行过程中,终端用户想要购买商品,进行离线支付时,可以出示预先生成的离线支付标识码,该离线支付标识码可以是二维码。商户可以利用扫描设备对终端显示屏上显示的离线支付标识码进行扫描,以获取支付信息,并将支付信息传输至商户收单***。在一些实施例中,离线支付标识码还可以是字符串,此时可以是商户的销售人员在商家收单***手动输入用户的离线支付标识码,以及商品的标识、支付金额等,以获取用户的支付信息。
在本申请实施例中,商户收单***可以认为是机上局域网收单***,用于对用户的购物信息进行收集,并且在商户收单***中存储有对用户身份信息以及对离线支付标识码进行验证的验证信息,以验证用户身份信息的真实性和离线支付标识码的有效性。
支付***也可以认为是商家收款***,主要用于对商户收单***提供的订单进行校验和入库,并将订单发送给发码平台以发起对用户的扣款。在收到发码平台扣款成功的通知消息后还要进行资金结算和对账。
需要说明的是,由于在飞机航行过程中用户购买商品时,商户收单***与支付***,以及商户收单***和发码平台、终端和支付***、终端和发码平台都没有建立有通信连接。扫码设备和商户收单***之间可以通过局域网建立有通信连接,因此扫码设备可以将获取到的支付信息传输至商户收单***。
在本申请实施例中,支付信息至少包括离线支付标识码信息和支付金额。
步骤S202,所述商户收单***对所述支付信息进行验证,得到第一验证结果。
这里,第一验证结果可以为验证通过和验证不通过。
步骤S202在实现时,商户收单***会对支付信息中的离线支付标识码和支付金额进行验证,只有当离线支付标识码和支付金额都验证通过时,第一验证结果才为验证通过。
在其他实施例中,在步骤S202之后,所述方法还包括:判断第一验证结果是否为验证通过;这里如果第一验证结果为验证通过,可以认为离线支付标识码的是真实有效的,支付金额也没有超过预设的消费限额,此时可以进入步骤S203;如果第一验证结果为验证不通过,则认为离线支付标识码不是真实有效的,和/或支付金额超过了消费限额,此时结束流程。
步骤S203,如果所述第一验证结果为验证通过,所述商户收单***基于所述支付信息生成订单信息,并基于所述订单信息完成与所述终端之间的交易。
这里,订单信息中可以包括订单号、支付金额和离线支付二维码信息。如果第一验证结果为验证通过,则认为可以在商户收单***与支付***建立连接后正常完成扣款,因此可以完成与终端用户之间的交易。
步骤S204,在所述商户收单***与所述支付***建立连接时,所述商家收单***将所述订单信息发送给所述支付***,以使得所述支付***发起对所述用户的延时扣费。
这里,在实际实现过程中,当飞机结束航行落地后,商户收单***与支付***建立通信连接,此时商家收单***会将订单信息发送给支付***,由支付***对订单进行校验后,再将订单信息发送给离线支付标识码对应的发码平台,以进行延时扣款。
发码平台在接收到订单信息后,会对订单信息中的订单号和离线支付标识码信息进行校验,并在校验通过后进行扣款。扣款成功后,发码平台还会给终端和支付***发送扣款成功通知消息,以使得终端保存扣款凭证,支付***基于该扣款成功通知消息进行资金结算等工作。
在本申请实施例提供的支付方法中,在飞行状态商户收单***和支付***没有建立连接的情况下,在用户使用离线支付标识码进行支付时,商户收单***对支付信息进行验证,如果支付信息验证通过,可以认为用户出示的离线支付标识码是真实有效的,且支付金额也在预设的消费限额之内,因此表明在商户收单***与支付***建立连接后可以完成正常扣款,此时商户收单***可以生成订单信息并基于订单信息完成交易,不仅实现了无网支付,还能够保证支付的安全性。
基于前述的实施例,本申请实施例再提供一种支付方法,图3为本申请实施例飞行状态下支付方法的又一个实现流程示意图,如图3所示,所述方法包括:
步骤S301,在飞行状态下终端基于用户的操作指令,生成并输出离线支付标识码,供扫描设备进行扫描。
这里,步骤S301在实现时,由于是在飞行状态下,那么终端与离线支付标识码对应的发码平台是没有建立有通信连接的,但是终端在飞机起飞前,也即与发码平台断开连接之前,已经从发码平台获取到了生成离线支付标识码的证书数据,从而可以在用户想要利用离线支付标识码进行支付时,即便没有与发码平台建立连接,也可以根据自身已经存储的证书数据生成离线支付标识码。
在本申请实施例中,输出离线支付标识码可以是指在终端的显示屏上输出显示所生成的离线支付标识码,以供扫描设备进行扫描。
步骤S302,扫描设备将通过扫描离线支付标识码获取到的支付信息传输给商户收单***。
这里,支付信息至少包括离线支付标识码信息和支付金额。
步骤S303,商户收单***对支付信息中的离线支付标识码信息进行验证,得到第二验证结果。
这里,离线支付标识码信息中至少包括证书数据、消息摘要数据和离线支付标识码的生成时间,因此步骤S303在实现时,分别对证书数据、消息摘要数据和离线支付标识码的生成时间进行验证,得到第二验证结果。
步骤S304,商户收单***判断第二验证结果是否为验证通过。
这里,如果证书数据、消息摘要数据和离线支付标识码的生成时间都验证通过,商户收单***确定所述第二验证结果为验证通过,此时进入步骤S305;如果证书数据、消息摘要数据和离线支付标识码的生成时间中只要有一个验证不通过,那么确定第二验证结果为验证不通过,此时,确定第一验证结果也为验证不通过,结束流程。
步骤S305,商户收单***对所述支付金额进行验证,得到第一验证结果。
这里,步骤S305在实现时,首先获取离线支付标识码信息对应的限制消费金额,并判断支付金额是否小于或者等于预设的限制消费金额,如果支付金额小于或者等于所述限制消费金额,确定第一验证结果为验证通过。
步骤S306,如果所述第一验证结果为验证通过,商户收单***基于所述支付信息生成订单信息,并基于所述订单信息完成与所述用户之间的交易。
在本申请实施例中,是先对离线支付标识码信息进行验证,再对支付金额进行验证,从而确定第一验证结果;在实际应用过程中,并不对离线支付标识码和支付金额的验证顺序进行限定,只要是离线支付标识码信息和支付金额都验证通过,那么就确定第一验证结果为验证通过,离线支付标识码信息和支付金额中有一个验证不通过,则第一验证结果为验证不通过。
如果第一验证结果为验证通过,那么就可以认为离线支付标识码信息是真实有效的,后续在商户收单***和支付***建立有通信连接后可以正常完成扣款,此时商户收单***可以基于支付信息生成订单信息,并完成与终端用户之间的交易。
步骤S307,在飞机结束航行商户收单***与支付***建立连接时,商户收单***将订单信息发送给所述支付***,以使得所述支付***发起对所述用户的延时扣费。
步骤S308,支付***基于接收到的商户收单***发送的订单信息,对所述订单信息进行校验。
这里,订单信息中可以包括订单号、支付金额和商品标识。支付***对订单信息进行校验可以是判断订单号是否重复,以及判断商品标识和支付金额是否对应。
步骤S309,当订单信息校验通过后,支付***将订单信息发送给发码平台,以通知发码平台进行扣款。
这里,如果订单号不重复,并且商品标识和支付金额是对应的,那么认为订单信息校验通过,此时支付***将订单信息发送给发码平台,以通知发码平台进行扣款。
步骤S310,发码平台基于接收到的订单信息,对订单信息中的订单号和所述离线支付标识码信息进行验证。
这里,订单信息除了包括订单号、支付金额和商品标识之外,还包括离线支付标识码信息。发码平台在基于订单信息进行扣款时,需要对订单号和离线支付标识码信息进行验证。在实现时,发码平台可以确定是否存在与所述订单号相同的订单号;如果不存在与所述订单号相同的订单号,发码平台再进一步对所述离线支付标识码信息中的交易认证码(Transaction Authorization Cryptogram,TAC)进行验证。
TAC密钥是由发码平台生成的,在生成TAC密码时可以依据但不限于证书生效时间、证书失效时间和二维码生成时间以及用户标识信息。TAC为不被商户所知的动态密钥,能够防止商户根据用户的证书数据来伪造二维码发起扣款。
步骤S311,如果所述订单号和所述离线支付标识码信息验证通过,发码平台基于所述支付金额,对所述订单信息对应的用户账户进行扣款。
这里,只有订单号和离线支付标识码信息都验证通过时,才认为订单信息验证通过,此时发码平台会基于支付金额对订单信息对应的用户账户进行扣款。
步骤S312,发码平台将扣款成功消息发送给所述订单信息对应的终端和支付***。
这里,当发码平台扣款成功后,会将扣款成功消息发送给终端和支付***。
步骤S313,支付***基于接收到的扣款成功消息,进行对账和资金结算。
在本实施例提供的支付方法中,当用户想要使用支付标识码进行离线支付时,可以基于预先获取到的证书数据生成离线支付标识码,扫描设备通过扫描该离线支付标识码后获取到支付信息并传输至商户收单***,由商户收单***对支付信息中的离线支付标识码信息和支付金额进行验证,如果离线支付标识码信息和支付金额都验证通过,那么可以认为该离线支付标识码是真实有效的,且支付金额也没有超出限制消费金额,此时认为可以正常完成交易,在商户收单***和支付***建立有通信连接之后,商户收单***将订单信息发送给支付***,支付***对商品和支付金额校验后,再将订单信息发送给发码平台进行扣款,这样不仅满足了用户可以进行离线支付,并且商户收单***还可以基于预先获取到的黑名单、验证公钥等对支付信息进行验证,以保证支付的安全性。
在其他实施例中,证书数据中至少包括用户信息、证书有效时间和签名数据,对应地,商户收单***对所述离线支付标识码信息中的证书数据进行验证可以通过以下步骤实现:
步骤321,商户收单***基于自身存储的用户校验信息,对所述证书数据中的用户信息进行验证。
这里,用户信息可以包括用户的姓名、身份证号、账号ID掩码等信息。用户校验信息至少包括黑名单和有效用户信息,有效用户信息是指真实有效的用户信息。黑名单可以是在与发码平台断开连接之前,从发码平台获取的。
该有效用户信息可以是商户预先存储好的,例如当在飞机航行的场景下,有效用户信息可以是从空运公司服务信息平台获取的本次航班的旅客信息,由于空运公司服务信息平台中存储的旅客信息一般为在用户购票时用到的用户信息,是准确的。当在就餐或购物场景下,有效用户信息可以是用户办理会员卡时存储的用户信息。
步骤321在实现时,可以首先判断该用户信息是否存在于黑名单中,如果用户信息不存在于所述黑名单中,基于所述有效用户信息,对所述用户信息进行验证。在实际应用过程中,基于有效用户信息对离线支付标识码信息中的用户信息进行验证时,可以是将离线支付标识码信息中的用户信息与有效用户信息进行匹配,以确定用户信息中的姓名、身份证号等是否正确。
步骤322,商户收单***基于自身的当前时间,对所述证书数据中的证书有效时间进行验证。
这里,证书有效时间中可以包括证书生效的起始时间和证书失效时间,例如证书有效时间可以为2019年3月15日至2019年4月15日,其中,2019年3月15日为证书生效的起始时间,2019年4月15日为证书失效时间。或者证书有效时间中可以包括证书生效的起始时间和证书有效时长,基于证书生效的起始时间和证书有效时长,可以确定出证书失效时间,例如证书有效时间可以为2019年3月15日,有效期30天,那么证书生效的起始时间为2019年3月15日,失效时间为2019年4月14日。
对证书有效时间进行验证,可以认为是验证证书数据的有效性,当当前时间在证书有效时间内,则认为证书有效时间通过验证,例如证书有效时间为2019年3月15日至2019年4月15日,当前时间为2019年3月19日,那么认为验证通过。
步骤323,商户收单***基于预先获取的验证公钥,对所述证书数据中的签名数据进行验证。
这里,如果用户信息、证书有效时间和签名数据都验证通过表征所述证书数据验证通过。
在其他实施例中,商户收单***对所述离线支付标识码信息中消息摘要数据进行验证可以通过以下步骤实现:
步骤331,商户收单***获取所述离线支付标识码的生成时间、证书有效起始时间、证书失效时间;
步骤332,商户收单***基于证书有效起始时间、证书失效时间和离线支付标识码的生成时间,对所述消息摘要数据中的MAC摘要进行验证。
这里,由于消息摘要数据中的MAC摘要是对证书有效起始时间、证书失效时间和离线支付标识码的生成时间进行摘要计算得到的,因此需要商户收单***基于证书有效起始时间、证书失效时间和离线支付标识码的生成时间也进行相同的摘要计算,以对消息摘要数据中的MAC摘要进行验证。
在其他实施例中,在所述商户收单***在与所述支付***断开连接之前,所述方法还包括:
步骤341,商户收单***将自身的时钟与离线支付标识码的发码平台的时钟进行校对。
这里,商户***将自身时钟与发码平台的时钟进行校对是为了避免因为时钟的差异,导致验证结果错误。
步骤342,商户收单***获取发码平台发送的验证公钥和黑名单。
这里,在商户收单***在与发码平台断开连接之前,需要获取验证公钥与黑名单,以对离线支付标识码信息进行验证。
在其他实施例中,在终端与发码平台断开连接之前,会请求获取生成离线支付标识码所需的证书数据,以在离线时生成离线支付标识码,终端获取证书数据的过程可以包括:
步骤351,终端向发码平台发送请求消息,所述请求消息用于获取生成离线支付标识码的证书数据。
步骤352,发码平台基于接收到的请求消息,对终端对应的身份信息进行验证。
步骤353,当所述身份信息通过验证后,发码平台确定所述身份信息对应的限制消费金额。
这里,步骤353在实现时,当所述身份信息通过验证后,首先获取用户选择的扣款方式,并确定所述扣款方式对应的账户余额;然后基于所述账户余额和信用等级,确定所述身份信息对应的限制消费金额。例如,当用户选择扣款方式为“零钱”时,则获取“零钱”中的账户余额,并基于账户余额和用户的信用等级,确定限制消费金额,很显然,限制消费金额是不能大于账户余额的,具体限制消费金额比账户余额低多少,可以由用户的信用等级决定,其中,用户的信用等级越高,那么限制消费金额就与账户余额越接近。
步骤354,发码平台至少基于所述身份信息和所述限制消息金额确定证书数据。
这里,证书数据可以包括卡证书、证书有效时间和签名数据。步骤354在实现时,首先发码平台基于所述身份信息和所述限制消费金额生成卡证书,进而再基于用户发送请求消息的时间点及预设的证书有效时长,确定所述证书数据的证书有效时间;基于验证私钥至少对所述身份信息进行签名,得到签名数据;最后至少基于所述卡证书、证书数据的有效时长和所述签名数据,生成证书数据。
步骤355,发码平台将所述证书数据发送给所述终端,以使所述终端基于所述证书数据生成离线支付标识码。
在本申请实施例中,发码平台还会基于身份信息生成该身份信息对应的分散密钥,并将该分散密钥发送给终端,终端生成的离线支付标识码中包括该分散密钥,从而可以保证离线支付标识码不可被商户伪造。
这样,通过步骤351至步骤355,终端就能获取到用于生成离线支付标识码的证书数据,在用户想要进行离线支付时即可生成离线支付标识码。
在其他实施例中,在发码平台接收到请求消息之后,所述方法还包括:
步骤361,发码平台获取所述身份信息对应的征信数据。
步骤362,发码平台基于所述征信数据确定信用等级。
这里,信用等级越高说明用户的信用度越好,信用等级越低说明用户的信用度越差。
步骤363,当所述信用等级低于预设等级阈值时,向所述终端发送生成失败的响应消息。
这里,如果用户的信用等级低于预设等级阈值,那么说明该用户的信用度很差,有可能不能完成正常扣款,因此此时向终端发送获取失败的响应消息,避免用户使用离线支付标识码进行离线支付。
本申请实施例提供一种支付方法,应用于乘客在飞行航行过程中完全无网的场景中,图4为本申请实施例飞行状态下支付方法对应的***架构图,如图4所示,所述***架构包括:用户终端401、账户***402、机上局域网收单***403、统一收单***404、计费平台405和统一发码平台406,其中:
用户终端401,在乘机之前向发码平台申请开通机上离线支付,已生成离线支付二维码。
账户***402,进一步包括航司账户***4021、综合风控数据模型4022和统一用户账户平台4023,其中,航司账户***4021提供基本用户资料核验,统一用户账户平台4023综合风控数据模型4022对用户进行区分授信,对于信用不合格用户,可以不予开通离线支付。
机上局域网收单***403,包含移动扫码设备4031以及机上局域网中台控制***4032。机上局域网中台控制***4032提供发码平台的验证公钥,以验证二维码的真实性和有效性;并提供黑名单数据杜绝恶意用户;另外还提供机上旅客数据,进一步校对用户身份真实性。机上局域网中台控制***4032还用于存储相关订单信息,以待通信网络恢复后自动推单到统一收单***404。该机上局域网收单***403对应其他实施例中的商家收单***。
统一收单***404和计费平台405,主要用于对上传的机上订单提供校验和入库,并发起对用户的延时扣款。计费平台405还提供资金结算、对账功能。本申请实施例中的统一收单***404和计费平台405对应其他实施例中的支付***。
统一发码平台406,用于提供用户开通离线支付流程、卡证书统一管理下发能力,统一配置能力。同时统一发码平台还基于接收到的订单发起扣款,扣款成功之后自动通知用户相关扣款信息。本申请实施例中的统一发码平台406对应其他实施例中的发码平台。
图5为本申请实施例飞行状态下支付方法的再一实现流程示意图,如图5所示,所述支付方法涉及三个阶段,即飞机起飞前、飞机航行中和飞机到达后,以下基于这三个阶段对本申请实施例提供的支付方法进行说明。
如图5所示,在起飞前,终端和发码平台完成的步骤包括:
步骤S501,终端向发码平台发送开通机上支付的请求消息。
这里,图6A为本申请实施例用户请求开通机上支付的界面示意图,如图6A所示,在该界面示意图中,提供了开通机上支付的按钮控件601,当终端在按钮控件601所在的屏幕区域接收到触控操作或点击操作时,终端向发码平台发送开通机上支付的请求消息。该请求消息中至少包括用户的身份信息,还可以包括航班信息。
步骤S502,发码平台为该终端开通服务。
这里,发码平台在接收到请求开通机上支付的请求消息后,可以根据请求消息中的航班信息从空运公司服务信息平台获取与航班信息对应的用户数据,并生成用户账号。
在该阶段,如图6B所示,发码平台会提示用户与空运公司签署相关代扣签约关系,并在终端界面显示阅读并同意《扣款授权确认书》的选择按钮控件611,用户需要选择同意才能开通。并为用户提供扣款方式的选择,用户可以选择零钱方式,还可以选择绑定的银行卡方式。同时,发码平台通过对用户身份做实名校验,如图6C所示,发码平台可以请求用户输入支付密码以确认是本人操作,并根据后台征信数据对用户进行区别授信。
步骤S503,发码平台向终端发送开通成功的通知消息。
这里,当发码平台向终端发送开通成功的通知消息后,终端会显示如图6D所示的界面。
步骤S504,终端向发码平台发送获取卡证书的请求消息。
步骤S505,发码平台基于该请求消息生成卡证书。
步骤S506,发码平台向终端返回卡证书。
这里,终端在获取到卡证书后,在与发码平台没有建立通信连接的情况下也可以生成如图6E所示的支付二维码。
如图5所示,在起飞前空运公司的机上局域网中台控制***也需要获取验证支付二维码的公钥、MAC根密钥以及黑名单,实现过程包括:
步骤S507,空运公司服务信息平台从发码平台定期下载卡证书公钥列表。
步骤S508,发码平台返回公钥列表给空运公司服务信息平台。
步骤S509,空运公司服务信息平台将公钥列表下发给机上局域网中台控制***。
步骤S510,空运公司服务信息平台从发码平台定期下载MAC根密钥列表。
步骤S511,发码平台返回MAC根密钥列表给空运公司服务信息平台。
步骤S512,空运公司服务信息平台将MAC根密钥列表下发给机上局域网中台控制***。
步骤S513,空运公司服务信息平台从发码平台定期下载黑名单列表。
步骤S514,发码平台返回黑名单列表给空运公司服务信息平台。
步骤S515,空运公司服务信息平台将黑名单列表下发给机上局域网中台控制***。
这里,经过步骤S507至步骤S515,机上局域网中台控制***就获取到了卡证书公钥、MAC根密钥列及黑名单列表,从而在无网的情况下,能够对用户的支付信息进行验证,以保证安全支付。
需要说明的是,步骤S501至步骤S506和步骤S507至步骤S515的执行不区分先后顺序,可以是先执行步骤S501至步骤S506,也可以是先执行步骤S507至步骤S515,当然还可以是在步骤S501至步骤S506的执行过程中,同时执行步骤S507至步骤S515。
如图5所示,在飞机航行过程中,用户想要通过支付二维码进行支付时的实现过程包括:
步骤S516,终端基于卡证书,离线生成机上支付码。
步骤S517,终端出示支付码,以供机上局域网中台控制***中的扫码设备进行离线扫码。
步骤S518,机上局域网中台控制***读取二维码。
步骤S519,机上局域网中台控制***向机具SDK发送获取二维码元素的请求消息。
步骤S520,机具SDK返回二维码元素给机上局域网中台控制***。
步骤S521,机上局域网中台控制***向机具SDK发送验证二维码的请求消息。
步骤S522,机具SDK验证二维码的合法性和有效性。
步骤S523,机具SDK在二维码验证通过后,生成扫码记录。
步骤S524,机具SDK将扫码记录返回给机上局域网中台控制***。
步骤S525,机上局域网中台控制***检查黑名单。
这里,如果用户不在黑名单列表中,则进入步骤S526,验证支付金额是否超过消费额度。
步骤S526,机上局域网中台控制***检查是否超过消费额度。
这里,如果支付金额没有超过消费额度,则表明可以完成交易,此时进入步骤S527。
步骤S527,机上局域网中台控制***保存交易记录。
通过步骤S516至步骤S527,旅客在机上消费时,展示手机上的离线二维码,空乘人员通过特定移动设备扫描二维码,并由机具SDK校验二维码真实性和时效性,并验证用户姓名身份证与机上旅客信息是否匹配,是否满足限额要求。通过则做支付成功,并保存相关订单信息于机上局域网中台控制***。由于机上局域网中台控制***与空运公司服务信息平台没有建立通信连接,不能实现即时扣款。但是由于机上局域网中台控制***已经对二维码的合法性和有效性、支付金额进行了验证,能够保证在飞机落地后与空运公司服务信息平台建立通信连接后,进行订单推送和扣款,保证了支付的安全性和有效性。
为了更好地理解如何对二维码的有效性和合法性进行验证,首先对二维码数据的组成进行说明。
二维码的整体数据组成及说明,如表1所示:
表1 二维码数据组成内容及说明
证书数据的组成内容及说明如表2所示:
表2 二维码数据组成内容及说明
由于二维码数据包含用户姓名信息、用户身份ID掩码信息,因此可以在机上扫码设备扫码时,与机上局域网***的旅客名单进行比对,进一步确认用户的真实身份。
在本申请实施例中,在获取到二维码信息后,机上局域网中台控制***通过验证以下信息,以验证二维码的真实性和有效性。
1、黑名单检查:检查用户是否处于机上局域网***黑名单中,黑名单在飞机起飞前更新至机上局域网***。
2、证书有效期检查。
在实现时,判断机上局域网服务器时间是否小于证书生效的起始时间或者是否大于证书失效时间,如果机上局域网服务器时间小于证书生效的起始时间或者大于证书失效时间,则不允许支付。局域网服务器的时钟在起飞前与二维码发码平台进行校对,确保时间准确。
3、证书验签。
在实现时,用二维码发码平台下发的公钥对证书签名进行验证,如果签名验证通过,则允许支付 。发码平台在飞机起飞前将公钥下发至机上局域网中台控制***。
4、二维码生成时间检查。
在实现时,如果二维码生成时间在证书生效的起始时间和证书失效时间范围之外,则验证失败,不允许支付;还可以是如果机上局域网服务器的时间减去二维码生成时间的值大于证书里的二维码失效时间时,验证失败,不允许支付;或者,如果机上局域网服务器时间加上时钟误差允许时间小于二维码生成时间时,验证失败,不允许支付。
5、MAC摘要验证。
在实现时,基于证书生效的起始时间、证书失效时间、二维码生成时间对MAC摘要进行验证,如果MAC摘要不正确,则验证失败,不允许支付。
6、限额检查。
在实现时,判断交易金额是否大于限额,如果交易金额大于限额则验证失败,不允许支付。
7、姓名身份证信息校对。
在实现时,将二维码中的用户姓名、身份证掩码信息与机上局域网服务器中本次航班旅客信息比对,匹配成功则认为合法,有效保证身份信息真实性。
在上述信息验证通过之后,保存相关订单信息到机上局域网中台控制***,其中订单信息包括订单号,交易详情、二维码字符串等。飞机落地之后,***恢复联网则自动将本地收储的订单上传至后台收单***。
在飞机落地,机上局域网中台控制***与空运公司信息服务平台建立通信连接后,进行延时扣款的实现过程包括:
步骤S528,机上局域网中台控制***上传扫码数据至空运公司信息服务平台。
步骤S529,空运公司服务信息平台上传订单数据至空运公司结算中心。
步骤S530,空运公司结算中心上传订单信息至发码平台,以通知发码平台进行扣款。
步骤S531,发码平台基于订单信息进行扣款。
步骤S532,发码平台在扣款成功后,向空运公司结算中心通知扣款成功。
步骤S533,空运公司结算中心通知空运公司服务信息平台支付成功。
步骤S534,发码平台通知终端扣款成功。
步骤S535,终端接收并显示扣款成功通知。
在步骤S528至步骤S535中,飞机落地后,机上中台***恢复联网之后,自动传输相关订单信息至空运公司服务信息平台,经过财务计费平台确认无误后,发送给二维码发码平台,对用户发起延时扣款。
图7为本申请实施例发码平台进行扣款的实现流程示意图,如图7所示,发码平台基于订单信息进行扣款可以通过以下步骤实现:
步骤S701,判断订单号是否重复。
这里,如果订单号重复,则结束流程;如果订单号不重复,则进入步骤S702。
步骤S702,验证二维码证书是否有效。
这里,发码平台可以对二维码证书中的签发有效期、用户信息等进行验证,判断二维码证书是否有效,如果二维码证书有效,则进入步骤S703,如果二维码证书无效,则结束流程。
步骤S703,验证二维码的TAC签名是否正确。
这里,发码平台基于用户身份信息、证书的有效期和二维码的生成时间对TAC签名进行验证,如果TAC签名正确,则进入步骤S704;如果TAC签名不正确,则结果流程。
在本实施例提供的机上支付方法中,用户通过展示其不可伪造的唯一身份二维码,并被空乘人员手持设备扫描并记录,然后与机上局域网中台控制***中的旅客信息进行比对,以确认用户身份的真实性,还会对二维码信息进行校验,校验通过则存储订单信息,二维码作为支付凭证。待飞机落地恢复网络后,机上局域网中台控制***自动上传订单信息,并通知进行扣款。这样,当机上旅客在购买机上商品如升舱服务、免税商品时,只需展示二维码即可完成机上支付,无需任何实体卡,非常方便快捷。另外用户需要持有发码平台颁发的卡证书才能生成二维码,卡证书经过发码平台的私钥签名,用户不可伪造,能够有效保证交易的真实性。
验码流程会校验二维码的时效性,并提取二维码中的姓名和身份证掩码,和机上局域网中台控制***中的旅客信息做比对,可以保证即便卡证书被盗别人也无法刷码。加之二维码中含有用户的分散密钥,空运公司无法伪造,这样就保证了用户和商户的双方皆不可伪造,保证交易的真实性。
另外,用户在开通卡证书时,发码平台会针对用户信用数据给与用户不同授信额度;在飞机起飞前更新实时黑名单给机上局域网中台控制***,以在用户刷码时,将用户信息与机上局域网中台控制***的黑名单做比对,能够有效防止恶意消费,从而提高延时扣款的成功率,保护商家利益。
基于前述的实施例,本申请实施例提供一种支付装置,该装置包括所包括的各模块、以及各单元所包括的各单元,可以通过计算机设备中的处理器来实现;当然也可通过具体的逻辑电路实现;在实施的过程中,处理器可以为中央处理器(CPU)、微处理器(MPU)、数字信号处理器(DSP)或现场可编程门阵列(FPGA)等。
图8为本申请实施例支付装置的组成结构示意图,如图8所示,所述支付装置800包括:第一获取模块801、第一验证模块802、第一生成模块503和第一发送模块804,其中:
所述第一获取模块801,用于当在飞行状态下自身未与支付***建立连接时,获取用户的支付信息;
所述第一验证模块802,用于对所述支付信息进行验证,得到第一验证结果;
所述第一生成模块803,用于如果所述第一验证结果为验证通过,基于所述支付信息生成订单信息,并基于所述订单信息完成与所述用户之间的交易;
所述第一发送模块804,用于在自身与所述支付***建立连接时,将所述订单信息发送给所述支付***,以使得所述支付***发起对所述用户的扣费。
在其他实施例中,所述支付信息至少包括离线支付标识码信息和支付金额,相应地,所述第一验证模块,包括:
第一验证单元,用于对所述离线支付标识码信息进行验证,得到第二验证结果;
第二验证单元,用于如果第二验证结果为验证通过,对所述支付金额进行验证,得到第一验证结果。
在其他实施例中,所述第一验证单元,包括:
第一验证子单元,用于分别对所述离线支付标识码信息中的证书数据、消息摘要数据和所述离线支付标识码的生成时间进行验证;
第一确定子单元,用于如果所述证书数据、消息摘要数据和所述离线支付标识码的生成时间都验证通过,确定所述第二验证结果为验证通过。
在其他实施例中,所述证书数据中至少包括用户信息、证书有效时间和签名数据,对应地,所述第一验证子单元还用于:
基于自身存储的用户校验信息,对所述证书数据中的用户信息进行验证;
基于自身的当前时间,对所述证书数据中的证书有效时间进行验证;
基于预先获取的验证公钥,对所述证书数据中的签名数据进行验证,其中,如果所述用户信息、证书有效时间和签名数据都验证通过表征所述证书数据验证通过。
在其他实施例中,所述第一验证子单元,还用于:
获取所述离线支付标识码的生成时间、证书有效起始时间、证书失效时间;
基于证书有效起始时间、证书失效时间和离线支付标识码的生成时间,对所述消息摘要数据中的MAC摘要进行验证。
在其他实施例中,所述第二验证单元,包括:
第一获取子单元,用于如果所述离线支付标识码信息验证通过,获取所述离线支付标识码信息对应的限制消费金额;
第二确定子单元,用于如果所述支付金额小于或者等于所述限制消费金额,确定所述第一验证结果为验证通过。
需要说明的是,上述支付装置实施例的描述,与上述方法实施例的描述是类似的,具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节,请参照本申请方法实施例的描述而理解。
本申请实施例再提供一种支付装置,所述支付装置包括:第一接收模块、第一校验模块、第二发送模块和结算模块,其中:
所述第一接收模块,用于接收商户收单***发送的订单信息;
所述第一校验模块,用于对所述订单信息进行校验;
所述第二发送模块,用于当所述订单信息校验通过后,将所述订单信息发送给发码平台,以通知发码平台进行扣款;
所述结算模块,用于基于接收到的扣款成功消息,进行对账和资金结算。
需要说明的是,上述支付装置实施例的描述,与上述方法实施例的描述是类似的,具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节,请参照本申请方法实施例的描述而理解。
本申请实施例再提供一种支付装置,所述支付装置包括:第二接收模块、第二验证模块、扣款模块和第三发送模块,其中:
所述第二接收模块,用于接收支付***发送的订单信息,所述订单信息至少包括订单号、支付金额、离线支付标识码信息;
所述第二验证模块,用于对所述订单号和所述离线支付标识码信息进行验证;
所述扣款模块,用于如果所述订单号和所述离线支付标识码信息验证通过,基于所述支付金额,对所述订单信息对应的用户账户进行扣款;
所述第三发送模块,用于将扣款成功消息发送给所述订单信息对应的终端和支付***。
在其他实施例中,所述支付装置还包括:
第三验证模块,用于基于接收到的请求消息,对终端对应的身份信息进行验证;所述请求消息用于请求获取生成离线支付标识码的证书数据;
第一确定模块,用于当所述身份信息通过验证后,确定所述身份信息对应的限制消费金额;
第二确定模块,用于至少基于所述身份信息和所述限制消息金额确定证书数据;
第四发送模块,用于将所述证书数据发送给所述终端,以使所述终端基于所述证书数据生成离线支付标识码。
在其他实施例中,所述第二确定模块,包括:
第一生成单元,用于基于所述身份信息和所述限制消费金额生成卡证书;
第一确定单元,用于基于用户发送请求消息的时间点及预设的证书有效时长,确定所述证书数据的有效时长;
签名单元,用于基于验证私钥至少对所述身份信息进行签名,得到签名数据;
第二生成单元,用于至少基于所述卡证书、证书数据的有效时长和所述签名数据,生成证书数据。
需要说明的是,上述支付装置实施例的描述,与上述方法实施例的描述是类似的,具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节,请参照本申请方法实施例的描述而理解。
需要说明的是,本申请实施例中,如果以软件功能模块的形式实现上述的支付方法,并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read Only Memory,ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样,本申请实施例不限制于任何特定的硬件和软件结合。
对应地,本申请实施例再提供一种存储介质,所述存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述的支付方法的步骤。
对应地,本申请实施例提供一种计算机设备,图9为本申请实施例计算机设备的组成结构示意图,如图9所示,所述计算机设备900包括:至少一个处理器901、至少一个通信总线902、用户接口903、至少一个外部通信接口904和存储器905。其中:
计算机设备900中的各个组件通过通信总线902耦合在一起。可理解,通信总线902用于实现这些组件之间的连接通信。通信总线902除包括数据总线之外,还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见,在图9中将各种总线都标为通信总线902。
用户接口903可以包括显示器、键盘、鼠标、轨迹球、点击轮、按键、按钮、触感板或者触摸屏等。
外部通信接口904可以包括标准的有线接口和无线接口。
存储器905可以是易失性存储器或非易失性存储器,也可包括易失性和非易失性存储器两者。其中,非易失性存储器可以是只读存储器(ROM,Read Only Memory)、可编程只读存储器(PROM,Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM,Erasable Programmable Read-Only Memory)、闪存(Flash Memory)等。易失性存储器可以是随机存取存储器(RAM,Random Access Memory),其用作外部高速缓存。通过示例性但不是限制性说明,许多形式的RAM可用,例如静态随机存取存储器(SRAM,Static RandomAccess Memory)、同步静态随机存取存储器(SSRAM,Synchronous Static Random AccessMemory)。本申请实施例描述的存储器905旨在包括这些和任意其它适合类型的存储器。
作为本申请实施例提供的方法采用软硬件结合实施的示例,本申请实施例所提供的方法可以直接体现为由处理器901执行的软件模块组合,软件模块可以位于存储介质中,存储介质位于存储器905,处理器901读取存储器905中软件模块包括的可执行指令,结合必要的硬件(例如,包括处理器901以及连接到通信总线902的其他组件)以实现上述实施例中提供的支付方法。
作为示例,处理器901可以是一种集成电路芯片,具有信号的处理能力,例如通用处理器、数字信号处理器(DSP,Digital Signal Processor),或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等,其中,通用处理器可以是微处理器或者任何常规的处理器等。
以上计算机设备和存储介质实施例的描述,与上述方法实施例的描述是类似的,具有同方法实施例相似的有益效果。对于本申请计算机设备和存储介质实施例中未披露的技术细节,请参照本申请方法实施例的描述而理解。
应理解,说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此,在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外,这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解,在本申请的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
在本申请所提供的几个实施例中,应该理解到,所揭露的设备和方法,可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。另外,所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口,设备或单元的间接耦合或通信连接,可以是电性的、机械的或其它形式的。
另外,在本申请各实施例中的各功能单元可以全部集成在一个处理单元中,也可以是各单元分别单独作为一个单元,也可以两个或两个以上单元集成在一个单元中;上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤。
或者,本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。
Claims (13)
1.一种飞行状态下的支付方法,其特征在于,所述方法包括:
当在飞行状态下商户收单***未与支付***建立连接时,所述商户收单***获取用户的支付信息;所述支付信息至少包括离线支付标识码信息和支付金额;所述离线支付标识码信息是基于从发码平台获取到的证书数据生成的,所述证书数据至少包括卡证书、证书有效时间和签名数据;
对所述支付信息进行验证,得到第一验证结果,其中,所述对所述支付信息进行验证,得到第一验证结果,包括:分别对所述离线支付标识码信息中的证书数据、消息摘要数据和所述离线支付标识码的生成时间进行验证;如果所述证书数据、消息摘要数据和所述离线支付标识码的生成时间都验证通过,确定第二验证结果为验证通过;如果所述第二验证结果为验证通过,对所述支付金额进行验证,得到第一验证结果;
如果所述第一验证结果为验证通过,基于所述支付信息生成订单信息,并基于所述订单信息完成与所述用户之间的交易;
在所述商户收单***与所述支付***建立连接时,将所述订单信息发送给所述支付***,以使得所述支付***发起对所述用户的扣费。
2.根据权利要求1中所述的方法,其特征在于,所述证书数据中至少包括用户信息、证书有效时间和签名数据,对应地,所述对所述离线支付标识码信息中的证书数据进行验证,包括:
基于自身存储的用户校验信息,对所述证书数据中的用户信息进行验证;
基于自身的当前时间,对所述证书数据中的证书有效时间进行验证;
基于预先获取的验证公钥,对所述证书数据中的签名数据进行验证,其中,如果所述用户信息、证书有效时间和签名数据都验证通过表征所述证书数据验证通过。
3.根据权利要求1中所述的方法,其特征在于,所述对所述离线支付标识码信息中消息摘要数据进行验证,包括:
获取所述离线支付标识码的生成时间、证书有效起始时间、证书失效时间;
基于证书有效起始时间、证书失效时间和离线支付标识码的生成时间,对所述消息摘要数据中的MAC摘要进行验证。
4.根据权利要求1中所述的方法,其特征在于,所述如果所述离线支付标识码信息验证通过,对所述支付金额进行验证,得到验证结果,包括:
如果所述离线支付标识码信息验证通过,获取所述离线支付标识码信息对应的限制消费金额;
如果所述支付金额小于或者等于所述限制消费金额,确定所述支付信息的验证结果为验证通过。
5.一种飞行状态下的支付方法,其特征在于,所述方法包括:
当商户收单***与支付***建立连接时,支付***接收商户收单***发送的订单信息,所述订单信息是所述商户收单***基于第一验证结果为验证通过的支付信息生成的,所述支付信息至少包括离线支付标识码信息和支付金额;所述离线支付标识码信息是基于从发码平台获取到的证书数据生成的,所述证书数据至少包括卡证书、证书有效时间和签名数据,所述第一验证结果是所述商户收单***分别对所述离线支付标识码信息中的证书数据、消息摘要数据和所述离线支付标识码的生成时间进行验证;如果所述证书数据、消息摘要数据和所述离线支付标识码的生成时间都验证通过,确定第二验证结果为验证通过;如果所述第二验证结果为验证通过,对所述支付金额进行验证得到的;
对所述订单信息进行校验;
当所述订单信息校验通过后,将所述订单信息发送给发码平台,以通知发码平台进行扣款;
基于接收到的扣款成功消息,所述支付***进行对账和资金结算。
6.一种飞行状态下的支付方法,其特征在于,所述方法包括:
发码平台接收支付***发送的订单信息,所述订单信息至少包括订单号、支付金额、离线支付标识码信息;所述离线支付标识码信息是基于从发码平台获取到的证书数据生成的,所述证书数据至少包括卡证书、证书有效时间和签名数据,所述订单信息是商户收单***基于第一验证结果为验证通过的支付信息生成的,所述支付信息至少包括所述离线支付标识码信息和所述支付金额,所述第一验证结果是所述商户收单***分别对所述离线支付标识码信息中的证书数据、消息摘要数据和所述离线支付标识码的生成时间进行验证;如果所述证书数据、消息摘要数据和所述离线支付标识码的生成时间都验证通过,确定第二验证结果为验证通过;如果所述第二验证结果为验证通过,对所述支付金额进行验证得到的;
对所述订单号和所述离线支付标识码信息进行验证;
如果所述订单号和所述离线支付标识码信息验证通过,基于所述支付金额,对所述订单信息对应的用户账户进行扣款;
将扣款成功消息发送给所述订单信息对应的终端和支付***。
7.根据权利要求6中所述的方法,其特征在于,所述方法还包括:
基于接收到的请求消息,对终端对应的身份信息进行验证;所述请求消息用于请求获取离线支付标识码的证书数据;
当所述身份信息通过验证后,确定所述身份信息对应的限制消费金额;
至少基于所述身份信息和所述限制消费金额确定证书数据;
将所述证书数据发送给所述终端,以使所述终端基于所述证书数据生成离线支付标识码。
8.根据权利要求7中所述的方法,其特征在于,所述至少基于所述身份信息和所述限制消费金额确定证书数据,包括:
基于所述身份信息和所述限制消费金额生成卡证书;
基于用户发送请求消息的时间点及预设的证书有效时长,确定所述证书数据的证书有效时间;
基于验证私钥至少对所述身份信息进行签名,得到签名数据;
至少基于所述卡证书、所述证书有效时间和所述签名数据,生成证书数据。
9.一种支付装置,其特征在于,所述支付装置包括:第一获取模块、第一验证模块、第一生成模块和第一发送模块,其中:
所述第一获取模块,用于当在飞行状态下自身未与支付***建立连接时,获取用户的支付信息;所述支付信息至少包括离线支付标识码信息和支付金额;所述离线支付标识码信息至少包括证书数据、消息摘要数据和离线支付标识码的生成时间;
所述第一验证模块,用于对所述支付信息进行验证,得到第一验证结果,所述第一验证模块还用于:分别对所述离线支付标识码信息中的证书数据、消息摘要数据和所述离线支付标识码的生成时间进行验证;如果所述证书数据、消息摘要数据和所述离线支付标识码的生成时间都验证通过,确定第二验证结果为验证通过;如果所述第二验证结果为验证通过,对所述支付金额进行验证,得到第一验证结果;
所述第一生成模块,用于如果所述第一验证结果为验证通过,基于所述支付信息生成订单信息,并基于所述订单信息完成与所述用户之间的交易;
所述第一发送模块,用于在自身与所述支付***建立连接时,将所述订单信息发送给所述支付***,以使得所述支付***发起对所述用户的扣费。
10.一种支付装置,其特征在于,所述支付装置包括:第一接收模块、第一校验模块、第二发送模块和结算模块,其中:
所述第一接收模块,用于当商户收单***与支付***建立连接时,接收商户收单***发送的订单信息,所述订单信息是所述商户收单***基于第一验证结果为验证通过的支付信息生成的,所述支付信息至少包括离线支付标识码信息和支付金额;所述离线支付标识码信息是基于从发码平台获取到的证书数据生成的,所述证书数据至少包括卡证书、证书有效时间和签名数据,所述第一验证结果是所述商户收单***分别对所述离线支付标识码信息中的证书数据、消息摘要数据和所述离线支付标识码的生成时间进行验证;如果所述证书数据、消息摘要数据和所述离线支付标识码的生成时间都验证通过,确定第二验证结果为验证通过;如果所述第二验证结果为验证通过,对所述支付金额进行验证得到的;
所述第一校验模块,用于对所述订单信息进行校验;
所述第二发送模块,用于当所述订单信息校验通过后,将所述订单信息发送给发码平台,以通知发码平台进行扣款;
所述结算模块,用于基于接收到的扣款成功消息,进行对账和资金结算。
11.一种支付装置,其特征在于,所述支付装置包括:第二接收模块、第二验证模块、扣款模块和第三发送模块,其中:
所述第二接收模块,用于接收支付***发送的订单信息,所述订单信息至少包括订单号、支付金额、离线支付标识码信息;所述离线支付标识码信息是基于从发码平台获取到的证书数据生成的,所述证书数据至少包括卡证书、证书有效时间和签名数据,所述订单信息是商户收单***基于第一验证结果为验证通过的支付信息生成的,所述支付信息至少包括所述离线支付标识码信息和所述支付金额,所述第一验证结果是所述商户收单***分别对所述离线支付标识码信息中的证书数据、消息摘要数据和所述离线支付标识码的生成时间进行验证;如果所述证书数据、消息摘要数据和所述离线支付标识码的生成时间都验证通过,确定第二验证结果为验证通过;如果所述第二验证结果为验证通过,对所述支付金额进行验证得到的;
所述第二验证模块,用于对所述订单号和所述离线支付标识码信息进行验证;
所述扣款模块,用于如果所述订单号和所述离线支付标识码信息验证通过,基于所述支付金额,对所述订单信息对应的用户账户进行扣款;
所述第三发送模块,用于将扣款成功消息发送给所述订单信息对应的终端和支付***。
12.一种计算机设备,其特征在于,所述计算机设备至少包括:存储器、通信总线和处理器,其中:
所述存储器,用于存储计算机程序;
所述通信总线,用于实现处理器和存储器之间的连接通信;
所述处理器,用于执行存储器中存储的计算机程序,以实现权利要求1至4中任一项所述的支付方法,或者权利要求5所述的支付方法,或者权利要求6至8中任一项所述的支付方法的步骤。
13.一种存储介质,其特征在于,所述存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现权利要求1至4中任一项所述的支付方法,或者权利要求5所述的支付方法,或者权利要求6至8中任一项中所述的支付方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910290481.7A CN111815326B (zh) | 2019-04-11 | 2019-04-11 | 一种飞行状态下的支付方法及其装置、设备和存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910290481.7A CN111815326B (zh) | 2019-04-11 | 2019-04-11 | 一种飞行状态下的支付方法及其装置、设备和存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111815326A CN111815326A (zh) | 2020-10-23 |
CN111815326B true CN111815326B (zh) | 2024-05-28 |
Family
ID=72844257
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910290481.7A Active CN111815326B (zh) | 2019-04-11 | 2019-04-11 | 一种飞行状态下的支付方法及其装置、设备和存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111815326B (zh) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114980119B (zh) * | 2020-12-02 | 2024-06-11 | 支付宝(杭州)信息技术有限公司 | 一种设备之间的连接方法、装置及设备 |
CN112581233B (zh) * | 2020-12-24 | 2024-01-26 | 北京顺达同行科技有限公司 | 订单离线操作的方法、装置、设备和计算机可读存储介质 |
CN113344572A (zh) * | 2021-06-23 | 2021-09-03 | 支付宝(杭州)信息技术有限公司 | 一种离线支付方法、装置及设备 |
CN113850579A (zh) * | 2021-09-27 | 2021-12-28 | 支付宝(杭州)信息技术有限公司 | 一种离线支付的授权、离线支付、收款方法及装置 |
CN114648331A (zh) * | 2022-03-22 | 2022-06-21 | 拉扎斯网络科技(上海)有限公司 | 订单支付方法、装置、计算机设备及计算机可读存储介质 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105868981A (zh) * | 2016-04-11 | 2016-08-17 | 万集融合信息技术(北京)有限公司 | 一种移动支付方法、*** |
WO2018040653A1 (zh) * | 2016-08-31 | 2018-03-08 | 中城智慧科技有限公司 | 一种基于nfc的离线支付方法 |
CN108053205A (zh) * | 2018-01-25 | 2018-05-18 | 苏宁云商集团股份有限公司 | 一种快速支付方法及设备 |
CN108229911A (zh) * | 2017-12-20 | 2018-06-29 | 中智关爱通(上海)科技股份有限公司 | 一种支付方法、***、服务器、终端及其存储介质 |
CN109087087A (zh) * | 2018-06-30 | 2018-12-25 | 企银易(北京)科技有限公司 | 一种扫码支付方法及*** |
CN109345241A (zh) * | 2018-09-14 | 2019-02-15 | 企银易(北京)科技有限公司 | 一种扫码支付方法及*** |
-
2019
- 2019-04-11 CN CN201910290481.7A patent/CN111815326B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105868981A (zh) * | 2016-04-11 | 2016-08-17 | 万集融合信息技术(北京)有限公司 | 一种移动支付方法、*** |
WO2018040653A1 (zh) * | 2016-08-31 | 2018-03-08 | 中城智慧科技有限公司 | 一种基于nfc的离线支付方法 |
CN108229911A (zh) * | 2017-12-20 | 2018-06-29 | 中智关爱通(上海)科技股份有限公司 | 一种支付方法、***、服务器、终端及其存储介质 |
CN108053205A (zh) * | 2018-01-25 | 2018-05-18 | 苏宁云商集团股份有限公司 | 一种快速支付方法及设备 |
CN109087087A (zh) * | 2018-06-30 | 2018-12-25 | 企银易(北京)科技有限公司 | 一种扫码支付方法及*** |
CN109345241A (zh) * | 2018-09-14 | 2019-02-15 | 企银易(北京)科技有限公司 | 一种扫码支付方法及*** |
Also Published As
Publication number | Publication date |
---|---|
CN111815326A (zh) | 2020-10-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111815326B (zh) | 一种飞行状态下的支付方法及其装置、设备和存储介质 | |
EP3410374B1 (en) | Credit payment method and device based on mobile terminal p2p | |
RU2711464C2 (ru) | Проверка транзакции, осуществляемая несколькими устройствами | |
US11238431B2 (en) | Credit payment method and apparatus based on card emulation of mobile terminal | |
CN107408170B (zh) | 认证激活的增强现实显示装置 | |
CN108074095B (zh) | 一种票务处理方法和装置 | |
CN103562973B (zh) | 用于快捷安全处理移动设备交易的电子*** | |
KR101129318B1 (ko) | 생체인식 카드를 활용한 공용시설물에 대한 대여 서비스 방법 및 시스템 | |
US20220343334A1 (en) | Payment Verification Using Multi-Factor Authentication | |
US11210650B2 (en) | Credit payment method and apparatus based on mobile terminal embedded secure element | |
US20160203475A1 (en) | Method and system for making a secure payment transaction | |
AU2008202139A1 (en) | Internet business security system | |
US9619798B2 (en) | System and method for providing emergency prepaid card | |
CN103400265A (zh) | 一种基于位置信息的快速支付方法及*** | |
KR20190143247A (ko) | 대중교통이용에 따른 탄소배출권 인증시스템 | |
KR101782436B1 (ko) | 결제 단말 장치 및 그를 이용한 카드 결제 거래 취소 방법 | |
KR20110112795A (ko) | 생체인식 카드를 활용한 공용시설물에 대한 대여 서비스 방법 및 시스템 | |
KR100920175B1 (ko) | 이동통신 단말기를 이용한 결제 시스템 및 그 결제 방법 | |
KR102442132B1 (ko) | 토큰 결제용 블록체인 id 카드 및 이를 이용한 토큰 결제 시스템 | |
KR102640368B1 (ko) | 토큰 결제용 블록체인 결제 단말기 및 이를 이용한 토큰 결제 시스템 | |
US11783315B2 (en) | Transaction system architecture and methods | |
JP7024738B2 (ja) | サーバ及び認証方法 | |
KR20050015475A (ko) | 인증 코드를 이용한 결제 시스템 및 방법 | |
KR20090002042A (ko) | 카드 매출전표의 전자관리 시스템 및 방법 | |
KR20090107658A (ko) | 조회요청 전문 처리 방법 및 시스템과 이를 위한 기록매체 |
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: 40030661 Country of ref document: HK |
|
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |