CN101034449A - 实现电子支付的方法、系统及移动终端 - Google Patents

Abstract

本发明实施例提供一种实现电子支付的方法，包括：支付终端将包括支付者账户信息和支付金额的支付信息发送给收讫终端；收讫终端接收所述支付信息，将支付授权请求发送给发卡行服务器，所述请求中携带所述支付信息和包括收讫者账户信息的收讫信息；发卡行服务器对接收到的支付授权请求进行验证，在验证通过后，将支付者应允的所述支付金额从支付者账户中转出。本发明实施例还基于该方法提供一种实现电子支付的系统及移动终端。本发明实施例提供的技术方案可减少整个支付过程中信息传输的反复性，简化支付流程，也因此减轻支付终端的通信负担，减少通信开支，并节约传输资源。

Description

实现电子支付的方法、系统及移动终端

技术领域

本发明涉及通信技术领域，尤其涉及一种实现电子支付的方法、系统及移动终端。

背景技术

因特网、移动通信及计算机技术的不断发展，也使人们的生活方式随之发生着很大的改变。电子支付这一付费方式即基于计算机及通信技术的发展得以实现，并给人们的生活带来方便。

3-D安全协议(3-D secure)是Visa在2002年提出并开发的网上支付安全协议，也是目前较为完善的电子支付安全协议，并已成为新一代电子付账认证的标准架构。Visa、MasterCard、JCB、中国银联和美国运通等都已经加入了该3-D安全协议平台。参见图1，图1是基于3-D Secure协议开发的电子支付系统示意图。该系统中，设消费者通过移动终端来付费，则移动支付者基于该系统实现电子支付的流程如下：

移动终端将决定购买的商品信息、支付者的银行帐户等信息发送到商家服务器；

商家服务器将支付者的银行帐户等信息发送给Visa目录服务器；

Visa目录服务器根据接收到的信息，查找是否有可用的发卡行的访问控制服务器(ACS)，若没有，则直接向商家服务器返回无法认证的响应；若有，则将接收到的上述信息转发给对应的发卡行的ACS，询问ACS上述帐户等信息是否合法；

ACS接收到Visa目录服务器的询问信息后，向Visa目录服务器返回应答；

Visa目录服务器再将ACS的应答返回商家服务器；

商家服务器将支付授权请求通过移动终端转发给ACS；移动终端检查该支付授权请求所携带的支付者的支付信息是否齐全，若不齐全，则补齐后，将该支付授权请求发送给ACS；

ACS收到该请求后，对支付者身份进行认证，之后产生支付授权响应信息，并对该支付授权响应信息进行数字签名；

ACS将上述支付授权响应信息通过移动终端转发给商家服务器，同时将相关信息存入授权历史记录中；

商家服务器接收支付授权响应信息，并验证ACS的数字签名，在验证通过后，将支付授权响应信息发送给商家的收单行服务器；

收单行服务器与发卡行服务器之间进行结算。

在整个支付流程中，移动终端作为移动支付请求的发起者，由于需要与发卡行与商家之间进行频繁的信息交互，导致移动终端的通信负担较重，也因此增加通信费用的支出，延长了交易时间。虽然在ACS通过口令对支付者身份进行认证之后才进行支付授权，但仍给掌握支付者大量支付信息的商家进行商业欺诈提供可乘之机。因此，现有基于3-D Secure协议的支付系统及实现支付的流程还存在可改进之处。

发明内容

本发明实施例提供一种实现电子支付的系统，通过该系统实现电子支付。

一种实现电子支付的系统，该系统包括：支付终端、收讫终端和发卡行服务器；其中，

支付终端，用于与收讫终端和发卡行服务器之间进行通信，且将包括支付者帐户信息和支付金额的支付信息发送给收讫终端；

收讫终端，用于与支付终端和发卡行服务器之间进行通信，接收来自支付终端的所述支付信息，且将支付授权请求发出，所述请求携带所述支付信息和包括收讫者帐户信息的收讫信息；

发卡行服务器，用于与支付终端和收讫终端之间进行通信，且对接收到的支付授权请求进行验证，在验证通过后，将支付者应允的所述支付金额从支付者帐户中转出。

本发明实施例提供一种实现电子支付的方法，通过该方法实现电子支付。

一种实现电子支付的方法，包括：

支付终端将包括支付者帐户信息和支付金额的支付信息发送给收讫终端；

收讫终端接收所述支付信息，将支付授权请求发送给发卡行服务器，所述请求中携带所述支付信息和包括收讫者帐户信息的收讫信息；

发卡行服务器对接收到的支付授权请求进行验证，在验证通过后，将支付者应允的所述支付金额从支付者帐户中转出。

本发明实施例提供一种移动终端，应用于所述现电子支付的系统，具有电子支付功能。

一种移动终端，包括：支付信息生成模块和通信模块；其中，

支付信息生成模块，用于生成包括支付者帐户信息和支付金额的支付信息，将该支付信息传送给通信模块；

