专利名称：基于客户端的支付方法、系统和支付客户端的制作方法
技术领域：
本发明涉及网络技术，特别涉及基于客户端的支付方法、系统和支付客户端。
背景技术：
目前的在线支付都是基于web的支付，其在实现时一般需要执行图1所示的流程:参见图1，图1为现有基于web支付的实现流程图。如图1所示，该流程可包括以下步骤:步骤101，在用户每次选择支付时，需要从用户当前的第三方应用页面跳转到支付渠道商提供的web支付页面。步骤102，用户在web支付页面进行支付操作。步骤103，在用户完成支付操作后，再从该web支付页面跳转至用户进行支付操作之前的第三方应用页面，并通知用户支付结果。从图1所示的流程可以看出，在用户每次进行支付时，需要从用户当前的第三方应用页面跳转到支付渠道商提供的web支付页面，即进行不同web页面的跳转，这会降低支付操作的效率，并且，在出现网络问题或者其他原因时会导致web支付页面不能正常跳转，进而不能实现在线支付。
发明内容
本发明提供了基于客户端的支付方法、系统和支付客户端，实现在客户端完成支付，无需不同web页面的跳转。本发明提供的技术方案包括:一种基于客户端的支付方法，包括:第三方应用平台接收用户在第三方应用页面发起的支付触发，并向支付平台发送支付请求；第三方应用平台接收支付平台针对所述支付请求返回的支付页面标识，并触使支付客户端调出所述支付页面标识对应的支付页面，以使所述用户在所述支付页面进行支付操作。一种基于客户端的支付方法，该方法包括:支付客户端在用户针对第三方应用进行支付时，在该第三方应用的页面向第三方应用平台发起支付触发，以使第三方应用平台向支付平台发送支付请求；支付客户端接收第三方应用平台的触发，所述触发携带了所述第三方应用平台接收的支付平台针对所述支付请求返回的支付页面标识，根据所述触发调出所述支付页面标识对应的支付页面，以使所述用户在所述支付页面进行支付操作。一种支付客户端，包括:支付触发单元，用于在用户针对第三方应用进行支付时，在该第三方应用的页面向第三方应用平台发起支付触发，以使第三方应用平台向支付平台发送支付请求；调用单元，用于接收第三方应用平台的触发，所述触发携带了所述第三方应用平台接收的支付平台针对所述支付请求返回的支付页面标识，根据所述触发调出所述支付页面标识对应的支付页面，以使所述用户在所述支付页面进行支付操作。一种基于客户端的支付系统，包括:第三方应用平台、支付平台和如上所述的支付客户端；其中，所述第三方应用平台包括:支付请求发送单元和处理单元；所述支付请求发送单元，用于接收用户在第三方应用页面发起的支付触发，并向支付平台发送支付请求；所述处理单元，用于接收支付平台针对所述支付请求返回的支付页面标识，并触使支付客户端调出所述支付页面标识对应的支付页面；所述支付平台，用于向所述第三方应用平台返回针对所述支付请求的支付页面标识。由以上技术方案可以看出，本发明中，当用户在第三方应用页面发起支付触发时，第三方应用平台接收用户在第三方应用页面发起的支付触发，并向支付平台发送支付请求，以及第三方应用平台接收支付平台针对所述支付请求返回的支付页面标识，并触使支付客户端调出所述支付页面标识对应的支付页面，以使所述用户在所述支付页面进行支付操作。即本发明中，由支付客户端在本地提供支付页面，其相当于支付客户端的一个接口，而不像现有技术那样需要支付渠道商提供web的支付页面，相比于现有技术，本发明实现了在客户端完成支付的目的，不需要执行不同web页面的中转。
图1为现有基于web支付的实现流程图；图2为本发明实施例提供的第一实施例流程图；图3为本发明实施例提供的第二实施例流程图；图4为本发明实施例提供的第三实施例流程图；图5为本发明实施例提供的第三实施例示意图；图6为本发明实施例提供的第一系统结构图；图7为本发明实施例提供的第二系统结构图；图8为本发明实施例提供的第三系统结构图。
具体实施例方式为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。为了避免现有基于web支付方式的缺陷,本发明结合客户端(Client)技术和web技术的优点，提出了基于客户端的支付方法，该支付方法采用非主机(hosting)模式，其中，非hosting模式要求第三方应用的支付网页部署在本地比如自身的服务器，不用租借其他平台的服务器。本发明提供的基于客户端的支付方法打破了现有基于web支付方式的局限，无需不同web页面的跳转，而是由支付客户端在本地提供可定制的支付页面(其相当于支付客户端的本地窗口，不同于web页面)。为了实现本发明，首先必须为web页面比如第三方应用的web页面提供访问本地服务的能力。要实现这种能力，一种优选的方式就是内嵌脚本对象。下面进行具体描述:浏览器内核里面可以运行脚本，而脚本是由浏览器内核里的脚本引擎提供运行环境的，对于浏览器来说，脚本引擎不但内置了窗口(window),文本(document)等对象,例如在脚本里调用window, open (" www.baidu.com"),就可以在新窗口里打开百度网页。为了为web页面比如第三方应用的web页面提供访问本地服务的能力，本发明需要对浏览器内核进行改造，具体为:在浏览器内核的脚本空间中嵌入自定义脚本对象，用于实现支付客户端呼出支付页面。基于上面描述，下面对本发明提供的方法进行描述:第一实施例:参见图2，图2为本发明实施例提供的第一实施例流程图。如图2所示，该流程可包括以下步骤:步骤201，第三方应用平台接收用户在第三方应用页面发起的支付触发，并向支付平台发送支付请求。本发明中，第三方应用平台具体可为第三方应用的后台服务器。另外，本发明中，支付平台具体可为用户触发的支付渠道的后台。比如，支付渠道为财付通支付，则所述支付平台为财付通的后台。步骤202，第三方应用平台接收支付平台针对所述支付请求返回的支付页面标识，并触使支付客户端调出所述支付页面标识对应的支付页面，以使所述用户在所述支付页面进行支付操作。优选地，本实施例中，步骤202中调出支付页面标识对应的支付页面可通过支付客户端已创建的支付接口实现，具体为:第三方应用平台运行浏览器内核脚本空间中嵌入的用于实现支付接口呼出支付页面的自定义脚本对象，来调用所述支付接口，由所述支付接口呼出所述支付客户端在本地提供的对应所述支付页面标识的支付页面。另外，本发明中，用户在支付页面进行的支付操作具体实现时至少可包括:输入支付金额、输入购买产品的数量等，本发明并不具体限定。至此，完成图2所示的流程。为使图2所示的流程更加清楚，下面通过第二实施例进行详细描述:第二实施例:参见图3，图3为本发明实施例提供的第二实施例流程图。如图3所示，该流程可包括以下步骤:步骤301，用户在第三方应用的web页面进行支付触发。步骤302，第三方应用平台接收到所述支付触发时，向支付平台发送支付请求。步骤303，支付平台向第三方应用平台返回针对所述支付请求的支付页面标识。优选地，本实施例中，所述支付页面标识具体实现时可为统一资源定位符(URL)，其中，该URL至少包括:用户的状态信息比如用户是否登录即时通信等、所述第三方应用页面的标识、所述第三方应用的标识、以及交易信息比如订单号、支付金额等信息。步骤304，第三方应用平台接收支付平台返回的支付页面标识，运行浏览器内核中内嵌的自定义脚本对象调用支付客户端中的支付接口，由所述支付接口呼出所述支付客户端在本地提供的对应所述支付页面标识的支付页面。目前流行的浏览器内核有IE，ChiOme，Firef0X，它们都提供了扩展脚本的能力，允许内嵌脚本对象。下面以IE为例描述如何调用支付接口，其他内核原理类似。IE提供了非常明确的机制,其对于window对象里面的external成员提供了专门的接口进行扩展，即，只要支付客户端在IE浏览器内核的脚本空间中嵌入自定义脚本对象实现相关的com接口，就可以对external对象进行扩展,用于调用支付客户端的支付接口呼出支付页面。具体来说，IE中的脚本扩展就是实现一个IDispatch接口，该IDispatch接口为一个基接口，可通过CHtmlView类的OnGetExternal虚函数返回此IDispatch接口指针，本发明可以在该基接口下实现com接口，用于调用支付客户端的支付接口呼出支付页面，之后可以在脚本中通过window, external.XXX来引用接口暴露的方法或属性,其中，XXX为com接口的相关信息，比如名称等。例如,通过脚本js调用window, external,open ( “www.tenpay.com”),则脚本解析器会从左到右逐个解析,首先找到window对象,然后再找到external对象,再在external对象中找到支付客户端在IE浏览器内核的脚本空间中嵌入的自定义脚本对象open函数(实质为com接口)，这样就会在支付客户端的支付窗口中打开财付通的网页。从步骤304可以看出，本步骤304提供的支付页面不为支付渠道商提供的web页面，而是由支付客户端本地提供支付页面，其相当于支付客户端提供的一个接口，与现有技术相比，本发明不需要执行不同web页面的中转。步骤305，所述支付客户端管理用户在所述支付页面进行的支付操作。至此，完成图3所示的流程。需要说明的是，在支付交易过程中，支付安全是必须的。为了保证支付的安全，防止一些不法网站比如钓鱼网站伪造信息诈骗用户财产，本发明还提供了第三实施例所示的方法:第三实施例:该第三实施例以上述的支付页面标识为URL为例，其他情况原理类似。参见图4，图4为本发明实施例提供的第三实施例流程图。如图4所示，该流程可包括以下步骤:步骤401至步骤402分别与步骤301至步骤302类似。步骤403，支付平台对所述支付请求进行验证，如果验证通过，则返回支付页面的URL和对应所述URL的验证串(token)给第三方应用平台。本步骤403中，对支付请求进行验证，目的是为了验证该支付请求的有效性，具体实现时可有多种实现形式，比如，验证所述支付请求携带的第三方应用的域名是否在设定的白名单中，如果是，则确定所述支付请求通过验证，否则，确定所述支付请求未通过验证。本发明通过对支付请求进行验证，目的是保证支付的安全，防止一些不法网站比如钓鱼网站伪造信息诈骗用户财产。作为本发明实施例的一种扩展，支付平台在所述支付请求不通过验证时，直接返回验证失败的信息给第三方应用平台。步骤404,第三方应用平台接收支付平台返回的URL和token。
其中，所述token每隔设定时间比如15分钟会失效。步骤405，第三方应用平台运行浏览器内核中内嵌的自定义脚本对象来调用支付客户端中的支付接口验证所述URL，如果通过验证，则由所述支付接口呼出所述支付客户端在本地提供的对应所述URL的支付页面。本步骤405之所以验证URL，目的是保证支付的安全，防止一些不法网站比如钓鱼网站伪造信息诈骗用户财产。其中，验证所述URL具体可为:验证所述URL是否在设定的白名单中，如果是，则确定所述URL通过验证，否则，确定所述URL不通过验证。优选地，作为本发明实施例的一个扩展，本步骤405中，如果所述URL不通过验证，则提供验证失败的提
/Jn ο步骤406，所述支付客户端管理用户在所述支付页面进行的支付操作，并在用户完成支付操作后，触发所述支付平台对支付操作进行处理。其中，所述支付平台对支付操作进行处理至少包括:将用户输入的支付金额直接进入所述第三方应用的账户。也即，通过本发明能够实现用户支付的金额直接进入第三方应用的账户，无需中转。另外，基于上述步骤401至步骤406可以看出，本发明中，支付客户端只关心打开哪个URL，而这个URL是第三方应用平台向支付台请求的，其不关心用户支付的是哪个银行、以及如何识别该银行。以URL为财付通的URL为例，则本发明中，支付客户端仅依据财付通的URL打开财付通的页面，由用户在财付通页面中选择支付银行。也即只要打开了财付通的页面，其他的就不需要第三方来管了。其中，财付通页面上的支付银行由财付通预先和支付银行洽谈所决定的。步骤407，所述支付平台发送处理结果给所述支付客户端。本步骤407中，所述处理结果至少为:支付成功、支付失败、或者所述token失效，需要请求新的token。其中，所述token失效的原因可为:由于token每隔设定时间比如15分钟会失效，当在步骤405呼出支付页面后，用户没有在设定时间内未执行支付操作，当超过设定时间后在执行支付操作，就会出现token失效的情况。步骤408，支付客户端根据所述处理结果执行相应操作。具体地，本步骤408可为:如果支付成功，则可以通知回调第三方比如通知第三方发货、验证支付金额等，如果支付失败，则通知用户支付失败原因，如果token失效，则返回步骤402第三方应用平台发送支付请求的操作，以请求新的token。至此，完成图4所示的流程。为使图4所示的流程更加清楚，图5提出了对应图4流程的示意图。至此，完成第三实施例的描述。需要说明的是，上述支付客户端中的支付接口由支付客户端中的支付组件同一管理，并且，支付接口呼出的支付页面并非固定不变，其可以根据需求进行动态修改，具体实现时:通过运行浏览器内核中的脚本调用所述支付组件管理的用于动态修改支付页面的接口来修改支付页面。还需要说明的是，上述都是通过运行浏览器内核中嵌入的自定义脚本对象调用支付客户端中支付组件管理的接口，作为本发明实施例的扩展，浏览器的插件比如IE的ActiveX、其它浏览器的NP插件也可以调用支付客户端中支付组件管理的接口。但是，开发浏览器的插件比如IE的ActiveX、其它浏览器的NP插件比较麻烦，对于开发者来说需要较高的门槛，并且，如果浏览器的插件可以直接执行本地代码，其功能就是不可控的，对于对安全要求极高的支付体系来说，这明显是不适用的。而在浏览器内核里面运行脚本调用支付客户端中支付组件管理的接口，可以完全控制脚本的访问范围，而且还可以进行权限控制，既简单同时又保证了整个支付的安全性。以上对本发明提供的方法进行了描述，下面对本发明提供的系统进行描述:参见图6，图6为本发明实施例提供的系统结构图。如图6所示，该系统可包括:第三方应用平台、支付平台和支付客户端。其中，如图7所示，该系统中的第三方应用平台具体实现时可包括:支付请求发送单元和处理单元；所述支付请求发送单元，用于接收用户在第三方应用页面发起的支付触发，并向支付平台发送支付请求；所述处理单元，用于接收支付平台针对所述支付请求返回的支付页面标识，并触使支付客户端调出所述支付页面标识对应的支付页面；所述支付平台，用于向所述第三方应用平台返回针对所述支付请求的支付页面标识。优选地，为保证支付安全，所述支付平台验证所述支付请求是否有效，如果验证通过，则向所述第三方应用平台返回针对所述支付请求的支付页面标识。基于图7所示的该系统中第三方应用平台的具体结构，图8示出了该系统中支付客户端的具体实现结构。如图8所示，该系统中的支付客户端可包括:支付触发单元，用于在用户针对第三方应用进行支付时，在该第三方应用的页面向第三方应用平台发起支付触发，以使第三方应用平台向支付平台发送支付请求；调用单元，用于接收第三方应用平台的触发，所述触发携带了所述第三方应用平台接收的支付平台针对所述支付请求返回的支付页面标识，根据所述触发调出所述支付页面标识对应的支付页面，以使所述用户在所述支付页面进行支付操作。本实施例中，所述调用单元验证所述支付页面标识的有效性，如果验证通过，则呼出由所述支付客户端在本地提供的对应所述支付页面标识的支付页面。本实施例中，所述支付平台针对所述支付请求返回支付页面标识进一步包括:返回所述支付页面标识对应的token ;基于此,如图8所示,所述支付客户端还包括:处理触发单元和支付处理单元；所述处理触发单元用于在用户完成支付操作后，触发所述支付平台对该支付操作进行处理，所述支付平台对支付操作进行处理至少包括:将用户输入的支付金额直接进入所述第三方应用的账户；所述支付处理单元用于根据所述支付平台的处理结果执行相应操作；所述处理结果至少为:支付成功、支付失败、或者所述token失效,需要请求新的token。本实施例中，所述支付页面标识为URL，其至少包含了用户的状态信息、所述第三方应用页面的标识、所述第三方应用的标识、以及交易信息。另外，本实施例中，所述调用单元可通过支付接口实现，而所述支付接口由所述支付客户端中的支付组件统一管理；其中，所述支付客户端提供的支付页面允许动态修改，其通过所述支付组件管理的其他接口实现。如图8所示,所述支付客户端还包括:内嵌单元，用于在浏览器内核的脚本空间中嵌入自定义脚本对象，用于实现所述支付接口呼出支付页面；基于此，所述支付接口在所述第三方应用平台运行所述内嵌单元嵌入的自定义脚本对象时，调出支付页面标识对应的支付页面。至此，完成本发明提供的系统结构描述。由以上技术方案可以看出，本发明中，当用户在第三方应用页面发起支付触发时，第三方应用平台接收用户在第三方应用页面发起的支付触发，并向支付平台发送支付请求，以及第三方应用平台接收支付平台针对所述支付请求返回的支付页面标识，并触使支付客户端调出所述支付页面标识对应的支付页面，以使所述用户在所述支付页面进行支付操作。即本发明中，由支付客户端在本地提供支付页面，其相当于支付客户端的一个接口，而不像现有技术那样需要支付渠道商提供web的支付页面，相比于现有技术，本发明实现了在客户端完成支付的目的，不需要执行不同web页面的中转；进一步地，本发明中，通过对支付请求、URL验证，可以保证支付的安全，防止一些不法网站比如钓鱼网站伪造信息诈骗用户财产；进一步地，本发明在浏览器内核里面运行脚本调用支付客户端中支付组件的方式，可以完全控制脚本的访问范围，而且还可以进行权限控制，既简单同时又保证了整个支付的安全性。更进一步地，本发明通过将用户输入的支付金额直接进入所述第三方应用的账户，能够实现用户支付的金额直接进入第三方应用的账户，无需中转。以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。
权利要求
1.一种基于客户端的支付方法，其特征在于，该方法包括: 第三方应用平台接收用户在第三方应用页面发起的支付触发，并向支付平台发送支付请求； 第三方应用平台接收支付平台针对所述支付请求返回的支付页面标识，并触使支付客户端调出所述支付页面标识对应的支付页面，以使所述用户在所述支付页面进行支付操作。
2.根据权利要求1所述的方法，其特征在于，所述触使支付客户端调出支付页面标识对应的支付页面包括: A，运行浏览器内核中的脚本调用支付客户端中的支付接口，由所述支付接口呼出所述支付客户端在本地提供的对应所述支付页面标识的支付页面。
3.根据权利要求2所述的方法，其特征在于，步骤A之前进一步包括:支付客户端在浏览器内核的脚本空间中嵌入自定义脚本对象，用于实现所述支付接口呼出支付页面； 步骤A中运行的脚本为:所述自定义脚本对象。
4.根据权利要求2或3所述的方法，其特征在于，所述支付接口呼出支付客户端在本地提供的对应所述支付页面标识的支付页面包括: 所述支付接口验证所述支付页面标识的有效性，如果验证通过，则呼出所述支付客户端在本地提供的对应所述支付页面标识的支付页面。
5.根据权利要求1所述的方法，其特征在于，所述支付平台针对所述支付请求返回支付页面标识包括:` 验证所述支付请求是否有效，如果验证通过，则向所述第三方应用平台返回针对所述支付请求的支付页面标识。
6.根据权利要求1所述的方法，其特征在于，所述第三方应用平台接收支付平台针对所述支付请求返回的支付页面标识进一步包括:接收所述支付平台返回的对应所述支付页面标识的验证串token ； 该方法进一步包括: 在用户完成支付操作后，所述支付客户端触发所述支付平台对该支付操作进行处理，所述支付平台对支付操作进行处理至少包括:将用户输入的支付金额直接进入所述第三方应用的账户； 所述支付客户端接收所述支付平台的处理结果，根据所述处理结果执行相应操作，其中，所述处理结果至少为:支付成功、支付失败、或者所述token失效,需要请求新的token。
7.根据权利要求6所述的方法，其特征在于，所述支付页面标识为统一资源定位符URL，其至少包含了用户的状态信息、所述第三方应用页面的标识、所述第三方应用的标识、以及交易信息。
8.根据权利要求2或3所述的方法，其特征在于，所述支付接口由所述支付客户端中的支付组件统一管理； 所述支付客户端提供的支付页面允许动态修改，其通过所述支付组件管理的其他接口实现。
9.一种基于客户端的支付方法，其特征在于，该方法包括: 支付客户端在用户针对第三方应用进行支付时，在该第三方应用的页面向第三方应用平台发起支付触发，以使第三方应用平台向支付平台发送支付请求； 支付客户端接收第三方应用平台的触发，所述触发携带了所述第三方应用平台接收的支付平台针对所述支付请求返回的支付页面标识，根据所述触发调出所述支付页面标识对应的支付页面，以使所述用户在所述支付页面进行支付操作。
10.根据权利要求9所述的方法，其特征在于，所述调出支付页面标识对应的支付页面由所述支付客户端的支付接口实现； 所述支付接口在所述第三方应用平台运行浏览器内核中的脚本时调出支付页面标识对应的支付页面；所述脚本为支付客户端在浏览器内核的脚本空间中嵌入的用于实现支付接口呼出支付页面的自定义脚本对象。
11.根据权利要求10所述的方法，其特征在于，所述支付接口调出支付页面标识对应的支付页面包括: 所述支付接口验证所述支付页面标识的有效性，如果验证通过，则呼出所述支付客户端在本地提供的对应所述支付页面标识的支付页面。
12.根据权利要求9所述的方法，其特征在于，所述支付平台针对所述支付请求返回支付页面标识进一步包括:返回所述支付页面标识对应的验证串token ； 该方法进一步包括: 所述支付客户端在用户完成支付操作后，触发所述支付平台对该支付操作进行处理，所述支付平台对支付操作进行处理至少包括:将用户输入的支付金额直接进入所述第三方应用的账户； 所述支付客户端接 收所述支付平台的处理结果；所述处理结果至少为:支付成功、支付失败、或者所述token失效，需要请求新的token，根据所述处理结果执行相应操作。
13.根据权利要求9至12任一所述的方法，其特征在于，所述支付页面标识为统一资源定位符URL，其至少包含了用户的状态信息、所述第三方应用页面的标识、所述第三方应用的标识、以及交易信息。
14.根据权利要求10或11所述的方法，其特征在于，所述支付接口由所述支付客户端中的支付组件统一管理； 所述支付客户端提供的支付页面允许动态修改，其通过所述支付组件管理的其他接口实现。
15.一种支付客户端，其特征在于，该支付客户端包括: 支付触发单元，用于在用户针对第三方应用进行支付时，在该第三方应用的页面向第三方应用平台发起支付触发，以使第三方应用平台向支付平台发送支付请求； 调用单元，用于接收第三方应用平台的触发，所述触发携带了所述第三方应用平台接收的支付平台针对所述支付请求返回的支付页面标识，根据所述触发调出所述支付页面标识对应的支付页面，以使所述用户在所述支付页面进行支付操作。
16.根据权利要求15所述的支付客户端，其特征在于，所述调用单元通过支付接口实现； 所述支付客户端还包括: 内嵌单元，用于在浏览器内核的脚本空间中嵌入自定义脚本对象，用于实现所述支付接口呼出支付页面；所述支付接口在所述第三方应用平台运行所述内嵌单元嵌入的自定义脚本对象时，调出支付页面标识对应的支付页面。
17.根据权利要求16所述的支付客户端，其特征在于，所述支付接口由所述支付客户端中的支付组件统一管理； 所述支付客户端提供的支付页面允许动态修改，其通过所述支付组件管理的其他接口实现。
18.根据权利要求15所述的支付客户端，其特征在于，所述调用单元验证所述支付页面标识的有效性，如果验证通过，则呼出由所述支付客户端在本地提供的对应所述支付页面标识的支付页面。
19.根据权利要求15所述的支付客户端，其特征在于，所述支付平台针对所述支付请求返回支付页面标识进一步包括:返回所述支付页面标识对应的验证串token ； 所述支付客户端还包括:处理触发单元和支付处理单元； 所述处理触发单元用于在用户完成支付操作后，触发所述支付平台对该支付操作进行处理，所述支付平台对支付操作进行处理至少包括:将用户输入的支付金额直接进入所述第三方应用的账户； 所述支付处理单元用于根据所述支付平台的处理结果执行相应操作；所述处理结果至少为:支付成功、支付失败、或者所述token失效,需要请求新的token。
20.根据权利要求15至19任一所述的支付客户端，其特征在于，所述支付页面标识为统一资源定位符URL，其至少包含了用户的状态信息、所述第三方应用页面的标识、所述第三方应用的标识、以及交易信息。
21.一种基于客户端的支付系统，其特征在于，该系统包括:第三方应用平台、支付平台和如权利要求15至19任一所述的支付客户端； 其中，所述第三方应用平台包括:支付请求发送单元和处理单元； 所述支付请求发送单元，用于接收用户在第三方应用页面发起的支付触发，并向支付平台发送支付请求； 所述处理单元，用于接收支付平台针对所述支付请求返回的支付页面标识，并触使支付客户端调出所述支付页面标识对应的支付页面； 所述支付平台，用于向所述第三方应用平台返回针对所述支付请求的支付页面标识。
22.根据权利要求21所述的系统，其特征在于，所述支付平台验证所述支付请求是否有效，如果验证通过， 则向所述第三方应用平台返回针对所述支付请求的支付页面标识。
全文摘要
本发明提供了基于客户端的支付方法、系统和支付客户端。一种方法包括第三方应用平台接收用户在第三方应用页面发起的支付触发，并向支付平台发送支付请求；第三方应用平台接收支付平台针对所述支付请求返回的支付页面标识，并触使支付客户端调出所述支付页面标识对应的支付页面，以使所述用户在所述支付页面进行支付操作。
文档编号G06Q20/08GK103106576SQ20111036111
公开日2013年5月15日 申请日期2011年11月15日 优先权日2011年11月15日
发明者郭学亨, 尚瀚焜, 李劲秋, 李斌, 谢昕虬, 黄奎 申请人:腾讯科技(深圳)有限公司