CN101730023A - 短信支付的方法和*** - Google Patents

Abstract

本发明提出一种短信支付的方法，包括以下步骤：接收用户发送的支付短信，所述支付短信包括项目代码、支付指示、支付密码、支付账号和支付金额，其中所述用户与被支付方及银行签有支付服务协议；根据所述项目代码选择符号业务需要的支付短信进行处理；根据支付的手机号校验用户的签约信息，如果所述用户已经签约，则将所述支付短信发送给支付平台；所述支付平台根据所述支付短信进行支付。用户能够通过本发明的方法和***使用手机短信进行支付，使得用户可以随时随地的进行支付，并且本发明实现安全、便捷、高效。

Description

短信支付的方法和***

技术领域

本发明涉及通信技术领域，特别涉及一种短信支付的方法和***。

背景技术

电子商务(Electronic Commerce)是在Internet开放的网络环境下，基于浏览器/服务器应用方式，实现消费者的网上购物、商户之间的网上交易和在线电子支付的一种新型的商业运营模式。电子商务是Internet***式发展的直接产物，是网络技术应用的全新发展方向。Internet本身所具有的开放性、全球性、低成本、高效率的特点，也成为电子商务的内在特征，并使得电子商务大大超越了作为一种新的贸易形式所具有的价值，它不仅会改变企业本身的生产、经营、管理活动，而且将影响到整个社会的经济运行与结构。电子商务将传统的商务流程电子化、数字化，一方面以电子流代替了实物流，可以大量减少人力、物力，降低了成本；另一方面突破了时间和空间的限制，使得交易活动可以在任何时间、任何地点进行，从而大大提高了效率。另外，电子商务所具有的开放性和全球性的特点，为企业创造了更多的贸易机会。

因此电子商务成为我国今后发展的重要内容，然而，电子支付作为电子商务的关键一环，由于电子支付手段比较单一，目前较为普遍应用的网络支付，如支付宝等还是对用户不是非常方便，用户不能随时随地的进行支付，因此电子支付是制约电子商务发展的瓶颈。随着电子商务的不断发展，亟需一种安全、便捷、高效的支付手段，不仅可为用户提供更多的选择，还可使用户随时随地的进行支付。

发明内容

本发明的目的旨在至少解决上述技术缺陷之一，特别是解决现有技术中支付手段单一，用户不能随时随地支付的缺陷。

为达到上述目的，本发明一方面提出一种短信支付的方法，包括以下步骤：接收用户发送的支付短信，所述支付短信包括项目代码、支付指示、支付密码、支付账号和支付金额，其中所述用户与被支付方及银行签有支付服务协议；根据所述项目代码选择符号业务需要的支付短信进行处理；根据支付的手机号校验用户的签约信息，如果所述用户已经签约，则将所述支付短信发送给支付平台；所述支付平台根据所述支付短信进行支付。

在本发明的一个实施例中，所述接收用户发送的支付短信包括：运营商短信网关接收用户发送的支付短信，所述支付短信包括项目代码、支付指示、支付密码、支付账号和支付金额；所述运营商短信网关将接收到的支付短信发送给银行短信网关，所述银行网关将支付短信***至本地子***数据库的上行信息表。

在本发明的一个实施例中，所述根据项目代码选择符号业务需要的支付短信进行处理包括：前置服务器定时扫描所述本地子***数据库的上行信息表，根据项目代码获取所述支付短信，并发送给多渠道业务整合平台。

在本发明的一个实施例中，根据支付的手机号校验用户的签约信息，如果所述用户已经签约，则将所述支付短信发送给支付平台包括：所述多渠道业务整合平台根据支付的手机号查询本地签约信息，根据本地签约信息判断所述用户是否签约；如果判断所述用户已经签约，则将所述支付短信发送给支付平台。

