本發(fā)明實施例涉及監(jiān)測領(lǐng)域，尤其涉及一種交易驗證方法和裝置。
背景技術(shù)：
：銀聯(lián)的全渠道平臺作為前置系統(tǒng)接入中國銀聯(lián)銀行卡信息交換系統(tǒng)，負責除線下支付之外的所有支付渠道接入，主要支撐移動、互聯(lián)網(wǎng)、語音等渠道前端產(chǎn)品，機構(gòu)及大商戶后臺接入后端產(chǎn)品。支持消費、預(yù)授權(quán)、退貨、查詢、繳費、還款、轉(zhuǎn)賬、代收、代付、集成電路卡(IntegratedCircuitCard，簡稱IC卡)類等共計37項交易類型。銀行通道方面，全渠道平臺目前支持2.0無卡、2.1無卡自助消費、2.1代收、2.1代付、2.1訂購、自聯(lián)銀行代扣、“商對客”(Business-to-Customer，簡稱B2C)網(wǎng)銀消費、多渠道代扣，多種銀行扣款通道，且各通道支持銀行不一，同一種通道各銀行扣款交易要素也不盡相同。面對復(fù)雜的交易組合和多樣的銀行通道，銀聯(lián)的對外服務(wù)部門需要精確了解全渠道平臺在生產(chǎn)環(huán)境下的業(yè)務(wù)支持情況，以便在對外服務(wù)時做到有的放矢、提高服務(wù)質(zhì)量。目前主要依賴一個簡單的報文生成工具和自動測試工具(quicktestProfessional，簡稱QTP)來開展驗證工作，存在如下問題：工具不夠自動化，不但需要人工填寫交易要素，同時驗證結(jié)果需要人工進行匯總整理，從而使得記錄的驗證結(jié)果容易出錯且人力成本投入較大。技術(shù)實現(xiàn)要素：本發(fā)明實施例提供一種交易驗證方法和裝置，用以解決現(xiàn)有技術(shù)中監(jiān)測支持交易屬性的過程中人工操作容易出錯且人力成本投入較大的問題。本發(fā)明實施例提供了一種交易驗證方法，包括：獲取待驗證案例，所述待驗證案例是根據(jù)交易模板和待驗證信息生成；根據(jù)所述待驗證案例生成驗證交易報文；根據(jù)所述驗證交易報文對所述待驗證案例進行驗證并確定驗證結(jié)果；在所述驗證結(jié)果與預(yù)設(shè)基準匹配時，將所述待驗證信息記錄為支持的交易屬性，所述預(yù)設(shè)基準是根據(jù)所述待驗證案例確定的。可選地，所述待驗證案例是根據(jù)交易模板和待驗證信息生成，包括：所述待驗證信息包括交易報文類型、驗證的多方交易對象；根據(jù)所述交易報文類型，確定所述交易報文類型對應(yīng)的關(guān)聯(lián)要素；根據(jù)所述驗證的多方交易對象，確定驗證要素集；根據(jù)所述交易模板、所述關(guān)聯(lián)要素和所述驗證要素集確定所述待驗證案例?？蛇x地，所述根據(jù)所述待驗證案例生成驗證交易報文，包括：所述驗證的多方交易對象包括待驗證銀行卡的卡號；根據(jù)所述待驗證銀行卡的卡號、所述交易報文類型對應(yīng)的關(guān)聯(lián)要素的取值方式確定所述交易報文類型對應(yīng)的關(guān)聯(lián)要素的具體取值和所述驗證要素集的具體取值，其中，所述交易報文類型對應(yīng)的關(guān)聯(lián)要素的取值方式是根據(jù)預(yù)設(shè)規(guī)則確定的；將所述交易報文類型對應(yīng)的關(guān)聯(lián)要素的具體取值和所述驗證要素集的具體取值進行組裝生成所述驗證交易報文?？蛇x地，所述根據(jù)所述驗證交易報文對所述待驗證案例進行驗證并確定驗證結(jié)果，包括：將所述驗證交易報文發(fā)送至所述待驗證銀行卡的發(fā)卡行，以使所述待驗證銀行卡的發(fā)卡行對所述驗證交易報文進行處理并反饋驗證結(jié)果；接收所述待驗證銀行卡的發(fā)卡行反饋的驗證結(jié)果。可選地，所述根據(jù)所述驗證交易報文對所述待驗證案例進行驗證并確定驗證結(jié)果之后，還包括：在確定所述驗證結(jié)果與預(yù)設(shè)基準不匹配時，將所述待驗證信息記錄為不支持的交易屬性。相應(yīng)的，本發(fā)明實施例還提供了一種交易驗證裝置，包括：獲取模塊，用于獲取待驗證案例，所述待驗證案例是根據(jù)交易模板和待驗證信息生成；處理模塊，用于根據(jù)所述待驗證案例生成驗證交易報文；驗證模塊，用于根據(jù)所述驗證交易報文對所述待驗證案例進行驗證并確定驗證結(jié)果；統(tǒng)計模塊，用于在所述驗證結(jié)果與預(yù)設(shè)基準匹配時，將所述待驗證信息記錄為支持的交易屬性，所述預(yù)設(shè)基準是根據(jù)所述待驗證案例確定的。可選地，所述所述獲取模塊具體用于：根據(jù)交易模板和待驗證信息生成待驗證案例；所述待驗證信息包括交易報文類型、驗證的多方交易對象；根據(jù)所述交易報文類型，確定所述交易報文類型對應(yīng)的關(guān)聯(lián)要素；根據(jù)所述驗證的多方交易對象，確定驗證要素集；根據(jù)所述交易模板、所述關(guān)聯(lián)要素和所述驗證要素集確定所述待驗證案例?？蛇x地，所述處理模塊具體用于：所述驗證的多方交易對象包括待驗證銀行卡的卡號；根據(jù)所述待驗證銀行卡的卡號、所述交易報文類型對應(yīng)的關(guān)聯(lián)要素的取值方式確定所述交易報文類型對應(yīng)的關(guān)聯(lián)要素的具體取值和所述驗證要素集的具體取值，其中，所述交易報文類型對應(yīng)的關(guān)聯(lián)要素的取值方式是根據(jù)預(yù)設(shè)規(guī)則確定的；將所述交易報文類型對應(yīng)的關(guān)聯(lián)要素的具體取值和所述驗證要素集的具體取值進行組裝生成所述驗證交易報文?？蛇x地，所述驗證模塊具體用于：將所述驗證交易報文發(fā)送至所述待驗證銀行卡的發(fā)卡行，以使所述待驗證銀行卡的發(fā)卡行對所述驗證交易報文進行處理并反饋驗證結(jié)果；接收所述待驗證銀行卡的發(fā)卡行反饋的驗證結(jié)果?？蛇x地，所述統(tǒng)計模塊還用于：所述根據(jù)所述驗證交易報文對所述待驗證案例進行驗證并確定驗證結(jié)果之后，在確定所述驗證結(jié)果與預(yù)設(shè)基準不匹配時，將所述待驗證信息記錄為不支持的交易屬性。本發(fā)明實施例，獲取待驗證案例，所述待驗證案例是根據(jù)交易模板和待驗證信息生成，然后根據(jù)所述待驗證案例生成驗證交易報文，根據(jù)所述驗證交易報文對所述待驗證案例進行驗證并確定驗證結(jié)果，最后在所述驗證結(jié)果與預(yù)設(shè)基準匹配時，將所述待驗證信息記錄為支持的交易屬性，所述預(yù)設(shè)基準是根據(jù)所述待驗證案例確定的。本發(fā)明實施例中根據(jù)交易模板和待驗證信息自動生成待驗證案例，同時對待驗證案例的執(zhí)行、驗證結(jié)果收集也進行了自動化設(shè)計，從而提高了交易驗證的速度，避免了人工收集和統(tǒng)計驗證結(jié)果帶來的出錯問題，降低了人力投入的成本。附圖說明為了更清楚地說明本發(fā)明實施例中的技術(shù)方案，下面將對實施例描述中所需要使用的附圖作簡要介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域的普通技術(shù)人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。圖1為本發(fā)明實施例提供的一種交易驗證方法的流程示意圖；圖2為本發(fā)明實施例提供的一種驗證案例生成的流程示意圖；圖3為本發(fā)明實施例提供的一種系統(tǒng)案例組裝的流程示意圖；圖4為本發(fā)明實施例提供的另一種交易驗證方法的流程示意圖；圖5為本發(fā)明實施例提供的一種交易驗證裝置的結(jié)構(gòu)示意圖。具體實施方式為了使本發(fā)明的目的、技術(shù)方案及有益效果更加清楚明白，以下結(jié)合附圖及實施例，對本發(fā)明進行進一步詳細說明。應(yīng)當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。圖1例性示出了本發(fā)明實施例提供的一種交易驗證方法的流程，該流程可以由交易驗證裝置執(zhí)行。步驟S101，獲取待驗證案例。步驟S102，根據(jù)所述待驗證案例生成驗證交易報文。步驟S103，根據(jù)所述驗證交易報文對所述待驗證案例進行驗證并確定驗證結(jié)果。步驟S104，在所述驗證結(jié)果與預(yù)設(shè)基準匹配時，將所述待驗證信息記錄為支持的交易屬性。上述實施例中的待驗證案例可以是從提前建立的驗證案例集中獲取，也可以在確定需要驗證的特定交易時，實時建立的。在對驗證案例進行驗證時，可以取整個驗證案例集執(zhí)行，將驗證案例集中每個驗證案例作為待驗證案例。也可以取單個驗證案例作為待驗證案例執(zhí)行。本發(fā)明實施例中根據(jù)交易模板和待驗證信息自動生成待驗證案例，同時對待驗證案例的執(zhí)行、驗證結(jié)果收集也進行了自動化設(shè)計，從而提高了交易驗證的速度，避免了人工收集和統(tǒng)計驗證結(jié)果帶來的出錯問題，降低了人力投入的成本。具體地，待驗證案例是根據(jù)交易模板和待驗證信息生成的，其中待驗證信息包括交易報文類型和驗證的多方交易對象，具體實施中，可以在系統(tǒng)中預(yù)設(shè)多種待驗證信息，定期進行循環(huán)驗證；也可以是基于用戶需求，根據(jù)用戶輸入的信息得到待驗證信息。本發(fā)明實施例提供了一種待驗證案例的生成過程，如圖2所示，包括以下步驟：步驟S201，根據(jù)交易報文類型，確定所述交易報文類型對應(yīng)的關(guān)聯(lián)要素；步驟S202，根據(jù)所述驗證的多方交易對象，確定驗證要素集；步驟S203，根據(jù)所述交易模板、所述關(guān)聯(lián)要素和所述驗證要素集確定所述待驗證案例。具體實施中，交易模板包括系統(tǒng)案例組裝模板和驗證案例組裝模板，確定待驗證案例的具體過程為：首先根據(jù)交易報文類型確定交易報文類型對應(yīng)的關(guān)聯(lián)要素，根據(jù)關(guān)聯(lián)要素和系統(tǒng)案例組裝模板組裝系統(tǒng)案例，然后根據(jù)系統(tǒng)案例、驗證要素集以及驗證案例組裝模板組裝待驗證案例。針對關(guān)聯(lián)要素和系統(tǒng)案例組裝模板組裝系統(tǒng)案例，如圖3所示，一種可實現(xiàn)方式包括以下步驟：步驟S301，確定交易報文類型；步驟S302，根據(jù)交易報文類型確定關(guān)聯(lián)要素及關(guān)聯(lián)要素的取值方式；步驟S303，將關(guān)聯(lián)要素按照系統(tǒng)案例組裝模板組裝。其中步驟S301中交易報文類型是根據(jù)交易類型、交易子類、產(chǎn)品類型、上送URL確定的。本發(fā)明實施例提供了一種交易報文類型確定的示例，如表1所示。表1交易報文類型確定示例表1中確定了一種消費交易報文，該消費交易報文對應(yīng)的報文ID為0001，報文類型說明為網(wǎng)關(guān)支付產(chǎn)品消費，交易類型為01：消費，交易子類為01：消費，產(chǎn)品類型為000201：B2C網(wǎng)關(guān)支付，上送URL為后臺URL。在步驟S302中，確定交易報文類型后，根據(jù)系統(tǒng)中預(yù)置的配置表，得到該交易報文類型對應(yīng)的關(guān)聯(lián)要素，并確定關(guān)聯(lián)要素的取值方式，其中交易報文類型對應(yīng)的關(guān)聯(lián)要素即為與交易報文類型匹配的交易報文要素。一種交易報文類型包括很多關(guān)聯(lián)要素，比如版本號、編碼格式、證書ID、簽名方法、簽名、商戶號、渠道類型、接入類型、證件類型等。關(guān)聯(lián)要素的值產(chǎn)生規(guī)則不同，有些是固定取值，有些是按照固定邏輯規(guī)則產(chǎn)生的，有些是根據(jù)自定義規(guī)則產(chǎn)生的。具體實施中，可以設(shè)計兩個配置表，兩個配置表分別是交易報文要素表和交易報文要素關(guān)聯(lián)表。根據(jù)這兩個配置表可以得到該交易報文類型的關(guān)聯(lián)要素及關(guān)聯(lián)要素的取值方式。例如確定報文ID為0001的消費交易報文后，根據(jù)系統(tǒng)中預(yù)置的配置表確定該消費交易報文對應(yīng)的交易報文要素關(guān)聯(lián)表，交易報文要素關(guān)聯(lián)表中包括報文ID為0001的消費交易報文對應(yīng)的所有關(guān)聯(lián)要素的要素ID，具體如表2所示。表2交易報文要素關(guān)聯(lián)表示例報文ID要素ID默認值00011{value:5.0.0}0001200013000140001500016000170001800019000110000111000112000113000114如表2所示，報文ID為0001的消費交易報文對應(yīng)有14個關(guān)聯(lián)要素，要素ID分別為1至14,其中要素ID為1的關(guān)聯(lián)要素取默認值，要素ID為2至14的關(guān)聯(lián)要素的具體取值方式需要查詢交易報文要素表來獲取。交易報文要素表中定義了各種交易報文類型對應(yīng)的交易報文要素，定義的每個交易報文要素包括要素ID、父ID、要素域名、要素變量名、要素數(shù)據(jù)格式、要素取值說明、取值類型以及要素具體值。表3示例性示出了一種交易報文要素表。表3交易報文要素表示例如表3所示，交易報文要素表中包括了14種交易報文要素以及各交易報文要素對應(yīng)的具體取值方式。需要說明的是，交易報文要素表中的交易報文要素并不限于上述14種。根據(jù)表2中消費交易報文對應(yīng)的關(guān)聯(lián)要素的要素ID從表3中查詢出相同的要素ID，然后根據(jù)相同要素ID對應(yīng)的交易報文要素的具體取值方式確定消費交易報文對應(yīng)的關(guān)聯(lián)要素的具體取值方式。例如通過查詢表3將要素ID為2的交易報文要素的具體取值方式確定為表2中要素ID為2的關(guān)聯(lián)要素的具體取值方式，最終確定報文ID為0001的消費交易報文中要素ID為2的關(guān)聯(lián)要素父報文ID為2，要素域名為編碼格式，要素變量名為encoding，要素數(shù)據(jù)格式為ANS1..20，要素取值說明為填寫報文使用的字符編碼，UTF-8|GBK|GB2312|GB18030，若不填寫，默認取值：UTF-8，取值類型為1：固定值，要素具體值為{value:UTF-8}。同樣的，根據(jù)相同的查詢方式可以得到報文ID為0001的消費交易報文其它對應(yīng)的關(guān)聯(lián)要素的具體取值方式，其中交易報文要素的要素ID為12、13和14的交易報文要素對應(yīng)同一個父報文ID。最后，系統(tǒng)案例組裝模板結(jié)合各關(guān)聯(lián)要素的父報文ID和各關(guān)聯(lián)要素得到系統(tǒng)案例。以下介紹驗證要素集的一種實現(xiàn)方式，具體地，待驗證信息中的多方交易對象包括銀行卡性質(zhì)、發(fā)卡銀行以及上傳至發(fā)卡行銀行的驗證要素。根據(jù)銀行卡性質(zhì)、發(fā)卡銀行以及上傳至發(fā)卡行銀行的驗證要素確定交易驗證過程中的驗證要素集。其中上傳至發(fā)卡銀行的驗證元素根據(jù)銀行卡性質(zhì)不同對應(yīng)的驗證元素不同。比如對于借記卡和貸記卡對應(yīng)的驗證元素分別如表4和表5所示。表4借記卡驗證元素示例其中，●：代表上送正確值，代表上送錯誤值，○：代表不上送。表5貸記卡驗證元素示例其中，CVN2為卡確認碼/安全碼，全稱為CardVerificationNumber，●：代表上送正確值，代表上送錯誤值，○：代表不上送。表4中借記卡對應(yīng)的上傳至發(fā)卡銀行的驗證要素包括卡號、密碼、手機號、姓名和證件號。在上傳驗證元素時可以采取不同的方式，比如卡號、密碼、手機號、姓名和證件號均上傳正確值，或者卡號、密碼、手機號、姓名上傳正確值，證件號碼上傳錯誤值等。表5中貸記卡對應(yīng)的上傳至發(fā)卡銀行的驗證要素包括卡號、有效期、CVN2、手機號、姓名和證件號，在上傳驗證元素時也可以采取不同的方式。由于針對每種交易類型確定交易報文類型，并結(jié)合發(fā)卡銀行的相關(guān)信息確定驗證案例，充分考慮了在線支付的業(yè)務(wù)復(fù)雜性，具有很強的針對性，能實現(xiàn)復(fù)雜業(yè)務(wù)場景的驗證。通過上述實施例得到待驗證案例后，根據(jù)待驗證案例中的信息生成驗證交易報文。本發(fā)明實施例提供了一種具體實現(xiàn)方式為：驗證的多方交易對象包括待驗證銀行卡的卡號，故根據(jù)待驗證銀行卡的卡號、交易報文類型對應(yīng)的關(guān)聯(lián)要素的取值方式確定交易報文類型對應(yīng)的關(guān)聯(lián)要素的具體取值和驗證要素集的具體取值，其中，交易報文類型對應(yīng)的關(guān)聯(lián)要素的取值方式是根據(jù)預(yù)設(shè)規(guī)則確定的。然后將交易報文類型對應(yīng)的關(guān)聯(lián)要素的具體取值和驗證要素集的具體取值進行組裝生成驗證交易報文。具體實施中，驗證的多方交易對象中待驗證銀行卡的卡號可以人工輸入或者提前存儲于數(shù)據(jù)庫中，使用時直接調(diào)用。為了更清楚地介紹驗證交易報文的生成過程，本發(fā)明實施例提供以下示例。設(shè)定選取的待驗證案例為驗證交通銀行卡是否支持借記卡的消費交易類型，通過用戶輸入的方式確定了交通銀行卡的卡號，根據(jù)交通銀行卡的卡號查詢對應(yīng)該交通銀行卡的賬戶信息，賬戶信息包括用戶姓名、手機號、證件號等，根據(jù)查詢得到的賬戶信息結(jié)合借記卡的驗證元素的組合形式得到用戶需要上傳至交通銀行的驗證要素的具體取值。進一步地，根據(jù)交易報文要素表確定消費交易類型對應(yīng)的關(guān)聯(lián)要素的具體取值方式，并結(jié)合用戶輸入的交通銀行卡的卡號得到消費交易類型對應(yīng)的關(guān)聯(lián)要素的具體取值。將消費交易類型對應(yīng)的關(guān)聯(lián)要素的具體取值、驗證要素集的具體取值按照報文要素層級組裝成json(全稱JavaScriptObjectNotation)字符串，組裝成的json字符串即為生成的驗證交易報文。需要說明的是本發(fā)明實施例在確定交易報文類型對應(yīng)的關(guān)聯(lián)要素的具體取值和驗證要素集的具體取值時，并不僅限于通過輸入待驗證銀行卡的卡號，還可以通過輸入商戶號、用戶姓名、手機號碼、證件號碼及其結(jié)合等。本發(fā)明實施例在生成驗證交易報文之后，根據(jù)驗證交易報文對待驗證案例進行驗證并確定驗證結(jié)果，在驗證結(jié)果與預(yù)設(shè)基準匹配時，將待驗證信息記錄為支持的交易屬性，預(yù)設(shè)基準是根據(jù)待驗證案例確定的。具體為將驗證交易報文發(fā)送至待驗證銀行卡的發(fā)卡行，以使待驗證銀行卡的發(fā)卡行對驗證交易報文進行處理并反饋驗證結(jié)果。然后接收待驗證銀行卡的發(fā)卡行反饋的驗證結(jié)果后將驗證結(jié)果與預(yù)設(shè)基準對比，若確定驗證結(jié)果與預(yù)設(shè)基準匹配時，將待驗證信息記錄為支持的交易屬性。在確定驗證結(jié)果與預(yù)設(shè)基準不匹配時，將待驗證信息記錄為不支持的交易屬性。具體實施中，設(shè)定選取的待驗證案例為驗證交通銀行卡是否支持借記卡的消費交易類型。業(yè)務(wù)運營監(jiān)測平臺確定了驗證交易報文后，將驗證交易報文發(fā)送至交通銀行。交通銀行在接收后對驗證交易報文進行處理，根據(jù)驗證交易報文中的消費交易報文對應(yīng)的關(guān)聯(lián)要素確定是否支持消費交易類型，根據(jù)驗證信息中的驗證要素集確定消費交易時用戶需要上傳至交通銀行的驗證要素。交通銀行對驗證交易報文處理完后反饋驗證結(jié)果。業(yè)務(wù)運營監(jiān)測平臺在接收到反饋的驗證結(jié)果后與預(yù)設(shè)基準進行對比，預(yù)設(shè)基準的設(shè)置方法可以為設(shè)置待驗證案例的執(zhí)行結(jié)果基準，也可以設(shè)置返回應(yīng)答碼基準，還可以設(shè)置應(yīng)答報文某個域的基準。如果反饋的驗證結(jié)果后與預(yù)設(shè)基準匹配，則說明交通銀行支持借記卡的消費交易類型，同時確定了消費交易時用戶需要上傳至交通銀行的驗證要素。將消費交易類型、交通銀行、借記卡以及驗證要素確定為支持的交易屬性。如果反饋的驗證結(jié)果后與預(yù)設(shè)基準不匹配，則說明交通銀行不支持借記卡的消費交易類型。將消費交易類型、交通銀行、借記卡以及驗證要素確定為不支持的交易屬性。進一步地，將支持的交易屬性記錄到交易日志表中。在執(zhí)行驗證案例的過程中，業(yè)務(wù)運營監(jiān)測平臺發(fā)送驗證交易報文一段時間后若沒有得到反饋的驗證結(jié)果，可以組裝驗證結(jié)果查詢報文查詢驗證結(jié)果并根據(jù)查詢結(jié)果更新交易日志表。如果超過10次查詢沒有得到驗證結(jié)果，則認為該交易驗證失敗。通過驗證多個驗證案例可以得到待驗證銀行支持的各種交易類型以及驗證要素上傳要求。通過將同一個驗證案例多次執(zhí)行情況作對比分析，將驗證結(jié)果發(fā)生變化的案例進行統(tǒng)計可以得到支持的交易屬性的變遷歷史。由于對驗證案例執(zhí)行、驗證結(jié)果收集和驗證結(jié)果統(tǒng)計分析進行了自動化設(shè)計，從而大大提高了交易驗證的速度，減小了人工出錯的概率。為了更好的解釋本發(fā)明實施例，下面通過具體的實施場景描述本發(fā)明實施例提供的一種交易驗證方法的流程，設(shè)定需要驗證發(fā)卡銀行A是否支持借記卡的交易類型B交易，同時確定用戶需要上傳至發(fā)卡銀行A的驗證要素，如圖4所示，包括以下步驟：步驟S401，根據(jù)交易類型B確定交易報文類型C，并配置交易報文類型C的關(guān)聯(lián)要素。步驟S402，根據(jù)交易報文類型C的關(guān)聯(lián)要素、發(fā)卡銀行A、借記卡和上傳至發(fā)卡銀行A的驗證要素組裝待驗證案例。步驟S403，用戶輸入發(fā)卡銀行A的銀行卡卡號以及交易中的商戶號。步驟S404，根據(jù)發(fā)卡銀行A的銀行卡卡號以及交易中的商戶號得到交易報文類型C的關(guān)聯(lián)要素具體取值和驗證元素的具體取值。步驟S405，根據(jù)交易報文類型C的關(guān)聯(lián)要素具體取值、發(fā)卡銀行A、借記卡和驗證元素的具體取值組裝驗證交易報文。步驟S406，將驗證交易報文發(fā)送至全渠道聯(lián)機系統(tǒng)。步驟S407，全渠道聯(lián)機系統(tǒng)調(diào)用無卡路由服務(wù)獲取路由信息，并向中國銀聯(lián)銀行卡信息交換系統(tǒng)發(fā)起交易請求。步驟S408，中國銀聯(lián)銀行卡信息交換系統(tǒng)將交易轉(zhuǎn)發(fā)給發(fā)卡銀行A并將發(fā)卡銀行A反饋的驗證結(jié)果返回給全渠道聯(lián)機系統(tǒng)。步驟S409，全渠道聯(lián)機系統(tǒng)將驗證結(jié)果返回給業(yè)務(wù)運營監(jiān)測平臺。步驟S410，業(yè)務(wù)運營監(jiān)測平臺獲取到驗證結(jié)果后和該驗證案例的預(yù)設(shè)基準做比對并記錄驗證結(jié)果和比對結(jié)果。本發(fā)明實施例，獲取待驗證案例，所述待驗證案例是根據(jù)交易模板和待驗證信息生成，然后根據(jù)所述待驗證案例生成驗證交易報文，根據(jù)所述驗證交易報文對所述待驗證案例進行驗證并確定驗證結(jié)果，最后在所述驗證結(jié)果與預(yù)設(shè)基準匹配時，將所述待驗證信息記錄為支持的交易屬性，所述預(yù)設(shè)基準是根據(jù)所述待驗證案例確定的。本發(fā)明實施例中根據(jù)交易模板和待驗證信息自動生成待驗證案例，同時對待驗證案例的執(zhí)行、驗證結(jié)果收集也進行了自動化設(shè)計，從而提高了交易驗證的速度，避免了人工收集和統(tǒng)計驗證結(jié)果帶來的出錯問題，降低了人力投入的成本?；谙嗤瑯?gòu)思，圖5示例性的示出了本發(fā)明實施例提供的一種交易驗證裝置的結(jié)構(gòu)，該裝置可以執(zhí)行交易驗證的流程。如圖5所示，該裝置包括：獲取模塊501，用于獲取待驗證案例，所述待驗證案例是根據(jù)交易模板和待驗證信息生成；處理模塊502，用于根據(jù)所述待驗證案例生成驗證交易報文；驗證模塊503，用于根據(jù)所述驗證交易報文對所述待驗證案例進行驗證并確定驗證結(jié)果；統(tǒng)計模塊504，用于在所述驗證結(jié)果與預(yù)設(shè)基準匹配時，將所述待驗證信息記錄為支持的交易屬性，所述預(yù)設(shè)基準是根據(jù)所述待驗證案例確定的?？蛇x地，所述所述獲取模塊501具體用于：根據(jù)交易模板和待驗證信息生成待驗證案例；所述待驗證信息包括交易報文類型、驗證的多方交易對象；根據(jù)所述交易報文類型，確定所述交易報文類型對應(yīng)的關(guān)聯(lián)要素；根據(jù)所述驗證的多方交易對象，確定驗證要素集；根據(jù)所述交易模板、所述關(guān)聯(lián)要素和所述驗證要素集確定所述待驗證案例?？蛇x地，所述處理模塊502具體用于：所述驗證的多方交易對象包括待驗證銀行卡的卡號；根據(jù)所述待驗證銀行卡的卡號、所述交易報文類型對應(yīng)的關(guān)聯(lián)要素的取值方式確定所述交易報文類型對應(yīng)的關(guān)聯(lián)要素的具體取值和所述驗證要素集的具體取值，其中，所述交易報文類型對應(yīng)的關(guān)聯(lián)要素的取值方式是根據(jù)預(yù)設(shè)規(guī)則確定的；將所述交易報文類型對應(yīng)的關(guān)聯(lián)要素的具體取值和所述驗證要素集的具體取值進行組裝生成所述驗證交易報文。可選地，所述驗證模塊503具體用于：將所述驗證交易報文發(fā)送至所述待驗證銀行卡的發(fā)卡行，以使所述待驗證銀行卡的發(fā)卡行對所述驗證交易報文進行處理并反饋驗證結(jié)果；接收所述待驗證銀行卡的發(fā)卡行反饋的驗證結(jié)果。可選地，所述統(tǒng)計模塊504還用于：所述根據(jù)所述驗證交易報文對所述待驗證案例進行驗證并確定驗證結(jié)果之后，在確定所述驗證結(jié)果與預(yù)設(shè)基準不匹配時，將所述待驗證信息記錄為不支持的交易屬性。本發(fā)明實施例，獲取待驗證案例，所述待驗證案例是根據(jù)交易模板和待驗證信息生成，然后根據(jù)所述待驗證案例生成驗證交易報文，根據(jù)所述驗證交易報文對所述待驗證案例進行驗證并確定驗證結(jié)果，最后在所述驗證結(jié)果與預(yù)設(shè)基準匹配時，將所述待驗證信息記錄為支持的交易屬性，所述預(yù)設(shè)基準是根據(jù)所述待驗證案例確定的。本發(fā)明實施例中根據(jù)交易模板和待驗證信息自動生成待驗證案例，同時對待驗證案例的執(zhí)行、驗證結(jié)果收集也進行了自動化設(shè)計，從而提高了交易驗證的速度，避免了人工收集和統(tǒng)計驗證結(jié)果帶來的出錯問題，降低了人力投入的成本。本領(lǐng)域內(nèi)的技術(shù)人員應(yīng)明白，本發(fā)明的實施例可提供為方法、或計算機程序產(chǎn)品。因此，本發(fā)明可采用完全硬件實施例、完全軟件實施例、或結(jié)合軟件和硬件方面的實施例的形式。而且，本發(fā)明可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(zhì)(包括但不限于磁盤存儲器、CD-ROM、光學(xué)存儲器等)上實施的計算機程序產(chǎn)品的形式。本發(fā)明是參照根據(jù)本發(fā)明實施例的方法、設(shè)備(系統(tǒng))、和計算機程序產(chǎn)品的流程圖和/或方框圖來描述的。應(yīng)理解可由計算機程序指令實現(xiàn)流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結(jié)合。可提供這些計算機程序指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數(shù)據(jù)處理設(shè)備的處理器以產(chǎn)生一個機器，使得通過計算機或其他可編程數(shù)據(jù)處理設(shè)備的處理器執(zhí)行的指令產(chǎn)生用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。這些計算機程序指令也可存儲在能引導(dǎo)計算機或其他可編程數(shù)據(jù)處理設(shè)備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產(chǎn)生包括指令裝置的制造品，該指令裝置實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。這些計算機程序指令也可裝載到計算機或其他可編程數(shù)據(jù)處理設(shè)備上，使得在計算機或其他可編程設(shè)備上執(zhí)行一系列操作步驟以產(chǎn)生計算機實現(xiàn)的處理，從而在計算機或其他可編程設(shè)備上執(zhí)行的指令提供用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。盡管已描述了本發(fā)明的優(yōu)選實施例，但本領(lǐng)域內(nèi)的技術(shù)人員一旦得知了基本創(chuàng)造性概念，則可對這些實施例作出另外的變更和修改。所以，所附權(quán)利要求意欲解釋為包括優(yōu)選實施例以及落入本發(fā)明范圍的所有變更和修改。顯然，本領(lǐng)域的技術(shù)人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動和變型在內(nèi)。當前第1頁1 2 3