一种公交支付方法、系统、公交收费设备及存储介质与流程

本申请涉及公交系统技术领域，特别涉及一种公交支付方法、系统、一种公交收费设备及一种存储介质。

背景技术：

目前国内通过社会保障卡可以乘坐公交的案例已经存在，但均为利用cpu卡片内部特定空间的文件结构，将交通部现有的互联互通文件体系原封不动地迁移进去作为一张复合卡，也就是一张卡在不同存储区的各自规划应用，具有多个钱包。因此，这种设计方案下，与传统公交卡一样，市民仍需持社会保障卡到客服网点办理充值业务，往公交钱包中充值后才能刷卡乘车，很多业务仍然需要持卡人将卡片放置至具有读写功能的硬件设备环境中才能办理。

因此，如何避免乘客向公交功能钱包反复充值，提高公交支付效率及资金安全是本领域技术人员目前需要解决的技术问题。

技术实现要素：

本申请的目的是提供一种公交支付方法、系统、一种公交收费设备及一种存储介质，能够避免乘客向公交功能钱包反复充值，提高公交支付效率及资金安全。

为解决上述技术问题，本申请提供一种公交支付方法，该公交支付方法包括：

读取社保卡的用户身份信息；

根据所述用户身份信息确定扣费金额，并上传所述扣费金额对应的扣费请求；

若接收到扣费成功的通知信息，则判定本次支付成功；

若接收到扣费失败的通知信息，则判定本次支付失败。

可选的，所述读取社保卡的用户身份信息，包括：

读取实体社保卡的m1扇区得到所述用户身份信息；

或，通过扫描电子社保卡中的二维码得到所述用户身份信息。

可选的，根据所述用户身份信息确定扣费金额，包括：

判断所述用户身份信息是否具有折扣权限；

若是，则根据所述用户身份信息的乘车折扣和乘车距离确定所述扣费金额；

若否，则根据所述乘车距离确定所述扣费金额。

可选的，判断所述用户身份信息是否具有折扣权限，包括：

根据所述用户身份信息确定乘客类别、折扣有效期和剩余折扣次数；

判断是否所述乘客类别为预设类别、当前时刻在所述折扣有效期内且所述剩余折扣次数大于0；

若是，则判定所述用户身份信息具有折扣权限；

若否，则判定所述用户身份信息不具有折扣权限。

可选的，在接收到扣费成功的通知信息之后，还包括：

更新所述社保卡中用户身份信息中的剩余折扣次数。

可选的，在接收到扣费失败的通知信息之后，还包括：

向与所述社保卡绑定的终端设备发送余额不足的提示信息。

可选的，上传所述扣费金额对应的扣费请求，包括：

向公交电子支付平台上传所述扣费金额对应的扣费请求，以便所述公交电子支付平台将所述扣费请求转发至所述社保卡对应的银联支付平台。

本申请还提供了一种公交支付系统，该系统包括：

信息读取模块，用于读取社保卡的用户身份信息；

扣费请求模块，用于根据所述用户身份信息确定扣费金额，并上传所述扣费金额对应的扣费请求；

支付结果输出模块，用于若接收到扣费成功的通知信息，则判定本次支付成功；还用于若接收到扣费失败的通知信息，则判定本次支付失败。

本申请还提供了一种存储介质，其上存储有计算机程序，所述计算机程序执行时实现上述公交支付方法执行的步骤。

本申请还提供了一种公交收费设备，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器调用所述存储器中的计算机程序时实现上述公交支付方法执行的步骤。

本申请提供了一种公交支付方法，包括：读取社保卡的用户身份信息；根据所述用户身份信息确定扣费金额，并上传所述扣费金额对应的扣费请求；若接收到扣费成功的通知信息，则判定本次支付成功；若接收到扣费失败的通知信息，则判定本次支付失败。

本申请通过读取社保卡的用户身份信息，根据用户身份信息确定本次乘坐公交的扣费金额，并上传扣费金额对应的扣费请求，以便从社保卡的账户中扣除相应的费用。根据社保卡账户反馈的扣费结果判定本次支付是否成功。本申请直接从社保卡账户进行乘车费用的扣除，可以免去乘客向公交功能钱包充值的操作，提高了公交支付效率及资金安全。本申请同时还提供了一种公交支付系统、一种存储介质和一种公交收费设备，具有上述有益效果，在此不再赘述。

附图说明

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

图1为本申请实施例所提供的一种公交支付方法的流程图；

图2为本申请实施例所提供的一种m1扇区卡结构的示意图；

图3为本申请实施例所提供的一种金融技术和交通二维码技术双技术融合在社保卡的应用框架图；

图4为本申请实施例所提供的一种使用者车载支付流程示意图；

