CN114463007A - 近景支付方法、介质、装置和计算设备 - Google Patents

近景支付方法、介质、装置和计算设备 Download PDF

Info

Publication number
CN114463007A
CN114463007A CN202210117794.4A CN202210117794A CN114463007A CN 114463007 A CN114463007 A CN 114463007A CN 202210117794 A CN202210117794 A CN 202210117794A CN 114463007 A CN114463007 A CN 114463007A
Authority
CN
China
Prior art keywords
payment
certificate
user certificate
target
transaction
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.)
Pending
Application number
CN202210117794.4A
Other languages
English (en)
Inventor
潘威
熊旭
牛魁元
余洋
刘庆生
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wangyibao Co ltd
Original Assignee
Wangyibao Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Wangyibao Co ltd filed Critical Wangyibao Co ltd
Priority to CN202210117794.4A priority Critical patent/CN114463007A/zh
Publication of CN114463007A publication Critical patent/CN114463007A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821Electronic credentials
    • G06Q20/38215Use of certificates or encrypted proofs of transaction rights
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821Electronic credentials
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/401Transaction verification
    • G06Q20/4014Identity check for transactions
    • G06Q20/40145Biometric identity checks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/409Device specific authentication in transaction processing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56Financial cryptography, e.g. electronic payment or e-cash

Abstract

本公开实施例提供的近景支付方法、介质、装置和计算设备中,在支付过程中,付款设备和收款设备建立近景连接,并由收款设备对目标交易进行签发生成第一支付凭证,再由付款设备对第一支付凭证进行校验,并签发目标支付凭证,最后由交易服务器对二者签发的支付凭证进行校验,并在校验通过时对目标交易进行核销。在此交易过程中,交易过程无需强依赖交易服务器,且由于付款方和收款方建立近景连接,无需依赖外部网络环境,当出现无网络、网络信号差、高峰网络拥塞或者交易服务器故障等情况时,也可以进行正常交易,同时可以避免外部网络的安全问题;另外,通过收款设备、付款设备和交易服务器对交易的多重验证,可以保障交易的可靠性。

Description

