銀行卡聯(lián)網(wǎng)聯(lián)合技術(shù)規(guī)范

1、Q/CUP中國銀聯(lián)股份有限公司企業(yè)標準配套文件銀行卡聯(lián)網(wǎng)聯(lián)合技術(shù)規(guī)范 V2.1境內(nèi)成員機構(gòu)改造指南2009-12-30 實施2009-11-19 2009-12-30 實施中國銀聯(lián)股份有限公司發(fā)布1編制思路4目的4范圍4編寫思路42報文版本升級說明5修改內(nèi)容和原因5是否為必選業(yè)務(wù)類型5使用要求5處理流程5新業(yè)務(wù)的支持原則5閱讀說明5業(yè)務(wù)說明5銀聯(lián)聯(lián)盟積分業(yè)務(wù) 5預付費卡業(yè)務(wù)7信用卡還款業(yè)務(wù)9IC卡借貸記應(yīng)用的預授權(quán)完成（請求）交易 12 TOC o 1-5 h z 電子現(xiàn)金IC卡現(xiàn)金充值撤消交易144國際業(yè)務(wù)說明16國際業(yè)務(wù)特色信息域16額外手續(xù)費業(yè)務(wù)處理18柜面取現(xiàn)業(yè)務(wù)處理19免驗密碼網(wǎng)絡(luò)標

2、志處理22F37的匹配處理23IC卡借貸記應(yīng)用的預授權(quán)完成（請求）類交易 24消費（分期付款）業(yè)務(wù) 27銀聯(lián)卡匯率查詢業(yè)務(wù) 31跨境匯款業(yè)務(wù)32聯(lián)機退貨業(yè)務(wù)36國際業(yè)務(wù)中對F60的處理37IC卡電子現(xiàn)金應(yīng)用的業(yè)務(wù)385代授權(quán)業(yè)務(wù)說明42業(yè)務(wù)說明42是否為必選業(yè)務(wù)類型43發(fā)卡方改造要求436文件接口規(guī)范說明 44術(shù)語和定義44文件收發(fā)45V2.1文件體系的調(diào)整 46跨行清算文件47代理清算文件52清算匯總文件56其他文件56文件的分類和選擇 56小結(jié)607報文域優(yōu)化和改進內(nèi)容的說明61F6061F4866F5767F2、F38、F42 的唯一性 68F55中的新增tag69IC卡借貸記應(yīng)用的余額

3、查詢70F54的處理71F61的處理718數(shù)據(jù)安全傳輸與控制規(guī)范的說明 72類轉(zhuǎn)賬流程交易的 MAC計算注意事項73重置密鑰注意事項 739通訊接口規(guī)范的說明 73空閑連接查詢報文的間隔時間73聯(lián)機交易的雙工連接 7410應(yīng)答碼的整理說明 74調(diào)整的內(nèi)容74是否為必選業(yè)務(wù)類型75機構(gòu)的處理7511改造說明歸納77總體改造要求 77具體改造要求 77銀行卡聯(lián)網(wǎng)聯(lián)合技術(shù)規(guī)范V2.1銀行卡聯(lián)網(wǎng)聯(lián)合技術(shù)規(guī)范V2.1境內(nèi)成員機構(gòu)改造指南1編制思路目的為了使各入網(wǎng)機構(gòu)能更好地了解規(guī)范本次的修訂內(nèi)容，并深刻地理解這些修訂的業(yè)務(wù)背景和必然 性，銀聯(lián)V2.1規(guī)范編寫組特地編寫了此改造指南文檔，作為規(guī)范修訂內(nèi)容的

4、配套理解手冊。每個規(guī)范修訂點的內(nèi)容都需要各入網(wǎng)機構(gòu)的配合改造才能實現(xiàn)真正的業(yè)務(wù)上線，所以機構(gòu)都很關(guān)心哪些是必選改造業(yè)務(wù)，哪些是可選改造業(yè)務(wù)。另外，規(guī)范的修訂完成并不意味著系統(tǒng)改造的完成，在系統(tǒng)改造過程中必然存在規(guī)范過渡的問題，銀聯(lián)系統(tǒng)作為轉(zhuǎn)接和清算中心承擔著過渡實現(xiàn)的功能，那么銀聯(lián)系統(tǒng)究竟是如何處理這些過渡內(nèi)容的，也是機構(gòu)關(guān)心的問題。機構(gòu)可以通過對銀聯(lián)系統(tǒng)處理方式的了解來設(shè)計自己的系統(tǒng)。針對每個規(guī)范修訂點， 銀聯(lián)規(guī)范編寫人員都是經(jīng)過仔細討論，反復商量再修訂的， 背后隱含著一些修訂的思路和思考， 這些隱含的內(nèi)容也是我們希望機構(gòu)了解的內(nèi)容，一方面是機構(gòu)在了解這些深層次的原因以后能更好地理解規(guī)范為什

5、么會有這樣的改造點又是為什么要這樣改，另一方面也希望對機構(gòu)的系統(tǒng)改造提供一些思考。綜上，我們編寫了這份改造指南，希望在機構(gòu)業(yè)務(wù)開展和系統(tǒng)改造設(shè)計方面提供力所能及的幫助。范圍本改造指南涵蓋了所有涉及系統(tǒng)修改的內(nèi)容，但一些只為幫助讀者更好地理解規(guī)范，卻不涉及系統(tǒng)改造內(nèi)容的文字修訂和篇章結(jié)構(gòu)的調(diào)整不在本文檔中描述。對于新增業(yè)務(wù)、國際業(yè)務(wù)和代授權(quán)業(yè)務(wù)這些改造比較大，比較新的內(nèi)容以業(yè)務(wù)為線條來組織描述， 是一種橫向描述，而不是按照規(guī)范各部分縱向的描述。這樣描述的目的在于講解新業(yè)務(wù)該如何開展，如果僅從規(guī)范各部分來描述的話，內(nèi)容比較分散，讀者沒有一個完全的業(yè)務(wù)概念，不利于系統(tǒng)的開發(fā)和設(shè)計。對于數(shù)據(jù)安全、通訊

6、接口和應(yīng)答碼這三個比較獨立和相對底層或普適的內(nèi)容就按照規(guī)范本身的編排 結(jié)構(gòu)來描述，便于讀者更好地理解規(guī)范的變更。對于優(yōu)化和改進內(nèi)容， 由于主要涉及報文接口的改變，雖然也是一個普適內(nèi)容， 但它是本次修訂的重點和難點，為便于讀者的理解和系統(tǒng)的設(shè)計，特單獨描寫。在文件接口方面，在原規(guī)范已有的跨行清算文件基礎(chǔ)之上又增補了銀聯(lián)代理清算文件，不同的機構(gòu)所需的文件不同，改造內(nèi)容也不同，為幫助機構(gòu)迅速了解自身所需的改造內(nèi)容， 本文將機構(gòu)分為15大類， 每類機構(gòu)可“對號入座”關(guān)注自己在文件方面的改造內(nèi)容。編寫思路整篇文檔的編寫遵守如下幾個原則：1、方便機構(gòu)了解是否需要支持由該業(yè)務(wù)引發(fā)的系統(tǒng)改造。為減輕機構(gòu)改造負

7、擔，為機構(gòu)提供更好 的服務(wù)，分析了每個修訂點是必選改造內(nèi)容還是可選改造內(nèi)容。機構(gòu)可據(jù)此安排改造計劃。2、以業(yè)務(wù)為線橫向貫穿規(guī)范的修訂內(nèi)容。修訂規(guī)范的時候，規(guī)范每個具體的修訂點必然是要分散 在規(guī)范各個部分的， 但讀規(guī)范卻不能如此。 如果這樣讀規(guī)范，就不能理解里面的業(yè)務(wù)含義和各自的聯(lián)系 性。為便于機構(gòu)的開發(fā)人員理解規(guī)范，改造指南從業(yè)務(wù)開展的角度出發(fā)，通過業(yè)務(wù)將各規(guī)范內(nèi)容橫向貫穿了起來。讓機構(gòu)能從業(yè)務(wù)發(fā)展角度根本性地理解這項業(yè)務(wù)的目的和處理方式，可以更好地讓機構(gòu)評估該項業(yè)務(wù)開展的必要性，也為機構(gòu)是否決定支持該業(yè)務(wù)提供評估標準。3、每個修訂點都是從背景描述開始，目的就是讓機構(gòu)了解每個修訂點的前因后果，