图5为本申请实施例所提供的一种实体社保卡车载终端支付流程图；

图6为本申请实施例所提供的一种电子社保卡车载终端支付流程图。

具体实施方式

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

下面请参见图1，图1为本申请实施例所提供的一种公交支付方法的流程图。

具体步骤可以包括：

s101：读取社保卡的用户身份信息；

其中，传统的公交ic卡是脱机钱包，还可以是脱机钱包与银行金融钱包的复合卡，前者只能在一卡通网点固定设备上圈存充值，后者也是虽然有多个钱包，但是两个钱包并不是互通的，需要在一卡通网点固定设备上圈存充值，传统的公交ic卡的圈存充值无法摆脱线下的圈存的设备，整个充值过程比较不方便，且的余额无法实时查看，且用户充值进去的金额无法退还。

本实施例中的社保卡为金融技术和交通二维码技术双技术融合在社保卡，该社保卡使用用户自己的网银账户，用户的余额用户可以随时可以查询到，且可以通过多种渠道对其网银账户充值使用，且充值后的金额能自由支配。金融技术和交通二维码技术双技术融合在社保卡的应用同时也解决了银行卡的身份需通过联网识别问题，通过结合传统公交ic卡的设计及公交场景，金融技术和交通二维码技术双技术融合在社保卡的实体卡、电子社保卡(二维码)都带有用户身份标识，用户优惠次数，有效期等信息，从而可以在设备上快速确定用户的身份，折扣，优惠次数，有效期等问题，让用户在使用上跟传统ic卡使用是一致的。

具体的，s101中读取社保卡的用户身份信息可以具体为读取实体社保卡的m1扇区得到所述用户身份信息，s101中读取社保卡的用户身份信息还可以具体为通过扫描电子社保卡中的二维码得到所述用户身份信息。m1扇区为mifare非接触式感应卡的扇区，请参见图2，图2为本申请实施例所提供的一种m1扇区卡结构的示意图。本实施例通过社保卡的m1扇区，写入交通行业标识并进行个人化处理。充分利用了非接触技术，具有读写能力，使用起来更方便、迅速，且卡片不会受到损害，更加适用于公共交通这类高频消费场景。个人化处理指对社保卡做基本数据和密钥的初始化，即根据社保卡结构进行数据初始化，作用是设定社保卡的初始化，确定卡片默认类型等。请参见表1，表1为个人化结构表。

表1个人化结构表

s102：根据所述用户身份信息确定扣费金额，并上传所述扣费金额对应的扣费请求；

其中，本步骤在确定社保卡对应的用户身份信息的基础上，根据用户身份信息确定对应的扣费金额。本实施例默认每一种用户身份信息可以有其对应的收费标准，进而根据收费标准确定本次乘车的扣费金额。本实施例可以根据扣费金额生成对应的扣费请求，并向公交电子支付平台上传所述扣费金额对应的扣费请求，以便所述公交电子支付平台将所述扣费请求转发至所述社保卡对应的银联支付平台。银联支付平台可以在接收到扣费请求后将扣费结构返回至公交电子支付平台，以便公交电子支付平台返回扣费成功或扣费失败的通知信息。

s103：若接收到扣费成功的通知信息，则判定本次支付成功；

其中，在判定本次支付成之后，本实施例可以播放扣费成功的提示信息以便允许乘客通过。

s104：若接收到扣费失败的通知信息，则判定本次支付失败。

其中，在判定本次支付失败之后，本实施例可以播放扣费失败的提示信息，以便提示乘客余额不足。作为一种更可行的实施方式，在接收到扣费失败的通知信息之后，还可以向与所述社保卡绑定的终端设备发送余额不足的提示信息。

本实施例通过读取社保卡的用户身份信息，根据用户身份信息确定本次乘坐公交的扣费金额，并上传扣费金额对应的扣费请求，以便从社保卡的账户中扣除相应的费用。根据社保卡账户反馈的扣费结果判定本次支付是否成功。本实施例直接从社保卡账户进行乘车费用的扣除，可以免去乘客向公交功能钱包充值的操作，提高了公交支付效率及资金安全。

在本实施例中，社保卡本身就是一张银行卡，用户无需做绑定工作。用户在与公交收费设备进行交易以后，乘客的公交信息和银联系统的网银账户的绑定关系即会同步给公交公司或公交ic卡管理公司，增加公交公司科技化管理，提升管理水平。

