CN113516460A - 预付订单处理方法、客户端、服务器及*** - Google Patents

预付订单处理方法、客户端、服务器及*** Download PDF

Info

Publication number
CN113516460A
CN113516460A CN202110507542.8A CN202110507542A CN113516460A CN 113516460 A CN113516460 A CN 113516460A CN 202110507542 A CN202110507542 A CN 202110507542A CN 113516460 A CN113516460 A CN 113516460A
Authority
CN
China
Prior art keywords
settlement
prepaid
amount
preferential
service
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.)
Pending
Application number
CN202110507542.8A
Other languages
English (en)
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.)
Shanghai Bilibili Technology Co Ltd
Original Assignee
Shanghai Bilibili Technology Co 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 Shanghai Bilibili Technology Co Ltd filed Critical Shanghai Bilibili Technology Co Ltd
Priority to CN202110507542.8A priority Critical patent/CN113516460A/zh
Publication of CN113516460A publication Critical patent/CN113516460A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/28—Pre-payment schemes, e.g. "pay before"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders

Landscapes

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

Abstract

本申请提供预付订单处理方法、客户端、服务器及***，其中所述预付订单处理方法包括：在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息；在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取针对所述预付业务的结算优惠数额，所述结算优惠数额根据所述预付业务对应的预付订单的生成顺序确定；根据所述结算优惠数额，确定并展示所述用户对应的待结算数额。如此，在预付阶段给予用户相应的结算优惠数额，促进了预付业务的发展，减少了库存积压，且可以节省服务器的处理资源。

Description

