本發(fā)明屬于智能收款技術(shù)領(lǐng)域，尤其涉及一種智能跨行收款系統(tǒng)及方法。

背景技術(shù)：

目前境內(nèi)人民幣收款時，如果收方和付方在不同的銀行開戶后，通過跨行收款渠道實現(xiàn)收款的過程中，付方開戶銀行為了避免自身存款的流失，關(guān)閉了某些特定的收款渠道，導(dǎo)致收方不能通過特定的渠道從付方賬號中收款。為了解決這一技術(shù)問題，現(xiàn)有技術(shù)中采用的技術(shù)方案是收方與多個銀行合作，采用多個銀行提供的收款渠道從付方賬號中收款。

但是，當(dāng)采用收方與多個銀行合作這一方式以實現(xiàn)從付方賬號收款時，若付方為多個，例如有線電視公司從多個開通有線電視的家庭中收取有線電視費用時，付方為多個家庭，有線電視公司需要通過多個銀行共同完成對所有家庭有線電視費用的收取，導(dǎo)致收方的操作復(fù)雜且占用資源多。

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

有鑒于此，本發(fā)明的目的在于提供一種跨行收款系統(tǒng)及方法，用于解決現(xiàn)有技術(shù)中實現(xiàn)跨行收款時操作復(fù)雜的問題。技術(shù)方案如下：

本發(fā)明提供一種收款渠道的建立方法，包括：

接收輸入的簽約信息；其中，所述簽約信息至少包括付方賬號；

依據(jù)每個付方賬號，獲取所述每個付方賬號支持的收款渠道；

從獲取到的所述每個付方賬號支持的收款渠道中，選擇與所述每個付方賬號對應(yīng)的簽約收款渠道；

建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)。

優(yōu)選地，所述建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)包括：

向所述簽約收款渠道發(fā)送渠道簽約信息；其中，所述渠道簽約信息至少包括所述每個付方賬號和每個付方賬號對應(yīng)的付方戶名；

接收所述簽約收款渠道對所述渠道簽約信息的審批結(jié)果；

判斷所述審批結(jié)果是否合格；

當(dāng)合格時，建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)。

優(yōu)選地，所述建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)，包括：

接收所述簽約收款渠道發(fā)送的渠道簽約信息；其中，所述渠道簽約信息至少包括所述每個付方賬號和每個付方賬號對應(yīng)的付方戶名；

依據(jù)所述渠道簽約信息，建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)。

本發(fā)明還提供了一種收款方法，包括：

接收輸入的收款信息；其中，所述收款信息至少包括收方賬號、付方賬號和收款金額；

依據(jù)所述收款信息，從預(yù)先建立的簽約收款渠道中獲取與所述收款信息對應(yīng)的簽約收款渠道；

利用所述簽約收款渠道收款。

優(yōu)選地，所述依據(jù)所述收款信息，從所述簽約收款渠道中獲取與所述收款信息對應(yīng)的簽約收款渠道，包括：

在與每個所述收方賬號對應(yīng)的所述簽約收款渠道中，查找與所述每個付方賬號一一對應(yīng)的簽約收款渠道。

優(yōu)選地，所述利用所述簽約收款渠道收款，包括：

向獲取到的所述簽約收款渠道發(fā)送收款交易請求；

接收所述每個付方賬號通過所述簽約收款渠道發(fā)送的交易回執(zhí)。

優(yōu)選地，所述向獲取到的所述簽約收款渠道發(fā)送收款交易請求之后，還包括：

對與所述收款交易請求對應(yīng)的收款交易，進行清算；

其中，對所述收款交易請求對應(yīng)的收款交易，進行清算包括：

接收所述簽約收款渠道對應(yīng)的清算通道平臺發(fā)送的清算文件；

根據(jù)所述清算文件，對所述收款交易進行清算。優(yōu)選地，所述向獲取到的所述簽約收款渠道發(fā)送收款交易請求包括：

接收收款交易請求；

判斷所述收款交易請求的數(shù)量是否超過預(yù)先設(shè)置的簽約收款渠道的收款交易量閾值；

判斷結(jié)果為是，則緩存接收到的所述收款交易請求；

將所述收款交易請求異步發(fā)送至所述簽約收款渠道。

本發(fā)明還提供了一種收款渠道的建立裝置，包括：

第一接收單元，用于接收輸入的簽約信息；其中，所述簽約信息至少包括付方賬號；

