CN114282892B

CN114282892B - 一种基于sdk补登的方法、地铁客户端及系统

Info

Publication number: CN114282892B
Application number: CN202111580769.1A
Authority: CN
Inventors: 吕博; 陈思宇; 何东树; 邹世清; 唐波
Original assignee: Chengdu Zhiyuanhui Information Technology Co Ltd
Current assignee: Chengdu Zhiyuanhui Information Technology Co Ltd
Priority date: 2021-12-22
Filing date: 2021-12-22
Publication date: 2023-05-02
Anticipated expiration: 2041-12-22
Also published as: CN114282892A

Abstract

本发明公开了一种基于SDK补登的方法、地铁客户端及系统，应用于城市B的地铁客户端中的SDK，所述SDK用于与城市A的互联互通服务器进行通信，具体包括以下步骤：S1、获取城市A的待补登行程；S2、根据所述城市A的待补登行程向所述城市A的互联互通服务器发送补登请求；S3、接收城市A的互联互通服务器返回的补登结果，所述补登结果生成过程为：城市A的MLC系统根据城市A的互联互通服务器转送的补登请求，进行补登、融对处理，并将补登结果通过城市A的互联互通服务器保存并返回至SDK。本发明通过解决在“二维码通行”互联互通过程中的如何补登的问题，以省去直接下载新的APP或异地现场补登的过程，进而实现城市之间互联互通。

Description

一种基于SDK补登的方法、地铁客户端及系统

技术领域

本发明涉及轨道交通技术领域，具体涉及一种基于SDK补登的方法、地铁客户端及系统。

背景技术

基于“二维码通行”的互联互通方案，不仅是通过互联技术助力克服了不同省市闸机硬件的差异，也在某种程度上跨越了各地居民的心理距离。在互联互通的区域方位内，用户不用再下载一个新的APP或在异地购票系统进行购票，提高了用户交通服务效率。在实际应用中，有时由于乘客误操作例如在进站或者出站时忘记刷乘车码，就会产生单边行程，而基于单边行程导致后续产生单边订单，所谓单边订单是指只有单边行程记录(只有进站记录或者只有出站记录)的订单；有时也会由于公共交通的网络异常导致用户进站记录或者出站记录丢失，导致后台无法匹配生成一笔正常的乘车订单，就会导致产生单边订单；而针对单边订单的费用进行扣费，因此，如何减少单边订单的生成，提高用户行程匹配的准确率，成为一个互联互通过程中亟待解决的问题。由于“二维码通行”互联互通工作存在着各地公共交通建设标准不统一、普及程度不同的问题，本发明解决在“二维码通行”互联互通过程中的如何补登的问题，以省去直接下载新的APP或异地现场补登的过程，进而实现城市之间互联互通。

发明内容

本发明的目的在于提供一种基于SDK补登的方法、地铁客户端及系统，通过在所在地的APP内集成SDK，通过SDK与目标城市的轨道交通服务器进行通信，实现补登的功能，解决“刷码过闸”过程中用户行程订单中没有进站或出站的消息，提升交通出行体验。用以解决现有“二维码通行”互联互通过程中的如何补登的问题。

一种基于SDK补登的方法，应用于城市B的地铁客户端中的城市A的SDK，所述城市A的SDK用于通过城市A的互联互通服务器与城市A的MLC系统进行通信，当用户通过城市B的地铁客户端唤起城市A的SDK，并进入城市A的SDK的行程列表页面选择城市A的待补登行程时，由所述城市A的SDK执行以下步骤：

S1、获取城市A的待补登行程；

S2、根据所述城市A的待补登行程通过所述城市A的互联互通服务器向城市A的MLC系统发送补登请求；

S3、接收城市A的互联互通服务器转发的由城市A的MLC系统进行行程补登、行程融对后生成的补登结果。

进一步地，所述城市A的SDK通过城市A的互联互通服务器、城市A的MLC系统与支付渠道进行通信，所述城市A的SDK向城市A的互联互通服务器发送查询订单请求；接收城市A的互联互通服务器返回的订单结果，所述订单结果为由城市A的MLC系统进行行程补登、行程融对和扣费处理后生成的补登结果，以及由城市A的MLC系统进行补登、融对后向支付渠道发起扣费请求后，推送的由支付渠道异步回调的扣费结果组成。

进一步地，还包括，所述待补登行程携带补登信息，所述城市A的MLC系统的行程补登、行程融对为：