预付订单处理方法、客户端、服务器及***
技术领域
本申请涉及计算机技术领域，特别涉及预付订单处理方法。本申请同时涉及预付订单处理客户端、服务器及***，计算设备，以及计算机可读存储介质。
背景技术
随着计算机技术和互联网技术的快速发展，通过网络进行线上交易，如网购、转账等越来越受到人们的推崇。随着线上交易的普及，越来越多的预付业务应用而生，现有技术中，用户可以在预付阶段先预付一部分定金，订购相应的预付业务，然后在结算阶段，再结清该预付业务对应的全部款项。
然而，用户在预付阶段支付了定金后，需要间隔一段时间后在结算阶段支付尾款，然后再过一段时间，才可以获取到自己订购的业务内容，从用户第一次支付定金至用户获取到自己订购的业务内容可能会间隔较长时间，导致很多用户在支付了定金后，又不想要订购该业务，发起退订，从而导致预付业务的退款率较高，预付业务销售受阻，库存积压严重，并且用户先进行预订，再进行退订，可能会导致服务器压力过大，浪费服务器的处理资源。
发明内容
有鉴于此，本申请实施例提供了一种预付订单处理方法。本申请同时涉及一种预付订单处理客户端、服务器及***，一种计算设备，以及一种计算机可读存储介质，以解决现有技术中存在的预定业务销售受阻、库存积压严重及浪费服务器的处理资源的问题。
根据本申请实施例的第一方面，提供了一种预付订单处理方法，应用于客户端，包括：
在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息；
在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额，所述结算优惠数额根据所述预付业务对应的预付订单的生成顺序确定；
根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额。
根据本申请实施例的第二方面，提供了一种预付订单处理方法，应用于服务器，包括：
接收预付业务的预定请求，并根据所述预定请求，生成对应的预付订单，返回预定成功信息；
根据所述预付订单的生成时间，确定所述预付订单对应的生成顺序；
根据所述生成顺序，确定所述预付业务对应的结算优惠数额；
确定发送所述预定请求的用户账号，向所述用户账号发放所述结算优惠数额对应的优惠。
根据本申请实施例的第三方面，提供了一种预付订单处理客户端，包括：
发送模块，被配置为在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息；
获取模块，被配置为在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额，所述结算优惠数额根据所述预付业务对应的预付订单的生成顺序确定；
第一展示模块，被配置为根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额。
根据本申请实施例的第四方面，提供了一种预付订单处理服务器，包括：
生成模块，被配置为接收预付业务的预定请求，并根据所述预定请求，生成对应的预付订单，返回预定成功信息；
第一确定模块，被配置为根据所述预付订单的生成时间，确定所述预付订单对应的生成顺序；
第二确定模块，被配置为根据所述生成顺序，确定所述预付业务对应的结算优惠数额；
发放模块，被配置为确定发送所述预定请求的用户账号，向所述用户账号发放所述结算优惠数额对应的优惠。
根据本申请实施例的第五方面，提供了一种预付订单处理***，包括：
预付订单处理客户端，被配置为在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息；在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额；根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额；
预付订单处理服务器，被配置为接收预付业务的预定请求，并根据所述预定请求，生成对应的预付订单，返回预定成功信息；根据所述预付订单的生成时间，确定所述预付订单对应的生成顺序；根据所述生成顺序，确定所述预付业务对应的结算优惠数额；确定发送所述预定请求的用户账号，向所述用户账号发放所述结算优惠数额对应的优惠。
根据本申请实施例的第六方面，提供了一种计算设备，包括：
存储器和处理器；
所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令以实现任意所述预付订单处理方法的步骤。
根据本申请实施例的第七方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现任意所述预付订单处理方法的步骤。
本申请提供的预付订单处理方法，在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息；在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额，所述结算优惠数额根据所述预付业务对应的预付订单的生成顺序确定；根据所述结算优惠数额，确定并展示所述用户对应的待结算数额。这种情况下，可以根据用户在预付阶段完成预订的排列顺序，向用户发放相应结算优惠数额的优惠，在结算阶段时，用户可以使用该结算优惠数额进行结算。如此，在预付阶段，不同的预订顺序可以获得不同的结算优惠数额，使得越先预订的用户可以获取越高的结算优惠数额，从而可以吸引更多用户尽快对预付业务进行预订，且结算优惠数额在结算阶段才可以使用，从而可以吸引用户不进行退订，促进了预付业务的发展，减少了库存积压，实现了去库存的效果，且降低了用户先进行预订，再进行退订的比例，进而降低了服务器的处理压力，节省了服务器的处理资源。
附图说明
图1是本申请一实施例提供的第一种预付订单处理方法的流程图；
图2是本申请一实施例提供的一种优惠页面示意图；
图3是本申请一实施例提供的另一种优惠页面示意图；
图4是本申请一实施例提供的一种订购确认界面示意图；
图5是本申请一实施例提供的一种结算优惠名单示意图；
图6是本申请一实施例提供的另一种结算优惠名单示意图；
图7是本申请一实施例提供的一种结算页面示意图；
图8是本申请一实施例提供的第二种预付订单处理方法的流程图；
图9是本申请一实施例提供的第三种预付订单处理方法的流程图；
图10是本申请一实施例提供的一种应用于网上购物场景中的预付订单处理方法的处理流程图；
图11是本申请一实施例提供的一种预付订单处理客户端的结构示意图；
图12是本申请一实施例提供的一种预付订单处理服务器的结构示意图；
图13是本申请一实施例提供的一种预付订单处理***的结构示意图；
图14是本申请一实施例提供的一种计算设备的结构框图。
具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。
在本申请一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请一个或多个实施例。在本申请一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本申请一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本申请一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
在本申请中，提供了一种预付订单处理方法，本申请同时涉及一种预付订单处理客户端、服务器及***，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。
图1示出了根据本申请一实施例提供的第一种预付订单处理方法的流程图，应用于客户端，具体包括以下步骤：
步骤102：在预付业务处于预付阶段前，展示所述预付业务的优惠页面。
实际应用中，用户可以在预付阶段先预付一部分定金，订购相应的预付业务，然后在结算阶段，再结清该预付业务对应的全部款项。然而，很多用户在支付了定金后，又不想要订购该业务，发起退订，从而导致预付业务的退款率较高，预付业务销售受阻，库存积压严重，并且用户先进行预订，再进行退订，可能会导致服务器压力过大，浪费服务器的处理资源。
因而，为了促进预付业务的发展及节省服务器的处理资源，本申请提供了一种预付订单处理方法，可以在预付业务处于预付阶段前，展示所述预付业务的优惠页面；之后，在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息；在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额，所述结算优惠数额根据所述预付业务对应的预付订单的生成顺序确定；根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额。如此，在预付阶段，不同的预订顺序可以获得不同的结算优惠数额，使得越先预订的用户可以获取越高的结算优惠数额，从而可以吸引更多用户尽快对预付业务进行预订，且结算优惠数额在结算阶段才可以使用，从而可以吸引用户不进行退订。
具体的，预付业务是指需要预先进行订购的业务，即预付业务分为两个阶段，预付阶段和结算阶段，预付阶段是指订购预付业务的时间周期，如1月1日至1月15日为预付阶段，用户可以在1月1日至1月15日之间任意时间进行预定。在预付阶段，用户只需先支付一部分预定数额即可，在结算阶段，再结算剩余的数额。例如，预付业务可以为当前网购中的预售商品，在预售阶段，用户先支付商品的定金，然后在付尾款阶段，再结算剩余的尾款。
另外，优惠页面是指包括预付业务的结算优惠信息和预付控件的页面，通过该优惠页面，用户可以获知预付业务的优惠信息，当用户想要订购该预付业务时，且预付业务进入预付阶段时，可以在该优惠页面中通过触发预付控件，发送预定请求，进行订购。需要说明的是，预付业务进入预付阶段前优惠页面中的预付控件不可触发，当确定预付业务进入预付阶段时，优惠页面中的预付控件转变为可触发。
本实施例一个可选的实施方式中，预付业务的优惠页面往往是商家预先设置的，商家可以通过访问服务器，预先设置预付业务相应的优惠信息，因而客户端在展示预付业务的优惠页面时，需要从服务器中获取，也即在预付业务处于预付阶段前，展示所述预付业务的优惠页面，具体实现过程可以如下：
向服务器发送所述预付业务的优惠页面获取请求；
接收并展示所述服务器返回的所述预付业务的优惠页面，所述优惠页面包括所述预付业务的预付阶段、结算阶段、预付数额、结算数额、结算优惠数额获取规则和最高结算优惠数额。
具体的，预付业务的优惠页面获取请求是指客户端向服务器请求获取预付业务的优惠页面的请求，该优惠页面获取请求中携带要获取的预付业务的业务标识，当预付业务为预售商品时，该业务标识可以是预售商品的SPU(Standard Product Unit，标准化产品单元)，SPU是一组可复用、易检索的标准化信息的集合，该集合描述了一个“产品”的特性，是商品信息聚合的最小单位，如某件二次元服装，其对应一个SPU。也就是说，在针对预售商品设置优惠信息时，可以以SPU为单位进行设置，即针对一个SPU设置一个优惠信息。
另外，预付阶段是指订购预付业务的时间周期，结算阶段是指结清预付业务的剩余数额的周期，预付数额是指在预付阶段订购预付业务需要支付的数额，结算数额是指在结算阶段需要支付的剩余数额，最高优惠数额是指结算预付业务的剩余数额时的最高优惠权益，结算优惠数额获取规则可以是指预付订单的不同生成顺序对应的结算优惠数额，且生成顺序越靠前的预付订单对应的结算优惠数额越高，即越早预定优惠力度越大，如第一名至第五名可以获取150元的结算优惠数额，第六名至第十名可以获取130元的结算优惠数额。
再者，预付数额与结算数额之和等于预付业务的总数额，结算数额减去获取的结算优惠数额是用户在结算阶段的待结算数额，其中，用户获取到的结算优惠数额只能在结算阶段使用。
需要说明的是，客户端在检测到展示预付业务的优惠页面的触发条件时，可以向服务器发送优惠页面获取请求，使得服务器在接收到该优惠页面获取请求时，向客户端返回对应的优惠页面。其中，触发条件可以是新的预付业务上架，此时可以在预付业务开始订购前获取并展示相应的优惠页面；或者，还可以是指检测到用户点击预付业务的详情页的操作，也可以是指检测到用户进入预付业务的展示页，如用户通过某关键词搜索商品，待向用户展示的预售商品就是预付业务，此时确定检测到该触发条件，将该预售商品的商品标识携带在优惠页面获取请求中发送给服务器，以获取到该预售商品对应的优惠页面。
示例的，图2是本申请一实施例提供的一种优惠页面示意图，如图2所示，预付业务为预售商品A，该预售商品A的预付阶段为1月1日至1月15日，结算阶段为2月1日至2月15日，预付数额为100元，结算数额为500元，最高结算优惠数额为150元，该优惠页面中还包括预付控件，在进入预付阶段后，该预付控件可触发。
另一种可能的实现方式中，优惠页面中也可以不包括预付业务的详细信息，而是突出预付业务的优惠信息，也即优惠页面可以包括预付业务的预付阶段的开始时间、结算优惠数额获取条件以及最高结算优惠数额。
示例的，图3是本申请一实施例提供的另一种优惠页面示意图，如图3所示，预付业务为预售商品A，该预售商品A的预付阶段开始时间为12月30日22点整，结算优惠数额的获取条件为前500名下单，最高结算优惠数额为385.35元。
本申请在预付业务进入预付阶段前，客户端可以从服务器中获取并展示预付业务的优惠页面，通过该优惠页面，用户可以获知预付业务的相关优惠信息，从而在后续预付业务处于预付阶段时，吸引用户踊跃订购，发起预定请求，促进预付业务的发展。
步骤104：在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息。
具体的，在展示所述预付业务的优惠页面的基础上，进一步地，将在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息。其中，预定请求是指用户通过预设操作触发的订购预付业务的请求，该预设操作可以为支付操作。客户端展示优惠页面后，当进入预付阶段时，用户可以在客户端展示的优惠页面中执行预设操作，此时客户端可以检测到用户针对所述预付业务发起的预定请求，将该预定请求发送给服务器，当服务器确定该用户预定成功后，可以返回预定成功信息，以告知用户成功预定该预付业务。
另外，预定请求中还可以携带用户预定的预付业务的子业务标识，该子业务标识用于表示用户具体订购了预付业务中的哪个子业务。在预付业务为预售商品时，预付业务的子业务标识为预售商品的SKU(Stock Keeping Unit，库存量单位)，SKU是库存进出计量的单位，可以是以件、盒、托盘等为单位，SKU是物理上不可分割的最小存货单元，每种商品均对应有唯一的SKU号。例如，某件二次元服装，其对应有不同的尺码，每个尺码的二次元服装对应一个SKU号。
需要说明的是，预付业务处于预付阶段，说明用户可以开始订购预付业务，此时用户可以通过在预付业务的优惠页面中的预设操作触发预定请求，客户端检测到该预定请求后，会将该预定请求发送给服务器，服务器会根据预定请求生成相应的预付订单，当生成订单时，说明预定成功，服务器可以向客户端返回预定成功信息。另外，由于服务器中预付业务对应的商家会预先设置有不同的预定顺序(即成功预定预付业务的先后顺序)对应的优惠信息，越先预定的用户获取到结算优惠数额越高(第i个生成的预付订单对应的结算优惠数额大于第i+1个生成的预付订单对应的结算优惠数额)，即预付订单的生成顺序靠前的用户对应的结算优惠数额大于靠后的，因而在确定用户预定成功后，服务器会根据预付订单生成时间，确定预付订单的生成顺序，从而确定用户预定的该预付业务对应的结算优惠数额，并在结算阶段之前发放至该用户的用户账号中，供该用户在后续结算阶段使用，一个用户账号只能获得一个结算优惠数额，即一个用户账号只能获得一份尾款优惠权益。
示例的，如图2所示，当用户点击预付控件时，可以弹出如图4所示的订购确认界面，图4是本申请一实施例提供的一种订购确认界面示意图，所述订购确认界面中包括预售商品A的商品信息，预付数额100元，结算数额400元，结算阶段的信息“结算阶段开始时间2月1日0点”等，当检测到用户点击所述订购确认界面中的支付控件时，客户端确定检测到预定请求，将该预售商品A的预定请求发送给服务器进行处理，并接收服务器返回的预定成功信息。
本实施例一个可选的实施方式中，服务器根据不同用户的预付订单的生成时间，确定各个用户对应的结算优惠数额后，还可以生成一个包括各个用户结算优惠数额的结算优惠名单返回给客户端，供客户端展示给用户，因而接收返回的预定成功信息之后，还包括：
接收并展示返回的结算优惠名单，所述结算优惠名单包括发起预定请求的各个用户和对应的结算优惠数额，所述各个用户基于对应的结算优惠数额按照预设规则排列。
具体的，预设规则可以为结算优惠数额从大至小排列，也可以为结算优惠数额从小至大排列，也即是，结算优惠名单可以由上至下，从最高结算优惠数额展示到最低一档结算优惠数额的用户名单，也可以由上至下，从最低结算优惠数额展示到最高一档结算优惠数额的用户名单。需要说明的是，服务器可以接收到多个用户发起的预定请求，然后分别生成对应的预付订单，并根据预付订单的生成顺序，为各个用户分别确定对应的结算优惠数额，为了方便用户获知自己和其他用户“抢购”到的优惠权益，服务器还可以生成包括各个用户优惠信息的结算优惠名单，并在满足预设时间条件的情况下返回给客户端，客户端可以对服务器返回的结算优惠名单进行展示，其中，该预设时间条件可以为预付阶段结束后的预设时长，如预付阶段结束后的10分钟后，将结算优惠名单发送给客户端。
示例的，图5是本申请一实施例提供的一种结算优惠名单示意图，如图5所示，每个用户对应有预付订单的生成顺序和获取到结算优惠数额，预设规则可以为结算优惠数额从大至小排列，用户1为第一名预定成功的用户，即用户1的预付订单的生成顺序为第1名，其对应获取到了150元的结算优惠数额，即结算阶段时可以优惠150元；用户2为第二名预定成功的用户，即用户2的预付订单的生成顺序为第2名，其对应获取到了130元的结算优惠数额，即结算阶段时可以优惠130元；用户3为第三名预定成功的用户，即用户3的预付订单的生成顺序为第3名，其对应获取到了100元的结算优惠数额，即结算阶段时可以优惠100元。
另一种可能的实现方式中，由于预付业务对应的商家在设置不同预定顺序对应不同结算优惠数额时，每个结算优惠数额可能不仅对应一个生成顺序的用户，而是可能对应一个生成顺序的区间，因而在生成结算优惠名单时，服务器除了可以针对每个用户单独显示对应的结算优惠数额外，还可以将用户按照预付订单的生成顺序进行划区间显示，即每个生成顺序区间，显示对应的结算优惠数额，然后在该生成顺序区间下只显示用户标识，不单独显示结算优惠数额。
示例的，图6是本申请一实施例提供的另一种结算优惠名单示意图，如图6所示，预设规则可以为结算优惠数额从大至小排列，第一名至第五名预定成功的用户，获取到了150元的结算优惠数额，其中，第一名至第五名预定成功的用户包括用户1、用户2、用户3、用户4和用户5；第六名至第十名预定成功的用户，获取到了100元的结算优惠数额，其中，第六名至第十名预定成功的用户包括用户6、用户7、用户8、用户9和用户10。
本申请中客户端可以接收服务器返回的结算优惠名单，使得用户可以获知自己和其他用户“抢购”到的优惠权益，从而通过其他用户获得到的优惠权益，促使用户不进行退订，节省服务器的处理资源，并鼓励吸引用户下次尽早预定，促进预付业务的发展。如某个用户获得的结算优惠数额较高，其在结算优惠名单中看大部分用户抢到的结算优惠数额均低于自己，可能会产生自己的结算优惠数额来之不易的心里，从而保证了预付订单的稳定性，一定程度上降低用户退订的概率；另外，假设某个用户获得的结算优惠数额较低，其在结算优惠名单中看大部分用户抢到的结算优惠数额都高于自己，此时可以刺激用户的竞争心里，该用户可能会在下次活动时尽早预定，从而保证预付业务的稳定性，促进预付业务的发展。
另外，实际应用中，客户端还可以只向用户展示其自身获得的结算优惠数额，也即，服务器在确定出预付订单对应的结算优惠数额后，确定发起该预付订单的客户端，并向该客户端返回用户预定该预付业务对应的结算优惠数额。如此，每个用户只可以看到自己抢到的结算优惠数额，看不到别的用户获得的结算优惠数额，别人也无法获知其获得的结算优惠数额，保证了用户的信息安全。
本实施例一个可选的实施方式中，接收并展示返回的结算优惠名单，具体实现过程可以如下：
接收并展示所述预付业务的业务详情页，所述业务详情页中添加有所述结算优惠名单；和/或，
接收并展示所述预付业务对应的预付订单，所述预付订单中添加有所述结算优惠名单。
需要说明的是，服务器可以将生成的结算优惠名单添加至对应的预付业务的业务详情页中发送给客户端，此时用户通过客户端查看预付业务的业务详情页时，就可以看到该结算优惠名单；服务器还可以将生成的结算优惠名单添加至对应的预付业务的预付订单中发送给客户端，此时用户通过客户端查看预付业务的预付订单时，也可以看到该结算优惠名单。
本申请中在预付业务处于预付阶段的情况下，客户端可以检测用户在展示的优惠页面中针对预付业务发起的预定请求，并将该预定请求发送给服务器，使得服务器根据该预定请求生成对应的预付订单，并根据生成预付订单的生成顺序，确定相应的结算优惠数额，发放至对应的用户账号中，供后续结算阶段时使用。
步骤106：在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额，所述结算优惠数额根据所述预付业务对应的预付订单的生成顺序确定。
具体的，在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息的基础上，进一步地，在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额，所述结算优惠数额根据所述预付业务对应的预付订单的生成顺序确定。其中，结算请求是指用户通过预设结算操作触发的结算预付业务的请求，该预设结算操作可以为余额支付操作，且只有发起预付业务的预定请求的用户可以执行相应的预设结算操作，触发结算请求。
需要说明的是，在预付业务处于结算阶段时，说明预付业务的预付阶段已经结束，进行了预定的用户需要支付自己预定的预付业务对应的剩余数额(即结算数额)，对该预付业务进行结算。由于用户在预定预付业务时，服务器可以根据预付订单的生成顺序为用户发放相应结算优惠数额的优惠，该结算优惠数额可以在结算阶段时使用，因而客户端在检测到用户的结算请求时，可以向服务器发送该预付业务的结算请求，从而获取该预付业务对应的结算优惠数额，即该用户订购该预付业务时获取到的结算优惠数额，后续基于该结算优惠数额进行结算。
本实施例一个可选的实施方式中，获取所述预付业务对应的结算优惠数额，具体实现过程可以如下：
确定发送所述预定请求对应的用户账号；
从所述用户账号中获取所述预付业务对应的结算优惠数额。
需要说明的是，服务器在确定出发送该预定请求的用户针对该预付业务的结算优惠数额时，会将结算优惠数额对应的优惠发放至该用户对应的用户账号中，因而在该用户发起结算请求时，可以根据发送预定请求对应的用户账号，获取所述预付业务对应的结算优惠数额。
另外，由于一个用户账号中可能会存在很多不同的预付业务对应的结算优惠数额，因而本申请中服务器在向用户账号发放结算优惠数额时，还可以在该结算优惠数额中携带对应的预付业务的标识，后续在用户针对某预付业务发起结算请求时，可以根据该预付业务的标识，在该用户的用户账号中获取对应的结算优惠数额，以使后续该用户针对该预付业务进行结算。
步骤108：根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额。
具体的，在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额的基础上，进一步地，将根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额。其中，待结算数额是指预定该预付业务的用户还需要支付的数额。
本实施例一个可选的实施方式中，根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额，具体实现过程可以如下：
确定所述预付业务对应的结算数额；
根据所述结算数额和所述结算优惠数额，确定所述预付业务对应的待结算数额；
根据所述待结算数额，生成所述预付业务对应的结算页面，在所述结算页面中展示所述待结算数额。
具体实现时，服务器在确定预付业务的优惠信息时，会确定预付业务对应的结算数额，如服务器生成的优惠页面中包括预付业务的结算数额，基于服务器返回的优惠页面，客户端可以确定预付业务对应的结算数额。
需要说明的是，结算数额减去用户获取到的结算优惠数额就是用户在结算阶段的待结算数额，然后根据所述待结算数额，生成所述预付业务对应的结算页面，使得用户可以根据结算页面中显示的待结算数额，对自己预定的预付业务进行结算，即用户只需要支付待结算数额即可完成预付业务的整个订购过程。
本实施例一个可选的实施方式中，由于预定该预付业务的用户账号中可能不仅包括有预付阶段获得的结算优惠数据，还可能会包括其他的优惠额度想要在预付业务中使用，因而在结算预付业务时，还可以考虑其他的优惠数额，也即根据所述结算数额和所述结算优惠数额，确定所述预付业务对应的待结算数额，具体实现过程还可以如下：
根据所述结算数额、所述结算优惠数额和目标优惠数额，确定所述预付业务对应的待结算数额。
本实施例一个可选的实施方式中，预定该预付业务的用户账号中包括的目标优惠数额可能是可以与该预付业务叠加使用的优惠，也可能是不可以与该预付业务叠加使用的优惠，因而在确定该预付业务对应的待结算数额时，需要考虑目标优惠数额是否可以与该预付业务叠加，即是否可以和结算优惠数额叠加使用，因而根据所述结算数额、所述结算优惠数额和目标优惠数额，确定所述预付业务对应的待结算数额，具体实现过程还可以如下：
在所述目标优惠数额和所述预付业务叠加使用的情况下，计算所述结算优惠数额和所述目标优惠数额之和，得到优惠总数额；
根据所述结算数额和所述优惠总数额，确定所述预付业务对应的待结算数额。
需要说明的是，目标优惠数额可以是指用户账号中包括的没有使用规则的优惠卷数额、红包优惠数额等，该目标优惠数额可以不限制于某一预付业务使用，且该目标优惠数额可以和结算优惠叠加使用，如用户账号中包括的无门槛红包。
实际应用中，若确定出结算请求中包括目标优惠数额，且该目标优惠数额可以和该预付业务叠加使用，此时可以先计算结算优惠数额和目标优惠数额之和，得到优惠总数额，使用结算数额减去该优惠总数额就是用户在结算阶段的待结算数额，用户支付该待结算数额即可完成预付业务的整个订购过程。
示例的，图7是本申请一实施例提供的一种结算页面示意图，如图7所示，结算页面为用户订购预售商品A对应的结算页面，该结算页面中包括商品A的信息，总金额500元，定金阶段支付50元，尾款阶段的待支付尾款为300元，尾款共优惠150元，其中包括尾款优惠金额130元和叠加红包20元。
本实施例一个可选的实施方式中，若目标优惠数额是不可以与该预付业务叠加使用的优惠，那么可以在结算预付业务时使用结算优惠数额和目标优惠数额中额度较大的优惠，也即根据所述结算数额、所述结算优惠数额和目标优惠数额，确定所述预付业务对应的待结算数额，具体实现过程还可以如下：
在所述目标优惠数额不和所述预付业务叠加使用的情况下，确定所述目标优惠数额是否大于所述结算优惠数额；
若是，则根据所述结算数额和所述目标优惠数额，确定所述待结算数额；
若否，则根据所述结算数额和所述结算优惠数额，确定所述待结算数额，并将所述目标优惠数额返回对应的用户账号。
需要说明的是，目标优惠数额可以是指有预设使用规则、不能与预付业务叠加使用的优惠券、有使用规则的红包等，因而，如果用户在预付阶段使用了该目标优惠数额，那么在结算阶段，可以取使用的目标优惠数额和结算优惠数额之间的最高值，对预付业务进行结算。具体的，可以确定目标优惠数额是否大于结算优惠数额，若是，则说明目标优惠数额的优惠力度较大，因而此时可以使用目标优惠数额对预付业务进行结算，目标优惠数额一经使用不予返还；若否，则说明结算优惠的优惠力度较大，因而此时可以使用结算优惠数额对预付业务进行结算，并将目标优惠数额返还至对应的用户账号，目标优惠数额的使用有效期不变。
示例的，预售商品B总金额500元，定金200元，尾款300元，假设用户在订购预售商品B时，在预付阶段使用了150元的优惠券，支付了50元的定金，其根据支付定金的顺序获取到的结算优惠数额为120元，由于优惠券的额度大于结算优惠数额，因而此时基于用户使用的优惠卷进行结算，即该预售商品B的尾款金额为300元。
又一示例的，预售商品C总金额500元，定金200元，尾款300元，假设用户在订购预售商品C时，在预付阶段使用了150元的优惠券，支付了50元的定金，其根据支付定金的顺序获取到的结算优惠数额为200元，由于结算优惠数额大于其使用的优惠券额度，因而此时基于用户获取到的结算优惠数额进行结算，即该预售商品B的尾款金额为250元，并将该用户使用的150元优惠券返回其用户账号中。
另一个可能的实现方式中，若服务器在生成预付业务的预付订单时，根据预付业务对应的结算数额和对应结算优惠数额，确定出了所述预付业务对应的待结算数额，并在预付订单的订单详情中增加了结算阶段的待结算数额，此时在检测到所述用户的结算请求的情况下，可以直接基于相应的待结算数额，显示对应的结算页面。
本申请提供的预付订单处理方法，客户端可以在预付业务处于预付阶段前，展示所述预付业务的优惠页面；在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息；在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额，所述结算优惠数额根据所述预付业务对应的预付订单的生成顺序确定；根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额。这种情况下，可以根据用户在预付阶段完成预订的顺序，向用户发放对应的结算优惠数额，在结算阶段时，用户可以使用该结算优惠数额进行结算。如此，在预付阶段，不同的预订顺序可以获得不同的结算优惠数额，越先预订的用户可以获取越高的结算优惠数额，从而可以吸引更多用户尽快对预付业务进行预订，且结算优惠数额在结算阶段才可以使用，从而可以吸引用户不进行退订，促进了预付业务的发展，减少了库存积压，实现了去库存的效果，且降低了用户先进行预订，再进行退订的比例，进而降低了服务器的处理压力，节省了服务器的处理资源。
图8示出了根据本申请一实施例提供的第二种预付订单处理方法的流程图，应用于服务器，具体包括以下步骤：
步骤802：接收预付业务的预定请求，并根据所述预定请求，生成对应的预付订单，返回预定成功信息。
需要说明的是，客户端检测到用户针对预付业务发起的预定请求后，会将该预定请求发送给服务器，服务器可以根据预定请求生成相应的预付订单，在成功生成预付订单时，确定该用户预定成功，可以获得相应的结算优惠，此时可以向客户端返回预定成功信息。
本实施例一个可选的实施方式中，针对预付业务，对应的商家可以预先设置有不同的优惠信息，也即接收预付业务的预定请求之前，还包括：
接收针对所述预付业务的优惠设置指令，所述优惠设置指令中包括预付阶段、结算阶段、预付数额、结算数额、结算优惠数额获取规则和最高结算优惠数额；
根据所述预付阶段、所述结算阶段、所述预付数额、所述结算数额、所述结算优惠数额获取规则和所述最高结算优惠数额，生成所述预付业务的优惠页面；
在接收到优惠页面获取请求的情况下，返回所述优惠页面。
需要说明的是，优惠设置指令是指针对某预付业务设置对应的优惠规则的指令，该优惠设置指令中携带的优惠规则可以包括预付阶段、结算阶段、预付数额、结算数额、结算优惠数额获取规则以及最高结算优惠数额，根据设置的相应的优惠规则，服务器可以生成该预付业务的优惠页面，并在客户端请求时，发送给客户端。
需要说明的是，预付业务对应的商家会预先通过服务器设置不同的预定顺序(即成功预定预付业务的先后顺序)对应的优惠信息，越先预定的用户获取到结算优惠数额越高，即预付订单的生成顺序靠前的用户对应的结算优惠数额大于靠后的，因而服务器会根据预付订单生成的时间生成顺序(即预定顺序)，确定该预定请求对应的结算优惠数额，并在结算阶段之前发放至该用户的用户账号中，供该用户在后续结算阶段使用，一个用户账号只能获得一个结算优惠数额，即一个用户账号只能获得一份尾款优惠权益。
步骤804：根据所述预付订单的生成时间，确定所述预付订单对应的生成顺序。
需要说明的是，服务器在接收到客户端发送的预定请求时，会生成对应的预付订单，当预付订单生成时，说明用户成功预定对应的预付业务。
步骤806：根据所述生成顺序，确定所述预付业务对应的结算优惠数额。
需要说明的是，每个预付订单均有相应的生成时间，根据其生成时间，可以确定出预付订单对应的生成顺序，从而后续可以确定出用户预定该预付业务对应的结算优惠数额。也即是，用户预定时间顺序的先后，决定了其能够获取到的结算优惠数额的多少，从而鼓励吸引用户尽早订购，营造“抢购”的氛围。
本实施例一个可选的实施方式中，根据所述生成顺序，确定所述预付订单对应的结算优惠数额，包括：
确定所述预付订单的生成顺序对应的目标顺序区间；
根据预先设置的顺序区间和优惠数额之间的对应关系，确定所述目标顺序区间对应的优惠数额；
将所述目标顺序区间对应的优惠数额确定为所述预付订单对应的结算优惠数额。
需要说明的是，商家在针对预付业务设置结算优惠数额的获取规则时，可以通过对应关系的方式进行设置，即预先设置好顺序区间和优惠数额之间的对应关系，后续生成预付订单后，可以直接根据生成顺序，确定出对应的结算优惠数额。
示例的，预先设置的顺序区间和优惠数额之间的对应关系如下表1所示，假设某预付订单的生成顺序为第三名，则根据如下表1可以确定出该预付订单对应的用户获取到的结算优惠数额为150元。
表1顺序区间和优惠数额之间的对应关系表
顺序区间 优惠数额
第一名至第五名 150
第六名至第十名 130
第十一名至第十五名 100
本实施例一个可选的实施方式中，服务器根据不同用户的预付订单的生成时间，确定各个用户对应的结算优惠数额后，还可以生成一个包括各个用户结算优惠数额的结算优惠名单返回给客户端，供客户端展示给用户，因而根据所述生成顺序，确定所述预付业务对应的结算优惠数额之后，还包括：
确定生成的各个预付订单对应的用户；
将所述用户基于预付业务对应的结算优惠数额，按照预设规则排列生成结算优惠名单；
在满足预设时间条件的情况下，返回所述结算优惠名单。
具体的，预设规则可以为结算优惠数额从大至小排列，也可以为结算优惠数额从小至大排列，也即是，结算优惠名单可以由上至下，从最高结算优惠数额展示到最低一档结算优惠数额的用户名单，也可以由上至下，从最低结算优惠数额展示到最高一档结算优惠数额的用户名单。
需要说明的是，服务器可以接收到多个用户发起的预定请求，然后分别生成对应的预付订单，并根据预付订单的生成顺序，为各个用户分别确定对应的结算优惠数额，为了方便用户获知自己和其他用户“抢购”到的优惠权益，服务器还可以生成包括各个用户优惠信息的结算优惠名单，并在满足预设时间条件的情况下返回给客户端，客户端可以对服务器返回的结算优惠名单进行展示，其中，该预设时间条件可以为预付阶段结束后的预设时长后，如预付阶段结束后的10分钟后，将结算优惠名单发送给客户端。
本申请中客户端可以接收服务器返回的结算优惠名单，使得用户可以获知自己和其他用户“抢购”到的优惠权益，从而通过其他用户获得到的优惠权益，促使用户不进行退订，并鼓励吸引用户下次尽早预定。如某个用户获得的结算优惠数额较高，其在结算优惠名单中看大部分用户抢到的结算优惠数额均低于自己，可能会产生自己的结算优惠数额来之不易的心里，从而保证了预付订单的稳定性，一定程度上降低用户退订的概率；另外，假设某个用户获得的结算优惠数额较低，其在结算优惠名单中看大部分用户抢到的结算优惠数额都高于自己，此时可以刺激用户的竞争心里，该用户可能会在下次活动时尽早预定，从而保证预付业务的稳定性，促进预付业务的发展。
另外，实际应用中，客户端还可以只向用户展示其自身获得的结算优惠数额，也即，服务器在确定出预付订单对应的结算优惠数额后，确定发起该预付订单的客户端，并向该客户端返回该预付订单对应的结算优惠数额。如此，每个用户只可以看到自己抢到的结算优惠数额，看不到别的用户获得的结算优惠数额，别人也无法获知其获得的结算优惠数额，保证了用户的信息安全。
本实施例一个可选的实施方式中，返回所述结算优惠名单，具体实现过程可以如下：
将所述结算优惠名单添加至所述预付业务的业务详情页中，返回所述业务详情页；和/或，
将所述结算优惠名单添加至所述预付业务对应的预付订单中，返回所述预付订单。
需要说明的是，服务器可以将生成的结算优惠名单添加至对应的预付业务的业务详情页中发送给客户端，此时用户通过客户端查看预付业务的业务详情页时，就可以看到该结算优惠名单；服务器还可以将生成的结算优惠名单添加至对应的预付业务的预付订单中发送给客户端，此时用户通过客户端查看预付业务的预付订单时，也可以看到该结算优惠名单
本申请中在预付业务处于预付阶段的情况下，客户端可以接收用户在所述优惠页面针对所述预付业务发起的预定请求，并将所述预定请求发送给服务器，服务器根据该预定请求生成对应的预付订单，并根据生成预付订单的生成顺序，确定相应的结算优惠数额，发放至对应的用户账号中，供后续结算阶段时使用。
步骤808：确定发送所述预定请求的用户账号，向所述用户账号发放所述结算优惠数额对应的优惠。
本申请提供的预付订单处理方法，在预付阶段，不同的预订顺序可以获得不同的结算优惠数额，越先预订的用户可以获取越高的结算优惠数额，从而可以吸引更多用户尽快对预付业务进行预订，且结算优惠数额在结算阶段才可以使用，从而可以吸引用户不进行退订，促进了预付业务的发展，减少了库存积压，实现了去库存的效果，且降低了用户先进行预订，再进行退订的比例，进而降低了服务器的处理压力，节省了服务器的处理资源。
图9示出了根据本申请一实施例提供的第三种预付订单处理方法的流程图，具体包括以下步骤：
步骤902：服务器接收针对预付业务的优惠设置指令，所述优惠设置指令中包括预付阶段、结算阶段、预付数额、结算数额、结算优惠数额获取规则和最高结算优惠数额。
步骤904：服务器根据所述预付阶段、所述结算阶段、所述预付数额、所述结算数额、所述结算优惠数额获取规则和所述最高结算优惠数额，生成所述预付业务的优惠页面。
步骤906：服务器在接收到客户端发送的优惠页面获取请求的情况下，向所述客户端返回所述优惠页面。
步骤908：客户端在预付业务处于预付阶段前，展示所述预付业务的优惠页面。
步骤910：客户端在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息。
步骤912：服务器接收预付业务的预定请求，并根据所述预定请求，生成对应的预付订单，返回预定成功信息。
步骤914：服务器根据所述预付订单的生成时间，确定所述预付订单对应的生成顺序，根据所述生成顺序，确定所述预付业务对应的结算优惠数额，并确定发送所述预定请求的用户账号，向所述用户账号发放所述结算优惠数额对应的优惠。
步骤916：客户端在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额，根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额。
本申请提供的预付订单处理方法，服务器可以根据用户在预付阶段完成预订的顺序，向用户发放对应的结算优惠数额，在结算阶段时，用户可以使用该结算优惠数额进行结算。如此，在预付阶段，不同的预订顺序可以获得不同的结算优惠数额，越先预订的用户可以获取越高的结算优惠数额，从而可以吸引更多用户尽快对预付业务进行预订，且结算优惠数额在结算阶段才可以使用，从而可以吸引用户不进行退订，促进了预付业务的发展，减少了库存积压，实现了去库存的效果，且降低了用户先进行预订，再进行退订的比例，进而降低了服务器的处理压力，节省了服务器的处理资源。
下述结合附图10，以本申请提供的预付订单处理方法在网上购物场景中的应用为例，对所述预付订单处理方法进行进一步说明。其中，图10示出了本申请一实施例提供的一种应用于网上购物场景中的预付订单处理方法的处理流程图，具体包括以下步骤：
步骤1002：服务器接收针对预售商品的优惠设置指令，所述优惠设置指令中包括付定金阶段、补尾款阶段、定金金额、尾款金额、尾款优惠金额获取规则和最高尾款优惠金额。
需要说明的是，该预售商品可以在进行销售前制作完成，如此，预售商品会存在大量的库存，可以通过向用户发放尾款优惠的方式，达到促进商品销售，去库存的效果；或者，预售商品也可以先不进行制作，在用户支付定金后，根据支付定金的用户情况，再制作相应的商品，如此，预售商品不会存在大量的库存，但是通过向用户发放尾款优惠的方式，可以促进预售商品的销售，提高销售额。
另外，在确定针对哪些商品进行预售时，可以选择一些比较受欢迎，或者商家主要想要宣传的商品，通过预售和尾款优惠的方式，促进核心商品的销售。
步骤1004：服务器根据所述付定金阶段、补尾款阶段、定金金额、尾款金额、尾款优惠金额获取规则和最高尾款优惠金额，生成该预售商品的预售页面。
步骤1006：服务器在接收到客户端发送的预售页面获取请求的情况下，向所述客户端返回所述预售页面。
步骤1008：客户端在预售商品开售前，展示所述预售商品的预售页面。
步骤1010：客户端在预售商品处于付定金阶段的情况下，发送所述预售商品的预购请求，并接收返回的预购成功信息。
步骤1012：服务器接收预售商品的预购请求，并根据所述预购请求，生成对应的预购订单，返回预购成功信息。
步骤1014：服务器根据所述预购订单的生成时间，确定所述预购订单对应的生成顺序，根据所述生成顺序，确定所述预售商品对应的尾款优惠金额，并确定发送所述预购请求的用户账号，向所述用户账号发放所述尾款优惠金额对应的优惠。
步骤1016：客户端在所述预售商品处于补尾款阶段的情况下，发送所述预付业务的结算请求，获取所述预售商品对应的尾款优惠金额，根据所述尾款优惠金额，确定并展示所述预售商品对应的待支付尾款。
本申请提供的预付订单处理方法，服务器可以根据用户在付定金阶段完成订购的顺序，向用户发放对应的尾款优惠金额，在补尾款阶段时，用户可以使用该尾款优惠金额进行结算。如此，在付定金阶段，不同的订购顺序可以获得不同的尾款优惠金额，越先预订的用户可以获取越高的尾款优惠金额，从而可以吸引更多用户尽快购买预售商品，且尾款优惠金额只有在补尾款阶段才可以使用，从而可以吸引用户不进行退款，促进了预售商品的销售，减少了库存积压，实现了去库存的效果，且降低了用户先进行订购，再进行退款的比例，进而降低了服务器的处理压力，节省了服务器的处理资源。
与上述方法实施例相对应，本申请还提供了预付订单处理客户端的实施例，图11示出了本申请一实施例提供的一种预付订单处理客户端的结构示意图。如图11所示，该客户端包括：
发送模块1102，被配置为在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息；
获取模块1104，被配置为在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额，所述结算优惠数额根据所述预付业务对应的预付订单的生成顺序确定；
第一展示模块1106，被配置为根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额。
可选地，所述客户端还包括第一接收模块，被配置为：
接收并展示返回的结算优惠名单，所述结算优惠名单包括发起预定请求的各个用户和对应的结算优惠数额，所述各个用户基于对应的结算优惠数额按照预设规则排列。
可选地，第一展示模块1106进一步被配置为：
确定所述预付业务对应的结算数额；
根据所述结算数额和所述结算优惠数额，确定所述预付业务对应的待结算数额；
根据所述待结算数额，生成所述预付业务对应的结算页面，在所述结算页面中展示所述待结算数额。
可选地，第一展示模块1106进一步被配置为：
根据所述结算数额、所述结算优惠数额和目标优惠数额，确定所述预付业务对应的待结算数额。
可选地，第一展示模块1106进一步被配置为：
在所述目标优惠数额和所述预付业务叠加使用的情况下，计算所述结算优惠数额和所述目标优惠数额之和，得到优惠总数额；
根据所述结算数额和所述优惠总数额，确定所述预付业务对应的待结算数额。
可选地，第一展示模块1106进一步被配置为：
在所述目标优惠数额不和所述预付业务叠加使用的情况下，确定所述目标优惠数额是否大于所述结算优惠数额；
若是，则根据所述结算数额和所述目标优惠数额，确定所述待结算数额；
若否，则根据所述结算数额和所述结算优惠数额，确定所述待结算数额，并将所述目标优惠数额返回对应的用户账号。
可选地，获取模块1104进一步被配置为：
确定发送所述预定请求对应的用户账号；
从所述用户账号中获取所述预付业务对应的结算优惠数额。
可选地，所述客户端还包括第二展示模块，被配置为：
在预付业务处于预付阶段前，展示所述预付业务的优惠页面，所述优惠页面包括所述预付业务的预付阶段、结算阶段、预付数额、结算数额、结算优惠数额获取规则和最高结算优惠数额。
可选地，第一接收模块进一步被配置为：
接收并展示所述预付业务的业务详情页，所述业务详情页中添加有所述结算优惠名单；和/或，
接收并展示所述预付业务对应的预付订单，所述预付订单中添加有所述结算优惠名单。
本申请提供的预付订单处理客户端，在预付阶段，不同的预订顺序可以获得不同的结算优惠数额，越先预订的用户可以获取越高的结算优惠数额，从而可以吸引更多用户尽快对预付业务进行预订，且结算优惠数额在结算阶段才可以使用，从而可以吸引用户不进行退订，促进了预付业务的发展，减少了库存积压，实现了去库存的效果，且降低了用户先进行预订，再进行退订的比例，进而降低了服务器的处理压力，节省了服务器的处理资源。
上述为本实施例的一种预付订单处理客户端的示意性方案。需要说明的是，该预付订单处理客户端的技术方案与上述的预付订单处理方法的技术方案属于同一构思，预付订单处理客户端的技术方案未详细描述的细节内容，均可以参见上述预付订单处理方法的技术方案的描述。
与上述方法实施例相对应，本申请还提供了预付订单处理服务器的实施例，图12示出了本申请一实施例提供的一种预付订单处理服务器的结构示意图。如图12所示，该服务器包括：
生成模块1202，被配置为接收预付业务的预定请求，并根据所述预定请求，生成对应的预付订单，返回预定成功信息；
第一确定模块1204，被配置为根据所述预付订单的生成时间，确定所述预付订单对应的生成顺序；
第二确定模块1206，被配置为根据所述生成顺序，确定所述预付业务对应的结算优惠数额；
发放模块1208，被配置为确定发送所述预定请求的用户账号，向所述用户账号发放所述结算优惠数额对应的优惠。
可选地，第二确定模块1206进一步被配置为：
确定所述预付订单的生成顺序对应的目标顺序区间；
根据预先设置的顺序区间和优惠数额之间的对应关系，确定所述目标顺序区间对应的优惠数额；
将所述目标顺序区间对应的优惠数额确定为所述预付订单对应的结算优惠数额。
可选地，所述服务器还包括发送模块，被配置为：
确定生成的各个预付订单对应的用户；
将所述用户基于预付业务对应的结算优惠数额，按照预设规则排列生成结算优惠名单；
在满足预设时间条件的情况下，返回所述结算优惠名单。
可选地，所述发送模块进一步被配置为：
将所述结算优惠名单添加至所述预付业务的业务详情页中，返回所述业务详情页；和/或，
将所述结算优惠名单添加至所述预付业务对应的预付订单中，返回所述预付订单。
可选地，所述服务器还包括第二接收模块，被配置为：
接收针对所述预付业务的优惠设置指令，所述优惠设置指令中包括预付阶段、结算阶段、预付数额、结算数额、结算优惠数额获取规则和最高结算优惠数额；
根据所述预付阶段、所述结算阶段、所述预付数额、所述结算数额、所述结算优惠数额获取规则和所述最高结算优惠数额，生成所述预付业务的优惠页面；
在接收到优惠页面获取请求的情况下，返回所述优惠页面。
本申请提供的预付订单处理服务器可以根据用户在预付阶段完成预订的顺序，向用户发放对应的结算优惠数额，在结算阶段时，用户可以使用该结算优惠数额进行结算。如此，在预付阶段，不同的预订顺序可以获得不同的结算优惠数额，越先预订的用户可以获取越高的结算优惠数额，从而可以吸引更多用户尽快对预付业务进行预订，且结算优惠数额在结算阶段才可以使用，从而可以吸引用户不进行退订，促进了预付业务的发展，减少了库存积压，实现了去库存的效果，且降低了用户先进行预订，再进行退订的比例，进而降低了服务器的处理压力，节省了服务器的处理资源。
上述为本实施例的一种预付订单处理服务器的示意性方案。需要说明的是，该预付订单处理服务器的技术方案与上述的预付订单处理方法的技术方案属于同一构思，预付订单处理服务器的技术方案未详细描述的细节内容，均可以参见上述预付订单处理方法的技术方案的描述。
与上述方法实施例相对应，本申请还提供了预付订单处理***的实施例，图13示出了本申请一实施例提供的一种预付订单处理***的结构示意图。如图13所示，该***包括：
预付订单处理客户端1302，被配置为在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息；在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额；根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额；
预付订单处理服务器1304，被配置为接收预付业务的预定请求，并根据所述预定请求，生成对应的预付订单，返回预定成功信息；根据所述预付订单的生成时间，确定所述预付订单对应的生成顺序；根据所述生成顺序，确定所述预付业务对应的结算优惠数额；确定发送所述预定请求的用户账号，向所述用户账号发放所述结算优惠数额对应的优惠。
本申请提供的预付订单处理***，服务器可以根据用户在预付阶段完成预订的顺序，向用户发放对应的结算优惠数额，在结算阶段时，用户可以使用该结算优惠数额进行结算。如此，在预付阶段，不同的预订顺序可以获得不同的结算优惠数额，越先预订的用户可以获取越高的结算优惠数额，从而可以吸引更多用户尽快对预付业务进行预订，且结算优惠数额在结算阶段才可以使用，从而可以吸引用户不进行退订，促进了预付业务的发展，减少了库存积压，实现了去库存的效果，且降低了用户先进行预订，再进行退订的比例，进而降低了服务器的处理压力，节省了服务器的处理资源。
上述为本实施例的一种预付订单处理***的示意性方案。需要说明的是，该预付订单处理***的技术方案与上述的预付订单处理方法的技术方案属于同一构思，预付订单处理***的技术方案未详细描述的细节内容，均可以参见上述预付订单处理方法的技术方案的描述。
图14示出了根据本申请一实施例提供的一种计算设备1400的结构框图。该计算设备1400的部件包括但不限于存储器1410和处理器1420。处理器1420与存储器1410通过总线1430相连接，数据库1450用于保存数据。
计算设备1400还包括接入设备1440，接入设备1440使得计算设备1400能够经由一个或多个网络1460通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备1440可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。
在本申请的一个实施例中，计算设备1400的上述部件以及图14中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图14所示的计算设备结构框图仅仅是出于示例的目的，而不是对本申请范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。
计算设备1400可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备1400还可以是移动式或静止式的服务器。
其中，处理器1420用于执行如下计算机可执行指令以实现上述任意预付订单处理方法的步骤。
上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的预付订单处理方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述预付订单处理方法的技术方案的描述。
本申请一实施例还提供一种计算机可读存储介质，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时以用于实现上述任意预付订单处理方法的步骤。
上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的预付订单处理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述预付订单处理方法的技术方案的描述。
上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本申请的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims (19)

