技术规范标准_银行卡联网联合技术规范

中国银联股份有限公司 发布2009-12-30实施2009-11-19发布银行卡联网联合技术规范V2.1境内成员机构改造指南配套文件Q/CUP中国银联股份有限公司企业标准我们总羡慕别人的幸福，却常常忽略自己生活中的美好。其实，幸福很平凡也很简单，它就藏在看似琐碎的生活中。幸福的人，并非拿到了世界上最好的东西，而是珍惜了生命中的点点滴滴，用感恩的心态看待生活，用乐观的态度闯过磨难。目 次1 编制思路41.1 目的41.2 范围41.3 编写思路42 报文版本升级说明52.1 修改内容和原因52.2 是否为必选业务类型52.3 使用要求52.4 处理流程52.5 新业务的支持原则52.6 阅读说明53 新增业务说明53.1 银联联盟积分业务53.2 预付费卡业务73.3 信用卡还款业务103.4 IC卡借贷记应用的预授权完成（请求）交易133.5 电子现金IC卡现金充值撤消交易144 国际业务说明164.1 国际业务特色信息域164.2 额外手续费业务处理194.3 柜面取现业务处理204.4 免验密码网络标志处理234.5 F37的匹配处理244.6 IC卡借贷记应用的预授权完成（请求）类交易254.7 消费（分期付款）业务294.8 银联卡汇率查询业务334.9 跨境汇款业务344.10 联机退货业务384.11 国际业务中对F60的处理394.12 IC卡电子现金应用的业务405 代授权业务说明435.1 业务说明435.2 是否为必选业务类型455.3 发卡方改造要求456 文件接口规范说明466.1 术语和定义466.2 文件收发476.3 V2.1文件体系的调整476.4 跨行清算文件496.5 代理清算文件546.6 清算汇总文件586.7 其他文件586.8 文件的分类和选择586.9 小结627 报文域优化和改进内容的说明637.1 F60637.2 F48697.3 F57707.4 F2、F38、F42的唯一性717.5 F55中的新增tag717.6 IC卡借贷记应用的余额查询737.7 F54的处理737.8 F61的处理748 数据安全传输与控制规范的说明758.1 类转账流程交易的MAC计算注意事项758.2 重置密钥注意事项769 通讯接口规范的说明769.1 空闲连接查询报文的间隔时间769.2 联机交易的双工连接7610 应答码的整理说明7710.1 调整的内容7710.2 是否为必选业务类型7710.3 机构的处理7711 改造说明归纳8011.1 总体改造要求8011.2 具体改造要求80 银行卡联网联合技术规范V2.1境内成员机构改造指南1 编制思路1.1 目的为了使各入网机构能更好地了解规范本次的修订内容，并深刻地理解这些修订的业务背景和必然性，银联V2.1规范编写组特地编写了此改造指南文档，作为规范修订内容的配套理解手册。每个规范修订点的内容都需要各入网机构的配合改造才能实现真正的业务上线，所以机构都很关心哪些是必选改造业务，哪些是可选改造业务。另外，规范的修订完成并不意味着系统改造的完成，在系统改造过程中必然存在规范过渡的问题，银联系统作为转接和清算中心承担着过渡实现的功能，那么银联系统究竟是如何处理这些过渡内容的，也是机构关心的问题。机构可以通过对银联系统处理方式的了解来设计自己的系统。针对每个规范修订点，银联规范编写人员都是经过仔细讨论，反复商量再修订的，背后隐含着一些修订的思路和思考，这些隐含的内容也是我们希望机构了解的内容，一方面是机构在了解这些深层次的原因以后能更好地理解规范为什么会有这样的改造点又是为什么要这样改，另一方面也希望对机构的系统改造提供一些思考。综上，我们编写了这份改造指南，希望在机构业务开展和系统改造设计方面提供力所能及的帮助。1.2 范围 本改造指南涵盖了所有涉及系统修改的内容，但一些只为帮助读者更好地理解规范，却不涉及系统改造内容的文字修订和篇章结构的调整不在本文档中描述。对于新增业务、国际业务和代授权业务这些改造比较大，比较新的内容以业务为线条来组织描述，是一种横向描述，而不是按照规范各部分纵向的描述。这样描述的目的在于讲解新业务该如何开展，如果仅从规范各部分来描述的话，内容比较分散，读者没有一个完全的业务概念，不利于系统的开发和设计。对于数据安全、通讯接口和应答码这三个比较独立和相对底层或普适的内容就按照规范本身的编排结构来描述，便于读者更好地理解规范的变更。对于优化和改进内容，由于主要涉及报文接口的改变，虽然也是一个普适内容，但它是本次修订的重点和难点，为便于读者的理解和系统的设计，特单独描写。在文件接口方面，在原规范已有的跨行清算文件基础之上又增补了银联代理清算文件，不同的机构所需的文件不同，改造内容也不同，为帮助机构迅速了解自身所需的改造内容，本文将机构分为15大类，每类机构可“对号入座”关注自己在文件方面的改造内容。1.3 编写思路 整篇文档的编写遵守如下几个原则：1、方便机构了解是否需要支持由该业务引发的系统改造。为减轻机构改造负担，为机构提供更好的服务，分析了每个修订点是必选改造内容还是可选改造内容。机构可据此安排改造计划。2、以业务为线横向贯穿规范的修订内容。修订规范的时候，规范每个具体的修订点必然是要分散在规范各个部分的，但读规范却不能如此。如果这样读规范，就不能理解里面的业务含义和各自的联系性。为便于机构的开发人员理解规范，改造指南从业务开展的角度出发，通过业务将各规范内容横向贯穿了起来。让机构能从业务发展角度根本性地理解这项业务的目的和处理方式，可以更好地让机构评估该项业务开展的必要性，也为机构是否决定支持该业务提供评估标准。3、每个修订点都是从背景描述开始，目的就是让机构了解每个修订点的前因后果，隐含内容，及规范编写人员的设计思想。这样编写的目的是希望能给读者一个全方面深层次的解释，而不是仅仅从系统改造角度描写。仅从技术层面描述，不能让读者深刻地理解这些修订点，也就不可能让读者接受这些改造点，从而进行系统改造。4、本文描述的是由于规范的修订而带来的系统改造内容，所以一方面要紧扣规范，另一方面也不必再重复规范内容，为达到该目的，本指南采用引用规范章节号的做法。凡是涉及具体规范的内容，都会列举最新修订规范中的对应章节号，指明规范出处，方便读者比对和查阅。5、本文既然是机构的改造指南，那么必然的重点是站在机构的角度分析机构应该关注的内容。文中有专门的章节描述了机构应该注意的内容和改造时应执行的操作。由于系统改造不是一朝而成的，同时不能由于系统的改造影响现有业务的开展，所以一定会存在一个过渡期，过渡期的处理是复杂的，同时也取决于银联系统的处理方式，为了让机构更好地理解过渡期的改造内容，本文也适当描述了银联系统的转换功能，方便机构了解银联的处理以便于决定自己的改造方案和改造计划。了解了上述五个编写原则，读者才能了解整篇文档的编写思路和希望达到的目的。总之，编者是希望通过这个配套文档解释规范的修订原因，修订方式，修订目的，以指导机构更好地改造系统，更好地开展新业务。2 报文版本升级说明2.1 修改内容和原因报文接口规范3.2.2.2节定义了报文头第2域的内容，其中该域的后4位组成的二进制值定义了该V2.1规范中报文格式的版本，目前的取值为0001。本次规范修订以后，在报文接口部分涉及到一些必改内容的域结构调整，如报文体中的第60域。由于有结构上的调整，又考虑到各机构的改造进度无法统一，所以为便于过渡阶段的报文转换和版本控制，将此版本号修改为0010。2.2 是否为必选业务类型必选。对于受理和发卡机构而言都是必选的。2.3 使用要求若机构需要使用更新的报文版本标识0010，表示该机构已按照本改造指南中要求的与报文版本标识有关的必选改造内容完成了改造。必选改造内容请参见本文Error! Reference source not found.节中的表格说明。一个机构只能拥有一个报文版本，要么是所有联机报文的报文版本标识都填写为0001，要么是全部填写为0010。不允许有的报文填写0001，有的填写0010；也不允许作为受理方时填写一个版本标识，作为发卡方时填写另一个版本标识。2.4 处理流程如果机构改造完成，首先需要向中国银联上海信息中心告知已完全支持将于2009年底发布的这版修订后规范，工作人员会将机构的版本属性修改为最新标识。然后在机构作为受理方上送报文时，应在报文头的第2域报文版本标识中上送新报文版本号0010。银联系统会根据接收到的报文版本信息和配置在系统中的机构报文版本属性进行比较，比较一致才允许进行后续的交易处理。同时，银联系统会根据机构属性中配置的版本信息进行不同报文版本之间的转换处理。机构需要能够正确识别银联系统转发的报文版本标识和进行正确地报文解析工作。2.5 新业务的支持原则由于报文版本标识只用在联机报文中，只是对联机报文的版本控制，所以该取值的改变与联机报文关系最密切，也导致该标志的使用会涉及到新增业务的支持原则。这里的新业务指的是本次修订新增加的交易，包括本文第Error! Reference source not found.章的所有内容，第Error! Reference source not found.章中的Error! Reference source not found.，Error! Reference source not found.，Error! Reference source not found.，Error! Reference source not found.，Error! Reference source not found.和Error! Reference source not found.各节。建议机构在修订后的最新规范中支持这些新交易。2.6 阅读说明由于报文版本标识为二进值取值，阅读起来不太方便，下面统一用修订前规范表示0001版本标识；修订后规范表示0010版本标识。3 新增业务说明3.1 银联联盟积分业务3.1.1 业务说明银联联盟积分是指依据银行卡交易数据，联合商户、成员机构及其他合作机构共同为银联持卡人提供标准积分的行为，以及特定企业将自己积分转换成银联标准积分。持卡人消费的是银联的联盟积分，而不是银行卡积分。它与银行卡积分业务最大的不同之处在于：银行卡积分交易的发卡方是银行，而银联联盟积分的发卡方是第三方机构，而不是银行。3.1.2 是否为必选业务类型3.1.2.1 受理方的选择可选。即机构做为受理方可选择是否支持银联联盟积分业务的受理。3.1.2.2 发卡方的选择联盟积分交易的发卡方是银联联盟积分系统，因此不涉及银行改造。3.1.3 支持的交易类型和交易流程3.1.3.1 交易类型联盟积分业务支持的交易类型包括:余额查询、消费类（含消费、消费冲正、消费撤销、消费撤销冲正）、退货（联机）。受理方可选择支持余额查询和消费类中的一类或两类。如果选择支持消费类，则需同时支持退货（联机）。3.1.3.2 交易流程交易处理的正常、异常和差错流程同传统消费类，无特殊。3.1.4 关键域的使用3.1.4.1 F25在联盟积分业务中，25域取值与传统消费不同，取值为65。受理方在其发送的交易请求报文中应按照本域定义填写，以区别于传统消费交易，详见Error! Reference source not found.交易关键域取值。3.1.4.2 F54在联盟积分余额查询、消费的应答报文中会出现54域。对于联盟积分来说，54域中的“账户类型”90，含义为“积分账户”；54域中的货币代码999，含义为“积分”。受理方应能够据此正确接收和解析54域。3.1.4.3 F60.2.1在联盟积分业务中，60.2.1域（账户所有人类型）与传统消费不同。而且，不同的联盟积分系统在60.2.1域对应不同的取值，受理方应根据终端上送的信息正确填写本域，详见Error! Reference source not found.交易关键域取值。目前本域仅定义了一个联盟积分系统，取值为A。今后根据需要本域可能会有扩展，终端和受理方应能够支持这种扩展。3.1.4.4 F60.3.4联盟积分业务要求在交易应答时向持卡人返回积分余额信息，因此可受理联盟积分的终端应支持余额的接收和打印。因此，受理方在其发送的联盟积分交易请求报文中，60.3.4域（支持部分承兑和返回余额标志）取值应为1，详见Error! Reference source not found.交易关键域取值。3.1.4.5 卡片信息的特殊处理为保障卡片信息的安全，CUPS在处理银联联盟积分交易时，会将受理方上送的卡片有效期（F14）、第一、二、三磁道信息（F45、F35、F36）屏蔽掉，不再向联盟积分系统传递。3.1.4.6 交易关键域取值交易名称报文类型交易处理码F3服务点条件码F25商户类型F18账户所有人类型F60.2.1终端类型F60.2.5支持部分承兑和返回余额F60.3.4余额查询0200/021030X00000根据实际情况填写A031消费0200/021000X00065A031消费冲正0420/043000X00065A031消费撤销0200/021020X00065A031消费撤销冲正0420/043020X00065A031退货（联机）0220/023020X00000A031或0注：1. 表中60.2.1域的取值表示目前支持的银联联盟积分系统，受理方应能够支持对其他联盟积分系统的扩展。2. 表中60.2.5域的取值表示交易仅从POS上发起，受理方应能够拓展支持从其他终端类型上发起。3.1.4.7 报文格式定义交易名称报文接口规范的参见章节号余额查询8.2.1.1余额查询消费8.2.1.9消费消费撤销8.2.1.10消费撤销消费冲正8.2.1.17冲正消费撤销冲正8.2.1.17冲正退货（联机）8.2.1.11退货（联机）3.1.5 清算处理说明联盟积分交易所涉及的流水文件和汇总文件均同传统借贷记卡交易文件，并无差别，在此不再一一列举。对受理方的要求：与传统借贷记卡进行相同的文件处理即可。对发卡方的要求：与传统借贷记卡进行相同的文件处理即可。3.1.6 过渡期期说明及注意事项受理方系统改造应在终端改造之前就绪，否则可能会将终端上送的联盟积分交易误判为普通消费或银行卡积分消费交易，从而导致银联在后续进行交易转发时出错。发卡机构是银联联盟积分系统，与银行无关。3.2 预付费卡业务3.2.1 业务说明预付费卡是指：金融机构或非金融机构（统称特种卡片发行机构）发行的单用途或多用途储值卡，有别于借记卡和信用卡，采用预先支付方式；它是包含着真实购买力的卡基支付产品，为了获得该卡片，消费者必须预先支付其价值。由于预付费卡是属于一种储值卡，因此它具有与普通借记卡、贷记卡不同的业务功能，主要体现在：交易成功后应返回卡内余额。3.2.2 是否为必选业务类型3.2.2.1 受理方的选择可选，即受理方系统可选择是否支持预付费卡的受理，或仅选择其中的一类或几类交易。详见Error! Reference source not found.交易类型。3.2.2.2 发卡方的选择可选。即，若发卡方不发预付费卡，则无需进行系统改造；若发了预付费卡就必须进行本节所述的与发卡方相关的改造。3.2.3 支持的交易类型和交易流程3.2.3.1 交易类型交易分类交易类型受理方需支持的交易类型发卡方需支持的交易类型消费类消费、消费冲正可选若发卡方发行预付费卡，则为必选消费撤销、消费撤销冲正预授权类预授权、预授权冲正可选若发卡方发行预付费卡，则为必选预授权撤销（联机）预授权撤销（联机）冲正预授权撤销（手工）预授权撤销（手工）冲正预授权完成（手工）预授权完成（请求）预授权完成（请求）冲正预授权完成（通知）预授权完成（请求）撤销预授权完成（请求）撤销冲正双信息授权类授权、授权冲正可选不支持双信息发卡方发行预付费卡授权撤销、授权撤销冲正文件结算综合上表所述： 1、受理方可选择支持预付费卡的消费类、预授权类和授权类其中的一类或多类。2、发卡方一旦发行预付费卡，则必须同时支持消费类和预授权类。而且银联不支持双信息发卡方发预付费卡。3.2.3.2 交易流程预付费卡的正常、异常处理流程均同传统的同名交易。预付费卡支持的差错类型包括：确认查询、贷记调整、一次退单、例外协商、差错例外。3.2.4 关键域的使用本节介绍支持预付费卡业务功能的几个相关域。3.2.4.1 “返回余额”的实现机制（1） 受理方上送消费交易请求报文： 根据终端的实际能力填写F60.3.4（支持返回余额和部分扣款标志）；（2） CUPS向发卡方转发该报文；（3） 发卡方处理：a. 根据卡号判定是否为预付费卡交易，若不是预付费卡则跳出，不再进行后续流程。b. 根据F60.3.4的取值判定终端能否支持返回余额，如果能，就在应答报文的54域返回余额信息；如果不能则不返回54域。（4） CUPS转发该应答报文；（5） 受理方接收该报文并向终端转发该应答；（6） 如果终端具备接收54域的能力，则将余额信息打印在签购单的指定位置。如果终端不具备该能力，理论上不会收到54域。3.2.4.2 F54F54（余额信息）与预付费卡交易返回余额有关。对受理方的要求：（1）可支持在预付费卡的消费、预授权、预授权完成、授权交易应答报文中接收54域信息。（2）发生交易的终端应能够支持54域信息的接收、显示和打印。（3）理论上，如果60.3.4域0时，发卡方不会返回54域，但仍然强烈建议受理方能够支持这种情况下收到54域，即不要去对应答报文做60.3.4域与54域之间关系的硬性检查，以增强受理方系统的健壮性。对发卡方的要求：（1）应支持在预付费卡的消费、预授权、预授权完成的成功应答报文中返回54域信息。（2）对预付费卡交易是否能够返回余额，发卡方应根据60.3.4域的取值进行严格的判断，只有当60.3.4=1时才能返回余额，否则不能返回。（3）对于非预付费卡的交易，即使60.3.4域1，发卡方也不应返回54域。3.2.4.3 F60.3.4F60.3.4（支持部分承兑和返回余额标志），与预付费卡的返回余额有关。这个域在预付费卡业务实现中是一个很关键的域，它实际上代表了终端是否具备受理预付费卡的能力，只有当F60.3.41（表示终端支持部分承兑和返回余额）时，该笔交易才能进入预付费卡的业务处理流程，否则只能按照传统借贷记卡流程处理。对受理方的要求：（1）F60.3.4表示终端的能力，与是否预付费卡交易无关。也就是说，当终端具备了这种能力后，在该终端发起的所有交易中，该域的取值都始终为1，不会随着交易的不同而不同。对发卡方的要求：（1）F60.3.4表示终端的能力，与是否预付费卡交易无关。也就是说，即使该标志为1，也并不意味着发卡方一定可以返回54域，还应结合卡性质（是否为预付费卡）做联合条件的判断。详见Error! Reference source not found.54域的处理。3.2.4.4 交易关键域取值预付费卡所支持的消费类、预授权类、授权类交易关键报文域取值与普通借贷记卡相同，没有任何差别，在此不再一一列举。具体可参见报文接口规范附录B 交易种类区分表。对受理方的要求：应按照附录B 交易种类区分表 中的定义上送有关预付费卡的交易信息。对发卡方的要求：能够根据附录B的定义识别相应的交易种类，并在判断出卡性质后，对预付费卡执行有别于借贷记卡的处理。3.2.4.5 报文格式定义交易名称报文接口规范的参见章节号消费8.2.1.9消费消费冲正8.2.1.17冲正消费撤销8.2.1.10消费撤销消费撤销冲正8.2.1.17冲正预授权8.2.1.2预授权预授权冲正8.2.1.17冲正预授权撤销（联机）8.2.1.4预授权撤销/预授权撤销（手工）预授权撤销（联机）冲正8.2.1.17冲正预授权撤销（手工）8.2.1.4预授权撤销/预授权撤销（手工）预授权撤销（手工）冲正8.2.1.17冲正预授权完成（手工）无联机报文预授权完成（请求）8.2.1.5预授权完成（请求）预授权完成（请求）冲正8.2.1.17冲正预授权完成（通知）8.2.1.6预授权完成（通知）预授权完成（请求）撤销8.2.1.8预授权完成（请求）撤销预授权完成（请求）撤销冲正8.2.1.17冲正授权8.2.2.2授权授权冲正8.2.2.5授权冲正授权撤销8.2.2.4授权撤销授权撤销冲正8.2.2.5授权撤销冲正对受理方的要求：按照相应章节的报文格式定义发送和接收报文。对发卡方的要求：按照相应章节的报文格式定义发送和接收报文。3.2.5 清算处理说明预付费卡消费类、预授权类和授权类交易所涉及的流水文件和汇总文件均同传统借贷记卡，并无差别，在此不再一一列举。注：预付费卡不收取品牌费，因此不会进入品牌费的相关文件。对受理方的要求：与传统借贷记卡进行相同的文件处理即可。对发卡方的要求：与传统借贷记卡进行相同的文件处理即可。3.2.6 过渡期说明及注意事项对预付费卡的支持涉及到终端、受理方和发卡方的系统改造，由于各方改造的进度无法统一，因此必然存在一个业务的过渡期，受理方和发卡方应对过渡期内的各种情况在系统和技术层面予以支持。下表说明了受理方系统已就绪，而终端尚未改造时带来的问题以及对受理方系统的要求：终端改造状态问题描述对受理方的要求未改造终端不支持在应答报文中接收54域信息受理方发出的请求报文中60.3.4域应置为0或该子域不出现。可以看出，受理方系统改造应该在终端改造之前就绪，否则无法在报文中正确反应终端的能力。下表说明了发卡方系统已就绪，而受理方系统未改造时带来的问题及对发卡方系统的要求：受理方改造状态问题描述对发卡方的要求未改造受理方报文中无60.3.4域或60.3.40发卡方可以承兑该笔预付费卡交易，但是不能向受理方返回54域。可以看出，发卡方系统必须在受理方系统改造之前就绪，否则无法满足预付费卡的业务功能要求。3.3 信用卡还款业务3.3.1 业务说明信用卡还款是指采用转账交易实现对信用卡透支金额的还款。其中，转出卡必须为借记卡，转入卡必须为信用卡。3.3.2 是否为必选业务类型3.3.2.1 受理方的选择可选。即受理方可选择是否支持采用转账交易实现信用卡还款业务。如果选择支持该项业务，则必须进行本节所述的受理方相关改造。3.3.2.2 发卡方的选择可选。即发卡方可选择是否支持采用转账交易实现信用卡还款业务，发卡方可选择以下三种的任一种：（1）仅支持转出交易；（2）仅支持转入交易；（3）同时支持转出和转入。如选择支持，则应完成相应的转出方、转入方相关改造。3.3.3 支持的交易类型和交易流程3.3.3.1 交易类型正常情况下，一笔信用卡还款由：受理方发出的转账、CUPS拆分出的转出、CUPS拆分出的转入三个环节即可完成。异常时，还可能引发转出冲正或转入确认。3.3.3.2 交易流程采用转账实现的信用卡还款业务正常流程如下：转账模式的信用卡还款交易出现异常时，会引发转出冲正或转入确认（均由CUPS引发），其异常流程较为复杂，具体参见银行卡联网联合技术规范V2.1第一部分交易处理说明8.7.2转账交易。另外，转账交易的超时时间与普通交易有差别，即转出方20秒，转入方20秒，受理方50秒。综上所述，在处理流程上对各方的要求是：对受理方的要求：在超时未收到转账交易应答6时，受理方不能发送转出冲正或转入确认，而是应通过终端提示持卡人“查询转出方和转入方”。对转出方的要求：（1）应能够接收和处理转出报文；（2）应能够满足20秒之内返回应答的要求；（3）应能够接收和处理转出冲正报文。对转入方的要求：（1）应能够接收和处理转入报文；（2）应能够满足20秒之内返回应答的要求；（3）应能够接收和处理转入确认报文。3.3.4 联机报文说明3.3.4.1 F18F18：商户类型码（Merchant Category Code），以下简称MCC。转账交易作为一种资金转移的实现方式，可以支持多种业务。由于不同的业务可能执行不同的业务规则、定价策略和风险要求，所以为当转账交易被用于实现信用卡还款业务时，为其定义了特殊的MCC：9498（信用卡还款），以便于银联和入网机构对交易进行区别处理。对受理方的要求：当转账交易被用于实现信用卡还款时，应将转账报文中的F18置为9498，含义为信用卡还款。对转出方的要求：（1）当收到的转出报文F18=9498时，应能够识别为一笔信用卡还款的转出业务；（2）应对转出卡进行卡性质的检查，若转出卡不是借记卡，则应拒绝，F3957（不允许持卡人进行的交易）。对转入方的要求：（1）当收到的转入报文F189498时，应能够识别为一笔信用卡还款的转入业务；（2）应对转入卡进行卡性质检查，若转入卡不是信用卡，则应拒绝，F3957（不允许持卡人进行的交易）。3.3.4.2 F22F22，服务点输入方式码，表示的是转出卡的输入方式。对受理方的要求：受理方应根据转出卡的刷卡方式和是否有PIN输入来填写该域。对转出方的要求：转出方可根据该域信息获取转出卡的输入方式，并进行相应的PIN检查。对转入方的要求：转入方不应根据此域来判断转入卡的输入方式。3.3.4.3 F28F28，交易费。在转账模式的信用卡还款业务中用于表示转出方应付出的交易手续费，该手续费在银联、受理、转出、转入四方之间分润。信用卡还款采用与普通转账一致的收费模式和价格水平。该域的属性为Xn12，其中X表示交易费的借贷方向，在信用卡还款业务各个环节的报文中X固定为D，表示借记，但是该符号位仅对转出方有效，即手续费是向转出方收取的。对受理方的要求：受理方发出的转账请求报文28域不出现；受理方收到的应答报文中28域为Dn12，表示转出方应付手续费，受理方可据此计算自己的手续费分润。对转出方的要求：28域表示了转出方应付的交易手续费，此时转出方可根据此金额计算扣收持卡人的手续费。对转入方的要求：28域表示了转出方应付的交易手续费，转入方可根据此金额计算自身的手续费分润。3.3.4.4 F2、F102、F103F2，主帐号；F102，账户标识1；F103，账户标识2；这三个帐号在转账交易的不同环节取值如下表所示：交易类型F2F102F103受理方发出的转账报文转出卡卡号转出卡卡号转入卡卡号转出方收到的转出请求报文转出卡卡号转出卡卡号转入卡卡号转入方收到的转入请求报文转入卡卡号转出卡卡号转入卡卡号转出方收到的转出冲正报文转出卡卡号转出卡卡号转入卡卡号转入方收到的转入确认报文转入卡卡号转出卡卡号转入卡卡号从上表可以看出，F102和F103域全程不变，仅F2域在交易过程中根据交易报文的接收方不同而有变化，因此对交易各方的要求如下：对受理方的要求：受理方应将F2置为转出卡卡号；对转出方的要求：转出方可通过转出报文、转出冲正报文第2域直接获取转出卡号；对转入方的要求：转入方可通过转入报文、转入确认报文第2域直接获取转入卡号。3.3.4.5 F121.5F121.5，用法ID，转入和转出方标识代码。1-8位放置转出方标识代码；9-16位放置转入方标识代码。对受理方的要求：无特殊要求。如果受理方需要了解转出方机构代码和转入方机构代码时，可解析此域。对转出方的要求：无特殊要求。如果转出方需要了解转入方机构代码，可解析此域。对转入方的要求：无特殊要求。如果转入方需要了解转出方机构代码，可解析此域。3.3.4.6 交易的主键转账交易涉及受理、转出、转入三个角色，机构可以是其中的一方或同时担任两方角色，如同时是受理方和转出方、或同时是受理方和转入方、或同时是转出方和转入方。当同时担任两方时，可能会出现“交易主键（F7、F11、F32、F33）重复”的现象，举例说明如下：（上海工行）是一笔信用卡还款交易的受理方和转出方，则关于该笔交易，会有两条记录，一条是转账受理，一条是转出，两条记录的F7、F11、F32、F33是一样的，因此会出现“主键重复”的现象，导致转出交易无法记库。因此，考虑到这种情况的存在，信用卡还款交易的交易主键除了F7、F11、F32、F33以外，还应增加F3（交易处理码）的前两位。3.3.4.7 交易关键域取值转账模式的信用卡还款所涉及的交易报文关键域取值如下：交易名称报文类型交易处理码F3服务点条件码F25商户类型F18终端类型F60.2.5受理方发出的转账交易0200/021040X000009498根据实际情况填写转账拆分出的转出交易0200/021046X000转账拆分出的转入交易0200/021047X000转出冲正0420/043046X000转入确认0220/023047X000对受理方的要求：能够准确填写信用卡还款的转账交易的关键信息域，尤其是F18域。对转出方的要求：能够根据F18的取值不同识别出一般转账和信用卡还款转账，以便于后续处理。对转入方的要求：能够根据F18的取值不同识别出一般转账和信用卡还款转账，以便于后续处理。3.3.5 报文格式定义交易名称报文接口规范的参见章节号受理方发出的转账交易8.2.1.16.1转账报文转账拆分出的转出交易8.2.1.16.2转出转账报文转账拆分出的转入交易8.2.1.16.3转入转账报文转出冲正8.2.1.16.4转出转账冲正转入确认8.2.1.16.5转入确认3.3.6 清算处理说明成功的信用卡还款转账参加当日清算；受理方、转出方、转入方各收到一个流水文件，可用于交易勾对。当存在转出冲正时，转出交易和转出冲正交易同时参加清算，均出现在转出方流水文件中；当存在转入确认时，转入确认参加清算，仅转入确认出现在转入方流水文件中。对信用卡还款转账交易，品牌服务费向转入行收取。支持信用卡还款的机构需要支持以下文件：文件名称文件用途记录格式代码特殊问题说明INDYYMMDD?ATFL，参见文件接口规范4.1.1.1文件列表 表11银联卡单信息流水文件列表CUPS下发给受理机构，用于受理机构进行交易勾对。TFL的受理方格式（参见文件接口规范5.1.2(TFL)转账交易流水格式）对各方来说，一般转账和信用卡还款转账都体现在同一个文件中，各方需要通过MCC进行区分，并正确核对应收手续费和应付手续费。INDYYMMDD?OTFL ，参见文件接口规范4.1.1.1文件列表 表11银联卡单信息流水文件列表CUPS下发给转出机构，用于转出机构进行交易勾对。TFL的发卡方格式（参见文件接口规范5.1.2(TFL)转账交易流水格式）INDYYMMDD?ITFL ，参见文件接口规范4.1.1.1文件列表 表11银联卡单信息流水文件列表CUPS下发给转入机构，用于转入机构进行交易勾对。TFL的发卡方格式（参见文件接口规范5.1.2(TFL)转账交易流水格式）INDYYMMDD?AERRN ，参见文件接口规范4.1.1.1文件列表 表11银联卡单信息流水文件列表CUPS下发给受理方，用于受理方进行差错交易的勾对。ERRN的受理方格式（参见文件接口规范5.1.4(ERRN)差错交易流水文件记录格式（新）INDYYMMDD?IERRN ，参见文件接口规范4.1.1.1文件列表 表11银联卡单信息流水文件列表CUPS下发给转出方和转入方，用于差错交易的勾对。ERRN的发卡方格式（参见文件接口规范5.1.4(ERRN)差错交易流水文件记录格式（新）INDYYMMDD?ILFEE，参见文件接口规范4.1.1.1文件列表 表11银联卡单信息流水文件列表CUPS下发给转账交易的转入方，用于转入方核对品牌费。LFE的发卡方格式（参见文件接口规范5.1.4(LFE)品牌服务费交易流水格式）该文件为可选，如转入方需要逐笔与银联核对品牌费的话，可以处理该文件。INOYYMMDD?SUM，（参见文件接口规范7.1汇总文件列表 表19银联卡汇总文件列表）CUPS下发给交易的参与方，供参与方核对信用卡还款转账交易的汇总数据。SUM（参见文件接口规范5.3.5(SUM)交易汇总表）信用卡还款转账与一般转账一起汇总，体现在同一个统计项目中，各方应能够准确核对。3.3.7 过渡期说明及注意事项若受理方支持信用卡还款转账，而转出方或转入方不支持，则CUPS会直接拒绝该笔转账交易，应答码为40，含义为请求的功能尚不支持。3.4 IC卡借贷记应用的预授权完成（请求）交易3.4.1 业务说明该交易是对PBOC借贷记应用下预授权类交易的完善，相当于增加了一种对预授权的结算方式。3.4.2 是否为必选业务类型3.4.2.1 受理方的选择对于只受理磁条卡的受理方来说，不必关心本节内容。对于决定或已向借贷记IC卡迁移的受理方来说，本交易为可选。3.4.2.2 发卡方的选择对于未发IC卡的发卡方来说，不必关心本节内容。对于决定发IC卡或已向借贷记IC卡迁移的发卡方来说，本交易为必选。3.4.3 支持的交易类型和交易流程3.4.3.1 交易类型预授权完成（请求）涉及到一系列的交易，包括：预授权完成（请求）、预授权完成（请求）冲正、预授权完成（请求）撤消、预授权完成（请求）撤消冲正。3.4.3.2 交易流程交易的正常及异常流程均同同名的磁条卡交易。借贷记IC卡预授权完成(请求)及其相关交易执行简化的EMV流程，即交易无需ARQC和ARPC校验，体现在交易报文上就是不必携带55域信息。3.4.4 联机报文说明3.4.4.1 F22、F60.2.2、F60.2.3F22，服务点输入方式码；F60.2.2，终端读取能力；F60.2.3，IC卡条件代码。这三个域在交易报文中出现时应满足一定的约束条件，具体可参见Error! Reference source not found.关于60.3.7域的说明。对受理方的要求：应能够根据上表所述准确填写F22、F60.2.2、F60.2.3域信息。对发卡方的要求：应能够根据上表所述识别IC卡交易的特征。3.4.4.2 F55F55，IC卡数据域预授权完成（请求）及其相关交易（含冲正、撤消）报文中无需出现55域。对受理方的要求：受理方在预授权完成（请求）及其相关交易中无需上送55域信息。对发卡方的要求：对预授权完成（请求）及其相关交易无需验证ARQC。3.4.4.3 交易关键域取值交易的关键域取值（报文类型、交易处理码、服务点条件码、商户类型、终端类型）均同同名的磁条卡交易。3.4.4.4 报文格式定义借贷记IC卡预授权完成（请求）相关交易的报文参考以下章节：交易名称报文接口规范的参见章节号预授权完成（请求）共用内容：8.2.1.5预授权完成（请求）IC卡特殊内容：8.7.2.2.2消费撤消、预授权撤消、存款撤消、预授权完成（请求）、预授权完成（请求）撤消报文格式报文格式预授权完成（请求）冲正共用内容：8.2.1.17冲正IC卡特殊内容：8.7.2.2.8冲正中“原始交易没有55域信息的冲正类交易报文格式”预授权完成（请求）撤消共用内容：8.2.1.8预授权完成撤消IC卡特殊内容：8.7.2.2.2消费撤消、预授权撤消、存款撤消、预授权完成（请求）、预授权完成（请求）撤消报文格式报文格式预授权完成（请求）撤消冲正共用内容：8.2.1.17冲正IC卡特殊内容：8.7.2.2.8冲正中“原始交易没有55域信息的冲正类交易报文格式”3.4.5 清算处理说明借贷记IC卡预授权完成（请求）交易所涉及的流水文件和汇总文件均同传统磁条卡同名交易，并无差别，在此不再一一列举。对受理方的要求：（1）与传统磁条卡同名交易进行相同的文件处理即可。（2）注意对文件中IC卡特征字段进行识别和处理，包括：卡序列号（F23）、终端读取能力（F60.2.2）、IC卡条件代码(F60.2.3)。对发卡方的要求：（1）与传统磁条卡同名交易进行相同的文件处理即可。（2）注意对文件中IC卡特征字段进行识别和处理，包括：卡序列号（F23）、终端读取能力（F60.2.2）、IC卡条件代码(F60.2.3)。3.4.6 过渡期说明及注意事项若发卡方不支持借贷记IC卡的交易且未要求CUPS代为校验ARQC，则CUPS直接拒绝交易，返回应答码40。3.5 电子现金IC卡现金充值撤消交易3.5.1 业务说明电子现金IC卡现金充值撤消是指对已完成的现金充值进行全额撤消。与其他IC卡撤消交易执行简化EMV流程不同的是：现金充值撤消需要执行完整的EMV流程。原因是该交易需要通过55域携带发卡行脚本来修改电子现金卡余额。也正是由于这个原因，现金充值撤消交易不支持降级（FALLBACK）处理。3.5.2 是否为必选业务类型3.5.2.1 受理方的选择对于不支持电子现金IC卡业务的机构来说，无需关心本节内容。对于选择支持电子现金IC卡现金充值业务的机构，该交易为必选。即：如果受理方支持现金充值交易，则必须支持其充值撤消及关联交易。3.5.2.2 发卡方的选择对于未发电子现金IC卡的发卡方来说，无需关心本节内容。对于已发电子现金IC卡且选择现金充值业务的发卡方来说，该交易为必选。即：如果支持电子现金充值交易，则必须支持其其充值撤消及关联交易。选择支持该交易的发卡方必须是EMV FULL的，即银联不对early的发卡方支持电子现金类交易。3.5.3 支持的交易类型和交易流程3.5.3.1 交易类型与现金充值撤消相关的交易类型包括：现金充值撤消、现金充值撤消冲正、脚本结果通知。其中现金充值撤消交易是对原充值金额的撤消，现金充值撤消冲正是交易异常时引发的，脚本结果通知是终端发送的对脚本执行情况的通知。对受理方的要求：支持电子现金充值交易的受理方，必须同时支持这三个交易。对发卡方的要求：支持电子现金充值交易的发卡方，必须同时支持这三个交易。3.5.3.2 交易流程现金充值撤消交易的正常处理流程如下图所示：1受理方发往CUPS的现金充值撤销交易请求2CUPS发往发卡方的现金充值撤销交易请求3发卡方发往CUPS的现金充值撤销交易应答4CUPS发往受理方的现金充值撤销交易应答5受理方发往CUPS的脚本处理结果通知，告知发卡方该笔撤销交易处理的结果6CUPS发往受理方的脚本处理结果通知应答7CUPS发往发卡方的脚本处理结果通知，告知发卡方该笔撤销交易处理的结果8发卡方返回CUPS的脚本处理结果通知应答现金充值撤消的异常处理流程基本同传统消费交易，但因涉及到终端和卡片的交互，因此当终端写卡失败时，也会引发冲正。现金充值撤消不支持降级（FALLBACK）处理。对受理方的要求：（1）按照上述要求对交易进行转发和处理，含正常和异常流程。（2）受理方终端应完成电子现金IC卡的改造，能够支持脚本的处理，并正确发送脚本结果通知。（3）受理方终端对现金充值撤消交易不应支持降级（FALLBACK）处理。对发卡方的要求：（1）按照上述要求对交易进行转发和处理，含正常和异常流程。（2）发卡方系统应完成电子现金IC卡的改造，能够在应答报文中返回现金充值撤消的相关脚本。（3）发卡方能够正确处理脚本结果通知。3.5.4 联机报文说明3.5.4.1 F22、F60.2.2、F60.2.3F22，服务点输入方式码；F60.2.2，终端读取能力；F60.2.3，IC卡条件代码。这三个域在交易报文中出现时应满足一定的约束条件，具体可参见本文Error! Reference source not found.中关于60.3.7域的说明。对受理方的要求：应能够根据上表所述准确填写F22、F60.2.2、F60.2.3域信息。对发卡方的要求：应能够根据上表所述识别IC卡交易的特征。3.5.4.2 F55现金充值撤消交易执行完整的EMV流程，因此交易报文中会出现55域。相应的，其冲正交易中55域的部分Tag可能也会出现。对受理方的要求：（1）受理方发出的交易请求报文应携带55域信息。（2）受理方终端应能够根据应答报文55域校验A