支付寶網(wǎng)銀接入業(yè)務規(guī)范V103.doc

支付寶網(wǎng)銀接入業(yè)務規(guī)范副標題：網(wǎng)銀接入標準版本 0.3修訂歷史版本號作者內(nèi)容提要核準人發(fā)布日期1.0.1葛喬初稿2010-2-261.0.2王增賢初稿2010-2-281.0.3葛喬增加明細查詢業(yè)務完善余額查詢條件完善結(jié)算標準2010-3-9目 錄1文檔概述41.1目標讀者41.2版本規(guī)范42交互模式42.1同步交互模式42.2異步交互模式52.3文件上傳模式63網(wǎng)銀業(yè)務73.1支付業(yè)務73.1.1業(yè)務功能83.1.2業(yè)務規(guī)則83.1.3處理流程93.1.4交互模式103.1.5業(yè)務要素113.2交易查詢123.2.1業(yè)務功能123.2.2業(yè)務規(guī)則123.2.3處理流程133.2.4交互模式133.2.5業(yè)務要素143.3余額查詢153.3.1業(yè)務功能153.3.2業(yè)務規(guī)則153.3.3處理流程163.3.4交互模式163.3.5業(yè)務要素173.4退貨業(yè)務183.4.1業(yè)務功能183.4.2業(yè)務規(guī)則183.4.3處理流程193.4.4交互模式203.4.5業(yè)務要素213.5清算業(yè)務223.5.1業(yè)務功能223.5.2業(yè)務規(guī)則233.5.3處理流程243.5.4交互模式253.5.5業(yè)務要素263.5.6文件格式274安全規(guī)范274.1安全配置274.1.1算法選擇274.1.2切換配置284.2數(shù)字簽名284.2.1簽名數(shù)據(jù)284.2.2簽名算法294.3數(shù)據(jù)加密294.3.1加密內(nèi)容294.3.2加密算法295附錄305.1結(jié)算標準305.2業(yè)務FAQ301文檔概述本文檔主要描述支付寶與銀行之間的網(wǎng)銀接入業(yè)務規(guī)范業(yè)務內(nèi)容、交互模式，安全配置等內(nèi)容。1.1 目標讀者本文的主要目標讀者是支付寶網(wǎng)銀接入業(yè)務銀行方的業(yè)務規(guī)劃人員，其中的部分內(nèi)容也可供銀行的管理與技術(shù)人員參考。1.2 版本規(guī)范支付寶網(wǎng)銀接入業(yè)務規(guī)范的版本規(guī)范是：.。本文介紹支付寶網(wǎng)銀接入業(yè)務規(guī)范的1.0.3版。2 交互模式支付寶網(wǎng)銀接入業(yè)務規(guī)范交互模式，根據(jù)不同業(yè)務需求包括：同步交互模式，異步交互模式，文件上傳模式三種交互模式。2.1 同步交互模式 同步交互模式，也叫請求-應答模式。在請求-應答模式下，一方作為服務提供者，另一方作為服務使用者。由服務使用者主動向服務提供者發(fā)起請求并等待應答，服務提供者接受請求，完成處理，并向服務使用者應答處理結(jié)果，服務使用者收到處理結(jié)果之后進行后續(xù)處理。請求-應答模式適用于服務使用者需要根據(jù)服務提供者的服務應答才能進行正確的后續(xù)處理的場景，比如，在交易查詢業(yè)務中，支付寶作為服務使用者，銀行作為服務提供者，支付寶需要知道銀行的交易處理結(jié)果之后才能繼續(xù)交易流程。2.2 異步交互模式異步交互模式，一方作為服務提供者，另一方作為服務使用者。由服務使用者主動向服務提供者發(fā)起請求，服務提供者接受請求，完成處理(圖：服務請求)。返回應答結(jié)果時，之前的服務提供者角色變?yōu)榉帐褂谜?，把處理的結(jié)果作為服務請求主動向之前的服務使用者發(fā)起請求，而之前的服務使用者角色變?yōu)榉仗峁┱?，提供接收應答結(jié)果的服務(圖：服務應答)。異步模式適用于服務提供者處理完服務請求后，需要主動通知服務使用者處理結(jié)果的場景。比如，在網(wǎng)銀支付業(yè)務中，支付寶作為服務使用者，銀行作為服務提供者，支付寶請求數(shù)據(jù)會跳轉(zhuǎn)到銀行網(wǎng)銀頁面，用戶在網(wǎng)銀頁面支付成功后，銀行需要把處理結(jié)果主動通知給支付寶，支付寶作為接收結(jié)果的服務方再做后續(xù)處理。圖：服務請求圖：服務應答2.3 文件上傳模式在文件上傳模式中，一方作為文件提供者，另一方作為文件使用者。文件提供者首先生成文件，然后將文件上傳給文件提供者。在文件上傳完成之后，文件提供者通知文件使用者，通知信息中包含文件的上傳位置與其它信息。文件使用者接到通知之后，根據(jù)文件內(nèi)容進行后續(xù)的業(yè)務處理。文件上傳模式的特點是文件使用者擁有文件服務系統(tǒng)。由于網(wǎng)銀接入規(guī)范中，文件服務系統(tǒng)是由支付寶統(tǒng)一提供的，因此，文件上傳模式適用于由銀行向支付寶發(fā)起的對帳業(yè)務處理請求，如清算對賬等。3 網(wǎng)銀業(yè)務支付寶網(wǎng)銀接入規(guī)范網(wǎng)銀業(yè)務支持業(yè)務包括：支付業(yè)務，交易查詢，余額查詢，內(nèi)部戶明細查詢，退貨業(yè)務和清算業(yè)務；以上各業(yè)務都為7*24小時運行，節(jié)假日同樣處理。下面對每個業(yè)務進行詳細描述。3.1 支付業(yè)務 支付業(yè)務主要實現(xiàn)互聯(lián)網(wǎng)交易中的買家，通過銀行網(wǎng)銀方式來給支付寶帳戶充值或進行交易支付的業(yè)務。3.1.1 業(yè)務功能 互聯(lián)網(wǎng)用戶可以通過支付業(yè)務， 把用戶在銀行卡中的資金用于在支付寶網(wǎng)站上的交易支付和帳戶充值等業(yè)務。從而完成用戶在互聯(lián)網(wǎng)上的購物行為。3.1.2 業(yè)務規(guī)則a) 支付業(yè)務從支付寶發(fā)起b) 支付寶清算流水號必須支付寶系統(tǒng)唯一c) 支付業(yè)務金額不能超過銀行網(wǎng)銀產(chǎn)品限額d) 銀行對同一清算流水號的重復支付請求，只做一次處理e) 銀行對超過網(wǎng)銀用戶限額的支付業(yè)務請求，不能做成功處理3.1.3 處理流程支付業(yè)務流程：a) 用戶在支付寶收銀臺選擇充值銀行b) 支付寶按 支付要素 構(gòu)造報文提交銀行接口c) 支付寶引導用戶到選擇的銀行網(wǎng)銀進行充值操作d) 用戶根據(jù)銀行網(wǎng)銀的要求進行操作（如：輸入卡號、密碼進行校驗；插入U盾等）e) 銀行根據(jù)規(guī)則對用戶操作進行驗證，并根據(jù) 支付返回要素 向支付寶返回i. 驗證成功：1. 銀行實時接口通知支付寶該筆交易成功2. 銀行將該筆用戶充值資金進行記錄，日終匯總一筆轉(zhuǎn)賬給支付寶在銀行開設的賬戶或內(nèi)部戶3. 銀行引導用戶跳轉(zhuǎn)到支付寶成功頁面ii. 驗證失敗：1. 該筆充值操作結(jié)束，銀行告知用戶失敗原因3.1.4 交互模式在支付業(yè)務中，銀行與支付寶通過異步交互模式進行交互。在支付流程第2步和第3步中，支付寶構(gòu)造請求要素并且主動向銀行網(wǎng)銀交易請求。在支付流程第6步和第7步中，銀行網(wǎng)銀處理結(jié)束應答結(jié)果時主動向支付寶發(fā)起請求。3.1.5 業(yè)務要素“支付業(yè)務”請求要素：要素名稱英文縮寫要素要求金額Amountl 必須要素，單位是分。幣種Currencyl 非必須要素，如果沒有該要素，則默認為人民幣?？愋蚦ardtypel 必須要素，銀行按支付寶發(fā)送的借、貸、其他標示控制用戶所支付能支持的卡類型清算流水號SerialNumberl 必須要素，由支付寶生成，銀行進行保存，其長度至少大于20位字符，支持數(shù)字和字符。l 該字段在銀行系統(tǒng)的唯一性，當天不重復l 在銀行系統(tǒng)不可重復的范圍內(nèi)，如果有重復的流水號提交到銀行，一定不能允許其支付。l 這里的流水號唯一性指的是相同商戶標號下的流水號唯一性。清算日期SettleTimel 非必須要素，格式為：yyyyMMddHHmmss。l 該要素用來進行流水號重復性控制，以及釣魚的防范，比如：銀行系統(tǒng)時間在SettleTime-30分鐘SettleTime+30分鐘以內(nèi)有效，超過該范圍的訂單不能進行支付。l 該要素可用來做資金對賬用。商戶編號MerchantNumberl 必須要素，銀行端用來定位密鑰以及清算流水號。數(shù)字簽名Signaturel 必須要素，必須使用非對稱加密算法生成l 待簽名要素必須覆蓋所有接口中需要傳遞的要素支付結(jié)果回執(zhí)地址ReturnUrll 銀行可以通過服務器通知，或者頁面跳轉(zhuǎn)來通知。支付寶建議使用通知服務器來通知，增加可靠性。“支付業(yè)務”應答要素：要素名稱英文縮寫要素要求金額Amountl 必須要素，單位是分。幣種Currencyl 非必須要素，如果沒有該要素，則默認為人民幣。卡類型cardtypel 必須要素，銀行按支付寶發(fā)送的借、貸、其他標示控制用戶所支付能支持的卡類型清算流水號SerialNumberl 必須要素，由支付寶生成，銀行進行保存，其長度至少大于20位字符，支持數(shù)字和字符。l 該字段在銀行系統(tǒng)的唯一性，當天不重復l 在銀行系統(tǒng)不可重復的范圍內(nèi)，如果有重復的流水號提交到銀行，一定不能允許其支付。l 這里的流水號唯一性指的是相同商戶標號下的流水號唯一性。清算日期SettleTimel 非必須要素，格式為：yyyyMMddHHmmss。l 該要素用來進行流水號重復性控制，以及釣魚的防范，比如：銀行系統(tǒng)時間在SettleTime-30分鐘SettleTime+30分鐘以內(nèi)有效，超過該范圍的訂單不能進行支付。l 該要素可用來做資金對賬用。清算狀態(tài)SettleStatusl 該要素必須有明確的結(jié)果返回。商戶編號MerchantNumberl 必須要素，銀行端用來定位密鑰以及清算流水號。數(shù)字簽名Signaturel 必須要素，必須使用非對稱加密算法生成l 待簽名要素必須覆蓋所有接口中需要傳遞的要素支付結(jié)果回執(zhí)地址ReturnUrll 銀行可以通過服務器通知，或者頁面跳轉(zhuǎn)來通知。支付寶建議使用通知服務器來通知，增加可靠性。3.2 交易查詢交易查詢業(yè)務是支付寶系統(tǒng)向銀行系統(tǒng)查詢某筆交易在銀行系統(tǒng)中處理最終結(jié)果的業(yè)務。目的是確認某筆交易的最終處理狀態(tài)。3.2.1 業(yè)務功能對于支付寶發(fā)送銀行的支付、退貨請求，因網(wǎng)絡、系統(tǒng)等原因造成掉單的交易，為了提升用戶使用體驗，減少用戶對資金的擔憂與咨詢，需在最短的時間內(nèi)進行恢復。此時支付寶需要向銀行查詢原請求在銀行端的狀態(tài)或結(jié)果，銀行需將最終結(jié)果返回給支付寶。3.2.2 業(yè)務規(guī)則a） 交易查詢業(yè)務僅支持單查詢b） 查詢交易結(jié)果為銀行最終處理結(jié)果 3.2.3 處理流程交易查詢流程：a) 支付寶按交易查詢要素構(gòu)造查詢報文向銀行發(fā)起查詢請求b) 銀行系統(tǒng)接收查詢請求，解析報文內(nèi)容c) 銀行系統(tǒng)查詢系統(tǒng)內(nèi)對應交易號狀態(tài)，并且構(gòu)造結(jié)果應答報文返回d) 支付寶系統(tǒng)接收銀行查詢結(jié)果應答報文e) 支付寶系統(tǒng)處理查詢應答結(jié)果3.2.4 交互模式在交易查詢業(yè)務中，銀行與支付寶通過同步交互模式進行交互。在交易查詢流程第1步、第2步、第3步和第4步交互中，支付寶構(gòu)造請求要素并且主動向銀行系統(tǒng)發(fā)起查詢請求，銀行系統(tǒng)接收報文，處理查詢請求后，構(gòu)造結(jié)果報文并返回支付寶系統(tǒng)。 3.2.5 業(yè)務要素“交易查詢”請求要素：要素名稱英文縮寫要素要求清算流水號SerialNumberl 必須要素，同支付時的流水號要求清算日期TransDatel 必須要素，格式為：yyyyMMddl 銀行要用該要素來進行流水號重復性控制，即銀行要查詢TransDate那天的流水號。商戶編號MerchantNumberl 必須要素，用來定位密鑰，以及流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。類型Typel支付l退貨數(shù)字簽名Signaturel 必須要素，必須使用非對稱加密算法生成l 待簽名要素必須覆蓋所有接口中需要傳遞的要素l 若查詢時采用的雙向加密認證的通信通道則可以不使用數(shù)字簽名“交易查詢”應答要素：要素名稱英文縮寫要素要求清算流水號SerialNumberl 必須要素，同支付時的流水號要求清算金額RealAmountl 必須要素，銀行實際清算成功金額，在接口文檔中要詳細說明該要素單位，是元還是分，還是千分位格式。清算日期SettleDatel 必須要素，格式為：yyyyMMddl 銀行清算日期。做充退時用來定位其實際日期。商戶編號MerchantNumberl 必須要素，用來定位密鑰，以及流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。清算狀態(tài)SettleStatusl 必須要素，完整的狀態(tài)必須包括成功，失敗，處理中，查無記錄。l 若銀行系統(tǒng)與其核心系統(tǒng)之間狀態(tài)無法確定，有兩種選擇1、可以告知清算狀態(tài)為處理中，2、告訴失敗，銀行自行沖正這筆交易，要確保該交易不會再變成成功。數(shù)字簽名Signaturel 必須要素，必須使用非對稱加密算法生成l 待簽名要素必須覆蓋所有接口中需要傳遞的要素l 若查詢時采用的雙向加密認證的通信通道則可以不使用數(shù)字簽名3.3 明細查詢（共用卡通提現(xiàn)的明細查詢接口）明細查詢主要指，支付寶為向銀行發(fā)起的查詢銀行內(nèi)部戶賬務變化明細的業(yè)務。目的是獲了支付寶在銀行內(nèi)部戶的賬務明細。3.3.1 業(yè)務功能因支付寶不在異地城商行開戶，未能登錄城商行網(wǎng)銀，故需查詢內(nèi)部戶賬務明細用于對賬。查詢回的明細要記錄與更新。3.3.2 業(yè)務規(guī)則a） 明細查詢業(yè)務需支持按時間段查詢（如：2010-3-1 2010-3-3）b） 明細查詢結(jié)果中的帳戶明細為該時間段支付寶內(nèi)部戶的交易明細3.3.3 處理流程明細查詢流程：a) 支付寶系統(tǒng)按明細查詢要素構(gòu)造明細查詢報文向銀行發(fā)起查詢請求b) 銀行系統(tǒng)接收請求報文，校驗數(shù)據(jù)是否有效c) 銀行系統(tǒng)查詢支付寶在銀行內(nèi)部戶該時間段賬務明細，并構(gòu)造結(jié)果報文返回d) 支付寶系統(tǒng)接收銀行明細查詢結(jié)果應答報文e) 支付寶系統(tǒng)記錄銀行內(nèi)部戶該時間段明細3.3.4 交互模式在明細查詢業(yè)務中，銀行與支付寶通過同步交互模式進行交互。在交易查詢流程第1步、第2步、第3步和第4步交互中，支付寶構(gòu)造請求要素并且主動向銀行系統(tǒng)發(fā)起查詢請求，銀行系統(tǒng)接收報文，處理查詢請求后，構(gòu)造結(jié)果報文并返回支付寶系統(tǒng)。3.3.5 業(yè)務要素“明細查詢”請求要素：要素名稱英文縮寫要素要求開始日期StartDatel 必須要素，用來確定查詢的開始日期結(jié)束日期EndDatel 必須要素，用來確定查詢的結(jié)束日期商戶編號MerchantNumberl 必須要素，用來定位密鑰，以及流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。數(shù)字簽名Signaturel 必須要素，必須使用非對稱加密算法生成l 待簽名要素必須覆蓋所有接口中需要傳遞的要素l 若查詢時采用的雙向加密認證的通信通道則可以不使用數(shù)字簽名“明細查詢”應答要素：明細數(shù)據(jù)要素：要素名稱英文縮寫要素要求交易日TransDatel 必須要素，賬戶明細變化時的日期金額RealAmountl 必須要素，銀行實際清算成功金額，在接口文檔中要詳細說明該要素單位，是元還是分，還是千分位格式。借貸Debit Creditl 必須要素，按借、貸進行區(qū)分顯示余額Balancel 必須要素，用來返回賬戶明細發(fā)生變化后的余額摘要Memol 必須要素，對該筆款項的注釋，比如：往來款、清算款、B2C充值、B2C退貨、卡通充值、卡通提現(xiàn)、卡通退貨商戶編號MerchantNumberl 必須要素，用來定位密鑰，以及流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。數(shù)字簽名Signaturel 必須要素，必須使用非對稱加密算法生成3.4 余額查詢（共用卡通的余額查詢接口）余額查詢業(yè)務是支付寶為向銀行發(fā)起的查詢銀行內(nèi)部戶頭寸的業(yè)務。目的是獲了支付寶在銀行內(nèi)部戶的余額。3.4.1 業(yè)務功能 因支付寶不在異地城商行開戶，只能開設內(nèi)部戶，需實時查詢內(nèi)部戶余額，此余額是隨業(yè)務增長而變化的。同時因結(jié)算需要，還需查詢每日支付寶內(nèi)部戶余額，此余額是日切后支付寶內(nèi)部戶余額，該余額日切后不可變化。查詢回的最新余額要分別記錄與更新。3.4.2 業(yè)務規(guī)則c） 余額查詢業(yè)務僅支持單查詢d） 余額查詢結(jié)果中的帳戶余額為支付寶可用余額3.4.3 處理流程余額查詢流程：f) 支付寶系統(tǒng)按余額查詢要素構(gòu)造余額查詢報文向銀行發(fā)起查詢請求g) 銀行系統(tǒng)接收請求報文，校驗數(shù)據(jù)是否有效h) 銀行系統(tǒng)查詢支付寶在銀行內(nèi)部戶余額，并構(gòu)造結(jié)果報文返回i) 支付寶系統(tǒng)接收銀行余額查詢結(jié)果應答報文j) 支付寶系統(tǒng)更新余額3.4.4 交互模式在余額查詢業(yè)務中，銀行與支付寶通過同步交互模式進行交互。在交易查詢流程第1步、第2步、第3步和第4步交互中，支付寶構(gòu)造請求要素并且主動向銀行系統(tǒng)發(fā)起查詢請求，銀行系統(tǒng)接收報文，處理查詢請求后，構(gòu)造結(jié)果報文并返回支付寶系統(tǒng)。3.4.5 業(yè)務要素“余額查詢”請求要素：要素名稱英文縮寫要素要求日期Datel 必須要素，用來定位查詢?nèi)掌陬愋蚑ypel 必須要素，N表示當前余額，該余額是變化的；H表示該日最終余額，該余額是不可變化的商戶編號MerchantNumberl 必須要素，用來定位密鑰，以及流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。數(shù)字簽名Signaturel 必須要素，必須使用非對稱加密算法生成l 待簽名要素必須覆蓋所有接口中需要傳遞的要素l 若查詢時采用的雙向加密認證的通信通道則可以不使用數(shù)字簽名“余額查詢”應答要素：要素名稱英文縮寫要素要求日期Datel 必須要素，用來返回查詢?nèi)掌谫~戶余額Balancel 必須要素，用來返回余額商戶編號MerchantNumberl 必須要素，用來定位密鑰，以及流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。數(shù)字簽名Signaturel 必須要素，必須使用非對稱加密算法生成l 待簽名要素必須覆蓋所有接口中需要傳遞的要素l 若查詢時采用的雙向加密認證的通信通道則可以不使用數(shù)字簽名3.5 退貨業(yè)務 退貨業(yè)務是支付寶發(fā)起的把已經(jīng)支付成功并且結(jié)算成功的交易，按原路退回到用戶銀行卡的業(yè)務。目的是把用戶支付業(yè)務的現(xiàn)金退回到用戶的銀行卡中。3.5.1 業(yè)務功能對于客戶的充值金額，為防止套現(xiàn)或借用支付寶渠道轉(zhuǎn)帳，支付寶控制客戶不能轉(zhuǎn)入其它銀行。為滿足客戶充值金額返回原充值銀行卡的需求，開發(fā)充值退回功能，即退貨業(yè)務。3.5.2 業(yè)務規(guī)則a) 退貨業(yè)務從支付寶發(fā)起。b) 單筆退貨業(yè)務必須有對應的支付寶支付業(yè)務交易c) 單筆退貨的金額不能超過對應的支付交易的金額，但可以少于支付時的金額d) 可支持多次退款，但退款總金額應少于支付時該筆交易的金額e) 單筆退貨的資金只能原路劃回支付業(yè)務使用的銀行卡賬戶中f) 客戶單筆退回時收到的資金只能從支付寶公司事先約定的清算賬戶中劃撥g) 同一退回訂單號的單筆退貨交易銀行必須保證只能執(zhí)行一次h) 在未獲取到銀行對該筆沖退有明確結(jié)果前，不得再發(fā)起對該筆交易的第2筆沖退操作a) 如果由于支付寶系統(tǒng)原因再次發(fā)起沖退，銀行應明確做失敗處理i) 銀行與支付寶需要保存單筆退回相關(guān)報文的日志，作為解決資金清算不一致的憑據(jù)j) 支持1年內(nèi)的交易退貨請求3.5.3 處理流程退貨業(yè)務流程：第一階段：客戶申請階段a) 客戶對充值金額申請普通提現(xiàn)。b) 提現(xiàn)失敗，錯誤提示頁面出現(xiàn)充值退回頁面鏈接入口。c) 支付寶系統(tǒng)對退回交易的合法性進行驗證。驗證內(nèi)容包括：n 客戶的銀行退貨服務狀態(tài)是否為激活n 單筆退回的交易是使用網(wǎng)銀充值的如果上述驗證中有一項不符合，則支付寶系統(tǒng)拒絕該筆網(wǎng)銀單筆退回請求。d) 支付寶系統(tǒng)臨時凍結(jié)客戶支付寶賬戶內(nèi)與單筆退回金額等量的資金，并登記退貨申請。e) 支付寶向客戶顯示網(wǎng)銀充值退回申請已經(jīng)被接受，等待支付寶處理。第二階段：批量處理階段f) 支付寶對退貨交易金額進行解凍扣款g) 支付寶將退貨交易單筆指令，構(gòu)造退貨報文并發(fā)送請求h) 銀行處理完成后進行實時返回a) 如為失敗需返回具體的失敗原因i) 支付寶根據(jù)返回進行后續(xù)邏輯處理3.5.4 交互模式在退貨業(yè)務中，銀行與支付寶通過同步交互模式進行交互。在交易查詢流程第8步、第9步、第11步和第12步交互中，支付寶構(gòu)造請求報文并主動向銀行系統(tǒng)發(fā)起退貨請求，銀行系統(tǒng)接收退貨報文，處理退貨結(jié)束后，構(gòu)造結(jié)果報文并返回支付寶系統(tǒng)。 3.5.5 業(yè)務要素“退貨業(yè)務”請求要素：退貨報文是支付寶向銀行發(fā)起的通知退貨指令請求。要素名稱英文縮寫要素要求退貨流水號SerialNumberl 必須要素，同支付時的流水號要求清算日期TransDatel 必須要素，格式為：yyyyMMdd手續(xù)費Chargel 非必須要素交易金額Amountl 必須要素，單位是分。幣種Currencyl 非必須要素，如果沒有該要素，則默認為人民幣。原交易流水號OriginalSerialNumberl 必須要素，對應原支付流水號原交易日期OriginalTransDatel 必須要素，對應原支付日期,格式為：yyyyMMdd商戶編號MerchantNumberl 必須要素，用來定位密鑰，以及流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。數(shù)字簽名Signaturel 必須要素，必須使用非對稱加密算法生成l 待簽名要素必須覆蓋所有接口中需要傳遞的要素l 若查詢時采用的雙向加密認證的通信通道則可以不使用數(shù)字簽名“退貨業(yè)務”應答要素： 要素名稱英文縮寫要素要求退貨流水號SerialNumberl 必須要素，同支付時的流水號要求清算日期TransDatel 必須要素，格式為：yyyyMMdd手續(xù)費Chargel 非必須要素交易金額Amountl 必須要素，單位是分。幣種Currencyl 非必須要素，如果沒有該要素，則默認為人民幣。原交易流水號OriginalSerialNumberl 必須要素，對應原支付流水號原交易日期OriginalTransDatel 必須要素，對應原支付日期,格式為：yyyyMMdd處理狀態(tài)Statusl 必須要素，Y成功，N失敗失敗原因Reasonl 非必須要素，如果處理狀態(tài)為失敗，則描述失敗原因商戶編號MerchantNumberl 必須要素，用來定位密鑰，以及流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。數(shù)字簽名Signaturel 必須要素，必須使用非對稱加密算法生成l 待簽名要素必須覆蓋所有接口中需要傳遞的要素l 若查詢時采用的雙向加密認證的通信通道則可以不使用數(shù)字簽名3.6 清算業(yè)務 清算業(yè)務是指支付寶系統(tǒng)與銀行系統(tǒng)勾對交易明細和資金結(jié)算操作。3.6.1 業(yè)務功能從支付寶發(fā)起的網(wǎng)上支付交易的執(zhí)行結(jié)果，以銀行返回給支付寶的交易應答為準。當發(fā)生網(wǎng)絡丟失報文或系統(tǒng)故障時，銀行返回給支付寶的交易應答有可能丟失，造成客戶簽約銀行卡賬戶中的資金變動與支付寶賬戶中的資金變動不一致。除了交易應答丟失產(chǎn)生清算不一致的情況下，還可能因為其它原因（比如系統(tǒng)中的缺陷，或者人為因素）產(chǎn)生清算不一致。清算對賬業(yè)務的目的是發(fā)現(xiàn)用戶簽約銀行卡賬戶與支付寶賬戶中的資金變動不一致的情況，并確定原因與處理辦法。清算對賬業(yè)務一般一天進行一次，由銀行在T日終核對完成之后主動向支付寶提供T日0:00-24:00所有涉及到資金變動的交易的明細數(shù)據(jù)，與支付寶T日的交易數(shù)據(jù)進行比對，找出不一致的交易記錄。對于由于銀行交易應答丟失造成的支付寶不一致的交易記錄，由支付寶進行恢復處理。對于由于其它原因產(chǎn)生清算不一致的情況，根據(jù)支付寶收到的銀行交易應答內(nèi)容確定資金處理差錯的一方，并由該方進行賬務調(diào)整處理。如果由銀行方的資金處理差錯造成清算差錯，則按照支付寶清算標準中規(guī)定的差錯處理方法進行清算差錯處理。3.6.2 業(yè)務規(guī)則清算對賬業(yè)務在執(zhí)行中需要滿足以下約束條件：n 銀行提供的T日0:00-24:00變化的網(wǎng)銀交易明細數(shù)據(jù)需要與銀行的賬務處理一致。n 銀行需要在T+1日上午5:00點之前主動向支付寶提供T日網(wǎng)銀交易明細數(shù)據(jù)文件。n T日交易凈額需要與銀行清算給支付寶的T日款項凈額相同。n 僅提供終結(jié)狀態(tài)為成功的交易明細n 當清算對賬完成后，并完成差錯處理之后，雙方直至T日的所有網(wǎng)銀交易引起的資金變動必須一致。n 清算方式請詳見附件支付寶網(wǎng)銀之結(jié)算標準；3.6.3 處理流程清算對賬處理流程：1. 銀行在T日日終時，將T日0:00-24:00已經(jīng)與銀行賬務系統(tǒng)核對正確的網(wǎng)銀支付與退貨（包括單筆與批量）的網(wǎng)銀交易記錄生成清算對賬文件并保存。不同交易性質(zhì)的網(wǎng)銀交易保存在同一個清算對賬文件中，按照交易性質(zhì)排序與交易時間排序。2. 銀行按照事先約定的上傳URL與文件名格式向支付寶上傳清算對賬文件。如果上傳文件失敗，銀行應當有恰當?shù)闹卦嚥呗浴Ｈ缬鑫募蟼鳟惓；驗榭諘r，銀行可通知支付寶刪除原文件，銀行再次進行上傳。3. 銀行以清算對賬日期、時間與文件名等信息構(gòu)造“清算對賬”通知報文，告知支付寶清算對賬文件已上傳。如果發(fā)送失敗，銀行應該有恰當?shù)闹卦嚥呗浴?. 支付寶收到“清算對賬”通知報文后，從銀行提供的清算對賬文件中解析出每一條網(wǎng)銀交易記錄，與自己在該對賬日期的所有網(wǎng)銀交易記錄進行逐筆核對。找出并生成以下三類交易記錄的清單。n A：銀行有，但支付寶沒有的交易記錄n B：支付寶有，但銀行沒有的交易記錄n C：雙方都有，但內(nèi)容不一致的交易記錄支付寶對不一致的網(wǎng)銀交易記錄進行恢復與處理。對于A類交易記錄，支付寶進行交易恢復，使支付寶對該筆交易的資金處理與銀行一致。對于B類交易記錄與C類交易記錄，支付寶人工介入處理，通過核對原始的銀行應答指令，找出原因并確定該由哪方進行訂正。如果存在需要銀行進行調(diào)整的交易記錄，則支付寶線下提供給銀行的需要調(diào)整的交易記錄清單，以及原始的銀行應答指令，由銀行在人工核實之后進行處理。3.6.4 交互模式在清算對賬業(yè)務中，銀行與支付寶通過文件上傳模式交互。在清算對賬處理流程的第2、3步，銀行作為文件提供者向支付寶上傳文件，并發(fā)送 “清算對賬”通知報文。3.6.5 業(yè)務要素T日日終后，由銀行生成T日資金對賬文件，并將文件上傳到支付寶網(wǎng)銀對賬文件服務器。文件頭數(shù)據(jù)要素：要素名稱英文縮寫要素要求總筆數(shù)TotalNumberl 必須要素，總筆數(shù)總金額TotalAmountl 必須要素，總金額，在接口文檔中要詳細說明該要素單位，是元還是分，還是千分位格式。成功總筆數(shù)SuccessNumberl 必須要素，成功總筆數(shù)成功總金額SuccessAmountl 必須要素，成功總金額，在接口文檔中要詳細說明該要素單位，是元還是分，還是千分位格式。清算日期SettleDatel 必須要素，格式為：yyyyMMddl 若銀行每天提供一個對賬文件則文件內(nèi)所有明細使用同一個SettleDatel 若銀行好幾天的數(shù)據(jù)匯總到一個文件中則該要素可以不填，要注明該要素會在明細中體現(xiàn)。文件明細數(shù)據(jù)要素：要素名稱英文縮寫要素要求清算流水號SerialNumberl 必須要素，同支付時的流水號要求清算金額RealAmountl 必須要素，銀行實際清算成功金額，在接口文檔中要詳細說明該要素單位，是元還是分，還是千分位格式。清算日期SettleDatel 必須要素，格式為：yyyyMMddl 銀行清算日期。做充退時用來定位其實際日期。清算狀態(tài)SettleStatusl Y 成功；N 失敗，必須要素，默認出現(xiàn)的即為成功的交易l 對賬文件中的數(shù)據(jù)狀態(tài)一定要是穩(wěn)定狀態(tài)。不允許出現(xiàn)處理中的狀態(tài)。失敗原因O如果處理狀態(tài)為失敗，則描述失敗的原因。交易金額R見金額格式說明交易貨幣代碼O默認為人民幣清算業(yè)務類型SettleType必須要素，0提現(xiàn); 1支付; 2退貨幣種Currencyl 非必須要素，默認為人民幣原流水號O退貨文件中原流水號原交易日期O退貨文件中原交易日期(YYYYMMDD)3.6.6 文件