CN113850591A - 一种基于加密和数字签名算法验证支付二维码真伪的方法 - Google Patents

Abstract

本发明提出了一种基于加密和数字签名算法验证支付二维码真伪的方法。该方法包括：客户端解析用户扫描的商家的线下支付二维码以获取验证平台地址以及商家标识，并将商家标识上传至验证平台；该验证平台基于商家标识在数据库中查询对应的合法二维码数据和合法商家名称，基于查询到的合法二维码数据生成第一数字摘要发送给客户端；该客户端基于扫描的线下支付二维码生成第二数字摘要，比较第一和第二数字摘要，如果两者一致，则向用户显示合法商家名称以供用户与当前线下的商家名称比对，以及响应于用户确定商家名称一致而确定线下支付二维码合法。本发明还提供了用于实现上述方法的验证平台和移动计算设备。

Description

一种基于加密和数字签名算法验证支付二维码真伪的方法

技术领域

本发明涉及验证支付二维码合法性，并且更具体地涉及加密和数字签名算法验证支付二维码合法性的方法。

背景技术

随着移动支付的发展，支付宝、微信二维码扫码支付安全隐患也日益显现，线下场景监管难、二维码生成简便、印制成本低廉使不法分子有机可乘，假冒支付二维码盗刷事件屡次发生。

为了让用户放心扫描支付二维码，保障移动支付发展环境，依托电信云资源和人工智能AI能力开发优势，期望可以建设具有公信力的支付二维码鉴权统一认证验证平台，以使用基于加密和数字签名算法来验证支付二维码合法性，从而保证支付二维码等敏感信息交互和存储的安全性和完整性，保证原支付流程的快捷方便，并且提升支付资金的安全。

发明内容：

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在标识出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以作为稍后给出的更加详细的描述之序。

为了让用户放心扫描支付二维码，保障移动支付发展环境，依托电信云资源和人工智能AI能力开发优势，本发明提出了一种基于加密和数字签名算法验证支付二维码合法性的方法。该方法包括：客户端解析用户扫描的商家的线下支付二维码以获取验证平台地址以及商家标识；所述客户端基于所述验证平台地址与验证平台建立连接；所述客户端将所述商家标识上传至所述验证平台；所述验证平台基于接收到的所述商家标识在数据库中查询对应的合法二维码数据和合法商家名称；所述验证平台基于查询到的合法二维码数据生成第一数字摘要，并将所述第一数字摘要和所述合法商家名称发送给所述客户端；所述客户端基于扫描的线下支付二维码生成第二数字摘要；所述客户端对所述第一数字摘要和所述第二数字摘要进行比较；如果所述第一数字摘要和所述第二数字摘要一致，所述客户端向用户显示所述合法商家名称以供用户与当前线下的商家名称比对；以及响应于用户确定显示的合法商家名称与当前线下的商家名称一致，所述客户端确定所述线下支付二维码合法。

根据本发明的进一步实施例，所述客户端用所述验证平台的公钥将用于与所述验证平台之间的会话的临时对称密钥与所述商家标识进行加密后发送给所述验证平台；所述验证平台使用所述验证平台的私钥解密得到所述临时对称密钥与所述商家标识；所述验证平台使用所述临时对称密钥对所述第一数字摘要和所述合法商家名称进行加密，随后再用所述验证平台的私钥加密；以及所述客户端用所述验证平台的公钥对接收到的信息解密，随后再用所述临时对称密钥解密以得到所述第一数字摘要和所述合法商家名称。

根据本发明的进一步实施例，所述公钥和所述私钥是所述验证平台针对每一次会话临时生成的。

根据本发明的进一步实施例，所述商家向所述验证平台提供商家资质和合法支付二维码；所述验证平台对所述商家资质进行验证；验证通过后，所述验证平台将所述商家提供的合法商家标识、合法商家名称、以及所述合法支付二维码存入所述数据库；所述验证平台基于所述合法商家标识、所述合法支付二维码、以及所述验证平台的合法地址生成防伪支付二维码；以及将所述防伪支付二维码提供给所述商家供用户扫描。

