基于移动终端P2P的信用支付方法及装置与流程

本发明涉及通信技术领域，尤其涉及一种基于移动终端p2p的信用支付方法及装置。

背景技术：

目前公共交通工具主要包括公交和地铁，而用户在乘坐公共交通工具购票时，主要采用现金或公交卡两种支付方式，现金支付主要针对公交系统，用户可以采用投币的形式购票。同时，用户也可以采用预付费的方式办理公交卡，以刷卡的形式乘坐公交车或地铁出行。

用户在使用现金的方式购票乘坐公交车时，一方面，由于很多公交车为无人售票车，不设找兑，使得用户须事先准备小额票款，给用户出行带来了不便。另一方面，公交系统的工作人员在营业结束后，还需对用户在乘坐无人售票公交车时投入的小额票款清点，给工作人员带来了额外的工作。用户在使用公交卡刷卡乘坐公共交通工具时，由于目前公交卡主要为非接触式射频卡，用户在使用和携带过程中，容易造成公交卡的弯折损坏、卡面的磨损致使卡面图案模糊等人为损耗。当用户乘坐公共交通工具使用单次公交卡时，也大多使用小额票款购买单次公交卡，同样需要工作人员对小额票款进行清点结算。

当用户乘坐公共交通工具使用可复用的预付费公交卡时，由于该可复用的预付费公交卡不记名、不挂失，丢失后会给用户造成很大的损失，并且还需要用户去指定的网点购买、充值和退款，同样给用户造成很大不便。

技术实现要素：

为克服相关技术中存在的问题，本发明提供一种基于移动终端p2p的信用支付方法及装置。

根据本发明实施例的第一方面，提供一种基于移动终端p2p的信用支付方法，应用于移动终端，包括：

接收所述交易终端发送的交易信息；

根据所述交易信息生成交易响应信息，并将所述交易响应信息发送给所述交易终端；

接收所述交易终端发送的本次支付交易的扣款接受请求信息；

根据所述扣款接受请求信息和所述交易响应信息，生成所述移动终端中的应用私钥 生成支付授权许可；

将所述支付授权许可发送给所述交易终端，以使所述交易终端根据接收到的所述支付授权许可完成本次支付交易。

进一步的，在所述将与所述交易信息相对应的交易响应信息发送给所述交易终端之后，还包括：

接收所述交易终端发送的应用公钥证书返回请求信息；

根据所述应用公钥证书返回请求信息将所述移动终端的应用公钥证书生成应用公钥证书响应信息，并将所述应用公钥证书响应信息发送给所述交易终端。

进一步的，所述生成所述移动终端中的应用私钥生成支付授权许可，包括：

根据所述扣款接受请求信息，利用所述移动终端存储的应用私钥生成签名数据；

根据所述扣款接受请求信息和所述交易响应信息，利用所述移动终端中预先生成的交易验证码tac子密钥生成tac；

将所述签名数据和所述tac作为所述支付授权许可。

进一步的，所述支付方法应用于公交出行的支付中；

所述交易响应信息，包括：支付卡号、可用额度和进出站标志。

进一步的，所述扣款接受请求信息，包括：扣款金额、本次支付交易日期、本次支付交易时间、本次支付交易进出站标志和本次支付交易的站点信息。

进一步的，还包括：

根据所述扣款接受请求信息中的扣款金额，将所述交易信息中的可用额度减去扣款金额，得到当前可用额度；

将所述当前可用额度作为所述移动终端中对应用户的可用额度。

根据本发明实施例的第二方面，提供一种基于移动终端p2p的信用支付装置，包括：

向所述移动终端发送交易信息；

接收所述移动终端发送的交易响应信息；

根据所述交易响应信息生成本次支付交易的扣款接受请求信息；

将所述扣款接受请求信息发送给所述移动终端；

当接收到支付授权许可时，根据所述支付授权许可确定本次支付交易完成。

进一步的，在所述接收所述移动终端发送的交易响应信息之后，还包括：

向所述移动终端发送应用公钥证书返回请求信息；

接收所述移动终端发送的应用公钥证书响应信息；

利用所述交易终端中的信用授权公钥对所述应用公钥证书响应信息中的应用公钥证书验签；

当验签过程中从所述应用公钥证书中恢复出应用公钥时，执行所述生成本次支付交易的扣款接受请求信息的步骤。

进一步的，所述支付方法应用于公交出行的支付中；

所述交易响应信息，包括：支付卡号、可用额度、进出站标志和上笔交易信息。

进一步的，所述方法还包括：

判断所述交易响应信息中的支付卡号是否包含在预设黑名单中；

当所述交易响应信息中的支付卡号没有包含在预设黑名单中时，执行所述向所述移动终端发送应用公钥证书返回请求信息的步骤。

进一步的，还包括：

判断所述交易响应信息中的可用额度是否大于或者等于预设阈值；

当所述可用额度大于或者等于预设阈值时，检查所述交易信息中的进出站标志是否为已出站状态；

当所述进出站标志为已出站状态时，执行所述向所述移动终端发送应用公钥证书返回请求信息的步骤。

进一步的，所述支付授权许可，包括：签名数据和交易验证码tac；所述根据所述支付授权许可确定本次支付交易完成，包括：

利用所述应用公钥对所述签名数据验签；

当所述签名数据验签成功时，生成交易日志；

将所述交易日志发送给预设服务器，以使得所述预设服务器根据所述交易日志扣除所述移动终端对应的用户账户中相应的金额；其中，所述交易日志包括：扣款金额、交易日期、交易时刻、交易终端id、支付卡号、可用额度和tac。

