CN105825663A - 打车方法、服务器及系统 - Google Patents

Abstract

本申请提供一种打车方法、服务端及系统。打车方法包括：根据乘客客户端的打车请求，生成打车服务订单；将打车服务订单发送给出租车客户端；接收出租车客户端返回的接单信息；对乘客客户端对应的担保账户进行冻结处理；向乘客客户端和出租车客户端发送订单成功消息。本申请可以充分发挥打车软件的优势。

Description

打车方法、服务器及系统

【技术领域】

本申请涉及通信技术领域，尤其涉及一种打车方法、服务器及系统。

【背景技术】

为解决乘客打车困难的问题，涌现出一批打车软件，例如滴滴打车、快的打车等，这些打车软件提供打车服务的流程如下：

乘客客户端向服务器端发送需要打车的请求，服务器端根据该请求，生成订单信息向符合一定条件的出租车的车载终端进行推送，当使用车载终端的出租车司机根据自身运营情况选择接单时，则订单完成，乘客和出租车司机之间完成打车交易。

在现有打车软件使用过程中经常出现下面的情况：出租车司机选择接单后，部分乘客没待出租车到来，就选择其他方式(例如乘坐公交车或选择其他路过的出租车)先行离开，导致接单的出租车空跑。久而久之，就会使出租车司机对打车软件丧失信心，无法充分发挥打车软件的优势。由此可见，迫切需要一种能够充分发挥打车软件优势的打车方法。

【发明内容】

本申请的多个方面提供一种打车方法、服务器及系统，用以充分发挥打车软件的优势。

本申请的一方面，提供一种打车方法，包括：

根据乘客客户端的打车请求，生成打车服务订单；

将所述打车服务订单发送给出租车客户端；

接收所述出租车客户端返回的接单信息；

对所述乘客客户端对应的担保账户进行冻结处理；

向所述乘客客户端和所述出租车客户端发送订单成功消息。

本申请的另一方面，提供一种服务端，包括：

生成模块，用于根据乘客客户端的打车请求，生成打车服务订单；

发送模块，用于将所述打车服务订单发送给出租车客户端；

接收模块，用于接收所述出租车客户端返回的接单信息；

冻结模块，用于对所述乘客客户端对应的担保账户进行冻结处理；

所述发送模块，还用于向所述乘客客户端和所述出租车客户端发送订单成功消息。

本申请的又一方面，提供一种打车系统，包括：乘客客户端、出租车客户端和服务端；

所述乘客客户端，用于向所述服务端发送打车请求，并接收所述服务端发送的订单成功消息；

所述服务端，用于根据所述打车请求，生成打车服务订单，将所述打车服务订单发送给所述出租车客户端，并接收所述出租车客户端返回的接单信息，对所述乘客客户端对应的担保账户进行冻结处理，以及向所述乘客客户端和所述出租车客户端发送所述订单成功消息；

所述出租车客户端，用于根据所述打车服务订单，生成所述接单信息，将所述接单信息发送给所述服务端，并接收所述服务端发送的所述订单成功消息。

由上述可见，本申请根据乘客客户端的打车请求，生成打车服务订单，将打车服务订单发送给出租车客户端，接收出租车客户端返回的接单信息，对乘客客户端对应的担保账户进行冻结处理，向乘客客户端和出租车客户端发送订单成功消息，完成打车流程。由于本申请通过对乘客客户端对应的担保账户进行冻结，在一定程度上向出租车司机提供了担保，使得出租车司机可以放心接单，有利于促进打车软件的广泛应用，充分发挥打车软件的优势。

【附图说明】

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

图1为本申请一实施例提供的打车方法的流程示意图；

图2为本申请另一实施例提供的打车方法的流程示意图；

图3为本申请一实施例提供的服务端的结构示意图；

图4为本申请另一实施例提供的服务端的结构示意图；

图5为本申请一实施例提供的打车系统的结构示意图。

【具体实施方式】

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

图1为本申请一实施例提供的打车方法的流程示意图。如图1所示，该方法包括：

101、根据乘客客户端的打车请求，生成打车服务订单。