使用者在使用社保实体卡或二维码支付的时候，公交收费设备通过读取实体卡m1扇区或二维码的特定字符可以确定用户身份信息，结合公交收费设备上针对不同身份的优惠折扣，可以根据其优惠折扣后向银联请款，银联收到请求以后扣除使用者网银账户金额。网银的账户会判断用户的网银账户余额是否足以满足用户的乘车条件，如不满足则返回，设备则提示用户无法乘车。用户网银账户有余额，即可刷卡乘车，用户余额不足的时候则可以随时通过银行，第三方支付机构等多种线上充值阶段充值，充值完成后，即可刷卡乘车。请参见图3，图3为本申请实施例所提供的一种金融技术和交通二维码技术双技术融合在社保卡的应用框架图，用户可以用过具备金融技术和交通二维码技术双技术融合的设备卡与公交收费设备进行交互，公交收费设备根据乘客的用户身份信息，公交收费设备将消费数据通过网络上传至银联体系的收单机构和转接机构，以便对乘客的银联金融钱包进行扣费。扣费过程包括非接消费交易和携带免密标识的非接消费交易。银联系统可以将交易数据结果返回公交收费设备，以便公交收费设备反馈支付结果。用户也可以通过多种充值渠道向绑定的银联金融钱包进行充值。

本实施例中，金融技术和交通二维码技术双技术融合在社保卡的应用在技术上使用的是用户的网银账户是金融级别，银联与人行监管下的账户体系，此网银账户安全级别比目前传统公交ic卡系统账户高很多，也解决很多传统公司关于公交ic卡的账户错乱的问题，同时解决使用者对资金安全的顾虑。

通过该应用的系统及支付方法，切实提升使用者乘坐公交的使用体验，免去公交网点充值放你，节省时间，解决公交充值点少的去向，充值方案不受时间、地点的限制，用户的有多种渠道的充值方式，同时也可以减少公交企业人力成本；同时便于现有公交公司的乘车收费硬件系统可以不做任何变更，只需要对公交收费设备(如车载pos)，且无需对公交充值数据系统与公交账户系统进行改造。

作为对于图1对应的实施例的进一步介绍，根据所述用户身份信息确定扣费金额，包括：判断所述用户身份信息是否具有折扣权限；若是，则根据所述用户身份信息的乘车折扣和乘车距离确定所述扣费金额；若否，则根据所述乘车距离确定所述扣费金额。

具体的，本实施例可以通过以下方式判断所述用户身份信息是否具有折扣权限，包括：根据所述用户身份信息确定乘客类别、折扣有效期和剩余折扣次数；判断是否所述乘客类别为预设类别、当前时刻在所述折扣有效期内且所述剩余折扣次数大于0；若是，则判定所述用户身份信息具有折扣权限；若否，则判定所述用户身份信息不具有折扣权限。作为一种可行的实施方式，本实施例可以在接收到扣费成功的通知信息之后，更新所述社保卡中用户身份信息中的剩余折扣次数。

请参见图4、图5和图6，图4为本申请实施例所提供的一种使用者车载支付流程示意图，图5为本申请实施例所提供的一种实体社保卡车载终端支付流程图，图6为本申请实施例所提供的一种电子社保卡车载终端支付流程图。

在使用者车载支付流程中，用户通过实体社保卡或电子社保卡在公交收费设备上刷卡或扫码。公交收费设备确定社保卡对应的用户身份信息，根据用户身份信息确定乘客享受的优惠折扣，以便根据用户的折扣金额生成并发送扣费请求。公交电子支付平台接收到扣费请求之后，可以将扣费请求转发至银联支付平台进行扣费。若扣费成功，公交收费设备可以播报欢迎乘车的语音信息。若扣费失败，公交收费设备可以播报余额不足的语音信息，以便用户向社保金额钱包中充值金额。

在实体社保卡车载终端支付流程中，用户在刷实体社保卡(即图5中的银联实体卡)后，公交收费设备判断实体社保卡是否存在m1扇区(即判断尸体社保卡是否经过个人化操作)。若不存在m1扇区则直接走银联收费流程；若存在m1扇区则判断实体社保卡是否激活，若未激活则拒绝乘车并提示“此卡未激活交通功能，若已激活则确定实体社保卡的卡类型。本实施例可以根据m1卡结构有相关字段判断实体社保卡是否激活。若卡类型为普通卡，则直接根据卡类型进行优惠折扣。若卡类型为特群卡(如学生卡、老年卡、关爱卡等)，则判断该特群卡是否在有效期内，若不在有效期内则直接根据卡类型进行优惠折扣；若在有效期内则判断本月内是否有优惠次数，若没有优惠次数则直接根据卡类型进行优惠折扣，若有优惠次数则扣除优惠次数并根据卡类型优惠折扣。若扣费成功则根据卡类型进行语音播报，若扣费失败则提示乘客重新刷卡。

