CN110827014A - 基于企业账户的乘车支付方法、系统及一种企业端、用户终端 - Google Patents

Abstract

本发明公开了一种基于企业账户的乘车支付方法，包括：企业端接收来自用户终端的发码请求；生成包含企业ID的乘车码并反馈给用户终端；企业端接收后台服务器基于POS端机具对乘车码的验证情况信息进行扣款后返回的扣款情况。本发明将用户终端与企业端关联，在有支付需求时，企业端给用户终端发乘车码，员工只需将乘车码提供给POS端机具，后台服务器会对企业端账户进行扣款。当有报销需求时，企业端与后台服务器直接对接。整个差旅支付及后续报销都非常便捷，无需员工垫付车费，也不用每次索取发票，并且，员工乘车的记录也可以被监控。本发明可以替代人工，提升工作效率。本发明还提供了基于企业账户的乘车支付系统、一种客户端及用户终端。

Description

基于企业账户的乘车支付方法、系统及一种企业端、用户终端

技术领域

本发明涉及移动支付技术领域，特别涉及基于企业账户的乘车支付方法、系统及一种企业端、用户终端。

背景技术

为了推动经济良性良好发展，国家大力提倡“大众创业、万众创新”，新成立的企业如雨后春笋般建立起来，企业员工出差、外勤等涉及到的交通费报销事宜越来越频繁。由于费用报销需要相应的发票，因此目前只能先由员工垫付乘车费用，然后再在公交上或者地铁站索取发票后向公司申请报销。鉴于公共交通费用低、频率高、发票索取麻烦等特点，整个报销过程容易耗费大量的人力。另外，出差过程中往往缺少第三方监控，无法避免多报销的情况。

近年，公共交通出行业使用扫码支付变得越来越普及。扫码支付系统一般包括位于用户侧的用户终端(比如手机)及公交或地铁闸机处的收款设备。乘客可以使用用户终端设备中的客户端软件生成二维码供收款设备读取，经过一定验证后实现支付。现有收款设备一般包括用于识别及验证二维码的POS端机具(如公交的刷卡机或者地铁闸机)及用于完成扣款等操作的后台服务器，在某些情况下可以将POS端机具和后台服务器集成在一起。用户终端上支持扫码乘车功能的主流客户端软件包括支付宝、微信等，为了保障用户刷码上车的体验，加快上车速度，支付宝及微信基于用户已有的个人账户体系，实现用户“先刷码后付款”，即用户刷码上车后，乘车金额从用户账户中自动扣除，无需用户输入支付密码，减少乘车刷码操作步骤。该方案可以提升乘车支付的效率，并且由于扫码支付后客户端软件上有记录支付时间及对应金额，因此能够起到一定的监督作用，避免多报销。但是这些方法未从根本上解决人工报销的模式，并且人们大多有固定思维，认为这是财务工作，从未考虑用技术手段解决类似问题。有鉴于此，实有必要提出一种智能化的解决方法，替代人工，提升工作效率。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种基于企业账户的乘车支付方法和系统。

第一方面，本发明实施例提供一种基于企业账户的乘车支付方法，包括以下步骤：

企业端接收来自用户终端的发码请求；

生成包含企业ID的乘车码并反馈给用户终端；

企业端接收后台服务器基于POS端机对所述乘车码的验证情况信息进行扣款后返回的扣款情况。

第二方面，基于同一发明构思，本发明实施例还提供一种基于企业账户的乘车支付方法，包括以下步骤：

用户终端判断自身网络状况，若已联网，则发送发码请求给企业端；

接收企业端发送的包含企业ID的乘车码；

用户终端向POS端机具请求验证所述乘车码。

第三方面，基于同一发明构思，本发明实施例还提供一种基于企业账户的乘车支付系统，该系统包括企业端、用户终端、POS端机具、后台服务器，其中：

企业端，用于接收来自用户终端的发码请求；生成包含企业ID的乘车码并反馈给用户终端；并接收后台服务器基于POS端机具对所述乘车码的验证情况信息进行扣款后返回的扣款情况；

用户终端，用于判断自身网络状况，若已联网，则发送发码请求给企业端；接收企业端发送的包含企业ID的乘车码；并向POS端机具请求验证所述乘车码；