通信模块，用于将接收到的所述支付信息发送给收讫终端。

综上所述，本发明实施例提供的实现电子支付的方法、系统及移动终端，通过支付终端将支付信息单向传送给收讫终端，以及收讫终端将支付信息和收讫信息单向传送给发卡行服务器，减少整个支付过程中信息传输的反复性，从而简化支付流程，也因此减轻支付终端的通信负担，减少通信开支，并节约传输资源；且本发明实施例提供的上述系统能够与现有电子支付系统相兼容，方便易行。

附图说明

图1是基于3-D Secure协议开发的电子支付系统示意图；

图2是本发明实施例中实现电子支付的方法流程图；

图3是本发明实施例提供的实现电子支付的系统结构示意图；

图4是本发明实施例的系统中支付终端的结构示意图；

图5是本发明实施例的系统中收讫终端的结构示意图；

图6是本发明实施例的系统中发卡行服务器的结构示意图；

图7是本发明实施例中通过移动终端申请移动支付业务的流程图；

图8是本发明实施例中通过移动终端取消移动支付业务的流程图；

图9是本发明实施例中手机用户申请电子支票的流程图；

图10是本发明实施例中实现电子支付的流程图；

图11是本发明另一实施例中实现电子支付系统的示意图；

图12本发明实施例中各实体通过注册获得数字证书的示意图；

图13是本实施例中的请求信息格式示意图；

图14是本实施例中的应答信息格式示意图。

具体实施方式

为使本发明实施例技术方案和优点更加清楚，下面将结合附图作进一步详细描述。

无论是通过移动终端进行交易，或者是通过互联网进行网上交易，都是一种电子支付方式。本发明实施例即提供一种实现电子支付的方法及系统，运用该方法及系统实现电子支付，同时减轻支付终端的通信负担，也因此减少通信开支，并有效缩短交易时间。

参见图2，图2是本发明实施例中实现电子支付的方法流程图，该流程包括以下步骤：

步骤201、支付终端将包括支付者帐户信息和支付金额的支付信息发送给收讫终端。

步骤202、收讫终端接收支付信息，将支付授权请求发送给发卡行服务器，该请求携带所述支付信息和包括收讫者帐户信息的收讫信息。

其中，收讫信息至少可包括：收讫者帐户信息。

步骤203、发卡行服务器对接收到的支付授权请求进行验证，在验证通过后，将支付者应允的上述支付金额从支付者帐户中转出。

上述支付信息中，支付者帐户信息可包括：支付者的银行帐号、及帐户密码。若支付者未当面与商家进行购买商品的交易，那么支付信息还可进一步包括：商品标识信息，如商品序列号等。

结合上述实现电子支付的方法，本发明实施例还提供一种实现电子支付的系统。参见图3，图3是该系统的示意图，该系统包括：支付终端、收讫终端和发卡行服务器；其中，

支付终端，用于与收讫终端和发卡行服务器之间进行通信，且将包括支付者帐户信息和支付金额的支付信息发送给收讫终端；

收讫终端，用于与支付终端和发卡行服务器之间进行通信，接收来自支付终端的所述支付信息，且将支付授权请求发送给发卡行服务器；

发卡行服务器，用于与支付终端和收讫终端之间进行通信，且对接收到的支付授权请求进行验证，在验证通过后，将支付者应允的所述支付金额从支付者帐户中转出。

上述支付终端可以是移动终端、接入互联网的计算机等，可与收讫终端和/或发卡行服务器进行通信的设备。收讫终端可以是商家服务器。

参见图4，图4是上述系统中支付终端的结构示意图，本发明实施例中，支付终端可包括：支付信息生成模块401，通信模块402；其中，

支付信息生成模块401，用于生成包括支付者帐户信息和支付金额的支付信息，将该支付信息传送给通信模块402；

通信模块402，用于与收讫终端和发卡行服务器之间进行通信，且接收来自存储模块的支付信息，将该信息输出。

参见图5，图5是上述系统中收讫终端的结构示意图，本发明实施例中，收讫终端可包括：请求生成模块501和通信模块502；其中，

请求生成模块501，用于接收收讫信息和支付信息，生成所述支付授权请求，且将支付授权请求信息传送给通信模块502；

通信模块502，用于与支付终端和发卡行服务器之间进行通信，且接收支付信息，将支付信息传送给请求生成模块501，且将请求生成模块生成的支付授权请求发送出去。

参见图6，图6是上述系统中发卡行服务器的结构示意图，本发明实施例中，发卡行服务器可包括：通信模块601、认证模块602和处理模块603；其中，

通信模块601，用于与支付终端和收讫终端之间进行通信，接收通过支付网关转发的支付者的交易信息和收讫者的交易信息，将接收到的信息传送给验证模块；

验证模块602，用于接收来自通信模块601的支付信息和收讫信息，对接收到的信息进行验证，将验证结果传送给处理模块603；

处理模块603，用于接收来自验证模块602的验证结果，根据验证通过的验证结果，将支付者允许的支付金额从支付者帐户中转出。

