CN104933558A - 订单支付方法和装置 - Google Patents

Abstract

本发明提出一种订单支付方法和装置，所述订单支付方法包括：接收商家发送的收款请求，所述收款请求是所述商家在接收到用户的支付请求后发送的，所述用户的支付请求是所述用户在对请求的订单消费完成之后发送给所述商家的，所述收款请求包括所述订单对应的消费信息；根据所述收款请求和所述用户的设置进行收款。本发明可以提升用户到线下消费场所，闭环消费的用户体验，用户支付路径较短，操作简便。

Description

订单支付方法和装置

技术领域

本发明涉及互联网技术领域，尤其涉及一种订单支付方法和装置。

背景技术

目前用户的预订或者排队等场景，预订、排队或点菜等操作与买单操作是分离的，买单操作需要用户单独发起，从页面上的专门入口进入，输入价格信息，并最终确认支付。这就使得用户在使用时，整体感很弱，不容易直接想到并使用买单功能，并且买单操作复杂，需要用户发起，同时输入价格信息，并最终确认，用户体验较差。

发明内容

本发明的目的旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本发明的第一个目的在于提出一种订单支付方法。该方法可以提升用户到线下消费场所，闭环消费的用户体验，用户支付路径较短，操作简便。

本发明的第二个目的在于提出一种订单支付装置。

为了实现上述目的，本发明第一方面实施例的订单支付方法，包括：接收商家发送的收款请求，所述收款请求是所述商家在接收到用户的支付请求后发送的，所述用户的支付请求是所述用户在对请求的订单消费完成之后发送给所述商家的，所述收款请求包括所述订单对应的消费信息；根据所述收款请求和所述用户的设置进行收款。

本发明实施例的订单支付方法，接收商家发送的收款请求，上述收款请求是商家在接收到用户的支付请求后发送的，而用户的支付请求是用户在对请求的订单消费完成之后发送给商家的，上述收款请求包括上述订单对应的消费信息，；然后，可以根据上述收款请求和用户的设置进行收款，从而可以提升用户到线下消费场所，闭环消费的用户体验，用户支付路径较短，操作简便。

为了实现上述目的，本发明第二方面实施例的订单支付装置，包括：接收模块，用于接收商家发送的收款请求，所述收款请求是所述商家在接收到用户的支付请求后发送的，所述用户的支付请求是所述用户在对请求的订单消费完成之后发送给所述商家的，所述收款请求包括所述订单对应的消费信息；收款模块，用于根据所述接收模块接收的收款请求和所述用户的设置进行收款。

本发明实施例的订单支付装置，接收模块接收商家发送的收款请求，上述收款请求是商家在接收到用户的支付请求后发送的，而用户的支付请求是用户在对请求的订单消费完成之后发送给商家的，上述收款请求包括上述订单对应的消费信息；然后，收款模块可以根据上述收款请求和用户的设置进行收款，从而可以提升用户到线下消费场所，闭环消费的用户体验，用户支付路径较短，操作简便。

本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本发明订单支付方法一个实施例的流程图；

图2为本发明用户操作界面一个实施例的示意图；

图3为本发明商家操作界面一个实施例的示意图；

图4为本发明无需用户介入的支付通知短信一个实施例的示意图；

图5为本发明需要用户介入的支付通知一个实施例的示意图；

图6为本发明支付信息确认界面一个实施例的示意图；

图7为本发明订单支付装置一个实施例的结构示意图；

图8为本发明订单支付装置另一个实施例的结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。相反，本发明的实施例包括落入所附加权利要求书的精神和内涵范围内的所有变化、修改和等同物。

图1为本发明订单支付方法一个实施例的流程图，如图1所示，该订单支付方法可以包括：

步骤101，接收商家发送的收款请求，上述收款请求是商家在接收到用户的支付请求后发送的，上述用户的支付请求是用户在对请求的订单消费完成之后发送给上述商家的，上述收款请求包括上述订单对应的消费信息。

其中，上述消费信息包括：上述订单对应的消费金额、消费明细和/或账单等相关信息。

步骤102，根据上述收款请求和上述用户的设置进行收款。

