卡数据交易处理方法、装置和设备

技术领域

本发明涉及信息处理技术领域，具体涉及一种卡数据交易处理方法、装置和设备。

背景技术

随着电子信息技术的发展，电子充值卡如公交充值卡的应用越来越广泛，使人们的生活更加便利。其中，例如对于公交充值卡的充值，当用户在充值设备如手机上对公交卡进行充值时，在支付成功后，需要将对应的金额写入到手机芯片内，在此操作过程中由于系统或芯片异常，可能会导致写入金额失败，这样就会造成扣了用户的钱，但是卡内的金额未给用户充值上，因此亟需一种提高充值识别，保证充值安全顺利进行的方法。

发明内容

为了至少在一定程度上解决上述技术问题，本发明提供一种卡数据交易处理方法、装置和设备。

第一方面，本申请实施例提供一种卡数据交易处理方法，包括：

响应于充值设备发送的实时充值指令，检测预设服务器中，是否存在与所述实时充值指令卡号相同的历史存疑订单；

若存在，则获取设备端交易信息，所述设备端交易信息为在所述充值设备中保存的充值成功的交易信息；

基于所述历史存疑订单的服务器端交易信息，和所述设备端交易信息，确定所述历史存疑订单的充值状态，其中，所述服务器端交易信息为在所述预设服务器中保存的交易信息。

可选地，所述获取设备端交易信息，包括：

基于applet技术生成控制指令；

将所述控制指令发送至所述充值设备中，供所述充值设备基于所述控制指令，向所述预设服务器返回所述设备端交易信息；

接收所述设备端交易信息。

可选地，所述设备端交易信息包括预设数量的交易订单信息；

所述交易订单信息包括：充值设备信息、充值卡号、交易计数器数值、充值时间和充值金额中的至少一种。

可选地，所述基于所述历史存疑订单的服务器端交易信息，和所述设备端交易信息，确定所述历史存疑订单的充值状态，包括：

若所述设备端交易信息中，存在与所述历史存疑订单的服务器端交易信息一致的交易订单信息，则修改所述历史存疑订单的充值状态为充值成功；

若所述设备端交易信息中，不存在与所述历史存疑订单的服务器端交易信息一致的交易订单信息，且所述历史存疑订单在所述预设服务器中的交易计数器数值小于所有所述设备端交易信息中的最小计算器数值，则确定所述历史存疑订单的充值状态仍为存疑；

若所述设备端交易信息中，不存在与所述历史存疑订单的服务器端交易信息一致的交易订单信息，且所述历史存疑订单在所述预设服务器中的交易计数器数值大于所有所述设备端交易信息中最小的计数器数值，则修改所述历史存疑订单的充值状态为充值失败。

可选地，还包括：

若所述设备端交易信息中，不存在与所述历史存疑订单的服务器端交易信息一致的交易订单信息，且所述设备端交易信息中所有的计数器数值均为零，则修改所述历史存疑订单的充值状态为充值失败。

可选地，还包括：

确定所述实时充值订单的充值状态是否为存疑；

对充值状态为充值失败的历史存疑订单重新进行充值，和对充值状态不为存疑和充值成功的实时充值订单进行充值。

可选地，还包括：将重新充值并成功充值后的历史存疑订单的充值状态，修改为充值成功。

可选地，还包括：

将预设服务器中的目标订单确定为重复订单，所述目标订单为与所述设备端交易信息中的设备信息、卡号和计数器信息相同，且订单号不同的订单。

第二方面，本申请实施例还提供一种数据交易处理装置，包括：

检测模块，用于响应于充值设备发送的实时充值指令，检测预设服务器中，是否存在与所述实时充值指令的卡号相同的历史存疑订单；

获取模块，用于获取设备端交易信息，所述设备端交易信息为在所述充值设备中保存的充值成功的交易信息；

计算模块，用于基于所述历史存疑订单的服务器端交易信息，和所述设备端交易信息，确定所述历史存疑订单的充值状态，其中，所述服务器端交易信息为在所述预设服务器中保存的交易信息。

第三方面，本申请还提供一种电子设备，包括存储器和处理器，以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时，实现如上述提到的卡数据交易处理方法。

