地铁乘车码支付数据处理方法、装置、系统及电子设备

本发明涉及网络技术领域，特别涉及一种地铁乘车码支付数据处理方法、装置、系统及电子设备。

在公共交通行业中，越来越多城市的地铁支持用户使用电子乘车码方式进行乘车，目前地铁乘车码支付的计费方式有两种，一种是在设备侧完成计费，另一种在数据处理设备完成计费。设备侧完成计费，使用用户移动设备与地铁设备进行交互完成计费，由于移动设备的型号不一，对用户移动设备及地铁硬件设备要求较高且设备兼容性较差，可能会有无法完成计费的情况，导致用户无法进站或出站，降低了用户体验，会招致投诉，这种计费模式应用在蓝牙+乘车码进站模式和仅乘车码进站模式中。数据处理设备完成计费，应用于仅乘车码进站模式中，大都是将用户未计费的行程直接进行配对，可能会造成按最远行程、最长时间计费的情况，导致多扣交易费用招致用户投诉和少计交易费用导致业主收入损失。

鉴于上述问题，有必要提出一种地铁乘车码支付数据处理方法以解决或部分解决上述问题，本发明提出的技术方案如下：

一种地铁乘车码支付数据处理方法，该方法包括：

接收闸机上传的交易数据，交易数据包括用户ID、进站交易数据和出站交易数据；

对预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对，若融对成功，则计算交易费后向客户端提出扣费申请；若融对失败，则按照单边交易规则挂起并向客户端发送补全交易数据指令；若预设第二时间段未收到客户端发送补全交易数据，则按预设规则计算交易费，并向客户端发送扣费申请及禁止生成乘车码指令。

进一步的，所述对预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对包括：根据交易时间就近原则对出站交易数据和进站交易数据进行融对。

进一步的，所述对预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对包括：同一用户ID对应的进站交易数据和出站交易数据分别仅有一条，则该进站交易数据和出站交易数据融对成功。

进一步的，若融对失败，则按照单边交易规则挂起并向客户端发送补全交易数据指令还包括：待用户提交补全交易数据后，再按预设规则进行交易融对。

进一步的，对预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对，还包括：若在融对前收到用户补全交易数据和闸机上传的交易数据，则以闸机上传的交易数据作为融对依据。

第二方面，本发明还提出了一种电子设备，包括存储器，以及耦合到所述存储器的处理器，所述处理器被配置为基于存储在所述存储器中的指令，执行权利上面所述的任一地铁乘车码支付数据处理方法。

第三方面，本发明还提出了一种地铁乘车码支付数据处理装置，包括数据接收模块、融对计费模块，其中：

数据接收模块，用于接收闸机上传的交易数据，交易数据包括用户ID、进站交易数据和出站交易数据；

融对计费模块，用于对预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对，若融对成功，则计算交易费后向客户端提出扣费申请；若融对失败，则按照单边交易规则挂起并向客户端发送补全交易数据指令；若预设第二时间段未收到客户端发送补全交易数据，则按预设规则计算交易费，并向客户端发送扣费申请及禁止生成乘车码指令。

第四方面，本发明还提出了一种地铁乘车码支付数据处理系统，包括交互设备、数据处理设备，其中：

交互设备，包括与数据处理设备连接的闸机、客户端；所述客户端用于生成供闸机识别的乘车码，接受来自数据处理设备的扣费申请，还用于接收数据处理设备发送的补全交易数据的提示；所述闸机读取所述乘车码信息，生成交易数据并上传至数据处理设备，所述交易数据包括用户ID、进站交易数据和出站交易数据；

数据处理设备，分别与闸机、客户端连接，用于接收来自闸机、客户端上传的交易数据，并将预设时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对，若融对成功，则计算交易费后向客户端提出扣费申请；若融对失败，则按照单边交易规则挂起并向客户端发送补全交易数据指令；若预设第二时间段未收到客户端发送补全交易数据，则按预设规则计算交易费，并向客户端发送扣费申请及禁止生成乘车码指令。

基于上述技术方案，本发明较现有技术而言的有益效果为：

