CN105654284A - 支付处理的方法及装置 - Google Patents

Abstract

本公开是关于一种支付处理的方法及装置，属于网络支付技术领域。该方法包括：检测是否在应用内发起支付请求；当在所述应用内发起支付请求时，接收输入的支付信息，在本地进行所述支付信息的验证；调用支付网关提交所述支付请求。本发明针对网络差的地区，能够提高网络支付率。

Description

支付处理的方法及装置

技术领域

本公开涉及网络支付技术，尤其涉及一种支付处理的方法及装置。

背景技术

目前，用户在移动终端(智能手机、平板电脑等)中进行支付的比例越来越大，随着电子商务的快速发展，许多服务商都需要提供移动终端支付服务，以满足业务增长需求，缩短用户从浏览商品到支付的时间，提高用户支付比例。移动支付对安全性和便捷性都有较高的要求。提供快速/便捷，同时又能保证安全性的支付解决方案，是电子商务中的重要环节之一。

由于地区发展的不均衡，基础设施建设的不完善，很多地区的无线网络连接速度和稳定性都无法得到保障，而用户在移动终端支付的需求又在日益提高。如何满足网络基础建设还不完善地区的移动终端支付需求，是目前电子商务发展急需解决的问题之一。

因此，需要一种新的支付处理的方法及装置。

在所述背景技术部分公开的上述信息仅用于加强对本公开的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开提供一种支付处理的方法及装置，能够提高移动终端的网络支付率。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一方面，提供一种支付处理的方法，包括：检测是否在应用内发起支付请求；当在所述应用内发起支付请求时，接收输入的支付信息，在本地进行所述支付信息的验证；调用支付网关提交所述支付请求。

根据本公开的一实施方式，其中所述输入的支付信息包括选择的支付方式和/或输入新的支付信息。

根据本公开的一实施方式，还包括：保存所述支付信息的部分或全部。

根据本公开的一实施方式，还包括：如果出现网络连接失败，重试操作时直接调出所述保存的支付信息；接收输入的未保存的支付信息；再次发起支付请求。

根据本公开的一实施方式，其中所述保存的支付信息包括卡的有效时间选择和/或卡的类型选择和/或文字输入框的内容。

根据本公开的一实施方式，其中所述应用提供站点浏览和购物操作功能。

根据本公开的一实施方式，其中所述支付信息包括常用支付卡，银行卡信息，支付方式信息。

根据本公开的一实施方式，其中所述支付验证信息包括CVV和/或密码信息，向所述支付网关提交所述密码和/或CVV信息。

根据本公开的一实施方式，所述应用中还包括所述支付网关的密钥信息。

根据本公开实施例的另一方面，提供一种支付处理的装置，包括：检测模块，用于检测是否在应用内发起支付请求；本地校验模块，用于当在所述应用内发起支付请求时，接收输入的支付信息，在本地进行所述支付信息的验证；支付网关交互模块，用于调用支付网关提交所述支付请求。

根据本公开的一实施方式，其中所述输入的支付信息包括选择的支付方式和/或输入新的支付信息。

根据本公开的一实施方式，还包括：保存模块，用于保存所述支付信息的部分或全部。

根据本公开的一实施方式，还包括：调出模块，用于出现网络连接失败时，重试操作时直接调出所述保存的支付信息；输入模块，用于接收输入的未保存的支付信息；支付请求模块，用于再次发起支付请求。

根据本公开的一实施方式，其中所述保存的支付信息包括卡的有效时间选择和/或卡的类型选择和/或文字输入框的内容。

根据本公开的一实施方式，其中所述应用提供站点浏览和购物操作功能。

根据本公开的一实施方式，其中所述支付信息包括常用支付卡，银行卡信息，支付方式信息。

根据本公开的一实施方式，其中所述支付验证信息包括CVV和/或密码信息，向所述支付网关提交所述密码和/或CVV信息。

根据本公开的一实施方式，所述应用中还包括所述支付网关的密钥信息。