本申请提供的卡数据交易处理方法包括：响应于充值设备发送的实时充值指令，检测预设服务器中，是否存在与实时充值指令卡号相同的历史存疑订单；若存在，则获取设备端交易信息；然后基于历史存疑订单的服务器端交易信息，和设备端交易信息，确定历史存疑订单的充值状态。如此，通过将服务器端和充值设备端的交易信息进行对比，快速准确判断存疑订单的状态，减少存疑订单的数量，使交易更加顺利安全进行。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。此外，这些附图和文字描述并不是为了通过任何方式限制本发明构思的范围，而是通过参考特定实施例为本领域技术人员说明本发明的概念。

图1为本申请实施例提供的卡数据交易处理方法的流程示意图；

图2为本申请实施例提供的卡数据交易处理方法中确定存疑的具体原理图；

图3为本申请另一实施例提供的卡数据交易处理方法的流程示意图；

图4为包含本申请提供的卡数据交易处理方法的充值流程图；

图5为包含本申请提供的卡数据交易处理方法的充值过程的原理示意图；

图6是本申请实施例提供的卡数据交易处理装置的结构示意图；

图7是本申请实施例提供的卡数据交易处理系统的结构示意图；

图8为本申请实施例提供的电子设备的结构示意图。

具体实施方式

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

方法实施例：

图1为本申请实施例提供的卡数据交易处理方法的流程示意图，如图1所示，本申请实施例提供的卡数据交易处理方法具体可以包括：

S101、响应于充值设备发送的实时充值指令，检测预设服务器中，是否存在与实时充值指令卡号相同的历史存疑订单。

具体的，实时充值指令可以是用户通过充值设备如手机等发起的，可以理解的是，实时充值指令用于为用户的电子卡如公交卡进行充值，所以该指令中必定包含与用户身份对应的信息，如充值卡号等。预设系统的服务器基于接收到用户发送的实时充值指令后，首先确定该指令的卡号，然后检测服务器端存储器内该卡号的交易信息，确定其中是否存在与该卡号相同的历史存疑订单，即无法判断是充值成功还是充值失败的历史订单。

S102、若存在，则获取设备端交易信息。

其中，设备端交易信息为在充值设备中保存的充值成功的交易信息。

具体的，设备端交易信息即为用户充值设备如手机等内部芯片或存储器中保存存储的交易信息，包括多笔交易订单信息，其中订单数量的多少可以是预先设置的，例如设备端最近10笔的交易订单信息，其中每笔交易订单信息可以包括该笔交易订单的详细信息，例如该笔交易订单的充值设备信息、充值卡号、交易计数器数值、充值时间和充值金额中等。

需要说明的是，充值设备中存储的交易信息即设备端交易信息一般仅包括该充值设备上交易成功的交易订单，所以上述设备端交易信息可以是充值设备端充值成功的交易信息。

在实际应用中，可以通过下发控制指令至充值设备上等方式，抓取获得设备端交易信息。

S103、基于历史存疑订单的服务器端交易信息，和设备端交易信息，确定历史存疑订单的充值状态。

其中，服务器端交易信息为在预设服务器中保存的交易信息。

具体的，在获取设备端交易信息后，将设备端交易信息与服务器中存储的与历史存疑订单对应的订单信息进行比对，从而判断确定历史存疑订单的充值状态。因为设备端交易信息均为充值成功的交易信息，所以可以在基于服务器端交易信息确定历史存疑订单后，以及基于该历史存疑订单在服务器端交易信息中的详细交易信息与设备端交易信息进行比对，当设备端交易信息中存在与历史存疑订单对应的交易信息时，可以确定该历史存疑订单的充值状态为充值成功；当设备端交易信息中不存在与历史存疑订单对应的交易信息时，可以确定该历史存疑订单的充值状态为充值失败。

本申请提供的卡数据交易处理方法，响应于充值设备发送的实时充值指令，检测预设服务器中，是否存在与实时充值指令卡号相同的历史存疑订单；若存在，则获取设备端交易信息；然后基于历史存疑订单的服务器端交易信息，和设备端交易信息，确定历史存疑订单的充值状态。如此，通过将服务器端和充值设备端的交易信息进行对比，快速准确判断存疑订单的状态，减少存疑订单的数量，使交易更加顺利安全进行。

在一些实施例中，在本申请提供的卡数据交易处理方法中，获取设备端交易信息的方式可以基于applet技术实现。

在实际应用中，当用户发起充值动作后，跳转到支付渠道，扣掉用户的钱，此时充值设备如手机内通过applet相关指令将数据写入芯片，因为是手机内部自行操作，若此时网络或进程中断，用户和服务器端均无法获知充值是否成功，导致业务流程中断。