后台服务器，用于为企业端分配企业ID，并根据接收到POS端机具对所述乘车码的验证情况信息后完成扣款操作，还将扣款情况发送给企业端；

POS端机具，用于对用户终端展示的乘车码进行验证，验证通过后，将验证情况信息发送给后台服务器。

第四方面，基于同一发明构思，本发明实施例还提供一种企业端，包括：发码模块、费用管理模块，其中：

发码模块，用于接收来自用户终端的发码请求；生成包含企业ID的乘车码并反馈给用户终端；

费用管理模块，用于接收后台服务器基于POS端机具对所述乘车码的验证情况信息进行扣款后返回的扣款情况。

第五方面，基于同一发明构思，本发明实施例还提供一种用户终端包括：

判断模块，用于判断自身网络状况；

通信模块，用于在联网情况下发送发码请求及接收企业端生成的乘车码；

发码请求生成模块，用于生成发码请求；

存储模块，用于存储接收的乘车码；

显示模块，用于向POS端机具请求验证所述乘车码。

本发明实施例提供的上述技术方案的有益效果至少包括：

本发明将用户终端与企业端关联，在有支付需求时，企业端给用户终端发乘车码，员工只需将乘车码提供给POS端机具，后台服务器会对企业端账户进行扣款。当有报销需求时，企业端与后台服务器直接对接。整个差旅支付及后续报销都非常便捷，无需员工垫付车费，也不用每次索取发票，并且，员工乘车的记录也可以被监控，便于企业主实现对全员外勤状况的监督。本发明可以完全替代人工，极大提升了工作效率。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1为本发明实施例一中一种基于企业账户的乘车支付系统的结构示意图；

图2为本发明实施例一中一种基于企业账户的乘车支付系统的工作时序图；

图3为本发明实施例二中，另一种基于企业账户的乘车支付系统的工作时序图；

图4为本发明实施例三中一种基于企业账户的乘车支付方法的流程图；

图5为本发明图三中步骤S301为不同情况时基于企业账户的乘车支付方法的流程图；

图6为本发明实施例中一种企业端的结构示意图；

图7为本发明实施例四中，另一种基于企业账户的乘车支付方法的流程图；

图8为本发明实施例中一种用户终端的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为了解决现有技术中存在的报销差旅费用不智能、效率低的问题，本发明实施例提供一种基于企业账户的乘车支付方法。

实施例一

本发明实施例提供一种基于企业账户的乘车支付系统，该系统的结构示意图如图1所示，包括企业端10、用户终端20、后台服务器31、POS端机具32，其中：

企业端10，用于接收来自用户终端20的发码请求；生成包含企业ID的乘车码并反馈给用户终端20；并接收后台服务器31基于POS端机具32对所述乘车码的验证情况信息进行扣款后返回的扣款情况。

用户终端20，用于判断自身网络状况，若已联网，则发送发码请求给企业端10；接收企业端10发送的包含企业ID的乘车码；并向POS端机具32请求验证所述乘车码。

后台服务器31，用于为企业端10分配企业ID，并在接收到POS端机具32对所述乘车码的验证情况信息后完成扣款操作，还将扣款情况发送给企业端10。

POS端机具32，用于对用户终端20展示的乘车码进行验证，验证通过后，将验证情况信息发送给后台服务器31。

结合图2，该系统的工作过程如下：

步骤S101：企业端10与后台服务器31连接，完成信息注册及费用充值，后台服务器31为企业分配企业ID。

具体的，企业端10向后台服务器31提交企业名称、联系人、联系方式等基本信息，并完成费用充值。后台服务器31会为企业分配企业ID，后续乘车支付过程依据企业ID执行。后台服务器31的功能还包括清分结算，也可以认为是一种清分结算机构。

步骤S102：企业端10为用户分配用户ID。

分配用户ID的目的是为了帮助企业端10在乘车支付过程中能准确识别自己的员工，本申请不对用户ID的分配规则进行限制。比如，可以根据员工入职时间顺序分配用户ID，也可以根据企业组织架，设置与每个部门对应的用户ID。当然，为了更好的监督管理每个员工的差旅情况，优选为每个员工分配唯一的用户ID。

