京東網(wǎng)銀在線快捷支付接口說明-銀行

1、.：.； PAGE 40快捷支付技術(shù)規(guī)范V1.0版前言本文檔引見快捷支付的技術(shù)規(guī)范，其中包括快捷支付的業(yè)務(wù)模型、平安責(zé)任模型、架構(gòu)模型、業(yè)務(wù)處置與系統(tǒng)交互方式、報(bào)文的語法與語義、網(wǎng)絡(luò)銜接方式、平安規(guī)范等。參與快捷支付業(yè)務(wù)的各方必需遵守快捷支付技術(shù)規(guī)范，以實(shí)現(xiàn)準(zhǔn)確、平安、方便的網(wǎng)上支付與相關(guān)業(yè)務(wù)。目錄 TOC o 1-3 h z u HYPERLINK l _Toc357775966 前言 PAGEREF _Toc357775966 h 2 HYPERLINK l _Toc357775967 第1章文檔概述 PAGEREF _Toc357775967 h 5 HYPERLINK l _Toc35

2、7775968 1.1引見 PAGEREF _Toc357775968 h 5 HYPERLINK l _Toc357775969 1.2參考規(guī)范與文獻(xiàn) PAGEREF _Toc357775969 h 6 HYPERLINK l _Toc357775970 第2章快捷支付業(yè)務(wù)概述 PAGEREF _Toc357775970 h 6 HYPERLINK l _Toc357775971 2.1快捷支付業(yè)務(wù)模型 PAGEREF _Toc357775971 h 6 HYPERLINK l _Toc357775972 2.2快捷支付平安責(zé)任模型 PAGEREF _Toc357775972 h 8 HYP

3、ERLINK l _Toc357775973 第3章快捷支付架構(gòu) PAGEREF _Toc357775973 h 9 HYPERLINK l _Toc357775974 3.1快捷支付架構(gòu)目的 PAGEREF _Toc357775974 h 9 HYPERLINK l _Toc357775975 3.2快捷支付架構(gòu)模型 PAGEREF _Toc357775975 h 10 HYPERLINK l _Toc357775976 3.3快捷支付交互方式 PAGEREF _Toc357775976 h 14 HYPERLINK l _Toc357775977 第4章快捷支付報(bào)文構(gòu)造 PAGEREF _

4、Toc357775977 h 15 HYPERLINK l _Toc357775978 4.1報(bào)文構(gòu)造 PAGEREF _Toc357775978 h 15 HYPERLINK l _Toc357775979 懇求/呼應(yīng)頭信息 PAGEREF _Toc357775979 h 16 HYPERLINK l _Toc357775980 懇求頭信息 PAGEREF _Toc357775980 h 16 HYPERLINK l _Toc357775981 呼應(yīng)頭信息 PAGEREF _Toc357775981 h 16 HYPERLINK l _Toc357775982 4.2報(bào)文的解析與傳輸 PAG

5、EREF _Toc357775982 h 19 HYPERLINK l _Toc357775983 第5章快捷支付業(yè)務(wù)虛現(xiàn)規(guī)范 PAGEREF _Toc357775983 h 20 HYPERLINK l _Toc357775984 5.1接口實(shí)現(xiàn)闡明 PAGEREF _Toc357775984 h 21 HYPERLINK l _Toc357775985 5.2網(wǎng)上簽約 PAGEREF _Toc357775985 h 21 HYPERLINK l _Toc357775986 5.3網(wǎng)上支付 PAGEREF _Toc357775986 h 22 HYPERLINK l _Toc35777598

6、7 5.4單筆撤銷 PAGEREF _Toc357775987 h 25 HYPERLINK l _Toc357775988 5.5單筆退款 PAGEREF _Toc357775988 h 25 HYPERLINK l _Toc357775989 5.6單筆/批量買賣查詢 PAGEREF _Toc357775989 h 29 HYPERLINK l _Toc357775990 5.7清算對賬 PAGEREF _Toc357775990 h 32 HYPERLINK l _Toc357775991 第6章網(wǎng)絡(luò)銜接規(guī)范 PAGEREF _Toc357775991 h 35 HYPERLINK l

7、_Toc357775992 第7章平安規(guī)范 PAGEREF _Toc357775992 h 35 HYPERLINK l _Toc357775993 7.1平安要挾 PAGEREF _Toc357775993 h 35 HYPERLINK l _Toc357775994 7.2數(shù)字簽名 PAGEREF _Toc357775994 h 36 HYPERLINK l _Toc357775995 7.3報(bào)文日志管理 PAGEREF _Toc357775995 h 36 HYPERLINK l _Toc357775996 第8章其它規(guī)范 PAGEREF _Toc357775996 h 37 HYPER

8、LINK l _Toc357775997 8.1異常處置規(guī)范 PAGEREF _Toc357775997 h 37 HYPERLINK l _Toc357775998 8.2錯(cuò)誤碼規(guī)范 PAGEREF _Toc357775998 h 37 HYPERLINK l _Toc357775999 8.3處置呼應(yīng)時(shí)間要求 PAGEREF _Toc357775999 h 37 HYPERLINK l _Toc357776000 8.4可用性要求 PAGEREF _Toc357776000 h 37 HYPERLINK l _Toc357776001 第9章附錄 PAGEREF _Toc357776001

9、 h 37 HYPERLINK l _Toc357776002 9.1快捷支付報(bào)文樣例 PAGEREF _Toc357776002 h 37 HYPERLINK l _Toc357776003 9.2快捷支付金額格式 PAGEREF _Toc357776003 h 37 HYPERLINK l _Toc357776004 9.3快捷支付貨幣代碼表 PAGEREF _Toc357776004 h 38 HYPERLINK l _Toc357776005 9.4數(shù)據(jù)字典定義 PAGEREF _Toc357776005 h 39文檔概述引見快捷支付概述在互聯(lián)網(wǎng)支付體系中，持卡人身份驗(yàn)證與資金清算是兩

10、個(gè)關(guān)鍵問題。在傳統(tǒng)處理方案中，對持卡人的身份驗(yàn)證普通是由持卡人在發(fā)卡行提供的身份驗(yàn)證效力器比如發(fā)卡行的網(wǎng)上銀行直接進(jìn)展，并將身份驗(yàn)證的結(jié)果通知商戶。資金清算能夠是在身份驗(yàn)證經(jīng)過之后實(shí)時(shí)進(jìn)展清算，也能夠是經(jīng)過公用的資金清算網(wǎng)絡(luò)單獨(dú)進(jìn)展。這種傳統(tǒng)處理方案要求發(fā)卡行提供基于互聯(lián)網(wǎng)的持卡人身份驗(yàn)證效力，并且要求商戶在持卡人在進(jìn)展互聯(lián)網(wǎng)支付時(shí)，將持卡人引導(dǎo)至發(fā)卡行進(jìn)展身份驗(yàn)證。隨著互聯(lián)網(wǎng)支付的普及，這種方式逐漸顯現(xiàn)出一些問題。其中最突出的問題是持卡人需求訪問多個(gè)互聯(lián)網(wǎng)效力站點(diǎn)才干完成一次完好的支付過程。在多個(gè)互聯(lián)網(wǎng)效力站點(diǎn)之間跳轉(zhuǎn)運(yùn)用戶的買賣與支付體驗(yàn)不夠流暢。在這個(gè)過程由于網(wǎng)絡(luò)傳輸、客戶端處置中任何一

11、個(gè)失敗都會(huì)呵斥支付過程失敗。隨著互聯(lián)網(wǎng)支付的開展，第三方支付平臺曾經(jīng)成為互聯(lián)網(wǎng)支付體系中的重要組成部分。越來越多的商戶不是直接經(jīng)過銀行，而是經(jīng)過第三方支付平臺實(shí)現(xiàn)基于互聯(lián)網(wǎng)支付，利用第三方支付平臺提供的快速便利的支付清算效力，降低接入復(fù)雜度、控制互聯(lián)網(wǎng)支付的本錢、提高用戶的支付體驗(yàn)?；诳旖葜Ц兜馁~戶平安體系，當(dāng)持卡人在進(jìn)展互聯(lián)網(wǎng)支付時(shí)，持卡人可以經(jīng)過快捷支付賬戶平安體系進(jìn)展身份驗(yàn)證，并在身份驗(yàn)證經(jīng)過時(shí)，委托快捷支付代他向銀行發(fā)出支付指令，實(shí)現(xiàn)運(yùn)用該持卡人委托范圍內(nèi)的銀行資金的劃撥，完成一次完好的互聯(lián)網(wǎng)支付。運(yùn)用這種方式，在持卡人進(jìn)展互聯(lián)網(wǎng)不需求訪問多個(gè)互聯(lián)網(wǎng)效力站點(diǎn)，防止輸入銀行卡號與密碼，

