本說明書的實施例提出一種新的基於條碼支付的實現方法，付款方終端向收款方出示攜帶有發碼機構標識和付款帳戶資訊的付款碼，收款方的收單機構在收到收款方設備上傳的發碼機構標識和付款帳戶資訊後，向具有該發碼機構標識的發碼機構的伺服器發送包括付款帳戶資訊的第二支付請求，發碼機構的伺服器根據付款帳戶資訊將使用該付款方終端的付款方帳戶作為付款帳戶進行支付。這樣，商戶只需與一個收單機構具有收單業務關係，就可以接收使用其他支付服務提供方的用戶的條碼支付，用戶也無需確認商戶是否支持自己使用的發碼機構，提高了商戶和用戶的支付效率，使得用戶和商戶在支付時更為便捷。
本說明書的實施例中，支付過程是由付款方向收款方出示付款碼，收款方透過掃描付款碼來收取款項。付款碼可以是一維條碼，可以是二維條碼，可以是一維和二維條碼的組合，還可以是兩個或兩個以上採用不同碼制編碼的一維和/或二維條碼的組合，本說明書的實施例對付款碼中條碼的個數、碼制均不做限定。
本說明書的實施例中，付款方在某個支付服務提供方開設有帳戶，當付款方希望以該帳戶進行某次支付時，付款方終端將出示按照該支付服務提供方的規則、基於該付款方帳戶產生的付款碼。該支付服務提供方即成為本次支付中的發碼機構，該付款方帳戶即成為本次支付中的付款帳戶。
收款方在某個支付服務提供方開設有帳戶，並且收款方與該支付服務提供方具有付款碼支付的收單業務關係，該支付服務提供方即可作為該收款方的收單機構。收款方可以有兩個或兩個以上收單機構，當某次支付中收款方在掃描付款碼後向某個支付服務提供方的伺服器發送支付請求時，接收支付請求的支付服務提供方即成為本次支付中的收單機構，該收款方在該收單機構的帳戶即成為本次支付中的收款帳戶。
本說明書的實施例中，收款方設備可以掃描付款方終端上展示的付款碼，收款方設備可以與收單機構的伺服器進行通信，收單機構的伺服器可以直接或透過其他網路節點間接與發碼機構的伺服器進行通信，付款方終端既可以是離線狀態也可以與發碼機構的伺服器進行通信。
在一個例子中，本說明書實施例應用場景的第一種網路結構如圖1所示，付款方終端可以與發碼機構的伺服器透過網路進行通信，收款方設備可以掃描付款方終端上展示的付款碼，收款方設備與收單機構的伺服器透過網路進行通信，收單機構的伺服器與發碼機構的伺服器透過網路直接進行通信。
在另一個例子中，本說明書實施例應用場景的第一種網路結構如圖1所示，付款方終端與發碼機構的伺服器透過網路進行通信，收款方設備可以掃描付款方終端上展示的付款碼，收款方設備與收單機構的伺服器透過網路進行通信，收單機構的伺服器、發碼機構的伺服器分別與機構互連伺服器透過網路直接進行通信，機構互連伺服器可以在收單機構的伺服器與發碼機構的伺服器之間進行資訊的轉發。
其中，付款方終端可以是手機、平板電腦、PC(Personal Computer，個人電腦)、筆記型電腦等設備；收款方設備可以是具有掃描、計算和儲存功能的一個設備或兩個及以上設備的組合，如手機、平板電腦、掃碼槍和PC、筆記型電腦等設備；發碼機構的伺服器、收單機構的伺服器或機構互連伺服器可以是一個物理或邏輯伺服器，也可以是由兩個或兩個以上分擔不同職責的物理或邏輯伺服器、相互協同來實現本說明書實施例中發碼機構的伺服器、收單機構的伺服器或機構互連伺服器的各項功能。
本說明書的實施例中，基於條碼支付的實現方法應用在付款方終端上的流程如圖3所示，應用在收款方設備上的流程如圖4所示，應用在收單機構的伺服器上的流程如圖5所示，應用在發碼機構的伺服器上的流程如圖6所示。
在付款方終端上，步驟310，獲取付款碼碼值。付款碼碼值包括發碼機構標識和付款帳戶資訊，付款帳戶資訊對應於具有該發碼機構標識的發碼機構的一個帳戶。
本說明書的實施例中，付款碼碼值中包括發碼機構標識和付款帳戶資訊。其中，發碼機構標識唯一代表一個向付款方提供服務的支付服務提供商，各個支付服務提供商能夠根據發碼機構標識確定本次支付的發碼機構是哪個；付款帳戶資訊能夠由發碼機構用來確定本機構的一個帳戶。付款碼碼值中的發碼機構標識通常採用明文的形式，以便任何一個收單機構的伺服器都可以識別出發碼機構。付款碼碼值中的付款帳戶資訊可以由發碼機構自行確定，只要發碼機構能夠將付款帳戶資訊唯一對應於本機構的一個帳戶即可。
通常付款帳戶資訊中包括標記化處理後的付款方的帳戶標識；還可以包括一些驗證資訊(如標記化處理後的付款方終端的設備標識)、以及其他資訊。其中，帳戶標識可以是任何在發碼機構中能夠唯一代表一個帳戶的資訊，如帳戶名稱、帳戶編號、帳戶索引等中的一個到多個；設備標識可以是任何能夠唯一對應於付款方終端的硬體標識或軟體標識，如行動設備的序列號、MAC(Media Access Control Address，媒體存取控制)地址、IMEI(International Mobile Equipment Identity，國際行動設備識別碼)等；標記化處理可以是任意一種能夠隱藏明文隱私資訊的處理方式，如加密等。
在一些應用場景中，可以在付款碼碼值中包括收單機構標識，收單機構標識可以由收款方設備用來確定本次支付的收單機構，即收款方設備將發碼機構標識和付款帳戶資訊上傳給哪個收單機構的伺服器。這樣，發碼機構可以向收款方指定收單機構、或向收款方推薦優選的收單機構。
需要說明的是，收單機構標識可以是專屬於某個支付服務提供方的標識(即該支付服務提供方自身的標識)；也可以是某個支付服務提供方加入的互連網路的標識。在該互連網路中，任何一個支付服務提供方都可以作為所有支付服務提供方的帳戶在付款時的收單機構，這樣該互連網路的標識可以作為加入該互連網路的所有支付服務提供方的收單機構標識。
此外，還可以在付款碼碼值中攜帶其他資訊，如付款碼碼值的版本號，用來表明付款碼碼值所採用的編碼格式是哪個；再如業務類型，用來表明採用該付款碼碼值進行的業務是哪個。
本說明書的實施例對付款碼碼值的編碼格式不做限定。編碼格式包括付款碼碼值所採用的字符(字母、數字、符號等)、所攜帶的各項資訊占用的字符長度、以及排列順序等。以下給出兩個付款碼碼值的編碼格式的例子。
第一個例子中，付款碼碼值採用全數位格式，長度為24到32位，每位可以是0到9中的一個數字。這種付款碼碼值由長度固定為8位的發碼機構標識和長度從16位到24位可變的付款帳戶資訊組成，其中發碼機構標識為前8位數字，付款帳戶資訊為後16至24位數字，發碼機構標識中的第1位數字是表示發碼機構所服務區域的區域碼。
如圖7所示，付款碼碼值的第1位到第8位為發碼機構標識，第9位到最後一位為付款帳戶資訊。發碼機構標識中的第1位為區域碼，區域碼根據支付服務提供方開展主要業務的區域决定，一種示例性的分配方式如表1所示：
可以分配一個到多個發碼機構標識給一個支付服務提供方，例如，將28100100~28100199分配給支付服務提供方PSP A，將28100600~28100699分配給支付服務提供方PSP B，將28100600~28100699分配給支付服務提供方PSP C，將40100100分配給支付服務提供方PSP D。
這個例子中的付款碼碼值能夠展現為一維條碼，從而使得大量使用一維條碼掃描儀的商戶無需升級硬體設備，即可支持更多的發碼機構。
第二個例子的付款碼碼值中包括收單機構標識，此外，還包括付款碼碼值的版本號和業務類型。這個例子中的付款碼碼值採用全數位格式，長度為24位，其中3位為發碼機構標識、16位為付款帳戶資訊、2位為收單機構標識、1位為付款碼碼值的版本號、2位為業務類型，每位可以是0到9中的一個數字。
如圖8所示，付款碼碼值為24位數字，其中，收單機構標識是第1位到第2位數字，付款碼碼值的版本號是第3位數字，發碼機構標識是第4位到第6位數字，業務類型是第7到第8位數字，付款帳戶資訊是第9至第24位數字。
付款方終端可以採用各種形式來獲取付款碼碼值，本說明書的實施例不做限定。例如，可以由安裝在付款方終端本地的某個發碼機構的用戶端軟體來產生付款碼碼值，產生的付款碼碼值中攜帶有該發碼機構標識、和以在該用戶端軟體登錄的帳戶作為付款帳戶的付款帳戶資訊。再如，還可以由付款方終端向某個發碼機構的伺服器發起付款碼請求，該發碼機構的伺服器在收到付款方終端的付款碼請求後，根據使用該付款方終端的帳戶產生付款帳戶資訊，向該付款方終端返回包括產生的付款帳戶資訊和本機構的發碼機構標識的付款碼碼值。此外，還可以結合上述兩種方式，當付款方終端處於在線狀態時，以向發碼機構的伺服器請求的方式來獲得付款碼碼值；當付款方終端處於離線狀態時，由本地的發碼機構用戶端軟體來產生付款碼碼值。
在付款方終端上，步驟320，將付款碼碼值渲染為條碼後顯示，供收款方設備掃描後將發碼機構標識和付款帳戶資訊上傳給收單機構的伺服器，由收單機構的伺服器根據發碼機構標識確定發碼機構，由該發碼機構的伺服器根據付款帳戶資訊確定用於本次支付的付款帳戶。
在收款方設備上，步驟410，透過掃描付款方終端提供的付款碼獲取付款碼碼值。
付款方終端將獲取的付款碼碼值渲染為付款碼，付款碼可以是一個到多個條碼，如一維條碼、二維條碼、或一維條碼和二維條碼的組合。付款方終端將付款碼顯示在螢幕上，供收款方設備掃描。
收款方設備在掃描付款方終端顯示的付款碼後，得到付款碼碼值。
在收款方設備上，步驟420，將包括發碼機構標識和付款帳戶資訊的第一支付請求發送給收單機構的伺服器，供收單機構的伺服器根據發碼機構標識確定發碼機構，由所確定的發碼機構的伺服器根據付款帳戶資訊確定用於本次支付的付款帳戶。
在收單機構的伺服器上，步驟510，接收付款方設備發送的第一支付請求。第一支付請求中包括付款碼碼值中的發碼機構標識和付款帳戶資訊。
收款方設備將付款碼碼值中的發碼機構標識和付款帳戶資訊封裝在第一支付請求中，發送給收單機構的伺服器。收款方設備可以將完整的付款碼碼值封裝在第一支付請求中。收款方設備還可以在第一支付請求中封裝收款方在收單機構的帳戶資訊、用來確定支付款項數額的款項資訊(如額度，或額度和幣種)、描述本次交易的交易資訊等其他資訊。本說明書的實施例不做限定。
對付款碼碼值中包括收單機構標識的應用場景，收款方設備提取付款碼碼值中的收單機構標識，根據提取的收單機構標識確定收單機構，將第一支付請求發送給具有該收單機構標識的收單機構的伺服器。
收單機構的伺服器在收到第一支付請求後，可以從中提取出付款碼的發碼機構標識、付款帳戶資訊、以及其他資訊。
在收單機構的伺服器上，步驟520，當該發碼機構標識不是本機構的發碼機構標識時，向該發碼機構的伺服器發送第二支付請求，所述第二支付請求中包括付款帳戶資訊，供發碼機構的伺服器根據付款帳戶資訊確定本次支付的付款帳戶，並從該付款帳戶中扣款。
收單機構的伺服器判斷第一支付請求中的發碼機構標識是否是本機構的發碼機構標識，如果不是，則需要由其他機構的伺服器來解讀付款帳戶資訊。收單機構的伺服器將第一支付請求中的付款帳戶資訊封裝在第二支付請求中，並向具有該發碼機構標識的發碼機構的伺服器發送第二支付請求。如果第一支付請求中攜帶有完整的付款碼碼值，收單機構的伺服器可以將完整的付款碼碼值封裝在第二支付請求中。收單機構的伺服器還可以將第一支付請求中本次支付的款項資訊、交易資訊等其他資訊中的一個到多個封裝在第二支付請求中。
在收單機構的伺服器與發碼機構的伺服器分別與機構互連伺服器直接進行通信的應用場景中，第二支付請求中需要攜帶來自第一支付請求的發碼機構標識，並且第二支付請求將透過機構互連伺服器轉發給具有該發碼機構標識的發碼機構的伺服器。在這個應用場景中，應用在機構互連伺服器上的基於條碼支付的實現方法的流程如圖9所示。
在機構互連伺服器上，步驟910，接收收單機構的伺服器發送的第二支付請求。第二支付請求中包括付款碼碼值中的發碼機構標識和付款帳戶資訊。
在機構互連伺服器上，步驟920，將第二支付請求轉發給具有該發碼機構標識的發碼機構的伺服器，供該發碼機構的伺服器根據付款帳戶資訊確定本次支付的付款帳戶，並從所述付款帳戶中扣款。
具體的，收單機構伺服器將第二支付請求發送給機構互連伺服器，機構互連伺服器在收到第二支付請求後，根據其中的發碼機構標識確定發碼機構，並且將第二支付請求轉發給所確定的發碼機構的伺服器。
在收單機構的伺服器與發碼機構的伺服器直接通信的應用場景中，收單機構的伺服器可以在第二支付請求中封裝發碼機構標識，也可以不在第二支付請求中封裝發碼機構標識。
如果第一支付請求中的發碼機構標識就是收單機構自己的發碼機構標識，則發碼機構的伺服器就是收單機構的伺服器，付款帳戶和收款方的帳戶都是在收單機構註冊的帳戶，收單機構的伺服器根據第一支付請求中的付款帳戶資訊確定本次支付的付款帳戶，並從所確定的付款帳戶中扣除本次支付的款項。
在發碼機構的伺服器上，步驟610，接收第二支付請求。第二支付請求中包括付款碼碼值中的發碼機構標識和付款帳戶資訊。
在發碼機構的伺服器上，步驟620，在確認接收的該發碼機構標識為本機構的發碼機構標識後，根據所述付款帳戶資訊確定本機構的一個帳戶作為付款帳戶，從所述付款帳戶扣款。
當發碼機構的伺服器接收到收款機構的伺服器發送的、攜帶有付款帳戶資訊但沒有攜帶發碼機構標識的第二支付請求後，根據其中的付款帳戶資訊確定本機構的一個帳戶作為付款帳戶，並從該付款帳戶扣款。
當發碼機構的伺服器接收到收款機構的伺服器發送的或機構互連伺服器發送的、攜帶有發碼機構標識的第二支付請求後，發碼機構的伺服器確認接收的該發碼機構標識為本機構的發碼機構標識後，根據第二支付請求中的付款帳戶資訊確定本機構的一個帳戶作為付款帳戶，從該付款帳戶扣款。如果第二支付請求中的發碼機構標識不是本機構的發碼機構標識，則發碼機構的伺服器不做處理，或者向發送第二支付請求的伺服器返回非本機構帳戶的通知訊息。
扣款操作完成後，發碼機構的伺服器向發送第二支付請求的伺服器返回扣款成功或扣款失敗的回應。如果第二支付請求是由機構互連伺服器轉發給發碼機構的伺服器，則機構互聯伺服器將扣款成功或扣款失敗的回應返回給收單機構的伺服器。收單機構的伺服器根據收到的回應向收款方設備返回支付成功或支付失敗的通知訊息。發碼機構的伺服器還可以向付款方終端發送支付成功或支付失敗的通知訊息。
可見，本說明書的實施例中，透過在付款碼碼值中攜帶發碼機構標識，在收款方設備向收單機構的伺服器上傳付款碼碼值後，收單機構的伺服器可以根據發碼機構標識確定發碼機構，由發碼機構的伺服器根據付款碼碼值中的付款帳戶資訊來確定付款帳戶，使得收單機構的伺服器能夠採用其他支付服務提供商的付款碼來完成支付過程，商戶只需與一個收單機構具有收單業務關係，就可以接收使用其他支付服務提供方的用戶的條碼支付，用戶也無需確認商戶是否支持自己使用的發碼機構，提高了商戶和用戶的支付效率，使商戶和用戶更為便利。
上述對本說明書特定實施例進行了描述。其它實施例在所附申請專利範圍的範圍內。在一些情况下，在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外，在圖式中描繪的過程不一定要求示出的特定順序或者連續順序才能實現期望的結果。在某些實施方式中，多任務處理和並行處理也是可以的或者可能是有利的。
在本說明書的第一個應用示例中，支付服務提供商PSP A、PSP B都採用圖7所示的付款碼碼值，分配給PSP A的發碼機構標識為28100100~28100199，分配給PSP B的發碼機構標識為28100600~28100699。
用戶A在PSP A開設有帳戶，在自己的終端上安裝了PSP A的用戶端App(應用程式)，PSP A的App中提供了基於條碼支付的功能。
用戶A與某個商戶交易時，希望用PSP A的App來進行支付。用戶A啓動基於條碼的支付功能後，App向PSP A的伺服器發送付款碼請求。PSP A成為用戶A在本次支付中的發碼機構。PSP A的伺服器根據在發送付款碼請求的App登錄的帳戶(即用戶A的帳戶)產生付款帳戶資訊，將PSP A的發碼機構標識和付款帳戶資訊按照圖7所示的格式組成付款碼碼值，將付款碼碼值封裝在對付款碼請求的回應中，發送給用戶A終端上的App。
假設本次支付的付款碼碼值為281001020123456789012345，其中28100102為PSP A的一個發碼機構標識，PSP A的伺服器可以將付款帳戶資訊0123456789012345對應於用戶A的帳戶。
用戶A終端上PSP A的App將付款碼碼值渲染為一維條碼和二維條碼，並顯示在螢幕上，提供給交易商戶的收款方設備掃描。
在第一種情形中，與用戶A交易的是商戶A，商戶A的收單機構為PSP A。這種情形下的支付流程如圖10所示。
商戶A的收款方設備將掃描後得到的付款碼碼值、本次支付的款項資訊、交易詳情封裝在第一支付請求中，發送給自己收單機構PSP A的伺服器。
PSP A的伺服器收到第一支付請求，從中提取出付款碼碼值中的發碼機構標識28100102，發現是本機構的發碼機構標識，則根據付款碼碼值中的付款帳戶資訊0123456789012345確定用戶A的帳戶為付款帳戶，並按照第一支付請求中的款項資訊從用戶A的帳戶中扣取相應的款項。
扣款成功後，PSP A的伺服器分別向商戶A的收款方設備和用戶A的App返回支付成功的訊息。
在第二種情形中，與用戶A交易的是商戶B，商戶B的收單機構為PSP B。PSP A的伺服器與PSP B的伺服器直接進行通信。在PSP B的伺服器上保存有各個發碼機構和分配給各個發碼機構標識的對應關係。這種情形下的支付流程如圖11所示。
商戶B的收款方設備將掃描後得到的付款碼碼值、本次支付的款項資訊、交易詳情封裝在第一支付請求中，發送給自己收單機構PSP B的伺服器。
PSP B的伺服器收到第一支付請求，從中提取出付款碼碼值中的發碼機構標識28100102，查詢保存的發碼機構標識與發碼機構的對應關係，發現是PSP A的發碼機構標識，則採用付款碼碼值、本次支付的款項資訊、交易詳情產生第二支付請求，並將第二支付請求發送給PSP A的伺服器。
PSP A的伺服器收到PSP B的伺服器發送的第二支付請求後，從中提取出付款碼碼值中的發碼機構標識28100102，確認是自己機構的發碼機構標識，則根據付款碼碼值中的付款帳戶資訊0123456789012345確定用戶A的帳戶為付款帳戶，並按照第二支付請求中的款項資訊從用戶A的帳戶中扣取相應的款項。
扣款成功後，PSP A的伺服器分別向PSP B的伺服器和用戶A的App返回支付成功的訊息。PSP B的伺服器向商戶B的收款方設備返回支付成功的訊息。
在第三種情形中，與用戶A交易的是商戶B，商戶B的收單機構為PSP B。機構互連伺服器分別與PSP A的伺服器和PSP B的伺服器直接進行通信。在PSP B的伺服器上保存有本機構的發碼機構標識和由機構互連伺服器進行轉發的發碼機構標識的對應關係，在機構互連伺服器上保存有各個發碼機構和分配給各個發碼機構標識的對應關係。這種情形下的支付流程如圖12所示。
商戶B的收款方設備將掃描後得到的付款碼碼值、本次支付的款項資訊、交易詳情封裝在第一支付請求中，發送給自己收單機構PSP B的伺服器。
PSP B的伺服器收到第一支付請求，從中提取出付款碼碼值中的發碼機構標識28100102，查詢後發現是由機構互連伺服器進行轉發的發碼機構標識，則採用付款碼碼值、本次支付的款項資訊、交易詳情產生第二支付請求，並將第二支付請求發送給機構互連伺服器。
機構互連伺服器收到第二支付請求，提取出付款碼碼值中的發碼機構標識28100102，查詢保存的發碼機構與發碼機構標識的對應關係表，發現是PSP A的發碼機構標識，則將第二支付請求轉發給PSP A的伺服器。
PSP A的伺服器收到機構互連伺服器轉發的第二支付請求後，從中提取出付款碼碼值中的發碼機構標識28100102，確認是自己機構的發碼機構標識，則根據付款碼碼值中的付款帳戶資訊0123456789012345確定用戶A的帳戶為付款帳戶，並按照第二支付請求中的款項資訊從用戶A的帳戶中扣取相應的款項。
扣款成功後，PSP A的伺服器分別向機構互連伺服器和用戶A的App返回支付成功的訊息。機構互連伺服器將支付成功的訊息轉發給PSP B的伺服器。PSP B的伺服器向商戶B的收款方設備返回支付成功的訊息。
應用示例二中，A國的支付服務提供商PSP A、B國的支付服務提供商PSP B都採用圖8所示的付款碼碼值，分配PSP A的發碼機構標識為610~612，分配給PSP B的發碼機構標識為100~105，分配給PSP B的收單機構標識為25~30。PSP A的伺服器與PSP B的伺服器透過機構互連伺服器進行通信。在PSP B的伺服器上保存有本機構的發碼機構標識和由機構互連伺服器進行轉發的發碼機構標識的對應關係，在機構互連伺服器上保存有各個發碼機構和分配給各個發碼機構標識的對應關係。
用戶A在PSP A開設有帳戶，在自己的終端上安裝了PSP A的用戶端App(應用程式)，PSP A的App中提供了基於條碼支付的功能。當用戶A在B國的實體商戶B處消費時，用其在PSP A的帳戶進行支付的流程如圖13所示。
用戶A啓動基於條碼的支付功能後，App向PSP A的伺服器發送付款碼請求。PSP A成為用戶A在本次支付中的發碼機構。PSP A的伺服器根據用戶A終端的定位資訊，得知用戶A在B國，按照在發送付款碼請求的App登錄的帳戶(即用戶A的帳戶)產生付款帳戶資訊，將PSP A的發碼機構標識、B國的PSP B的收單機構標識、和付款帳戶資訊按照圖8所示的格式組成付款碼碼值，將付款碼碼值封裝在對付款碼請求的回應中，發送給用戶A終端上的App。
假設本次支付的付款碼碼值為301610020123456789012345，其中前2位的30為PSP B的一個收單機構標識，第4到第6位的610為PSP A的一個發碼機構標識，第7到第8位的02表示業務類型為線下支付，PSP A的伺服器可以將第9到第24位的付款帳戶資訊0123456789012345對應於用戶A的帳戶。
用戶A終端上PSP A的App將付款碼碼值渲染為一維條碼和二維條碼，並顯示在螢幕上，提供給商戶B的收款方設備掃描。
商戶B的收款方設備掃描後得到付款碼碼值，從中提取出的收單機構標識30是PSP B的收單機構標識。商戶B的收款方設備將付款碼碼值、本次支付的款項資訊、交易詳情封裝在第一支付請求中，發送給PSP B的伺服器。
PSP B的伺服器收到第一支付請求，從中提取出付款碼碼值中的發碼機構標識610，查詢後發現是由機構互連伺服器進行轉發的發碼機構標識，則採用付款碼碼值、本次支付的款項資訊、交易詳情產生第二支付請求，並將第二支付請求發送給機構互連伺服器。
機構互連伺服器收到第二支付請求，提取出付款碼碼值中的發碼機構標識610，查詢保存的發碼機構與發碼機構標識的對應關係表，發現是PSP A的發碼機構標識，則將第二支付請求轉發給PSP A的伺服器。
PSP A的伺服器收到機構互連伺服器轉發的第二支付請求後，從中提取出付款碼碼值中的發碼機構標識610，確認是自己機構的發碼機構標識，則根據付款碼碼值中的付款帳戶資訊0123456789012345確定用戶A的帳戶為付款帳戶，並按照第二支付請求中的款項資訊從用戶A的帳戶中扣取相應的款項。
扣款成功後，PSP A的伺服器分別向機構互連伺服器和用戶A的App返回支付成功的訊息。機構互連伺服器將支付成功的訊息轉發給PSP B的伺服器。PSP B的伺服器向商戶B的收款方設備返回支付成功的訊息。
可見，採用圖7所示或圖8所示的付款碼碼值後，由於編碼格式十分簡潔，能夠支持渲染為一維條碼，從而兼容很多使用一維條碼掃碼槍的商戶，商戶無需升級設備即可從更多支付服務提供方的帳戶收款，尤其在跨境支付中極大的降低了商戶的接入成本。
與上述流程實現對應，本說明書的實施例還提供了一種應用在收款方設備上的基於條碼支付的實現裝置、一種應用在收款方設備上的基於條碼支付的實現裝置、一種應用在收單機構的伺服器上的基於條碼支付的實現裝置、和一種應用在發碼機構的伺服器上的基於條碼支付的實現裝置。上述裝置均可以透過軟體實現，也可以透過硬體或者軟硬體結合的方式實現。以軟體實現為例，作為邏輯意義上的裝置，是透過終端或伺服器的CPU(Central Process Unit，中央處理器)將對應的電腦程式指令讀取到記憶體中運行形成的。從硬體層面而言，除了圖14所示的CPU、記憶體以及記憶體之外，上述裝置所在的設備通常還包括用於進行無線信號收發的晶片等其他硬體，和/或用於實現網路通信功能的板卡等其他硬體。
圖15所示為本說明書實施例提供的一種基於條碼支付的實現裝置，應用在付款方終端上，所述裝置包括付款碼碼值獲取單元和付款碼展示單元，其中：付款碼碼值獲取單元用於獲取付款碼碼值，所述付款碼碼值包括發碼機構標識和付款帳戶資訊，所述付款帳戶資訊對應於具有所述發碼機構標識的發碼機構的一個帳戶；付款碼展示單元用於將所述付款碼碼值渲染為條碼後顯示，供收款方設備掃描後將發碼機構標識和付款帳戶資訊上傳給收單機構的伺服器，由收單機構的伺服器根據發碼機構標識確定發碼機構，由所述發碼機構的伺服器根據付款帳戶資訊確定用於本次支付的付款帳戶。
可選的，所述付款碼碼值獲取單元具體用於以下之一：由安裝在本地的所述發碼機構的用戶端軟體產生付款碼碼值；或，向所述發碼機構的伺服器發送付款碼請求，接收所述發碼機構的伺服器返回的付款碼碼值。
可選的，所述付款帳戶資訊包括：標記化處理後的帳戶標識和所述付款方終端的設備標識。
可選的，所述付款碼碼值為24至32位數字，其中發碼機構標識為前8位數字，付款帳戶資訊為後16至24位數字；發碼機構標識中的第1位數字為表示發碼機構所服務區域的區域碼。
一個例子中，所述付款碼碼值還包括：收單機構標識，用來由收款方設備確定上傳發碼機構標識和付款帳戶資訊的收單機構。
上述例子中，所述付款碼碼值為24位數字，其中收單機構標識為前2位數字，發碼機構標識為第4位到第6位數字，付款帳戶資訊為第9至第24位數字，第3位數字為付款碼碼值的版本號，第7到第8位數字為業務類型。
圖16所示為本說明書實施例提供的一種基於條碼支付的實現裝置，應用在收款方設備上，所述裝置包括付款碼掃描單元和第一支付請求發送單元，其中：付款碼掃描單元用於透過掃描付款方終端提供的付款碼獲取付款碼碼值，所述付款碼碼值包括發碼機構標識和付款帳戶資訊，所述付款帳戶資訊對應於具有所述發碼機構標識的發碼機構的一個帳戶；第一支付請求發送單元用於將包括所述發碼機構標識和付款帳戶資訊的第一支付請求發送給收單機構的伺服器，供收單機構的伺服器根據發碼機構標識確定發碼機構，由所述發碼機構的伺服器根據付款帳戶資訊確定用於本次支付的付款帳戶。
可選的，所述付款碼碼值為24至32位數字，其中發碼機構標識為前8位數字，付款帳戶資訊為後16至24位數字；發碼機構標識中的第1位數字為表示發碼機構所服務區域的區域碼。
一個例子中，所述付款碼碼值還包括：收單機構標識；所述第一支付請求發送單元具體用於：根據所述收單機構標識確定收單機構，將包括所述發碼機構標識和付款帳戶資訊的第一支付請求發送給所確定的收單機構的伺服器。
上述例子中，所述付款碼碼值為24位數字，其中收單機構標識為前2位數字，發碼機構標識為第4位到第6位數字，付款帳戶資訊為第9至第24位數字，第3位數字為付款碼碼值的版本號，第7到第8位數字為業務類型。
圖17所示為本說明書實施例提供的一種基於條碼支付的實現裝置，應用在收單機構的伺服器上，所述裝置包括第一支付請求接收單元和第二支付請求發送單元，其中：第一支付請求接收單元用於接收付款方設備發送的第一支付請求，所述第一支付請求中包括付款碼碼值中的發碼機構標識和付款帳戶資訊；第二支付請求發送單元用於當所述發碼機構標識不是本機構的發碼機構標識時，向具有所述發碼機構標識的發碼機構的伺服器發送第二支付請求，所述第二支付請求中包括所述付款帳戶資訊，供發碼機構的伺服器根據所述付款帳戶資訊確定本次支付的付款帳戶，並從所述付款帳戶中扣款。
可選的，所述第二支付請求中還包括所述發碼機構標識；所述第二支付請求發送單元具體用於：當所述發碼機構標識不是本機構的發碼機構標識時，將第二支付請求發送給機構互連伺服器，由機構互連伺服器將第二支付請求轉發給具有所述發碼機構標識的發碼機構的伺服器。
可選的，所述裝置還包括：第一支付請求處理單元，用於當所述發碼機構標識為本機構的發碼機構標識時，根據所述付款帳戶資訊確定本次支付的付款帳戶，並從所述付款帳戶中扣款。
可選的，所述第一支付請求中包括付款碼碼值；所述付款碼碼值為24至32位數字，其中發碼機構標識為前8位數字，付款帳戶資訊為後16至24位數字；發碼機構標識中的第1位數字為表示發碼機構所服務區域的區域碼。
可選的，所述第一支付請求中包括付款碼碼值；所述付款碼碼值為24位數字，其中收單機構標識為前2位數字，發碼機構標識為第4位到第6位數字，付款帳戶資訊為第9至第24位數字，第3位數字為付款碼碼值的版本號，第7到第8位數字為業務類型。
圖18所示為本說明書實施例提供的一種基於條碼支付的實現裝置，應用在發碼機構的伺服器上，所述裝置包括第二支付請求接收單元和第二支付請求處理單元，其中：第二支付請求接收單元用於接收第二支付請求，所述第二支付請求中包括付款碼碼值中的發碼機構標識和付款帳戶資訊；第二支付請求處理單元用於在確認所述發碼機構標識為本機構的發碼機構標識後，根據所述付款帳戶資訊確定本機構的一個帳戶作為付款帳戶，從所述付款帳戶扣款。
可選的，所述第二支付請求接收單元具體用於以下之一：接收收單機構的伺服器發送的第二支付請求；或，接收機構互連伺服器轉發的第二支付請求，所述第二支付請求由收單機構的伺服器發送給機構互連伺服器。
可選的，所述第二支付請求中包括付款碼碼值；所述付款碼碼值為24至32位數字，其中發碼機構標識為前8位數字，付款帳戶資訊為後16至24位數字；發碼機構標識中的第一位數字為表示發碼機構所服務區域的區域碼。
可選的，所述第二支付請求中包括付款碼碼值；所述付款碼碼值為24位數字，其中收單機構標識為前2位數字，發碼機構標識為第4位到第6位數字，付款帳戶資訊為第9至第24位數字，第3位數字為付款碼碼值的版本號，第7到第8位數字為業務類型。
可選的，所述裝置還包括：付款碼碼值下發單元，用於在收到付款方終端的付款碼請求後，根據使用所述付款方終端的帳戶產生付款帳戶資訊，向所述付款方終端返回包括所述付款帳戶資訊和本機構的發碼機構標識的付款碼碼值。
圖19所示為本說明書實施例提供的一種基於條碼支付的實現裝置，應用在機構互連伺服器上，所述裝置包括第二支付請求中轉單元和第二支付請求轉發單元，其中：第二支付請求中轉單元用於接收收單機構的伺服器發送的第二支付請求，所述第二支付請求中包括付款碼碼值中的發碼機構標識和付款帳戶資訊；第二支付請求轉發單元用於將第二支付請求轉發給具有所述發碼機構標識的發碼機構的伺服器，供所述發碼機構的伺服器根據所述付款帳戶資訊確定本次支付的付款帳戶，並從所述付款帳戶中扣款。
可選的，所述付款碼碼值為24至32位數字，其中發碼機構標識為前8位數字，付款帳戶資訊為後16至24位數字；發碼機構標識中的第1位數字為表示發碼機構所服務區域的區域碼。
可選的，所述付款碼碼值為24位數字，其中收單機構標識為前2位數字，發碼機構標識為第4位到第6位數字，付款帳戶資訊為第9至第24位數字，第3位數字為付款碼碼值的版本號，第7到第8位數字為業務類型。
本說明書的實施例提供了一種電腦設備，該電腦設備包括記憶體和處理器。其中，記憶體上儲存有能夠由處理器運行的電腦程式；處理器在運行儲存的電腦程式時，執行本說明書實施例中應用在用戶終端上的基於條碼支付的實現方法的各個步驟。對應用在用戶終端上的基於條碼支付的實現方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本說明書的實施例提供了一種電腦設備，該電腦設備包括記憶體和處理器。其中，記憶體上儲存有能夠由處理器運行的電腦程式；處理器在運行儲存的電腦程式時，執行本說明書實施例中應用在收款方設備上的基於條碼支付的實現方法的各個步驟。對應用在收款方設備上的基於條碼支付的實現方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本說明書的實施例提供了一種電腦設備，該電腦設備包括記憶體和處理器。其中，記憶體上儲存有能夠由處理器運行的電腦程式；處理器在運行儲存的電腦程式時，執行本說明書實施例中應用在收單機構的伺服器上的基於條碼支付的實現方法的各個步驟。對應用在收單機構的伺服器上的基於條碼支付的實現方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本說明書的實施例提供了一種電腦設備，該電腦設備包括記憶體和處理器。其中，記憶體上儲存有能夠由處理器運行的電腦程式；處理器在運行儲存的電腦程式時，執行本說明書實施例中應用在發碼機構的伺服器上的基於條碼支付的實現方法的各個步驟。對應用在發碼機構的伺服器上的基於條碼支付的實現方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本說明書的實施例提供了一種電腦設備，該電腦設備包括記憶體和處理器。其中，記憶體上儲存有能夠由處理器運行的電腦程式；處理器在運行儲存的電腦程式時，執行本說明書實施例中應用在機構互連伺服器上的基於條碼支付的實現方法的各個步驟。對應用在機構互連伺服器上的基於條碼支付的實現方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本說明書的實施例提供了一種電腦可讀儲存媒體，該儲存媒體上儲存有電腦程式，這些電腦程式在被處理器運行時，執行本說明書實施例中應用在用戶終端上的基於條碼支付的實現方法的各個步驟。對應用在用戶終端上的基於條碼支付的實現方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本說明書的實施例提供了一種電腦可讀儲存媒體，該儲存媒體上儲存有電腦程式，這些電腦程式在被處理器運行時，執行本說明書實施例中應用在收款方設備上的基於條碼支付的實現方法的各個步驟。對應用在收款方設備上的基於條碼支付的實現方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本說明書的實施例提供了一種電腦可讀儲存媒體，該儲存媒體上儲存有電腦程式，這些電腦程式在被處理器運行時，執行本說明書實施例中應用在收單機構的伺服器上的基於條碼支付的實現方法的各個步驟。對應用在收單機構的伺服器上的基於條碼支付的實現方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本說明書的實施例提供了一種電腦可讀儲存媒體，該儲存媒體上儲存有電腦程式，這些電腦程式在被處理器運行時，執行本說明書實施例中應用在發碼機構的伺服器上的基於條碼支付的實現方法的各個步驟。對應用在發碼機構的伺服器上的基於條碼支付的實現方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本說明書的實施例提供了一種電腦可讀儲存媒體，該儲存媒體上儲存有電腦程式，這些電腦程式在被處理器運行時，執行本說明書實施例中應用在機構互連伺服器上的基於條碼支付的實現方法的各個步驟。對應用在機構互連伺服器上的基於條碼支付的實現方法的各個步驟的詳細描述請參見之前的內容，不再重複。
圖20所示為本說明書的實施例提供了一種基於條碼支付的系統，包括收單機構的伺服器、機構互連伺服器和發碼機構的伺服器，其中：收單機構的伺服器用於接收付款方設備發送的、包括付款碼碼值中的發碼機構標識和付款帳戶資訊的第一支付請求，當所述發碼機構標識不是本機構的發碼機構標識時，向機構互連伺服器發送攜帶有所述發碼機構標識和付款帳戶資訊的第二支付請求；機構互連伺服器用於接收收單機構的伺服器發送的包括發碼機構標識和付款帳戶資訊的第二支付請求，並將所述第二支付請求轉發給具有所述發碼機構標識的發碼機構的伺服器；發碼機構的伺服器用於接收機構互連伺服器發送的包括發碼機構標識和付款帳戶資訊第二支付請求，在確認所述發碼機構標識為本機構的發碼機構標識後，根據所述付款帳戶資訊確定本機構的一個帳戶作為付款帳戶，從所述付款帳戶扣款。
可選的，所述付款碼碼值為24至32位數字，其中發碼機構標識為前8位數字，付款帳戶資訊為後16至24位數字；發碼機構標識中的第1位數字為表示發碼機構所服務區域的區域碼。
可選的，所述付款碼碼值為24位數字，其中收單機構標識為前2位數字，發碼機構標識為第4位到第6位數字，付款帳戶資訊為第9至第24位數字，第3位數字為付款碼碼值的版本號，第7到第8位數字為業務類型。
以上所述僅為本說明書的較佳實施例而已，並不用以限制請求保護的其他實施例，凡在本說明書的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在請求保護的範圍之內。
在一個典型的配置中，計算設備包括一個或多個處理器(CPU)、輸入/輸出接口、網路接口和記憶體。
記憶體可能包括電腦可讀媒體中的非永久性記憶體，隨機存取記憶體 (RAM)和/或非揮發性記憶體等形式，如唯讀記憶體(ROM)或快閃記憶體(flash RAM)。記憶體是電腦可讀媒體的示例。
電腦可讀媒體包括永久性和非永久性、可移除和非可移除媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。電腦的儲存媒體的例子包括，但不限於相變記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可抹除可程式化唯讀記憶體(EEPROM)、快閃記憶體或其他記憶體技術、唯讀光碟唯讀記憶體(CD-ROM)、數位多功能光碟(DVD)或其他光學儲存、磁盒式磁帶，磁帶磁碟儲存或其他磁性儲存設備或任何其他非傳輸媒體，可用於儲存可以被計算設備存取的資訊。按照本文中的界定，電腦可讀媒體不包括暫存電腦可讀媒體(transitory media)，如調變的資料信號和載波。
還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情况下，由語句“包括一個……”限定的要素，並不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。
本領域技術人員應明白，本說明書的實施例可提供為方法、系統或電腦程式產品。因此，本說明書的實施例可採用完全硬體實施例、完全軟體實施例或結合軟體和硬體方面的實施例的形式。而且，本說明書的實施例可採用在一個或多個其中包含有電腦可用程式代碼的電腦可用儲存媒體(包括但不限於磁碟記憶體、CD-ROM、光學記憶體等)上實施的電腦程式產品的形式。The embodiment of this specification proposes a new method for implementing barcode-based payment. The payer’s terminal shows the payee a payment code carrying the code issuing institution’s identification and payment account information. The payee’s acquiring institution receives the payment After the code issuing agency ID and payment account information uploaded by the party’s device, a second payment request including the payment account information is sent to the server of the code issuing agency with the code issuing agency’s ID, and the server of the code issuing agency will Use the payer's account of the payer's terminal as the payment account for payment. In this way, merchants only need to have an acquiring business relationship with an acquirer to receive barcode payments from users who use other payment service providers, and users do not need to confirm whether the merchant supports their own code issuing organization, which improves merchants and users. The payment efficiency makes it more convenient for users and merchants to pay. In the embodiment of this specification, the payment process is that the payer shows the payment code to the payee, and the payee receives the payment by scanning the payment code. The payment code can be a one-dimensional barcode, a two-dimensional barcode, a combination of one-dimensional and two-dimensional barcodes, or a combination of two or more one-dimensional and/or two-dimensional barcodes encoded with different symbologies. The embodiment of the specification does not limit the number of barcodes and the code system in the payment code. In the embodiment of this specification, the payer has an account with a payment service provider. When the payer wants to make a certain payment with the account, the payer’s terminal will show that the payment service provider’s rules are based on the payment. The payment code generated by the party account. The payment service provider becomes the code issuing institution in this payment, and the payer's account becomes the payment account in this payment. If the payee has an account with a certain payment service provider, and the payee has a payment code payment acquiring business relationship with the payment service provider, the payment service provider can act as the payee's acquirer . The payee can have two or more acquirers. When the payee scans the payment code and sends a payment request to the server of a payment service provider in a certain payment, the payment service provider that receives the payment request The party becomes the acquirer in this payment, and the payee's account with the acquirer becomes the receiving account in this payment. In the embodiment of this specification, the payee device can scan the payment code displayed on the payer terminal, the payee device can communicate with the server of the acquirer, and the server of the acquirer can directly or through other networks The node indirectly communicates with the server of the code issuing agency, and the payer terminal can either be offline or communicate with the server of the code issuing agency. In an example, the first network structure of the application scenario of the embodiment of this specification is shown in Figure 1. The payer's terminal can communicate with the server of the code issuing agency through the network, and the payee's device can scan the payer's terminal With the payment code shown above, the payee’s device and the server of the acquirer communicate through the network, and the server of the acquirer and the server of the code issuer communicate directly through the network. In another example, the first network structure of the application scenario of the embodiment of this specification is shown in Figure 1. The payer's terminal and the server of the code issuer communicate through the network, and the payee's device can scan the payer's terminal For the payment code shown above, the payee’s device communicates with the server of the acquirer through the network, and the server of the acquirer and the server of the code issuing organization communicate directly with the institution interconnect server through the network. The agency interconnection server can forward information between the server of the acquiring agency and the server of the code issuing agency. Among them, the payer’s terminal can be a mobile phone, tablet, PC (Personal Computer, personal computer), notebook computer, etc.; the payee’s device can be one device or two or more devices with scanning, computing and storage functions. Combinations, such as mobile phones, tablets, code scanners and PCs, notebooks and other equipment; the server of the code issuing agency, the server of the acquiring agency, or the agency interconnection server can be a physical or logical server, or It is composed of two or more physical or logical servers that share different responsibilities and cooperate with each other to realize the functions of the server of the code issuing organization, the server of the acquiring organization, or the server of the organization interconnection in the embodiments of this specification. . In the embodiments of this specification, the process of applying the barcode-based payment method to the payer’s terminal is shown in Figure 3, and the process of applying the payee’s device to the payee’s device is shown in Figure 4, which is applied to the server of the acquirer. The above process is shown in Figure 5, and the process applied to the server of the code issuing mechanism is shown in Figure 6. On the payer's terminal, step 310, obtain the payment code value. The code value of the payment code includes the code issuer identification and payment account information, and the payment account information corresponds to an account of the code issuer having the code issuer identification. In the embodiment of this specification, the code value of the payment code includes the code issuing institution identification and the payment account information. Among them, the code issuing agency ID uniquely represents a payment service provider that provides services to the payer. Each payment service provider can determine the code issuing agency for this payment according to the code issuing agency ID; the payment account information can be determined by the code issuing agency Used to identify an account of this institution. The code issuing organization identification in the payment code value is usually in the form of plain text, so that the server of any acquiring organization can identify the originating code organization. The payment account information in the payment code value can be determined by the code issuer itself, as long as the code issuer can uniquely correspond to an account of the institution. Generally, the payment account information includes the tokenized payer’s account identification; it may also include some verification information (such as the tokenized payer’s terminal device identification) and other information. Among them, the account ID can be any information that can uniquely represent an account in the code issuing organization, such as one or more of the account name, account number, account index, etc.; the device ID can be any information that can uniquely correspond to the payer's terminal Hardware identification or software identification, such as the serial number of the mobile device, MAC (Media Access Control Address, Media Access Control) address, IMEI (International Mobile Equipment Identity, International Mobile Equipment Identity), etc.; tokenization can be any type It can hide the processing methods of plaintext private information, such as encryption. In some application scenarios, the acquiring institution identification can be included in the payment code value. The acquiring institution identification can be used by the payee device to determine the acquiring institution for this payment, that is, the payee device will identify the issuing institution And the server of which acquirer the payment account information is uploaded to. In this way, the code issuing agency can designate an acquirer to the payee or recommend a preferred acquirer to the payee. It should be noted that the acquirer identity can be an identity exclusive to a certain payment service provider (that is, the identity of the payment service provider itself); it can also be an identity of an internet network joined by a certain payment service provider. In the Internet, any payment service provider can act as the acquirer for all payment service providers’ accounts when paying, so that the identity of the Internet can be used as the payment service provider for all payment service providers that join the Internet. Single institution identification. In addition, you can also carry other information in the payment code code value, such as the version number of the payment code code value, which is used to indicate which encoding format the payment code code value adopts; and the type of business is used to indicate that the payment code is used What is the business performed by the code value? The embodiment of this specification does not limit the encoding format of the payment code code value. The encoding format includes the characters (letters, numbers, symbols, etc.) used in the code value of the payment code, the length of the characters occupied by the various information carried, and the order of arrangement, etc. The following gives two examples of the encoding format of the payment code code value. In the first example, the code value of the payment code adopts a full-digit format, with a length of 24 to 32 bits, and each bit can be a number from 0 to 9. The code value of this kind of payment code is composed of a code issuing agency ID with a fixed length of 8 digits and payment account information with a variable length from 16 to 24 digits. The code issuing agency ID is the first 8 digits, and the payment account information is the last 16 digits. Up to 24 digits, the first digit in the ID of the issuing agency is the area code that represents the area served by the issuing agency. As shown in Figure 7, the first to eighth digits of the code value of the payment code are the identification of the code issuing organization, and the ninth to the last digits are the payment account information. The first digit in the ID of the code issuing agency is the area code. The area code is determined according to the area where the payment service provider conducts the main business. An exemplary allocation method is shown in Table 1: One or more code issuing agency IDs can be assigned to a payment service provider. For example, 28100100~28100199 can be assigned to payment service provider PSP A, 28100600~28100699 can be assigned to payment service provider PSP B, and 28100600~28100699 can be assigned To the payment service provider PSP C, 40100100 is allocated to the payment service provider PSP D. The code value of the payment code in this example can be displayed as a one-dimensional barcode, so that a large number of merchants who use one-dimensional barcode scanners can support more code issuing agencies without upgrading their hardware equipment. In the second example, the payment code value includes the acquirer's identity, in addition to the version number and service type of the payment code value. The payment code value in this example uses a full-digit format, with a length of 24 digits, of which 3 digits are the ID of the issuing institution, 16 digits are the payment account information, 2 digits are the ID of the acquirer, and 1 digit is the code value of the payment code. The version number and 2 digits are business types, and each bit can be a number from 0 to 9. As shown in Figure 8, the code value of the payment code is 24 digits, where the acquirer ID is the first digit to the second digit, the version number of the payment code code value is the third digit, and the code issuing agency ID is the first digit. 4 to 6 digits, business type is 7 to 8 digits, payment account information is 9 to 24 digits. The payer terminal can use various forms to obtain the payment code value, which is not limited in the embodiment of this specification. For example, the payment code value can be generated by the client software of a certain code issuing agency installed locally on the payer’s terminal, and the generated payment code code value carries the code issuer’s identification and can be registered in the client software. The account of is used as the payment account information for the payment account. For another example, the payer’s terminal can also initiate a payment code request to the server of a certain code issuer. After receiving the payment code request from the payer’s terminal, the server of the code issuer will use the payer’s terminal’s account Generate payment account information, and return the payment code value including the generated payment account information and the code issuing agency ID of the institution to the payer terminal. In addition, the above two methods can also be combined. When the payer's terminal is online, the payment code value is obtained by requesting the code issuing agency's server; when the payer's terminal is offline, the local sender Code agency client software to generate payment code value. On the payer’s terminal, in step 320, the value of the payment code is rendered as a bar code and displayed for the payee’s device to scan and upload the code issuing institution’s identification and payment account information to the acquirer’s server. The server determines the code issuing agency according to the code issuing agency ID, and the server of the code issuing agency determines the payment account used for this payment according to the payment account information. On the payee device, in step 410, the payment code value is obtained by scanning the payment code provided by the payer terminal. The payer terminal renders the obtained payment code code value as a payment code. The payment code can be one or more barcodes, such as a one-dimensional barcode, a two-dimensional barcode, or a combination of a one-dimensional barcode and a two-dimensional barcode. The payer’s terminal displays the payment code on the screen for the payee’s device to scan. The payee device obtains the payment code value after scanning the payment code displayed on the payer terminal. On the payee's device, in step 420, the first payment request including the code issuing agency ID and payment account information is sent to the server of the acquiring agency, so that the server of the acquiring agency determines the issuing agency according to the ID of the issuing agency , The server of the determined code issuing agency determines the payment account used for this payment according to the payment account information. On the server of the acquirer, in step 510, the first payment request sent by the payer's device is received. The first payment request includes the code issuing agency identification and payment account information in the payment code code value. The payee device encapsulates the code issuing institution identification and payment account information in the payment code value in the first payment request, and sends it to the server of the acquiring institution. The payee device may encapsulate the complete payment code value in the first payment request. The payee device can also encapsulate the account information of the payee at the acquiring institution in the first payment request, the payment information used to determine the payment amount (such as the amount, or the amount and currency), and the transaction describing the current transaction Information and other information. The embodiments of this specification are not limited. For the application scenario where the payment code value includes the acquirer identification, the payee device extracts the acquirer identification in the payment code value, determines the acquirer based on the extracted acquirer identification, and sends the first payment request to The server of the acquirer with the identifier of the acquirer. After receiving the first payment request, the server of the acquiring institution can extract the code issuing institution identification of the payment code, payment account information, and other information from it. On the server of the acquiring institution, in step 520, when the identity of the issuing institution is not the identity of the issuing institution of the institution, a second payment request is sent to the server of the issuing institution, and the second payment request includes Payment account information. The server of the code issuing agency determines the payment account for this payment based on the payment account information, and deducts the payment from the payment account. The server of the acquiring institution determines whether the code issuing institution identification in the first payment request is the code issuing institution identification of the institution. If not, the server of other institutions is required to interpret the payment account information. The server of the acquiring institution encapsulates the payment account information in the first payment request in the second payment request, and sends the second payment request to the server of the code issuing institution with the code issuing institution identifier. If the first payment request carries the complete payment code value, the server of the acquirer may encapsulate the complete payment code value in the second payment request. The server of the acquirer may also encapsulate one or more of the payment information, transaction information and other information of the current payment in the first payment request in the second payment request. In an application scenario where the server of the acquiring institution and the server of the code issuing institution respectively communicate directly with the institution interconnect server, the second payment request needs to carry the code issuing institution identifier from the first payment request, and the second payment request The payment request will be forwarded to the server of the code issuing institution with the code issuing institution's identification through the institution interconnection server. In this application scenario, the flow of the implementation method of barcode-based payment applied to the institutional interconnection server is shown in Figure 9. On the institution interconnection server, step 910, the second payment request sent by the server of the acquiring institution is received. The second payment request includes the code issuer identification and payment account information in the payment code value. On the institution interconnection server, in step 920, the second payment request is forwarded to the server of the code issuing institution with the code issuing institution identification, so that the server of the code issuing institution determines the payment for this payment according to the payment account information Account and debit the payment account. Specifically, the acquiring institution server sends the second payment request to the institution interconnection server. After receiving the second payment request, the institution interconnection server determines the code issuing institution according to the code issuing institution identifier therein, and sends the second payment request to the institution interconnection server. 2. The payment request is forwarded to the server of the determined code issuing agency. In the application scenario where the server of the acquiring institution communicates directly with the server of the code issuing institution, the server of the acquiring institution may encapsulate the code issuing institution identification in the second payment request, or may not encapsulate the issuing institution identifier in the second payment request. Code organization ID. If the code issuing agency ID in the first payment request is the acquiring agency’s own code issuing agency ID, then the server of the issuing agency is the server of the acquiring agency, and the payment account and the payee’s account are both in the acquirer For the account registered by the institution, the server of the acquiring institution determines the payment account for this payment according to the payment account information in the first payment request, and deducts the payment for this payment from the determined payment account. On the server of the code issuing agency, step 610, the second payment request is received. The second payment request includes the code issuer identification and payment account information in the payment code value. On the server of the code issuing institution, in step 620, after confirming that the received code issuing institution identification is the code issuing institution identification of the institution, an account of this institution is determined as the payment account according to the payment account information, and The payment account is debited. When the server of the code issuing institution receives the second payment request sent by the server of the receiving institution that carries the payment account information but does not carry the code issuing institution’s identification, it determines an account of this institution as Payment account, and debit the payment account. When the server of the code issuing institution receives the second payment request sent by the server of the receiving institution or sent by the server of the institution interconnection and carrying the identity of the issuing institution, the server of the code issuing institution confirms the receipt of the payment request. After the code institution identifier is the code issuing institution identifier of the institution, an account of the institution is determined as the payment account according to the payment account information in the second payment request, and the payment account is deducted from the payment account. If the ID of the issuing agency in the second payment request is not the ID of the issuing agency of the agency, the server of the issuing agency will not process it, or the server that sent the second payment request will return a notification message of a non-organizational account. After the deduction operation is completed, the server of the code issuing institution returns a response of successful deduction or failure of deduction to the server that sent the second payment request. If the second payment request is forwarded by the institution interconnection server to the server of the issuing institution, the institution interconnection server returns a response of successful deduction or failure of deduction to the server of the acquiring institution. The server of the acquirer returns a notification message of payment success or failure to the payee device according to the received response. The server of the code issuing agency may also send a notification message of payment success or failure to the payer terminal. It can be seen that, in the embodiment of this specification, by carrying the identification of the code issuing institution in the code value of the payment code, after the payee device uploads the code value of the payment code to the server of the acquiring institution, the server of the acquiring institution can The code institution identification determines the code issuing institution, and the server of the code issuing institution determines the payment account according to the payment account information in the payment code value, so that the server of the acquiring institution can use the payment code of other payment service providers to complete the payment In the process, merchants only need to have an acquiring business relationship with an acquirer to receive barcode payments from users who use other payment service providers, and users do not need to confirm whether the merchant supports their own code issuing organization, which improves merchants and users. The payment efficiency makes it more convenient for merchants and users. The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the attached patent application. In some cases, the actions or steps described in the scope of the patent application may be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous. In the first application example of this manual, the payment service providers PSP A and PSP B both use the payment code code value shown in Figure 7. The code issuing agency ID assigned to PSP A is 28100100~28100199, which is assigned to PSP B The code issuing agency ID is 28100600~28100699. User A opens an account with PSP A, installs PSP A's client App (application) on his terminal, and PSP A's App provides a barcode-based payment function. When user A trades with a certain merchant, he hopes to use PSP A's App to make payment. After user A activates the barcode-based payment function, the App sends a payment code request to the server of PSP A. PSP A becomes user A's code issuing agency in this payment. The server of PSP A generates payment account information according to the account registered in the App that sent the payment code request (ie user A’s account), and composes the payment code with the code issuing agency ID and payment account information of PSP A according to the format shown in Figure 7 Code value, encapsulate the payment code code value in the response to the payment code request, and send it to the App on the user A terminal. Assuming that the payment code value of this payment is 281001020123456789012345, where 28100102 is the ID of a code issuing agency of PSP A, the server of PSP A can correspond the payment account information 0123456789012345 to user A's account. The PSP A App on the user A terminal renders the payment code value into a one-dimensional bar code and a two-dimensional bar code, and displays it on the screen, and provides it to the merchant’s payee device to scan. In the first scenario, merchant A is trading with user A, and the acquiring institution of merchant A is PSP A. The payment process in this case is shown in Figure 10. The payee device of merchant A encapsulates the scanned payment code value, the payment information of this payment, and the transaction details in the first payment request, and sends it to the server of its own acquirer PSP A. The server of PSP A receives the first payment request and extracts the code issuing agency ID 28100102 from the payment code value. If it is found to be the agency’s code issuing agency ID, it will be determined according to the payment account information 0123456789012345 in the payment code value. The user A’s account is a payment account, and the corresponding money is deducted from the user A’s account according to the payment information in the first payment request. After the deduction is successful, the server of PSP A returns a payment success message to merchant A's payee device and user A's App. In the second scenario, merchant B is trading with user A, and the acquirer of merchant B is PSP B. The server of PSP A communicates directly with the server of PSP B. The corresponding relationship between each code issuing organization and the identification assigned to each code issuing organization is stored on the server of PSP B. The payment process in this case is shown in Figure 11. Merchant B's payee device encapsulates the scanned payment code value, the payment information of this payment, and the transaction details in the first payment request, and sends it to the server of its acquirer PSP B. The server of PSP B receives the first payment request, extracts the code issuing agency ID 28100102 from the payment code value, and inquires about the correspondence between the saved code issuing agency ID and the code issuing agency, and finds that it is the code issuing agency of PSP A For the identification, the payment code value, the payment information of this payment, and the transaction details are used to generate a second payment request, and the second payment request is sent to the server of PSP A. After the server of PSP A receives the second payment request sent by the server of PSP B, it extracts the code issuing agency ID 28100102 in the payment code value, and confirms that it is the code issuing agency ID of its own institution, then according to the payment code code The payment account information 0123456789012345 in the value determines that the account of user A is a payment account, and the corresponding payment is deducted from the account of user A according to the payment information in the second payment request. After the deduction is successful, the server of PSP A returns a payment success message to the server of PSP B and the App of user A respectively. The server of PSP B returns a payment success message to the recipient's device of merchant B. In the third scenario, merchant B is trading with user A, and the acquirer of merchant B is PSP B. The agency interconnection server communicates directly with the server of PSP A and the server of PSP B, respectively. The corresponding relationship between the code-issuing agency ID of this institution and the code-issuing agency ID forwarded by the agency interconnection server is stored on the server of PSP B. The agency interconnection server stores each code issuing agency and its distribution to Correspondence of each code issuing agency ID. The payment process in this case is shown in Figure 12. Merchant B's payee device encapsulates the scanned payment code value, the payment information of this payment, and the transaction details in the first payment request, and sends it to the server of its acquirer PSP B. The server of PSP B receives the first payment request and extracts the code issuing institution ID 28100102 from the payment code value. After querying, it is found that the code issuing agency ID is forwarded by the institution interconnection server, and the payment code is used. The value, the payment information of this payment, and the transaction details generate a second payment request, and send the second payment request to the institutional interconnection server. The institution interconnection server receives the second payment request, extracts the code issuing institution ID 28100102 in the payment code value, and inquires the saved correspondence table of the code issuing institution and the code issuing institution ID, and finds that it is the code issuing institution of PSP A ID, the second payment request is forwarded to the server of PSP A. After receiving the second payment request forwarded by the institution interconnection server, the PSP A server extracts the code issuing institution ID 28100102 from the payment code value, confirming that it is the code issuing institution ID of its own institution, and then according to the payment code code The payment account information 0123456789012345 in the value determines that the account of user A is a payment account, and the corresponding payment is deducted from the account of user A according to the payment information in the second payment request. After the deduction is successful, the server of PSP A returns a payment success message to the organization interconnection server and the App of user A respectively. The agency interconnection server forwards the payment success message to the PSP B server. The server of PSP B returns a payment success message to the recipient's device of merchant B. In application example two, the payment service provider PSP A in country A and the payment service provider PSP B in country B both use the payment code value shown in Figure 8. The code issuing agency ID of PSP A is assigned 610~612, The ID of the issuing agency for PSP B is 100~105, and the ID of the acquiring agency allocated to PSP B is 25~30. The server of PSP A and the server of PSP B communicate through the mechanism interconnection server. The corresponding relationship between the code-issuing agency ID of this institution and the code-issuing agency ID forwarded by the agency interconnection server is stored on the server of PSP B. The agency interconnection server stores each code issuing agency and its distribution to Correspondence of each code issuing agency ID. User A opens an account with PSP A, installs PSP A's client App (application) on his terminal, and PSP A's App provides a barcode-based payment function. When a user A spends at a physical merchant B in country B, the process of making a payment with his account in PSP A is shown in Figure 13. After user A activates the barcode-based payment function, the App sends a payment code request to the server of PSP A. PSP A becomes user A's code issuing agency in this payment. The server of PSP A knows that user A is in country B based on the location information of user A’s terminal, and generates payment account information according to the account (ie user A’s account) logged in the App that sent the payment code request, and sends the code to PSP A The organization ID, PSP B’s acquirer ID of country B, and the payment account information compose the payment code value according to the format shown in Figure 8. The payment code value is encapsulated in the response to the payment code request and sent to user A App on the terminal. Assuming that the payment code value of this payment is 301610020123456789012345, the first 2 digits 30 is an acquirer ID of PSP B, the 4th to 6th 610 is a code issuing agency ID of PSP A, and the 7th to the 6th digits are The 8-digit 02 indicates that the service type is offline payment, and the server of PSP A can correspond the payment account information 0123456789012345 in the 9th to 24th digits to user A's account. The App of PSP A on User A’s terminal renders the payment code value into a one-dimensional bar code and a two-dimensional bar code, and displays it on the screen, and provides it to merchant B’s payee device to scan. Merchant B's payee device scans and obtains the payment code value, and the acquirer identifier 30 extracted therefrom is the acquirer identifier of PSP B. The payee device of merchant B encapsulates the payment code value, the payment information of this payment, and the transaction details in the first payment request, and sends it to the server of PSP B. The server of PSP B receives the first payment request and extracts the code issuing agency ID 610 from the payment code value. After querying, it is found that the code issuing agency ID is forwarded by the agency interconnection server, and then the payment code code is used The value, the payment information of this payment, and the transaction details generate a second payment request, and send the second payment request to the institutional interconnection server. The institution interconnection server receives the second payment request, extracts the code issuing institution ID 610 in the payment code value, and queries the saved correspondence table of the code issuing institution and the code issuing institution ID, and finds that it is the code issuing institution of PSP A ID, the second payment request is forwarded to the server of PSP A. After receiving the second payment request forwarded by the agency interconnection server, the server of PSP A extracts the code issuing agency ID 610 from the payment code value, and confirms that it is the agency ID of its own institution, then according to the payment code code The payment account information 0123456789012345 in the value determines that the account of user A is a payment account, and the corresponding payment is deducted from the account of user A according to the payment information in the second payment request. After the deduction is successful, the server of PSP A returns a payment success message to the organization interconnection server and the App of user A respectively. The agency interconnection server forwards the payment success message to the PSP B server. The server of PSP B returns a payment success message to the recipient's device of merchant B. It can be seen that after the payment code value shown in Figure 7 or Figure 8 is adopted, because the encoding format is very simple, it can support rendering as a one-dimensional barcode, which is compatible with many merchants who use one-dimensional barcode scanners, and merchants do not need to upgrade their equipment. You can collect money from more payment service providers' accounts, especially in cross-border payments, which greatly reduces the merchant's access cost. Corresponding to the implementation of the above process, the embodiments of this specification also provide a barcode-based payment implementation device that is applied to the payee device, a barcode-based payment implementation device that is applied to the payee device, and an application that is used on the payee device. A device for implementing barcode-based payment on a server of a single institution, and a device for implementing barcode-based payment on a server of a code issuing institution. The above-mentioned devices can be realized through software, or through hardware or a combination of software and hardware. Take software implementation as an example. As a logical device, it is formed by reading the corresponding computer program instructions into the memory through the CPU (Central Process Unit, central processing unit) of the terminal or server. From the perspective of hardware, in addition to the CPU, memory, and memory shown in Figure 14, the equipment where the above-mentioned devices are located usually includes other hardware such as chips for wireless signal transmission and reception, and/or implementation Other hardware such as boards for network communication functions. Figure 15 shows a device for implementing barcode-based payment according to an embodiment of this specification, which is applied to a payer's terminal. The device includes a payment code value acquisition unit and a payment code display unit, wherein: payment code value acquisition unit Used to obtain a payment code code value, the payment code code value including a code issuing institution identification and payment account information, the payment account information corresponding to an account of the code issuing institution with the code issuing institution identification; payment code display unit It is used to render the value of the payment code code into a barcode and display it for the payee device to scan and upload the code issuing institution identification and payment account information to the acquirer’s server, and the acquirer’s server will issue the code according to the code The institution identifier determines the code issuing institution, and the server of the code issuing institution determines the payment account used for this payment according to the payment account information. Optionally, the payment code value obtaining unit is specifically used for one of the following: the payment code value is generated by the client software of the code issuing institution installed locally; or, to the server of the code issuing institution Send a payment code request, and receive the payment code value returned by the server of the code issuing agency. Optionally, the payment account information includes: a tokenized account identifier and a device identifier of the payer terminal. Optionally, the code value of the payment code is 24 to 32 digits, wherein the code issuing agency identifier is the first 8 digits, and the payment account information is the last 16 to 24 digits; the first digit in the code issuing agency identifier is Indicates the area code of the area served by the code issuing agency. In an example, the code value of the payment code further includes: an acquirer identifier, which is used by the payee device to determine the acquirer that uploads the code issuing organization identifier and payment account information. In the above example, the code value of the payment code is 24 digits, among which the acquirer ID is the first 2 digits, the code issuing agency ID is the 4th to 6th digits, and the payment account information is the 9th to 24th digits Numbers, the 3rd digit is the version number of the payment code value, and the 7th to 8th digits are the type of business. Figure 16 shows a barcode-based payment implementation device provided by an embodiment of this specification, which is applied to a payee device. The device includes a payment code scanning unit and a first payment request sending unit, wherein: the payment code scanning unit uses The payment code value is obtained by scanning the payment code provided by the terminal of the payer, the payment code value including the code issuing institution identification and payment account information, and the payment account information corresponds to the code issuing institution having the code issuing institution identification The first payment request sending unit is used to send the first payment request including the code issuing institution identification and payment account information to the server of the acquiring institution for the server of the acquiring institution according to the identification of the issuing institution The code issuing agency is determined, and the server of the code issuing agency determines the payment account used for this payment according to the payment account information. Optionally, the code value of the payment code is 24 to 32 digits, wherein the code issuing agency identifier is the first 8 digits, and the payment account information is the last 16 to 24 digits; the first digit in the code issuing agency identifier is Indicates the area code of the area served by the code issuing agency. In an example, the code value of the payment code further includes: an acquiring institution identification; the first payment request sending unit is specifically configured to: determine an acquiring institution according to the acquiring institution identification, and include the code issuing institution identification The first payment request with payment account information is sent to the server of the determined acquirer. In the above example, the code value of the payment code is 24 digits, among which the acquirer ID is the first 2 digits, the code issuing agency ID is the 4th to 6th digits, and the payment account information is the 9th to 24th digits Numbers, the 3rd digit is the version number of the payment code value, and the 7th to 8th digits are the type of business. Figure 17 shows a barcode-based payment implementation device provided by an embodiment of this specification, which is applied to a server of an acquiring institution. The device includes a first payment request receiving unit and a second payment request sending unit, wherein: A payment request receiving unit is used to receive a first payment request sent by the payer's device. The first payment request includes the code issuing institution identification and payment account information in the payment code value; the second payment request sending unit is used when When the code issuing agency ID is not the code issuing agency ID of the agency, a second payment request is sent to the server of the code issuing agency with the code issuing agency ID, and the second payment request includes the payment account information , The server of the code issuing agency determines the payment account for this payment according to the payment account information, and deducts the payment from the payment account. Optionally, the second payment request further includes the code-issuing institution identification; the second payment request sending unit is specifically configured to: when the code-issuing institution identification is not the code-issuing institution identification of the institution, The second payment request is sent to the institution interconnection server, and the institution interconnection server forwards the second payment request to the server of the code issuing institution with the code issuing institution identifier. Optionally, the device further includes: a first payment request processing unit, configured to determine the payment account for this payment according to the payment account information when the code issuing institution is identified as the code issuing institution of the institution, And deduct money from the payment account. Optionally, the first payment request includes a payment code code value; the payment code code value is 24 to 32 digits, where the code issuing agency identifier is the first 8 digits, and the payment account information is the last 16 to 24 digits Number; the first digit in the code issuing agency's identification is the area code that represents the area served by the code issuing agency. Optionally, the first payment request includes a payment code code value; the payment code code value is 24 digits, where the acquiring institution identifier is the first 2 digits, and the code issuing institution identifier is the fourth to sixth digits. Digits, the payment account information is the 9th to 24th digits, the 3rd digit is the version number of the payment code value, and the 7th to 8th digits are the business type. Figure 18 shows a barcode-based payment implementation device provided by an embodiment of this specification, which is applied to a server of a code issuing institution. The device includes a second payment request receiving unit and a second payment request processing unit, wherein: The second payment request receiving unit is used to receive a second payment request, the second payment request includes the code issuing institution identification and payment account information in the payment code code value; the second payment request processing unit is used to confirm the sending code After the institution ID is the code issuing institution ID of the institution, an account of the institution is determined as the payment account according to the payment account information, and the payment is deducted from the payment account. Optionally, the second payment request receiving unit is specifically used for one of the following: receiving the second payment request sent by the server of the acquiring institution; or, receiving the second payment request forwarded by the server of the institution interconnection, the The second payment request is sent from the server of the acquiring institution to the institution interconnection server. Optionally, the second payment request includes a payment code code value; the payment code code value is 24 to 32 digits, where the code issuing agency identifier is the first 8 digits, and the payment account information is the last 16 to 24 digits Number; the first digit in the code issuing agency's identification is the area code that represents the area served by the code issuing agency. Optionally, the second payment request includes a payment code code value; the payment code code value is 24 digits, where the acquiring institution identifier is the first 2 digits, and the code issuing institution identifier is the fourth to sixth digits. Digits, the payment account information is the 9th to 24th digits, the 3rd digit is the version number of the payment code value, and the 7th to 8th digits are the business type. Optionally, the device further includes: a payment code value issuing unit, configured to, after receiving a payment code request from the payer terminal, generate payment account information based on the account of the payer terminal, and send the payment to the The party terminal returns the payment code value including the payment account information and the code issuing agency identification of the institution. Figure 19 shows a barcode-based payment implementation device provided by an embodiment of this specification, which is applied to an institutional interconnection server. The device includes a second payment request transfer unit and a second payment request forwarding unit, wherein: 2. The payment request transfer unit is configured to receive a second payment request sent by the server of the acquirer, where the second payment request includes the code issuing institution identification and payment account information in the payment code value; the second payment request is forwarded The unit is used to forward the second payment request to the server of the code issuing organization with the identifier of the code issuing organization, for the server of the code issuing organization to determine the payment account for this payment according to the payment account information, and from Debits from the payment account. Optionally, the code value of the payment code is 24 to 32 digits, wherein the code issuing agency identifier is the first 8 digits, and the payment account information is the last 16 to 24 digits; the first digit in the code issuing agency identifier is Indicates the area code of the area served by the code issuing agency. Optionally, the code value of the payment code is 24 digits, where the acquirer identifier is the first 2 digits, the code issuer identifier is the 4th to 6th digits, and the payment account information is the 9th to 24th digits. Numbers, the 3rd digit is the version number of the payment code value, and the 7th to 8th digits are the type of business. The embodiments of this specification provide a computer device, which includes a memory and a processor. Wherein, the memory stores a computer program that can be run by the processor; when the processor runs the stored computer program, it executes the steps of the barcode-based payment implementation method applied to the user terminal in the embodiments of this specification. Please refer to the previous content for a detailed description of each step of the barcode-based payment implementation method applied on the user terminal, and will not be repeated. The embodiments of this specification provide a computer device, which includes a memory and a processor. Among them, the memory stores a computer program that can be run by the processor; when the processor runs the stored computer program, it executes the steps of the barcode-based payment implementation method applied to the payee device in the embodiments of this specification. Please refer to the previous content for the detailed description of each step of the implementation method of barcode-based payment applied on the payee's device, and will not be repeated. The embodiments of this specification provide a computer device, which includes a memory and a processor. Among them, the memory stores a computer program that can be run by the processor; when the processor runs the stored computer program, it executes each of the barcode-based payment implementation methods applied to the server of the acquirer in the embodiments of this specification. step. Please refer to the previous content for a detailed description of each step of the barcode-based payment implementation method applied on the server of the acquirer, and will not be repeated. The embodiments of this specification provide a computer device, which includes a memory and a processor. Among them, the memory stores a computer program that can be run by the processor; when the processor runs the stored computer program, it executes each of the barcode-based payment implementation methods applied to the server of the code issuing agency in the embodiments of this specification. step. Please refer to the previous content for a detailed description of the steps of the barcode-based payment implementation method applied on the server of the code issuing agency, and will not be repeated. The embodiments of this specification provide a computer device, which includes a memory and a processor. Among them, the memory stores a computer program that can be run by the processor; when the processor runs the stored computer program, it executes each step of the implementation method of barcode-based payment applied to the institutional interconnection server in the embodiment of this specification. . Please refer to the previous content for a detailed description of each step of the barcode-based payment implementation method applied to the institutional interconnection server, and will not be repeated. The embodiment of this specification provides a computer-readable storage medium with computer programs stored on the storage medium. These computer programs, when run by a processor, execute the implementation of barcode-based payment applied to the user terminal in the embodiment of this specification. The steps of the method. Please refer to the previous content for a detailed description of each step of the barcode-based payment implementation method applied on the user terminal, and will not be repeated. The embodiment of this specification provides a computer-readable storage medium with computer programs stored on the storage medium. These computer programs, when run by a processor, execute the barcode-based payment applied to the payee device in the embodiment of this specification. The steps of the implementation method. Please refer to the previous content for the detailed description of each step of the implementation method of barcode-based payment applied on the payee's device, and will not be repeated. The embodiment of this specification provides a computer-readable storage medium with computer programs stored on the storage medium. These computer programs, when run by a processor, execute the application based on the server of the acquiring institution in the embodiment of this specification. Each step of the implementation method of barcode payment. Please refer to the previous content for a detailed description of each step of the barcode-based payment implementation method applied on the server of the acquirer, and will not be repeated. The embodiment of this specification provides a computer-readable storage medium with computer programs stored on the storage medium. When run by a processor, these computer programs execute the code-sending mechanism's server based on the embodiment of this specification. Each step of the implementation method of barcode payment. Please refer to the previous content for a detailed description of the steps of the barcode-based payment implementation method applied on the server of the code issuing agency, and will not be repeated. The embodiment of this specification provides a computer-readable storage medium with computer programs stored on the storage medium. These computer programs, when run by a processor, execute the barcode-based application on the mechanism interconnection server in the embodiment of this specification. The steps of the payment implementation method. Please refer to the previous content for a detailed description of each step of the barcode-based payment implementation method applied to the institutional interconnection server, and will not be repeated. Figure 20 shows the embodiment of this specification provides a barcode-based payment system, including the server of the acquiring organization, the server of the organization interconnection, and the server of the code issuing organization, where: the server of the acquiring organization is used for Receive the first payment request sent by the payer’s device that includes the code issuing agency ID and payment account information in the payment code value, and when the code issuing agency ID is not the agency’s code issuing agency ID, interconnect the server to the institution The device sends a second payment request carrying the code issuing institution identification and payment account information; the institution interconnection server is used to receive the second payment request including the code issuing institution identification and payment account information sent by the server of the acquiring institution , And forward the second payment request to the server of the code issuing agency with the code issuing agency ID; the server of the code issuing agency is used to receive the code issuing agency ID and the payment account sent by the agency interconnection server For the second payment request of information, after confirming that the code issuing agency ID is the code issuing agency ID of the agency, an account of the agency is determined as the payment account according to the payment account information, and the payment is deducted from the payment account. Optionally, the code value of the payment code is 24 to 32 digits, wherein the code issuing agency identifier is the first 8 digits, and the payment account information is the last 16 to 24 digits; the first digit in the code issuing agency identifier is Indicates the area code of the area served by the code issuing agency. Optionally, the code value of the payment code is 24 digits, where the acquirer identifier is the first 2 digits, the code issuer identifier is the 4th to 6th digits, and the payment account information is the 9th to 24th digits. Numbers, the 3rd digit is the version number of the payment code value, and the 7th to 8th digits are the type of business. The above descriptions are only the preferred embodiments of this specification, and are not intended to limit other embodiments for protection. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be It is included in the scope of protection. In a typical configuration, the computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory. Memory may include non-permanent memory in computer-readable media, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media. Computer-readable media includes permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), and other types of random access memory (RAM) , Read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital multi-function Optical discs (DVD) or other optical storage, magnetic cassettes, magnetic tape storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves. It should also be noted that the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or equipment including a series of elements not only includes those elements, but also includes Other elements that are not explicitly listed, or also include elements inherent to such processes, methods, commodities, or equipment. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, method, commodity, or equipment that includes the element. Those skilled in the art should understand that the embodiments of this specification can be provided as methods, systems or computer program products. Therefore, the embodiments of this specification may adopt the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of this specification can adopt computer programs implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer-usable program codes. The form of the product.
