CN112200968B - 扫码支付方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明提供了一种扫码支付方法、装置、电子设备及存储介质。扫码支付方法包括：在接收到扫描目标二维码触发的支付请求时，基于预先建立的二维码与车牌号的绑定关系，获取目标二维码绑定的目标车牌号；基于预先存储的车牌号与车机设备号的绑定关系，获取目标车牌号对应的目标车机设备号，并查询目标车机设备号对应的车机端当前登录的司机账号；创建支付请求对应的待支付订单，并关联待支付订单和所述司机账号，对待支付订单进行支付操作。本发明将二维码与车牌号绑定，乘客扫码支付时，实时匹配该车牌号对应的车机端当前登录的司机账号，从而将支付的费用自动关联到当前登录的司机账号，司机换班后无需换码即可实现准确支付，处理过程更加简便。

Description

扫码支付方法、装置、电子设备及存储介质

技术领域

本发明涉及互联网技术领域，特别是涉及一种扫码支付方法、装置、电子设备及存储介质。

背景技术

随着互联网技术的迅速发展，出租车服务越来越受到用户的青睐，用户通过出租车服务能够更加便利地进行乘车。

为了方便乘客支付，目前的出租车通常都支持扫码支付。目前，出租车的各类收款码，采用司机与收款码绑定的方式，乘客扫码支付后将费用打到绑定的司机账户。但是，由于一辆出租车通常会分配至少两个司机，因此会存在司机换班的情况，导致司机换班时也需要换码。同时为了保障支付的准确性，也无法将收款码放置到车内方便乘客扫码的固定位置，每次支付均需要司机单独出示收款码。因此，现有的扫码支付方案处理过程复杂，给司机乘客的支付过程带来不便。

发明内容

鉴于上述问题，提出了本发明实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种扫码支付方法、装置、电子设备及存储介质。

第一方面，本发明实施例公开了一种扫码支付方法，执行于服务端，所述方法包括：

在接收到扫描目标二维码触发的支付请求时，基于预先建立的二维码与车牌号的绑定关系，获取所述目标二维码绑定的目标车牌号；

基于预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号，并查询所述目标车机设备号对应的车机端当前登录的司机账号；

创建所述支付请求对应的待支付订单，并关联所述待支付订单和所述司机账号，对所述待支付订单进行支付操作。

可选地，所述二维码与车牌号的绑定关系通过如下方式建立：在接收到扫描预先下发的二维码触发的绑定请求时，识别所述二维码是否已绑定车牌号；在未绑定车牌号时，接收车牌号和司机身份信息，并分别对所述车牌号和所述司机身份信息进行校验；在所述车牌号和所述司机身份信息均校验成功时，建立所述车牌号与所述二维码的绑定关系。

可选地，所述二维码与车牌号的绑定关系通过如下方式建立：在接收到二维码申请请求时，获取所述二维码申请请求中携带的车牌号和司机身份信息；分别对所述车牌号和所述司机身份信息进行校验；在所述车牌号和所述司机身份信息均校验成功时，获取未绑定车牌号的二维码，建立所述车牌号与所述二维码的绑定关系。

可选地，在创建所述支付请求对应的待支付订单之后，还包括：查询当前是否存在所述目标车牌号对应的行程信息；在存在所述行程信息时，关联所述行程信息和所述待支付订单。

可选地，在接收到扫描目标二维码触发的支付请求时，基于预先建立的二维码与车牌号的绑定关系，获取所述目标二维码绑定的目标车牌号之前，还包括：确定出司机在车机端刷卡登录成功后，获取刷卡登录时上传的车牌号和车机设备号；将所述上传的车牌号和车机设备号，与当前存储的车牌号与车机设备号的绑定关系进行对比；在对比结果不一致时，如果所述上传的车牌号和车机设备号被上传的次数达到预设次数，则利用所述上传的车牌号与车机设备号，更新当前存储的车牌号与车机设备号的绑定关系。

可选地，在基于预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号之前，还包括：识别所述目标车牌号对应的车辆是否处于运营状态；在所述车辆处于运营状态时，基于预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号。