根据所述城市A的待补登行程，确定城市A的待补登行程中的补登信息是否有效；

当所述补登信息有效时，基于所述补登信息结合所述城市A的待补登行程进行行程订单匹配。

进一步地，还包括，所述确定补登信息是否有效具体包括：

确认所述城市A的待补登行程是否超过预设的有效期限：

若超过，则确认所述城市A的待补登行程无效；

若未超过，则确认用户的补登请求是否超过预设次数：

若超过，则确认所述城市A的待补登行程无效；

若为超过，则确认所述城市A的待补登行程有效。

进一步地，还包括，所述城市A的SDK还用于接收城市A的互联互通服务器每隔预设周期下发的提醒补登的消息，并根据所述提醒补登的消息展示需要补登的乘车记录与截止时间。

进一步地，所述提醒补登的消息由所述城市A的互联互通服务器对行程订单的进行查询，当发现用户的行程订单没有进站或出站的消息时生成。

进一步地，所述城市A的SDK在进行补登前需完成异地乘车二维码服务的支付渠道代扣签约，具体包括以下步骤：

Sa、根据异地乘车二维码的请求，向城市A的互联互通服务器发送查询是否签约的请求；

Sa、根据城市A的乘车二维码的请求，向城市A的互联互通服务器发送查询是否签约的请求；

Sb、接收城市A的互联互通服务器返回的签约信息；

Sc、若所述签约信息指示用户未完成支付渠道代扣签约，则跳转签约页面，显示可签约的支付渠道；

Sd、获取用户选定的支付渠道，根据所选定的支付渠道对应的签约流程及要求，跳转到所述选定的支付渠道的支付签约页面；

Se、接收由支付渠道通过城市B的地铁客户端同步返回的签约结果；

Sf、通过所述城市A的互联互通服务器向支付渠道发送查询签约结果的请求；

Sg、通过所述城市A的互联互通服务器接受所述支付渠道返回的结果。

进一步地，当城市B的地铁客户端的用户成功完成支付渠道的支付代扣签约后，所述城市A的SDK还包括支付代扣解约的处理，具体包括以下步骤：

Sa、获取待解约的支付方式；

Sb、根据所述待解约的支付方式，通过城市A的互联互通服务器向支付渠道发送解约请求；

Sc、向所述城市A的互联互通服务器发送查询解约结果的请求；

Sd、接收城市A的互联互通服务器返回的由支付渠道异步回调的解约结果。

进一步地，一种基于SDK补登的城市B的地铁客户端,包括：

城市B的地铁客户端，集成在城市B的地铁客户端中的一个或多个其他城市的SDK，

所述城市B的地铁客户端用于：当用户通过城市B的地铁客户端进入异地乘车二维码界面时，弹出一个或多个其他城市列表的页面，获取一个或多个其他城市列表的页面的触发信号，进入指定的城市的乘车二维码页面，唤起指定的城市的SDK；

所述一个或多个其他城市的SDK用于：当用户通过城市B的地铁客户端唤起指定的城市的SDK，并进入所述指定的城市的SDK的行程列表页面选择指定的城市的待补登行程时，通过所述指定的城市的互联互通服务器与所述指定的城市的MLC系统进行通信，根据种基于SDK补登的方法，进行补登。

进一步地，一种基于SDK补登的系统，包括：

城市B的地铁客户端，集成在城市B的地铁客户端中的一个或多个其他城市的SDK，一个或多个城市的互联互通服务器，其中：

所述一个或多个其他城市的SDK用于：当用户通过城市B的地铁客户端唤起指定的城市的SDK，并进入所述指定的城市的SDK的行程列表页面选择指定的城市的待补登行程时，通过所述指定的城市的互联互通服务器与所述指定的城市的MLC系统进行通信，根据基于SDK补登的方法，进行补登；

一个或多个城市的互联互通服务器用于：实现指定的城市的SDK与指定的城市的MLC系统之间的通信；

当用户通过城市B的地铁客户端进入城市B的行程列表页面并选择城市A的待补登行程时，通过城市B的服务器与城市B的MLC系统进行通信，进行补登,数据的路线为：城市B的地铁客户端--城市B的服务器--城市B的MLC系统--支付渠道；