根据本发明的一个方面，提供了一种支付方法，包括：使用支付客户端扫描线下支付二维码；所述支付客户端调用嵌入的二维码验证模块通过如上述权利要求中的任意一项的方法来验证所扫描的线下支付二维码是否合法；以及响应于验证所扫描的线下支付二维码合法，所述支付客户端调用支付接口以完成支付过程。

根据本发明的一个方面，提供了一种用于验证支付二维码合法性的验证平台，所述验证平台用于：响应于接收到商家提供的商家资质和合法支付二维码而对所述商家资质进行验证；在验证通过后，将从所述商家接收到的合法商家标识、合法商家名称、以及所述合法支付二维码存入数据库；基于所述合法商家标识、所述合法支付二维码、以及所述验证平台的合法地址生成防伪支付二维码；以及将所述防伪支付二维码提供给所述商家供用户线下扫描。

根据本发明的进一步实施例，所述验证平台响应于用户使用客户端扫描商家的线下支付二维码发起的请求而与所述客户端建立连接；基于从所述客户端接收到的商家标识在所述数据库中查询对应的合法二维码数据和合法商家名称；基于查询到的合法二维码数据生成第一数字摘要，并将所述第一数字摘要和所述合法商家名称发送给所述客户端，以供所述客户端将所述第一数字摘要与所述客户端基于扫描的线下支付二维码生成的第二数字摘要进行比较以及所述用户将所述合法商家名称与当前线下的商家名称进行比对。

根据本发明的进一步实施例，所述验证平台生成包括公钥和私钥的临时非对称密钥；将所述公钥发送给客户端；从所述客户端获得用所述公钥将用于与所述验证平台之间的会话的临时对称密钥与所述商家标识进行加密后的数据；使用所述私钥解密所述数据得到所述临时对称密钥与所述商家标识；以及使用所述临时对称密钥对所述第一数字摘要和所述合法商家名称进行加密，随后再用所述私钥加密并发送给所述客户端。

根据本发明的一个方面，提供了一种移动计算设备，所述移动计算设备包括：显示装置；二维码扫描装置，所述二维码扫描装置被配置成扫描商家的线下支付二维码；以及支付客户端，所述支付客户端配置成：解析用户使用所述二维码扫描装置扫描的商家的线下支付二维码以获取验证平台地址以及商家标识；基于所述验证平台地址与验证平台建立连接；将所述商家标识上传至所述验证平台；从所述验证平台接收第一数字摘要和商家名称，其中所述验证平台基于所述商家标识在数据库中查询对应的合法二维码数据和商家名称并基于所述合法二维码数据来生成所述第一数字摘要；基于扫描的线下支付二维码生成第二数字摘要；对所述第一数字摘要和所述第二数字摘要进行比较；如果所述第一数字摘要和所述第二数字摘要一致，向用户显示所述商家名称以供用户与当前线下的商家名称比对；以及响应于用户确定显示的商家名称与当前线下的商家名称一致而确定所述线下支付二维码合法。

根据本发明的进一步实施例，所述支付客户端具有嵌入的二维码验证SDK，并且所述验证所扫描的线下支付二维码是否合法的步骤由所述二维码验证SDK执行。

提供本发明内容是为了以简化的形式来介绍一些概念，这些概念将在下面的具体实施方式中进一步描述。本发明内容不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。各实施例的其他方面、特征和/或优点将部分地在下面的描述中阐述，并且将部分地从描述中显而易见，或者可以通过本公开的实践来学习。

附图说明