102、将上述打车服务订单发送给出租车客户端。

103、接收出租车客户端返回的接单信息。

104、对乘客客户端对应的担保账户进行冻结处理。

105、向乘客客户端和出租车客户端发送订单成功消息。

本实施例提供一种打车方法，可由打车系统中的服务端来执行。该打车系统可由打车软件实现，一般包括：乘客客户端、出租车客户端和服务端。

具体的，当乘客需要打车时，可以通过乘客客户端向服务端发送打车请求。乘客客户端可安装于乘客的终端设备上，终端设备可以是用户的手机、平板电脑或笔记本等。乘客可以通过乘客客户端以语音方式向服务端发送打车请求，或者乘客也可以通过乘客客户端以文本方式向服务端发送打车请求。打车请求一般携带有乘客的联系方式、起始位置信息和终点位置信息等信息。

服务端接收乘客客户端发送的打车请求，根据该打车请求，生成打车服务订单，并将打车服务订单发送给出租车客户端。其中打车服务订单一般包括乘客的联系方式、起始位置信息、终点位置信息、是否加价以及加价时的加价金额等信息。可选的，服务端可以将打车服务订单发送给符合一定条件的出租车客户端，例如可以是距离乘客起始位置一定范围的出租车客户端。出租车客户端接收服务端发送的打车服务订单后，可以将打车服务订单显示给出租车司机，这样出租车司机可以根据打车服务订单携带的信息进行抢单，其中，出租车司机抢单主要是向出租车客户端发抢单指令。若出租车司机抢单成功，出租车客户端会生成接单信息，并向服务端返回接单信息，该接单信息用于指示该出租车司机接单。

服务端接收出租车客户端发送的接单信息，根据该接单信息可以了解到有出租车司机接单。为了降低因乘客在接单的出租车到达之前采用其他方式先行离开，造成接单的出租车空跑，降低上座率这一现象的概率，服务端在确定有出租车司机接单后，先对乘客客户端对应的担保账户进行冻结处理，然后再向乘客客户端和出租车客户端发送订单成功消息。其中，乘客客户端对应的担保账户实际上是乘客的担保账户，该担保账户可以是乘客签约的账户。通过对乘客的担保账户进行冻结，若出现乘客在接单的出租车到达之前先行离开导致出租车空跑的情况，则可以根据所冻结的乘客的担保账户，采取各种方式给出租车司机做出一定程度的补偿或保障，例如将冻结的金额转入出租车司机的账户以作为补偿，或者也可以根据担保账户的冻结情况，降低该乘客的诚信度，并在以后的打车过程中将该诚信度作为提醒信息提供给出租车司机，这样可以降低日后出租车的空跑概率，提高上座率。

其中，对乘客客户端对应的担保账户进行冻结处理具体可以是冻结该担保账户中指定数量(例如可以是10元)的金额，这样该担保账户中被冻结的金额在解冻前将不能被使用；或者也可以是直接冻结该担保账户，这样该担保账户中的全部金额在担保账户被解冻前将不能被使用；或者还可以是冻结与该担保账户绑定的银行卡等。

值得说明的，服务端发送给乘客客户端的订单成功消息可以携带有该笔订单的订单号以及出租车司机的联系方式。例如，乘客客户端可以在其界面上显示出租车司机的联系方式，以便于乘客与出租车司机联系。相应的，服务端发送给出租车客户端的订单成功消息可以携带有该笔订单的订单号、乘客的联系方式、起始位置信息和终点位置信息等。出租车客户端可以在其界面上显示乘客的联系方式，以便于出租车司机与乘客联系。

上述订单号是全局唯一的，例如可以由日期、时间戳、司机号码和N个信息位构成，但不限于此。N是自然数。

由上述可见，在本实施例提供的方法中，服务端在确定有出租车司机接收乘客的打车服务订单后，先对乘客的担保账户进行冻结处理，再向乘客和出租车司机发送订单完成消息，完成该笔打车服务订单，其中，通过对乘客的担保账户进行冻结，一定程度上给了出租车司机提供了保障，同时也对乘客的诚信度有了一定限定，有利于降低乘客在接单的出租车到达之前先行离开的概率，降低了出租车空跑的概率，并且有利于鼓励出租车司机积极抢单，有利于促进打车软件的广泛应用，充分发挥打车软件的优势。