在实际应用中，支付终端、收讫终端及发卡行服务器之间相互传输相关信息时，需确保信息传输的机密性，如应确保发卡行服务器所接收到的支付者所需支付金额为该支付者所填写的金额，并未被中途篡改；应确保收讫者提供的收讫者银行帐户信息未被篡改；等等。相应地，由于支付方式为电子支付，因此，在实际应用中，支付者、收讫者及发卡行三者之间还需进行身份确认，相应地，支付终端所传输的支付信息还需包括支付者身份标识等信息；收讫终端所传输的收讫信息还需包括收讫者身份标识信息。对发卡行服务器而言，若有需要，也应对相关信息进行加密传输。

在实际应用中，可模拟现实生活中的支票形式，将需要传输的信息项目罗列在一张电子支票上，并由该电子支票的发送方填写相关项目的内容，填写完毕后再将该电子支票发送出去。这样，以电子支票的形式将相关信息在支付终端、收讫终端和发卡行服务器之间传递，以便于传输及管理众多的信息。相应地，支付终端需要为进行电子支付准备一张有效的电子支票，所谓有效即该电子支票得到发卡行的认可。支付终端可通过向发卡行申请的方式获得一张电子支票。本发明实施例通过由支付终端向发卡行申请的方式来获得电子支票，其中，电子支票上罗列的项目可由三个部分组成：电子支票的基本信息，可包括：票号、发卡行标识等；支付信息，可包括：支付帐号、支付密码、、商品序列号、支付金额、收讫者标识、交易时间戳等，还可包括支付者身份标识信息，如支付终端标识、支付者数字签名等；收讫信息，可包括：收讫者的开户行标识、收讫者帐号等，还可包括收讫者身份标识信息，如收讫者数字签名等。参见表1，表1给出本发明实施例中电子支票的描述信息。表1所给出的电子支票项目较多，实际应用中所需的电子支票项目可与表1所示的电子支票项目有所不同，只要能够配合上述实现电子支付的流程，便于传输相关信息即可。

项目	描述	传输/存储形式	填写者/生成者
				票号	由支付者的开户行(即发卡行)按一定的规则产生	明文	发卡行
发卡行标识	用于唯一标识发卡行	明文	发卡行
				银行帐号	支付者可预先在支付终端内存入银行帐号，在支付时通过选择支付终端内关于支付的菜单列表选中该帐号，或由支付者支付时填写	密文	支付者
支付终端标识	唯一标识该支付终端	明文	支付终端
				商品序列号	该序列号可由商家通过网络、电话、短信等途径告知支付者，由支付者在购买该商品时输入或由支付终端自动读取商家反馈到支付终端上的该序列号	明文	支付者/支付终端
支付金额	支付者为购买商品所需支付金额+币种	明文	支付者
				收讫者标识	该标识用于唯一标识出售上述商品的商家。该标识可由商家通过网络、电话、短信等途径告知支付者，由支付者填写或由支付终端自动读取商家反馈到支付终端上的该标识	明文	支付者/支付终端
支付者的帐户密码	由支付者在支付时即时填写	密文	支付者
				交易时间戳	支付终端自动生成	明文	支付终端
支付者的数字签名	用于认证支付者所发信息的不可否认性	密文	支付终端
				收讫者的开户行标识	用于唯一标识收讫者的帐户所在银行	密文	收讫终端
收讫者的银行帐号	发卡行服务器确认支付授权请求后，支付金额将被转到该帐号上	密文	收讫终端

收讫者的数字签名

用于认证收讫者所发信息的不可否认性

密文

收讫终端

                                表1

从上述内容可知，本发明实施例中的支付终端可以是移动终端，鉴于移动终端，如手机是人们经常用到的通信工具，且随着通信技术的进步，手机所具有的功能越来越强大，如在本发明实施例中，就可在现有手机中植入本发明实施例中支付终端所包括的模块，使现有手机具有电子支付功能。因此，本发明实施例还可提供一种移动终端，该移动终端包括图3所示支付终端所包括的模块，具有电子支付功能。

在实际应用中，对于移动终端，如手机而言，其所能够开展的某些增值业务通常需要手机用户主动申请，如本发明实施例中，电子支付业务是由发卡行与移动运营商联合提供的一项服务业务，对于手机用户说，该业务需要手机用户主动申请获得。因此，手机用户在使用手机进行电子支付之前，需向发卡行申请开通该移动支付业务。手机用户可到发卡行的营业厅开通上述电子支付业务，也可通过与发卡行之间的信息交互开通该业务。相应地，在实际应用中，为便于手机用户对该移动支付业务进行操作，可将相关操作项目做成菜单形式。

另外，为验证申请或使用该移动支付业务的手机用户的合法性，可设置启用该移动支付功能的密码，只有输入正确密码的用户才能对移动支付业务菜单进行操作。

参见图7，图7是本发明实施例中通过移动终端申请移动支付业务的流程图，该流程可包括以下步骤：