8、隱含內(nèi)容，及 規(guī)范編寫人員的設(shè)計思想。 這樣編寫的目的是希望能給讀者一個全方面深層次的解釋，而不是僅僅從系統(tǒng)改造角度描寫。 僅從技術(shù)層面描述， 不能讓讀者深刻地理解這些修訂點，也就不可能讓讀者接受這些改造點，從而進行系統(tǒng)改造。4、本文描述的是由于規(guī)范的修訂而帶來的系統(tǒng)改造內(nèi)容，所以一方面要緊扣規(guī)范，另一方面也不 必再重復規(guī)范內(nèi)容， 為達到該目的，本指南采用引用規(guī)范章節(jié)號的做法。凡是涉及具體規(guī)范的內(nèi)容，都會列舉最新修訂規(guī)范中的對應(yīng)章節(jié)號，指明規(guī)范出處，方便讀者比對和查閱。5、本文既然是機構(gòu)的改造指南，那么必然的重點是站在機構(gòu)的角度分析機構(gòu)應(yīng)該關(guān)注的內(nèi)容。文 中有專門的章節(jié)描述了機構(gòu)應(yīng)該注意的內(nèi)容

9、和改造時應(yīng)執(zhí)行的操作。由于系統(tǒng)改造不是一朝而成的，同時不能由于系統(tǒng)的改造影響現(xiàn)有業(yè)務(wù)的開展，所以一定會存在一個過渡期，過渡期的處理是復雜的，同時也取決于銀聯(lián)系統(tǒng)的處理方式，為了讓機構(gòu)更好地理解過渡期的改造內(nèi)容，本文也適當描述了銀聯(lián)系統(tǒng)的轉(zhuǎn)換功能，方便機構(gòu)了解銀聯(lián)的處理以便于決定自己的改造方案和改造計劃。了解了上述五個編寫原則， 讀者才能了解整篇文檔的編寫思路和希望達到的目的?？傊?，編者是希望通過這個配套文檔解釋規(guī)范的修訂原因，修訂方式，修訂目的，以指導機構(gòu)更好地改造系統(tǒng)， 更好地開展新業(yè)務(wù)。2報文版本升級說明2.1 修改內(nèi)容和原因報文接口規(guī)范節(jié)定義了報文頭第2域的內(nèi)容，其中該域的后 4位組成的

10、二進制值定義了 該V2.1規(guī)范中報文格式的版本，目前的取值為 0001。本次規(guī)范修訂以后，在報文接口部分涉及到一些必改內(nèi)容的域結(jié)構(gòu)調(diào)整，如報文體中的第60域。由于有結(jié)構(gòu)上的調(diào)整，又考慮到各機構(gòu)的改造進度無法統(tǒng)一，所以為便于過渡階段的報文轉(zhuǎn)換和版本控制，將此版本號修改為0010。 2.2 是否為必選業(yè)務(wù)類型必選。對于受理和發(fā)卡機構(gòu)而言都是必選的。2.3 使用要求若機構(gòu)需要使用更新的報文版本標識0010,表示該機構(gòu)已按照本改造指南中要求的與報文版本標識有關(guān)的必選改造內(nèi)容完成了改造。必選改造內(nèi)容請參見本文0節(jié)中的表格說明。一個機構(gòu)只能擁有一個報文版本，要么是所有聯(lián)機報文的報文版本標識都填寫為0001

11、 ,要么是全部填寫為0010。不允許有的報文填寫0001,有的填寫0010;也不允許作為受理方時填寫一個版本標識，作 為發(fā)卡方時填寫另一個版本標識。 2.4 處理流程如果機構(gòu)改造完成，首先需要向中國銀聯(lián)上海信息中心告知已完全支持將于2009年底發(fā)布的這版修訂后規(guī)范，工作人員會將機構(gòu)的版本屬性修改為最新標識。然后在機構(gòu)作為受理方上送報文時，應(yīng)在報文頭的第2域報文版本標識中上送新報文版本號0010。銀聯(lián)系統(tǒng)會根據(jù)接收到的報文版本信息和配置在系統(tǒng)中的機構(gòu)報文版本屬性進行比較，比較一致才允許進行后續(xù)的交易處理。同時，銀聯(lián)系統(tǒng)會根據(jù)機構(gòu)屬性中配置的版本信息進行不同報文版本之間的轉(zhuǎn)換處理。機構(gòu)需要能夠正確

12、識別銀聯(lián)系統(tǒng)轉(zhuǎn)發(fā)的報文版本標識和進行正確地報文解析工作。 2.5 新業(yè)務(wù)的支持原則由于報文版本標識只用在聯(lián)機報文中，只是對聯(lián)機報文的版本控制，所以該取值的改變與聯(lián)機報文關(guān)系最密切，也導致該標志的使用會涉及到新增業(yè)務(wù)的支持原則。這里的新業(yè)務(wù)指的是本次修訂新增加的交易，包括本文第0章的所有內(nèi)容，第0章中的0, 0, 0, 0, 0和0各節(jié)。建議機構(gòu)在修訂后的最新規(guī)范 中支持這些新交易。 2.6 閱讀說明由于報文版本標識為二進值取值，閱讀起來不太方便，下面統(tǒng)一用修訂前規(guī)范表示0001版本標識；修訂后規(guī)范表示0010版本標識。3新增業(yè)務(wù)說明銀聯(lián)聯(lián)盟積分業(yè)務(wù)業(yè)務(wù)說明銀聯(lián)聯(lián)盟積分是指依據(jù)銀行卡交易數(shù)據(jù)，聯(lián)

13、合商戶、成員機構(gòu)及其他合作機構(gòu)共同為銀聯(lián)持卡人提供標準積分的行為，以及特定企業(yè)將自己積分轉(zhuǎn)換成銀聯(lián)標準積分。持卡人消費的是銀聯(lián)的聯(lián)盟積分， 而不是銀行卡積分。它與銀行卡積分業(yè)務(wù)最大的不同之處在于：銀行卡積分交易的發(fā)卡方是銀行，而銀聯(lián)聯(lián)盟積分的發(fā)卡方是第三方機構(gòu)，而不是銀行。是否為必選業(yè)務(wù)類型受理方的選擇可選。即機構(gòu)做為受理方可選擇是否支持銀聯(lián)聯(lián)盟積分業(yè)務(wù)的受理。發(fā)卡方的選擇聯(lián)盟積分交易的發(fā)卡方是銀聯(lián)聯(lián)盟積分系統(tǒng)，因此不涉及銀行改造。支持的交易類型和交易流程交易類型聯(lián)盟積分業(yè)務(wù)支持的交易類型包括：余額查詢、消費類（含消費、消費沖正、消費撤銷、消費撤銷沖正）、退貨（聯(lián)機）。受理方可選擇支持余額查詢

14、和消費類中的一類或兩類。如果選擇支持消費類，則需同時支持退貨（聯(lián)機）。交易流程交易處理的正常、異常和差錯流程同傳統(tǒng)消費類，無特殊。關(guān)鍵域的使用 TOC o 1-5 h z F25在聯(lián)盟積分業(yè)務(wù)中，25域取值與傳統(tǒng)消費不同，取值為 65。受理方在其發(fā)送的交易請求報文中應(yīng)按照本域定義填寫，以區(qū)別于傳統(tǒng)消費交易，詳見0交易關(guān)鍵域取值。F54在聯(lián)盟積分余額查詢、消費的應(yīng)答報文中會出現(xiàn) 54域。對于聯(lián)盟積分來說，54域中的“賬戶類型”= 90,含義為“積分賬戶”；54域中的貨幣代碼=999,含義為“積分”。受理方應(yīng)能夠據(jù)此正確接收和解析54域。F60.2.1在聯(lián)盟積分業(yè)務(wù)中，60.2.1域（賬戶所有人類

15、型）與傳統(tǒng)消費不同。而且，不同的聯(lián)盟積分系統(tǒng)在對應(yīng)不同的取值，受理方應(yīng)根據(jù)終端上送的信息正確填寫本域，詳見0交易關(guān)鍵域取值。目前本域僅定義了一個聯(lián)盟積分系統(tǒng)，取值為A今后根據(jù)需要本域可能會有擴展，終端和受理方應(yīng)能夠支持這種擴展。F60.3.4聯(lián)盟積分業(yè)務(wù)要求在交易應(yīng)答時向持卡人返回積分余額信息，因此可受理聯(lián)盟積分的終端應(yīng)支持余額的接收和打印。因此，受理方在其發(fā)送的聯(lián)盟積分交易請求報文中，60.3.4域（支持部分承兌和返回余額標志）取值應(yīng)為1，詳見0交易關(guān)鍵域取值。卡片信息的特殊處理為保障卡片信息的安全，CUPSE處理銀聯(lián)聯(lián)盟積分交易時，會將受理方上送的卡片有效期（F14）、第一、二、三磁道信息

