阅读说明：本技术 基于信用度的乘车支付方法、装置、电子设备及存储介质 (Bus taking payment method and device based on credit degree, electronic equipment and storage medium ) 是由 刘家凯 于 2019-10-21 设计创作，主要内容包括：本发明实施例提供了一种基于信用度的乘车支付方法、装置、电子设备及存储介质；其中,方法包括：响应于针对虚拟乘车卡的开通指令,呈现用于授权对应所述虚拟乘车卡的支付方式的支付授权按键；响应于基于所述支付授权按键触发的授权指令,获取所述虚拟乘车卡关联的目标用户的信用度；基于所述目标用户的信用度,为所述虚拟乘车卡分配相应的支付金额；响应于通过近场通信连接发送的第一支付订单,从所述支付金额中扣除对应所述第一支付订单的订单金额；基于所述订单金额,发送第二支付订单至所述支付方式对应的支付端,以基于所述第二支付订单,从关联的所述目标用户的支付账户中扣除所述订单金额。(The embodiment of the invention provides a riding payment method and device based on credit, electronic equipment and a storage medium; the method comprises the following steps: responding to a starting instruction aiming at the virtual bus taking card, and presenting a payment authorization key for authorizing a payment mode corresponding to the virtual bus taking card; responding to an authorization instruction triggered based on the payment authorization key, and acquiring the credit degree of a target user associated with the virtual riding card; distributing corresponding payment amount to the virtual riding card based on the credit degree of the target user; in response to a first payment order sent through a near field communication connection, deducting an order amount corresponding to the first payment order from the payment amount; and sending a second payment order to the payment terminal corresponding to the payment mode based on the order amount, and deducting the order amount from the associated payment account of the target user based on the second payment order.)

基于信用度的乘车支付方法、装置、电子设备及存储介质

技术领域

本发明涉及通信技术及区块链技术，尤其涉及一种基于信用度的乘车支付方法、装置、电子设备及存储介质。

背景技术

随着互联网技术的发展，用户乘车(如公交车、地铁)出行多采用实体乘车卡进行乘车支付，用户通过在刷卡设备上刷卡完成乘车支付，实体乘车卡的存在大大方便了用户的出行。

相关技术中，实体乘车卡在使用前需要有足够支付乘车费用的余额，用户需要为实体乘车卡提前充值，而为实体乘车卡充值用户需要去到专门的充值点或手动通过手机为实体乘车卡充值，操作繁琐，在用户忘记提前充值的情况下，影响用户的乘车，用户体验低。

发明内容

本发明实施例提供一种基于信用度的乘车支付方法、装置、电子设备及存储介质，能够为用户带来先乘车后付费的体验，降低用户乘车所需的时间成本及操作成本。

本发明实施例的技术方案是这样实现的：

本发明实施例提供一种基于信用度的乘车支付方法，所述方法包括：

响应于针对虚拟乘车卡的开通指令，呈现用于授权对应所述虚拟乘车卡的支付方式的支付授权按键；

响应于基于所述支付授权按键触发的授权指令，获取所述虚拟乘车卡关联的目标用户的信用度；

基于所述目标用户的信用度，为所述虚拟乘车卡分配相应的支付金额；

响应于通过近场通信连接发送的第一支付订单，从所述支付金额中扣除对应所述第一支付订单的订单金额；

基于所述订单金额，发送第二支付订单至所述支付方式对应的支付端，以基于所述第二支付订单，从关联的所述目标用户的支付账户中扣除所述订单金额。

本发明实施例还提供一种基于信用度的乘车支付装置，包括：

显示模块，用于响应于针对虚拟乘车卡的开通指令，呈现用于授权对应所述虚拟乘车卡的支付方式的支付授权按键；

获取模块，用于响应于基于所述支付授权按键触发的授权指令，获取所述虚拟乘车卡关联的目标用户的信用度；

分配模块，用于基于所述目标用户的信用度，为所述虚拟乘车卡分配相应的支付金额；

支付模块，用于响应于通过近场通信连接发送的第一支付订单，从所述支付金额中扣除对应所述第一支付订单的订单金额；

发送模块，用于基于所述订单金额，发送第二支付订单至所述支付方式对应的支付端，以基于所述第二支付订单，从关联的所述目标用户的支付账户中扣除所述订单金额。

上述方案中，所述装置还包括关联模块；

所述显示模块，还用于呈现对应所述支付方式的支付规则，以及用于确定所述支付方式的确定功能项；

所述关联模块，用于响应于根据所述支付规则触发的针对所述确定功能项的操作指令，关联所述虚拟乘车卡与对应所述支付方式的支付端。

上述方案中，所述获取模块，还用于发送对应所述目标用户的信用度获取请求；

接收返回的用于表征所述目标用户的信用度的信用评分。

上述方案中，所述获取模块，还用于通过子应用程序，发送所述信用度获取请求至运行所述子应用程序的母应用程序。

上述方案中，所述分配模块，还用于基于所述目标用户的信用度、信用度与支付额度的映射关系，确定所述虚拟乘车卡的支付额度；

基于所述虚拟乘车卡的支付额度，为所述虚拟乘车卡分配相应的支付金额。

上述方案中，所述显示模块，还用于在视图界面中呈现包含乘车卡***的所述虚拟乘车卡，所述乘车卡***用于标识所述虚拟乘车卡，指示所述虚拟乘车卡开通成功。

上述方案中，所述显示模块，还用于通过弹窗，呈现所述虚拟乘车卡对应的刷卡信息和/或支付信息。

上述方案中，所述获取模块，还用于发送包含所述订单金额的对应所述虚拟乘车卡的刷卡记录；

接收返回的基于所述刷卡记录生成的所述第二支付订单，所述第二支付订单对应的支付金额与所述订单金额相同。

上述方案中，所述装置还包括：

充值模块，用于接收对应所述第二支付订单的支付成功消息；

基于所述支付成功消息，为所述虚拟乘车卡充值，使得所述虚拟乘车卡的余额与所述支付金额相同。

上述方案中，所述支付模块，还用于响应于通过近场通信连接发送的第三支付订单，获取所述虚拟乘车卡的余额；

所述显示模块，还用于当所述余额小于所述第三支付订单的订单金额时，呈现提示余额不足的提示消息。

上述方案中，所述获取模块，还用于获取更新的所述目标用户的信用度；

所述分配模块，还用于基于更新的所述目标用户的信用度，调整为所述虚拟乘车卡分配的支付金额。