第一獲取單元，用于依據(jù)每個付方賬號，獲取所述每個付方賬號支持的收款渠道；

選擇單元，用于從獲取到的所述每個付方賬號支持的收款渠道中，選擇與所述每個付方賬號對應(yīng)的簽約收款渠道；

建立單元，用于建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)。

優(yōu)選地，所述建立單元，包括：

第一發(fā)送子單元，用于向所述簽約收款渠道發(fā)送渠道簽約信息；其中，所述渠道簽約信息至少包括所述每個付方賬號和每個付方賬號對應(yīng)的付方戶名；

第一接收子單元，用于接收所述簽約收款渠道對所述渠道簽約信息的審批結(jié)果；

判斷子單元，用于判斷所述審批結(jié)果是否合格；

第一建立子單元，用于當(dāng)所述判斷子單元判斷所述審批結(jié)果合格時，建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)。

優(yōu)選地，所述建立單元，包括：

第二接收子單元，用于接收所述簽約收款渠道發(fā)送的渠道簽約信息；其中，所述渠道簽約信息至少包括所述每個付方賬號和每個付方賬號對應(yīng)的付方戶名；

第二建立子單元，用于依據(jù)所述第二接收子單元接收的所述渠道簽約信息，建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)。

本發(fā)明還提供了一種收款裝置，包括：

第二接收單元，用于接收輸入的收款信息；其中，所述收款信息至少包括收方賬號、付方賬號和收款金額；

第二獲取單元，用于依據(jù)所述收款信息，從預(yù)先建立的簽約收款渠道中獲取與所述收款信息對應(yīng)的簽約收款渠道；

收款單元，用于利用所述簽約收款渠道收款。

優(yōu)選地，所述收款單元，包括：

第二發(fā)送子單元，用于向獲取到的所述簽約收款渠道發(fā)送收款交易請求；

第二接收子單元，用于接收所述每個付方賬號通過所述簽約收款渠道發(fā)送的交易回執(zhí)。

優(yōu)選地，還包括：

清算單元；

所述清算單元，用于對與所述收款交易請求對應(yīng)的收款交易，進行清算；

其中，所述清算單元包括：

第三接收子單元，用于接收所述簽約收款渠道對應(yīng)的清算通道平臺發(fā)送的清算文件；

清算子單元，用于根據(jù)所述清算文件，對所述收款交易進行清算。

優(yōu)選地，所述第二發(fā)送子單元，包括：

交易請求接收單元，用于接收收款交易請求；

閾值判斷單元，用于判斷所述收款交易請求的數(shù)量是否超過預(yù)先設(shè)置的簽約收款渠道的收款交易量閾值；

存儲單元，用于當(dāng)所述閾值判斷單元判斷結(jié)果為是時，緩存接收到的所述收款交易請求；

異步發(fā)送單元，用于將所述收款交易請求異步發(fā)送至所述簽約收款渠道。

與現(xiàn)有技術(shù)相比，本發(fā)明提供的上述技術(shù)方案具有如下優(yōu)點：

從上述技術(shù)方案可知，本發(fā)明通過接收輸入的簽約信息，建立與簽約信息對應(yīng)的簽約收款渠道，當(dāng)收方輸入多個不同的簽約信息時，則針對不同的簽約信息，分別建立與之對應(yīng)的簽約收款渠道，并建立收方賬號與簽約信息以及簽約收款渠道之間的關(guān)聯(lián)，使得收方通過一次簽約即可根據(jù)自身需求通過不同的收款渠道實現(xiàn)收款。

相較于現(xiàn)有技術(shù)中，用戶需要與多個銀行分別簽訂協(xié)議，才能實現(xiàn)從不同的付方收款的方式，本申請中通過一次簽約實現(xiàn)將多個收款渠道融合，并供用戶使用，用戶針對不同的付方，可以選擇不同的收款渠道實現(xiàn)收款，而無需用戶與多個銀行合作。操作簡單，且減少了用戶的工作量。

附圖說明

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1是本實施例公開的一種收款渠道的建立方法的流程圖；

圖2是本實施例公開的一種收款方法的流程圖；

圖3是本實施例公開的另一種收款方法的流程圖；

圖4是本實施例公開的一種收款渠道的建立裝置的結(jié)構(gòu)圖；

圖5是本實施例公開的一種收款裝置的結(jié)構(gòu)圖；