12、可以提升用戶的互聯(lián)網(wǎng)支付體驗(yàn)，添加支付勝利率，減少用戶銀行卡號與密碼被盜的風(fēng)險(xiǎn)。與此同時(shí)，基于這種信任與委托關(guān)系，在快捷支付與銀行之間可以協(xié)作為持卡人與快捷支付用戶提供更多的增值效力，比如商戶貨款的實(shí)時(shí)提現(xiàn)效力等。本文檔論述的快捷支付技術(shù)規(guī)范，為更加快捷平安的互聯(lián)網(wǎng)支付結(jié)算提供了完全處理方案。目的讀者本文的主要目的讀者是快捷支付規(guī)范銀行方的技術(shù)實(shí)施人員，其中的部分內(nèi)容也可供銀行的管理與業(yè)務(wù)人員參考。版本規(guī)范快捷支付規(guī)范的版本規(guī)范是：.。本文引見快捷支付技術(shù)規(guī)范的1.0.0版。最近修訂版本號作者內(nèi)容提要核準(zhǔn)人發(fā)布日期1.0.0 xxp初次版本2021-05-27參考規(guī)范與文獻(xiàn)快捷支付業(yè)務(wù)概述本章

13、引見快捷支付的業(yè)務(wù)模型，描畫快捷支付業(yè)務(wù)的主要業(yè)務(wù)目的，引見各個(gè)參與方的功能與責(zé)任，并論述作為快捷支付平安性根底的平安責(zé)任模型?？旖葜Ц稑I(yè)務(wù)模型業(yè)務(wù)模型快捷支付的業(yè)務(wù)目的是充分結(jié)合快捷支付在互聯(lián)網(wǎng)買賣效力與市場占用率方面的專長，與銀行在資金管理與結(jié)算效力上的專長，雙方優(yōu)勢互補(bǔ)，為快捷支付與銀行的共同用戶其中包括互聯(lián)網(wǎng)買家與商戶提供整合、快捷、平安的互聯(lián)網(wǎng)支付與結(jié)算處理方案?？旖葜Ц吨饕峁┰诨ヂ?lián)網(wǎng)上進(jìn)展支付時(shí)持卡人作為買家委托快捷支付運(yùn)用他在銀行卡賬戶中的資金進(jìn)展網(wǎng)上支付業(yè)務(wù)功能。在網(wǎng)上支付時(shí)，資金從買家銀行卡賬戶流入快捷支付的客戶保證金賬戶中.用戶域用戶域中包括了快捷支付業(yè)務(wù)的主要效力對象，

14、其中包括互聯(lián)網(wǎng)買賣中的買家與商戶。買家運(yùn)用快捷支付業(yè)務(wù)進(jìn)展買賣貨款支付，商戶運(yùn)用快捷支付業(yè)務(wù)進(jìn)展買賣貨款結(jié)算。無論是買家還是商戶，假設(shè)需求運(yùn)用快捷支付業(yè)務(wù)，必需至少擁有一個(gè)快捷支付賬戶與一張銀行卡，并且快捷支付賬戶與銀行卡的姓名與身份證件需求一致。買賣控制域買賣控制域直接為用戶域提供互聯(lián)網(wǎng)買賣效力以及與之相關(guān)的資金效力，其中包括買賣支付時(shí)的買家身份驗(yàn)證與授權(quán)、為商戶提供貨款結(jié)算效力、監(jiān)視完好的買賣履約過程、為買賣各方提供溝通與交互平臺等。在快捷支付業(yè)務(wù)模型中，買賣控制域的主體是快捷支付。中心業(yè)務(wù)為了運(yùn)用快捷支付與銀行結(jié)合提供的快捷支付效力，用戶首先需求與快捷支付和銀行簽定協(xié)議，明確各方的權(quán)益與

15、義務(wù)，這一過程稱為“快捷支付簽約；“快捷支付簽約所構(gòu)成的數(shù)據(jù)記錄稱為“快捷支付簽約記錄；簽約勝利后，快捷支付與銀行交互過程中用于識別用戶身份及銀行卡信息的編號稱為“快捷支付協(xié)議號。在簽約勝利后，用戶就可以運(yùn)用快捷支付進(jìn)展方便、平安的網(wǎng)上支付與提現(xiàn)。為了保證快捷支付業(yè)務(wù)處置的準(zhǔn)確性，快捷支付規(guī)范中也規(guī)定了各種管理類業(yè)務(wù)，如批量查詢、單筆買賣查詢、清算對賬、簽約對賬等。 貸記卡快捷支付與借記卡快捷支付快捷支付業(yè)務(wù)不僅支持借記卡支付業(yè)務(wù)，同時(shí)也支持信譽(yù)卡支付業(yè)務(wù)，由于借記卡快捷支付與信譽(yù)卡快捷支付業(yè)務(wù)沒有本質(zhì)性的差別，本文將借記卡快捷支付業(yè)務(wù)與信譽(yù)卡快捷支付業(yè)務(wù)整合到一同進(jìn)展引見，沒有特別闡明，所引

16、見的業(yè)務(wù)不區(qū)分借記卡與信譽(yù)卡。下面是信譽(yù)卡快捷支付與借記卡快捷支付的區(qū)別如下表：借記卡快捷支付貸記卡快捷支付能否區(qū)分大小額否是能否收費(fèi)否大額收費(fèi)，小額不收費(fèi)快捷支付平安責(zé)任模型平安目的快捷支付支付業(yè)務(wù)的主要平安目的是，只需經(jīng)本人用戶委托與授權(quán)，才可以動(dòng)用該用戶開通快捷支付業(yè)務(wù)的銀行卡賬戶內(nèi)的資金，并且用于用戶指定的支付目的。這一平安目的是經(jīng)過用戶、快捷支付與銀行三方共同履行責(zé)任來保證的。引入快捷支付平安責(zé)任模型，目的在于明確規(guī)定各方在保證平安目的時(shí)的責(zé)任?？旖葜Ц镀桨藏?zé)任模型為了實(shí)現(xiàn)平安支付這一目的，用戶、快捷支付與銀行各自應(yīng)該履行的責(zé)任 。用戶：只需本人同時(shí)擁有賬戶號與支付密碼。 向快捷支付

17、發(fā)起的支付懇求代表本人的真實(shí)意圖?？旖葜Ц叮褐恍栌脩舭l(fā)起買賣支付懇求，并且賬戶與支付密碼驗(yàn)證經(jīng)過，才干發(fā)起支付指令。 只需收到英航的賬務(wù)處置的勝利結(jié)果，才執(zhí)行用戶懇求的買賣支付。銀行：只需來之快捷支付的支付指定才干觸發(fā)快捷業(yè)務(wù)的賬務(wù)處置。 給快捷支付的支付反響真實(shí)反響賬務(wù)處置結(jié)果 快捷效力與額度在用戶授權(quán)范圍內(nèi)。從上可知只需快捷支付支付業(yè)務(wù)的參與者都恰當(dāng)?shù)芈男辛吮救说呢?zé)任，即可確保實(shí)現(xiàn)快捷支付支付的平安目的。當(dāng)用戶運(yùn)用快捷支付時(shí)，信任快捷支付履行責(zé)任只需用戶發(fā)起買賣支付懇求，并且賬戶與支付密碼驗(yàn)證經(jīng)過，才干發(fā)起快捷支付支付指令。這一信任關(guān)系與快捷支付現(xiàn)有的用戶協(xié)議是相容的。責(zé)任認(rèn)定方式當(dāng)出現(xiàn)快

18、捷支付平安目的被違背的情況時(shí)，為了認(rèn)定責(zé)任，快捷支付與銀行必需分別舉證本人履行了責(zé)任。假設(shè)兩方中有一方無法舉證本人履行了平安責(zé)任模型中規(guī)定的責(zé)任，那么由于本次平安目的違背事件引發(fā)的損失由未能舉證的一方承當(dāng)。假設(shè)快捷支付與銀行都可以舉證本人履行了責(zé)任，那么闡明用戶未履行本人的平安責(zé)任，損失由用戶承當(dāng)。由于平安責(zé)任模型中信任關(guān)系的存在，因此快捷支付無須舉證本人履行了責(zé)任只需用戶發(fā)起買賣支付懇求，并且賬戶與支付密碼驗(yàn)證經(jīng)過，才干發(fā)起快捷支付支付指令。快捷支付技術(shù)規(guī)范將支持銀行與快捷支付舉證本人履行了責(zé)任?？旖葜Ц都軜?gòu)本章引見快捷支付的技術(shù)架構(gòu)。描畫組成快捷支付系統(tǒng)的各個(gè)組件以及它們之間的協(xié)作方式?？?/p>