近景支付方法、介质、装置和计算设备
技术领域
本公开的实施方式涉及支付技术领域,更具体地,本公开的实施方式涉及一种近景支付方法、介质、装置和计算设备。
背景技术
本部分旨在为权利要求书中陈述的本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
随着互联网的普及,移动支付渐渐融入到生活,为社会生活、生产带来了诸多便利。移动支付又可分为远景支付和近景支付,其中,近景支付是一种需要用户近距离接触、面对面交易的支付方式,如现金交易、NFC支付、扫码支付等。
然而,在这些支付的技术中,交易过程强依赖后端的交易服务器,且付款方和收款方均需要稳定安全的网络环境,当出现无网络、网络信号差、高峰网络拥塞或者交易服务器故障等情况时,交易则无法正常进行,若使用未知的无线网络,网络环境安全则无法保证。
发明内容
本公开实施方式提供一种近景支付方法、介质、装置和计算设备,用于解决目前的近景支付过程中对交易服务器和网络的依赖性强、安全性低的技术问题。
在本公开实施例的第一方面中,提供一种近景支付方法,应用于收款设备,该近景支付方法包括:基于收款设备与付款设备建立的近景连接,获取付款设备的第一用户证书,第一用户证书用于校验付款设备的身份;对付款设备对应的目标交易进行签发,生成目标交易对应的第一支付凭证;根据第一用户证书中的第一公钥对第一支付凭证进行加密,并基于近景连接,向付款设备发送加密后的第一支付凭证,第一支付凭证用于付款设备对目标交易进行校验,并生成目标交易对应的目标支付凭证;接收付款设备基于近景连接发送的目标支付凭证,并在收款设备与交易服务器建立通信时起通信连接后,向交易服务器发送目标支付凭证,目标支付凭证用于交易服务器对目标交易进行核销。
在本公开实施例的第二方面中,提供一种近景支付方法,应用于付款设备,近景支付方法包括:基于付款设备与收款设备建立的近景连接,获取收款设备的第二用户证书,第二用户证书用于校验收款设备的身份;获取收款设备签发的目标交易的第一支付凭证;根据第一支付凭证,生成目标交易的目标支付凭证;根据第二用户证书中的第二公钥对目标支付凭证进行加密,并基于近景连接,向收款设备发送加密后的目标支付凭证,以使收款设备向交易服务器发送目标支付凭证;和/或,在付款设备与交易服务器建立起通信连接后,根据交易服务器的根证书公钥对目标支付凭证进行加密,并向交易服务器发送加密后的目标支付凭证,目标支付凭证用于交易服务器对目标交易进行核销。
在本公开实施方式的第三方面中,提供一种近景支付方法,应用于交易服务器,近景支付方法包括:接收收款设备和/或付款设备发送的目标订单的目标支付凭证;基于目标支付凭证,对目标订单进行核销,目标支付凭证中包括第一支付凭证以及付款设备签发的第四数字签名,第一支付凭证中包括订单信息、收款设备的第二用户证书、付款设备的第一用户证书以及收款设备签发的第一数字签名。
在本公开实施方式的第四方面中,提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机执行指令,当处理器执行计算机执行指令时,实现如第一方面、第二方面和第三方面中任一项的近景支付方法。
在本公开实施方式的第五方面中,提供一种近景支付装置,应用于收款设备,近景支付装置包括:获取模块,用于基于收款设备与付款设备建立的近景连接,获取付款设备的第一用户证书,第一用户证书用于校验付款设备的身份;签发模块,用于对付款设备对应的目标交易进行签发,生成目标交易对应的第一支付凭证;发送模块,根据第一用户证书中的第一公钥对第一支付凭证进行加密,并基于近景连接,向付款设备发送加密后的第一支付凭证,第一支付凭证用于付款设备对目标交易进行校验,并生成目标交易对应的目标支付凭证,接收付款设备基于近景连接发送的目标支付凭证,并在收款设备与交易服务器建立通信时起通信连接后,向交易服务器发送目标支付凭证,目标支付凭证用于交易服务器对目标交易进行核销。
在本公开实施方式的第六方面中,提供一种近景支付装置,应用于付款设备,近景支付装置包括:第一获取模块,用于基于付款设备与收款设备建立的近景连接,获取收款设备的第二用户证书,第二用户证书用于校验收款设备的身份;第二获取模块,用于获取收款设备签发的目标交易的第一支付凭证;处理模块,用于根据第一支付凭证,生成目标交易的目标支付凭证;发送模块,用于根据第二用户证书中的第二公钥对目标支付凭证进行加密,并基于近景连接,向收款设备发送加密后的目标支付凭证,以使收款设备向交易服务器发送目标支付凭证;和/或,在付款设备与交易服务器建立起通信连接后,根据交易服务器的根证书公钥对目标支付凭证进行加密,并向交易服务器发送加密后的目标支付凭证,目标支付凭证用于交易服务器对目标交易进行核销。
在本公开实施方式的第七方面中,还提供一种近景支付装置,应用于交易服务器,近景支付装置包括:接收模块,用于接收收款设备和/或付款设备发送的目标订单的目标支付凭证;处理模块,用于基于目标支付凭证,对目标订单进行核销,目标支付凭证中包括第一支付凭证以及付款设备签发的第四数字签名,第一支付凭证中包括订单信息、收款设备的第二用户证书、付款设备的第一用户证书以及收款设备签发的第一数字签名。
在本公开实施方式的第八方面中,还提供一种计算设备,包括:至少一个处理器和存储器;存储器存储有计算机执行指令;至少一个处理器执行存储器存储的计算机执行指令,实现如第一方面、第二方面和第三方面中任一方面中的近景支付方法。
在本公开实施方式的第九方面中,还提供一种计算机程序产品,计算机程序产品包括计算机程序;计算机程序被执行时实现如第一方面、第二方面和第三方面中任一方面中的近景支付方法。
本公开实施例提供的近景支付方法、介质、装置和计算设备中,在支付过程中,付款设备和收款设备建立近景连接,并由收款设备对目标交易进行签发生成第一支付凭证,再由付款设备对第一支付凭证进行校验,并签发目标支付凭证,最后由交易服务器对二者签发的支付凭证进行校验,并在校验通过时对目标交易进行核销。在此交易过程中,交易过程无需强依赖交易服务器,且由于付款方和收款方建立近景连接,无需依赖外部网络环境,当出现无网络、网络信号差、高峰网络拥塞或者交易服务器故障等情况时,也可以进行正常交易,同时可以避免外部网络的安全问题;另外,通过收款设备、付款设备和交易服务器对交易的多重验证,可以保障交易的可靠性。
附图说明
通过参考附图阅读下文的详细描述,本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中,以示例性而非限制性的方式示出了本公开的若干实施方式,其中:
图1为本公开实施方式提供的应用场景示意图;
图2为本公开的实施例提供的近景支付方法的流程示意图一;
图3为本公开的实施例提供的近景支付方法的流程示意图二;
图4为本公开实施例提供的交易凭证获取方法的原理示意图;
图5为本公开的实施例提供的付款设备的第一用户证书获取过程的流程示意图;
图6为本公开实施例提供的用户证书获取方法的原理示意图;
图7为本公开的实施例提供的收款设备的第二用户证书获取过程的流程示意图;
图8为本公开实施例提供的服务器对目标订单进行核销的原理示意图;
图9为本公开示例性实施例提供的存储介质的结构示意图;
图10为本公开实施例提供的近景支付装置的结构示意图一;
图11为本公开实施例提供的近景支付装置的结构示意图二;
图12为本公开实施例提供的近景支付装置的结构示意图三;
图13为本公开实施例提供的计算设备的结构示意图;
在附图中,相同或对应的标号表示相同或对应的部分。
具体实施方式
下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解,给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开,而并非以任何方式限制本公开的范围。相反,提供这些实施方式是为了使本公开更加透彻和完整,并且能够将本公开的范围完整地传达给本领域的技术人员。
本领域技术人员知道,本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此,本公开可以具体实现为以下形式,即:完全的硬件、完全的软件(包括固件、驻留软件、微代码等),或者硬件和软件结合的形式。
在本文中,需要理解的是,所涉及的术语以及术语的含义如下:
核销:进行往来业务挂账后的一种处理方法,比如付款都通过预付科目先挂账,等和对方结算时挂到应付账款,这时再对预付款和应付款进行核销,以完成整个交易。
非对称加密算法(Asymmetric cryptography)是密码学的一种加密算法,常见算法有RSA算法、Elgamal算法、背包算法、Rabin、Diffie-Hellman算法、椭圆曲线加密算法ECC等。
非对称加密需要一个公开密钥和一个私有密钥,其中,公钥用于加密,私钥用于解密,使用公钥把明文加密后所得的密文,只能用相对应的私钥才能解密并得到原本的明文。
此外,附图中的任何元素数量均用于示例而非限制,以及任何命名都仅用于区分,而不具有任何限制含义。
下面参考本公开的若干代表性实施方式,详细阐释本公开的原理和精神。
发明概述
发明人发现,现有的交易过程强依赖后端的交易服务器,且付款方和收款方均需要稳定安全的网络环境,当出现无网络、网络信号差、高峰网络拥塞或者交易服务器故障等情况时,交易则无法正常进行,若使用未知的无线网络,网络环境安全则无法保证。
有鉴于此,本公开的实施例提供一种近景支付方法,在支付过程中,由付款方和收款方之间建立近景连接,无需依赖外部网络环境,当出现无网络、网络信号差、高峰网络拥塞或者交易服务器故障等情况时,也可以进行正常交易,同时可以避免外部网络的安全问题;另外,通过收款设备、付款设备和交易服务器对交易的多重验证,可以保障交易的可靠性。
应用场景总览
首先参考图1,图1为本公开实施方式提供的应用场景示意图,该应用场景涉及的设备包括收款设备101、付款设备102和交易服务器103.
其中,交易服务器103与收款设备101、付款设备102均可通过网络进行通信,收款设备101和付款设备102之间可以建立近景连接。
其中,收款设备101和付款设备102可以是个人数字处理(personal digitalassistant,简称PDA)设备、具有无线通信功能的手持设备(例如智能手机、平板电脑)、计算设备(例如个人电脑(personal computer,简称PC))、车载设备、可穿戴设备(例如智能手表、智能手环)、智能家居设备(例如智能显示设备)等,图中以手机为例示出,但不以此为限定。
交易服务器103可以为支付应用程序的产品服务器,在交易服务器103中部署有支付应用程序的用户数据、业务数据等,从而向多个设备(例如收款设备101和付款设备102)的用户提供有关该支付应用程序的支付服务。
相应的,收款设备101和付款设备102安装有支付应用程序的客户端,用户可以通过该客户端使用产品服务器中提供的支付服务。
示例性方法
下面结合图1的应用场景,参考图2-8来描述根据本公开示例性实施方式的近景支付方法。需要注意的是,上述应用场景仅是为了便于理解本公开的精神和原理而示出,本公开的实施方式在此方面不受任何限制。相反,本公开的实施方式可以应用于适用的任何场景。
参考图2,图2为本公开的实施例提供的近景支付方法的流程示意图一。如图2所示,该近景支付方法包括如下步骤:
S201、收款设备基于收款设备与付款设备建立的近景连接,获取付款设备的第一用户证书。
S202、付款设备基于付款设备与收款设备建立的近景连接,获取收款设备的第二用户证书。
其中,第一用户证书用于校验付款设备的身份,第二用户证书用于校验收款设备的身份,在身份校验过程中,主要用于校验第一用户证书和第二用户证书是否由交易服务器签发。至于用户身份的校验方法,以及用户证书的签发方法,在后续实施例中示出。
本公开实施例中,在交易前,收款设备和付款设备双方通过交换用户证书,并进行相互校验,可以防止非法冒充交易身份,从而保障近景连接中信息传输过程的安全性,同时保障收款方和付款方的资金安全性,提升交易过程的可靠性。
在本公开的实施例中,收款设备与付款设备的近景连接方式包括但不限于以下任意一种:NFC连接、蓝牙连接、远距离无线电连接(Long Range Radio,LoRa)或者WIFI连接等,本公开实施例不做限定。
S203、收款设备对付款设备对应的目标交易进行签发,生成目标交易对应的第一支付凭证。
S204、收款设备根据第一用户证书中的第一公钥对第一支付凭证进行加密,并基于近景连接,向付款设备发送加密后的第一支付凭证。
其中,目标交易为收款设备和付款设备建立近景连接后,由收款设备和付款设备所发起的交易。
在本公开实施例中,收款设备会对目标交易进行认证和授权,从而生成第一支付凭证,应理解,离线环境支付其实是一个记账过程,第一支付凭证即为收款设备记录的交易详情以及支付过程的数据格式,至于第一支付凭证的内容和具体生成方式,在后续实施例中示出。
进一步的,在获得第一支付凭证之后,采用付款设备的第一公钥对第一支付凭证进行加密,并基于近景连接将加密后的第一支付凭证发送给付款设备。
本公开实施例中,通过第一公钥对第一支付凭证进行加密,可以与付款设备之间建立加密通信隧道,由于只有付款设备和收款设备才能够对加密内容进行解密,此过程可以进一步加强交易过程的安全性。
S205、付款设备根据第一支付凭证,生成目标交易的目标支付凭证。
相应的,付款设备根据其自身的第一私钥对接收到的第一支付凭证进行解密,并根据第一支付凭证生成目标支付凭证。
类似的,目标支付凭证即为付款设备记录交易详情以及支付过程的数据格式,在接收到第一支付凭证之后,首先对第一支付凭证进行校验,当校验通过时,根据第一支付凭证生成目标支付凭证,至于目标支付凭证的内容和具体生成方式,在后续实施例中示出。
本公开实施例中,通过付款设备和收款设备双方对目标交易进行多重校验及授权,可以确保支付凭证不被篡改、不可抵赖,从而确保支付过程的合法有效、支付结果可回溯,进而保障保证付款方和收款方的资金安全。
S206、付款设备根据第二用户证书中的第二公钥对目标支付凭证进行加密,并基于近景连接,向收款设备发送加密后的目标支付凭证,以使收款设备向交易服务器发送目标支付凭证。
S207、收款设备接收付款设备基于近景连接发送的目标支付凭证,并在收款设备与交易服务器建立起通信连接后,向交易服务器发送目标支付凭证。
在一种实施方式中,付款设备在生成目标支付凭证之后,可以基于近景连接,直接将目标支付凭证发送给收款设备,由收款设备将目标支付凭证转发给交易服务器,由交易服务器进行核销进而完成交易。
可选的,收款设备在向交易服务器发送目标支付凭证前,可以采用交易服务器的根证书公钥对目标支付凭证进行加密。
本申请实施例中,通过根证书公钥在收款设备与交易服务器之间建立加密通信隧道,由于只有收款设备和交易服务器才能够进行解密,此过程可以进一步加强交易过程的安全性。
在交易服务器完成核销后,会对付款设备对应的账户进行扣款,而收款设备会收到相应的款项。因此,对于付款方而言,可能会出现不想付款、拖延付款的情况,进而导致付款方推进交易的核销进程的主动性较低,而对于收款方而言,其可能更需要尽快收到款项,使得收款方推进交易的核销进程的主动性较高。在本公开的其中一实施例中,在付款设备生成目标支付凭证时,将目标支付凭证发送给收款设备,由收款设备向交易服务器发送目标支付凭证进而完成核销,可以一定程度上的提升交易进度,防止由于付款设备的主动性差而导致无法完成核销的情况,保障收款方的权益。
另外,在本公开的其中一实施例中,如果收款设备所在场所具备较好的联网条件,则可以基于近景连接让付款设备将支付凭证发送给收款设备,并由收款设备统一同步到交易服务器,从而可以使得交易服务器进行实时的核销,并实时反馈交易结果,对于商场、超市或者其他大额交易等场景中,由此可以在保证交易安全性的同时,提升交易过程的实时性。
并且,付款设备在向收款设备发送目标支付凭证前,采用收款设备的第二公钥对目标支付凭证进行加密,可以与收款设备之间建立加密通信隧道,由于只有付款设备和收款设备才能够进行解密,此过程可以进一步加强交易过程的安全性。
S208、付款设备在付款设备与交易服务器建立起通信连接后,根据交易服务器的根证书公钥对目标支付凭证进行加密,并向交易服务器发送加密后的目标支付凭证。
需要说明的是,当收款设备位于较为固定、且网络环境较差的场景,例如是,山区、地下通道等区域中时,这就导致收款设备可能长期处于离线状态,而付款设备通常移动能力较强,可能不会长期处于离线状态。因此,通过在本公开的其中一实施例中,可以由付款设备向交易服务器发送目标支付凭证,从而在收款方未及时上传目标交易凭证时,尽快推进交易的核销进程,进一步保障目标交易的时效性和可靠性。
另外,付款设备在向交易服务器发送目标支付凭证前,采用交易服务器的根证书公钥对目标支付凭证进行加密,可以与交易服务器之间建立加密通信隧道,由于只有付款设备和交易服务器才能够进行解密,此过程可以进一步加强交易过程的安全性。
需要说明的是,步骤S207和步骤S208可以择一执行,也可以均执行,且,当步骤S207和步骤S208均执行时,对于其执行顺序不做严格限定,例如,可以先执行步骤S208再执行步骤S207。
在一种可选的实施方式中,在步骤S207和S208中,收款设备和/或付款设备在向交易服务器发送目标交易凭证时,可以进行分批发送。
具体的,对于同一付款设备(或者是收款设备)在与交易服务器建立通信连接后,一方面,可以根据未核销的各交易对应的交易时间,自动向交易服务器分批次发送目标支付凭证。对于交易时间的划分,本公开实施例不做具体限定,例如,可以以30分钟、1个小时、24小时为时间间隔,每隔一段时间发送该段时间所产生的交易的目标支付凭证,或者,也可以设置固定的发送时间,在该发送时间发送该时间之前产生的但还未核销的交易的目标支付凭证,例如,设置时间点分别为11:00和18:00,则在11:00处发送11:00前的交易对应的目标支付凭证,在18:00发送11:00~18:00之间的交易对应的目标支付凭证。
需要说明的是,交易时间可以为收款设备和付款设备建立连接的时间,也可以为目标支付凭证的生成时间等,且每个批次的起始时间可以为固定时间(例如,设置时间点),也可以为上个批次上传目标交易凭证的结束时间。另外,用户还可以根据需求设置目标支付凭证的发送间隔时长和发送时间。
本公开实施例中,通过分批次发送目标交易凭证,可以降低设备的发送次数,进而降低设备的功耗和流量消耗,且分批次上传目标支付凭证,可以便于用户对交易的管理。另外,由于此种方式中,用户可以根据需求设置发送时间和时间间隔,可以满足用户的个性化需求,提升用户体验。
在另一方面,还可以根据交易类别向交易服务器分批发送目标支付凭证。具体的,交易类别可以包括:支付账户类别(例如是支付宝支付、微信支付、网银支付等)、商品类别等。
示例性的,可以将同一支付类别的交易作为同一批次发送给交易服务器,或者将同一商品类别的交易作为同一批次发送给交易服务器。
本公开实施例中,根据交易类别对目标支付凭证进行分批发送,可以降低设备的发送次数,进而降低设备的功耗和流量消耗,且分批次上传目标支付凭证,可以便于用户对交易的管理,使得付款方或收款方对交易进行核对、记账等处理,提升用户体验。
S209、基于目标支付凭证,对目标订单进行核销。
其中,目标支付凭证中包括第一支付凭证以及付款设备签发的第四数字签名,第一支付凭证中包括订单信息、收款设备的第二用户证书、付款设备的第一用户证书以及收款设备签发的第一数字签名。
本公开实施例中,交易服务器对第一支付凭证中的第一数字签名,以及目标支付凭证中的第四数字签名进行核验,当二者校验通过时,则对当前交易进行核销,并进行归档、资金划账等操作,从而完成整个交易。需要说明的是,至于交易服务器对目标订单的核销方案,在后续实施例中示出。
本公开实施例中,交易过程无需强依赖交易服务器,且由于付款方和收款方建立近景连接,无需依赖外部网络环境,当出现无网络、网络信号差、高峰网络拥塞或者交易服务器故障等情况时,也可以进行正常交易,同时可以避免外部网络的安全问题;另外,通过收款设备、付款设备和交易服务器对目标交易进行多重验证,可以保障交易的可靠性。
并且,相关技术中,由于交易过程强依赖交易服务器,在一些食堂、公交、景区、企业内部消费等小额、高频的交易场景中,同一时段可能需要交易服务器对多个交易进行同步处理,造成交易服务器的拥堵,使得交易进程缓慢,甚至极容易出现交易失败的情况,严重影响用户的交易体验。通过本公开实施例提供的方案,在交易过程中,无需强依赖交易服务器,可以在交易时先生成目标支付凭证,从而对交易进行“挂账”处理,以实现在设备本地直接进行支付,进而提升支付效率;当各付款设备/收款设备网络正常时,由于各付款设备/和收款设备与交易服务器建立连接的时间不同,且可以人为的自由选择上传目标支付凭证的时间,因而各设备可以避免同时向交易服务器发送目标支付凭证的情况,实现分散性的向服务器发送目标交易凭证,避免高并发的情况,从而使得服务器对交易进行分散性的核销,从而有效解决弱网络、高并发、耗时长等交易场景的交易问题,降低交易服务器的处理压力,提升用户的交易体验。
接下来,结合图3对本公开实施例中付款设备和收款设备的交易过程进行详细说明:
图3为本公开的实施例提供的近景支付方法的流程示意图二。如图3所示,近景支付方法具体包括如下步骤:
S301、收款设备根据收款设备的连接信息,生成二维码和/或NFC标签。
首先,根据收款设备的连接方式,生成连接信息,其中,连接方式例如是蓝牙连接、WiFi连接、Lora连接、NFC连接等等。
相应的,若收款设备支持WIFI或蓝牙连接,则生成包含收款设备连接信息的二维码;若收款设备支持NFC连接,则生成包含收款设备的连接信息的NFC标签。应理解,若收款设备同时支持多种方式,可以生成提示信息,由收款方根据提示信息选择所需的连接方式。
具体的,收款设备的连接信息的数据大小为预设大小,且连接信息的内容为预设格式的连接标识和口令,示例性的,预设格式可以为{T:WiFi/Bluetooth;S:DeviceName;P:password},即{T:连接方式;S:设备名称;P:密码},例如是{T:WiFi;S:NetEase-5G;P:123456}、{T:Bluetooth;S:DeviceName;P:PinCode}等,此处不再一一示出。
S302、付款设备基于收款设备生成的二维码和/或NFC标签,与收款设备建立近景连接。
具体的,在连接过程中,若付款设备支持NFC功能,则优先使用NFC功能来读取卖方NFC标签内容,从而实现二者的连接。
相应的,若NFC标签内容读取失败,则可以自动打开相机,提示付款方通过收款方提供的二维码进行连接,并在完成扫码后,解析二维码包含的连接信息,从而根据连接信息与收款设备建立WiFi或蓝牙连接(具体连接方式可以依据设备所支持的连接方式而定,也可以依据用户的选择而定)。
可选的,若扫码失败,则可以获取周围的收款设备列表,从而引导用户手动连接该目标交易对应的收款设备。
本公开实施例中,通过提供多种连接方式,可以满足不同类型设备的支付需求,提升连接过程的可靠性,保障用户体验。
S303、收款设备基于与付款设备建立的近景连接,获取付款设备的第一用户证书。
S304、收款设备基于交易服务器的根证书公钥,对第三数字签名进行解析,获得第三摘要信息。
S305、收款设备基于数字签名算法,对第一原始用户证书进行加签,获得第四摘要信息。
S306、收款设备响应于第三摘要信息和第四摘要信息相匹配,确定付款设备的身份校验成功。
其中,第一用户证书中包括第一原始用户证书和第三数字签名。
本公开实施例中,首先采用根证书公钥对第三数字签名进行解析,若能够得到第三摘要信息,则说明第三数字签名是交易服务器签发获得的;相应的,若无法采用根证书公钥对第三数字签名进行解析,则说明该第三数字签名非交易服务器签发的,此时,中断交易,从而防止发生安全隐患。
需要说明的是,对于数字签名算法的具体类型,本公开实施例不做限定,例如,可以为哈希(hash)算法、DSA算法、RSA算法等。
应理解,数字签名算法是通过一个单向函数,即对要传送的信息进行处理得到的用以认证信息来源,并核实信息在传送过程中是否发生变化的一个字母数字串。因此,本公开实施例中,通过数字签名算法对第一原始用户证书进行加签,获得第四摘要信息,并对第三数字签名进行解析,获得第三摘要信息,若第三数字签名合法,且未被篡改,理论上第三摘要信息和第四摘要应该是相同的。
也就是说,若第三摘要信息和第四摘要信息相同,则说明付款设备的身份校验成功;若第三摘要信息和第四摘要信息不相同,则说明付款设备的身份校验失败,付款设备的身份可能存在一定的安全隐患。
进一步的,当付款设备的身份校验成功时,则继续交易流程,若身份校验失败,则中断交易流程。
相应的,付款设备也需要对收款设备的身份进行校验,接下来结合不做S307~S310对收款设备的身份校验方案进行详细说明:
S307、付款设备基于与收款设备建立的近景连接,获取收款设备的第二用户证书。
第二用户证书中包括第二原始用户证书和第二数字签名,第二数字签名是交易服务器基于数字签名算法,对第二原始用户证书进行加签获得的。
S308、付款设备基于交易服务器的根证书公钥,对第二数字签名进行解析,获得第九摘要信息;
S309、付款设备基于数字签名算法,对第二原始用户证书进行加签,获得第十摘要信息;
S310、付款设备响应于第九摘要信息和第十摘要信息相匹配,确定收款设备的身份校验成功。
类似的,当收款设备的身份校验成功时,则继续交易流程,若身份校验失败,则中断交易流程。
应当理解的是,收款设备的身份校验方法与付款设备校验方法(步骤S303~S306)类似,具体可参考上述实施例,此处不再赘述。
另外需要说明的是,对于上述步骤的执行顺序,本公开实施例也不做具体限定,例如,可以先由付款设备校验收款设备的身份,也可以先由收款设备校验付款设备的身份;且,在身份校验过程中,也可以先对原始用户证书进行加签,再对数字签名进行解析。
接下来结合图4对上述实施例中的第一交易凭证以及目标交易凭证的获取方式进行详细说明。
图4为本公开实施例提供的交易凭证获取方法的原理示意图。如图4所示,对于收款设备而言,第一支付凭证的获取方法(即图2所示实施例中的步骤S203)具体包括如下步骤:
(1)收款设备获取目标交易的订单信息和收款设备的第二用户证书。
其中,订单信息包括但不限于以下任意一种:订单号、商品内容、金额、时间戳等,其中,时间戳可以为收款设备和付款设备建立连接的时刻,也可以为目标订单的生成时刻;
第二用户证书是交易服务器签发的收款设备的数字化身份信息,第二用户证书中包括收款设备的第二身份信息、第二账号信息以及第二公钥。
(2)基于第二用户证书中的第二私钥,对订单信息和第二用户证书进行加密,获得第一数字签名。
(3)基于第一用户证书中的第一公钥,对订单信息、第二用户证书、第一数字签名和第一用户证书进行加密,生成第一支付凭证。
在一些实施方式中,第一支付凭证中还需要包括收款设备和付款设备的连接信息,具体的,上述步骤(3)具体包括如下步骤:
I、获取收款设备与付款设备之间的连接信息;
II、基于第一用户证书中的第一公钥,对订单信息、第二用户证书、第一数字签名、第一用户证书以及连接信息进行加密,生成第一支付凭证。
本公开实施例中,通过获取连接信息,收款设备可以基于连接信息实时检查付款设备和收款设备的连接状态,并响应于付款设备和收款设备之间断开连接时,基于连接信息,与付款设备重新建立连接。
通过本方案,在收款设备和付款设备之间断开连接时,可以及时响应并重新主动建立连接,可以避免由于断开连接而导致的支付失败,有助于提升支付效率,提升用户体验,并且,通过连接信息生成第一支付凭证,当断开连接时,可以基于第一支付凭证中的连接信息直接建立连接,无需重新生成二维码或NFC标签,其连接过程更加简洁、方便,用户体验更好。
在一些实施例中,支付凭证为预设格式,其中,预设格式例如为如下所示的表格格式:
订单信息 第二用户证书 第一数字签名
连接信息 第一用户证书
其中,订单信息、第二用户证书、第一数字签名、连接信息和第一用户证书即为第一支付凭证中的内容,这部分内容可以由收款设备来填充。
请继续参考图4,对于付款设备而言,目标支付凭证的获取方法(即图2所示实施例中的步骤S205)具体包括如下步骤:
I、付款设备获取第一支付凭证中的第一数字签名。
在本步骤中,付款设备接收到第一支付凭证后,采用自身的第一私钥进行解密,从而获取完整的第一支付凭证,并获取第一支付凭证中的第一数字签名。
其中,第一数字签名中包括订单信息和第二用户证书。
II、付款设备根据第二用户证书对第一数字签名进行校验。
具体的,对第一数字签名进行校验的过程如下步骤i~iii所示:
i、基于第二用户证书中的第二公钥,对第一数字签名进行解析,获得第五摘要信息。
ii、基于数字签名算法,对订单信息和第二用户证书进行加密,获得第六摘要信息。
iii、响应于第五摘要信息和第六摘要信息相匹配,确定第一数字签名校验成功。
本公开实施例中,由于第一数字签名是收款设备基于数字签名算法对订单信息和第二用户证书进行加签后获得的,若第一数字签名合法且未被篡改,理论上第五摘要信息和第六摘要信息应该是相同的。
因此,若第五摘要信息和第六摘要信息相同,则说明第一数字签名合法;若五摘要信息和第六摘要信息不相同,则说明第一数字签名可能并非收款设备签发的,或者,第一数字签名可能已被篡改。
进一步的,若第一数字签名合法(即校验成功),则继续执行下述步骤III,若第一数字签名不合法(校验失败),则中断目标交易,以防止交易信息被恶意篡改从而为付款方、收款方甚至是支付平台带来安全隐患。
III、付款设备响应于第一数字签名校验成功,获取第一支付凭证中的第一用户证书。
IV、付款设备根据交易服务器签发的第一用户证书对第一支付凭证中的第一用户证书进行校验。
具体的,采用交易服务器签发的第一用户证书与第一支付凭证中的第一用户证书进行比对,若二者相同,则第一支付凭证中的第一用户证书校验通过,反之,则校验不通过,中断当前的交易,从而避免在交易过程中出现安全隐患,给付款方或收款方带来损失。
V、付款设备响应于第一支付凭证中的第一用户证书校验成功,根据付款设备的第一私钥,生成目标支付凭证。
具体的,采用付款设备的第一私钥对第一支付凭证进行加密,生成第四数字签名,并在第一支付凭证的表格中填写第四数字签名,以获得如下表所示的目标支付凭证:
订单信息 第二用户证书 第一数字签名
连接信息 第一用户证书 第四数字签名
作为一种可选的实施例,付款设备还可以获取订单信息中的订单交易时长,其中,交易时长是根据当前时刻以及收款设备与付款设备建立连接时(即订单信息中的时间戳)的第一时刻获得的,即,交易时长为当前时刻与第一时刻之间的时段。
进一步的,响应于交易时长小于或等于预设时长,根据订单信息,生成订单确认页面,其中,订单确认页面中可以包括:订单信息,例如是,订单金额、商品类型、时间戳等等;应当理解的是,本公开的实施例对于预设时长不做具体限定,例如,可以为1分钟、90秒等等。
相应的,当用户在订单确认页面的进行订单确认操作时,说明付款方对于当前交易的订单信息确认无误,此时,根据付款设备的第一私钥,对第一支付凭证进行加密,生成第四数字签名。
更进一步的,根据第一支付凭证和第四数字签名,生成目标支付凭证。
在一些实施例中,响应于交易时长大于预设时长,则向收款设备发送指示信息,以通过指示信息指示收款设备重新生成第一支付凭证。
本公开实施例中,通过付款方对订单进行进一步确认,可以保障订单的准确性,当订单信息出现错误时,付款方可以及时的更正交易或者中断交易,防止对收款方或付款方带来资金损失。
另外,通过设置预设时长对交易进行时间限制,可以一定程度上对付款方起到催促作用,防止长时间挂单,从而推进交易的完成进度,提升交易效率。同时,也可以避免由于交易时间过长而使得交易信息被篡改,从而造成的安全隐患,进一步提升交易过程的可靠性。
在一种可选的实施方式中,当第一支付凭证中包含连接信息时,付款设备还可以根据第一支付凭证中的连接信息对当前所连接的收款设备进行校验,从而防止连接信息被篡改,或者,防止其他设备顶替收款设备与付款设备建立连接。
具体的,获取第一支付凭证中的连接信息,以及与收款设备建立连接时获取的连接信息(例如,通过扫码或NFC获得的连接信息),对比二者是否一致,若一致,则继续当前交易,若不一致,则中断交易,或者以及连接时获取的连接信息重新与连接信息对应的收款设备建立连接。
示例性的,以付款设备与收款设备建立连接时,获得的收款设备的连接信息为{T:WiFi;S:NetEase-5G;P:123456}为例,在获得第一支付凭证后,获取第一支付凭证中的连接信息,确定第一支付凭证中的连接信息中的“设备名称”是否与“NetEase-5G”相匹配,以及第一支付凭证中的连接信息中的“密码”是否与“123456”相匹配。
进一步的,响应于设备名称和密码中的任意一个无法匹配,则确定第一支付凭证中的连接信息已被篡改或顶替;相应的,若响应于设备名称和密码均能够匹配,则说明第一支付凭证中的连接信息未被篡改或顶替。
相应的,当第一支付凭证中的连接信息已被篡改或顶替时,付款设备可以根据与收款设备建立连接时获取的连接信息与收款设备重新建立连接。
通过本方案,可以防止在付款过程中,收款设备的连接信息被篡改,或者防止其他设备顶替收款设备与付款设备建立连接的情况,避免为收款方和付款方带来经济损失,同时也可以防止收款方和付款放的信息被泄露。另外,当发现连接信息被篡改或者顶替时,通过获取的连接信息还可以及时与收款设备重新建立连接,进而继续完成交易,无需再进行扫码或NFC等连接操作,可以简化交易操作,提升交易效率。
可选的,付款设备还可以实时的检查与收款设备的连接状态,当与收款设备断开连接时,可以获取第一支付凭证中的连接信息,并在该连接信息校验通过时,根据连接信息重新与收款设备建立连接。通过本公开实施例的方案,若支付过程中出现意外断线,可以根据连接信息直接建立连接,无需再进行扫码或NFC连接操作,可以简化交易操作,从而提升交易效率。
交易服务器的根证书是整个支付流程信任链体系的基石,由交易服务器使用非对称加密算法生成根证书秘钥对,其中私钥由服务端保存,公钥打包到根证书中,随着支付应用程序的下发、安装、更新而下发到各个设备,例如是付款设备或收款设备等,从而确保设备端内置合法的根证书,以完成后续的信息发布或合法性校验。另外,在进行交易前,付款设备和收款设备均需要由交易服务器进行认证,从而保证交易过程的安全性。接下来,结合图5~图7对设备的认证过程进行详细说明。
参考图5,图5为本公开的实施例提供的付款设备的第一用户证书获取过程的流程示意图。如图5所示,第一用户证书获取过程具体包括如下步骤:
S501、付款设备生成付款设备的第一公钥和第一私钥。
具体的,可以基于非对称加密算法生成第一公钥和第一私钥,其中,第一私钥可以保存在付款设备本地,至于具体生成过程,此处不再赘述。
S502、付款设备根据付款设备对应的第二身份信息、第二账号信息以及第一公钥,生成第一原始用户证书。
本步骤中,可以将第二身份信息、第二账号信息以及第一公钥进行打包,从而生成第一原始用户证书。
其中,第二身份信息例如是付款设备的密码、人脸、指纹、虹膜和指静脉等设备认证信息,第二账号信息例如是付款设备上所登录的支付账号的账号信息。
S503、付款设备向交易服务器发送第一原始用户证书。
具体的,付款设备通过本地的根证书公钥对第一原始用户证书进行加密,并将加密后的第一原始用户证书发送给交易服务器。
S504、交易服务器基于数字签名算法,对第一原始用户证书进行加签,获得第三数字签名。
S505、交易服务器向付款设备发送第一目标用户证书。
其中,第一目标用户证书中包括第一原始用户证书和交易服务器签发的第三数字签名,在发送该第一目标用户证书时,可以采用第一原始用户证书中的第一公钥对第一目标用户证书进行加密,从而提升用户认证过程中的安全性,防止付款设备当中的相关信息被非法盗用或篡改。
S506、付款设备根据第一目标用户证书,获得第一用户证书。
图6为本公开实施例提供的用户证书获取方法的原理示意图。如图6所示,步骤S506可以包括如下步骤:
(1)付款设备获取第一目标用户证书中的第三数字签名和第一原始用户证书。
首先,付款设备在接收到第一目标用户证书时,采用本地存储的第一私钥对第一用户证书进行解密,从而获取第三数字签名和第一原始用户证书。
(2)付款设备基于交易服务器的根证书公钥,对第三数字签名进行解析,获得第七摘要信息。
(3)付款设备基于数字签名算法,对第一原始用户证书进行加密,获得第八摘要信息。
(4)付款设备响应于第七摘要信息和第八摘要信息相匹配,确定第一目标用户证书为第一用户证书。
需要说明的是,由于第三数字签名是交易服务器基于数字签名算法对第一原始用户证书进行加签获得的,若第三数字签名合法且未被篡改,理论上第七摘要信息和第八摘要应该是相同的。
因此,若第七摘要信息和第八摘要信息相同,则说明第三数字签名合法,也就是说,第一目标用户证书校验通过,此时,确定第一目标用户证书则为付款设备的第一用户证书。
相应的,若第七摘要信息和第八摘要信息不相同,则说明第三数字签名可能并非交易服务器签发的,或者,第三数字签名可能已被非法篡改,此时,第一目标用户证书校验失败,此时,则中断当前的认证过程。
参考图7,图7为本公开的实施例提供的收款设备的第二用户证书获取过程的流程示意图。如图7所示,第二用户证书获取过程具体包括如下步骤:
S701、收款设备生成收款设备的第二公钥和第二私钥;
S702、收款设备根据收款设备的对应的第二身份信息、第二账号信息以及第二公钥,生成第二原始用户证书;
S703、收款设备向交易服务器发送第二原始用户证书;
S704、服务器基于数字签名算法,对第二原始用户证书进行加签,获得第二数字签名;
S705、服务器向收款设备发送第二目标用户证书;
其中,第二目标用户证书中包括第二原始用户证书和第二数字签名。
S706、收款设备根据第二目标用户证书,获得第二用户证书。
具体的,上述步骤S706具体包括如下步骤:
(1)获取第二目标用户证书中的第二数字签名和第二原始用户证书;
(2)基于交易服务器的根证书公钥,对第二数字签名进行解析,获得第一摘要信息;
(3)基于数字签名算法,对第二原始用户证书进行加签处理,获得第二摘要信息;
(4)响应于第一摘要信息和第二摘要信息相匹配,确定第二目标用户证书为第二用户证书。
需要说明的是,步骤S701~S706中获取第二用户证书的方案,与图5~图6所示实施例中获取第一用户证书的方法和原理类似,具体内容可参考上述实施例,此处不再赘述。
图8为本公开实施例提供的服务器对目标订单进行核销的原理示意图。如图8所示,目标支付凭证中包括第一支付凭证以及付款设备签发的第四数字签名。
第一支付凭证中包括订单信息、收款设备的第二用户证书、付款设备的第一用户证书以及收款设备签发的第一数字签名。
如图8所示,目标订单进行核销过程具体包括如下步骤:
(1)通过付款设备的第一公钥,对第四数字签名进行解析,获得第十一摘要信息。
(2)基于数字签名算法,对第一数字签名和第一用户证书进行加签,获得第十二摘要信息。
其中,由于第四数字签名是付款设备基于数字签名算法,对第一数字签名和第一用户证书进行加签获得的,若第三数字签名合法且未被篡改,理论上第十一摘要信息和第十二摘要应该是相同的。
因此,通过对比第十一摘要信息和第十二摘要信息,可以校验出目标支付凭证的合法性。相应的,当第十一摘要信息和第十二摘要信息相同时,则说明第四数字签名合法,也就是说,目标支付凭证校验通过。
相应的,若第十一摘要信息和第十二摘要信息不相同,则说明第四数字签名可能并非由付款设备签发的,或者,第四数字签名可能已被非法篡改,此时,目标支付凭证校验失败。
(3)通过收款设备的第二公钥,对第一数字签名进行解析,获得第十三摘要信息。
(4)基于数字签名算法,对订单信息和第二用户证书进行加签,获得第十四摘要信息。
类似的,第一数字签名是收款设备基于数字签名算法,对订单信息和第二用户证书进行加签获得的,若第一数字签名合法且未被篡改,理论上第十三摘要信息和第十四摘要信息应该是相同的。
因此,通过对比十三摘要信息和第十四摘要信息,可以校验出第一支付凭证的合法性。当十三摘要信息和第十四摘要信息相同时,则说明第一数字签名合法,也就是说,第一支付凭证校验通过。
相应的,若十三摘要信息和第十四摘要信息不相同,则说明第一数字签名可能并非由收款设备签发的,或者,第一数字签名可能已被非法篡改,此时,第一支付凭证校验失败。
(5)响应于第十一摘要信息和第十二摘要信息相匹配,且,第十三摘要信息和第十四摘要信息相匹配,确定目标订单通过校验,并对目标订单进行核销。
在一些实施例中,当第一数字签名和第四数字签名均校验通过时,整个交易校验通过,相应的,若第一数字签名和第四数字签名中任意一个未校验通过,则整个交易校验失败。
当校验通过时,交易服务器根据订单信息,对当前订单进行归档和资金划账等操作,以完成整个订单的核销。可选的,在完成核销操作后,可以通知收款方和付款方,也可以由收款方和付款方主动发起支付结果查询。
作为一种可选的实施例,当交易校验失败时,可以中断当前交易,从而保障收款设备和付款设的安全性。
在本公开实施例中,首先通过收款设备对交易信息进行验签,获得第一支付凭证,再采用付款设备对第一支付凭证进行验签,获得目标支付凭证,最终由交易服务器对二者进行核销,从而完成整个交易,通过多个角度、多个轮次的核验,可以保障交易的合法性,防止在交易过程中的信息被非法篡改,进而为收款方、付款方乃至服务器方带来损失。
在一些实施例中,第一支付凭证中还可以包括付款设备和收款设备的连接信息,则上述步骤(2)具体包括:基于数字签名算法,对第一数字签名、第一用户证书以及连接信息进行加签,获得第十二摘要信息。
通过对连接信息的同步校验,可以根据连接信息校验出收款设备和付款设备是否发生恶意篡改,从而防止资金损失,进一步保障支付过程的安全性。
在一些实施例中,服务器也可以对所接收到的各交易的目标交易凭证进行分批次处理,例如,可以基于各交易的交易时间,对同一时段的交易进行同时核销,或者,也可以基于各交易的交易类别,对同一交易类别的交易进行同时核销。至于基于交易时间和交易类别进行分批核销的处理方式,与付款设备(或者收款设备)分批发送目标支付凭证的方案和有益效果类似,此处不做赘述。
示例性介质
在介绍了本公开示例性实施方式的方法之后,接下来,参考图9对本公开示例性实施方式的存储介质进行说明。
参考图9所示,存储介质900中存储着根据本公开的实施方式的用于实现上述方法的程序产品,其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码,并可以在终端设备,例如个人电脑上运行。然而,本公开的程序产品不限于此。
程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了可读程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质。
可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码,程序设计语言包括面向对象的程序设计语言—诸如Java、C++等,还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中,远程计算设备可以通过任意种类的网络,包括局域网(LAN)或广域网(WAN),连接到用户计算设备。
示例性装置
在介绍了本公开示例性实施方式的介质之后,接下来,参考图10-12对本公开示例性实施方式的近景支付装置进行说明。
参考图10,图10为本公开实施例提供的近景支付装置的结构示意图一。其中,本公开实施例提供的近景支付装置应用于收款设备,如图10所示,该近景支付装置1000包括:
获取模块1001,用于基于收款设备与付款设备建立的近景连接,获取付款设备的第一用户证书,第一用户证书用于校验付款设备的身份;
签发模块1002,用于对付款设备对应的目标交易进行签发,生成目标交易对应的第一支付凭证;
发送模块1003,根据第一用户证书中的第一公钥对第一支付凭证进行加密,并基于近景连接,向付款设备发送加密后的第一支付凭证,第一支付凭证用于付款设备对目标交易进行校验,并生成目标交易对应的目标支付凭证;
接收付款设备基于近景连接发送的目标支付凭证,并在收款设备与交易服务器建立通信时起通信连接后,向交易服务器发送目标支付凭证,目标支付凭证用于交易服务器对目标交易进行核销。
在一种可能的实施方式中,签发模块1002具体用于:获取目标交易的订单信息和收款设备的第二用户证书;基于第二用户证书中的第二私钥,对订单信息和第二用户证书进行加密,获得第一数字签名,第二用户证书是交易服务器签发的;基于第一用户证书中的第一公钥,对订单信息、第二用户证书、第一数字签名和第一用户证书进行加密,生成第一支付凭证。
在一种可能的实施方式中,签发模块1002具体用于:获取收款设备与付款设备之间的连接信息;基于第一用户证书中的第一公钥,对订单信息、第二用户证书、第一数字签名、第一用户证书以及连接信息进行加密,生成第一支付凭证。
在一种可能的实施方式中,该近景支付装置还包括:处理模块1004,用于生成收款设备的第二公钥和第二私钥;根据收款设备的对应的第二身份信息、第二账号信息以及第二公钥,生成第二原始用户证书;
发送模块1003还用于向交易服务器发送第二原始用户证书;获取模块1001还用于:获取交易服务器发送的第二目标用户证书,第二目标用户证书中包括第二原始用户证书和交易服务器签发的第二数字签名,第二数字签名是交易服务器基于数字签名算法,对第二原始用户证书进行加签后获得的;根据第二目标用户证书,获得第二用户证书。
在一种可能的实施方式中,获取模块1001具体用于:获取第二目标用户证书中的第二数字签名和第二原始用户证书;基于交易服务器的根证书公钥,对第二数字签名进行解析,获得第一摘要信息;基于数字签名算法,对第二原始用户证书进行加签处理,获得第二摘要信息;响应于第一摘要信息和第二摘要信息相匹配,确定第二目标用户证书为第二用户证书。
在一种可能的实施方式中,获取模块1001具体用于:根据收款设备的连接信息,生成二维码和/或NFC标签;基于二维码和/或NFC标签,与付款设备建立近景连接;基于与付款设备建立的近景连接,获取付款设备的第一用户证书。
在一种可能的实施方式中,第一用户证书中包括第一原始用户证书和第三数字签名,第三数字签名是交易服务器基于数字签名算法,对第一原始用户证书进行加签获得的;近景支付装置还包括:校验模块1005,用于基于交易服务器的根证书公钥,对第三数字签名进行解析,获得第三摘要信息;基于数字签名算法,对第一原始用户证书进行加签,获得第四摘要信息;响应于第三摘要信息和第四摘要信息相匹配,确定付款设备的身份校验成功。
在一种可能的实施方式中,近景支付装置还包括:连接模块1006,用于响应于付款设备和收款设备之间断开连接,基于连接信息,与付款设备重新建立连接。
应理解的是,本公开实施例提供的近景支付装置1000用于实现上述收款设备侧任一方法实施例中的近景支付方法,其实现原理和技术效果类似,在此不再赘述。
参考图11,图11为本公开实施例提供的近景支付装置的结构示意图二。其中,本公开实施例提供的近景支付装置应用于付款设备,如图11所示,该近景支付装置1100包括:
第一获取模块1101,用于基于付款设备与收款设备建立的近景连接,获取收款设备的第二用户证书,第二用户证书用于校验收款设备的身份;
第二获取模块1102,用于获取收款设备签发的目标交易的第一支付凭证;
处理模块1103,用于根据第一支付凭证,生成目标交易的目标支付凭证;
发送模块1104,用于根据第二用户证书中的第二公钥对目标支付凭证进行加密,并基于近景连接,向收款设备发送加密后的目标支付凭证,以使收款设备向交易服务器发送目标支付凭证;和/或,在付款设备与交易服务器建立起通信连接后,根据交易服务器的根证书公钥对目标支付凭证进行加密,并向交易服务器发送加密后的目标支付凭证,目标支付凭证用于交易服务器对目标交易进行核销。
在一种可能的实施方式中,处理模块1103具体用于:获取第一支付凭证中的第一数字签名,第一数字签名中包括订单信息和第二用户证书,第一数字签名是收款设备基于数字签名算法,对订单信息和第二用户证书进行加签后获得的;根据第二用户证书对第一数字签名进行校验;响应于第一数字签名校验成功,获取第一支付凭证中的第一用户证书;根据交易服务器签发的第一用户证书对第一支付凭证中的第一用户证书进行校验;响应于第一支付凭证中的第一用户证书校验成功,根据付款设备的第一私钥,生成目标支付凭证。
在一种可能的实施方式中,处理模块1103具体用于:基于第二用户证书中的第二公钥,对第一数字签名进行解析,获得第五摘要信息;基于数字签名算法,对订单信息和第二用户证书进行加密,获得第六摘要信息;响应于第五摘要信息和第六摘要信息相匹配,确定第一数字签名校验成功。
在一种可能的实施方式中,处理模块1103具体用于:响应于第一支付凭证中的第一用户证书校验成功,从订单信息中获得订单当前的交易时长,交易时长是根据当前时刻以及收款设备与付款设备建立连接时的第一时刻获得的;响应于交易时长小于或等于预设时长,根据订单信息,生成订单确认页面;响应于用户在订单确认页面的订单确认操作,根据付款设备的第一私钥,对第一支付凭证进行加密,生成第四数字签名;根据第一支付凭证和第四数字签名,生成目标支付凭证。
在一种可能的实施方式中,发送模块1104还用于:响应于交易时长大于预设时长,向收款设备发送指示信息,以通过指示信息指示收款设备重新生成第一支付凭证。
在一种可能的实施方式中,该近景支付装置1100还包括:校验模块1105,用于获取第一支付凭证中的连接信息;基于收款设备与付款设备之间的连接信息,校验第一支付凭证中的连接信息;响应于第一支付凭证中的连接信息校验通过,且付款设备和收款设备断开连接,基于第一支付凭证中的连接信息,与收款设备重新建立连接;或者,响应于第一支付凭证中的连接信息未校验通过,中断订单的交易。
在一种可能的实施方式中,处理模块1103还用于:生成付款设备的第一公钥和第一私钥;根据付款设备对应的第二身份信息、第二账号信息以及第一公钥,生成第一原始用户证书;发送模块1104还用于:向交易服务器发送第一原始用户证书;处理模块1103还用于:获取交易服务器发送的第一目标用户证书,第一目标用户证书中包括第一原始用户证书和交易服务器签发的第三数字签名,第三数字签名是交易服务器基于数字签名算法,对第一原始用户证书进行加签获得的;根据第一目标用户证书,获得第一用户证书。
在一种可能的实施方式中,处理模块1103具体用于:获取第一目标用户证书中的第三数字签名和第一原始用户证书;基于交易服务器的根证书公钥,对第三数字签名进行解析,获得第七摘要信息;基于数字签名算法,对第一原始用户证书进行加密,获得第八摘要信息;响应于第七摘要信息和第八摘要信息相匹配,确定第一目标用户证书为第一用户证书。
在一种可能的实施方式中,第一获取模块1101具体用于:基于收款设备生成的二维码和/或NFC标签,与收款设备建立近景连接;通过与收款设备建立的近景连接,获取收款设备的第二用户证书。
在一种可能的实施方式中,第二用户证书中包括第二原始用户证书和第二数字签名,第二数字签名是交易服务器基于数字签名算法,对第二原始用户证书进行加签获得的;校验模块1105还用于基于交易服务器的根证书公钥,对第二数字签名进行解析,获得第九摘要信息;基于数字签名算法,对第二原始用户证书进行加签,获得第十摘要信息;响应于第九摘要信息和第十摘要信息相匹配,确定收款设备的身份校验成功。
应理解的是,本公开实施例提供的近景支付装置1100用于实现上述付款设备侧任一方法实施例中的近景支付方法,其实现原理和技术效果类似,在此不再赘述。
参考图12,图12为本公开实施例提供的近景支付装置的结构示意图三。其中,本公开实施例提供的近景支付装置应用于交易服务器,如图12所示,该近景支付装置1200包括:
接收模块1201,用于接收收款设备和/或付款设备发送的目标订单的目标支付凭证;
处理模块1202,用于基于目标支付凭证,对目标订单进行核销,目标支付凭证中包括第一支付凭证以及付款设备签发的第四数字签名,第一支付凭证中包括订单信息、收款设备的第二用户证书、付款设备的第一用户证书以及收款设备签发的第一数字签名。
在一种可能的实施方式中,处理模块1202具体用于:通过付款设备的第一公钥,对第四数字签名进行解析,获得第十一摘要信息,第四数字签名是付款设备基于数字签名算法,对第一数字签名和第一用户证书进行加签获得的;基于数字签名算法,对第一数字签名和第一用户证书进行加签,获得第十二摘要信息;通过收款设备的第二公钥,对第一数字签名进行解析,获得第十三摘要信息,第一数字签名是收款设备基于数字签名算法,对订单信息和第二用户证书进行加签获得的;基于数字签名算法,对订单信息和第二用户证书进行加签,获得第十四摘要信息;响应于第十一摘要信息和第十二摘要信息相匹配,且,第十三摘要信息和第十四摘要信息相匹配,确定目标订单通过校验,并对目标订单进行核销。
在一种可能的实施方式中,第一支付凭证中还包括:付款设备和收款设备的连接信息;处理模块1202具体用于:基于数字签名算法,对第一数字签名、第一用户证书以及连接信息进行加签,获得第十二摘要信息。
应理解的是,本公开实施例提供的近景支付装置1200用于实现上述交易服务器备侧的任一方法实施例中的近景支付方法,其实现原理和技术效果类似,在此不再赘述。
示例性计算设备
在介绍了本公开示例性实施方式的方法、介质和装置之后,接下来,参考图13对本公开示例性实施方式的计算设备进行说明。应理解,图13显示的计算设备1300仅仅是一个示例,不应对本公开实施例的功能和使用范围带来任何限制。
图13为本公开实施例提供的计算设备的结构示意图。如图13所示,计算设备1300以通用计算设备的形式表现。计算设备1300的组件可以包括但不限于:上述至少一个处理单元1301、上述至少一个存储单元1302,连接不同系统组件(包括处理单元1301和存储单元1302)的总线1303。
总线1303包括数据总线、控制总线和地址总线。存储单元1302可以包括易失性存储器形式的可读介质,例如随机存取存储器(RAM)1313和/或高速缓存存储器1322,可以进一步包括非易失性存储器形式的可读介质,例如只读存储器(ROM)1332。
存储单元1302还可以包括具有一组(至少一个)程序模块1342的程序/实用工具1352,这样的程序模块1342包括但不限于:操作系统、一个或者多个应用程序、其它程序模块以及程序数据,这些示例中的每一个或某种组合中可能包括网络环境的实现。
计算设备1300也可以与一个或多个外部设备1304(例如键盘、指向设备等)通信。这种通信可以通过输入/输出(I/O)接口1305进行。并且,计算设备1300还可以通过网络适配器1306与一个或者多个网络(例如局域网(LAN),广域网(WAN)和/或公共网络,例如因特网)通信。如图13所示,网络适配器1306通过总线1303与计算设备1300的其它模块通信。应当理解,尽管图中未示出,可以结合计算设备1300使用其它硬件和/或软件模块,包括但不限于:微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。
应当注意,尽管在上文详细描述中提及了定时更新装置的若干单元/模块或子单元/模块,但是这种划分仅仅是示例性的并非强制性的。实际上,根据本公开的实施方式,上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之,上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。
此外,尽管在附图中以特定顺序描述了本公开方法的操作,但是,这并非要求或者暗示必须按照该特定顺序来执行这些操作,或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地,可以省略某些步骤,将多个步骤合并为一个步骤执行,和/或将一个步骤分解为多个步骤执行。
虽然已经参考若干具体实施方式描述了本公开的精神和原理,但是应该理解,本公开并不限于所公开的具体实施方式,对各方面的划分也不意味着这些方面中的特征不能组合以进行受益,这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (10)