为了能详细地理解本发明的上述特征所用的方式，可以参照各实施例来对以上简要概述的内容进行更具体的描述，其中一些方面在附图中示出。然而应该注意，附图仅示出了本发明的某些典型方面，故不应被认为限定其范围，因为该描述可以允许有其它等同有效的方面。在附图中，类似附图标记始终作类似的标识。要注意，所描述的附图只是示意性的并且是非限制性的。在附图中，一些部件的尺寸可放大并且出于解说性的目的不按比例绘制。

图1解说了根据现有技术的线下手机客户端扫码支付流程示例。

图2解说了根据本发明的一实施例的线下收集扫码支付流程示例。

图3解说了根据本发明的一实施例的防伪支付二维码验证实现模块结构图的示意图。

图4解说了根据本发明的一实施例的防伪支付二维码生成逻辑图的示意图。

图5解说了根据本发明的一实施例的防伪支付二维码验证实现方法流程图。

图6解说了根据本发明的一实施例的移动计算设备的示图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。在以下详细描述中，阐述了许多具体细节以提供对所描述的示例性实施例的透彻理解。然而，对于本领域技术人员显而易见的是，可以在没有这些具体细节中的一些或全部的情况下实践所描述的实施例。在其他示例性实施例中，没有详细描述公知的结构或处理步骤，以避免不必要地模糊本公开的概念。

在本说明书中，除非另有说明，否则通过本说明书使用的术语“A或B”指的是“A和B”和“A或B”，而不是指A和B是排他性的。

本发明通过对支付客户端(例如，可以是翼支付、微信)提供嵌入式验证软件开发工具包(SDK)，通过非对称加密算法、对称加密算法、数字签名与验证平台(在本申请中也可被称为验证云、云端等)交互，验证完成用户端扫描的支付二维码合法性，可以满足海量商家的支付二维码在用户支付前的合法性验证需求。本发明所提供的支付二维码验证SDK可集成在多种支付应用APP中，通过在目前调用统一的支付接口的流程中前置支付二维码的合法性校验环节，并以云端下发合法二维码的数字摘要的方法，改进了传统上下行二维码数据对比验证占用大量带宽和高迟延的缺点，填补了现有支付流程的不足。

图1解说了根据现有技术的线下手机客户端扫码支付流程示例。

如图1所示，在客户端(例如，手机端的APP)，用户可扫描线下商家放置的支付二维码，客户端读取用户扫描的支付二维码信息，并且调用支付接口。

而在支付平台侧，用户可能需要输入金额、密码，与资金账户交互，从而完成扣款。

图2解说了根据本发明的一实施例的线下手机扫码支付流程示例。在本申请的实施例中，可通过使用在客户端嵌入的验证SDK，进行云端验证能力交互来对用户扫描的二维码做合法性校验并提示用户，确认合法后再进入支付操作。

如图2所示，参照图中虚线框中的内容，本发明可在用户输入金额、密码支付环节之前，验证支付二维码的合法性。例如，当客户端发起扫码支付请求时，客户端调用SDK将用户扫描的二维码图片中的商家标识(ID)上传至验证平台。其中，该商家ID是例如发放二维码的鉴权机构(例如，运营商或第三方鉴权机构)基于商家营业资质(例如，营业执照)来唯一性地提前生成的，其可以包括字符、数字等，并且可以是随机的。

验证平台根据商家ID从合法二维码数据库(例如，可存储在云端)中查找对应的商家合法支付二维码数据，通过哈希(HASH)算法生成合法二维码数字摘要，用数据加密标准(DES)密钥加密后，用非对称加密算法(RSA)私钥二次加密并下发到客户端。附加地，验证平台可同时查找对应的合法商家名称连同合法二维码数字摘要一起发送给客户端。

客户端接收后实行解密，将解密后的数字摘要和基于线下二维码数据的数字摘要做比对，如一致则验证线下二维码为合法二维码，并且根据校验结果确定是否调用第三方支付接口进行后续支付操作。图2所描述的线下手机扫码支付流程的详细步骤可进一步参照图下面关于图5的详细描述。