根据本发明实施例的第三方面，提供一种基于移动终端p2p的信用支付装置，包括：

第一返回请求信息接收单元，用于在检测到交易终端时，接收所述交易终端发送的交易信息；

交易响应信息，用于根据所述交易信息生成交易响应信息；

信息发送单元，用于将所述交易响应信息发送给所述交易终端；

扣款接受请求信息接收单元，用于接收所述交易终端发送的本次支付交易的扣款接受请求信息；

应用私钥生成支付授权许可生成单元，用于根据所述扣款接受请求信息和所述交易响应信息，生成所述移动终端中的应用私钥生成支付授权许可；

支付授权许可发送单元，用于将所述支付授权许可发送给所述交易终端，以使所述交易终端根据接收到的所述支付授权许可完成本次支付交易。

进一步的，所述装置还包括：

第二返回请求信息接收单元，用于接收所述交易终端发送的应用公钥证书返回请求信息；

应用公钥证书响应信息生成单元，用于根据所述应用公钥证书返回请求信息将所述移动终端的应用公钥证书生成应用公钥证书响应信息；

公钥证书响应信息发送单元，用于将所述应用公钥证书响应信息发送给所述交易终端。

进一步的，所述应用私钥生成支付授权许可生成单元，包括：

签名数据生成模块，用于根据所述扣款接受请求信息，利用所述移动终端存储的应用私钥生成签名数据；

信息生成模块，用于根据所述扣款接受请求信息和所述交易响应信息，利用所述移动终端中预先生成的交易验证码tac子密钥生成tac；

支付授权许可确定模块，用于将所述签名数据和所述tac作为所述支付授权许可。

进一步的，所述交易响应信息，包括：支付卡号、可用额度、进出站标志和上笔交易信息。

进一步的，所述支付方法应用于公交出行的支付中；

所述扣款接受请求信息，包括：扣款金额、本次支付交易日期、本次支付交易时间、本次支付交易进出站标志和本次支付交易的站点信息。

进一步的，还包括：

当前可用额度生成单元，用于根据所述扣款接受请求信息中的扣款金额，将所述交易信息中的可用额度减去扣款金额，得到当前可用额度；

可用额度确定单元，用于将所述当前可用额度作为所述移动终端中对应用户的可用 额度。

根据本发明实施例的第四方面，提供一种基于移动终端p2p的信用支付装置，应用于交易终端，所述装置包括：

交易信息发送单元，向所述移动终端发送交易信息；

交易响应信息接收单元，用于接收所述移动终端发送的交易响应信息；

扣款单元，用于根据所述交易响应信息生成本次支付交易的扣款接受请求信息；

扣款接受请求信息发送单元，用于将所述扣款接受请求信息发送给所述移动终端；

本次支付交易完成单元，用于在接收到支付授权许可时，根据所述支付授权许可确定本次支付交易完成。

进一步的，所述装置还包括：

返回请求信息发送单元，用于向所述移动终端发送应用公钥证书返回请求信息；

公钥证书响应信息接收单元，用于接收所述移动终端发送的应用公钥证书响应信息；

验签单元，用于利用所述交易终端中的信用授权公钥对所述应用公钥证书响应信息中的应用公钥证书验签。

进一步的，所述交易响应信息，包括：支付卡号、可用额度和进出站标志。

进一步的，所述装置还包括：

黑名单判断单元，用于判断所述交易响应信息中的支付卡号是否包含在预设黑名单中；

返回请求信息发送单元，还用于在所述交易响应信息中的支付卡号没有包含在预设黑名单中时，向所述移动终端发送应用公钥证书返回请求信息。

进一步的，还包括：

阈值判断单元，用于判断所述交易响应信息中的可用额度是否大于或者等于预设阈值；

状态检查单元，用于在所述可用额度大于或者等于预设阈值时，检查所述交易信息中的进出站标志是否为已出站状态。

进一步的，所述支付授权许可，包括：签名数据和交易验证码tac；所述本次支付交易完成单元，包括：

验签模块，用于利用所述应用公钥对所述签名数据验签；

交易日志生成模块，用于在所述签名数据验签成功时，生成交易日志；

交易日志发送模块，用于将所述交易日志发送给预设服务器，以使得所述预设服务器根据所述交易日志扣除所述移动终端对应的用户账户中相应的金额；其中，所述交易日志包括：扣款金额、交易日期、交易时刻、交易终端id、支付卡号、可用额度和tac。

本发明的实施例提供的技术方案可以包括以下有益效果：

本发明提供的基于移动终端p2p的信用支付方法及装置，可以应用在移动终端和交易终端中，当用户开通支付应用之后，可以通过使用移动终端就可以完成对交易终端的离线信用支付，可以快速、安全的完成支付交易，并且无需在线支付，避免了相关技术中，例如用户在乘坐公共交通工具时，还需要用户使用现金或公交卡等方式才能实现支付交易功能。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

图1是根据一示例性实施例示出的信用授权系统示意图；

图2是根据一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图3是根据另一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图4是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图5是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图6是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图7是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图8是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图9是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图10是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图11是图10中步骤s320的流图；

图12是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图13是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图14是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图15是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图16是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图17是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付方法流程图；

图18是图14中步骤s450的流程图；

图19是信用授权系统应用、信用支付应用及信用授权系统的服务端之间的流程相互之间的数据交互流程信令图；

图20是公交闸机与信用授权系统的服务端之间的数据交互信令图；

