CN111461701A - 订单处理方法、电子设备及可读存储介质 - Google Patents

Abstract

本申请实施例提供了一种订单处理方法、服务器、收银设备、用户终端、电子设备及可读存储介质。所述订单处理方法包括：获得收银设备的标识和所述收银设备当前对应的第一订单；确定与所述收银设备的标识预先绑定的静态二维码；将所述静态二维码与所述第一订单相关联，以对基于所述静态二维码的第一支付请求进行处理。顾客结账时，将即顾客准备结账的订单与预先绑定的静态二维码关联，顾客的用户终端扫描与收银设备绑定的静态二维码后，将第一订单发送给用户终端，顾客只需要授权用户终端对该第一订单完成支付即可，当顾客支付完成后，商户的收银设备也能自动确定顾客支付的款项所隶属的交易订单。

Description

订单处理方法、电子设备及可读存储介质

技术领域

本申请实施例涉及移动支付技术领域，尤其涉及一种订单处理方法、服务器、收银设备、用户终端、电子设备及可读存储介质。

背景技术

移动支付中，付款方可以通过扫描收款方的收款码向收款方付款。

在线下交易中，顾客是为自己的消费行为、且是与商户协定的消费金额向商户支付；当顾客选择扫描商户的静态二维收款码付款时，对于提供支付服务的交易平台而言，并不获知顾客准备向商户支付的金额，故交易平台部署的服务器获取到顾客终端的支付请求后，向顾客的用户终端返回的是商户的静态二维收款码对应的收款页面，顾客需要在用户终端输出的该收款界面中手动输入支付金额，进而完成付款。

由此可见，顾客通过扫描商户的静态二维收款码支付时，不仅顾客的用户终端不能自动获知顾客需要支付的金额，而且商户的收银设备也无法确定顾客支付的款项所隶属的交易订单。

发明内容

本申请实施例提供一种订单处理方法、服务器、收银设备、用户终端、电子设备及可读存储介质，以解决顾客的用户终端不能自动获知顾客需要支付的金额，而且商户的收银设备也不能自行确定顾客支付的款项所隶属的交易订单的技术问题。

本申请实施例第一方面提供了一种订单处理方法，应用于服务器，所述方法包括：

获得收银设备的标识和所述收银设备当前对应的第一订单；

确定与所述收银设备的标识预先绑定的静态二维码；

将所述静态二维码与所述第一订单相关联，以对基于所述静态二维码的第一支付请求进行处理。

本申请实施例第二方面提供一种订单处理方法，应用于收银设备，所述方法包括：

获得当前对应的第一订单和所述第一订单的支付方式；

在所述第一订单的支付方式是预设支付方式时，向服务器发送所述第一订单，所述预设支付方式是基于与所述收银设备的标识预先绑定的静态二维码的支付方式；

接收所述服务器发送的关联有所述静态二维码的第一订单。

本申请实施例第三方面提供一种订单处理方法，应用于用户终端，所述方法包括：

在检测到对静态二维码的扫描操作时，向服务器发送订单获取请求，所述静态二维码与收银设备的标识预先绑定；

接收并输出所述服务器发送的关联有所述静态二维码的第一订单，所述第一订单是所述收银设备当前对应的订单；

检测用户对所述第一订单的支付操作；

响应于所述支付操作成功，生成订单支付成功消息，并同步至所述服务器。

本申请实施例第四方面提供一种订单处理服务器，包括：

获得模块，用于获得收银设备的标识和所述收银设备当前对应的第一订单；

确定模块，用于确定与所述收银设备的标识预先绑定的静态二维码；

关联模块，用于将所述静态二维码与所述第一订单相关联，以对基于所述静态二维码的第一支付请求进行处理。

本申请实施例第五方面提供一种收银设备，包括：

获得模块，用于获得当前对应的第一订单和所述第一订单的支付方式；

发送模块，用于在所述第一订单的支付方式是预设支付方式时，向服务器发送所述第一订单，所述预设支付方式是基于与所述收银设备的标识预先绑定的静态二维码的支付方式；

接收模块，用于接收所述服务器发送的关联有所述静态二维码的第一订单。

本申请实施例第六方面提供一种用户终端，包括：

发送模块，用于在检测到对静态二维码的扫描操作时，向服务器发送订单获取请求，所述静态二维码与收银设备的标识预先绑定；

处理模块，用于接收并输出所述服务器发送的关联有所述静态二维码的第一订单，所述第一订单是所述收银设备当前对应的订单；

检测模块，用于检测用户对所述第一订单的支付操作；

生成模块，用于响应于所述支付操作成功，生成订单支付成功消息。

本申请实施例第七方面提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请第一方面、第二方面或第三方面所述的方法中的步骤。

本申请实施例第八方面提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行时实现本申请第一方面、第二方面或第三方面所述的方法的步骤。

采用本申请实施例提供的订单处理方法，当顾客准备结账时，交易平台的服务器将收银设备当前对应的第一订单(即顾客准备结账的订单)与预先绑定的静态二维码关联，顾客用自己的用户终端扫描与收银设备绑定的静态二维码后，将收银设备当前对应的第一订单发送给顾客的用户终端，顾客只需要授权用户终端对该第一订单完成支付即可，顾客的用户终端自动获知相应的应付金额，不再需要手动输入支付金额，因为顾客支付得总是收银设备当前对应的第一订单，当顾客支付完成后，商户的收银设备也能自动确定顾客支付的款项所隶属的交易订单。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是台卡上粘贴的美团平台为商户下发的收款码的示意图；