根据实际情况，可以调整步骤S101、S102的顺序。步骤S101、S102仅需执行一次，当需要乘车支付时，重复执行步骤S103-S106。

步骤S103：当需要乘车支付时，用户终端20判断自身网络状况，若已联网，执行步骤S104。

用户终端20可以为手机、IPAD等，其上安装的客户端软件可以为支付宝、微信等主流扫码支付软件，也可以是钉钉等可以实现关联支付的办公软件，还可以是定制化的软件，本发明实施例对此不做限制。

步骤S104：用户终端20发送包含用户ID的发码请求给企业端10，企业端10生成包含企业ID的乘车码反馈给用户终端20。

具体的，根据发码请求中的用户ID，企业端10判断接收的发码请求是否来源于本公司员工，若是，则生成乘车码并反馈给用户终端20，否则拒绝生成乘车码。乘车码的组成可以根据实际情况确定，但必须包含企业ID。

在一些情况下，如果企业端10认为向其发送发码请求的都是可信的用户终端20，则也可以不需要步骤S102，步骤S104中用户终端20也可以发送不包含用户ID的发码请求。但是从安全性、可监控性角度，建议企业端10为用户分配用户ID。

步骤S105：POS端机具32验证用户终端20示出的乘车码。

用户终端20展示乘车码，POS端机具32扫描该码，解析乘车码的内容，一般需要分离出身份信息并对身份信息进行验证，防止付款方示出的二维码为非乘车码。

步骤S106：验证通过后，POS端机具32将验证情况信息发送给后台服务器31进行扣款操作。

POS端机具32对乘车码的验证情况信息至少包括包括企业ID，如果需要监控员工差旅情况还需要用户ID。当然，验证情况信息还应该包括后台服务器31的结算程序所需要的一些参数，除了从乘车码里提取，还可以由POS端机具32产生。比如，对于地铁费用，需要根据记录的入站、出站地理位置计算票价；某些公交23时至凌晨5时的票价贵于其余时间段等等。相应的，POS端机具32发送的验证情况信息还应该包括站点信息、乘车线路信息、扫码支付的时间信息等。

步骤S107：后台服务器31将扣款情况发送给企业端10。

后台服务器31将扣款金额情况，比如用户ID、支付金额、支付时间甚至乘车线路等情况发送给企业端10。

实施例二

在另一些实施例中，相比于实施例一，企业端10还用于为员工配置乘车规则权益，以更好的管理员工差旅情况。当企业端10接收到用户终端20发送的发码请求后，先判断该员工的申请是否满足乘车规则权益，若满足才生成乘车码反馈给用户终端20。

用户终端20，用于接收用户支付申请时，判断自身网络状况，若已联网，则发送发码请求给企业端10，并接收企业端10发来的乘车码，若未联网，则查找预先存储缓存的包含企业ID的乘车码。

后台服务器31，用于为企业端10分配企业ID，并在接收到POS端机具32对所述乘车码的验证情况信息后完成扣款操作，还将扣款情况发送给企业端10。

POS端机具32，用于对用户终端20展示的乘车码进行验证，验证通过后，将验证情况信息发送给后台服务器31。

可以理解的，一般后台服务器31及POS端机具32一般都是分离的，都隶属于运营商，在一些特殊情况下，可能存在将后台服务器31与POS端机具32集成的情况。

结合图3所示出的本系统的时序图，该基于企业账户的乘车支付系统的工作过程如下：

步骤S201：企业端10与后台服务器31连接，完成信息注册及费用充值，后台服务器31为企业分配企业ID。

步骤S202：企业端10为用户分配用户ID并配置乘车规则权益。

为了更好的监督管理每个员工的差旅情况，优选为每个员工分配唯一的用户ID。

配置乘车规则权益包括对员工的乘次数、乘车时间、乘车金额等方面进行限制，这样可以更好的管理员工差旅情况。比如，设置每个员工每月可乘车次数上限，某个员工乘车超过该上限后，当月无法再乘车。又或者员工的乘车时间设置为工作日，不允许在节假日乘车。再比如，设置单次消费金额的上限。

