掌桥专利:专业的专利平台
掌桥专利
首页

计费提醒方法、装置、电子设备、介质及程序产品

文献发布时间:2024-01-17 01:13:28


计费提醒方法、装置、电子设备、介质及程序产品

技术领域

本公开涉及互联网技术领域,具体涉及一种计费提醒方法、装置、电子设备、介质及程序产品。

背景技术

目前,网约车的计费模式是网约车平台根据乘客的上车点和下车点计算出本次订单的车费,在本次订单的行程中存在除车费之附加费用(如过路费、停车费等)时,司机会输入附加费,然后网约车平台就可以根据该车费和附加费生成支付账单并发送给乘客,让乘客进行支付。由于附加费是通过司机手动输入的,目前并没有判断该附加费的费用是否合理的监控手段,有时司机会输入过多的附加费,出现多计费的情况,造成乘客体验受损,容易引起司乘冲突。因此,如何有效地对司机的计费行为进行约束管理成为亟待解决的技术问题。

发明内容

为了解决相关技术中的问题,本公开实施例提供一种计费提醒方法、装置、电子设备、介质及程序产品。

第一方面,本公开实施例中提供了一种计费提醒方法,包括:

获取服务提供端发送的目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

响应于所述支付费用信息中包含附加费,确定所述目标订单的行程路线中是否包含收费路线;

响应于所述目标订单的行程路线中不包含收费路线,向所述服务提供端发送第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

重新获取所述服务提供端发送的所述目标订单的新的支付申请消息,所述新的支付申请消息中携带的支付费用信息不包括所述附加费。

第二方面,本公开实施例中提供了一种计费提醒方法,包括:

向服务器发送目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

接收并显示所述服务器发送的第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

响应于获取指示取消收取所述附加费的取消指令,显示所述目标订单的支付申请页面;

响应于针对所述支付申请页面的申请提交指令,重新向所述服务器发送所述目标订单的新的支付申请消息,所述新的支付申请消息中携带的支付费用信息不包括所述附加费。

第三方面,本公开实施例中提供了一种计费提醒方法,包括:

服务提供端向服务器发送目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

所述服务器响应于所述支付费用信息中包含附加费,确定所述目标订单的行程路线中是否包含收费路线;

所述服务器响应于所述目标订单的行程路线中不包含收费路线,向所述服务提供端发送第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

所述服务提供端接收并显示所述服务器发送的第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

所述服务提供端响应于获取指示取消收取所述附加费的取消指令,显示所述目标订单的支付申请页面;

所述服务提供端响应于针对所述支付申请页面的申请提交指令,重新向所述服务器发送所述目标订单的新的支付申请消息。

第四方面,本公开实施例中提供了一种计费提醒装置,包括:

第一获取模块,被配置为获取服务提供端发送的目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

第一确定模块,被配置为响应于所述支付费用信息中包含附加费,确定所述目标订单的行程路线中是否包含收费路线;

第一发送模块,被配置为响应于所述目标订单的行程路线中不包含收费路线,向所述服务提供端发送第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

第二获取模块,被配置为重新获取所述服务提供端发送的所述目标订单的新的支付申请消息,所述新的支付申请消息中携带的支付费用信息不包括所述附加费。

第五方面,本公开实施例中提供了一种计费提醒装置,包括:

第二发送模块,被配置为向服务器发送目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

第一接收显示模块,被配置为接收并显示所述服务器发送的第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

第一显示模块,被配置为响应于获取指示取消收取所述附加费的取消指令,显示所述目标订单的支付申请页面;

第三发送模块,被配置响应于针对所述支付申请页面的申请提交指令,重新向所述服务器发送所述目标订单的新的支付申请消息,所述新的支付申请消息中携带的支付费用信息不包括所述附加费。

在一个可能的设计中,上述装置的结构中包括存储器和处理器,所述存储器用于存储一条或多条支持上述装置执行上述对应方法的计算机指令,所述处理器被配置为用于执行所述存储器中存储的计算机指令。上述装置还可以包括通信接口,用于上述装置与其他设备或通信网络通信。

第六方面,本公开实施例提供了一种电子设备,包括存储器、处理器以及存储在存储器上的计算机程序,其中,所述处理器执行所述计算机程序以实现上述任一方面所述的方法。

第七方面,本公开实施例提供了一种计算机可读存储介质,用于存储上述任一装置所用的计算机指令,该计算机指令被处理器执行时用于实现上述任一方面所述的方法。

第八方面,本公开实施例提供了一种计算机程序产品,其包含计算机指令,该计算机指令被处理器执行时用于实现上述任一方面所述的方法。

本公开实施例提供的技术方案可以包括以下有益效果:

本实施例可以让在司机收取附加费的情况下,通过确定目标订单的行程路线中是否包含收费路线来判断是否应收取该附加费,并在不包含收费路线时向服务提供端发送第一提示信息,提醒司机取消收取附加费,对附加费的合理收取进行检测,防止司机因误操作而额外收取附加费,提升乘客体验,避免发生司乘冲突。

应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。

附图说明

结合附图,通过以下非限制性实施方式的详细描述,本公开的其它特征、目的和优点将变得更加明显。在附图中:

图1示出根据本公开一实施方式的计费提醒系统的系统架构示意图;

图2示出根据本公开的实施例的一种应用于服务器的计费提醒方法的流程图;

图3示出根据本公开一实施方式的一种应用于服务提供端的计费提醒方法的流程图;

图4是根据一示例性实施例示出的一种应用于系统的计费提醒方法的流程图;

图5是根据一示例性实施例示出的另一种应用于系统的计费提醒方法的流程图;

图6是根据一示例性实施例示出的又一种应用于系统的计费提醒方法的流程图;

图7示出根据本公开的实施例的一种应用于服务器的计费提醒装置的结构框图;

图8示出根据本公开的实施例的一种应用于服务提供端的计费提醒装置的结构框图;

图9示出根据本公开的实施例的电子设备的结构框图;

图10示出适于用来实现根据本公开实施例的方法的计算机系统的结构示意图。

具体实施方式

下文中,将参考附图详细描述本公开的示例性实施例,以使本领域技术人员可容易地实现它们。此外,为了清楚起见,在附图中省略了与描述示例性实施例无关的部分。