图21是公交闸机与信用授权系统的服务端之间的数据交互信令图；

图22是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付装置示意图图；

图23是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付装置示意图；

图24是图22中应用私钥生成支付授权许可生成单元的示意图；

图25是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付装置示意图；

图26是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付装置示意图；

图27是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付装置示意图；

图28是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付装置示意图；

图29是根据又一示例性实施例示出的一种基于移动终端p2p的信用支付装置示意图；

图30是图26中本次支付交易完成单元的示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

移动支付(mobilepayment)，也称手机支付，用户可以使用移动终端对所购买的商品或者服务进行账务支付。移动终端可以采用nfc(nearfieldcommunication，近场通信)与交易终端通信，实现支付交易。其中，nfc又称近距离通信，是一种短距离的高频无线通信技术，允许电子设备之间进行非接触式点对点数据传输交换数据。由于近场通信具有天然的安全性，因此，nfc技术在支付等领域具有很大的应用前景。

p2p，即点对点peertopeer，是nfc技术的三种工作模式之一，这个模式和红外线差不多，可用于数据交换，只是传输距离较短，传输创建速度较快，传输速度也快些，功耗低(蓝牙也类似)。将两个具备nfc功能的设备无线链接，能实现数据点对点传输，如下载音乐、交换图片或者同步设备地址薄。因此通过nfc，多个设备如数位相机、pda、计算机和手机之间都可以交换资料或者服务。本发明实施例中移动终端采用nfc技术中的p2p方式与公交闸机进行数据交互，完成信用支付交易。

为了便于本领域技术人员理解和实施本发明，首先简要说明本发明实施例中涉及到的移动终端、支付终端及服务器之间的相互关系，如上述各终端之间的数据如何传输和处理等。由于本发明可以用在包括移动支付在内的很多领域，为了便于说明，本发明实施例中以用户乘坐公共交通工具时，通过刷手机进行信用支付为例进行说明。

如图1所示，本发明实施例中提供的信用授权系统包括：移动终端100、交易终端200和服务器300。其中，移动终端100可以是带有支付交易功能的手机；交易终端200可以是公交闸机，公交闸机是指公交、地铁系统中使用的pos机；服务器300是信用授权系统的服务端。在用户通过移动终端100与交易终端200进行支付交易之前，还需要通过服务器300开通移动终端100的信用支付交易功能，然后才能实现移动终端100与交易终端200的支付交易。并且交易终端200会定期上传移动终端100的交易日志给服务器300，服务器300会对移动终端100对应的账户内扣除相应的金额，并将该金额支付给公交公司。

在本发明提供的实施例中，移动终端中可安装有两个应用，一个是信用支付应用，例如信用支付应用applet，该应用applet对于java卡来讲，sun公司定了applet作为其上运行的applet的对象。移动终端上的另一应用可以是信用授权系统应用。上述两个应 用在移动终端上的功能也可以在同一个应用中来实现，本申请实施例不做特别限制。

交易终端200会使用严格的身份安全认证机制，保证只有身份通过安全认证，而且有足够信用额度的用户才能开通公交信用支付应用。

信用支付应用applet安装在具有nfc功能移动终端100中，在个人化时生成应用公私密钥对，并将应用私钥保存在信用支付应用中，由信用支付应用保证其数据在任何条件下均不可被盗取，应用公钥由信用授权系统的私钥签发成应用公钥证书，保存到信用支付应用中。信用授权系统的公钥会提供给交易终端200，保存位置由交易终端200决定，由于其为公钥，所以对安全方面可以不需要强制性的要求。

提供信用支付交易时，交易终端200在读取到信用支付应用中的应用公钥证书以后，使用信用授权系统的公钥验签，恢复出应用公钥。信用支付应用会使用应用私钥生成支付授权许可，交易终端200使用应用公钥对支付授权许可进行验签，通过后再对授权许可中的安全因子进行检查，确认安全后进行信用记账，随后在指定时间再向相应的信用账户进行结算。为了保证安全，当使用次数，额度和间隔时间任一因素超过指定阀值，均需要移动终端联网对用户的身份信息进行验证，需重新授权，信用支付的安全性。

为了解决相关技术问题，本发明实施例首先提供了一种基于移动终端p2p的信用支付方法，用于在移动终端开通信用支付的过程中，如图2所示，该方法可以包括如下步骤：

在步骤s110中，利用移动终端中的信用授权系统应用向预设服务器发送应用授权请求。

信用授权系统应用安装在移动终端中，移动终端可以通过授权系统应用向信用授权系统的服务端发送应用授权请求。

在步骤s120中，接收预设服务器发送的应用公钥证书和应用私钥。

信用授权系统的服务端根据接收到的应用授权请求，生成一对应用公私钥，即应用公钥和应用私钥，服务端利用本地存储的授权私钥对应用公钥签名，生成应用公钥证书，将得到的应用公钥证书和应用私钥分别发送给移动终端。

在步骤s130中，将应用公钥证书和应用私钥分别保存到移动终端的信用支付应用中。

移动终端将服务端发送的应用公钥证书及应用私钥保存到移动终端的信用支付应用中。

在步骤s140中，向预设服务器发送信用支付数据获取请求。

在步骤s150中，接收预设服务器发送的信用支付数据，并根据信用支付数据开通所 述移动终端的信用支付功能。

信用支付数据可以是个人化脚本，其中，个人化脚本包括：支付卡号、信用额度、可用额度、tac子密钥。其中，支付卡号是信用授权系统为每一个用户的信用支付应用生成的唯一特征码。可用额度是用户当前可以使用的金额。并且tac子密钥是信用授权系统服务端使用tac母密钥根据卡号散列得到的。