根据本公开实施例的再一方面，提供一种移动终端，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器被配置为：检测是否在应用内发起支付请求；当在所述应用内发起支付请求时，接收输入的支付信息，在本地进行所述支付信息的验证；调用支付网关提交所述支付请求。

根据本公开的支付处理的方法及装置，能够提高网络支付的成功率。

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

附图说明

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

图1示意性示出根据本公开示例实施方式的支付处理的方法的流程图；

图2示意性示出根据本公开示例实施方式的支付处理的方法的流程图；

图3示意性示出根据本公开示例实施方式的支付处理的方法的流程图；

图4示意性示出根据本公开示例实施方式的支付处理的装置的框图；

图5示意性示出根据本公开示例实施方式的移动终端的框图；

图6示意性示出根据本公开示例实施方式的支付处理的装置的框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知结构、方法、装置、实现、材料或者操作以避免喧宾夺主而使得本公开的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

图1示意性示出根据本公开示例实施方式的支付处理的方法的流程图。

如图1所示，在步骤S110，开始。

在步骤S120，检测是否在应用内发起支付请求；如果在所述应用内发起支付请求，则进入下一步；反之，跳回到步骤S110。

在示例性实施例，其中所述应用提供站点浏览和购物操作功能。

在步骤S130，接收输入的支付信息，在本地进行所述支付信息的验证。

在示例性实施例，在本地进行所述支付信息的验证，例如在印度用62XXXX的卡支付，但是这个卡是中国的卡，不能在印度支付。现有技术中默认的行为是先提交服务器，然后服务器校验卡是否支持。本公开实施方式把这个校验放到了本地进行，不提交服务端，少了一次交互请求。

卡类型一般情况下可以通过正则表达式等一些规则判断，服务器端校验的好处在于方便调整校验策略，网络好，或者希望降低维护成本，都会采用服务器校验。本地校验的好处在于减少网络请求，提高速度。类似的例子还有支付方需要提供身份信息等，比如要提交身份证校验，而身份证的合法性可以在本地校验，也可以在服务器校验。利弊类似上述例子。网络好的地区，如大陆，可能不会用本地校验，原因和上述类似。

在示例性实施例，还包括：保存所述支付信息的部分或全部。

在示例性实施例，还包括：如果出现网络连接失败，重试操作时直接调出所述保存的支付信息；接收输入的未保存的支付信息；再次发起支付请求。

在示例性实施例，其中所述保存的支付信息包括卡的有效时间选择和/或卡的类型选择和/或文字输入框的内容。

在示例性实施例，其中所述支付信息包括常用支付卡，银行卡信息，支付方式信息。

在步骤S140，调用支付网关提交所述支付请求。

在示例性实施例，其中所述支付验证信息包括CVV和/或密码信息，向所述支付网关提交所述密码和/或CVV信息。所述CVV即信用卡验证码，是印在信用卡背面的附加码，也称为CVC(CardVerificationCode)。

在示例性实施例，其中所述方法应用于低速不稳定网络连接下的移动平台的支付场景，用于减少移动应用程序和服务器之间的交互。

本公开是应用在印度、印尼等地区，这些地区网络条件很差，一般的网速也就是2G水平，而且不稳定。互联网和配套的支付支持服务没有中国完善。银行和支付机构非常多，没有统一市场的类似支付宝、微信一类的支付供应商。银行很多，所占的份额也都不大，对网络支付的支持有限，基本就是网站支付，通常只是适合PC机的网站，某些有适合手机的移动站，极少数有Android系统的本地支付SDK。本方案是基于这样一个市场环境。对以上部分的理解，一定要放在网络很差的环境中，如果网络好，直接APP内置浏览器跳银行移动站进行操作即可，不需要去调用银行支付网关。

