CN117350715A - 支付方法、账户配置方法、系统、装置、设备和介质 - Google Patents

Abstract

本申请公开了一种支付方法、账户配置方法、系统、装置、设备和介质，涉及电子支付技术领域，具体涉及离线支付安全技术领域。其中一种支付方法应用于支付端服务器，该方法包括：获取收款设备发送的第一收款信息和支付验证信息；支付验证信息是付款设备对来自收款设备的第二收款信息进行签名处理或者签名加密处理生成的；第一收款信息和第二收款信息为目标交易的收款信息；基于支付验证信息验证第一收款信息，获得验证结果；若验证结果为通过，则根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，获得目标交易的交易结果。能够提高付款设备使用的便利性以及安全性。

Description

支付方法、账户配置方法、系统、装置、设备和介质

技术领域

本申请一般涉及电子支付技术领域，具体涉及离线支付安全技术领域，尤其涉及一种支付方法、账户配置方法、系统、装置、设备和介质。

背景技术

数字经济时代，技术驱动力所带来的创新价值和竞争力，不断快速催生各类创新产品形态和服务能力。在电子化货币流通的过程中，硬件钱包正日益影响着人们日常生活的各个方面，其离线支付功能也越来越受到用户的喜爱。

现有技术中，在使用硬件钱包之前，需要向硬件钱包(如公交卡)中充值，而后才可以使用，但这种提前充值的方式不仅非常麻烦，而且支付安全性也非常低。

发明内容

鉴于现有技术中的上述缺陷或不足，期望提供一种支付方法、账户配置方法、系统、装置、设备和介质，能够提高付款设备使用的便利性以及安全性。

第一方面，本申请提供了一种支付方法，应用于支付端服务器，该方法包括：获取收款设备发送的第一收款信息和支付验证信息；支付验证信息是付款设备对来自收款设备的第二收款信息进行签名处理或者签名加密处理生成的；第一收款信息和第二收款信息为目标交易的收款信息；基于支付验证信息验证第一收款信息，获得验证结果；若验证结果为通过，则根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，获得目标交易的交易结果。

第二方面，本申请提供了一种账户配置方法，应用于虚拟钱包客户端，该方法包括：显示付款设备的至少一个配置项；接收至少一个配置项的配置操作，并根据配置操作确定付款设备的配置信息；向支付端服务器发送配置信息，配置信息用于支付端服务器生成虚拟钱包和付款设备的绑定关系。

第三方面，本申请提供了一种支付方法，应用于虚拟钱包客户端，该方法包括：接收来自收款设备第二收款信息；对第二收款信息进行签名处理或者签名加密处理，生成支付验证信息，；将支付验证信息传输至收款设备，支付验证信息用于收款设备向服务器发送，使得支付端服务器基于支付验证信息验证第一收款信息获得验证结果，并在验证结果为通过的情况下，根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，获得目标交易的交易结果；第一收款信息是收款设备向服务器发送的，第一收款信息和第二收款信息为目标交易的收款信息。

第四方面，本申请提供了一种支付系统，该支付系统包括：付款设备，用于接收来自收款设备的第二收款信息；付款设备，还用于对第二收款信息进行签名处理或者签名加密处理，生成支付验证信息，并将支付验证信息传输至收款设备；收款设备，用于将支付验证信息和第一收款信息发送至支付端服务器；第一收款信息和第二收款信息为目标交易的收款信息；支付端服务器，用于基于支付验证信息验证第一收款信息，获得验证结果；若验证结果为通过，则根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，获得目标交易的交易结果。

第五方面，本申请提供了一种支付装置，应用于支付端服务器，该支付装置包括：获取单元，用于获取收款设备发送的第一收款信息和支付验证信息；支付验证信息是付款设备对来自收款设备的第二收款信息进行签名处理或者签名加密处理生成的；第一收款信息和第二收款信息为目标交易的收款信息；验证单元，用于基于支付验证信息验证第一收款信息，获得验证结果；交易处理单元，用于若验证结果为通过，则根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，获得目标交易的交易结果。

第六方面，本申请提供了一种账户配置装置，应用于虚拟钱包客户端，该账户配置装置包括：显示单元，用于显示付款设备的至少一个配置项；接收单元，用于接收至少一个配置项的配置操作；处理单元，用于根据配置操作确定付款设备的配置信息；发送单元，用于向支付端服务器发送配置信息，配置信息用于支付端服务器生成虚拟钱包和付款设备的绑定关系。

第七方面，本申请提供了一种支付装置，应用于付款设备，该支付装置包括：接收单元，用于接收来自收款设备第二收款信息；签名单元，用于对第二收款信息进行签名处理或者签名加密处理生成支付验证信息；传输单元，用于将支付验证信息传输至收款设备，支付验证信息用于收款设备向服务器发送，使得支付端服务器基于支付验证信息验证第一收款信息获得验证结果，并在验证结果为通过的情况下，根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，获得目标交易的交易结果；第一收款信息是收款设备向服务器发送的，第一收款信息和第二收款信息为目标交易的收款信息。

第八方面，本申请实施例提供了一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，该处理器执行该程序时实现如本申请实施例描述的方法。

第九方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请实施例描述的方法。

第十方面，本申请实施例提供一种计算机程序产品，该计算机程序产品包括指令，当该指令被运行时，使得如本申请实施例描述的方法被执行。

本申请提出的支付方法、账户配置方法、系统、装置、设备和介质，用户在使用付款设备进行交易时，收款设备将该笔交易的收款信息分别发送至付款设备和支付端服务器；付款设备对收到的收款信息(即第二收款信息)进行签名处理或者签名加密处理生成支付验证信息；将该支付验证信息再通过收款设备传输至支付端服务器。支付端服务器利用支付验证信息对来自收款设备的收款信息(即第一收款信息)进行验证。由于第一收款信息和第二收款信息均对应同一交易(即目标交易)；因此，通过上述验证这一手段，不仅能够确定出付款设备是否对第一收款信息进行支付授权，而且能够识别出第一收款信息在传输的过程中是否被恶意篡改，从而保证了收款信息的真实性，避免了错误扣款的情况。

另外，在第一收款信息验证通过的情况下，支付端服务器根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，获得该笔交易的交易结果。这样，用户可以通过付款设备进行现场交易，在虚拟钱包中进行该笔交易的处理(即扣款处理)，实现了无需向付款设备中进行提前充值也能利用付款设备进行交易的目的，并保证了付款设备的使用安全性。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为本申请实施例提供的支付系统的结构示意图；

图2为本申请实施例提供的支付方法的流程示意图；

图3为本申请实施例提供的密钥配置界面的效果示意图；

图4为本申请实施例提供的账户配置方法的流程示意图；

图5a为本申请实施例提供的虚拟钱包客户端的效果示意图；

图5b为本申请实施例提供的配置界面的效果示意图；

图6为本申请实施例提供的又一配置界面的效果示意图；

图7为本申请实施例提供的支付方法的另一流程示意图；

图8为本申请实施例提供的支付系统的架构示意图；

图9为本申请实施例提供的支付装置的结构示意图；

图10为本申请实施例提供的账户配置装置的结构示意图；

图11为本申请实施例提供的又一支付装置的结构示意图；

图12为本申请实施例提供的计算机设备的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

近几年来，硬件钱包一直是电子化货币的主要钱包之一。其原因是硬件钱包更具有抵抗大多数已知网络媒介攻击的能力，它已经成为电子化货币钱包安全的“黄金标准”。

现有技术中，在使用硬件钱包之前，需要向硬件钱包(如公交卡)中充值，而后才可以使用，但这种提前充值的方式不仅非常麻烦，而且支付安全性也非常低。

基于此，本申请实施例提供一种支付方法、账户配置方法、系统、装置、设备和介质，其主要原理是：用户可在虚拟钱包客户端对付款设备进行绑定授权，具体可以通过虚拟钱包客户端中展示的付款设备的至少一个配置项中进行配置操作，以获取配置信息，并将该配置信息发送至支付端服务器；使支付端服务器根据配置信息生成虚拟钱包与付款设备的绑定关系以及对付款设备的交易限制规则。在用户使用付款设备进行交易时，收款设备将该笔交易对应的收款信息分别发送至付款设备以及支付端服务器；付款设备根据收到的收款信息进行签名操作或者签名加密操作生成支付验证信息；将该支付验证信息再通过收款设备传输至支付端服务器。支付端服务器利用支付验证信息对来自收款设备的收款信息进行验证。在支付验证信息验证通过的情况下，支付端服务器根据收款信息对付款设备绑定的虚拟钱包进行交易处理，获得该笔交易的交易结果。通过本申请实施例中所提供的方法能够保证收款信息的真实性，避免了错误扣款的情况。