19、捷支付架構(gòu)目的業(yè)務(wù)目的快捷支付架構(gòu)的目的是在快捷支付業(yè)務(wù)模型的框架下，實(shí)現(xiàn)快捷支付業(yè)務(wù)的目的、約束與流程，對快捷支付平安與責(zé)任模型提供支持。技術(shù)目的除了實(shí)現(xiàn)業(yè)務(wù)目的，快捷支付架構(gòu)也需求達(dá)成一些技術(shù)上的目的。其中最重要的技術(shù)目的是開放、簡單、平安。開放快捷支付規(guī)范需求實(shí)現(xiàn)快捷支付與各個(gè)銀行系統(tǒng)的互聯(lián)，為了方便快捷支付與銀行之間的異構(gòu)平臺與系統(tǒng)的互聯(lián)，快捷支付架構(gòu)必需基于開放平臺與規(guī)范，方便跨平臺、跨地域的接入。簡單快捷支付作為一種創(chuàng)新的、以簡單、平安、快捷為中心思念的在線支付規(guī)范，在運(yùn)用的方便性和接入的簡單性方面，要求超越傳統(tǒng)的互聯(lián)網(wǎng)支付處理方案。平安由于快捷支付規(guī)范簡化了支付流程，并且由快捷支

20、付系統(tǒng)而不是發(fā)卡行完成用戶身份的驗(yàn)證，因此必需規(guī)定嚴(yán)厲的平安責(zé)任模型，并且經(jīng)過恰當(dāng)?shù)募夹g(shù)規(guī)范和方法來實(shí)現(xiàn)該責(zé)任模型?？旖葜Ц都軜?gòu)模型架構(gòu)模型由于不同銀行在系統(tǒng)架構(gòu)上存在差別，本文中以典型的銀行系統(tǒng)為例，引見快捷支付的架構(gòu)模型。在快捷支付系統(tǒng)的詳細(xì)實(shí)施與接入中，可以視需求對該架構(gòu)模型進(jìn)展修正，添加、刪除、分拆或者合并系統(tǒng)中包含的組件。圖3-1 快捷支付架構(gòu)模型圖中顯示了實(shí)現(xiàn)快捷支付業(yè)務(wù)涉及到的系統(tǒng)組件。這些系統(tǒng)組件有些需求全新引入如銀行快捷支付渠道和銀行快捷支付業(yè)務(wù)系統(tǒng)，有些需求在原有系統(tǒng)之上擴(kuò)展如銀行柜面渠道，有些可以直接運(yùn)用現(xiàn)有的系統(tǒng)如銀行賬務(wù)與卡業(yè)務(wù)系統(tǒng)。架構(gòu)組件快捷支付技術(shù)架構(gòu)中涉及到的

21、系統(tǒng)組件與它們的主要職責(zé)如下：銀行快捷支付接入系統(tǒng)銀行快捷支付渠道與快捷支付渠道之間經(jīng)過平安的信道互聯(lián)，擔(dān)任與快捷支付之間平安地交換快捷支付協(xié)議報(bào)文，驗(yàn)證報(bào)文的真實(shí)性與合法性，維護(hù)快捷支付報(bào)文日志，并在快捷支付協(xié)議報(bào)文與銀行快捷支付業(yè)務(wù)系統(tǒng)所可以了解的買賣指令之間進(jìn)展翻譯銀行快捷支付接入系統(tǒng)可以獨(dú)立搭建，也可以在現(xiàn)有渠道平臺上擴(kuò)展。銀行柜臺銀行柜面渠道是銀行柜員的任務(wù)平臺，擔(dān)任接受銀行柜員提交的快捷支付簽約懇求，并且提供柜員與快捷支付相關(guān)的資金對賬與清算、客戶效力等功能。銀行柜面渠道不直接處置快捷支付業(yè)務(wù)的中心邏輯，相關(guān)處置均翻譯成銀行快捷支付業(yè)務(wù)系統(tǒng)所可以了解的買賣指令，交給銀行快捷支付業(yè)務(wù)

22、系統(tǒng)進(jìn)展處置。普通情況下，可以經(jīng)過對現(xiàn)有銀行柜面渠道系統(tǒng)進(jìn)展功能擴(kuò)展來支持快捷支付業(yè)務(wù)。銀行快捷支付業(yè)務(wù)系統(tǒng)銀行快捷支付業(yè)務(wù)系統(tǒng)是快捷支付業(yè)務(wù)在銀行端處置的主要系統(tǒng)，擔(dān)任接受銀行快捷支付渠道或者銀行柜面渠道的懇求、控制快捷支付業(yè)務(wù)流程、管理快捷支付業(yè)務(wù)數(shù)據(jù)、驗(yàn)證快捷支付效力授權(quán)與額度等業(yè)務(wù)規(guī)那么、構(gòu)造對銀行賬務(wù)與卡業(yè)務(wù)系統(tǒng)的買賣懇求、處置銀行賬務(wù)與卡業(yè)務(wù)系統(tǒng)的前往結(jié)果、并將結(jié)果前往給銀行快捷支付渠道或銀行柜面渠道等銀行快捷支付業(yè)務(wù)系統(tǒng)可以獨(dú)立搭建，也可以在現(xiàn)有中間業(yè)務(wù)平臺上擴(kuò)展。銀行賬務(wù)與卡業(yè)務(wù)系統(tǒng)銀行賬務(wù)與卡業(yè)務(wù)系統(tǒng)作為銀行的中心系統(tǒng)，為快捷支付業(yè)務(wù)提供根底的客戶身份驗(yàn)證、卡片密碼驗(yàn)證、資金

23、清算處置等功能。理想情況下，現(xiàn)有的銀行賬務(wù)與卡業(yè)務(wù)系統(tǒng)所提供的效力就可以支持快捷支付業(yè)務(wù)，不需求擴(kuò)展或者修正銀行賬務(wù)與卡業(yè)務(wù)系統(tǒng)。快捷支付前臺系統(tǒng)快捷支付前臺系統(tǒng)是快捷支付會(huì)員直接運(yùn)用快捷支付業(yè)務(wù)功能的入口，引導(dǎo)用戶進(jìn)展快捷支付協(xié)議簽約、激活，對于曾經(jīng)激活的快捷支付用戶，能直接運(yùn)用快捷支付進(jìn)展充值，提現(xiàn)，查詢銀行卡余額，修正快捷支付限額等功能。是快捷支付業(yè)務(wù)展現(xiàn)給用戶運(yùn)用的平臺?？旖葜Ц稑I(yè)務(wù)系統(tǒng)快捷支付業(yè)務(wù)系統(tǒng)目前主要擔(dān)任處置快捷支付協(xié)議及其他非清算類業(yè)務(wù)處置，擔(dān)任整個(gè)快捷支付簽約信息的管理。非清算類業(yè)務(wù)功能，包含：快捷支付cms信息管理，快捷支付限額查詢/修正，快捷支付余額查詢，快捷支付簽約

24、信息查詢等?？旖葜Ц吨Ц?清算系統(tǒng)快捷支付體系中，支付層擔(dān)任接納快捷支付清算類業(yè)務(wù)懇求，用戶在快捷支付前臺系統(tǒng)選擇快捷支付進(jìn)展充值，提現(xiàn)，充退等操作時(shí)，前臺系統(tǒng)將快捷支付懇求發(fā)送到支付層，有支付層擔(dān)任將懇求分類記錄并發(fā)送到清算層，并等待清算層回執(zhí)處置結(jié)果后，通知賬務(wù)系統(tǒng)完成用戶賬務(wù)操作。清算層是是快捷支付清算類業(yè)務(wù)處置的中心系統(tǒng)，收到支付層快捷支付業(yè)務(wù)懇求后，清算層記錄快捷支付懇求信息，并將懇求觸發(fā)到快捷支付前置系統(tǒng)，由快捷支付前置系統(tǒng)完成快捷支付報(bào)文與銀行端的交互，完成快捷支付懇求處置。同時(shí)，清算層還擔(dān)任觸發(fā)快捷支付相關(guān)的查詢業(yè)務(wù)，文件處置業(yè)務(wù)，業(yè)務(wù)對賬業(yè)務(wù)等。快捷支付賬務(wù)/會(huì)計(jì)/核算系統(tǒng)賬