步骤S201、S202仅需执行一次，当需要乘车支付时，重复执行步骤S203-S208。

步骤S203：有乘车支付需求时，用户终端20判断自身网络状况，若已联网，执行步骤S204，否则，执行步骤S205。

步骤S204：用户终端20发送包含用户ID的发码请求给企业端10，企业端10判断当前员工是否满足乘车规则权益，若满足，则生成包含企业ID的乘车码反馈给用户终端20。

具体的，企业端10根据发码请求中的用户ID判断接收的发码请求是否来源于本公司员工，若是，则根据步骤S202中配置的乘车规则权益判断员工是否满足条件，若满足则生成乘车码并反馈给用户终端20，否则拒绝生成乘车码。比如，某员工月乘车金额上限为200元，企业端10统计的该员工本月截止到当前的乘车总金额为100元，则本次还允许员工乘车，于是生成包含企业ID的乘车码发送给用户终端20。

对于步骤S204，乘车码的结构不做限制，可以根据实际情况确定，但必须包含企业ID，表1示出一种乘车码的部分结构内容。

在表1示出的实施例中，同一个员工不同的乘车码之间一般主要有2个字段不同：(1)二维码生成时间，会在生码时将当前的时间(离线时也能获取手机的时间)填到乘车码的字段中再生码。(2)支付账户用户私钥签名即企业端10的用户私钥签名，这个是用于验证乘车码是否有效的关键，每个码的该字段都不一样。

表1

步骤S205：使用本地预先存储的包含企业ID的乘车码。

为了防止用户终端20处于无网状态时无法支付，可以预先缓存一些乘车码，当用户终端20发现缓存的乘车码用完或超过了如表1中二维码有效时间而失效后，则在联网状态时向企业端10发送发码请求，并接收企业端10反馈的乘车码。

步骤S206：POS端机具32验证用户终端20示出的乘车码。

用户终端20展示乘车码，POS端机具32扫描该码，解析乘车码的内容，一般需要分离出身份信息并对身份信息进行验证，比如对表1中支付账户用户私钥签名进行验证。

步骤S207：验证通过后，POS端机具32将验证情况信息发送给后台服务器31进行扣款操作。

步骤S208：后台服务器31将扣款情况发送给企业端10。

验证通过后，后台服务器31计算需要支付的金额完成扣款，并将扣款金额情况，比如用户ID、金额、支付时间甚至车次、线路等情况发送给企业端10，企业端10结合乘车规则权益的具体要求对员工差旅情况做好记录。

对于步骤S204：用户终端20发送包含用户ID的发码请求给企业端10，企业端10还可以先判断当前企业账户余额是否达到阈值，若达到则拒绝生成乘车码；(当然，也可以先生成乘车码并反馈给用户终端20；而后提醒企业账户充值，当充值成功后再进行扣款。)若还未达到，则再判断当前员工是否满足乘车规则权益，若满足，则生成包含企业ID的乘车码反馈给用户终端20。

对于本申请，无论POS端机具32是否联网，都能完成对乘车码的验证，但只有在联网情况下，POS端机具32将验证情况信息发送给后台服务器31进行扣款操作。本系统将用户终端20与企业端10关联，在有支付需求时，企业端10给用户终端20发乘车码，员工只需将乘车码提供给POS端机具31，后台服务器32会对企业端10账户进行扣款。当有报销需求时，企业端10与后台服务器32直接对接。整个差旅支付及后续报销都非常便捷，无需员工垫付车费，也不用每次索取发票，并且，员工乘车的记录也可以被监控，便于企业主实现对全员外勤状况的监督。本发明可以完全替代人工，极大提升了工作效率。

实施例三

基于同一发明构思，本发明实施例还提供一种基于企业账户的乘车支付方法，如图4所示，该乘车支付方法包括以下步骤：

步骤S301：企业端10接收来自用户终端20的发码请求。

步骤S302：生成包含企业ID的乘车码并反馈给用户终端20。

其中，发码请求包含企业端10预先为用户分配的用户ID。另外，生成包含企业ID的乘车码之前，还包括：企业端10根据所述用户ID对用户身份进行合法性验证，当验证用户身份合法后再执行生成乘车码的步骤。