例如，用户在移动终端的购物应用内发起支付请求。其中常用支付卡信息、银行卡信息输入等操作，均在本地打开，不需要跳转到银行网站，或者调用银行应用程序，用户可以选择常用支付方式，或者输入新的支付信息，点击支付即可。用户输入支付验证信息，如CVV，密码之类，提交支付信息。

在上述的支付信息输入步骤，不需要与网络或者其他应用程序交互，仅仅在提交支付阶段，向支付网关提交密码、CVV等信息，减少了该购物应用与其他的网络交互。系统利用网络接口直接调用支付网关交互数据，而不需要跳到第三方如银行的网站，然后再在该购物应用的内置浏览器中提交支付信息，减少了浏览器本身渲染输入界面所需要的时间和网络交互。

在示例性实施例，所述应用中包括所述支付网关的密钥信息。

密钥信息编译在应用中，第三方无法通过拦截网络请求等方式伪造支付数据，保证支付操作的安全性。支付方提供的支付网关，一般都是加密传输的。密钥之类的在商务谈判阶段会相互确定。可以理解为把某个银行的U盾集成到该购物应用中了，这样可以保证网络支付的安全性，第三方拦截网络数据也看不到明文，无法伪装成该购物应用骗取支付。

目前，用户进行网络支付，一般都是通过移动终端的第三方浏览器进行，例如iOS系统的用户，都在iOS系统自带的Safari浏览器中，完成添加商品和支付的操作。这样的方式支付操作需要多次网络交互，支付环节存在大量服务器和客户端之间的网络交互。在网络状况恶劣的环境下，如果某次交互连接超时或者失败，需要用户从头开始提交所有的信息，降低用户体验，多次反复连接和提交数据会让部分用户会放弃支付，影响网上订单的支付成功率。

现有技术中，在用户购物环节，浏览器或者购物应用程序通过调用第三方支付的本地应用程序来进行支付验证。支付环节需要安装第三方支付的应用程序，在网络环境恶劣的情况下，用户支付时需要额外下载一个应用程序，网络差的地区通常无法在短时间内下载成功，而且即使已经安装第三方支付应用程序，也需要进行多次的应用程序切换，网络验证和应用程序之间的交互验证，通常会带来比较长的延时和较高的失败率，影响用户体验的同时，会降低订单的支付率。

本公开的支付处理的方法，通过在移动购物应用中集成网络浏览器和支付应用功能于一体，将支付环节部分的网络验证修改到本地进行，减少网络交互次数。

图2示意性示出根据本公开示例实施方式的支付处理的方法的流程图。

如图2所示，在步骤S210，开始。

在步骤S220，检测是否在应用中发起支付请求；如果发起支付请求，则进入下一步；反之，跳回到步骤S210。

在步骤S230，接收输入至所述应用中的支付信息，在本地进行所述支付信息的验证，保存支付信息的部分或全部。

在示例性实施例，可以通过即时通信方式将所述输入的支付信息发送到本地存储数据库，可以是异步JavaScript和XML(AsynchronousJavascript+XML，ajax)方式。即时通信可以及时将用户填写的信息保存，不用等待全部填写完毕才传送。

在步骤S240，判断所述支付请求过程中，是否网络连接失败；如果失败，则进入下一步；反之，直接跳转到步骤S280。

在步骤S250，重试操作时直接调出所述保存的支付信息。

在步骤S260，接收输入的未保存的支付信息。

在步骤S270，再次发起支付请求。

在步骤S280，在应用中提交支付请求，利用网络接口调用支付网关交互数据。

电商APP一般会集成浏览器功能，如果不集成浏览器功能，将无法进行支付。但是很多第三方的接口，比如银行，并不会提供本地方法实现。本公开实施方式是针对电商支付环境进行的。比如应用程序需要连接到外部程序，就会打开APP内置的浏览器，进入第三方的网站。一般的实现都是使用Andoird系统默认的浏览器，在提交页面后，如果失败返回，浏览器不会记录输入信息的，即使能记录，也仅仅是文字输入框的内容。但通常支付需要的控件很多，例如还包括有效时间选择，卡的类型选择等，不单单是文字输入框。这部分的信息无法被浏览器记录，需要有针对性的对支付环境，修改内置浏览器的记录内容。