图3解说了根据本发明的一实施例的防伪支付二维码验证实现模块结构图的示意图。

在本发明的实施例中，构建了基于运营商云资源的支付二维码鉴权认证验证平台，其可以完成以下功能性：接入商家营业资质验证、商家已有第三方支付二维码验证、防伪支付二维码生成、商家营业资质数据存储和商家合法支付二维码数据存储、数字证书(例如，生成、发放或验证)、非对称密钥生成及加解密、对称密钥生成及加解密、数字摘要生成等等。

客户端嵌入的验证SDK可完成用户扫描二维码数据读取、本地对称密钥生成及加解密、本地数字摘要生成、公钥加解密等功能性。

图4解说了根据本发明的一实施例的商家防伪支付二维码生成逻辑图的示意图。

首先，可基于电信云资源来搭建验证平台，以对商家上传的营业资质联网工商局做审核校验，对厂商计划投放的原始支付二维码图进行校验审核并在鉴定无木马、病毒、钓鱼、伪冒等非法因素之后，验证平台用云端解码器将商家上传的原始二维码图片解码转换为字符串，将确认为合法的二维码图片和解码后的字符串数据加密后存入云端。附加地，商家可同时提供合法商家名称和合法商家ID，并且验证平台可存储该合法商家名称和合法商家ID。

随后，在营业资质信息和原始二维码合法性均完成校验后，云端再次基于商家ID和原二维码数据等来生成一个新的二维码，发放给商家，供商家在线下各类场景放置供用户支付时扫码。

图5解说了根据本发明的一实施例的防伪支付二维码验证实现方法流程图。

验证平台可对每个提交的合法二维码生成1个对称密钥key0，该对称密钥在商家营业资质信息和原始支付二维码图通过校验后，由验证平台根据对称加密算法随机生成。对称密钥key0用于对商家原始支付二维码解析字符串数据加密，加密后的支付二维码数据与商家ID及验证平台地址一起生成新防伪支付二维码图片，发放给商家供用户扫码使用。在本发明的实施例中，key0存放在验证平台，以确保二维码不可轻易被破解。

在本发明的实施例中，验证平台对审核通过的商家生成新的二维码数据结构S0如下：

商家ID

验证平台地址

加密后商家合法支付二维码数据

在本发明的实施例中，验证平台还可以存储与合法商家ID对应的合法商家名称。此外，验证平台还可以基于商家ID来在其数据库中查找对应的合法支付二维码数据和合法商家名称。

在本发明的实施例中，用户扫描二维码后的合法性验证流程如下：

在501，用户操作已嵌入验证SDK的客户端进行扫描以发起扫码支付请求。在本发明的实施例中，客户端可解析扫描的二维码数据以获取验证平台地址，并且基于该验证平台地址与验证平台(例如，云端)建立连接(例如，HTTPS连接)。客户端可与验证平台建立基于可信任的数字证书的HTTPS连接，并且验证平台为本次验证会话生成一对临时非对称密钥(例如，RSA非对称密钥，其可以是一次性的)。其中私钥存储在云端，公钥通过连接下发给客户端。客户端同步生成本次加密用的临时对称密钥(例如，DES对称密钥，其可以是一次性的)，并且可任选地，使用公钥加密后提前上传验证平台。在客户端本地随机生成的一个对称密钥被用于对传输报文加密，加密后的报文始再用验证平台临时生成的数字证书非对称公钥加密，即使在传输中被黑客获取到报文，因没有私钥而无法解密报文。附加地或替换地，即使黑客侥幸拿到私钥，因为是非对称密钥是临时生成的，生存周期很短(例如，不超过1分钟)，在该周期内几乎无法猜到非对称加密算法并用私钥进行解密。

在502，客户端还可以通过解析线下扫描的二维码数据获取商家ID。

在503，客户端将502中获取的商家ID用对称密钥加密后，再通过验证平台下发的公钥二次加密上传至验证平台。