在本公开中,应理解,诸如“包括”或“具有”等的术语旨在指示本说明书中所公开的特征、数字、步骤、行为、部件、部分或其组合的存在,并且不欲排除一个或多个其他特征、数字、步骤、行为、部件、部分或其组合存在或被添加的可能性。

另外还需要说明的是,在不冲突的情况下,本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开。

在本公开中,对用户信息或用户数据的获取均为经用户授权、确认,或由用户主动选择的操作,这里的用户包括该网约车平台上的各种类型的用户,可以是司机也可以是乘客。

首先,在具体介绍本公开实施例的技术方案之前,先对本公开实施例基于的技术背景或者技术演进脉络进行介绍。目前,网约车的计费模式是网约车平台根据乘客的上车点和下车点计算出本次订单的车费,在本次订单的行程中存在除车费之附加费用(如过路费、停车费等)时,司机会输入附加费,然后网约车平台就可以根据该车费和附加费生成支付账单并发送给乘客,让乘客进行支付。由于附加费是通过司机手动输入的,目前并没有判断该附加费的费用是否合理的监控手段,有时司机会输入过多的附加费,出现多计费的情况,造成乘客体验受损,容易引起司乘冲突。因此,如何有效地对司机的计费行为进行约束管理成为亟待解决的技术问题。

为了解决上述的技术问题,本公开提供了一种计费提醒方法,下面结合本公开实施例所应用的场景,对本公开实施例涉及的技术方案进行介绍。

本公开实施例提供的计费提醒方法,可以应用于如图1所示的系统架构中。该系统架构包括服务接受端101、服务器102和服务提供端103。其中,服务接受端101可以为手机、平板电脑、IPAD等电子设备,或者,服务接受端101也可以为安装在服务接受端设备上的第一APP软件。服务器102可以为服务器,该服务器可以是独立的服务器,还可以是服务器集群。服务提供端103可以为手机、平板电脑、IPAD或者个人计算机(Personal Computer,PC)等电子设备,或者服务提供端也可以为安装在服务提供端设备上的第二APP软件。需要说明的是,上述第一APP软件、第二APP软件可以为两个单独的APP软件,还可以为同一款软件在不同模式下的软件呈现,例如,网约车平台发布一款打车软件,该打车软件具有乘客模式和司机模式两种模式,不同的模式下软件的功能实现不一样,面对的用户群体也不一样。本公开实施例可以在乘客到达目的地后,由司机发起支付申请来申请收取本次目标订单的费用,司机可以在服务提供端的用户界面上输入支付费用信息,该服务提供端发送的目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;服务器接收到该支付申请消息后,响应于该支付费用信息中包含附加费,确定所述目标订单的行程路线中是否包含收费路线;响应于所述目标订单的行程路线中不包含收费路线,向所述服务提供端发送第一提示信息,所述第一提示信息用于提示所述服务提供端即司机确认是否收取所述附加费;如果司机是误操作输入的附加费,则该司机会在服务提供端输入取消指令,取消收取该附加费并重新发起支付申请,服务器102重新获取所述服务提供端103发送的所述目标订单的新的支付申请消息,进而生成支付账单,并将该支付账单发送给服务接受端101即乘客端,由服务接受方即乘客进行支付。这样,可以在司机收取附加费时,通过确定目标订单的行程路线中是否包含收费路线来判断是否应收取该附加费,并在不包含收费路线时向服务提供端发送第一提示信息,提醒司机取消收取附加费,对附加费的合理收取进行检测,避免司机因误操作而额外收取附加费,提升乘客体验,避免发生司乘冲突。

本公开实施例提供的计费提醒方法的使用场景可以是打车时司机进行计费时的场景、代驾时代驾人员进行计费时的场景、送外卖时配送人员进行计费时的场景。以下可以以打车时司机进行计费时的场景为例来说明本公开实施例提供的计费提醒方案。

由于本公开实施例提供的计费提醒方法的执行主体有服务提供端、服务器以及系统(服务提供端、服务器接受端和服务器组成的系统),故本公开实施例根据方法实施主体的不同,布置了服务提供端一侧、服务器一侧、系统的实施例,如下所述:

服务器一侧的实施例:

图2示出根据本公开的实施例的一种应用于服务器的计费提醒方法的流程图。如图2所示,所述计费提醒方法应用于服务器,包括以下步骤S201-S204:

在步骤S201中,获取服务提供端发送的目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

在步骤S202中,响应于所述支付费用信息中包含附加费,确定所述目标订单的行程路线中是否包含收费路线;

在步骤S203中,响应于所述目标订单的行程路线中不包含收费路线,向所述服务提供端发送第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

在步骤S204中,重新获取所述服务提供端发送的所述目标订单的新的支付申请消息,所述新的支付申请消息中携带的支付费用信息不包括所述附加费。

本实施例中,该服务提供端指的是可以提供订单服务的用户的设备端或APP客户端,比如可以是司机端。服务接受端指的是接受该服务提供端提供的服务的用户的设备端或APP客户端,比如可以是乘客端。乘客使用服务接受端下单后,司机可以通过服务提供端接单,并为该乘客提供服务,这里的服务可以是打车服务、代驾服务、外卖服务等需要行车的服务。

本实施例中,针对乘客的目标订单,网约车平台按照预设算法计算从目标订单的起点位置到终点位置的费用称为固定车费,该固定车费是按照固定的算法合理计算得到的。该附加费指的是除固定车费之外的各种费用的统称,比如说可以是订单的行车过程中经过高速路段时的过路费、需要在停车场停车时的停车费等等。

本实施例中,服务提供端的用户即司机在为该服务接受端的用户即乘客提供了目标订单中的相应服务后,可以发起支付申请,操作服务提供端向服务器发送该目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息,以便该服务器向该服务接受端的用户指示进行服务费用支付,该支付费用信息指的是司机申请向乘客收取的费用信息。示例的,该服务为打车服务时,司机在把乘客送达目的地后,就会操作该服务提供端进入支付申请页面,该支付申请页面上可以显示有该目标订单的固定车费的金额以及附加费输入框,司机可以在该附加费输入框中输入附加费金额,然后点击支付申请页面上的“确认”按键,该服务提供端就检测到司机输入的支付申请发起操作,向服务器发送该目标订单的支付申请消息,该支付申请消息中携带的是司机申请收取的支付费用信息,如果司机未输入附加费金额则该支付费用信息只包括固定车费,如果司机在该附加费输入框中输入了附加费金额则该支付费用信息中包括固定车费和附加费。