在本发明的一个实施例中，所述支付平台根据所述支付短信进行支付包括：所述支付平台判断被支付方是否为所述银行的行内账号；如果判断被支付方为所述银行的行内账号，则所述支付平台向所述银行的主机发送支付请求，由所述银行主机进行支付；如果判断被支付方不为所述银行的行内账号，则所述支付平台将支付请求发送给分行平台，由所述分行平台进行支付。

在本发明的一个实施例中，由所述分行平台进行支付包括：由所述分行通过人行集中支付***或银联支付网络进行支付。

在本发明的一个实施例中，还包括：在完成支付后，所述支付平台接收所述银行主机或分行平台返回的支付结果；所述支付平台通过短信将支付结果发送给所述用户。

在本发明的一个实施例中，还包括：所述运营商短信网关和所述银行短信网关有相互双向绑定的IP地址和端口，且所述运营商短信网关和所述银行短信网关之间用约定的报文通信。

本发明还提出了一种短信支付的***，包括银行短信网关、前置服务器、多渠道业务整合平台和支付平台，所述银行短信网关，用于接收用户发送的支付短信，所述支付短信包括项目代码、支付指示、支付密码、支付账号和支付金额，并将支付短信***至本地子***数据库的上行信息表，其中所述用户与被支付方及银行签有支付服务协议；所述前置服务器，用于定时扫描所述本地子***数据库的上行信息表，根据项目代码获取所述支付短信，并发送给多渠道业务整合平台；所述多渠道业务整合平台，用于根据支付的手机号查询本地签约信息，根据本地签约信息判断所述用户是否签约，如果判断所述用户已经签约，则将所述支付短信发送给支付平台；所述支付平台，用于根据所述支付短信进行支付。

在本发明的一个实施例中，还包括银行主机和分行平台，所述支付平台，用于判断被支付方是否为所述银行的行内账号，如果判断被支付方为所述银行的行内账号，则所述支付平台向所述银行的主机发送支付请求，由所述银行主机进行支付，如果判断被支付方不为所述银行的行内账号，则所述支付平台将支付请求发送给分行平台，由所述分行平台进行支付。

在本发明的一个实施例中，所述分行通过人行集中支付***或银联支付网络进行支付。

在本发明的一个实施例中，所述支付平台还用于在接收所述银行主机或分行平台返回的支付结果之后，通过短信将支付结果发送给所述用户。

在本发明的一个实施例中，所述银行短信网关和运营商短信网关有相互双向绑定的IP地址和端口，且所述运营商短信网关和所述银行短信网关之间用约定的报文通信。

本发明还提出另一种短信支付的方法，包括以下步骤：支付平台接收收款人发送的请求付款人支付的消息，所述消息包括付款人清单和扣款指令；所述支付平台通过银行网关和运营商网关向所述付款人发送扣款短信；所述支付平台通过银行网关和运营商网关接收所述付款人返回的付款指令，并根据所述付款指令向所述收款人进行支付。

作为本发明的一个实施例，所述付款人返回的付款指令包括以下之一：确认付款指令、确认收货指令。

作为本发明的一个实施例，所述支付平台根据所述付款指令进行支付包括：所述支付平台判断被支付方是否为所述银行的行内账号；如果判断被支付方为所述银行的行内账号，则所述支付平台向所述银行的主机发送支付请求，由所述银行主机进行支付；如果判断被支付方不为所述银行的行内账号，则所述支付平台将支付请求发送给分行平台，由所述分行平台进行支付。

作为本发明的一个实施例，由所述分行平台进行支付包括：由所述分行通过人行集中支付***或银联支付网络进行支付。

作为本发明的一个实施例，还包括：所述收款人与人行与签约并录入经销商信息。

作为本发明的一个实施例，还包括：在完成支付后，所述支付平台接收所述银行主机或分行平台返回的支付结果；所述支付平台通过短信将支付结果发送给所述付款人。

作为本发明的一个实施例，还包括：所述运营商短信网关和所述银行短信网关有相互双向绑定的IP地址和端口，且所述运营商短信网关和所述银行短信网关之间用约定的报文通信。