所以本申请中，在确定存在历史存疑订单后，可以通过applet技术生成相应的控制指令，发送至充值设备中，从而供充值设备基于控制指令，读取芯片内的文件数据，再将与控制指令对应的数据返回发送至服务器中，实现服务器读取充值设备芯片内的文件内容。

其中，基于控制指令读取的文件数据，可以是针对公交卡等使用场所而确定的不同的文件类型，例如基于该地区公交卡的充值类型而确定，如针对一些只有线上充值的城市如北京，可以读取读手机设备中的18文件，其他城市如苏州和深圳可以读18与1F文等。

图2为本申请实施例提供的卡数据交易处理方法中确定存疑的具体原理图，如图2所示，基于历史存疑订单的服务器端交易信息，和设备端交易信息，确定历史存疑订单的充值状态，包括：若设备端交易信息中，存在与历史存疑订单的服务器端交易信息一致的订单信息，则修改历史存疑订单的充值状态为充值成功；若设备端交易信息中，不存在与历史存疑订单的服务器端交易信息一致的订单信息，且历史存疑订单在预设服务器中的交易计数器数值小于所有设备端交易信息中的计算器数值，则确定历史存疑订单的充值状态为存疑状态；若设备端交易信息中，不存在与历史存疑订单的服务器端交易信息一致的订单信息，且历史存疑订单在预设服务器中的交易计数器数值大于设备端交易信息中最小的计数器数值，则修改历史存疑订单的充值状态为充值失败；若设备端交易信息中，不存在与历史存疑订单的服务器端交易信息一致的订单信息，且设备端交易信息中所有的计数器数值均为零，则修改历史存疑订单的充值状态为充值失败。

具体的，例如获取的设备端交易信息包括最近10笔交易订单信息，其中每一笔交易订单信息可以包括交易卡号、交易计数器数值、交易时间和圈存金额(交易金额)。

其中，交易计数器数值在每进行一笔交易以后加一(服务器端和充值设备端均是)，所以可以根据交易计数器数值对各笔交易进行核对。

例如，首先基于本次获取的设备端交易信息中的10笔交易记录中，获取最大的计数器数值(cardseq)为最大计数器数值(maxCount)与最小的cardseq为最小计数器数值(mincount)，以及cardseq(圈存表中保存的圈存前交易联机交易序号)+1为当前的计数器数值count，然后进行如下判断：

1)当服务器端确定的历史存疑订单在设备端交易记录中存在信息卡号、圈存时间、金额、交易计数器数值(可以是联机交易序号)一致或匹配的订单信息，则可以判断该笔历史存疑订单的充值状态为为成功。

2)当服务器端确定的历史存疑订单在设备端交易记录中不存在信息卡号、圈存时间、金额、交易计数器数值(可以是联机交易序号)一致或匹配的订单信息，同时，count

3)当服务器端确定的历史存疑订单在设备端交易记录中不存在信息卡号、圈存时间、金额、交易计数器数值(可以是联机交易序号)一致或匹配的订单信息，同时，mincount<＝count或者mincount＝maxcount＝0说明未被覆盖且无记录，此时确定该历史存疑订单的充值状态为充值失败。

在一些实施例中，上述提到的用于计算判断的交易计数器数值可以是圈存前连接交易序号，也可以是交易成功后联机交易序号。在另一些实施例中，可以将获取的交易信息在服务器端存储，方便后续更快的进行和完成计算判断。如调用服务器端recharge(充值流水表)保存的数据(圈存前连接交易序号)，以及将从充值设备端获取交易成功后联机交易序号保存在recharge_record(充值记录表)表中。

在另一些实施例中，还可以对充值记录表中的数据增加invalid(是否有效)字段，1为有效0为无效，在做存疑判断时只查询其中的有效记录，从而在解绑后将卡的所有信息设置成无效，从而防止有重复卡号导致判断不正确、迁卡异常导致的问题，也可避免测试坏境重复使用卡号导致测试结果不正确的问题。

其中，如果圈存表(即在服务器端，用于保存之后用于计算判断的计数器数值，包括服务器自身中的交易计数器数值和从充值设备中获取的交易计数器数值的表)中保存的是交易前联机交易序号还是交易后联机交易序号，上述使用的交易前联机交易序号，如果使用的交易后联机交易序号不需要加一。

在本申请另一些实施例中，因为设备端还可以在接收到用户的实时充值指令后，对实时充值指令的充值状态进行检测确定。