在504，验证平台对接收到的待验证数据依次用验证平台私钥解密、对称密钥二次解密，并且在验证平台数据库中根据解密后的商家ID来查找到对应的合法二维码数据。本领域技术人员应领会，针对步骤501-504，客户端也可以通过解析线下扫描的二维码数据同时获取验证平台地址和商家ID，并在基于验证平台地址建立连接后将商家ID和客户端生成的临时对称密钥使用从验证平台获得的公钥加密后一起上传至验证平台，随后，验证平台可以仅使用验证平台的私钥解密同时得到临时对称密钥和商家ID。

进一步地，在505，验证平台基于查找到的合法二维码数据来生成数字摘要DEST0，并且在506将数字摘要DEST0使用对称密钥加密、验证平台私钥二次加密，然后下发至客户端。可任选地，可以将合法商家名称与数字摘要DEST0一起加密并下发至客户端。其中，可以使用HASH算法来生成数字摘要DEST0。

在507，客户端接收到505由验证平台传送的信息，并将其依次用公钥和对称密钥解密以获得经解密的数字摘要DEST0，以及可任选的合法商家名称。

在508，客户端基于扫描的线下支付二维码数据，例如，使用HASH算法来生成数字摘要DEST1，并在509将DEST0与DEST1进行比较。如一致，则表明用户扫描的二维码是合法二维码，客户端可与验证平台断开连接，关闭本次验证对话。如不一致，则返回用户扫描的二维码是非法二维码，并且在510提示用户，终止支付流程。

附加地或替换地，在DEST0与DEST1一致的情况下，客户端可根据反馈结果，决定下一步操作。例如，当验证为合法二维码时，可以在511显示验证平台返回的商家信息(例如，合法商家名称)并在512提示用户检查与当前商家线下名称是否一致，用户可比对商家名称，如一致则确认一致并调用第三方支付接口；如返回的合法商家名称与当前商家线下名称不一致，则同样地行进至510提示用户，并终止支付流程。

为了便于理解，下面将以线下餐饮商家为例解说上述流程。商家通过电信验证云提交商家营业资质信息和已获得的合法支付二维码，验证平台经过审核将商家信息(例如，商家名称、商家ID)和合法支付二维码数据加密后存入验证平台，对商家生成新的防伪支付二维码发放给商家，供商家在线下门店放置供用户支付时扫描。

用户在使用翼支付、微信、支付宝等支付客户端来扫描商家线下门店放置的支付二维码后，APP的嵌入式验证SDK读取用户扫描的二维码信息，解析到云端的地址后与云端建立HTTPS连接；云端生成用于本次会话加密需用的非对称RSA密钥，客户端在本地生成本次数据加密所需的对称DES密钥。

随后，客户端SDK读取用户扫描二维码中的商家ID，通过DES对称密钥和RSA公钥加密后上传到云端，云端解密后，根据商家ID查询二维码数据库，搜索到对应的合法二维码数据和商家名称后，用HASH算法对云端合法二维码数据生成数字摘要DEST0，连同商家名称一起并用DES对称密钥和RSA私钥依次加密后，回送给客户端SDK。

客户端SDK收到云端回送的加密数据做解密处理，得到云端DEST0，并对本地扫描获取的线下二维码数据生成数字摘要得到DEST1，比对DEST0和DEST1，如果两个数字摘要一致，则验证了线下扫描的二维码数据是合法的。

客户端SDK根据两个数字摘要的比对结果，在APP页面提示用户，如数字摘要一致，则显示商家名称供用户与线下商家名字人工核对，商家名称一致则调用第三方支付接口，进入支付流程；如不一致或验证结果为非法二维码，则提示用户此二维码非法并关闭后续的支付操作。

本申请中，由于云端与客户端采用对称和非对称密钥算法及数字签名等方法，保证了支付二维码等敏感信息交互和存储的安全性和完整性，其具有如下优点：