1.一种近景支付方法,应用于收款设备,所述近景支付方法包括:
基于所述收款设备与付款设备建立的近景连接,获取所述付款设备的第一用户证书,所述第一用户证书用于校验所述付款设备的身份;
对所述付款设备对应的目标交易进行签发,生成所述目标交易对应的第一支付凭证;
根据所述第一用户证书中的第一公钥对所述第一支付凭证进行加密,并基于近景连接,向所述付款设备发送加密后的所述第一支付凭证,所述第一支付凭证用于所述付款设备对所述目标交易进行校验,并生成所述目标交易对应的目标支付凭证;
接收所述付款设备基于近景连接发送的所述目标支付凭证,并在所述收款设备与交易服务器建立起通信连接后,向所述交易服务器发送所述目标支付凭证,所述目标支付凭证用于所述交易服务器对所述目标交易进行核销。
2.根据权利要求1所述的近景支付方法,所述对所述付款设备对应的目标交易进行签发,生成所述目标交易对应的第一支付凭证,包括:
获取所述目标交易的订单信息和所述收款设备的第二用户证书;
基于所述第二用户证书中的第二私钥,对所述订单信息和所述第二用户证书进行加密,获得第一数字签名,所述第二用户证书是所述交易服务器签发的;
基于所述第一用户证书中的第一公钥,对所述订单信息、所述第二用户证书、所述第一数字签名和所述第一用户证书进行加密,生成所述第一支付凭证。
3.根据权利要求2所述的近景支付方法,所述基于所述第一用户证书中的第一公钥,对所述订单信息、所述第二用户证书、所述第一数字签名和所述第一用户证书进行加密,生成所述第一支付凭证,包括:
获取所述收款设备与所述付款设备之间的连接信息;
基于所述第一用户证书中的第一公钥,对所述订单信息、所述第二用户证书、所述第一数字签名、所述第一用户证书以及所述连接信息进行加密,生成所述第一支付凭证。
4.根据权利要求1至3中任一项所述的近景支付方法,还包括:
生成所述收款设备的第二公钥和第二私钥;
根据所述收款设备的对应的第二身份信息、第二账号信息以及所述第二公钥,生成第二原始用户证书;
向所述交易服务器发送所述第二原始用户证书;
获取所述交易服务器发送的第二目标用户证书,所述第二目标用户证书中包括所述第二原始用户证书和所述交易服务器签发的第二数字签名,所述第二数字签名是所述交易服务器基于数字签名算法,对所述第二原始用户证书进行加签后获得的;
根据所述第二目标用户证书,获得第二用户证书。
5.根据权利要求4所述的近景支付方法,所述根据所述第二目标用户证书,获得所述第二用户证书,包括:
获取所述第二目标用户证书中的所述第二数字签名和所述第二原始用户证书;
基于所述交易服务器的根证书公钥,对所述第二数字签名进行解析,获得第一摘要信息;
基于所述数字签名算法,对所述第二原始用户证书进行加签处理,获得第二摘要信息;
响应于所述第一摘要信息和所述第二摘要信息相匹配,确定所述第二目标用户证书为所述第二用户证书。
6.根据权利要求1至3中任一项所述的近景支付方法,所述基于所述收款设备与付款设备建立的近景连接,获取所述付款设备的第一用户证书,包括:
根据所述收款设备的连接信息,生成二维码和/或NFC标签
基于所述二维码和/或所述NFC标签,与所述付款设备建立近景连接;
基于与所述付款设备建立的近景连接,获取所述付款设备的第一用户证书。
7.根据权利要求6所述的近景支付方法,所述第一用户证书中包括第一原始用户证书和第三数字签名,所述第三数字签名是所述交易服务器基于所述数字签名算法,对所述第一原始用户证书进行加签获得的;
所述近景支付方法,还包括:
基于所述交易服务器的根证书公钥,对所述第三数字签名进行解析,获得第三摘要信息;
基于所述数字签名算法,对所述第一原始用户证书进行加签,获得第四摘要信息;
响应于所述第三摘要信息和所述第四摘要信息相匹配,确定所述付款设备的身份校验成功。
8.根据权利要求3所述的近景支付方法,还包括:
响应于所述付款设备和所述收款设备之间断开连接,基于所述连接信息,与所述付款设备重新建立连接。
9.一种近景支付方法,应用于付款设备,所述近景支付方法包括:
基于所述付款设备与收款设备建立的近景连接,获取所述收款设备的第二用户证书,所述第二用户证书用于校验所述收款设备的身份;
获取所述收款设备签发的目标交易的第一支付凭证;
根据所述第一支付凭证,生成所述目标交易的目标支付凭证;
根据所述第二用户证书中的第二公钥对所述目标支付凭证进行加密,并基于近景连接,向所述收款设备发送加密后的所述目标支付凭证,以使所述收款设备向所述交易服务器发送所述目标支付凭证;和/或,在所述付款设备与所述交易服务器建立起通信连接后,根据所述交易服务器的根证书公钥对所述目标支付凭证进行加密,并向所述交易服务器发送加密后的所述目标支付凭证,所述目标支付凭证用于所述交易服务器对所述目标交易进行核销。
10.根据权利要求9所述的近景支付方法,所述根据所述第一支付凭证,生成所述目标交易的目标支付凭证,包括:
获取所述第一支付凭证中的第一数字签名,所述第一数字签名中包括订单信息和第二用户证书,所述第一数字签名是所述收款设备基于数字签名算法,对所述订单信息和所述第二用户证书进行加签后获得的;
根据所述第二用户证书对所述第一数字签名进行校验;
响应于所述第一数字签名校验成功,获取所述第一支付凭证中的第一用户证书;
根据所述交易服务器签发的第一用户证书对所述第一支付凭证中的第一用户证书进行校验;
响应于所述第一支付凭证中的第一用户证书校验成功,根据所述付款设备的第一私钥,生成所述目标支付凭证。
CN202210117794.4A 2022-02-08 2022-02-08 近景支付方法、介质、装置和计算设备 Pending CN114463007A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210117794.4A CN114463007A (zh) 2022-02-08 2022-02-08 近景支付方法、介质、装置和计算设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210117794.4A CN114463007A (zh) 2022-02-08 2022-02-08 近景支付方法、介质、装置和计算设备

