CN114358930A

CN114358930A - 一种基于sdk获取异地乘车二维码执行交易的方法、地铁客户端及系统

Info

Publication number: CN114358930A
Application number: CN202111580793.5A
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: 2022-04-15
Anticipated expiration: 2041-12-22
Also published as: CN114358930B

Abstract

本发明公开了一种基于SDK获取异地乘车二维码执行交易的方法、地铁客户端及系统，具体包括以下步骤：S2、根据所述城市A的乘车二维码的请求，生成城市A的乘车二维码并展示，所述城市A的乘车二维码用于用户在城市A的AGM有效读写区域内进行扫码过闸，以使所述城市A的MLC系统根据城市A的AGM上传的扫码过闸交易数据进行OD行程匹配及扣费；S3、向城市A的互联互通服务器发送查询用户行程订单及行程计费订单的请求；S4、接收由城市A的互联互通服务器返回的由城市A的MLC系统生成的用户行程订单及行程计费订单并进行展示。本发明通过获取城市A的乘车二维码的请求，解决互联互通过程中扫码过闸等执行交易的过程，从而提升出行体验。

Description

一种基于SDK获取异地乘车二维码执行交易的方法、地铁客户端及系统

技术领域

本发明涉及轨道交通技术领域，具体涉及一种基于SDK获取异地乘车二维码执行交易的方法、地铁客户端及系统。

背景技术

基于“二维码通行”的互联互通方案，不仅是通过互联技术助力克服了不同省市闸机硬件的差异，也在某种程度上跨越了各地居民的心理距离。在互联互通的区域方位内，用户不用再下载一个新的APP或在异地购票系统进行购票，提高了用户交通服务效率。由于“二维码通行”互联互通工作存在着各地公共交通建设标准不统一、普及程度不同的问题，目前各地二维码乘地铁业务流程存在差别大，无法衔接的问题，存在新的密钥管理体系、新的发卡机构和发码机构管理体系等诸多不同之处，因此持城市A的乘车二维码乘地铁的业务处理复杂度高。目前主要采用由各线路集成商在闸机系统的上位机进程里实现所有的二维码业务，并由上位机直接对接二维码乘车业务后台。由于二维码乘车业务的复杂性和多变性，需要对不同厂商的上位机进程进行改造，以实现与二维码乘车业务后台的对接。但这种改造成本很高，工期很长，导致地铁各线路集成商接入二维码乘车业务后台的难度很大。因此本发明解决在“一码通行”互联互通过程中的生成城市A的乘车二维码如何验证扫码过闸的问题，以省去直接下载新的APP或异地现场购票的过程，避免改造闸机硬件的问题，进而实现城市之间互联互通。

发明内容

本发明的目的在于提供一种基于SDK获取异地乘车二维码执行交易的方法、地铁客户端及系统，通过在所在地的APP内集成SDK，通过SDK与目标城市的互联互通服务器进行通信，完成交易过程，从而实现“刷码过闸”，提升交通出行体验。用以解决现有“一码通行”互联互通过程过程中的基于异地乘车二维码执行交易的问题。

一种基于SDK获取异地乘车二维码执行交易的方法，应用于城市B的地铁客户端中的城市A的SDK，所述城市A的SDK用于通过城市A的互联互通服务器与城市A的MLC系统进行通信，当用户通过城市B的地铁客户端进入城市A的乘车二维码页面时唤起城市A的SDK，由所述城市A的SDK执行以下步骤：

S1、获取城市A的乘车二维码的请求；

S2、根据所述城市A的乘车二维码的请求，生成城市A的乘车二维码并展示，所述城市A的乘车二维码用于用户在城市A的AGM有效读写区域内进行扫码过闸，以使所述城市A的MLC系统根据城市A的AGM上传的扫码过闸交易数据进行OD行程匹配及扣费；

S3、城市A的互联互通服务器发送查询用户行程订单及行程计费订单的请求；

S4、接收由城市A的互联互通服务器返回的由城市A的MLC系统生成的用户行程订单及行程计费订单并进行展示。

进一步地，所述步骤S1具体包括以下步骤：

