本發明的實施例中，在跨地域支付時，付款方採用跨域碼進行支付。付款方向收款方提供的跨域碼可以是一串數字，也可以是一串字元(包括數字、字母、文字、符號中的一種到多種)；付款方終端可以將跨域碼作為支付卡的卡片編號提供給收款方設備，也可以將跨域碼渲染為條碼(如一維條碼、二維條碼、或一維條碼與二維條碼的組合等)；均不做限定。
付款方在某個支付服務提供方開設有帳戶，當付款方採用跨域碼進行支付時，支付的款項將由該支付服務提供方從該付款方的帳戶中轉出，則該支付服務提供方成為該跨域碼的發碼機構，該帳戶成為該跨域碼的付款帳戶。
跨域碼支付的收款方在某個支付服務提供方開設有帳戶，並且收款方與該支付服務提供方具有收單業務關係，當某次支付中收款方在獲得跨域碼後向該支付服務提供方的伺服器發送支付請求時，接收支付請求的支付服務提供方即成為本次支付中的收單機構，該收款方在該收單機構的帳戶即成為本次支付中的收款帳戶。
本發明的實施例中，發碼機構的伺服器與收單機構的伺服器通常處於不同的地理區域(如地區、國家、洲等等)，發碼機構的伺服器與收單機構的伺服器連接到一個互連網路，該互連網路由一個到多個機構互連伺服器來與各個支付服務提供方的伺服器進行通信，所有的機構互連伺服器都具有該互連網路的標識，本發明實施例中稱之為互連標識。互連網路的組網結構不做限定，例如，可以是由分佈在不同地理區域的多個機構互連伺服器組成的IDC(Internet Data Center，網際網路資料中心)。對包括兩個或兩個以上機構互連伺服器的互連網路，發碼機構的伺服器和收單機構的伺服器可以連接至任意一個機構互連伺服器，各個機構互連伺服器可以看做是同一個機構互連伺服器。
本發明的實施例中，跨域碼中包括互連標識、發碼機構標識和付款帳戶資訊。其中，互連標識是與發碼機構的伺服器和收單機構的伺服器進行通信的互連網路的標識(或機構互連伺服器的標識)；發碼機構標識唯一代表跨域碼的一個發碼機構，例如可以是跨域碼發碼機構的簡稱、編碼或代號等，各個支付服務提供者能夠根據發碼機構標識確定跨域碼的發碼機構是哪個；付款帳戶資訊能夠由發碼機構用來確定本機構的一個帳戶，其具體內容可以由發碼機構自行確定，只要發碼機構能夠將付款帳戶資訊唯一對應於本機構的一個帳戶即可。跨域碼中還可以包括其他資訊，不做限定，例如可以包括跨域碼的業務類型，用來限制使用該跨域碼時只能進行哪個或哪些種類的業務。
在一種實現方式中，跨域碼採用全數字格式，長度為24位或24位以上，每位可以是0到9中的一個數字。這種跨域碼由固定長度為8位的頭部(Header)和可變長度從16位到16位元以上的負載(Payload)組成，如圖1所示，頭部的前2位元數字為互連標識，第3位元數字為跨域碼的版本號，第4位元到第6位元數字為發碼機構標識，第7到第8位元數字為業務類型；從第9位元數字開始為負載，負載為付款帳戶資訊，即該跨域碼的第9至最後一位元數字為付款帳戶資訊。
跨域碼可以以明文的形式使用，因此跨域碼中的付款帳戶資訊通常避免使用帳戶名稱、帳戶編號等可能洩露用戶隱私或帶來安全隱患的內容。例如，付款帳戶資訊可以包括用戶出生日期、跨域碼的密碼、跨域碼的有效期中的一項到多項。其中，跨域碼的密碼用來由機構互連伺服器在接受採用該跨域碼進行的支付前，對付款方進行認證。跨域碼的有效期用來由機構互連伺服器在接受採用該跨域碼進行的支付前，對支付發生的時間是否處於該跨域碼的有效期內進行認證。
此外，還可以在付款帳戶資訊中包括去重位元，去重位的值可以由發碼機構的伺服器來設置，這樣當該發碼機構的不同帳戶具有相同的用戶出生日期、跨域碼的密碼和跨域碼的有效期時，發碼機構的伺服器可以通過為每個帳戶設置不同的去重位的值，來使得一個付款帳戶資訊唯一對應於該發碼機構的一個帳戶。
仍以圖1所示的跨域碼為例，從第9至最後一位元數字是付款帳戶資訊，其中可以包括6位付款方的出生日期(如830112表示付款方用戶出生於1983年1月12日)、4位元跨域碼密碼、4位元跨域碼的有效期(如2208表示該跨域碼的有效期截止到2022年8月)、和2位去重位。
需要說明的是，本發明實施例中的離線支付，是指在支付發生時，付款方終端與付款帳戶所屬支付服務提供方(即發碼機構)的伺服器之間不進行通信，即相對於發碼機構的伺服器，付款方終端處於離線狀態；而不是指付款方終端與任何設備都不能夠進行通信。
本發明的實施例一提出一種跨地域離線支付的註冊方法，發碼機構的伺服器在收到付款方終端的請求後，產生包括互連標識、發碼機構標識和付款帳戶資訊的跨域碼，下發給付款方終端，並將該跨域碼及其授權額度註冊到具有該互連標識的機構互連伺服器，付款方終端在該機構互連伺服器所服務的地域可以使用該跨域碼進行支付並由該機構互連伺服器進行確認，使得在該機構互連伺服器所服務的地域無需發碼機構的伺服器參與即可完成支付，付款方和收款方不必等待長時間的跨地域通信，節省了支付時間，提高了支付效率。
本發明實施例一應用場景的一種網路結構如圖2所示，付款方終端與發碼機構的伺服器之間、發碼機構的伺服器與機構互連伺服器之間通過網路可以進行通信。其中，付款方終端可以是手機、平板電腦、PC(Personal Computer，個人電腦)、筆記型電腦等設備；發碼機構的伺服器或機構互連伺服器可以是一個實體或邏輯伺服器，也可以是由兩個或兩個以上分擔不同職責的實體或邏輯伺服器、相互協同來實現本發明實施例中發碼機構的伺服器或機構互連伺服器的各項功能。
本發明的實施例一中，跨地域離線支付的註冊方法應用在發碼機構的伺服器上的流程如圖3所示，應用在付款方終端上的流程如圖4所示，應用在機構互連伺服器上的流程如圖5所示。
在付款方終端上，步驟410，向發碼機構的伺服器發送跨域碼發行請求。
在發碼機構的伺服器上，步驟310，接收付款方終端發送的跨域碼發行請求。
當付款方希望使用其在發碼機構的帳戶，在該發碼機構服務地域之外的其他地域進行行動支付時，可以通過付款方終端向發碼機構的伺服器發送跨域碼發行請求。付款方可以通過安裝在其終端上的該發碼機構的用戶端軟體提供的跨域碼請求功能來發起這一請求，也可以通過存取發碼機構的網站來發起該請求，還可以採用其他方式，不做限定。
對在使用時可能需要輸入密碼的跨域碼，可以由發碼機構的伺服器確定初始密碼；也可以由付款方指定跨域碼的密碼後，將指定密碼攜帶在跨域碼發行請求中發送給發碼機構的伺服器。對具有有效期的跨域碼，可以由發碼機構的伺服器確定有效期；也可以由付款方指定跨域碼的有效期，並將指定的有效期在跨域碼發行請求中發送給發碼機構的伺服器。對付款帳戶資訊中包括付款方出生日期的跨域碼，可以由發碼機構的伺服器根據付款方的證件號碼確定其出生日期；也可以由付款方自行輸入，付款方終端將輸入的出生日期在跨域碼發行請求中發送給發碼機構的伺服器。
在發碼機構的伺服器上，步驟320，產生包括互連標識、發碼機構標識和付款帳戶資訊的跨域碼，儲存付款帳戶資訊與付款方帳戶的對應關係，向該付款方終端返回攜帶有該跨域碼的回應。
在付款方終端上，步驟420，接收發碼機構的伺服器返回的攜帶有跨域碼的回應。
發碼機構的伺服器在收到跨域碼發行請求後，產生跨域碼的付款帳戶資訊。付款帳戶資訊的內容和產生方式可以由由發碼機構自行確定，只要發碼機構的伺服器能夠將付款帳戶資訊唯一對應於本機構的一個帳戶即可。在產生付款帳戶資訊後，發碼機構的伺服器儲存付款帳戶資訊與使用該付款方終端的付款方帳戶的對應關係。
發碼機構的伺服器採用連接本伺服器和服務於其他地域的支付服務提供方的伺服器(其中包括服務於付款發生地域的支付服務提供方的伺服器)的互連網路的標識(即該互連網路中每個機構互連伺服器的互連標識)、本發碼機構的發碼機構標識、和付款帳戶資訊產生跨域碼，將產生的跨域碼封裝在跨域碼發行回應中，返回給付款給終端。
根據實際應用場景中跨域碼的具體組成，發碼機構的伺服器產生的跨域碼中還可以包括其他資訊，如業務類型、版本號等。當跨域碼發行請求中攜帶有付款方指定的跨域碼的密碼、付款方指定的跨域碼的有效期、付款方出生日期中的一項到多項時，發碼機構的伺服器將根據跨域碼發行請求中的這些資訊來產生跨域碼。
在付款方終端上，步驟430，儲存該跨域碼，用來在具有該互連標識的機構互連伺服器所服務的地域內、以該發碼機構的付款方帳戶進行支付。
付款方終端從跨域碼發行回應中提取跨域碼，將跨域碼儲存在本地。當付款方身處該互連網路所服務的地域時，當希望以在發碼機構的付款方帳戶進行離線支付時，即可採用儲存的跨域碼來向收款方付款。
根據付款方終端採用的具體支付形式，跨域碼可以在付款方終端儲存為支付卡卡號，由付款方終端在支付時向收款方出示或傳輸給收款方的收款設備；也可以儲存為付款碼碼值，由付款方終端在支付時將其渲染為條碼、二維碼等，供收款方的收款設備掃描；還可以是其他方式。
在發碼機構的伺服器上，步驟330，向具有該互連標識的機構互連伺服器發送攜帶有該跨域碼和授權額度的跨域碼註冊請求，供機構互連伺服器在儲存該跨域碼和授權額度後，在所服務的地域、在授權額度內接受該付款方終端採用該跨域碼、以該付款方帳戶進行的支付。
在機構互連伺服器上，步驟510，接收發碼機構的伺服器發送的攜帶有跨域碼和授權額度的跨域碼註冊請求。
發碼機構伺服器在為付款方終端產生跨域碼後，確定該跨域碼的授權額度。授權額度是付款方終端使用該跨域碼能夠支付的總數額。授權額度可以由發碼機構確定，如由發碼機構的伺服器根據付款方的信用額度確定；也可以由付款方自行設定，如由付款方在其終端上輸入授權額度後，付款方終端在跨域碼發行請求中將付款方指定的授權額度傳輸給發碼機構的伺服器。
發碼機構的伺服器將跨域碼、該跨域碼的授權額度封裝在跨域碼註冊請求中，發送給具有該跨域碼中互連標識的機構互連伺服器。
在機構互連伺服器上，步驟520，儲存該跨域碼和授權額度，用來在該授權額度內接受採用該跨域碼、以該發碼機構的付款方帳戶進行的支付。
機構互連伺服器在收到跨域碼註冊請求後，將跨域碼及其授權額度儲存在可以存取的儲存位置。當收到以該跨域碼進行支付的請求時，機構互連伺服器即可在該跨域碼的授權額度內，接受採用該跨域碼進行的付款，並通過與發碼機構伺服器的交互，最終從該跨域碼中付款帳戶資訊對應的付款方帳戶中扣取支付的款項。
可見，本發明的實施例一中，根據付款方終端的請求，發碼機構的伺服器產生包括互連標識、發碼機構標識和付款帳戶資訊的跨域碼，下發給付款方終端，並向具有該互連標識的機構互連伺服器註冊該跨域碼及其授權額度，付款方終端在該機構互連伺服器所服務的地域可以使用該跨域碼進行支付並由該機構互連伺服器進行確認，支付過程無需存取發碼機構的伺服器即可完成，避免了因跨地域的通信鏈路造成的長時間等待，節省了支付時間，提高了支付效率，提升了付款方和收款方的體驗。
本發明的實施例二提出一種跨地域離線支付的付款方法，付款方終端在付款時提供跨域碼，收單機構的伺服器將跨域碼和款項資訊發送給具有跨域碼中互連標識的機構互連伺服器，機構互連伺服器根據自身維護的該跨域碼的剩餘額度決定是否接受支付，使得付款方終端在該機構互連伺服器所服務的地域無需發碼機構的伺服器參與即可完成支付，付款方和收款方不必等待長時間的跨地域通信，節省了支付時間，提高了支付效率。
本發明實施例二應用場景的一種網路結構如圖6所示，付款方終端與收款方的收款設備之間能夠進行近距離的資料交換，如掃描或通過無線局域網進行通信；收款設備與收款方的收單機構的伺服器之間、收單機構的伺服器與機構互連伺服器之間、機構互連伺服器與發碼機構的伺服器之間通過網路可以進行通信。其中，付款方終端可以是手機、平板電腦、PC(Personal Computer，個人電腦)、筆記型電腦等設備；收款方設備可以是具有掃描和計算功能、或具有通信和計算功能的一個設備或兩個及以上設備的組合，如手機、平板電腦、掃碼槍和PC、筆記型電腦等設備；發碼機構的伺服器、收單機構的伺服器或機構互連伺服器可以是一個實體或邏輯伺服器，也可以是由兩個或兩個以上分擔不同職責的實體或邏輯伺服器、相互協同來實現本發明實施例中發碼機構的伺服器、收單機構的伺服器或機構互連伺服器的各項功能。
本發明的實施例二中，跨地域離線支付的付款方法應用在收單機構的伺服器上的流程如圖7所示，應用在機構互連伺服器上的流程如圖8所示，應用在發碼機構的伺服器上的流程如圖9所示。
當付款方來到其帳戶的發碼機構所服務的地域外，希望用該帳戶付款時，可以採用實施例一中由發碼機構發行的跨域碼來啟動支付過程。付款方終端將跨域碼在付款時提供給收款方的收款設備，例如將跨域碼作為支付卡的卡號傳輸給收款設備，或者將跨域碼作為碼值渲染為付款碼顯示給收款設備掃描。
收款設備獲取跨域碼後，將跨域碼和本次支付的款項資訊封裝在第一支付請求中發送給該收款方收單機構的伺服器。其中，款項資訊用來確定支付款項的具體數額，例如可以是付款數額、或付款數額和幣種等。第一支付請求中還可以包括其他資訊，如描述本次交易的交易資訊等。
在收單機構的伺服器上，步驟710，接收收款設備發送的第一支付請求。第一支付請求中包括款項資訊和收款設備從付款方終端獲取的跨域碼。
在收單機構的伺服器上，步驟720，向具有該互連標識的機構互連伺服器發送攜帶有跨域碼和款項資訊的第二支付請求；
在機構互連伺服器上，步驟810，接收收單機構的伺服器發送的攜帶有跨域碼和款項資訊的第二支付請求。該跨域碼由付款方終端提供。
如實施例一中所述，跨域碼中包括互連標識、發碼機構標識和付款帳戶資訊，此外，還可以包括跨域碼的密碼、跨域碼的有效期中的一項或兩項。收單機構的伺服器在處理來自收款設備的支付請求時，如果請求中的支付卡卡號或付款碼碼值中攜帶有互連標識，則可以識別出本次支付是採用跨域碼進行的支付，需要機構互連伺服器來進行處理。
當第一支付請求中攜帶有互連標識時，收單機構的伺服器向具有該互連標識的機構互連伺服器發送攜帶有該第一支付請求中跨域碼和款項資訊的第二支付請求。收單機構的伺服器可以直接將第一支付請求作為第二支付請求發送給機構互連伺服器，也可以按照與機構互連伺服器約定的格式來產生第二支付請求，在第二支付請求中封裝該跨域碼和款項資訊，還可以封裝其他資訊，如交易資訊等。
在機構互連伺服器上，步驟820，當該跨域碼的剩餘額度不小於該款項資訊對應的支付額度時，根據該款項資訊更新該跨域碼的剩餘額度，向收單機構的伺服器返回支付成功的回應。剩餘額度的初始值為該跨域碼的授權額度。
在收單機構的伺服器上，步驟730，接收攜帶有支付結果的第二支付回應。支付結果由機構互連伺服器根據款項資訊和該跨域碼的剩餘額度確定。
機構互連伺服器為每個已經註冊的跨域碼維護其剩餘額度。剩餘額度是付款方後續還可以使用該跨域碼支付的總數額，等於該跨域碼的授權額度減去註冊後已經使用該跨域碼支付的數額。剩餘額度的初始值是該跨域碼的授權額度，每次使用該跨域碼支付成功時，從剩餘額度中扣減掉本次支付的數額。
機構互連伺服器收到收單機構的伺服器發送的第二支付請求，從中提取出跨域碼和款項資訊。機構互連伺服器在確認該跨域碼是已經在本互連網路註冊的跨域碼後，根據款項資訊確定本次支付的支付額度。如果該跨域碼的剩餘額度大於或等於本次支付的支付額度，則根據款項資訊更新該跨域碼的剩餘額度，即將該跨域碼的剩餘額度更新為更新前的剩餘額度減去本次支付的支付額度，機構互連伺服器向收單機構的伺服器返回第二支付回應，其中攜帶有支付成功的訊息。
如果該跨域碼不是在本互連網路註冊的跨域碼，或者該跨域碼的剩餘額度小於本次支付的支付額度，則機構互連伺服器向收單機構的伺服器返回攜帶有支付失敗訊息的第二支付回應。
在跨域碼中包括跨域碼的有效期的應用場景中，機構互連伺服器在第二支付請求中的跨域碼是已經在本互連網路註冊的跨域碼、接收第二支付請求的時間在該跨域碼的有效期內，並且該跨域碼的剩餘額度不小於本次支付的支付額度時，根據本次支付的支付額度更新該跨域碼的剩餘額度，並向收單機構的伺服器返回支付成功的回應；否則向收單機構的伺服器返回支付失敗的回應。
在跨域碼中包括跨域碼的有效期的應用場景中，機構互連伺服器可以在每次支付時都要求付款方提供密碼，也可以在必要時(如支付款項超過預定數額時、或交易資訊滿足預定安全條件時等)要求付款方提供密碼。具體的，可以由機構互連伺服器向收單機構的伺服器發送所述跨域碼的密碼請求，收單機構的伺服器向收款設備轉發該跨域碼的密碼請求；收款方請付款方在收款設備上輸入密碼後，將輸入的密碼封裝在密碼回應中發送給收單機構的伺服器；收單機構的伺服器將密碼回應轉發給機構互連伺服器。機構互連伺服器從密碼回應中提取付款方提供的密碼，當第二支付請求中的跨域碼是已經在本互連網路註冊的跨域碼、付款方提供的密碼與該跨域碼中的密碼相匹配，並且該跨域碼的剩餘額度不小於本次支付的支付額度時，根據本次支付的支付額度更新該跨域碼的剩餘額度，並向收單機構的伺服器返回支付成功的回應；否則向收單機構的伺服器返回支付失敗的回應。
在發碼機構的伺服器上，步驟910，接收機構互連伺服器發送的攜帶有跨域碼和款項資訊的跨域碼結算請求。該跨域碼由付款方終端提供。
對採用跨域碼付款成功的一次支付，機構互連伺服器產生攜帶有該跨域碼和該次支付的款項資訊的跨域碼結算請求，發送給具有該跨域碼中發碼機構標識的發碼機構的伺服器。跨域碼結算請求還可以包括其他資訊，如交易資訊、支付發生的時間、付款方在付款時輸入的密碼等。
在發碼機構的伺服器上，步驟920，根據款項資訊，對對應於付款帳戶資訊的本機構帳戶進行扣款。
發碼機構的伺服器收到跨域碼結算請求，從其中的跨域碼中提取出發碼機構標識和付款帳戶資訊。發碼機構確認該跨域碼中的發碼機構標識是本機構的發碼機構標識，從儲存的付款帳戶資訊與本機構帳戶的對應關係中查找跨域碼結算請求中的付款帳戶資訊對應的本機構帳戶，將找到的帳戶作為付款帳戶，從付款帳戶中扣取與款項資訊相應額度的款項。
扣款成功後，發碼機構的伺服器可以向機構互連伺服器返回結算成功的回應。發碼機構的伺服器與機構互連伺服器的結算過程在付款成功之後進行，即使發碼機構的伺服器與機構互連伺服器之間的通信時間較長，也不會影響付款方與收款方之間的支付速度。
上述對本發明特定實施例進行了描述。其它實施例在所附申請專利範圍的範圍內。在一些情況下，在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外，在圖式中描繪的過程不一定要求示出的特定順序或者連續順序才能實現期望的結果。在某些實施方式中，多工處理和並行處理也是可以的或者可能是有利的。
在本發明的一個應用示例中，A國的支付服務提供方Inst_A加入一個支付服務聯盟，該聯盟的成員包括若干個國家支付服務提供方(如B國的支付服務提供方Inst_B)，某個聯盟成員的用戶可以在這些國家採用其帳戶進行支付，以某個聯盟成員為收單機構的商戶也可以接收所有聯盟成員用戶的付款。該支付服務聯盟建立有包括若干台機構互連伺服器的互連網路，這些機構互連伺服器組成IDC中心，與各個聯盟成員的伺服器進行通信。
Inst_A的用戶User_A希望在該支付服務聯盟提供服務的B國使用其在Inst_A開設的帳戶進行行動支付，可以先向Inst_A的伺服器申請註冊跨域碼。Inst_A即成為該跨域碼的發碼機構。註冊跨域碼時的交互流程參見圖11。
User_A在其終端(一種付款方終端)上Inst_A的用戶端App(應用程式)中，打開註冊跨域碼的頁面，在頁面上輸入自己的出生日期(設為1983年1月12日)、跨域碼的密碼(設為1234)、跨域碼的有效期(設為截止到2022年8月)、和授權額度後，指令申請跨域碼。App將用戶輸入的上述資訊封裝在跨域碼發行請求中，發送給Inst_A的伺服器。
Inst_A的伺服器按照圖1所示的組成結構，將該支付服務聯盟的標識(一種互連標識，設為28)、跨域碼的版本號(設為1)、本機構的發碼機構標識(設為006)、業務類型(設為02，表示線下支付)組成跨域碼的Header；將出生日期(830112)、跨域碼的密碼(1234)、去重位(設為00)和跨域碼的有效期(2208)組成付款帳戶資訊，產生跨域碼281006028301121234002208。Inst_A的伺服器將產生的跨域碼封裝在跨域碼發行回應中，返回給User_A終端的App。Inst_A的伺服器儲存該跨域碼中付款帳戶資訊與User_A的帳戶的對應關係。
User_A終端的App收到跨域碼發行響應，將其中的跨域碼儲存在本地，並告知User_A跨域碼已申請成功。
Inst_A的伺服器將該跨域碼、User_A為該跨域碼指定的授權額度封裝在跨域碼註冊請求中，發送給互連網路的機構互連伺服器。機構互連伺服器在查驗該跨域碼符合圖1所示的規範後，儲存該跨域碼及其授權額度，將該跨域碼的剩餘額度置為其授權額度。機構互連伺服器向Inst_A的伺服器返回跨域碼註冊回應，告知Inst_A的伺服器註冊成功。
當User_A來到B國，在商戶Merc_B處消費。User_A採用跨域碼支付的流程如圖12所示。
User_A在其終端上Inst_A的用戶端App中打開跨域碼支付頁面，App讀取儲存的跨域碼，將其作為碼值渲染為一維條碼和/或二維條碼。商戶Merc_B的收款設備掃描後，得到跨域碼，將跨域碼、款項資訊、交易資訊封裝在第一支付請求中，發送給Merc_B的收單機構Inst_B的伺服器。
Inst_B的伺服器提取第一支付請求中的跨域碼，根據其中支付服務聯盟的標識28，得知該支付請求需要由互連網路來處理。Inst_B的伺服器將跨域碼、款項資訊和交易資訊封裝在第二支付請求中，發送給機構互連伺服器。
機構互連伺服器提取第二支付請求中的跨域碼，在儲存的跨域碼中查找是否有該跨域碼，查驗收到第二支付請求的時間是否在該跨域碼的有效期內，並根據款項資訊判斷該跨域碼的剩餘額度是否足以進行本次支付。如果上述各項均為是的話，則機構互連伺服器在該跨域碼的剩餘額度中扣除本次支付的數額，並向Inst_B的伺服器返回攜帶支付成功訊息的第二支付回應。
Inst_B的伺服器向Merc_B的收款設備返回支付成功的第一支付回應，Merc_B的收款設備通知商戶支付成功。
機構互連伺服器將該跨域碼、該次支付的款項資訊和交易資訊封裝在跨域碼結算請求中，根據該跨域碼中的發碼機構標識006，發送給Inst_A的伺服器。
Inst_A的伺服器確認該跨域碼中的發碼機構標識為本機構的發碼機構標識，查找儲存的付款帳戶資訊與帳戶的對應關係，得知與跨域碼結算請求中的跨域碼對應的帳戶為User_A的帳戶。Inst_A的伺服器從User_A的帳戶中扣取與款項資訊對應數額的款項，向機構互連伺服器返回結算成功的回應。
與上述流程實現對應，本發明的實施例還提供了一種應用在發碼機構的伺服器上的跨地域離線支付的註冊裝置、一種應用在付款方終端上的跨地域離線支付的註冊裝置、一種應用在機構互連伺服器上的跨地域離線支付的註冊裝置、一種應用在收單機構的伺服器上的跨地域離線支付的付款裝置和一種應用在機構互連伺服器上的跨地域離線支付的付款裝置。上述裝置均可以通過軟體實現，也可以通過硬體或者軟硬體結合的方式實現。以軟體實現為例，作為邏輯意義上的裝置，是通過所在設備的CPU(Central Process Unit，中央處理器)將對應的電腦程式指令讀取到記憶體中運行形成的。從硬體層面而言，除了圖12所示的CPU、內建記憶體以及記憶體之外，上述裝置所在的設備通常還包括用於進行無線信號收發的晶片等其他硬體，和/或用於實現網路通信功能的板卡等其他硬體。
圖13所示為本發明實施例提供的一種跨地域離線支付的註冊裝置，應用在發碼機構的伺服器上，所述裝置包括發行請求接收單元、發行回應發送單元和註冊請求發送單元，其中：發行請求接收單元用於接收付款方終端發送的跨域碼發行請求；發行回應發送單元用於產生包括互連標識、發碼機構標識和付款帳戶資訊的跨域碼，儲存付款帳戶資訊與付款方帳戶的對應關係，向所述付款方終端返回攜帶有所述跨域碼的回應；所述互連標識是服務於付款發生地域的機構互連伺服器的標識，所述付款帳戶資訊在發碼機構唯一對應於付款方的帳戶；註冊請求發送單元用於向具有所述互連標識的機構互連伺服器發送攜帶有所述跨域碼和授權額度的跨域碼註冊請求，供所述機構互連伺服器在儲存所述跨域碼和授權額度後，在所服務的地域、在授權額度內接受所述付款方終端採用所述跨域碼、以所述付款方帳戶進行的支付。
可選的，所述付款帳戶資訊中包括：所述跨域碼的密碼和有效期中的至少一項，供所述機構互連伺服器在接受採用所述跨域碼的支付前，對支付發生的時間和付款方中的至少一項進行認證。
一個例子中，所述跨域碼的付款帳戶資訊包括以下一項到多項：付款方的出生日期、跨域碼密碼、跨域碼的有效期、用於使付款帳戶資訊唯一對應於所述發碼機構的一個帳戶的去重位。
上述例子中，所述跨域碼的付款帳戶資訊為至少16位元數字，其中包括6位元付款方的出生日期、4位元跨域碼密碼、4位元跨域碼的有效期、和2位元用於使得付款帳戶資訊唯一對應於所述發碼機構的一個帳戶的去重位。
一種實現方式中，所述跨域碼還包括以下至少一項：跨域碼的版本號、業務類型。
上述實現方式中，所述跨域碼為至少24位元數字，其中前2位元數字為互連標識，第3位元數字為跨域碼的版本號，第4位元到第6位元數字為發碼機構標識，第7到第8位元數字為業務類型，第9至最後一位元數字為付款帳戶資訊。
可選的，所述跨域碼發行請求中包括以下的一項到多項：付款方指定的授權額度、付款方指定的跨域碼密碼、付款方指定的跨域碼有效期、付款方的出生日期。
圖14所示為本發明實施例提供的一種跨地域離線支付的註冊裝置，應用在付款方終端上，所述裝置包括發行請求發送單元、發行回應接收單元和跨域碼儲存單元，其中：發行請求發送單元用於向發碼機構的伺服器發送跨域碼發行請求；發行回應接收單元用於接收發碼機構的伺服器返回的攜帶有跨域碼的回應；所述跨域碼包括互連標識、發碼機構標識和付款帳戶資訊，所述互連標識是服務於付款發生地域的機構互連伺服器的標識，所述付款帳戶資訊在發碼機構唯一對應於付款方的帳戶；跨域碼儲存單元用於儲存所述跨域碼，用來在具有所述互連標識的機構互連伺服器所服務的地域內、以所述發碼機構的付款方帳戶進行支付。
一個例子中，所述跨域碼還包括以下至少一項：跨域碼的版本號、業務類型。
上述例子中，所述跨域碼為至少24位元數字，其中前2位元數字為互連標識，第3位元數字為跨域碼的版本號，第4位元到第6位元數字為發碼機構標識，第7到第8位元數字為業務類型，第9至最後一位元數字為付款帳戶資訊。
可選的，所述跨域碼發行請求中包括以下的一項到多項：付款方指定的授權額度、付款方指定的跨域碼密碼、付款方指定的跨域碼有效期、付款方的出生日期。
可選的，所述跨域碼在付款方終端儲存為支付卡卡號、或付款碼碼值。
圖15所示為本發明實施例提供的一種跨地域離線支付的註冊裝置，應用在機構互連伺服器上，所述裝置包括註冊請求接收單元和跨域碼及額度儲存單元，其中：註冊請求接收單元用於接收發碼機構的伺服器發送的攜帶有所述跨域碼和授權額度的跨域碼註冊請求；所述跨域碼包括本伺服器的互連標識、發碼機構標識和付款帳戶資訊，所述付款帳戶資訊在發碼機構唯一對應於付款方的帳戶；跨域碼及額度儲存單元用於儲存所述跨域碼和授權額度，用來在所述授權額度內接受採用所述跨域碼、以所述發碼機構的付款方帳戶進行的支付。
可選的，所述付款帳戶資訊中包括：所述跨域碼的密碼和有效期中的至少一項，用來在接受採用所述跨域碼的支付前，對支付發生的時間和付款方中的至少一項進行認證。
一個例子中，所述跨域碼的付款帳戶資訊包括以下一項到多項：付款方的出生日期、跨域碼密碼、跨域碼的有效期、用於使付款帳戶資訊唯一對應於所述發碼機構的一個帳戶的去重位。
上述例子中，所述跨域碼的付款帳戶資訊為至少16位元數字，其中包括6位元付款方的出生日期、4位元跨域碼密碼、4位元跨域碼的有效期、和2位元用於使得付款帳戶資訊唯一對應於所述發碼機構的一個帳戶的去重位。
一種實現方式中，所述跨域碼還包括以下至少一項：跨域碼的版本號、業務類型。
上述實現方式中，所述跨域碼為至少24位元數字，其中前2位元數字為互連標識，第3位元數字為跨域碼的版本號，第4位元到第6位元數字為發碼機構標識，第7到第8位元數字為業務類型，第9至最後一位元數字為付款帳戶資訊。
圖16所示為本發明實施例提供的一種跨地域離線支付的付款裝置，應用在收單機構的伺服器上，所述裝置包括第一支付請求接收單元、第二支付請求發送單元和第二支付回應接收單元，其中：第一支付請求接收單元用於接收收款設備發送的第一支付請求，所述第一支付請求中包括款項資訊和收款設備從付款方終端獲取的跨域碼；所述跨域碼中包括互連標識；第二支付請求發送單元用於向具有所述互連標識的機構互連伺服器發送攜帶有所述跨域碼和款項資訊的第二支付請求；第二支付回應接收單元用於接收攜帶有支付結果的第二支付回應，所述支付結果由機構互連伺服器根據所述款項資訊和所述跨域碼的剩餘額度確定。
可選的，所述裝置還包括：密碼轉發單元，用於從所述機構互連伺服器接收、並向所述收款設備轉發所述跨域碼的密碼請求，從所述收款設備接收、並向所述機構互連伺服器轉發攜帶有付款方提供的密碼的回應。
一個例子中，所述跨域碼還包括以下至少一項：跨域碼的版本號、業務類型。
上述例子中，所述跨域碼為至少24位元數字，其中前2位元數字為互連標識，第3位元數字為跨域碼的版本號，第4位元到第6位元數字為發碼機構標識，第7到第8位元數字為業務類型，第9至最後一位元數字為付款帳戶資訊。
圖17所示為本發明實施例提供的一種跨地域離線支付的付款裝置，應用在機構互連伺服器上，所述裝置包括第二支付請求接收單元和第二支付請求處理單元：第二支付請求接收單元用於接收收單機構的伺服器發送的攜帶有跨域碼和款項資訊的第二支付請求；所述跨域碼由付款方終端提供；第二支付請求處理單元用於當所述跨域碼的剩餘額度不小於所述款項資訊對應的支付額度時，根據所述款項資訊更新所述跨域碼的剩餘額度，向所述收單機構的伺服器返回支付成功的回應；所述剩餘額度的初始值為所述跨域碼的授權額度。
可選的，所述跨域碼中包括：所述跨域碼的發碼機構標識和付款帳戶資訊：所述裝置還包括結算請求發送單元，用於向具有所述發碼機構標識的發碼機構的伺服器發送攜帶有所述跨域碼和款項資訊的跨域碼結算請求，供所述發碼機構的伺服器根據所述款項資訊，對對應於所述付款帳戶資訊的本機構帳戶進行扣款。
可選的，所述跨域碼中包括：所述跨域碼的密碼；所述裝置還包括密碼獲取單元，用於向所述收單機構的伺服器發送所述跨域碼的密碼請求，接收所述收單機構的伺服器返回攜帶有密碼的回應；所述密碼由付款方提供；所述第二支付請求處理單元具體用於：當跨域碼的剩餘額度不小於所述款項資訊對應的支付額度、並且付款方提供的密碼與所述跨域碼中的密碼相匹配時，根據所述款項資訊更新所述跨域碼的剩餘額度，向所述收單機構的伺服器返回支付成功的回應。
可選的，所述跨域碼中包括：所述跨域碼的有效期；所述第二支付請求處理單元具體用於：當跨域碼的剩餘額度不小於所述款項資訊對應的支付額度、並且接收第二支付請求的時間在所述跨域碼的有效期內時，根據所述款項資訊更新所述跨域碼的剩餘額度，向所述收單機構的伺服器返回支付成功的回應。
圖18所示為本發明實施例提供的一種跨地域離線支付的付款裝置，應用在發碼機構的伺服器上，所述裝置包括結算請求接收單元和結算扣款單元，其中：結算請求接收單元用於接收機構互連伺服器發送的攜帶有跨域碼和款項資訊的跨域碼結算請求；所述跨域碼由付款方終端提供；所述跨域碼中包括唯一對應於本機構一個帳戶的付款帳戶資訊；結算扣款單元用於根據所述款項資訊，對對應於所述付款帳戶資訊的本機構帳戶進行扣款。
可選的，所述跨域碼中還包括：發碼機構標識；所述結算扣款單元具體用於：在確認跨域碼中的發碼機構標識為本機構的發碼機構標識後，根據所述款項資訊，對對應於所述付款帳戶資訊的本機構帳戶進行扣款。
本發明的實施例提供了一種電腦設備，該電腦設備包括記憶體和處理器。其中，記憶體上儲存有能夠由處理器運行的電腦程式；處理器在運行儲存的電腦程式時，執行本發明實施例中應用在發碼機構的伺服器上的跨地域離線支付的註冊方法的各個步驟。對應用在發碼機構的伺服器上的跨地域離線支付的註冊方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本發明的實施例提供了一種電腦設備，該電腦設備包括記憶體和處理器。其中，記憶體上儲存有能夠由處理器運行的電腦程式；處理器在運行儲存的電腦程式時，執行本發明實施例中應用在付款方終端上的跨地域離線支付的註冊方法的各個步驟。對應用在付款方終端上的跨地域離線支付的註冊方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本發明的實施例提供了一種電腦設備，該電腦設備包括記憶體和處理器。其中，記憶體上儲存有能夠由處理器運行的電腦程式；處理器在運行儲存的電腦程式時，執行本發明實施例中應用在機構互連伺服器上的跨地域離線支付的註冊方法的各個步驟。對應用在機構互連伺服器上的跨地域離線支付的註冊方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本發明的實施例提供了一種電腦設備，該電腦設備包括記憶體和處理器。其中，記憶體上儲存有能夠由處理器運行的電腦程式；處理器在運行儲存的電腦程式時，執行本發明實施例中應用在收單機構的伺服器上的跨地域離線支付的付款方法的各個步驟。對應用在收單機構的伺服器上的跨地域離線支付的付款方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本發明的實施例提供了一種電腦設備，該電腦設備包括記憶體和處理器。其中，記憶體上儲存有能夠由處理器運行的電腦程式；處理器在運行儲存的電腦程式時，執行本發明實施例中應用在機構互連伺服器上的跨地域離線支付的付款方法的各個步驟。對應用在機構互連伺服器上的跨地域離線支付的付款方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本發明的實施例提供了一種電腦設備，該電腦設備包括記憶體和處理器。其中，記憶體上儲存有能夠由處理器運行的電腦程式；處理器在運行儲存的電腦程式時，執行本發明實施例中應用在發碼機構的伺服器上的跨地域離線支付的付款方法的各個步驟。對應用在發碼機構的伺服器上的跨地域離線支付的付款方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本發明的實施例提供了一種電腦可讀儲存介質，該儲存介質上儲存有電腦程式，這些電腦程式在被處理器運行時，執行本發明實施例中應用在發碼機構的伺服器上的跨地域離線支付的註冊方法的各個步驟。對應用在發碼機構的伺服器上的跨地域離線支付的註冊方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本發明的實施例提供了一種電腦可讀儲存介質，該儲存介質上儲存有電腦程式，這些電腦程式在被處理器運行時，執行本發明實施例中應用在付款方終端上的跨地域離線支付的註冊方法的各個步驟。對應用在付款方終端上的跨地域離線支付的註冊方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本發明的實施例提供了一種電腦可讀儲存介質，該儲存介質上儲存有電腦程式，這些電腦程式在被處理器運行時，執行本發明實施例中應用在機構互連伺服器上的跨地域離線支付的註冊方法的各個步驟。對應用在機構互連伺服器上的跨地域離線支付的註冊方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本發明的實施例提供了一種電腦可讀儲存介質，該儲存介質上儲存有電腦程式，這些電腦程式在被處理器運行時，執行本發明實施例中應用在收單機構的伺服器上的跨地域離線支付的付款方法的各個步驟。對應用在收單機構的伺服器上的跨地域離線支付的付款方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本發明的實施例提供了一種電腦可讀儲存介質，該儲存介質上儲存有電腦程式，這些電腦程式在被處理器運行時，執行本發明實施例中應用在機構互連伺服器上的跨地域離線支付的付款方法的各個步驟。對應用在機構互連伺服器上的跨地域離線支付的付款方法的各個步驟的詳細描述請參見之前的內容，不再重複。
本發明的實施例提供了一種電腦可讀儲存介質，該儲存介質上儲存有電腦程式，這些電腦程式在被處理器運行時，執行本發明實施例中應用在發碼機構的伺服器上的跨地域離線支付的付款方法的各個步驟。對應用在發碼機構的伺服器上的跨地域離線支付的付款方法的各個步驟的詳細描述請參見之前的內容，不再重複。
以上所述僅為本發明的較佳實施例而已，並不用以限制請求保護的其他實施例，凡在本發明的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在請求保護的範圍之內。
在一個典型的配置中，計算設備包括一個或多個處理器(CPU)、輸入/輸出介面、網路介面和記憶體。
記憶體可能包括電腦可讀介質中的非永久性記憶體，隨機存取記憶體 (RAM)和/或非輝發性記憶體等形式，如唯讀記憶體(ROM)或快閃記憶體(flash RAM)。記憶體是電腦可讀介質的示例。
電腦可讀介質包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。電腦的儲存介質的例子包括，但不限於相變記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可擦除可程式設計唯讀記憶體 (EEPROM)、快閃記憶體或其他記憶體技術、唯讀光碟唯讀記憶體(CD-ROM)、數位多功能光碟(DVD)或其他光學儲存、磁盒式磁帶，磁帶磁磁片儲存或其他磁性存放裝置或任何其他非傳輸介質，可用於儲存可以被計算設備存取的資訊。按照本文中的界定，電腦可讀介質不包括暫存電腦可讀媒體(transitory media)，如調變的資料信號和載波。
還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，並不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。
本領域技術人員應明白，本發明的實施例可提供為方法、系統或電腦程式產品。因此，本發明的實施例可採用完全硬體實施例、完全軟體實施例或結合軟體和硬體方面的實施例的形式。而且，本發明的實施例可採用在一個或多個其中包含有電腦可用程式碼的電腦可用儲存介質(包括但不限於磁碟記憶體、CD-ROM、光學記憶體等)上實施的電腦程式產品的形式。 In the embodiment of the present invention, when making a cross-regional payment, the payer uses a cross-region code to make the payment. The cross-domain code provided by the payee to the payee can be a string of numbers or a string of characters (including one or more of numbers, letters, texts, and symbols); the payer's terminal can use the cross-domain code as a payment card The card number is provided to the payee device, and the cross-domain code can also be rendered into a barcode (such as a one-dimensional barcode, a two-dimensional barcode, or a combination of a one-dimensional barcode and a two-dimensional barcode, etc.); there are no restrictions. The payer has an account with a payment service provider. When the payer uses a cross-domain code to pay, the payment will be transferred out of the payer's account by the payment service provider, and the payment service provider becomes The code-issuing agency of the cross-domain code, this account becomes the payment account of the cross-domain code. The payee of a cross-domain code payment has an account with a payment service provider, and the payee has an acquiring business relationship with the payment service provider. When the payee obtains the cross-domain code in a payment, When the payment service provider's server sends a payment request, the payment service provider that receives the payment request becomes the acquirer in this payment, and the payee's account with the acquirer becomes the acquirer in this payment. Collection account. In embodiments of the present invention, the code-issuing institution's server and the acquiring institution's server are usually located in different geographical areas (such as regions, countries, continents, etc.), and the code-issuing institution's server and the acquiring institution's server Connected to an interconnection network that routes one to multiple institutional interconnection servers to communicate with servers of various payment service providers, all institutional interconnection servers having an identity of the interconnection network, embodiments of the present invention is called the interconnection identifier. The networking structure of the interconnection network is not limited. For example, it can be an IDC (Internet Data Center) composed of interconnected servers of multiple organizations distributed in different geographical areas. For an interconnection network that includes two or more institutional interconnection servers, the server of the code-issuing institution and the server of the acquiring institution can be connected to any one of the institutional interconnection servers. Each institutional interconnection server can be regarded as It is the same organization interconnecting servers. In the embodiment of the present invention, the cross-domain code includes an interconnection identifier, a code-issuing agency identifier, and payment account information. Among them, the interconnection identifier is the identifier of the interconnection network that communicates with the server of the code-issuing institution and the server of the acquiring institution (or the identifier of the interconnection server of the institution); the identifier of the code-issuing institution uniquely represents an issuer of cross-domain code. The coding organization, for example, can be the abbreviation, code or code of the cross-domain code issuing organization. Each payment service provider can determine which coding organization is the cross-domain code issuing organization based on the coding organization identification; the payment account information can be determined by the coding organization It is used to identify an account of the organization, and its specific content can be determined by the code-issuing organization itself, as long as the code-issuing organization can uniquely correspond the payment account information to an account of the organization. The cross-domain code may also include other information without limitation. For example, it may include the service type of the cross-domain code, which is used to limit which type or types of services can only be performed when using the cross-domain code. In one implementation, the cross-domain code adopts an all-numeric format with a length of 24 bits or more, and each bit can be a number from 0 to 9. This cross-domain code consists of a header with a fixed length of 8 bits and a payload with a variable length from 16 bits to more than 16 bits. As shown in Figure 1, the first 2 digits of the header It is an interconnection identifier, the third digit is the version number of the cross-domain code, the 4th to 6th digits are the code-issuing agency identification, the 7th to 8th digits are the business type; from the 9th digit The metadigit starts with the payload, and the payload is the payment account information, that is, the 9th to the last metadigit of the cross-domain code is the payment account information. Cross-domain codes can be used in clear text, so payment account information in cross-domain codes usually avoid using account names, account numbers, and other content that may reveal user privacy or bring security risks. For example, the payment account information may include one or more of the user's birth date, cross-domain code password, and cross-domain code validity period. Among them, the password of the cross-domain code is used by the institution's interconnection server to authenticate the payer before accepting payment using the cross-domain code. The validity period of the cross-domain code is used by the institutional interconnection server to verify whether the time when the payment occurs is within the validity period of the cross-domain code before accepting payment using the cross-domain code. In addition, the payment account information can also include deduplication bits. The value of the deduplication bit can be set by the server of the code issuing agency, so that when different accounts of the code issuing agency have the same user date of birth, cross-domain code When the password and cross-domain code are valid, the server of the code-issuing institution can set a different deduplication bit value for each account so that one payment account information uniquely corresponds to an account of the code-issuing institution. Still taking the cross-domain code shown in Figure 1 as an example, the 9th to the last digit is the payment account information, which can include the 6-digit birth date of the payer (for example, 830112 means that the payer user was born in January 1983 12th), a 4-digit cross-domain code password, a 4-digit cross-domain code validity period (for example, 2208 indicates that the cross-domain code is valid until August 2022), and a 2-digit deduplication bit. It should be noted that offline payment in the embodiment of the present invention means that when payment occurs, there is no communication between the payer terminal and the server of the payment service provider (ie, the code issuance agency) to which the payment account belongs, that is, relative to The server of the code-issuing institution and the payer terminal are offline; it does not mean that the payer terminal cannot communicate with any device. Embodiment 1 of the present invention proposes a registration method for cross-regional offline payment. After receiving a request from the payer terminal, the server of the code-issuing institution generates a cross-domain code including an interconnection identification, a code-issuing institution identification and payment account information. , issue it to the payer terminal, and register the cross-domain code and its authorization amount to the institutional interconnection server with the interconnection identifier. The payer terminal can use the cross-domain code in the region served by the institutional interconnection server. The domain code is used for payment and is confirmed by the organization's interconnection server, so that the payment can be completed in the region served by the organization's interconnection server without the participation of the server of the issuing organization, and the payer and the payee do not have to wait for a long time Cross-regional communication saves payment time and improves payment efficiency. A network structure of the application scenario of Embodiment 1 of the present invention is shown in Figure 2. The payer terminal and the server of the code issuing institution, and the connection between the server of the code issuing institution and the institution interconnection server can be connected through the network. communication. Among them, the payer terminal can be a mobile phone, tablet computer, PC (Personal Computer, personal computer), notebook computer and other equipment; the server or institutional interconnection server of the code-issuing institution can be a physical or logical server, or it can Two or more entities or logical servers sharing different responsibilities cooperate with each other to realize various functions of the server of the code issuing mechanism or the mechanism interconnection server in the embodiment of the present invention. In the first embodiment of the present invention, the process of applying the registration method for cross-regional offline payment on the server of the code-issuing institution is shown in Figure 3, and the process of applying it on the payer terminal is shown in Figure 4. The process of connecting to the server is shown in Figure 5. On the payer terminal, in step 410, a cross-domain code issuance request is sent to the server of the code issuing institution. On the server of the code issuing institution, step 310 receives the cross-domain code issuance request sent by the payer terminal. When a payer wishes to use its account with a code-issuing institution to make mobile payments in regions other than the code-issuing institution's service area, the payer can send a cross-region code issuance request to the code-issuing institution's server through the payer's terminal. The payer can initiate this request through the cross-domain code request function provided by the client software of the code-issuing institution installed on its terminal, or by accessing the website of the code-issuing institution, or by other means. method, without limitation. For cross-domain codes that may require a password when used, the initial password can be determined by the server of the code-issuing institution; the payer can also specify the password for the cross-domain code and then carry the specified password in the cross-domain code issuance request. To the server of the code-issuing organization. For cross-domain codes with a validity period, the validity period can be determined by the server of the code-issuing organization; the payer can also specify the validity period of the cross-domain code, and send the specified validity period to the server of the code-issuing organization in the cross-domain code issuance request. device. For cross-domain codes that include the payer's date of birth in the payment account information, the code-issuing agency's server can determine the date of birth based on the payer's ID number; it can also be entered by the payer themselves, and the payer's terminal will input the date of birth. Sent to the server of the code issuing organization in a cross-domain code issuance request. On the server of the code-issuing institution, step 320 generates a cross-domain code including the interconnection identification, the code-issuing institution identification and the payment account information, stores the corresponding relationship between the payment account information and the payer's account, and returns the ported code to the payer's terminal. There is a response for this cross-domain code. On the payer's terminal, in step 420, a response carrying the cross-domain code returned by the server of the code-issuing institution is received. After receiving the cross-domain code issuance request, the code-issuing agency's server generates cross-domain code payment account information. The content and generation method of the payment account information can be determined by the code-issuing organization, as long as the code-issuing organization's server can uniquely correspond the payment account information to an account of the organization. After the payment account information is generated, the server of the code issuing organization stores the corresponding relationship between the payment account information and the payer account using the payer terminal. The server of the code-issuing institution adopts the identifier of the Internet connecting this server and servers of payment service providers serving other regions (including servers serving payment service providers in the region where payment occurs) (i.e., the Internet). The cross-domain code is generated using the interconnection ID of each institution's interconnection server), the code-issuing institution's ID of the code-issuing institution, and the payment account information. The generated cross-domain code is encapsulated in the cross-domain code issuance response and returned Give payment to the terminal. Depending on the specific composition of the cross-domain code in the actual application scenario, the cross-domain code generated by the server of the code issuing organization may also include other information, such as business type, version number, etc. When the cross-domain code issuance request carries one or more of the password of the cross-domain code specified by the payer, the validity period of the cross-domain code specified by the payer, and the date of birth of the payer, the server of the code-issuing institution will use the cross-domain code according to the cross-domain code issuance request. This information in the domain code issuance request is used to generate cross-domain codes. On the payer terminal, step 430, the cross-domain code is stored, which is used to make payment with the payer account of the code-issuing institution in the region served by the institution interconnection server with the interconnection identifier. The payer terminal extracts the cross-domain code from the cross-domain code issuance response and stores the cross-domain code locally. When the payer is in the region served by the Internet and wants to make an offline payment using the payer's account at the code-issuing institution, the stored cross-domain code can be used to pay the payee. Depending on the specific payment form used by the payer's terminal, the cross-domain code can be stored as a payment card number in the payer's terminal, which will be presented to the payee or transmitted to the payee's collection device when the payer's terminal pays; it can also be stored It is the payment code value, which is rendered by the payer's terminal into a barcode, QR code, etc. for scanning by the payee's payment equipment during payment; other methods are also possible. On the server of the code-issuing institution, in step 330, a cross-domain code registration request carrying the cross-domain code and the authorization amount is sent to the institution interconnection server with the interconnection identifier, so that the institution interconnection server can store the cross-domain code. After entering the cross-domain code and authorization limit, the payer's terminal will accept payments using the cross-domain code and the payer's account in the region served and within the authorized limit. On the institution interconnection server, in step 510, receive the cross-domain code registration request carrying the cross-domain code and authorization quota sent by the server of the code-issuing institution. After the code-issuing agency server generates the cross-domain code for the payer terminal, it determines the authorization amount of the cross-domain code. The authorization amount is the total amount that the payer's terminal can pay using the cross-domain code. The authorization limit can be determined by the code-issuing institution, for example, the code-issuing institution's server determines it based on the payer's credit limit; it can also be set by the payer itself, for example, after the payer enters the authorization limit on its terminal, the payer's terminal In the cross-domain code issuance request, the authorization amount specified by the payer is transmitted to the server of the code issuing institution. The server of the code-issuing institution encapsulates the cross-domain code and the authorization quota of the cross-domain code in the cross-domain code registration request, and sends it to the institutional interconnection server with the interconnection identifier in the cross-domain code. On the institution interconnection server, in step 520, the cross-domain code and the authorization limit are stored, which are used to accept payments using the cross-domain code and the payer account of the code-issuing institution within the authorization limit. After receiving the cross-domain code registration request, the institutional interconnection server stores the cross-domain code and its authorization amount in an accessible storage location. When receiving a request for payment using the cross-domain code, the institutional interconnection server can accept the payment using the cross-domain code within the authorization limit of the cross-domain code, and communicate with the code-issuing institution server through Interact, and finally deduct the payment from the payer account corresponding to the payment account information in the cross-domain code. It can be seen that in the first embodiment of the present invention, according to the request of the payer terminal, the server of the code-issuing institution generates a cross-domain code including the interconnection identification, the code-issuing institution identification and the payment account information, and issues it to the payer terminal, and Register the cross-domain code and its authorization amount with the institutional interconnection server with the interconnection identifier. The payer terminal can use the cross-domain code for payment in the region served by the institutional interconnection server and be interconnected by the institution. The server confirms, and the payment process can be completed without accessing the server of the code-issuing institution, which avoids long waits caused by cross-regional communication links, saves payment time, improves payment efficiency, and improves the relationship between the payer and Payee experience. Embodiment 2 of the present invention proposes a payment method for cross-regional offline payment. The payer terminal provides a cross-domain code when making payment, and the server of the acquirer sends the cross-domain code and payment information to a client with an interconnection identifier in the cross-domain code. The institutional interconnection server determines whether to accept payment based on the remaining balance of the cross-domain code it maintains, so that the payer terminal does not need the server of the code-issuing institution in the region served by the institutional interconnection server. Payment can be completed by participating. The payer and payee do not have to wait for long cross-regional communication, which saves payment time and improves payment efficiency. A network structure of the application scenario of Embodiment 2 of the present invention is shown in Figure 6. The payer's terminal and the payee's payment device can conduct close-range data exchange, such as scanning or communicating through a wireless local area network; payment collection Communication can be carried out through the network between the device and the payee's acquirer's server, between the acquirer's server and the institution's interconnection server, and between the institution's interconnection server and the code-issuing institution's server. . Among them, the payer terminal can be a mobile phone, tablet computer, PC (Personal Computer, personal computer), notebook computer and other devices; the payee device can be one or two devices with scanning and calculation functions, or communication and calculation functions. A combination of one or more devices, such as mobile phones, tablets, code scanners, PCs, laptops and other devices; the server of the code-issuing institution, the server of the acquiring institution or the institution interconnection server can be an entity or a logical The server can also be composed of two or more entities or logical servers that share different responsibilities and cooperate with each other to implement the server of the code issuing mechanism, the server of the acquiring mechanism, or the interworking server of the mechanism in the embodiment of the present invention. various functions of the device. In the second embodiment of the present invention, the process of applying the payment method for cross-regional offline payment on the acquirer's server is shown in Figure 7, and the process of applying it on the institution's interconnection server is shown in Figure 8. The process on the server of the code issuing organization is shown in Figure 9. When the payer comes outside the region served by the code-issuing institution of his account and wishes to use the account to pay, he can use the cross-domain code issued by the code-issuing institution in Embodiment 1 to start the payment process. The payer's terminal provides the cross-domain code to the payee's payment device when making payment. For example, the cross-domain code is transmitted to the payment device as the card number of the payment card, or the cross-domain code is rendered as a code value and displayed to the payment code. Scanning of payment collection equipment. After the payment device obtains the cross-domain code, it encapsulates the cross-domain code and the payment information of this payment in the first payment request and sends it to the server of the payee's acquirer. Among them, the payment information is used to determine the specific amount of the payment, for example, it can be the payment amount, or the payment amount and currency, etc. The first payment request may also include other information, such as transaction information describing this transaction. On the acquirer's server, in step 710, receive the first payment request sent by the payment device. The first payment request includes payment information and a cross-domain code obtained by the payment device from the payer's terminal. On the acquirer's server, step 720, send a second payment request carrying the cross-domain code and payment information to the institution's interconnection server with the interconnection identifier; on the institution's interconnection server, step 810, Receive the second payment request carrying the cross-domain code and payment information sent by the acquirer's server. This cross-domain code is provided by the payer terminal. As described in Embodiment 1, the cross-domain code includes an interconnection identifier, a code-issuing institution identifier, and payment account information. In addition, it may also include one or both of the password of the cross-domain code and the validity period of the cross-domain code. When the acquirer's server processes a payment request from a payment device, if the payment card number or payment code value in the request carries an interconnection identifier, it can identify that the payment was made using a cross-domain code. Payments require institutional interconnection servers for processing. When the first payment request carries the interconnection identifier, the acquirer's server sends the second payment carrying the cross-domain code and payment information in the first payment request to the institution's interconnection server with the interconnection identifier. request. The acquirer's server can directly send the first payment request as the second payment request to the institution interconnection server, or it can generate the second payment request in the format agreed with the institution interconnection server. It encapsulates the cross-domain code and payment information, and can also encapsulate other information, such as transaction information, etc. On the institutional interconnection server, step 820, when the remaining limit of the cross-domain code is not less than the payment limit corresponding to the payment information, update the remaining limit of the cross-domain code based on the payment information and report it to the acquirer's server. Returns a successful payment response. The initial value of the remaining quota is the authorization quota of the cross-domain code. On the acquirer's server, in step 730, a second payment response carrying the payment result is received. The payment result is determined by the institution's interconnection server based on the payment information and the remaining balance of the cross-domain code. The institutional interconnection server maintains the remaining quota for each registered cross-domain code. The remaining amount is the total amount that the payer can subsequently pay using the cross-domain code, which is equal to the authorization limit of the cross-domain code minus the amount paid using the cross-domain code after registration. The initial value of the remaining limit is the authorized limit of the cross-domain code. Each time a payment is successfully made using the cross-domain code, the amount of this payment will be deducted from the remaining limit. The institutional interconnection server receives the second payment request sent by the acquirer's server and extracts the cross-domain code and payment information. After confirming that the cross-domain code is a cross-domain code that has been registered on this interconnection network, the institutional interconnection server determines the payment amount of this payment based on the payment information. If the remaining amount of the cross-domain code is greater than or equal to the payment amount of this payment, the remaining amount of the cross-domain code is updated based on the payment information, that is, the remaining amount of the cross-domain code is updated to the remaining amount before the update minus this payment. The payment amount is paid, and the institution interconnection server returns a second payment response to the acquirer's server, which carries a message of successful payment. If the cross-domain code is not a cross-domain code registered on this interconnection network, or the remaining amount of the cross-domain code is less than the payment amount of this payment, the institutional interconnection server returns a payment failure message to the acquirer's server. The second payment response to the message. In the application scenario where the cross-domain code includes the validity period of the cross-domain code, the cross-domain code in the second payment request by the institution's interconnection server is the cross-domain code that has been registered in this interconnection network, and the time of receiving the second payment request Within the validity period of the cross-domain code, and the remaining balance of the cross-domain code is not less than the payment amount of this payment, the remaining balance of the cross-domain code will be updated based on the payment amount of this payment, and the remaining amount of the cross-domain code will be reported to the server of the acquirer. The server returns a response that the payment is successful; otherwise, it returns a response that the payment failed to the server of the acquirer. In application scenarios where the cross-domain code includes the validity period of the cross-domain code, the institutional interconnection server can require the payer to provide a password every time a payment is made, or when necessary (such as when the payment exceeds a predetermined amount, or when the transaction When the information meets the predetermined security conditions, etc.) the payer is required to provide a password. Specifically, the institution interconnection server can send the cross-domain code password request to the acquirer's server, and the acquirer's server forwards the cross-domain code password request to the payment device; the payee requests After the payer enters the password on the payment device, the entered password is encapsulated in a password response and sent to the acquirer's server; the acquirer's server forwards the password response to the institution's interconnection server. The institutional interconnection server extracts the password provided by the payer from the password response. When the cross-domain code in the second payment request is a cross-domain code that has been registered on this interconnection network, the password provided by the payer and the cross-domain code in the cross-domain code When the passwords match and the remaining balance of the cross-domain code is not less than the payment amount of this payment, the remaining balance of the cross-domain code is updated based on the payment amount of this payment, and a successful payment is returned to the acquirer's server. response; otherwise, a payment failure response is returned to the acquirer's server. On the server of the code-issuing institution, step 910 receives the cross-domain code settlement request carrying the cross-domain code and payment information sent by the institution's interconnection server. This cross-domain code is provided by the payer terminal. For a successful payment using a cross-domain code, the institution interconnection server generates a cross-domain code settlement request carrying the cross-domain code and the payment information of the payment, and sends it to the person with the code-issuing institution identification in the cross-domain code The server of the code issuing organization. Cross-domain code settlement requests can also include other information, such as transaction information, the time when payment occurs, the password entered by the payer when making payment, etc. On the server of the code-issuing institution, step 920 debits the institution's account corresponding to the payment account information based on the payment information. The server of the code-issuing institution receives the cross-domain code settlement request and extracts the code-issuing institution identification and payment account information from the cross-domain code. The code-issuing institution confirms that the code-issuing institution ID in the cross-domain code is the code-issuing institution ID of the organization, and searches for the corresponding payment account information in the cross-domain code settlement request from the correspondence between the stored payment account information and the organization's account. This organization's account uses the found account as the payment account, and deducts the amount corresponding to the payment information from the payment account. After the deduction is successful, the server of the code-issuing institution can return a successful settlement response to the institution's interconnection server. The settlement process between the code-issuing organization's server and the organization's interconnection server is carried out after the payment is successful. Even if the communication time between the code-issuing organization's server and the organization's interconnection server takes a long time, it will not affect the payer and the recipient. The speed of payment between parties. The foregoing has described specific embodiments of the invention. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claimed claims can be performed in a different order than in the embodiments and still achieve desirable results. Additionally, the processes depicted in the drawings do not necessarily require the specific order shown, or a sequential order, to achieve desirable results. In certain embodiments, multiplexing and parallel processing are also possible or may be advantageous. In an application example of the present invention, payment service provider Inst_A in country A joins a payment service alliance. The members of this alliance include payment service providers from several countries (such as payment service provider Inst_B in country B). A certain alliance Members' users can use their accounts to make payments in these countries, and merchants that use a certain alliance member as their acquirer can also receive payments from all alliance member users. The payment service alliance has established an interconnection network including several institutional interconnection servers. These institutional interconnection servers form an IDC center to communicate with the servers of each alliance member. User_A of Inst_A wants to use his account opened in Inst_A to make mobile payments in country B where the payment service alliance provides services. He can first apply to the server of Inst_A to register a cross-domain code. Inst_A becomes the code-issuing agency of the cross-domain code. See Figure 11 for the interaction process when registering a cross-domain code. User_A opens the page for registering a cross-domain code in Inst_A's client App (application) on his terminal (a kind of payer terminal), and enters his date of birth (set to January 12, 1983), cross-domain code on the page. After setting the password of the domain code (set to 1234), the validity period of the cross-domain code (set to August 2022), and the authorization limit, instruct to apply for the cross-domain code. The App encapsulates the above information entered by the user in a cross-domain code issuance request and sends it to the server of Inst_A. Inst_A's server follows the composition structure shown in Figure 1, and sets the payment service alliance's identifier (an interconnection identifier, set to 28), the cross-domain code version number (set to 1), and the organization's code-issuing agency identifier. (set to 006), business type (set to 02, indicating offline payment) to form the header of the cross-domain code; combine the date of birth (830112), the password of the cross-domain code (1234), the deduplication bit (set to 00) and The validity period of the cross-domain code (2208) constitutes the payment account information, resulting in the cross-domain code 281006028301121234002208. The server of Inst_A encapsulates the generated cross-domain code in the cross-domain code issuance response and returns it to the App of User_A terminal. Inst_A's server stores the correspondence between the payment account information in the cross-domain code and User_A's account. The App of User_A's terminal receives the cross-domain code issuance response, stores the cross-domain code locally, and notifies User_A that the cross-domain code application has been successful. Inst_A's server encapsulates the cross-domain code and the authorization quota specified by User_A for the cross-domain code in a cross-domain code registration request and sends it to the institutional interconnection server of the Internet. After verifying that the cross-domain code meets the standards shown in Figure 1, the institutional interconnection server stores the cross-domain code and its authorization quota, and sets the remaining quota of the cross-domain code as its authorization quota. The institutional interconnection server returns a cross-domain code registration response to Inst_A's server, informing Inst_A's server that the registration is successful. When User_A comes to country B, he spends money at merchant Merc_B. The process of User_A using cross-domain code payment is shown in Figure 12. User_A opens the cross-domain code payment page in Inst_A's client App on his terminal. The App reads the stored cross-domain code and renders it as a code value into a one-dimensional barcode and/or a two-dimensional barcode. After scanning the merchant Merc_B's payment device, the cross-domain code is obtained. The cross-domain code, payment information, and transaction information are encapsulated in the first payment request and sent to the server of Merc_B's acquirer Inst_B. The server of Inst_B extracts the cross-domain code in the first payment request, and according to the identifier 28 of the payment service alliance, learns that the payment request needs to be processed by the Internet. Inst_B's server encapsulates the cross-domain code, payment information and transaction information in the second payment request and sends it to the institutional interconnection server. The institutional interconnection server extracts the cross-domain code in the second payment request, searches for the cross-domain code in the stored cross-domain codes, and checks whether the time when the second payment request is received is within the validity period of the cross-domain code. And based on the payment information, it is judged whether the remaining balance of the cross-domain code is sufficient for this payment. If all the above items are yes, the institutional interconnection server will deduct the amount of this payment from the remaining balance of the cross-domain code, and return a second payment response carrying the payment success message to the server of Inst_B. Inst_B's server returns the first payment response of successful payment to Merc_B's payment device, and Merc_B's payment device notifies the merchant that the payment is successful. The institution interconnection server encapsulates the cross-domain code, the payment information and transaction information in the cross-domain code settlement request, and sends it to the server of Inst_A based on the code-issuing institution identification 006 in the cross-domain code. Inst_A's server confirms that the code-issuing agency ID in the cross-domain code is the code-issuing agency ID of this organization, searches for the correspondence between the stored payment account information and the account, and learns that it corresponds to the cross-domain code in the cross-domain code settlement request. The account is User_A's account. Inst_A's server deducts the amount corresponding to the payment information from User_A's account and returns a successful settlement response to the institutional interconnection server. Corresponding to the above process implementation, embodiments of the present invention also provide a registration device for cross-regional offline payment applied on the server of the code issuing institution, a registration device for cross-regional offline payment applied on the payer terminal, a A registration device for cross-regional offline payment applied to the institutional interconnection server, a payment device for cross-regional offline payment applied to the acquirer's server, and a cross-regional offline payment application applied to the institutional interconnection server payment device. The above devices can be implemented by software, or can be implemented by hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by reading the corresponding computer program instructions into the memory and running them through the CPU (Central Process Unit) of the device. From a hardware perspective, in addition to the CPU, built-in memory, and memory shown in Figure 12, the equipment in which the above-mentioned devices are located usually also includes other hardware such as chips used for wireless signal transmission and reception, and/or user interfaces. Board cards and other hardware used to implement network communication functions. Figure 13 shows a registration device for cross-regional offline payment provided by an embodiment of the present invention, applied on a server of a code issuing institution. The device includes an issuance request receiving unit, an issuance response sending unit and a registration request sending unit, where : The issuance request receiving unit is used to receive the cross-domain code issuance request sent by the payer terminal; the issuance response sending unit is used to generate the cross-domain code including the interconnection identification, the code issuing institution identification and the payment account information, and store the payment account information and payment The corresponding relationship between the payer's account and the response carrying the cross-domain code is returned to the payer terminal; the interconnection identifier is the identifier of the institutional interconnection server serving the region where the payment occurs, and the payment account information is sent The code institution uniquely corresponds to the account of the payer; the registration request sending unit is used to send a cross-domain code registration request carrying the cross-domain code and the authorization amount to the institution interconnection server with the interconnection identification for the After storing the cross-domain code and the authorization limit, the institutional interconnection server accepts the payment made by the payer terminal using the cross-domain code and the payer account in the region served and within the authorization limit. Optionally, the payment account information includes: at least one of the password and validity period of the cross-domain code, so that the institution interconnection server can check the payment before accepting the payment using the cross-domain code. At least one of the time and payer must be authenticated. In one example, the payment account information of the cross-domain code includes one or more of the following: the payer's date of birth, the cross-domain code password, the validity period of the cross-domain code, and the payment account information used to uniquely correspond to the issuance code. Deduplication of an account of an organization. In the above example, the payment account information of the cross-domain code is at least 16 digits, including the 6-digit date of birth of the payer, the 4-digit cross-domain code password, the validity period of the 4-digit cross-domain code, and 2 The bit is used to make the payment account information uniquely correspond to the deduplication bit of an account of the code issuing institution. In one implementation, the cross-domain code further includes at least one of the following: a version number of the cross-domain code and a service type. In the above implementation, the cross-domain code is a number of at least 24 digits, of which the first 2 digits are the interconnection identifier, the third digit is the version number of the cross-domain code, and the 4th to 6th digits are The number is the identification of the code-issuing institution, the 7th to 8th digits are the business type, and the 9th to last digits are the payment account information. Optionally, the cross-domain code issuance request includes one or more of the following: the authorization amount specified by the payer, the cross-domain code password specified by the payer, the validity period of the cross-domain code specified by the payer, and the payer's date of birth. . Figure 14 shows a registration device for cross-regional offline payment provided by an embodiment of the present invention, applied on a payer terminal. The device includes an issuance request sending unit, an issuance response receiving unit and a cross-domain code storage unit, where: issuance The request sending unit is used to send a cross-domain code issuance request to the server of the code-issuing organization; the issuance response receiving unit is used to receive a response carrying the cross-domain code returned by the server of the code-issuing organization; the cross-domain code includes interconnection Identity, code-issuing institution identification and payment account information. The interconnection identification is the identification of the institutional interconnection server serving the region where the payment occurs. The payment account information uniquely corresponds to the payer's account at the code-issuing institution; cross-domain The code storage unit is used to store the cross-domain code, which is used to make payments with the payer account of the code-issuing institution in the region served by the institution interconnection server with the interconnection identification. In one example, the cross-domain code further includes at least one of the following: a version number of the cross-domain code and a service type. In the above example, the cross-domain code is a number of at least 24 digits, of which the first 2 digits are the interconnection identifier, the third digit is the version number of the cross-domain code, and the 4th to 6th digits are the version number of the cross-domain code. It is the identification of the code-issuing institution, the 7th to 8th digits are the business type, and the 9th to last digits are the payment account information. Optionally, the cross-domain code issuance request includes one or more of the following: the authorization amount specified by the payer, the cross-domain code password specified by the payer, the validity period of the cross-domain code specified by the payer, and the payer's date of birth. . Optionally, the cross-domain code is stored in the payer terminal as a payment card number or payment code value. Figure 15 shows a registration device for cross-regional offline payment provided by an embodiment of the present invention, applied on an institutional interconnection server. The device includes a registration request receiving unit and a cross-domain code and quota storage unit, where: registration request The receiving unit is used to receive the cross-domain code registration request carrying the cross-domain code and the authorization amount sent by the server of the code-issuing institution; the cross-domain code includes the interconnection identification of the server, the code-issuing institution identification and the payment Account information, the payment account information uniquely corresponds to the payer's account in the code-issuing institution; the cross-domain code and quota storage unit is used to store the cross-domain code and authorization quota, and is used to accept all transactions within the authorization quota. The above-mentioned cross-domain code is paid with the payer account of the above-mentioned code-issuing institution. Optionally, the payment account information includes: at least one of the password and validity period of the cross-domain code, which is used to verify the time when the payment occurs and the payer before accepting payment using the cross-domain code. At least one of the In one example, the payment account information of the cross-domain code includes one or more of the following: the payer's date of birth, the cross-domain code password, the validity period of the cross-domain code, and the payment account information used to uniquely correspond to the issuance code. Deduplication of an account of an organization. In the above example, the payment account information of the cross-domain code is at least 16 digits, including the 6-digit date of birth of the payer, the 4-digit cross-domain code password, the validity period of the 4-digit cross-domain code, and 2 The bit is used to make the payment account information uniquely correspond to the deduplication bit of an account of the code issuing institution. In one implementation, the cross-domain code further includes at least one of the following: a version number of the cross-domain code and a service type. In the above implementation, the cross-domain code is a number of at least 24 digits, of which the first 2 digits are the interconnection identifier, the third digit is the version number of the cross-domain code, and the 4th to 6th digits are The number is the identification of the code-issuing institution, the 7th to 8th digits are the business type, and the 9th to last digits are the payment account information. Figure 16 shows a payment device for cross-regional offline payment provided by an embodiment of the present invention, applied on a server of an acquirer. The device includes a first payment request receiving unit, a second payment request sending unit and a second payment request sending unit. A payment response receiving unit, wherein: the first payment request receiving unit is used to receive a first payment request sent by the payment device, where the first payment request includes payment information and a cross-domain code obtained by the payment device from the payer terminal; The cross-domain code includes an interconnection identifier; the second payment request sending unit is configured to send a second payment request carrying the cross-domain code and payment information to the institutional interconnection server with the interconnection identifier; The second payment response receiving unit is configured to receive a second payment response carrying a payment result. The payment result is determined by the institution interconnection server based on the payment information and the remaining balance of the cross-domain code. Optionally, the device further includes: a password forwarding unit, configured to receive the password request of the cross-domain code from the institution interconnection server and forward it to the payment device, and to receive the password request from the payment device. , forwarding a response carrying the password provided by the payer to the institutional interconnection server. In one example, the cross-domain code further includes at least one of the following: a version number of the cross-domain code and a service type. In the above example, the cross-domain code is a number of at least 24 digits, of which the first 2 digits are the interconnection identifier, the third digit is the version number of the cross-domain code, and the 4th to 6th digits are the version number of the cross-domain code. It is the identification of the code-issuing institution, the 7th to 8th digits are the business type, and the 9th to last digits are the payment account information. Figure 17 shows a payment device for cross-regional offline payment provided by an embodiment of the present invention, applied on an institutional interconnection server. The device includes a second payment request receiving unit and a second payment request processing unit: second payment The request receiving unit is used to receive the second payment request carrying the cross-domain code and payment information sent by the server of the acquirer; the cross-domain code is provided by the payer terminal; the second payment request processing unit is used to when the When the remaining limit of the cross-domain code is not less than the payment limit corresponding to the payment information, the remaining limit of the cross-domain code is updated according to the payment information, and a response of successful payment is returned to the server of the acquirer; The initial value of the remaining quota is the authorization quota of the cross-domain code. Optionally, the cross-domain code includes: the code-issuing institution identification and payment account information of the cross-domain code: the device also includes a settlement request sending unit for sending the code-issuing institution identification with the code-issuing institution identification. The server of the organization sends a cross-domain code settlement request carrying the cross-domain code and payment information, so that the server of the code-issuing organization performs the processing on the organization's account corresponding to the payment account information based on the payment information. Deduction. Optionally, the cross-domain code includes: a password of the cross-domain code; the device further includes a password acquisition unit for sending a password request for the cross-domain code to the server of the acquirer, The server that receives the acquirer returns a response carrying a password; the password is provided by the payer; the second payment request processing unit is specifically used: when the remaining amount of the cross-domain code is not less than the amount corresponding to the payment information When the payment limit is reached and the password provided by the payer matches the password in the cross-domain code, the remaining limit of the cross-domain code is updated according to the payment information, and payment success is returned to the server of the acquirer. response. Optionally, the cross-domain code includes: the validity period of the cross-domain code; the second payment request processing unit is specifically used to: when the remaining amount of the cross-domain code is not less than the payment amount corresponding to the payment information, And when the time of receiving the second payment request is within the validity period of the cross-domain code, the remaining balance of the cross-domain code is updated according to the payment information, and a response of successful payment is returned to the server of the acquirer. Figure 18 shows a payment device for cross-regional offline payment provided by an embodiment of the present invention, applied on a server of a code issuing institution. The device includes a settlement request receiving unit and a settlement deduction unit, wherein: the settlement request receiving unit Used to receive cross-domain code settlement requests carrying cross-domain codes and payment information sent by the institution's interconnection server; the cross-domain code is provided by the payer's terminal; the cross-domain code includes a unique account corresponding to the institution The payment account information; the settlement and deduction unit is used to debit the account of the organization corresponding to the payment account information based on the payment information. Optionally, the cross-domain code also includes: a code-issuing agency identifier; the settlement deduction unit is specifically used to: after confirming that the code-issuing agency identifier in the cross-domain code is the code-issuing agency identifier of the organization, according to The payment information is used to debit the institution's account corresponding to the payment account information. An embodiment of the present invention provides 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 registration method for cross-regional offline payment applied on the server of the code issuing institution in the embodiment of the present invention. various steps. For a detailed description of each step of the registration method for cross-regional offline payment applied on the server of the code issuing institution, please refer to the previous content and will not be repeated. An embodiment of the present invention provides a computer device, which includes a memory and a processor. 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 registration method for cross-regional offline payment applied on the payer terminal in the embodiment of the present invention. For a detailed description of each step of the registration method for cross-regional offline payment applied on the payer terminal, please refer to the previous content and will not be repeated. An embodiment of the present invention provides a computer device, which includes a memory and a processor. 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 registration methods for cross-regional offline payment applied on the institutional interconnection server in the embodiment of the present invention. steps. For a detailed description of each step of the registration method for cross-regional offline payment applied on the institution's interconnection server, please refer to the previous content and will not be repeated. An embodiment of the present invention provides 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 cross-regional offline payment payment method applied on the server of the acquirer in the embodiment of the present invention. various steps. For a detailed description of each step of the payment method for cross-regional offline payment applied on the server of the acquirer, please refer to the previous content and will not be repeated. An embodiment of the present invention provides a computer device, which includes a memory and a processor. 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 payment methods for cross-regional offline payment applied on the institutional interconnection server in the embodiment of the present invention. steps. For a detailed description of each step of the payment method for cross-regional offline payment applied on the institution's interconnection server, please refer to the previous content and will not be repeated. An embodiment of the present invention provides 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 cross-regional offline payment payment method applied on the server of the code issuing institution in the embodiment of the present invention. various steps. For a detailed description of each step of the payment method for cross-regional offline payment applied on the server of the code issuing institution, please refer to the previous content and will not be repeated. Embodiments of the present invention provide a computer-readable storage medium. Computer programs are stored on the storage medium. When these computer programs are run by a processor, they execute the cross-platform operations applied to the server of the code issuing mechanism in the embodiment of the present invention. Each step of the registration method for regional offline payment. For a detailed description of each step of the registration method for cross-regional offline payment applied on the server of the code issuing institution, please refer to the previous content and will not be repeated. Embodiments of the present invention provide a computer-readable storage medium. Computer programs are stored on the storage medium. When these computer programs are run by a processor, they execute the cross-regional offline payment applied on the payer terminal in the embodiment of the present invention. the various steps of the registration method. For a detailed description of each step of the registration method for cross-regional offline payment applied on the payer terminal, please refer to the previous content and will not be repeated. Embodiments of the present invention provide a computer-readable storage medium. Computer programs are stored on the storage medium. When these computer programs are run by a processor, they execute the cross-region cross-region server application in the embodiment of the present invention. Various steps of the registration method for offline payment. For a detailed description of each step of the registration method for cross-regional offline payment applied on the institution's interconnection server, please refer to the previous content and will not be repeated. Embodiments of the present invention provide a computer-readable storage medium. Computer programs are stored on the storage medium. When these computer programs are run by a processor, they execute the cross-border processing applied on the server of the acquirer in the embodiment of the present invention. Various steps of the payment method for regional offline payment. For a detailed description of each step of the payment method for cross-regional offline payment applied on the server of the acquirer, please refer to the previous content and will not be repeated. Embodiments of the present invention provide a computer-readable storage medium. Computer programs are stored on the storage medium. When these computer programs are run by a processor, they execute the cross-region cross-region server application in the embodiment of the present invention. Various steps of payment methods for offline payments. For a detailed description of each step of the payment method for cross-regional offline payment applied on the institution's interconnection server, please refer to the previous content and will not be repeated. Embodiments of the present invention provide a computer-readable storage medium. Computer programs are stored on the storage medium. When these computer programs are run by a processor, they execute the cross-platform operations applied to the server of the code issuing mechanism in the embodiment of the present invention. Various steps of the payment method for regional offline payment. For a detailed description of each step of the payment method for cross-regional offline payment applied on the server of the code issuing institution, please refer to the previous content and will not be repeated. The above descriptions are only preferred embodiments of the present invention and are not intended to limit other claimed embodiments. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention shall be included within the scope of the claimed protection. In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory. Memory may include non-volatile memory in a computer-readable medium, random access memory (RAM), and/or non-volatile memory in the form of read-only memory (ROM) or flash memory ( flash RAM). Memory is an example of a computer-readable medium. Computer-readable media includes permanent and non-transitory, removable and non-removable media that can be used for information storage by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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, compact disc read only memory (CD-ROM), digital multi-function Optical discs (DVDs) or other optical storage, magnetic tape cassettes, magnetic tape storage or other magnetic storage devices, or any other non-transmission medium can be used to store information that can be accessed by computing devices. As defined in this article, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves. It should also be noted that the terms "comprises," "comprises," or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements not only includes those elements, but also includes Other elements are not expressly listed or are inherent to the process, method, article or equipment. Without further limitation, an element defined by the statement "comprises a..." does not exclude the presence of additional identical elements in a process, method, article, or device that includes the stated element. Those skilled in the art will understand that embodiments of the present invention may be provided as methods, systems or computer program products. Thus, embodiments of the invention may take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention may employ computer programs implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) embodying computer-usable program code therein. Product form.