可选地，所述识别所述目标车牌号对应的车辆是否处于运营状态，包括：判断所述目标车牌号对应车辆的车机端和计价器是否处于在线状态；在所述车机端和所述计价器中的至少一个处于在线状态时，确定所述目标车牌号对应的车辆处于运营状态；在所述车机端和所述计价器均处于离线状态时，获取所述车机端和所述计价器处于离线状态的持续时长；在所述车机端和所述计价器中的至少一个处于离线状态的持续时长小于预设时长时，确定所述目标车牌号对应的车辆处于运营状态。

第二方面，本发明实施例公开了一种扫码支付装置，应用于服务端，所述装置包括：

第一获取模块，用于在接收到扫描目标二维码触发的支付请求时，基于预先建立的二维码与车牌号的绑定关系，获取所述目标二维码绑定的目标车牌号；

第一查询模块，用于基于预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号，并查询所述目标车机设备号对应的车机端当前登录的司机账号；

第一关联模块，用于创建所述支付请求对应的待支付订单，并关联所述待支付订单和所述司机账号，对所述待支付订单进行支付操作。

可选地，所述二维码与车牌号的绑定关系通过如下模块建立：第一识别模块，用于在接收到扫描预先下发的二维码触发的绑定请求时，识别所述二维码是否已绑定车牌号；第一校验模块，用于在所述第一识别模块识别出所述二维码未绑定车牌号时，接收车牌号和司机身份信息，并分别对所述车牌号和所述司机身份信息进行校验；第一建立模块，用于在所述车牌号和所述司机身份信息均校验成功时，建立所述车牌号与所述二维码的绑定关系。

可选地，所述二维码与车牌号的绑定关系通过如下模块建立：第二获取模块，用于在接收到二维码申请请求时，获取所述二维码申请请求中携带的车牌号和司机身份信息；第二校验模块，用于分别对所述车牌号和所述司机身份信息进行校验；第二建立模块，用于在所述车牌号和所述司机身份信息均校验成功时，获取未绑定车牌号的二维码，建立所述车牌号与所述二维码的绑定关系。

可选地，所述装置还包括：第二查询模块，用于在所述第一关联模块创建所述支付请求对应的待支付订单之后，查询当前是否存在所述目标车牌号对应的行程信息；第二关联模块，用于在所述第二查询模块查询到存在所述行程信息时，关联所述行程信息和所述待支付订单。

可选地，所述装置还包括：第三获取模块，用于确定出司机在车机端刷卡登录成功后，获取刷卡登录时上传的车牌号和车机设备号；对比模块，用于将所述上传的车牌号和车机设备号，与当前存储的车牌号与车机设备号的绑定关系进行对比；更新模块，用于在所述对比模块的对比结果不一致时，如果所述上传的车牌号和车机设备号被上传的次数达到预设次数，则利用所述上传的车牌号与车机设备号，更新当前存储的车牌号与车机设备号的绑定关系。

可选地，所述装置还包括：第二识别模块，用于识别所述目标车牌号对应的车辆是否处于运营状态；所述第一查询模块，具体用于在所述第二识别模块识别出所述车辆处于运营状态时，基于预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号，并查询所述目标车机设备号对应的车机端当前登录的司机账号。

可选地，所述第二识别模块，包括：判断单元，用于判断所述目标车牌号对应车辆的车机端和计价器是否处于在线状态；第一确定单元，用于在所述判断单元判断出所述车机端和所述计价器中的至少一个处于在线状态时，确定所述目标车牌号对应的车辆处于运营状态；时长获取单元，用于在所述车机端和所述计价器均处于离线状态时，获取所述车机端和所述计价器处于离线状态的持续时长；第二确定单元，用于在所述车机端和所述计价器中的至少一个处于离线状态的持续时长小于预设时长时，确定所述目标车牌号对应的车辆处于运营状态。

第三方面，本发明实施例公开了一种电子设备，包括：一个或多个处理器；和其上存储有指令的一个或多个机器可读介质；当所述指令由所述一个或多个处理器执行时，使得所述处理器执行如上任一项所述扫码支付方法。

第四方面，本发明实施例公开了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上任一项所述的扫码支付方法。

