一种车费代付方法及装置与流程

本公开涉及计算机处理技术领域，具体涉及一种车费代付方法及装置。

背景技术：

现有技术中，乘客通过交通运输类软件叫车时，只有通过平台支付车费后，司机才能得到相应的分成收入。但是，乘客在下车后，因为各种原因没有及时支付车费。虽然交通运输类软件设置有乘客下次乘客必须付清所欠车费的规定，但是大部分乘客叫车的周期较长，在下次乘客时支付车费，导致司机收款的账期将被拉长，使司机收费体验差。为缩短账期，当乘客长时间不支付车费时，部分司机会主动联系乘客，让其支付车费，导致乘客付款体验不好，甚至会引起乘客的流失。

技术实现要素：

针对现有技术中的缺陷，本公开提供一种车费代付方法及装置，可以部分地或者全部地解决现有技术中乘客叫车不支付车费导致服务提供者的账期延长，其收款体验差，或者部分服务提供者向乘客催款，导致乘客叫车支付体验差的问题。

第一方面，本公开提供了一种车费代付方法，所述方法包括：

当接收到当前订单的完成指令时，检测乘客是否已支付车费；

若在第一预设时间段内所述乘客未支付车费，获取当前订单的预设参数值；

根据所述预设参数值利用预设评估模型对所述当前订单进行评估；

若评估通过，代替所述乘客向所述服务提供者的账户垫付对应所述当前订单金额的车费。

可选地，所述完成指令为服务操作者的操作指令、乘客的操作指令或者当前订单到达终点时产生的结束指令。

可选地，预设参数包括：订单金额、起点、终点、起点与终点跨度、行程距离、出发时间、结束时间、完成时长、日期、是否节假日、订单类型以及是否为代叫车中的一种或者多种；或者，

所述预设参数包括：服务提供者信用记录、乘客信用记录、订单金额、起点、终点、起点与终点跨度、行程距离、出发时间、结束时间、完成时长、日期、是否节假日、订单类型以及是否为代叫车中的一种或者多种。

可选地，所述预设评估模型通过以下步骤对当前订单进行评估包括：

获取所述当前订单的服务提供者与乘客的信用记录；将所述信用记录与信用预设值进行比较；

若所述信用记录超过信用预设值，则根据所述预设参数值利用预设评估模型对所述当前订单进行评估。

可选地，所述预设评估模型通过以下方法获取包括：

获取第二预设时间段内所有历史订单数据；

利用所有历史订单数据的预设参数以及支付记录作为训练样本对基础评估模型进行训练；

当所述基础评估模型输出结果与支付记录的匹配成功率超过预设准确率时，将当前基础评估模型作为预设评估模型。

可选地，所述方法还包括：

向所述服务提供者的终端发送第一指令以使所述终端弹出包括车费支付成功内容的第一提示窗；和/或，

向所述乘客的移动终端发送第二指令以使所述移动终端弹出包括按时付款内容的第二提示窗。

可选地，所述评估未通时，所述方法还包括：

向所述服务提供者的终端发送第三指令以使所述终端弹出包括等待乘客支付车费内容的第三提示窗。

第二方面，本公开实施例还提供了一种车费代付装置，所述装置包括：

检测模块，用于在接收到当前订单的完成指令时，检测乘客是否已支付车费；

预设参数值获取模块，用于在第一预设时间段内所述乘客未支付车费时，获取当前订单的预设参数值；

评估模块，用于根据所述预设参数值利用预设评估模型对所述当前订单进行评估；

代付模块，用于在评估通过时代替所述乘客向所述服务提供者的账户垫付对应所述当前订单金额的车费。

可选地，所述检测模块中完成指令为服务操作者的操作指令、乘客的操作指令或者当前订单到达终点时产生的结束指令；

和/或，

所述评估模块中预设参数包括：订单金额、起点、终点、起点与终点跨度、行程距离、出发时间、结束时间、完成时长、日期、是否节假日、订单类型以及是否为代叫车中的一种或者多种，或者，所述预设参数包括：服务提供者信用记录、乘客信用记录、订单金额、起点、终点、起点与终点跨度、行程距离、出发时间、结束时间、完成时长、日期、是否节假日、订单类型以及是否为代叫车中的一种或者多种。