在本公开实施方式中，在提交支付信息的场景下，所述应用的内置浏览器会记录用户输入的所有支付信息，而不仅仅限于输入框。

例如，用户在购物应用内发起支付请求，由于网络连接问题，连接失败，需要重新连接。用户提交信息后，信息被应用保存，遇到需要重新连接的情况，用户无需重复输入如卡号，密码之类的信息(CVV等法律不允许保存的信息除外)。用户只需要填写法律不允许保存的支付相关信息，即可以再次发起网络支付请求，提高了重试的便捷性和用户体验。

本公开的支付处理的方法，通过在移动购物应用中集成网络浏览器和支付应用功能于一体，将支付环节部分的网络验证修改到本地进行，减少网络交互次数。同时记录用户支付时提交的部分信息，在网络连接失败以后，可以减少用户重新填写重复信息的环节，提高重新连接的效率和便捷性，从而提高用户支付率。移动设备上用户输入信息相对麻烦，减少用户信息输入，降低应用交互等待时间，可以提高用户的支付体验，从而提高支付率。

图3示意性示出根据本公开示例实施方式的支付处理的方法的流程图。

如图3所示，在步骤S310，登录应用，所述应用提供站点浏览和购物操作功能。

在步骤S320，所述应用保存相应的登录信息。

在步骤S330，检测是否在所述应用内发起支付请求；如果是，则进入下一步；反之，继续检测。

在步骤S340，本地校验账户信息的合法性。

在步骤S350，接收输入所述应用中的支付信息，在本地进行所述支付信息的验证，保存支付信息的部分或全部。

在步骤S360，在应用中提交支付请求，利用网络接口调用支付网关交互数据。

例如，提示用户在应用登陆后，即可以在应用如淘宝窗口内，进行移动站点的浏览和购物操作。应用保存用户的登陆信息。用户发起支付请求，在本地即可校验用户的帐户信息是否合法，不需要发起一次网络请求，验证用户帐户。

本公开的一种支付处理的方法，能够利用浏览器和支付接口集成的方式，降低网络交互次数。同时在连接失败的情况下，能够方便用户进行重试操作，减少重新连接所需要的操作。

图4示意性示出根据本公开示例实施方式的支付处理的装置的框图。

如图4所示，该装置包括：检测模块410，用于检测是否在应用内发起支付请求；本地校验模块420，用于当在所述应用内发起支付请求时，接收输入的支付信息，在本地进行所述支付信息的验证；支付网关交互模块430，在所述应用中调用支付网关提交所述支付请求。

在示例性实施例，其中所述输入的支付信息包括选择的支付方式和/或输入新的支付信息。

在示例性实施例，其中所述装置应用于低速不稳定网络连接下的移动终端的支付场景，用于减少移动应用程序和服务器之间的交互。

在示例性实施例，还包括：保存模块，用于保存所述支付信息的部分或全部。

在示例性实施例，还包括：调出模块，用于出现网络连接失败时，重试操作时直接调出所述保存的支付信息；输入模块，用于接收输入的未保存的支付信息；支付请求模块，用于再次发起支付请求。

在示例性实施例，其中所述保存的支付信息包括卡的有效时间选择和/或卡的类型选择和/或文字输入框的内容。

在示例性实施例，其中所述应用提供站点浏览和购物操作功能。

在示例性实施例，其中所述支付信息包括常用支付卡，银行卡信息，支付方式信息。

在示例性实施例，其中所述支付验证信息包括CVV和/或密码信息，向所述支付网关提交所述密码和/或CVV信息。

在示例性实施例，所述应用中还包括所述支付网关的密钥信息。

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

本公开实施方式提供的支付处理的装置，能够在保证安全性的情况下，减少用户的在线支付环节需要进行的网络请求和应用程序间的请求，提高在低速不稳定网络连接下移动平台支付的成功率和用户体验，提高用户支付率，提高电商收入。