步骤S303：企业端10接收后台服务器31基于POS端机对所述乘车码的验证情况信息进行扣款后返回的扣款情况。

在步骤S301之前需要进行一些初始化步骤，步骤S300包括：企业端10预先与后台服务器31连接，完成信息注册及费用充值，并接受后台服务器31分配的企业ID。步骤S300仅需执行一次，当需要乘车支付时，重复执行步骤S301-S303。

结合图5所示，对于步骤S301还包括以下步骤：

步骤S301A,企业端10接收来自用户终端20的发码请求,判断当前用户是否满足预设的乘车规则权益，若满足，则执行步骤S302。乘车规则权益包括用户的乘车次数限制、乘车时间限制、乘车金额限制等。

或者，S301B,企业端10接收来自用户终端20的发码请求,判断当前企业账户余额是否达到预设的阈值，若还未达到，则再判断当前用户是否满足预设的乘车规则权益，若满足，则执行步骤S302。

相应的，本发明实施例还提供一种用于执行上述基于企业账户的乘车支付方法的企业端10，如图6所示，该企业端10包括：发码模块12、费用管理模块13，其中：

发码模块12，用于接收来自用户终端20的发码请求；生成包含企业ID的乘车码并反馈给用户终端20。

费用管理模块13，用于接收后台服务器31基于POS端机具32对所述乘车码的验证情况信息进行扣款后返回的扣款情况。

可以理解的，企业端10还包括用户中心11，用户中心11用于向后台服务器31注册后获得企业ID，管理企业用户信息，为用户分配用户ID、设置乘车规则权益。费用管理模块13还用于预先向后台服务器31内充值，并接收后台服务器31设置的账户余额阈值。

关于上述实施例中的企业端10，其具体工作方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

实施例四

基于同一发明构思，本发明实施例还提供一种基于企业账户的乘车支付方法，如图7所示，该乘车支付方法包括以下步骤：

步骤S401：用户终端20判断自身网络状况，若已联网，则执行步骤S402，否则，执行步骤S403。

步骤S402：发送发码请求给企业端10，接收企业端10发送的包含企业ID的乘车码。

发码请求包含企业端10预先为用户分配的用户ID。乘车码为企业端10基于用户ID验证用户身份合法后生成的。

步骤S403：查找本地预先缓存的包含企业ID的乘车码。

步骤S404：用户终端20向POS端机具32请求验证乘车码。

其中，对于步骤S401，用户终端20判断自身网络状态之前还包括：用户终端20先判断自身是否满足乘车规则权益，若满足则再判断自身网络状况；相应的，在用户终端20判断自身网络状态之前还包括接收企业端10预先设置并发送而来的乘车规则权益的步骤。

对于步骤S403，查找本地预先缓存的包含企业ID的乘车码时，用户终端20还需判断是否还有预先缓存的乘车码或其是否已失效，若预先缓存的乘车码已用完或失效后，则需要在联网状态时向企业端10发送发码请求，并接收企业端10反馈的乘车码。

相应的，本发明实施例还提供一种用于执行上述基于企业账户的乘车支付方法的用户终端20，如图8所示，该用户终端20包括：

判断模块21，用于判断自身网络状况。

通信模块22，用于在联网情况下发送发码请求及接收企业端10生成的乘车码。

发码请求生成模块23，用于生成发码请求，该发码请求至少包括用户ID。

存储模块24，用于存储接收的乘车码。存储模块24还用于接收企业端10分配的用户ID。

显示模块25，用于向POS端机具32请求验证所述乘车码。

在一些实施例中，存储模块24保存的乘车码包括根据当此支付需求发送的发码请求产生的乘车码，以及预先存储的乘车码，当判断模块21判断用户终端20未联网时，就调用存储模块24中预先存储的乘车码供POS端机具32扫描。

关于上述实施例中的用户终端20，其具体工作方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

应该明白，公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好，应该理解，过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素，并且不是要限于所述的特定顺序或层次。