步骤701、手机用户输入正确的移动支付功能的启动密码，进入移动支付业务菜单。

步骤702、手机用户从移动支付业务菜单中，选择“开启移动支付服务”选项，向发卡行服务器发送“开启移动支付服务请求”信息。

该步骤中，“开启移动支付服务请求”信息可包括手机标识信息、会话密钥、注册密码等。其中，移动终端标识信息由该请求信息自带；注册密码可在支付者通过移动终端开启该移动支付业务之前，先到银行营业厅申请开办该服务，与银行之间交涉注册密码，且该注册密码可被更改；注册密码由支付者自己填写后，会被发卡行服务器保存；之后，当支付者想开通该业务时，可在发送给发卡行服务器的上述“开启移动支付业务请求”信息中携带该注册密码，由发卡行服务器利用该注册密码确认申请开通该业务的支付者的合法身份；会话密钥用于加/解密手机与发卡行服务器之间会话的数据信息；该会话密钥可由发卡行服务器与移动终端之间商定的机制产生相同的会话密钥，比如双方共享根密钥，每次通信，由发起通信方产生随机数，并由根密钥与随机数产生会话密钥，发起通信放在密态通信息中附上随机数，则通信的另一方就可以利用共享的根密钥获知本次通信的会话密钥。

步骤703、发卡行服务器接收到该“开启移动支付服务请求”信息后，验证该信息中手机标识及注册密码信息的合法性，在验证通过后，启动该手机支付者的移动支付服务，并将“开启移动支付服务应答”信息发出。

步骤704、手机终端收到“开启移动支付服务应答”信息后，提示手机用户移动支付业务申请成功。

若手机用户要取消移动支付业务，则可参见图8，图8是本发明实施例中通过移动终端取消移动支付业务的流程图，该流程可包括以下步骤：

步骤801、手机用户输入正确的移动支付功能的启动密码，进入移动支付业务菜单。

步骤802、手机用户从移动支付业务菜单中，选择“取消移动支付服务”选项，向发卡行服务器发送“取消移动支付服务请求”信息。

步骤803、发卡行服务器接收到该“取消移动支付服务请求”信息后，验证该信息中手机标识及注册密码信息的合法性，在验证通过后，取消该手机用户的移动支付业务，并将“取消移动支付业务应答”信息发出。

步骤804、手机终端收到“取消移动支付服务应答”信息后，提示手机用户移动支付业务已取消。

手机用户在使用电子支票开展电子支付业务之前，需要主动向发卡行申请一张可用的电子支票，发卡行在确认该手机支付者尚未拥有电子支票后，接收手机用户的申请。参见图9，图9是本发明实施例中手机用户申请电子支票的流程图，该流程包括以下步骤：

步骤901、手机用户输入正确的移动支付功能的启动密码，进入移动支付业务菜单。

步骤902、手机用户从菜单中，选择“申请电子支票”选项，向发卡行服务器发送“申请电子支票”信息。

步骤903、发卡行服务器接收到该“申请电子支票”信息后，验证该信息中手机标识及注册密码信息的合法性，在验证通过后，签发一张有效的电子支票，并向该手机支付者发送“申请电子支票应答”信息。

有效的电子支票即得到所申请的发卡行服务器认可的数字信息，该电子支票被发卡行服务器利用会话密钥和/或加发卡行服务器的数字签名后发送给移动终端，移动终端接收到该包含电子支票的数据信息后，对该数据信息进行解密、验证信息完成性或验证发卡行服务器的数字签名等操作后，将该有效的电子支票保存于本地。

发卡行服务器签发电子支票是指发卡行服务器将电子支票号码、该银行标识等相关信息发送给移动终端，之后在发卡行服务器本地保存该电子支票的票号等信息。发卡行服务器也可在发送之前对上述信息进行数字签名。相应地，支付者在之后使用该电子支票进行支付时，须附上电子支票号码、银行标识等由发卡行服务器用于验证该电子支票有效性的信息，在验证相关信息无误之后，才允许进行转账处理，完成支付。

步骤904、手机终端接收到上述“申请电子支票应答”信息后，验证该信息的合法性，在通过验证后，提示手机用户电子支票申请成功。

另外，实际应用中，通过手机进行电子支付的支付者也可在发卡行的营业厅办理上述电子支票的申请。

下面结合具体的实施例，具体说明基于本发明实施例给出的系统实现电子支付的过程。参见图10，图10是本发明实施例中实现电子支付的流程图，该流程可包括以下步骤：

步骤1001、支付终端通过与收讫终端之间的通信链路，将电子支票发送给收讫终端。

参见表1，该步骤中，支付终端发出的电子支票上，需要由支付终端或支付者填写的内容已填写，如帐号、支付终端标识等等，还可包括支付者数字签名，以保证数据传输的不可否认性。并且，支付终端还可对涉及支付者私人信息的支付信息，利用会话密钥进行加密处理，并产生校验码，以保证数据传输的机密性和完整性。