图2为本申请另一实施例提供的打车方法的流程示意图。如图2所示，该方法包括：

201、根据乘客客户端的打车请求，生成打车服务订单。

202、将上述打车服务订单发送给出租车客户端。

203、接收出租车客户端返回的接单信息，该接单信息携带有担保指示信息，该担保指示信息用以指示出租车司机选择担保打车模式。

204、根据上述担保指示信息，对乘客客户端对应的担保账户进行冻结处理。

205、向乘客客户端和出租车客户端发送订单成功消息。

本实施例与图1所示实施例相类似，区别在于：本实施例向出租车司机提供了至少两种服务模式，至少两种服务模式中包括担保打车模式，另外还可以包括普通打车模式等非担保打车模式。其中，普通打车模式是指现有技术中的常规做法，即服务端确定有出租车司机接单后，直接向乘客客户端和出租车客户端返回订单成功消息。担保打车模式是指需要对乘客的担保账户进行冻结处理的方式，即对乘客客户端对应的担保账户进行冻结处理后，向乘客客户端和出租车客户端返回订单成功消息。

其中，出租车司机可以选择服务模式，为了便于服务端了解出租车司机选择的是何种服务模式，出租车客户端需要在返回给服务端的接单消息中携带用于指示出租车司机选择何种服务模式的指示信息，当出租车司机选择担保打车模式时，接单信息携带担保指示信息，用以指示出租车司机选择担保打车模式。

在一实施方式中，服务模式的选择可由出租车司机来控制，即出租车司机可以自行决定使用哪种服务模式。在该实施方式中，出租车司机向出租车客户端发出接单指令时可以直接发出选择担保打车模式的接单指令，则出租车客户端在生成接单信息时，可以直接将担保指示信息携带在接单信息中。

在另一实施方式中，服务模式的选择可以由服务端来控制，例如服务端可以向出租车客户端发送担保提示信息，用以提示出租车司机是否选择担保打车模式，还是选择其他服务模式。可选的，服务端可以将担保提示信息携带在打车服务订单中提供给出租车客户端。可选的，服务端提供的担保提示信息可以是给出租车客户端一指令，出租车客户端根据该指令生成担保打车模式的选择按钮和普通打车模式的选择按钮，并将两个选择按钮显示给出租车司机，以供出租车司机进行选择。在该实施方式中，出租车客户端可以在向出租车客户端发出接单指令时，直接点击担保打车模式的选择按钮，在发出接单指令的同时选择了担保打车模式，则出租车客户端在生成接单信息时，可以将担保指示信息携带在接单信息中。

进一步，在上述各实施例的基础上，若对乘客客户端对应的担保账户冻结处理失败，例如无法冻结或者余额不足或者不支持等，服务端可以将冻结失败消息发送给乘客客户端，以提示乘客可以选择普通打车模式；并将冻结失败消息发送给出租车司机客户端，提示本次订单失败，并告知失败原因。

进一步，在上述各实施例的基础上，当服务端向乘客客户端和出租车客户端发送订单成功消息之后，出租车司机开始向乘客提供打车服务。当打车服务完成之后，乘客需要向出租车司机支付打车费。乘客可以选择现金支付，也可以选择在线支付。其中，在线支付过程具体包括：

服务端接收乘客客户端发送的付款请求；根据付款请求，执行扣款操作，并对担保账户进行解冻处理；向乘客客户端和出租车客户端发送付款成功消息。

在一可选实施方式中，服务端可以通过用户签约的第三方支付公司提供的支付平台(简称为第三方支付平台)执行扣款操作。该过程属于现有技术，本实施例不做详述。