16、（F45、F35、F36）屏蔽掉，不再向聯(lián)盟積分系統(tǒng)傳遞。交易關(guān)鍵域取值交易名稱報文類型交易處 理碼F3服務(wù)點 條件碼 F25商戶類 型F18賬戶所有 人類型 F60.2.1終端類型F60.2.5支持部分承 兌和返回余 額F60.3.4余額查詢0200/021030X00000根據(jù)實 際情況 填寫A031消費0200/021000X00065A031消費沖正0420/043000X00065A031消費撤銷0200/021020X00065A031消費撤銷 沖正0420/043020X00065A031退貨（聯(lián) 機）0220/023020X00000A031或0.表中60.2.1域的取值表示目

17、前支持的銀聯(lián)聯(lián)盟積分系統(tǒng)，受理方應(yīng)能夠支持對其他聯(lián)盟積分系統(tǒng)的擴展。.表中60.2.5域的取值表示交易僅從 POSE發(fā)起，受理方應(yīng)能夠拓展支持從其他終端類型上發(fā)起。報文格式定義交易名稱報文接口規(guī)范的參見章節(jié)號余額查詢余額查詢消費 消費消費撤銷：0消費撤銷消費沖正7 沖正消費撤銷沖正7 沖正退貨（聯(lián)機）1退貨（聯(lián)機）清算處理說明聯(lián)盟積分交易所涉及的流水文件和匯總文件均同傳統(tǒng)借貸記卡交易文件，并無差別，在此不再一一列舉。對受理方的要求：與傳統(tǒng)借貸記卡進行相同的文件處理即可。對發(fā)卡方的要求：與傳統(tǒng)借貸記卡進行相同的文件處理即可。過渡期期說明及注意事項受理方系統(tǒng)改造應(yīng)在終端改造之前就緒，否則可能會將終

18、端上送的聯(lián)盟積分交易誤判為普通消費或銀行卡積分消費交易，從而導致銀聯(lián)在后續(xù)進行交易轉(zhuǎn)發(fā)時出錯。發(fā)卡機構(gòu)是銀聯(lián)聯(lián)盟積分系統(tǒng)，與銀行無關(guān)。預付費卡業(yè)務(wù)業(yè)務(wù)說明預付費卡是指：金融機構(gòu)或非金融機構(gòu)（統(tǒng)稱特種卡片發(fā)行機構(gòu)）發(fā)行的單用途或多用途儲值卡，有別于借記卡和信用卡， 采用預先支付方式；它是包含著真實購買力的卡基支付產(chǎn)品，為了獲得該卡片，消費者必須預先支付其價值。由于預付費卡是屬于一種儲值卡，因此它具有與普通借記卡、貸記卡不同的業(yè)務(wù)功能， 主要體現(xiàn)在:交易成功后應(yīng)返回卡內(nèi)余額。是否為必選業(yè)務(wù)類型受理方的選擇可選，即受理方系統(tǒng)可選擇是否支持預付費卡的受理，或僅選擇其中的一類或幾類交易。詳見3.2.3交

19、易類型。發(fā)卡方的選擇可選。即，若發(fā)卡方不發(fā)預付費卡，則無需進行系統(tǒng)改造；若發(fā)了預付費卡就必須進行本節(jié)所述的與發(fā)卡方相關(guān)的改造。3.2.3支持的交易類型和交易流程交易類型交易分類交易類型受理方需支持的交易類型發(fā)卡方需支持的交易類型消費類消費、消費沖正消費撤銷、消費撤銷沖正可選若發(fā)卜方發(fā)行預付貴卡,則 為必選預授權(quán)類預授權(quán)、預授權(quán)沖正 預授權(quán)撤銷（聯(lián)機） 預授權(quán)撤銷（聯(lián)機）沖正 預授權(quán)撤銷（手工） 預授權(quán)撤銷（手工）沖正 預授權(quán)完成（手工）預授權(quán)完成（請求） 預授權(quán)完成（請求）沖正 預授權(quán)完成（通知）預授權(quán)完成（請求）撤銷 預授權(quán)完成（請求）撤銷 沖正可選若發(fā)卜方發(fā)行預付吸卡,則 為必選雙信息授

20、權(quán)類授權(quán)、授權(quán)沖正授權(quán)撤銷、授權(quán)撤銷沖正 文件結(jié)算可選不支持雙信息發(fā)卡方發(fā)行 預付費綜合上表所述：1、受理方可選擇支持預付費卡的消費類、預授權(quán)類和授權(quán)類其中的一類或多類。2、發(fā)卡方一旦發(fā)行預付費卡，則必須同時支持消費類和預授權(quán)類。而且銀聯(lián)不支持雙信息發(fā)卡方 發(fā)預付費卡。 交易流程預付費卡的正常、異常處理流程均同傳統(tǒng)的同名交易。預付費卡支持的差錯類型包括：確認查詢、貸記調(diào)整、一次退單、例外協(xié)商、差錯例外。3.2.4關(guān)鍵域的使用本節(jié)介紹支持預付費卡業(yè)務(wù)功能的幾個相關(guān)域?！胺祷赜囝~”的實現(xiàn)機制（1）受理方上送消費交易請求報文：根據(jù)終端的實際能力填寫 F60.3.4 （支持返回余額和部分扣款標志）；（

21、2） CUP的發(fā)卡方轉(zhuǎn)發(fā)該報文；（3）發(fā)卡方處理：a.根據(jù)卡號判定是否為預付費卡交易，若不是預付費卡則跳出，不再進行后續(xù)流程。b.根據(jù)F60.3.4的取值判定終端能否支持返回余額，如果能，就在應(yīng)答報文的54域返回余額信息；如果不能則不返回 54域。（4） CUPS專發(fā)該應(yīng)答報文；（5）受理方接收該報文并向終端轉(zhuǎn)發(fā)該應(yīng)答；（6）如果終端具備接收54域的能力，則將余額信息打印在簽購單的指定位置。如果終端不具備該能力，理論上不會收到 54域。F54F54 （余額信息）與預付費卡交易返回余額有關(guān)。對受理方的要求：（1）可支持在預付費卡的消費、預授權(quán)、預授權(quán)完成、授權(quán)交易應(yīng)答報文中接收54域信息。（2）

22、發(fā)生交易的終端應(yīng)能夠支持 54域信息的接收、顯示和打印。（3）理論上，如果60.3.4域=0時，發(fā)卡方不會返回54域，但仍然強烈建議受理方能夠支持這種情 況下收到54域，即不要去對應(yīng)答報文做 60.3.4域與54域之間關(guān)系的硬性檢查，以增強受理方系統(tǒng)的健壯性。對發(fā)卡方的要求：（1）應(yīng)支持在預付費卡的消費、預授權(quán)、預授權(quán)完成的成功應(yīng)答報文中返回54域信息。（2）對預付費卡交易是否能夠返回余額，發(fā)卡方應(yīng)根據(jù)60.3.4域的取值進行嚴格的判斷，只有當60.3.4=1時才能返回余額，否則不能返回。（3）對于非預付費卡的交易，即使 60.3.4域=1,發(fā)卡方也不應(yīng)返回54域。 F60.3.4F60.3.

23、4 （支持部分承兌和返回余額標志），與預付費卡的返回余額有關(guān)。這個域在預付費卡業(yè)務(wù)實現(xiàn)中是一個很關(guān)鍵的域，它實際上代表了終端是否具備受理預付費卡的能力，只有當F60.3.4 =1 （表示終端支持部分承兌和返回余額）時，該筆交易才能進入預付費卡的業(yè)務(wù)處理流程，否則只能按照傳統(tǒng)借貸記卡流程處理。對受理方的要求：（1） F60.3.4表示終端的能力，與是否預付費卡交易無關(guān)。也就是說，當終端具 備了這種能力后，在該終端發(fā)起的所有交易中，該域的取值都始終為1,不會隨著交易的不同而不同。對發(fā)卡方的要求：（1） F60.3.4表示終端的能力，與是否預付費卡交易無關(guān)。也就是說，即使該標 志為1 ,也并不意味著