图2是一种收银机和扫码***构示意图的示意图；

图3是商户、顾客和交易平台之间的关系的示意图；

图4是交易订单的示意图；

图5是一种收银机中选择交易订单的支付方式的示意图；

图6是用户终端扫描静态二维码授权支付的示意图；

图7是传统技术中基于静态二维码进行支付的流程示意图；

图8是一已支付订单的示意图；

图9是一录入支付信息后的交易订单的示意图；

图10是本申请的实施例的收银机的结构示意图；

图11是本申请一实施例的收银机绑定静态二维码的流程的示意图；

图12是本申请一实施例的收银机绑定静态二维码的操作示意图；

图13是本申请的一种订单处理方法的流程的示意图；

图14是本申请的实施例的一待支付订单的示意图；

图15是本申请的实施例的用户终端获得订单后的支付操作示意图；

图16是本申请的实施例的另一种订单处理方法的流程的示意图；

图17是本申请的实施例的交易订单关联了已支付订单的示意图；

图18是本申请的实施例的收银机输出关联成功和扫码提示的示意图；

图19是示出本申请的实施例的服务器的示意图；

图20是示出本申请的实施例的收银设备的示意图；

图21是示出本申请的实施例的用户终端的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

按照时效性，二维码包括：静态二维码和动态二维码。静态二维码是指编码不随时间变化而变化的二维码，始终有效。动态二维码是指随着时间变化动态地进行编码的二维码，每次生成的编码，只在有效期内有效，过期后该次编码失效，刷新编码。

按照功能性，支付二维码包括：收款码和付款码。收款码和付款码均是交易平台与用户订立支付协议后，由交易平台向用户下发。收款码是供用户收取款项的二维码，如图1所示的台卡上粘贴的美团平台向商户下发的收款码。付款码是供用户支付款项的二维码。

用户的付款码常置为动态二维码，只能在每次生成的编码的有效期内付款，过期失效，以防止不法分子获取了用户的付款码后盗刷，如支付宝的付款码的有效期是60秒。而收款码多数是静态二维码，如图1所示的收款码是静态二维码，不论何时被扫描，顾客都能向商户付款。

在当前商场、餐厅等商业场所中，商户基本都是采用收银机收银，并提供移动支付。下面先以一示例性的场景阐明本申请要解决的技术问题。

图2示例性地示出了一种收银机101，包括第一屏幕1011(触摸屏)，以输出信息以及供银员录入信息。收银机101还通信连接有扫码枪102。

如图3示例的场景，包括商户001(王二火锅店)，商户001有收银机011(即是隶属于商户001的编号为“011”的收银机，如采用了图2中所示的收银机101，下同，不再解释说明)和收银机012，以供商户001雇佣的收银员111进行收银。交易平台004为商户001下发了静态二维收款码013和静态二维收款码014。还包括进入了商户001消费的顾客051和顾客061，以及各自所持有的手机005和手机006。

继续考图3，交易平台004包括收银***0041和支付***0042，是交易平台004(如美团平台等)部署的服务器或服务器集群。收银***0041支持商户进行收银管理，与收银机交互，按照会计记账方式(如流水账)记录商户的每笔交易订单，供商户通过线上入口(APP或链接地址等)访问调取。支付***响应于顾客的用户终端扫描商户的静态二维收款码后，与用户终端交互，支持顾客通过用户终端扫描商户的静态二维码支付。

收银员111通过收银机011为顾客051和顾客061下单。顾客051和顾客061的交易订单编号为“XXXXXXXXX01”和“XXXXXXXXX02”，如图4A示例了顾客051的交易订单。并在收银机011中生成了如图5A所示的支付队列，以待顾客051和顾客061支付。

当顾客051结账时，如图5A所示，收银员111在收银机101的第一屏幕1011上点击顾客051的交易订单对应的“结算”按钮，收银机011核算该交易订单，如图4B示出了“XXXXXXXXX01”号的交易订单核算后的示意图。如图5B所示，示出了“XXXXXXXXX01”号的交易订单的可选支付方式，包括“静态码收取”、“扫码枪收取”或“动态二维码收取”。

若收银员111点击“动态二维码收取”，根据“XXXXXXXXX01”号的交易订单核算结果，生成对应的动态二维收款码，如在第二屏幕1012示出。顾客051通过手机005扫描该动态二维收款码支付。需要说明的是，有效期内扫描“XXXXXXXXX01”号的交易订单对应的动态二维收款码，只能收取“XXXXXXXXX01”号的交易订单的款项，不能用于收取其他交易订单的款项；如，“XXXXXXXXX02”号的交易订单支付时，需要重新生成“XXXXXXXXX02”号的交易订单对应的动态二维收款码，顾客061通过手机006扫描该新的动态二维码，才能支付编号“XXXXXXXXX02”号的交易订单；若顾客061通过手机006扫描根据“XXXXXXXXX01”号的交易订单生成的动态二维收款码完成了支付，将支付的是“XXXXXXXXX01”号的交易订单，而不是支付“XXXXXXXXX02”号的交易订单。

以顾客051扫描静态二维码013付款说明本申请解决的技术问题。

如图5B所示，若收银员111点击“静态码收取”，顾客051通过手机005中具有扫码功能的APP扫描(如“相机”的扫描功能，或“微信”、“支付宝”、“美团钱包”等内嵌的“扫一扫”功能)商户001的静态二维码013。