本发明提出了一种地铁乘车码支付数据处理方法，数据处理设备接收到闸机上传的交易数据后，将预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对，融对成功后，计算交易费并向客户端发起扣费申请，若未能成功融对，则按照单边交易规则挂起并通过客户端向乘客推送补全交易数据指令；若预设第二时间段未收到客户端发送补全交易数据，则按预设规则计算交易费，并向客户端发送扣费申请及禁止生成乘车码指令。本发明的计费是在数据处理设备完成，克服了在设备侧计费兼容性差的问题，提高了计费成功率，提升了用户的使用体验；并且本发明对预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对，融对成功即计费，即便融对失败，也可根据用户补全的交易数据进行扣费，克服了现有技术中将用户未计费的行程直接按最远行程、最长时间计费的情况，保证产生的行程数据的准确性，减少了多扣交易费招致的用户投诉和少计交易费导致的地铁运营方收入损失。另外，用户可以在客户端直接补全交易数据，无需去人工解决，补票操作更加方便。若融对失败且在预设第二时间段未收到客户端发送补全交易数据，则按预设规则计算交易费，并向客户端发送扣费申请及禁止生成乘车码指令，不仅弥补了地铁运营商收入，还能通过禁止通行再次提醒用户补全交易数据。

图1是本发明实施例一中，一种地铁乘车码支付数据处理方法的流程示意图；

图2是本发明实施例三中，一种地铁乘车码支付数据处理装置的结构示意图；

图3是本发明实施例四中，一种电子设备的结构示意图；

图4是本发明实施例五中，一种地铁乘车码支付数据处理系统的结构示意图。

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

实施例一

本实施例提出了一种地铁乘车码支付数据处理方法，如图1所示，该方法包括：

步骤S1：接收闸机上传的交易数据，交易数据包括用户ID、进站交易数据和出站交易数据。

用户乘地铁在闸机上刷码后，用户ID、扫码时间、闸机信息(一般包括闸机ID、闸机所在站点信息、闸机进出站类型等数据)将一起作为交易数据打包上传给数据处理设备。在本实施例中将进出站类型为进站、该闸机所在站点信息、扫码时间合称为进站交易数据，将进出站类型为出站、该闸机所在站点信息、扫码时间合称为出站交易数据。

下面通过表格对本步骤进行详细说明。下面的描述中：“进”表示进站，“出”表示出站，A、B…分别代表不同站点，甲、乙…分别代表不同用户ID。表1为接收的各交易数据包:

表1

步骤S2：对预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对，若融对成功，执行步骤S201，若融对失败，则执行步骤S202。

预设时间段可以根据实际情况设置，比如可以是同一运营日内，运营日是指地铁开始运营到地铁停运的时间段。其中，步骤S201：计算交易费后向客户端提出扣费申请。步骤S202：按照单边交易规则挂起并向客户端发送补全交易数据指令；若预设第二时间段未收到客户端发送补全交易数据，则按预设规则计算交易费，并向客户端发送扣费申请及禁止生成乘车码指令。

表2-表5为将与表1中同一用户ID的对应的交易数据进行整理的结果，即表2-表5分别为用户甲、用户乙、用户丙、用户丁的交易数据。

用户ID 甲 甲 进出站类型 进 出 扫码时间 8：40 9：00 站点 A B

表2

用户ID 乙 乙 进出站类型 进 出 扫码时间 8：42 9：10 站点 A D

表3

用户ID 丙 丙 丙 丙 进出站类型 进 出 进 出 扫码时间 8：42 8：55 10：10 10：30 站点 B C E A

表4

表5

具体的，根据预设规则进行交易融对的方法包括：根据交易时间就近原则对出站交易数据和进站交易数据进行融对，或者同一用户ID对应的进站交易数据和出站交易数据分别仅有一条，则该进站交易数据和出站交易数据融对成功。由表4可见，用户丙有两条进站数据，进站点分别为B、E,有两条出站数据，出站点分别为C、A。由于进站点时间应该早于站点时间，且与进站点B时间更接近的为出站点为C，可以理解的，已经完成融对的出站交易数据和进站交易数据，不再与待融对交易数据进行融对。因此对于用户丙来说有两条融对结果，分别是：

(1)站点B(进)-站点C(出)

(2)站点E(进)-站点A(出)

由表2可见，用户甲的进站交易数据和出站交易数据分别仅有一条，因此对于用户甲来说交易数据的融对结果为：站点A(进)-站点B(出)。

同理，可知用户乙交易数据融对结果为：站点A(进)-站点D(出)。

对于用户甲、用户乙、用户丙而言，在交易数据融对成功后，即执行步骤S201，根据融对结果计算交易费，并向客户端提出扣费申请以完成扣费。

对用户丁而言，仅有一条出站交易数据，缺少进站交易数据，因此融对失败，则执行步骤S202，按照单边交易规则挂起并向客户端发送补全交易数据指令，用户可以通过的半自动售票机或客户端补全交易数据。比如，用户丁实际是在A站点进站的，当客户端收到缺少进站交易数据的提醒时，用户丁主动通过的半自动售票机(又称BOM机)或客户端将“进站点为A”的信息发送到数据处理设备，再按预设规则进行交易融对。由于用户丁只有一条进站交易数据、一条出站交易数据，因此融对结果是：站点A(进)-站点D(出),按照此融对情况进行扣费。