图1为本申请实施例提供的一种支付系统的结构示意图。本申请实施例所提供的支付方法可应用于该支付系统100。参考图1，该支付系统100包括付款设备101、虚拟钱包客户端102、收款子系统103以及支付端服务器104。其中收款子系统103至少包括收款设备1031，还可以包括收款端服务器1032；当收款设备1031能够与支付端服务器104进行直接通信的情况下，收款子系统103可以不包括收款端服务器1032；例如，当收款设备1031的后台服务器为支付端服务器104时，收款设备1031可以与支付端服务器104进行直接通信。这时则无需收款端服务器1032。又如，当收款设备1031的后台服务器不为支付端服务器104时，收款设备1031则需要通过收款端服务器1032与支付端服务器104进行间接通信。

在一个实施例中，付款设备101是依托货币流通体系的支付工具，可以存储用户身份认证信息(如标识或私钥)，并具有一定的计算能力，具有唯一可识别编号的硬件产品，具体可以为硬件钱包，该硬件钱包包括但不限于如公交卡或门禁卡等形式的IC卡，也可以是安装于IC卡或终端设备中的模块。付款设备101与收款设备1031可采用近场通信(nearfield communication，NFC)网络进行数据的传输。付款设备101与虚拟钱包客户端102之间的数据可以通过近场通信网络、有线数据传输技术或者通过驱动硬件设备这种第三方传输设备等方式进行传输。付款设备101与支付端服务器104的数据传输方式同理，此处不在赘述。

在另一个实施例中，虚拟钱包客户端102为终端设备中的应用程序。

示例性的，终端设备可以是包括但不限于个人计算、平台电脑、智能手机、车载终端等设备，本申请实施例对此不作限定。支付端服务器104和收款端服务器1032均可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供支付技术的基础云计算服务的云服务器。

下面将结合图1，以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。以下具体地实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

如图2所示，本申请实施例提供一种支付方法，应用于上述的支付端服务器102中，该方法具体包括以下步骤：

201、获取收款设备发送的第一收款信息和支付验证信息；支付验证信息是付款设备对来自收款设备的第二收款信息进行签名处理或者签名加密处理生成的；第一收款信息和第二收款信息为目标交易的收款信息。

可以理解的，第一收款信息和第二收款信息为同一笔交易(即目标交易)的收款信息。

需要说明的是，若第一收款信息在传输的过程中未被更改，则第一收款信息与第二收款信息可以理解为同一收款信息，即该目标交易的收款信息。

作为一个实例，收款信息可以包括交易的基本信息，基本信息可以包括如下信息中的至少一个：收款方信息、交易金额、交易标识、交易类型、交易币种、交易时间。收款方信息例如可以是收款设备的标识以及收款设备所对应的账户名称(例如商户名称)。交易金额为本次交易的变动金额。交易标识为该笔交易的标识，具有唯一性。交易类型包括但不限于支付、收款和退款等。交易币种可以包括但不限于人民币、美元、欧元等。收款设备的标识具有唯一性，可以唯一确定出收款设备，通过收款设备的账户名称可以明确收款方的身份。在本申请实施例中，支付端服务器在获取收款信息时，也需要先征得付款设备以及收款设备的同意或许可，并且支付端服务器获取的收款信息也需要符合法律法规和相关的规则标准。

进一步的，收款设备还需要将付款设备发送的付款设备的标识与第一收款信息一同传输至支付端服务器。其中，付款设备的标识可以用于支付端服务器获取付款设备的公钥以及确定付款设备绑定的虚拟钱包；另外，当付款设备在生成支付验证信息时，除了用到了第二收款信息，还用到的付款设备的标识，则支付端服务器还可利用付款设备的公钥对第一收款信息以及付款设备的表示进行签名处理，得到待验证信息，以使支付验证信息验证该待验证信息是否正确。

在一种实现方式中，付款设备根据来自收款设备的第二收款信息结合付款设备的标识和/或授权签名盐生成支付验证信息。

202、基于支付验证信息验证第一收款信息，获得验证结果。

需要说明的是，支付端服务器在利用支付验证信息对第一收款信息进行验证时，需采用与付款设备在生成支付验证信息相同的算法，例如，当付款设备生成支付验证信息采用的是RSA(rivest-shamir-adleman)算法中的签名流程，则支付端服务器采用RSA算法中的解签流程对第一收款信息进行验证。又如，当付款设备生成支付验证信息采用的是RSA算法中签名加密流程，则支付端服务器采用RSA算法中的签名解密流程对第一收款信息进行验证。

进一步的，当付款设备在生成支付验证信息时，采用的是付款设备的标识与第二收款信息，对应的，支付端服务器利用支付验证信息对第一收款信息进行验证的过程中就需要基于付款设备的标识以及第一收款信息。

可选的，当支付验证信息是对第一收款信息进行签名加密得到的，支付端服务器在接收到支付验证信息时，可以通过付款设备的标识获取付款设备的公钥，通过付款设备的公钥对支付验证信息进行解密处理，以得到第二收款信息对应的摘要信息h，并基于上述付款设备所使用的摘要提取算法对接收到的第一收款信息进行摘要提取，从而可以得到第一收款信息的摘要信息H，进而可以将所得到的摘要信息h和哈希计算所得到的摘要信息H进行比较，得到验证结果。

在一种可能的实现方式中，在摘要信息h与摘要信息H匹配时，验证结果则为通过；在摘要信息h与摘要信息H不匹配时，验证结果则为不通过。可以理解的是，验证结果则为不通过，支付端服务器可以拒绝与收款设备进行该笔目标交易；在验证结果则为通过时，支付端服务器可以对该笔目标交易进行后续的交易处理。

在一个优选的方案中，在摘要信息h与摘要信息H相同时，验证结果则为通过；在摘要信息h与摘要信息H不相同时，验证结果则为不通过。可以理解的是，验证结果则为不通过，支付端服务器可以拒绝与收款设备进行该笔目标交易；在验证结果则为通过时，支付端服务器可以对该笔目标交易进行后续的交易处理。

203、若验证结果为通过，则根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，获得目标交易的交易结果。

可选的，目标交易的交易结果包括交易成功和交易失败两种结果。在交易失败的情况下，可以将交易失败的原因发送至收款设备，也可以将交易失败的原因发送至虚拟钱包客户端，本申请实施例对此不作限定。交易失败的原因可以是如账户余额不足或者不满足交易限制规则等。

具体的，根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理包括以下两种实现方式：

在其中一种实现方式中，支付端服务器根据付款设备的标识确定其所绑定的虚拟钱包，并确定虚拟钱包中的余额是否大于或等于第一收款信息中的交易金额；如果是，则可以直接扣除虚拟钱包中的交易金额并将该交易金额转移至收款设备；如果不是，则向收款设备返回交易失败的反馈信息，该反馈信息中可以携带交易失败的原因(如余额不足)，也可以不携带，本申请实施例对此不作任何限定。

在另一种实现方式中，支付端服务器根据付款设备的标识确定付款设备所绑定的虚拟钱包，并直接根据第一收款信息中的交易金额直接对虚拟钱包中的余额执行交易金额的扣除操作，若虚拟钱包中的余额大于或等于交易金额时，则会扣除成功，并将扣除的交易金额转移至收款设备；若虚拟钱包中的余额小于交易金额时，则会扣除失败向收款设备返回交易失败的反馈信息，该反馈信息中可以携带交易失败的原因(如余额不足)，也可以不携带，本申请实施例对此不作任何限定。需要说明的是，若反馈信息中携带的交易失败的原因涉及到用户隐私问题，则需要用户进行授权，才可在反馈信息中携带涉及用户隐私的交易失败的原因。

本申请实施例提出的支付方法，用户在使用付款设备进行交易时，收款设备将该笔交易的收款信息分别发送至付款设备和支付端服务器；付款设备对收到的收款信息(即第二收款信息)进行签名处理或者签名加密处理生成支付验证信息；将该支付验证信息再通过收款设备传输至支付端服务器。支付端服务器利用支付验证信息对来自收款设备的收款信息(即第一收款信息)进行验证。由于第一收款信息和第二收款信息均对应同一交易(即目标交易)；因此，通过上述验证这一手段，不仅能够确定出付款设备是否对第一收款信息进行支付授权，而且能够识别出第一收款信息在传输的过程中是否被恶意篡改，从而保证了收款信息的真实性，避免了错误扣款的情况。