可选地，所述预设评估模型通过以下步骤对当前订单进行评估包括：

获取所述当前订单的服务提供者与乘客的信用记录；

将所述信用记录与信用预设值进行比较；

若所述信用记录超过信用预设值，则根据所述预设参数值利用预设评估模型对所述当前订单进行评估。

可选地，所述评估模块中预设评估模型通过以下方法获取包括：

获取第二预设时间段内所有历史订单数据；

利用所有历史订单数据的预设参数以及支付记录作为训练样本对基础评估模型进行训练；

当所述基础评估模型输出结果与支付记录的匹配成功率超过预设准确率时，将当前基础评估模型作为预设评估模型。

可选地，所述装置还包括指令发送模块，用于：

向所述服务提供者的终端发送第一指令以使所述终端弹出包括车费支付成功内容的第一提示窗；和/或，

向所述乘客的移动终端发送第二指令以使所述移动终端弹出包括按时还款内容的第二提示窗。

可选地，所述评估未通时，指令发送模块还用于：

向所述服务提供者的终端发送第三指令以使所述终端弹出包括等待乘客支付车费内容的第三提示窗。

由上述技术方案可知，本公开实施例通过检测订单完成后乘客未支付车费时，获取该当前订单的预设参数值，然后利用预设评估模型对当前订单进行评估，并在评估通过后代替所述乘客向所述服务提供者的账户垫付对应所述当前订单金额的车费。可见，本公开利用预设评估模型对当前订单进行评估可以减少代付车费时产生坏账的情况，从而提高代付车费的成功率。另外，本公开通过代替符合要求的乘客支付车费，可以使乘客有较好的支付体验；通过代替支付车费可以使服务提供者在第一时间得到车费分成收入，极大的缩短了其收账期，从而提升了服务提供者的收款体验。本公开通过上述方案使乘客与服务提供者都提升使用交通运输类软件的体验，从而避免运力以及客源的流失。

附图说明

通过参考附图会更加清楚的理解本公开的特征和优点，附图是示意性的而不应理解为对本公开进行任何限制，在附图中：

图1是本公开实施例一提供的一种车费代付方法流程示意图；

图2是本公开实施例二提供的一种车费代付方法流程示意图；

图3是本公开实施例三提供的一种车费代付装置框图。

具体实施方式

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

本公开实施例中该运力调配方法可以应用于服务器，下文以服务器为执行主体对本方法作详细说明。当然也可以应用于移动终端、智能设备以及在线网络等，本公开不作限定。

实施例一

本公开实施例提供了一种车费代付方法，如图1所示，包括：

s11、当接收到当前订单的完成指令时，检测乘客是否已支付车费。

乘客通过移动终端利用交通运输类软件叫车时，多个服务提供者通过终端利用该交通运输类软件抢单。当其中一个服务提供者抢到上述乘客的订单时，将该乘客从起点载到终点从而完成一个叫车订单。当完成订单时，此时服务器根据终端的位置与订单中终点进行比较，当终端的位置与终点相同或相近(坐标相同，或者坐标之差在预设范围内，例如预设范围可以是终点为圆心，半径为100米的圆形区域)时，会产生当前订单的结束指令，服务器得到结束指令时开始检测乘客是否已支付车费。

实际应用中，乘客在叫车时因各种原因中途下车或者距离终点较远时，此时无法得到当前订单的结束指令，使服务器无法知晓当前订单已经完成。为解决上述问题，本公开实施例中服务器检测服务提供者的终端的操作指令和/或乘客的移动终端的操作指令，当检测到其中一个操作指令时表明当前订单已经完成，此时服务器开始检测乘客是否已支付车费。

乘客支付车费是指，服务器接收到来自移动终端的支付指令，然后根据支付指令从该乘客账户划转与当前订单中金额相等的车费到上述服务提供者的账户中。判断乘客是否已支付车费则可以根据上述支付指令以及乘客与服务提供者的账户内的车费变动进行判断。当然支付车费的方案还可以采用现有技术中的方案实现，本公开不作限定。

s12、若在第一预设时间段内所述乘客未支付车费，获取当前订单的预设参数值。