为了防止地铁运营的损失，用户丁若为在预设第二时间补全交易数据，按预设规则计算交易费，并向客户端发送扣费申请及禁止生成乘车码指令。该预设规则可以是按最高额计算交易费；或按最低额计算交易费；或按平均额计算交易费。

本发明实施例提出的地铁乘车码支付数据处理方法，在数据处理设备处完成计费，克服了在设备侧计费兼容性差的问题，提高了计费成功率，提升了用户的使用体验；并且本发明对预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对，融对成功即计费，即便融对失败，也可根据用户补全的交易数据进行扣费，克服了现有技术中将用户未计费的行程直接按最远行程、最长时间计费的情况，保证产生的行程数据的准确性，减少了多扣交易费招致的用户投诉和少计交易费导致的地铁运营方收入损失。另外，用户可以在客户端直接补全交易数据，无需去人工解决，补票操作更加方便。若融对失败且在预设第二时间段未收到客户端发送补全交易数据，则按预设规则计算交易费，并向客户端发送扣费申请及禁止生成乘车码指令，不仅弥补了地铁运营商收入，还能通过禁止通行再次提醒用户补全交易数据。

实施例二

与实施例一相比，在另一些实施例中，可能存在出现网络故障的问题，比如表4中缺少用户丙在E站点的进站交易数据，此时与丙相关的交易数据如表6所示。

用户ID 丙 丙 丙 进出站类型 进 出 出 扫码时间 8：42 8：55 10：30 站点 B C A

表6

系统并不知道存在网络状态，仍然按照步骤S2执行，由于缺少与出站点A对应的进站交易数据，因此会按照单边交易规则挂起并向客户端发送补全交易数据指令。若用户丙补全了进站交易数据待融对时，网络又恢复了，用户丙在E站点的进站交易数据进入到系统，此时用户丙的交易数据恢复为表4，仍然选择从闸机上传的E站点的进站交易数进行融对，得到融对结果：站点E(进)-站点A(出)。可以理解的，若用户丙诚信，则用户丙自主补全的交易数据应该与从闸机上传的交易数据一致，若用户丙不诚信，则此方法能避免地铁运营商的损失。

实施例三

本实施例提出了一种地铁乘车码支付数据处理装置，如图2所示，包括数据接收模块101、融对计费模块102，其中：

数据接收模块101，用于接收从闸机采集并上传的交易数据，交易数据包括用户ID、进站交易数据和出站交易数据。

在本实施例中，数据接收模块101接收的交易数据包括乘车码信息(包括用户ID、扫码时间等)及闸机信息(闸机ID、闸机所在站点信息、闸机进出站类型等)，将进出站类型为进站、该闸机所在站点信息、扫码时间合称为进站交易数据，将进出站类型为出站、该闸机所在站点信息、扫码时间合称为出站交易数据数据。

融对计费模块102，对预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对，若融对成功，则计算交易费后向客户端提出扣费申请；若融对失败，则按照单边交易规则挂起并向客户端发送补全交易数据指令；若预设第二时间段未收到客户端发送补全交易数据，则按预设规则计算交易费，并向客户端发送扣费申请及禁止生成乘车码指令。

具体的，根据预设规则进行交易融对的方法包括：根据交易时间就近原则对出站交易数据和进站交易数据进行融对，或者同一用户ID对应的进站交易数据和出站交易数据分别仅有一条，则该进站交易数据和出站交易数据融对成功。

在另一些实施例中，数据接收模块101还用于接收用户通过的半自动售票机或客户端上传的补全的交易数据，以供融对计费模块102继续融对。

具体的，地铁乘车码支付数据处理装置的工作原理可以参考实施例一，在此不再赘述。

本发明提出了一种地铁乘车码支付数据处理装置，数据接收模块101接收数据处理设备从闸机采集并上传的交易数据，融对计费模块102对预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对。本发明中，计费在地铁乘车码支付数据处理装置中完成，克服了在设备侧计费兼容性差的问题，提高了计费成功率，提升了用户的使用体验；并且本发明的融对计费模块102对预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对，融对成功即计费，即便融对失败，也可根据用户补全的交易数据进行扣费，若预设第二时间段未收到客户端发送补全交易数据，则按预设规则计算交易费，并向客户端发送扣费申请及禁止生成乘车码指令，克服了现有技术中将用户未计费的行程直接按最远行程、最长时间计费的情况，保证产生的行程数据的准确性，减少了多扣交易费招致的用户投诉和少计交易费导致的地铁运营方收入损失。另外，用户可以在客户端直接补全交易数据，无需去人工解决，补票操作更加方便。