25、務(wù)系統(tǒng)擔(dān)任快捷支付用戶虛擬賬戶管理，記錄用戶賬戶資金流動(dòng)情況。會(huì)計(jì)系統(tǒng)按照規(guī)范的會(huì)計(jì)規(guī)那么，用復(fù)式記賬的方式記錄用戶賬戶資金借貸關(guān)系記錄。核算系統(tǒng)主要擔(dān)任將銀行實(shí)踐的資金流動(dòng)與支付的資金流動(dòng)關(guān)系進(jìn)展核對?？旖葜Ц稌?huì)員/認(rèn)證系統(tǒng)會(huì)員系統(tǒng)記錄了快捷支付用戶根本的身份信息，在快捷支付業(yè)務(wù)中，會(huì)員系統(tǒng)主要用于獲取快捷支付業(yè)務(wù)處置時(shí)所需求的用戶信息。認(rèn)證系統(tǒng)主要擔(dān)任完成用戶身份信息的認(rèn)證任務(wù)，快捷支付協(xié)議激活時(shí)，由認(rèn)證系統(tǒng)自動(dòng)完成用戶實(shí)名認(rèn)證，所以，簽約快捷支付是最便利的實(shí)名認(rèn)證方式?？旖葜Ц段募到y(tǒng)快捷支付業(yè)務(wù)中，有很多地方與銀行的交互會(huì)運(yùn)用到文件系統(tǒng)，比如，銀行上傳簽約對賬文件，清算類業(yè)務(wù)/資金對賬

26、文件等。這些文件能夠是銀行自動(dòng)上傳到我方文件系統(tǒng)，也能夠是我方到銀行方系統(tǒng)下載后存到文件系統(tǒng)。快捷支付前置系統(tǒng)快捷支付前置系統(tǒng)是快捷支付中心業(yè)務(wù)系統(tǒng)與銀行快捷支付接入系統(tǒng)進(jìn)展交互的橋梁，主要擔(dān)任交互報(bào)文封裝，解析，簽名，驗(yàn)簽；并將報(bào)文信息轉(zhuǎn)換為內(nèi)部系統(tǒng)業(yè)務(wù)對象前往給業(yè)務(wù)系統(tǒng)完成快捷支付業(yè)務(wù)處置。快捷支付后臺管理系統(tǒng)快捷支付后臺管理系統(tǒng)主要運(yùn)用者是快捷支付結(jié)算，運(yùn)維，客服人員，后臺管理系統(tǒng)提供了一系列快捷支付業(yè)務(wù)相關(guān)的管理功能，經(jīng)過這些功能，支持快捷支付接入可配置化，同時(shí)也展現(xiàn)出用戶快捷支付運(yùn)用的相關(guān)信息，后臺管理功能主要包含：快捷支付渠道管理，快捷支付文件管理，快捷支付簽約信息管理，快捷支付C

27、MS信息管理等。快捷支付交互方式在快捷支付業(yè)務(wù)的技術(shù)實(shí)現(xiàn)中，快捷支付與銀行之間經(jīng)過交換報(bào)文與數(shù)據(jù)文件來交換業(yè)務(wù)信息、實(shí)現(xiàn)業(yè)務(wù)流程、控制業(yè)務(wù)規(guī)那么。實(shí)現(xiàn)快捷支付業(yè)務(wù)所需的交互方式可以歸納為懇求-應(yīng)對、單向通知這兩種方式，實(shí)踐業(yè)務(wù)中能夠會(huì)將各種交互方式結(jié)合起來運(yùn)用。下文將引見這兩種交互方式適用的場景與實(shí)現(xiàn)方式。懇求-應(yīng)對方式在懇求-應(yīng)對方式下，一方作為效力提供者，另一方作為效力運(yùn)用者。由效力運(yùn)用者自動(dòng)向效力提供者發(fā)起懇求并等待應(yīng)對，效力提供者接受懇求，完成處置，并向效力運(yùn)用者應(yīng)對處置結(jié)果，效力運(yùn)用者收四處置結(jié)果之后進(jìn)展后續(xù)處置。懇求-應(yīng)對方式適用于效力運(yùn)用者需求根據(jù)效力提供者的效力應(yīng)對才干進(jìn)展正確

28、的后續(xù)處置的場景，比如，在快捷支付網(wǎng)上支付業(yè)務(wù)中，快捷支付作為效力運(yùn)用者，銀行作為效力提供者，快捷支付需求知道銀行的支付處置結(jié)果之后才干繼續(xù)買賣流程。圖3-2 懇求-應(yīng)對方式單向通知方式在單向通知方式下，一方作為通知發(fā)送者，一方作為通知接納者。發(fā)送者發(fā)送通知，并保證接納者收到通知。通知接納者在收到通知之后，立刻前往發(fā)送者通知已收到。通知送達(dá)之后，發(fā)送方與接納方可以獨(dú)立地進(jìn)展后續(xù)業(yè)務(wù)處置。在快捷支付規(guī)范中，假設(shè)對方進(jìn)展業(yè)務(wù)處置所需的時(shí)間不可預(yù)知時(shí)，采用單向通知方式。圖3-3 單向通知方式快捷支付報(bào)文構(gòu)造快捷支付報(bào)文規(guī)范是快捷支付技術(shù)規(guī)范中重要的組成部分，規(guī)定了快捷支付與銀行之間交換報(bào)文的順序、格

29、式與語義與處置規(guī)范。本章中引見快捷支付報(bào)文的普通構(gòu)造與公共元素，這些規(guī)范適用于一切的快捷支付協(xié)議報(bào)文。詳細(xì)快捷支付業(yè)務(wù)中運(yùn)用的報(bào)文，在各個(gè)業(yè)務(wù)虛現(xiàn)規(guī)范中分別進(jìn)展論述。報(bào)文構(gòu)造快捷支付報(bào)文一致采用xml格式。一切的快捷支付報(bào)文均以QPAY作為根元素，每個(gè)QPAY元素中可以包含Head和Body元素。Head元素中包含代表進(jìn)展的業(yè)務(wù)的描畫屬性，比如Code、DateTime等。Body元素中包含代筆業(yè)務(wù)的詳細(xì)屬性。作為商定，業(yè)務(wù)元素屬性均是首字母大寫的CamelCase方式。標(biāo)志Tag闡明快捷支付報(bào)文塊開場報(bào)文頭開場 報(bào)文頭內(nèi)容報(bào)文頭終了報(bào)文體開場報(bào)文體內(nèi)容報(bào)文體終了快捷支付報(bào)文塊終了懇求/呼應(yīng)頭

30、信息懇求頭信息標(biāo)志Tag長度能否必輸闡明懇求頭信息開場5Y協(xié)議版本號20Y報(bào)文獨(dú)一標(biāo)識6Y買賣碼14Y買賣時(shí)間格式：yyyyMMDDHHmmss懇求頭信息終了呼應(yīng)頭信息標(biāo)志Tag長度能否必輸闡明呼應(yīng)頭信息開場5Y協(xié)議版本號20報(bào)文獨(dú)一標(biāo)識 以上送標(biāo)識為準(zhǔn)6Y買賣碼14Y買賣時(shí)間 格式：yyyyMMDDHHmmss 6Y呼應(yīng)碼 100呼應(yīng)信息描畫呼應(yīng)頭信息終了在下文中出現(xiàn)的詳細(xì)報(bào)文格式描畫中，“能否必輸列包含的值的含義如下表所示：符號含義懇求方約束效力方約束YRequired(必需的)必需包含該域必需校驗(yàn)該域能否存在和內(nèi)容的合法性CConditional(有條件的)假設(shè)條件符合必需包含該域當(dāng)條件

31、滿足時(shí)，必需校驗(yàn)該域能否存在當(dāng)該域存在時(shí)，必需檢查其內(nèi)容的合法性N或空白Optional(可選的)該域可選當(dāng)該域存在時(shí)，必需檢查其內(nèi)容的合法性錯(cuò)誤代碼闡明下表列舉了規(guī)范的錯(cuò)誤代碼：錯(cuò)誤代碼錯(cuò)誤描畫解釋報(bào)文類錯(cuò)誤0000無效的根元素根元素?zé)o法識別0001未定義的買賣碼音訊不是懇求和應(yīng)對等；或者音訊發(fā)送給了一個(gè)錯(cuò)誤的組件0002必填項(xiàng)缺失報(bào)文中“能否必輸為Y的參數(shù)缺失0003協(xié)議版本有誤版本號錯(cuò)誤0004根據(jù)規(guī)范，一個(gè)或多個(gè)域不符合格式要求例如，非數(shù)字，或者不是有效的日期格式等等。0005銀行標(biāo)識不正確域中的銀行標(biāo)識不正確0007簽名無效報(bào)文簽名校驗(yàn)不經(jīng)過0008加密密鑰不存在加密密鑰不存在000