圖6是本實施例公開的另一種收款裝置的結(jié)構(gòu)圖。

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例。基于本發(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

用戶在建行申請開通一個賬戶，以從任意一個或多個付方賬號處實現(xiàn)收款時，建行根據(jù)客戶的需求，結(jié)合收取費用等內(nèi)容，為客戶提供合適的收款渠道，例如，用戶為有線電視公司，其需要從每個開通了有線電視服務(wù)的家庭中分別收取費用，則用戶所要求實現(xiàn)的是大批量的交易，結(jié)合收款渠道不同的收費標(biāo)準(zhǔn)，為有限電視公司提供金聯(lián)收款這一收款渠道。

但是，由于每個家庭即付方所持有的賬戶的開戶行可能不同，例如付方可以持有農(nóng)村商業(yè)銀行或信用社賬戶，這類小型銀行并不在金聯(lián)渠道支持的范圍內(nèi)。此時，當(dāng)多個已經(jīng)開通了有線電視服務(wù)的家庭，持有不同他行的銀行卡，且他行并不支持金聯(lián)收款這一收款渠道時，導(dǎo)致有線電視公司不能成功的從持有他行銀行卡的家庭中收款有線電視服務(wù)費用。

現(xiàn)有技術(shù)中，為了實現(xiàn)用戶能夠從每個已經(jīng)開通了有線電視服務(wù)的家庭中收取費用，采用的方式是：針對持有他行銀行卡的家庭，有線電視公司分別與他行簽約，以實現(xiàn)從每個家庭中收取費用。這一方式導(dǎo)致用戶的操作復(fù)雜且占用資源多。

針對此問題，本申請?zhí)峁┝艘环N收款渠道的建立方法，通過接收輸入的簽約信息，建立與簽約信息對應(yīng)的收款渠道，當(dāng)收方輸入多個不同的簽約信息時，則針對不同的簽約信息，分別建立與之對應(yīng)的收款渠道，使得收方通過一次簽約即可根據(jù)自身需求通過不同的收款渠道實現(xiàn)收款。

相較于現(xiàn)有技術(shù)中，用戶需要與多個銀行分別簽訂協(xié)議，才能實現(xiàn)從不同的付方收款的方式，本申請中通過一次簽約實現(xiàn)將多個收款渠道融合，并供用戶使用，用戶針對不同的付方，可以選擇不同的收款渠道實現(xiàn)收款，而無需用戶與多個銀行合作。操作簡單，且減少了用戶的工作量。

請參閱圖1，其示出了本申請實施例提供的一種收款渠道的建立方法的流程圖，所述建立方法包括：

S101、接收輸入的簽約信息；

其中，所述簽約信息至少包括付方賬號；

優(yōu)選地，所述付方賬號可以是付方的銀行卡號。

S102、依據(jù)每個付方賬號，獲取所述每個付方賬號支持的收款渠道；

不同的銀行，其開通的銀行卡支持的收款渠道是不同的，針對每個付方賬號對應(yīng)的開戶行，分別獲取每個付方賬號支持的收款渠道。每個付方賬號支持的收款渠道可以為一個，也可以為多個。

S103、從獲取到的所述每個付方賬號支持的收款渠道中，選擇與所述每個付方賬號對應(yīng)的簽約收款渠道；

當(dāng)付方賬號支持的收款渠道為一個時，則選擇這一個收款渠道為與此付方賬號對應(yīng)的簽約收款渠道；

當(dāng)付方賬號支持的收款渠道為多個時，則從這多個收款渠道中選擇一個收款渠道為與此付方賬號對應(yīng)的簽約收款渠道。

S104、建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)。

優(yōu)選地，建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)包括：

S1041、向所述簽約收款渠道發(fā)送渠道簽約信息；其中，所述渠道簽約信息至少包括所述每個付方賬號和每個付方賬號對應(yīng)的付方戶名；

針對每個付方賬號，將至少包括付方賬號、付方賬號對應(yīng)的付方戶名的渠道簽約信息，發(fā)送到所述簽約收款渠道；

由于不同的收款渠道，在簽訂收款協(xié)議時，所需要提供的具體渠道簽約信息是不同的，因此針對簽約收款渠道，向所述簽約收款渠道發(fā)送包括其所需要的渠道簽約信息的內(nèi)容。