图5示意性示出根据本公开示例实施方式的移动终端的框图。

如图5所示，所述移动终端500包括：处理器502；用于存储处理器502可执行指令的存储器504。

所述处理器502可被配置为：检测是否在应用内发起支付请求；当在所述应用内发起支付请求时，接收输入的支付信息，在本地进行所述支付信息的验证；调用支付网关提交所述支付请求。

例如，移动终端500可以是智能手机，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

参照图5，移动终端500可以包括以下一个或多个组件：处理组件501，存储器504，电源组件505，多媒体组件505，音频组件507，输入/输出(I/O)的接口503，传感器组件509，以及通信组件508。

处理组件501通常控制移动终端500的整体操作，诸如与显示，数据通信，相机操作和记录操作相关联的操作。处理组件501可以包括一个或多个处理器502来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件501可以包括一个或多个模块，便于处理组件501和其他组件之间的交互。例如，处理组件501可以包括多媒体模块，以方便多媒体组件506和处理组件501之间的交互。

存储器504被配置为存储各种类型的数据以支持在设备500的操作。这些数据的示例包括用于在移动终端500上操作的任何应用程序或方法的指令，消息，图片，视频等。存储器504可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件505为移动终端500的各种组件提供电力。电源组件505可以包括电源管理系统，一个或多个电源，及其他与为移动终端500生成、管理和分配电力相关联的组件。

多媒体组件506包括在所述移动终端500和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件506包括一个前置摄像头和/或后置摄像头。当设备500处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件507被配置为输出和/或输入音频信号。例如，音频组件507包括一个麦克风(MIC)，当移动终端500处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器504或经由通信组件508发送。在一些实施例中，音频组件507还包括一个扬声器，用于输出音频信号。

I/O接口503为处理组件501和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件509包括一个或多个传感器，用于为移动终端500提供各个方面的状态评估。例如，传感器组件509可以检测到设备500的打开/关闭状态，组件的相对定位，例如所述组件为移动终端500的显示器和小键盘，传感器组件509还可以检测移动终端500或移动终端500一个组件的位置改变，用户与移动终端500接触的存在或不存在，移动终端500方位或加速/减速和移动终端500的温度变化。传感器组件509可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件509还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件509还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件508被配置为便于移动终端500和其他设备之间有线或无线方式的通信。移动终端500可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件508经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件508还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例，移动终端500可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器504，上述指令可由移动终端500的处理器502执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

一种非临时性计算机可读存储介质，当所述存储介质中的指令由移动终端的处理器执行时，使得移动终端能够执行一种支付处理的方法，所述方法包括：

检测是否在应用内发起支付请求；当在所述应用内发起支付请求时，接收输入的支付信息，在本地进行所述支付信息的验证；调用支付网关提交所述支付请求。

图6示意性示出根据本公开示例实施方式的支付处理的装置600的框图。

如图6所示，600例如，装置600可以被提供为一服务器。参照图6，装置600包括处理组件601，其进一步包括一个或多个处理器，以及由存储器603所代表的存储器资源，用于存储可由处理组件601的执行的指令，例如应用程序。存储器603中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件601被配置为执行指令，以执行上述方法。

装置600还可以包括一个电源组件602被配置为执行装置600的电源管理，一个有线或无线网络接口604被配置为将装置600连接到网络，和一个输入输出(I/O)接口605。装置600可以操作基于存储在存储器603的操作系统，例如WindowsServerTM，MacOSXTM，UnixTM，LinuxTM，FreeBSDTM或类似。

本发明实施例中其它内容参考上述发明实施例中的内容，在此不再赘述。