本实施例中，步骤101之前，还可以接收用户的订单请求，获得上述用户输入的订单信息，并将上述用户的订单信息发送给商家，以便商家将上述用户的订单信息与上述用户的消费行为进行关联。其中，上述用户的订单请求可以通过用户使用的移动终端上安装的应用(Application；以下简称：APP)发送；上述用户输入的订单信息可以包括用户使用的移动终端的标识(例如：用户的手机号)和用户请求的订单所需的相关信息。

接收到上述用户的订单信息之后，商家可以将用户的消费行为与订单信息进行关联，关联方式可以是用户手机号中的特定几位，或者可以是特定的预订码或排队号等，这样在接收到用户的支付请求之后，商家可以根据该用户的手机号或特定的预订码或排队号获得该用户的订单信息，进而获得订单对应的消费信息，然后商家可以将上述订单对应的消费信息携带在收款请求中。

本实施例中，上述用户的支付请求是通过人工方式发送给上述商家的，例如：用户可以告知相关服务员需要进行支付，然后服务员会在商家后台进行相关的收款操作；或者，上述用户的支付请求是通过点击上述订单中提供的支付功能按键发送给上述商家的，举例来说，上述订单中可以提供“支付”或“结账”的功能按键，用户点击该按键，即向商家发送了支付请求，商家收到用户发送的支付请求之后，会进行相关的收款操作。

本实施例的一种实现方式中，步骤102可以为：当上述用户允许无介入型的直接支付时，根据上述收款请求自动关联用户可享受的优惠信息，并直接从上述用户的账户中扣除上述用户的实际支付金额。进一步地，从上述用户的账户中扣除用户的实际支付金额之后，还可以将用户的实际支付金额和消费信息告知上述用户。

其中，无介入型的直接支付可以包括白条类信贷产品(例如：京东白条、百度白条或淘宝花呗等)，或余额类资产(例如：网站余额或储值卡等)，又或者信用卡网上免密支付的直接支付方式等等，本实施例对无介入型的直接支付的具体形式不作限定。

本实施例的另一种实现方式中，步骤102可以为：当用户不允许无介入型的直接支付时，向用户发送支付通知，上述支付通知中包括用户的支付金额和支付链接；接收到用户通过点击上述支付链接输入的指令之后，向用户展示支付信息确认界面，上述支付信息确认界面中包括用户可享受的优惠信息和用户的实际支付金额；接收用户在上述支付信息确认界面输入的确认指示之后，从上述用户的账户中扣除上述用户的实际支付金额。

上述订单支付方法中，接收商家发送的收款请求，上述收款请求包括上述用户的消费信息，上述收款请求是商家在接收到用户的支付请求后发送的，而用户的支付请求是用户在对请求的订单消费完成之后发送给商家的；然后，可以根据上述收款请求和用户的设置进行收款，从而可以提升用户到线下消费场所，闭环消费的用户体验，用户支付路径较短，操作简便。

本发明图1所示实施例的方法可以应用在预订、排队、团购和/或点菜等场景，只要明确用户会到某个确定地点消费的场景，都可以适用本发明图1所示实施例提供的方法。

下面以预订场景为例进行说明。

1、预订阶段。

用户打开该用户使用的移动终端上安装的APP，通过平台提供的预订功能向平台发送预订请求，然后平台会将预定界面通过APP展示给用户，用户在预订界面上填写订单所需的相关信息，平台就会接收到上述用户的订单信息完成预订操作。在用户预订完之后，用户可以进入图2所示的界面查看自己的订单或进行支付。图2为本发明用户操作界面一个实施例的示意图。

此时平台会将用户的订单信息发送给商家，以便商家将用户的消费行为与预订行为进行关联，关联方式可以是用户手机号中的特定几位，或者可以是特定的预订码或排队号等，这样在接收到用户的支付请求之后，商家可以根据该用户的手机号或特定的预订码或排队号获得该用户的订单信息，进而获得订单对应的消费信息，然后商家可以将上述订单对应的消费信息携带在收款请求中。

2、用户准备结账阶段。