另外，在第一收款信息验证通过的情况下，支付端服务器根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，获得该笔交易的交易结果。这样，用户可以通过付款设备进行现场交易，在虚拟钱包中进行该笔交易的处理(即扣款处理)，实现了无需向付款设备中进行提前充值也能利用付款设备进行交易的目的，并保证了付款设备的使用安全性。

在本申请的另一实施例中，当付款设备与支付端服务器约定的支付验证信息的生成方式为签名方式，则可通过对第一收款信息进行签名处理，并基于支付验证信息对该签名信息进行验证，以得到验证结果。具体的，支付验证信息是付款设备对来自收款设备的第二收款信息进行签名得到，基于支付验证信息验证第一收款信息，获得验证结果，包括：利用付款设备的公钥对第一收款信息进行签名处理，得到待验证信息；根据支付验证信息验证待验证信息，确定验证结果。

可以理解的是，本实施例中根据支付验证信息验证待验证信息实际是将支付验证信息与待验证信息进行匹配。具体的匹配方式可根据所选用的签名算法确定，本申请实施例对此不作限定。

在一个优选的方案中，针对所选用的签名算法，均可采用以下匹配方式：当待验证信息与支付验证信息相同时，验证结果为通过；当待验证信息与支付验证信息不同时，验证结果为失败或者不通过。

可选的，可采用第一预设的签名算法实现支付验证信息以及待验证信息的生成，第一预设的签名算法可以为第一预设的非对称签名算法或者第一预设的对称签名算法。为了进一步保证签名信息的安全性，这里优选非对称签名算法实现支付验证信息和待验证信息的生成。

具体的，付款设备利用第一预设的签名算法对第二收款信息进行签名处理得到支付验证信息，支付端服务器利用与付款设备相同的签名算法，并采用付款设备的公钥对第一摘要信息进行签名处理得到待验证信息，支付端服务器通过判断支付验证信息与待验证信息是否相同，得到对应的验证结果。其中付款设备的私钥和公钥可根据第一预设的非对称签名算法得到。在本申请实施例中，支付端服务器在获取付款设备的公钥时，也需要先征得付款设备以及收款设备的同意或许可，并且支付端服务器获取的付款设备的公钥也需要符合法律法规和相关的规则标准。

进一步的，计算支付验证信息的参数不限于第一收款信息，还可以包括付款设备的标识和/或授权签名盐；同理，计算待验证信息的参数不限于第二收款信息，还可以包括付款设备的标识和/或授权签名盐。本申请实施例对此不作任何限定，只需要计算支付验证信息和待验证信息的参数组成相同即可。

作为一个示例，假设无论是计算支付验证信息还是计算待验证信息时的参数组成均包括收款信息、付款设备的标识以及授权签名盐。那么，付款设备利用其私钥(即授权私钥证书)计算得到支付验证信息可以是利用授权私钥证书对付款设备的标识、第二收款信息、授权签名盐进行签名，得到支付验证信息，即支付验证信息＝签名sign(付款设备的标识+第二收款信息+授权签名盐，授权私钥证书)；支付端服务器利用付款设备的公钥(即授权公钥证书)计算得到待验证信息具体可以是利用授权公钥证书对付款设备的标识、第一收款信息、授权签名进行签名，得到待验证信息，即待验证信息＝签名sign(付款设备的标识+第一收款信息+授权签名盐，授权公钥证书)；最后，支付端服务器确定“支付验证信息”是否等于“待验证信息”判断签名合法性，以得到验证结果；即验证结果＝验证签名checksign(待验证信息，支付验证信息)。

示例性的，第一预设的签名算法可以是DSA(digital signature algorithm)算法或者RSA算法。

本实施例中，通过判断利用付款设备的公钥对第一收款信息进行签名处理得到的待验证信息与支付验证信息，来确定验证结果，能够验证传输过程中信息的完整性，以便识别出第一收款信息在传输的过程中是否被恶意篡改，从而保证了收款信息的真实性，避免了错误扣款的情况。

在本申请的一个实施例中，当付款设备与支付端服务器约定的支付验证信息的生成方式为签名加密的方式，则支付端服务器还可以获取支付验证信息过程中的摘要信息与第一收款信息对应的摘要信息进行对比，以确定验证结果。因此，在一种实现方式中，支付验证信息是付款设备对来自收款设备的第二收款信息进行签名加密得到，基于支付验证信息验证第一收款信息，获得验证结果，包括：利用付款设备的公钥对支付验证信息进行解密处理，得到第二摘要信息；对第一收款信息进行摘要提取，得到第一摘要信息；根据第二摘要信息验证第一摘要信息，确定验证结果。

可以理解的是，本实施例中；根据第二摘要信息验证第一摘要信息实际是将第一摘要信息与第二摘要信息进行匹配。具体的匹配方式可根据所选用的签名算法确定，本申请实施例对此不作限定。

在一个优选的方案中，当第一摘要信息与第二摘要信息相同时，验证结果为通过；当第一摘要信息与第二摘要信息不同时，验证结果为失败或者不通过。

可选的，可采用第二预设的摘要提取算法结合第二预设的签名算法实现签名加密以及签名验证。具体的，付款设备采用其私钥对第一收款信息进行摘要提取(即签名)，得到第一摘要信息，并利用私钥对第一摘要信息进行加密处理得到支付验证信息，支付端服务器采用付款设备的公钥对支付验证信息进行解密处理，得到第一摘要信息；再对第二收款信息进行摘要提取(即签名)得到第二摘要信息。支付端服务器通过判定第一摘要信息与第二摘要信息是否相同，得到对应的验证结果。其中付款设备的私钥和公钥可根据第二预设的非对称签名算法得到。

进一步的，本申请的实施例不限于对第一收款信息进行摘要提取得到的第一摘要信息，还可以对第一收款信息和/或付款设备的标识和/或授权签名盐进行摘要提取得到第一摘要信息；同理，不限于对第二收款信息进行摘要提取得到的第二摘要信息，还可以对第二收款信息和/或付款设备的标识和/或授权签名盐进行摘要提取得到第二摘要信息。本申请实施例对此不作任何限定，只需提取第一摘要信息和第二摘要信息的参数组成相同即可。

作为一个示例，假设无论是提取第一摘要信息还是提取第二摘要信息时的参数组成均包括收款信息、付款设备的标识以及授权签名盐。那么，付款设备利用其私钥(即授权私钥证书)计算得到支付验证信息可以是对付款设备的标识和第二收款信息进行加盐(即授权签名盐)摘要提取(即签名)得到第二摘要信息，即第二摘要信息＝签名sign(付款设备的标识+第二收款信息+授权签名盐)，并利用授权私钥证书对第二摘要信息进行签名，得到支付验证信息，即支付验证信息＝加密encrypt(第二摘要信息，授权私钥证书)；支付端服务器利用付款设备的公钥(即授权公钥证书)对支付验证信息进行解密，得到第二摘要信息，即第二摘要信息＝解密decrypt(支付验证信息，授权公钥证书)。再对付款设备的标识和第一收款信息进行加盐摘要提取(即签名)，得到第一摘要信息，即第一摘要信息＝签名sign(付款设备的标识+第一收款信息+授权签名盐)；最后，支付端服务器确定“支付验证信息”是否等于“待验证信息”判断签名合法性，以得到验证结果，即验证结果＝验证摘要(第一摘要信息，第二摘要信息)。

示例性的，第二预设的签名算法可以是国密算法SM2或者RSA算法。第一预设的摘要提取算法可以是消息摘要算法版本5(message digest algorithm5，MD5)、安全散列算法1(secure hash algorithm-1，SHA-1)或者安全散列算法256(secure hash algorithm-256，SHA-256)等摘要提取算法。

本实施例中，利用付款设备的公钥对支付验证信息进行解密处理得到第二摘要信息，并对第一收款信息进行摘要提取得到第一摘要信息，通过判断第一摘要信息与第二摘要信息，来确定验证结果，能够验证传输过程中信息的完整性，以便识别出第一收款信息在传输的过程中是否被恶意篡改，从而保证了收款信息的真实性，避免了错误扣款的情况。