32、9簽名密鑰不存在簽名密鑰不存在文件類錯(cuò)誤0301業(yè)務(wù)日期不正確業(yè)務(wù)日期格式不對，普通情況下業(yè)務(wù)日期必需是昨日，不過系統(tǒng)也支持以前日期的數(shù)據(jù)處置查詢類錯(cuò)誤0400支付流水反復(fù)反復(fù)的網(wǎng)上支付流水0401原支付流水不存在懇求退貨的原支付流水不存在0402查詢范圍太大查詢時(shí)間跨度太大0403查詢的買賣不存在查詢的買賣不存在用戶類錯(cuò)誤可以將錯(cuò)誤信息顯示給用戶1000協(xié)議號曾經(jīng)簽約勝利1001快捷支付協(xié)議號無效快捷支付協(xié)議號不對應(yīng)有效的快捷支付簽約記錄。1002快捷支付簽約形狀不正確快捷支付簽約形狀不允許執(zhí)行當(dāng)前的業(yè)務(wù)1200身份證曾經(jīng)被運(yùn)用身份證曾經(jīng)被其它用戶運(yùn)用，并簽約1201年齡不滿足如：用戶未滿1

33、8歲1202身份證格式不正確身份證不是有效的身份證1203真實(shí)姓名不正確真實(shí)姓名與快捷支付中的不一致1204證件類型不正確證件類型與快捷支付中的不一致1205身份證號碼不匹配身份證號碼與快捷支付中登記的身份證號碼不匹配1206認(rèn)證信息不匹配認(rèn)證信息與快捷支付經(jīng)過認(rèn)證的信息不匹配1207該銀行卡號曾經(jīng)勝利簽約該銀行卡號對應(yīng)的快捷支付賬號曾經(jīng)簽約勝利。1301快捷支付賬戶不存在快捷支付賬戶標(biāo)識不對應(yīng)有效的快捷支付賬戶。1302快捷支付賬戶形狀不正確快捷支付賬戶的形狀不允許簽約。1303快捷支付賬戶類型不正確快捷支付賬戶的類型不允許簽約。1304快捷支付賬戶曾經(jīng)懇求1305快捷支付賬號綁定的快捷支付

34、數(shù)量超限快捷支付賬號綁定的銀行卡曾經(jīng)超越最大數(shù)量。1306快捷支付賬號經(jīng)過的認(rèn)證數(shù)量超越最大值快捷支付賬號經(jīng)過的認(rèn)證數(shù)量超越最大值。1307登陸賬號無效, 快捷支付賬戶格式不對1311賬號無效。賬戶未開通快捷支付1800銀行卡戶名不存在戶名不存在1801銀行卡卡號不存在銀行卡號不存在1802戶名與銀行卡號不匹配戶名與銀行卡號不匹配1803銀行卡號與卡類型不匹配銀行卡號與卡類型不匹配1804不支持的銀行卡號不支持的銀行卡號1805不支持的證件類型不支持的證件類型1806證件號碼格式錯(cuò)誤證件號碼格式錯(cuò)誤1807與登記證件類型不匹配與登記證件類型不匹配1808與登記證件號碼不匹配與登記證件號碼不匹配

35、1809未登記手機(jī)號碼未登記手機(jī)號碼1810與登記的手機(jī)號碼不匹配與登記的手機(jī)號碼不匹配支付類錯(cuò)誤1401密碼校驗(yàn)次數(shù)超限密碼校驗(yàn)次數(shù)超限1402銀行卡形狀不正確銀行卡形狀不正確1403銀行賬戶形狀不允許該操作銀行賬戶形狀不允許該操作1404銀行支付校驗(yàn)碼輸入錯(cuò)誤銀行支付校驗(yàn)碼輸入錯(cuò)誤1405銀行支付校驗(yàn)碼失效支付校驗(yàn)碼超越輸入時(shí)間范圍限制，失效1406原支付懇求流水號曾經(jīng)支付支付流水號曾經(jīng)支付過1407原支付懇求流水不存在支付懇求流水不存在1408支付密碼輸入超限快捷支付支付密碼超越輸入次數(shù)限制1409支付異常，請查詢銀行卡能否已扣款無法獲得發(fā)卡中心的呼應(yīng)銀行卡類錯(cuò)誤1601金額超限支付金額

36、超越每日限額1602余額缺乏銀行賬戶中的余額缺乏以完成支付1604銀行買賣處置中該筆買賣在銀行前置系統(tǒng)中形狀未知1605銀行買賣失敗該筆買賣在銀行系統(tǒng)中曾經(jīng)失敗，且形狀不會(huì)再發(fā)生變卦。錯(cuò)誤詳細(xì)概略經(jīng)過ErrorDetail告知。1607銀行卡卡號不正確銀行卡卡號不正確信譽(yù)卡類錯(cuò)誤1701信譽(yù)卡凍結(jié)貸記卡已被凍結(jié)1702信譽(yù)卡掛失貸記卡已懇求掛失1703信譽(yù)卡不能進(jìn)展支付未領(lǐng)卡，未激活，止付，預(yù)銷戶1704信譽(yù)卡透支超限貸記卡透支超限管理類錯(cuò)誤2000快捷支付渠道封鎖沒有開通快捷支付業(yè)務(wù)2001效力沒有開通懇求的業(yè)務(wù)沒有開通系統(tǒng)類錯(cuò)誤9000暫時(shí)系統(tǒng)異常例如，一個(gè)懇求隊(duì)列滿了。9001永久系統(tǒng)異

37、常例如，無法訪問一個(gè)重要數(shù)據(jù)庫所在的磁盤。報(bào)文的解析與傳輸快捷支付報(bào)文的傳輸運(yùn)用XML Over (S)方式，在HTTP懇求/呼應(yīng)體中包含XML方式的報(bào)文。報(bào)文解析對XML解析的根本要求如下版本號檢查用于表示組件支持的協(xié)議版本號。音訊版本號必需表示為：n.n.n ，其中“n 表示數(shù)字。比如1.0或1.0.1。在一切的音訊中，各組件都必需填寫本身支持的協(xié)議版本號。音訊版本號不能低于1.0.0。假設(shè)音訊版本號低于接納方組件支持的最低版本號，那么接納方組件必需前往錯(cuò)誤音訊，并且設(shè)置錯(cuò)誤碼=0003。xml解析為了可以支持后續(xù)協(xié)議版本，xml解析的實(shí)現(xiàn)不要做嚴(yán)厲的驗(yàn)證。特別是需求忽略未被確認(rèn)的域。一切

38、xml音訊必需用“utf-8編碼。懇求和應(yīng)對域之id屬性匹配懇求和應(yīng)對報(bào)文的Head域之id屬性必需一樣，id是懇求方生成的獨(dú)一序列號。比如：銀行在懇求的Head域設(shè)置了一個(gè)id屬性值，那么快捷支付在應(yīng)對里面的Head域的id屬性必需和懇求的Head域之id值一樣。報(bào)文傳輸對HTTPS傳輸?shù)母疽笕缦拢哼\(yùn)用POST發(fā)送音訊音訊懇求基于HTTP/HTTPS的POST方式。HTTP音訊頭要求HTTP懇求與呼應(yīng)音訊中必需按照如下要求設(shè)置頭部域：Content-Length：必需設(shè)置成音訊體的長度Content-Type：必需設(shè)置下面的值：application/xml; charset=utf-8

39、快捷支付業(yè)務(wù)虛現(xiàn)規(guī)范快捷支付業(yè)務(wù)功能覆蓋了從簽約、效力與管理的各個(gè)方面。簽約類的業(yè)務(wù)擔(dān)任快捷支付效力協(xié)議的建立、調(diào)整與吊銷，其中包括柜臺簽約、網(wǎng)上簽約、柜臺簽約撤銷、網(wǎng)上撤約、批量簽約/撤約、支付限額查詢、網(wǎng)上支付限額修正。效力類的業(yè)務(wù)滿足用戶互聯(lián)網(wǎng)買賣與資金需求，其中包括網(wǎng)上支付、提現(xiàn)單筆與批量、退貨單筆與批量與銀行卡余額查詢。管理類業(yè)務(wù)是為了保證互聯(lián)網(wǎng)買賣的正常進(jìn)展而引入的，其中包含批量買賣查詢、單筆買賣查詢、簽約對賬與清算對賬、中間賬戶賬務(wù)明細(xì)查詢等。本章描畫如何經(jīng)過用戶、快捷支付與銀行之間的協(xié)作實(shí)現(xiàn)上述快捷支付業(yè)務(wù)的流程與規(guī)那么。同時(shí)，本章也規(guī)定了在銀行快捷支付渠道與快捷支付渠道間的交