上述方案中，所述装置还包括检测模块；

所述检测模块，用于检测近场通信接口，得到检测结果；

所述显示模块，还用于当所述检测结果表征检测到近场通信接口时，呈现用于授权对应所述虚拟乘车卡的支付方式的支付授权按键。

上述方案中，所述装置还包括：

存储模块，用于对所述第二支付订单进行哈希处理，得到所述第二支付订单的摘要；

存储所述第二支付订单的摘要至区块链网络。

本发明实施例还提供一种电子设备，包括：

存储器，用于存储可执行程序；

处理器，用于执行所述存储器中存储的可执行程序时，实现本发明实施例提供的基于信用度的乘车支付方法。

本发明实施例还提供一种存储介质，存储有可执行程序，所述可执行程序被处理器执行时，实现本发明实施例提供的基于信用度的乘车支付方法。

应用本发明上述实施例具有以下有益效果：

基于用户的信用度为用户的虚拟乘车卡分配相应的支付金额，在用户乘车后，首先从分配的支付金额中扣除相应的乘车费用，之后再从用户的支付账户中扣除该乘车费用，为用户带来先乘车后付费的体验，同时，由于用户无需为虚拟乘车卡充值，大大降低了用户乘车所需的时间成本及人力成本，提高用户的乘车体验。

附图说明

图1A至图1G为相关技术提供的通过手机为实体乘车卡充值的界面视图；

图2A至图2H为相关技术提供的通过乘车码实现乘车支付的界面视图；

图3为本发明实施例提供的基于信用度的乘车支付系统的一个可选的架构示意图；

图4是本发明实施例提供的电子设备400的结构示意图；

图5A为本发明实施例提供的客户端运行小程序的一个可选的系统架构示意图；

图5B为本发明实施例提供的在客户端中显示小程序页面的示意图；

图6为本发明实施例提供的基于信用度的乘车支付方法的流程示意图；

图7A至图7G为本发明实施例提供的基于信用度的乘车支付的界面视图；

图8为本发明实施例提供的区块链网络的应用架构示意图；

图9是本发明实施例提供的区块链网络80中区块链的结构示意图；

图10为本发明实施例提供的区块链网络80的功能架构示意图；

图11为本发明实施例提供的开通虚拟乘车卡的方法流程示意图；

图12A及图12B为本发明实施例提供的开通虚拟乘车卡的方法流程示意图；

图13A及图13B为本发明实施例提供的使用虚拟乘车卡的方法流程示意图；

图14为本发明实施例提供的基于信用度的乘车支付装置的组成结构示意图。

具体实施方式

以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所提供的实施例仅仅用以解释本发明，并不用于限定本发明。另外，以下所提供的实施例是用于实施本发明的部分实施例，而非提供实施本发明的全部实施例，在不冲突的情况下，本发明实施例记载的技术方案可以任意组合的方式实施。

需要说明的是，在本发明实施例中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的方法或者装置不仅包括所明确记载的要素，而且还包括没有明确列出的其他要素，或者是还包括为实施方法或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的方法或者装置中还存在另外的相关要素(例如方法中的步骤或者装置中的单元，例如的单元可以是部分电路、部分处理器、部分程序或软件等等)。

例如，本发明实施例提供的网页处理方法包含了一系列的步骤，但是本发明实施例提供的网页处理方法不限于所记载的步骤，同样地，本发明实施例提供的网页处理装置包括了一系列单元，但是本发明实施例提供的装置不限于包括所明确记载的单元，还可以包括为获取相关信息、或基于信息进行处理时所需要设置的单元。

对本发明进行进一步详细说明之前，对本发明实施例中涉及的名词和术语进行说明，本发明实施例中涉及的名词和术语适用于如下的解释。

1)母应用程序，例如各种客户端，包括终端中运行的用于提供各种服务的应用程序，典型地，以微信为代表的即时通信客户端。

2)子应用程序，在母应用中程序中运行的程序，例如小程序，小程序是基于面向前端的语言(例如JavaScript)开发的、在超文本标记语言(HTML，Hyper Text MarkupLanguage)页面中实现服务的程序，通过客户端下载后可以立即在客户端中解释执行，节省在客户端中安装的步骤。

3)交易(Transaction)，等同于计算机术语“事务”，交易包括了需要提交到区块链网络执行的操作，并非单指商业语境中的交易，鉴于在区块链技术中约定俗成地使用了“交易”这一术语，本发明实施例遵循了这一习惯。

例如，部署(Deploy)交易用于向区块链网络中的节点安装指定的智能合约并准备好被调用；调用(Invoke)交易用于通过调用智能合约在区块链中追加交易的记录，并对区块链的状态数据库进行操作，包括更新操作(包括增加、删除和修改状态数据库中的键值对)和查询操作(即查询状态数据库中的键值对)。

4)区块链(Blockchain)，是由区块(Block)形成的加密的、链式的交易的存储结构。

5)区块链网络(Blockchain Network)，通过共识的方式将新区块纳入区块链的一系列的节点的集合。

6)账本(Ledger)，是区块链(也称为账本数据)和与区块链同步的状态数据库的统称。其中，区块链是以文件系统中的文件的形式来记录交易；状态数据库是以不同类型的键(Key)值(Value)对的形式来记录区块链中的交易，用于支持对区块链中交易的快速查询。

7)智能合约(Smart Contracts)，也称为链码(Chaincode)或应用代码，部署在区块链网络的节点中的程序，节点执行接收的交易中所调用的智能合约，来对状态数据库的键值对数据进行更新或查询的操作。

8)共识(Consensus)，是区块链网络中的一个过程，用于在涉及的多个节点之间对区块中的交易达成一致，达成一致的区块将被追加到区块链的尾部，实现共识的机制包括工作量证明(PoW，Proof of Work)、权益证明(PoS，Proof of Stake)、股份授权证明(DPoS，Delegated Proof-of-Stake)、消逝时间量证明(PoET，Proof of Elapsed Time)等。

9)响应于，用于表示所执行的操作所依赖的条件或者状态，当满足所依赖的条件或状态时，所执行的一个或多个操作可以是实时的，也可以具有设定的延迟；在没有特别说明的情况下，所执行的多个操作不存在执行先后顺序的限制。

相关技术中，用户乘车出行采用实体乘车卡进行乘车支付，为了不影响正常使用，用户需要为实体乘车卡提前充值，图1A至图1G为相关技术提供的通过手机为实体乘车卡充值的界面视图，结合图1A至图1G对实体乘车卡充值的流程进行说明。