24、發(fā)卡方一定可以返回54域，還應(yīng)結(jié)合卡性質(zhì)（是否為預付費卡）做聯(lián)合條件的判斷。詳見054域的處理。 交易關(guān)鍵域取值預付費卡所支持的消費類、預授權(quán)類、授權(quán)類交易關(guān)鍵報文域取值與普通借貸記卡相同，沒有任何差別，在此不再一一列舉。具體可參見報文接口規(guī)范附錄 B交易種類區(qū)分表。對受理方的要求： 應(yīng)按照附錄B交易種類區(qū)分表 中的定義上送有關(guān)預付費卡的交易信息。對發(fā)卡方的要求：能夠根據(jù)附錄B的定義識別相應(yīng)的交易種類，并在判斷出卡性質(zhì)后，對預付費卡執(zhí)行有別于借貸記卡的處理。報文格式定義交易名稱報文接口規(guī)范的參見章節(jié)號消費 消費消費沖正7 沖正消費撤銷0消費撤銷消費撤銷沖正7 沖正預授權(quán)預授權(quán)預授權(quán)沖正7 沖正

25、預授權(quán)撤銷（聯(lián)機）預授權(quán)撤銷/預授權(quán)撤銷（手工）預授權(quán)撤銷（聯(lián)機）沖正7 沖正預授權(quán)撤銷（手工）預授權(quán)撤銷/預授權(quán)撤銷（手工）預授權(quán)撤銷（手工）沖正7 沖正預授權(quán)完成（手工）無聯(lián)機報文預授權(quán)完成（請求）預授權(quán)完成（請求）預授權(quán)完成（請求）沖正7 沖正預授權(quán)完成（通知）預授權(quán)完成（通知）預授權(quán)完成（請求）撤銷預授權(quán)完成（請求）撤銷預授權(quán)完成（請求）撤銷沖正7 沖正授權(quán) 授權(quán)授權(quán)沖正授權(quán)沖正授權(quán)撤銷授權(quán)撤銷授權(quán)撤銷沖正授權(quán)撤銷沖正對受理方的要求：按照相應(yīng)章節(jié)的報文格式定義發(fā)送和接收報文。對發(fā)卡方的要求：按照相應(yīng)章節(jié)的報文格式定義發(fā)送和接收報文。清算處理說明預付費卡消費類、預授權(quán)類和授權(quán)類交易所涉及

26、的流水文件和匯總文件均同傳統(tǒng)借貸記卡，并無差別，在此不再 列舉。注：預付費卡不收取品牌費，因此不會進入品牌費的相關(guān)文件。對受理方的要求：與傳統(tǒng)借貸記卡進行相同的文件處理即可。對發(fā)卡方的要求：與傳統(tǒng)借貸記卡進行相同的文件處理即可。過渡期說明及注意事項對預付費卡的支持涉及到終端、受理方和發(fā)卡方的系統(tǒng)改造，由于各方改造的進度無法統(tǒng)一，因此必然存在一個業(yè)務(wù)的過渡期，受理方和發(fā)卡方應(yīng)對過渡期內(nèi)的各種情況在系統(tǒng)和技術(shù)層面予以支持。卜表說明了受理方系統(tǒng)已就緒，而終端尚未改造時帶來的問題以及對受理方系統(tǒng)的要求:未改造終端不支持在應(yīng)答報文受理方發(fā)出的請求報文中60.3.4域應(yīng)置為0或該中接收54域信息子域不出現(xiàn)

27、?？梢钥闯?，受理方系統(tǒng)改造應(yīng)該在終端改造之前就緒，否則無法在報文中正確反應(yīng)終端的能力。卜表說明了發(fā)卡方系統(tǒng)已就緒，而受理方系統(tǒng)未改造時帶來的問題及對發(fā)卡方系統(tǒng)的要求:未改造受理方報文中無 60.3.4發(fā)卡方可以承兌該筆預付費卡交易，但是不能向域或60.3.4 =0受理方返回54域。可以看出，發(fā)卡方系統(tǒng)必須在受理方系統(tǒng)改造之前就緒，否則無法滿足預付費卡的業(yè)務(wù)功能要求。3.3信用卡還款業(yè)務(wù)業(yè)務(wù)說明信用卡還款是指采用轉(zhuǎn)賬交易實現(xiàn)對信用卡透支金額的還款。其中，轉(zhuǎn)出卡必須為借記卡，轉(zhuǎn)入卡必須為信用卡。是否為必選業(yè)務(wù)類型受理方的選擇如果選擇支持該項業(yè)務(wù)，則必可選。即受理方可選擇是否支持采用轉(zhuǎn)賬交易實現(xiàn)信用

28、卡還款業(yè)務(wù)。如果選擇支持該項業(yè)務(wù)，則必須進行本節(jié)所述的受理方相關(guān)改造。發(fā)卡方的選擇可選。即發(fā)卡方可選擇是否支持采用轉(zhuǎn)賬交易實現(xiàn)信用卡還款業(yè)務(wù)，發(fā)卡方可選擇以下三種的任一種：（1）僅支持轉(zhuǎn)出交易；（2）僅支持轉(zhuǎn)入交易；（3）同時支持轉(zhuǎn)出和轉(zhuǎn)入。如選擇支持，則應(yīng)完 成相應(yīng)的轉(zhuǎn)出方、轉(zhuǎn)入方相關(guān)改造。支持的交易類型和交易流程交易類型正常情況下，一筆信用卡還款由：受理方發(fā)出的轉(zhuǎn)賬、CUP斷分出的轉(zhuǎn)出、CUP斷分出的轉(zhuǎn)入三個環(huán)節(jié)即可完成。異常時，還可能引發(fā)轉(zhuǎn)出沖正或轉(zhuǎn)入確認。交易流程采用轉(zhuǎn)賬實現(xiàn)的信用卡還款業(yè)務(wù)正常流程如下：轉(zhuǎn)賬模式的信用卡還款交易出現(xiàn)異常時，會引發(fā)轉(zhuǎn)出沖正或轉(zhuǎn)入確認（均由CUPSI發(fā)），

29、其異常流程較為復雜，具體參見銀行卡聯(lián)網(wǎng)聯(lián)合技術(shù)規(guī)范V2.1 第一部分交易處理說明8.7.2轉(zhuǎn)賬交易。另外，轉(zhuǎn)賬交易的超時時間與普通交易有差別，即轉(zhuǎn)出方20秒，轉(zhuǎn)入方20秒，受理方50秒。綜上所述，在處理流程上對各方的要求是：對受理方的要求：在超時未收到轉(zhuǎn)賬交易應(yīng)答 6時，受理方不能發(fā)送轉(zhuǎn)出沖正或轉(zhuǎn)入確認，而是應(yīng) 通過終端提示持卡人“查詢轉(zhuǎn)出方和轉(zhuǎn)入方”。對轉(zhuǎn)出方的要求：（1）應(yīng)能夠接收和處理轉(zhuǎn)出報文；（2）應(yīng)能夠滿足20秒之內(nèi)返回應(yīng)答的要求；（3）應(yīng)能夠接收和處理轉(zhuǎn)出沖正報文。對轉(zhuǎn)入方的要求：（1）應(yīng)能夠接收和處理轉(zhuǎn)入報文；（2）應(yīng)能夠滿足20秒之內(nèi)返回應(yīng)答的要求；（3）應(yīng)能夠接收和處理轉(zhuǎn)入確

30、認報文。聯(lián)機報文說明F18F18:商戶類型碼（Merchant Category Code ）,以下簡稱 MCC轉(zhuǎn)賬交易作為一種資金轉(zhuǎn)移的實現(xiàn)方式，可以支持多種業(yè)務(wù)。由于不同的業(yè)務(wù)可能執(zhí)行不同的業(yè)務(wù)規(guī)則、定價策略和風險要求，所以為當轉(zhuǎn)賬交易被用于實現(xiàn)信用卡還款業(yè)務(wù)時，為其定義了特殊的MCC9498 （信用卡還款），以便于銀聯(lián)和入網(wǎng)機構(gòu)對交易進行區(qū)別處理。對受理方的要求：當轉(zhuǎn)賬交易被用于實現(xiàn)信用卡還款時，應(yīng)將轉(zhuǎn)賬報文中的F18置為9498,含義為信用卡還款。對轉(zhuǎn)出方的要求：（1）當收到的轉(zhuǎn)出報文F18=9498時，應(yīng)能夠識別為一筆信用卡還款的轉(zhuǎn)出業(yè)務(wù)；（2）應(yīng)對轉(zhuǎn)出卡進行卡性質(zhì)的檢查，若轉(zhuǎn)出卡不