本实施例中,服务器接收到该服务提供端发送的目标订单的支付申请消息后,可以判断该支付费用信息中是否包括附加费,如果该支付费用信息只有标识为固定车费的费用信息,则表明该目标订单没有附加费是按照固定车费来收取的,不存在多计费问题,此时计费提醒流程结束,服务器可以直接生成支付账单并发送给乘客的服务接受端,该服务接受端就可以基于乘客的支付操作支付该固定车费,完成该目标订单的支付。如果该支付费用信息包含有标识为附加费的费用信息,则需要通过判断目标订单的行程路线中是否包含收费路线来确定该附加费是否是违规收取的,如果该目标订单的行程路线中包含收费路线,则表明司机需要收取该附加费,如果该目标订单的行程路线中不包含收费路线,则表明司机不需要收取附加费。故,如果支付费用信息中包含附加费,而目标订单的行程路线中不包含收费路线,则表明该附加费可能是违规收取的,此时服务器会向服务提供端发送第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费。

本实施例中,服务提供端接收到该第一提示信息后,可以显示该第一提示信息,如可以弹窗显示该第一提示信息“确认是否收取附加费”以及“确认”按键、“取消”按键,如果司机是误操作输入的附加费,则司机在看到该第一提示信息后,可以点击“取消”按键,此时,服务提供端检测到司机针对该“取消”按键的点击操作后,就可以显示所述目标订单的支付申请页面,删除该支付申请页面中的附加费金额,重新向该服务器发送该目标订单的新的支付申请消息,该新的支付申请消息中携带的支付费用信息就不包括该附加费,此时,服务器可以继续执行步骤S201,此时,服务器可以响应于所述支付费用信息中不包含附加费,可以直接基于该新的支付申请消息生成支付账单并发送给乘客的服务接受端,该服务接受端就可以基于乘客的支付操作支付该固定车费,完成该目标订单的支付。这里,该服务提供端在获取到指示取消收取所述附加费的取消指令时,可以向服务器发送取消收取附加费的取消消息告知服务器取消申请上次的支付费用信息,也可以不向服务器发送取消收取附加费的取消消息而是直接发送该目标订单的新的支付申请消息,用新的支付申请消息来取代上次的支付费用信息。

这里需要说明的是,本实施例中所述收费路线包括需要收取过路费的路线以及包括在停车场的驻留时长超过预设时长的需要收取停车费的路线等等;判断该目标订单的行程路线中是否包含收费路线可以是:如果所述目标订单的行程包含需要收取过路费的路线,或者驻留在停车场且驻留时长超过预设时长,则所述目标订单的行程路线包括收费路线;否则,该目标订单的行程路线不包括收费路线。

本实施例可以在司机收取附加费的情况下,通过确定目标订单的行程路线中是否包含收费路线来判断是否应收取该附加费,并在不包含收费路线时向服务提供端发送第一提示信息,提醒司机取消收取附加费,对附加费的合理收取进行检测,防止司机因误操作而额外收取附加费,提升乘客体验,避免发生司乘冲突。

在本实施例的一个可选实现方式中,在步骤S204之前即在重新获取所述服务提供端发送的所述目标订单的新的支付申请消息之前,所述计费提醒方法还可以包括以下步骤:

在步骤A1中,响应于所述目标订单的行程路线中包含收费路线,根据所述收费路线计算所述收费路线产生的预估附加费;

在步骤A2中,响应于所述附加费比所述预估附加费多出的差额大于预设阈值,向所述服务提供端发送所述第二提示信息,所述第二提示信息用于提示所述服务提供端是否修改所述附加费的额度。

在该实现方式中,如果目标订单的行程路线中包含收费路线,则表明收取附加费的操作是合理的,但是,有时会存在收取的附加费的金额远大于附加费的实际金额的情况,为了保证收取的附加费的金额也是合理的,本实现方式对该附加费的额度是否合理进行进一步的检测。

在该实现方式中,该预估附加费是的是预估出来的经过该收费路线时需要收取的附加费。可以根据该收费路线计算该收费路线产生的预估附加费,该计算方法可以是按照该收费路线的历史计费数据确定该收费路线产生的预估附加费,如将该收费路线的历史计费金额的平均值作为该收费路线产生的预估附加费;该计算方法还可以是按照预存该收费路线的计费规则来确定该收费路线产生的预估附加费,如高速路线上都有固定的计费标准,可以按照该计费标准来计算该收费路线产生的预估附加费。

在该实现方式中,正常情况下,司机输入的附加费应该与该预估附加费差不多,如果该附加费比所述预估附加费多出的差额不大于预设阈值,则表明收取的附加费属于正常计费水平,不存在多计费问题,此时计费提醒流程结束,服务器可以直接生成支付账单并发送给乘客的服务接受端,该服务接受端就可以基于乘客的支付操作支付该固定车费,完成该目标订单的支付。如果该附加费比所述预估附加费多出的差额大于预设阈值,则表明收取的附加费超出了正常计费水平,属于违规计费,此时服务器会向服务提供端发送第二提示信息,所述第二提示信息用于提示所述服务提供端是否修改所述附加费的额度。

本实施例中,服务提供端接收到该第二提示信息后,可以显示该第二提示信息,如可以弹窗显示该第二提示信息“是否修改所述附加费的额度”以及“确认”按键、“取消”按键,如果司机是误操作多输入的附加费,则司机在看到该第二提示信息后,可以点击“确认”按键,此时,服务提供端检测到司机针对该“确认”按键的点击操作后,就可以显示所述目标订单的支付申请页面,修改该支付申请页面中的附加费金额,重新向该服务器发送该目标订单的新的支付申请消息,该新的支付申请消息中携带的支付费用信息中就不包括之前上次输入的附加费而是包括新输入的合理的附加费,此时,服务器可以继续执行步骤S201,此时,服务器可以响应于所述目标订单的行程路线中包含收费路线且新的附加费比所述预估附加费多出的差额不大于预设阈值,直接基于该新的支付申请消息生成支付账单并发送给乘客的服务接受端,该服务接受端就可以基于乘客的支付操作支付该固定车费,完成该目标订单的支付。这里,该服务提供端在检测到确认修改附加费的确认操作时,可以向服务器发送确认修改附加费的确认消息告知服务器取消申请上次的支付费用信息,也可以不向服务器发送确认修改附加费的确认消息而是直接发送该目标订单的新的支付申请消息,用新的支付申请消息来取代上次的支付费用信息。