首先，在呈现有近场通信(NFC，Near Field Communication)按键的视图界面(即图1A所示)上，用户点击NFC按键触发手机跳转至NFC功能的设置界面(即图1B所示)，用户点击开启NFC功能对应的功能开关触发NFC功能的开启；用户将实体乘车卡靠近手机，如将实体乘车卡贴在手机背面，以实现近场通信，手机所呈现的页面跳转至充值界面(即图1C所示)，用户选择充值额度，之后页面跳转至支付页面，用户采用关联的支付方式完成付款后，通过近场通信对实体乘车卡进行数据写入，完成充值。

上述对实体乘车卡充值的方式，需要用户手动操作，流程复杂，操作时间久，在用户忘记提前充值的情况下，影响用户的乘车，用户体验低。

相关技术中，用户乘车出行还可通过乘车码小程序，通过乘车码进行乘车支付，图2A至图2H为相关技术提供的通过乘车码实现乘车支付的界面视图，将结合图2A至图2H对采用乘车码实现乘车支付的流程进行说明。

用户打开客户端(母应用程序)，通过客户端的搜索功能搜索“乘车码”小程序(子应用程序)，用户从搜索到的呈现的小程序中选择乘车码小程序，呈现对应所选乘车码小程序的视图界面(即图2B所示)，用户点击视图界面中“去乘车”按键，触发乘车码的开通，页面跳转至乘车码的开通界面(即图2C所示)，用户点击“开通乘车码”触发对于乘车码的开通指令，页面跳转至支付授权界面(即图2D所示)，通过该界面开通免密支付，用户可选定扣费方式，当开通免密支付后，用户基于乘车码支付时，通过具备扫码功能的计费设备扫码实现乘车支付，支付过程中通过用户选定的扣费方式从关联的账户中扣除相应的乘车费用。

上述采用乘车码实现乘车支付的方式，需要对相关技术中的刷卡设备(闸机)进行改造，使其具备扫码功能，然而，对刷卡设备改造需要消耗大量的人力、物力，成本极高。

基于此，提出本发明实施例的基于信用度的乘车支付方法、装置、电子设备、系统及存储介质，以至少解决相关技术中的上述问题，接下来分别进行说明。

图3为本发明实施例提供的基于信用度的乘车支付系统的一个可选的架构示意图，参见图3，为实现支撑一个示例性应用，终端(包括终端400-1和终端400-2)通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合，使用无线或有线链路实现数据传输。

终端(如终端400-1)，用于响应于用户触发的虚拟乘车卡的开通指令，呈现用于授权对应虚拟乘车卡的支付方式的支付授权按键；当用户基于支付授权按键触发的授权指令时，终端发送虚拟乘车卡关联的目标用户的信用度获取请求给服务器200，以获取虚拟乘车卡关联的目标用户的信用度；

服务器200，用于基于接收的信用度获取请求，在数据库查询目标用户的信用度，并返回目标用户的信用度给终端；

终端(如终端400-1)，还用于通过近场通信连接接收刷卡设备发送的第一支付订单，从虚拟乘车卡的支付金额中，扣除对述第一支付订单的订单金额；

终端(如终端400-1)，还用于基于订单金额，发送第二支付订单至支付方式对应的支付端，以基于第二支付订单，从关联的目标用户的支付账户中扣除该订单金额。

在实际应用中，服务器200既可以为单独配置的支持各种业务的一个服务器，亦可以配置为一个服务器集群；终端可以为智能手机、平板电脑、笔记本电脑等各种类型的用户终端，还可以为可穿戴计算设备、个人数字助理(PDA)、台式计算机、蜂窝电话、媒体播放器、导航设备、游戏机、电视机、或者这些数据处理设备或其他数据处理设备中任意两个或多个的组合。

接下来下面对实施本发明实施例的基于信用度的乘车支付方法的电子设备进行说明。在一些实施例中，电子设备可以为终端，还可以为服务器。参见图4，图4是本发明实施例提供的电子设备400的结构示意图，图4所示的电子设备400包括：处理器410、存储器450、网络接口420和用户接口430。电子设备400中的各个组件通过总线系统440耦合在一起。可理解，总线系统440用于实现这些组件之间的连接通信。总线系统440除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图4中将各种总线都标为总线系统440。

处理器410可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

用户接口430包括使得能够呈现媒体内容的一个或多个输出装置431，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口430还包括一个或多个输入装置432，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。

存储器450可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器450可选地包括在物理位置上远离处理器410的一个或多个存储设备。

存储器450包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本发明实施例描述的存储器450旨在包括任意适合类型的存储器。

在一些实施例中，存储器450能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统451，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块452，用于经由一个或多个(有线或无线)网络接口420到达其他计算设备，示例性的网络接口420包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；

呈现模块453，用于经由一个或多个与用户接口430相关联的输出装置431(例如，显示屏、扬声器等)使得能够呈现信息(例如，用于操作***设备和显示内容和信息的用户接口)；

输入处理模块454，用于对一个或多个来自一个或多个输入装置432之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。

在一些实施例中，本发明实施例提供的基于信用度的乘车支付装置可以采用软件方式实现，图4示出了存储在存储器450中的基于信用度的乘车支付装置455，其可以是程序和插件等形式的软件，包括以下软件模块：显示模块4551、获取模块4552、分配模块4553、支付模块4554及发送模块4555，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分，将在下文中说明各个模块的功能。

在另一些实施例中，本发明实施例提供的基于信用度的乘车支付装置可以采用硬件方式实现，作为示例，本发明实施例提供的基于信用度的乘车支付装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本发明实施例提供的基于信用度的乘车支付方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，ProgrammableLogic Device)、复杂可编程逻辑器件(CPLD，Complex Programmable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable Gate Array)或其他电子元件。

基于上述对本发明实施例的基于信用度的乘车支付系统及电子设备的说明，在对本发明实施例提供的基于信用度的乘车支付方法进行说明之前，首先对本发明实施例中涉及的母应用程序及子应用程序进行说明。

