专利名称：一种交易支付方法和系统的制作方法
一种交易支付方法和系统技术领域：
本发明涉及网络技术，尤其涉及一种交易支付方法和系统。背景技术：
随着电子商务的快速发展，以及银行电子化服务水平的提高，银行与第三方支付方式不断创新，目前已有的支付方式种类繁多，包括传统的POS支付、ATM机支付、网银支付、手机银行等多种支付方式，为人们提供了快速便捷的支付方式，大大方便了人们的日常生活。
传统的交易支付方式通常都采用单信道信息传输方式。例如，手机银行，其依托的是移动通信运营商的网络，基于WAP技术，为手机客户提供账户查询、转账、缴费付款、消费支付等金融服务。例如，互联网支付、网银支付是在互联网信道或即时通讯信道上传输交易数据。
然而，传统的这些交易支付方式，在确认用户身份信息时存在各种安全性的问题。 如对于手机银行，手机容易丢失；对于互联网支付、网银支付，通常仅需要验证用户密码，验证用户身份信息的方式单一，在用户终端电脑中木马病毒时，容易导致数据被窃。因此，传统的交易支付方式的安全性并不高。
发明内容
基于此，有必要提供一种能提高安全性的交易支付方法。
一种交易支付方法，包括以下步骤
支付终端获取用户的支付信息，所述支付信息包括通信号码，所述支付终端将所述支付信息提交到电话支付 系统；
所述电话支付系统通过互动式语音应答平台呼叫所述通信号码，获取用户输入的支付密码，并将所述支付密码和支付信息发送至银行系统；
所述银行系统对所述支付密码和支付信息进行验证，验证通过则进行支付。
优选的，所述通信号码为移动通信号码；在所述电话支付系统通过互动式语音应答平台呼叫所述移动通信号码的步骤之前，还包括
通过短信平台向所述移动通信号码对应的移动终端下发短信验证码；
接收所述移动终端返回的回复验证码；
判断所述回复验证码是否与所述短信验证码一致，若是，则验证通过，否则验证不通过。
优选的，在所述电话支付系统通过互动式语音应答平台呼叫所述移动通信号码的步骤之前，还包括
获取返回回复验证码的移动终端的移动通信号码；
通过银行系统验证所述获取的移动通信号码是否与预先存储的开户信息中的移动通信号码一致，若是，则验证通过，否则验证不通过。
优选的，在回复验证码验证通过的步骤和/或返回回复验证码的移动终端的移动 通信号码验证通过的步骤之后，还包括
对所述支付信息进行风险信息校验。
优选的，在所述电话支付系统通过互动式语音应答平台呼叫所述通信号码的步骤 之前，和/或在所述支付密码验证通过之后，还包括
对所述支付信息进行风险信息校验。
优选的，所述支付终端对所述支付信息进行风险信息校验的步骤包括
获取所述支付信息中的商户额度，检测所述商户额度是否大于设定阈值，若是，则 校验不通过，否则校验通过；和/或
根据所述支付信息判断用户是否为黑名单用户，若是，则校验不通过，否则校验通 过。
优选的，所述对所述支付信息进行风险信息校验的步骤还包括
所述电话支付系统将所述支付信息发送至银行系统；
所述银行系统判断所述支付信息是否与预先存储的开户信息一致，若是，则校验 通过，否则校验不通过。
此外，还有必要提供一种能提高安全性的交易支付系统。
一种交易支付系统，所述系统包括
支付终端，用于获取用户的支付信息，所述支付信息包括通信号码；所述支付终端 还用于将所述支付信息提交到电话支付系统；
电话支付系统，包括互动式语音应答平台，所述互动式语音应答平台用于呼叫所 述通信号码，获取用户输入的支付密码，并将所述支付密码和支付信息发送至银行系统；
银行系统，用于对所述支付密码和支付信息进行验证，验证通过则进行支付。
优选的，所述通信号码为移动通信号码；所述电话支付系统还包括短信平台，用于 通过短信向所述移动通信号码对应的移动终端下发短信验证码，接收所述移动终端返回的 回复验证码，判断所述回复验证码是否与所述短信验证码一致，若是，则验证通过，否则验 证不通过。
优选的，所述短信平台还用于获取返回回复验证码的移动终端的移动通信号码， 将所述移动通信号码发送至所述银行系统；
所述银行系统还用于验证所述获取的移动通信号码是否与预先存储的开户信息 中的移动通信号码一致，若是，则验证通过，否则验证不通过。
优选的，所述电话支付系统还包括用于在回复验证码验证通过和/或返回回复验 证码的移动终端的移动通信号码验证通过之后，对所述支付信息进行风险信息校验的风险 控制系统。
优选的，所述风险控制系统还用于在所述电话支付系统通过互动式语音应答平台 呼叫所述通信号码的步骤之前，和/或在所述支付密码验证通过之后对所述支付信息进行 风险信息校验。
优选的，所述风险控制系统用于获取所述支付信息中的商户额度，检测所述商户 额度是否大于设定阈值，若是，则校验不通过，否则校验通过；和/或
所述风险控制系统用于根据所述支付信息判断用户是否为黑名单用户，若是，则校验不通过，否则校验通过。
优选的，所述风险控制系统还用于将所述支付信息发送至所述银行系统；
所述银行系统还用于判断所述支付信息是否与预先存储的开户信息一致，若是， 则校验通过，否则校验不通过。
上述交易支付方法和系统中，电话支付系统在接收到支付信息后，通过互动式语音应答平台自动呼叫支付信息中的移动通信号码，获取用户输入的支付密码并对支付密码和支付信息进行验证。由于支付终端提交支付信息所采用的通道与互动式语言应答平台所采用的通道不相同，在对支付密码和支付信息进行验证时，减少了不法分子通过假网站、木马病毒截获用户的支付信息的可能，因此能够提高安全性。
图1为一个实施例中交易支付方法的流程示意图2为另一个实施例中交易支付方法的流程示意图3为一个实施例中进行风险信息校验的流程图4为一个实施例中交易支付系统的结构示意图5为另一个实施例中电话支付系统的结构示意图。
具体实施方式
如图1所示，在一个实施例中，一种交易支付方法，包括以下步骤
步骤S102，支付终端获取用户的支付信息，该支付信息包括通信号码，支付终端将支付信息提交到电话支付系统。
支付终端可以是计算机、电视机、移动通信终端及其他嵌入式电子设备，可以通过 Web浏览器提交订单，也可以通过即时通讯工具提交订单，从而生成订单数据。订单数据包括用户信息、商户信息、购买的商品信息等。其中，用户信息包括用户注册帐号、用户名称、 收获地址、联系方式等；商户信息即商家信息，例如店铺名称、地址、联系方式等；购买的商品信息包括购买数量、购买价格、应付金额等。
通过支付终端提交订单并确认支付后，获取用户的支付信息。用户的支付信息包括银行卡号、用户身份信息、订单相关信息，其中用户身份信息包括但不限于身份证信息 (包括用户姓名和身份证号码等)、支付密码、通信号码(可以是移动通信号码，也可以是固定通信号码)、即时通信号码、联系地址等，订单相关信息包括应付金额等。在一个实施例中，在用户提交订单数据后，可弹出提示框提示用户填写支付信息。具体的，支付终端通过互联网信道或即时通信信道将支付信息提交到电话支付系统。
步骤S104，电话支付系统通过互动式语音应答平台呼叫所述通信号码，获取用户输入的支付密码，并将支付密码和支付信息发送到银行系统。
具体的，电话支付系统设置有互动式语音应答平台(Interactive Voice Response, IVR)，通过IVR平台呼叫支付信息中的通信号码。该通信号码对应的通信终端会收到呼叫，持有该通信终端的用户接听后，通信终端与IVR平台建立连接，通信终端会收到 IVR平台通过语音信道下发的语音提示，用户根据语音提示输入支付密码，终端将支付密码上传到电话支付系统，由电话支付系统将支付密码和支付信息组织成交易报文，并发送至银行系统。
步骤S106，银行系统对支付密码和支付信息进行验证，验证通过则进行支付。
银行系统预先存储了用户的开户信息，包括身份证信息、开通的银行卡卡号、联系 地址、移动通信号码、支付密码等。银行系统在收到支付密码和支付信息后，验证用户输入 的支付密码是否正确，并验证支付信息是否与用户的开户信息相符，如果正确，则验证通 过，则直接扣款。
在一个实施例中，银行系统完成支付后，通知电话支付系统，由电话支付系统修改 用户订单状态等。
在一个实施例中，在步骤S104之前，还包括对支付信息进行风险信息校验的步 骤。在支付信息的风险信息校验通过后IVR平台才呼叫通信号码，从而能够确保在呼叫之 前的安全性。在本实施例或另一个实施例中，在步骤S106中对支付密码进行验证通过后， 还包括对支付信息进行风险信息校验的步骤。由于支付密码验证通过后支付信息还可能更 改，在支付信息的风险信息校验通过后银行系统才进行扣款，能够进一步提高支付的安全 性。
由于支付终端提交支付信息和IVR平台获取支付密码分别是通过不同的信道进 行数据传输的，可以在两个信道上对支付信息进行验证，从而提高了安全性。另外，电话 支付系统在收到支付信息后，通过IVR平台自动呼叫支付信息中的通信号码来获取支付密 码，相对于传统的用户主动呼叫IVR平台提供支付密码的方式，能确保提供支付密码的用 户为通信号码对应的终端的持有人。如果支付密码被盗取，也能通过自动呼叫提供的通信 号码来有效阻止支付，因此，进一步提高了安全性。
如图2所示，在另一个实施例中，一种交易支付方法，包括以下步骤
步骤S202，支付终端获取用户的支付信息，该支付信息包括移动通信号码，支付终 端将支付信息提交到电话支付系统。
步骤S204，通过短信平台向移动通信号码对应的移动终端下发短信验证码。
步骤S206，接收移动终端返回的回复验证码。
具体的，移动终端接收到短信后，用户输入回复验证码，回复验证码返回到短信平 台。
步骤S208，判断回复验证码是否与短信验证码一致，若是，则进入步骤S210，否则结束。
在一个实施例中，如果回复验证码与短信验证码不一致，可下发短信提示用户返 回的验证码不正确，不能完成支付。这样，通过短信信道进行数据传输，再次对支付信息进 行验证，进一步提高了安全性。
步骤S210，获取返回回复验证码的移动终端的移动通信号码。
步骤S212，通过银行系统验证获取的移动通信号码是否与预先存储的开户信息中 的移动通信号码一致，若是，则进入步骤S214，否则结束。
在银行系统中预先存储了用户的开户信息，包括用户开通银行卡时所提供的移动 通信号码。如果银行系统获取的移动通信号码与预先存储的开户信息中的移动通信号码一 致，则通过验证，否则，验证不通过。
在一个实施例中，如果验证不通过，银行系统可以通知电话支付系统，电话支付系统通过短信平台下发短信到移动终端，提示用户验证不通过，不能完成支付。通过银行系统 对返回回复验证码的移动通信号码进行验证，确保了移动终端的持有者即为银行卡用户， 避免了因为移动终端丢失而银行卡资金丢失的风险，进一步提高了安全性。
此外，由于在呼叫移动通信号码之前，对短信验证码进行了验证，以及对获取返回 回复验证码的移动通信号码进行了验证，因此能够避免由于移动通信终端的转移呼叫而造 成的安全性问题。
步骤S214，对支付信息进行风险信息校验，如果校验通过，则进入步骤S216。
步骤S216，电话支付系统通过IVR平台呼叫移动通信号码，获取用户输入的支付 密码，并将支付密码和支付信息发送至银行系统。
如上所述，具体的，移动通信号码对应的移动终端会收到呼叫，持有该移动终端的 用户接听后，移动终端与IVR平台建立起连接，移动终端会收到IVR平台通过语音信道下发 的语音提示，用户根据语音提示输入支付密码，移动终端将支付密码上传到电话支付系统， 电话支付系统将支付密码和支付信息组织成交易报文，并发送到银行系统。
步骤S218，银行系统对支付密码和支付信息进行验证，验证通过则进行支付。
具体的，银行系统验证支付密码是否正确以及验证支付信息是否与预先存储的开 户信息相符，若是，则验证通过，直接扣款，否则，通知电话支付系统，由IVR平台下发语音 提示给移动终端，提示用户密码输入不正确或支付信息不对。
在一个实施例中，上述对支付信息进行风险信息校验的步骤包括获取交易信息 中的商户额度，检测该商户额度是否大于设定阈值，若是，则校验不通过，否则校验通过。商 户额度是订单的交易额度，如一次交易的数量、金额等，超过设定阈值的数量、金额的交易 认为有风险的(如可能银行卡被盗用等)，则校验不通过。这样，可以有效提高支付的安全 性。
在本实施例中或另一个实施例中，对支付信息进行风险信息交易的步骤还包括 根据支付信息判断用户是否为黑名单用户，若是，则校验不通过，否则校验通过。如果用户 交易存在不良记录，例如支付信息验证失败2次则认为该用户非法，则将用户身份信息加 入到黑名单中。对于黑名单中的用户，在进行风险信息校验时，校验不通过，即非法用户不 能完成支付。这样，避免了非法用户再次进行交易，进一步提高了支付的安全性。
在一个实施例中，对支付信息进行风险校验的步骤还包括电话支付系统将支付 信息发送至银行系统，银行系统判断支付信息是否与预先存储的开户信息一致，若是，则校 验通过，否则校验不通过。
如图3所示，在一个实施例中，步骤S214中，对支付信息进行风险信息校验的过程 具体如下
步骤S302，根据支付信息判断用户是否为黑名单用户，若是，则流程结束，否则进 入步骤S304。
步骤S304，根据支付信息判断商户额度是否大于设定阈值，若是，则流程结束，否 则进入步骤S306。
步骤S306，判断是否存在已校验的支付信息，若是，则进入步骤S216，进入后续流 程，否则，进入步骤S308。
步骤S308，提示用户填写支付信息。
步骤S310，对用户填写的支付信息进行风险信息校验。
步骤S310中对支付信息进行风险信息校验的过程如上所示，在此不再赘述。
在一个实施例中，在步骤S218中支付密码验证通过，还可再对支付信息进行风险 信息校验，例如，根据支付信息判断商户额度是否大于设定阈值等。由于在支付密码验证通 过后，用户可能会更改支付信息，通过再次进行风险信息校验，能进一步提高安全性。
如图4所示，在一个实施例中，一种交易支付系统，包括支付终端10、电话支付系 统20和银行系统30，其中
支付终端10用于获取用户的支付信息，该支付信息包括通信号码，支付终端10还 用于将支付信息提交到电话支付系统20。
电话支付系统20，包括IVR平台202，IVR平台202用于呼叫通信号码，获取用户 输入的支付密码，并将支付密码和支付信息发送到银行系统30。
银行系统30用于对支付密码和支付信息进行验证，验证通过则进行支付。
在一个实施例中，用户通过支付终端10提交订单，订单数据包括用户信息、商户 信息、购买的商品信息等。其中，用户信息包括用户注册帐号、用户名称、收货地址、联系方 式等；商户信息即商家信息，例如店铺名称、地址、联系方式等；购买的商品信息包括购买 数量、购买价格、应付金额等。
通过支付终端提交订单并确认支付后，获取用户的支付信息。用户的支付信息包 括银行卡号、用户身份信息、订单相关信息，其中用户身份信息包括但不限于身份证信息 (包括用户姓名、身份证号码等)、支付密码、通信号码(可以是移动通信号码，也可以是固 定通信号码)、即时通信号码、联系地址等，订单相关信息包括应付金额等。在一个实施例 中，在用户提交订单数据后，可弹出提示框提示用户填写支付信息。具体的，支付终端10通 过互联网信道或即时通信信道将支付信息提交到电话支付系统20。
在一个实施例中，通过IVR平台202呼叫支付信息中的通信号码，该通信号码对应 的通信终端会收到呼叫，持有该通信终端的用户接听后，通信终端与IVR平台202建立连 接，通信终端会收到IVR平台202通过语音信道下发的语音提示，用户根据语音提示输入支 付密码，通信终端将支付密码上传到电话支付系统20，由电话支付系统20将支付密码和支 付信息组织成交易报文，并发送至银行系统30。
在银行系统30预先存储了用户的开户信息，包括用户的身份证信息、开通的银行 卡卡号、联系地址、移动通信号码、支付密码等。银行系统30在收到支付密码和支付信息 后，验证用户输入的支付密码是否正确，并验证支付信息是否与用户的开户信息相符，如果 正确，则验证通过，则直接扣款，完成支付。
在一个实施例中，电话支付系统20还包括核心支付系统(图中未示出)，用于管理 订单等。当银行系统30完成支付后，通知核心支付系统，由核心支付系统修改订单状态，并 将该订单状态返回到支付终端10。
在另一个实施例中，如图5所示，电话支付系统20还包括短信平台204，短信平台 204用于通过短信向支付信息中的移动通信号码对应的移动终端下发短信验证码，接收该 移动终端返回的回复验证码，判断回复验证码是否与短信验证码一致，若是，则验证通过， 否则验证不通过。
在一个实施例中，短信平台204还用于获取返回回复验证码的移动终端的移动通信号码，将该移动通信号码发送至银行系统30。本实施例中，银行系统30还用于验证获取 的移动通信号码是否与预先存储的开户信息中的移动通信号码一致，若是，则验证通过，否 则验证不通过。
在一个实施例中，如图5所示，电话支付系统20还包括用于回复验证码验证通过 和/或返回回复验证码的移动终端的移动通信号码验证通过之后，对支付信息进行风险信 息校验的风险控制系统206。
在一个实施例中，风险控制系统206还用于在电话支付系统20通过IVR平台202 呼叫通信号码的步骤之前对支付信息进行风险信息校验。在本实施例或另一个实施例中， 风险控制系统206还用于在支付密码验证通过之后对支付信息进行风险信息校验。
在一个实施例中，风险控制系统206用于获取支付信息中的商户额度，检测商户 额度是否大于设定阈值，若是，则校验不通过，否则校验通过。在本实施例或另一实施例中， 风险控制系统208还用于根据支付信息判断用户是否为黑名单用户，若是，则校验不通过， 否则校验通过。
在一个实施例中，风险控制系统206还用于将支付信息发送到银行系统30。本实 施例中，银行系统30还用于判断支付信息是否与预先存储的开户信息一致，若是，则校验 通过，否则校验不通过。
上述交易支付方法和系统中，通过使用移动终端、互联网、IVR平台、短信平台等多 个通信通道采集用户的支付信息，大大增加了用户的支付信息被全部盗取的难度，因此增 加了非面对面支付的安全性。
上述交易支付方法和系统中，通过短信验证确认移动终端持有人，通过银行系统 确认银行卡持有人的身份、移动通信号码等信息，通过多个通信通道来验证用户身份信息， 确保了安全支付。
以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并 不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员 来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保 护范围。因此，本发明专利的保护范围应以所附权利要求为准。
权利要求
1.一种交易支付方法，包括以下步骤 支付终端获取用户的支付信息，所述支付信息包括通信号码，所述支付终端将所述支付信息提交到电话支付系统； 所述电话支付系统通过互动式语音应答平台呼叫所述通信号码，获取用户输入的支付密码，并将所述支付密码和支付信息发送至银行系统； 所述银行系统对所述支付密码和支付信息进行验证，验证通过则进行支付。
2.根据权利要求1所述的交易支付方法，其特征在于，所述通信号码为移动通信号码；在所述电话支付系统通过互动式语音应答平台呼叫所述移动通信号码的步骤之前，还包括 通过短信平台向所述移动通信号码对应的移动终端下发短信验证码； 接收所述移动终端返回的回复验证码； 判断所述回复验证码是否与所述短信验证码一致，若是，则验证通过，否则验证不通过。
3.根据权利要求2所述的交易支付方法，其特征在于，在所述电话支付系统通过互动式语音应答平台呼叫所述移动通信号码的步骤之前，还包括 获取返回回复验证码的移动终端的移动通信号码； 通过银行系统验证所述获取的移动通信号码是否与预先存储的开户信息中的移动通信号码一致，若是，则验证通过，否则验证不通过。
4.根据权利要求3所述的交易支付方法，其特征在于，在回复验证码验证通过的步骤和/或返回回复验证码的移动终端的移动通信号码验证通过的步骤之后，还包括 对所述支付信息进行风险信息校验。
5.根据权利要求1所述的交易支付方法，其特征在于，在所述电话支付系统通过互动式语音应答平台呼叫所述通信号码的步骤之前，和/或在所述支付密码验证通过之后，还包括 对所述支付信息进行风险信息校验。
6.根据权利要求4或5所述的交易支付方法，其特征在于，所述支付终端对所述支付信息进行风险信息校验的步骤包括 获取所述支付信息中的商户额度，检测所述商户额度是否大于设定阈值，若是，则校验不通过，否则校验通过；和/或 根据所述支付信息判断用户是否为黑名单用户，若是，则校验不通过，否则校验通过。
7.根据权利要求6所述的交易支付方法，其特征在于，所述对所述支付信息进行风险信息校验的步骤还包括 所述电话支付系统将所述支付信息发送至银行系统； 所述银行系统判断所述支付信息是否与预先存储的开户信息一致，若是，则校验通过，否则校验不通过。
8.一种交易支付系统，其特征在于，所述系统包括 支付终端，用于获取用户的支付信息，所述支付信息包括通信号码；所述支付终端还用于将所述支付信息提交到电话支付系统； 电话支付系统，包括互动式语音应答平台，所述互动式语音应答平台用于呼叫所述通信号码，获取用户输入的支付密码，并将所述支付密码和支付信息发送至银行系统； 银行系统，用于对所述支付密码和支付信息进行验证，验证通过则进行支付。
9.根据权利要求8所述的交易支付系统，其特征在于，所述通信号码为移动通信号码；所述电话支付系统还包括短信平台，用于通过短信向所述移动通信号码对应的移动终端下发短信验证码，接收所述移动终端返回的回复验证码，判断所述回复验证码是否与所述短信验证码一致，若是，则验证通过，否则验证不通过。
10.根据权利要求9所述的交易支付系统，其特征在于，所述短信平台还用于获取返回回复验证码的移动终端的移动通信号码，将所述移动通信号码发送至所述银行系统； 所述银行系统还用于验证所述获取的移动通信号码是否与预先存储的开户信息中的移动通信号码一致，若是，则验证通过，否则验证不通过。
11.根据权利要求10所述的交易支付系统，其特征在于，所述电话支付系统还包括用于在回复验证码验证通过和/或返回回复验证码的移动终端的移动通信号码验证通过之后，对所述支付信息进行风险信息校验的风险控制系统。
12.根据权利要求11所述的交易支付系统，其特征在于，所述风险控制系统还用于在所述电话支付系统通过互动式语音应答平台呼叫所述通信号码的步骤之前，和/或在所述支付密码验证通过之后对所述支付信息进行风险信息校验。
13.根据权利要求11或12所述的交易支付系统，其特征在于，所述风险控制系统用于获取所述支付信息中的商户额度，检测所述商户额度是否大于设定阈值，若是，则校验不通过，否则校验通过；和/或 所述风险控制系统用于根据所述支付信息判断用户是否为黑名单用户，若是，则校验不通过，否则校验通过。
14.根据权利要求13所述的交易支付系统，其特征在于，所述风险控制系统还用于将所述支付信息发送至所述银行系统； 所述银行系统还用于判断所述支付信息是否与预先存储的开户信息一致，若是，则校验通过，否则校验不通过。
全文摘要
一种交易支付方法，包括以下步骤支付终端获取用户的支付信息，所述支付信息包括通信号码，所述支付终端将所述支付信息提交到电话支付系统；所述电话支付系统通过互动式语音应答平台呼叫所述通信号码，获取用户输入的支付密码，并将所述支付密码和支付信息发送至银行系统；所述银行系统对所述支付密码和支付信息进行验证，验证通过则进行支付。采用上述交易支付方法，能够提高支付的安全性。此外，还提供了一种交易支付系统。
文档编号G06Q20/40GK103020820SQ20111028012
公开日2013年4月3日 申请日期2011年9月20日 优先权日2011年9月20日
发明者向陶, 廖少波, 刘铁华, 赵大鹏, 冯云霞, 成敏 申请人:深圳市财付通科技有限公司