用户能够通过本发明的方法和***使用手机短信进行支付，使得用户可以随时随地的进行支付，并且本发明实现安全、便捷、高效。

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

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本发明实施例的一种短信支付的方法流程图；

图2为本发明的实施例的一种利用人行集中支付***进行短信支付的示意图；

图3为本发明的实施例的另一种利用人行集中支付***进行短信支付的示意图；

图4为本发明实施例的短信支付的***结构图；

图5为本发明实施例的另一种短信支付的方法流程图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

如图1所示，为本发明实施例的短信支付的方法流程图，该方法包括以下步骤：

步骤S101，用户向运营商网关发送支付短信，该支付短信包括项目代码、支付指示、支付密码、支付账号和支付金额等，其中，用户与被支付方及银行签有支付服务协议。在本发明的实施例中，被支付人、支付人和银行需要签署支付服务协议，且由客户亲自办理并设置密码，并且在向协议指定的手机号码发送支付密码。在本发明的另一个实施例中，为了提高业务的扩展性，支付人在签约时可提供3组账户，并且每组账号都有不同的初始密码，这样用户在支付时可以从这3组账户中选择一个账户进行支付。其中，项目代码是确定不同收款人收款业务的唯一标识，可由银行总行统计进行分配和管理，在分行上报业务后，总行审批发放项目代码。另外，在签约时可要求用户设置最大支付金额，如果不做设置可认为为无限制。

在本发明的一个实施例中，本发明提出了一种短信格式：项目代码+功能码+支付账号+支付密码+支付金额。例如，短信格式为PMKO#ZF#1#123456#100到9555801，代表通过短信从账户1中支付100元到代码为PMKO的收款方，支付密码为123456，并将该短信发送至与银行对应的长码(例如可为9555801)。

在本发明的实施例中可通过两种方式触发该步骤，一种是用户的主动支付，另一种是需要用户确认付款。在本发明的一个实施例中，收款人向支付人发送短信，***自动在下行短信(即发给支付人的短信)的号码中加入项目标识码，及下行短信号码规则为9555801+项目标识码，支付人直接回复该短信进行支付。或者，在本发明的另一个实施例中，支付人在收到需要其支付的短信后，支付人主动编辑项目标识码进行支付。

步骤S102，运营商短信网关将接收到的支付短信发送给银行短信网关，银行网关将支付短信***至本地子***数据库的上行信息表。在本发明的实施例中，运营商短信网关和银行短信网关有相互双向绑定的IP地址和端口，且运营商短信网关和所述银行短信网关之间用约定的报文通信。具体地，采用Soket方式，运营商开放一个网关服务器的IP地址和端口，银行网关可按约定好的报文格式向运营商网关发送下行信息，同样，银行也需要提供一台服务器的IP地址和端口，运营商网关根据长号码把报文转发给银行网关。另外，双向的IP地址都是绑定的，银行只接收运营商提供的IP地址发送过来的上行信息，运营商也只接收中信提供的IP地址发送过来的下行信息。

步骤S103，前置服务器定时扫描所述本地子***数据库的上行信息表，根据项目代码获取所述支付短信，并发送给多渠道业务整合平台(BP)。

步骤S104，多渠道业务整合平台根据支付的手机号查询本地签约信息，根据本地签约信息判断该用户是否签约；如果判断所述用户已经签约，则将支付短信发送给支付平台(也可称为总行平台或交换平台)。

步骤S105，支付平台判断目的账号是否为银行的行内账号；如果判断目的账号为银行的行内账号，则支付平台向银行的主机发送支付请求，由银行主机进行支付；如果判断目的账号不为银行的行内账号，则支付平台将支付请求发送给分行平台，由分行平台进行支付。在本发明的一个实施例中，由分行通过人行集中支付***或银联支付网络进行支付，当然人行集中支付***等仅是一个例子，任何能够提供跨行转账的支付***都可应用在本发明中。为了对本发明有更清楚的理解，以下对人行集中支付***进行简单介绍。