S001、根据所述城市A的乘车二维码的请求，检查城市A的生码授权数据的有效期是否过期，若过期，则转步骤S3，若未过期，则转步骤S5；

S002、生成一个经城市A的互联互通服务器转发至城市A的MLC系统的生码授权请求；

S003、接收城市A的互联互通服务器返回的由城市A的MLC系统生成的生码授权数据；

S004、根据所述生码授权数据及生码逻辑生成城市A的乘车二维码并展示。

进一步地，还包括，所述扫码过闸的流程为：

所述城市A的AGM按照本地的二维码验码流程完成进站或出站的验码、开闸，并将扫码过闸交易数据实时上传至城市A的MLC系统；

进一步地，所述城市A的AGM对城市A的乘车二维码的验码流程为：

Sa、使用中心公钥验证所述城市A的乘车二维码中的第一公钥证书，若验证通过，则进行下一步验证；否则，验证交易终止；

Sb、使用第一公钥证书的第一公钥验证城市A的乘车二维码中的授权签名数据，若验证通过，则进行下一步验证；否则，验证交易终止；

Sc、使用支付渠道的用户公钥验证城市A的乘车二维码中的用户私钥签名数据，若验证通过，则二维码证书验证通过，获取到所有二维码数据信息；否则，验证交易终止；

Sd、根据城市A的乘车二维码，验证城市A的乘车二维码是否在有效使用期内，有效期包括第一公钥证书有效期、支付账户系统授权过期时间、二维码有效期以及二维码生成时间，若在有效期内，则记录二维码交易，并对交易成功或刷卡成功进行开闸，否则验证交易终止。

进一步地，所述城市A的MLC系统根据城市A的互联互通服务器转发的城市A的SDK的生码授权请求生成生码授权数据，具体过程为：

SA、获取生码授权请求；

SB、根据所述生码授权请求，按照二维码的结构生成二维码业务数据；

SC、使用中心私钥获得第一公钥证书，并将所述二维码业务数据与所述第一公钥证书打包封装成二维码原始数据；

SD、使用第一私钥对所述二维码原始数据进行签名生成授权签名数据，并将所述二维码原始数据与所述授权签名数据打包封装成生码授权数据。

进一步地，所述SDK生成城市A的乘车二维码的过程为：根据所述生码授权数据，使用支付渠道的用户私钥对生码授权数据进行签名生成用户私钥签名数据，并将所述生码授权数据与所述用户私钥签名数据打包封装成城市A的乘车二维码。

进一步地，所述城市A的乘车二维码包括第一公钥证书、二维码业务数据、生码授权签名数据以及用户私钥签名数据。

进一步地，所述城市A的MLC系统根据城市A的AGM上传的扫码过闸交易数据，进行OD行程匹配生成用户行程订单，并将用户行程订单推送至城市A的互联互通服务器；根据所述用户行程订单进行计费生成行程计费订单，并将行程计费订单推送至城市A的互联互通服务器，所述OD行程匹配、计费，具体包括：

根据扫码过闸交易数据中的用户账户ID、交易时间信息以及进出站信息进行匹配，并根据交易计费规则计算交易金额，完成结算交易数据并生成用户行程订单；

进一步地，一种基于SDK获取异地乘车二维码执行交易的城市B的地铁客户端,包括：

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

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

所述一个或多个其他城市的SDK用于：通过指定的城市的互联互通服务器与指定的城市的MLC系统进行通信，根据权利1-8任意所述的一种基于SDK获取异地乘车二维码执行交易的方法，进行扫码过闸。

进一步地，一种基于SDK获取异地乘车二维码执行交易的系统，包括：

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

所述一个或多个其他城市的SDK用于：通过对应的城市的互联互通服务器与对应的城市的MLC系统进行通信，根据权利1-8任意所述的一种基于SDK获取异地乘车二维码执行交易的方法，进行扫码过闸；

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

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

当用户通过城市B的地铁客户端进入城市B的乘车二维码页面时，通过城市B的服务器与城市B的MLC系统进行通信，完成扫码过闸,数据的路线为：城市B的地铁客户端--城市B的AGM--城市B的MLC系统--城市B的服务器；