图1、2和3示出根据本公开示例实施方式的支付处理的方法的流程图。该方法可例如利用如图4、5或6所示的支付处理的装置实现，但本公开不限于此。需要注意的是，图1、2和3仅是根据本公开示例实施方式的方法所包括的处理的示意性说明，而不是限制目的。易于理解，图1、2和3所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块/进程/线程中同步或异步执行的。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本公开的支付处理的方法及装置，在购物应用中集成网络浏览器和支付应用程序，在保证安全性的前提下，将部分网络验证改到本地进行，减少移动应用程序和服务器的交互次数。同时，在不违反相关法律规定的范围内，记录用户提交的信息，在网络连接失败以后，用户重试操作，不需要重复输入之前已经输入过的信息，改善重试操作的用户体验，提高用户支付率。本发明特别针对网络差的地区，用于提高移动平台的网络支付率。

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

以上具体地示出和描述了本公开的示例性实施方式。应可理解的是，本公开不限于这里描述的详细结构、设置方式或实现方法；相反，本公开意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

Claims (19)

1.一种支付处理的方法，其特征在于，包括：

检测是否在应用内发起支付请求；

当在所述应用内发起支付请求时，接收输入的支付信息，在本地进行所述支付信息的验证；

调用支付网关提交所述支付请求。

2.根据权利要求1所述的方法，其特征在于，其中所述输入的支付信息包括选择的支付方式和/或输入新的支付信息。

3.根据权利要求1所述的方法，其特征在于，还包括：保存所述支付信息的部分或全部。

4.根据权利要求3所述的方法，其特征在于，还包括：

如果出现网络连接失败，重试操作时直接调出所述保存的支付信息；

接收输入的未保存的支付信息；

再次发起支付请求。

5.根据权利要求3或4所述的方法，其特征在于，其中所述保存的支付信息包括卡的有效时间选择和/或卡的类型选择和/或文字输入框的内容。

6.根据权利要求1所述的方法，其特征在于，其中所述应用提供站点浏览和购物操作功能。

7.根据权利要求1所述的方法，其特征在于，其中所述支付信息包括常用支付卡，银行卡信息，支付方式信息。

8.根据权利要求1所述的方法，其特征在于，其中所述支付验证信息包括CVV和/或密码信息，向所述支付网关提交所述密码和/或CVV信息。

9.根据权利要求1所述的方法，其特征在于，所述应用中还包括所述支付网关的密钥信息。

10.一种支付处理的装置，其特征在于，包括：

检测模块，用于检测是否在应用内发起支付请求；

本地校验模块，用于当在所述应用内发起支付请求时，接收输入的支付信息，在本地进行所述支付信息的验证；

支付网关交互模块，用于调用支付网关提交所述支付请求。

11.根据权利要求10所述的装置，其特征在于，其中所述输入的支付信息包括选择的支付方式和/或输入新的支付信息。

12.根据权利要求10所述的装置，其特征在于，还包括：保存模块，用于保存所述支付信息的部分或全部。

13.根据权利要求10所述的装置，其特征在于，还包括：

调出模块，用于出现网络连接失败时，重试操作时直接调出所述保存的支付信息；

输入模块，用于接收输入的未保存的支付信息；

支付请求模块，用于再次发起支付请求。

14.根据权利要求12或13所述的装置，其特征在于，其中所述保存的支付信息包括卡的有效时间选择和/或卡的类型选择和/或文字输入框的内容。

15.根据权利要求10所述的装置，其特征在于，其中所述应用提供站点浏览和购物操作功能。

16.根据权利要求10所述的装置，其特征在于，其中所述支付信息包括常用支付卡，银行卡信息，支付方式信息。

17.根据权利要求10所述的装置，其特征在于，其中所述支付验证信息包括CVV和/或密码信息，向所述支付网关提交所述密码和/或CVV信息。

18.根据权利要求10所述的装置，其特征在于，所述应用中还包括所述支付网关的密钥信息。

19.一种移动终端，其特征在于，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

检测是否在应用内发起支付请求；

当在所述应用内发起支付请求时，接收输入的支付信息，在本地进行所述支付信息的验证；

调用支付网关提交所述支付请求。