40、互方式、交換的報(bào)文與文件的構(gòu)造、語義與處置規(guī)范。為了保證快捷支付業(yè)務(wù)的正常開展，還有一些在銀行或快捷支付內(nèi)部完成的業(yè)務(wù)流程，比如在銀行完成的支付限額修正，以及各種業(yè)務(wù)報(bào)表等，這些業(yè)務(wù)由于不涉及到快捷支付與銀行的交互，因此在本文檔中不作詳細(xì)描畫。接口實(shí)現(xiàn)闡明序號接口類型實(shí)現(xiàn)方式買賣類型代碼1網(wǎng)上簽約必做QP0012網(wǎng)上支付必做QP0053撤銷支付必做QP0064實(shí)時(shí)退款必做QP0075單筆/批量買賣查詢必做QP0086清算對帳必做QP009網(wǎng)上簽約簽約懇求相關(guān)參數(shù)懇求標(biāo)志Tag長度能否必輸闡明報(bào)文體開場1Y客戶類型10Y商戶編號22Y支付卡號1Y卡種，見數(shù)據(jù)字典定義！30Y戶名11N手機(jī)號碼，卡

41、種為信譽(yù)卡時(shí)必填2N證件類型30N證件號碼3NCvv2 ，卡種為信譽(yù)卡4N有效期，卡種為信譽(yù)卡時(shí)必填30預(yù)留100預(yù)留報(bào)文體終了呼應(yīng)標(biāo)志Tag長度闡明報(bào)文體開場1驗(yàn)證結(jié)果，見數(shù)據(jù)字典定義！30預(yù)留100預(yù)留報(bào)文體終了網(wǎng)上支付業(yè)務(wù)功能快捷支付網(wǎng)上支付業(yè)務(wù)的主要效力對象是互聯(lián)網(wǎng)買賣中的買家，使買家可以經(jīng)過快捷支付運(yùn)用簽約銀行卡內(nèi)的資金實(shí)現(xiàn)快捷、平安的買賣支付?？旖葜Ц稉?dān)任驗(yàn)證客戶持卡人身份與效力權(quán)限，并懇求銀行劃撥客戶的資金用于互聯(lián)網(wǎng)買賣的支付；銀行擔(dān)任驗(yàn)證由快捷支付發(fā)出的支付指令能否在快捷支付簽約的業(yè)務(wù)范圍與銀行控制的快捷支付支付限額內(nèi)，并實(shí)時(shí)扣減簽約銀行卡內(nèi)的余額。由于網(wǎng)上支付引起的銀行與快捷

42、支付間的資金清算方法由快捷支付清算規(guī)范規(guī)定。業(yè)務(wù)規(guī)那么網(wǎng)上支付業(yè)務(wù)在執(zhí)行中需求滿足以下約束條件：網(wǎng)上支付必需由客戶懇求，從快捷支付發(fā)起。網(wǎng)上支付時(shí)的資金只能從快捷支付簽約時(shí)確定的簽約銀行卡賬戶中支出，用于同一客戶的網(wǎng)上支付。網(wǎng)上支付時(shí)客戶在簽約銀行卡賬戶中的資金只能轉(zhuǎn)移到快捷支付公司指定的清算賬戶中。同一支付訂單號的快捷支付網(wǎng)上支付買賣銀行必需保證只能執(zhí)行一次。銀行與快捷支付需求保管網(wǎng)上支付相關(guān)報(bào)文的日志作為處理資金清算不一致的根據(jù)。銀行必需根據(jù)客戶的志愿做限額控制；對于信譽(yù)卡快捷支付，支付時(shí)有大額支付和小額支付之分，銀行端接納到支付報(bào)文時(shí)，需求根據(jù)快捷支付報(bào)文中的擴(kuò)展字段來區(qū)分大額支付和小額

43、支付。處置流程客戶經(jīng)過互聯(lián)網(wǎng)在快捷支付商戶處購物，并在快捷支付創(chuàng)建買賣?？蛻糨斎胫Ц睹艽a，并懇求快捷支付運(yùn)用本人快捷支付賬戶關(guān)聯(lián)的快捷支付簽約銀行卡為買賣支付?？旖葜Ц厄?yàn)證客戶身份與快捷支付網(wǎng)上支付懇求的合法性，驗(yàn)證工程包含： 該快捷支付賬戶的形狀允許支付。支付密碼正確?？旖葜Ц缎Яσ鸭せ钯~戶平安等級到達(dá)快捷支付支付的要求當(dāng)日快捷支付網(wǎng)上支付總額在快捷支付規(guī)定的快捷支付每日支付限額內(nèi)。上述驗(yàn)證中假設(shè)有一項(xiàng)不符，那么快捷支付回絕客戶的快捷支付網(wǎng)上支付懇求，并將客戶引導(dǎo)到恰當(dāng)?shù)目旖葜Ц豆δ茼撁??？旖葜Ц渡瑟?dú)一的快捷支付網(wǎng)上支付訂單號，并根據(jù)該快捷支付賬戶簽約的快捷支付協(xié)議號確定銀行、構(gòu)造“網(wǎng)上支

44、付懇求報(bào)文?？旖葜Ц秾⒃搱?bào)文發(fā)送給銀行。銀行接受“網(wǎng)上支付懇求報(bào)文，驗(yàn)證網(wǎng)上支付的合法性。驗(yàn)證工程至少包括： 快捷支付協(xié)議號對應(yīng)的快捷支付簽約記錄已勝利銀行卡形狀有效銀行卡余額足夠銀行卡號當(dāng)日累計(jì)的快捷支付支付總額未超越銀行規(guī)定的每日支付限額上述驗(yàn)證中假設(shè)有一項(xiàng)不符，那么銀行回絕該懇求報(bào)文，并前往快捷支付支付失敗的緣由。銀行處置網(wǎng)上支付買賣，從快捷支付簽約記錄中的銀行卡賬戶劃付資金至快捷支付資金清算公用賬戶中，并進(jìn)展其它關(guān)聯(lián)處置比如手續(xù)費(fèi)扣減、積分計(jì)算等。銀行處置網(wǎng)上支付買賣處置勝利之后，將買賣處置結(jié)果經(jīng)過“網(wǎng)上支付應(yīng)對報(bào)文前往給快捷支付。快捷支付接納到銀行前往的“網(wǎng)上支付應(yīng)對報(bào)文，從中解析出

45、處置結(jié)果。假設(shè)處置結(jié)果顯示銀行處置勝利，那么快捷支付為客戶進(jìn)展資金入賬，并支付該筆互聯(lián)網(wǎng)買賣?？旖葜Ц断蛴脩麸@示網(wǎng)上支付的結(jié)果。客戶查看網(wǎng)上支付的結(jié)果。報(bào)文格式 懇求標(biāo)志Tag長度能否必輸闡明報(bào)文體開場1Y客戶類型10Y商戶編號30Y訂單號12Y買賣金額(單位：分)3幣種，默許15611N手機(jī)號碼，卡種為信譽(yù)卡時(shí)必填30Y姓名注：針對信譽(yù)卡該字段無效1Y卡種，見數(shù)據(jù)字典定義！22Y卡號2N證件類型，見數(shù)據(jù)字典定義！30N證件號碼3NCvv2 ，卡種為信譽(yù)卡注：針對信譽(yù)卡該字段無效4C有效期，卡種為信譽(yù)卡時(shí)必輸報(bào)文體終了呼應(yīng)標(biāo)志Tag長度闡明報(bào)文體開場10商戶編號20流水號30訂單號1買賣形狀，

46、見數(shù)據(jù)字典定義！30預(yù)留字段1100預(yù)留字段2報(bào)文體終了單筆撤銷商戶因業(yè)務(wù)需求，在支付業(yè)務(wù)未完成清算前，取消支付的過程。假設(shè)支付曾經(jīng)完成，那么銀行會(huì)回絕呼應(yīng)吊銷支付懇求。處置流程商戶發(fā)起吊銷一筆支付的懇求；銀行檢索支付記錄的形狀，并進(jìn)展處置。假設(shè)未付那么把支付懇求吊銷，并前往給商戶支付懇求吊銷勝利的信息；否那么前往商戶吊銷支付懇求失敗的信息。交互方式在撤銷支付業(yè)務(wù)中，商戶與銀行經(jīng)過懇求-應(yīng)對方式進(jìn)展交互。報(bào)文格式 同單筆退款單筆退款業(yè)務(wù)功能對于客戶的充值金額，為防止套現(xiàn)或借用快捷支付渠道轉(zhuǎn)帳，快捷支付控制客戶不能轉(zhuǎn)入其它銀行。為滿足客戶充值金額前往原充值銀行卡的需求，那么需求充值退回功能。單筆