在另一可选实施方式中，考虑到乘客可能会有多个账户，例如微信支付账户、支付宝账户、财付通账号、信用卡预授权账户等，若乘客使用不同账户作为担保账户时，需要分别到相应的第三方支付平台，例如微信平台、支付宝平台、财付通平台、信用卡平台等进行签约。为了避免乘客需要到多个平台进行签约，本实施例提供一种统一的平台，称为签约平台，各种支付平台，例如微信平台、支付宝平台、财付通平台、信用卡平台等可以接入签约平台，乘客只需与签约平台签约即可，这样可以屏蔽平台无关性，实现乘客无缝接入的目的，提高乘客使用打车软件的便利性。

其中，签约平台会预先绑定乘客信息与支付平台提供的担保账户以及支付账户之间的关系。若乘客与签约平台签约，该签约平台统一跳到第三方支付平台(例如支付宝平台或微信平台)完成签约。这样，服务端可以通过签约平台对担保账户进行冻结，例如签约平台可以无缝调用第三方支付平台的冻结接口，对乘客的担保账户进行冻结处理。另外，服务端也可以通过签约平台执行扣款操作，例如签约平台可以无缝调用第三方支付平台提供的支付接口，对乘客的支付账户进行扣款操作。

下面说明基于签约平台进行担保账户冻结和解冻的流程：

担保账户的冻结：服务端向签约平台发送冻结请求，以指示签约平台从乘客的签约账户中确定担保账户，并冻结所述担保账户中指定数量的金额；接收签约平台返回的冻结成功消息。

可选的，若乘客在签约平台同时签约了多个账户，乘客可以预先设定账户的优先级，签约平台可以根据账户的优先级确定担保账户。例如，乘客可以通过调用签约平台提供的查询接口或者优先级设置接口，来设置所签约的多个账户之间的优先级。举例说明，假设乘客同时签约了支付宝账户和财付通账户，则可以确定支付宝账户的优先级高于财付通账户的优先级。

担保账户的解冻：服务端向签约平台发送解冻请求，以指示签约平台解冻担保账户中被冻结的指定数量的金额；接收签约平台返回的解冻成功消息。

在一可选实施方式中，为了在扣款失败的情况下能够继续给出租车司机提供保障，可以在扣款成功后再对担保账户进行解冻处理。具体流程可如下所示：

服务端向签约平台发送扣款请求，以指示签约平台对乘客客户端对应的支付账户进行扣款；

服务端接收签约平台返回的扣款成功消息；

服务端向签约平台发送解冻请求，以指示签约平台解冻担保账户中被冻结的指定数量的金额；

服务端接收签约平台返回的解冻成功消息。

值得说明的是，在上述流程中，支付账户和担保账户可以是同一账户。

综上所述，本申请通过对乘客客户端对应的担保账户进行冻结，在一定程度上向出租车司机提供了担保，使得出租车司机可以放心接单，有利于促进打车软件的广泛应用，充分发挥打车软件的优势。另外，通过提供统一的签约平台，可以简化乘客的签约流程，并且更有利于管理。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

图3为本申请一实施例提供的服务端的结构示意图。如图3所示，服务端包括：生成模块31、发送模块32、接收模块33和冻结模块34。

生成模块31，用于根据乘客客户端的打车请求，生成打车服务订单。

发送模块32，用于将生成模块31生成的打车服务订单发送给出租车客户端。

接收模块33，用于接收出租车客户端返回的接单信息。

冻结模块34，用于对乘客客户端对应的担保账户进行冻结处理。

发送模块32，还用于向乘客客户端和出租车客户端发送订单成功消息。

在一可选实施方式中，上述接单信息携带有担保指示信息，担保指示信息用以指示出租车司机选择担保打车模式。相应的，冻结模块34具体用于：根据担保指示信息，对担保账户进行冻结处理。

在一可选实施方式中，上述打车服务订单包括：担保提示信息，以提示出租车司机是否选择担保打车模式。

在一可选实施方式中，如图4所示，服务端还包括：扣款模块35和解冻模块36。

接收模块33，还用于接收乘客客户端发送的付款请求。

扣款模块35，用于执行扣款操作。

解冻模块36，用于对担保账户进行解冻处理。

发送模块32，还用于向乘客客户端和出租车客户端发送付款成功消息。