当用户通过城市B的地铁客户端进入异地乘车二维码界面时，弹出一个或多个其他城市列表的页面，获得一个或多个其他城市列表的页面的触发信号，进入指定的城市的乘车二维码页面，唤起指定的城市的SDK，所述指定的城市的SDK，通过指定的城市的互联互通服务器与指定的城市的MLC系统进行通信，基于SDK获取异地乘车二维码执行交易的方法，进行扫码过闸,数据的路线为：城市B的地铁客户端--指定的城市的SDK--指定的城市的AGM--指定的城市的的MLC系统--指定的城市的的互联互通服务器。

本发明的地铁执行交易过程为：用户使用城市B的地铁客户端展示的城市A的地铁乘车码，在城市A的AGM上扫码进站、出站,城市A的AGM将用户的进、出站过闸数据上传给城市A的MLC系统，城市A的MLC系统推送进、出站过闸数据到城市A的互联互通服务器，在用户完成出站后，城市A的MLC系统匹配完整用户行程，并进行程计费、生成行程订单，城市A的MLC系统向该用户签约的支付渠道发起扣款，记录扣款结果，城市A的MLC系统推送OD及扣费信息数据到城市A的互联互通服务器，通过城市B的地铁客户端唤起城市A的SDK，查看用户在城市A的地铁的乘车记录、扣款信息。

本发明具有的有益效果：

1、通过在城市B的地铁客户端内集成与城市A的地铁票务平台(将承担发码及行程OD配对、计费的系统统一称之为地铁票务平台)进行通信的城市A的SDK，获取城市A的乘车二维码，所述城市A的SDK通过与城市A的MLC系统进行数据交互，实现城市A的乘车二维码的执行交易，提高了出行体验。

2、在不需要下载新城市APP、无需现场购买异地车票，也避免了改造闸机硬件电路，通过将所在地的APP内集成SDK，实现异地的乘车二维码的执行交易；

附图说明

图1为本发明的基于SDK的异地乘车二维码执行交易的方法流程示意图；

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

图3为本发明的基于SDK的异地乘车二维码执行交易的系统示意图；

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

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

图6为本发明的实施例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。

2.成都地铁SDK根据成都地铁乘车码的生码逻辑检查本地的授权有效期等有效性以及执行本地风控检查(欠费、单边行程等)，若生码授权有效期过期，则请求成都地铁APP后台，发起生码授权请求。

3.成都地铁APP后台接收生码授权请求，执行生码风控检查，校验该用户开通状态、支付签约情况以及业务风控检查(欠款、单边行程等)，检查通过后向成都地铁MLC系统请求生码授权。

4.成都地铁MLC系统接收成都地铁APP后台发起的生码授权请求，进行业务合法性校验后生成并返回生码授权数据。

5.经成都地铁APP后台将成都地铁的乘车码生码授权数据返回给成都地铁SDK，成都地铁SDK安全存储成都地铁的生码授权数据，然后根据成都地铁乘车码生码逻辑生成乘车码数据并展示成都地铁乘车码。

二、扫码过闸与收费

西安地铁APP通过成都地铁SDK生成成都地铁乘车码后，即可在成都地铁进行扫码过闸，成都地铁遵循本地二维码业务流程、票务规则、AFC标准完成西安地铁APP用户的扫码过闸、OD匹配、行程订单生成及计费订单支付扣款的业务处理。流程图如下：

具体实现流程说明如下:

1.用户持西安地铁APP拉取的成都地铁乘车码在成都地铁的闸机(AGM)扫码过闸。

2.成都地铁的闸机按照成都地铁本地二维码验码流程完成进站或出站的验码、开闸，并将扫码过闸交易实时上传成都地铁MLC系统。

3.成都地铁MLC系统将用户进、出站行程数据推送给成都地铁APP后台。

4.西安地铁APP用户在成都地铁闸机上完成进站、出站后，成都地铁MLC系统完成OD行程匹配后生成行程订单，并对订单进行计费，然后将行程计费订单推送给成都地铁APP后台。

5.成都地铁MLC系统查询用户的支付渠道签约信息，然后向签约的支付渠道发起扣款，完成该用户的行程订单消费扣款，用户的付款直接进入服务方即成都地铁的收款商户号，确保资金的安全和流程合规，业务合规。支付机构T+1日将资金清算给服务方账户。