以母应用程序为客户端、子应用程序为小程序为例，图5A为本发明实施例提供的客户端运行小程序的一个可选的系统架构示意图，图5B为本发明实施例提供的在客户端中显示小程序页面的示意图，结合图5A及图5B，设置于终端20中的客户端11(如微信客户端WeChat)在首次运行小程序时，需要下载小程序，发送初始化请求给小程序的服务器来下载小程序，为了提高下载速度，请求可以被重定向至内容分发网络13(CDN，Content DeliveryNetwork)，从内容分发网络13中合适的节点服务器(例如基于链路最短条件、负载均衡条件等选择节点服务器)上，由内容分发网络13代替小程序的服务器向客户端11发送小程序的数据包(Package)，即所述小程序的源代码，从而实现小程序的下载；客户端对小程序初始化完成后，通过解释小程序的代码来进行小程序页面的加载，小程序通过发送数据请求给服务器12，以获取页面显示及页面更新所需的JSON数据，进而小程序根据获取的JSON数据进行页面渲染，实现小程序在客户端中的页面显示/更新。

基于上述对母应用程序及子应用程序的说明，接下来对本发明实施例提供的基于信用度的乘车支付方法进行说明。图6为本发明实施例提供的基于信用度的乘车支付方法的流程示意图，图7A至图7G为本发明实施例提供的基于信用度的乘车支付的界面视图；在一些实施例中，该基于信用度的乘车支付方法可由终端实施，或由服务器及终端协同实施，以终端实施为例，如通过图3中的终端400-1实施，将结合图3、图6、图7A至图7G，对本发明实施例提供的基于信用度的乘车支付方法进行说明。

步骤601：终端响应于针对虚拟乘车卡的开通指令，呈现用于授权对应虚拟乘车卡的支付方式的支付授权按键。

这里，在实际实施时，由于基于虚拟乘车卡进行乘车支付需要终端具备NFC功能，因此，在开通虚拟乘车卡之前需要对终端的NFC功能进行检测，以判断终端是否具备NFC功能，具体地，终端检测近场通信接口，得到检测结果，当检测结果表征检测到近场通信接口时，视为终端具备NFC功能，进而可在接收到针对虚拟乘车卡的开通指令时，呈现用于授权对应虚拟乘车卡的支付方式的支付授权按键。

在一些实施例中，终端上设置有虚拟乘车卡客户端，终端通过运行虚拟乘车卡客户端，呈现包括一个或多个虚拟乘车卡的开通界面，用户选择想要开通的虚拟乘车卡，通过针对所选虚拟乘车卡的点击操作，触发针对该虚拟乘车卡的开通指令，在支付授权界面，呈现用于授权对应虚拟乘车卡的支付方式的支付授权按键。

这里，虚拟乘车卡为在具备NFC功能的终端上实现实体乘车卡模拟，实现手机内置乘车卡的功能。

在另一些实施例中，终端上设置有母应用程序，如即时通信客户端，通过母应用程序提供的小程序搜索功能，搜索“乘车卡”小程序，呈现对应搜索“乘车卡”小程序的搜索结果界面(图7A所示)，用户在搜索结果界面点击“乘车卡”小程序，实现页面跳转至小程序页面(图7B所示)，用户选择想要开通的虚拟乘车卡，通过点击操作触发针对虚拟乘车卡的开通指令(如通过点击图7B所示视图界面中“立即开通”按键，触发针对虚拟乘车卡的开通指令)，小程序实现页面跳转至支付授权界面(图7C所示)，在支付授权界面，呈现用于授权对应虚拟乘车卡的支付方式的支付授权按键。

在一些实施例中，终端在支付授权界面，还呈现对应所述支付方式的支付规则，以及用于确定支付方式的确定功能项；响应于根据所述支付规则触发的针对确定功能项的操作指令，关联虚拟乘车卡与对应所述支付方式的支付端。

以执行主体为小程序为例，参见图7C，小程序在支付授权界面，呈现的支付方式为“零钱”，对应支付方式为“零钱”的支付规则为乘车后卡内余额不足时通过零钱支付充值；这里，对应支付方式的支付规则用于对该支付方式进行解释说明；当用户根据支付规则触发针对确定功能项的操作指令时，小程序实现该虚拟乘车卡与对应该支付方式的支付端，即运行该小程序的客户端。

步骤602：响应于基于支付授权按键触发的授权指令，获取虚拟乘车卡关联的目标用户的信用度。

在一些实施例中，当终端上设置有虚拟乘车卡客户端时，响应于基于支付授权按键触发的授权指令，虚拟乘车卡客户端发送虚拟乘车卡关联的目标用户的信用度获取请求给后台服务器，以获取后台服务器返回的目标用户的信用度。这里，在实际实施时，后台服务器自身可以存储多个用户的信用度，依据信用度获取请求中携带的目标用户标识查询相应的信用度，或者，后台服务器基于目标用户的目标用户标识，转发该信用度获取请求给存储有用户信用度信息的服务器，以获取目标用户的信用度，并返回给虚拟乘车卡客户端。

这里，信用度，是指从社会信誉、经济状况、商品交易的履约情况等方面反映出来的用户的守信程度，在实际应用中，可通过信用评分表征用户的信用度，信用评分的高低相应的反应了信用度的高低。

在另一些实施例中，当执行主体为小程序时，小程序响应于基于支付授权按键触发的授权指令，发送对应目标用户的信用度获取请求给运行该小程序的客户端，以使运行该小程序的客户端从后台服务器处获取目标用户的信用度，并返回给小程序。

步骤603：基于目标用户的信用度，为虚拟乘车卡分配相应的支付金额。

在一些实施例中，设置有信用度与支付额度的映射关系，终端基于目标用户的信用度、信用度与支付额度的映射关系，确定虚拟乘车卡的支付额度；并可基于虚拟乘车卡的支付额度，为虚拟乘车卡分配相应的支付金额。

在一些实施例中，信用度采用信用评分来表征，终端可通过如下方式为虚拟乘车卡分配相应的支付金额：终端确定目标用户的信用评分所处的评分范围，依据确定的评分范围，确定对应目标用户的虚拟乘车卡的支付额度，并基于确定的支付额度，为虚拟乘车卡分配相应的支付金额。

举例说明，假设信用评分为百分制，设置信用评分的评分范围包括[0,60]、[60,80]、[80,100]；其中，评分范围[0,60]对应的支付额度为5元，评分范围[60,80]对应的支付额度为10元，评分范围[80,100]对应的支付额度为15元；所获取的目标用户的信用评分为75，确定该信用评分所处的评分范围为[60,80]，相应的，可确定对应目标用户的虚拟乘车卡的支付额度为10元，为虚拟乘车卡分配相应的支付金额为10元。