服务器持续判断乘客是否已经支付车费，在当前订单的完成时刻持续第一预设时间段后，若服务器还未检测到乘客支付该订单的车费，则获取当前订单的预设参数值。

需要说明的是，本公开实施例中第一预设时间段是指，表示从一个时刻到另一个时刻之间的时间长度。其中第一预设时间段中的一个时刻是当前订单的结束时刻，另一个时刻是指一个时刻即结束时刻之后持续一定时间后的时刻。该第一预设时间段可以是十分钟、半小时、一小时、一天等，本领域技术人员可以根据具体使用场景进行设定，本公开不作限定。

上述预设参数为订单金额、起点、终点、起点与终点跨度、行程距离、出发时间、结束时间、完成时长、日期、是否节假日、订单类型以及是否为代叫车中的一种或者多种；或者，服务提供者信用记录、乘客信用记录、订单金额、起点、终点、起点与终点跨度、行程距离、出发时间、结束时间、完成时长、日期、是否节假日、订单类型以及是否为代叫车中的一种或者多种。其中，订单金额是指乘客应付给服务提供者的车费。起点、终点是指乘客上车的地点、下车的地点。起点与终点跨度是指订单的起点与终点之间是否跨省、跨城市或者跨城区。出发时间是指乘客叫车时间。结束时间是指服务器收到完成指令的时间。完成时长是指乘客从叫车到服务器收到完成指令之间的时间长度。日期是指发生该订单的日期。是否节假日是指发生订单的当天是否为国家规定的放假时间、或者周末时间。订单类型包括实时订单、预约订单和接送机订单等。是否为代叫车是指，叫车人与乘客为同一人，否则为代叫车。预设参数值是指对应相应预设参数的数值。

若服务器检测到乘客已经支付车费，则再不检测，并向服务提供者的终端发送支付成功指令，此时该终端会弹出提示窗，显示乘客已支付车费的内容。同时在乘客的移动终端显示支付成功的内容。

s13、根据所述预设参数值利用预设评估模型对所述当前订单进行评估。

服务器根据步骤12中获取的预设参数值代入预设评估模型进行评估，即将该预设评估模型所需要输入的预设参数值输入到该预设评估模型中，获取该预设评估模型的输出结果。该输出结果包括可以代付和不满足代付条件两种情况。可以代付的情况是指该预设评估模型对当前订单与历史订单匹配度达到预设准确率的情况，例如，相同条件的历史订单中预设准确率范围内的乘客都按时支付车费，当前订单与上述历史订单具有相同条件，那么该乘客能够按时支付车费的概率也应该为预设准确率，甚至超过预设准确率。不满足代付条件是指，预设参数值中的至少有一个参数会使上述预设评估模型的评估结果小于预设准确率。

需要说明的是，本公开实施例中预设评估模型通过以下方法获取包括：

s131、获取第二预设时间段内所有历史订单数据。该第二预设时间段内是指从一个时刻到另一个时刻之间的时间长度。其中第一预设时间段中的一个时刻是当前订单的结束时刻，另一个时刻是指一个时刻即结束时刻之前持续一定时间后的时刻。该第二预设时间段可以是一天、一周、一月甚至一年等，本领域技术人员可以根据具体使用场景进行设定，本公开不作限定。

s132、利用所有历史订单数据的预设参数以及支付记录作为训练样本对基础评估模型进行训练。

s133、当所述基础评估模型输出结果与支付记录的匹配成功率超过预设准确率时，将当前基础评估模型作为预设评估模型。

需要说明的是，本公开实施例中上述基础评估模型可以采用现有技术中的机器学习模型，例如朴素贝叶斯、决策树、logistic回归、线性回归、最近邻算法、boosting算法、k-means算法、plsa算法、ld算法、gdbt算法、em算法中的一种或者多种。当然，本领域技术人员可以根据具体使用场景选择合适的基础评估模型，同样可以实现本公开的技术方案，即也落入本公开的保护范围。

对于上述基础评估模型进行训练得到预设评估模型的训练方法也采用现有技术中的机器学习方法实现，本公开不作限定。

s14、若评估通过，代替所述乘客向所述服务提供者的账户垫付对应所述当前订单金额的车费。