6.完成支付扣款后，微信支付宝将扣款结果返回给成都地铁MLC系统，由成都地铁MLC系统推送给成都地铁APP后台。

7.西安地铁APP唤起成都地铁SDK，可发起用户行程及订单查询。

如上述方案所述，成都西安乘车码互联互通按照双方提供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内的，且地铁APP内安装在用户终端内，并且用户终端内包括用于存储该地铁APP的数据的存储空间，指定SDK组件能够将待推送消息存储至地铁APP对应的存储空间内，并且通知地铁APP，该待推送信息已经存储至地铁APP内对应的存储空间内，该地铁APP可以通过该存储空间获取到该待推送消息。

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

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

Claims

1.一种基于SDK获取异地乘车二维码执行交易的方法，其特征在于，应用于城市B的地铁APP中的城市A的SDK，所述城市A的SDK用于通过城市A的互联互通服务器与城市A的MLC系统进行通信，当用户通过城市B的地铁客户端进入城市A的乘车二维码页面时唤起城市A的SDK，由所述城市A的SDK执行以下步骤：

S1、获取城市A的乘车二维码的请求；

S3、向城市A的互联互通服务器发送查询用户行程订单及行程计费订单的请求；

2.根据权利要求1所述的一种基于SDK获取异地乘车二维码执行交易的方法，其特征在于，所述步骤S1具体包括以下步骤：

3.根据权利要求1所述的一种基于SDK获取异地乘车二维码执行交易的方法，其特征在于，还包括，所述扫码过闸的流程为：

4.根据权利要求2所述的一种基于SDK获取异地乘车二维码执行交易的方法，其特征在于，所述城市A的AGM对城市A的乘车二维码的验码流程为：

5.根据权利要求4所述的一种基于SDK获取异地乘车二维码执行交易的方法，其特征在于，所述城市A的MLC系统根据城市A的互联互通服务器转发的城市A的SDK的生码授权请求生成生码授权数据，具体过程为：

SA、获取生码授权请求；

6.根据权利要求5所述的一种基于SDK获取异地乘车二维码执行交易的方法，其特征在于，所述SDK生成城市A的乘车二维码的过程为：根据所述生码授权数据，使用支付渠道的用户私钥对生码授权数据进行签名生成用户私钥签名数据，并将所述生码授权数据与所述用户私钥签名数据打包封装成城市A的乘车二维码。

7.根据权利要求6所述的一种基于SDK获取异地乘车二维码执行交易的方法，其特征在于，所述城市A的乘车二维码包括第一公钥证书、二维码业务数据、生码授权签名数据以及用户私钥签名数据。

8.根据权利要求1所述的一种基于SDK获取异地乘车二维码执行交易的方法，其特征在于，所述城市A的MLC系统根据城市A的AGM上传的扫码过闸交易数据，将用户行程订单推送至城市A的互联互通服务器；进行OD行程匹配生成用户行程订单，根据所述用户行程订单进行计费生成行程计费订单，并将行程计费订单推送至城市A的互联互通服务器，所述OD行程匹配、计费，具体包括：

根据扫码过闸交易数据中的用户账户ID、交易时间信息以及进出站信息进行匹配，并根据交易计费规则计算交易金额，完成结算交易数据并生成用户行程订单。

9.一种基于SDK获取异地乘车二维码执行交易的地铁客户端,其特征在于，包括：

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

10.一种基于SDK获取异地乘车二维码执行交易的系统，其特征在于，包括：

当用户通过城市B的地铁客户端进入异地乘车二维码界面时，弹出一个或多个其他城市列表的页面，获得一个或多个其他城市列表的页面的触发信号，进入指定的城市的乘车二维码页面，唤起指定的城市的SDK，所述指定的城市的SDK，通过指定的城市的互联互通服务器与指定的城市的MLC系统进行通信，根据权利1-8任意所述的一种基于SDK获取异地乘车二维码执行交易的方法，进行扫码过闸,城市B的地铁客户端--指定的城市的SDK--指定的城市的AGM--指定的城市的的MLC系统--指定的城市的的互联互通服务器。