1.一种预付订单处理方法，其特征在于，应用于客户端，包括：
在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息；
在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额，所述结算优惠数额根据所述预付业务对应的预付订单的生成顺序确定；
根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额。
2.根据权利要求1所述的预付订单处理方法，其特征在于，接收返回的预定成功信息之后，还包括：
接收并展示返回的结算优惠名单，所述结算优惠名单包括发起预定请求的各个用户和对应的结算优惠数额，所述各个用户基于对应的结算优惠数额按照预设规则排列。
3.根据权利要求1或2所述的预付订单处理方法，其特征在于，根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额，包括：
确定所述预付业务对应的结算数额；
根据所述结算数额和所述结算优惠数额，确定所述预付业务对应的待结算数额；
根据所述待结算数额，生成所述预付业务对应的结算页面，在所述结算页面中展示所述待结算数额。
4.根据权利要求3所述的预付订单处理方法，其特征在于，根据所述结算数额和所述结算优惠数额，确定所述预付业务对应的待结算数额，包括：
根据所述结算数额、所述结算优惠数额和目标优惠数额，确定所述预付业务对应的待结算数额。
5.根据权利要求4所述的预付订单处理方法，其特征在于，根据所述结算数额、所述结算优惠数额和目标优惠数额，确定所述预付业务对应的待结算数额，包括：
在所述目标优惠数额和所述预付业务叠加使用的情况下，计算所述结算优惠数额和所述目标优惠数额之和，得到优惠总数额；
根据所述结算数额和所述优惠总数额，确定所述预付业务对应的待结算数额。
6.根据权利要求4所述的预付订单处理方法，其特征在于，根据所述结算数额、所述结算优惠数额和目标优惠数额，确定所述预付业务对应的待结算数额，包括：
在所述目标优惠数额不和所述预付业务叠加使用的情况下，确定所述目标优惠数额是否大于所述结算优惠数额；
若是，则根据所述结算数额和所述目标优惠数额，确定所述待结算数额；
若否，则根据所述结算数额和所述结算优惠数额，确定所述待结算数额，并将所述目标优惠数额返回对应的用户账号。
7.根据权利要求1或2所述的预付订单处理方法，其特征在于，获取所述预付业务对应的结算优惠数额，包括：
确定发送所述预定请求的用户账号；
从所述用户账号中获取所述预付业务对应的结算优惠数额。
8.根据权利要求1或2所述的预付订单处理方法，其特征在于，在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求之前，还包括：
在预付业务处于预付阶段前，展示所述预付业务的优惠页面，所述优惠页面包括所述预付业务的预付阶段、结算阶段、预付数额、结算数额、结算优惠数额获取规则和最高结算优惠数额。
9.根据权利要求2所述的预付订单处理方法，其特征在于，接收并展示返回的结算优惠名单，包括：
接收并展示所述预付业务的业务详情页，所述业务详情页中添加有所述结算优惠名单；和/或，
接收并展示所述预付业务对应的预付订单，所述预付订单中添加有所述结算优惠名单。
10.一种预付订单处理方法，其特征在于，应用于服务器，包括：
接收预付业务的预定请求，并根据所述预定请求，生成对应的预付订单，返回预定成功信息；
根据所述预付订单的生成时间，确定所述预付订单对应的生成顺序；
根据所述生成顺序，确定所述预付业务对应的结算优惠数额；
确定发送所述预定请求的用户账号，向所述用户账号发放所述结算优惠数额对应的优惠。
11.根据权利要求10所述的预付订单处理方法，其特征在于，根据所述生成顺序，确定所述预付订单对应的结算优惠数额，包括：
确定所述生成顺序对应的目标顺序区间；
根据预先设置的顺序区间和优惠数额之间的对应关系，确定所述目标顺序区间对应的优惠数额；
将所述目标顺序区间对应的优惠数额确定为所述预付订单对应的结算优惠数额。
12.根据权利要求10或11所述的预付订单处理方法，其特征在于，根据所述生成顺序，确定所述预付业务对应的结算优惠数额之后，还包括：
确定生成的各个预付订单对应的用户；
将所述用户基于预付业务对应的结算优惠数额，按照预设规则排列生成结算优惠名单；
在满足预设时间条件的情况下，返回所述结算优惠名单。
13.根据权利要求12所述的预付订单处理方法，其特征在于，返回所述结算优惠名单，包括：
将所述结算优惠名单添加至所述预付业务的业务详情页中，返回所述业务详情页；和/或，
将所述结算优惠名单添加至所述预付业务对应的预付订单中，返回所述预付订单。
14.根据权利要求10或11所述的预付订单处理方法，其特征在于，接收预付业务的预定请求之前，还包括：
接收针对所述预付业务的优惠设置指令，所述优惠设置指令中包括预付阶段、结算阶段、预付数额、结算数额、结算优惠数额获取规则和最高结算优惠数额；
根据所述预付阶段、所述结算阶段、所述预付数额、所述结算数额、所述结算优惠数额获取规则和所述最高结算优惠数额，生成所述预付业务的优惠页面；
在接收到优惠页面获取请求的情况下，返回所述优惠页面。
15.一种预付订单处理客户端，其特征在于，包括：
发送模块，被配置为在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息；
获取模块，被配置为在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额，所述结算优惠数额根据所述预付业务对应的预付订单的生成顺序确定；
第一展示模块，被配置为根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额。
16.一种预付订单处理服务器，其特征在于，包括：
生成模块，被配置为接收预付业务的预定请求，并根据所述预定请求，生成对应的预付订单，返回预定成功信息；
第一确定模块，被配置为根据所述预付订单的生成时间，确定所述预付订单对应的生成顺序；
第二确定模块，被配置为根据所述生成顺序，确定所述预付业务对应的结算优惠数额；
发放模块，被配置为确定发送所述预定请求的用户账号，向所述用户账号发放所述结算优惠数额对应的优惠。
17.一种预付订单处理***，其特征在于，包括：
预付订单处理客户端，被配置为在预付业务处于预付阶段的情况下，发送所述预付业务的预定请求，并接收返回的预定成功信息；在所述预付业务处于结算阶段的情况下，发送所述预付业务的结算请求，获取所述预付业务对应的结算优惠数额；根据所述结算优惠数额，确定并展示所述预付业务对应的待结算数额；
预付订单处理服务器，被配置为接收预付业务的预定请求，并根据所述预定请求，生成对应的预付订单，返回预定成功信息；根据所述预付订单的生成时间，确定所述预付订单对应的生成顺序；根据所述生成顺序，确定所述预付业务对应的结算优惠数额；确定发送所述预定请求的用户账号，向所述用户账号发放所述结算优惠数额对应的优惠。
18.一种计算设备，其特征在于，包括：
存储器和处理器；
所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，以实现权利要求1至9或者10至14任意一项所述预付订单处理方法的步骤。
19.一种计算机可读存储介质，其特征在于，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现权利要求1至9或者10至14任意一项所述预付订单处理方法的步骤。
CN202110507542.8A 2021-05-10 2021-05-10 预付订单处理方法、客户端、服务器及*** Pending CN113516460A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110507542.8A CN113516460A (zh) 2021-05-10 2021-05-10 预付订单处理方法、客户端、服务器及***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110507542.8A CN113516460A (zh) 2021-05-10 2021-05-10 预付订单处理方法、客户端、服务器及***