服务器根据预设评估模型的评估结果进行处理。例如，当预设评估模型的计算结果大于上述预设准确率时会输出可以代付的代付指令，此时服务器根据上述代付指令代替乘客向服务提供者账户内划转当前订单金额的车费。同时，服务器在代付完成后向服务提供者的终端发送第一指令，使终端弹出包括车费支付成功内容的第一提示窗，这样服务提供者可以第一时间了解到收款信息。和/或，向乘客的移动终端发送第二指令以使移动终端弹出包括按时付款内容的第二提示窗，这样乘客可以知晓订单支付情况，在下次乘车前或指定期限内将车费还给提供端即可。可见，通过代付车费使乘客无需担心服务提供者的催款电话，而服务提供者也无需要担心收款期限延长，从而使双方有更好的使用交通运输类软件的体验。

当预设评估模型的计算结果小于上述预设准确率即评估结果为不满足代付条件时会产生不能代付的禁付指令，此时交通运输类软件提供商代付车费后有可能会产生坏账，为减少坏账风险，服务器会根据上述禁付指令向服务提供者的终端发送第三指令，使终端弹出包括等待乘客支付车费内容的第三提示窗。

实际应用中，在当前订单的乘客在指定时间内支付车费或者未支付车费时会形成一个新的历史订单数据，此时将该当前订单加入到历史订单数据库中，还可以对预设评估模型进行继续训练，使预设评估模型的评估结果越来越准确。继续训练方法与基础评估模型的训练方法相同，在此不再赘述。

本公开实施例中基础评估模型以加权求和为例进行说明。

定义r为乘客支付概率，0≤r≤100％，r越小，订单为坏账的可能性越大。

定义a为订单金额，1≤a≤100，当订单金额超过100时，a＝100。当订单金额小于1时，a＝1。

定义x1为订单金额对乘客支付概率的影响因子，0≤x1≤100％。

定义b为订单是否跨城市，1≤b≤100，当订单起终点横跨多个省时，b＝100；当订单起终点横跨1个省时，b＝50；当订单起终点横跨多个市时，b＝20；当订单起终点横跨1个市时，b＝10；当订单起终点横跨多个区县时，b＝5；当订单起终点横跨1个区县时，b＝2；当订单起终点不跨区县，b＝1。

定义x2为订单是否跨城市对乘客支付概率的影响因子，0≤x1≤100％。

基础评估模型为：

r＝x1*a+x2*b+x3*c……。

从历史订单数据库中选取三组数据作为训练样本：

训练样本1：r＝1,a＝10,b＝1；

训练样本2：r＝1,a＝20,b＝1；

训练样本3：r＝1,a＝100,b＝50。

训练后得出x1＝0,x2＝1，即预设评估模型为r＝0*x1+1*x2。

可见，该预设评估模型相对简单，评估准确率极低，因此需要继续输入真实的历史订单数据进行训练。

当然，本领域技术人员也可以采用上述算法中任意一种或者多种进行训练，得到一个或者多个预设评估模型。当设置有多个预设评估模型时，分别采用多个预设评估模型对当前订单进行评估，然后将得到的评估模型进行综合评估，从而可以提高评估结果的准确度。

实施例二

本公开实施例提供了一种车费代付方法，如图2所示，图2中步骤s21、s22以及s24分别与图1中的s11、s12以及s14相同，在此不再赘述。图2中还包括：

s25、获取所述当前订单的服务提供者与乘客的信用记录；

s24’、将所述信用记录与信用预设值进行比较；

s24、根据所述预设参数值利用预设评估模型对所述当前订单进行评估。

需要说明的是，本公开实施例中步骤s25可以与步骤s22互换。另外服务提供者与乘客的信用记录预先设置在服务器内，该信用记录可以来自国家交通部门提供的驾车违法违章记录，也可以是国家政府部门提供的违法记录，还可以是交通运输类软件提供商自建的信用记录；乘客的信用记录可以是国家政府部门提供的违法记录，还可以是交通运输类软件提供商自建的信用记录，本领域技术人员可以根据具体使用场景进行选择，本公开不作限定。

步骤s14中预设参数值和/信用记录作为预设评估模型的输入参数的，即训练预设评估模型是可以将服务提供者/乘客的信用记录作为其中的预设参数。而步骤s24’与步骤s13的不同之处在于，服务提供者以及乘客的信用记录作为基于的一个判断条件，只有服务提供者以及乘客的信用记录超过信用预设值时，才利用预设评估模型进行评估，这样可以有针对性的提高当前订单的评估准确率，进一步降低产生坏账的风险。