在一可选实施方式中，冻结模块34具体用于：向签约平台发送冻结请求，以指示签约平台从乘客的签约账户中确定担保账户，并冻结担保账户中指定数量的金额；接收签约平台返回的冻结成功消息。

在一可选实施方式中，扣款模块35具体用于：向签约平台发送扣款请求，以指示签约平台对乘客客户端对应的支付账户进行扣款；接收签约平台返回的扣款成功消息。相应的，解冻模块36具体用于：在扣款模块35接收到扣款成功消息后，向签约平台发送解冻请求，以指示签约平台解冻担保账户中被冻结的指定数量的金额；接收签约平台返回的解冻成功消息。

本实施例提供的服务端，根据乘客客户端的打车请求，生成打车服务订单，将打车服务订单发送给出租车客户端，接收出租车客户端返回的接单信息，对乘客客户端对应的担保账户进行冻结处理，向乘客客户端和出租车客户端发送订单成功消息，完成打车流程。由于本实施例提供的服务端通过对乘客客户端对应的担保账户进行冻结，在一定程度上向出租车司机提供了担保，使得出租车司机可以放心接单，有利于促进打车软件的广泛应用，充分发挥打车软件的优势。

图5为本申请一实施例提供的打车系统的结构示意图。如图5所示，该系统包括：乘客客户端51、出租车客户端52和服务端53。

乘客客户端51，用于向服务端发送打车请求，并接收服务端发送的订单成功消息。

服务端53，用于根据打车请求，生成打车服务订单，将打车服务订单发送给出租车客户端，并接收出租车客户端返回的接单信息，对乘客客户端对应的担保账户进行冻结处理，以及向乘客客户端和出租车客户端发送订单成功消息。

出租车客户端52，用于根据打车服务订单，生成接单信息，将接单信息发送给服务端，并接收服务端发送的订单成功消息。

在一可选实施方式中，上述接单信息携带有担保指示信息，担保指示信息用以指示出租车司机选择担保打车模式。相应的，服务端53具体用于：根据担保指示信息，对担保账户进行冻结处理。

在一可选实施方式中，上述打车服务订单包括：担保提示信息，以提示出租车司机是否选择担保打车模式。

在一可选实施方式中，服务端53还用于接收乘客客户端发送的付款请求，执行扣款操作，并对担保账户进行解冻处理，向乘客客户端和出租车客户端发送付款成功消息。

在一可选实施方式中，本实施例的打车系统还包括签约平台。

基于上述，服务端53冻结担保账户具体可为：向签约平台发送冻结请求，以指示签约平台从乘客的签约账户中确定担保账户，并冻结担保账户中指定数量的金额；接收签约平台返回的冻结成功消息。

在一可选实施方式中，服务端53执行扣款操作，并解冻担保账户具体可以为：向签约平台发送扣款请求，以指示签约平台对乘客客户端对应的支付账户进行扣款；接收签约平台返回的扣款成功消息，向签约平台发送解冻请求，以指示签约平台解冻担保账户中被冻结的指定数量的金额；接收签约平台返回的解冻成功消息。