在本申请的一个实施例中，在使用付款设备进行现场交易之前，还需通过虚拟钱包客户端来实现对付款设备的信息配置。因此，本申请实施例所述提供的支付方法还包括：支付端服务器接收来自虚拟钱包客户端的配置信息，根据配置信息对虚拟钱包进行配置；配置信息至少用于为虚拟钱包配置付款设备。

在一种实现方式中，该配置信息具体可用于建立付款设备和虚拟钱包的绑定关系，和/或设置付款设备的支付权限(如交易限制规则)，和/或其他的一些信息设置，本申请实施例对此不作限定。其中，支付权限用于表征使用付款设备进行交易的限制条件。例如，支付权限可以对收款者白名单的限制、交易类型的限制、连续交易间隔时间的限制、交易额度的限制以及交易次数的限制等数据；交易类型的限制可以包括餐饮、商超等商户类型交易的限制；交易额度限制可以包括单笔交易额度限制、单日交易总额度限制、月交易总额度限制等；交易次数的限制可以是单日交易次数限制等；通过建立付款设备和虚拟钱包的绑定关系或者设置支付权限，可以使付款设备具有一定限度的支付权限，使得持有付款设备的用户可以在一定权限范围内独立的完成支付，从而提高支付效率，同时为持有付款设备的用户(如孩子或者老人)以及指定的移动终端所在的用户(如家长)提供更便捷的支付以及管控方案。在本申请实施例中，支付端服务器在获取虚拟钱包客户端的配置信息时，也需要先征得虚拟钱包客户端的同意或许可，并且支付端服务器获取的配置信息也需要符合法律法规和相关的规则标准。

进一步的，配置信息还包括对付款设备的交易限制规则中的目标项的修改、删除等信息。具体的，当支付端服务器接收到的配置信息为对交易限制规则中的目标项的修改信息或删除信息时，则根据修改信息修改该目标项，或者根据删除信息对目标项进行删除。其中，根据修改信息修改该目标项可以是将目标项中的当前信息替换为修改信息。

示例性的，可以用键值对的方式将付款设备的标识与虚拟钱包的标识进行存储，来形成付款设备与虚拟钱包的绑定关系。

可选的，虚拟钱包客户端可以是终端设备中一个单独的应用程序(application，APP)，也可以是某一应用程序中的一个小程序，或者是web浏览器。本申请实施例对此不作任何限定。

本实施例中，通过对来自虚拟钱包客户端的配置信息对虚拟钱包进行配置，从而实现为虚拟钱包配置付款设备的目的，以便为付款设备的持有者提供更为便捷的支付功能。

在本申请的另一实施例中，根据配置信息对虚拟钱包进行配置，包括：支付端服务器根据配置信息生成虚拟钱包与付款设备的绑定关系，以及付款设备的交易限制规则。

在实际应用中，虚拟钱包与付款设备的对应关系可以是一对一，也可以是一对多。也就是说，虚拟钱包能够至少绑定一个付款设备，虚拟钱包的持有者可根据付款设备的实际需求量进行配置。

在一种可能的实现方式中，支付端服务器在生成付款设备的交易限制规则后，可以存储于本地，在付款设备发生交易行为时，支付端服务器可基于本地存储的交易限制规则对该交易行为所形成的收款信息进行规则匹配，确定其收款信息是否满足所设置的交易限制规则。

在另一种可能的实现方式中，支付端服务器在生成付款设备的交易限制规则后，可将交易限制规则的部分或者全部传输至付款设备。

例如，假设支付端服务器将部分交易限制规则的传输至付款设备，那么交易限制规则分为第一交易限制规则和第二交易限制规则。支付端服务器将第一交易限制规则传输至付款设备，将第二交易限制规则存储于本地。在付款设备发生交易行为时，付款设备可基于接收到的第一交易限制规则对该交易行为所形成的收款信息进行规则匹配，确定其第二收款信息是否满足第一交易限制规则。若不满足，付款设备则直接拒绝该笔交易；从而减少支付端服务器的计算压力。若满足，则对第二收款信息进行签名加密生成支付验证信息，以便收款设备将该支付验证信息与第一收款信息发送至支付端服务器。支付端服务器基于支付验证信息验证第一收款信息，并在验证通过的情况下，基于第二交易限制规则对第一收款信息进行规则匹配，确定该第一收款信息是否满足第二交易限制规则。

又如，假设支付端服务器将全部交易限制规则的传输至付款设备。在付款设备发生交易行为时，付款设备可基于接收到的交易限制规则对该交易行为所形成的收款信息进行规则匹配，确定其第二收款信息是否满足交易限制规则。若不满足，付款设备则直接拒绝该笔交易；从而减少支付端服务器的计算压力。若满足，则对第二收款信息进行签名加密生成支付验证信息，以便收款设备将该支付验证信息与第一收款信息发送至支付端服务器。支付端服务器基于支付验证信息验证第一收款信息，并在验证通过的情况下，根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，从而获得目标交易的交易结果。

当然，为了进一步保障支付的安全性，交易限制规则也可同时存储于支付端服务器以及付款设备中，在付款设备发生交易行为后，由支付端服务器和付款设备分别对交易行为所产生的收款信息进行规则匹配，本申请实施例对此不作任何限定。

本申请实施例中，通过生成虚拟钱包与付款设备的绑定关系以及付款设备的交易限制规则，可以使付款设备具有一定限度的支付权限，使得付款设备的持有者可以在一定权限范围内独立的完成支付，从而提高支付效率，同时为付款设备的持有者提供更便捷的支付以及管控方案，并降低了恶意交易的风险。

在本申请的一个实施例中，可基于配置的交易限制规则对收款信息进行规则匹配，从而进一步保障付款设备的支付安全性。因此，在一种实现方式中，根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理：若第一收款信息满足交易限制规则，支付端服务器则根据第一收款信息对虚拟钱包进行扣款处理；若不满足交易限制规则，支付端服务器则拒绝对虚拟钱包进行扣款处理。

这里，第一收款信息不满足交易限制规则中的至少一项，即可理解为第一收款信息不满足交易限制规则。

其中，交易限制规则可以包括是否为收款者白名单、是否为预设的交易类型、连续交易间隔时间是否满足预设间隔时间、交易额度是否大于预设交易额度以及交易次数是否小于预设次数等数据中的至少一项。其中，预设的交易类型可以包括宾馆、餐饮、娱乐、珠宝金饰、工艺美术品类等类型；预设交易额度可以包括单笔预设交易额度、单日预设交易总额度、月预设交易总额度限制中的一项或多项；预设交易次数可以是单日预设交易次数等。

在一个实施场景中，支付端服务器在单笔交易的金额超过单笔交易额度限制时，则拒绝处理该笔交易，并向收费终端发送交易失败的信息，同时，还可提示收费终端交易失败的原因为超过单笔交易额度限制。

在另一个实施场景中，支付端服务器核实收费终端所对应的商户名称是否属于白名单中的商户，若不属于，则拒绝处理该笔交易，并向收费终端发送交易失败的信息，同时，还可提示收费终端交易失败的原因为非白名单商户。

本实施例中，为了确保交易的安全性和可靠性，根据付款设备的交易限制规则对收款信息进行规则匹配，对于满足交易限制规则的收款信息，支付端服务器对虚拟钱包进行扣款处理；对于不满足交易限制规则的收款信息，则拒绝对虚拟钱包进行扣款处理，通过限制和约束付款设备进行离线交易的规模，从而降低恶意交易的风险。

在本申请的一个实施例中，为了减少付款设备以及虚拟钱包客户端的计算压力，对于付款设备的公钥和私钥可以由支付端服务器生成，因此，本申请实施例所提供的支付方法还包括：支付端服务器生成付款设备的公钥和私钥，向付款设备发送私钥，私钥用于付款设备根据第二收款信息生成支付验证信息，公钥用于验证第一收款信息。

具体的，支付端服务器采用预设的签名算法，生成付款设备的私钥和公钥。其中预设的签名算法可以是上述的第一预设的签名算法或者第二预设的签名算法，对于第一预设的签名算法或者第二预设的签名算法的相关实施例可参考上述，此处不在赘述。

进一步的，支付端服务器采用预设的签名算法，生成付款设备的私钥和公钥，具体可以包括：支付端服务器根据基于预设的签名算法的门限密码算法，生成付款设备的私钥和公钥。