当然，本公开实施例还可以将服务提供者以及乘客的信用记录作为一个评估结果与预设估计模型的评估结果各自加权得到最终的评估结果，同样可以实现本申请的方案，具体实施方式不再详述。

实施例三

本公开实施例还提供了一种车费代付装置，如图3所示，所述装置包括：

检测模块m11，用于在接收到当前订单的完成指令时，检测乘客是否已支付车费；

预设参数值获取模块m12，用于在第一预设时间段内所述乘客未支付车费时，获取当前订单的预设参数值；

评估模块m13，用于根据所述预设参数值利用预设评估模型对所述当前订单进行评估；

代付模块m14，用于在评估通过时代替所述乘客向所述服务提供者的账户垫付对应所述当前订单金额的车费。

可选地，检测模块m11中完成指令为服务操作者的操作指令、乘客的操作指令或者当前订单到达终点时产生的结束指令；

和/或，

评估模块m13中预设参数包括：订单金额、起点、终点、起点与终点跨度、行程距离、出发时间、结束时间、完成时长、日期、是否节假日、订单类型以及是否为代叫车中的一种或者多种。

可选地，评估模块m13通过以下步骤对当前订单进行评估包括：

获取所述当前订单的服务提供者与乘客的信用记录；

将上述信用记录与信用预设值进行比较；

若上述信用记录超过信用预设值时，则根据所述预设参数值利用预设评估模型对所述当前订单进行评估。

可选地，评估模块m13中预设评估模型通过以下方法获取包括：

获取第二预设时间段内所有历史订单数据；

利用所有历史订单数据的预设参数以及支付记录作为训练样本对基础评估模型进行训练；

当所述基础评估模型输出结果与支付记录的匹配成功率超过预设准确率时，将当前基础评估模型作为预设评估模型。

可选地，所述装置还包括指令发送模块(图中未示出)，用于：

向所述服务提供者的终端发送第一指令以使所述终端弹出包括车费支付成功内容的第一提示窗；和/或，

向所述乘客的移动终端发送第二指令以使所述移动终端弹出包括按时还款内容的第二提示窗。

可选地，所述评估未通时，上述指令发送模块还用于：

向所述服务提供者的终端发送第三指令以使所述终端弹出包括等待乘客支付车费内容的第三提示窗。

对于装置实施例而言，由于该装置实施例对应实施例一的方法实施例，因而可以解决相同的技术问题，达到相同的技术效果，描述的比较简单，相关之处参见方法实施例的部分说明即可。

综上所述，本公开实施例提供的一种车费代付方法及装置，通过检测订单完成后乘客未支付车费时，获取该当前订单的预设参数值，然后利用预设评估模型对当前订单进行评估，并在评估通过后代替所述乘客向所述服务提供者的账户垫付对应所述当前订单金额的车费。可见，本公开利用预设评估模型对当前订单进行评估可以减少代付车费时产生坏账的情况，从而提高代付车费的成功率。另外，本公开通过代替符合要求的乘客支付车费，可以使乘客有较好的支付体验；通过代替支付车费可以使服务提供者在第一时间得到车费分成收入，极大的缩短了其收账期，从而提升了服务提供者的收款体验。本公开通过上述方案使乘客与服务提供者都提升使用交通运输类软件的体验，从而避免运力以及客源的流失。

应当注意的是，在本实施例公开的装置的各个部件中，根据其要实现的功能而对其中的部件进行了逻辑划分，但是，本公开不受限于此，可以根据需要对各个部件进行重新划分或者组合，例如，可以将一些部件组合为单个部件，或者可以将一些部件进一步分解为更多的子部件。

本公开的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本公开实施例的系统中的一些或者全部部件的一些或者全部功能。本公开还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本公开的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是，上述实施例对本公开进行说明而不是对本公开进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本公开可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。词语第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

以上实施方式仅适于说明本公开，而并非对本公开的限制，有关技术领域的普通技术人员，在不脱离本公开的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本公开的范畴，本公开的专利保护范围应由权利要求限定。