本实施例提供的打车系统，服务端根据乘客客户端的打车请求，生成打车服务订单，将打车服务订单发送给出租车客户端，接收出租车客户端返回的接单信息，对乘客客户端对应的担保账户进行冻结处理，向乘客客户端和出租车客户端发送订单成功消息，完成打车流程。由于本实施例提供的打车系统通过对乘客客户端对应的担保账户进行冻结，在一定程度上向出租车司机提供了担保，使得出租车司机可以放心接单，有利于促进打车软件的广泛应用，充分发挥打车软件的优势。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(RandomAccessMemory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (13)

1.一种打车方法，其特征在于，包括：

根据乘客客户端的打车请求，生成打车服务订单；

将所述打车服务订单发送给出租车客户端；

接收所述出租车客户端返回的接单信息；

对所述乘客客户端对应的担保账户进行冻结处理；

向所述乘客客户端和所述出租车客户端发送订单成功消息。

2.根据权利要求1所述的方法，其特征在于，所述接单信息携带有担保指示信息，所述担保指示信息用以指示出租车司机选择担保打车模式；

所述对所述乘客客户端对应的担保账户进行冻结处理，包括：

根据所述担保指示信息，对所述担保账户进行冻结处理。

3.根据权利要求2所述的方法，其特征在于，所述打车服务订单包括：担保提示信息，以提示所述出租车司机是否选择所述担保打车模式。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述向所述乘客客户端和所述出租车客户端发送订单成功消息之后，还包括：

接收所述乘客客户端发送的付款请求；

执行扣款操作，并对所述担保账户进行解冻处理；

向所述乘客客户端和所述出租车客户端发送付款成功消息。

5.根据权利要求4所述的方法，其特征在于，所述对所述乘客客户端对应的担保账户进行冻结处理，包括：

向签约平台发送冻结请求，以指示所述签约平台从乘客的签约账户中确定所述担保账户，并冻结所述担保账户中指定数量的金额；

接收所述签约平台返回的冻结成功消息。

6.根据权利要求5所述的方法，其特征在于，所述执行扣款操作，并对所述担保账户进行解冻处理，包括：

向所述签约平台发送扣款请求，以指示所述签约平台对所述乘客客户端对应的支付账户进行扣款；

接收所述签约平台返回的扣款成功消息；

向所述签约平台发送解冻请求，以指示所述签约平台解冻所述担保账户中被冻结的所述指定数量的金额；

接收所述签约平台返回的解冻成功消息。

7.一种服务端，其特征在于，包括：

生成模块，用于根据乘客客户端的打车请求，生成打车服务订单；

发送模块，用于将所述打车服务订单发送给出租车客户端；

接收模块，用于接收所述出租车客户端返回的接单信息；

冻结模块，用于对所述乘客客户端对应的担保账户进行冻结处理；

所述发送模块，还用于向所述乘客客户端和所述出租车客户端发送订单成功消息。

8.根据权利要求7所述的服务端，其特征在于，所述接单信息携带有担保指示信息，所述担保指示信息用以指示出租车司机选择担保打车模式；

所述冻结模块具体用于：根据所述担保指示信息，对所述担保账户进行冻结处理。

9.根据权利要求8所述的服务端，其特征在于，所述打车服务订单包括：担保提示信息，以提示所述出租车司机是否选择所述担保打车模式。

10.根据权利要求7-9任一项所述的服务端，其特征在于，还包括：扣款模块和解冻模块；

所述接收模块，还用于接收所述乘客客户端发送的付款请求；

所述扣款模块，用于执行扣款操作；

所述解冻模块，用于对所述担保账户进行解冻处理；

所述发送模块，还用于向所述乘客客户端和所述出租车客户端发送付款成功消息。

11.根据权利要求10所述的服务端，其特征在于，所述冻结模块具体用于：

向签约平台发送冻结请求，以指示所述签约平台从乘客的签约账户中确定所述担保账户，并冻结所述担保账户中指定数量的金额；

接收所述签约平台返回的冻结成功消息。

12.根据权利要求11所述的服务端，其特征在于，所述扣款模块具体用于：

向所述签约平台发送扣款请求，以指示所述签约平台对所述乘客客户端对应的支付账户进行扣款；

接收所述签约平台返回的扣款成功消息；

所述解冻模块具体用于：

在所述扣款模块接收到所述扣款成功消息后，向所述签约平台发送解冻请求，以指示所述签约平台解冻所述担保账户中被冻结的所述指定数量的金额；

接收所述签约平台返回的解冻成功消息。

13.一种打车系统，其特征在于，包括：乘客客户端、出租车客户端和服务端；

所述乘客客户端，用于向所述服务端发送打车请求，并接收所述服务端发送的订单成功消息；

所述服务端，用于根据所述打车请求，生成打车服务订单，将所述打车服务订单发送给所述出租车客户端，并接收所述出租车客户端返回的接单信息，对所述乘客客户端对应的担保账户进行冻结处理，以及向所述乘客客户端和所述出租车客户端发送所述订单成功消息；

所述出租车客户端，用于根据所述打车服务订单，生成所述接单信息，将所述接单信息发送给所述服务端，并接收所述服务端发送的所述订单成功消息。