在另一些实施例中，信用度采用信用评分来表征，终端可通过如下方式为虚拟乘车卡分配相应的支付金额：终端确定目标用户的信用评分对应的信用等级，基于确定的信用等级、信用等级与支付额度的映射关系，确定虚拟乘车卡的支付额度，进而基于虚拟乘车卡的支付额度，为虚拟乘车卡分配相应的支付金额。

在一些实施例中，终端为虚拟乘车卡分配相应的支付金额之后，呈现相应的提示信息，该提示信息，用于提示用户无需对虚拟乘车卡进行充值即可乘车如图7D所示，在视图界面呈现“授信成功，无需充值，乘车后通过代扣支付车费”的提示信息；其中，授信为根据用户的信用情况，事先给用户的虚拟乘车卡授予一定的额度，用户在使用虚拟乘车卡时，无需提前充值，在乘坐车费低于授信额度内的车时，可直接刷虚拟乘车卡支付车费；代扣为事先与用户进行代扣签约，使用约定账户扣款，在用户使用虚拟乘车卡后需要支付车费时，用户无需操作，自动代替用户从约定账户扣除相应的车费。

在一些实施例中，终端为虚拟乘车卡分配相应的支付金额之后，终端在视图界面中呈现包含乘车卡***的虚拟乘车卡，该乘车卡***用于标识虚拟乘车卡，指示虚拟乘车卡开通成功。参见图7E所示，终端在视图界面中呈现开通成功的虚拟乘车卡(即云交通卡)，虚拟乘车卡中包括相应的***，以唯一的标识该虚拟乘车卡，以及指示虚拟乘车卡开通成功。

步骤604：响应于通过近场通信连接发送的第一支付订单，从支付金额中扣除对应第一支付订单的订单金额。

在实际应用中，虚拟乘车卡开通成功后，用户可基于该虚拟乘车卡进行刷卡乘车，具体地，用户手持终端贴近刷卡设备，以使终端与刷卡设备之间建立NFC通信连接，刷卡设备通过近场通信连接发送第一支付订单给终端，终端从虚拟乘车卡对应的支付金额中扣除对应第一支付订单的订单金额。

在一些实施例中，终端从支付金额中扣除对应第一支付订单的订单金额之后，通过弹窗，呈现虚拟乘车卡对应的刷卡信息和/或支付信息；其中，刷卡信息指示刷卡成功或刷卡失败，支付信息指示本次刷卡所扣除的对应第一支付订单的订单金额。参见图7F，终端刷卡成功、从支付金额中扣除对应第一支付订单的订单金额之后，通过弹窗呈现刷卡成功及授信支付5元的信息。

步骤605：基于订单金额，发送第二支付订单至所述支付方式对应的支付端，以基于第二支付订单，从关联的目标用户的支付账户中扣除订单金额。

在实际实施时，终端发送第二支付订单至所述支付方式对应的支付端之前，需要获取第二支付订单，在一些实施例中，终端可通过如下方式获取第二支付订单：发送包含订单金额的对应虚拟乘车卡的刷卡记录；接收返回的基于刷卡记录生成的第二支付订单，其中，第二支付订单对应的支付金额与订单金额相同。

示例性地，虚拟乘车卡客户端发送包含订单金额的对应虚拟乘车卡的刷卡记录给后台服务器，并接收后台服务器返回的基于刷卡记录生成的第二支付订单。

示例性地，小程序发送包含订单金额的对应虚拟乘车卡的刷卡记录给小程序的后台服务器，并接收小程序的后台服务器返回的基于刷卡记录生成的第二支付订单。

在一些实施例中，执行主体为小程序时，小程序基于订单金额，发送第二支付订单至所述支付方式对应的支付端，即发送第二支付订单至运行小程序的客户端，以使客户端基于第二支付订单，从关联的目标用户的支付账户中扣除订单金额。

相应的，当终端从关联的目标用户的支付账户中扣除订单金额后，呈现相应的扣费成功的提示信息，参见图7G，在微信的支付结果界面呈现扣费金额为5元的扣费成功提示信息。

在一些实施例中，终端发送第二支付订单至所述支付方式对应的乘车支付端之后，终端接收对应支付订单的支付成功消息；基于支付成功消息，为虚拟乘车卡充值，使得虚拟乘车卡的余额与支付金额相同。也就是说，在用户每次乘车后，首先从基于用户的信用度为用户的虚拟乘车卡分配的支付金额中扣取相应的车费，之后再从关联的支付账户中扣取该车费，当扣费成功时，自动为用户的虚拟车车卡充值，使其余额与最初分配的支付金额相同，以保证用户每次均能顺利乘车，用户无需为虚拟乘车卡进行充值，极大的方便了用户的出行。

在实际应用中，存在用户乘车后，对关联的用户的支付账户中扣费失败的情况，导致终端无法为用户的虚拟乘车卡进行充值，进而余额不足的情况，在该情况下，当用户采用该虚拟乘车卡刷卡乘车时，终端通过近场通信连接接收刷卡设备发送的第三支付订单，获取虚拟乘车卡的余额，当确定余额小于第三支付订单的订单金额时，呈现提示余额不足的提示消息，以使用户手动完成上次乘车时的扣费，以实现终端为虚拟乘车卡的自动充值。

在实际应用中，由于用户消费的增加、履约情况的变化等，会导致用户的信用度发生变化，此时，终端相应的会基于变化后的用户的信用度，调整为其虚拟乘车卡分配的支付金额；具体地，终端获取更新的目标用户的信用度，基于更新的目标用户的信用度，调整为虚拟乘车卡分配的支付金额。

应用本发明上述实施例，基于用户的信用度为用户的虚拟乘车卡分配相应的支付金额，在用户乘车后，首先从分配的支付金额中扣除相应的乘车费用，之后再从用户的支付账户中扣除该乘车费用，为用户带来先乘车后付费的体验，同时，由于用户无需为虚拟乘车卡充值，大大降低了用户乘车所需的时间成本及人力成本，提高用户的乘车体验。

在一些实施例中，终端在获取到第二支付订单之后，还可以结合区块链技术，将第二支付订单存储至区块链网络，具体地，终端对第二支付订单进行哈希处理，得到第二支付订单的摘要；存储第二支付订单的摘要至区块链网络，以使支付端从区块链网络获取到第二支付订单之后，校验从终端接收到的第二支付订单的真实性，接下来具体进行说明。