在本发明提供的又一实施例中，基于图2，如图3所示，在步骤s110之前，还可以包括如下步骤：

在步骤s101中，获取移动终端的设备参数信息。

移动终端的设备参数信息可以是移动终端的硬件信息，需要根据该设备参数信息检测该移动终端是否具备支付交易所具备的硬件条件，如是否具有nfc功能等。当然，设备参数信息还可以是移动终端的设备型号、rom版本、系统型号(如android版本)和应用版本等信息。

在步骤s102中，将设备参数信息发送给预设服务器。

移动终端将获取到自身的设备参数信息发送给信用授权系统的服务端，以使服务端根据接收到的设备参数信息判断该移动终端是否满足开通信用支付的硬件条件。

在步骤s103中，检测是否接收到预设服务器发送的信用支付开通信息。

如果移动终端满足开通信用支付的硬件条件，那么服务端会向移动终端发送信用支付开通信息。其中，该信用支付开通信息可以是信用支付应用开通页面。

如果移动终端不满足开通信用支付的硬件条件，那么服务端不会向移动终端发送信用支付开通信息。

当接收到预设服务器发送的信用支付开通信息时，执行步骤s104。

在步骤s104中，确定移动终端满足开通信用支付的硬件条件，随后执行步骤s110。

除了需要检测移动终端是否满足开通信用支付的硬件条件，基于图2，在步骤s110之前，如图4所示，还需要检测移动终端是否满足安全认证条件，因此，在本发明提供的又一实施例中，本发明提供的基于移动终端p2p的信用支付方法，还可以包括以下步骤：

在步骤s105中，获取移动终端中对应的用户身份信息。

用户的身份信息，可以是用户的身份证号码、姓名、银行卡号、邮箱及支付宝账号等信息。

在步骤s106中，将用户身份信息发送给预设服务器。以使预设终端根据接收到的用 户身份信息判断移动终端是否满足开通信用支付的安全认证条件。

移动终端将用户身份信息发送给信用授权系统的服务端，以使服务端对用户身份信息进行验证，如验证银行卡号是否正常提供服务，该用户账号是否有信用不良交易记录等。

在步骤s107中，检测是否接收到预设服务器发送的安全认证通过信息。

服务端在接收到移动终端发送的用户信息之后，会对该用户信息进行检查，如果满足开通信用支付的安全认证条件，那么会向移动终端发送安全认证通过信息。

当接收到预设服务器发送的安全认证通过信息时，在步骤s108中，确定移动终端满足开通信用支付的安全认证条件，随后执行步骤s110。

当移动终端接收到服务端发送的安全认证通过信息时，确定移动终端满足开通信用支付的安全认证条件。

当移动终端没有接收到服务端发送的安全认证通过信息时，确定移动终端不满足开通信用支付的安全认证条件。

基于图2，在步骤s110之前，如图5所示，还需要在移动终端安装相关应用，因此，本发明提供的基于移动终端p2p的信用支付方法，还包括如下步骤：

在步骤s160中，向预设服务器发送获取预设安装文件的请求。

预设安装文件包括：信用支付应用。

在步骤s170中，获取预设服务器发送的预设安装文件。

在步骤s180中，将预设安装文件安装在移动终端中。随后执行步骤s110。

将信用支付应用和注册脚本分别安装移动终端后，相当于移动终端的用户个人化完成。那么移动终端侧开通信用支付功能的流程结束，结合上述实施例，下面对移动终端开通信用支付功能的信用授权系统的服务端侧的执行流程做出详细阐述。

在本发明提供的又一实施例中，如图6所示，本发明提供的基于移动终端p2p的信用支付方法，在服务器(信用授权系统的服务端)的执行流程，可以包括以下步骤：

在步骤s210中，接收移动终端发送的应用授权请求。

在步骤s220中，根据应用授权请求分别生成应用公钥和应用私钥。

在步骤s230中，利用预设服务器中保存的信用授权私钥对应用公钥签名，生成应用公钥证书。

在步骤s240中，将应用公钥证书和应用私钥分别发送给移动终端。

信用授权系统的服务端根据接收到的应用授权请求，生成一对应用公私钥，即应用公钥和应用私钥，服务端利用本地存储的授权私钥对应用公钥签名，生成应用公钥证书，将得到的应用公钥证书和应用私钥分别发送给移动终端。

在步骤s250中，接收移动终端发送的信用支付数据获取请求。

在步骤s260中，根据信用支付数据获取请求，生成与移动终端相对应信用支付数据，并将信用支付数据发送给移动终端，以使移动终端根据接收到的信用支付数据开通所述移动终端的信用支付功能。

信用支付数据可以是个人化脚本，其中，个人化脚本包括：支付卡号、信用额度、可用额度、tac子密钥。其中，支付卡号是信用授权系统为每一个用户的信用支付应用生成的唯一特征码。可用额度是用户当前可以使用的金额。并且tac子密钥是信用授权系统服务端使用tac母密钥根据卡号散列得到的。

基于图6，如图7所示，在本发明提供的又一实施例中，服务器(信用授权系统的服务端)根据移动终端发送的设备参数信息，判断该移动终端是否满足开通信用支付的硬件条件，因此，本发明实施例中提供的基于移动终端p2p的信用支付方法，在步骤s210之前，还可以包括以下步骤：

在步骤s201中，接收移动终端发送的设备参数信息。