本实现方式可以在司机可以附加费的情况下,通过计算得出的收费路线产生的预估附加费判断收取的附加费的额度是否合理,并在不合理时向服务提供端发送第二提示信息,提醒司机修改附加费的额度,对附加费的收取金额进行检测,防止司机收取过多的附加费,提升乘客体验,避免发生司乘冲突。

在一种可能的实现方式中,在向所述服务提供端发送所述第一提示信息或所述第二提示消息之后,所述计费提醒方法还可以包括以下步骤:

在步骤B1中,接收所述服务提供端发送的确认收取所述附加费的第一确认消息;

在步骤B2中,响应于接收到所述第一确认消息,基于所述支付费用信息生成支付账单并将所述支付账单发送给服务接受端;

在步骤B3中,确定所述目标订单为异常计费订单,记录所述异常计费订单的订单数据。

在该实现方式中,服务提供端接收并显示该第一提示信息或第二提示信息后,司机看到该第一提示信息或第二提示信息,司机仍然坚持收取该附加费,此时,司机就会在该服务提供端输入确认收取所述附加费的确认操作,服务提供端就会向服务器发送确认收取所述附加费的第一确认消息,服务器接收到该第一确认消息后,就会基于该支付费用信息生成支付账单,并发送给乘客的服务接受端,该服务接受端显示该支付账单后,如果该附加费是与司机协商好的,乘客可以进行支付操作,如果乘客认为该附加费是多出的或附加费的额度超过的,可以反馈至网约车平台进行裁决。

在该实现方式中,在给司机提示后司机仍坚持收取该附加费时,服务器可以将该目标订单记录为异常计费订单,并存储所述异常计费订单的订单数据,以便后续基于该记录对异常计费的司机进行判罚。该异常计费订单的订单数据包括该异常计费订单的服务提供端、异常计费金额等,该异常计费金额指的是超出该异常计费订单正常计费的金额。

在一种可能的实现方式中,在将所述支付账单发送给服务接受端时,所述计费提醒方法还可以进行步骤B4,所述步骤B3还可以实现为步骤B31:

在步骤B4中,将所述服务提供端存在异常计费风险的第三提示信息发送给服务接受端;

在步骤B31中,响应于接收到所述服务接受端发送的确认存在异常计费的第二确认消息,确定所述目标订单为异常计费订单,记录所述异常计费订单的订单数据。

在该实现方式中,如果司机看到该第一提示信息或第二提示信息后仍然坚持收取该附加费,则服务器在将该支付账单发送给服务接受端时,还会向服务接受端发送第三提示信息,提示该服务接受端的用户此次计费可能存在违规计费的风险,服务接受端可以弹窗显示该第三提示信息,示例的,该服务接受端可以在弹窗内显示信息“司机是否违规计费”以及“同意”按键、“不同意”按键。如果服务接受端的用户即乘客与司机是协商好按照该附加费进行计费的,则可以点击“不同意”按键,并按照该支付账单支付。如果乘客认为该附加费是属于违规计费的,则可以点击“同意”按键,该服务接受端就会向该服务器发送确认该目标订单存在异常计费的第二确认消息,服务器接收到该第二确认消息,就可以确定该服务提供端确实存在异常计费,此时就可以确定所述目标订单为异常计费订单,记录所述异常计费订单的订单数据。

本实现方式可以在司机异常计费时提示乘客存在异常计费风险,提醒乘客注意,并在平台和乘客均确定该司机异常计费时,才确定目标订单为异常计费订单,更准确地确定异常计费订单,以便后续基于该记录准确地对异常计费的司机进行判罚。

在一种可能的实现方式中,上述的计费提醒方法还可以包括以下步骤C1和C2:

在步骤C1中,基于所述异常计费订单的订单数据,统计所述服务提供端的异常计费次数和/或异常计费总金额;

在步骤C2中,若所述异常计费次数大于预设次数和/或所述异常计费总金额大于预设金额,则对所述服务提供端执行异常计费处理。

在该实现方式中,若服务提供端的异常计费次数过多或异常计费总金额过多,则需要对该服务提供端的司机执行异常计费处理,比如说对经常进行异常计费的司机进行一定的惩罚,减少司机多计费的情况,保证乘客的利益和提升乘客的体验。

在该实现方式中,所述异常计费处理包括以下一种或多种的组合:减少服务提供端的司机的评价分、限制服务提供端的接单类型、限制服务提供端的接单数量等等,这样可以对司机的计费行为进行有力检测管理,进一步地减少司机多计费的情况。

在一种可能的实现方式中,在步骤S202之前,所述计费提醒方法还可以包括以下步骤D1:

在步骤D1中,响应于所述目标订单属于预设类型的订单,确定所述支付费用信息中是否包含附加费。

在该实现方式中,一口价订单中的附加费是通过司机手动输入的,通过数据发现乘客投诉主要聚集在司机添加附加费,一口价订单多计费问题也远高于其他类型的订单,故可以设置该预设类型的订单为一口价订单,服务器在接收到该目标订单的支付申请消息后,可以先判断该目标订单的订单类型是否是一口价订单,如果是一口价订单才会进行后续的步骤S202至S204。如果该目标订单的订单类型不是一口价订单,则服务器可以按照该类型的订单支付流程进行。这样,就可以对一口价订单中的附加费的计费情况进行检测,减少一口价订单中的多计费的情况,减少一口价订单的投诉。

服务提供端一侧实施例

图3示出根据本公开一实施方式的一种应用于服务提供端的计费提醒方法的流程图。如图3所示,该计费提醒方法可以包括以下步骤:

在步骤S301中,向服务器发送目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

在步骤S302中,接收并显示所述服务器发送的第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

在步骤S303中,响应于获取指示取消收取所述附加费的取消指令,显示所述目标订单的支付申请页面;

在步骤S304中,响应于针对所述支付申请页面的申请提交指令,重新向所述服务提供端发送的所述目标订单的新的支付申请消息,所述新的支付申请消息中携带的支付费用信息不包括所述附加费。

本实施例中,服务提供端的用户即司机在为该服务接受端的用户即乘客提供了目标订单中的相应服务后,可以发起支付申请,操作服务提供端向服务器发送该目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息,以便该服务器向该服务接受端的用户指示进行服务费用支付,该支付费用信息指的是司机申请向乘客收取的费用信息。

本实施例中,服务器接收到该服务提供端发送的目标订单的支付申请消息后,可以判断该支付费用信息中是否包括附加费,如果该支付费用信息只有标识为固定车费的费用信息,则表明该目标订单没有附加费是按照固定车费来收取的,不存在多计费问题,此时计费提醒流程结束,服务器可以直接生成支付账单并发送给乘客的服务接受端,该服务接受端就可以基于乘客的支付操作支付该固定车费,完成该目标订单的支付。如果该支付费用信息包含有标识为附加费的费用信息,则需要通过判断目标订单的行程路线中是否包含收费路线来确定该附加费是否是违规收取的,如果该目标订单的行程路线中包含收费路线,则表明司机需要收取该附加费,如果该目标订单的行程路线中不包含收费路线,则表明司机不需要收取附加费。故,如果支付费用信息中包含附加费,而目标订单的行程路线中不包含收费路线,则表明该附加费可能是违规收取的,此时服务器会向服务提供端发送第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费。

本实施例中,服务提供端接收到该第一提示信息后,可以显示该第一提示信息,如可以弹窗显示该第一提示信息“确认是否收取附加费”以及“确认”按键、“取消”按键,如果司机是误操作输入的附加费,则司机在看到该第一提示信息后,可以点击“取消”按键,服务提供端检测到司机针对该“取消”按键的点击操作,就获取到司机输入的指示取消收取所述附加费的取消指令,此时服务提供端可以显示所述目标订单的支付申请页面,该支付申请页面可以是初始的附加费为空白的支付申请页面,也可以是司机上次提交输入有附加费的支付申请页面,在有附加费时需要司机删除该支付申请页面中的附加费金额,司机确定该支付申请页面中未添加附加费后可以重新点击该支付申请页面中的“提交”按键,服务提供端就会检测到针对所述支付申请页面的申请提交指令,此时,该服务提供端就可以重新向所述服务提供端发送的所述目标订单的新的支付申请消息。该新的支付申请消息中携带的支付费用信息不包括该附加费,此时,服务器可以继续执行步骤S201,此时,服务器可以响应于所述支付费用信息中不包含附加费,可以直接基于该新的支付申请消息生成支付账单并发送给乘客的服务接受端,该服务接受端就可以基于乘客的支付操作支付该固定车费,完成该目标订单的支付。

这里,该服务提供端在获取司机输入的指示取消收取所述附加费的取消指令时,可以向服务器发送取消收取附加费的取消消息告知服务器取消申请上次的支付费用信息,也可以不向服务器发送取消收取附加费的取消消息而是直接发送该目标订单的新的支付申请消息,用新的支付申请消息来替换旧的支付申请消息。

本实施例可以在目标订单的行程路线中不包含收费路线而司机收取附加费的情况下,显示第一提示信息来提醒司机取消收取附加费,对附加费的合理收取进行检测,防止司机因误操作而额外收取附加费,提升乘客体验,避免发生司乘冲突。

在一种可能的实现方式中,上述计费提醒方法还可以包括:

在步骤E1中,接收并显示所述服务器发送的第二提示信息,所述第二提示信息用于提示所述服务提供端是否修改所述附加费的额度;

在步骤E2中,响应于获取指示修改收取所述附加费的修改指令,显示所述目标订单的支付申请页面。

在该实现方式中,如果目标订单的行程路线中包含收费路线,则表明收取附加费的操作是合理的,但是,有时会存在收取的附加费的金额远大于附加费的实际金额的情况,为了保证收取的附加费的金额也是合理的,本实现方式中服务器还会对该附加费的额度的合理性进行进一步的检测,如果该附加费比所述预估附加费多出的差额不大于预设阈值,则表明收取的附加费属于正常计费水平,不存在多计费问题,此时计费提醒流程结束,服务器可以直接生成支付账单并发送给乘客的服务接受端,该服务接受端就可以基于乘客的支付操作支付该固定车费,完成该目标订单的支付。如果该附加费比所述预估附加费多出的差额大于预设阈值,则表明收取的附加费超出了正常计费水平,属于违规计费,此时服务器会向服务提供端发送第二提示信息,所述第二提示信息用于提示所述服务提供端是否修改所述附加费的额度。

本实施例中,服务提供端接收到该第二提示信息后,可以显示该第二提示信息,如可以弹窗显示该第二提示信息“是否修改所述附加费的额度”以及“确认”按键、“取消”按键,如果司机是误操作多输入的附加费,则司机在看到该第二提示信息后,可以点击“确认”按键,此时,服务提供端检测到司机针对该“确认”按键的点击操作后,就获取到司机输入的指示修改收取所述附加费的修改指令,此时服务提供端可以显示所述目标订单的支付申请页面,修改该支付申请页面中的附加费金额,重新向该服务器发送该目标订单的新的支付申请消息,该新的支付申请消息中携带的支付费用信息就不包括上次输入的附加费而是包括新输入的合理的附加费,此时,服务器可以继续执行步骤S201,此时,服务器可以响应于所述目标订单的行程路线中包含收费路线且新的附加费比所述预估附加费多出的差额不大于预设阈值,直接基于该新的支付申请消息生成支付账单并发送给乘客的服务接受端,该服务接受端就可以基于乘客的支付操作支付该固定车费,完成该目标订单的支付。这里,该服务提供端在检测到确认修改附加费的确认操作时,可以向服务器发送确认修改附加费的确认消息告知服务器取消申请上次的支付费用信息,也可以不向服务器发送确认修改附加费的确认消息而是直接发送该目标订单的新的支付申请消息,用新的支付申请消息来取代上次的支付费用信息。

