支付寶網(wǎng)銀業(yè)務(wù)管理與管理知識規(guī)范標(biāo)準(zhǔn)

1、WORD25/25支付寶網(wǎng)銀接入業(yè)務(wù)規(guī)范副標(biāo)題：網(wǎng)銀接入標(biāo)準(zhǔn)版本0.3修訂歷史版本號作者內(nèi)容提要核準(zhǔn)人發(fā)布日期1.0.1葛喬初稿2010-2-261.0.2王增賢初稿2010-2-281.0.3葛喬增加明細(xì)查詢業(yè)務(wù)完善余額查詢條件完善結(jié)算標(biāo)準(zhǔn)2010-3-9目 錄 TOC o 1-3 h z u HYPERLINK l _Toc2552263721文檔概述 PAGEREF _Toc255226372 h 4HYPERLINK l _Toc2552263731.1目標(biāo)讀者 PAGEREF _Toc255226373 h 4HYPERLINK l _Toc2552263741.2版本規(guī)范 PAGE

2、REF _Toc255226374 h 4HYPERLINK l _Toc2552263752交互模式 PAGEREF _Toc255226375 h 4HYPERLINK l _Toc2552263762.1同步交互模式 PAGEREF _Toc255226376 h 4HYPERLINK l _Toc2552263772.2異步交互模式 PAGEREF _Toc255226377 h 5HYPERLINK l _Toc2552263782.3文件上傳模式 PAGEREF _Toc255226378 h 6HYPERLINK l _Toc2552263793網(wǎng)銀業(yè)務(wù) PAGEREF _Toc

3、255226379 h 7HYPERLINK l _Toc2552263803.1支付業(yè)務(wù) PAGEREF _Toc255226380 h 7HYPERLINK l _Toc2552263813.1.1業(yè)務(wù)功能 PAGEREF _Toc255226381 h 8HYPERLINK l _Toc2552263823.1.2業(yè)務(wù)規(guī)則 PAGEREF _Toc255226382 h 8HYPERLINK l _Toc2552263833.1.3處理流程 PAGEREF _Toc255226383 h 9HYPERLINK l _Toc2552263843.1.4交互模式 PAGEREF _Toc25

4、5226384 h 10HYPERLINK l _Toc2552263853.1.5業(yè)務(wù)要素 PAGEREF _Toc255226385 h 11HYPERLINK l _Toc2552263863.2交易查詢 PAGEREF _Toc255226386 h 12HYPERLINK l _Toc2552263873.2.1業(yè)務(wù)功能 PAGEREF _Toc255226387 h 12HYPERLINK l _Toc2552263883.2.2業(yè)務(wù)規(guī)則 PAGEREF _Toc255226388 h 12HYPERLINK l _Toc2552263893.2.3處理流程 PAGEREF _To

5、c255226389 h 13HYPERLINK l _Toc2552263903.2.4交互模式 PAGEREF _Toc255226390 h 13HYPERLINK l _Toc2552263913.2.5業(yè)務(wù)要素 PAGEREF _Toc255226391 h 14HYPERLINK l _Toc2552263923.3余額查詢 PAGEREF _Toc255226392 h 15HYPERLINK l _Toc2552263933.3.1業(yè)務(wù)功能 PAGEREF _Toc255226393 h 15HYPERLINK l _Toc2552263943.3.2業(yè)務(wù)規(guī)則 PAGEREF

6、_Toc255226394 h 15HYPERLINK l _Toc2552263953.3.3處理流程 PAGEREF _Toc255226395 h 16HYPERLINK l _Toc2552263963.3.4交互模式 PAGEREF _Toc255226396 h 16HYPERLINK l _Toc2552263973.3.5業(yè)務(wù)要素 PAGEREF _Toc255226397 h 17HYPERLINK l _Toc2552263983.4退貨業(yè)務(wù) PAGEREF _Toc255226398 h 18HYPERLINK l _Toc2552263993.4.1業(yè)務(wù)功能 PAGER

7、EF _Toc255226399 h 18HYPERLINK l _Toc2552264003.4.2業(yè)務(wù)規(guī)則 PAGEREF _Toc255226400 h 18HYPERLINK l _Toc2552264013.4.3處理流程 PAGEREF _Toc255226401 h 19HYPERLINK l _Toc2552264023.4.4交互模式 PAGEREF _Toc255226402 h 20HYPERLINK l _Toc2552264033.4.5業(yè)務(wù)要素 PAGEREF _Toc255226403 h 21HYPERLINK l _Toc2552264043.5清算業(yè)務(wù) PA

8、GEREF _Toc255226404 h 22HYPERLINK l _Toc2552264053.5.1業(yè)務(wù)功能 PAGEREF _Toc255226405 h 22HYPERLINK l _Toc2552264063.5.2業(yè)務(wù)規(guī)則 PAGEREF _Toc255226406 h 23HYPERLINK l _Toc2552264073.5.3處理流程 PAGEREF _Toc255226407 h 24HYPERLINK l _Toc2552264083.5.4交互模式 PAGEREF _Toc255226408 h 25HYPERLINK l _Toc2552264093.5.5業(yè)務(wù)

9、要素 PAGEREF _Toc255226409 h 26HYPERLINK l _Toc2552264103.5.6文件格式 PAGEREF _Toc255226410 h 27HYPERLINK l _Toc2552264114安全規(guī)范 PAGEREF _Toc255226411 h 27HYPERLINK l _Toc2552264124.1安全配置 PAGEREF _Toc255226412 h 27HYPERLINK l _Toc2552264134.1.1算法選擇 PAGEREF _Toc255226413 h 27HYPERLINK l _Toc2552264144.1.2切換配

10、置 PAGEREF _Toc255226414 h 28HYPERLINK l _Toc2552264154.2數(shù)字簽名 PAGEREF _Toc255226415 h 28HYPERLINK l _Toc2552264164.2.1簽名數(shù)據(jù) PAGEREF _Toc255226416 h 28HYPERLINK l _Toc2552264174.2.2簽名算法 PAGEREF _Toc255226417 h 29HYPERLINK l _Toc2552264184.3數(shù)據(jù)加密 PAGEREF _Toc255226418 h 29HYPERLINK l _Toc2552264194.3.1加密

11、內(nèi)容 PAGEREF _Toc255226419 h 29HYPERLINK l _Toc2552264204.3.2加密算法 PAGEREF _Toc255226420 h 29HYPERLINK l _Toc2552264215附錄 PAGEREF _Toc255226421 h 30HYPERLINK l _Toc2552264225.1結(jié)算標(biāo)準(zhǔn) PAGEREF _Toc255226422 h 30HYPERLINK l _Toc2552264235.2業(yè)務(wù)FAQ PAGEREF _Toc255226423 h 301文檔概述本文檔主要描述支付寶與銀行之間的網(wǎng)銀接入業(yè)務(wù)規(guī)范業(yè)務(wù)內(nèi)容、交互

12、模式，安全配置等內(nèi)容。目標(biāo)讀者本文的主要目標(biāo)讀者是支付寶網(wǎng)銀接入業(yè)務(wù)銀行方的業(yè)務(wù)規(guī)劃人員，其中的部分內(nèi)容也可供銀行的管理與技術(shù)人員參考。版本規(guī)范支付寶網(wǎng)銀接入業(yè)務(wù)規(guī)范的版本規(guī)范是：.。本文介紹支付寶網(wǎng)銀接入業(yè)務(wù)規(guī)范的1.0.3版。交互模式支付寶網(wǎng)銀接入業(yè)務(wù)規(guī)范交互模式，根據(jù)不同業(yè)務(wù)需求包括：同步交互模式，異步交互模式，文件上傳模式三種交互模式。同步交互模式 同步交互模式，也叫請求-應(yīng)答模式。在請求-應(yīng)答模式下，一方作為服務(wù)提供者，另一方作為服務(wù)使用者。由服務(wù)使用者主動向服務(wù)提供者發(fā)起請求并等待應(yīng)答，服務(wù)提供者接受請求，完成處理，并向服務(wù)使用者應(yīng)答處理結(jié)果，服務(wù)使用者收到處理結(jié)果之后進(jìn)行后續(xù)處理

13、。請求-應(yīng)答模式適用于服務(wù)使用者需要根據(jù)服務(wù)提供者的服務(wù)應(yīng)答才能進(jìn)行正確的后續(xù)處理的場景，比如，在交易查詢業(yè)務(wù)中，支付寶作為服務(wù)使用者，銀行作為服務(wù)提供者，支付寶需要知道銀行的交易處理結(jié)果之后才能繼續(xù)交易流程。異步交互模式異步交互模式，一方作為服務(wù)提供者，另一方作為服務(wù)使用者。由服務(wù)使用者主動向服務(wù)提供者發(fā)起請求，服務(wù)提供者接受請求，完成處理(圖：服務(wù)請求)。返回應(yīng)答結(jié)果時，之前的服務(wù)提供者角色變?yōu)榉?wù)使用者，把處理的結(jié)果作為服務(wù)請求主動向之前的服務(wù)使用者發(fā)起請求，而之前的服務(wù)使用者角色變?yōu)榉?wù)提供者，提供接收應(yīng)答結(jié)果的服務(wù)(圖：服務(wù)應(yīng)答)。異步模式適用于服務(wù)提供者處理完服務(wù)請求后，需要主動通

14、知服務(wù)使用者處理結(jié)果的場景。比如，在網(wǎng)銀支付業(yè)務(wù)中，支付寶作為服務(wù)使用者，銀行作為服務(wù)提供者，支付寶請求數(shù)據(jù)會跳轉(zhuǎn)到銀行網(wǎng)銀頁面，用戶在網(wǎng)銀頁面支付成功后，銀行需要把處理結(jié)果主動通知給支付寶，支付寶作為接收結(jié)果的服務(wù)方再做后續(xù)處理。圖：服務(wù)請求 SKIPIF 1 0 圖：服務(wù)應(yīng)答 SKIPIF 1 0 文件上傳模式在文件上傳模式中，一方作為文件提供者，另一方作為文件使用者。文件提供者首先生成文件，然后將文件上傳給文件提供者。在文件上傳完成之后，文件提供者通知文件使用者，通知信息中包含文件的上傳位置與其它信息。文件使用者接到通知之后，根據(jù)文件內(nèi)容進(jìn)行后續(xù)的業(yè)務(wù)處理。文件上傳模式的特點是文件使用者

15、擁有文件服務(wù)系統(tǒng)。由于網(wǎng)銀接入規(guī)范中，文件服務(wù)系統(tǒng)是由支付寶統(tǒng)一提供的，因此，文件上傳模式適用于由銀行向支付寶發(fā)起的對帳業(yè)務(wù)處理請求，如清算對賬等。網(wǎng)銀業(yè)務(wù)支付寶網(wǎng)銀接入規(guī)范網(wǎng)銀業(yè)務(wù)支持業(yè)務(wù)包括：支付業(yè)務(wù)，交易查詢，余額查詢，內(nèi)部戶明細(xì)查詢，退貨業(yè)務(wù)和清算業(yè)務(wù)；以上各業(yè)務(wù)都為7*24小時運行，節(jié)假日同樣處理。下面對每個業(yè)務(wù)進(jìn)行詳細(xì)描述。支付業(yè)務(wù)支付業(yè)務(wù)主要實現(xiàn)互聯(lián)網(wǎng)交易中的買家，通過銀行網(wǎng)銀方式來給支付寶XX充值或進(jìn)行交易支付的業(yè)務(wù)。業(yè)務(wù)功能 互聯(lián)網(wǎng)用戶可以通過支付業(yè)務(wù)， 把用戶在銀行卡中的資金用于在支付寶網(wǎng)站上的交易支付和XX充值等業(yè)務(wù)。從而完成用戶在互聯(lián)網(wǎng)上的購物行為。業(yè)務(wù)規(guī)則支付業(yè)務(wù)從支

16、付寶發(fā)起支付寶清算流水號必須支付寶系統(tǒng)唯一支付業(yè)務(wù)金額不能超過銀行網(wǎng)銀產(chǎn)品限額銀行對同一清算流水號的重復(fù)支付請求，只做一次處理銀行對超過網(wǎng)銀用戶限額的支付業(yè)務(wù)請求，不能做成功處理處理流程 SKIPIF 1 0 支付業(yè)務(wù)流程：用戶在支付寶收銀臺選擇充值銀行支付寶按 支付要素 構(gòu)造報文提交銀行接口支付寶引導(dǎo)用戶到選擇的銀行網(wǎng)銀進(jìn)行充值操作用戶根據(jù)銀行網(wǎng)銀的要求進(jìn)行操作（如：輸入卡號、密碼進(jìn)行校驗；插入U盾等）銀行根據(jù)規(guī)則對用戶操作進(jìn)行驗證，并根據(jù) 支付返回要素 向支付寶返回驗證成功：銀行實時接口通知支付寶該筆交易成功銀行將該筆用戶充值資金進(jìn)行記錄，日終匯總一筆轉(zhuǎn)賬給支付寶在銀行開設(shè)的賬戶或內(nèi)部戶銀

17、行引導(dǎo)用戶跳轉(zhuǎn)到支付寶成功頁面驗證失?。涸摴P充值操作結(jié)束，銀行告知用戶失敗原因交互模式在支付業(yè)務(wù)中，銀行與支付寶通過異步交互模式進(jìn)行交互。在支付流程第2步和第3步中，支付寶構(gòu)造請求要素并且主動向銀行網(wǎng)銀交易請求。 SKIPIF 1 0 在支付流程第6步和第7步中，銀行網(wǎng)銀處理結(jié)束應(yīng)答結(jié)果時主動向支付寶發(fā)起請求。 SKIPIF 1 0 業(yè)務(wù)要素“支付業(yè)務(wù)”請求要素：要素名稱英文縮寫要素要求金額Amount 必須要素，單位是分。幣種Currency 非必須要素，如果沒有該要素，則默認(rèn)為人民幣?？愋蚦ardtype 必須要素，銀行按支付寶發(fā)送的借、貸、其他標(biāo)示控制用戶所支付能支持的卡類型清算流水號

18、SerialNumber 必須要素，由支付寶生成，銀行進(jìn)行保存，其長度至少大于20位字符，支持?jǐn)?shù)字和字符。 該字段在銀行系統(tǒng)的唯一性，當(dāng)天不重復(fù) 在銀行系統(tǒng)不可重復(fù)的范圍內(nèi)，如果有重復(fù)的流水號提交到銀行，一定不能允許其支付。 這里的流水號唯一性指的是一樣商戶標(biāo)號下的流水號唯一性。清算日期SettleTime 非必須要素，格式為：yyyyMMddHHmmss。 該要素用來進(jìn)行流水號重復(fù)性控制，以與釣魚的防范，比如：銀行系統(tǒng)時間在SettleTime-30分鐘SettleTime+30分鐘以內(nèi)有效，超過該范圍的訂單不能進(jìn)行支付。 該要素可用來做資金對賬用。商戶編號MerchantNumber 必須

19、要素，銀行端用來定位密鑰以與清算流水號。數(shù)字簽名Signature 必須要素，必須使用非對稱加密算法生成 待簽名要素必須覆蓋所有接口中需要傳遞的要素支付結(jié)果回執(zhí)地址ReturnUrl 銀行可以通過服務(wù)器通知，或者頁面跳轉(zhuǎn)來通知。支付寶建議使用通知服務(wù)器來通知，增加可靠性。“支付業(yè)務(wù)”應(yīng)答要素：要素名稱英文縮寫要素要求金額Amount 必須要素，單位是分。幣種Currency 非必須要素，如果沒有該要素，則默認(rèn)為人民幣?？愋蚦ardtype 必須要素，銀行按支付寶發(fā)送的借、貸、其他標(biāo)示控制用戶所支付能支持的卡類型清算流水號SerialNumber 必須要素，由支付寶生成，銀行進(jìn)行保存，其長度至

20、少大于20位字符，支持?jǐn)?shù)字和字符。 該字段在銀行系統(tǒng)的唯一性，當(dāng)天不重復(fù) 在銀行系統(tǒng)不可重復(fù)的范圍內(nèi)，如果有重復(fù)的流水號提交到銀行，一定不能允許其支付。 這里的流水號唯一性指的是一樣商戶標(biāo)號下的流水號唯一性。清算日期SettleTime 非必須要素，格式為：yyyyMMddHHmmss。 該要素用來進(jìn)行流水號重復(fù)性控制，以與釣魚的防范，比如：銀行系統(tǒng)時間在SettleTime-30分鐘SettleTime+30分鐘以內(nèi)有效，超過該范圍的訂單不能進(jìn)行支付。 該要素可用來做資金對賬用。清算狀態(tài)SettleStatus 該要素必須有明確的結(jié)果返回。商戶編號MerchantNumber 必須要素，銀行

21、端用來定位密鑰以與清算流水號。數(shù)字簽名Signature 必須要素，必須使用非對稱加密算法生成 待簽名要素必須覆蓋所有接口中需要傳遞的要素支付結(jié)果回執(zhí)地址ReturnUrl 銀行可以通過服務(wù)器通知，或者頁面跳轉(zhuǎn)來通知。支付寶建議使用通知服務(wù)器來通知，增加可靠性。交易查詢交易查詢業(yè)務(wù)是支付寶系統(tǒng)向銀行系統(tǒng)查詢某筆交易在銀行系統(tǒng)中處理最終結(jié)果的業(yè)務(wù)。目的是確認(rèn)某筆交易的最終處理狀態(tài)。業(yè)務(wù)功能對于支付寶發(fā)送銀行的支付、退貨請求，因網(wǎng)絡(luò)、系統(tǒng)等原因造成掉單的交易，為了提升用戶使用體驗，減少用戶對資金的擔(dān)憂與咨詢，需在最短的時間內(nèi)進(jìn)行恢復(fù)。此時支付寶需要向銀行查詢原請求在銀行端的狀態(tài)或結(jié)果，銀行需將最終

22、結(jié)果返回給支付寶。業(yè)務(wù)規(guī)則交易查詢業(yè)務(wù)僅支持單查詢 查詢交易結(jié)果為銀行最終處理結(jié)果 處理流程 SKIPIF 1 0 交易查詢流程：支付寶按交易查詢要素構(gòu)造查詢報文向銀行發(fā)起查詢請求銀行系統(tǒng)接收查詢請求，解析報文內(nèi)容銀行系統(tǒng)查詢系統(tǒng)內(nèi)對應(yīng)交易號狀態(tài)，并且構(gòu)造結(jié)果應(yīng)答報文返回支付寶系統(tǒng)接收銀行查詢結(jié)果應(yīng)答報文支付寶系統(tǒng)處理查詢應(yīng)答結(jié)果交互模式在交易查詢業(yè)務(wù)中，銀行與支付寶通過同步交互模式進(jìn)行交互。在交易查詢流程第1步、第2步、第3步和第4步交互中，支付寶構(gòu)造請求要素并且主動向銀行系統(tǒng)發(fā)起查詢請求，銀行系統(tǒng)接收報文，處理查詢請求后，構(gòu)造結(jié)果報文并返回支付寶系統(tǒng)。 SKIPIF 1 0 業(yè)務(wù)要素“交易

23、查詢”請求要素：要素名稱英文縮寫要素要求清算流水號SerialNumber 必須要素，同支付時的流水號要求清算日期TransDate 必須要素，格式為：yyyyMMdd 銀行要用該要素來進(jìn)行流水號重復(fù)性控制，即銀行要查詢TransDate那天的流水號。商戶編號MerchantNumber 必須要素，用來定位密鑰，以與流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。類型Type支付退貨數(shù)字簽名Signature 必須要素，必須使用非對稱加密算法生成 待簽名要素必須覆蓋所有接口中需要傳遞的要素 若查詢時采用的雙向加密認(rèn)證的通信通道則可以不使用數(shù)字簽名“交易查詢”應(yīng)答要素：要素名稱英文縮寫

24、要素要求清算流水號SerialNumber 必須要素，同支付時的流水號要求清算金額RealAmount 必須要素，銀行實際清算成功金額，在接口文檔中要詳細(xì)說明該要素單位，是元還是分，還是千分位格式。清算日期SettleDate 必須要素，格式為：yyyyMMdd 銀行清算日期。做充退時用來定位其實際日期。商戶編號MerchantNumber 必須要素，用來定位密鑰，以與流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。清算狀態(tài)SettleStatus 必須要素，完整的狀態(tài)必須包括成功，失敗，處理中，查無記錄。 若銀行系統(tǒng)與其核心系統(tǒng)之間狀態(tài)無法確定，有兩種選擇1、可以告知清算狀態(tài)為處理

25、中，2、告訴失敗，銀行自行沖正這筆交易，要確保該交易不會再變成成功。數(shù)字簽名Signature 必須要素，必須使用非對稱加密算法生成 待簽名要素必須覆蓋所有接口中需要傳遞的要素 若查詢時采用的雙向加密認(rèn)證的通信通道則可以不使用數(shù)字簽名明細(xì)查詢（共用卡通提現(xiàn)的明細(xì)查詢接口）明細(xì)查詢主要指，支付寶為向銀行發(fā)起的查詢銀行內(nèi)部戶賬務(wù)變化明細(xì)的業(yè)務(wù)。目的是獲了支付寶在銀行內(nèi)部戶的賬務(wù)明細(xì)。業(yè)務(wù)功能因支付寶不在異地城商行開戶，未能登錄城商行網(wǎng)銀，故需查詢內(nèi)部戶賬務(wù)明細(xì)用于對賬。查詢回的明細(xì)要記錄與更新。業(yè)務(wù)規(guī)則明細(xì)查詢業(yè)務(wù)需支持按時間段查詢（如：2010-3-1 2010-3-3）明細(xì)查詢結(jié)果中的XX明細(xì)

26、為該時間段支付寶內(nèi)部戶的交易明細(xì)處理流程 SKIPIF 1 0 明細(xì)查詢流程：支付寶系統(tǒng)按明細(xì)查詢要素構(gòu)造明細(xì)查詢報文向銀行發(fā)起查詢請求銀行系統(tǒng)接收請求報文，校驗數(shù)據(jù)是否有效銀行系統(tǒng)查詢支付寶在銀行內(nèi)部戶該時間段賬務(wù)明細(xì)，并構(gòu)造結(jié)果報文返回支付寶系統(tǒng)接收銀行明細(xì)查詢結(jié)果應(yīng)答報文支付寶系統(tǒng)記錄銀行內(nèi)部戶該時間段明細(xì)交互模式在明細(xì)查詢業(yè)務(wù)中，銀行與支付寶通過同步交互模式進(jìn)行交互。在交易查詢流程第1步、第2步、第3步和第4步交互中，支付寶構(gòu)造請求要素并且主動向銀行系統(tǒng)發(fā)起查詢請求，銀行系統(tǒng)接收報文，處理查詢請求后，構(gòu)造結(jié)果報文并返回支付寶系統(tǒng)。 SKIPIF 1 0 業(yè)務(wù)要素“明細(xì)查詢”請求要素：要

27、素名稱英文縮寫要素要求開始日期StartDate 必須要素，用來確定查詢的開始日期結(jié)束日期EndDate 必須要素，用來確定查詢的結(jié)束日期商戶編號MerchantNumber 必須要素，用來定位密鑰，以與流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。數(shù)字簽名Signature 必須要素，必須使用非對稱加密算法生成 待簽名要素必須覆蓋所有接口中需要傳遞的要素 若查詢時采用的雙向加密認(rèn)證的通信通道則可以不使用數(shù)字簽名“明細(xì)查詢”應(yīng)答要素：明細(xì)數(shù)據(jù)要素：要素名稱英文縮寫要素要求交易日TransDate 必須要素，賬戶明細(xì)變化時的日期金額RealAmount 必須要素，銀行實際清算成功金額

28、，在接口文檔中要詳細(xì)說明該要素單位，是元還是分，還是千分位格式。借貸Debit Credit 必須要素，按借、貸進(jìn)行區(qū)分顯示余額Balance 必須要素，用來返回賬戶明細(xì)發(fā)生變化后的余額摘要Memo 必須要素，對該筆款項的注釋，比如：往來款、清算款、B2C充值、B2C退貨、卡通充值、卡通提現(xiàn)、卡通退貨商戶編號MerchantNumber必須要素，用來定位密鑰，以與流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。數(shù)字簽名Signature必須要素，必須使用非對稱加密算法生成余額查詢（共用卡通的余額查詢接口）余額查詢業(yè)務(wù)是支付寶為向銀行發(fā)起的查詢銀行內(nèi)部戶頭寸的業(yè)務(wù)。目的是獲了支付寶在銀

29、行內(nèi)部戶的余額。業(yè)務(wù)功能因支付寶不在異地城商行開戶，只能開設(shè)內(nèi)部戶，需實時查詢內(nèi)部戶余額，此余額是隨業(yè)務(wù)增長而變化的。同時因結(jié)算需要，還需查詢每日支付寶內(nèi)部戶余額，此余額是日切后支付寶內(nèi)部戶余額，該余額日切后不可變化。查詢回的最新余額要分別記錄與更新。業(yè)務(wù)規(guī)則余額查詢業(yè)務(wù)僅支持單查詢余額查詢結(jié)果中的XX余額為支付寶可用余額處理流程 SKIPIF 1 0 余額查詢流程：支付寶系統(tǒng)按余額查詢要素構(gòu)造余額查詢報文向銀行發(fā)起查詢請求銀行系統(tǒng)接收請求報文，校驗數(shù)據(jù)是否有效銀行系統(tǒng)查詢支付寶在銀行內(nèi)部戶余額，并構(gòu)造結(jié)果報文返回支付寶系統(tǒng)接收銀行余額查詢結(jié)果應(yīng)答報文支付寶系統(tǒng)更新余額交互模式在余額查詢業(yè)務(wù)中

30、，銀行與支付寶通過同步交互模式進(jìn)行交互。在交易查詢流程第1步、第2步、第3步和第4步交互中，支付寶構(gòu)造請求要素并且主動向銀行系統(tǒng)發(fā)起查詢請求，銀行系統(tǒng)接收報文，處理查詢請求后，構(gòu)造結(jié)果報文并返回支付寶系統(tǒng)。 SKIPIF 1 0 業(yè)務(wù)要素“余額查詢”請求要素：要素名稱英文縮寫要素要求日期Date 必須要素，用來定位查詢?nèi)掌陬愋蚑ype 必須要素，N表示當(dāng)前余額，該余額是變化的；H表示該日最終余額，該余額是不可變化的商戶編號MerchantNumber 必須要素，用來定位密鑰，以與流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。數(shù)字簽名Signature 必須要素，必須使用非對稱加密算

31、法生成 待簽名要素必須覆蓋所有接口中需要傳遞的要素 若查詢時采用的雙向加密認(rèn)證的通信通道則可以不使用數(shù)字簽名“余額查詢”應(yīng)答要素：要素名稱英文縮寫要素要求日期Date 必須要素，用來返回查詢?nèi)掌谫~戶余額Balance 必須要素，用來返回余額商戶編號MerchantNumber 必須要素，用來定位密鑰，以與流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。數(shù)字簽名Signature 必須要素，必須使用非對稱加密算法生成 待簽名要素必須覆蓋所有接口中需要傳遞的要素 若查詢時采用的雙向加密認(rèn)證的通信通道則可以不使用數(shù)字簽名退貨業(yè)務(wù)退貨業(yè)務(wù)是支付寶發(fā)起的把已經(jīng)支付成功并且結(jié)算成功的交易，按原路

32、退回到用戶銀行卡的業(yè)務(wù)。目的是把用戶支付業(yè)務(wù)的現(xiàn)金退回到用戶的銀行卡中。業(yè)務(wù)功能對于客戶的充值金額，為防止套現(xiàn)或借用支付寶渠道轉(zhuǎn)帳，支付寶控制客戶不能轉(zhuǎn)入其它銀行。為滿足客戶充值金額返回原充值銀行卡的需求，開發(fā)充值退回功能，即退貨業(yè)務(wù)。業(yè)務(wù)規(guī)則退貨業(yè)務(wù)從支付寶發(fā)起。單筆退貨業(yè)務(wù)必須有對應(yīng)的支付寶支付業(yè)務(wù)交易單筆退貨的金額不能超過對應(yīng)的支付交易的金額，但可以少于支付時的金額可支持多次退款，但退款總金額應(yīng)少于支付時該筆交易的金額單筆退貨的資金只能原路劃回支付業(yè)務(wù)使用的銀行卡賬戶中客戶單筆退回時收到的資金只能從支付寶公司事先約定的清算賬戶中劃撥同一退回訂單號的單筆退貨交易銀行必須保證只能執(zhí)行一次在未

33、獲取到銀行對該筆沖退有明確結(jié)果前，不得再發(fā)起對該筆交易的第2筆沖退操作如果由于支付寶系統(tǒng)原因再次發(fā)起沖退，銀行應(yīng)明確做失敗處理銀行與支付寶需要保存單筆退回相關(guān)報文的日志，作為解決資金清算不一致的憑據(jù)支持1年內(nèi)的交易退貨請求處理流程 SKIPIF 1 0 退貨業(yè)務(wù)流程：第一階段：客戶申請階段客戶對充值金額申請普通提現(xiàn)。提現(xiàn)失敗，錯誤提示頁面出現(xiàn)充值退回頁面鏈接入口。支付寶系統(tǒng)對退回交易的合法性進(jìn)行驗證。驗證內(nèi)容包括：客戶的銀行退貨服務(wù)狀態(tài)是否為激活單筆退回的交易是使用網(wǎng)銀充值的如果上述驗證中有一項不符合，則支付寶系統(tǒng)拒絕該筆網(wǎng)銀單筆退回請求。支付寶系統(tǒng)臨時凍結(jié)客戶支付寶賬戶內(nèi)與單筆退回金額等量的

34、資金，并登記退貨申請。支付寶向客戶顯示網(wǎng)銀充值退回申請已經(jīng)被接受，等待支付寶處理。第二階段：批量處理階段支付寶對退貨交易金額進(jìn)行解凍扣款支付寶將退貨交易單筆指令，構(gòu)造退貨報文并發(fā)送請求銀行處理完成后進(jìn)行實時返回如為失敗需返回具體的失敗原因支付寶根據(jù)返回進(jìn)行后續(xù)邏輯處理交互模式在退貨業(yè)務(wù)中，銀行與支付寶通過同步交互模式進(jìn)行交互。在交易查詢流程第8步、第9步、第11步和第12步交互中，支付寶構(gòu)造請求報文并主動向銀行系統(tǒng)發(fā)起退貨請求，銀行系統(tǒng)接收退貨報文，處理退貨結(jié)束后，構(gòu)造結(jié)果報文并返回支付寶系統(tǒng)。 SKIPIF 1 0 業(yè)務(wù)要素“退貨業(yè)務(wù)”請求要素：退貨報文是支付寶向銀行發(fā)起的通知退貨指令請求。

35、要素名稱英文縮寫要素要求退貨流水號SerialNumber 必須要素，同支付時的流水號要求清算日期TransDate 必須要素，格式為：yyyyMMdd手續(xù)費Charge 非必須要素交易金額Amount 必須要素，單位是分。幣種Currency 非必須要素，如果沒有該要素，則默認(rèn)為人民幣。原交易流水號OriginalSerialNumber 必須要素，對應(yīng)原支付流水號原交易日期OriginalTransDate 必須要素，對應(yīng)原支付日期,格式為：yyyyMMdd商戶編號MerchantNumber 必須要素，用來定位密鑰，以與流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。數(shù)字簽名S

36、ignature 必須要素，必須使用非對稱加密算法生成 待簽名要素必須覆蓋所有接口中需要傳遞的要素 若查詢時采用的雙向加密認(rèn)證的通信通道則可以不使用數(shù)字簽名“退貨業(yè)務(wù)”應(yīng)答要素：要素名稱英文縮寫要素要求退貨流水號SerialNumber 必須要素，同支付時的流水號要求清算日期TransDate 必須要素，格式為：yyyyMMdd手續(xù)費Charge 非必須要素交易金額Amount 必須要素，單位是分。幣種Currency 非必須要素，如果沒有該要素，則默認(rèn)為人民幣。原交易流水號OriginalSerialNumber 必須要素，對應(yīng)原支付流水號原交易日期OriginalTransDate 必須要

37、素，對應(yīng)原支付日期,格式為：yyyyMMdd處理狀態(tài)Status 必須要素，Y成功，N失敗失敗原因Reason 非必須要素，如果處理狀態(tài)為失敗，則描述失敗原因商戶編號MerchantNumber 必須要素，用來定位密鑰，以與流水范圍，查詢出來的結(jié)果一定要是在這個商戶編號下面發(fā)生的。數(shù)字簽名Signature 必須要素，必須使用非對稱加密算法生成 待簽名要素必須覆蓋所有接口中需要傳遞的要素 若查詢時采用的雙向加密認(rèn)證的通信通道則可以不使用數(shù)字簽名清算業(yè)務(wù) 清算業(yè)務(wù)是指支付寶系統(tǒng)與銀行系統(tǒng)勾對交易明細(xì)和資金結(jié)算操作。業(yè)務(wù)功能從支付寶發(fā)起的網(wǎng)上支付交易的執(zhí)行結(jié)果，以銀行返回給支付寶的交易應(yīng)答為準(zhǔn)。當(dāng)

38、發(fā)生網(wǎng)絡(luò)丟失報文或系統(tǒng)故障時，銀行返回給支付寶的交易應(yīng)答有可能丟失，造成客戶簽約銀行卡賬戶中的資金變動與支付寶賬戶中的資金變動不一致。除了交易應(yīng)答丟失產(chǎn)生清算不一致的情況下，還可能因為其它原因（比如系統(tǒng)中的缺陷，或者人為因素）產(chǎn)生清算不一致。清算對賬業(yè)務(wù)的目的是發(fā)現(xiàn)用戶簽約銀行卡賬戶與支付寶賬戶中的資金變動不一致的情況，并確定原因與處理辦法。清算對賬業(yè)務(wù)一般一天進(jìn)行一次，由銀行在T日終核對完成之后主動向支付寶提供T日0:00-24:00所有涉與到資金變動的交易的明細(xì)數(shù)據(jù)，與支付寶T日的交易數(shù)據(jù)進(jìn)行比對，找出不一致的交易記錄。對于由于銀行交易應(yīng)答丟失造成的支付寶不一致的交易記錄，由支付寶進(jìn)行恢復(fù)

39、處理。對于由于其它原因產(chǎn)生清算不一致的情況，根據(jù)支付寶收到的銀行交易應(yīng)答內(nèi)容確定資金處理差錯的一方，并由該方進(jìn)行賬務(wù)調(diào)整處理。如果由銀行方的資金處理差錯造成清算差錯，則按照支付寶清算標(biāo)準(zhǔn)中規(guī)定的差錯處理方法進(jìn)行清算差錯處理。業(yè)務(wù)規(guī)則清算對賬業(yè)務(wù)在執(zhí)行中需要滿足以下約束條件：銀行提供的T日0:00-24:00變化的網(wǎng)銀交易明細(xì)數(shù)據(jù)需要與銀行的賬務(wù)處理一致。銀行需要在T+1日上午5:00點之前主動向支付寶提供T日網(wǎng)銀交易明細(xì)數(shù)據(jù)文件。T日交易凈額需要與銀行清算給支付寶的T日款項凈額一樣。僅提供終結(jié)狀態(tài)為成功的交易明細(xì)當(dāng)清算對賬完成后，并完成差錯處理之后，雙方直至T日的所有網(wǎng)銀交易引起的資金變動必須

40、一致。清算方式請詳見附件支付寶網(wǎng)銀之結(jié)算標(biāo)準(zhǔn)；處理流程 SKIPIF 1 0 清算對賬處理流程：銀行在T日日終時，將T日0:00-24:00已經(jīng)與銀行賬務(wù)系統(tǒng)核對正確的網(wǎng)銀支付與退貨（包括單筆與批量）的網(wǎng)銀交易記錄生成清算對賬文件并保存。不同交易性質(zhì)的網(wǎng)銀交易保存在同一個清算對賬文件中，按照交易性質(zhì)排序與交易時間排序。銀行按照事先約定的上傳URL與文件名格式向支付寶上傳清算對賬文件。如果上傳文件失敗，銀行應(yīng)當(dāng)有恰當(dāng)?shù)闹卦嚥呗浴Ｈ缬鑫募蟼鳟惓；驗榭諘r，銀行可通知支付寶刪除原文件，銀行再次進(jìn)行上傳。銀行以清算對賬日期、時間與文件名等信息構(gòu)造“清算對賬”通知報文，告知支付寶清算對賬文件已上傳。如果

41、發(fā)送失敗，銀行應(yīng)該有恰當(dāng)?shù)闹卦嚥呗?。支付寶收到“清算對賬”通知報文后，從銀行提供的清算對賬文件中解析出每一條網(wǎng)銀交易記錄，與自己在該對賬日期的所有網(wǎng)銀交易記錄進(jìn)行逐筆核對。找出并生成以下三類交易記錄的清單。A：銀行有，但支付寶沒有的交易記錄B：支付寶有，但銀行沒有的交易記錄C：雙方都有，但內(nèi)容不一致的交易記錄支付寶對不一致的網(wǎng)銀交易記錄進(jìn)行恢復(fù)與處理。對于A類交易記錄，支付寶進(jìn)行交易恢復(fù)，使支付寶對該筆交易的資金處理與銀行一致。對于B類交易記錄與C類交易記錄，支付寶人工介入處理，通過核對原始的銀行應(yīng)答指令，找出原因并確定該由哪方進(jìn)行訂正。如果存在需要銀行進(jìn)行調(diào)整的交易記錄，則支付寶線下提供給銀

42、行的需要調(diào)整的交易記錄清單，以與原始的銀行應(yīng)答指令，由銀行在人工核實之后進(jìn)行處理。交互模式在清算對賬業(yè)務(wù)中，銀行與支付寶通過文件上傳模式交互。在清算對賬處理流程的第2、3步，銀行作為文件提供者向支付寶上傳文件，并發(fā)送 “清算對賬”通知報文。 SKIPIF 1 0 業(yè)務(wù)要素T日日終后，由銀行生成T日資金對賬文件，并將文件上傳到支付寶網(wǎng)銀對賬文件服務(wù)器。文件頭數(shù)據(jù)要素：要素名稱英文縮寫要素要求總筆數(shù)TotalNumber 必須要素，總筆數(shù)總金額TotalAmount 必須要素，總金額，在接口文檔中要詳細(xì)說明該要素單位，是元還是分，還是千分位格式。成功總筆數(shù)SuccessNumber 必須要素，成功總筆數(shù)成功總金額SuccessAmount 必須要素，成功總金額，在接口文檔中要詳細(xì)說明該要素單位，是元還是分，還是千分位格式。清算日期SettleDate 必須要素，格式為：yyyyMMdd 若銀行每天提供一個對賬文件則文件內(nèi)所有明細(xì)使用同一個SettleDate 若銀行好幾天的數(shù)據(jù)匯總到一個文件中則該要素可以不填，要注明該要素會在明細(xì)中體現(xiàn)。文件明細(xì)數(shù)據(jù)要素：要素名稱英文縮寫要素要求清算流水號SerialNumber 必須要素，同支付時的流水號要求清算金額RealAmount 必須要素，銀行實際清算成功金額，在接口文檔中要詳細(xì)說明該要素單位，是元還是分，還是千分位格式