当用户通过城市B的地铁客户端唤起指定的城市的SDK时，并进入所述指定的城市的SDK的行程列表页面选择指定的城市的待补登行程时，通过所述指定的城市的互联互通服务器与所述指定的城市的MLC系统进行通信，根据基于SDK补登的方法，进行补登，城市B的地铁客户端--指定的城市的SDK--指定的城市的互联互通服务器--指定的城市的的MLC系统--支付渠道。

本发明具有的有益效果：

本发明通过基于SDK的补登方法，解决在现有“一码通行”互联互通过程中，在发现单边行程记录时，城市A的MLC系统通过城市A的互联互通服务器向SDK下发提醒消息--客户端通过SDK发送待补登形成并通过城市A的互联互通服务器转发至城市A的MLC系统--城市A的MLC系统补登处理并反馈结果，通过行程补登减少了单边订单，通过对补登信息进行补登融对，提高了用户行程匹配的准确度，避免了单边订单扣费高于真实行程费用导致的用户投诉，也避免了单边订单金额低于真实行程费用导致公共交通服务方收益受损。

附图说明

图1为本发明的基于SDK补登的方法流程示意图；

图2为本发明的基于SDK的互联互通示意图；

图3为本发明的基于SDK补登的系统示意图；

图4为本发明的实施例1的西安地铁与成都地铁互联互通示意图；

图5为本发明的实施例1的西安地铁用户漫游到成都签约支付方式示意图；

图6为本发明的实施例1的西安地铁用户漫游到成都支付代扣解约示意图；

图7为本发明的实施例1的西安地铁用户漫游到成都补登示意图；

具体实施方式

下面结合实施例及附图，对本发明作进一步的详细说明，但本发明的实施方式不限于此。

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖向”、“纵向”、“侧向”、“水平”、“内”、“外”、“前”、“后”、“顶”、“底”等指示的方位或位置关系为基于附图所示的方位或位置关系，或者是该发明产品使用时惯常摆放的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。

在本发明的描述中，还需要说明的是，除非另有明确的规定和限定，术语“设置”、“开有”、“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

对于本方案中可能会使用到的一些名称、缩略语定义和解释如下表。

以下实施例中所使用的名词与说明书中的名词对应如下：

城市B的地铁客户端——西安地铁APP，城市A的SDK——成都地铁SDK，城市A的互联互通服务器——成都地铁APP后台，城市A的MLC系统——成都地铁MLC系统。

实施例1

本发明的地铁票务互联互通方法，以西安与成都的地铁业务场景及流程进行说明：

1.成都地铁乘车码服务开通

西安地铁APP用户进入乘车码页面，选择切换到成都乘车码页面，通过成都地铁SDK向成都地铁APP后台、MLC系统发起生码授权请求。若该用户未开通成都地铁乘车码服务，则需先开通成都地铁乘车码服务，注册成为成都地铁用户。西安地铁APP调用成都地铁SDK，将用户实名注册信息同步给成都地铁APP后台--成都地铁MLC系统，完成该用户在成都地铁APP后台、MLC上的乘车码业务注册开通，并在西安地铁APP界面上提示开通成功。

2.支付渠道代扣签约

成都地铁乘车码服务开通成功后，唤起需签约的支付渠道签约页面，按照支付渠道的签约流程、页面提示完成支付签约。

3.请码及生码

西安地铁APP用户完成成都地铁乘车码服务开通以及支付签约后，即可发起成都乘车码申请，按西安地铁APP--成都地铁SDK--成都地铁APP后台--成都地铁MLC系统完成生码授权数据的请求，成都地铁SDK根据成都地铁乘车码生码要求进行生码并展示成都地铁乘车码。

4.扫码进出站、行程匹配及计费、扣款

用户使用西安地铁APP展示的成都地铁乘车码，在成都地铁的AGM上扫码进站、出站。成都地铁AGM将用户的进、出站过闸数据上传给成都地铁MLC系统，MLC系统推送进、出站过闸数据到成都地铁APP后台。

在用户完成出站后，成都地铁MLC系统匹配完整用户行程，并进行程计费、生成行程订单，然后成都地铁MLC系统向该用户签约的支付渠道发起扣款，记录扣款结果，MLC系统推送OD及扣费信息数据到成都地铁APP后台。

西安地铁APP唤起成都地铁SDK，查看用户在成都地铁的乘车记录、扣款信息。

成都地铁和西安地铁乘车码互连互通的主要业务流程及功能实现原理一致，持成都地铁APP或西安地铁APP的用户到对方城市进行乘车按同样的接口交互，以下仅以西安地铁APP用户漫游到成都地铁乘车流程举例说明。