终端获取到第二支付订单之后，生成用于存储第二支付订单的交易，并发送生成的交易至区块链网络的节点，以使节点对交易共识后将第二支付订单存储至区块链网络；支付端在接收到终端发送的第二支付订单之后，在从关联的目标用户的支付账户中扣除订单金额之前，首先对接收到的第二支付订单的真实性进行校验，以在校验通过后执行从支付账户扣款的操作，具体地，支付端生成获取第二支付订单的交易，发送生成的交易至区块链网络的节点，以使节点对交易共识后将第二支付订单的摘要返回给支付端，支付端对从终端接收的第二支付订单进行哈希处理，并将哈希结果与从区块链网络获取的第二支付订单的摘要进行匹配，当匹配成功时，确定校验通过。

接下来对本发明实施例中的区块链网络进行说明。图8为本发明实施例提供的区块链网络的应用架构示意图，包括业务主体50、认证中心70，区块链网络80(示例性示出了共识节点81-1至共识节点81-3)，下面分别说明。

区块链网络80的类型是灵活多样的，例如可以为公有链、私有链或联盟链中的任意一种。以公有链为例，任何业务主体的电子设备例如用户终端和服务器，都可以在不需要授权的情况下接入区块链网络80；以联盟链为例，业务主体在获得授权后其下辖的电子设备(例如终端/服务器)可以接入区块链网络80，此时，成为区块链网络80中的客户端节点。

在一些实施例中，客户端节点可以只作为区块链网络80的观察者，即提供支持业务主体发起交易(例如，用于上链存储数据或查询链上数据)功能，对于区块链网络80的共识节点81(如共识节点81-1)的功能，例如排序功能、共识服务和账本功能等，客户端节点可以缺省或者有选择性(例如，取决于业务主体的具体业务需求)地实施。从而，可以将业务主体的数据和业务处理逻辑最大程度迁移到区块链网络80中，通过区块链网络80实现数据和业务处理过程的可信和可追溯。

区块链网络80中的共识节点接收来自不同业务主体(如业务主体50)的客户端节点(如归属于业务主体50的客户端节点51)提交的交易，执行交易以查找并返回第二支付订单的摘要，执行交易的各种中间结果或最终结果可以返回至业务主体的客户端节点中显示。

例如，客户端节点51可以订阅区块链网络80中感兴趣的事件，例如区块链网络80中特定的组织/通道中发生的交易，由共识节点81推送相应的交易通知到客户端节点51，从而触发客户端节点51中相应的业务逻辑。

以业务主体接入区块链网络以实现第二支付订单摘要的获取为例说明区块链的示例性应用。

参见图8，业务主体50为支付服务平台，从认证中心70进行登记注册获得数字证书，数字证书中包括业务主体的公钥、以及认证中心70对业务主体的公钥和身份信息签署的数字签名，用来与业务主体针对交易的数字签名一起附加到交易中，并被发送到区块链网络，以供区块链网络从交易中取出数字证书和签名，验证消息的可靠性(即是否未经篡改)和发送消息的业务主体的身份信息，区块链网络会根据身份进行验证，例如是否具有发起交易的权限。业务主体下辖的电子设备(例如终端或者服务器)运行的客户端都可以向区块链网络80请求接入而成为客户端节点。

业务主体50的客户端节点51用于在接收到终端发送的第二支付订单时，生成用于获取区块链中存储的第二支付订单摘要的交易，在交易中指定了实现第二支付订单摘要的获取操作需要调用的智能合约、以及向智能合约传递的参数，交易还携带了客户端51的数字证书、签署的数字签名(例如，使用客户端51的数字证书中的私钥，对交易的摘要进行加密得到)，并将交易广播到区块链网络80中的共识节点。

区块链网络80中的共识节点接收交易时，对交易携带的数字证书和数字签名进行验证，验证成功后，根据交易中携带的业务主体50的身份，确认业务主体50是否是具有交易权限，数字签名和权限验证中的任何一个验证判断都将导致交易失败。验证成功后签署节点自己的数字签名(例如，使用节点81-1的私钥对交易的摘要进行加密得到)，并继续在区块链网络80中广播。

区块链网络80中的共识节点接收验证成功的交易后，将交易填充到新的区块中，并进行广播。区块链网络80中的共识节点广播的新区块时，会对新区块进行共识过程，如果共识成功，则将新区块追加到自身所存储的区块链的尾部，并根据交易的结果更新状态数据库，执行新区块中的交易：对于提交的获取第二支付订单摘要的交易，从状态数据库中查询第二支付订单摘要对应的键值对，并返回交易结果。

作为区块链的示例，参见图9，图9是本发明实施例提供的区块链网络80中区块链的结构示意图，每个区块的头部既可以包括区块中所有交易的哈希值，同时也包含前一个区块中所有交易的哈希值，新产生的交易的记录被填充到区块并经过区块链网络中节点的共识后，会被追加到区块链的尾部从而形成链式的增长，区块之间基于哈希值的链式结构保证了区块中交易的防篡改和防伪造。

下面说明本发明实施例提供的区块链网络的示例性的功能架构，参见图10，图10为本发明实施例提供的区块链网络80的功能架构示意图，包括应用层1、共识层2、网络层3、数据层4和资源层5，下面分别进行说明。

资源层5封装了实现区块链网路80中的各个节点81的计算资源、存储资源和通信资源。

数据层4封装了实现账本的各种数据结构，包括以文件系统中的文件实现的区块链，键值型的状态数据库和存在性证明(例如区块中交易的哈希树)。

网络层3封装了点对点(P2P，Point to Point)网络协议、数据传播机制和数据验证机制、接入认证机制和业务主体身份管理的功能。

其中，P2P网络协议实现区块链网络80中节点81之间的通信，数据传播机制保证了交易在区块链网络80中的传播，数据验证机制用于基于加密学方法(例如数字证书、数字签名、公/私钥对)实现节点81之间传输数据的可靠性；接入认证机制用于根据实际的业务场景对加入区块链网络80的业务主体的身份进行认证，并在认证通过时赋予业务主体接入区块链网络80的权限；业务主体身份管理用于存储允许接入区块链网络80的业务主体的身份、以及权限(例如能够发起的交易的类型)。

共识层2封装了区块链网络80中的节点81对区块达成一致性的机制(即共识机制)、交易管理和账本管理的功能。共识机制包括POS、POW和DPOS等共识算法，支持共识算法的可插拔。

交易管理用于验证节点81接收的交易中携带的数字签名，验证业务主体的身份信息，并根据身份信息判断确认其是否具有权限进行交易(从业务主体身份管理读取相关信息)；对于获得接入区块链网络80的授权的业务主体而言，均拥有认证中心颁发的数字证书，业务主体利用自己的数字证书中的私钥对提交的交易进行签名，从而声明自己的合法身份。

