本發(fā)明屬于支付技術應用領域，具體而言，本發(fā)明涉及一種多支付機構(gòu)條碼統(tǒng)碼支付方法和系統(tǒng)。

背景技術：

近年來，支付行業(yè)發(fā)展迅速，尤其是條碼支付市場快速發(fā)展。但由于各支付機構(gòu)的條碼標準自成體系、互不兼容，并且機構(gòu)間存在相互競爭關系，造成商戶受理和客戶使用的不便。在市場需求的催化下，外包服務商和部分銀行卡收單機構(gòu)推出了“聚合支付”服務，盡管能夠解決“一柜多碼”、“一柜多機”的問題，但也產(chǎn)生了更多更嚴重的新問題。如：“聚合支付”機構(gòu)開展商戶審核、經(jīng)手商戶資金等支付機構(gòu)核心業(yè)務時，易存在截留客戶資金、采集、留存特約商戶和消費者的敏感信息等風險情況，造成各參與方業(yè)務邊界混亂、職責定位不清；支付機構(gòu)對商戶缺乏直接、有效的管理，削弱了交易風險的控制力；游離監(jiān)管之外的“聚合支付”機構(gòu)野蠻生長，導致市場亂象叢生等。

在此背景下，網(wǎng)聯(lián)提出建設條碼服務平臺，制定條碼業(yè)務標準，逐步規(guī)范條碼服務市場。達到讓客戶便捷、合規(guī)、安全的使用條碼服務的行業(yè)目標。

技術實現(xiàn)要素：

本發(fā)明的目的在于提供一種多支付機構(gòu)條碼統(tǒng)碼支付方法和系統(tǒng)，以至少解決現(xiàn)有技術中存在的沒有統(tǒng)一的條碼業(yè)務標準，條碼服務市場不規(guī)范，客戶在使用條碼服務時不便捷的技術問題。

為了解決上述問題，本發(fā)明一方面提供一種多支付機構(gòu)條碼統(tǒng)碼支付方法，其包括：商戶側(cè)獲取統(tǒng)碼步驟，商戶側(cè)發(fā)送條碼信息請求以獲得商戶側(cè)條碼統(tǒng)碼，所述商戶側(cè)條碼統(tǒng)碼根據(jù)條碼信息生成，所述條碼信息表征與支付機構(gòu)簽約的商戶信息；交易步驟，客戶通過移動終端上的客戶app掃描所述商戶側(cè)獲取統(tǒng)碼步驟中獲取的商戶側(cè)條碼統(tǒng)碼以向所述支付機構(gòu)發(fā)送交易請求，若所述交易請求中涉及所述支付機構(gòu)的支付賬戶，所述支付機構(gòu)自行處理得到交易結(jié)果；若所述交易請求中涉及所述支付機構(gòu)的綁定賬戶，所述支付機構(gòu)則向支付清算平臺發(fā)送交易請求以得到交易結(jié)果；其中所述支付機構(gòu)為所述客戶app所屬的支付機構(gòu)。

在如上所述的方法中，優(yōu)選地，所述商戶側(cè)獲取統(tǒng)碼步驟包括：條碼信息生成子步驟，商戶側(cè)以與所述支付機構(gòu)簽約的形式發(fā)送靜態(tài)的條碼信息請求，條碼系統(tǒng)根據(jù)所述支付機構(gòu)報送的簽約商戶信息生成條碼信息；統(tǒng)碼生成子步驟，所述支付機構(gòu)根據(jù)所述條碼系統(tǒng)返回的條碼信息生成靜態(tài)的商戶側(cè)條碼統(tǒng)碼以供客戶掃描向簽約商戶付款。

在如上所述的方法中，優(yōu)選地，所述商戶側(cè)獲取統(tǒng)碼步驟包括：條碼信息生成子步驟，所述條碼系統(tǒng)在接收到商戶側(cè)以商戶顯碼終端發(fā)送的動態(tài)的條碼信息請求后，根據(jù)所述支付機構(gòu)預先報送的與所述商戶顯碼終端對應的簽約商戶信息生成條碼信息；統(tǒng)碼生成子步驟，所述商戶顯碼終端根據(jù)所述條碼系統(tǒng)返回的條碼信息生成動態(tài)的商戶側(cè)條碼統(tǒng)碼以供客戶掃描向簽約商戶付款。

在如上所述的方法中，優(yōu)選地，所述商戶側(cè)獲取統(tǒng)碼步驟包括：商戶顯碼終端根據(jù)預先存儲的條碼信息生成動態(tài)的商戶側(cè)條碼統(tǒng)碼以供客戶掃描向簽約商戶付款，其中所述條碼信息由商戶側(cè)布放的支付機構(gòu)獲取。

在如上所述的方法中，優(yōu)選地，所述商戶側(cè)獲取統(tǒng)碼步驟包括：條碼信息生成子步驟，所述支付機構(gòu)在接收到商戶側(cè)以商戶顯碼終端發(fā)送的動態(tài)的條碼信息請求后，根據(jù)條碼信息規(guī)則生成條碼信息發(fā)送至所述商戶顯碼終端，所述條碼信息規(guī)則由條碼系統(tǒng)發(fā)送給所述支付機構(gòu)；統(tǒng)碼生成子步驟，所述商戶顯碼終端根據(jù)所述支付機構(gòu)返回的條碼信息生成動態(tài)的商戶側(cè)條碼統(tǒng)碼以供客戶掃描向簽約商戶付款。

另一方面，本發(fā)明提供了一種多支付機構(gòu)條碼統(tǒng)碼支付系統(tǒng)，其包括：條碼系統(tǒng)、支付機構(gòu)、客戶app和支付清算平臺；所述條碼系統(tǒng)生成條碼信息，所述條碼信息表征與所述支付機構(gòu)簽約的商戶信息；所述支付機構(gòu)根據(jù)所述條碼信息生成商戶側(cè)條碼統(tǒng)碼并發(fā)送給商戶以供客戶app掃描、發(fā)送交易請求，所述支付機構(gòu)對所述交易請求進行處理，若所述交易請求中涉及所述支付機構(gòu)的支付賬戶，所述支付機構(gòu)自行處理得到交易結(jié)果；若所述交易請求中涉及所述支付機構(gòu)的綁定賬戶，所述支付機構(gòu)則向所述支付清算平臺發(fā)送交易請求以得到交易結(jié)果；其中，所述支付機構(gòu)為所述客戶app所屬的支付機構(gòu)。

本發(fā)明還提供了一種多支付機構(gòu)條碼統(tǒng)碼支付系統(tǒng)，其包括：條碼系統(tǒng)、支付機構(gòu)、商戶顯碼終端和客戶app；所述條碼系統(tǒng)在接收到商戶側(cè)以所述商戶顯碼終端發(fā)送的動態(tài)的條碼信息請求后，根據(jù)所述支付機構(gòu)預先報送的與所述商戶顯碼終端對應的簽約商戶信息生成條碼信息，所述商戶顯碼終端根據(jù)所述條碼系統(tǒng)返回的條碼信息生成動態(tài)的商戶側(cè)條碼統(tǒng)碼以供客戶掃描向簽約商戶付款；或所述商戶顯碼終端根據(jù)預先存儲的條碼信息生成動態(tài)的商戶側(cè)條碼統(tǒng)碼以供客戶掃描向簽約商戶付款，其中所述條碼信息由商戶側(cè)布放的支付機構(gòu)獲?。换蛩鲋Ц稒C構(gòu)在接收到商戶側(cè)以所述商戶顯碼終端發(fā)送的動態(tài)的條碼信息請求后，根據(jù)條碼信息規(guī)則生成條碼信息發(fā)送至所述商戶顯碼終端，所述條碼信息規(guī)則由條碼系統(tǒng)發(fā)送給所述支付機構(gòu)，所述商戶顯碼終端根據(jù)所述支付機構(gòu)返回的條碼信息生成動態(tài)的商戶側(cè)條碼統(tǒng)碼以供客戶掃描向簽約商戶付款；所述支付機構(gòu)對所述客戶app掃描后發(fā)送的交易請求進行處理，若所述交易請求中涉及所述支付機構(gòu)的支付賬戶，所述支付機構(gòu)自行處理得到交易結(jié)果；若所述交易請求中涉及所述支付機構(gòu)的綁定賬戶，所述支付機構(gòu)則向所述支付清算平臺發(fā)送交易請求以得到交易結(jié)果，其中，所述支付機構(gòu)為所述客戶app所屬的支付機構(gòu)。

又一方面，本發(fā)明提供了一種多支付機構(gòu)條碼統(tǒng)碼支付方法，其包括：客戶側(cè)獲取統(tǒng)碼步驟，客戶通過客戶app向所述客戶app所屬的支付機構(gòu)發(fā)送條碼請求以獲得客戶側(cè)條碼統(tǒng)碼；交易步驟，商戶側(cè)的商戶掃碼終端掃描所述客戶側(cè)獲取統(tǒng)碼步驟中獲取的客戶側(cè)條碼統(tǒng)碼以向所述支付機構(gòu)發(fā)送交易請求，若所述交易請求中涉及所述支付機構(gòu)的支付賬戶，所述支付機構(gòu)自行處理得到交易結(jié)果；若所述交易請求中涉及所述支付機構(gòu)的綁定賬戶，所述支付機構(gòu)則向支付清算平臺發(fā)送交易請求以得到交易結(jié)果。

在如上所述的方法中，優(yōu)選地，所述交易步驟中向所述支付機構(gòu)發(fā)送交易請求，具體包括：所述商戶掃碼終端向條碼系統(tǒng)發(fā)送交易請求，所述條碼系統(tǒng)請求將所述交易請求轉(zhuǎn)發(fā)至所述支付機構(gòu)。