Publications (1)

Publication Number Publication Date
CN114463007A true CN114463007A (zh) 2022-05-10

Family

ID=81413413

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210117794.4A Pending CN114463007A (zh) 2022-02-08 2022-02-08 近景支付方法、介质、装置和计算设备

Country Status (1)

Country Link
CN (1) CN114463007A (zh)

Similar Documents

Publication Publication Date Title
AU2018202542B2 (en) Automated account provisioning
US11102007B2 (en) Contactless card emulation system and method
US10785287B2 (en) Secure binding of software application to a communication device
TWI792284B (zh) 用於驗證對安全裝置功能性之線上存取之方法
CN105608577B (zh) 实现不可否认性的方法及其支付管理服务器和用户终端
US10192214B2 (en) Pending deposit for payment processing system
US11657392B2 (en) On-boarding server for remotely authorizing use of a terminal
WO2015161699A1 (zh) 数据安全交互方法和系统
CN107784499B (zh) 近场通信移动终端的安全支付系统及方法
US20210258166A1 (en) Systems and methods for cryptographic authentication of contactless cards
CN112789643A (zh) 用于非接触式卡的密码认证的系统和方法
WO2022078367A1 (zh) 支付密钥的加密和解密方法、支付认证方法及终端设备
CN104851206A (zh) 一种基于usbkey的电费在线支付系统
CN103281187A (zh) 安全认证方法、设备和系统
US20200266993A1 (en) Systems and methods for cryptographic authentication of contactless cards
CN104835038A (zh) 一种联网支付装置及方法
CN111709747B (zh) 智能终端认证方法及系统
CN110601836B (zh) 密钥获取方法、装置、服务器和介质
CN114463007A (zh) 近景支付方法、介质、装置和计算设备
KR101710950B1 (ko) 암호키 배포 방법, 그를 이용한 카드리더 모듈 및 암호키 배포 시스템
CN115280720A (zh) 在线秘密加密
WO2020122949A1 (en) Graphical user interface indicator for broadcaster presence
WO2024020508A1 (en) Authentication data validation
WO2023091613A1 (en) Method for securing security token and smartcard into processing device, and system, terminal and computer-readable medium for the same
CN114462990A (zh) 基于数字货币进行免密支付的方法和装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination