卡聯網聯合技術規(guī)范V21--境內成員機構改造指南(200.doc

Q/CUP 006.42009 中國銀聯股份有限公司 發(fā)布2009-12-30實施2009-11-19發(fā)布銀行卡聯網聯合技術規(guī)范V2.1境內成員機構改造指南配套文件Q/CUP中國銀聯股份有限公司企業(yè)標準87目 次1 編制思路41.1 目的41.2 范圍41.3 編寫思路42 報文版本升級說明52.1 修改內容和原因52.2 是否為必選業(yè)務類型52.3 使用要求52.4 處理流程52.5 新業(yè)務的支持原則52.6 閱讀說明53 新增業(yè)務說明53.1 銀聯聯盟積分業(yè)務53.2 預付費卡業(yè)務73.3 信用卡還款業(yè)務103.4 IC卡借貸記應用的預授權完成（請求）交易133.5 電子現金IC卡現金充值撤消交易144 國際業(yè)務說明164.1 國際業(yè)務特色信息域164.2 額外手續(xù)費業(yè)務處理194.3 柜面取現業(yè)務處理204.4 免驗密碼網絡標志處理234.5 F37的匹配處理244.6 IC卡借貸記應用的預授權完成（請求）類交易254.7 消費（分期付款）業(yè)務294.8 銀聯卡匯率查詢業(yè)務334.9 跨境匯款業(yè)務344.10 聯機退貨業(yè)務384.11 國際業(yè)務中對F60的處理394.12 IC卡電子現金應用的業(yè)務405 代授權業(yè)務說明435.1 業(yè)務說明435.2 是否為必選業(yè)務類型455.3 發(fā)卡方改造要求456 文件接口規(guī)范說明466.1 術語和定義466.2 文件收發(fā)476.3 V2.1文件體系的調整476.4 跨行清算文件496.5 代理清算文件546.6 清算匯總文件586.7 其他文件586.8 文件的分類和選擇586.9 小結627 報文域優(yōu)化和改進內容的說明637.1 F60637.2 F48697.3 F57707.4 F2、F38、F42的唯一性717.5 F55中的新增tag717.6 IC卡借貸記應用的余額查詢737.7 F54的處理737.8 F61的處理748 數據安全傳輸與控制規(guī)范的說明758.1 類轉賬流程交易的MAC計算注意事項758.2 重置密鑰注意事項769 通訊接口規(guī)范的說明769.1 空閑連接查詢報文的間隔時間769.2 聯機交易的雙工連接7610 應答碼的整理說明7710.1 調整的內容7710.2 是否為必選業(yè)務類型7710.3 機構的處理7711 改造說明歸納8011.1 總體改造要求8011.2 具體改造要求80 銀行卡聯網聯合技術規(guī)范V2.1境內成員機構改造指南1 編制思路1.1 目的為了使各入網機構能更好地了解規(guī)范本次的修訂內容，并深刻地理解這些修訂的業(yè)務背景和必然性，銀聯V2.1規(guī)范編寫組特地編寫了此改造指南文檔，作為規(guī)范修訂內容的配套理解手冊。每個規(guī)范修訂點的內容都需要各入網機構的配合改造才能實現真正的業(yè)務上線，所以機構都很關心哪些是必選改造業(yè)務，哪些是可選改造業(yè)務。另外，規(guī)范的修訂完成并不意味著系統(tǒng)改造的完成，在系統(tǒng)改造過程中必然存在規(guī)范過渡的問題，銀聯系統(tǒng)作為轉接和清算中心承擔著過渡實現的功能，那么銀聯系統(tǒng)究竟是如何處理這些過渡內容的，也是機構關心的問題。機構可以通過對銀聯系統(tǒng)處理方式的了解來設計自己的系統(tǒng)。針對每個規(guī)范修訂點，銀聯規(guī)范編寫人員都是經過仔細討論，反復商量再修訂的，背后隱含著一些修訂的思路和思考，這些隱含的內容也是我們希望機構了解的內容，一方面是機構在了解這些深層次的原因以后能更好地理解規(guī)范為什么會有這樣的改造點又是為什么要這樣改，另一方面也希望對機構的系統(tǒng)改造提供一些思考。綜上，我們編寫了這份改造指南，希望在機構業(yè)務開展和系統(tǒng)改造設計方面提供力所能及的幫助。1.2 范圍 本改造指南涵蓋了所有涉及系統(tǒng)修改的內容，但一些只為幫助讀者更好地理解規(guī)范，卻不涉及系統(tǒng)改造內容的文字修訂和篇章結構的調整不在本文檔中描述。對于新增業(yè)務、國際業(yè)務和代授權業(yè)務這些改造比較大，比較新的內容以業(yè)務為線條來組織描述，是一種橫向描述，而不是按照規(guī)范各部分縱向的描述。這樣描述的目的在于講解新業(yè)務該如何開展，如果僅從規(guī)范各部分來描述的話，內容比較分散，讀者沒有一個完全的業(yè)務概念，不利于系統(tǒng)的開發(fā)和設計。對于數據安全、通訊接口和應答碼這三個比較獨立和相對底層或普適的內容就按照規(guī)范本身的編排結構來描述，便于讀者更好地理解規(guī)范的變更。對于優(yōu)化和改進內容，由于主要涉及報文接口的改變，雖然也是一個普適內容，但它是本次修訂的重點和難點，為便于讀者的理解和系統(tǒng)的設計，特單獨描寫。在文件接口方面，在原規(guī)范已有的跨行清算文件基礎之上又增補了銀聯代理清算文件，不同的機構所需的文件不同，改造內容也不同，為幫助機構迅速了解自身所需的改造內容，本文將機構分為15大類，每類機構可“對號入座”關注自己在文件方面的改造內容。1.3 編寫思路 整篇文檔的編寫遵守如下幾個原則：1、方便機構了解是否需要支持由該業(yè)務引發(fā)的系統(tǒng)改造。為減輕機構改造負擔，為機構提供更好的服務，分析了每個修訂點是必選改造內容還是可選改造內容。機構可據此安排改造計劃。2、以業(yè)務為線橫向貫穿規(guī)范的修訂內容。修訂規(guī)范的時候，規(guī)范每個具體的修訂點必然是要分散在規(guī)范各個部分的，但讀規(guī)范卻不能如此。如果這樣讀規(guī)范，就不能理解里面的業(yè)務含義和各自的聯系性。為便于機構的開發(fā)人員理解規(guī)范，改造指南從業(yè)務開展的角度出發(fā)，通過業(yè)務將各規(guī)范內容橫向貫穿了起來。讓機構能從業(yè)務發(fā)展角度根本性地理解這項業(yè)務的目的和處理方式，可以更好地讓機構評估該項業(yè)務開展的必要性，也為機構是否決定支持該業(yè)務提供評估標準。3、每個修訂點都是從背景描述開始，目的就是讓機構了解每個修訂點的前因后果，隱含內容，及規(guī)范編寫人員的設計思想。這樣編寫的目的是希望能給讀者一個全方面深層次的解釋，而不是僅僅從系統(tǒng)改造角度描寫。僅從技術層面描述，不能讓讀者深刻地理解這些修訂點，也就不可能讓讀者接受這些改造點，從而進行系統(tǒng)改造。4、本文描述的是由于規(guī)范的修訂而帶來的系統(tǒng)改造內容，所以一方面要緊扣規(guī)范，另一方面也不必再重復規(guī)范內容，為達到該目的，本指南采用引用規(guī)范章節(jié)號的做法。凡是涉及具體規(guī)范的內容，都會列舉最新修訂規(guī)范中的對應章節(jié)號，指明規(guī)范出處，方便讀者比對和查閱。5、本文既然是機構的改造指南，那么必然的重點是站在機構的角度分析機構應該關注的內容。文中有專門的章節(jié)描述了機構應該注意的內容和改造時應執(zhí)行的操作。由于系統(tǒng)改造不是一朝而成的，同時不能由于系統(tǒng)的改造影響現有業(yè)務的開展，所以一定會存在一個過渡期，過渡期的處理是復雜的，同時也取決于銀聯系統(tǒng)的處理方式，為了讓機構更好地理解過渡期的改造內容，本文也適當描述了銀聯系統(tǒng)的轉換功能，方便機構了解銀聯的處理以便于決定自己的改造方案和改造計劃。了解了上述五個編寫原則，讀者才能了解整篇文檔的編寫思路和希望達到的目的?？傊?，編者是希望通過這個配套文檔解釋規(guī)范的修訂原因，修訂方式，修訂目的，以指導機構更好地改造系統(tǒng)，更好地開展新業(yè)務。2 報文版本升級說明2.1 修改內容和原因報文接口規(guī)范3.2.2.2節(jié)定義了報文頭第2域的內容，其中該域的后4位組成的二進制值定義了該V2.1規(guī)范中報文格式的版本，目前的取值為0001。本次規(guī)范修訂以后，在報文接口部分涉及到一些必改內容的域結構調整，如報文體中的第60域。由于有結構上的調整，又考慮到各機構的改造進度無法統(tǒng)一，所以為便于過渡階段的報文轉換和版本控制，將此版本號修改為0010。2.2 是否為必選業(yè)務類型必選。對于受理和發(fā)卡機構而言都是必選的。2.3 使用要求若機構需要使用更新的報文版本標識0010，表示該機構已按照本改造指南中要求的與報文版本標識有關的必選改造內容完成了改造。必選改造內容請參見本文11.2節(jié)中的表格說明。一個機構只能擁有一個報文版本，要么是所有聯機報文的報文版本標識都填寫為0001，要么是全部填寫為0010。不允許有的報文填寫0001，有的填寫0010；也不允許作為受理方時填寫一個版本標識，作為發(fā)卡方時填寫另一個版本標識。2.4 處理流程如果機構改造完成，首先需要向中國銀聯上海信息中心告知已完全支持將于2009年底發(fā)布的這版修訂后規(guī)范，工作人員會將機構的版本屬性修改為最新標識。然后在機構作為受理方上送報文時，應在報文頭的第2域報文版本標識中上送新報文版本號0010。銀聯系統(tǒng)會根據接收到的報文版本信息和配置在系統(tǒng)中的機構報文版本屬性進行比較，比較一致才允許進行后續(xù)的交易處理。同時，銀聯系統(tǒng)會根據機構屬性中配置的版本信息進行不同報文版本之間的轉換處理。機構需要能夠正確識別銀聯系統(tǒng)轉發(fā)的報文版本標識和進行正確地報文解析工作。2.5 新業(yè)務的支持原則由于報文版本標識只用在聯機報文中，只是對聯機報文的版本控制，所以該取值的改變與聯機報文關系最密切，也導致該標志的使用會涉及到新增業(yè)務的支持原則。這里的新業(yè)務指的是本次修訂新增加的交易，包括本文第3章的所有內容，第3章中的4.3，4.6，4.7，4.8，4.9和4.12各節(jié)。建議機構在修訂后的最新規(guī)范中支持這些新交易。2.6 閱讀說明由于報文版本標識為二進值取值，閱讀起來不太方便，下面統(tǒng)一用修訂前規(guī)范表示0001版本標識；修訂后規(guī)范表示0010版本標識。3 新增業(yè)務說明3.1 銀聯聯盟積分業(yè)務3.1.1 業(yè)務說明銀聯聯盟積分是指依據銀行卡交易數據，聯合商戶、成員機構及其他合作機構共同為銀聯持卡人提供標準積分的行為，以及特定企業(yè)將自己積分轉換成銀聯標準積分。持卡人消費的是銀聯的聯盟積分，而不是銀行卡積分。它與銀行卡積分業(yè)務最大的不同之處在于：銀行卡積分交易的發(fā)卡方是銀行，而銀聯聯盟積分的發(fā)卡方是第三方機構，而不是銀行。3.1.2 是否為必選業(yè)務類型3.1.2.1 受理方的選擇可選。即機構做為受理方可選擇是否支持銀聯聯盟積分業(yè)務的受理。3.1.2.2 發(fā)卡方的選擇聯盟積分交易的發(fā)卡方是銀聯聯盟積分系統(tǒng)，因此不涉及銀行改造。3.1.3 支持的交易類型和交易流程3.1.3.1 交易類型聯盟積分業(yè)務支持的交易類型包括:余額查詢、消費類（含消費、消費沖正、消費撤銷、消費撤銷沖正）、退貨（聯機）。受理方可選擇支持余額查詢和消費類中的一類或兩類。如果選擇支持消費類，則需同時支持退貨（聯機）。3.1.3.2 交易流程交易處理的正常、異常和差錯流程同傳統(tǒng)消費類，無特殊。3.1.4 關鍵域的使用3.1.4.1 F25在聯盟積分業(yè)務中，25域取值與傳統(tǒng)消費不同，取值為65。受理方在其發(fā)送的交易請求報文中應按照本域定義填寫，以區(qū)別于傳統(tǒng)消費交易，詳見3.1.4.6交易關鍵域取值。3.1.4.2 F54在聯盟積分余額查詢、消費的應答報文中會出現54域。對于聯盟積分來說，54域中的“賬戶類型”90，含義為“積分賬戶”；54域中的貨幣代碼999，含義為“積分”。受理方應能夠據此正確接收和解析54域。3.1.4.3 F60.2.1在聯盟積分業(yè)務中，60.2.1域（賬戶所有人類型）與傳統(tǒng)消費不同。而且，不同的聯盟積分系統(tǒng)在60.2.1域對應不同的取值，受理方應根據終端上送的信息正確填寫本域，詳見3.1.4.6交易關鍵域取值。目前本域僅定義了一個聯盟積分系統(tǒng)，取值為A。今后根據需要本域可能會有擴展，終端和受理方應能夠支持這種擴展。3.1.4.4 F60.3.4聯盟積分業(yè)務要求在交易應答時向持卡人返回積分余額信息，因此可受理聯盟積分的終端應支持余額的接收和打印。因此，受理方在其發(fā)送的聯盟積分交易請求報文中，60.3.4域（支持部分承兌和返回余額標志）取值應為1，詳見3.1.4.6交易關鍵域取值。3.1.4.5 卡片信息的特殊處理為保障卡片信息的安全，CUPS在處理銀聯聯盟積分交易時，會將受理方上送的卡片有效期（F14）、第一、二、三磁道信息（F45、F35、F36）屏蔽掉，不再向聯盟積分系統(tǒng)傳遞。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域的取值表示目前支持的銀聯聯盟積分系統(tǒng)，受理方應能夠支持對其他聯盟積分系統(tǒng)的擴展。2. 表中60.2.5域的取值表示交易僅從POS上發(fā)起，受理方應能夠拓展支持從其他終端類型上發(fā)起。3.1.4.7 報文格式定義交易名稱報文接口規(guī)范的參見章節(jié)號余額查詢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 清算處理說明聯盟積分交易所涉及的流水文件和匯總文件均同傳統(tǒng)借貸記卡交易文件，并無差別，在此不再一一列舉。對受理方的要求：與傳統(tǒng)借貸記卡進行相同的文件處理即可。對發(fā)卡方的要求：與傳統(tǒng)借貸記卡進行相同的文件處理即可。3.1.6 過渡期期說明及注意事項受理方系統(tǒng)改造應在終端改造之前就緒，否則可能會將終端上送的聯盟積分交易誤判為普通消費或銀行卡積分消費交易，從而導致銀聯在后續(xù)進行交易轉發(fā)時出錯。發(fā)卡機構是銀聯聯盟積分系統(tǒng)，與銀行無關。3.2 預付費卡業(yè)務3.2.1 業(yè)務說明預付費卡是指：金融機構或非金融機構（統(tǒng)稱特種卡片發(fā)行機構）發(fā)行的單用途或多用途儲值卡，有別于借記卡和信用卡，采用預先支付方式；它是包含著真實購買力的卡基支付產品，為了獲得該卡片，消費者必須預先支付其價值。由于預付費卡是屬于一種儲值卡，因此它具有與普通借記卡、貸記卡不同的業(yè)務功能，主要體現在：交易成功后應返回卡內余額。3.2.2 是否為必選業(yè)務類型3.2.2.1 受理方的選擇可選，即受理方系統(tǒng)可選擇是否支持預付費卡的受理，或僅選擇其中的一類或幾類交易。詳見3.2.3.1交易類型。3.2.2.2 發(fā)卡方的選擇可選。即，若發(fā)卡方不發(fā)預付費卡，則無需進行系統(tǒng)改造；若發(fā)了預付費卡就必須進行本節(jié)所述的與發(fā)卡方相關的改造。3.2.3 支持的交易類型和交易流程3.2.3.1 交易類型交易分類交易類型受理方需支持的交易類型發(fā)卡方需支持的交易類型消費類消費、消費沖正可選若發(fā)卡方發(fā)行預付費卡，則為必選消費撤銷、消費撤銷沖正預授權類預授權、預授權沖正可選若發(fā)卡方發(fā)行預付費卡，則為必選預授權撤銷（聯機）預授權撤銷（聯機）沖正預授權撤銷（手工）預授權撤銷（手工）沖正預授權完成（手工）預授權完成（請求）預授權完成（請求）沖正預授權完成（通知）預授權完成（請求）撤銷預授權完成（請求）撤銷沖正雙信息授權類授權、授權沖正可選不支持雙信息發(fā)卡方發(fā)行預付費卡授權撤銷、授權撤銷沖正文件結算綜合上表所述： 1、受理方可選擇支持預付費卡的消費類、預授權類和授權類其中的一類或多類。2、發(fā)卡方一旦發(fā)行預付費卡，則必須同時支持消費類和預授權類。而且銀聯不支持雙信息發(fā)卡方發(fā)預付費卡。3.2.3.2 交易流程預付費卡的正常、異常處理流程均同傳統(tǒng)的同名交易。預付費卡支持的差錯類型包括：確認查詢、貸記調整、一次退單、例外協商、差錯例外。3.2.4 關鍵域的使用本節(jié)介紹支持預付費卡業(yè)務功能的幾個相關域。3.2.4.1 “返回余額”的實現機制（1） 受理方上送消費交易請求報文： 根據終端的實際能力填寫F60.3.4（支持返回余額和部分扣款標志）；（2） CUPS向發(fā)卡方轉發(fā)該報文；（3） 發(fā)卡方處理：a. 根據卡號判定是否為預付費卡交易，若不是預付費卡則跳出，不再進行后續(xù)流程。b. 根據F60.3.4的取值判定終端能否支持返回余額，如果能，就在應答報文的54域返回余額信息；如果不能則不返回54域。（4） CUPS轉發(fā)該應答報文；（5） 受理方接收該報文并向終端轉發(fā)該應答；（6） 如果終端具備接收54域的能力，則將余額信息打印在簽購單的指定位置。如果終端不具備該能力，理論上不會收到54域。3.2.4.2 F54F54（余額信息）與預付費卡交易返回余額有關。對受理方的要求：（1）可支持在預付費卡的消費、預授權、預授權完成、授權交易應答報文中接收54域信息。（2）發(fā)生交易的終端應能夠支持54域信息的接收、顯示和打印。（3）理論上，如果60.3.4域0時，發(fā)卡方不會返回54域，但仍然強烈建議受理方能夠支持這種情況下收到54域，即不要去對應答報文做60.3.4域與54域之間關系的硬性檢查，以增強受理方系統(tǒng)的健壯性。對發(fā)卡方的要求：（1）應支持在預付費卡的消費、預授權、預授權完成的成功應答報文中返回54域信息。（2）對預付費卡交易是否能夠返回余額，發(fā)卡方應根據60.3.4域的取值進行嚴格的判斷，只有當60.3.4=1時才能返回余額，否則不能返回。（3）對于非預付費卡的交易，即使60.3.4域1，發(fā)卡方也不應返回54域。3.2.4.3 F60.3.4F60.3.4（支持部分承兌和返回余額標志），與預付費卡的返回余額有關。這個域在預付費卡業(yè)務實現中是一個很關鍵的域，它實際上代表了終端是否具備受理預付費卡的能力，只有當F60.3.41（表示終端支持部分承兌和返回余額）時，該筆交易才能進入預付費卡的業(yè)務處理流程，否則只能按照傳統(tǒng)借貸記卡流程處理。對受理方的要求：（1）F60.3.4表示終端的能力，與是否預付費卡交易無關。也就是說，當終端具備了這種能力后，在該終端發(fā)起的所有交易中，該域的取值都始終為1，不會隨著交易的不同而不同。對發(fā)卡方的要求：（1）F60.3.4表示終端的能力，與是否預付費卡交易無關。也就是說，即使該標志為1，也并不意味著發(fā)卡方一定可以返回54域，還應結合卡性質（是否為預付費卡）做聯合條件的判斷。詳見7.754域的處理。3.2.4.4 交易關鍵域取值預付費卡所支持的消費類、預授權類、授權類交易關鍵報文域取值與普通借貸記卡相同，沒有任何差別，在此不再一一列舉。具體可參見報文接口規(guī)范附錄B 交易種類區(qū)分表。對受理方的要求：應按照附錄B 交易種類區(qū)分表 中的定義上送有關預付費卡的交易信息。對發(fā)卡方的要求：能夠根據附錄B的定義識別相應的交易種類，并在判斷出卡性質后，對預付費卡執(zhí)行有別于借貸記卡的處理。3.2.4.5 報文格式定義交易名稱報文接口規(guī)范的參見章節(jié)號消費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授權撤銷沖正對受理方的要求：按照相應章節(jié)的報文格式定義發(fā)送和接收報文。對發(fā)卡方的要求：按照相應章節(jié)的報文格式定義發(fā)送和接收報文。3.2.5 清算處理說明預付費卡消費類、預授權類和授權類交易所涉及的流水文件和匯總文件均同傳統(tǒng)借貸記卡，并無差別，在此不再一一列舉。注：預付費卡不收取品牌費，因此不會進入品牌費的相關文件。對受理方的要求：與傳統(tǒng)借貸記卡進行相同的文件處理即可。對發(fā)卡方的要求：與傳統(tǒng)借貸記卡進行相同的文件處理即可。3.2.6 過渡期說明及注意事項對預付費卡的支持涉及到終端、受理方和發(fā)卡方的系統(tǒng)改造，由于各方改造的進度無法統(tǒng)一，因此必然存在一個業(yè)務的過渡期，受理方和發(fā)卡方應對過渡期內的各種情況在系統(tǒng)和技術層面予以支持。下表說明了受理方系統(tǒng)已就緒，而終端尚未改造時帶來的問題以及對受理方系統(tǒng)的要求：終端改造狀態(tài)問題描述對受理方的要求未改造終端不支持在應答報文中接收54域信息受理方發(fā)出的請求報文中60.3.4域應置為0或該子域不出現?？梢钥闯觯芾矸较到y(tǒng)改造應該在終端改造之前就緒，否則無法在報文中正確反應終端的能力。下表說明了發(fā)卡方系統(tǒng)已就緒，而受理方系統(tǒng)未改造時帶來的問題及對發(fā)卡方系統(tǒng)的要求：受理方改造狀態(tài)問題描述對發(fā)卡方的要求未改造受理方報文中無60.3.4域或60.3.40發(fā)卡方可以承兌該筆預付費卡交易，但是不能向受理方返回54域?？梢钥闯?，發(fā)卡方系統(tǒng)必須在受理方系統(tǒng)改造之前就緒，否則無法滿足預付費卡的業(yè)務功能要求。3.3 信用卡還款業(yè)務3.3.1 業(yè)務說明信用卡還款是指采用轉賬交易實現對信用卡透支金額的還款。其中，轉出卡必須為借記卡，轉入卡必須為信用卡。3.3.2 是否為必選業(yè)務類型3.3.2.1 受理方的選擇可選。即受理方可選擇是否支持采用轉賬交易實現信用卡還款業(yè)務。如果選擇支持該項業(yè)務，則必須進行本節(jié)所述的受理方相關改造。3.3.2.2 發(fā)卡方的選擇可選。即發(fā)卡方可選擇是否支持采用轉賬交易實現信用卡還款業(yè)務，發(fā)卡方可選擇以下三種的任一種：（1）僅支持轉出交易；（2）僅支持轉入交易；（3）同時支持轉出和轉入。如選擇支持，則應完成相應的轉出方、轉入方相關改造。3.3.3 支持的交易類型和交易流程3.3.3.1 交易類型正常情況下，一筆信用卡還款由：受理方發(fā)出的轉賬、CUPS拆分出的轉出、CUPS拆分出的轉入三個環(huán)節(jié)即可完成。異常時，還可能引發(fā)轉出沖正或轉入確認。3.3.3.2 交易流程采用轉賬實現的信用卡還款業(yè)務正常流程如下：轉賬模式的信用卡還款交易出現異常時，會引發(fā)轉出沖正或轉入確認（均由CUPS引發(fā)），其異常流程較為復雜，具體參見銀行卡聯網聯合技術規(guī)范V2.1第一部分交易處理說明8.7.2轉賬交易。另外，轉賬交易的超時時間與普通交易有差別，即轉出方20秒，轉入方20秒，受理方50秒。綜上所述，在處理流程上對各方的要求是：對受理方的要求：在超時未收到轉賬交易應答6時，受理方不能發(fā)送轉出沖正或轉入確認，而是應通過終端提示持卡人“查詢轉出方和轉入方”。對轉出方的要求：（1）應能夠接收和處理轉出報文；（2）應能夠滿足20秒之內返回應答的要求；（3）應能夠接收和處理轉出沖正報文。對轉入方的要求：（1）應能夠接收和處理轉入報文；（2）應能夠滿足20秒之內返回應答的要求；（3）應能夠接收和處理轉入確認報文。3.3.4 聯機報文說明3.3.4.1 F18F18：商戶類型碼（Merchant Category Code），以下簡稱MCC。轉賬交易作為一種資金轉移的實現方式，可以支持多種業(yè)務。由于不同的業(yè)務可能執(zhí)行不同的業(yè)務規(guī)則、定價策略和風險要求，所以為當轉賬交易被用于實現信用卡還款業(yè)務時，為其定義了特殊的MCC：9498（信用卡還款），以便于銀聯和入網機構對交易進行區(qū)別處理。對受理方的要求：當轉賬交易被用于實現信用卡還款時，應將轉賬報文中的F18置為9498，含義為信用卡還款。對轉出方的要求：（1）當收到的轉出報文F18=9498時，應能夠識別為一筆信用卡還款的轉出業(yè)務；（2）應對轉出卡進行卡性質的檢查，若轉出卡不是借記卡，則應拒絕，F3957（不允許持卡人進行的交易）。對轉入方的要求：（1）當收到的轉入報文F189498時，應能夠識別為一筆信用卡還款的轉入業(yè)務；（2）應對轉入卡進行卡性質檢查，若轉入卡不是信用卡，則應拒絕，F3957（不允許持卡人進行的交易）。3.3.4.2 F22F22，服務點輸入方式碼，表示的是轉出卡的輸入方式。對受理方的要求：受理方應根據轉出卡的刷卡方式和是否有PIN輸入來填寫該域。對轉出方的要求：轉出方可根據該域信息獲取轉出卡的輸入方式，并進行相應的PIN檢查。對轉入方的要求：轉入方不應根據此域來判斷轉入卡的輸入方式。3.3.4.3 F28F28，交易費。在轉賬模式的信用卡還款業(yè)務中用于表示轉出方應付出的交易手續(xù)費，該手續(xù)費在銀聯、受理、轉出、轉入四方之間分潤。信用卡還款采用與普通轉賬一致的收費模式和價格水平。該域的屬性為Xn12，其中X表示交易費的借貸方向，在信用卡還款業(yè)務各個環(huán)節(jié)的報文中X固定為D，表示借記，但是該符號位僅對轉出方有效，即手續(xù)費是向轉出方收取的。對受理方的要求：受理方發(fā)出的轉賬請求報文28域不出現；受理方收到的應答報文中28域為Dn12，表示轉出方應付手續(xù)費，受理方可據此計算自己的手續(xù)費分潤。對轉出方的要求：28域表示了轉出方應付的交易手續(xù)費，此時轉出方可根據此金額計算扣收持卡人的手續(xù)費。對轉入方的要求：28域表示了轉出方應付的交易手續(xù)費，轉入方可根據此金額計算自身的手續(xù)費分潤。3.3.4.4 F2、F102、F103F2，主帳號；F102，賬戶標識1；F103，賬戶標識2；這三個帳號在轉賬交易的不同環(huán)節(jié)取值如下表所示：交易類型F2F102F103受理方發(fā)出的轉賬報文轉出卡卡號轉出卡卡號轉入卡卡號轉出方收到的轉出請求報文轉出卡卡號轉出卡卡號轉入卡卡號轉入方收到的轉入請求報文轉入卡卡號轉出卡卡號轉入卡卡號轉出方收到的轉出沖正報文轉出卡卡號轉出卡卡號轉入卡卡號轉入方收到的轉入確認報文轉入卡卡號轉出卡卡號轉入卡卡號從上表可以看出，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）重復”的現象，舉例說明如下：01022900（上海工行）是一筆信用卡還款交易的受理方和轉出方，則關于該筆交易，會有兩條記錄，一條是轉賬受理，一條是轉出，兩條記錄的F7、F11、F32、F33是一樣的，因此會出現“主鍵重復”的現象，導致轉出交易無法記庫。因此，考慮到這種情況的存在，信用卡還款交易的交易主鍵除了F7、F11、F32、F33以外，還應增加F3（交易處理碼）的前兩位。3.3.4.7 交易關鍵域取值轉賬模式的信用卡還款所涉及的交易報文關鍵域取值如下：交易名稱報文類型交易處理碼F3服務點條件碼F25商戶類型F18終端類型F60.2.5受理方發(fā)出的轉賬交易0200/021040X000009498根據實際情況填寫轉賬拆分出的轉出交易0200/021046X000轉賬拆分出的轉入交易0200/021047X000轉出沖正0420/043046X000轉入確認0220/023047X000對受理方的要求：能夠準確填寫信用卡還款的轉賬交易的關鍵信息域，尤其是F18域。對轉出方的要求：能夠根據F18的取值不同識別出一般轉賬和信用卡還款轉賬，以便于后續(xù)處理。對轉入方的要求：能夠根據F18的取值不同識別出一般轉賬和信用卡還款轉賬，以便于后續(xù)處理。3.3.5 報文格式定義交易名稱報文接口規(guī)范的參見章節(jié)號受理方發(fā)出的轉賬交易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，參見文件接口規(guī)范4.1.1.1文件列表 表11銀聯卡單信息流水文件列表CUPS下發(fā)給受理機構，用于受理機構進行交易勾對。TFL的受理方格式（參見文件接口規(guī)范5.1.2(TFL)轉賬交易流水格式）對各方來說，一般轉賬和信用卡還款轉賬都體現在同一個文件中，各方需要通過MCC進行區(qū)分，并正確核對應收手續(xù)費和應付手續(xù)費。INDYYMMDD?OTFL ，參見文件接口規(guī)范4.1.1.1文件列表 表11銀聯卡單信息流水文件列表CUPS下發(fā)給轉出機構，用于轉出機構進行交易勾對。TFL的發(fā)卡方格式（參見文件接口規(guī)范5.1.2(TFL)轉賬交易流水格式）INDYYMMDD?ITFL ，參見文件接口規(guī)范4.1.1.1文件列表 表11銀聯卡單信息流水文件列表CUPS下發(fā)給轉入機構，用于轉入機構進行交易勾對。TFL的發(fā)卡方格式（參見文件接口規(guī)范5.1.2(TFL)轉賬交易流水格式）INDYYMMDD?AERRN ，參見文件接口規(guī)范4.1.1.1文件列表 表11銀聯卡單信息流水文件列表CUPS下發(fā)給受理方，用于受理方進行差錯交易的勾對。ERRN的受理方格式（參見文件接口規(guī)范5.1.4(ERRN)差錯交易流水文件記錄格式（新）INDYYMMDD?IERRN ，參見文件接口規(guī)范4.1.1.1文件列表 表11銀聯卡單信息流水文件列表CUPS下發(fā)給轉出方和轉入方，用于差錯交易的勾對。ERRN的發(fā)卡方格式（參見文件接口規(guī)范5.1.4(ERRN)差錯交易流水文件記錄格式（新）INDYYMMDD?ILFEE，參見文件接口規(guī)范4.1.1.1文件列表 表11銀聯卡單信息流水文件列表CUPS下發(fā)給轉賬交易的轉入方，用于轉入方核對品牌費。LFE的發(fā)卡方格式（參見文件接口規(guī)范5.1.4(LFE)品牌服務費交易流水格式）該文件為可選，如轉入方需要逐筆與銀聯核對品牌費的話，可以處理該文件。INOYYMMDD?SUM，（參見文件接口規(guī)范7.1匯總文件列表 表19銀聯卡匯總文件列表）CUPS下發(fā)給交易的參與方，供參與方核對信用卡還款轉賬交易的匯總數據。SUM（參見文件接口規(guī)范5.3.5(SUM)交易匯總表）信用卡還款轉賬與一般轉賬一起匯總，體現在同一個統(tǒng)計項目中，各方應能夠準確核對。3.3.7 過渡期說明及注意事項若受理方支持信用卡還款轉賬，而轉出方或轉入方不支持，則CUPS會直接拒絕該筆轉賬交易，應答碼為40，含義為請求的功能尚不支持。3.4 IC卡借貸記應用的預授權完成（請求）交易3.4.1 業(yè)務說明該交易是對PBOC借貸記應用下預授權類交易的完善，相當于增加了一種對預授權的結算方式。3.4.2 是否為必選業(yè)務類型3.4.2.1 受理方的選擇對于只受理磁條卡的受理方來說，不必關心本節(jié)內容。對于決定或已向借貸記IC卡遷移的受理方來說，本交易為可選。3.4.2.2 發(fā)卡方的選擇對于未發(fā)IC卡的發(fā)卡方來說，不必關心本節(jié)內容。對于決定發(fā)IC卡或已向借貸記IC卡遷移的發(fā)卡方來說，本交易為必選。3.4.3 支持的交易類型和交易流程3.4.3.1 交易類型預授權完成（請求）涉及到一系列的交易，包括：預授權完成（請求）、預授權完成（請求）沖正、預授權完成（請求）撤消、預授權完成（請求）撤消沖正。3.4.3.2 交易流程交易的正常及異常流程均同同名的磁條卡交易。借貸記IC卡預授權完成(請求)及其相關交易執(zhí)行簡化的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卡條件代碼。這三個域在交易報文中出現時應滿足一定的約束條件，具體可參見7.1.3.8關于60.3.7域的說明。對受理方的要求：應能夠根據上表所述準確填寫F22、F60.2.2、F60.2.3域信息。對發(fā)卡方的要求：應能夠根據上表所述識別IC卡交易的特征。3.4.4.2 F55F55，IC卡數據域預授權完成（請求）及其相關交易（含沖正、撤消）報文中無需出現55域。對受理方的要求：受理方在預授權完成（請求）及其相關交易中無需上送55域信息。對發(fā)卡方的要求：對預授權完成（請求）及其相關交易無需驗證ARQC。3.4.4.3 交易關鍵域取值交易的關鍵域取值（報文類型、交易處理碼、服務點條件碼、商戶類型、終端類型）均同同名的磁條卡交易。3.4.4.4 報文格式定義借貸記IC卡預授權完成（請求）相關交易的報文參考以下章節(jié)：交易名稱報文接口規(guī)范的參見章節(jié)號預授權完成（請求）共用內容：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卡預授權完成（請求）交易所涉及的流水文件和匯總文件均同傳統(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）、IC卡條件代碼(F60.2.3)。3.4.6 過渡期說明及注意事項若發(fā)卡方不支持借貸記IC卡的交易且未要求CUPS代為校驗ARQC，則CUPS直接拒絕交易，返回應答碼40。3.5 電子現金IC卡現金充值撤消交易3.5.1 業(yè)務說明電子現金IC卡現金充值撤消是指對已完成的現金充值進行全額撤消。與其他IC卡撤消交易執(zhí)行簡化EMV流程不同的是：現金充值撤消需要執(zhí)行完整的EMV流程。原因是該交易需要通過55域攜帶發(fā)卡行腳本來修改電子現金卡余額。也正是由于這個原因，現金充值撤消交易不支持降級（FALLBACK）處理。3.5.2 是否為必選業(yè)務類型3.5.2.1 受理方的選擇對于不支持電子現金IC卡業(yè)務的機構來說，無需關心本節(jié)內容。對于選擇支持電子現金IC卡現金充值業(yè)務的機構，該交易為必選。即：如果受理方支持現金充值交易，則必須支持其充值撤消及關聯交易。3.5.2.2 發(fā)卡方的選擇對于未發(fā)電子現金IC卡的發(fā)卡方來說，無需關心本節(jié)內容。對于已發(fā)電子現金IC卡且選擇現金充值業(yè)務的發(fā)卡方來說，該交易為必選。即：如果支持電子現金充值交易，則必須支持其其充值撤消及關聯交易。選擇支持該交易的發(fā)卡方必須是EMV FULL的，即銀聯不對early的發(fā)卡方支持電子現金類交易。3.5.3 支持的交易類型和交易流程3.5.3.1 交易類型與現金充值撤消相關的交易類型包括：現金充值撤消、現金充值撤消沖正、腳本結果通知。其中現金充值撤消交易是對原充值金額的撤消，現金充值撤消沖正是交易異常時引發(fā)的，腳本結果通知是終端發(fā)送的對腳本執(zhí)行情況的通知。對受理方的要求：支持電子現金充值交易的受理方，必須同時支持這三個交易。對發(fā)卡方的要求：支持電子現金充值交易的發(fā)卡方，必須同時支持這三個交易。3.5.3.2 交易流程現金充值撤消交易的正常處理流程如下圖所示：1受理方發(fā)往CUPS的現金充值撤銷交易請求2CUPS發(fā)往發(fā)卡方的現金充值撤銷交易請求3發(fā)卡方發(fā)往CUPS的現金充值撤銷交易應答4CUPS發(fā)往受理方的現金充值撤銷交易應答5受理方發(fā)往CUPS的腳本處理結果通知，告知發(fā)卡方該筆撤銷交易處理的結果6CUPS發(fā)往受理方的腳本處理結果通知應答7CUPS發(fā)往發(fā)卡方的腳本處理結果通知，告知發(fā)卡方該筆撤銷交易處理的結果8發(fā)卡方返回CUPS的腳本處理結果通知應答現金充值撤消的異常處理流程基本同傳統(tǒng)消費交易，但因涉及到終端和卡片的交互，因此當終端寫卡失敗時，也會引發(fā)沖正?，F金充值撤消不支持降級（FALLBACK）處理。對受理方的要求：（1）按照上述要求對交易進行轉發(fā)和處理，含正常和異常流程。（2）受理方終端應完成電子現金IC卡的改造，能夠支持腳本的處理，并正確發(fā)送腳本結果通知。（3）受理方終端對現金充值撤消交易不應支持降級（FALLBACK）處理。對發(fā)卡方的要求：（1）按照上述要求對交易進行轉發(fā)和處理，含正常和異常流程。（2）發(fā)卡方系統(tǒng)應完成電子現金IC卡的改造，能夠在應答報文中返回現金充值撤消的相關腳本。（3）發(fā)卡方能夠正確處理腳本結果通知。3.5.4 聯機報文說明3.5.4.1 F22、F60.2.2、F60.2.3F22，服務點輸入方式碼；F60.2.2，終端讀取能力；F60.2.3，IC卡條件代碼。這三個域在交易報文中出現時應滿足一定的約束條件，具體可參見本文7.1.3.8中關于60.3.7域的說明。對受理方的要求：應能夠根據上表所述準確填寫F22、F60.2.2、F60.2.3域信息。對發(fā)卡方的要求：應能夠根據上表所述識別IC卡交易的特征。3.5.4.2 F55現金充值撤消交易執(zhí)行完整的EMV流程，因此交易報文中會出現55域。相應的，其沖正交易中55域的部分Tag可能也會出現。對受理方的要求：（1）受理方發(fā)出的交易請求報文應攜帶55域信息。（2）受理方終端應能夠根據應答報文55域校驗ARPC。（3）受理方終端應能夠正確執(zhí)行發(fā)卡行腳本，并在執(zhí)行完成后發(fā)送腳本結果通知，告知發(fā)卡行腳本執(zhí)行的情況。對發(fā)卡方的要求：（1）發(fā)卡方應根據55域信息進行ARQC校驗，并返回ARPC。（2）發(fā)卡方應在應答報文55域返回腳本。3.5.4.3 交易關鍵域取值交易名稱報文類型交易處理碼F3服務點條件碼F25商戶類型F18終端類型F60.2.5網絡管理碼F70現金充值撤消0200/021017X00091根據實際情況填寫根據實際情況填寫現金充值撤消沖正0420/043017X00091腳本結果通知0620/063017 X00091同現金充值撤消交易同現金充值撤消交易951對受理方的要求：能夠按照上表所述發(fā)送現金充值及其相關交易報文。對發(fā)卡方的要求：能夠按照上表所述識別出現金充值及其相關交易。3.5.4.4 報文格式定義電子現金IC卡現金充值相關交易的報文參考以下章節(jié)：交易名稱報文接口規(guī)范的參見章節(jié)號現金充值撤消8.7.2.1.4現金充值撤消現金充值撤消沖正8.7.1.1.2指定賬戶圈存沖正腳本結果通知8.7.2.3電子現金和借貸記應用的腳本處理結果通知報文3.5.5 清算處理說明電子現金充值撤消及其沖正與原現金充值交易一起，都參加清算和對帳。