例如，簽約收款渠道為小額借記時，渠道簽約信息包括付方賬號、付方戶名、付方聯(lián)行號和授權(quán)支付協(xié)議號；

簽約收款渠道為銀聯(lián)收款時，渠道簽約信息除包括付方賬號、付方戶名、付方聯(lián)行號、商戶編號、POS編號和證件類型等商戶注冊信息；其中，所述商戶注冊信息可以從商戶登記系統(tǒng)獲取；

簽約收款渠道為金聯(lián)收款時，渠道簽約信息除包括付方賬號、付方戶名、付方聯(lián)行號和營業(yè)執(zhí)照、組織機構(gòu)代碼證等企業(yè)入網(wǎng)信息。

S1042、接收所述簽約收款渠道對所述渠道簽約信息的審批結(jié)果；

S1043、判斷所述審批結(jié)果是否合格；

當(dāng)合格時，執(zhí)行S1044；

S1044、建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)。

上述建立每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)的方式，適用于金聯(lián)、銀聯(lián)等收款渠道，需要收方發(fā)起簽約請求。

優(yōu)選地，建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)包括：

接收所述簽約收款渠道發(fā)送的渠道簽約信息；其中，所述渠道簽約信息至少包括所述每個付方賬號和每個付方賬號對應(yīng)的付方戶名；

依據(jù)所述渠道簽約信息，建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)。

上述建立每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)的方式，適用于小額借記等收款渠道，需要付方發(fā)起簽約請求。

針對每個付方賬號，確定了與所述每個付方賬號對應(yīng)的簽約收款渠道后，將所述每個付方賬號、所述簽約收款渠道，與收方賬號相關(guān)聯(lián)。其中，所述收方賬號可以為一個，也可以為多個。

一個收方賬號對應(yīng)的簽約收款渠道有多個，但這一收方賬號對應(yīng)的每個付方賬號，僅對應(yīng)一個簽約收款渠道。當(dāng)收方賬號以及付方賬號都確定后，能夠找到唯一一個簽約收款渠道。

通過建立付方賬號、簽約收款渠道和收方賬號之間的關(guān)聯(lián)，收方賬號從付方賬號處通過一個簽約收款渠道實現(xiàn)收款。

本實施例中，通過接收輸入的簽約信息，建立與簽約信息對應(yīng)的簽約收款渠道，當(dāng)收方輸入多個不同的簽約信息時，則針對不同的簽約信息，分別建立與之對應(yīng)的簽約收款渠道，并建立收方賬號與簽約信息以及簽約收款渠道之間的關(guān)聯(lián)，使得收方通過一次簽約即可根據(jù)自身需求通過不同的收款渠道實現(xiàn)收款。

相較于現(xiàn)有技術(shù)中，用戶需要與多個銀行分別簽訂協(xié)議，才能實現(xiàn)從不同的付方收款的方式，本申請中通過一次簽約實現(xiàn)將多個收款渠道融合，并供用戶使用，用戶針對不同的付方，可以選擇不同的收款渠道實現(xiàn)收款，而無需用戶與多個銀行合作。操作簡單，且減少了用戶的工作量。

基于上述實施例公開的收款渠道的建立方法建立的收款渠道，本實施例還公開了一種收款方法。參閱圖2，其示出了本申請實施例提供的一種收款方法的流程圖，所述收款方法包括：

S201、接收輸入的收款信息；其中，所述收款信息至少包括收方賬號、付方賬號和收款金額；

在進行收款時，需要連接銀行系統(tǒng)，其中，連接方式可以是通過登錄網(wǎng)上銀行的方式，通過輸入用戶名以及密碼登錄網(wǎng)上銀行；連接方式還可以是直連的方式，用戶通過登錄自己的系統(tǒng)，輸入對接接口規(guī)范后，實現(xiàn)自己的系統(tǒng)與建行系統(tǒng)的連接。

連接銀行系統(tǒng)后，銀行系統(tǒng)接收用戶輸入的收款信息，其中，所述收款信息至少包括收方賬號、付方賬號和收款金額。

優(yōu)選地，所述收方賬號可以在登錄到網(wǎng)上銀行后，直接根據(jù)登錄網(wǎng)上銀行時輸入的用戶名獲取，也可以在登錄企業(yè)系統(tǒng)后，根據(jù)登錄企業(yè)系統(tǒng)時輸入的信息獲取到；