Publications (1)

Publication Number Publication Date
CN113516460A true CN113516460A (zh) 2021-10-19

Family

ID=78063986

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110507542.8A Pending CN113516460A (zh) 2021-05-10 2021-05-10 预付订单处理方法、客户端、服务器及***

Country Status (1)

Country Link
CN (1) CN113516460A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114529229A (zh) * 2022-04-25 2022-05-24 广州市普丰科技有限公司 根据监控画面行为判断优先级的自行车销售用显示***
CN117196876A (zh) * 2023-11-03 2023-12-08 普链(深圳)企业发展有限公司 任务款项结算方法、装置、电子设备及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107346508A (zh) * 2017-06-27 2017-11-14 湖北智灿网络技术有限公司 一种基于互联网平台的商品预售***
CN107622456A (zh) * 2017-09-26 2018-01-23 安徽网网络科技有限公司 基于移动终端的订座及订餐管理***及其使用方法
CN108460586A (zh) * 2018-02-10 2018-08-28 深圳壹账通智能科技有限公司 一种聚合支付的金额优惠方法、装置、终端设备及存储介质
CN109034952A (zh) * 2018-07-01 2018-12-18 苏州优康网络电子商务有限公司 一种预包装食品的预售***及预售方法
CN109672719A (zh) * 2018-09-26 2019-04-23 深圳壹账通智能科技有限公司 基于用户行为大数据的信息推送方法及相关设备
CN110610401A (zh) * 2019-08-20 2019-12-24 苏州炜晔互联网科技有限公司 一种互联网拼团购物的方法、***、介质及终端
CN112418968A (zh) * 2020-03-16 2021-02-26 上海哔哩哔哩科技有限公司 订单数据处理方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107346508A (zh) * 2017-06-27 2017-11-14 湖北智灿网络技术有限公司 一种基于互联网平台的商品预售***
CN107622456A (zh) * 2017-09-26 2018-01-23 安徽网网络科技有限公司 基于移动终端的订座及订餐管理***及其使用方法
CN108460586A (zh) * 2018-02-10 2018-08-28 深圳壹账通智能科技有限公司 一种聚合支付的金额优惠方法、装置、终端设备及存储介质
CN109034952A (zh) * 2018-07-01 2018-12-18 苏州优康网络电子商务有限公司 一种预包装食品的预售***及预售方法
CN109672719A (zh) * 2018-09-26 2019-04-23 深圳壹账通智能科技有限公司 基于用户行为大数据的信息推送方法及相关设备
CN110610401A (zh) * 2019-08-20 2019-12-24 苏州炜晔互联网科技有限公司 一种互联网拼团购物的方法、***、介质及终端
CN112418968A (zh) * 2020-03-16 2021-02-26 上海哔哩哔哩科技有限公司 订单数据处理方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114529229A (zh) * 2022-04-25 2022-05-24 广州市普丰科技有限公司 根据监控画面行为判断优先级的自行车销售用显示***
CN117196876A (zh) * 2023-11-03 2023-12-08 普链(深圳)企业发展有限公司 任务款项结算方法、装置、电子设备及存储介质
CN117196876B (zh) * 2023-11-03 2024-02-23 普链(深圳)企业发展有限公司 任务款项结算方法、装置、电子设备及存储介质