本实现方式可以在司机可以收取附加费但收取的附加费的额度不合理,可以显示第二提示信息,提醒司机修改附加费的额度,对附加费的收取金额的合理性进行检测,防止司机收取过多的附加费,提升乘客体验,避免发生司乘冲突。

在一种可能的实现方式中,上述计费提醒方法还可以包括以下步骤F1:

在步骤F1中,响应于获取指示确认收取所述附加费的确认指令,向所述服务器发送确认收取所述附加费的第一确认消息。

在该实现方式中,服务提供端接收并显示该第一提示信息或第二提示信息后,司机看到该第一提示信息或第二提示信息,仍然坚持收取该附加费,此时,司机就会在该服务提供端输入指示确认收取所述附加费的确认指令,仍按照上述示例,司机可以点击该第一提示信息“确认是否收取附加费”的“确认”按键,输入指示确认收取所述附加费的确认指令;或者司机可以点击该第二提示信息“是否修改所述附加费的额度”的“取消”按键,输入指示确认收取所述附加费的确认指令。

在该实现方式中,服务提供端获取指示确认收取所述附加费的确认指令后,就会向服务器发送确认收取所述附加费的第一确认消息,服务器接收到该第一确认消息后,就会基于该支付费用信息生成支付账单,并发送给乘客的服务接受端,该服务接受端显示该支付账单后,如果该附加费是与司机协商好的,乘客可以进行支付操作,如果乘客认为该附加费是多出的或附加费的额度超过的,可以反馈至网约车平台进行裁决。

在该实现方式中,在给司机提示后司机仍坚持收取该附加费时,服务器可以将该目标订单记录为异常计费订单,并存储所述异常计费订单的订单数据,以便后续基于该记录对异常计费的司机进行判罚。该异常计费订单的订单数据包括该异常计费订单的服务提供端、异常计费金额等,该异常计费金额指的是超出该异常计费订单正常计费的金额。

系统实施例

图4是根据一示例性实施例示出的一种应用于系统的计费提醒方法的流程图,如图4所示,该计费提醒方法可以由服务提供端和服务器协作来实现,可以包括步骤S401-S406。

在步骤S401中,服务提供端向服务器发送目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

在步骤S402中,所述服务器响应于所述支付费用信息中包含附加费,确定所述目标订单的行程路线中是否包含收费路线;

在步骤S403中,所述服务器响应于所述目标订单的行程路线中不包含收费路线,向所述服务提供端发送第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

在步骤S404中,所述服务提供端接收并显示所述服务器发送的第一提示信息;

在步骤S405中,所述服务提供端响应于获取指示取消收取所述附加费的取消指令,显示所述目标订单的支付申请页面;

在步骤S406中,所述服务提供端响应于针对所述支付申请页面的申请提交指令,重新向所述服务器发送所述目标订单的新的支付申请消息,所述新的支付申请消息中携带的支付费用信息不包括所述附加费。

在一种可能的实现方式中,如图5所示,上述计费提醒方法还可以包括以下步骤:

在步骤S407中,所述服务器响应于所述目标订单的行程路线中包含收费路线,根据所述收费路线计算所述收费路线产生的预估附加费;

在步骤S408中,所述服务器响应于所述附加费比所述预估附加费多出的差额大于预设阈值,向所述服务提供端发送所述第二提示信息,所述第二提示信息用于提示所述服务提供端是否修改所述附加费的额度;

在步骤S409中,服务提供端接收并显示所述服务器发送的第二提示信息,所述第二提示信息用于提示所述服务提供端是否修改所述附加费的额度;

在步骤S410中,服务提供端响应于获取指示修改收取所述附加费的修改指令,显示所述目标订单的支付申请页面。

此时,所述新的支付申请消息中携带的支付费用信息包括修改后的附加费。

在一种可能的实现方式中,如图6所示,上述计费提醒方法还可以包括以下步骤:

在步骤S411中,服务提供端响应于获取指示确认收取所述附加费的确认指令,向所述服务器发送确认收取所述附加费的第一确认消息。

在步骤S412中,服务器响应于接收到所述第一确认消息,基于所述支付费用信息生成支付账单并将所述支付账单发送给服务接受端;

在步骤S413中,服务器确定所述目标订单为异常计费订单,记录所述异常计费订单的订单数据。

在一种可能的实现方式中,上述计费提醒方法还可以包括以下步骤G1:

在步骤G1中,服务器将所述服务提供端存在异常计费风险的第三提示信息发送给服务接受端。

服务器可以响应于接收到所述服务接受端发送的确认存在异常计费的第二确认消息,执行步骤S413,确定所述目标订单为异常计费订单,记录所述异常计费订单的订单数据。

在一种可能的实现方式中,如图6所示,上述计费提醒方法还可以包括以下步骤:

在步骤S414中,服务器基于所述异常计费订单的订单数据,统计所述服务提供端的异常计费次数和/或异常计费总金额;

在步骤S415中,服务器在所述异常计费次数大于预设次数和/或所述异常计费总金额大于预设金额时,对所述服务提供端执行异常计费处理。

在一种可能的实现方式中,如图6所示,上述计费提醒方法还可以包括以下步骤:

在步骤S416中,服务器响应于所述目标订单属于预设类型的订单,确定所述支付费用信息中是否包含附加费。

本实施例中计费提醒方法的具体细节可以参见上述服务器侧实施例和服务提供段侧实施例对计费提醒方法的描述,在此不再赘述。

图7示出根据本公开的实施例的一种应用于服务器的计费提醒装置的结构框图。

其中,该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。

如图7所示,所述计费提醒装置700包括第一获取模块710、第一确定模块720、第一发送模块730和第二获取模块740。

第一获取模块710,被配置为获取服务提供端发送的目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

第一确定模块720,被配置为响应于所述支付费用信息中包含附加费,确定所述目标订单的行程路线中是否包含收费路线;

第一发送模块730,被配置为响应于所述目标订单的行程路线中不包含收费路线,向所述服务提供端发送第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