在一个示例性的方案中，用户可以通过虚拟钱包客户端的密钥配置界面自行配置签名算法类型等密钥信息。如图3所示，图3为一个实施例中虚拟钱包客户端的密钥配置界面示意图。当用户需要生成密钥时，用户可以通过虚拟钱包客户端的密钥配置界面301，获取用户配置的部分密钥信息，例如，图3中示出的密钥名称、密钥描述信息以及密钥算法类型。虚拟钱包客户端可以生成携带密钥信息的密钥生成请求，并将该密钥生成请求传输至支付端服务器。支付端服务器可以根据用户配置的密钥信息中所选择的密钥算法类型生成付款设备的私钥(即授权私钥证书)、公钥(即授权公钥证书)、授权签名盐，并将私钥、授权签名盐传输至付款设备，为保障付款设备的私钥的安全性，支付端服务器还可在私钥、授权签名盐传输至付款设备之后，删除本地的该付款设备的私钥。

在一个优选的方案中，可以采用(t,n)秘密分享或(t,n)门限密码算法来生成多个付款设备的私钥分量。例如，如果采用(t,n)秘密分享，则先生成付款设备的私钥，然后将该付款设备的私钥拆分为n份，至少需要其中的t+1个分量可以恢复出初始的付款设备的私钥。又如，如果采用(t,n)门限密码算法，直接生成n个付款设备的私钥分量作为付款设备的私钥，其中的至少t+1个分量参与可以实现基于该付款设备的私钥的密码运算，在这一过程中，既不生成付款设备的私钥，使用时也无需恢复出付款设备的私钥，即付款设备的私钥自始至终都未曾出现完整的明文，而是以密钥分量的形式存在。显然，使用(t,n)门限密码算法生成付款设备的私钥的安全性更高，在本申请实施例中，优选地，使用(t,n)门限密码算法来直接生成付款设备的私钥分量作为付款设备的私钥。

本实施例中，支付端服务器生成付款设备的公钥和私钥后，将私钥发送至付款设备，以便付款设备能够基于私钥对第二收款信息进行签名加密操作得到支付验证信息，来保证信息传输过程的安全性。同时，支付端服务器还可利用公钥和支付验证信息来验证第一支付信息，识别出第一收款信息在传输的过程中是否被恶意篡改，从而保证了收款信息的真实性，避免了错误扣款的情况。

在本申请的另一实施例中，为了保障付款设备的私钥的安全性，可由付款设备生成其私钥和公钥，并将公钥传输至支付端服务器，因此本申请实施例所提供的支付方法还包括：支付端服务器接收付款设备发送的公钥；公钥用于验证第一收款信息；公钥与付款设备的私钥对应，私钥用于付款设备根据第二收款信息生成支付验证信息。

对于支付端服务器而言，只需将接收到的付款设备的公钥进行存储，当接收到该付款设备利用私钥进行签名的支付验证信息时，直接利用付款设备的公钥对支付验证信息进行验证即可，无需自己计算付款设备的公钥和私钥，减少了支付端服务器的计算量，同时，避免了付款设备私钥在各个设备之间流通，从而进一步保障了付款设备的私钥的安全性。

在本申请的另一实施例中，考虑到用户在使用付款设备的过程中，可能存在丢失或者不想使用该付款设备进行支付等情况，因此，本申请实施例所提供的支付方法还包括：支付端服务器接收来自虚拟钱包客户端的解绑指令；响应于解绑指令，删除虚拟钱包与付款设备的绑定关系。

可选的，响应于解绑指令，删除虚拟钱包与付款设备的绑定关系以及其他关于该付款设备的配置信息(如交易限制规则)。具体的，解绑指令可以携带付款设备的标识，通过付款设备的标识查找该付款设备与虚拟钱包的绑定关系以及其他关于该付款设备的配置信息。

作为一个示例，如果付款设备丢失或者用户不想再使用该付款设备实现支付时，用户可以通过虚拟钱包客户端进行解绑操作以生成相应的解绑指令，并将该解绑指令传输至支付端服务器中，支付端服务器可以查找该解绑指令所指向的虚拟钱包以及对应的付款设备，例如根据解绑指令所携带的付款设备的标识查找虚拟钱包与付款设备的绑定关系以及其他关于该付款设备的配置信息；并解除或者删除该虚拟钱包与该付款设备的绑定关系以及其他关于该付款设备的配置信息。

针对付款设备丢失的情况，即便其他用户捡到该付款设备，并使用该付款设备进行支付时，由于支付端服务器无法查找到付款设备绑定的虚拟钱包，进而无法实现支付，保证了虚拟钱包的资金安全。

需要说明的是，在实际应用中，同一个支付账号可以绑定一个或多个付款设备，即用户可以拥有多个付款设备，其中每个付款设备设置的标识不同。当某个付款设备丢失时，用户可以根据付款设备的标识等信息解除该丢失的付款设备和该虚拟钱包的绑定关系，避免了由于该付款设备的丢失造成的虚拟钱包中资金可能丢失的问题，在确保资金安全的同时，不影响其他付款设备的使用。

本实施例中，支付端服务器根据来自虚拟钱包客户端的解绑指令，删除虚拟钱包与付款设备的绑定关系，以便停止该付款设备后续支付功能。

参照图4，本申请实施例还提供一种账户配置方法，应用于虚拟钱包客户端，该方法包括：

401、虚拟钱包客户端显示付款设备的至少一个配置项。

其中，至少一个配置项可以是选择项和/或输入项。

作为一个示例，配置项可以是选择项。选择项支持用户根据实际的规则配置需求(例如，对日预设交易次数的规则配置需求)，在该选择项的下拉菜单中选择配置内容。用户选择的规则配置需求可以是日预设交易次数，用户选择的日预设交易次数用于表征用户每日使用付款设备的最高交易次数。

具体实现中，用户通过配置界面的选择项选择日预设交易次数后，支付端服务器可以获取用户通过选择项选择的日预设交易次数，根据用户选择的日预设交易次数确定配置信息。

作为另一个示例，配置项可以是输入项。输入项支持用户根据实际的规则配置需求(例如，对日预设交易次数的规则配置需求)，在该输入项输入配置内容。用户输入的规则配置需求可以是日预设交易次数，用户输入的日预设交易次数用于表征用户每日使用付款设备的最高交易次数。

具体实现中，用户通过配置界面的输入项输入日预设交易次数后，支付端服务器可以获取用户通过输入项输入的日预设交易次数，根据用户输入的日预设交易次数确定配置信息。

当然，配置项也可以同时包括选择项和输入项，当选择项中没有用户需要选择的配置内容，则可以通过输入的方式确定所需要的配置内容。例如，对于日预设交易次数，可能选择项的下拉菜单中只展示了常规的[1、2、3、4、5]这几个次数选项，而用户需要的次数为10次，那么，对于这种情况，用户可通过输入项输入10次，以便得到所需的日预设交易次数。

示例性的，假设虚拟钱包客户端为智能手机中一个单独的应用程序(application，APP)，该应用程序的名称设为虚拟钱包，参照图5a，用户可通过触发虚拟钱包的标识控件51，进入到(即展示)图5b所示的虚拟钱包的配置界面52，配置界面52中展示了关于付款设备的至少一个配置项，该配置项可以包括如图5b所示的付款设备的标识的配置项521、付款设备的交易限制规则的配置项522，其中，图5b中展示了付款设备的交易限制规则的配置项522包括的预设交易类型5221、预设日交易次数5222、预设交易额度5223。需要说明的是，图5b中仅示例性的展示了三种交易限制规则的配置项，不作为对本申请实施例对交易限制规则的配置项的具体限定，在配置交易限制规则时，可根据实际需求增加配置项或删除已有的配置项。对于付款设备的至少一个配置项可以是包括选择项和/或输入项。例如，对于付款设备的标识的配置项521可以只有输入项。对于预设交易类型5221、预设日交易次数5222、预设交易额度5223可以既有选择项，又有输入项。当选择项的下拉菜单中包含了用户所需要选取的配置内容，用户可通过选择下拉菜单中的配置内容以获取对于该选择项的选择。

需要说明的是，考虑到付款设备的标识的唯一性，在配置付款设备的标识可以自动生成具有唯一性的多个选项以供用户选择，也可以用户自行输入。虚拟钱包客户端对用户自行输入的付款设备的标识还可以进行唯一性的验证，当用户自行输入的付款设备的标识不具备唯一性时，可提醒用户输入新的付款设备的标识，或者在选择项中选择其中一个作为该付款设备的标识。