请结合参考图6和图7，如图6A所示，手机005中的APP捕捉到静态二维码013的图像，APP响应于扫描到的静态二维码013，向支付***0042发起支付请求；支付***0042向手机005返回如图6B所示的商家001的付款页面，顾客051在付款页面的“金额输入栏”中输入金额“105.00”；响应于顾客051点击“确认支付”按钮，如图6C所示，生成确认支付弹窗；响应于顾客051点击弹窗上的“确认支付”按钮，如图6D所示，生成获取支付权限的弹窗，如是图9所示输入支付密码(面部识别或声纹识别等)授权，最终完成“XXXXXXXXX01”号的交易订单的支付。

当顾客051通过手机005完成支付后，手机005生成支付成功消息，并发送至支付***0042，支付***0042以流水账的形式记录顾客051通过扫描静态二维码013完成支付的支付信息，如图8所示，示出了支付***0042以支付订单的形式记录的支付信息。

由此可知，在现有技术中，顾客通过用户终端扫描商户的静态二维(收款)码支付，收银设备无法将支付金额同步给顾客的用户终端，顾客只有在支付***返回的付款页面中手动输入支付金额，顾客难免输入的支付金额有误；并且，在支付完成后，商户的收银设备也不能自行确定顾客支付的款项所隶属的交易订单。

本申请的发明人在进一步研究后，发现通过扫描商户的静态二维收款码支付时，还会造会计核算困难。下面仍让结合上述示例进行说明。

已知，这种支付方式中，收银设备不能自行确定支付的款项所隶属的交易订单，故需要收银员手工录入支付信息至对应的交易订单上。如上述示例的场景中，收银员111将顾客051的支付信息通过收银机011录入至“XXXXXXXXX01”号的交易订单的相应之处，如图9所示的录入顾客051的支付信息后的交易订单。收银员也难免会输入的支付信息与实际支付信息有误，导致交易订单的支付信息记录错误，给会计核算造成困难。

商户001进行会计对账这类账单时，需要从收银机011和收银机012中获取每笔手工录入支付信息的交易订单的流水信息，然后再从支付***0042中获取每笔支付订单的流水信息。然后会计人员一笔交易订单、一笔支付订单地进行一一人工比对，核算每笔交易订单的实收金额。在会计周期内，会产生大量交易订单和支付订单，这将非常难以进行会计核算。

在这种静态二维码支付的场景中，不论是商户(尤其是收银员和会计人员)还是顾客经常面临上述问题，故商户和顾客一直都迫切渴望得到解决。但这种支付方式的支付的流程对于商户和/或顾客而言，都是不透明的，故商户和/或顾客对上述技术问题感到非常棘手。

本申请的发明人在进行深入研究后，创造性地提出本申请的发明构思：预先将每个商户的每个收银设备和一个静态二维(收款)码绑定，当收银设备中的交易订单准备通过扫描静态二维码支付时，则将该笔交易订单与该收银设备绑定的静态二维码相关联，当顾客的用户终端扫描静态二维码进行支付时，向顾客的用户终端直接返回包括该笔交易订单的待支付金额的支付界面，顾客直接进行支付即可。顾客支付完成后，收银机可以自行确定到账的款项隶属于当前结算订单，并对其记录和同步。

本申请的技术方案仍然以图3所示的场景说明。为便于对本申请的技术方案的实质进行清楚地说明，下面直接将交易平台004的所有服务器和/或服务器集群看成一个服务器对外提供服务，即下文的服务器004等同于交易平台004(的所有服务器或服务器集群)，但这不是对本申请的限制。

图10是本申请一实施例示例性示出的一种收银机的示意图。

基于图4所示的实施例，请参考图4，收银机101还包括第二屏幕1012，第二屏幕1012用于向顾客展示信息等。

基于图4所示的实施例，请参考图10，收银机101还包括设置在收银机101本体内部的通信模块1013，可通过无线和/或有线链路与外部进行通信，如与图2中的扫码枪102进行通信、与图3中的服务器004进行通信。收银机101还可包括设置于收银机101本体内部的扬声器1015、内存1016、非易失性存储器1017等。收银机101还包括设置于收银机101本体内部的处理模块1014，可与通信模块1013、扬声器1015、第一屏幕1011和第二屏幕1012电性连接，该处理模块1014根据不同的指令驱动相应的模块执行相应的操作。所述处理模块1014可以为MCU、CPU，FPGA等。以上都是示例，本说明书不作限制。

随后说明书中所涉及的收银设备主要是图2和图10示出的收银机，这也只是一种示例，不是对本申请的限制。收银设备还可以是图3所示的商户001所持有的智能终端015，如智能手机，平板电脑、AI机器人等。

基于上述发明构思，需要预先将商户的每个收银设备与商户的一个静态二维(收款)码绑定，在本实施例中，可以通过以下方式进行绑定：

如图11所示，图11示例性地示出了一种将收银设备与静态二维码进行绑定的流程图。包括：

S101，在检测到二维码绑定操作时，向扫码枪发送激活指令。

S102，激活所述扫码枪。

S103，扫描静态二维码。

在本申请的实施例中，交易平台为每个商户下发有至少一个静态二维(收款)码；服务器004还与商户的收银设备进行通信，支持收银服务。