一、支付渠道代扣签约

西安地铁APP的用户成功完成成都地铁乘车码服务开通后，申请乘车二维码前需完成成都地铁乘车码服务的支付渠道代扣的签约，才能请码成功。支付渠道代扣签约的流程如下：

具体实现流程说明如下：

1.西安地铁APP通过成都地铁SDK向成都地铁APP后台请求生码授权数据，成都地铁APP后台校验该用户的支付代扣签约关系,若该用户未完成成都地铁的支付签约，则直接返回用户未完成支付签约，要求用户完成成都地铁的支付签约。

2.成都地铁SDK，显示成都地铁可签约的支付渠道，用户选择一种支付渠道进行支付代扣签约。

3.成都地铁SDK根据所选择的支付渠道，根据支付渠道的签约流程、要求跳转到微信或支付宝的支付签约页面，用户同意授权并按流程完成支付签约后，微信或支付宝将签约结果回调返回给成都地铁APP后台。

4.成都地铁APP后台保存用户的签约关系，并将用户在成都地铁支付渠道商户号上的签约信息同步给MLC系统。

5.用户可在成都地铁SDK中，根据成都地铁支持的支付渠道，选择一种或多种完成签约，并支持设置支付方式的扣款顺序。

二、用户支付渠道代扣解约

西安地铁APP的用户成功完成微信、支付宝支付签约代扣后，可进行支付代扣解约。解约的流程如下：

具体实现流程说明如下:

1.西安地铁APP唤起成都地铁SDK，用户进入支付渠道支付代扣列表页面，选择支付方式进行解约；

2.成都地铁SDK请求成都地铁APP后台解约接口，成都地铁APP后台根据该请求进行判定：

当无进行中的行程或者非异常行程时，成都地铁APP后台向微信或支付宝或发起解约。

当有进行中的行程或者异常行程时(如待补登、扣费失败等)时，不允许解约。

3.成都地铁APP后台收到微信或支付宝解约回调结果，并保存此次解约结果。然后同步到成都地铁MLC系统。

4.成都地铁SDK可通过成都地铁APP后台查询用户解约信息，并进行用户状态的刷新。

三、用户补登

针对单边行程，西安地铁APP的用户可通过成都地铁SDK发起补登操作，流程如下：

具体实现流程说明如下:

1.用户进入行程列表，选择待补登行程；

2.成都地铁SDK请求成都地铁APP后台补登接口，成都地铁APP后台向MLC发起补登请求。

3.MLC系统收到补登请求后，补登行程并进行行程融对和扣费。

4.MLC系统在收到支付渠道的扣费回调后，将扣费信息推送至成都地铁APP后台。

5.成都地铁SDK可通过成都地铁APP后台查询用户行程及扣费信息。

如上述方案所述，成都西安乘车码互联互通按照双方提供SDK的方式进行对接的方案，由双方SDK提供相关乘车码能力接口，实现两城乘车码业务的互连互通。因此要求双方的地铁APP后台、APP、SDK应具备以下主要功能：

地铁APP

西安地铁APP需实现用户直接持西安地铁APP生成成都地铁乘车码，以实现在成都地铁扫码过闸，其主要功能包括：

1.城市切换：互通城市乘车码切换，支持选择并切换到成都地铁乘车码请码页面；

2.接入SDK：地铁APP需接入互通城市的SDK，由SDK完成注册、签约、拉码等功能；

地铁SDK

地铁SDK应具备向互通城市地铁APP提供实名、签约、生码、补登等接口的能力，并能够兼容互通城市地铁APP，主要功能包括：

1.服务开通：对于首次请求互通城市地铁乘车码的用户，需实现成都地铁乘车码服务授权协议用户注册；

2.支付渠道代扣签约：对于未进行互通城市地铁支付渠道代扣签约的，支持引导用户完成地铁支付渠道代扣签约；已完成支付签约的支持进行解约或新增其他的支付渠道代扣签约；

3.地铁乘车码获取及展示：获取、安全存储互通城市地铁乘车码的生码授权数据，并实现地铁乘车码的生成及展示。

4.补登：针对单边行程，地铁SDK需提供补登功能。

地铁APP后台

地铁APP后台应具备乘车码的输出能力，以实现向互通城市地铁APP进行互联互通对接，实现地铁APP用户在互通城市地铁的扫码过闸。因此要求地铁APP后台具备以下乘车码互通功能：