在上述的详细描述中，各种特征一起组合在单个的实施方案中，以简化本公开。不应该将这种公开方法解释为反映了这样的意图，即，所要求保护的主题的实施方案需要清楚地在每个权利要求中所陈述的特征更多的特征。相反，如所附的权利要求书所反映的那样，本发明处于比所公开的单个实施方案的全部特征少的状态。因此，所附的权利要求书特此清楚地被并入详细描述中，其中每项权利要求独自作为本发明单独的优选实施方案。

本领域技术人员还应当理解，结合本文的实施例描述的各种说明性的逻辑框、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或其组合。为了清楚地说明硬件和软件之间的可交换性，上面对各种说明性的部件、框、模块、电路和步骤均围绕其功能进行了一般地描述。至于这种功能是实现成硬件还是实现成软件，取决于特定的应用和对整个系统所施加的设计约束条件。熟练的技术人员可以针对每个特定应用，以变通的方式实现所描述的功能，但是，这种实现决策不应解释为背离本公开的保护范围。

结合本文的实施例所描述的方法或者算法的步骤可直接体现为硬件、由处理器执行的软件模块或其组合。软件模块可以位于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动磁盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质连接至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。该ASIC可以位于用户终端中。当然，处理器和存储介质也可以作为分立组件存在于用户终端中。

对于软件实现，本申请中描述的技术可用执行本申请所述功能的模块(例如，过程、函数等)来实现。这些软件代码可以存储在存储器单元并由处理器执行。存储器单元可以实现在处理器内，也可以实现在处理器外，在后一种情况下，它经由各种手段以通信方式耦合到处理器，这些都是本领域中所公知的。

上文的描述包括一个或多个实施例的举例。当然，为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的，但是本领域普通技术人员应该认识到，各个实施例可以做进一步的组合和排列。因此，本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外，就说明书或权利要求书中使用的术语“包含”，该词的涵盖方式类似于术语“包括”，就如同“包括，”在权利要求中用作衔接词所解释的那样。此外，使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。

Claims (24)

1.一种基于企业账户的乘车支付方法，其特征在于，包括以下步骤：

企业端接收来自用户终端的发码请求；

生成包含企业ID的乘车码并反馈给用户终端；

企业端接收后台服务器基于POS端机具对所述乘车码的验证情况信息进行扣款后返回的扣款情况。

2.如权利要求1所述的乘车支付方法，其特征在于，所述发码请求包含企业端预先为用户分配的用户ID；相应的，所述生成包含企业ID的乘车码之前，还包括：

企业端根据所述用户ID对用户身份进行合法性验证，当验证用户身份合法后再执行生成乘车码的步骤。

3.如权利要求1所述的乘车支付方法，其特征在于，所述企业端接收来自用户终端的发码请求后还包括：判断当前用户是否满足预设的乘车规则权益，若满足，则生成乘车码。

4.如权利要求1所述的乘车支付方法，其特征在于，所述企业端接收来自用户终端的发码请求后还包括：判断当前企业账户余额是否达到预设的阈值，若还未达到，则再判断当前用户是否满足乘车规则权益，若满足，则生成乘车码。

5.如权利要求3或4所述的乘车支付方法，其特征在于，所述乘车规则权益包括用户的乘车次数限制、乘车时间限制、乘车金额限制。

6.如权利要求1所述的乘车支付方法，其特征在于，该乘车支付方法还包括初始化步骤，包括：企业端预先与后台服务器连接，完成信息注册及费用充值，并接受后台服务器分配的企业ID。

7.一种基于企业账户的乘车支付方法，其特征在于，包括以下步骤：

用户终端判断自身网络状况，若已联网，则发送发码请求给企业端；

接收企业端发送的包含企业ID的乘车码；

用户终端向POS端机具请求验证所述乘车码。

8.如权利要求7所述的乘车支付方法，其特征在于，所述发码请求包含企业端预先为用户分配的用户ID，所述乘车码为企业端基于用户ID验证用户身份合法后生成的。

9.如权利要求7所述的乘车支付方法，其特征在于，用户终端判断自身网络状况还包括：未联网时，向POS端机具请求验证本地预先缓存的包含企业ID的乘车码。