31、是借記卡，則應(yīng)拒絕，F(xiàn)39=57 （不允許持卡人進行的交易）。對轉(zhuǎn)入方的要求：（1）當收到的轉(zhuǎn)入報文F18=9498時，應(yīng)能夠識別為一筆信用卡還款的轉(zhuǎn)入業(yè)務(wù)；（2）應(yīng)對轉(zhuǎn)入卡進行卡性質(zhì)檢查，若轉(zhuǎn)入卡不是信用卡，則應(yīng)拒絕，F(xiàn)39=57 （不允許持卡人進行的交易）。F22F22,服務(wù)點輸入方式碼，表示的是轉(zhuǎn)出卡的輸入方式。對受理方的要求：受理方應(yīng)根據(jù)轉(zhuǎn)出卡的刷卡方式和是否有PIN輸入來填寫該域。對轉(zhuǎn)出方的要求： 轉(zhuǎn)出方可根據(jù)該域信息獲取轉(zhuǎn)出卡的輸入方式，并進行相應(yīng)的PIN檢查。對轉(zhuǎn)入方的要求： 轉(zhuǎn)入方不應(yīng)根據(jù)此域來判斷轉(zhuǎn)入卡的輸入方式。F28F28,交易費。在轉(zhuǎn)賬模式的信用卡還款業(yè)務(wù)中用于表示轉(zhuǎn)出

32、方應(yīng)付出的交易手續(xù)費，該手續(xù)費在 銀聯(lián)、受理、轉(zhuǎn)出、轉(zhuǎn)入四方之間分潤。信用卡還款采用與普通轉(zhuǎn)賬一致的收費模式和價格水平。該域的屬性為X+ n12,其中X表示交易費的借貸方向，在信用卡還款業(yè)務(wù)各個環(huán)節(jié)的報文中X固定為D,表示借記，但是該符號位僅對轉(zhuǎn)出方有效，即手續(xù)費是向轉(zhuǎn)出方收取的。對受理方的要求：受理方發(fā)出的轉(zhuǎn)賬請求報文 28域不出現(xiàn)；受理方收到的應(yīng)答報文中 28域為D+ n12, 表示轉(zhuǎn)出方應(yīng)付手續(xù)費，受理方可據(jù)此計算自己的手續(xù)費分潤。對轉(zhuǎn)出方白要求：28域表示了轉(zhuǎn)出方應(yīng)付的交易手續(xù)費，此時轉(zhuǎn)出方可根據(jù)此金額計算扣收持卡人的手續(xù)費。對轉(zhuǎn)入方白要求：28域表示了轉(zhuǎn)出方應(yīng)付的交易手續(xù)費，轉(zhuǎn)入方可

33、根據(jù)此金額計算自身的手續(xù)費分潤。F2、F102、F103F2,主帳號；F102,賬戶標識1; F103,賬戶標識2;這三個帳號在轉(zhuǎn)賬交易的不同環(huán)節(jié)取值如下表所示:交易類型F2F102F103受理方發(fā)出的轉(zhuǎn)賬報文轉(zhuǎn)出卡T二口. 、勺轉(zhuǎn)出卡轉(zhuǎn)入卡H二 口 、勺轉(zhuǎn)出方收到的轉(zhuǎn)出請求報文轉(zhuǎn)出卡T二 口、勺轉(zhuǎn)出卡轉(zhuǎn)入卡H二 口 、勺轉(zhuǎn)入方收到的轉(zhuǎn)入請求報文一轉(zhuǎn)入卡H二口. 、勺轉(zhuǎn)出卡轉(zhuǎn)入卡H二 口 、勺轉(zhuǎn)出方收到的轉(zhuǎn)出沖正報文轉(zhuǎn)出卡T二 口、勺轉(zhuǎn)出卡轉(zhuǎn)入卡H二 口 、勺轉(zhuǎn)入方收到的轉(zhuǎn)入確認報文轉(zhuǎn)入卡H二口. 、勺轉(zhuǎn)出卡4轉(zhuǎn)入卡H二 口 、勺從上表可以看出，F(xiàn)102和F103域全程不變，僅F2M在交易過程

34、中根據(jù)交易報文的接收方不同而有變化，因此對交易各方的要求如下:對受理方的要求：受理方應(yīng)將F2置為轉(zhuǎn)出卡卡號；對轉(zhuǎn)出方的要求：轉(zhuǎn)出方可通過轉(zhuǎn)出報文、轉(zhuǎn)出沖正報文第2域直接獲取轉(zhuǎn)出卡號；對轉(zhuǎn)入方的要求：轉(zhuǎn)入方可通過轉(zhuǎn)入報文、轉(zhuǎn)入確認報文第2域直接獲取轉(zhuǎn)入卡號。F121.5F121.5 ,用法ID,轉(zhuǎn)入和轉(zhuǎn)出方標識代碼。1-8位放置轉(zhuǎn)出方標識代碼；9-16位放置轉(zhuǎn)入方標識代碼。對受理方的要求：無特殊要求。如果受理方需要了解轉(zhuǎn)出方機構(gòu)代碼和轉(zhuǎn)入方機構(gòu)代碼時，可解析此域。對轉(zhuǎn)出方的要求： 無特殊要求。如果轉(zhuǎn)出方需要了解轉(zhuǎn)入方機構(gòu)代碼，可解析此域。對轉(zhuǎn)入方的要求：無特殊要求。如果轉(zhuǎn)入方需要了解轉(zhuǎn)出方機構(gòu)代

35、碼，可解析此域。交易的主鍵轉(zhuǎn)賬交易涉及受理、 轉(zhuǎn)出、轉(zhuǎn)入三個角色，機構(gòu)可以是其中的一方或同時擔任兩方角色，如同時是受理方和轉(zhuǎn)出方、或同時是受理方和轉(zhuǎn)入方、或同時是轉(zhuǎn)出方和轉(zhuǎn)入方。當同時擔任兩方時，可能會出 現(xiàn)“交易主鍵（F7、F11、F32、F33）重復”的現(xiàn)象，舉例說明如下：01022900 （上海工行）是一筆信用卡還款交易的受理方和轉(zhuǎn)出方，則關(guān)于該筆交易，會有兩條記錄,一條是轉(zhuǎn)賬受理，一條是轉(zhuǎn)出，兩條記錄的F7、F11、F32、F33是一樣的，因此會出現(xiàn)“主鍵重復”的現(xiàn)象，導致轉(zhuǎn)出交易無法記庫。因此，考慮到這種情況的存在，信用卡還款交易的交易主鍵除了F7、F11、F32、F33以外，還應(yīng)增

36、加F3 （交易處理碼）的前兩位。交易關(guān)鍵域取值轉(zhuǎn)賬模式的信用卡還款所涉及的交易報文關(guān)鍵域取值如下:交易名稱報文類型交易處理碼F3服務(wù)點條件碼F25商戶類型F18終端類型F60.2.5受理方發(fā)出的轉(zhuǎn)賬交易0200/021040X000009498根據(jù)實際情 況填寫轉(zhuǎn)賬拆分出的轉(zhuǎn)出交易0200/021046X000轉(zhuǎn)賬拆分出的轉(zhuǎn)入交易0200/021047X000轉(zhuǎn)出沖正0420/043046X000轉(zhuǎn)入確認P0220/023047X000對受理方的要求對轉(zhuǎn)出方的要求對轉(zhuǎn)入方的要求能夠準確填寫信用卡還款的轉(zhuǎn)賬交易的關(guān)鍵信息域，尤其是對受理方的要求對轉(zhuǎn)出方的要求對轉(zhuǎn)入方的要求F18 域。能夠根據(jù)F1

37、8F18 域。能夠根據(jù)F18的取值不同識別出一般轉(zhuǎn)賬和信用卡還款轉(zhuǎn)賬，以便于后續(xù)處理。3.3.5報文格式定義交易名稱報文接口規(guī)范的參見章節(jié)號受理方發(fā)出的轉(zhuǎn)賬交易6.1轉(zhuǎn)賬報文轉(zhuǎn)賬拆分出的轉(zhuǎn)出交易6.2轉(zhuǎn)出轉(zhuǎn)賬報文轉(zhuǎn)賬拆分出的轉(zhuǎn)入交易6.3轉(zhuǎn)入轉(zhuǎn)賬報文轉(zhuǎn)出沖正6.4轉(zhuǎn)出轉(zhuǎn)賬沖正轉(zhuǎn)入確認6.5轉(zhuǎn)入確認3.3.6 清算處理說明成功的信用卡還款轉(zhuǎn)賬參加當日清算；受理方、轉(zhuǎn)出方、轉(zhuǎn)入方各收到一個流水文件，可用于交易勾對。當存在轉(zhuǎn)出沖正時，轉(zhuǎn)出交易和轉(zhuǎn)出沖正交易同時參加清算，均出現(xiàn)在轉(zhuǎn)出方流水文件中;當存在轉(zhuǎn)入確認時，轉(zhuǎn)入確認參加清算，僅轉(zhuǎn)入確認出現(xiàn)在轉(zhuǎn)入方流水文件中。對信用卡還款轉(zhuǎn)賬交易，品牌服務(wù)費向轉(zhuǎn)