本发明实施例中，预先建立二维码与车牌号的绑定关系，在接收到扫描目标二维码触发的支付请求时，基于二维码与车牌号的绑定关系，获取所述目标二维码绑定的目标车牌号；基于预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号，并查询所述目标车机设备号对应的车机端当前登录的司机账号；创建所述支付请求对应的待支付订单，并关联所述待支付订单和所述司机账号，对所述待支付订单进行支付操作。由此可知，本发明实施例中将二维码与车牌号绑定，乘客扫码支付时，实时匹配该车牌号对应的车机端当前登录的司机账号，将待支付订单与司机账号关联，从而可以将支付的费用自动关联到当前登录的司机账号，因此司机换班后无需再换码即可实现准确支付，处理过程更加简便。

附图说明

图1是本发明实施例的一种扫码支付方法的步骤流程图。

图2是本发明实施例的一种关联原理的示意图。

图3是本发明实施例的另一种扫码支付方法的步骤流程图。

图4是本发明实施例的一种扫码支付装置的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

参照图1，示出了本发明实施例的一种扫码支付方法的步骤流程图。图1所示的扫码支付方法执行于服务端。

如图1所示，扫码支付方法可以包括以下步骤：

步骤101，在接收到扫描目标二维码触发的支付请求时，基于预先建立的二维码与车牌号的绑定关系，获取所述目标二维码绑定的目标车牌号。

服务端预先生成多个二维码，每个二维码可以携带一个唯一的token(令牌)，该token作为二维码的唯一编号，新生成的二维码未绑定信息。当为某个车辆成功绑定二维码后，建立二维码与车牌号的绑定关系，服务端存储二维码与车牌号的绑定关系。其中，一个二维码可以绑定一个车牌号，一个车牌号可以被多个二维码绑定。

在当前车辆的车牌号与目标二维码绑定后，可以将该目标二维码放置到车辆内方便乘客扫码的位置。当乘客要进行支付时，乘客使用乘客端扫描目标二维码，扫描成功后触发目标二维码对应的支付请求，乘客端将目标二维码对应的支付请求发送至服务端。服务端在接收到目标二维码对应的支付请求时，基于预先建立的二维码与车牌号的绑定关系，获取所述目标二维码绑定的目标车牌号。

步骤102，基于预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号，并查询所述目标车机设备号对应的车机端当前登录的司机账号。

每个车机端具有唯一的车机设备号。在将车机端成功安装到车辆上后，服务端存储车牌号与车机设备号的绑定关系。服务端在获取到目标二维码绑定的目标车牌号后，基于预先存储的车牌号与车机设备号的绑定关系，获取目标车牌号对应的目标车机设备号。

司机换班后，接班司机要在车机端进行刷卡登录，刷卡登录成功后，服务端对应存储车机端的车机设备号及车机端当前登录的司机账号。服务端获取目标车牌号对应的目标车机设备号后，基于存储的车机端的车机设备号及车机端当前登录的司机账号，查询目标车机设备号对应的车机端当前登录的司机账号。

步骤103，创建所述支付请求对应的待支付订单，并关联所述待支付订单和所述司机账号，对所述待支付订单进行支付操作。

服务端查询到当前登录的司机账号后，创建所述支付请求对应的待支付订单，并将待支付订单和当前登录的司机账号。对待支付订单进行支付操作后，即可将支付的费用自动关联到当前登录的司机账号。

本发明实施例中，乘客端可以为乘客使用的APP(应用程序)或微信小程序，也可以为巡游出租车乘客招手上车后，乘客使用的用来与该巡游出租车建立关联订单的APP。车机端可以为巡游出租车的车载智能车机端。服务端可以为上述APP和车机端对应的服务端。

本发明实施例中，将二维码与车牌号绑定，乘客扫码支付时，实时匹配该车牌号对应的车机端当前登录的司机账号，将待支付订单与司机账号关联，从而可以将支付的费用自动关联到当前登录的司机账号，因此司机换班后无需再换码即可实现准确支付，处理过程更加简便。