账本管理用于维护区块链和状态数据库。对于取得共识的区块，追加到区块链的尾部；执行取得共识的区块中的交易，当交易包括更新操作时更新状态数据库中的键值对，当交易包括查询操作时查询状态数据库中的键值对并向业务主体的客户端节点返回查询结果。支持对状态数据库的多种维度的查询操作，包括：根据区块序列号(例如交易的哈希值)查询区块；根据区块哈希值查询区块；根据交易序列号查询区块；根据交易序列号查询交易；根据业务主体的账号(序列号)查询业务主体的账号数据；根据通道名称查询通道中的区块链。

应用层1封装了区块链网络能够实现的各种业务，包括交易的溯源、存证和验证等。

接下来以即时通讯客户端中运行乘车卡小程序，实现乘车卡的开通及使用为例，继续对本发明实施例提供的基于信用度的乘车支付方法进行说明。图8为本发明实施例提供的开通虚拟乘车卡的方法流程示意图，参见图11，本发明实施例提供的开通虚拟乘车卡的方法包括：

步骤701：即时通讯客户端运行乘车卡小程序。

这里，在实际实施时，终端具备NFC功能，终端上设置有即时通讯客户端(如微信客户端)，通过即时通讯客户端提供的小程序搜索功能，搜索乘车卡小程序，下载其源代码后即可运行乘车卡小程序。

步骤702：乘车卡小程序响应于针对虚拟乘车卡的开通指令，呈现用于授权对应虚拟乘车卡的支付方式的支付授权按键。

在实际应用中，在小程序页面，即虚拟乘车卡的开通界面，呈现一个或多个虚拟乘车卡供用户进行选择，用户选取想要开通的虚拟乘车卡，通过点击显示的虚拟乘车卡触发针对该虚拟乘车卡的开通指令，乘车卡小程序响应于用户触发的开通指令，呈现支付授权界面，在支付授权界面，呈现用于授权对应虚拟乘车卡的支付方式的支付授权按键。

在实际实施时，乘车卡小程序在支付授权界面，还呈现用于确定支付方式的确定功能项，以基于该确定功能项，关联虚拟乘车卡与即时通讯客户端。

步骤703：乘车卡小程序响应于基于支付授权按键触发的授权指令，发送目标用户的信用度获取请求给即时通讯客户端。

步骤704：即时通讯客户端返回目标用户的信用评分给乘车卡小程序。

步骤705：乘车卡小程序基于目标用户的信用评分，确定虚拟乘车卡的支付额度。

在实际实施时，信用度采用信用评分来表征，乘车卡小程序可通过如下方式确定虚拟乘车卡的支付额度：

乘车卡小程序确定目标用户的信用评分所处的评分范围，依据确定的评分范围，确定对应目标用户的虚拟乘车卡的支付额度。

步骤706：乘车卡小程序基于确定的支付额度，为虚拟乘车卡分配相应的支付金额。

步骤707：乘车卡小程序通过与刷卡设备之间的近场通信连接，接收第一支付订单，从支付金额中扣除对应第一支付订单的订单金额。

步骤708：乘车卡小程序通过弹窗，呈现虚拟乘车卡对应的刷卡信息和/或支付信息。

这里，刷卡信息用于指示刷卡成功或刷卡失败，支付信息用于指示本次刷卡所扣除的对应第一支付订单的订单金额。

步骤709：乘车卡小程序基于第一支付订单的订单金额，生成并发送第二支付订单给即时通讯客户端。

这里，第二支付订单对应的支付金额与订单金额相同。

步骤710：即时通讯客户端从关联的目标用户的支付账户中扣除订单金额。

步骤711：即时通讯客户端发送第二支付订单支付成功的消息给乘车卡小程序。

步骤712：乘车卡小程序为虚拟乘车卡充值。

在实际实施时，乘车卡小程序接收到第二支付订单支付成功的消息后，自动为虚拟乘车卡充值，使得虚拟乘车卡的余额与确定的支付额度相同。

继续以即时通讯客户端中运行乘车卡小程序，实现乘车卡的开通及使用为例，继续对本发明实施例提供的基于信用度的乘车支付方法进行说明。

图12A及图12B为本发明实施例提供的开通虚拟乘车卡的流程示意图，结合图12A及图12B对本发明实施例提供的开通虚拟乘车卡的流程进行说明。

步骤801：即时通讯客户端运行乘车卡小程序。

这里，在实际实施时，即时通讯客户端(如微信客户端)在首次运行乘车卡小程序时，需要下载小程序，即获取乘车卡小程序的源代码，然后即时通讯客户端通过解释乘车卡小程序的代码来进行乘车卡小程序页面的加载，后续在乘车卡小程序的使用过程中，无需重复下载，可直接运行。

步骤802：乘车卡小程序检测终端具备NFC功能。

这里，在实际实施时，乘车卡小程序可通过检测NFC功能接口，实现对终端NFC功能的检测。

步骤803：用户申请开通一卡通。

这里，一卡通为虚拟乘车卡，在乘车卡小程序页面可呈现多个可用的一卡通，用户通过针对所选一卡通的点击操作，触发针对一卡通的开通指令。

步骤804：乘车卡小程序发送签约免密支付请求给即时通讯客户端。

在实际实施时，当用户触发针对一卡通的开通指令后，小程序实现页面跳转至“开通免密支付”界面(即前述实施例中的支付授权界面)，当用户点击界面中呈现的“开通免密支付”按键时，触发乘车卡小程序发送签约免密支付请求给即时通讯客户端。

步骤805：即时通讯客户端返回签约成功消息给乘车卡小程序。

这里，当即时通讯客户端接收到乘车卡小程序发送的签约免密支付请求后，进行对应一卡通与所选扣费方式的关联，以在用户乘车后进行车费的代扣。

步骤806：乘车卡小程序呈现签约成功的消息。

当乘车卡小程序接收到即时通讯客户端返回签约成功消息后，相应的，将签约成功的消息呈现给用户。

步骤807：乘车卡小程序查询用户信息，进行授信。

具体地，乘车卡小程序从即时通讯客户端处获取用户信息，如获取用户的信用评分，然后基于用户的信用评分为该用户的一卡通分配相应的支付金额，在实际应用中，用户的信用评分越高，相应的分配的一卡通的支付金额越高。

步骤808：乘车卡小程序授信成功，呈现开卡成功信息。