38、入行收取。支持信用卡還款的機構(gòu)需要支持以下文件：文件名稱文件用途記錄格式代碼特殊問題說明INDYYMMDD?ATFL ,參見文件接口規(guī)范文件列表 表11銀聯(lián)卡單信息流水文件 列表CUPS下發(fā)給受理機 構(gòu)，用于受理機構(gòu)進行 交易勾對。TFL的受理方格式（參 見文件接口規(guī)范5.1.2（TFL）轉(zhuǎn)賬交易 流水格式）對名方來說，一般轉(zhuǎn) 賬和信用卡還款轉(zhuǎn)賬 都體現(xiàn)在同一個文件 中，各方需要通過 MCC進行區(qū)分，并正 確核對應(yīng)收手續(xù)費和 應(yīng)付手續(xù)費。INDYYMMDD?OTFL ,參見文件接口規(guī) 范文件列表 表11銀聯(lián)卡單信息流水 文件列表CUPS下發(fā)給轉(zhuǎn)出機 構(gòu)，用于轉(zhuǎn)出機構(gòu)進行 交易勾對。TFL的發(fā)卡

39、方格式（參 見文件接口規(guī)范 5.1.2（TFL）轉(zhuǎn)賬交易 流水格式）INDYYMMDD?ITFL,參見文件接口規(guī)范文件列表 表11銀聯(lián)卡單信息流水文件 列表CUPS下發(fā)給轉(zhuǎn)入機 構(gòu)，用于轉(zhuǎn)入機構(gòu)進行 交易勾對。TFL的發(fā)卡方格式（參 見文件接口規(guī)范 5.1.2（TFL）轉(zhuǎn)賬交易 流水格式）INDYYMMDD?AERRN ,參見文件接口 規(guī)范文件列表 表11銀聯(lián)卡單信息流 水文件列表CUPS下發(fā)給受理方， 用于受理方進行差錯 交易的勾對。ERRN的受理方格式 （參見文件接口規(guī)范5.1.4（ERRN）差錯 交易流水文件記錄格 式（新）INDYYMMDD?IERRN ,參見文件接口規(guī) 范文件列表 表

40、11銀聯(lián)卡單信息流水 文件列表CUPS下發(fā)給轉(zhuǎn)出方和 轉(zhuǎn)入方，用于差錯交易 的勾對。ERRN的發(fā)卡方格式 （參見文件接口規(guī)范5.1.4（ERRN）差錯 交易流水文件記錄格 式（新）INDYYMMDD?ILFEE ，參見文件接口規(guī)范文件列表 表11銀聯(lián)卡單信息流水文件 列表CUPS下發(fā)給轉(zhuǎn)賬交易 的轉(zhuǎn)入方，用于轉(zhuǎn)入方 核對品牌費。LFE的發(fā)卡方格式（參 見文件接口規(guī)范5.1.4（LFE）品牌服務(wù) 費交舄流水格式）該文件為可選，如轉(zhuǎn) 入方需要逐筆與銀聯(lián) 核對品牌費的話，可 以處理該文件。INOYYMMDD?SUM ,（參見文件接口規(guī)范7.1匯總文件列表表19銀聯(lián)卡匯總文件列表）CUPS下發(fā)給交易的

41、參 與方，供參與方核對信 用卡還款轉(zhuǎn)賬交易的 匯總數(shù)據(jù)。SUM （參見文件接 口規(guī)范5.3.5（SUM） 交易匯總表）信用卡還款轉(zhuǎn)賬與一 般轉(zhuǎn)賬一起匯總，體 現(xiàn)在同一個統(tǒng)計項目 中，各方應(yīng)能夠準確 核對。3.3.7 過渡期說明及注意事項若受理方支持信用卡還款轉(zhuǎn)賬，而轉(zhuǎn)出方或轉(zhuǎn)入方不支持，則CUP窯直接拒絕該筆轉(zhuǎn)賬交易，應(yīng)答碼為40,含義為請求的功能尚不支持。3.4 IC卡借貸記應(yīng)用的預授權(quán)完成（請求）交易業(yè)務(wù)說明該交易是對PBO借貸記應(yīng)用下預授權(quán)類交易的完善，相當于增加了一種對預授權(quán)的結(jié)算方式。是否為必選業(yè)務(wù)類型受理方的選擇對于只受理磁條卡的受理方來說，不必關(guān)心本節(jié)內(nèi)容。對于決定或已向借貸記I

42、C卡遷移的受理方來說，本交易為可選。發(fā)卡方的選擇對于未發(fā)IC卡的發(fā)卡方來說，不必關(guān)心本節(jié)內(nèi)容。對于決定發(fā)IC卡或已向借貸記IC卡遷移的發(fā)卡方來說，本交易為必選。支持的交易類型和交易流程交易類型預授權(quán)完成（請求）涉及到一系列的交易，包括：預授權(quán)完成（請求）、預授權(quán)完成（請求）沖正、預授權(quán)完成（請求）撤消、預授權(quán)完成（請求）撤消沖正。交易流程交易的正常及異常流程均同同名的磁條卡交易。借貸記IC卡預授權(quán)完成（請求）及其相關(guān)交易執(zhí)行簡化的 EMVf程，即交易無需ARQCBARP破驗，體 現(xiàn)在交易報文上就是不必攜帶55域信息。聯(lián)機報文說明F22、F60.2.2、F60.2.3F22,服務(wù)點輸入方式碼；F

43、60.2.2 ,終端讀取能力；F60.2.3 , IC卡條件代碼。這三個域在交易報文中出現(xiàn)時應(yīng)滿足一定的約束條件，具體可參見0關(guān)于60.3.7域的說明。對受理方的要求：應(yīng)能夠根據(jù)上表所述準確填寫F22、F60.2.2、F60.2.3域信息。對發(fā)卡方的要求：應(yīng)能夠根據(jù)上表所述識別IC卡交易的特征。F55F55, IC卡數(shù)據(jù)域預授權(quán)完成（請求）及其相關(guān)交易（含沖正、撤消）報文中無需出現(xiàn)55域。對受理方的要求：受理方在預授權(quán)完成（請求）及其相關(guān)交易中無需上送55域信息。對發(fā)卡方的要求：對預授權(quán)完成（請求）及其相關(guān)交易無需驗證ARQC交易關(guān)鍵域取值交易的關(guān)鍵域取值（報文類型、交易處理碼、服務(wù)點條件碼、

44、商戶類型、終端類型）均同同名的磁條卡交易。報文格式定義借貸記IC卡預授權(quán)完成（請求）相關(guān)交易的報文參考以下章節(jié)：交易名稱報文接口規(guī)范的參見章節(jié)號預授權(quán)完成（請求）共用內(nèi)容：預授權(quán)完成（請求）IC卡特殊內(nèi)容：.2消費撤消、預授權(quán)撤消、存款撤消、預授權(quán) 完成（請求）、預授權(quán)完成（請求）撤消報文格式報文格式預授權(quán)完成（請求）沖正共用內(nèi)容：7沖正IC卡特殊內(nèi)容：.8沖正中“原始交易沒有55域信息的沖正類交易報文格式”預授權(quán)完成（請求）撤消共用內(nèi)容：預授權(quán)完成撤消IC卡特殊內(nèi)容：.2消費撤消、預授權(quán)撤消、存款撤消、預授權(quán) 完成（請求）、預授權(quán)完成（請求）撤消報文格式報文格式預授權(quán)完成（請求）撤消沖正共用

45、內(nèi)容：7沖正IC卡特殊內(nèi)容：.8沖正中“原始交易沒有55域信息的沖正類交易報文格式”3.4.5清算處理說明借貸記IC卡預授權(quán)完成（請求）交易所涉及的流水文件和匯總文件均同傳統(tǒng)磁條卡同名交易，并無差別，在此不再一一列舉。對受理方的要求：（1）與傳統(tǒng)磁條卡同名交易進行相同的文件處理即可。（2）注意對文件中IC卡特征字段進行識別和處理，包括：卡序列號（F23）、終端讀取能力（F60.2.2 ）、IC卡條件代碼（F60.2.3）。對發(fā)卡方的要求：（1）與傳統(tǒng)磁條卡同名交易進行相同的文件處理即可。（2）注意對文件中IC卡特征字段進行識別和處理，包括：卡序列號（F23）、終端讀取能力（F60.2.2 ）、

