本申请涉及移动支付技术领域,尤其涉及一种在线支付方法和装置。
背景技术:
随着互联网的飞速发展,在线支付应用场景越来越广泛。而用户在线支付的场景非常复杂,有无网、弱网以及强网等环境。当在强网条件下,移动终端可以与服务端联网,从而可以在用户的移动终端上展示可供选择的支付渠道。
但是,当移动终端处于无网或弱网情况下,无法在移动终端上展示可供选择的支付渠道,用户无法实现对支付渠道的选择。
技术实现要素:
本申请旨在至少在一定程度上解决相关技术中的技术问题之一。
为此,本申请的一个目的在于提出一种在线支付方法,该方法可以在移动终端处于无网或弱网情况下,用户依然可以选择支付渠道。
本申请的另一个目的在于提出一种在线支付装置。
为达到上述目的,本申请第一方面实施例提出的在线支付方法,包括:获取待支付订单的用户信息;从服务端获取与所述用户信息对应的可供选择的支付渠道;将所述可供选择的支付渠道展示在商户服务终端上,以便用 户在所述可供选择的支付渠道中选择支付渠道进行在线支付。
本申请第一方面实施例提出的在线支付方法,通过将可供选择的支付渠道展示在商户服务终端上,可以由用户在商户服务终端进行支付渠道的选择,从而在移动终端无网或弱网的情况下,用户依然可以选择支付渠道,更好满足用户需求。
为达到上述目的,本申请第二方面实施例提出的在线支付方法,包括:接收商户服务终端发送的待支付订单的用户信息;获取与所述用户信息对应的可供选择的支付渠道;将所述可供选择的支付渠道发送给商户服务终端,并展示在商户服务终端上,以便用户在所述可供选择的支付渠道中选择支付渠道进行在线支付。
本申请第二方面实施例提出的在线支付方法,通过将可供选择的支付渠道发送给商户服务终端并进行展示,可以由用户在商户服务终端进行支付渠道的选择,从而在移动终端无网或弱网的情况下,用户依然可以选择支付渠道,更好满足用户需求。
为达到上述目的,本申请第三方面实施例提出的在线支付装置,包括:第一获取模块,用于获取待支付订单的用户信息;第二获取模块,用于从服务端获取与所述用户信息对应的可供选择的支付渠道;展示模块,用于将所述可供选择的支付渠道展示在商户服务终端上,以便用户在所述可供选择的支付渠道中选择支付渠道进行在线支付。
本申请第三方面实施例提出的在线支付装置,通过将可供选择的支付渠道展示在商户服务终端上,可以由用户在商户服务终端进行支付渠道的选择,从而在移动终端无网或弱网的情况下,用户依然可以选择支付渠道,更好满足用户需求。
为达到上述目的,本申请第四方面实施例提出的在线支付装置,包括:接收模块,用于接收商户服务终端发送的待支付订单的用户信息;获取模块,用于获取与所述用户信息对应的可供选择的支付渠道;发送模块,用于将所述可供选择的支付渠道发送给商户服务终端,并展示在商户服务终端上,以便用户在所述可供选择的支付渠道中选择支付渠道进行在线支付。
本申请第四方面实施例提出的在线支付装置,通过将可供选择的支付渠道发送给商户服务终端并进行展示,可以由用户在商户服务终端进行支付渠道的选择,从而在移动终端无网或弱网的情况下,用户依然可以选择支付渠道,更好满足用户需求。
本申请附加的方面和优点将在下面的描述中部分给出,部分将从下面的描述中变得明显,或通过本申请的实践了解到。
附图说明
本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解,其中:
图1是本申请一实施例提出的在线支付方法的流程示意图;
图2是本申请另一实施例提出的在线支付方法的流程示意图;
图3是本申请另一实施例提出的在线支付方法的流程示意图;
图4是本申请另一实施例提出的在线支付装置的结构示意图;
图5是本申请另一实施例提出的在线支付装置的结构示意图;
图6是本申请另一实施例提出的在线支付装置的结构示意图;
图7是本申请另一实施例提出的在线支付装置的结构示意图;
图8是本申请另一实施例提出的电子设备的结构示意图;
图9是本申请另一实施例提出的电子设备的结构示意图。
具体实施方式
下面详细描述本申请的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的模块或具有相同或类似功能的模块。下面通过参考附图描述的实施例是示例性的,仅用于解释本申请,而不能理解为对本申请的限制。相反,本申请的实施例包括落入所附加权利要求书的精神和内涵范围内的所有变化、修改和等同物。
图1是本申请一实施例提出的在线支付方法的流程示意图。
本实施例的方法可以应用在商户服务终端上,商户服务终端是指对商品进行结账的设备。
参见图1,该方法包括:
s11:获取待支付订单的用户信息。
例如,在商户服务终端上设置用户信息采集模块,用户信息采集模块用于采集用户信息。
用户信息采集模块可以是软件形式,例如,商户服务终端的主界面上设置有录入用户信息的按钮,用户通过点击该按钮可以进入用户信息录入界面,用户在该界面内可以输入用户信息,例如输入:账户名、手机号、邮箱号等。或者,
用户信息采集模块也可以是硬件形式,例如,商户服务终端上设置指纹采集器,由指纹采集器采集用户的指纹信息。或者,商户服务终端上设置虹膜采集器,由虹膜采集器采集用户的虹膜信息。或者,商户服务终端上设置二维码扫描装置,用户可以先根据自身信息生成二维码,例如,用 户使用自身的照片生成二维码,再由商户服务终端上的二维码扫描装置扫描二维码获取用户的照片信息等。或者,
用户信息采集模块也可以是软硬件结合的形式,例如,结合用户的输入以及实际的硬件采集模块获取用户信息。
s12:从服务端获取与所述用户信息对应的可供选择的支付渠道。
其中,服务端中可以预先关联用户信息与可供选择的支付渠道,例如,用户在注册的时候,可以在服务端注册用户信息与对应的可供选择的支付渠道。
以支付宝的服务端为例,例如,用户可以在注册时,注册支付宝账户,并且对应支付宝账户关联多个银行卡账号,每个银行卡账号可以作为一种可供选择的支付渠道。
商户服务终端在获取到用户信息后,可以与服务端交互,从而从服务端获取对应的可供选择的支付渠道。
s13:将所述可供选择的支付渠道展示在商户服务终端上,以便用户在所述可供选择的支付渠道中选择支付渠道进行在线支付。
其中,商户服务终端从服务端获取可供选择的支付渠道后,可以将支付渠道展示在自身的界面上,以供用户选择。
之后,用户可以在可供选择的支付渠道中选择一个支付渠道进行在线支付。
本实施例中,通过将可供选择的支付渠道展示在商户服务终端上,可以由用户在商户服务终端进行支付渠道的选择,从而在移动终端无网或弱网的情况下,用户依然可以选择支付渠道,更好满足用户需求。
图2是本申请另一实施例提出的在线支付方法的流程示意图。
本实施例的方法可以应用在服务端上,服务端是指完成在线支付的服务端,例如,支付宝的服务端等。
参见图2,该方法包括:
s21:接收商户服务终端发送的待支付订单的用户信息。
例如,商户服务终端在采集到用户信息后,可以将其发送给服务端。
s22:获取与所述用户信息对应的可供选择的支付渠道。
其中,服务端中可以预先配置用户信息与可供选择的支付渠道的对应关系,从而可以根据接收的用户信息确定对应的可供选择的支付渠道。
其中,服务端可以在用户注册时,根据用户注册时输入的用户信息和可供选择的支付渠道确定上述的对应关系。
当然,可以理解的是,上述的对应关系的确定并不限于注册时,例如,随着用户的使用,用户可以随时新增或删除可供选择的支付渠道等,从而上述的对应关系可以是不断更新的。
s23:将所述可供选择的支付渠道发送给商户服务终端,并展示在商户服务终端上,以便用户在所述可供选择的支付渠道中选择支付渠道进行在线支付。
其中,服务端在获取到对应的可供选择的支付渠道后,可以将其发送给商户服务终端,由商户服务终端展示给用户进行选择。
本实施例中,通过将可供选择的支付渠道发送给商户服务终端并进行展示,可以由用户在商户服务终端进行支付渠道的选择,从而在移动终端无网或弱网的情况下,用户依然可以选择支付渠道,更好满足用户需求。
图3是本申请另一实施例提出的在线支付方法的流程示意图。
本实施例以用户、商户服务终端及服务端之间的交互为例。
参见图3,该方法包括:
s301:商户服务终端接收用户下发的订单信息。
其中,商户服务终端可以是自助服务终端,例如,用户在商户中购物后,可以使用该自助服务终端进行结账等操作。
用户在下发订单信息时,例如,用户使用商户服务终端提供的扫码枪扫描商品上的二维码,以在商户服务终端上进行结账。
s302:商户服务终端获取用户信息。
例如,商户服务终端可以设置软件和/或硬件形式的用户信息采集模块,从而完成对用户信息的采集。具体内容可以参见上一实施例,在此不再赘述。
s303:商户服务终端与服务端交互,获取用户信息对应的可供选择的支付渠道。
例如,服务端是支付宝的服务端,在支付宝的服务端,可以预先配置用户信息与可供选择的支付渠道之间的对应关系,以便根据用户信息获取对应的支付渠道。具体内容可以参见上一实施例,在此不再赘述。
s304:商户服务终端将可供选择的支付渠道展示在自身的界面上。
其中,商户服务终端从服务端获取可供选择的支付渠道后,可以将其展示给用户。
s305:商户服务终端接收用户选择的支付渠道。
例如,商户服务终端提供触摸屏,用户可以通过触摸的形式选择支付渠道。当然,可以理解的是,用户与商户服务终端的交互不限于触发方式,还可以通过硬件或软件的按键等方式实现交互。
另外,可以理解的是,获取订单信息以及用户信息在时序上不限定。
为了提高安全性,可选的,本实施例还可以包括:
s306:商户服务终端获取用户的身份信息。
其中,该步骤s306获取的用户的身份信息可以是与s302获取的用户信息不同的信息,以便进行验证。
例如,s302获取的用户信息是账户名,此时的用户的身份信息可以是指纹信息、虹膜信息等生物特征信息。或者,如果s302获取的用户信息是指纹信息或虹膜信息等生物特征信息,此时的用户的身份信息可以是账户名、用户名、手机号等信息。
具体的,在采集身份信息时也可以类似采集用户信息的流程,例如,用户可以通过软件和/或硬件向商户服务终端输入身份信息。
s307:商户服务终端将订单信息、用户选择的支付渠道的信息和用户的身份信息发送给服务端。
s308:服务端根据用户的身份信息进行验证。
其中,服务端中可以预先保存用户信息与用户的身份信息之间的对应关系,例如,在用户注册时,用户注册了账户名后,还可以对应保存指纹信息等。从而在验证时,服务端可以将接收的用户信息和身份信息与预先保存的信息进行比对,如果一致,则表明通过验证,否则未通过验证。
s309:在通过验证后,服务端采用用户选择的支付渠道对订单信息进行支付。
例如,身份验证通过后,服务端在用户选择的支付渠道中扣除订单信息中所需的费用。
s310:服务端向商户服务终端反馈支付成功消息。
s311:商户服务终端向用户反馈支付成功消息。
另一方面,当服务端对身份信息进行验证后未通过验证,或者支付时出现异常时,服务端可以向商户服务终端反馈支付失败消息,并由商户服务终端展示给用户,在支付失败消息中还可以携带失败原因等。
本实施例中,通过将可供选择的支付渠道发送给商户服务终端并进行展示,可以由用户在商户服务终端进行支付渠道的选择,从而在移动终端无网或弱网的情况下,用户依然可以选择支付渠道,更好满足用户需求。进一步的,通过将用户的身份信息发送给服务端进行验证,可以提高安全性。
图4是本申请另一实施例提出的在线支付装置的结构示意图。该装置可以位于商户服务终端上。参见图4,该装置包括:第一获取模块41、第二获取模块42和展示模块43。
第一获取模块41,用于获取待支付订单的用户信息。
例如,在商户服务终端上设置用户信息采集模块,用户信息采集模块用于采集用户信息。
用户信息采集模块可以是软件形式,例如,商户服务终端的主界面上设置有录入用户信息的按钮,用户通过点击该按钮可以进入用户信息录入界面,用户在该界面内可以输入用户信息,例如输入:账户名、手机号、邮箱号等。或者,
用户信息采集模块也可以是硬件形式,例如,商户服务终端上设置指纹采集器,由指纹采集器采集用户的指纹信息。或者,商户服务终端上设置虹膜采集器,由虹膜采集器采集用户的虹膜信息。或者,商户服务终端上设置二维码扫描装置,用户可以先根据自身信息生成二维码,例如,用户使用自身的照片生成二维码,再由商户服务终端上的二维码扫描装置扫描二维码获取用户的照片信息等。或者,
用户信息采集模块也可以是软硬件结合的形式,例如,结合用户的输入以及实际的硬件采集模块获取用户信息。
第二获取模块42,用于从服务端获取与所述用户信息对应的可供选择的支付渠道。
其中,服务端中可以预先关联用户信息与可供选择的支付渠道,例如,用户在注册的时候,可以在服务端注册用户信息与对应的可供选择的支付渠道。
以支付宝的服务端为例,例如,用户可以在注册时,注册支付宝账户,并且对应支付宝账户关联多个银行卡账号,每个银行卡账号可以作为一种可供选择的支付渠道。
商户服务终端在获取到用户信息后,可以与服务端交互,从而从服务端获取对应的可供选择的支付渠道。
展示模块43,用于将所述可供选择的支付渠道展示在商户服务终端上,以便用户在所述可供选择的支付渠道中选择支付渠道进行在线支付。
其中,商户服务终端从服务端获取可供选择的支付渠道后,可以将支付渠道展示在自身的界面上,以供用户选择。
之后,用户可以在可供选择的支付渠道中选择一个支付渠道进行在线支付。
一些实施例中,参见图5,该装置还包括:
第三获取模块44,用于获取用户的身份信息。
可选的,所述用户信息和/或身份信息是:用户通过商户服务终端上的软件和/硬件输入的。
可选的,所述用户信息和身份信息是不同的信息,所述用户信息或身份信 息包括如下项中的至少一项:
账户名、手机号、邮箱号、生物特征信息。
发送模块45,用于将所述身份信息发送给服务端,以使所述服务端对所述身份信息进行验证通过后进行支付。
上述模块的具体内容可以参见方法实施例中的描述,在此不再赘述。
本实施例中,通过将可供选择的支付渠道展示在商户服务终端上,可以由用户在商户服务终端进行支付渠道的选择,从而在移动终端无网或弱网的情况下,用户依然可以选择支付渠道,更好满足用户需求。
图6是本申请另一实施例提出的在线支付装置的结构示意图。该装置可以位于服务端。参见图6,该装置60包括:接收模块61、获取模块62和发送模块63。
接收模块61,用于接收商户服务终端发送的待支付订单的用户信息。
例如,商户服务终端在采集到用户信息后,可以将其发送给服务端。
获取模块62,用于获取与所述用户信息对应的可供选择的支付渠道。
其中,服务端中可以预先配置用户信息与可供选择的支付渠道的对应关系,从而可以根据接收的用户信息确定对应的可供选择的支付渠道。
其中,服务端可以在用户注册时,根据用户注册时输入的用户信息和可供选择的支付渠道确定上述的对应关系。
当然,可以理解的是,上述的对应关系的确定并不限于注册时,例如,随着用户的使用,用户可以随时新增或删除可供选择的支付渠道等,从而上述的对应关系可以是不断更新的。
发送模块63,用于将所述可供选择的支付渠道发送给商户服务终端,并展示在商户服务终端上,以便用户在所述可供选择的支付渠道中选择支付渠 道进行在线支付。
其中,服务端在获取到对应的可供选择的支付渠道后,可以将其发送给商户服务终端,由商户服务终端展示给用户进行选择。
一些实施例中,参见图7,该装置还包括:
验证模块64,用于接收所述商户服务终端发送的用户的身份信息;以及,对所述身份信息进行验证;
支付模块65,用于在验证通过后,根据用户选择的支付渠道对订单进行支付。
可选的,所述验证模块用于对所述身份信息进行验证,包括:
根据预先配置的用户信息与身份信息之间的对应关系,以及接收的用户信息和身份信息进行比对;
如果一致,则确定通过验证,否则确定未通过验证。
其中,服务端中可以预先保存用户信息与用户的身份信息之间的对应关系,例如,在用户注册时,用户注册了账户名后,还可以对应保存指纹信息等。从而在验证时,服务端可以将接收的用户信息和身份信息与预先保存的信息进行比对,如果一致,则表明通过验证,否则未通过验证。
例如,身份验证通过后,服务端在用户选择的支付渠道中扣除订单信息中所需的费用。
本实施例中,通过将可供选择的支付渠道发送给商户服务终端并进行展示,可以由用户在商户服务终端进行支付渠道的选择,从而在移动终端无网或弱网的情况下,用户依然可以选择支付渠道,更好满足用户需求。
图8是本申请另一实施例提出的电子设备的结构示意图。该电子设备可以具体是指商户服务终端。参见图8,该电子设备80包括:壳体81、处 理器82、存储器83、电路板84和电源电路85,其中,电路板84安置在壳体围成的空间内部,处理器82和存储器83设置在电路板84上;电源电路85,用于为电子设备的各个电路或器件供电;存储器83用于存储可执行程序代码;处理器82通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的程序,以用于执行以下步骤:
获取待支付订单的用户信息;
从服务端获取与所述用户信息对应的可供选择的支付渠道;
将所述可供选择的支付渠道展示在商户服务终端上,以便用户在所述可供选择的支付渠道中选择支付渠道进行在线支付。
可选的,还包括:
获取用户的身份信息;
将所述身份信息发送给服务端,以使所述服务端对所述身份信息进行验证通过后进行支付。
可选的,所述用户信息和/或身份信息是:用户通过商户服务终端上的软件和/硬件输入的。
可选的,所述用户信息和身份信息是不同的信息,所述用户信息或身份信息包括如下项中的至少一项:
账户名、手机号、邮箱号、生物特征信息。
本实施例的具体内容可以参见上述实施例中的相关描述,在此不再详细说明。
本实施例中,通过将可供选择的支付渠道展示在商户服务终端上,可以由用户在商户服务终端进行支付渠道的选择,从而在移动终端无网或弱网的情况下,用户依然可以选择支付渠道,更好满足用户需求。
图9是本申请另一实施例提出的电子设备的结构示意图。该电子设备可以具体是指服务器。参见图9,该电子设备90包括:壳体91、处理器92、存储器93、电路板94和电源电路95,其中,电路板94安置在壳体围成的空间内部,处理器92和存储器93设置在电路板94上;电源电路95,用于为电子设备的各个电路或器件供电;存储器93用于存储可执行程序代码;处理器82通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的程序,以用于执行以下步骤:
接收商户服务终端发送的待支付订单的用户信息;
获取与所述用户信息对应的可供选择的支付渠道;
将所述可供选择的支付渠道发送给商户服务终端,并展示在商户服务终端上,以便用户在所述可供选择的支付渠道中选择支付渠道进行在线支付。
可选的,还包括:
接收所述商户服务终端发送的用户的身份信息;
对所述身份信息进行验证;
在验证通过后,根据用户选择的支付渠道对订单进行支付。
可选的,所述对所述身份信息进行验证,包括:
根据预先配置的用户信息与身份信息之间的对应关系,以及接收的用户信息和身份信息进行比对;
如果一致,则确定通过验证,否则确定未通过验证。
本实施例的具体内容可以参见上述实施例中的相关描述,在此不再详细说明。
本实施例中,通过将可供选择的支付渠道发送给商户服务终端并进行展示,可以由用户在商户服务终端进行支付渠道的选择,从而在移动终端无 网或弱网的情况下,用户依然可以选择支付渠道,更好满足用户需求。
需要说明的是,在本申请的描述中,术语“第一”、“第二”等仅用于描述目的,而不能理解为指示或暗示相对重要性。此外,在本申请的描述中,除非另有说明,“多个”的含义是指至少两个。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为,表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分,并且本申请的优选实施方式的范围包括另外的实现,其中可以不按所示出或讨论的顺序,包括根据所涉及的功能按基本同时的方式或按相反的顺序,来执行功能,这应被本申请的实施例所属技术领域的技术人员所理解。
应当理解,本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中,多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如,如果用硬件来实现,和在另一实施方式中一样,可用本领域公知的下列技术中的任一项或他们的组合来实现:具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路,具有合适的组合逻辑门电路的专用集成电路,可编程门阵列(pga),现场可编程门阵列(fpga)等。
本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,该程序在执行时,包括方法实施例的步骤之一或其组合。
此外,在本申请各个实施例中的各功能单元可以集成在一个处理模块中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个模块 中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。
上述提到的存储介质可以是只读存储器,磁盘或光盘等。
在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不一定指的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
尽管上面已经示出和描述了本申请的实施例,可以理解的是,上述实施例是示例性的,不能理解为对本申请的限制,本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。