参照图2，示出了本发明实施例的一种关联原理的示意图。如图2所示，服务端生成1个(不限定个数)带token的二维码，但是该二维码不绑定任何信息。多个司机入驻服务端。某个司机将车牌号与二维码绑定。出租车上安装计价器和车机端，车机端的车机设备号与车牌号匹配关联。司机在接班某辆出租车后，在该出租车安装的车机端上打卡登录。乘客使用微信或APP扫描二维码，通过该二维码与车牌号的匹配关联查找到车牌号，通过车牌号与车机设备号的匹配关联查找到车机设备号，再查询该车机设备号对应的车机端当前登录的司机账号，从而将乘客、车辆、司机关联到一起，以便乘客支付的费用能够自动关联到车辆当前登录的司机账号。

下面，对建立二维码与车牌号的绑定关系的过程进行说明。

在一种可选实施方式中，二维码与车牌号的绑定关系通过如下步骤A1～A3的方式建立：

步骤A1，在接收到扫描预先下发的二维码触发的绑定请求时，识别所述二维码是否已绑定车牌号。

该种实施方式中，服务端可以主动预先下发二维码，比如预先向出租车公司下发二维码。当需要为某个车辆绑定二维码时，司机可以使用司机端扫描服务端预先下发的二维码，以便触发所述二维码对应的绑定请求，司机端将所述二维码对应的绑定请求发送至服务端。其中，司机端可以为司机使用的APP(应用程序)或微信小程序，司机端也可以为车机端。

服务端在接收到所述二维码对应的绑定请求后，识别所述二维码是否已绑定车牌号，也即查询是否已存储所述二维码与车牌号的绑定关系。在所述二维码未绑定车牌号时，服务端继续执行步骤A2；在所述二维码已绑定车牌号时，服务端不继续执行后续的绑定流程，并且可以向司机端发送所述二维码已绑定的提示信息。

步骤A2，在未绑定车牌号时，接收车牌号和司机身份信息，并分别对所述车牌号和所述司机身份信息进行校验。

在所述二维码未绑定车牌号时，服务端可以引导司机在司机端输入车牌号和司机身份信息，司机端将车牌号和司机身份信息上传至服务端。服务端分别对所述车牌号和所述司机身份信息进行校验。

比如，服务端可以根据所述二维码所在地域的交通局的官方数据，校验接收的车牌号是否为真实车牌号，校验接收的车牌号是否为合法车牌号等，如果对接收的车牌号的上述校验通过，则校验成功，否则校验失败。

比如，服务端可以根据所述二维码所在地域的交通局的官方数据，校验司机身份信息是否合法(比如校验姓名、手机号、身份证号是否合法等)，校验司机与车牌号对应的车辆是否是真实运营关系等，如果对司机身份信息的上述校验通过，则校验成功，否则校验失败。

步骤A3，在所述车牌号和所述司机身份信息均校验成功时，建立所述车牌号与所述二维码的绑定关系。

在另一种可选实施方式中，所述二维码与车牌号的绑定关系通过如下步骤B1～B3的方式建立：

步骤B1，在接收到二维码申请请求时，获取所述二维码申请请求中携带的车牌号和司机身份信息。

该种实施方式中，司机端可以主动申请二维码。当需要为某个车辆绑定二维码时，司机可以使用司机端输入车牌号和司机身份信息等，并触发携带车牌号和司机身份信息二维码申请请求，司机端将所述二维码申请请求发送至服务端。

步骤B2，分别对所述车牌号和所述司机身份信息进行校验。

服务端在接收到二维码申请请求后，分别对所述车牌号和所述司机身份信息进行校验。对于具体的校验过程，参照上述步骤A2中的相关描述即可，在此不再详细论述。

步骤B3，在所述车牌号和所述司机身份信息均校验成功时，获取未绑定车牌号的二维码，建立所述车牌号与所述二维码的绑定关系。

需要说明的是，如果绑定车牌号与二维码时出现错误，则可以允许司机进行二次绑定的操作权限，绑定流程与正常流程一致。

参照图3，示出了本发明实施例的另一种扫码支付方法的步骤流程图。图3所示的扫码支付方法执行于服务端。

如图3所示，扫码支付方法可以包括以下步骤：

步骤301，确定出司机在车机端刷卡登录成功后，获取刷卡登录时上传的车牌号和车机设备号。