人行集中支付***已于2008年上线试运行，业务范围已涵盖了珠三角(除深圳)及省内大部分县市地区，开通业务的银行包括四大行在内的17家银行。在开通集中代收付业务的地区，收、付款单位只需在任何一家银行开户，即可对所在地区内任何一家银行开户的企事业单位及个人扣收或支付款项。为了充分利用该人行集中支付***，本发明提出了利用该人行集中支付***的两种模式：

模式一，如图2所示，为本发明的实施例的一种利用人行集中支付***进行短信支付的示意图，包括以下步骤：

步骤S201，付款方与收款方有贸易关系，在该实施例中为厂家与经销商建立供销关系，当然在该实施例中还可建立其他任何类型的贸易关系。

步骤S202，厂家与人行签约并录入经销商信息，确定收款账户为中信银行。

步骤S203，厂家与人行签约后，与中信广州分行签约。

步骤S204，该厂家的各个经销商通过短信箱中信银行发送支付指令。

步骤S205，中信银行将扣款指令发送给人行。

步骤S206，人行将款项打入厂家的中信账户。

模式二，如图3所示，为本发明的实施例的另一种利用人行集中支付***进行短信支付的示意图，包括以下步骤：

步骤S301，收款人与付款人有资金往来。

步骤S302，收款人与人行签约并录入付款人信息，确定收款账户为中信银行。

步骤S303，收款人与人行签约后，将付款人清单交中信广州分行签约，并且收款人向中信银行发送批量扣款指令。

步骤S304，中信银行向各个付款人发送扣款短信，各个付款人回复Y/N进行付款。

步骤S305，如果付款人回复Y，则中信银行将扣款指令发送给人行。

步骤S306，人行将款项打入收款人的中信账户。

以上实施例为采用人行集中支付***的具体实施例，当然也可采用其他***进行支付。

步骤S106，在完成支付后，支付平台接收银行主机或分行平台返回的支付结果，支付平台通过短信将支付结果发送给用户。具体地，支付平台将结果转发给多渠道业务整合平台(BP)，多渠道业务整合平台解析交易结果将交易结果反馈给前置服务器，前置服务器按照约定好的格式将交易结果放入指定地点，银行短信网关读取该结果并发送给运营商短信网关，通过运营商网关将下行信息发送给用户。

在上述实施例中，结合具体的***结构对通过短信支付的方式进行了描述，但是还可通过该***进行密码修改，查询交易明细等，其过程与支付过程类似，在此不再赘述。

如图4所示，为本发明实施例的短信支付的***结构图，该***包括银行短信网关100、前置服务器200、多渠道业务整合平台(BP)300和支付平台400。银行短信网关100，用于接收运营商网关500发送的用户发送的支付短信，该支付短信包括项目代码、支付指示、支付密码、支付账号、目的账号和支付金额，并将支付短信***至本地子***数据库的上行信息表。前置服务器200用于定时扫描本地子***数据库的上行信息表，根据项目代码获取所述支付短信，并发送给多渠道业务整合平台300。多渠道业务整合平台300用于根据支付的手机号查询本地签约信息(如从***数据库(DB)查询)，根据本地签约信息判断所述用户是否签约，如果判断所述用户已经签约，则将支付短信发送给支付平台400。支付平台400用于根据支付短信进行支付。

在本发明的一个实施例中，该***还包括银行主机600和分行平台700。支付平台400用于判断目的账号是否为银行的行内账号，如果判断目的账号为银行的行内账号，则支付平台400向银行主机600发送支付请求，由银行主机600进行支付，如果判断目的账号不为银行的行内账号，则支付平台400将支付请求发送给分行平台700，由分行平台700进行支付。在本发明的一个实施例中，分行通过人行集中支付***或银联支付网络进行支付，即通过分行NCR进行支付。