另外，为节约通信传输资源，在实际应用中，还可在发送电子支票之前，对支付终端内所记录的当前支付帐户的余额与应支付金额进行对比，若余额不足，则可提示支付者；反之，允许发出电子支票，并且当交易成功后，根据发卡行返回的支付确认请求，刷新余额。

上述通信链路可包括能够实现支付终端与收讫终端之间通信的有线或无线链路。

步骤1002、收讫终端对接收到的电子支票进行验证后，填充电子支票中需要收讫终端或收讫者填写的收讫信息，且生成支付授权请求，然后将携带电子支票信息的支付授权请求发送出去。

该步骤中，收讫终端对接收到的电子支票中的除支付者帐户的其他信息，进行验证，该验证过程可包括：验证校验码，检验电子支票的完整性；若校验码检验错误，核对电子支票明文支付信息，如支付终端标识、商品序列号、支付金额、收讫者标识、交易时间戳等；若上述被验证的内容无误，则电子支票通过验证；否则收讫终端向支付终端发送电子支票信息错误的响应，并中止支付流程。参见图5，相应地，收讫终端进一步可包括验证模块503，用于接收来自通信模块502的支付信息，对该信息进行验证，将验证通过的结果再传送给通信模块502；通信模块502根据验证通过的结果，再将支付授权请求发送出去。

参见表1，该步骤中，由于密文支付信息被支付终端采用支付终端与发卡行服务其之间的会话密钥进行加密，所以密文支付信息对收讫终端来说是无法解密的，从而确保支付者认为重要的支付信息的安全性。

该步骤中，在收讫终端将电子支票发出之前，需补齐电子支票中需要收讫终端或收讫者填写的内容，如收讫者的帐户信息，收讫者数字签名等，且收讫终端还可对收款信息进行加密，并产生校验码，以保证数据传输过程中的不可否认性、机密性和完整性。

收讫终端添加收讫信息的做法可包括：收讫终端使用自己的私钥产生数字签名；然后使用发卡行的公钥对收讫信息和数字签名进行加密；最后产生校验码，连同电子支票以及自己的数字证书一起，生成支付授权请求，将该支付收取请求发出。

步骤1003、支付网关将接收到的支付授权请求转发给发卡行服务器。

本实施例中，收讫终端通过支付网关，向发卡行服务器发送支付授权请求。该支付网关的作用包括，为收讫终端和发卡行服务器提供一个交易平台。参见图11，图11是另一本发明实施例中实现电子支付系统的示意图，该系统进一步可包括该支付网关，该支付网关与收讫终端和发卡行服务器之间进行通信，收讫终端通过该平台将支付授权请求发送给发卡行服务器，相应地，发卡行服务器可通过该平台，将支付授权请求的确认应答转发给收讫终端。并且，该支付网关还可具有记录交易信息的功能，以及为收讫者提供转帐服务的功能。该支付网关具体可包括：

授权请求转发模块，用于接收来自收讫终端的支付授权请求，将该请求转发给发卡行服务器；

请求应答转发模块，用于接收来自发卡行服务器的支付授权请求的应答，且将该应答转发给收讫终端；

记录模块，用于记录请求应答转发模块所接收到的支付授权请求的应答信息。

步骤1004、发卡行服务器根据接收到的支付授权请求，对支付授权请求中携带的信息进行验证，在验证通过后，将支付者应允的支付金额从支付者帐户中转出，且向支付终端发送支付信息的确认请求。

参见表1，该步骤中，发卡行服务器根据电子支票的票号、发卡行标识来确认该电子支票是否合法，并对电子支票中支付者帐户、支付密码、收讫者帐户等信息进行验证，还对标识支付者身份和收讫者身份的相关信息进行验证。其中，对于电子支票中经过加密的数据，发卡行服务器需要采用相应的密钥解密后再作验证。上述验证的过程可以是：验证支付授权请求的校验码，以验证该请求信息的完整性；使用与支付终端之间的会话密钥解密相关支付信息，对支付者身份及帐户等信息进行验证；使用私钥解密相关收讫信息，对收讫者身份进行验证；若上述各验证结果均为合法，则通过验证，继续支付流程；否则，中止支付流程。

在上述信息均被验证通过后，发卡行服务器对支付金额作转帐处理，在实际应用中，该处理过程可包括：发卡行服务器先将资金转到一个保付帐号中，然后向支付终端发送支付信息的确认请求，在一段时间内等待支付终端返回该请求的确认应答，在收到支付终端的确认应答后向收讫终端发送支付授权请求的应答信息；若在该时间段内未收到确认应答，可重复发送，若重复发送的次数超过预先设定的一个阈值，则，发送交易失败信息。  另外，发卡行服务器可对发送给支付终端的上述确认请求信息进行加密后再发送。

步骤1005、支付终端收到支付信息的确认请求信息后，自动或者由用户手动发送确认应答。