当司机在接班某个车辆后，要在该车辆安装的车机端上刷卡登录。司机的卡中存储有司机身份信息、车牌号等信息。司机在车机端刷卡后，车机端生成登录请求，登录请求中可以携带司机身份信息(包括姓名、身份证号、手机号等)、车牌号、车机端的车机设备号等信息。车机端将登录请求发送至服务端，以便将司机身份信息、车牌号、车机设备号等信息上传至服务端。

服务端接收到登录请求后，对上传的司机身份信息进行校验。比如，将上传的司机身份信息与预先存储的官方司机身份信息进行对比，如果对比结果一致，则确定对司机身份信息校验成功，该司机登录成功，否则该司机登陆失败。司机登录成功后，服务端可以向车机端发送登录成功响应，服务端继续执行后续步骤302。司机登录失败后，服务端可以向车机端发送登录失败响应，服务端暂时不执行后续步骤302。

步骤302，将所述上传的车牌号和车机设备号，与当前存储的车牌号与车机设备号的绑定关系进行对比。

服务端确定出司机在车机端刷卡登录成功后，获取司机刷卡登录时车机端上传的车牌号和车机设备号。服务端将所述上传的车牌号和车机设备号，与当前存储的车牌号与车机设备号的绑定关系进行对比。

比如，如果上传的车牌号为A，上传的车机设备号为B，当前存储的车牌号与车机设备号的绑定关系中车牌号A与车机设备号B绑定，则对比结果一致。如果上传的车牌号为A，上传的车机设备号为B，当前存储的车牌号与车机设备号的绑定关系中车牌号A与车机设备号C绑定，则对比结果不一致。

步骤303，在对比结果不一致时，如果所述上传的车牌号和车机设备号被上传的次数达到预设次数，则利用所述上传的车牌号与车机设备号，更新当前存储的车牌号与车机设备号的绑定关系。

在对比结果一致时，服务端无需对当前存储的车牌号与车机设备号的绑定关系进行更新，因此可以继续执行后续步骤304。在对比结果不一致时，服务端可以统计所述上传的车牌号和车机设备号被上传的次数，并判断被上传的次数是否达到预设次数。如果所述上传的车牌号和车机设备号被上传的次数未达到预设次数，则服务端暂时无需对当前存储的车牌号与车机设备号的绑定关系进行更新，还可以向车机端发送车牌号与车机设备号关系错误的提示信息，司机可以选择重新刷卡登录，或者联系服务端客服确认等。如果所述上传的车牌号和车机设备号被上传的次数达到预设次数，则服务端利用所述上传的车牌号与车机设备号，更新当前存储的车牌号与车机设备号的绑定关系。

对于预设次数的具体数值，可以根据实际经验选用任意适用的数值，比如，可以设置预设次数为1次、2次、3次、5次等，本发明实施例对此不做限制。

步骤304，记录所述车机端当前登录的司机账号。

服务端在确定出司机在车机端刷卡登录成功后，还可以记录所述车机端当前登录的司机账号，以便后续查询使用。

步骤305，在接收到扫描目标二维码触发的支付请求时，基于预先建立的二维码与车牌号的绑定关系，获取所述目标二维码绑定的目标车牌号。

在当前车辆的车牌号与目标二维码绑定后，可以将该目标二维码放置到车辆内方便乘客扫码的位置。司机在车机端刷卡登录成功后，即可开始巡游接单，乘客可以招手乘坐车辆。当乘客要进行支付时，乘客使用乘客端扫描目标二维码，扫描成功后触发目标二维码对应的支付请求，乘客端将目标二维码对应的支付请求发送至服务端。服务端在接收到目标二维码对应的支付请求时，查询预先建立的二维码与车牌号的绑定关系，获取所述目标二维码绑定的目标车牌号。

步骤306，识别所述目标车牌号对应的车辆是否处于运营状态。

服务端识别所述目标车牌号对应的车辆是否处于运营状态。在所述车辆处于运营状态时，服务端可以继续执行步骤307；在所述车辆处于未运营状态时，服务端可以向乘客端和车机端发送无法支付的提示信息。

在一种可选实施方式中，识别所述目标车牌号对应的车辆是否处于运营状态的过程，可以包括如下步骤C1～C4：

步骤C1，判断所述目标车牌号对应车辆的车机端和计价器是否处于在线状态。