具体的，可以通过与上述判断历史存疑订单的原理判断实时充值订单的充值状态，即从充值设备中获取设备端交易信息，基于设备端交易信息确定实时充值订单是否异常存疑。其中，获取设备端交易信息的方式以及判断实时充值订单的充值状态原理与上述实施例中的原理相同，在此不再进行赘述。

在实际应用中，随着服务器端接入的公交城市越来越多，各个区域公交的圈存异常处理都不一致，导致存疑订单可以判出圈存结果却未判出或存疑判断结果不正确的问题，因此重新规范统一圈存异常处理流程，便于日后维护，减少存疑状态的订单提高用户体验。所以，在本申请中，通过两端(充值设备端和服务器端)的数据对存疑订单进行在此判断，可以大大减少存疑订单的数量，加快后续处理流程。

图3为本申请另一实施例提供的卡数据交易处理方法的流程示意图，如图3所示，该实施例中，包括：

首先获取交易订单，并判断该订单是否为存疑订单。

若订单不是存疑订单，则直接进入正常订单处理流程，如在充值失败后进入充值流程，或在充值成功后结束充值并通知用户。

若订单为存疑订单，则对存疑订单进行再次判断，通过上述原理获取设备端交易信息，基于设备端交易信息，判断该存疑订单的充值状态，当其充值状态为充值成功时，将该订单的充值状态修改为充值成功，当其充值状态为充值失败时，将该订单的充值状态修改为充值失败，并将该订单加入退款队列中。

其中，对存疑订单进行再次判断的方式还可以是从Get signed Data指令中取出远程交易凭证，例如远程交易计数器值以及远程交易的TAC等，判断是否存在系统各端(充值设备端和服务器端)的交易计数器和TAC是否一致，若一致，则将存疑订单的充值状态修改为成功，若不一致，则修改订单的充值状态为充值失败，并将订单加入退款队列中。

在上述实施例的基础上，本申请还可以对上述最后确认为失败订单的订单进行再次充值，如对经再次判断后，最终充值状态为充值失败的历史存疑订单进行重新进行充值，和对充值状态不为存疑且充值没有成功的实时充值订单进行充值。以及对经重新充值并且充值成功后的订单的充值状态，修改为充值成功。

在上述实施例的基础上，本申请提供的卡数据交易处理方法中，还可以将服务器中订单进行筛选，将筛选得到的目标订单确定为重复订单，其中，重复订单为与设备端交易信息中的设备信息、卡号和计数器信息相同，且订单号不同的订单。

例如，从服务器端recharge表中将与从充值设备中订单信息中的当前cplc、卡号、cardseq相同但是订单号不同的记录查出来，确定为重复订单，以及将其状态设成失败并下发通知，供与本系统通信连接的充值系统进行后续的处理。

在一些实施例中，可以只在applet中只有18文件的公交中做此处理(北京、岭南通、苏州、深圳)，因为只有18文件的applet交易记录容易被消费记录覆盖，针对性的设置重复订单的检测，可以提前确认失败的订单，从而进一步提高用户体验。

另外，因为上述实施例的基础上，可以对响应于每个实时充值订单，获取设备端的交易信息，并在服务器端进行存储。所以针对某一个服务器中检测到的历史存疑订单，当实时单次获取预设数量如10条设备端的订单交易信息中，无法确定历史存疑订单的充值状态时，还可以通过检测经多次获取生成的recharge_record(响应于每个实时充值订单，获取设备端的交易信息，并在服务器端进行存储生成的充值记录表)，检测是否存在与历史存疑订单匹配的订单信息，从而判断该历史存疑订单的充值状态，判断过程与上述判断原理相同，即通过卡号、cardseq+1到recharge_record中查询记录(cardseq为圈存表中保存的圈存前交易计数器)，包括：

1)如果recharge_record中存在与该历史存疑订单在服务器端订单信息记录卡号、圈存时间、金额一致的订单，则可以判断该历史存疑订单的充值状态为成功。

2)如果记录不存在状态仍为存疑(该比交易可能未上传至服务器)

3)如果存在记录时间或金额等不一致可判断为失败。

图4为包含本申请提供的卡数据交易处理方法的充值流程图，如图4所示，该充值方法可以包括：

首先，接收当前充值订单，服务器端生成下发获取最近10条圈存交易记录的指令；

然后，将获取的数据保存至服务器端的recharge_record中。