该步骤中，若支付终端收到的支付信息的确认请求被发卡行服务器加密，那么支付终端需对该确认请求信息进行解密，在核对支付信息后，自动或者由用户手动发送确认应答，且更新支付终端内的帐户余额；

步骤1006、发卡行服务器收到支付终端的确认应答后，通过支付网关，向收讫终端发送支付授权应答信息。

该步骤中，支付网关将支付授权应答信息存入历史记录中以备查询。

步骤1007、收讫终端接收到支付授权应答后，向支付终端发送支付成功的回执。

步骤1008、收讫终端将接收到的支付授权应答转发给收单行服务器，向收单行服务器申请结算，支付流程结束。

该步骤中，收讫终端可定期把支付授权应答信息发送给收单行服务器，收单行服务器对支付授权应答进行验证后，收单行服务器与发卡行服务器及支付网关之间进行银行内部资金转账、结算。该步骤的具体实现可与现有技术相同。

参见图11，实现电子支付的系统进一步可包括：收单行服务器，用于对支付授权应答进行验证，验证通过后，与发卡行服务器及支付网关之间进行银行内部资金结算。

基于上述图7至图10所示的流程，本发明实施例提供的移动终端进一步可包括：加解密模块和验证模块和/或密码比较模块；其中，

密码比较模块，用于验证使用移动支付业务的支付者身份的合法性；

加解密模块，用于对通过通信模块发送的数据进行加密，对通过通信模块接收的数据进行解密，将解密得到的数据传送给验证模块；

验证模块，用于验证接收到的解密得到的数据的合法性；

存储模块，用于存储支付者身份标识(ID)和/或身份证号和/或注册密码和/或会话密钥和/或数字证书和/或当前工作密码和/或移动支付业务的启动密码和/或输入密码的次数阈值等等。

另外还要说明一下的是，发卡行服务器等实体可通过向第三方证书发布机构注册得到用于数字签名的数字证书。参见图12，图12本发明实施例中各实体通过注册获得数字证书的示意图，该注册的情况可以是：

发卡行服务器向第三方证书发布机构进行注册，第三方证书发布机构向发卡行服务器颁发数字证书；

支付网关向第三方证书发布机构进行注册，第三方证书发布机构向支付网关颁发数字证书；

收单行服务器向第三方证书发布机构进行注册，第三方证书发布机构向收单行服务器颁发数字证书；

支付终端向发卡行服务器进行注册，发卡行服务器为支付终端建立银行帐号，并向支付终端颁发帐号密码；

收讫终端向收单行服务器进行注册，收单行服务器建立收讫终端的银行帐号。

在实际应用中，为进一步增强电子支付的安全性，本发明实施例还提供交易过程的安全协议，该安全协议根据会话密钥和加密算法对被传递的重要信息进行加、解密。该安全协议给出了对信息进行的加、解密的方法，也规定了相应的加、解密密钥管理细节。该安全协议可包括：在支付终端初始化时写入根密钥；使用基于信息交互次数的会话密钥更新方法，也即在支付终端设置一个计数器，该计数器用于对支付终端发送信息的次数进行计数，当计数结果达到一个阈值时，支付终端自动在发出的信息中设置密钥更新标志位，发卡行服务器接到该信息后就在返回支付终端的支付信息的确认请求应答信息中携带新的会话随机数，之后，支付终端可使用接到新的会话随机数生成新的会话密钥，以对信息进行加解密。会话密钥的更新采用的是离线生成的方式，即密钥不通过网络传输而是在终端本地生成，有效防止了密钥被泄漏或截获的情况。

在通过移动终端实现电子支付的方案中，可在移动终端内设置密码输入计数器，该计数器用于对支付者输入的启动移动支付业务的次数进行计数。可设置若支付者连续输入错误密码的次数超过一个阈值，那么锁住移动终端的移动支付功能，此后支付者将不能进入该移动终端的“移动支付业务”菜单。支付者若要重新进入菜单使用“移动支付”功能，必须对移动终端进行解锁。该解锁的操作可以是：进入移动支付终端“解锁”菜单，移动终端界面提示支付者输入解锁口令，若支付者输入正确的口令，则可再次有进入“移动支付业务”菜单的机会；若支付者连续输入错误口令的次数超过一个阈值，那么该移动终端的移动支付功能将会被锁死，即将无法使用移动支付功能。该安全机制可有效防止非法支付者对移动终端的穷举攻击。

对于采用移动终端实现电子支付的情况，本发明实施例提供具体实现时可以使用的一种协议信息格式。下面对该协议信息格式作具体说明。本实施例中，可将该协议信息区分为请求信息和应答信息。参见图13，图13是本实施例中的请求信息格式示意图，该请求信息可由信息头和信息体两部分构成。

其中，请求信息的信息头可包括：

信息标识(flag)：用于区别普通短信和移动支付协议短信的标识。

版本：协议的版本号；

发卡行标识：使用唯一标识来表示支付者的帐户所属银行；发卡行标识放在协议信息头区域是为了便于支付网关收到请求信息之后不用拆分协议信息而直接通过识别发卡行标识把该信息转发至相应的发卡行服务器。