402、虚拟钱包客户端接收至少一个配置项的配置操作，并根据配置操作确定付款设备的配置信息。

具体的，该配置操作可以是对配置项的输入操作或者选择操作。这里，输入操作可以是字符输入操作，还可以是语音输入操作，当该输入操作为字符输入操作时，可以通过字符输入操作直接确定输入的字符；当该输入操作为语音输入操作时，可以在获取到输入的语音信息后，将语音信息转换为文字，得到输入的字符。

上述选择操作可以是指触摸操作、光标操作。其中，触摸操作可以是对目标选项的触摸点击操作、触摸按压操作或者触摸滑动操作，触摸操作也可以是对目标选项的单点触摸操作或者多点触摸操作；光标操作可以是控制光标进行对目标选项的点击的操作或者控制光标对目标选项的进行按压的操作；按键操作可以是对目标选项所对应的虚拟按键操作或者实体按键操作等。

403、虚拟钱包客户端向支付端服务器发送配置信息，配置信息用于支付端服务器生成虚拟钱包和付款设备的绑定关系。

进一步的，配置信息还用于生成付款设备的交易限制规则。

在一种实现方式中，配置操作还包括对至少一个目标项的修改操作或删除操作，对应的，配置信息还包括对付款设备的交易限制规则中的各个目标项的修改或者删除等信息。具体的，虚拟钱包客户端接收用户对交易限制项中的目标项的修改操作或删除操作，基于该修改操作或删除操作生成对应的修改信息或删除信息，并将修改信息或删除信息传输至支付端服务器。以使支付端服务器根据修改信息修改该目标项，或者根据删除信息对目标项进行删除。其中，根据修改信息修改该目标项可以是将目标项中的当前信息替换为修改信息。在本申请实施例中，虚拟钱包客户端在获取配置信息时，也需要先征得用户的同意或许可，并且钱包客户端获取的配置信息也需要符合法律法规和相关的规则标准。

对于交易限制规则的其他实施例可参考上述，此处不在赘述。

本申请实施例提出的账户配置方法，虚拟钱包客户端显示付款设备的至少一个配置项，以便用户通过各配置项对付款设备进行配置操作，虚拟钱包客户端响应用户针对各配置项的配置操作，生成付款设备的配置信息，并将该配置信息传输至支付端服务器，以使支付端服务器能够基于该配置信息生成虚拟钱包和付款设备的绑定关系，从而达到通过付款设备进行现场交易的目的。另外，该配置信息还用于生成付款设备的交易限制规则，为用户提供更为信任的支付环境，保证了付款设备的支付安全性。

在本申请的一个实施例中，考虑到用户在使用付款设备的过程中，可能存在丢失或者不想使用该付款设备进行支付等情况，用户可以通过虚拟钱包客户端直接进行解绑操作，已生成相应地解绑指令。具体的，在一种实现方式中，本申请实施例所提供的支付方法还包括：虚拟钱包客户端接收针对付款设备的解绑操作；并响应于解绑操作，生成解绑指令；向支付端服务器发送解绑指令，解绑指令用于指示支付端服务器删除虚拟钱包与付款设备的绑定关系。

示例性的，假设虚拟钱包客户端为智能手机中一个单独的应用程序，参照图6，用户可通过触发虚拟钱包的配置界面52中取消绑定控件53。可以理解的是，取消绑定控件53的具体位置不限于图6中示出的虚拟钱包的配置界面52中，还可以位于其他界面中，例如单独的解绑界面。

需要说明的是，虚拟钱包客户端在解绑指令中添加付款设备的标识。以便支付端服务器通过付款设备的标识查找该付款设备与虚拟钱包的绑定关系以及其他关于该付款设备的配置信息。

本实施例中，虚拟钱包客户端提供解绑功能，以便在付款设备丢失或者用户不想再使用该付款设备实现支付等情况时，用户通过虚拟钱包客户端中进行解绑操作，即可实现该付款设备与虚拟钱包之间绑定关系的解除。这样，既能够保障软件钱包中资金的安全性；而且，对于用户来说，操作简单且方便，提高了用户的使用体验感。

参照图7，本申请实施例还提供一种支付方法，应用于付款设备，该方法包括：

701、接收来自收款设备第二收款信息。

702、对第二收款信息进行签名处理或者签名加密处理，生成支付验证信息；将支付验证信息传输至收款设备，支付验证信息用于收款设备向服务器发送，使得支付端服务器基于支付验证信息验证第一收款信息获得验证结果，并在验证结果为通过的情况下，根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，获得目标交易的交易结果；第一收款信息是收款设备向服务器发送的，第一收款信息和第二收款信息为目标交易的收款信息。

进一步的，付款设备生成其私钥和公钥，并将其公钥传输至支付端服务器，以使支付端服务器利用其公钥以及支付验证信息对第一收款信息进行验证，具体的验证流程可参照上述实施例，此处不在赘述。

具体的，付款设备采用预设的签名算法，生成付款设备的私钥和公钥。其中预设的签名算法可以是上述的第一预设的签名算法或者第二预设的签名算法，对于第一预设的签名算法或者第二预设的签名算法的相关实施例可参考上述，此处不在赘述。

进一步的，付款设备采用预设的签名算法，生成付款设备的私钥，具体可以包括：付款设备根据基于预设的签名算法的门限密码算法，生成付款设备的私钥和公钥。需要说明的是，对于门限签名算法的实施例可参照上述关于支付端服务器生成付款设备的私钥和公钥的实施例，此处不再赘述。

本申请实施例提出的支付方法，用户在使用付款设备进行交易时，收款设备将该笔交易的收款信息分别发送至付款设备和支付端服务器；付款设备对收到的收款信息(即第二收款信息)进行签名处理或者签名加密处理生成支付验证信息；将该支付验证信息再通过收款设备传输至支付端服务器。支付端服务器利用支付验证信息对来自收款设备的收款信息(即第一收款信息)进行验证。由于第一收款信息和第二收款信息均对应同一交易(即目标交易)；因此，通过上述验证这一手段，不仅能够确定出付款设备是否对第一收款信息进行支付授权，而且能够识别出第一收款信息在传输的过程中是否被恶意篡改，从而保证了收款信息的真实性，避免了错误扣款的情况。

另外，在第一收款信息验证通过的情况下，支付端服务器根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，获得该笔交易的交易结果。这样，用户可以通过付款设备进行现场交易，在虚拟钱包中进行该笔交易的处理(即扣款处理)，实现了无需向付款设备中进行提前充值也能利用付款设备进行交易的目的，并保证了付款设备的使用安全性。

参照图8，本申请实施例还提供一种支付系统，该系统包括：

付款设备101，用于接收来自收款设备1031的第二收款信息。

付款设备101，还用于对第二收款信息进行签名处理或者签名加密处理，生成支付验证信息，并将支付验证信息传输至收款设备1031。

收款设备1031，用于将支付验证信息和第一收款信息发送至支付端服务器104；第一收款信息和第二收款信息为目标交易的收款信息。

支付端服务器104，用于基于支付验证信息验证第一收款信息，获得验证结果；若验证结果为通过，则根据第一收款信息对付款设备101绑定的虚拟钱包进行交易处理，获得目标交易的交易结果。

在本申请的一个实施例中，虚拟钱包客户端102，用于显示付款设备101的至少一个配置项。

虚拟钱包客户端102，还用于接收至少一个配置项的配置操作，并根据配置操作确定付款设备101的配置信息。

虚拟钱包客户端102，还用于将配置信息发送至支付端服务器104。

支付端服务器104，用于根据配置信息生成虚拟钱包和付款设备101的绑定关系。

需要说明的是，针对支付系统中付款设备、虚拟钱包、虚拟钱包客户端、收款设备以及支付端服务器的其他步骤以及相关实施例均可参照上述方法，此处不再赘述。

对于图8中示出的支付系统架构图中，还包括了收款端服务器1032，当收款设备1301无法于支付端服务器104进行直接通信时，可通过收款端服务器1032与支付端服务器104进行数据传输。

应当注意，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。

图9为本申请一个实施例的支付装置的方框示意图，该支付装置设置于支付端服务器中。

如图9所示，支付装置包括：获取单元901、验证单元902、交易处理单元903、信息配置单元904。其中，

获取单元901，用于获取收款设备发送的第一收款信息和支付验证信息；支付验证信息是付款设备对来自收款设备的第二收款信息进行签名处理或者签名加密处理生成的；第一收款信息和第二收款信息为目标交易的收款信息；