以图3中商户001的编号为“011”的收银机与静态二维码013进行绑定为例，请结合参考图11和图12，请参考12A，当编号为“011”的收银机101检测到第一屏幕1011上的“开通静态码收取”被点击，并复选了“绑定二维码”选项，收银机101向扫码枪102发送激活指令，激活扫码枪102。请参考图12B，收银机101在检测到扫码枪102被激活后，在第一屏幕1011上输出“请扫描欲绑定的静态二维码”的提示信息。如收银员111将图1所示的粘贴在台卡上的静态二维码013悬停在图2所示收银机101通信的扫码枪102的扫码窗口1021上方，扫描静态二维码013。

S104-S105，在检测到所述扫码枪扫描的所述静态二维码时，向所述服务器发送绑定请求，所述绑定请求携带所述静态二维码和所述收银设备的标识。

S106，服务器接收所述收银设备发送的绑定请求，所述绑定请求携带所述静态二维码和所述收银设备的标识；并将所述收银设备的标识与所述静态二维码绑定。

收银设备的标识用于标识收银设备的身份(还可以指示所隶属的商户)。如可以是收银设备的指纹信息(如厂家、软件固件信息、硬件信息等)、收银设备的编号等，如是图3所示收银设备的编号(收银机011、收银机012…，或智能终端015的设备标识)，在本申请中不作具体限制。参考图2和图11，当收银机101通过扫码枪102扫描到静态二维码013后，将收银机101的设备标识和静态二维码013的编码发送至服务器004。

以上述图3所示场景，在将所有的商户的静态二维码和所有商户的所有收银机的标识绑定后，在服务器004中将存在表1所示的映射关系表。

S107，服务器向收银机返回绑定成功信息，收银机输出绑定成功提示。如可以是在收银机101的第一屏幕1011输出“绑定成功”。

表1收银机与静态二维码绑定关系映射表

在另一实施方式中，收银机011(也即图2中的收银机101)在检测到扫码枪102扫描的静态二维码013时，收银机011直接将收银设备011的标识与静态二维码013绑定，然后收银机011再将绑定信息同步至服务器004。服务器004存储所有的绑定关系，并建立如表1所示的映射表。若商户用智能终端作为收银设备，则可以为智能终端指定绑定的静态二维码。

以上是以图3中的收银机011绑定静态二维码013的示例，其他的收银机与静态二维码的绑定方式相似，在此不再赘述。

图13是本申请一实施例提出的订单处理方法的流程图。如图13所示，该方法包括以下步骤：

S301，获得收银设备的标识和所述收银设备当前对应的第一订单。

所述收银设备当前对应的第一订单是当前时刻顾客准备结算的订单。结账时，选择的是通过扫描商户的静态二维码完成支付，则收银机将自身的设备标识(如编号)和所述收银设备当前正在结算的订单发送至服务器。服务器还可以根据HTTP协议，基于IP地址追踪发送第一订单的收银设备的设备标识。当然也可以其他方式获得，本申请不作具体限制。

所述第一订单是包含了消费内容的交易订单或根据交易订单生成的待支付订单，均可以根据调整信息(用于调整消费金额，以确定应收金额，如优惠、打折等，由商户和/或交易平台赋予给顾客)调整消费金额，如图4所示的是顾客051准备支付的包含调整信息的“XXXXXXXXX01”号的交易订单。而待支付订单由收银机生成后发送给服务器；或，收银机将交易订单发送给服务器，服务器根据交易订单生成。如图8是根据顾客051的编号为“XXXXXXXXX01”号的交易订单和优惠信息生成的待支付订单。

顾客051结账时，如图5B所示，收银员111为顾客051选择的是扫描静态二维码支付。收银机101将根据编号为“XXXXXXXXX01”号的交易订单确定的第一订单(交易订单或待支付订单)和收银设备011的设备标识发送给服务器。

S302，确定与所述收银设备的标识预先绑定的静态二维码。

服务器查询发送第一订单的收银设备标识绑定的静态二维码，如通过上述表1查询到收银设备011绑定的是静态二维码013。

S303，将所述静态二维码与所述第一订单相关联，以对基于所述静态二维码的第一支付请求进行处理。

用户终端与服务器基于HTTP协议通信，即用户终端扫描所述静态二维码后向服务器发送一个请求(request)，服务器根据该request返回该静态二维码对应的响应消息(report)。服务器将确定的静态二位码和第一订单相关联，如将第一订单写入响应于基于静态二维码的request的report的链接中，当用户终端扫描该静态二维码发起访问时，不再向用户终端返回图6B所示的付款界面，而如图15A所示是返回第一订单，手机005上输出“XXXXXXXXX01”号交易订单的第一订单，包括应支付的金额。顾客051只要授权支付即可，不需要手动输入支付金额。第一订单还可以包括顾客的交易详情，如顾客051消费的火锅以及配菜的单价、数量等。

采用本申请实施例提供的订单处理方法，当顾客准备结账时，交易平台的服务器将收银设备当前对应的第一订单(即顾客准备结账的订单)与预先绑定的静态二维码关联，顾客用自己的用户终端扫描与收银设备绑定的静态二维码后，将收银设备当前对应的第一订单发送给顾客的用户终端，顾客只需要授权用户终端对该第一订单完成支付即可，顾客的用户终端自动获知相应的应付金额，不再需要手动输入支付金额，因为顾客支付得总是收银设备当前对应的第一订单，当顾客支付完成后，商户的收银设备也能自动确定顾客支付的款项所隶属的交易订单。避免了顾客因输入的支付金额不正确导致的支付错误。也不需要收银员手动录入支付信息，避免人工录入错误。并且收银设备可以自动确定顾客的支付信息所隶属的交易订单，为会计核算降低了工作难度。