步骤C2，在所述车机端和所述计价器中的至少一个处于在线状态时，确定所述目标车牌号对应的车辆处于运营状态。

当车辆在运营时，车辆上的车机端和计价器中的至少一个应该联网，处于在线状态。因此，服务端判断所述目标车牌号对应车辆的车机端和计价器是否处于在线状态。在所述车机端和所述计价器中的至少一个处于在线状态时，服务端可以确定所述目标车牌号对应的车辆处于运营状态。

步骤C3，在所述车机端和所述计价器均处于离线状态时，获取所述车机端和所述计价器处于离线状态的持续时长。

步骤C4，在所述车机端和所述计价器中的至少一个处于离线状态的持续时长小于预设时长时，确定所述目标车牌号对应的车辆处于运营状态。

由于车辆在行驶过程中会出现异常状况导致断网，比如在经过山洞、隧道等网络信号较差的路径时，会导致断网，从而导致在该段路径上所述车机端和所述计价器会在短时间内处于离线状态，但是实际上该车辆也是处于运营状态的。因此，服务端在所述车机端和所述计价器均处于离线状态时，统计所述车机端和所述计价器处于离线状态的持续时长，在所述车机端和所述计价器中的至少一个处于离线状态的持续时长小于预设时长时，可以确定所述目标车牌号对应的车辆处于运营状态。

对于预设时长的具体数值，可以根据实际经验设置任意适用的数值，比如可以设置预设时长为5分钟、10分钟、15分钟等，本发明实施例对此不做限制。

步骤307，基于预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号，并查询所述目标车机设备号对应的车机端当前登录的司机账号。

服务端在所述目标车牌号对应的车辆处于运营状态时，查询预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号。然后，服务端从当前的登录信息中，查询所述目标车机设备号对应的车机端当前登录的司机账号。

步骤308，创建所述支付请求对应的待支付订单，并关联所述待支付订单和所述司机账号。

服务端创建支付请求对应的待支付订单，待支付订单中可以包括支付费用等信息。服务端将所述待支付订单和所述当前登录的司机账号关联，以便后续乘客支付的费用可以与当前登录的司机账号关联，将费用转到当前登录的司机账号对应的司机处。

步骤309，查询当前是否存在所述目标车牌号对应的行程信息，在存在所述行程信息时，关联所述行程信息和所述待支付订单。

在实际乘车过程中，乘客乘车时可能存在如下几种情况：1、乘客与司机提前协商费用，司机没有在计价器上执行抬表和落表的操作，该种情况下不存在行程信息。2、司机有在计价器上执行抬表和落表的操作，乘客提前下车，行程未结束时进行扫码支付，该种情况下存在进行中的行程信息。3、司机有在计价器上执行抬表和落表的操作，乘客到终点后下车，行程结束后进行扫码支付，该种情况下存在已结束的行程信息。

本发明实施例中，服务端创建所述支付请求对应的待支付订单，关联所述待支付订单和所述司机账号后，还可以查询当前是否存在所述目标车牌号对应的行程信息，该行程信息可以为进行中的行程信息，也可以为结束时长未超过第二预设时长的已结束的行程信息。在存在所述行程信息时，关联所述行程信息和所述待支付订单。因此，所述行程信息、所述待支付订单和所述当前登录的司机账号均进行关联。在不存在所述行程信息时，继续执行下述步骤310。

对于第二预设时长的具体数值，可以根据实际经验设置任意适用的数值，比如可以设置预设时长为1分钟、2分钟、4分钟等，本发明实施例对此不做限制。

步骤310，对所述待支付订单进行支付操作。

在存在所述行程信息时，服务端携带待支付订单和行程信息进入支付流程，支付成功后，将乘客支付的费用与当前登录的司机账号关联，将费用转到当前登录的司机账号对应的司机处。行程信息中可以包括起点位置、重点位置、起点时间、终点时间、GPS(GlobalPositioning System，全球定位系统)轨迹信息、计价器信息等。因此，通过关联的行程信息，可以对乘坐的车辆进行追溯等。

在不存在所述行程信息时，可以直接携带待支付订单进入支付流程，支付成功后，将乘客支付的费用与当前登录的司机账号关联，将费用转到当前登录的司机账号对应的司机处。