验证单元902，用于基于支付验证信息验证第一收款信息，获得验证结果；

交易处理单元903，用于若验证结果为通过，则根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，获得目标交易的交易结果。

在其中一个实施例中，所述支付验证信息是付款设备对来自所述收款设备的第二收款信息进行签名得到，验证单元902，具体用于利用所述付款设备的公钥对所述第一收款信息进行签名处理，得到待验证信息；根据所述支付验证信息验证所述待验证信息，确定所述验证结。

在其中一个实施例中，所述支付验证信息是付款设备对来自所述收款设备的第二收款信息进行签名加密得到，验证单元902，具体用于

利用所述付款设备的公钥对所述支付验证信息进行解密处理，得到所述第二摘要信息；对所述第一收款信息进行摘要提取，得到第一摘要信息；根据所述第二摘要信息验证所述第一摘要信息，确定所述验证结果。

在其中一个实施例中，获取单元901，还用于接收来自虚拟钱包客户端的配置信息。

信息配置单元904，用于根据配置信息对虚拟钱包进行配置；配置信息至少用于为虚拟钱包配置付款设备。

在其中一个实施例中，信息配置单元904，具体用于根据配置信息生成虚拟钱包与付款设备的绑定关系，以及付款设备的交易限制规则。

在其中一个实施例中，交易处理单元903，具体用于若第一收款信息满足交易限制规则，则根据第一收款信息对虚拟钱包进行扣款处理；若不满足交易限制规则，则拒绝对虚拟钱包进行扣款处理。

在其中一个实施例中，信息配置单元904，还用于生成付款设备的公钥和私钥。

发送单元，用于向付款设备发送私钥，所述私钥用于所述付款设备根据所述第二收款信息生成所述支付验证信息，所述公钥用于验证所述第一收款信息。

在其中一个实施例中，获取单元901，还用于接收付款设备发送的公钥；所述公钥用于验证所述第一收款信息；所述公钥与所述付款设备的私钥对应，所述私钥用于所述付款设备根据所述第二收款信息生成所述支付验证信息。

在其中一个实施例中，获取单元901，还用于接收来自虚拟钱包客户端的解绑指令。

信息配置单元904，用于响应于解绑指令，删除虚拟钱包与付款设备的绑定关系。

本申请实施例提出的支付装置，用户在使用付款设备进行交易时，收款设备将该笔交易的收款信息分别发送至付款设备和支付装置；付款设备对收到的收款信息(即第二收款信息)进行签名处理或者签名加密处理生成支付验证信息；将该支付验证信息再通过收款设备传输至支付装置。支付装置利用支付验证信息对来自收款设备的收款信息(即第一收款信息)进行验证。由于第一收款信息和第二收款信息均对应同一交易(即目标交易)；因此，通过上述验证这一手段，不仅能够确定出付款设备是否对第一收款信息进行支付授权，而且能够识别出第一收款信息在传输的过程中是否被恶意篡改，从而保证了收款信息的真实性，避免了错误扣款的情况。

另外，在第一收款信息验证通过的情况下，支付装置根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，获得该笔交易的交易结果。这样，用户可以通过付款设备进行现场交易，在虚拟钱包中进行该笔交易的处理(即扣款处理)，实现了无需向付款设备中进行提前充值也能利用付款设备进行交易的目的，并保证了付款设备的使用安全性。

应当理解，支付装置中记载的诸单元与参考图2描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征同样适用于支付装置及其中包含的单元，在此不再赘述。支付装置可以预先实现在计算机设备的浏览器或其他安全应用中，也可以通过下载等方式而加载到计算机设备的浏览器或其安全应用中。支付装置中的相应单元可以与计算机设备中的单元相互配合以实现本申请实施例的方案。

图10为本申请一个实施例的账户配置装置的方框示意图，该账户配置装置设置于虚拟钱包客户端中。

如图10所示，该账户配置装置包括：显示单元1001、接收单元1002、处理单元1003、发送单元1004。其中

显示单元1001，用于显示付款设备的至少一个配置项。

接收单元1002，用于接收至少一个配置项的配置操作。

处理单元1003，用于根据配置操作确定付款设备的配置信息。

发送单元1004，用于向支付端服务器发送配置信息，配置信息用于支付端服务器生成虚拟钱包和付款设备的绑定关系。

在其中一个实施例中，配置信息还用于生成付款设备的交易限制规则。

在其中一个实施例中，接收单元1002，还用于接收针对付款设备的解绑操作。

处理单元1003，用于响应于解绑操作，生成解绑指令。

发送单元1004，用于向支付端服务器发送解绑指令，解绑指令用于指示支付端服务器删除虚拟钱包与付款设备的绑定关系。

本申请实施例提供的账户配置装置能够显示付款设备的至少一个配置项，以便用户通过各配置项对付款设备进行配置操作，账户配置装置用户针对各配置项的配置操作，生成付款设备的配置信息，并将该配置信息传输至支付端服务器，以使支付端服务器能够基于该配置信息生成虚拟钱包和付款设备的绑定关系，从而达到通过付款设备进行现场交易的目的。另外，该配置信息还用于生成付款设备的交易限制规则，为用户提供更为信任的支付环境，保证了付款设备的支付安全性。

应当理解，账户配置装置中记载的诸单元与图4描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征同样适用于账户配置装置及其中包含的单元，在此不再赘述。账户配置装置可以预先实现在计算机设备的浏览器或其他安全应用中，也可以通过下载等方式而加载到计算机设备的浏览器或其安全应用中。账户配置装置中的相应单元可以与计算机设备中的单元相互配合以实现本申请实施例的方案。

图11为本申请一个实施例的支付装置的方框示意图，该支付装置设置于付款设备中。

如图11所示，该支付装置包括：接收单元1101、签名单元1102、传输单元1103。其中

接收单元1101，用于接收来自收款设备第二收款信息。

签名单元1102，用于对第二收款信息进行签名处理或者签名加密处理，生成支付验证信息。

传输单元1103，用于将支付验证信息传输至收款设备，支付验证信息用于收款设备向服务器发送，使得支付端服务器基于支付验证信息验证第一收款信息获得验证结果，并在验证结果为通过的情况下，根据第一收款信息对付款设备绑定的虚拟钱包进行交易处理，获得目标交易的交易结果；第一收款信息是收款设备向服务器发送的，第一收款信息和第二收款信息对应目标交易。

本申请实施例提出的支付装置，用户在使用支付装置进行交易时，收款设备将该笔交易的收款信息分别发送至支付装置和支付端服务器；支付装置对收到的收款信息(即第二收款信息)进行签名处理或者签名加密处理生成支付验证信息；将该支付验证信息再通过收款设备传输至支付装置。支付端服务器利用支付验证信息对来自收款设备的收款信息(即第一收款信息)进行验证。由于第一收款信息和第二收款信息均对应同一交易(即目标交易)；因此，通过上述验证这一手段，不仅能够确定出支付装置是否对第一收款信息进行支付授权，而且能够识别出第一收款信息在传输的过程中是否被恶意篡改，从而保证了收款信息的真实性，避免了错误扣款的情况。

另外，在第一收款信息验证通过的情况下，支付装置根据第一收款信息对支付装置绑定的虚拟钱包进行交易处理，获得该笔交易的交易结果。这样，用户可以通过支付装置进行现场交易，在虚拟钱包中进行该笔交易的处理(即扣款处理)，实现了无需向支付装置中进行提前充值也能利用支付装置进行交易的目的，并保证了支付装置的使用安全性。

应当理解，支付装置中记载的诸单元与参考图7描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征同样适用于支付装置及其中包含的单元，在此不再赘述。支付装置可以预先实现在计算机设备的浏览器或其他安全应用中，也可以通过下载等方式而加载到计算机设备的浏览器或其安全应用中。支付装置中的相应单元可以与计算机设备中的单元相互配合以实现本申请实施例的方案。

在上文详细描述中提及的若干模块或者单元，这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

需要说明的是，本申请实施例的支付装置中未披露的细节，请参照本申请上述实施例中所披露的细节，这里不再赘述。