请求类型，可包括：开启移动支付业务请求、取消移动支付业务请求、移动支付请求、申请电子支票四种类型；

应答类型，可包括：开启移动支付业务请求的应答、取消移动支付业务请求的应答、移动支付请求的应答、申请电子支票请求的应答四种类型；

数据长度：标识协议信息体的数据长度；

时间戳：用于标识发出请求/应答协议短信的时间，可采用标准的TP-SCTS格式，参见GSM 03.40 9.2.3.11。

请求信息协议体的数据内容可包括：支付终端标识、商品序列号、支付金额、支付帐号、注册/支付密码，除了“支付终端标识”和“注册/支付密码”是需要存在数据项的之外，其它数据项的内容可为空。例如信息的请求类型为开启移动支付业务请求，或申请电子支票请求，或取消移动支付业务请求，则封装的请求信息协议体数据中除了“支付终端标识”和“注册/支付密码”外，其它数据项为空。当请求信息的类型为“移动支付请求信息”时，所有的数据项可被写入内容。

另外，如之前提及的，支付终端标识、商品序列号等信息可以明文形式传输，以便于收讫终端对接收到支付信息中的明文信息进行核对；支付帐号和支付密码涉及到支付者的私人信息，可使用会话密钥加密后以密文的形式传输，保证该信息的机密性。

参见图14，图14是本实施例中的应答信息格式示意图，该应答信息也可由信息头和信息体两部分构成，且有关信息头的描述可参见上文。对于应答信息协议体的数据内容，除“请求失败/成功”是需要存在数据项的之外，其它数据项的内容可以为空。若请求失败，则设置“请求失败/成功”数据项内容为0，然后在“失败信息”数据项中写入请求失败的原因。系统可以用特定的标识符预先定义常见的请求失败类型，如密码错误、帐号错误、余额不足等，这样可以减少应答信息的数据传输量。若请求成功，则设置“请求失败/成功”数据项内容为1，如果应答信息的类型为“移动支付应答”，则在支付帐号、余额、新票号各数据项中写入相应的内容；如果是其它类型的应答信息，后四项数据项的内容为空。其中请求失败/成功、失败信息/会话随机数、支付帐号、余额、新票号涉及到支付者的私人信息，可使用会话密钥加密后以密文的形式传输，以保证信息的机密性。

综上所述，本发明实施例提供的实现电子支付的方法、系统及移动终端，通过支付终端将支付信息单向传送给收讫终端，以及收讫终端将支付信息和收讫信息单向传送给发卡行服务器，减少整个支付过程中信息传输的反复性，从而简化支付流程，也因此减轻支付终端的通信负担，减少通信开支，并节约传输资源；且本发明实施例提供的上述系统能够与现有电子支付系统相兼容，方便易行。另外，本发明实施例提供的方法及系统中，可采用相应的加密技术对传输的重要信息进行加密处理，提供信息传输的安全性，同时由于相关信息采用单向传输的机制，使信息传输对网络安全性的依赖性降低。本发明实施例中，为进一步确保支付的可靠性，可采取由发卡行服务器向支付终端发送支付确认的请求信息，且发卡行服务器在得到支付终端的应答后才完成转帐，有效保障支付者的利益，且在交易过程中，也放宽了支付者一次性可支付的金额数。

Claims (21)

1、一种实现电子支付的方法，其特征在于，包括：

支付终端将包括支付者帐户信息和支付金额的支付信息发送给收讫终端；

收讫终端接收所述支付信息，将支付授权请求发送给发卡行服务器，所述请求中携带所述支付信息和包括收讫者帐户信息的收讫信息；

发卡行服务器对接收到的支付授权请求进行验证，在验证通过后，将支付者应允的所述支付金额从支付者帐户中转出。

2、根据权利要求1所述的方法，其特征在于，所述支付信息进一步包括：支付者身份标识信息和/或商品标识信息。

3、根据权利要求1或2所述的方法，其特征在于，收讫终端将所述支付授权请求发送给发卡行服务器之前，该方法进一步包括：

收讫终端对所述支付信息中信息进行验证。

4、根据权利要求2所述的方法，其特征在于，所述收讫信息进一步包括：收讫者身份标识信息。

5、根据权利要求4所述的方法，其特征在于，发卡行服务器对接收到的支付授权请求进行验证的步骤进一步包括：

发卡行服务器对支付者身份和收讫者身份进行合法性验证。

6、根据权利要求1所述的方法，其特征在于，支付终端将包括支付者帐户信息的支付信息以明文或密文的方式发送给收讫终端。

7、根据权利要求1所述的方法，其特征在于，发卡行服务器将支付者应允的支付金额从支付者帐户中转出之前，该方法进一步包括：

发卡行服务器向支付终端发送支付信息的确认请求，等待支付终端返回该请求的确认应答。