當(dāng)收方賬號有多個時，即一個用戶對應(yīng)多個收方賬號時，可以在收款時從多個收方賬號中選擇一個收方賬號。

S202、依據(jù)所述收款信息，從預(yù)先建立的簽約收款渠道中獲取與所述收款信息對應(yīng)的簽約收款渠道；

接收到收款信息后，在預(yù)先建立的每個付方賬號、簽約收款渠道和收方賬號之間的關(guān)聯(lián)中，獲取與收款信息中包括的收方賬號對應(yīng)的所述簽約收款渠道，再根據(jù)收款信息中包括的付方賬號，查找與所述每個付方賬號一一對應(yīng)的簽約收款渠道。

S203、利用所述簽約收款渠道收款。

優(yōu)選地，所述利用所述簽約收款渠道收款，包括：

S2031、向獲取到的所述簽約收款渠道發(fā)送收款交易請求；

向所述簽約收款渠道發(fā)送收款交易請求，所述簽約收款渠道依據(jù)所述渠道簽約信息，向付方開戶銀行發(fā)送收款交易請求。

S2032、接收所述每個付方賬號通過所述簽約收款渠道發(fā)送的交易回執(zhí)。

本實施例中，在收方從多個付方賬號中收款時，根據(jù)預(yù)先建立的與收方賬號、付方賬號對應(yīng)的簽約收款渠道，實現(xiàn)從每個付方賬號中收款。即用戶只需要在建行開通一個對公活期賬戶，在于建行簽約的過程中，針對不同的付方賬號建立不同的收款渠道，通過將多個收款渠道融合，以實現(xiàn)采用一個或多個收款渠道分別從每個付方賬號中收款。解決了在面對持有不同他行的付方時，用戶需要分別與多個銀行分別簽訂協(xié)議，才能實現(xiàn)從不同的付方收款，導(dǎo)致的操作復(fù)雜的問題。

參閱圖3，其示出了本申請實施例提供的另一種收款方法的流程圖，所述收款方法包括：

S301、接收輸入的收款信息；其中，所述收款信息至少包括收方賬號、付方賬號和收款金額；

S302、依據(jù)所述收款信息，從預(yù)先建立的簽約收款渠道中獲取與所述收款信息對應(yīng)的簽約收款渠道；

本實施例中的步驟S301、S302與圖2所示的實施例中的步驟S201、S202相同，此處不再贅述。

S303、向獲取到的所述簽約收款渠道發(fā)送收款交易請求；

優(yōu)選地，所述向獲取到的所述簽約收款渠道發(fā)送收款交易請求，包括：

S3031、接收收款交易請求；

接收用戶通過企業(yè)系統(tǒng)發(fā)送的收款交易請求，此交易請求可以通過特定的按鈕觸發(fā)；

S3032、判斷所述收款交易請求的數(shù)量是否超過預(yù)先設(shè)置的簽約收款渠道的收款交易量閾值；

判斷結(jié)果為是，則執(zhí)行S3033；

判斷結(jié)果為否，則執(zhí)行S3035；

針對每個簽約收款渠道，可以預(yù)先設(shè)置收款交易量閾值；

此主要針對的用戶是企業(yè)，企業(yè)在短時間內(nèi)集中發(fā)送大量收款交易請求。

在接收到收款交易請求后，根據(jù)所述獲取到的所述簽約收款渠道對應(yīng)的預(yù)先設(shè)置的收款交易量閾值，判斷所述收款交易請求的數(shù)量是否超過所述簽約收款渠道的收款交易量閾值；

S3033、緩存接收到的所述收款交易請求；

當(dāng)判斷接收到的所述收款交易請求的數(shù)量超過了所述簽約收款渠道的收款交易量閾值，則將接收到的所述收款交易請求存儲；

S3034、將所述收款交易請求異步發(fā)送至所述簽約收款渠道；

采用異步的方式將存儲的所述收款交易請求發(fā)送至所述簽約收款渠道。

可選地，可以針對用戶預(yù)先設(shè)置收款交易量閾值，即當(dāng)接收到的收款交易請求是某個特定用戶發(fā)送的，則根據(jù)這一特定用戶預(yù)先設(shè)置的收款交易量閾值，判斷所述收款交易請求的數(shù)量是否超過了閾值，若超過了則存儲后，采用異步的方式向所述簽約收款渠道發(fā)送。