1.验证云不可仿冒性：每次客户端用户扫描二维码，发起防伪验证时，由客户端读取用户扫描的二维码信息中的验证云地址(例如，验证平台地址)并发送验证求，验证云随机下发自己的数字证书，双方通过数字证书中的公钥和验证平台私钥完成验证平台的身份校验。仿冒的服务器没有认证数字证书，即使可以自己分发非对称公钥仍无法假冒验证云与客户端通信。

2.传输中数据防篡改：客户端对提交给验证云的报文(例如，厂商计划投放的原始支付二维码图、商家名称、商家ID等)，使用单向加密HASH算法对需验证的二维码字符串数据生成数据摘要，在传输过程中，如果黑客截获了报文并修改后再次传给验证云，在验证平台通过HASH算法对报文主体加密后与数据摘要比对，只要不完全匹配就可认定报文被篡改过。

3.数据保密性：线下扫描的防伪支付二维码由验证平台加密后生成，密钥(例如，key0)存放在验证平台保证了二维码不可轻易被破解。客户端在提交防伪验证前，在客户端本地随机生成一个对称密钥用于对传输报文加密，加密后的报文始再用验证平台临时生成的数字证书非对称公钥加密，即使在传输中被黑客获取到报文，因没有私钥，也无法解密。或者黑客侥幸拿到私钥，因为是非对称密钥临时生成的，生存周期很短，在如此短的时间内猜到非对称加密算法并用私钥解密的可能性几乎为零。

图6解说了根据本发明的一实施例的移动计算设备600的示图。

移动计算设备600可包括显示装置620、二维码扫描装置640、收发机660和支付客户端680。应当注意，移动计算设备600还可包括其他未示出的组件，诸如处理器、存储器、接收机可执行软件等。上述组件可经由一条或多条总线(例如，总线610)处于电子通信。其中处理器可包括智能硬件设备(例如，通用处理器、数字信号处理器(DSP)、中央处理单元(CPU)、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、可编程逻辑器件、分立的门或晶体管逻辑组件、分立的硬件组件、或者其任何组合)。在一些情形中，处理器可被配置成使用存储器控制器来操作存储器阵列。在其他情形中，存储器控制器可被集成到处理器中。处理器可被配置成执行存储器中所储存的计算机程序以执行各种功能(例如，支持基于专用SSID来将智能终端设备接入网络的各功能或任务)。存储器可包括随机存取存储器(RAM)和只读存储器(ROM)。存储器可存储包括指令的计算机可读、计算机可执行软件，这些指令在被执行时使得处理器执行本文中描述的各种功能。移动计算设备600可经由收发机635与外围设备进行通信(例如，向/从局域网内的智能终端设备传送/接收数据、与外部网络中的网络实体通信等)。

显示装置620可包括显示器等可用于显示本申请中的商家名称和/或对用户进行提示的装置。二维码扫描装置640被配置成扫描商家的线下支付二维码。

在一个实施例中，移动计算设备600的支付客户端(例如，可以是翼支付、微信、支付宝等应用)可被配置成：解析用户使用二维码扫描装置扫描的商家的线下支付二维码以获取验证平台地址以及商家标识；基于验证平台地址与验证平台建立连接；将商家标识上传至验证平台；从验证平台接收第一数字摘要和商家名称，其中验证平台基于商家标识在数据库中查询对应的合法二维码数据和商家名称并基于合法二维码数据来生成所述第一数字摘要；基于扫描的线下支付二维码生成第二数字摘要；对第一数字摘要和第二数字摘要进行比较；如果第一数字摘要和第二数字摘要一致，向用户显示商家名称以供用户与当前线下的商家名称比对；以及响应于用户确定显示的商家名称与当前线下的商家名称一致，确定线下支付二维码合法。并且，所述支付客户端可以是由一个或多个处理器执行的。