在移动终端开通信用支付功能的过程中，可以通过网络等方式与信用授权系统的服务端(即服务器)通信，信用授权系统的服务端可以接收移动终端发送的设备参数信息。

在步骤s202中，根据设备参数信息判断移动终端是否满足开通信信用支付的硬件条件。

移动终端发送的参数信息，可以是移动终端的设备型号、rom版本、系统型号(如android版本)和应用版本等信息等。服务端可以根据移动终端发送的上述信息检测移动终端是否具备nfc功能等。

如果服务端检测到移动终端满足开通信用支付的硬件条件，那么服务端会向移动终端发送信用支付开通信息。其中，该信用支付开通信息可以是信用支付应用开通页面。用户可以在移动终端上的信用支付应用开通界面上输入用户信息上传到服务端。

如果服务端检测到移动终端不满足开通信用支付的硬件条件，那么服务端不会向移动终端发送信用支付开通信息。

当移动终端满足开通信信用支付的硬件条件时，在步骤s203中，向移动终端发送信用支付开通信息。随后执行步骤s210。

信用授权系统的服务端除了要检测移动终端发送的设备参数信息，还需要检测移动 终端发送的用户身份信息，判断移动终端对应的用户是否满足安全认证条件。因此，基于图6，如图8所示，本发明提供的基于移动终端p2p的信用支付方法，在移动终端开通信用支付功能的过程中，在步骤s210之前，还可以包括如下步骤：

在步骤s204中，接收移动终端发送的用户身份信息。

该用户身份信息可以是用户的身份证号码、姓名、银行卡号、邮箱及支付宝账号等信息。

在步骤s205中，根据用户身份信息判断移动终端是否满足开通信信用支付的安全认证条件。

示例性的，服务端可以检测用户身份信息中的一行卡号是否正常提供服务，是否有不良交易记录等。

如果服务端检测到移动终端满足开通信用支付的安全认证条件，那么会向移动终端发送安全认证通过信息。

当身份信息满足开通信信用支付的安全认证条件时，在步骤s206中，向移动终端发送安全认证通过信息。随后执行步骤s210。

移动终端在开通信用支付时，还需要安装信用支付应用，而这些安装文件都需要信用支付系统的服务端发送给移动终端。因此，基于图6，如图9所示，在本发明提供的又一实施例中，本发明提供的基于移动终端p2p的信用支付方法，在步骤s210之前，还可以包括如下步骤：

在步骤s207中，接收移动终端发送的获取预设安装文件的请求。

其中，预设安装文件包括：信用支付应用。

在步骤s208中，根据获取预设安装文件的请求分别将预设安装文件发送给移动终端，随后执行步骤s210。

上述本发明实施例中描述了如何在移动终端开通信用支付的过程，在一些场景下，该种信用支付的过程也可以通过其他途径获得，例如预先在移动终端设定，或者，通过到信用支付机构进行注册申请等等，在此对信用支付开通的过程不做特别限制。

为了解决相关技术问题，本发明实施例首先提供了一种基于移动终端p2p的信用支付方法，用于在移动终端与交易终端之间的信用支付的过程中，如图10所示，该方法可以包括如下步骤：

在步骤s310中，接收交易终端发送的交易信息。

在用户手持移动终端贴近公交闸机进行支付交易时，由于公交闸机上能够产生射频 场，当移动终端贴近公交闸机时，即移动终端进入公交闸机产生的射频场时，移动终端会检测到公交闸机，同时，公家闸机也会检测到移动终端。这时，公交闸机会与移动终端建立通讯连接，公交闸机向移动终端发送交易信息，移动终端会接收公家闸机发送的交易信息。

需要说明的是，在p2p模式下定义了如何进行ndef(nfcdataexchangeformat:nfc，数据交换格式)消息的交互。

在步骤s320中，将与根据交易信息生成交易响应信息，并将交易响应信息发送给交易终端。

在步骤s330中，接收交易终端发送的本次支付交易的扣款接受请求信息。

公交闸机在接收到移动终端发送的应用公钥证书之后，会对该应用公钥证书验签，生成本次支付交易的扣款信息，并将该扣款信息发送给移动终端，移动终端接收公交闸机发送的扣款信息。

在步骤s340中，根据扣款接受请求信息和交易响应信息，生成移动终端中的应用私钥生成支付授权许可。

移动终端生成的支付授权许可包括：签名数据和tac(transactionauthenticationcode，交易验证码)。

在步骤s350中，将支付授权许可发送给交易终端，以使交易终端根据接收到的支付授权许可完成本次支付交易。

公交闸机在接收到移动终端发送的支付授权许可后，会对该支付许可进行验证，如果验证正确，将确定完成本次支付交易。

公交闸机感应到移动终端后，能够组装snepgetrequestmessage发送给公交信用支付应用，message的information域标识本message为读取卡信息。公交信用支付应用收到后，组装需要返回的数据为snepresponsemessage，包括卡号、可用额度、进站出站标志、上笔交易信息，返回给闸机。上笔交易信息的内容包括站点信息、交易日期及交易时间等。

需要说明的是，sneprequestmessage：p2p中的snepclient发送给snepserver的请求消息。消息分为get和put两种类型，get请求server返回数据，put请求server接受数据。本文区分为snepgetrequestmessage和snepputrequestmessage。snepresponsemessage：p2p中的snepserver返回给snepclient的响应消息。get请求返回数据，put请求返回success或出错的响应码。

返回请求信息相当于snepgetrequestmessage，交易响应信息相当于snep responsemessage。