实施例四

本实施例提出了一种电子设备，如图3所示，包括存储器21，以及耦合到存储器21的处理器22，处理器22被配置为基于存储在存储器21中的指令，执行实施例一中的地铁乘车码支付数据处理方法。由于具体步骤在实施例一中已详细说明，在此不再赘述。该电子设备可以是移动设备、PC、服务器等。

实施例五

本实施例提出了一种地铁乘车码支付数据处理系统，如图4所示，包括交互设备31、数据处理设备32，其中：

交互设备31，包括与数据处理设备32连接的闸机311、客户端312。

客户端312用于生成供闸机311识别的乘车码，接受来自数据处理设备32的扣费申请，还用于接收数据处理设备32发送的补全交易数据的提示。用户可以在客户端312直接补全交易数据，无需去人工解决，补票操作更加方便。

闸机311，用于读取所述乘车码信息，生成交易数据并上传至数据处理设备32，交易数据包括用户ID、进站交易数据和出站交易数据。

数据处理设备32，分别与闸机311、客户端312连接，用于接收来自闸机311、客户端312上传的交易数据，并将预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对，若融对成功，则计算交易费后向客户端312提出扣费申请；若融对失败，则按照单边交易规则挂起并向客户端312发送补全交易数据指令；若预设第二时间段未收到客户端312发送补全交易数据，则按预设规则计算交易费，并向客户端312发送扣费申请及禁止生成乘车码指令。

具体的，用户进出地铁站时在客户端321生成乘车码供闸机311读取，闸机将读取的乘车码信息(包括用户ID、扫码时间等)及闸机信息(闸机ID、闸机所在站点信息、闸机进出站类型等)一起作为交易数据打包上传给数据处理设备。

数据处理设备32对接收的数据包按照用户ID进行分类，将预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对。在本实施例中，数据处理设备32将进出站类型为进站、该闸机所在站点信息、扫码时间合称为进站交易数据，将进出站类型为出站、该闸机所在站点信息、扫码时间合称为出站交易数据。融对的方法包括：根据交易时间就近原则对出站交易数据和进站交易数据进行融对，或者同一用户ID对应的进站交易数据和出站交易数据分别仅有一条，则该进站交易数据和出站交易数据融对成功等。若融对成功，则计算交易费后向客户端312提出扣费申请。若融对失败，则按照单边交易规则挂起并向客户端312发送补全交易数据指令。

用户在客户端312收到补全交易数据的提示后，可以直接在客户端补全进站点、出站点等相关数据并发给数据处理设备32继续进行融对操作。用户在客户端312直接补全交易数据，无需去人工解决，补票操作更加方便。

为了防止地铁运营的损失，用户若收到补全交易数据的提示后未补全信息，可暂停用户交易请求，数据处理设备32可以通知用户的客户端312禁止生成乘车码或通知闸机311禁止开闸。

在另一些实施例中，交互设备31还包括与数据处理设备32连接的设置于的半自动售票机313。当用户收到补全交易数据的提示后用户可以在半自动售票机313上补全交易数据，半自动售票机313会将补全的交易数据上传至数据处理设备32。

关于本实施例提出的地铁乘车码支付数据处理系统更详细的工作原理可以参考实施例一，在此不再赘述。

本发明提出的地铁乘车码支付数据处理系统，包括交互设备31、数据处理设备32，出站交易上传至数据处理设备32后，数据处理设备32将对预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对，融对成功后，计算交易费用并向客户端312发起扣费申请；未能成功融对时，则按照单边交易规则挂起并将向乘客的客户端312推送行程补全的提示；若预设第二时间段未收到客户端发送补全交易数据，则按预设规则计算交易费，并向客户端发送扣费申请及禁止生成乘车码指令。本发明的计费是在数据处理设备32完成，克服了在设备侧计费兼容性差的问题，提高了计费成功率，提升了用户的使用体验；并且本发明的数据处理设备32对预设第一时间段同一用户ID对应的进站交易数据与出站交易数据根据预设规则进行交易融对，融对成功即计费，即便融对失败，也可根据用户补全的交易数据进行扣费，若预设第二时间段未收到客户端发送补全交易数据，则按预设规则计算交易费，并向客户端发送扣费申请及禁止生成乘车码指令，克服了现有技术中将用户未计费的行程直接按最远行程、最长时间计费的情况，保证产生的行程数据的准确性，减少了多扣交易费招致的用户投诉和少计交易费导致的地铁运营方收入损失。另外，用户可以在客户端直接补全交易数据，无需去人工解决，补票操作更加方便。

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

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