在本发明的一个实施例中，支付平台400还用于在接收银行主机600或分行平台700返回的支付结果之后，通过短信将支付结果发送给用户。

在本发明的一个实施例中，银行短信网关100和运营商短信网关500有相互双向绑定的IP地址和端口，且运营商短信网关500和银行短信网关100之间用约定的报文通信。

如图5所示为本发明实施例的另一种短信支付的方法流程图，该方法包括以下步骤：

步骤S510，支付平台400接收收款人发送的请求付款人支付的消息，所述消息包括付款人清单和扣款指令。

步骤S520，支付平台400通过银行短信网关100和运营商短信网关500向付款人发送扣款短信。

步骤S530，支付平台400通过银行短信网关100和运营商短信网关500接收付款人返回的付款指令，并根据付款指令向收款人进行支付。

付款人返回的付款指令可以为确认付款指令如#1(其中，#为确认付款标志，1为付款客户的帐号)，也可以为确认收货指令如*。支付平台400接收到付款指令后，首先判断被支付方是否为银行的行内账号：如果判断被支付方为银行的行内账号，则支付平台400向银行主机600发送支付请求，由银行主机600进行支付；如果判断被支付方不为银行的行内账号，则支付平台400将支付请求发送给分行平台700，由分行平台700通过人行集中支付***或银联支付网络进行支付。完成支付后，支付平台400接收银行主机600或分行平台700返回的支付结果，并将支付结果通过短信发送给付款人。

用户能够通过本发明的方法和***使用手机短信进行支付，使得用户可以随时随地的进行支付，并且本发明实现安全、便捷、高效。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同限定。

Claims (20)

1.一种短信支付的方法，其特征在于，包括以下步骤：

接收用户发送的支付短信，所述支付短信包括项目代码、支付指示、支付密码、支付账号和支付金额，其中所述用户与被支付方及银行签有支付服务协议；

根据所述项目代码选择符号业务需要的支付短信进行处理；

根据支付的手机号校验用户的签约信息，如果所述用户已经签约，则将所述支付短信发送给支付平台；

所述支付平台根据所述支付短信进行支付。

2.如权利要求1所述的短信支付的方法，其特征在于，所述接收用户发送的支付短信包括：

运营商短信网关接收用户发送的支付短信，所述支付短信包括项目代码、支付指示、支付密码、支付账号和支付金额；

所述运营商短信网关将接收到的支付短信发送给银行短信网关，所述银行网关将支付短信***至本地子***数据库的上行信息表。

3.如权利要求2所述的短信支付的方法，其特征在于，所述根据项目代码选择符号业务需要的支付短信进行处理包括：

前置服务器定时扫描所述本地子***数据库的上行信息表，根据项目代码获取所述支付短信，并发送给多渠道业务整合平台。

4.如权利要求3所述的短信支付的方法，其特征在于，根据支付的手机号校验用户的签约信息，如果所述用户已经签约，则将所述支付短信发送给支付平台包括：

所述多渠道业务整合平台根据支付的手机号查询本地签约信息，根据本地签约信息判断所述用户是否签约；

如果判断所述用户已经签约，则将所述支付短信发送给支付平台。

5.如权利要求4所述的短信支付的方法，其特征在于，所述支付平台根据所述支付短信进行支付包括：

所述支付平台判断被支付方是否为所述银行的行内账号；

如果判断被支付方为所述银行的行内账号，则所述支付平台向所述银行的主机发送支付请求，由所述银行主机进行支付；

如果判断被支付方不为所述银行的行内账号，则所述支付平台将支付请求发送给分行平台，由所述分行平台进行支付。

6.如权利要求5所述的短信支付的方法，其特征在于，由所述分行平台进行支付包括：

由所述分行通过人行集中支付***或银联支付网络进行支付。

7.如权利要求5所述的短信支付的方法，其特征在于，还包括：