以上描述了根据本发明的实时加密和数字签名算法验证支付二维码合法性的方法、验证平台、系统和计算机设备，相对现有技术而言，本发明至少具有以下优点：

1.依托云资源，突破合法支付二维码海量数据存储瓶颈；

2.云端下发合法二维码数字摘要的方法，改进了传统上下行二维码加密数据占用大量带宽和高迟延的缺点，填补了现有支付流程的不足；

3.用户操作对二维码合法性验证流程没有明显感知，整个验证流程由客户端SDK和云端实现，无用户介入操作，嵌入的二维码校验环节透明无缝，保证原支付流程的快捷方便，但提升了支付资金的安全；

4.应用范围，适用场景广，以线下消费为主要服务场景，共享单车、商家门店、个体户等涉及到需扫描支付二维码的都可接入此系统。

5.商家无需自己搭建验证平台和开发APP，可以使用嵌入式验证SDK在统一支付APP中实现二维码合法性验证；

6.客户端用对称密钥和算法加密数据报文，客户端-云端用非对称密钥和算法传输数据，密钥在用户扫码时临时生成，用完即删除，最大限度地避免了数据被黑客截获，保证了数据验证的可靠性和真实性，弥补简单地利于HTTPS协议传输数据易被中途截取和破解修改的不足；

7.云端与客户端采用对称和非对称密钥算法及数字签名等方法，保证了支付二维码等敏感信息交互和存储的安全性和完整性，保证了身份验证和数据安全。

在整个说明书中已经参照“实施例”，意味着特定描述的特征、结构或特性包括在至少一个实施例中。因此，这些短语的使用可以不仅仅指代一个实施例。此外，所描述的特征、结构或特性可以在一个或多个实施例中以任何合适的方式组合。

然而，相关领域的技术人员可以认识到，可以在没有一个或多个具体细节的情况下或者利用其他方法、资源、材料等来实践这些实施例。在其他情况下，众所周知的结构、资源，或者仅仅为了观察实施例的模糊方面而未详细示出或描述操作。

虽然已经说明和描述了实施例和应用，但是应该理解，实施例不限于上述精确配置和资源。在不脱离所要求保护的实施例的范围的情况下，可以在本文公开的方法和系统的布置，操作和细节中进行对本领域技术人员显而易见的各种修改、替换和改进。

Claims (10)

1.一种用于验证支付二维码合法性的方法，包括：

客户端解析用户扫描的商家的线下支付二维码以获取验证平台地址以及商家标识；

所述客户端基于所述验证平台地址与验证平台建立连接；

所述客户端将所述商家标识上传至所述验证平台；

所述验证平台基于接收到的所述商家标识在数据库中查询对应的合法二维码数据和合法商家名称；

所述验证平台基于查询到的合法二维码数据生成第一数字摘要，并将所述第一数字摘要和所述合法商家名称发送给所述客户端；

所述客户端基于扫描的线下支付二维码生成第二数字摘要；

所述客户端对所述第一数字摘要和所述第二数字摘要进行比较；

如果所述第一数字摘要和所述第二数字摘要一致，所述客户端向用户显示所述合法商家名称以供用户与当前线下的商家名称比对；以及

响应于用户确定显示的合法商家名称与当前线下的商家名称一致，所述客户端确定所述线下支付二维码合法。

2.如权利要求1所述的方法，其特征在于：

所述客户端用所述验证平台的公钥将用于与所述验证平台之间的会话的临时对称密钥与所述商家标识进行加密后发送给所述验证平台；

所述验证平台使用所述验证平台的私钥解密得到所述临时对称密钥与所述商家标识；

所述验证平台使用所述临时对称密钥对所述第一数字摘要和所述合法商家名称进行加密，随后再用所述验证平台的私钥加密；以及

所述客户端用所述验证平台的公钥对接收到的信息解密，随后再用所述临时对称密钥解密以得到所述第一数字摘要和所述合法商家名称。