在如上所述的方法中，優(yōu)選地，所述交易步驟中向所述支付機構(gòu)發(fā)送交易請求，具體包括：所述商戶掃碼終端經(jīng)手動選擇或自動識別直接向所述支付機構(gòu)發(fā)送所述交易請求。

再另一方面，本發(fā)明提供了一種多支付機構(gòu)條碼統(tǒng)碼支付系統(tǒng)，其包括：客戶app、商戶掃碼終端、支付機構(gòu)和支付清算平臺；客戶通過所述客戶app向所述客戶app所屬的支付機構(gòu)發(fā)送條碼請求以獲得客戶側(cè)條碼統(tǒng)碼；商戶側(cè)的商戶掃碼終端掃描所述客戶側(cè)條碼統(tǒng)碼以向所述條碼系統(tǒng)發(fā)送交易請求，所述二位碼系統(tǒng)將所述交易請求轉(zhuǎn)送至所述支付機構(gòu)，若所述交易請求中涉及所述支付機構(gòu)的支付賬戶，所述支付機構(gòu)自行處理得到交易結(jié)果；若所述交易請求中涉及所述支付機構(gòu)的綁定賬戶，所述支付機構(gòu)則向所述支付清算平臺發(fā)送交易請求以得到交易結(jié)果。

本發(fā)明還提供了一種多支付機構(gòu)條碼統(tǒng)碼支付系統(tǒng)，其包括：客戶app、商戶掃碼終端、支付機構(gòu)、條碼系統(tǒng)和支付清算平臺；客戶通過所述客戶app向所述客戶app所屬的支付機構(gòu)發(fā)送條碼請求以獲得客戶側(cè)條碼統(tǒng)碼；商戶側(cè)的商戶掃碼終端經(jīng)手工選擇識別所述app所屬的支付機構(gòu)，并掃描所述客戶側(cè)條碼統(tǒng)碼，直接向所述支付機構(gòu)發(fā)送交易請求；或商戶側(cè)的商戶掃碼終端掃描所述客戶側(cè)條碼統(tǒng)碼并自動識別所述app所屬的支付機構(gòu)，直接向所述支付機構(gòu)發(fā)送交易請求；若所述交易請求中涉及所述支付機構(gòu)的支付賬戶，所述支付機構(gòu)自行處理得到交易結(jié)果；若所述交易請求中涉及所述支付機構(gòu)的綁定賬戶，所述支付機構(gòu)則向所述支付清算平臺發(fā)送交易請求以得到交易結(jié)果。

分析可知，與現(xiàn)有技術相比，本發(fā)明的優(yōu)點和有益效果在于：

(1)協(xié)助監(jiān)管部門掌握全面、準確的條碼支付業(yè)務及風險情況，為監(jiān)管政策提供數(shù)據(jù)支持和落地抓手，促進條碼支付市場健康有序發(fā)展。

(2)厘清各參與方業(yè)務邊界是撥亂方正的重點。重構(gòu)支付機構(gòu)與外包服務商、支付機構(gòu)之間的業(yè)務關系，明確商戶準入管理、交易信息傳輸?shù)雀鞣矫嬉蟆?/p>

(3)通過共享問題商戶、虛假商戶申請人和違規(guī)外包服務商等風險信息，對市場參與者去蕪存菁，保障合規(guī)機構(gòu)的利益。

(4)為支付機構(gòu)提供統(tǒng)一、規(guī)范、安全的條碼信息生成及轉(zhuǎn)接服務，防止違規(guī)信息聚合、交易資金二清，并解決商戶“一柜多碼”、“一柜多機”的受理痛點問題。

附圖說明

圖1為本發(fā)明實施例二提供的一種多支付機構(gòu)條碼統(tǒng)碼支付方法；

圖2為本發(fā)明實施例三提供的一種多支付機構(gòu)條碼統(tǒng)碼支付方法；

圖3為本發(fā)明實施例四提供的一種多支付機構(gòu)條碼統(tǒng)碼支付方法；

圖4為本發(fā)明實施例五提供的一種多支付機構(gòu)條碼統(tǒng)碼支付方法；

圖5為本發(fā)明實施例六提供的一種多支付機構(gòu)條碼統(tǒng)碼支付方法；

圖6為本發(fā)明實施例七提供的一種多支付機構(gòu)條碼統(tǒng)碼支付方法；

圖7為本發(fā)明實施例八提供的一種多支付機構(gòu)條碼統(tǒng)碼支付方法。

具體實施方式

下面結(jié)合附圖和具體實施方式對本發(fā)明做進一步詳細說明。

實施例一

本發(fā)明提供了一種多支付機構(gòu)條碼統(tǒng)碼支付方法，其包括：