在完成支付后，所述支付平台接收所述银行主机或分行平台返回的支付结果；

所述支付平台通过短信将支付结果发送给所述用户。

8.如权利要求2所述的短信支付的方法，其特征在于，还包括：

所述运营商短信网关和所述银行短信网关有相互双向绑定的IP地址和端口，且所述运营商短信网关和所述银行短信网关之间用约定的报文通信。

9.一种短信支付的***，其特征在于，包括银行短信网关、前置服务器、多渠道业务整合平台和支付平台，

所述银行短信网关，用于接收用户发送的支付短信，所述支付短信包括项目代码、支付指示、支付密码、支付账号和支付金额，并将支付短信***至本地子***数据库的上行信息表，其中所述用户与被支付方及银行签有支付服务协议；

所述前置服务器，用于定时扫描所述本地子***数据库的上行信息表，根据项目代码获取所述支付短信，并发送给多渠道业务整合平台；

所述多渠道业务整合平台，用于根据支付的手机号查询本地签约信息，根据本地签约信息判断所述用户是否签约，如果判断所述用户已经签约，则将所述支付短信发送给支付平台；

所述支付平台，用于根据所述支付短信进行支付。

10.如权利要求9所述的短信支付的***，其特征在于，还包括银行主机和分行平台，

所述支付平台，用于判断被支付方是否为所述银行的行内账号，如果判断被支付方为所述银行的行内账号，则所述支付平台向所述银行的主机发送支付请求，由所述银行主机进行支付，如果判断被支付方不为所述银行的行内账号，则所述支付平台将支付请求发送给分行平台，由所述分行平台进行支付。

11.如权利要求10所述的短信支付的***，其特征在于，所述分行通过人行集中支付***或银联支付网络进行支付。

12.如权利要求10所述的短信支付的***，其特征在于，所述支付平台还用于在接收所述银行主机或分行平台返回的支付结果之后，通过短信将支付结果发送给所述用户。

13.如权利要求9所述的短信支付的***，其特征在于，所述银行短信网关和运营商短信网关有相互双向绑定的IP地址和端口，且所述运营商短信网关和所述银行短信网关之间用约定的报文通信。

14.一种短信支付的方法，其特征在于，包括以下步骤：

支付平台接收收款人发送的请求付款人支付的消息，所述消息包括付款人清单和扣款指令；

所述支付平台通过银行短信网关和运营商短信网关向所述付款人发送扣款短信；

所述支付平台通过银行短信网关和运营商短信网关接收所述付款人返回的付款指令，并根据所述付款指令向所述收款人进行支付。

15.如权利要求14所述的短信支付的方法，其特征在于，所述付款人返回的付款指令包括以下之一：确认付款指令、确认收货指令。

16.如权利要求14所述的短信支付的方法，其特征在于，所述支付平台根据所述付款指令进行支付包括：

所述支付平台判断被支付方是否为所述银行的行内账号；

如果判断被支付方为所述银行的行内账号，则所述支付平台向所述银行的主机发送支付请求，由所述银行主机进行支付；

如果判断被支付方不为所述银行的行内账号，则所述支付平台将支付请求发送给分行平台，由所述分行平台进行支付。

17.如权利要求16所述的短信支付的方法，其特征在于，由所述分行平台进行支付包括：

由所述分行通过人行集中支付***或银联支付网络进行支付。

18.如权利要求17所述的短信支付的方法，其特征在于，还包括：

所述收款人与人行与签约并录入经销商信息。

19.如权利要求16所述的短信支付的方法，其特征在于，还包括：

在完成支付后，所述支付平台接收所述银行主机或分行平台返回的支付结果；

所述支付平台通过短信将支付结果发送给所述付款人。

20.如权利要求16所述的短信支付的方法，其特征在于，还包括：

所述运营商短信网关和所述银行短信网关有相互双向绑定的IP地址和端口，且所述运营商短信网关和所述银行短信网关之间用约定的报文通信。

Images