本发明实施例提供的方法，在用户利用移动终端与交易终端进行支付交易时，在移动终端依据交易终端发送的相关指令信息依次将交易信息、应用公钥证书及生成的支付授权许可分别发送给交易终端，交易终端根据移动终端发送的信息完成本次支付交易。与相关技术存在的问题相比，本发明实施例提供的信用支付方法，用户在利用移动终端与交易终端交易时，可以使移动终端和交易终端分别处于离线模式，并且可以对移动终端的用户账户采用信用记账消费，在用户利用移动终端消费之后才进行结算，可以避免用户采用现金交易时产生的资金损失风险。

作为图10方法的细化，在本发明的另一实施例中，如图11所示，在步骤s320之后，还可以包括下述步骤：

在步骤s360中，接收交易终端发送的应用公钥证书返回请求信息。

在步骤s370中，根据应用公钥证书返回请求信息将移动终端的应用公钥证书生成应用公钥证书响应信息，并将应用公钥证书响应信息发送给移动终端。

其中，应用公钥证书响应信息与应用公钥证书返回请求信息相对应，符合数据发送和接收的格式要求。

为了详细说明本发明实施例移动终端是如何生成支付授权许可，以便交易终端根据移动终端发送的授权许可完成本次支付交易，作为图10方法的细化，在本发明的另一实施例中，如图12所示，步骤s340还可以包括如下步骤：

在步骤s361中，根据扣款接受请求信息，利用移动终端存储的应用私钥生成签名数据。

应用私钥是预先生成的，并且存储在移动终端中，信用支付应用利用该应用私钥对扣款信息签名，生成签名数据。其中，扣款信息包括：扣款金额、本次支付交易日期、本次支付交易时间、本次支付交易进出站标志和本次支付交易的站点信息。

在步骤s362中，根据扣款接受请求信息和交易响应信息，利用移动终端中预先生成的交易验证码tac子密钥生成tac。

扣款接受请求信息包括扣款信息，交易响应信息包括交易信息。根据扣款信息和交易信息，移动终端中的信用支付应用对扣款金额、本次支付交易日期、本次支付交易时间、支付卡号、可用额度和信用额度加密，生成tac。其中，信用额度是是信用授权系统授权给用户在离线状态下的最大可用金额。

在步骤s363中，将签名数据和tac作为支付授权许可。

信用支付应用可以将签名数据和tac作为支付授权许可分别发送给公交闸机，也可 以将签名数据和tac作为信用授权许可一起发送给公交闸机。

另外，上述交易信息，包括：支付卡号、可用额度、进出站标志和上笔交易信息。其中，支付卡号是信用授权系统为每一个用户的信用支付应用生成的唯一特征码。可用额度是用户当前可以使用的金额。并且tac子密钥是信用授权系统服务端使用tac母密钥根据卡号散列得到的。上笔交易信息的内容包括站点信息、交易日期和交易时间等。

基于图10，如图13所示，在本发明的另一实施例中，该方法还可以包括如下步骤：

在步骤s380中，根据扣款接受请求信息中的扣款金额，将交易信息中的可用额度减去扣款金额，得到当前可用额度；

在步骤s390中，将当前可用额度作为移动终端中对应用户的可用额度。

为了详细说明移动终端与交易终端之间的交易支付过程，本发明实施例提供的一种基于移动终端p2p的信用支付方法，在交易终端侧的执行流程，如图14所示，该方法可以包括如下步骤：

在步骤s410中，向移动终端发送交易信息。

在步骤s420中，接收移动终端发送的交易响应信息。

在步骤s430中，根据交易响应信息生成本次支付交易的扣款接受请求信息。

在步骤s440中，将扣款接受请求信息发送给移动终端。

在步骤s450中，当接收到支付授权许可时，根据支付授权许可确定本次支付交易完成。

由于该方法为信用支付交易过程中公交闸机侧的执行流程，与信用支付交易过程中移动终端侧的执行流程相对应，这里对二者之间的数据交换不在赘述，详细可参见上述实施例中移动终端侧的执行流程。

需要说明的是，实施例中涉及到的，如交易信息、交易响应信息、公钥证书返回请求信息及公钥证书响应信息等，是为了说明在数据交互过程中满足格式的要求，交易信息、交易响应信息、公钥证书返回请求信息及公钥证书响应信息，如交易响应信息可以分别理解为返回包含交易信息的响应信息，公钥证书响应信息可以理解为包含公钥证书的响应信息。

另外，交易响应信息，包括：支付卡号、可用额度、进出站标志和上笔交易信息。

基于图14，如图15所示，在本发明提供的又一实施例中，在步骤s420之后，该方法还可以包括以下步骤：

在步骤s460中，向移动终端发送应用公钥证书返回请求信息。

在步骤s470中，接收移动终端发送的应用公钥证书响应信息。

在步骤s480中，利用交易终端中的信用授权公钥对应用公钥证书响应信息中的应用公钥证书验签。

由于该方法为信用支付交易过程中公交闸机侧的执行流程，与信用支付交易过程中移动终端侧的执行流程相对应，这里对二者之间的数据交换不在赘述，详细可参见上述实施例中移动终端侧的执行流程。

基于图14，，如图16所示，在本发明提供的又一实施例中，该方法还可以包括以下步骤：

在步骤s401中，判断交易响应信息中的支付卡号是否包含在预设黑名单中。

当交易响应信息中的支付卡号没有包含在预设黑名单中时，执行步骤s460。