本发明实施例中，将巡游出租车接单后的服务线上化，解决乘客一次扫码就能完成乘客订单与司机、车辆关联的问题，方便乘客通过App或小程序等对出租车订单进行支付，同时能够在线上获取出租车电子发票，出现安全问题也可及时方便的追溯到当时的出租司机和相关出租车辆。

参照图4，示出了本发明实施例的一种扫码支付装置的结构框图。图4所示的扫码支付装置应用于服务端。

如图4所示，扫码支付装置可以包括以下模块：

第一获取模块401，用于在接收到扫描目标二维码触发的支付请求时，基于预先建立的二维码与车牌号的绑定关系，获取所述目标二维码绑定的目标车牌号；

第一查询模块402，用于基于预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号，并查询所述目标车机设备号对应的车机端当前登录的司机账号；

第一关联模块403，用于创建所述支付请求对应的待支付订单，并关联所述待支付订单和所述司机账号，对所述待支付订单进行支付操作。

可选地，所述二维码与车牌号的绑定关系通过如下模块建立：第一识别模块，用于在接收到扫描预先下发的二维码触发的绑定请求时，识别所述二维码是否已绑定车牌号；第一校验模块，用于在所述第一识别模块识别出所述二维码未绑定车牌号时，接收车牌号和司机身份信息，并分别对所述车牌号和所述司机身份信息进行校验；第一建立模块，用于在所述车牌号和所述司机身份信息均校验成功时，建立所述车牌号与所述二维码的绑定关系。

可选地，所述二维码与车牌号的绑定关系通过如下模块建立：第二获取模块，用于在接收到二维码申请请求时，获取所述二维码申请请求中携带的车牌号和司机身份信息；第二校验模块，用于分别对所述车牌号和所述司机身份信息进行校验；第二建立模块，用于在所述车牌号和所述司机身份信息均校验成功时，获取未绑定车牌号的二维码，建立所述车牌号与所述二维码的绑定关系。

可选地，所述装置还包括：第二查询模块，用于在所述第一关联模块创建所述支付请求对应的待支付订单之后，查询当前是否存在所述目标车牌号对应的行程信息；第二关联模块，用于在所述第二查询模块查询到存在所述行程信息时，关联所述行程信息和所述待支付订单。

可选地，所述装置还包括：第三获取模块，用于确定出司机在车机端刷卡登录成功后，获取刷卡登录时上传的车牌号和车机设备号；对比模块，用于将所述上传的车牌号和车机设备号，与当前存储的车牌号与车机设备号的绑定关系进行对比；更新模块，用于在所述对比模块的对比结果不一致时，如果所述上传的车牌号和车机设备号被上传的次数达到预设次数，则利用所述上传的车牌号与车机设备号，更新当前存储的车牌号与车机设备号的绑定关系。

可选地，所述装置还包括：第二识别模块，用于识别所述目标车牌号对应的车辆是否处于运营状态；所述第一查询模块，具体用于在所述第二识别模块识别出所述车辆处于运营状态时，基于预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号，并查询所述目标车机设备号对应的车机端当前登录的司机账号。

可选地，所述第二识别模块，包括：判断单元，用于判断所述目标车牌号对应车辆的车机端和计价器是否处于在线状态；第一确定单元，用于在所述判断单元判断出所述车机端和所述计价器中的至少一个处于在线状态时，确定所述目标车牌号对应的车辆处于运营状态；时长获取单元，用于在所述车机端和所述计价器均处于离线状态时，获取所述车机端和所述计价器处于离线状态的持续时长；第二确定单元，用于在所述车机端和所述计价器中的至少一个处于离线状态的持续时长小于预设时长时，确定所述目标车牌号对应的车辆处于运营状态。

本发明实施例中将二维码与车牌号绑定，乘客扫码支付时，实时匹配该车牌号对应的车机端当前登录的司机账号，将待支付订单与司机账号关联，从而可以将支付的费用自动关联到当前登录的司机账号，因此司机换班后无需再换码即可实现准确支付，处理过程更加简便。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

在本发明的实施例中，还提供了一种电子设备。该电子设备可以包括一个或多个处理器，以及其上存储有指令的一个或多个机器可读介质，指令例如应用程序。当所述指令由所述一个或多个处理器执行时，使得所述处理器执行上述的方法。