商戶側(cè)獲取統(tǒng)碼步驟，商戶側(cè)發(fā)送條碼信息請求以獲得商戶側(cè)條碼統(tǒng)碼，商戶側(cè)條碼統(tǒng)碼根據(jù)條碼信息生成，條碼信息表征與支付機構(gòu)簽約的商戶信息；

交易步驟，客戶通過移動終端上的客戶app掃描商戶側(cè)獲取統(tǒng)碼步驟中獲取的商戶側(cè)條碼統(tǒng)碼以向支付機構(gòu)發(fā)送交易請求，若交易請求中涉及支付機構(gòu)的支付賬戶，支付機構(gòu)自行處理得到交易結(jié)果；若交易請求中涉及支付機構(gòu)的綁定賬戶，支付機構(gòu)則向支付清算平臺發(fā)送交易請求以得到交易結(jié)果；其中支付機構(gòu)為客戶app所屬的支付機構(gòu)，其中本文中的支付清算平臺也可稱為網(wǎng)絡支付清算平臺，簡稱網(wǎng)聯(lián)。

實施例二

參見圖1，基于上述實施例一的內(nèi)容，本實施例對商戶側(cè)獲取統(tǒng)碼步驟和交易步驟進行詳細說明。

商戶側(cè)獲取統(tǒng)碼步驟包括：

條碼信息生成子步驟，商戶側(cè)以與支付機構(gòu)簽約的形式發(fā)送靜態(tài)的條碼信息請求，條碼系統(tǒng)根據(jù)支付機構(gòu)報送的簽約商戶信息生成條碼信息；統(tǒng)碼生成子步驟，支付機構(gòu)根據(jù)條碼系統(tǒng)返回的條碼信息生成靜態(tài)的商戶側(cè)條碼統(tǒng)碼以供客戶掃描向簽約商戶付款。即支付機構(gòu)為條碼生成方，常見的支付機構(gòu)如支付寶、財付通、百付寶，其常見支付產(chǎn)品分別有支付寶、微信支付、百度錢包等。本文中的條碼系統(tǒng)也可稱為網(wǎng)聯(lián)條碼系統(tǒng)。

具體地，條碼系統(tǒng)根據(jù)支付機構(gòu)報送的簽約商戶信息生成條碼信息。具體而言，商戶與支付機構(gòu)簽約條碼支付業(yè)務的請求，并將商戶信息提供給支付機構(gòu)，該商戶信息包括但不限于：名稱、身份識別碼(如統(tǒng)一社會信用代碼、組織機構(gòu)代碼)、銀行賬號。提供方式可以是面交、郵寄，還可以是在支付機構(gòu)開放的簽約平臺上傳，本實施例對此不進行限定。支付機構(gòu)審核完后，簽約登記，并根據(jù)商戶信息生成簽約客戶信息，簽約商戶信息包含但不限于法人、營業(yè)執(zhí)照信息、法定代表人信息、商戶實際經(jīng)營情況。然后將簽約商戶信息報送給條碼系統(tǒng)，條碼系統(tǒng)根據(jù)簽約商戶信息生成表征簽約商戶信息的字符串，字符串根據(jù)商戶實際信息按照網(wǎng)聯(lián)編碼規(guī)則加密生成，該字符串具有統(tǒng)一性和唯一性，即每個簽約商戶信息對應一個字符串，一個字符串對應一個簽約商戶信息，換言之“一柜一碼”。

支付機構(gòu)根據(jù)條碼系統(tǒng)返回的條碼信息生成靜態(tài)的商戶側(cè)條碼以供客戶掃描向簽約商戶付款。具體而言，支付機構(gòu)根據(jù)條碼系統(tǒng)返回的條碼信息生成商戶側(cè)條碼統(tǒng)碼，該條碼為靜態(tài)條碼(或稱商戶靜態(tài)碼)，在商戶信息不發(fā)生變化的情況下，其不隨時間發(fā)生更新，并將商戶側(cè)條碼統(tǒng)碼提供給商戶收款使用。提供的方式可以是支付機構(gòu)在其簽約平臺上上傳有商戶側(cè)條碼統(tǒng)碼，然后商戶下載，打印；還可以是郵寄，本實施例對此不進行限定?？蛻舾犊顣r，通過操作其持有的移動終端上安裝的支付機構(gòu)客戶app掃描商戶布放的商戶側(cè)條碼統(tǒng)碼實現(xiàn)向商戶付款。與商戶簽約的支付機構(gòu)(或稱商戶側(cè)支付機構(gòu))中有與客戶使用的客戶app所屬的支付機構(gòu)(或稱客戶側(cè)支付機構(gòu))為同一支付機構(gòu)的支付機構(gòu)。

交易步驟：