下面参考图12，图12示出了适于用来实现本申请实施例的计算机设备的结构示意图，如图12所示，计算机系统1200包括中央处理单元(CPU)1201，其可以根据存储在只读存储器(ROM)1202中的程序或者从存储部分12012加载到随机访问存储器(RAM)1203中的程序而执行各种适当的动作和处理。在RAM1203中，还存储有系统的操作指令所需的各种程序和数据。CPU1201、ROM1202以及RAM1203通过总线1204彼此相连。输入/输出(I/O)接口1205也连接至总线1204。

以下部件连接至I/O接口1205；包括键盘、鼠标等的输入部分1206；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1207；包括硬盘等的存储部分12012；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分12012。通信部分12012经由诸如因特网的网络执行通信处理。驱动器1210也根据需要连接至I/O接口1205。可拆卸介质1211，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1210上，以便于从其上读出的计算机程序根据需要被安装入存储部分12012。

特别地，根据本申请的实施例，上文参考流程图图2、图4和图7描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分12012从网络上被下载和安装，和/或从可拆卸介质1211被安装。在该计算机程序被中央处理单元(CPU)1201执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体地例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以为的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作指令。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，前述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以不同于附图中所标注的顺序发生。例如，两个连接表示的方框实际上可以基本并行地执行，他们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作指令的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，例如，可以描述为：一种处理器包括违规人物检测单元、多模态检测单元以及识别单元。其中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的计算机设备中所包含的，也可以是单独存在，而未装配入该计算机设备中的。上述计算机可读存储介质存储有一个或多个程序，当上述程序被一个或者一个以上的处理器用来执行本申请所述的支付方法。例如，可以执行图2所示的支付方法的各个步骤，或者可以执行图4所示的账户配置方法的各个步骤，或者可以执行图7所示的支付方法的各个步骤。

本申请实施例提供一种计算机程序产品，该计算机程序产品包括指令，当该指令被运行时，使得如本申请实施例描述的方法被执行。例如，可以执行图2所示的支付方法的各个步骤，或者可以执行图4所示的账户配置方法的各个步骤，或者可以执行图7所示的支付方法的各个步骤。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离前述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其他技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (19)

1.一种支付方法，应用于支付端服务器，其特征在于，所述方法包括：

获取收款设备发送的第一收款信息和支付验证信息；所述支付验证信息是付款设备对来自所述收款设备的第二收款信息进行签名处理或者签名加密处理生成的；所述第一收款信息和所述第二收款信息为目标交易的收款信息；

基于所述支付验证信息验证所述第一收款信息，获得验证结果；

若所述验证结果为通过，则根据所述第一收款信息对所述付款设备绑定的虚拟钱包进行交易处理，获得所述目标交易的交易结果。

2.根据权利要求1所述的支付方法，其特征在于，所述支付验证信息是付款设备对来自所述收款设备的第二收款信息进行签名得到，所述基于所述支付验证信息验证所述第一收款信息，获得验证结果，包括：

利用所述付款设备的公钥对所述第一收款信息进行签名处理，得到待验证信息；

根据所述支付验证信息验证所述待验证信息，确定所述验证结果。

3.根据权利要求1所述的支付方法，其特征在于，所述支付验证信息是付款设备对来自所述收款设备的第二收款信息进行签名加密得到，所述基于所述支付验证信息验证所述第一收款信息，获得验证结果，包括：

利用所述付款设备的公钥对所述支付验证信息进行解密处理，得到所述第二摘要信息；

对所述第一收款信息进行摘要提取，得到第一摘要信息；

根据所述第二摘要信息验证所述第一摘要信息，确定所述验证结果。

4.根据权利要求1-3任一项所述的支付方法，其特征在于，所述方法还包括：

接收来自虚拟钱包客户端的配置信息，根据所述配置信息对所述虚拟钱包进行配置；所述配置信息至少用于为所述虚拟钱包配置所述付款设备。

5.根据权利要求4所述的支付方法，其特征在于，所述根据所述配置信息对所述虚拟钱包进行配置，包括：

根据所述配置信息生成所述虚拟钱包与所述付款设备的绑定关系，以及所述付款设备的交易限制规则。

6.根据权利要求5所述的支付方法，其特征在于，所述根据所述第一收款信息对所述付款设备绑定的虚拟钱包进行交易处理：

若所述第一收款信息满足所述交易限制规则，则根据所述第一收款信息对所述虚拟钱包进行扣款处理；

若不满足所述交易限制规则，则拒绝对所述虚拟钱包进行扣款处理。

7.根据权利要求1-6任一项所述的支付方法，其特征在于，所述方法还包括：

生成所述付款设备的公钥和私钥，向所述付款设备发送所述私钥，所述私钥用于所述付款设备根据所述第二收款信息生成所述支付验证信息，所述公钥用于验证所述第一收款信息。

8.根据权利要求1-6任一项所述的支付方法，其特征在于，所述方法还包括：

接收所述付款设备发送的公钥；所述公钥用于验证所述第一收款信息；所述公钥与所述付款设备的私钥对应，所述私钥用于所述付款设备根据所述第二收款信息生成所述支付验证信息。

9.根据权利要求1-8任一项所述的支付方法，其特征在于，所述方法还包括：

接收来自所述虚拟钱包客户端的解绑指令；

响应于所述解绑指令，删除所述虚拟钱包与所述付款设备的绑定关系。

10.一种账户配置方法，应用于虚拟钱包客户端，其特征在于，所述方法包括：

显示付款设备的至少一个配置项；

接收所述至少一个配置项的配置操作，并根据所述配置操作确定所述付款设备的配置信息；

向支付端服务器发送所述配置信息，所述配置信息用于所述支付端服务器生成所述虚拟钱包和所述付款设备的绑定关系。

11.根据权利要求10所述的账户配置方法，其特征在于，所述配置信息还用于生成所述付款设备的交易限制规则。

12.根据权利要求10或11所述的账户配置方法，其特征在于，所述方法还包括：

接收针对所述付款设备的解绑操作；

响应于所述解绑操作，生成解绑指令；

向所述支付端服务器发送所述解绑指令，所述解绑指令用于指示所述支付端服务器删除所述虚拟钱包与所述付款设备的绑定关系。

13.一种支付系统，其特征在于，包括：

付款设备，用于接收来自收款设备的第二收款信息；

所述付款设备，还用于对所述第二收款信息进行签名处理或者签名加密处理，生成支付验证信息，并将所述支付验证信息传输至所述收款设备；

所述收款设备，用于将所述支付验证信息和第一收款信息发送至支付端服务器；所述第一收款信息和所述第二收款信息为目标交易的收款信息；

所述支付端服务器，用于基于所述支付验证信息验证所述第一收款信息，获得验证结果；若所述验证结果为通过，则根据所述第一收款信息对所述付款设备绑定的虚拟钱包进行交易处理，获得所述目标交易的交易结果。

14.根据权利要求13所述的支付系统，其特征在于，

虚拟钱包客户端，用于显示付款设备的至少一个配置项；

所述虚拟钱包客户端，还用于接收所述至少一个配置项的配置操作，并根据所述配置操作确定所述付款设备的配置信息；

所述虚拟钱包客户端，还用于将所述配置信息发送至所述支付端服务器；

所述支付端服务器，用于根据所述配置信息生成所述虚拟钱包和付款设备的绑定关系。

15.一种支付装置，其特征在于，所述支付装置包括：

获取单元，用于获取收款设备发送的第一收款信息和支付验证信息；所述支付验证信息是付款设备对来自所述收款设备的第二收款信息进行签名处理或者签名加密处理生成的；所述第一收款信息和所述第二收款信息为目标交易的收款信息；

验证单元，用于基于所述支付验证信息验证所述第一收款信息，获得验证结果；

交易处理单元，用于若所述验证结果为通过，则根据所述第一收款信息对所述付款设备绑定的虚拟钱包进行交易处理，获得所述目标交易的交易结果。

16.一种账户配置装置，应用于虚拟钱包客户端，其特征在于，所述账户配置装置包括：

显示单元，用于显示付款设备的至少一个配置项；

接收单元，用于接收所述至少一个配置项的配置操作；

处理单元，用于根据所述配置操作确定所述付款设备的配置信息；

发送单元，用于向支付端服务器发送所述配置信息，所述配置信息用于所述支付端服务器生成所述虚拟钱包和所述付款设备的绑定关系。

17.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时，实现如权利要求1至12任一项所述的方法。

18.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1至12中任一项所述的方法。

19.一种计算机程序产品，其特征在于，所述计算机程序产品包括指令，当所述指令被运行时，使得如权利要求1至12任一项所述的支付方法被执行。