在另一个可选的实施例中，所述第一订单的类型为第一类型；即所述订单为交易订单，在步骤S303，在将所述静态二维码与所述第一订单相关联之前，所述方法还包括：

S3021，根据所述第一类型的第一订单的订单内容和待支付金额，生成第二类型的第一订单。第二类型的第一订单是待支付订单。

交易订单包括消费详情；待支付金额是需要支付的金额，如图4所示。根据消费详情和待支付金额直接生成待支付订单，如图14所示的生成的待支付订单。当然待支付订单还可以包括消费详情，本申请不作限制。

步骤S303，将所述静态二维码与所述第一订单相关联，包括：

S3031，将所述静态二维码与所述第二类型的第一订单相关联。

将待支付订单与静态二维码关联，当用户终端基于静态二维码发起支付待支付订单请求时，如图16A所示，返回待支付订单。

在一个可选的实施例中，订单处理方法还包括：

S304，获得所述收银设备当前对应的第二订单。

S305，解除所述静态二维码与所述第一订单之间的关联，并将所述静态二维码与所述第二订单相关联，以对基于所述静态二维码的第二支付请求进行处理。

第二订单是指在第一订单支付完成后，所获取的下一个新的准备支付的订单。第二支付请求是相对于第一支付请求而言的，是指用户终端扫描静态二维码时再次发起的订单获取请求。

如图5A所示的“XXXXXXXXX01”号交易订单支付完成后，接着结算的“XXXXXXXXX02”号的交易订单就是第二订单。如顾客061的手机006扫描静态二维码013再次发起的订单获取请求，此时将基于所述静态二维码013处理编号为“XXXXXXXXX02”号的交易订单，该订单获取请求就是第二支付请求。“XXXXXXXXX02”号的交易订单与“XXXXXXXXX01”号的交易订单的支付流程相似，在此不再赘述。对收银机支付队列中的交易订单的进行循环，使每笔交易订单均能基于静态二维码实现支付。

图16是本申请一实施例提出的订单处理方法的流程图。如图16所示，该方法包括以下步骤：

S401，收银设备获得当前对应的第一订单和所述第一订单的支付方式。

所述收银设备当前对应的第一订单是当前时刻顾客准备结算的订单。请参见上文步骤S301中的详细介绍。收银设备获得当前对应的第一订单和所述第一订单的支付方式(“静态码收取”、“扫码枪收取”、或“其他方式收取”等等)，如图5A和图5B所示例，收银员或其他人员点击相应的触控按钮触发相应的指令，更具体地，请参见前文相关介绍，在此不再赘述。

S402，在所述第一订单的支付方式是预设支付方式时，收银设备向服务器发送所述第一订单，所述预设支付方式是基于与所述收银设备的标识预先绑定的静态二维码的支付方式。

预设支付方式是指示顾客扫描与该收银设备的标识绑定的静态二维码支付。如收银员111点击“静态码收取”，收银机011向服务器004发送“XXXXXXXXX01”号订单，并指示顾客051扫描静态二维码013支付。

S403，服务器获得收银设备的标识和所述收银设备当前对应的第一订单。

S404，服务器确定与所述收银设备的标识预先绑定的静态二维码。

S405，将所述静态二维码与所述第一订单相关联，以对基于所述静态二维码的第一支付请求进行处理。

步骤S403至S405一一对应步骤S301至S303，具体请参见上文。

S406，用户终端在检测到对静态二维码的扫描操作时，向服务器发送订单获取请求，所述静态二维码与收银设备的标识预先绑定。

用户终端即顾客所持有具有移动支付功能的终端，如手机等。

订单获取请求用于向服务器请求支付订单，以供顾客进行支付。

如是顾客051的手机005扫描了静态二维码013，手机005将响应于扫描到静态二维码013的编码，向服务器004发送订单获取请求，以请求顾客051准备支付的订单：“XXXXXXXXX01”号订单。

S407，服务器在接收到用户终端的订单获取请求后，将向用户终端返回所述静态二维码关联的第一订单；用户终端接收并输出所述服务器发送的关联有所述静态二维码的第一订单，所述第一订单是所述收银设备当前对应的订单。

在可选地实施方式中，步骤S407还包括：S4071和S4072。

S4071，服务器接收用户终端发送的基于所述静态二维码的第一支付请求，所述第一支付请求是所述用户终端在检测到所述静态二维码被扫描而生成的。

第一支付请求即用户终端发送的订单获取请求，当用户终端扫描到所述静态二维码后，将自动向服务器发起。具体请参见前文相关说明。

S4072，服务器获取并向所述用户终端返回关联有所述静态二维码的第一订单。

服务器基于HTTP协议向用户终端返回关联的第一订单，具体请参见步骤S303，在此不再赘述。

S408，用户终端检测用户对所述第一订单的支付操作。

检测顾客是否对该第一订单进行了支付。如图15B所示，检测用户是否点击了确认支付按钮，以及用户是否是直接关闭了该支付界面。

S409，用户终端响应于所述支付操作成功，生成订单支付成功消息，并同步至所述服务器。