1.实现对地铁APP用户的实名乘车码服务开通/关闭、支付渠道代扣签约/解约；

2.具备对互通城市APP用户在本平台的实名信息管理；

3.提供落地城市生码风控控制、生码授权接口等功能；

4.支持对互通城市地铁APP(如成都地铁)用户的风控控制、行程订单支付扣款、查询等功能；

5.支持对互通城市地铁APP用户乘车码交易的交易业务对账。

6.支持按地铁二维码业务流程、票务规则实现对互通城市APP用户(如成都地铁APP)在本城市扫码过闸的交易处理，包括扫码过闸数据上传、OD匹配、订单生成、订单计费等交易处理，提供互通城市APP用户的乘客事务处理。

具体的，本发明的地铁票务互联互通方法基于SDK与互联互通服务器进行通信的原理如下：

应用于系统的地铁APP，所述系统还包括至少一个互联互通服务器，所述方法包括：获取消息推送的请求，所述消息推送的请求包括指定互联互通服务器标识；基于所述指定互联互通服务器确定指定端口，若所述指定端口与指定SDK组件连接，则基于所述指定端口将待推送消息通过所述指定SDK组件发送至所述指定互联互通服务器；若所述指定端口没有连接指定SDK组件，则基于所述指定端口将待推送消息直接发送至所述指定互联互通服务器。

指定端口可以是客户端的一个端口，具体地，该端口是一个数据端口，该端口是一个API接口，该数据端口用于将数据按照一定格式打包，并且将打包之后的数据发送至与该端口连接的SDK组件或其他模块。。

该地铁APP内存储有连接对应表，该连接对应表用于记录每个端口对应的互联互通服务器标识。通过该连连接对应表能够确定该消息推送请求内的指定互联互通标服务器标识对应的端口标识，确定该端口标识所连接的SDK组件，进而确定指定互联互通服务器标识对应的指定SDK组件。

其中，SDK(Software Development Kit)组件，一般为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合。具体地，SDK组件内集成有多个应该访问接口，则地铁APP能够通过所集成的访问接口与互联互通服务器连接。并且，该地铁APP至少包括一个SDK组件。

具体的一种实施方式中，所述消息推送的请求为待补登行程的请求，在基于“二维码通行”的互联互通方案中，各地二维码乘地铁业务流程差别大，无法衔接，存在新的密钥管理体系、新的发卡机构和发码机构管理体系等诸多不同之处，因为涉及移动支付功能，不同的经营主体采用不同的密钥体系区隔，二维码生成体系标准不同造成的技术壁垒，因此持本地的乘车二维码乘地铁的业务区外地刷码通行的处理复杂度高。目前主要采用由各线路集成商在闸机系统的上位机进程里实现所有的二维码业务，并由上位机直接对接地铁票务平台。由于二维码乘车业务的复杂性和多变性，需要对不同厂商的上位机进程进行改造，以实现与二维码乘车业务后台的对接。但这种改造成本很高，工期很长，导致地铁各线路集成商接入二维码乘车业务后台的难度很大。

在本方案中，在每个SDK组件内，集成指定的城市的互联互通服务器与地铁APP之间的通信协议，因此该SDK组件可以用于实现指定的城市的互联互通服务器与地铁APP之间的数据交互和通信。因此可以在地铁APP内集成一个或多个SDK组件，以使指定的城市的SDK组件通过指定的城市的互联互通服务器与指定的城市的MLC系统通信，从而完成异地行程的补登。

在本方案中，在每个SDK组件内，集成指定的城市的互联互通服务器与地铁APP之间的通信协议，因此该SDK组件可以用于实现指定的城市的互联互通服务器与地铁APP之间的数据交互和通信。因此可以在地铁APP内集成一个或多个SDK组件，以使指定的城市的SDK组件通过指定的城市的互联互通服务器与指定的城市的MLC系统通信，从而完成异地乘车二维码的执行交易。

指定SDK组件是集成在地铁APP内的，且地铁APP内安装在用户终端内，并且用户终端内包括用于存储该地铁APP的数据的存储空间，指定SDK组件能够将待推送消息存储至地铁APP对应的存储空间内，并且通知地铁APP，该待推送信息已经存储至地铁APP内对应的存储空间内，该地铁APP可以通过该存储空间获取到该待推送消息。