客戶通過其持有的移動終端上的客戶app掃描商戶布放的靜態(tài)的商戶側(cè)條碼統(tǒng)碼，客戶app向其所屬支付機構(gòu)發(fā)送交易請求，支付機構(gòu)進行交易處理，若交易資金來源于支付賬戶，如微信錢包中的零錢，支付寶中的余額等，則由支付機構(gòu)從客戶支付賬戶中扣款；若交易請求中涉及銀行賬戶，如微信錢包綁定的工商銀行銀行卡，則向網(wǎng)聯(lián)的支付清算平臺發(fā)送交易請求，支付清算平臺清算后將交易結(jié)果返回給支付機構(gòu)，支付機構(gòu)將交易結(jié)果通知給客戶和商戶，其中銀行賬戶可以稱為綁定賬戶。

實施例三

參見圖2，基于上述實施例一的內(nèi)容，本實施例對商戶側(cè)獲取統(tǒng)碼步驟和交易步驟進行詳細說明。

商戶側(cè)獲取統(tǒng)碼步驟包括：條碼信息生成子步驟，條碼系統(tǒng)在接收到商戶側(cè)以商戶顯碼終端發(fā)送的動態(tài)的條碼信息請求后，根據(jù)支付機構(gòu)預先報送的與商戶顯碼終端對應的簽約商戶信息生成條碼信息；統(tǒng)碼生成子步驟，商戶顯碼終端根據(jù)條碼系統(tǒng)返回的條碼信息生成動態(tài)的商戶側(cè)條碼統(tǒng)碼以供客戶掃描向簽約商戶付款，其中，動態(tài)條碼請求包括：簽約商戶信息和顯碼終端登記信息，條碼系統(tǒng)根據(jù)其獲取的簽約商戶信息和顯碼終端登記信息生成條碼信息。

關于簽約商戶信息的獲取可參見上述實施例一中的相關內(nèi)容描述。其中，在商戶簽約后，支付機構(gòu)或其拓展代理商為商戶布放顯碼終端，以在交易過程中顯示商戶側(cè)條碼統(tǒng)碼的設備。該顯碼終端可為商戶收銀機、單獨的銀行卡業(yè)務受理設備，本實施例對此不進行限定。

交易步驟：客戶通過其持有的移動終端上的客戶app掃描商戶布放的商戶顯碼終端顯示的動態(tài)的商戶側(cè)條碼統(tǒng)碼，客戶app向其所屬支付機構(gòu)發(fā)送交易處理請求，支付機構(gòu)校驗客戶賬戶信息，并根據(jù)條碼信息進行交易處理。若交易請求中涉及支付機構(gòu)支付賬戶，如微信錢包中的零錢，支付寶中的余額等，則由支付機構(gòu)從客戶支付賬戶中扣款；客戶若交易請求中涉及銀行賬戶，如微信錢包綁定的工商銀行銀行卡，則向網(wǎng)聯(lián)的支付清算平臺發(fā)送交易請求，支付清算平臺清算后將交易結(jié)果返回給支付機構(gòu)，支付機構(gòu)將交易結(jié)果通知給客戶app以通知客戶和條碼系統(tǒng)，條碼系統(tǒng)在將交易結(jié)果通知給顯碼終端以通知給商戶，其中銀行賬戶可以稱為綁定賬戶。

實施例四

參見圖3，基于上述實施例一的內(nèi)容，本實施例對商戶側(cè)獲取統(tǒng)碼步驟和交易步驟進行詳細說明。

商戶側(cè)獲取統(tǒng)碼步驟：商戶顯碼終端根據(jù)預先存儲的條碼信息生成動態(tài)的商戶側(cè)條碼統(tǒng)碼以供客戶掃描向簽約商戶付款，其中條碼信息由商戶側(cè)布放的支付機構(gòu)獲取。

具體地，在簽約商戶登記環(huán)節(jié)，商戶顯碼終端布放的支付機構(gòu)經(jīng)條碼系統(tǒng)獲取可生成商戶側(cè)條碼統(tǒng)碼的加簽字符串，在為商戶安裝顯碼終端機具前，根據(jù)網(wǎng)聯(lián)條碼生成規(guī)則灌裝至終端機具，其中，支付機構(gòu)獲取條碼信息或加簽字符串的方式詳見實施二中的相關內(nèi)容描述，此處不再一一贅述。

交易步驟，客戶通過其持有的移動終端上的支付機構(gòu)客戶app掃描商戶布放的商戶顯碼終端顯示的動態(tài)的商戶側(cè)條碼統(tǒng)碼，客戶app向其所屬支付機構(gòu)發(fā)送交易請求，支付機構(gòu)進行交易處理，如微信錢包中的零錢，支付寶中的余額等，則由支付機構(gòu)從客戶支付賬戶中扣款；若交易請求中涉及銀行賬戶，如微信錢包綁定的工商銀行銀行卡，則向網(wǎng)聯(lián)的支付清算平臺發(fā)送交易請求，支付清算平臺清算后將交易結(jié)果返回給支付機構(gòu)，支付機構(gòu)將交易結(jié)果通知給客戶客戶app和商戶。

實施例五

參見圖4，基于上述實施例一的內(nèi)容，本實施例對商戶側(cè)獲取統(tǒng)碼步驟和交易步驟進行詳細說明。