第二获取模块740,被配置为重新获取所述服务提供端发送的所述目标订单的新的支付申请消息,所述新的支付申请消息中携带的支付费用信息不包括所述附加费。

在一种可能的实现方式中,所述装置还包括:

计算模块,被配置为响应于所述目标订单的行程路线中包含收费路线,根据所述收费路线计算所述收费路线产生的预估附加费;

第四发送模块,被配置为响应于所述附加费比所述预估附加费多出的差额大于预设阈值,向所述服务提供端发送所述第二提示信息,所述第二提示信息用于提示所述服务提供端是否修改所述附加费的额度。

在一种可能的实现方式中,所述装置还包括:

第一接收模块,被配置为接收所述服务提供端发送的确认收取所述附加费的第一确认消息;

账单生成模块,被配置为响应于接收到所述第一确认消息,基于所述支付费用信息生成支付账单并将所述支付账单发送给服务接受端;

记录模块,被配置为确定所述目标订单为异常计费订单,记录所述异常计费订单的订单数据。

在一种可能的实现方式中,所述装置还包括:

第五发送模块,被配置为将所述服务提供端存在异常计费风险的第三提示信息发送给服务接受端;

所述记录模块被配置为:响应于接收到所述服务接受端发送的确认存在异常计费的第二确认消息,确定所述目标订单为异常计费订单,记录所述异常计费订单的订单数据。

在一种可能的实现方式中,所述装置还包括:

统计模块,被配置为基于所述异常计费订单的订单数据,统计所述服务提供端的异常计费次数和/或异常计费总金额;

处理模块,被配置为若所述异常计费次数大于预设次数和/或所述异常计费总金额大于预设金额,则对所述服务提供端执行异常计费处理。

在一种可能的实现方式中,所述装置还包括:

第二确定模块,被配置为响应于所述目标订单属于预设类型的订单,确定所述支付费用信息中是否包含附加费。

本实施例中计费提醒装置的具体细节可以参见上述服务器侧实施例对计费提醒方法的描述,在此不再赘述。

图8示出根据本公开的实施例的一种应用于服务提供端的计费提醒装置的结构框图。其中,该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。

如图8所示,所述计费提醒装置800包括第二发送模块810、第一接收显示模块820、第一显示模块830和第三发送模块840。

第二发送模块810,被配置为向服务器发送目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

第一接收显示模块820,被配置为接收并显示所述服务器发送的第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

第一显示模块830,被配置为响应于获取指示取消收取所述附加费的取消指令,显示所述目标订单的支付申请页面;

第三发送模块840,被配置响应于针对所述支付申请页面的申请提交指令,重新向所述服务器发送所述目标订单的新的支付申请消息,所述新的支付申请消息中携带的支付费用信息不包括所述附加费。

在一种可能的实现方式中,所述装置还包括:

第二接收显示模块,被配置为接收并显示所述服务器发送的第二提示信息,所述第二提示信息用于提示所述服务提供端是否修改所述附加费的额度;

第二显示模块,被配置为响应于获取指示修改收取所述附加费的修改指令,显示所述目标订单的支付申请页面。

在一种可能的实现方式中,所述装置还包括:

第六发送模块,被配置为响应于获取指示确认收取所述附加费的确认指令,向所述服务器发送确认收取所述附加费的第一确认消息。

本实施例中计费提醒装置的具体细节可以参见上述服务提供端一侧实施例对计费提醒方法的描述,在此不再赘述。

本公开还公开了一种电子设备,图9示出根据本公开的实施例的电子设备的结构框图。

如图9所示,所述电子设备900包括存储器901和处理器902,其中,存储器901用于存储一条或多条计算机指令,其中,所述一条或多条计算机指令被所述处理器902执行以实现根据本公开的各实施例的方法。

图10示出适于用来实现根据本公开实施例的方法的计算机系统的结构示意图。

如图10所示,计算机系统1000包括处理单元1001,其可以根据存储在只读存储器(ROM)1002中的程序或者从存储部分1008加载到随机访问存储器(RAM)1003中的程序而执行上述实施例中的各种处理。在RAM 1003中,还存储有系统1000操作所需的各种程序和数据。处理单元1001、ROM 1002以及RAM 1003通过总线1004彼此相连。输入/输出(I/O)接口1005也连接至总线1004。

以下部件连接至I/O接口1005:包括键盘、鼠标等的输入部分1006;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1007;包括硬盘等的存储部分1008;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1009。通信部分1009经由诸如因特网的网络执行通信处理。驱动器1010也根据需要连接至I/O接口1005。可拆卸介质1011,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器1010上,以便于从其上读出的计算机程序根据需要被安装入存储部分1008。其中,所述处理单元1001可实现为CPU、GPU、TPU、FPGA、NPU等处理单元。

特别地,根据本公开的实施例,上文描述的方法可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括计算机指令,该计算机指令被处理器执行时实现上文所述的方法步骤。在这样的实施例中,该计算机程序产品可以通过通信部分1009从网络上被下载和安装,和/或从可拆卸介质1011被安装。

附图中的流程图和框图,图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施例中所涉及到的单元或模块可以通过软件的方式实现,也可以通过可编程硬件的方式来实现。所描述的单元或模块也可以设置在处理器中,这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定。

作为另一方面,本公开还提供了一种计算机可读存储介质,该计算机可读存储介质可以是上述实施例中电子设备或计算机系统中所包含的计算机可读存储介质;也可以是单独存在,未装配入设备中的计算机可读存储介质。计算机可读存储介质存储有一个或者一个以上程序,所述程序被一个或者一个以上的处理器用来执行描述于本公开的方法。

本申请实施例公开了TS1、一种计费提醒方法,其特征在于,所述方法包括:

获取服务提供端发送的目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

响应于所述支付费用信息中包含附加费,确定所述目标订单的行程路线中是否包含收费路线;

响应于所述目标订单的行程路线中不包含收费路线,向所述服务提供端发送第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

重新获取所述服务提供端发送的所述目标订单的新的支付申请消息,所述新的支付申请消息中携带的支付费用信息不包括所述附加费。

TS2、如TS1所述的方法,其中,所述重新获取所述服务提供端发送的所述目标订单的新的支付申请消息之前,所述方法还包括:

响应于所述目标订单的行程路线中包含收费路线,根据所述收费路线计算所述收费路线产生的预估附加费;

响应于所述附加费比所述预估附加费多出的差额大于预设阈值,向所述服务提供端发送第二提示信息,所述第二提示信息用于提示所述服务提供端是否修改所述附加费的额度。

TS3、如TS1或TS2所述的方法,其中,在向所述服务提供端发送所述第一提示信息或第二提示消息之后,所述方法还包括:

接收所述服务提供端发送的确认收取所述附加费的第一确认消息;

响应于接收到所述第一确认消息,基于所述支付费用信息生成支付账单并将所述支付账单发送给服务接受端;

确定所述目标订单为异常计费订单,记录所述异常计费订单的订单数据。

TS4、如TS3所述的方法,其中,在将所述支付账单发送给服务接受端时,所述方法还包括:

将所述服务提供端存在异常计费风险的第三提示信息发送给服务接受端;

所述确定所述目标订单为异常计费订单,记录所述异常计费订单的订单数据包括:

响应于接收到所述服务接受端发送的确认存在异常计费的第二确认消息,确定所述目标订单为异常计费订单,记录所述异常计费订单的订单数据。

TS5、如TS3所述的方法,其中,所述方法还包括:

基于所述异常计费订单的订单数据,统计所述服务提供端的异常计费次数和/或异常计费总金额;

若所述异常计费次数大于预设次数和/或所述异常计费总金额大于预设金额,则对所述服务提供端执行异常计费处理。

TS6、如TS1所述的方法,其中,在响应于所述支付费用信息中包含附加费,确定所述目标订单的行程路线中是否包含收费路线之前,所述方法还包括:

响应于所述目标订单属于预设类型的订单,确定所述支付费用信息中是否包含附加费。

TS7、一种计费提醒方法,其特征在于,包括:

向服务器发送目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

接收并显示所述服务器发送的第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取附加费;

响应于获取指示取消收取所述附加费的取消指令,显示所述目标订单的支付申请页面;

响应于针对所述支付申请页面的申请提交指令,重新向所述服务器发送所述目标订单的新的支付申请消息,所述新的支付申请消息中携带的支付费用信息不包括所述附加费。

TS8、如TS7所述的方法,其中,在响应于针对所述支付申请页面的申请提交指令,重新向所述服务器发送所述目标订单的新的支付申请消息之前,所述方法还包括:

接收并显示所述服务器发送的第二提示信息,所述第二提示信息用于提示所述服务提供端是否修改所述附加费的额度;

响应于获取指示修改收取所述附加费的修改指令,显示所述目标订单的支付申请页面。

TS9、如TS7所述的方法,其中,在显示所述服务器发送的第一提示信息或第二提示信息之后,所述方法还包括:

响应于获取指示确认收取所述附加费的确认指令,向所述服务器发送确认收取所述附加费的第一确认消息。

TS10、一种计费提醒方法,其特征在于,包括:

服务提供端向服务器发送目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

所述服务器响应于所述支付费用信息中包含附加费,确定所述目标订单的行程路线中是否包含收费路线;

所述服务器响应于所述目标订单的行程路线中不包含收费路线,向所述服务提供端发送第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

所述服务提供端接收并显示所述服务器发送的第一提示信息;

所述服务提供端响应于获取指示取消收取所述附加费的取消指令,显示所述目标订单的支付申请页面;

所述服务提供端响应于针对所述支付申请页面的申请提交指令,重新向所述服务器发送所述目标订单的新的支付申请消息,所述新的支付申请消息中携带的支付费用信息不包括所述附加费。

TS11、一种计费提醒装置,其特征在于,包括:

第一获取模块,被配置为获取服务提供端发送的目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

第一确定模块,被配置为响应于所述支付费用信息中包含附加费,确定所述目标订单的行程路线中是否包含收费路线;

第一发送模块,被配置为响应于所述目标订单的行程路线中不包含收费路线,向所述服务提供端发送第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

第二获取模块,被配置为重新获取所述服务提供端发送的所述目标订单的新的支付申请消息,所述新的支付申请消息中携带的支付费用信息不包括所述附加费。

TS12、一种计费提醒装置,其特征在于,包括:

第二发送模块,被配置为向服务器发送目标订单的支付申请消息,所述支付申请消息中携带有服务提供端申请的支付费用信息;

第一接收显示模块,被配置为接收并显示所述服务器发送的第一提示信息,所述第一提示信息用于提示所述服务提供端确认是否收取所述附加费;

第一显示模块,被配置为响应于获取指示取消收取所述附加费的取消指令,显示所述目标订单的支付申请页面;

第三发送模块,被配置响应于针对所述支付申请页面的申请提交指令,重新向所述服务器发送所述目标订单的新的支付申请消息,所述新的支付申请消息中携带的支付费用信息不包括所述附加费。

TS13、一种电子设备,其特征在于,包括存储器和处理器;其中,所述存储器用于存储一条或多条计算机指令,其中,所述一条或多条计算机指令被所述处理器执行以实现上述TS1至TS9任一项所述的方法步骤。

TS14、一种可读存储介质,其特征在于,其上存储有计算机指令,该计算机指令被处理器执行时实现上述TS1至TS9任一项所述的方法步骤。

TS15、一种计算机程序产品,其特征在于,包括计算机指令,该计算机指令被处理器执行时实现上述TS1至TS9任一项所述的方法步骤。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解,本公开中所涉及的发明范围,并不限于上述技术特征的特定组合而成的技术方案,同时也应涵盖在不脱离所述发明构思的情况下,由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

相关技术
  • 图像处理方法和装置、电子设备、存储介质、程序产品
  • 图像处理方法和装置、电子设备、存储介质、程序产品
  • 目标检测方法和装置、电子设备、存储介质、程序产品
  • 行人再识别方法和装置、电子设备、存储介质、程序产品
  • 图像处理方法和装置、电子设备、存储介质、程序产品
  • 电子设备的遗忘提醒方法、装置、车辆、介质及程序产品
  • 计费方法、装置、系统、设备、介质和程序产品
技术分类

06120116068993