用户在对请求的订单消费完成之后，准备进行支付时，用户可以有两种方式。一种是通过人工方式发送给商家，例如直接告知相关服务员需要进行支付操作，此时服务员知悉后会在商家后台进行相关的收款操作；另一种是用户通过APP，在如图2的界面中，点击“结账”按键，这样用户就向商家发送了支付请求，商家后台接收到用户发送的支付请求之后，会进行相关的收款操作。

3、实际结账阶段。

商家接收到用户的支付请求之后，商家可以在商家后台中操作，在图3所示的界面中输入用户的消费金额(图3中的A区域)，还可以上传账单等相关信息，此处为通过拍照，上传用户的消费明细(图3中的B区域)，在输入完用户的消费信息之后，商家点击图3中的C区域的“向用户收款”按键，即向平台发送了收款请求。图3为本发明商家操作界面一个实施例的示意图。

平台收到商家的收款请求之后，会根据收款请求和用户的设置选择不同的方式进行收款。

一种实现方式中，当用户允许无介入型的直接支付时，例如用户允许使用白条类信贷产品(例如：京东白条、百度白条或淘宝花呗等)，或余额类资产(例如：网站余额或储值卡等)，又或者信用卡网上免密支付的直接支付方式时，平台将根据上述收款请求自动关联用户可享受的优惠信息，并直接从上述用户的账户中扣除上述用户的实际支付金额，完成最终交易，完成交易后，平台将用户的实际支付金额和消费信息通过短信或通知推送的方式告知上述用户，如图4所示，图4为本发明无需用户介入的支付通知短信一个实施例的示意图。

另一种实现方式中，当用户不允许无介入型的直接支付时，平台将以短信或者推送的方式向用户发送支付通知，上述支付通知中可以包括用户的支付金额和支付，链接如图5所示，图5为本发明需要用户介入的支付通知一个实施例的示意图。当用户点击上述支付通知中的支付链接时，用户将进入如图6所示的界面，进行支付信息的确认，图6为本发明支付信息确认界面一个实施例的示意图。在该界面中，用户可以看到该用户可享受的优惠信息，如图6中A区域所示，以及用户的实际支付金额，如图6中B区域所示。因此当用户确认信息后，点击“确认向商家支付”按键，即通过上述支付信息确认界面输入确认指示，接收到该确认指示之后，平台从用户的账户中扣除上述用户的实际支付金额。至此，完成整个支付流程。

此处解释下图6中实际支付金额为508的计算方法：用户购买5张90元的代金券，同时享受平台满300减30的优惠，于是用户通过450-30＝420购买了可以抵用500元的代金券。因为消费总价为588，用户再补上88元，因此总支付金额为420+88＝508元。

本发明中，上述平台可以为第三方支付平台，本发明对平台的具体形式不作限定，只要可以完成上述功能即可。

本发明提供的订单支付方法可以提升用户到线下消费场所，闭环消费(例如：预订加支付)的用户体验，用户支付路径更短，选择优惠更加方便。并且对于商家来说，更便于管理用户，不用担心用户不买单走人，同时当买单人数多时，可以考虑用户体验让用户先行离开，后续完成交易。提供了年轻人更喜欢的白条支付方式，更加容易吸引年轻人使用，对于百度的百度白条产品具有推动作用。并且对于百度糯米的线上到线下(Online toOffline；以下简称：O2O)场景，可以提供目前市场上独有的支付体验。

图7为本发明订单支付装置一个实施例的结构示意图，本实施例中的订单支付装置可以作为平台，或平台的一部分实现本发明图1所示实施例的流程，如图7所示，该订单支付装置可以包括：接收模块71和收款模块72；

其中，接收模块71，用于接收商家发送的收款请求，上述收款请求是商家在接收到用户的支付请求后发送的，上述用户的支付请求是用户在对请求的订单消费完成之后发送给上述商家的，上述收款请求包括上述订单对应的消费信息；其中，上述消费信息包括：上述订单对应的消费金额、消费明细和/或账单等相关信息。

收款模块72，用于根据接收模块71接收的收款请求和上述用户的设置进行收款。

本实施例中，上述平台可以为第三方支付平台，本实施例对平台的具体形式不作限定，只要可以完成上述功能即可。