商戶側(cè)獲取統(tǒng)碼步驟包括：條碼信息生成子步驟，支付機構(gòu)在接收到商戶側(cè)以商戶顯碼終端發(fā)送的動態(tài)的條碼信息請求后，將預先存儲的條碼信息發(fā)送至商戶顯碼終端，條碼信息由條碼系統(tǒng)根據(jù)支付機構(gòu)報送的簽約商戶信息生成，并發(fā)送給支付機構(gòu)；統(tǒng)碼生成子步驟，商戶顯碼終端根據(jù)支付機構(gòu)返回的條碼信息生成動態(tài)的商戶側(cè)條碼統(tǒng)碼以供客戶掃描向簽約商戶付款。

具體地，支付機構(gòu)按照網(wǎng)聯(lián)條碼規(guī)范要求建立相應的條碼識別與讀取規(guī)范，網(wǎng)聯(lián)條碼規(guī)范要求也稱條碼信息規(guī)則，該條碼信息規(guī)則可由條碼系統(tǒng)發(fā)送至支付機構(gòu)。商戶在商戶側(cè)顯碼終端上選擇支付機構(gòu)，向支付機構(gòu)發(fā)送動態(tài)條碼請求，支付機構(gòu)返回根據(jù)條碼信息規(guī)則生成的條碼信息。顯碼終端根據(jù)條碼信息生成動態(tài)條碼以供客戶掃描向簽約商戶付款。其中，支付機構(gòu)獲取條碼信息的方式詳見實施二中的相關內(nèi)容描述，此處不再一一贅述。

該方案尤其適用于線上商戶、由簽約多家支付機構(gòu)的外包服務商拓展維護的商戶，其應用場景可以為：比如在淘寶買東西，跳轉(zhuǎn)到支付寶界面的時候，有時候輸入交易密碼，如果你在網(wǎng)吧等不安全的支付環(huán)境時，可以選擇通過支付寶客戶app選擇掃描電腦顯示屏顯示的商戶側(cè)條碼統(tǒng)碼實現(xiàn)支付(電腦顯示屏即為商戶側(cè)的商戶顯碼終端)。

交易步驟，客戶通過其持有的移動終端上的支付機構(gòu)客戶app掃描商戶布放的顯碼終端顯示的動態(tài)條碼以處理動態(tài)條碼表征的信息，客戶app向其所屬支付機構(gòu)發(fā)送交易請求，支付機構(gòu)進行交易處理，若交易資金來源于支付賬戶，如微信錢包中的零錢，支付寶中的余額等，則由支付機構(gòu)從客戶支付賬戶中扣款；若交易請求中涉及銀行賬戶，如微信錢包綁定的工商銀行銀行卡，則向網(wǎng)聯(lián)的支付清算平臺發(fā)送交易請求，支付清算平臺清算后將交易結(jié)果返回給支付機構(gòu)，支付機構(gòu)將交易結(jié)果通知給客戶和商戶。條碼系統(tǒng)對商戶和商戶顯碼終端進行事后校驗。

實施例六

本發(fā)明還提供了另一種多支付機構(gòu)條碼統(tǒng)碼支付方法，其包括：

客戶側(cè)獲取統(tǒng)碼步驟，客戶通過客戶app向客戶app所屬的支付機構(gòu)發(fā)送條碼請求以獲得客戶側(cè)條碼統(tǒng)碼；

交易步驟，商戶側(cè)的商戶掃碼終端掃描客戶側(cè)獲取統(tǒng)碼步驟中獲取的客戶側(cè)條碼統(tǒng)碼以向支付機構(gòu)發(fā)送交易請求，若交易請求中涉及支付機構(gòu)的支付賬戶，支付機構(gòu)自行處理得到交易結(jié)果；若交易請求中涉及支付機構(gòu)的綁定賬戶，支付機構(gòu)則向支付清算平臺發(fā)送交易請求以得到交易結(jié)果。

實施例七

參見圖5，基于上述實施例六的內(nèi)容，本實施例對客戶側(cè)獲取統(tǒng)碼步驟和交易步驟進行詳細說明。

支付機構(gòu)在其相關條碼生成規(guī)范和流程的基礎上，添加網(wǎng)聯(lián)標識和支付機構(gòu)代碼，生成動態(tài)的客戶側(cè)條碼統(tǒng)碼(或稱動態(tài)付款碼)?？蛻粼诟犊钋?，打開客戶app付款碼界面提供商戶掃碼終端進行掃碼。