8、根据权利要求1或7所述的方法，其特征在于，发卡行服务器将支付者应允的支付金额从支付者帐户中转出之后，该方法进一步包括：

发卡行服务器向收讫终端发送支付授权请求的确认应答。

9、根据权利要求8所述的方法，其特征在于，发卡行服务器将支付者应允的支付金额从支付者帐户中转出之后，该方法进一步包括：

收讫终端将接收到所述确认应答转发给收单行服务器；

收单行服务器与发卡行服务器之间进行结算。

10、根据权利要求1所述的方法，其特征在于，收讫终端接收所述支付信息，将支付授权请求发送给发卡行服务器的步骤包括：

收讫终端将所述支付授权请求通过支付网关发送给发卡行服务器。

11、根据权利要求1所述的方法，其特征在于，支付终端将所述支付信息发送给收讫终端之前，该方法进一步包括：

支付终端、收讫终端和发卡行服务器通过第三方证书发布机构获得各自的数字证书，且相互交换各自的数字证书。

12、一种实现电子支付的系统，其特征在于，该系统包括：支付终端、收讫终端和发卡行服务器；其中，

支付终端，用于与收讫终端和发卡行服务器之间进行通信，且将包括支付者帐户信息和支付金额的支付信息发送给收讫终端；

收讫终端，用于与支付终端和发卡行服务器之间进行通信，接收来自支付终端的所述支付信息，且将支付授权请求发出，所述请求携带所述支付信息和包括收讫者帐户信息的收讫信息；

发卡行服务器，用于与支付终端和收讫终端之间进行通信，且对接收到的支付授权请求进行验证，在验证通过后，将支付者应允的所述支付金额从支付者帐户中转出。

13、根据权利要求12所述的系统，其特征在于，所述支付终端包括：支付信息生成模块和通信模块；其中，

支付信息生成模块，用于生成包括支付者帐户信息和支付金额的支付信息，将该支付信息传送给通信模块；

通信模块，用于将接收到的所述支付信息发送给收讫终端。

14、根据权利要求12所述的系统，其特征在于，所述收讫终端包括：请求生成模块和通信模块；其中，

请求生成模块，用于接收收讫信息和支付信息，生成所述支付授权请求，且将支付授权请求信息传送给通信模块；

通信模块，用于与支付终端和发卡行服务器之间进行通信，且接收支付信息，将支付信息传送给请求生成模块，且将请求生成模块生成的支付授权请求发送出去。

15、根据权利要求12所述的系统，其特征在于，所述发卡行服务器包括：通信模块、认证模块和处理模块；其中，

通信模块，用于与支付终端和收讫终端之间进行通信，将接收到支付授权请求接收通过支付网关转发的支付者的交易信息和收讫者的交易信息，将接收到的信息传送给验证模块；

验证模块，用于接收来自通信模块的支付者的交易信息和收讫者的交易信息，对接收到的信息进行验证，将验证结果传送给处理模块；

处理模块，用于接收来自验证模块的验证结果，根据验证通过的验证结果，将支付者允许的支付金额从支付者帐户中转出。

16、根据权利要求12所述的系统，其特征在于，所述系统进一步包括：支付网关，该支付网关包括：

授权请求转发模块，用于接收来自收讫终端的支付授权请求，将该请求转发给发卡行服务器；

请求应答转发模块，用于接收来自发卡行服务器的支付授权请求的应答，且将该应答转发给收讫终端。

17、根据权利要求16所述的系统，其特征在于，所述支付网关进一步包括：

记录模块，用于记录请求应答转发模块所接收到的支付授权请求的应答信息。

18、根据权利要求16所述的系统，其特征在于，所述系统进一步包括：

收单行服务器，用于接收来自发卡行服务器的支付授权应答信息，对该信息进行验证，验证通过后，与发卡行服务器及支付网关之间进行银行内部资金结算；

所述支付网关进一步包括：

转帐模块，用于与收单行服务器和发卡行服务器之间进行银行内部资金结算。

19、一种移动终端，其特征在于，包括：支付信息生成模块和通信模块；其中，

支付信息生成模块，用于生成包括支付者帐户信息和支付金额的支付信息，将该支付信息传送给通信模块；

通信模块，用于将接收到的所述支付信息发送给收讫终端。

20、根据权利要求19所述的移动终端，其特征在于，该移动终端进一步包括：加解密模块和验证模块和/或密码比较模块；其中，

密码比较模块，用于验证使用移动支付业务的支付者身份的合法性；

加解密模块，用于对通过通信模块发送的数据进行加密，对通过通信模块接收的数据进行解密，将解密得到的数据传送给验证模块；

验证模块，用于验证接收到的解密得到的数据的合法性。

21、根据权利要求20所述的移动终端，其特征在于，所述存储模块进一步包括存储模块，用于存储支付者身份标识ID和/或身份证号和/或注册密码和/或会话密钥和/或数字证书和/或当前工作密码和/或移动支付业务的启动密码和/或输入密码的次数阈值。

Images