上述订单支付装置中，接收模块71接收商家发送的收款请求，上述收款请求是商家在接收到用户的支付请求后发送的，而用户的支付请求是用户在对请求的订单消费完成之后发送给商家的，上述收款请求包括上述订单对应的消费信息；然后，收款模块72可以根据上述收款请求和用户的设置进行收款，从而可以提升用户到线下消费场所，闭环消费的用户体验，用户支付路径较短，操作简便。

图8为本发明订单支付装置另一个实施例的结构示意图，与图7所示的订单支付装置相比，不同之处在于，图8所示的订单支付装置中还可以包括：发送模块73；

接收模块71，还用于在接收商家发送的收款请求之前，接收用户的订单请求，获得上述用户输入的订单信息；其中，上述用户的订单请求可以通过用户使用的移动终端上安装的APP发送；上述用户输入的订单信息可以包括用户使用的移动终端的标识(例如：用户的手机号)和用户请求的订单所需的相关信息。

发送模块73，用于将上述用户的订单信息发送给商家，以便商家将上述用户的订单信息与上述用户的消费行为进行关联。本实施例中，接收到上述用户的订单信息之后，商家可以将用户的消费行为与订单信息进行关联，关联方式可以是用户手机号中的特定几位，或者可以是特定的预订码或排队号等，这样在接收到用户的支付请求之后，商家可以根据该用户的手机号或特定的预订码或排队号获得该用户的订单信息，进而获得订单对应的消费信息，然后商家可以将上述订单对应的消费信息携带在收款请求中。

本实施例中，上述用户的支付请求是通过人工方式发送给上述商家的，例如：用户可以告知相关服务员需要进行支付，然后服务员会在商家后台进行相关的收款操作；或者，上述用户的支付请求是通过点击上述订单中提供的支付功能按键发送给上述商家的，举例来说，上述订单中可以提供“支付”或“结账”的功能按键，用户点击该按键，即向商家发送了支付请求，商家收到用户发送的支付请求之后，会进行相关的收款操作。

本实施例的一种实现方式中，收款模块72，具体用于当用户允许无介入型的直接支付时，根据上述收款请求自动关联用户可享受的优惠信息，并直接从上述用户的账户中扣除上述用户的实际支付金额。

进一步地，上述订单支付装置还可以包括：通知模块74；

通知模块74，用于在收款模块72从上述用户的账户中扣除上述用户的实际支付金额之后，将上述用户的实际支付金额和消费信息告知上述用户。

其中，无介入型的直接支付可以包括白条类信贷产品(例如：京东白条、百度白条或淘宝花呗等)，或余额类资产(例如：网站余额或储值卡等)，又或者信用卡网上免密支付的直接支付方式等等，本实施例对无介入型的直接支付的具体形式不作限定。

本实施例的另一种实现方式中，收款模块72，具体用于当上述用户不允许无介入型的直接支付时，通过通知模块74向上述用户发送支付通知，上述支付通知中包括用户的支付金额和支付链接；在接收模块71接收到用户通过点击上述支付链接输入的指令之后，向用户展示支付信息确认界面，上述支付信息确认界面中包括用户可享受的优惠信息和上述用户的实际支付金额；在接收模块71接收用户在上述支付信息确认界面输入的确认指示之后，从上述用户的账户中扣除用户的实际支付金额。

上述订单支付装置可以提升用户到线下消费场所，闭环消费(例如：预订加支付)的用户体验，用户支付路径更短，选择优惠更加方便。并且对于商家来说，更便于管理用户，不用担心用户不买单走人，同时当买单人数多时，可以考虑用户体验让用户先行离开，后续完成交易。提供了年轻人更喜欢的白条支付方式，更加容易吸引年轻人使用，对于百度的百度白条产品具有推动作用。并且对于百度糯米的O2O场景，可以提供目前市场上独有的支付体验。