支付操作成功是指顾客对用户终端上输出的待支付订单完成了支付。如是用户点击了图15B中的确认支付按钮并授权完成支付后，跳转至图15C，输出支付成功提示。用户取消支付，如直接关闭图15A的支付页面或图15B的支付确认界面，均意味着支付失败。在顾客支付完成后，用户终端会生成支付成功消息，并将支付成功消息同步至服务器。支付成功消息用于指示第一订单已经支付完成，可以包括支付设备的设备信息等。

如顾客051在手机005上执行了上述S406至S409的步骤后，完成了支付，手机005会将支付成功消息发送至服务器004。

当顾客准备结账时，将收银设备当前对应的第一订单(即顾客准备结账的订单)与预先绑定的静态二维码关联，顾客用自己的用户终端扫描与收银设备绑定的静态二维码后，将收银设备当前对应的第一订单发送给顾客的用户终端，顾客只需要授权用户终端对该第一订单完成支付即可，不再需要手动输入支付金额。避免了顾客通过用户终端扫描静态二维码支付时，因输入的支付金额错误导致的支付错误的尴尬情形地出现。

S410，收银设备接收所述服务器发送的关联有所述静态二维码的第一订单。

关联有所述静态二维码的第一订单是消费支付完成后第一订单。

顾客在对第一订单支付完成后，服务器更新第一订单已支付，并发送给收银设备，收银设备更新第一订单为已支付，并同步顾客支付的支付信息。如根据用户终端的支付成功消息生成已支付订单，并关联至对应的交易订单，如图17所示。顾客总是支付收银设备当前对应的第一订单，当顾客支付完成后，收银设备自动将已支付订单关联至对应的交易订单，自动确定顾客支付的款项所隶属的交易订单。不需要收银员手动录入顾客的支付信息，避免人工录入错误，并且收银设备自动确定顾客的支付信息所隶属的交易订单，为会计核算降低了工作难度。

由此可见，使得顾客在支付消费时，不再需要输入支付金额，支付更加便捷；同时，收银员不需要录入顾客的支付信息，降低了工作失误率；不再需要一笔一笔地比对交易订单和支付订单，会计核算更加简单可行。

在一个可选的实施例中，在步骤S401之后，收银设备还执行以下步骤：

S4011，在所获得的第一订单的类型为第一类型时，根据所述第一类型的第一订单的订单内容和待支付金额，生成第二类型的第一订单。第一类型的第一订单是交易订单，第二类型的第一订单是待支付订单。

交易订单包括消费详情，待支付金额是需要支付的金额，如是图4所示。根据消费详情和待支付金额直接生成待支付订单，如图14所示的生成的待支付订单。当然待支付订单还可以包括消费详情，本申请不作限制。

步骤S402，在所述第一订单的支付方式是预设支付方式时，向服务器发送所述第一订单，包括：S4021，在所述第一订单的支付方式是预设支付方式时，向服务器发送所述第二类型的第一订单。

在当前订单是基于静态二维码支付时，将待支付订单发送给服务器，服务器将待支付订单和收银设备绑定的静态二维码关联，以待顾客支付。

在又一个可选的实施例中，收银设备还执行以下步骤：在步骤S406，在将所述静态二维码与所述第一订单相关联之后，所述方法还包括：

S401，服务器向所述收银设备发送扫码操作的提示消息；

S402，收银机接收所述服务器发送的扫码操作的提示消息，并根据所述扫码操作的提示消息，输出扫码操作提示。和/或，

S403，服务器向所述收银设备发送关联成功的消息；

S404，接收所述服务器发送的关联成功的消息，并根据所述关联成功的消息，输出关联成功的提示。

如收银机的处理模块1014驱动第二屏幕1012输出扫描操作提示，如图18A所示，同时还可以在第二屏幕1012上输出顾客的详细的交易信息。和/或，收银机的处理模块1014驱动第一屏幕1011输出关联成功提示，如图18B所示。并同步驱动扬声器1015输出“请扫码”的语音提示。

在另一个可选的实施例中，收银设备还执行以下步骤：在步骤S410之后，订单处理方法还包括：

S411，服务器接收所述用户终端发送的订单支付成功消息，并将所述订单支付成功消息同步至所述收银设备。

收银设备响应于该支付成功消息，将已支付订单关联至相应的交易订单，如图17所示；同时，收银机的处理模块1014还可以响应于该支付成功消息，驱动第一屏幕1011和/或第二屏幕1012输出支付成功的提示，分别用于提示收银员和顾客，相应订单已经完成支付，还可以同步驱动扬声器1015输出语音提示，如“‘XXXXXXXXX01’号订单支付成功”。

需要说明的是，本申请说明书附图旨在示例性地辅助说明本申请的技术方案，并不是对本申请的限制。尤其是附图中所涉及的图元的数量(如图3中示例的商户、收银员、收银设备、商户的静态二维收款码、顾客、用户终端、交易平台的服务器的数量)均不应当解释为对本申请的限制。图2、图3和图10中的收银机只是一种示例的收银设备，收银设备还可以手机、平板电脑、个人计算机、智能AI机器人等，本申请不做具体限制。

另外，出于隐私保护的需要，对说明书附图中所有的二维码图元均作了部分遮挡处理(如图1、图3中的二维码中)，但仍能确定该图元是二维码，故不应当将这些二维码图元中的遮挡部分解释为是附图不清楚。