46、IC卡條件代碼（F60.2.3）。3.4.6過渡期說明及注意事項若發(fā)卡方不支持借貸記IC卡的交易且未要求 CUPS；為校驗ARQC則CUP直接拒絕交易，返回應(yīng)答碼 40。3.5電子現(xiàn)金IC卡現(xiàn)金充值撤消交易業(yè)務(wù)說明電子現(xiàn)金IC卡現(xiàn)金充值撤消是指對已完成的現(xiàn)金充值進行全額撤消。與其他IC卡撤消交易執(zhí)行簡化 EM航程不同的是：現(xiàn)金充值撤消需要執(zhí)行完整的EMVf程。原因是該交易需要通過55域攜帶發(fā)卡行腳本來修改電子現(xiàn)金卡余額。也正是由于這個原因， 現(xiàn)金充值撤消交易不支持降級（FALLBACK處理。是否為必選業(yè)務(wù)類型受理方的選擇對于不支持電子現(xiàn)金IC卡業(yè)務(wù)的機構(gòu)來說，無需關(guān)心本節(jié)內(nèi)容。對于選擇支持電子

47、現(xiàn)金IC卡現(xiàn)金充值業(yè)務(wù)的機構(gòu)，該交易為必選。即：如果受理方支持現(xiàn)金充值交 易，則必須支持其充值撤消及關(guān)聯(lián)交易。發(fā)卡方的選擇對于未發(fā)電子現(xiàn)金IC卡的發(fā)卡方來說，無需關(guān)心本節(jié)內(nèi)容。對于已發(fā)電子現(xiàn)金IC卡且選擇現(xiàn)金充值業(yè)務(wù)的發(fā)卡方來說，該交易為必選。即：如果支持電子現(xiàn)金充值交易，則必須支持其其充值撤消及關(guān)聯(lián)交易。選擇支持該交易的發(fā)卡方必須是EMV FULL勺，即銀聯(lián)不對early的發(fā)卡方支持電子現(xiàn)金類交易。支持的交易類型和交易流程交易類型與現(xiàn)金充值撤消相關(guān)的交易類型包括：現(xiàn)金充值撤消、現(xiàn)金充值撤消沖正、腳本結(jié)果通知。其中現(xiàn)金充值撤消交易是對原充值金額的撤消，現(xiàn)金充值撤消沖正是交易異常時引發(fā)的，腳本結(jié)

48、果通知是終端發(fā)送的對腳本執(zhí)行情況的通知。對受理方的要求： 支持電子現(xiàn)金充值交易的受理方，必須同時支持這三個交易。對發(fā)卡方的要求： 支持電子現(xiàn)金充值交易的發(fā)卡方，必須同時支持這三個交易。交易流程現(xiàn)金充值撤消交易的正常處理流程如下圖所示：1一受理方發(fā)往CUPS的現(xiàn)金充值撤銷交易請求2 CUPS發(fā)往發(fā)卡方的現(xiàn)金充值撤銷交易請求3發(fā)卡方發(fā)往CUPS的現(xiàn)金充值撤銷交易應(yīng)答4 CUPS發(fā)往受理方的現(xiàn)金充值撤銷交易應(yīng)答5一受理方發(fā)往CUPS的腳本處理結(jié)果通知，告知發(fā)卡方該筆撤銷交易處理的結(jié)果6 CUPS發(fā)往受理方的腳本處理結(jié)果通知應(yīng)答7-CUPS發(fā)往發(fā)卡方的腳本處理結(jié)果通知，告知發(fā)卡方該筆撤銷交易處理的結(jié)果

49、8-發(fā)卡方返回CUPS的腳本處理結(jié)果通知應(yīng)答現(xiàn)金充值撤消的異常處理流程基本同傳統(tǒng)消費交易，但因涉及到終端和卡片的交互，因此當終端寫卡失敗時，也會引發(fā)沖正?，F(xiàn)金充值撤消不支持降級（FALLBACK處理。對受理方的要求： （1）按照上述要求對交易進行轉(zhuǎn)發(fā)和處理，含正常和異常流程。（2）受理方終端應(yīng)完成電子現(xiàn)金IC卡的改造，能夠支持腳本的處理，并正確發(fā)送腳本結(jié)果通知。（3）受理方終端對現(xiàn)金充值撤消交易不應(yīng)支持降級（ FALLBACK處理。對發(fā)卡方的要求： （1）按照上述要求對交易進行轉(zhuǎn)發(fā)和處理，含正常和異常流程。（2）發(fā)卡方系統(tǒng)應(yīng)完成電子現(xiàn)金IC卡的改造，能夠在應(yīng)答報文中返回現(xiàn)金充值撤消的相關(guān)腳本。

50、（3）發(fā)卡方能夠正確處理腳本結(jié)果通知。3.5.4 聯(lián)機報文說明F22、F60.2.2、F60.2.3F22,服務(wù)點輸入方式碼；F60.2.2 ,終端讀取能力；F60.2.3 , IC卡條件代碼。這三個域在交易報文中出現(xiàn)時應(yīng)滿足一定的約束條件，具體可參見本文0中關(guān)于60.3.7域的說明。對受理方的要求：應(yīng)能夠根據(jù)上表所述準確填寫F22、F60.2.2、F60.2.3域信息。對發(fā)卡方的要求：應(yīng)能夠根據(jù)上表所述識別IC卡交易的特征。F55現(xiàn)金充值撤消交易執(zhí)行完整的EM流程，因此交易報文中會出現(xiàn) 55域。相應(yīng)的，其沖正交易中 55域的部分Tag可能也會出現(xiàn)。對受理方的要求：（1）受理方發(fā)出的交易請求報

51、文應(yīng)攜帶55域信息。（2）受理方終端應(yīng)能夠根據(jù)應(yīng)答報文55域校驗ARPC （3）受理方終端應(yīng)能夠正確執(zhí)行發(fā)卡行腳本，并在執(zhí)行完成后發(fā)送腳本結(jié)果 通知，告知發(fā)卡行腳本執(zhí)行的情況。對發(fā)卡方的要求：（1）發(fā)卡方應(yīng)根據(jù)55域信息進行ARQ皎驗，并返回ARPC （2）發(fā)卡方應(yīng)在應(yīng)答報文55域返回腳本。交易關(guān)鍵域取值交易名稱報文類型交易處理碼F3服務(wù)點條件碼F25商戶類型F18終端類型F60.2.5網(wǎng)絡(luò)管理碼F70現(xiàn)金充值撤消0200/021017X00091根據(jù)實際根據(jù)實際情現(xiàn)金充值撤消沖正0420/043017X00091情況填寫況填寫腳本結(jié)果通知0620/063017 X00091同現(xiàn)金充 值撤消交

52、 易同現(xiàn)金充值 撤消交易951對受理方的要求：能夠按照上表所述發(fā)送現(xiàn)金充值及其相關(guān)交易報文。對發(fā)卡方的要求： 能夠按照上表所述識別出現(xiàn)金充值及其相關(guān)交易。 報文格式定義電子現(xiàn)金IC卡現(xiàn)金充值相關(guān)交易的報文參考以下章節(jié):交易名稱報文接口規(guī)范的參見章節(jié)號現(xiàn)金充值撤消.4現(xiàn)金充值撤消現(xiàn)金充值撤消沖正.2指定賬戶圈存沖正腳本結(jié)果通知電子現(xiàn)金和借貸記應(yīng)用的腳本處理結(jié)果通知報文3.5.5清算處理說明電子現(xiàn)金充值撤消及其沖正與原現(xiàn)金充值交易一起，都參加清算和對帳。交易金額和手續(xù)費都參與清算?，F(xiàn)金充值交易不收取品牌費，不涉及品牌費文件。涉及到的相關(guān)文件如下表所示：文件名稱文件用途記錄格式代碼特殊問題說明IND