47、充值退回必需在快捷支付核實(shí)之后，由快捷支付發(fā)起。業(yè)務(wù)規(guī)那么單筆充值退回業(yè)務(wù)在執(zhí)行中需求滿足以下約束條件：單筆充值退回業(yè)務(wù)從快捷支付發(fā)起。單筆充值退回業(yè)務(wù)必需有對應(yīng)的快捷支付充值買賣。快捷支付可以針對90天內(nèi)的快捷支付充值發(fā)起單筆充值退回業(yè)務(wù)。單筆充值退回的金額不能超越對應(yīng)的快捷支付充值的金額，但可以少于快捷支付充值時(shí)的金額；針對一筆快捷支付充值，可以進(jìn)展多次退回，但退回的總金額不能大于該筆快捷支付充值退回的總金額。單筆退回的資金只能原路劃回快捷支付充值時(shí)運(yùn)用的簽約銀行卡賬戶中?？蛻魡喂P退回時(shí)收到的資金只能從快捷支付公司事先商定的清算賬戶中劃撥。同一退回訂單號的單筆提現(xiàn)買賣銀行必需保證只能執(zhí)行一

48、次。銀行與快捷支付需求保管單筆退回相關(guān)報(bào)文的日志，作為處理資金清算不一致的憑據(jù)。處置流程客戶在快捷支付頁面對充值金額懇求普通提現(xiàn)。提現(xiàn)失敗，出現(xiàn)錯(cuò)誤提示信息頁面和充值退回頁面鏈接入口。快捷支付系統(tǒng)對退貨退回的合法性進(jìn)展驗(yàn)證。驗(yàn)證內(nèi)容包括：客戶的快捷支付效力形狀為激活單筆退貨的互聯(lián)網(wǎng)買賣是運(yùn)用快捷支付充值的假設(shè)上述驗(yàn)證中有一項(xiàng)不符合，那么快捷支付系統(tǒng)回絕該筆快捷支付單筆退回懇求?？旖葜Ц断到y(tǒng)暫時(shí)凍結(jié)客戶快捷支付賬戶內(nèi)與單筆退貨金額等量的資金?？旖葜Ц断到y(tǒng)產(chǎn)生獨(dú)一的快捷支付單筆退貨訂單號，并根據(jù)該快捷支付賬戶簽約的快捷支付協(xié)議號確定銀行、構(gòu)造“單筆退貨懇求報(bào)文?？旖葜Ц秾⒃搱?bào)文發(fā)送給銀行。銀行接受

49、“單筆退貨懇求報(bào)文，從報(bào)文中解析出退貨指令的要素，并對其進(jìn)展合法性驗(yàn)證。驗(yàn)證內(nèi)容包括： 快捷支付協(xié)議號對應(yīng)有效的快捷支付簽約記錄快捷支付簽約銀行卡形狀有效原始快捷支付網(wǎng)上支付訂單號對應(yīng)的快捷支付支付買賣存在，且時(shí)間在90天內(nèi)針對該買賣進(jìn)展快捷支付退貨的累計(jì)金額不大于原始快捷支付支付訂單號對應(yīng)的快捷支付網(wǎng)上支付買賣的總金額本次單筆退貨訂單號之前未執(zhí)行過。上述驗(yàn)證中假設(shè)有一項(xiàng)不符，那么銀行回絕單筆退貨懇求，前往快捷支付單筆退貨不勝利的緣由。銀行處置單筆退貨買賣，從快捷支付資金清算公用賬戶中實(shí)時(shí)劃付資金至客戶的快捷支付簽約銀行卡賬戶中，并進(jìn)展其它關(guān)聯(lián)處置比如消費(fèi)積分扣減。銀行處置單筆退貨買賣勝利之后

50、，將買賣處置結(jié)果經(jīng)過“單筆退貨應(yīng)對報(bào)文前往給快捷支付?？旖葜Ц督蛹{到銀行前往的“單筆退貨應(yīng)對報(bào)文，從中解析出處置結(jié)果。假設(shè)處置結(jié)果顯示銀行處置勝利，那么快捷支付解凍客戶因退貨暫時(shí)凍結(jié)的資金，并扣減客戶快捷支付賬戶中的余額。假設(shè)處置結(jié)果顯示銀行處置失敗，那么快捷支付直接解凍客戶因退貨暫時(shí)凍結(jié)的資金，不變動(dòng)客戶快捷支付賬戶中的余額。交互方式在單筆退貨業(yè)務(wù)中，快捷支付與銀行經(jīng)過懇求-應(yīng)對方式交互。在單筆退貨流程的第5步，快捷支付作為效力運(yùn)用者向銀行發(fā)送 “單筆退貨懇求報(bào)文，在流程第8步，銀行作為效力提供者向快捷支付前往“單筆退貨應(yīng)對報(bào)文。圖6-20 單筆退款交互方式報(bào)文格式懇求標(biāo)志Tag長度能否必輸

51、闡明報(bào)文體開場1Y客戶類型10Y商戶編號2Y買賣類型16;/吊銷支付18;/實(shí)時(shí)退款30Y原訂單號12N退款金額 (單位：分)類型為“退款時(shí)必填！30預(yù)留字段1100預(yù)留字段2報(bào)文體終了呼應(yīng)標(biāo)志Tag長度闡明報(bào)文體開場10商戶編號20流水號30原訂單號1買賣形狀，見數(shù)據(jù)字典定義！30預(yù)留字段1100預(yù)留字段2報(bào)文體終了單筆/批量買賣查詢業(yè)務(wù)功能快捷支付批量查詢由快捷支付發(fā)起，向銀行查詢一定時(shí)間段范圍內(nèi)全部或指定一組訂單號的支付、提現(xiàn)或退貨買賣的處置形狀。當(dāng)由于網(wǎng)絡(luò)或系統(tǒng)缺點(diǎn)產(chǎn)生掉單快捷支付發(fā)出了快捷支付懇求報(bào)文，但沒有收到銀行的應(yīng)對報(bào)文時(shí)，快捷支付可以運(yùn)用快捷支付批量買賣查詢業(yè)務(wù)得到銀行的買賣

52、形狀，并運(yùn)用該形狀對快捷支付買賣進(jìn)展恢復(fù)處置。這樣做，可以及時(shí)恢復(fù)客戶的買賣，提升客戶體驗(yàn)。業(yè)務(wù)規(guī)那么批量查詢查詢業(yè)務(wù)在執(zhí)行中需求滿足以下約束條件：只需快捷支付支付和快捷支付單筆退貨及撤銷買賣是可以查詢的。銀行端前往勝利的買賣形狀代表賬務(wù)勝利，前往失敗的代表賬務(wù)失敗。銀行端只前往賬務(wù)處置主機(jī)有明確結(jié)果的買賣形狀,不明確的不用前往。銀行必需保證前往的快捷支付買賣的處置形狀與實(shí)踐形狀一致。快捷支付以銀行前往的查詢結(jié)果信息為準(zhǔn)調(diào)整快捷支付端的買賣形狀，快捷支付買賣的處置形狀一旦進(jìn)入勝利形狀或者失敗形狀，那么銀行端不允許改動(dòng)?？旖葜Ц栋l(fā)起的快捷支付批量買賣查詢的時(shí)間段是當(dāng)日的任一準(zhǔn)確到秒的時(shí)間段，時(shí)間

53、段的起止時(shí)間是快捷支付公司發(fā)起的買賣指令中的時(shí)間。對于支付買賣查詢，前往的結(jié)果里面必需是一切勝利的支付流水，失敗的不能前往。而且下面的STATUS也不要填寫，這個(gè)形狀是供提現(xiàn)查詢運(yùn)用的，假設(shè)需求填寫，必需保證是勝利形狀0001。銀行端必需實(shí)現(xiàn)按照時(shí)間段查詢，時(shí)間段加上流水號，流水號這三種方式查詢對于信譽(yù)卡快捷支付，快捷支付發(fā)起批量查詢時(shí)，運(yùn)用擴(kuò)展字段標(biāo)明本次查詢懇求是針對大額的還是針對小額的；銀行處置完成，前往查詢結(jié)果通知時(shí)，同樣需求在擴(kuò)展字段標(biāo)明查詢結(jié)果屬于大額還是小額。(查詢懇求和查詢結(jié)果通知報(bào)文中大小額標(biāo)識，針對本次查詢，不用于流水明細(xì))處置流程批量查詢查詢的處置流程如下：快捷支付系統(tǒng)根

54、據(jù)未得到銀行應(yīng)對的快捷支付買賣懇求，確定當(dāng)日的某個(gè)需求實(shí)時(shí)查詢的買賣時(shí)間段、買賣類型與買賣訂單號列表?？旖葜Ц断到y(tǒng)以該時(shí)間段、買賣類型與買賣單號列表構(gòu)造“批量查詢查詢懇求報(bào)文，并發(fā)送給銀行。銀行收到“批量查詢查詢懇求報(bào)文之后，驗(yàn)證查詢起始時(shí)間與終了時(shí)間能否在允許范圍內(nèi)。假設(shè)不在允許范圍內(nèi)，那么銀行回絕快捷支付的批量查詢查詢通知。銀行向快捷支付前往“批量查詢查詢接受報(bào)文，表示已接受快捷支付批量買賣查詢懇求?？旖葜Ц督拥健芭坎樵儾樵兘邮軋?bào)文之后，完成懇求發(fā)送任務(wù)?？旖葜Ц恫煌降却坎樵儾樵兘Y(jié)果。銀行根據(jù)查詢懇求中的買賣類型、買賣時(shí)間段與買賣訂單號列表，查詢這些買賣的實(shí)踐執(zhí)行結(jié)果。銀行將買賣的