針對用戶設(shè)置閾值主要是考慮到有些用戶，每次發(fā)送的交易請求量都很大，這時可以為此用戶設(shè)置閾值，避免同時發(fā)送大量交易請求時，導(dǎo)致系統(tǒng)擁堵，交易請求失敗的問題產(chǎn)生。

對用戶設(shè)置閾值與對簽約收款渠道設(shè)置閾值是不同的，其中，對簽約收款渠道設(shè)置閾值，僅針對在這一簽約收款渠道下發(fā)送的交易請求進行控制；而對用戶設(shè)置閾值，則只要是這一用戶發(fā)起的交易，無論采用何種收款渠道，則都對交易請求進行控制。

S3035、將所述收款交易請求同時發(fā)送至所述簽約收款渠道；

S304、接收所述每個付方賬號通過所述簽約收款渠道發(fā)送的交易回執(zhí)；

S305、對與所述收款交易請求對應(yīng)的收款交易，進行清算；

優(yōu)選地，對于所述收款交易請求對應(yīng)的收款交易進行清算，包括：

S3051、接收所述簽約收款渠道對應(yīng)的清算通道平臺發(fā)送的清算文件；

由于不同的簽約收款渠道，對應(yīng)的清算通道平臺是不同的，接收不同所述清算通道平臺發(fā)送的清算文件。

S3052、根據(jù)所述清算文件，對所述收款交易進行清算。

其中，步驟S304與步驟S305的執(zhí)行順序并不受本實施例的限定。在實際應(yīng)用中，對發(fā)起的收款交易進行清算是定時執(zhí)行的。

本實施例公開的一種收款方法，還可以包括對與所述收款交易請求對應(yīng)的收款交易，進行對賬；

其中，對與所述收款交易請求對應(yīng)的收款交易，進行對賬包括：

向與獲取到的所述簽約收款渠道對應(yīng)的對賬系統(tǒng)發(fā)送對賬請求；

由于不同的簽約收款渠道，對應(yīng)的對賬系統(tǒng)是不同的，例如所述簽約收款渠道為小額借記時，對應(yīng)的對賬系統(tǒng)是支付結(jié)算系統(tǒng)；所述簽約收款渠道為銀聯(lián)收款時，對應(yīng)的對賬系統(tǒng)是銀聯(lián)系統(tǒng)；所述簽約收款渠道為金聯(lián)收款時，對應(yīng)的對賬系統(tǒng)是支付結(jié)算系統(tǒng)和金聯(lián)萬家系統(tǒng)。因此需要根據(jù)所述簽約收款渠道，確定與所述簽約收款渠道對應(yīng)的對賬系統(tǒng)，并向所述對賬系統(tǒng)發(fā)送對賬請求。

接收所述對賬系統(tǒng)返回的對賬結(jié)果。

用戶可以通過統(tǒng)一的查詢界面查詢對賬結(jié)果，進而獲知收款交易的交易結(jié)果。由于不同的簽約收款渠道對應(yīng)的對賬系統(tǒng)是不同的，因此，對賬系統(tǒng)返回的對賬結(jié)果的顯示形式或內(nèi)容是不同的。

在實際應(yīng)用中，可以預(yù)先設(shè)置周期，按照周期完成對賬操作。

本實施例中，在收方從多個付方賬號中收款時，根據(jù)預(yù)先建立的與收方賬號、付方賬號對應(yīng)的簽約收款渠道，實現(xiàn)從每個付方賬號中收款。即用戶只需要在建行開通一個對公活期賬戶，在于建行簽約的過程中，針對不同的付方賬號建立不同的收款渠道，通過將多個收款渠道融合，以實現(xiàn)采用一個或多個收款渠道分別從每個付方賬號中收款。解決了在面對持有不同他行的付方時，用戶需要分別與多個銀行分別簽訂協(xié)議，才能實現(xiàn)從不同的付方收款，導(dǎo)致的操作復(fù)雜的問題。

同時，本實施例中，在發(fā)送收款交易請求時，針對簽約收款渠道設(shè)置的閾值，對同時發(fā)送的交易量進行控制，可以避免同時發(fā)送大量交易請求導(dǎo)致系統(tǒng)擁堵，交易請求失敗的問題產(chǎn)生。且對收款交易提供了清算和對賬操作，方便用戶獲知當(dāng)前收款交易的交易結(jié)果，提高了用戶體驗。