53、YYMMDD?ALOD ,（參見文件接口規(guī)范文件列表 表11銀聯(lián)卡單信息流水文件 列表）CUPS下發(fā)給受理方， 用于現(xiàn)金充值業(yè)務(wù)的 勾對。LOD現(xiàn)金充值業(yè)務(wù)與IC卡 指定賬戶圈存業(yè)務(wù)包 含在同一個流水文件 中。INDYYMMDD?ILOD ,（參見文件接口規(guī) 范文件列表 表11銀聯(lián)卡單信息流水 文件列表）CUPS下發(fā)給發(fā)卡方， 用于現(xiàn)金充值業(yè)務(wù)的 勾對。LODINDYYMMDD?ALER ,（參見文件接口規(guī) 范文件列表 表11銀聯(lián)卡單信息流水CUPS下發(fā)給受理方， 用于現(xiàn)金充值差錯業(yè)LER現(xiàn)金充值交易的 差錯與圈存類交易的文件列表）務(wù)的勾對。差錯包含在同一個流 水文件中。INDYYMMDD?I

54、LER ,（參見文件接口規(guī)范文件列表 表11銀聯(lián)卡單信息流水文件 列表）CUPS下發(fā)給發(fā)卡方， 用于現(xiàn)金充值差錯業(yè) 務(wù)的勾對。LERINOYYMMDD?SUM ,（參見文件接口規(guī)范6.1匯總文件列表）CUPS下發(fā)給交易的參 與方，供參與方核對現(xiàn) 金充值業(yè)務(wù)的匯總數(shù) 據(jù)。SUM （參見文件接 口規(guī)范7.2.1（SUM） 交易匯總表）現(xiàn)金充值撤消匯總在summary report 的“IC PBOC CASH CANCEL ”項目中。對受理方的要求：（1）能夠處理和解析上表所述的文件。（2）能夠區(qū)分現(xiàn)金充值業(yè)務(wù)和指定賬戶圈存業(yè)務(wù)的相關(guān)交易。對發(fā)卡方的要求：（1）能夠處理和解析上表所述的文件。（2）

55、能夠區(qū)分現(xiàn)金充值業(yè)務(wù)和指定賬戶圈存業(yè)務(wù)的相關(guān)交易。3.5.6 過渡期說明及注意事項現(xiàn)金充值類業(yè)務(wù)屬于新增業(yè)務(wù)類型，只有受理方、發(fā)卡方同時完成系統(tǒng)改造，交易才可能成功，不存在過渡期。對于現(xiàn)金充值業(yè)務(wù)所包含的所有交易類型，受理方、發(fā)卡方必須全部支持，不能僅支持充值而不支持撤消，而且必須是該類業(yè)務(wù)所包含的交易類型全部同時上線。4國際業(yè)務(wù)說明國際業(yè)務(wù)特色信息域業(yè)務(wù)說明對于境內(nèi)發(fā)行的銀聯(lián)卡在境外使用的情況（以下簡稱北卡南用） 銀聯(lián)系統(tǒng)目前的做法是對境內(nèi)機構(gòu)完全屏蔽了原始交易的地域信息和原始交易幣種信息，即無論交易幣種是何種類型都將交易金額轉(zhuǎn)換為等值的人民幣金額向境內(nèi)機構(gòu)發(fā)送。但隨著北卡南用交易量的擴大，

56、越來越多的機構(gòu)希望了解境外交易的實際發(fā)生情況，而且人民幣可自由兌換將是一個發(fā)展趨勢，未來在境內(nèi)也可能出現(xiàn)非人民幣結(jié)算的情況，所以本次規(guī)范修訂確定將國際業(yè)務(wù)的特色信息域放入聯(lián)機報文一并傳送給境內(nèi)發(fā)卡方。這些特色信息域包括：第一類 多幣種信息：F5清算金額，F(xiàn)研卡人扣賬金額，F(xiàn)9青算匯率，F(xiàn)10持卡人扣賬匯率，F(xiàn)16兌 換日期，F(xiàn)50清算幣種，F(xiàn)51持卡人扣賬幣種；第二類 交易發(fā)生地信息：F19受理機構(gòu)國家代碼第三類 一磁道信息：F45第一磁道信息。提到一磁是因為在北卡南用的情況下，境外受理機構(gòu)有讀一磁數(shù)據(jù)并以一磁數(shù)據(jù)為交易數(shù)據(jù)的終端，而既然終端能讀出一磁數(shù)據(jù)，說明境內(nèi)發(fā)卡方有寫一磁數(shù)據(jù)的卡片，為

57、了支持這些卡片在這樣的特殊終端上的交易，需要在聯(lián)機報文中支持一磁信息。是否為必選業(yè)務(wù)類型受理方的選擇雖然在國際業(yè)務(wù)中也存在境外發(fā)行的銀聯(lián)卡在境內(nèi)使用的情況（以下簡稱南卡北用），但由于在境內(nèi)的使用要符合境內(nèi)的規(guī)定，因此，交易幣種一定是人民幣幣種，交易發(fā)生地的國家代碼一定是中國地區(qū)，且國內(nèi)終端都是以二磁為交換數(shù)據(jù)，即使讀一磁數(shù)據(jù)也肯定會上送二磁數(shù)據(jù)，所以，考慮到終端改造的困難，同時也為減小受理機構(gòu)的改造，V2.1規(guī)范對上述三類特色信息的支持都不涉及受理方上送請求交易的改造。但是在這種模式下， 持卡人的扣賬幣種與交易幣種可能是不相同的，根據(jù)規(guī)范要求當二者不同時，中心需要向受理方傳遞真實的持卡人扣賬信

58、息。另外，為保證規(guī)范境內(nèi)卷和跨境卷處理方式上的一致，中心會在應(yīng)答報文中向受理方傳遞交易發(fā)生地信息。故，境內(nèi)受理機構(gòu)在上送請求報文時不必支持這三類特征信息，但在接收應(yīng)答時需要支持第一類和第二類特征信息。發(fā)卡方的選擇國際業(yè)務(wù)中最重要的業(yè)務(wù)模式就是北卡南用模式，而北卡南用時境內(nèi)發(fā)行的銀聯(lián)卡都是在境外使 用，因此交易發(fā)生地和交易發(fā)生幣種都是千變?nèi)f化的，且也存在境外受理機構(gòu)僅上送一磁的現(xiàn)象，在這些情況下，境內(nèi)發(fā)卡方就必選接收國際業(yè)務(wù)特色信息域并能給予處理，因此，這三類特色信息域全部為必選。支持的交易類型和交易流程交易類型多幣種信息涉及的交易類型涉及境內(nèi)機構(gòu)修改的內(nèi)容主要在于涉及資金結(jié)算的跨境業(yè)務(wù)所涉及到

59、的交易類型，包含（需要注意的是，所有的撤銷類交易都不在其中）：第一類 單信息交易：預授權(quán)、預授權(quán)完成（請求）、取現(xiàn)、消費（含一次性消費和分期付款）、 及其上述交易的沖正交易、預授權(quán)完成（通知）、結(jié)算通知、退貨（聯(lián)機）、銀聯(lián)卡匯率查詢、 匯款（聯(lián)機）。第二類 雙信息交易：授權(quán)、及其沖正。第三類IC卡借貸記應(yīng)用交易：消費、取現(xiàn)、預授權(quán)、預授權(quán)完成（請求）、授權(quán)、預授權(quán)完成（通 知）、退貨、結(jié)算通知、及其上述交易的沖正。第四類IC卡電子現(xiàn)金應(yīng)用交易：指定賬戶圈存、現(xiàn)金充值、指定賬戶圈存沖正、現(xiàn)金充值沖正。第五類 由CUPSecure認證的網(wǎng)上交易：消費、預授權(quán)、余額查詢、預授權(quán)完成（請求）、聯(lián)機退貨

60、、 及其它們的沖正。交易發(fā)生地信息涉及的交易類型除包含節(jié)列舉的所有交易類型以外，還包含它們的撤銷交易。一磁信息涉及的交易類型除包含節(jié)列舉的所有交易類型以外，還包含它們的撤銷交易。交易流程交易流程與現(xiàn)有同名交易保持完成一致。關(guān)鍵域的使用多幣種信息域多幣種信息域的出現(xiàn)全部都是條件出現(xiàn)的，只有在符合條件的情況下才出現(xiàn)，否則不出現(xiàn)。它們出現(xiàn)的條件是：1、域5 （清算金額）、域9 （清算匯率）、域16 （兌換日期）、域50 （清算貨幣代碼）均涉及清算， 當交易發(fā)生所采用的幣種和機構(gòu)與銀聯(lián)約定的清算幣種不同時，在聯(lián)機類涉及清算金額的報文中均會出現(xiàn)。授權(quán)類及查詢類交易由于不參加清算，其對應(yīng)的報文中不包含這幾