商戶通過掃碼終端讀取客戶app生成的條碼信息后發(fā)送至條碼系統(tǒng)，由條碼系統(tǒng)在校驗商戶及終端信息后，根據(jù)機構(gòu)代碼路由轉(zhuǎn)接至客戶app所屬支付機構(gòu)進行交易處理。若所述交易請求中涉及支付機構(gòu)的支付賬戶，如支付金額來自于微信錢包中的零錢，支付寶中的余額等，則由支付機構(gòu)從客戶支付賬戶中扣款；若交易請求中涉及銀行賬戶，如微信錢包綁定的工商銀行銀行卡，則向網(wǎng)聯(lián)的支付清算平臺發(fā)送交易請求，支付清算平臺清算后將交易結(jié)果返回給支付機構(gòu)，支付機構(gòu)將交易結(jié)果通知給客戶和商戶。

實施例八

參見圖6，基于上述實施例六的內(nèi)容，本實施例對交易步驟進行詳細說明，本實施例中關于客戶側(cè)獲取統(tǒng)碼步驟的說明可參見上述實施例六的相關內(nèi)容描述，此處不再一一贅述。

在掃碼終端手工選擇支付機構(gòu)，并通過掃碼終端讀取客戶app生成的條碼信息后生成交易請求并發(fā)送至支付機構(gòu)，支付機構(gòu)進行交易處理，該條碼信息包括但不限于客戶賬號，app所屬支付機構(gòu)。若所述交易請求中涉及支付機構(gòu)的支付賬戶，如支付金額來自于微信錢包中的零錢，支付寶中的余額等，則由支付機構(gòu)從客戶支付賬戶中扣款；若交易請求中涉及銀行賬戶，如微信錢包綁定的工商銀行銀行卡，則向網(wǎng)聯(lián)的支付清算平臺發(fā)送交易請求，支付清算平臺清算后將交易結(jié)果返回給支付機構(gòu)，支付機構(gòu)將交易結(jié)果通知給客戶客戶app和條碼系統(tǒng)，條碼系統(tǒng)向商戶通知交易結(jié)果。

在其他的實施例中，參見圖7，交易請求的流程還可以為：商戶通過掃碼終端讀取客戶客戶app生成的條碼信息，并自動識別支付機構(gòu)，然后生成交易請求并直接發(fā)送至支付機構(gòu)。

實施例九

基于上述實施例一～二的內(nèi)容，本發(fā)明實施例提供了一種多支付機構(gòu)條碼統(tǒng)碼支付系統(tǒng)，其包括：條碼系統(tǒng)、支付機構(gòu)、客戶app和支付清算平臺；條碼系統(tǒng)生成條碼信息，條碼信息表征與支付機構(gòu)簽約的商戶信息；支付機構(gòu)根據(jù)條碼信息生成商戶側(cè)條碼統(tǒng)碼并發(fā)送給商戶以供客戶app掃描、發(fā)送交易請求，支付機構(gòu)對交易請求進行處理，若交易請求中涉及支付機構(gòu)的支付賬戶，支付機構(gòu)自行處理得到交易結(jié)果；若交易請求中涉及支付機構(gòu)的綁定賬戶，支付機構(gòu)則向支付清算平臺發(fā)送交易請求以得到交易結(jié)果；其中，支付機構(gòu)為客戶app所屬的支付機構(gòu)。關于條碼系統(tǒng)、支付機構(gòu)、客戶app和支付清算平臺各自執(zhí)行的動作請參見上述實施例一～二的相關內(nèi)容描述，此處不再一一贅述。

實施例十

基于上述實施例一、三～五的內(nèi)容，本發(fā)明實施例提供了一種多支付機構(gòu)條碼統(tǒng)碼支付系統(tǒng)，其包括：條碼系統(tǒng)、支付機構(gòu)、商戶顯碼終端和客戶app；條碼系統(tǒng)在接收到商戶側(cè)以商戶顯碼終端發(fā)送的動態(tài)的條碼信息請求后，根據(jù)支付機構(gòu)預先報送的與商戶顯碼終端對應的簽約商戶信息生成條碼信息，商戶顯碼終端根據(jù)條碼系統(tǒng)返回的條碼信息生成動態(tài)的商戶側(cè)條碼統(tǒng)碼以供客戶掃描向簽約商戶付款；或商戶顯碼終端根據(jù)預先存儲的條碼信息生成動態(tài)的商戶側(cè)條碼統(tǒng)碼以供客戶掃描向簽約商戶付款，其中條碼信息由商戶側(cè)布放的支付機構(gòu)獲??；或支付機構(gòu)在接收到商戶側(cè)以商戶顯碼終端發(fā)送的動態(tài)的條碼信息請求后，將預先存儲的條碼信息發(fā)送至商戶顯碼終端，條碼信息由條碼系統(tǒng)根據(jù)支付機構(gòu)報送的簽約商戶信息生成，并發(fā)送給支付機構(gòu)，商戶顯碼終端根據(jù)支付機構(gòu)返回的條碼信息生成動態(tài)的商戶側(cè)條碼統(tǒng)碼以供客戶掃描向簽約商戶付款；支付機構(gòu)對客戶app掃描后發(fā)送的交易請求進行處理，若交易請求中涉及支付機構(gòu)的支付賬戶，支付機構(gòu)自行處理得到交易結(jié)果；若交易請求中涉及支付機構(gòu)的綁定賬戶，支付機構(gòu)則向支付清算平臺發(fā)送交易請求以得到交易結(jié)果，其中，支付機構(gòu)為客戶app所屬的支付機構(gòu)。關于條碼系統(tǒng)、支付機構(gòu)、客戶app、商戶顯碼終端和支付清算平臺各自執(zhí)行的動作請參見上述實施例一、三～五的相關內(nèi)容描述，此處不再一一贅述。