在电子社保卡车载终端支付流程中，根据电子社保卡中的二维码得到所述用户身份信息，根据用户身份信息确定卡类型。若卡类型为普通卡，则直接根据卡类型进行优惠折扣。若卡类型为特群卡(如学生卡、老年卡、关爱卡等)，则判断本月内是否有优惠次数，若没有优惠次数则直接根据卡类型进行优惠折扣，若有优惠次数则扣除优惠次数并根据卡类型优惠折扣。若扣费成功则根据应扣扣款金额播报语音或参照目前银行卡的语音提示，还可以播报相应的卡类型。若扣费失败则提示乘客重刷二维码。作为一种可行的实施方式，扣费失败的用户只有在支付后才能继续使用二维码。电子社保卡仅在app端展示，除了展示社保卡相关信息外，包含根据交通部互联互通二维码标准生成的公交二维码，所以本实施例需要先打开电子社保卡页面后才能调取用于公交乘车的二维码。

上述实施例保留了交通部互联互通技术体系下适合交通场景的卡类别设计、卡片有效期的规划、刷卡次数的记录等，在支付环节采用安全可靠的pboc3.0金融账户体系，结合先进成熟的交通部互联互通技术，实现客户使用第三代社会保障实体/电子卡，通过交通部互联互通卡/二维码支付所产生的金额，由相关金融机构以银联系统的数据报表为依托，直接向公交企业结算的模式。此种模式乘客使用金融钱包进行公交乘车支付，其交易环节处于银行成熟的风控监管体系下，安全可靠。此种方式既避免了乘客额外开通公交功能钱包容易出现卡管理企业挪用资金、篡改数据的风险，也省去了乘客向公交功能钱包反复充值的使用流程，提升了乘客的体验感。另外，本实施例在第三代社会保障电子卡现有技术基础上，嵌入交通部互联互通二维码体系，实现第三代社保保障实体/电子卡线上、线下皆具备交通功能，解决了社会保障卡在交通场景下线上、线下双渗透。

本申请实施例还提供的一种公交支付系统，该系统可以包括：

信息读取模块，用于读取社保卡的用户身份信息；

扣费请求模块，用于根据所述用户身份信息确定扣费金额，并上传所述扣费金额对应的扣费请求；

支付结果输出模块，用于若接收到扣费成功的通知信息，则判定本次支付成功；还用于若接收到扣费失败的通知信息，则判定本次支付失败。

本实施例通过读取社保卡的用户身份信息，根据用户身份信息确定本次乘坐公交的扣费金额，并上传扣费金额对应的扣费请求，以便从社保卡的账户中扣除相应的费用。根据社保卡账户反馈的扣费结果判定本次支付是否成功。本实施例直接从社保卡账户进行乘车费用的扣除，可以免去乘客向公交功能钱包充值的操作，提高了公交支付效率及资金安全。

进一步的，信息读取模块，包括：

实体卡读取单元，用于读取实体社保卡的m1扇区得到所述用户身份信息；

或，二维码读取单元，用于通过扫描电子社保卡中的二维码得到所述用户身份信息。

进一步的，扣费请求模块包括：

权限判断单元，用于判断所述用户身份信息是否具有折扣权限；

第一金额确定单元，用于若用户身份信息具有折扣权限，则根据所述用户身份信息的乘车折扣和乘车距离确定所述扣费金额；

第二金额确定单元，用于若用户身份信息不具有折扣权限，则根据所述乘车距离确定所述扣费金额。

进一步的，所述权限判断单元用于根据所述用户身份信息确定乘客类别、折扣有效期和剩余折扣次数；还用于判断是否所述乘客类别为预设类别、当前时刻在所述折扣有效期内且所述剩余折扣次数大于0；若是，则判定所述用户身份信息具有折扣权限；若否，则判定所述用户身份信息不具有折扣权限。

进一步的，还包括：

折扣次数更新单元，用于在接收到扣费成功的通知信息之后，更新所述社保卡中用户身份信息中的剩余折扣次数。

进一步的，还包括：

提示模块，用于在接收到扣费失败的通知信息之后，向与所述社保卡绑定的终端设备发送余额不足的提示信息。

进一步的，扣费请求模块上传所述扣费金额对应的扣费请求的过程包括：向公交电子支付平台上传所述扣费金额对应的扣费请求，以便所述公交电子支付平台将所述扣费请求转发至所述社保卡对应的银联支付平台。

由于系统部分的实施例与方法部分的实施例相互对应，因此系统部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。

本申请还提供了一种存储介质，其上存有计算机程序，该计算机程序被执行时可以实现上述实施例所提供的步骤。该存储介质可以包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请还提供了一种公交收费设备，可以包括存储器和处理器，所述存储器中存有计算机程序，所述处理器调用所述存储器中的计算机程序时，可以实现上述实施例所提供的步骤。当然所述公交收费设备还可以包括各种网络接口，电源等组件。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的状况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。