在本发明的实施例中，还提供了一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序可由电子设备的处理器执行，以完成上述的方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

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

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

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

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

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

Claims (10)

1.一种扫码支付方法，其特征在于，执行于服务端，所述方法包括：

在接收到扫描目标二维码触发的支付请求时，基于预先建立的二维码与车牌号的绑定关系，获取所述目标二维码绑定的目标车牌号；

基于预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号，并查询所述目标车机设备号对应的车机端当前登录的司机账号；

创建所述支付请求对应的待支付订单，并关联所述待支付订单和所述司机账号，对所述待支付订单进行支付操作。

2.根据权利要求1所述的方法，其特征在于，所述二维码与车牌号的绑定关系通过如下方式建立：

在接收到扫描预先下发的二维码触发的绑定请求时，识别所述二维码是否已绑定车牌号；

在未绑定车牌号时，接收车牌号和司机身份信息，并分别对所述车牌号和所述司机身份信息进行校验；

在所述车牌号和所述司机身份信息均校验成功时，建立所述车牌号与所述二维码的绑定关系。

3.根据权利要求1所述的方法，其特征在于，所述二维码与车牌号的绑定关系通过如下方式建立：

在接收到二维码申请请求时，获取所述二维码申请请求中携带的车牌号和司机身份信息；

分别对所述车牌号和所述司机身份信息进行校验；

在所述车牌号和所述司机身份信息均校验成功时，获取未绑定车牌号的二维码，建立所述车牌号与所述二维码的绑定关系。

4.根据权利要求1所述的方法，其特征在于，在创建所述支付请求对应的待支付订单之后，还包括：

查询当前是否存在所述目标车牌号对应的行程信息；

在存在所述行程信息时，关联所述行程信息和所述待支付订单。

5.根据权利要求1所述的方法，其特征在于，在接收到扫描目标二维码触发的支付请求时，基于预先建立的二维码与车牌号的绑定关系，获取所述目标二维码绑定的目标车牌号之前，还包括：

确定出司机在车机端刷卡登录成功后，获取刷卡登录时上传的车牌号和车机设备号；

将所述上传的车牌号和车机设备号，与当前存储的车牌号与车机设备号的绑定关系进行对比；

在对比结果不一致时，如果所述上传的车牌号和车机设备号被上传的次数达到预设次数，则利用所述上传的车牌号与车机设备号，更新当前存储的车牌号与车机设备号的绑定关系。

6.根据权利要求1所述的方法，其特征在于，在基于预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号之前，还包括：

识别所述目标车牌号对应的车辆是否处于运营状态；

在所述车辆处于运营状态时，基于预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号。

7.根据权利要求6所述的方法，其特征在于，所述识别所述目标车牌号对应的车辆是否处于运营状态，包括：

判断所述目标车牌号对应车辆的车机端和计价器是否处于在线状态；

在所述车机端和所述计价器中的至少一个处于在线状态时，确定所述目标车牌号对应的车辆处于运营状态；

在所述车机端和所述计价器均处于离线状态时，获取所述车机端和所述计价器处于离线状态的持续时长；

在所述车机端和所述计价器中的至少一个处于离线状态的持续时长小于预设时长时，确定所述目标车牌号对应的车辆处于运营状态。

8.一种扫码支付装置，其特征在于，应用于服务端，所述装置包括：

第一获取模块，用于在接收到扫描目标二维码触发的支付请求时，基于预先建立的二维码与车牌号的绑定关系，获取所述目标二维码绑定的目标车牌号；

第一查询模块，用于基于预先存储的车牌号与车机设备号的绑定关系，获取所述目标车牌号对应的目标车机设备号，并查询所述目标车机设备号对应的车机端当前登录的司机账号；

第一关联模块，用于创建所述支付请求对应的待支付订单，并关联所述待支付订单和所述司机账号，对所述待支付订单进行支付操作。

9.一种电子设备，其特征在于，包括：

一个或多个处理器；和

其上存储有指令的一个或多个机器可读介质；

当所述指令由所述一个或多个处理器执行时，使得所述处理器执行如权利要求1至7任一项所述的方法。

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

Images