3.如权利要求2所述的方法，其特征在于，所述公钥和所述私钥是所述验证平台针对每一次会话临时生成的。

4.如权利要求1所述的方法，其特征在于，进一步包括：

所述商家向所述验证平台提供商家资质和合法支付二维码；

所述验证平台对所述商家资质进行验证；

验证通过后，所述验证平台将所述商家提供的合法商家标识、合法商家名称、以及所述合法支付二维码存入所述数据库；

所述验证平台基于所述合法商家标识、所述合法支付二维码、以及所述验证平台的合法地址生成防伪支付二维码；以及

将所述防伪支付二维码提供给所述商家供用户扫描。

5.一种支付方法，包括：

使用支付客户端扫描线下支付二维码；

所述支付客户端调用嵌入的二维码验证模块通过如上述权利要求中的任意一项的方法来验证所扫描的线下支付二维码是否合法；以及

响应于验证所扫描的线下支付二维码合法，所述支付客户端调用支付接口以完成支付过程。

6.一种用于验证支付二维码合法性的验证平台，所述验证平台用于：

响应于接收到商家提供的商家资质和合法支付二维码而对所述商家资质进行验证；

在验证通过后，将从所述商家接收到的合法商家标识、合法商家名称、以及所述合法支付二维码存入数据库；

基于所述合法商家标识、所述合法支付二维码、以及所述验证平台的合法地址生成防伪支付二维码；以及

将所述防伪支付二维码提供给所述商家供用户线下扫描。

7.如权利要求6所述的验证平台，其特征在于，

响应于用户使用客户端扫描商家的线下支付二维码发起的请求而与所述客户端建立连接；

基于从所述客户端接收到的商家标识在所述数据库中查询对应的合法二维码数据和合法商家名称；

基于查询到的合法二维码数据生成第一数字摘要，并将所述第一数字摘要和所述合法商家名称发送给所述客户端，以供所述客户端将所述第一数字摘要与所述客户端基于扫描的线下支付二维码生成的第二数字摘要进行比较以及所述用户将所述合法商家名称与当前线下的商家名称进行比对。

8.如权利要求7所述的验证平台，其特征在于，

生成包括公钥和私钥的临时非对称密钥；

将所述公钥发送给客户端；

从所述客户端获得用所述公钥将用于与所述验证平台之间的会话的临时对称密钥与所述商家标识进行加密后的数据；

使用所述私钥解密所述数据得到所述临时对称密钥与所述商家标识；以及

使用所述临时对称密钥对所述第一数字摘要和所述合法商家名称进行加密，随后再用所述私钥加密并发送给所述客户端。

9.一种移动计算设备，所述移动计算设备包括：

显示装置；

二维码扫描装置，所述二维码扫描装置被配置成扫描商家的线下支付二维码；以及

支付客户端，所述支付客户端配置成：

解析用户使用所述二维码扫描装置扫描的商家的线下支付二维码以获取验证平台地址以及商家标识；

基于所述验证平台地址与验证平台建立连接；

将所述商家标识上传至所述验证平台；

从所述验证平台接收第一数字摘要和商家名称，其中所述验证平台基于所述商家标识在数据库中查询对应的合法二维码数据和商家名称并基于所述合法二维码数据来生成所述第一数字摘要；

基于扫描的线下支付二维码生成第二数字摘要；

对所述第一数字摘要和所述第二数字摘要进行比较；

如果所述第一数字摘要和所述第二数字摘要一致，向用户显示所述商家名称以供用户与当前线下的商家名称比对；以及

响应于用户确定显示的商家名称与当前线下的商家名称一致而确定所述线下支付二维码合法。

10.如权利要求9所述的移动计算设备，其特征在于，所述支付客户端具有嵌入的二维码验证SDK，并且所述验证所扫描的线下支付二维码是否合法的步骤由所述二维码验证SDK执行。

Images