再检测服务器端是否存在历史存疑订单，即判断是否有上一笔存疑订单。

若存在上一笔存疑订单，则通过上述图3中的方案，对存疑订单进行判断，在确定其充值状态后或不存在存疑订单时，进行下一步骤。

检测当前订单是否存疑，若为存疑则仍然基于上述图3中的方案，确定当前订单的充值状态。

若当前订单不存疑且未充值成功，或经上述图3中的方案确定当前订单为充值失败，则进行充值，包括获取充值平台的MAC2或直接获取远程交易MAC值，进行充值。

若当前订单为存疑，经上述图3中的方案中确认结果为充值成功，或者仍然无法判断是否充值成功，则直接结束流程。

其中，上述过程包括了服务器端与充值设备端的数据交互，需要充值设备端基于控制指令向服务器端返回数据，若在服务器端下发指令后断网或无结果返回(此时订单的充值状态为存疑)，此时还可以重试，即重新发送相关指令，直至有数据返回。

图5为包含本申请提供的卡数据交易处理方法的充值过程的原理示意图，如图5所示，公交卡的充值全过程分为两种，第一类卡需要充值平台进行对应操作(图5中的a部分)，第二类卡不需要充值平台进行对应操作(图5中的b部分)，具体包括：

对于第一类卡的充值，首先判断订单的有效性，若订单有效，在确认订单重试逻辑后，生成获取卡信息的指令，发送至充值设备中，供充值设备执行指令并向服务器返回数据结果；检测和确认是否存在上一笔存疑的圈存交易，以及确认当前充值订单的状态，再向通卡请求充值MAC2，充值平台验证MAC2计算MAC2后，生成充值指令并发送至充值设备，供充值设备执行充值指令，完成充值，以及更新订单的状态为充值成功，并通知通卡和供用户确认充值成功。

对于第二类卡的充值，首先判断订单的有效性，若订单有效，在确认订单重试逻辑后，生成获取卡信息的指令，发送至充值设备中，供充值设备执行指令并向服务器返回结果；检测和确认是否存在上一笔存疑的圈存交易，以及确认当前充值订单的状态，再计算远程充值MAC，生成充值指令并发送至充值设备，供充值设备执行充值指令，完成充值，以及更新订单的状态为充值成功，并通知通卡和供用户确认充值成功。

装置实施例：

基于同一个发明构思，本申请实施例还提供一种卡数据交易处理装置，图6是本申请实施例提供的卡数据交易处理装置的结构示意图，如图6所示，该装置包括：

检测模块61，用于响应于充值设备发送的实时充值指令，检测预设服务器中，是否存在与实时充值指令的卡号相同的历史存疑订单；

获取模块62，用于获取设备端交易信息，设备端交易信息为在充值设备中保存的充值成功的交易信息；

计算模块63，用于基于历史存疑订单的服务器端交易信息，和设备端交易信息，确定历史存疑订单的充值状态，其中，服务器端交易信息为在预设服务器中保存的交易信息。

上述卡数据交易处理装置的原理，已经在卡数据交易处理方法中进行了详细介绍，可以参考卡数据交易处理方法进行理解，此处不再赘述。

系统实施例：

基于同一个发明构思，本申请实施例还提供一种卡数据交易处理系统，图7是本申请实施例提供的卡数据交易处理系统的结构示意图，如图7所示，该装置包括：服务器71即核心系统，和多个充值设备72；

服务器71与预设充值平台73和多个充值设备72通信连接，用于执行上述方法实施例中提到的卡数据交易处理方法。

其中，所述服务器71中至少包括存储器，所述充值设备72中至少包括芯片和芯片存储器。

上述卡数据交易处理系统的原理，已经在卡数据交易处理方法中进行了详细介绍，可以参考卡数据交易处理方法进行理解，此处不再赘述。

电子设备实施例：

基于同一个发明构思，本申请还提供一种电子设备，图8为本申请实施例提供的电子设备的结构示意图，如图8所示，该电子设备包括存储器81和处理器82以及存储在存储器81上并可在处理器82上运行的计算机程序，其中，该计算机程序被处理器82执行时，实现如上述方法实施例中提供的卡数据交易处理方法。

本申请实施例提供的电子设备的具体实施方案可以参考以上任意实施例的卡数据交易处理方法的实施方式，此处不再赘述。

可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。

需要说明的是，在本发明的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本发明的描述中，除非另有说明，“多个”的含义是指至少两个。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本发明各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。