55、實(shí)踐執(zhí)行結(jié)果組裝成“批量查詢查詢結(jié)果報(bào)文，以單向通知的方式發(fā)送給快捷支付。假設(shè)通知失敗，銀行需求有恰當(dāng)?shù)闹卦噾?zhàn)略?？旖葜Ц督蛹{到批量查詢查詢結(jié)果之后，根據(jù)結(jié)果逐條買賣進(jìn)展恢復(fù)處置。交互方式快捷支付與銀行經(jīng)過懇求-應(yīng)對方式交互。報(bào)文格式懇求標(biāo)志Tag長度能否必輸闡明報(bào)文體開場10Y商戶編號1Y查詢類型0：當(dāng)日1：歷史30Y訂單號或者打款號30預(yù)留字段1100預(yù)留字段2報(bào)文體終了呼應(yīng)標(biāo)志Tag長度闡明報(bào)文體開場10商戶編號60商戶稱號循環(huán)域開場單筆開場30訂單號或打款號20買賣流水號2買賣類型，見數(shù)據(jù)字典定義12買賣金額(單位：分)14買賣日期時(shí)間12已退款金額(單位：分)12已預(yù)授權(quán)完成金額(單

56、位：分)1買賣形狀，見數(shù)據(jù)字典定義單筆終了循環(huán)體終了30預(yù)留字段1100預(yù)留字段2報(bào)文體終了清算對賬業(yè)務(wù)功能從快捷支付發(fā)起的快捷支付網(wǎng)上支付退貨買賣的執(zhí)行結(jié)果以銀行前往給快捷支付的買賣應(yīng)對為準(zhǔn)。當(dāng)發(fā)生網(wǎng)絡(luò)喪失報(bào)文或系統(tǒng)缺點(diǎn)時(shí)，銀行前往給快捷支付的買賣應(yīng)對有能夠喪失，呵斥客戶簽約銀行卡賬戶中的資金變動(dòng)與快捷支付賬戶中的資金變動(dòng)不一致。除了買賣應(yīng)對喪失產(chǎn)生清算不一致的情況下，還能夠由于其它緣由比如系統(tǒng)中的缺陷，或者人為要素產(chǎn)生清算不一致?？旖葜Ц肚逅銓~業(yè)務(wù)的目的是發(fā)現(xiàn)用戶簽約銀行卡賬戶與快捷支付賬戶中的資金變動(dòng)不一致的情況，并確定緣由與處置方法?？旖葜Ц肚逅銓~業(yè)務(wù)普通一天進(jìn)展一次，獲取由銀行在

57、T日終核對完成之后提供T日0:00-24:00一切涉及到資金變動(dòng)的快捷支付買賣的明細(xì)數(shù)據(jù)，與快捷支付T日的快捷支付買賣數(shù)據(jù)進(jìn)展比對，找出不一致的買賣記錄。對于由于銀行買賣應(yīng)對喪失呵斥的快捷支付不一致的買賣記錄，由快捷支付進(jìn)展恢復(fù)處置。對于由于其它緣由產(chǎn)生清算不一致的情況，根據(jù)快捷支付收到的銀行買賣應(yīng)對內(nèi)容確定資金處置過失的一方，并由該方進(jìn)展賬務(wù)調(diào)整處置。假設(shè)由銀行方的資金處置過失呵斥清算過失，那么按照快捷支付清算規(guī)范中規(guī)定的過失處置方法進(jìn)展清算過失處置。業(yè)務(wù)規(guī)那么清算對賬業(yè)務(wù)在執(zhí)行中需求滿足以下約束條件：銀行提供的T日0:00-24:00變化的快捷支付買賣明細(xì)數(shù)據(jù)需求與銀行的賬務(wù)處置一致。T日

58、快捷支付買賣凈額需求與銀行清算給快捷支付的T日快捷支付款項(xiàng)凈額一樣。當(dāng)清算對賬完成后，并完成過失處置之后，雙方直至T日的一切快捷支付買賣引起的資金變動(dòng)必需一致。對于信譽(yù)卡快捷支付清算對賬，銀行在通知快捷支付做清算對賬時(shí)，需求將大額信譽(yù)卡和小額信譽(yù)卡對應(yīng)的清算流水生成到不同的清算文件中，在發(fā)送清算對賬通知時(shí)，需求在報(bào)文的擴(kuò)展字段中標(biāo)明文件中的流水信息屬于大額還是小額。處置流程清算對賬的處置流程如下所示：快捷支付收到“清算對賬報(bào)文后，從銀行提供的清算對賬文件中解析出每一條快捷支付買賣記錄，與本人在該對賬日期的一切快捷支付買賣記錄進(jìn)展逐筆核對。找出并生成以下三類買賣記錄的清單。A：銀行有，但快捷支付

59、沒有的買賣記錄B：快捷支付有，但銀行沒有的買賣記錄C：雙方都有，但內(nèi)容不一致的買賣記錄快捷支付對不一致的快捷支付買賣記錄進(jìn)展恢復(fù)與處置。對于A類買賣記錄，快捷支付進(jìn)展買賣恢復(fù)，使快捷支付對該筆買賣的資金處置與銀行一致。對于B類買賣記錄與C類買賣記錄，快捷支付人工介入處置，經(jīng)過核對原始的銀行應(yīng)對指令，找出緣由并確定該由哪方進(jìn)展訂正。假設(shè)存在需求銀行進(jìn)展調(diào)整的買賣記錄，那么快捷支付線下提供應(yīng)銀行的需求調(diào)整的買賣記錄清單，以及原始的銀行應(yīng)對指令，由銀行在人工核實(shí)之后進(jìn)展處置。交互方式快捷支付與銀行經(jīng)過懇求-應(yīng)對方式交互。報(bào)文格式懇求標(biāo)志Tag長度能否必輸闡明報(bào)文體開場10Y商戶編號8Y對賬日期yyy

60、yMMdd30預(yù)留字段1100預(yù)留字段2報(bào)文體終了呼應(yīng)I長度闡明報(bào)文體開場10商戶編號8對賬日期30訂單號或打款號20流水號14買賣時(shí)間yyyyMMddHHmmss12買賣金額 以分為單位2買賣類型，見數(shù)據(jù)字典定義1買賣形狀 ，見數(shù)據(jù)字典定義100預(yù)留字段30100報(bào)文體終了網(wǎng)絡(luò)銜接規(guī)范快捷支付渠道與銀行快捷支付渠道之間的平安信道建立方式與高層網(wǎng)絡(luò)銜接協(xié)議。平安規(guī)范在快捷支付業(yè)務(wù)流程與規(guī)范中，曾經(jīng)采用了大量的規(guī)那么來降低快捷支付業(yè)務(wù)的平安風(fēng)險(xiǎn)，如快捷支付簽約客戶的實(shí)名制；快捷支付業(yè)務(wù)的資金流動(dòng)量、流動(dòng)途徑與方向的業(yè)務(wù)規(guī)那么等。因此，本章主要從技術(shù)角度論述快捷支付系統(tǒng)中能夠出現(xiàn)的平安要挾，以及經(jīng)