在实际实施时，乘车卡小程序为用户的一卡通分配相应的支付金额后，分别向用户展示授信成功及开卡成功的信息。

图13A及图13B为本发明实施例提供的使用虚拟乘车卡的流程示意图，结合图13A及图13B对本发明实施例提供的使用虚拟乘车卡的流程进行说明。

步骤901：一卡通云服务器为一卡通提前充值。

这里，在对用户的一卡通授信成功后，基于用户的信用度(如信用评分)，为用户的一卡通自动充值，即为用户的一卡通分配相应的支付金额。

步骤902：进入一卡通小程序。

在实际应用中，当用户需要用开通成功的一卡通进行乘车支付时，用户触发即时通讯客户端运行一卡通小程序。

步骤903：一卡通小程序检测终端具备NFC功能。

这里，在实际实施时，乘车卡小程序可通过检测NFC功能接口，实现对终端NFC功能的检测。

步骤904：用户触发请求一卡通数据。

这里，在实际实施时，用户通过针对呈现的一卡通的点击操作，触发请求一卡通数据。

步骤905：一卡通小程序向一卡通云服务器请求一卡通数据。

步骤906：一卡通云服务器下发一卡通数据给一卡通小程序。

步骤907：一卡通小程序向用户呈现一卡通数据。

步骤908：闸机发送扣款成功消息给一卡通小程序。

当用户手机贴近闸机刷卡感应处时，闸机通过与一卡通小程序间的NFC连接，在一卡通中扣除本次乘车费用。

步骤909：一卡通小程序显示“刷卡成功”弹窗。

在实际实施时，一卡通扣款成功后，相应的，一卡通余额扣减。

步骤910：一卡通小程序生成充值订单。

在实际实施时，一卡通小程序基于闸机拓传的扣款成功消息，生成相应的充值订单。

步骤911：一卡通小程序发送充值订单至即时通讯客户端。

步骤912：即时通讯客户端发起代扣。

在实际实施时，即时通讯客户端在接收到一卡通小程序发送的充值订单后，从关联的用户的账户中扣除相应的乘车费用。

步骤913：即时通讯客户端发送支付成功消息给一卡通小程序。

步骤914：一卡通小程序呈现支付成功消息给用户。

步骤915：一卡通小程序发送充值成功订单给一卡通云服务器。

步骤916：一卡通云服务器为一卡通充值。

继续对本发明实施例提供的基于信用度的乘车支付装置行说明。图14为本发明实施例提供的基于信用度的乘车支付装置的组成结构示意图，参见图14，本发明实施例提供的基于信用度的乘车支付装置455包括：

显示模块4551，用于响应于针对虚拟乘车卡的开通指令，呈现用于授权对应所述虚拟乘车卡的支付方式的支付授权按键；

获取模块4552，用于响应于基于所述支付授权按键触发的授权指令，获取所述虚拟乘车卡关联的目标用户的信用度；

分配模块4553，用于基于所述目标用户的信用度，为所述虚拟乘车卡分配相应的支付金额；

支付模块4554，用于响应于通过近场通信连接发送的第一支付订单，从所述支付金额中扣除对应所述第一支付订单的订单金额；

发送模块4555，用于基于所述订单金额，发送第二支付订单至所述支付方式对应的支付端，以基于所述第二支付订单，从关联的所述目标用户的支付账户中扣除所述订单金额。

在一些实施例中，所述装置还包括关联模块；

所述显示模块，还用于呈现对应所述支付方式的支付规则，以及用于确定所述支付方式的确定功能项；

所述关联模块，用于响应于根据所述支付规则触发的针对所述确定功能项的操作指令，关联所述虚拟乘车卡与对应所述支付方式的支付端。

在一些实施例中，所述获取模块，还用于发送对应所述目标用户的信用度获取请求；

接收返回的用于表征所述目标用户的信用度的信用评分。

在一些实施例中，所述获取模块，还用于通过子应用程序，发送所述信用度获取请求至运行所述子应用程序的母应用程序。

在一些实施例中，所述分配模块，还用于基于所述目标用户的信用度、信用度与支付额度的映射关系，确定所述虚拟乘车卡的支付额度；

基于所述虚拟乘车卡的支付额度，为所述虚拟乘车卡分配相应的支付金额。

在一些实施例中，所述显示模块，还用于在视图界面中呈现包含乘车卡***的所述虚拟乘车卡，所述乘车卡***用于标识所述虚拟乘车卡，指示所述虚拟乘车卡开通成功。

在一些实施例中，所述显示模块，还用于通过弹窗，呈现所述虚拟乘车卡对应的刷卡信息和/或支付信息。

在一些实施例中，所述获取模块，还用于发送包含所述订单金额的对应所述虚拟乘车卡的刷卡记录；

接收返回的基于所述刷卡记录生成的所述第二支付订单，所述第二支付订单对应的支付金额与所述订单金额相同。

在一些实施例中，所述装置还包括：

充值模块，用于接收对应所述第二支付订单的支付成功消息；

基于所述支付成功消息，为所述虚拟乘车卡充值，使得所述虚拟乘车卡的余额与所述支付金额相同。

在一些实施例中，所述支付模块，还用于响应于通过近场通信连接发送的第三支付订单，获取所述虚拟乘车卡的余额；

所述显示模块，还用于当所述余额小于所述第三支付订单的订单金额时，呈现提示余额不足的提示消息。

在一些实施例中，所述获取模块，还用于获取更新的所述目标用户的信用度；

所述分配模块，还用于基于更新的所述目标用户的信用度，调整为所述虚拟乘车卡分配的支付金额。

在一些实施例中，所述装置还包括检测模块；

所述检测模块，用于检测近场通信接口，得到检测结果；

所述显示模块，还用于当所述检测结果表征检测到近场通信接口时，呈现用于授权对应所述虚拟乘车卡的支付方式的支付授权按键。

这里需要指出的是：以上涉及装置的描述，与上述方法描述是类似的，同方法的有益效果描述，不做赘述，对于本发明实施例所述装置中未披露的技术细节，请参照本发明方法实施例的描述。

本发明实施例还提供了一种电子设备，所述电子设备包括：

存储器，用于存储可执行程序；

处理器，用于执行所述存储器中存储的可执行程序时，实现本发明实施例提供的上述基于信用度的乘车支付方法。

本发明实施例还提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本发明实施例提供的基于信用度的乘车支付方法。

实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、随机存取存储器(RAM，Random Access Memory)、只读存储器(ROM，Read-Only Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、RAM、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。