黑名单可以是交易终端，及公交闸机中预先设置的，将移动终端对应的用户身份信息与该黑名单中的信息比对，如果该用户身份信息存在该黑名单中，那么停止本次交易支付流程，避免造成恶意交易。

基于图14，如图17所示，在本发明提供的又一实施例中，该方法还可以包括以下步骤：

在步骤s402中，判断交易响应信息中的可用额度是否大于或者等于预设阈值；

当可用额度大于或者等于预设阈值时，在步骤s403中，检查交易信息中的进出站标志是否为已出站状态；

当进出站标志为已出站状态时，执行步骤s460。

通过检查用户的可用额度，来判断是否需要继续信用支付交易，当用户的可用额度低于本次交易的扣款金额时，停止本次信用支付交易，可以避免恶意支付交易。

该步骤主要是为了公交闸机根据移动终端发送的交易信息，检查移动终端对应的用户账户的可用额度是否足以支付本次支付交易所用的金额，如果可用额度不足，那么拒绝本次支付交易，如果可用额度足够，那么公交闸机会检查交易信息中的进出站标志是否为0，如果进出站标志不为0，那么拒绝本次支付交易；如果进出站标志为0，那么继续本次支付交易。需要说明的是，进出站标志中1表示用户手持移动终端为已进站状态，那么拒绝本次支付交易；进出站标志中0表示用户手持移动终端为已出站状态，那么表示可以结账，进行本次支付交易。

基于图14，如图18所示，在本发明提供的又一实施例中，步骤s450可以包括：

在步骤s481中，利用应用公钥对签名数据验签。

应用公钥是公交闸机从移动终端发送的支付授权许可中恢复出而得到的，应用公钥会检查签名数据中的相关信息是否与应用公钥中对应的信息是否匹配，如果匹配，确定验签通过。

在步骤s482中，当签名数据验签成功时，生成交易日志。

当公交闸机对签名数据验签通过之后，生成本次支付的交易日志。其中，交易日志包括：扣款金额、交易日期、交易时刻、交易终端id、支付卡号、可用额度和tac。

在步骤s483中，将交易日志发送给预设服务器，以使得预设服务器根据交易日志扣除移动终端对应的用户账户中相应的金额。

其中，交易日志包括：扣款金额、交易日期、交易时刻、交易终端id、支付卡号、可用额度和tac。支付授权许可，包括：签名数据和交易验证码tac。

在本发明提供的又一实施例中，如图19所示，本发明提供的基于移动终端p2p的信用支付方法，在实施例中，以手机代表移动终端，信用授权系统的服务端代表服务器进行说明，在手机开通信用支付功能时，手机中的信用授权系统应用、信用支付应用及信用授权系统的服务端之间的流程包括：

步骤1001、获取手机的设备参数信息；

步骤1002、上传设备参数信息；

步骤1003、判断手机收是否满足开通信用支付的硬件条件；

步骤1004、返回判断结果；

步骤1005、判断结果是：展示开通信用支付应用界面；

步骤1006、上传用户身份信息；

步骤1007、判断手机收是否满足开通信用支付的安全认证条件；

步骤1008、返回判断结果；

步骤1009、用户选择开通信用支付应用；

步骤1010、激活信用支付应用；

步骤1011、返回激活成功结果；

步骤1012、请求应用私钥、应用公钥证书和信用支付数据；

步骤1013、生成一对公私钥对，使用信用授权私钥生成应用公钥证书；生成支付卡；号、散列生成应用tac子密钥、应用加子密钥和信用支付数据；

步骤1014、返回应用私钥、应用公钥证书和信用支付数据；

步骤1015、发送应用私钥、应用公钥证书和信用支付数据；

步骤1016、保存应用私钥、应用公钥证书和信用支付数据；

步骤1017、返回个人化结果；

步骤1018、发送信用支付开通结果；

步骤1019、记录开通结果；

步骤1020、返回处理完成通知；

步骤1021、提示用户信用支付应用开通成功。

在本发明提供的又一实施例中，如图20所示，本发明提供的基于移动终端p2p的信用支付方法，移动终端在支付交易的过程中，移动终端与公交闸机之间的数据交互流程如下：

步骤2001、snep-request(get[读卡信息])；

步骤2002、读取需要返回的数据；

步骤2003、snep-response(返回支付卡号、可用额度、进出站标志、上次交易信息)；

步骤2004、黑名单判断；若存在黑名单中，提示拒绝信息；

步骤2005、检查可用额度、进出站标志；检查不通过，提示拒绝信息；

步骤2006、snep-request(get[读取应用公钥证书])；

步骤2007、snep-response(应用公钥证书)；

步骤2008、读取保管的应用授权系统的公钥，对应用公钥证书验签；验签不通过，提示拒绝信息；验签通过，解析出应用公钥；

步骤2009、计算扣款金额；

步骤2010、snep-request(put(扣款：扣款金额、交易时间、进出站标志和交易信息(站点等)))；

步骤2011、生成支付授权许可，包括：签名数据和tac；

步骤2012、返回签名数据和tac；

步骤2013、使用应用公钥对数据签名验签；验签通过，记录交易日志；验签不通过，提示拒绝信息。

另外，如图21所示，公交闸机还需要定期上传交易日志信用授权系统，以及更新黑名单列表。本发明提供的基于移动终端p2p的信用支付方法，公交闸机(交易终端)与 信用授权系统的服务端之间的数据交互流程如下：

步骤3001、定期上传交易日志；

步骤3002、结算，查询系统中的黑名单是否有更新，若有更新，准备黑名单列表返回；

步骤3003、返回交易日志接收结果和黑名单列表；