基于同一发明构思，本申请一实施例提供一种订单处理服务器。参考图19，图19是本申请一实施例提供的订单服务器500的示意图。如图35所示，该服务器500包括：

获得模块501，用于获得收银设备的标识和所述收银设备当前对应的第一订单；

确定模块502，用于确定与所述收银设备的标识预先绑定的静态二维码；

关联模块503，用于将所述静态二维码与所述第一订单相关联，以对基于所述静态二维码的第一支付请求进行处理。

可选的，所述服务器还包括：

第一接收模块，用于接收用户终端发送的基于所述静态二维码的第一支付请求，所述第一支付请求是所述用户终端在检测到所述静态二维码被扫描而生成的；

返回模块，用于获取并向所述用户终端返回关联有所述静态二维码的第一订单。

可选地，所述服务器还包括：

第二订单获得模块，用于获得所述收银设备当前对应的第二订单；

第二订单关联模块，用于解除所述静态二维码与所述第一订单之间的关联，并将所述静态二维码与所述第二订单相关联，以对基于所述静态二维码的第二支付请求进行处理。

可选地，所述第一订单的类型为第一类型；所述服务器还包括：

生成模块，用于根据所述第一类型的第一订单的订单内容和待支付金额，生成第二类型的第一订单；

所述关联模块包括：

关联单元，用于将所述静态二维码与所述第二类型的第一订单相关联。

可选地，所述服务器还包括：

第二接收模块，用于接收所述收银设备发送的绑定请求，所述绑定请求携带所述静态二维码和所述收银设备的标识；

绑定模块，用于将所述收银设备的标识与所述静态二维码绑定。

可选地，所述服务器还包括：

第三接收模块，用于接收所述用户终端发送的订单支付成功消息，并将所述订单支付成功消息同步至所述收银设备。

可选地，所述服务器还包括：

第一发送模块，用于向所述收银设备发送扫码操作的提示消息，以使所述收银设备根据所述扫码操作的提示消息，输出扫码操作提示；和/或

第二发送模块，用于向所述收银设备发送关联成功的消息，以使所述收银设备根据所述关联成功的消息，输出关联成功的提示。

基于同一发明构思，本申请一实施例提供一种收银设备。参考图20，图20是本申请一实施例提供的收银设备700的示意图。如图20所示，该收银设备700包括：

获得模块601，用于获得当前对应的第一订单和所述第一订单的支付方式；

发送模块602，用于在所述第一订单的支付方式是预设支付方式时，向服务器发送所述第一订单，所述预设支付方式是基于与所述收银设备的标识预先绑定的静态二维码的支付方式；

接收模块603，用于接收所述服务器发送的关联有所述静态二维码的第一订单。

可选地，所述收银获得模块包括：

生成单元，用于在所获得的第一订单的类型为第一类型时，根据所述第一类型的第一订单的订单内容和待支付金额，生成第二类型的第一订单；

所述发送模块包括：

发送单元，用于在所述第一订单的支付方式是预设支付方式时，向服务器发送所述第二类型的第一订单。

可选的，所述收银设备还包括：

激活指令发送模块，用于在检测到二维码绑定操作时，向扫码枪发送激活指令，以激活所述扫码枪；

绑定模块，用于在检测到所述扫码枪扫描的所述静态二维码时，将所述收银设备的标识与所述静态二维码绑定，并同步至所述服务器，或，绑定请求发送模块，用于向所述服务器发送绑定请求，所述绑定请求携带所述静态二维码和所述收银设备的标识。

可选的，所述收银设备还包括：

提示信息接收输出模块，用于接收所述服务器发送的扫码操作的提示消息，并根据所述扫码操作的提示消息，输出扫码操作提示；和/或，

关联成功信息接收输出模块，用于接收所述服务器发送的关联成功的消息，并根据所述关联成功的消息，输出关联成功的提示。

基于同一发明构思，本申请一实施例提供一种用户终端。参考图21，图21是本申请一实施例提供的用户终端的示意图。如图21所示，该用户终端包括：

发送模块701，用于在检测到对静态二维码的扫描操作时，向服务器发送订单获取请求，所述静态二维码与收银设备的标识预先绑定；

处理模块702，用于接收并输出所述服务器发送的关联有所述静态二维码的第一订单，所述第一订单是所述收银设备当前对应的订单；

检测模块703，用于检测用户对所述第一订单的支付操作；

生成模块704，用于响应于所述支付操作成功，生成订单支付成功消息。

基于同一发明构思，本申请另一实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请上述任一实施例所述的方法中的步骤。

基于同一发明构思，本申请另一实施例提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行时实现本申请上述任一实施例所述的方法中的步骤。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。故，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请实施例是参照根据本申请实施例的方法、终端设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种订单处理方法、服务器、收银设备、用户终端、电子设备和存储介质，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (17)

1.一种订单处理方法，其特征在于，应用于服务器，所述方法包括：

获得收银设备的标识和所述收银设备当前对应的第一订单；

确定与所述收银设备的标识预先绑定的静态二维码；

将所述静态二维码与所述第一订单相关联，以对基于所述静态二维码的第一支付请求进行处理。

2.根据权利要求1所述的方法，其特征在于，在将所述静态二维码与所述第一订单相关联之后，所述方法还包括：

接收用户终端发送的基于所述静态二维码的第一支付请求，所述第一支付请求是所述用户终端在检测到所述静态二维码被扫描而生成的；