對應(yīng)圖1所示的一種收款渠道的建立方法，本實施例公開了一種收款渠道的建立裝置，參閱圖4，其示出了本實施例公開的一種收款渠道的建立裝置的結(jié)構(gòu)圖，所述建立裝置包括：

第一接收單元11、第一獲取單元12、選擇單元13和建立單元14；

所述第一接收單元11，用于接收輸入的簽約信息；其中，所述簽約信息至少包括付方賬號；

所述第一獲取單元12，用于依據(jù)每個付方賬號，獲取所述每個付方賬號支持的收款渠道；

所述選擇單元13，用于從獲取到的所述每個付方賬號支持的收款渠道中，選擇與所述每個付方賬號對應(yīng)的簽約收款渠道；

所述建立單元14，用于建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)。

優(yōu)選地，所述建立單元14，包括：

第一發(fā)送子單元21、第一接收子單元22、判斷子單元23和第一建立子單元24；

所述第一發(fā)送子單元21，用于向所述簽約收款渠道發(fā)送渠道簽約信息；其中，所述渠道簽約信息至少包括所述每個付方賬號和每個付方賬號對應(yīng)的付方戶名；

所述第一接收子單元22，用于接收所述簽約收款渠道對所述渠道簽約信息的審批結(jié)果；

所述判斷子單元23，用于判斷所述審批結(jié)果是否合格；

所述第一建立子單元24，用于當(dāng)所述判斷子單元判斷所述審批結(jié)果合格時，建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)。

優(yōu)選地，所述建立單元14，包括：

第二接收子單元和第二建立子單元；

所述第二接收子單元，用于接收所述簽約收款渠道發(fā)送的渠道簽約信息；其中，所述渠道簽約信息至少包括所述每個付方賬號和每個付方賬號對應(yīng)的付方戶名；

所述第二建立子單元，用于依據(jù)所述第二接收子單元接收的所述渠道簽約信息，建立所述每個付方賬號、所述簽約收款渠道和收方賬號之間的關(guān)聯(lián)。

在建立收方賬號、付方賬號與簽約收款渠道之間的關(guān)聯(lián)時，根本不同的簽約收款渠道，選擇不同的建立單元14，實現(xiàn)建立三者之間的關(guān)聯(lián)。

本實施例中，通過第一接收單元接收輸入的簽約信息，建立單元建立與簽約信息對應(yīng)的簽約收款渠道，當(dāng)收方輸入多個不同的簽約信息時，則針對不同的簽約信息，分別建立與之對應(yīng)的簽約收款渠道，并建立收方賬號與簽約信息以及簽約收款渠道之間的關(guān)聯(lián)，使得收方通過一次簽約即可根據(jù)自身需求通過不同的收款渠道實現(xiàn)收款。

相較于現(xiàn)有技術(shù)中，用戶需要與多個銀行分別簽訂協(xié)議，才能實現(xiàn)從不同的付方收款的方式，本申請中通過一次簽約實現(xiàn)將多個收款渠道融合，并供用戶使用，用戶針對不同的付方，可以選擇不同的收款渠道實現(xiàn)收款，而無需用戶與多個銀行合作。操作簡單，且減少了用戶的工作量。

對應(yīng)圖2所示的一種收款方法，本實施例公開了一種收款裝置，參閱圖5，其示出了本實施例公開的一種收款裝置的結(jié)構(gòu)圖，所述收款裝置包括：

第二接收單元31、第二獲取單元32和收款單元33；

所述第二接收單元31，用于接收輸入的收款信息；其中，所述收款信息至少包括收方賬號、付方賬號和收款金額；

所述第二獲取單元32，用于依據(jù)所述收款信息，從預(yù)先建立的簽約收款渠道中獲取與所述收款信息對應(yīng)的簽約收款渠道；

所述收款單元33，用于利用所述簽約收款渠道收款。

優(yōu)選地，所述收款單元33包括：

第二發(fā)送子單元41，用于向獲取到的所述簽約收款渠道發(fā)送收款交易請求；

第二接收子單元42，用于接收所述每個付方賬號通過所述簽約收款渠道發(fā)送的交易回執(zhí)。