需要说明的是，在本发明的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(Programmable Gate Array；以下简称：PGA)，现场可编程门阵列(Field ProgrammableGate Array；以下简称：FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，本发明各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (12)

1.一种订单支付方法，其特征在于，包括：

接收商家发送的收款请求，所述收款请求是所述商家在接收到用户的支付请求后发送的，所述用户的支付请求是所述用户在对请求的订单消费完成之后发送给所述商家的，所述收款请求包括所述订单对应的消费信息；

根据所述收款请求和所述用户的设置进行收款。

2.根据权利要求1所述的方法，其特征在于，所述接收商家发送的收款请求之前，还包括：

接收用户的订单请求，获得所述用户输入的订单信息，并将所述用户的订单信息发送给所述商家，以便所述商家将所述用户的订单信息与所述用户的消费行为进行关联。

3.根据权利要求2所述的方法，其特征在于，所述用户的支付请求是通过人工方式发送给所述商家的；或者，所述用户的支付请求是通过点击所述订单中提供的支付功能按键发送给所述商家的。

4.根据权利要求1-3任意一项所述的方法，其特征在于，所述根据所述收款请求和所述用户的设置进行收款包括：

当所述用户允许无介入型的直接支付时，根据所述收款请求自动关联所述用户可享受的优惠信息，并直接从所述用户的账户中扣除所述用户的实际支付金额。

5.根据权利要求4所述的方法，其特征在于，所述从所述用户的账户中扣除所述用户的实际支付金额之后，还包括：

将所述用户的实际支付金额和消费信息告知所述用户。

6.根据权利要求1-3任意一项所述的方法，其特征在于，所述根据所述收款请求和所述用户的设置进行收款包括：

当所述用户不允许无介入型的直接支付时，向所述用户发送支付通知，所述支付通知中包括所述用户的支付金额和支付链接；

接收到所述用户通过点击所述支付链接输入的指令之后，向所述用户展示支付信息确认界面，所述支付信息确认界面中包括所述用户可享受的优惠信息和所述用户的实际支付金额；

接收所述用户在所述支付信息确认界面输入的确认指示之后，从所述用户的账户中扣除所述用户的实际支付金额。

7.一种订单支付装置，其特征在于，包括：

接收模块，用于接收商家发送的收款请求，所述收款请求是所述商家在接收到用户的支付请求后发送的，所述用户的支付请求是所述用户在对请求的订单消费完成之后发送给所述商家的，所述收款请求包括所述订单对应的消费信息；

收款模块，用于根据所述接收模块接收的收款请求和所述用户的设置进行收款。

8.根据权利要求7所述的装置，其特征在于，还包括：发送模块；

所述接收模块，还用于在接收商家发送的收款请求之前，接收用户的订单请求，获得所述用户输入的订单信息；

所述发送模块，用于将所述用户的订单信息发送给所述商家，以便所述商家将所述用户的订单信息与所述用户的消费行为进行关联。

9.根据权利要求8所述的装置，其特征在于，所述用户的支付请求是通过人工方式发送给所述商家的；或者，所述用户的支付请求是通过点击所述订单中提供的支付功能按键发送给所述商家的。

10.根据权利要求7-9任意一项所述的装置，其特征在于，

所述收款模块，具体用于当所述用户允许无介入型的直接支付时，根据所述收款请求自动关联所述用户可享受的优惠信息，并直接从所述用户的账户中扣除所述用户的实际支付金额。

11.根据权利要求10所述的装置，其特征在于，还包括：通知模块；

所述通知模块，用于在所述收款模块从所述用户的账户中扣除所述用户的实际支付金额之后，将所述用户的实际支付金额和消费信息告知所述用户。

12.根据权利要求7-9任意一项所述的装置，其特征在于，还包括：通知模块；

所述收款模块，具体用于当所述用户不允许无介入型的直接支付时，通过所述通知模块向所述用户发送支付通知，所述支付通知中包括所述用户的支付金额和支付链接；在所述接收模块接收到所述用户通过点击所述支付链接输入的指令之后，向所述用户展示支付信息确认界面，所述支付信息确认界面中包括所述用户可享受的优惠信息和所述用户的实际支付金额；在所述接收模块接收所述用户在所述支付信息确认界面输入的确认指示之后，从所述用户的账户中扣除所述用户的实际支付金额。