實施例十一

基于上述實施例六～七的內(nèi)容，本發(fā)明實施例提供了一種多支付機構(gòu)條碼統(tǒng)碼支付系統(tǒng)，其包括：客戶app、商戶掃碼終端、支付機構(gòu)和支付清算平臺；客戶通過客戶app向其所屬的支付機構(gòu)發(fā)送條碼請求以獲得客戶側(cè)條碼統(tǒng)碼；商戶側(cè)的商戶掃碼終端掃描客戶側(cè)條碼統(tǒng)碼以向條碼系統(tǒng)發(fā)送交易請求，二位碼系統(tǒng)將交易請求轉(zhuǎn)送至支付機構(gòu)，若交易請求中涉及支付機構(gòu)的支付賬戶，支付機構(gòu)自行處理得到交易結(jié)果；若交易請求中涉及支付機構(gòu)的綁定賬戶，支付機構(gòu)則向支付清算平臺發(fā)送交易請求以得到交易結(jié)果。關于客戶app、商戶掃碼終端、支付機構(gòu)和支付清算平臺各自執(zhí)行的動作請參見上述實施例六、八的相關內(nèi)容描述，此處不再一一贅述。

實施例十二

基于上述實施例六～七的內(nèi)容，本發(fā)明實施例提供了一種多支付機構(gòu)條碼統(tǒng)碼支付系統(tǒng)，其包括：客戶app、商戶掃碼終端、支付機構(gòu)、條碼系統(tǒng)和支付清算平臺；客戶通過客戶app向其所屬的支付機構(gòu)發(fā)送條碼請求以獲得客戶側(cè)條碼統(tǒng)碼；商戶側(cè)的商戶掃碼終端經(jīng)手工選擇識別app所屬的支付機構(gòu)，并掃描客戶側(cè)條碼統(tǒng)碼，直接向支付機構(gòu)發(fā)送交易請求；或商戶側(cè)的商戶掃碼終端掃描客戶側(cè)條碼統(tǒng)碼并自動識別app所屬的支付機構(gòu)，直接向支付機構(gòu)發(fā)送交易請求；若交易請求中涉及支付機構(gòu)的支付賬戶，支付機構(gòu)自行處理得到交易結(jié)果；若交易請求中涉及支付機構(gòu)的綁定賬戶，支付機構(gòu)則向支付清算平臺發(fā)送交易請求以得到交易結(jié)果。關于客戶app、商戶掃碼終端、支付機構(gòu)和支付清算平臺各自執(zhí)行的動作請參見上述實施例六～七的相關內(nèi)容描述，此處不再一一贅述。

需要說明的是：

本著“對等開放、互利共贏”的原則，將成員機構(gòu)作為重要合作伙伴。共同推進線下線上渠道業(yè)務合作、電子支付業(yè)務創(chuàng)新發(fā)展、維護商戶資源和信用體系共享

分析可知，與現(xiàn)有技術相比，本發(fā)明的優(yōu)點和有益效果在于：

(1)協(xié)助監(jiān)管部門掌握全面、準確的條碼支付業(yè)務及風險情況，為監(jiān)管政策提供數(shù)據(jù)支持和落地抓手，促進條碼支付市場健康有序發(fā)展。

(2)厘清各參與方業(yè)務邊界是撥亂方正的重點。重構(gòu)支付機構(gòu)與外包服務商、支付機構(gòu)之間的業(yè)務關系，明確商戶準入管理、交易信息傳輸?shù)雀鞣矫嬉蟆?/p>

(3)通過共享問題商戶、虛假商戶申請人和違規(guī)外包服務商等風險信息，對市場參與者去蕪存菁，保障合規(guī)機構(gòu)的利益。

(4)為支付機構(gòu)提供統(tǒng)一、規(guī)范、安全的條碼信息生成及轉(zhuǎn)接服務，防止違規(guī)信息聚合、交易資金二清，并解決商戶“一柜多碼”、“一柜多機”的受理痛點問題。

由技術常識可知，本發(fā)明可以通過其它的不脫離其精神實質(zhì)或必要特征的實施方案來實現(xiàn)。因此，上述公開的實施方案，就各方面而言，都只是舉例說明，并不是僅有的。所有在本發(fā)明范圍內(nèi)或在等同于本發(fā)明的范圍內(nèi)的改變均被本發(fā)明包含。