Similar Documents

Publication Publication Date Title
CN107146077B (zh) 一种支付方法及相应的便携式终端、第三方支付平台
CN109583998B (zh) 一种基于信用值的平台合约执行方法和装置
CN113516460A (zh) 预付订单处理方法、客户端、服务器及***
US20200160296A1 (en) Bill splitting system
JP7302636B2 (ja) 情報処理システム、情報処理方法および情報処理プログラム
WO2019062704A1 (zh) 交易数据处理方法、装置及***
JP2019083052A (ja) 特典管理装置及び特典管理方法
US20130317907A1 (en) Business to Consumer Marketing
JP7077430B2 (ja) 特典管理装置及び特典管理方法
CN110335417B (zh) 电子水票的应用***及方法
CN110717745B (zh) 一种业务处理的方法以及服务器
US20180165685A1 (en) Method, Terminal, and Related Server for Providing Transaction Object
CN113505906B (zh) 对象预定方法及装置
JP6730019B2 (ja) 電子決済システムおよび電子決済方法
CN114445128A (zh) 卡券管理方法、装置、电子设备和计算机可读介质
CN114066300A (zh) 服务提供***及方法
CN103077468A (zh) 一种网上交易中的动态资源分配方法及***
JP2013254323A (ja) クレジットカードのポイント交換システム
JP7181986B2 (ja) 情報処理装置及び情報処理方法
KR102528149B1 (ko) 판매 수익의 분배를 바탕으로 한 상품 판매 촉진 시스템
KR20000058841A (ko) 인터넷을 이용한 화장품 쇼핑몰 운영 방법
KR102277799B1 (ko) 판매 수익 분배를 이용한 상품 판매 촉진 시스템
KR102376640B1 (ko) 이벤트 성공에 따른 판매 수익 분배를 이용한 상품 판매 촉진 시스템
CN115375347A (zh) 虚拟资源发放方法及***
KR102279440B1 (ko) 상품 판매 촉진 시스템

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
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20211019