本實施例中，在收方從多個付方賬號中收款時，根據(jù)預(yù)先建立的與收方賬號、付方賬號對應(yīng)的簽約收款渠道，實現(xiàn)從每個付方賬號中收款。即用戶只需要在建行開通一個對公活期賬戶，在于建行簽約的過程中，針對不同的付方賬號建立不同的收款渠道，通過將多個收款渠道融合，以實現(xiàn)采用一個或多個收款渠道分別從每個付方賬號中收款。解決了在面對持有不同他行的付方時，用戶需要分別與多個銀行分別簽訂協(xié)議，才能實現(xiàn)從不同的付方收款，導(dǎo)致的操作復(fù)雜的問題。

對應(yīng)圖3所示的一種收款方法，本實施例公開了一種收款裝置，參閱圖6，其示出了本實施例公開的一種收款裝置的結(jié)構(gòu)圖，所述收款裝置包括：

第二接收單元31、第二獲取單元32、第二發(fā)送子單元41、第二接收子單元42和清算單元51；

所述清算單元51，用于對與所述收款交易請求對應(yīng)的收款交易，進行清算；

其中，所述清算單元51包括：

第三接收子單元，用于接收所述簽約收款渠道對應(yīng)的清算通道平臺發(fā)送的清算文件；

清算子單元，用于根據(jù)所述清算文件，對所述收款交易進行清算。

優(yōu)選地，所述第二發(fā)送子單元41包括：

交易請求接收單元61、閾值判斷單元62、存儲單元63和異步發(fā)送單元64；

所述交易請求接收單元61，用于接收收款交易請求；

所述閾值判斷單元62，用于判斷所述收款交易請求的數(shù)量是否超過預(yù)先設(shè)置的簽約收款渠道的收款交易量閾值；

所述存儲單元63，用于當(dāng)所述閾值判斷單元判斷結(jié)果為是時，緩存接收到的所述收款交易請求；

所述異步發(fā)送單元64，用于將所述收款交易請求異步發(fā)送至所述簽約收款渠道。

本實施例中，在收方從多個付方賬號中收款時，根據(jù)預(yù)先建立的與收方賬號、付方賬號對應(yīng)的簽約收款渠道，實現(xiàn)從每個付方賬號中收款。即用戶只需要在建行開通一個對公活期賬戶，在于建行簽約的過程中，針對不同的付方賬號建立不同的收款渠道，通過將多個收款渠道融合，以實現(xiàn)采用一個或多個收款渠道分別從每個付方賬號中收款。解決了在面對持有不同他行的付方時，用戶需要分別與多個銀行分別簽訂協(xié)議，才能實現(xiàn)從不同的付方收款，導(dǎo)致的操作復(fù)雜的問題。

同時，本實施例中，在發(fā)送收款交易請求時，針對簽約收款渠道設(shè)置的閾值，對同時發(fā)送的交易量進行控制，可以避免同時發(fā)送大量交易請求導(dǎo)致系統(tǒng)擁堵，交易請求失敗的問題產(chǎn)生。且對收款交易提供了清算和對賬操作，方便用戶獲知當(dāng)前收款交易的交易結(jié)果，提高了用戶體驗。

需要說明的是，本說明書中的各個實施例均采用遞進的方式描述，每個實施例重點說明的都是與其他實施例的不同之處，各個實施例之間相同相似的部分互相參見即可。對于方法類實施例而言，由于其與設(shè)備實施例基本相似，所以描述的比較簡單，相關(guān)之處參見設(shè)備實施例的部分說明即可。

最后，還需要說明的是，在本文中，諸如第一和第二等之類的關(guān)系術(shù)語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關(guān)系或者順序。而且，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設(shè)備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設(shè)備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設(shè)備中還存在另外的相同要素。

對所公開的實施例的上述說明，使本領(lǐng)域技術(shù)人員能夠?qū)崿F(xiàn)或使用本發(fā)明。對這些實施例的多種修改對本領(lǐng)域技術(shù)人員來說將是顯而易見的，本文中所定義的一般原理可以在不脫離本發(fā)明的精神或范圍的情況下，在其它實施例中實現(xiàn)。因此，本發(fā)明將不會被限制于本文所示的這些實施例，而是要符合與本文所公開的原理和新穎特點相一致的最寬的范圍。

以上所述僅是本發(fā)明的優(yōu)選實施方式，應(yīng)當(dāng)指出，對于本技術(shù)領(lǐng)域的普通技術(shù)人員來說，在不脫離本發(fā)明原理的前提下，還可以做出若干改進和潤飾，這些改進和潤飾也應(yīng)視為本發(fā)明的保護范圍。