10.如权利要求9所述的乘车支付方法，其特征在于，向POS端机具请求验证本地预先缓存的包含企业ID的乘车码之前还包括：用户终端判断本地是否还有预先缓存的乘车码或预先缓存的乘车码是否失效，若预先缓存的乘车码已用完或失效后，则在联网状态时向企业端发送发码请求，并接收企业端反馈的乘车码。

11.如权利要求8所述的乘车支付方法，其特征在于，用户终端判断自身网络状态之前还包括：用户终端先判断自身是否满足乘车规则权益，若满足则再判断自身网络状况；相应的，在用户终端判断自身网络状态之前还包括接收企业端预先设置并发送而来的乘车规则权益的步骤。

12.一种基于企业账户的乘车支付系统，其特征在于，该系统包括企业端、用户终端、POS端机具、后台服务器，其中：

企业端，用于接收来自用户终端的发码请求；生成包含企业ID的乘车码并反馈给用户终端；并接收后台服务器基于POS端机具对所述乘车码的验证情况信息进行扣款后返回的扣款情况；

用户终端，用于判断自身网络状况，若已联网，则发送发码请求给企业端；接收企业端发送的包含企业ID的乘车码；并向POS端机具请求验证所述乘车码；

后台服务器，用于为企业端分配企业ID，并根据接收到POS端机具对所述乘车码的验证情况信息后完成扣款操作，还将扣款情况发送给企业端；

POS端机具，用于对用户终端展示的乘车码进行验证，验证通过后，将验证情况信息发送给后台服务器。

13.如权利要求12所述的乘车支付系统，其特征在于，所述用户终端发送的发码请求包含企业端预先为用户分配的用户ID，所述企业端生成的乘车码为企业端基于用户ID验证用户身份合法后生成的。

14.如权利要求12所述的乘车支付系统，其特征在于，所述企业端还用于接收来自用户终端的发码请求后，判断当前用户是否满足预设的乘车规则权益，若满足，则生成乘车码。

15.如权利要求12所述的乘车支付系统，其特征在于，所述企业端还用于接收来自用户终端的发码请求后，判断当前企业账户余额是否达到预设的阈值，若还未达到，则再判断当前用户是否满足乘车规则权益，若满足，则生成乘车码。

16.如权利要求14所述的乘车支付系统，其特征在于，所述企业端预设的乘车规则权益包括用户的乘车次数限制、乘车时间限制、乘车金额限制。

17.如权利要求12所述的乘车支付系统，其特征在于，所述企业端还用于预先与后台服务器连接，完成信息注册及费用充值，并接受后台服务器分配的企业ID。

18.如权利要求12所述的乘车支付系统，其特征在于，所述用户终端还用于当判断自身网络状况未联网时，向POS端机具请求验证本地预先缓存的包含企业ID的乘车码。

19.如权利要求18所述的乘车支付系统，其特征在于，所述用户终端还用于发现本地预先缓存的乘车码用完或失效后，在联网状态时向企业端发送发码请求，并接收企业端反馈的乘车码。

20.如权利要求12所述的乘车支付系统，其特征在于，所述用户终端判断自身是否满足乘车规则权益，若满足则再判断自身网络状况，所述乘车规则权益由企业端预先设置并发送给所述用户终端。

21.一种企业端，其特征在于，所述企业端包括：发码模块、费用管理模块，其中：

发码模块，用于接收来自用户终端的发码请求；生成包含企业ID的乘车码并反馈给用户终端；

费用管理模块，用于接收后台服务器基于POS端机具对所述乘车码的验证情况信息进行扣款后返回的扣款情况。

22.如权利要求21所述的企业端，其特征在于，所述企业端还包括用户中心，所述用户中心用于向后台服务器注册后获得企业ID，管理企业用户信息，为用户分配用户ID，所述费用管理模块还用于预先向后台服务器内充值。

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

判断模块，用于判断自身网络状况；

通信模块，用于在联网情况下发送发码请求及接收企业端生成的乘车码；

发码请求生成模块，用于生成发码请求；

存储模块，用于存储接收的乘车码；

显示模块，用于向POS端机具请求验证所述乘车码。

24.如权利要求23所述的用户终端，其特征在于，所述存储模块，用于接收企业端分配的用户ID，所述发码请求生成模块生成的发码请求至少包括用户ID。

Images