因此，地铁APP将异地乘车二维码请求发送至指定SDK组件，由指定SDK组件将该异地乘车二维码请求通过指定端口发送至指定互联互通服务器，通过指定的互联互通服务器与MLC系统通信。

以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，依据本发明的技术实质，在本发明的精神和原则之内，对以上实施例所作的任何简单的修改、等同替换与改进等，均仍属于本发明技术方案的保护范围之内。

Claims

1.一种基于SDK补登的方法，其特征在于，应用于城市B的地铁客户端中的城市A的SDK，所述城市A的SDK用于通过城市A的互联互通服务器与城市A的MLC系统进行通信，所述城市A的SDK通过城市A的互联互通服务器、城市A的MLC系统与支付渠道进行通信，所述城市A的SDK向城市A的互联互通服务器发送查询订单请求；接收城市A的互联互通服务器返回的订单结果，所述订单结果为由城市A的MLC系统进行行程补登、行程融对和扣费处理后生成的补登结果，以及由城市A的MLC系统进行补登、融对后向支付渠道发起扣费请求后，推送的由支付渠道异步回调的扣费结果组成；

当用户通过城市B的地铁客户端唤起城市A的SDK，并进入城市A的SDK的行程列表页面选择城市A的待补登行程时，由所述城市A的SDK执行以下步骤：

S1、获取城市A的待补登行程；

2.根据权利要求1所述的一种基于SDK补登的方法，其特征在于，还包括，所述城市A的MLC系统的行程补登、行程融对为：

3.根据权利要求2所述的一种基于SDK补登的方法，其特征在于，还包括，所述确定补登信息是否有效具体包括：

确认所述城市A的待补登行程是否超过预设的有效期限：

若超过，则确认所述城市A的待补登行程无效；

若未超过，则确认用户的补登请求是否超过预设次数：

若超过，则确认所述城市A的待补登行程无效；

若为超过，则确认所述城市A的待补登行程有效。

4.根据权利要求1所述的一种基于SDK补登的方法，其特征在于，还包括，所述城市A的SDK还用于接收城市A的互联互通服务器每隔预设周期下发的提醒补登的消息，并根据所述提醒补登的消息展示需要补登的乘车记录与截止时间。

5.根据权利要求4所述的一种基于SDK补登的方法，其特征在于，所述提醒补登的消息由所述城市A的互联互通服务器对行程订单的进行查询，当发现用户的行程订单没有进站或出站的消息时生成。

6.根据权利要求1所述的一种基于SDK补登的方法，其特征在于，所述城市A的SDK在进行补登前需完成异地乘车二维码服务的支付渠道代扣签约，具体包括以下步骤：

Sb、接收城市A的互联互通服务器返回的签约信息；

7.根据权利要求6所述的一种基于SDK补登的方法，其特征在于，当城市B的地铁客户端的用户成功完成支付渠道的支付代扣签约后，所述城市A的SDK还包括支付代扣解约的处理，具体包括以下步骤：

Sa、获取待解约的支付方式；

8.一种基于SDK补登的地铁客户端,其特征在于，包括：

城市B的地铁客户端，集成在城市B的地铁客户端中的一个或多个其他城市的SDK；

所述一个或多个其他城市的SDK用于：当用户通过城市B的地铁客户端唤起指定的城市的SDK，并进入所述指定的城市的SDK的行程列表页面选择指定的城市的待补登行程时，通过所述指定的城市的互联互通服务器与所述指定的城市的MLC系统进行通信，根据权利要求1-7任意所述的一种基于SDK补登的方法，进行补登。

9.一种基于SDK补登的系统，其特征在于，包括：

所述一个或多个其他城市的SDK用于：当用户通过城市B的地铁客户端唤起指定的城市的SDK，并进入所述指定的城市的SDK的行程列表页面选择指定的城市的待补登行程时，通过所述指定的城市的互联互通服务器与所述指定的城市的MLC系统进行通信，根据权利要求1-7任意所述的一种基于SDK补登的方法，进行补登；

当用户通过城市B的地铁客户端唤起指定的城市的SDK时，并进入所述指定的城市的SDK的行程列表页面选择指定的城市的待补登行程时，通过所述指定的城市的互联互通服务器与所述指定的城市的MLC系统进行通信，根据权利要求1-7任意所述的一种基于SDK补登的方法，进行补登，城市B的地铁客户端--指定的城市的SDK--指定的城市的互联互通服务器--指定的城市的的MLC系统--支付渠道。