获取并向所述用户终端返回关联有所述静态二维码的第一订单。

3.根据权利要求1所述的方法，其特征在于，在将所述静态二维码与所述第一订单相关联之后，所述方法还包括：

获得所述收银设备当前对应的第二订单；

解除所述静态二维码与所述第一订单之间的关联，并将所述静态二维码与所述第二订单相关联，以对基于所述静态二维码的第二支付请求进行处理。

4.根据权利要求1所述的方法，其特征在于，所述第一订单的类型为第一类型；在将所述静态二维码与所述第一订单相关联之前，所述方法还包括：

根据所述第一类型的第一订单的订单内容和待支付金额，生成第二类型的第一订单；

将所述静态二维码与所述第一订单相关联，包括：

将所述静态二维码与所述第二类型的第一订单相关联。

5.根据权利要求1至4任一项所述的方法，其特征在于，在获得收银设备的标识和所述收银设备当前对应的第一订单之前，所述方法还包括：

接收所述收银设备发送的绑定请求，所述绑定请求携带所述静态二维码和所述收银设备的标识；

将所述收银设备的标识与所述静态二维码绑定。

6.根据权利要求2至4任一项所述的方法，其特征在于，在获取并向所述用户终端返回关联有所述静态二维码的第一订单之后，所述方法还包括：

接收所述用户终端发送的订单支付成功消息，并将所述订单支付成功消息同步至所述收银设备。

7.根据权利要求1至4任一项所述的方法，其特征在于，在将所所述静态二维码与所述第一订单相关联之后，所述方法还包括：

向所述收银设备发送扫码操作的提示消息，以使所述收银设备根据所述扫码操作的提示消息，输出扫码操作提示；和/或

向所述收银设备发送关联成功的消息，以使所述收银设备根据所述关联成功的消息，输出关联成功的提示。

8.一种订单处理方法，其特征在于，应用于收银设备，所述方法包括：

获得当前对应的第一订单和所述第一订单的支付方式；

在所述第一订单的支付方式是预设支付方式时，向服务器发送所述第一订单，所述预设支付方式是基于与所述收银设备的标识预先绑定的静态二维码的支付方式；

接收所述服务器发送的关联有所述静态二维码的第一订单。

9.根据权利要求8所述的方法，其特征在于，在获得当前对应的第一订单之后，所述方法还包括：

在所获得的第一订单的类型为第一类型时，根据所述第一类型的第一订单的订单内容和待支付金额，生成第二类型的第一订单；

在所述第一订单的支付方式是预设支付方式时，向服务器发送所述第一订单，包括：

在所述第一订单的支付方式是预设支付方式时，向服务器发送所述第二类型的第一订单。

10.根据权利要求8所述的方法，其特征在于，在向服务器发送所述第一订单之前，所述方法还包括：

在检测到二维码绑定操作时，向扫码枪发送激活指令，以激活所述扫码枪；

在检测到所述扫码枪扫描的所述静态二维码时，将所述收银设备的标识与所述静态二维码绑定，并同步至所述服务器，或，向所述服务器发送绑定请求，所述绑定请求携带所述静态二维码和所述收银设备的标识。

11.根据权利要求8-10任一所述的方法，其特征在于，在向服务器发送所述第一订单之后，还包括：

接收所述服务器发送的扫码操作的提示消息，并根据所述扫码操作的提示消息，输出扫码操作提示；和/或，

接收所述服务器发送的关联成功的消息，并根据所述关联成功的消息，输出关联成功的提示。

12.一种订单处理方法，其特征在于，应用于用户终端，包括：

在检测到对静态二维码的扫描操作时，向服务器发送订单获取请求，所述静态二维码与收银设备的标识预先绑定；

接收并输出所述服务器发送的关联有所述静态二维码的第一订单，所述第一订单是所述收银设备当前对应的订单；

检测用户对所述第一订单的支付操作；

响应于所述支付操作成功，生成订单支付成功消息，并同步至所述服务器。

13.一种订单处理服务器，其特征在于，包括：

获得模块，用于获得收银设备的标识和所述收银设备当前对应的第一订单；

确定模块，用于确定与所述收银设备的标识预先绑定的静态二维码；

关联模块，用于将所述静态二维码与所述第一订单相关联，以对基于所述静态二维码的第一支付请求进行处理。

14.一种收银设备，其特征在于，包括：

获得模块，用于获得当前对应的第一订单和所述第一订单的支付方式；

发送模块，用于在所述第一订单的支付方式是预设支付方式时，向服务器发送所述第一订单，所述预设支付方式是基于与所述收银设备的标识预先绑定的静态二维码的支付方式；

接收模块，用于接收所述服务器发送的关联有所述静态二维码的第一订单。

15.一种用户终端，其特征在于，包括：

发送模块，用于在检测到对静态二维码的扫描操作时，向服务器发送订单获取请求，所述静态二维码与收银设备的标识预先绑定；

处理模块，用于接收并输出所述服务器发送的关联有所述静态二维码的第一订单，所述第一订单是所述收银设备当前对应的订单；

检测模块，用于检测用户对所述第一订单的支付操作；

生成模块，用于响应于所述支付操作成功，生成订单支付成功消息。

16.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1至7任一项、或权利要求8至11任一项、或权利要求12所述的方法中的步骤。

17.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行时实现如权利要求1至7任一项、或权利要求8至11任一项、或权利要求12所述的方法的步骤。

Images