CN106682888B - 业务信息的处理方法和处理装置 - Google Patents

业务信息的处理方法和处理装置 Download PDF

Info

Publication number
CN106682888B
CN106682888B CN201510756278.6A CN201510756278A CN106682888B CN 106682888 B CN106682888 B CN 106682888B CN 201510756278 A CN201510756278 A CN 201510756278A CN 106682888 B CN106682888 B CN 106682888B
Authority
CN
China
Prior art keywords
user
order information
information
service
paid
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201510756278.6A
Other languages
English (en)
Other versions
CN106682888A (zh
Inventor
胡毅浩
张稳
叶海宏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to CN201510756278.6A priority Critical patent/CN106682888B/zh
Publication of CN106682888A publication Critical patent/CN106682888A/zh
Application granted granted Critical
Publication of CN106682888B publication Critical patent/CN106682888B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请公开了一种业务信息的处理方法以及装置,其中方法包括:获取第一用户选择的业务的业务信息,并针对第一用户选择的业务信息生成对应的第一订单信息,其中,第一订单信息包括业务的总金额;获取第一用户输入的N个第二用户的用户信息,其中,N为正整数;根据N个第二用户的用户信息将第一订单信息提供至N个第二用户;当N个第二用户中的第i个第二用户触发第一订单信息时,根据业务的总金额生成对应的随机金额,其中,i为正整数,1≤i≤N;以及根据随机金额创建第二订单信息,并将第二订单信息提供至第i个第二用户。该方法通过多人分担同一订单的支付金额,减轻了用户的经济负担,带动了用户的购买欲望,提升了用户体验。

Description

业务信息的处理方法和处理装置
技术领域
本申请涉及互联网技术领域,尤其涉及一种业务信息的处理方法和处理装置。
背景技术
随着互联网以及电子商务的快速发展,越来越多的用户通过电子商务来进行业务交易或享受相关服务。例如,由于电子商务方便快捷等特点,越来越多的用户通过在网上商店购买商品,当确定用户选择购买某个商品并对该商品进行支付时,可针对该商品的相关信息生成对应的订单信息,用户自己可针对该订单进行支付操作,也可以针对该订单找他人代为支付,用户自己或他人完成支付时,该商品即为该用户的所属物。
然而,针对某个业务的支付行为,无论是用户自己进行支付操作,还是他人代为支付,都是一个人对该业务完成支付行为,例如,当该业务(如商品)的金额比较大时,对一个人来说可能无法完全承担该业务对应的订单的支付操作,使得用户无法享受该业务,导致这种支付方式不再完全满足用户的需求,用户体验变差。
发明内容
本申请的目的旨在至少在一定程度上解决上述的技术问题之一。
为此,本申请的第一个目的在于提出一种业务信息的处理方法。该方法实现了将一个业务(如商品)的金额由多个人分多次支付完成,并在向多个人提供第一订单时强关联业务信息,扩大了业务的推广范围,同时通过多人分担同一订单的支付金额,减轻了用户的经济负担,带动了用户的购买欲望,提升了用户体验。
本申请的第二个目的在于提出一种业务信息的处理装置。
为达上述目的,本申请第一方面实施例的业务信息的处理方法,包括:获取第一用户选择的业务的业务信息,并针对所述第一用户选择的所述业务信息生成对应的第一订单信息,其中,所述第一订单信息包括所述业务的总金额;获取所述第一用户输入的N个第二用户的用户信息,其中,N为正整数;根据所述N个第二用户的用户信息将所述第一订单信息提供至所述N个第二用户;当所述N个第二用户中的第i个第二用户触发所述第一订单信息时,根据所述业务的总金额生成对应的随机金额,其中,i为正整数,1≤i≤N;以及根据所述随机金额创建第二订单信息,并将所述第二订单信息提供至所述第i个第二用户。
本申请实施例的业务信息的处理方法,可先获取第一用户选择的业务的业务信息,并针对第一用户选择的业务信息生成对应的第一订单信息,其中,第一订单信息包括业务的总金额,之后,可获取第一用户输入的N个第二用户的用户信息,并根据N个第二用户的用户信息将第一订单信息提供至N个第二用户,当N个第二用户中的第i个第二用户触发第一订单信息时,根据业务的总金额生成对应的随机金额,并根据随机金额创建第二订单信息,最后将第二订单信息提供至第i个第二用户,实现了将一个业务(如商品)的金额由多个人分多次支付完成,并在向多个人提供第一订单时强关联业务信息,扩大了业务的推广范围,同时通过多人分担同一订单的支付金额,减轻了用户的经济负担,带动了用户的购买欲望,提升了用户体验。
为达上述目的,本申请第二方面实施例的业务信息的处理装置,包括:第一获取模块,用于获取第一用户选择的业务的业务信息;第一生成模块,用于针对所述第一用户选择的所述业务信息生成对应的第一订单信息,其中,所述第一订单信息包括所述业务的总金额;第二获取模块,用于获取所述第一用户输入的N个第二用户的用户信息,其中,N为正整数;第一提供模块,用于根据所述N个第二用户的用户信息将所述第一订单信息提供至所述N个第二用户;第二生成模块,用于在所述N个第二用户中的第i个第二用户触发所述第一订单信息时,根据所述业务的总金额生成对应的随机金额,其中,i为正整数,1≤i≤N;创建模块,用于根据所述随机金额创建第二订单信息;以及第二提供模块,用于将所述第二订单信息提供至所述第i个第二用户。
本申请实施例的业务信息的处理装置,可通过第一获取模块获取第一用户选择的业务的业务信息,第一生成模块针对第一用户选择的业务信息生成对应的第一订单信息,其中,第一订单信息包括业务的总金额,第二获取模块获取第一用户输入的N个第二用户的用户信息,第一提供模块根据N个第二用户的用户信息将第一订单信息提供至N个第二用户,当N个第二用户中的第i个第二用户触发第一订单信息时,第二生成模块根据业务的总金额生成对应的随机金额,创建模块根据随机金额创建第二订单信息,第二提供模块将第二订单信息提供至第i个第二用户,实现了将一个业务(如商品)的金额由多个人分多次支付完成,并在向多个人提供第一订单时强关联业务信息,扩大了业务的推广范围,同时通过多人分担同一订单的支付金额,减轻了用户的经济负担,带动了用户的购买欲望,提升了用户体验。
本申请附加的方面和优点将在下面的描述中部分给出,部分将从下面的描述中变得明显,或通过本申请的实践了解到。
附图说明
本申请的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解,其中:
图1是根据本申请一个实施例的业务信息的处理方法的流程图;
图2是根据本申请一个实施例的第一订单信息生成过程的流程图;
图3是根据本申请另一个实施例的业务信息的处理方法的流程图;
图4是根据本申请一个实施例的业务信息的处理装置的结构框图;
图5是根据本申请另一个实施例的业务信息的处理装置的结构框图;
图6是根据本申请又一个实施例的业务信息的处理装置的结构框图;
图7是根据本申请再一个实施例的业务信息的处理装置的结构框图;以及
图8是根据本申请又另一个实施例的业务信息的处理装置的结构框图。
具体实施方式
下面详细描述本申请的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,旨在用于解释本申请,而不能理解为对本申请的限制。
下面参考附图描述本申请实施例的业务信息的处理方法以及处理装置。
图1是根据本申请一个实施例的业务信息的处理方法的流程图。如图1所示,该业务信息的处理方法可以包括:
S101,获取第一用户选择的业务的业务信息,并针对第一用户选择的业务信息生成对应的第一订单信息,其中,第一订单信息包括业务的总金额。
此外,在本申请的实施例中,上述业务可以是商品、服务等,业务信息可以是商品信息、或服务信息,以商品信息为例,该商品信息可包括但不限于商品的名称、ID(IDentity,身份标识号码)、类型、型号、颜色、商品的金额、商品所在页面的网页地址信息(如URL(Uniform Resource Locator,统一资源定位符)等)等。
以业务为商品为例,当第一用户想通过网上商店来购买某个商品时,可为用户提供一个基于AA收款的商品付款方式的AA收款创建接口,当第一用户针对选择的商品点击该接口时,可先确定该第一用户最终选择的商品,并获取该商品的商品信息,之后可针对该商品信息生成对应的第一订单信息。其中,用户可通过浏览用户的收藏夹、购物车信息来选择自己想要购买的商品,还可通过浏览该商品所在商店的页面信息来选择自己想要购买的商品,也就是说,本申请对用户想要购买的商品的选择途径不作具体限定。
需要说明的是,在本申请的实施例中,上述第一订单信息除了包括业务的总金额之后,还可包括但不限于业务的名称、ID、型号、类型、颜色、业务所在页面的网页地址信息等。可以理解,上述第一订单信息包括这些信息是为了后续第二用户在点击查看该第一订单信息时,除了可以了解到该第一订单信息对应业务的总金额,还可了解到该业务的其他相关信息,也可通过网页地址信息(如URL等)进入该业务的详情页面了解该业务的详情信息。由此,可以方便业务的推广。
S102,获取第一用户输入的N个第二用户的用户信息,其中,N为正整数。
具体地,当用户想将该业务的订单分享给其他好友,并通过其他好友来帮忙凑齐一部分或全部该业务的金额以帮助自己来分担购买高金额业务(如商品)带来的负担时,用户可选择至少一个好友(即N个第二用户),当用户已完成选择N个第二用户时,可获取这些N个第二用户的用户信息,如用户的名称、ID(IDentity,身份标识号码)等。
S103,根据N个第二用户的用户信息将第一订单信息提供至N个第二用户。
具体地,在获取到第一用户输入的N个第二用户的用户信息之后,可根据这些用户信息将上述生成的第一订单信息分别分享给对应的第二用户,以使第二用户根据自己实际情况是否对该第一订单信息进行查看或支付操作。可以理解,在本申请的实施例中,除了将第一订单信息分享至N个第二用户之后,还可生成对应的分享原由信息,并将该分享原由同第一订单信息一通提供给第二用户,使得第二用户了解到第一用户分享该第一订单的具体原因。
S104,当N个第二用户中的第i个第二用户触发第一订单信息时,根据业务的总金额生成对应的随机金额,其中,i为正整数,1≤i≤N。
具体而言,在本申请的实施例中,当第二用户接收到该第一订单信息并进入查看该第一订单信息时,可先获取针对该第一订单信息的剩余待支付金额,并根据剩余待支付金额生成随机金额,其中,随机金额小于或等于剩余待支付金额。
为了确保第二用户能够及时了解该第一订单的支付情况,并避免出现第二用户无止境地帮助为第一用户支付该第一订单,优选地,在本申请的一个实施例中,在根据剩余待支付金额生成随机金额之前,该处理方法还可包括:获取针对第一订单信息的已支付总金额,并判断针对第一订单信息的已支付总金额是否小于业务的总金额;如果是,则根据剩余待支付金额生成随机金额。也就是说,当前针对该第一订单中的总金额还没有通过第二用户全部凑齐时,可根据针对该第一订单的剩余待支付金额随机生成一个随机数,该随机数即为该第二用户将为第一用户支付的金额。
可选地,在本申请的一个实施例中,该处理方法还可包括:当针对第一订单信息的已支付总金额等于业务的总金额时,判定已完成针对第一订单信息的支付操作,并生成提示信息,以及将提示信息提供至第i个第二用户。
也就是说,当第二用户想通过该第一订单信息帮助第一用户来支付该业务的部分金额时,可点击进入该第一订单,在每个第二用户每次进入并查看该第一订单信息时,需要先检查该业务订单(即第一订单)中的总金额是否已经凑齐,即需要检查业务订单是否已完成支付,如判断针对该第一订单信息的已支付总金额是否小于业务的总金额,若是,则根据该第一订单的剩余待支付金额随机生成一个随机数,该随机数作为该第二用户应为第一用户支付的金额,否则,确定该第一订单的总金额已经凑齐,第一用户可对该第一订单完成支付操作,同时可生成提示信息并提供给第二用户,提示第二用户该第一订单已完成,以使得第二用户及时了解该第一订单的动态信息。
S105,根据随机金额创建第二订单信息,并将第二订单信息提供至第i个第二用户。
具体地,可根据上述生成的随机金额创建一个针对该第二用户的第二订单信息,并将该第二订单信息提供给对应的第二用户。其中,上述第一订单可理解为是根订单(或主订单),第二订单可理解是该根订单(或主订单)的子订单。
进一步地,在本申请的一个实施例中,在将第二订单信息提供至第i个第二用户之后,该处理方法还可包括:当第i个第二用户触发第二订单信息时,根据第二订单信息调用支付接口;当第i个第二用户通过支付接口完成针对第二订单信息的支付操作时,记录第i个第二用户的支付数据,支付数据为随机金额。也就是说,当第二用户想为第一用户支付这笔金额时,可确定支付对应的第二订单,并在接收到该第二用户的确定支付指令时,根据该第二订单信息调用支付接口,并生成相应的支付界面,以供第二用户进行支付,当第二用户完成该第二订单的支付操作时,可记录该第二用户的支付行为以及支付金额等数据。
举例而言,以业务为商品A,该商品A的售价金额为100元为例,当确定到第一用户想购买商品A时,可针对该商品A的商品信息生成对应的主订单(即上述的第一订单)信息,其中,该主订单信息中包括该商品A的总金额100元。第一用户想通过多个好友来为该主订单进行支付操作,也就是说,第一用户想通过多个好友来帮忙为该主订单进行买单,当第一用户完成好友的选择时,可获取第一用户所选择的N个第二用户的用户信息,并可根据用户信息将该主订单分别分享到对应的第二用户。当第二用户进入查看该主订单信息时,并判断该100元的主订单当前并没有完成支付,即还有剩余待支付的金额时,可先获取该100元的主订单当前的剩余待支付金额,假设为90,则可根据该剩余待支付金额90来随机生成一个随机数,假设为15,则根据该随机数15来创建一个子订单,该订单的支付金额为15元,并将该子订单提供给对应的第二用户,以便第二用户为第一用户分担主订单的支付金额。也就是说,在主订单的支付金额未凑齐之前,每当第二用户进入查看该主订单时,都会创建一个子订单,该子订单中的支付金额是随机生成的随机数,且该支付金额应小于或等于该主订单的剩余待支付金额。
为了避免特殊情况的发生,提高可用性,例如,当第一用户针对同一个业务(如商品)发起多次类似AA收款的行为时,可每次检查针对该业务是否存在上次第一订单是否完成,如果未完成,则延续上次未完成的第一订单,否则创建一个新的第一订单。具体而言,在本申请的实施例中,如图2所示,针对第一用户选择的业务信息生成对应的第一订单信息的具体实现过程可包括:判断是否针对第一用户选择的业务信息已生成第一订单信息(S201)。如果未生成,则针对第一用户选择的业务信息生成对应的第一订单信息(S202)。如果已生成,则进一步判断针对第一订单信息的已支付总金额是否等于业务的总金额(S203)。如果针对第一订单信息的已支付总金额等于业务的总金额,则执行步骤S202,即针对第一用户选择的业务信息生成新的第一订单信息。如果针对第一订单信息的已支付总金额小于业务的总金额,则调用已生成的第一订单信息(S204)。由此,确保针对同一业务只能对应一个未完成的第一订单。
综上,本申请的业务信息的处理方法通过将用户想购买的业务(如商品)对应的订单分摊给多个人,当这些人想为用户分担该订单的付款金额时,可生成该订单的子订单,这些人通过对应的子订单来为用户支付该订单的部分金额,实现了将一个业务(如商品)的金额由多个人分多次支付完成,并在向多个人提供第一订单时强关联业务信息,扩大了业务的推广范围,同时通过多人分担同一订单的支付金额,减轻了用户的经济负担,带动了用户的购买欲望,提升了用户体验。
本申请实施例的业务信息的处理方法,可先获取第一用户选择的业务的业务信息,并针对第一用户选择的业务信息生成对应的第一订单信息,其中,第一订单信息包括业务的总金额,之后,可获取第一用户输入的N个第二用户的用户信息,并根据N个第二用户的用户信息将第一订单信息提供至N个第二用户,当N个第二用户中的第i个第二用户触发第一订单信息时,根据业务的总金额生成对应的随机金额,并根据随机金额创建第二订单信息,最后将第二订单信息提供至第i个第二用户,实现了将一个业务(如商品)的金额由多个人分多次支付完成,并在向多个人提供第一订单时强关联业务信息,扩大了业务的推广范围,同时通过多人分担同一订单的支付金额,减轻了用户的经济负担,带动了用户的购买欲望,提升了用户体验。
图3是根据本申请另一个实施例的业务信息的处理方法的流程图。
为了保障当第一订单的已支付总金额与待支付订单金额的和值大于业务的总金额时,新的第二用户也能够给该第一订单进行支付操作,在本申请的实施例中,在根据随机金额创建第二订单信息之前,可先进行判断操作,之后根据该判断结果进行相应的操作。具体地,如图3所示,该业务信息的处理方法可以包括:
S301,获取第一用户选择的业务的业务信息,并针对第一用户选择的业务信息生成对应的第一订单信息,其中,第一订单信息包括业务的总金额。
S302,获取第一用户输入的N个第二用户的用户信息,其中,N为正整数。
S303,根据N个第二用户的用户信息将第一订单信息提供至N个第二用户。
S304,当N个第二用户中的第i个第二用户触发第一订单信息时,根据业务的总金额生成对应的随机金额,其中,i为正整数,1≤i≤N。
S305,获取针对所有第二订单信息的已支付总金额以及剩余待支付总金额。
具体地,在生成随机金额之后,可先获取针对所有的第二订单的已支付总金额,以及该所有的第二订单的剩余待支付总金额。例如,假设第一订单的支付总金额为10元,第二用户的数个为3个,即第二用户1、第二用户2、第二用户3,第二用户1点击了第一订单,并支付了对应的第二订单1,支付的金额为3元,假设第二用户2点击了第一订单,创建了该第二用户2对应的第二订单2,该第二订单2的应支付金额为5元,但并没有支付该第二订单2,第三用户3尚未点击第一订单,则此时所有的第二订单的已支付总金额应为第二订单1的金额3元,所有的第二订单的剩余待支付总金额应为第二订单2的金额5元。
S306,判断针对所有第二订单信息的已支付总金额与剩余待支付总金额的和值是否小于业务的总金额。
可以理解,以上述步骤S305中的例子为例,此时,可判断针对所有第二订单信息的已支付总金额与剩余待支付总金额的和值小于业务的总金额10元。又如,假设第三用户3点击了第一订单,创建了该第二用户3对应的第二订单3,该第二订单3的应支付金额为2元,但并没有支付该第二订单3,此时,可判断针对所有第二订单信息的已支付总金额与剩余待支付总金额的和值等于业务的总金额10元。
S307,如果否,则删除创建时间最长、且未完成支付操作的第二订单信息,直至针对所有第二订单信息的已支付总金额与剩余待支付总金额的和值小于业务的总金额。
具体地,当判断针对所有第二订单信息的已支付总金额与剩余待支付总金额的和值等于或大于业务的总金额时,可将创建时间最长、且未完成支付操作的第二订单信息进行失效操作,如此重复循环直到针对所有第二订单信息的已支付总金额与剩余待支付总金额的和值小于业务的总金额为止。由此,可以保证新的第二用户为该第一订单支付剩余的金额。
S308,如果是,则根据随机金额创建第二订单信息,并将第二订单信息提供至第i个第二用户。
本申请实施例的业务信息的处理方法,在根据随机金额创建第二订单信息之前,可先获取针对所有第二订单信息的已支付总金额以及剩余待支付总金额,并判断针对所有第二订单信息的已支付总金额与剩余待支付总金额的和值是否小于业务的总金额,若否,则删除创建时间最长、且未完成支付操作的第二订单信息,直至针对所有第二订单信息的已支付总金额与剩余待支付总金额的和值小于业务的总金额为止,可以保证新的第二用户为该第一订单支付剩余的金额。
为了提高可用性,以及保证第一用户能够尽可能多的凑齐第一订单的支付金额,优选地,在本申请的一个实施例中,在根据业务的总金额生成对应的随机金额之前,该处理方法还可包括:获取第i个第二用户与第一用户之间的关系友好程度。其中,在本实施例中,根据业务的总金额生成对应的随机金额的具体实现方式可如下:根据第i个第二用户与第一用户之间的关系友好程度、以及业务的总金额生成与第i个第二用户对应的随机金额。也就是说,在生成随机金额并创建第二订单时,可根据该第二用户与第一用户之间的关系友好程度随机生成一个随机金额,并根据该随机金额创建第二订单信息。
与上述几种实施例提供的业务信息的处理方法相对应,本申请的一种实施例还提供一种业务信息的处理装置,由于本申请实施例提供的业务信息的处理装置与上述几种实施例提供的业务信息的处理方法相对应,因此在前述业务信息的处理方法的实施方式也适用于本实施例提供的业务信息的处理装置,在本实施例中不再详细描述。图4是根据本申请一个实施例的业务信息的处理装置的结构框图。如图4所示,该业务信息的处理装置可以包括:第一获取模块10、第一生成模块20、第二获取模块30、第一提供模块40、第二生成模块50、创建模块60和第二提供模块70。
具体地,第一获取模块10可用于获取第一用户选择的业务的业务信息。
第一生成模块20可用于针对第一用户选择的业务信息生成对应的第一订单信息,其中,第一订单信息包括业务的总金额。
为了避免特殊情况的发生,提高可用性,例如,当第一用户针对同一个业务(如商品)发起多次类似AA收款的行为时,可每次检查针对该业务是否存在上次第一订单是否完成,如果未完成,则延续上次未完成的第一订单,否则创建一个新的第一订单。具体而言,在本申请的实施例中,第一生成模块20可先判断是否针对第一用户选择的业务信息已生成第一订单信息,如果未生成,则针对第一用户选择的业务信息生成对应的第一订单信息,如果已生成,则进一步判断针对第一订单信息的已支付总金额是否等于业务的总金额,如果针对第一订单信息的已支付总金额等于业务的总金额,则针对第一用户选择的业务信息生成新的第一订单信息,如果针对第一订单信息的已支付总金额小于业务的总金额,则调用已生成的第一订单信息。由此,确保针对同一业务只能对应一个未完成的第一订单。
第二获取模块30可用于获取第一用户输入的N个第二用户的用户信息,其中,N为正整数。
第一提供模块40可用于根据N个第二用户的用户信息将第一订单信息提供至N个第二用户。
第二生成模块50可用于在N个第二用户中的第i个第二用户触发第一订单信息时,根据业务的总金额生成对应的随机金额,其中,i为正整数,1≤i≤N。
创建模块60可用于根据随机金额创建第二订单信息。
第二提供模块70可用于将第二订单信息提供至第i个第二用户。
进一步地,在本申请的一个实施例中,如图5所示,该处理装置还可包括:调用模块80和记录模块90。具体地,调用模块80可用于在将第二订单信息提供至第i个第二用户之后,当第i个第二用户触发第二订单信息时,根据第二订单信息调用支付接口。记录模块90可用于在第i个第二用户通过支付接口完成针对第二订单信息的支付操作时,记录第i个第二用户的支付数据,支付数据为随机金额。
也就是说,当第二用户想为第一用户支付这笔金额时,可确定支付对应的第二订单,调用模块80在接收到该第二用户的确定支付指令时,根据该第二订单信息调用支付接口,并生成相应的支付界面,以供第二用户进行支付,当第二用户完成该第二订单的支付操作时,记录模块90可记录该第二用户的支付行为以及支付金额等数据。
在本申请的实施例中,第二生成模块50根据业务的总金额生成对应的随机金额的具体实现过程可如下:获取针对第一订单信息的剩余待支付金额;根据剩余待支付金额生成随机金额,其中,随机金额小于或等于剩余待支付金额。
为了确保第二用户能够及时了解该第一订单的支付情况,并避免出现第二用户无止境地帮助为第一用户支付该第一订单,进一步地,在本申请的一个实施例中,如图6所示,该处理装置还可包括第一判断模块100,第一判断模块100可用于获取针对第一订单信息的已支付总金额,并判断针对第一订单信息的已支付总金额是否小于业务的总金额。其中,在本申请的实施例中,第二生成模块50还可用于在第一判断模块100判断针对第一订单信息的已支付总金额小于业务的总金额时,根据剩余待支付金额生成随机金额。
可选地,在本申请的实施例中,如图6所示,该处理装置还可包括提示模块110,提示模块110可用于在第一判断模块100判断针对第一订单信息的已支付总金额等于业务的总金额时,判定已完成针对第一订单信息的支付操作,并生成提示信息,以及将提示信息提供至第i个第二用户。
为了保障当第一订单的已支付总金额与待支付订单金额的和值大于业务的总金额时,新的第二用户也能够给该第一订单进行支付操作,进一步地,在本申请的一个实施例中,如图7所示,该处理装置还可包括:第三获取模块120、第二判断模块130和删除模块140。
具体地,第三获取模块120可用于在根据随机金额创建第二订单信息之前,获取针对所有第二订单信息的已支付总金额以及剩余待支付总金额。
第二判断模块130可用于判断针对所有第二订单信息的已支付总金额与剩余待支付总金额的和值是否小于业务的总金额。
删除模块140可用于在第二判断模块130判断针对所有第二订单信息的已支付总金额与剩余待支付总金额的和值大于或等于业务的总金额时,删除创建时间最长、且未完成支付操作的第二订单信息,直至针对所有第二订单信息的已支付总金额与剩余待支付总金额的和值小于业务的总金额。
其中,在本实施例中,创建模块60还可用于在第二判断模块130判断针对所有第二订单信息的已支付总金额与剩余待支付总金额的和值小于业务的总金额时,根据随机金额创建第二订单信息。
为了提高可用性,以及保证第一用户能够尽可能多的凑齐第一订单的支付金额,优选地,在本申请的一个实施例中,如图8所示,该处理装置还可包括第四获取模块150,第四获取模块150可用于在根据业务的总金额生成对应的随机金额之前,获取第i个第二用户与第一用户之间的关系友好程度。其中,在本实施例中,第二生成模块50具体用于:根据第i个第二用户与第一用户之间的关系友好程度、以及业务的总金额生成与第i个第二用户对应的随机金额。
本申请实施例的业务信息的处理装置,可通过第一获取模块获取第一用户选择的业务的业务信息,第一生成模块针对第一用户选择的业务信息生成对应的第一订单信息,其中,第一订单信息包括业务的总金额,第二获取模块获取第一用户输入的N个第二用户的用户信息,第一提供模块根据N个第二用户的用户信息将第一订单信息提供至N个第二用户,当N个第二用户中的第i个第二用户触发第一订单信息时,第二生成模块根据业务的总金额生成对应的随机金额,创建模块根据随机金额创建第二订单信息,第二提供模块将第二订单信息提供至第i个第二用户,实现了将一个业务(如商品)的金额由多个人分多次支付完成,并在向多个人提供第一订单时强关联业务信息,扩大了业务的推广范围,同时通过多人分担同一订单的支付金额,减轻了用户的经济负担,带动了用户的购买欲望,提升了用户体验。
在本申请的描述中,需要理解的是,术语“第一”、“第二”、“第三”、“第四”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”、“第三”、“第四”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中,“多个”的含义是至少两个,例如两个,三个等,除非另有明确具体的限定。
在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为,表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分,并且本申请的优选实施方式的范围包括另外的实现,其中可以不按所示出或讨论的顺序,包括根据所涉及的功能按基本同时的方式或按相反的顺序,来执行功能,这应被本申请的实施例所属技术领域的技术人员所理解。
在流程图中表示或在此以其他方式描述的逻辑和/或步骤,例如,可以被认为是用于实现逻辑功能的可执行指令的定序列表,可以具体实现在任何计算机可读介质中,以供指令执行***、装置或设备(如基于计算机的***、包括处理器的***或其他可以从指令执行***、装置或设备取指令并执行指令的***)使用,或结合这些指令执行***、装置或设备而使用。就本说明书而言,"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行***、装置或设备或结合这些指令执行***、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下:具有一个或多个布线的电连接部(电子装置),便携式计算机盘盒(磁装置),随机存取存储器(RAM),只读存储器(ROM),可擦除可编辑只读存储器(EPROM或闪速存储器),光纤装置,以及便携式光盘只读存储器(CDROM)。另外,计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质,因为可以例如通过对纸或其他介质进行光学扫描,接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序,然后将其存储在计算机存储器中。
应当理解,本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中,多个步骤或方法可以用存储在存储器中且由合适的指令执行***执行的软件或固件来实现。例如,如果用硬件来实现,和在另一实施方式中一样,可用本领域公知的下列技术中的任一项或他们的组合来实现:具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路,具有合适的组合逻辑门电路的专用集成电路,可编程门阵列(PGA),现场可编程门阵列(FPGA)等。
本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,该程序在执行时,包括方法实施例的步骤之一或其组合。
此外,在本申请各个实施例中的各功能单元可以集成在一个处理模块中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。
上述提到的存储介质可以是只读存储器,磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例,可以理解的是,上述实施例是示例性的,不能理解为对本申请的限制,本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (14)

1.一种业务信息的处理方法,其特征在于,包括以下步骤:
获取第一用户选择的业务的业务信息,并针对所述第一用户选择的所述业务信息生成对应的第一订单信息,其中,所述第一订单信息包括所述业务的总金额;
获取所述第一用户输入的N个第二用户的用户信息,其中,N为正整数;
根据所述N个第二用户的用户信息将所述第一订单信息提供至所述N个第二用户;
当所述N个第二用户中的第i个第二用户触发所述第一订单信息时,根据所述业务的总金额生成对应的随机金额,包括:根据针对所述第一订单信息的剩余待支付金额生成所述随机金额,其中,所述随机金额小于或等于所述剩余待支付金额;其中,i为正整数,1≤i≤N;以及
根据所述随机金额创建第二订单信息,并将所述第二订单信息提供至所述第i个第二用户。
2.如权利要求1所述的业务信息的处理方法,其特征在于,在将所述第二订单信息提供至所述第i个第二用户之后,所述方法还包括:
当所述第i个第二用户触发所述第二订单信息时,根据所述第二订单信息调用支付接口;
当所述第i个第二用户通过所述支付接口完成针对所述第二订单信息的支付操作时,记录所述第i个第二用户的支付数据,所述支付数据为所述随机金额。
3.如权利要求1所述的业务信息的处理方法,其特征在于,在根据针对所述第一订单信息的剩余待支付金额生成所述随机金额之前,所述方法还包括:
获取针对所述第一订单信息的已支付总金额,并判断所述针对所述第一订单信息的已支付总金额是否小于所述业务的总金额;
如果是,则根据针对所述第一订单信息的剩余待支付金额生成所述随机金额。
4.如权利要求3所述的业务信息的处理方法,其特征在于,还包括:
当所述针对所述第一订单信息的已支付总金额等于所述业务的总金额时,判定已完成针对所述第一订单信息的支付操作,并生成提示信息,以及将所述提示信息提供至所述第i个第二用户。
5.如权利要求2所述的业务信息的处理方法,其特征在于,在根据所述随机金额创建第二订单信息之前,所述方法还包括:
获取针对所有第二订单信息的已支付总金额以及剩余待支付总金额;
判断所述针对所有第二订单信息的已支付总金额与所述剩余待支付总金额的和值是否小于所述业务的总金额;
如果否,则删除创建时间最长、且未完成支付操作的第二订单信息,直至所述针对所有第二订单信息的已支付总金额与所述剩余待支付总金额的和值小于所述业务的总金额;
如果是,则根据所述随机金额创建第二订单信息。
6.如权利要求1所述的业务信息的处理方法,其特征在于,在根据所述业务的总金额生成对应的随机金额之前,所述方法还包括:
获取所述第i个第二用户与所述第一用户之间的关系友好程度;
其中,根据所述业务的总金额生成对应的随机金额具体包括:
根据所述第i个第二用户与所述第一用户之间的关系友好程度、以及所述业务的总金额生成与所述第i个第二用户对应的所述随机金额。
7.如权利要求1所述的业务信息的处理方法,其特征在于,针对所述第一用户选择的所述业务信息生成对应的第一订单信息,具体包括:
判断是否针对所述第一用户选择的所述业务信息已生成所述第一订单信息;
如果未生成,则针对所述第一用户选择的所述业务信息生成对应的第一订单信息;
如果已生成,则进一步判断针对所述第一订单信息的已支付总金额是否等于所述业务的总金额;
如果针对所述第一订单信息的已支付总金额等于所述业务的总金额,则针对所述第一用户选择的所述业务信息生成新的所述第一订单信息;
如果针对所述第一订单信息的已支付总金额小于所述业务的总金额,则调用所述已生成的所述第一订单信息。
8.一种业务信息的处理装置,其特征在于,包括:
第一获取模块,用于获取第一用户选择的业务的业务信息;
第一生成模块,用于针对所述第一用户选择的所述业务信息生成对应的第一订单信息,其中,所述第一订单信息包括所述业务的总金额;
第二获取模块,用于获取所述第一用户输入的N个第二用户的用户信息,其中,N为正整数;
第一提供模块,用于根据所述N个第二用户的用户信息将所述第一订单信息提供至所述N个第二用户;
第二生成模块,用于在所述N个第二用户中的第i个第二用户触发所述第一订单信息时,根据所述业务的总金额生成对应的随机金额,包括:根据针对所述第一订单信息的剩余待支付金额生成所述随机金额,其中,所述随机金额小于或等于所述剩余待支付金额;其中,i为正整数,1≤i≤N;
创建模块,用于根据所述随机金额创建第二订单信息;以及
第二提供模块,用于将所述第二订单信息提供至所述第i个第二用户。
9.如权利要求8所述的业务信息的处理装置,其特征在于,还包括:
调用模块,用于在将所述第二订单信息提供至所述第i个第二用户之后,当所述第i个第二用户触发所述第二订单信息时,根据所述第二订单信息调用支付接口;
记录模块,用于在所述第i个第二用户通过所述支付接口完成针对所述第二订单信息的支付操作时,记录所述第i个第二用户的支付数据,所述支付数据为所述随机金额。
10.如权利要求8所述的业务信息的处理装置,其特征在于,还包括:
第一判断模块,用于获取针对所述第一订单信息的已支付总金额,并判断所述针对所述第一订单信息的已支付总金额是否小于所述业务的总金额;
其中,所述第二生成模块还用于在所述第一判断模块判断所述针对所述第一订单信息的已支付总金额小于所述业务的总金额时,根据针对所述第一订单信息的剩余待支付金额生成所述随机金额。
11.如权利要求10所述的业务信息的处理装置,其特征在于,还包括:
提示模块,用于在第一判断模块判断所述针对所述第一订单信息的已支付总金额等于所述业务的总金额时,判定已完成针对所述第一订单信息的支付操作,并生成提示信息,以及将所述提示信息提供至所述第i个第二用户。
12.如权利要求9所述的业务信息的处理装置,其特征在于,还包括:
第三获取模块,用于在根据所述随机金额创建第二订单信息之前,获取针对所有第二订单信息的已支付总金额以及剩余待支付总金额;
第二判断模块,用于判断所述针对所有第二订单信息的已支付总金额与所述剩余待支付总金额的和值是否小于所述业务的总金额;
删除模块,用于在所述第二判断模块判断所述针对所有第二订单信息的已支付总金额与所述剩余待支付总金额的和值大于或等于所述业务的总金额时,删除创建时间最长、且未完成支付操作的第二订单信息,直至所述针对所有第二订单信息的已支付总金额与所述剩余待支付总金额的和值小于所述业务的总金额;
其中,所述创建模块还用于在所述第二判断模块判断所述针对所有第二订单信息的已支付总金额与所述剩余待支付总金额的和值小于所述业务的总金额时,根据所述随机金额创建第二订单信息。
13.如权利要求8所述的业务信息的处理装置,其特征在于,还包括:
第四获取模块,用于在根据所述业务的总金额生成对应的随机金额之前,获取所述第i个第二用户与所述第一用户之间的关系友好程度;
其中,所述第二生成模块具体用于:
根据所述第i个第二用户与所述第一用户之间的关系友好程度、以及所述业务的总金额生成与所述第i个第二用户对应的所述随机金额。
14.如权利要求8所述的业务信息的处理装置,其特征在于,所述第一生成模块具体用于:
判断是否针对所述第一用户选择的所述业务信息已生成所述第一订单信息;
如果未生成,则针对所述第一用户选择的所述业务信息生成对应的第一订单信息;
如果已生成,则进一步判断针对所述第一订单信息的已支付总金额是否等于所述业务的总金额;
如果针对所述第一订单信息的已支付总金额等于所述业务的总金额,则针对所述第一用户选择的所述业务信息生成新的所述第一订单信息;
如果针对所述第一订单信息的已支付总金额小于所述业务的总金额,则调用所述已生成的所述第一订单信息。
CN201510756278.6A 2015-11-09 2015-11-09 业务信息的处理方法和处理装置 Active CN106682888B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510756278.6A CN106682888B (zh) 2015-11-09 2015-11-09 业务信息的处理方法和处理装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510756278.6A CN106682888B (zh) 2015-11-09 2015-11-09 业务信息的处理方法和处理装置

Publications (2)

Publication Number Publication Date
CN106682888A CN106682888A (zh) 2017-05-17
CN106682888B true CN106682888B (zh) 2021-03-23

Family

ID=58863337

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510756278.6A Active CN106682888B (zh) 2015-11-09 2015-11-09 业务信息的处理方法和处理装置

Country Status (1)

Country Link
CN (1) CN106682888B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108960800A (zh) * 2017-05-20 2018-12-07 高春花 一种基于通讯群的支付方案多样化产生方法
CN107609853A (zh) * 2017-10-11 2018-01-19 深圳给乐信息科技有限公司 一种基于随机抽签的群体支付金额分配方法及***
CN108335098B (zh) * 2018-01-24 2023-03-14 创新先进技术有限公司 一种多人付款的方法和装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1591499A (zh) * 2003-08-28 2005-03-09 黄金富 购物消费后由不在身边的朋友用手机代为确认付款的方法
CN104850993A (zh) * 2015-06-01 2015-08-19 走遍世界(北京)信息技术有限公司 支付方法及装置
CN104933558A (zh) * 2015-05-29 2015-09-23 百度在线网络技术(北京)有限公司 订单支付方法和装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1501057A1 (en) * 2003-07-21 2005-01-26 Sap Ag Method and sofware application and system for automated bill processing

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1591499A (zh) * 2003-08-28 2005-03-09 黄金富 购物消费后由不在身边的朋友用手机代为确认付款的方法
CN104933558A (zh) * 2015-05-29 2015-09-23 百度在线网络技术(北京)有限公司 订单支付方法和装置
CN104850993A (zh) * 2015-06-01 2015-08-19 走遍世界(北京)信息技术有限公司 支付方法及装置

Also Published As

Publication number Publication date
CN106682888A (zh) 2017-05-17

Similar Documents

Publication Publication Date Title
JP7198853B2 (ja) ユーザに価格変更を通知するウェブブラウザ内のウィッシュリストユーザインタフェース
US20220148043A1 (en) Methods and systems for multi-merchant couponing
CN107180371B (zh) 使用优惠券购买商品的方法、***和计算机可读存储介质
CN105654293B (zh) 支付方法及装置
US20170323335A1 (en) Method for advertising or selling products on basis of user's social network service activity
CN110490572B (zh) 一种支付方法、装置、相关设备及***
KR20160113716A (ko) 3d 프린팅에서의 연합 프린터 액세스 기법
CN112948521B (zh) 对象处置方法及装置
US20090182573A1 (en) Multi-Party Payment System for Online Creative Works Sale
CN112948522B (zh) 对象处置方法及装置
US20150154519A1 (en) Analyzing incomplete transactions
CN106682888B (zh) 业务信息的处理方法和处理装置
US20140278595A1 (en) Venue ticket buyback with smart pricing
JP5864651B2 (ja) 対話型ネットワークベースの情報オブジェクトの貨幣化のための方法、システム及び媒体
CN112633933A (zh) 一种信息推荐的方法及装置
KR20230009336A (ko) 리뷰 컨텐츠의 구매 기여도에 기초한 리워드 제공 서비스를 제공하는 제공 방법 및 이를 구현하는 시스템
US20140236699A1 (en) Personalized product pricing
CN112734460B (zh) 数据处理、支付数据输出、支付优惠数据提供方法及装置
KR101582244B1 (ko) 구매자의 소개를 이용한 소셜 쇼핑 시스템 및 방법
KR102341942B1 (ko) 확인 코드를 이용한 리워드 제공 방법 및 시스템
WO2016109056A1 (en) Dynamic product placement based on perceived value
KR101784823B1 (ko) 소비자 크라우드 검증 정보 제공 장치 및 방법
CN116188072A (zh) 一种用户权益处理***及会员权益处理***
US20190311335A1 (en) Systems and methods for in-application content management
JP2020113005A (ja) 情報処理方法、情報処理装置、及びプログラム

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1237105

Country of ref document: HK

GR01 Patent grant
GR01 Patent grant