步骤3004、检查是否存在黑名单列表；

步骤3005、公交闸机更新黑名单列表；

步骤3006、更新；

步骤3007、返回更新完成结果。

其中，公家闸机管理系统可以位于公交闸机中。

上述实施例中，是以公交中实现支付的过程为例进行说明，可以理解的是，在其它场景下也同样适用，例如线下购物支付中，地铁支付中等等。具体应用场景不做限制。

通过以上的方法实施例的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：只读存储器(rom)、随机存取存储器(ram)、磁碟或者光盘等各种可以存储程序代码的介质。

另外，作为对上述各实施例的实现，本发明实施例还提供了一种基于移动终端p2p的信用支付装置，该装置位于移动终端中，如图22所示，该装置包括：第一返回请求信息接收单元10、交易响应信息20、信息发送单元30、扣款接受请求信息接收单元40、应用私钥生成支付授权许可生成单元50和支付授权许可发送单元60，其中，

第一返回请求信息接收单元10，用于接收所述交易终端发送的交易信息；

交易响应信息20，用于根据所述交易信息生成交易响应信息；

信息发送单元30，用于将交易响应信息发送给所述交易终端；

扣款接受请求信息接收单元40，用于接收所述交易终端发送的本次支付交易的扣款接受请求信息；

应用私钥生成支付授权许可生成单元50，用于根据所述扣款接受请求信息和所述交易响应信息，生成所述移动终端中的应用私钥生成支付授权许可；

支付授权许可发送单元60，用于将所述支付授权许可发送给所述交易终端，以使所述交易终端根据接收到的所述支付授权许可完成本次支付交易。

在本发明又一实施例中，基于图22，在本发明提供的又一实施例中，如图23所示，该装置还包括：

第二返回请求信息接收单元70，用于接收所述交易终端发送的应用公钥证书返回请求信息；

应用公钥证书响应信息生成单元80，用于根据所述应用公钥证书返回请求信息将所述移动终端的应用公钥证书生成应用公钥证书响应信息；

公钥证书响应信息发送单元90，用于将所述应用公钥证书响应信息发送给所述移动终端。

在本发明又一实施例中，基于图22，如图24所示，所述应用私钥生成支付授权许可生成单元50，包括：

签名数据生成模块51，用于根据所述扣款接受请求信息，利用所述移动终端存储的应用私钥生成签名数据；

信息生成模块52，用于根据所述扣款接受请求信息和所述交易响应信息，利用所述移动终端中预先生成的交易验证码tac子密钥生成tac；

支付授权许可确定模块53，用于将所述签名数据和所述tac均作为所述支付授权许可。

在本发明又一实施例中，基于图22，如图25所示，该装置还包括：

当前可用额度生成单元91，用于根据所述扣款接受请求信息中的扣款金额，将所述交易信息中的可用额度减去扣款金额，得到当前可用额度；

可用额度确定单元92，用于将所述当前可用额度作为所述移动终端中对应用户的可用额度。

在本发明又一实施例中，本发明实施例还提供了一种基于移动终端p2p的信用支付装置，该装置位于交易终端中，如图26所示，该装置包括：交易信息发送单元11、交易响应信息接收单元12、扣款单元13、扣款接受请求信息发送单元14和本次支付交易完成单元15，其中，

交易信息发送单元11，用于向所述移动终端发送交易信息；

交易响应信息接收单元12，用于接收所述移动终端发送的交易响应信息；

扣款单元13，用于根据交易响应信息生成本次支付交易的扣款接受请求信息；

扣款接受请求信息发送单元14，用于将所述扣款接受请求信息发送给所述移动终端；

本次支付交易完成单元15，用于在接收到支付授权许可时，根据所述支付授权许可确定本次支付交易完成。

在本发明又一实施例中，基于图26，如图27所示，该装置还包括：

返回请求信息发送单元16，用于向所述移动终端发送应用公钥证书返回请求信息；

公钥证书响应信息接收单元17，用于接收所述移动终端发送的应用公钥证书响应信息；

验签单元18，用于利用所述交易终端中的信用授权公钥对所述应用公钥证书响应信息中的应用公钥证书验签；

在本发明又一实施例中，基于图26，如图28所示，该装置还包括：黑名单判断单元191。其中，

黑名单判断单元191，用于判断所述交易响应信息中的支付卡号是否包含在预设黑名单中。

返回请求信息发送单元192，还用于在所述交易响应信息中的支付卡号没有包含在预设黑名单中时，向所述移动终端发送应用公钥证书返回请求信息。

在本发明又一实施例中，基于图21，如图29所示，该装置还包括：

阈值判断单元193，用于判断所述交易响应信息中的可用额度是否大于或者等于预设阈值；

状态检查单元194，用于在所述可用额度大于或者等于预设阈值时，检查所述交易信息中的进出站标志是否为已出站状态。

在本发明又一实施例中，基于图26，如图30所示，所述支付授权许可，包括：签名数据和交易验证码tac；所述本次支付交易完成单元15，包括：

验签模块151，用于利用所述应用公钥对所述签名数据验签；

交易日志生成模块152，用于在所述签名数据验签成功时，生成交易日志；

交易日志发送模块153，用于将所述交易日志发送给预设服务器，以使得所述预设服务器根据所述交易日志扣除所述移动终端对应的用户账户中相应的金额；其中，所述交易日志包括：扣款金额、交易日期、交易时刻、交易终端id、支付卡号、可用额度和tac。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

可以理解的是，本发明可用于众多通用或专用的计算系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。