一種基於銀行API伺服器的提現方法和系統與流程
2023-05-29 17:17:46 1

本發明涉及數據處理領域,特別涉及一種基於銀行api伺服器的提現方法和系統。
背景技術:
隨著網際網路電子商務的飛速發展,用戶在提現方面的需要越來越大,對提現過程中實時性和效率的要求也越來越高,而現有技術的銀行提現速度較慢,尤其是在銀行帳戶餘額不足需要跨行提現時,跨行提現速度較慢且實時性差。
技術實現要素:
本發明旨在至少解決上述技術問題之一。
為此,本發明的一個目的在於提出一種基於銀行api伺服器的提現方法,該提現方法能夠在帳戶餘額不足需要跨行轉帳時也可以實現快速提現,確保用戶提現的效率和實時性,另外,該方法實現簡單,投入成本低。
本發明的另一個目的在於提供一種基於銀行api伺服器的提現系統。
為了實現上述目的,本發明的一個實施例提出了一種基於銀行api伺服器的提現方法,包括以下步驟:
s1,應用伺服器接收用戶的提現請求,並獲取在預先建立的支付系統中開設支付中心帳號的所有銀行名單;
s2,應用伺服器對所述提現請求進行解析,生成提現金額和提現請求對應的第一目標銀行;
s3,應用伺服器判斷第一目標銀行是否在所述銀行名單上,若是,則獲取第一目標銀行對應支付中心帳號的第一餘額,以及銀行名單上其他銀行對應支付中心帳號的第二餘額;若否,則結束提現流程;
s4,應用伺服器判斷所述第一餘額是否大於或等於所述提現金額,若是,則向所述支付系統發送第一凍結指令,並生成提現指令發送到銀行api伺服器,所述第一凍結指令用於凍結第一目標銀行對應支付中心帳號中的所述提現金額;若否,則獲取銀行名單上第二餘額大於或者等於所述提現金額的第二目標銀行,並向所述支付系統發送第二凍結指令,並生成提現指令發送到銀行api伺服器,所述第二凍結指令用於凍結第二目標銀行對應支付中心帳號中的所述提現金額;
s5,銀行api伺服器接收所述提現指令,並經與第一目標銀行或者第二目標銀行對應的請求轉發伺服器將所述提現指令發送給所述第一目標銀行或者第二目標銀行,同時定時查詢所述第一目標銀行或者第二目標銀行返回的提現結果,且將所述提現結果發送給所述應用伺服器;
s6,應用伺服器接收所述提現結果,並根據提現結果向所述支付系統發送用於解除提現金額凍結狀態的解凍指令或用於將所述提現金額從第一餘額或者第二餘額中扣除的扣除指令。
根據本發明實施例的基於銀行api伺服器的提現方法,通過銀行api伺服器和請求轉發伺服器發送提現指令至對應的第一目標銀行或者第二目標銀行,在帳戶餘額不足需要跨行轉帳時也可以實現快速提現,確保用戶提現的效率和實時性,另外,該方法實現簡單,投入成本低。
另外,根據本發明上述實施例的基於銀行api伺服器的提現方法還可以具有如下附加的技術特徵:
在一些示例中,所述步驟s1具體為:應用伺服器接收用戶的提現請求,記錄所述提現請求的接收時間,並判斷所述接收時間是否在預設時間範圍內,若是,則獲取在預先建立的支付系統中開設支付中心帳號的所有銀行名單,若否,則結束提現流程。
在一些示例中,所述預設時間範圍為9:00~17:00。
在一些示例中,所述步驟s5包括提現指令發送步驟和提現結果獲取步驟,所述提現指令發送步驟具體為:
s500,所述銀行api伺服器接收所述提現指令,並將所述提現指令記錄到銀行api伺服器的資料庫;
s501,所述銀行api伺服器對資料庫進行查詢,獲取未處理的所有提現請求,並將所有提現請求按照第一目標銀行或者第二目標銀行封裝為對應的第一提現報文;
s502,所述銀行api伺服器獲取所述第一目標銀行或者所述第二目標銀行對應的配置文件,根據所述配置文件定時將所述第一提現報文轉發至第一目標銀行或者第二目標銀行對應的請求轉發伺服器;
s503,所述請求轉發伺服器接收所述第一提現報文,並對所述第一提現報文進行數據封裝後生成第二提現報文,然後將所述第二提現報文通過tomcat發送至第一目標銀行或者第二目標銀行的銀企前置機;
s504,所述請求轉發伺服器獲取對應的第一目標銀行或者第二目標銀行返回的業務流水號或者業務參考號,並將所述業務流水號或者所述業務參考號發送至銀行api伺服器;
s505,所述銀行api伺服器記錄所述業務流水號或者所述業務參考號;
所述提現結果獲取步驟具體為:
s510,所述銀行api伺服器對資料庫進行查詢,獲取處理中的所有提現請求以及所述提現請求對應的業務流水號或者業務參考號;
s511,所述銀行api伺服器根據所述業務流水號或者所述業務參考號將所述提現請求按照第一目標銀行或者第二目標銀行封裝為對應的第一查詢報文;
s512,所述銀行api伺服器根據所述配置文件定時將所述第一查詢報文轉發至所述第一目標銀行或者第二目標銀行對應的請求轉發伺服器;
s413,所述請求轉發伺服器接收所述第一查詢報文,並對所述第一查詢報文進行數據封裝後生成第二查詢報文,然後將所述第二查詢報文通過tomcat發送至對應第一目標銀行或者第二目標銀行的銀企前置機;
s514,所述請求轉發伺服器獲取對應第一目標銀行或者對應第二目標銀行返回的提現結果,並將所述提現結果發送至銀行api伺服器;
s515,所述銀行api伺服器接收提現結果並將所述提現結果發送至應用伺服器。
在一些示例中,所述步驟515中,提現結果包括提現狀態,所述提現狀態包括提現成功狀態和提現失敗狀態,當提現狀態為提現失敗狀態時,所述提現結果還包括失敗原因;所述銀行api伺服器接收所述提現結果後,當提現狀態為提現成功狀態時,將資料庫中對應提現請求標記為成功,當提現狀態為提現失敗狀態時,將資料庫中對應提現請求標記為失敗,並寫入所述失敗原因。
在一些示例中,步驟s4中,所述銀行api伺服器包括主銀行api伺服器和備用銀行api伺服器,應用伺服器發送提現指令前,先獲取所述主銀行api伺服器的狀態,判斷所述主銀行api伺服器是否失效,若是,則將所述提現指令發送至備用銀行api伺服器;若否,則將所述提現指令發送至主銀行api伺服器。
本發明第二方面的實施例還提出了一種基於銀行api伺服器的提現系統,包括至少一個應用伺服器、至少一個銀行api伺服器和至少一個請求轉發伺服器,所述至少一個應用伺服器包括:
第一接收模塊,用於接收用戶的提現請求;
獲取模塊,用於獲取在預先建立的支付系統中開設支付中心帳號的所有銀行名單;
解析模塊,用於對所述提現請求進行解析,生成提現金額和提現請求對應的第一目標銀行;
第一判斷模塊,用於判斷第一目標銀行是否在所述銀行名單上,若是,則獲取第一目標銀行對應支付中心帳號的第一餘額,以及銀行名單上其他銀行對應支付中心帳號的第二餘額;若否,則結束提現流程;
第二判斷模塊,用於判斷所述第一餘額是否大於或等於所述提現金額,若是,則向所述支付系統發送第一凍結指令,並生成提現指令發送到銀行api伺服器,所述第一凍結指令用於凍結第一目標銀行對應支付中心帳號中的所述提現金額;若否,則獲取銀行名單上第二餘額大於或者等於所述提現金額的第二目標銀行,則向所述支付系統發送第二凍結指令,並生成提現指令發送到銀行api伺服器,所述第二凍結指令用於凍結第二目標銀行對應支付中心帳號中的所述提現金額;
第二接收模塊,用於接收提現結果,並根據提現結果向所述支付系統發送用於解除提現金額凍結狀態的解凍指令或用於將所述提現金額從第一餘額或者第二餘額中扣除的扣除指令;
所述至少一個銀行api伺服器用於接收所述提現指令,並將所述提現指令發送至與第一目標銀行或者第二目標銀行對應的請求轉發伺服器;以及用於接收所述請求轉發伺服器發送的提現結果,並將所述提現結果發送至應用伺服器;
所述至少一個請求轉發伺服器用於將所述提現指令發送給對應的所述第一目標銀行或者第二目標銀行,同時定時查詢所述第一目標銀行或者第二目標銀行返回的提現結果,且將所述提現結果發送給銀行api伺服器。
根據本發明實施例的基於銀行api伺服器的提現系統,通過銀行api伺服器和請求轉發伺服器發送提現指令至對應的第一目標銀行或者第二目標銀行,在帳戶餘額不足需要跨行轉帳時也可以實現快速提現,確保用戶提現的效率和實時性,另外,該方法實現簡單,投入成本低。
另外,根據本發明上述實施例的基於銀行api伺服器的提現系統還可以具有如下附加的技術特徵:
在一些示例中,所述第一接收模塊具體用於接收用戶的提現請求,記錄所述提現請求的接收時間,並判斷所述接收時間是否在預設時間範圍內,若是,則驅動獲取模塊,若否,則結束提現流程。
在一些示例中,所述至少一個銀行api伺服器包括:
第三接收模塊,用於接收所述提現指令,並將所述提現指令記錄到銀行api伺服器的資料庫;
第一查詢模塊,用於對資料庫進行查詢,獲取未處理的所有提現請求;
第一封裝模塊,用於將所有提現請求按照第一目標銀行或者第二目標銀行封裝為對應的第一提現報文;
第一發送模塊,用於獲取所述第一目標銀行或者所述第二目標銀行對應的配置文件,根據所述配置文件定時將所述第一提現報文轉發至所述第一目標銀行或者第二目標銀行對應的請求轉發伺服器;
記錄模塊,用於記錄業務流水號或者所述業務參考號;
第二查詢模塊,用於對資料庫進行查詢,獲取處理中的所有提現請求以及所述提現請求對應的業務流水號或者業務參考號;
第二封裝模塊,用於根據所述業務流水號或者所述業務參考號將所述提現請求按照第一目標銀行或者第二目標銀行封裝為對應的第一查詢報文;
第二發送模塊,用於根據所述配置文件定時將所述第一查詢報文轉發至所述第一目標銀行或者第二目標銀行對應的請求轉發伺服器;
轉發模塊,用於接收提現結果並將所述提現結果發送至應用伺服器;
所述至少一個請求轉發伺服器包括:
第一收發模塊,用於接收所述第一提現報文,並對所述第一提現報文進行數據封裝後生成第二提現報文,然後將所述第二提現報文通過tomcat發送至對應的第一目標銀行或者第二目標銀行的銀企前置機;
第二收發模塊,用於獲取第一目標銀行或者第二目標銀行返回的業務流水號或者業務參考號,並將所述業務流水號或者所述業務參考號發送至銀行api伺服器;
第三收發模塊,用於接收所述第一查詢報文,並對所述第一查詢報文進行數據封裝後生成第二查詢報文,然後將所述第二查詢報文通過tomcat發送至對應第一目標銀行或者第二目標銀行的銀企前置機;
第四收發模塊,用於獲取對應的第一目標銀行或者第二目標銀行返回的提現結果,並將所述提現結果發送至銀行api伺服器。
在一些示例中,所述銀行api伺服器包括主銀行api伺服器和備用銀行api伺服器,所述第二判斷模塊還用於發送提現指令前,先獲取所述主銀行api伺服器的狀態,判斷所述主銀行api伺服器是否失效,若是,則將所述提現指令發送至備用銀行api伺服器;若否,則將所述提現指令發送至主銀行api伺服器。
本發明的附加方面和優點將在下面的描述中部分給出,部分將從下面的描述中變得明顯,或通過本發明的實踐了解到。
附圖說明
本發明的上述和/或附加的方面和優點從結合下面附圖對實施例的描述中將變得明顯和容易理解,其中:
圖1為本發明實施例1一種基於銀行api伺服器的提現方法的流程示意圖;
圖2為本發明實施例2步驟s5中提現指令發送步驟的流程示意圖;
圖3為本發明實施例3步驟s5中提現結果獲取步驟的流程示意圖;
圖4為實施例4一種基於銀行api伺服器的提現系統的結構示意圖。
具體實施方式
在本發明的描述中,術語「第一」、「第二」僅用於描述目的,而不能理解為指示或暗示相對重要性。
參照下面的描述和附圖,將清楚本發明的實施例的這些和其他方面。在這些描述和附圖中,具體公開了本發明的實施例中的一些特定實施方式,來表示實施本發明的實施例的原理的一些方式,但是應當理解,本發明的實施例的範圍不受此限制。相反,本發明的實施例包括落入所附加權利要求書的精神和內涵範圍內的所有變化、修改和等同物。
以下結合附圖描述根據本發明實施例的基於銀行api伺服器的提現方法和系統。
圖1為實施例1一種基於銀行api伺服器的提現方法的流程示意圖,如圖1所示,包括以下步驟:
s1,應用伺服器接收用戶的提現請求,並獲取在預先建立的支付系統中開設支付中心帳號的所有銀行名單;
s2,應用伺服器對所述提現請求進行解析,生成提現金額和提現請求對應的第一目標銀行;
s3,應用伺服器判斷第一目標銀行是否在所述銀行名單上,若是,則獲取第一目標銀行對應支付中心帳號的第一餘額,以及銀行名單上其他銀行對應支付中心帳號的第二餘額;若否,則結束提現流程;
s4,應用伺服器判斷所述第一餘額是否大於或等於所述提現金額,若是,則向所述支付系統發送第一凍結指令,並生成提現指令發送到銀行api伺服器,所述第一凍結指令用於凍結第一目標銀行對應支付中心帳號中的所述提現金額;若否,則獲取銀行名單上第二餘額大於或者等於所述提現金額的第二目標銀行,並向所述支付系統發送第二凍結指令,並生成提現指令發送到銀行api伺服器,所述第二凍結指令用於凍結第二目標銀行對應支付中心帳號中的所述提現金額;
s5,銀行api伺服器接收所述提現指令,並經與第一目標銀行或者第二目標銀行對應的請求轉發伺服器將所述提現指令發送給所述第一目標銀行或者第二目標銀行,同時定時查詢所述第一目標銀行或者第二目標銀行返回的提現結果,且將所述提現結果發送給所述應用伺服器;
s6,應用伺服器接收所述提現結果,並根據提現結果向所述支付系統發送用於解除提現金額凍結狀態的解凍指令或用於將所述提現金額從第一餘額或者第二餘額中扣除的扣除指令。
本實施例中,銀行api伺服器是一個外部伺服器調用的接口伺服器,負責接收來自於應用伺服器的請求,提供統一的銀行業務如支付轉帳、支付結果查詢,背書轉讓、票據籤收、操作結果查詢等操作接口,並將請求結果返回給請求客戶端。請求轉發伺服器主要處理單個銀行請求業務的伺服器,用於連接銀行前置機、接受銀行api伺服器的業務請求,並根據各個銀行的報文要求,將請求內容封裝成對應的報文,並發送報文到銀行前置機。之後,接收前置機返回的報文並解析該報文,將解析的結果返回給銀行api伺服器。一般各家銀行均有自己的前置機環境,為了適應不通的前置機環境,設置了針對不通前置機環境的請求轉發伺服器。本實施例的基於銀行api伺服器的提現方法,不同銀行對應一個不同的請求轉發伺服器,通過銀行api伺服器和請求轉發伺服器發送提現指令至對應的第一目標銀行或者第二目標銀行,在帳戶餘額不足需要跨行轉帳時也可以實現快速提現,確保了用戶提現的效率和實時性,另外,該方法實現簡單,投入成本低。在另一實施例中,在銀行api伺服器和請求轉發伺服器之間增加消息伺服器,應用伺服器首先將所述提現指令發送到消息伺服器進行存儲,所述銀行api伺服器對消息伺服器的提現指令進行監聽,當監聽到消息伺服器中存儲有提前指令時,獲取所述提現指令,並進行以上後續步驟。
在優選實施例中,所述步驟s1具體為:應用伺服器接收用戶的提現請求,記錄所述提現請求的接收時間,並判斷所述接收時間是否在預設時間範圍內,若是,則獲取在預先建立的支付系統中開設支付中心帳號的所有銀行名單,若否,則結束提現流程。具體的,在某些實施例中,所述預設時間範圍為9:00~17:00,即在每天的9:00~17:00時間段,可以採用本實施例的提現方法進行提現,當然,在其他實施例中,可以根據國家規定對所述預設時間範圍進行修改。
圖2為實施例2步驟s5中提現指令發送步驟的流程示意圖,如圖2所示,所述提現指令發送步驟具體為:
s500,所述銀行api伺服器接收所述提現指令,並將所述提現指令記錄到銀行api伺服器的資料庫;
s501,所述銀行api伺服器對資料庫進行查詢,獲取未處理的所有提現請求,並將所有提現請求按照第一目標銀行或者第二目標銀行封裝為對應的第一提現報文;
s502,所述銀行api伺服器獲取所述第一目標銀行或者所述第二目標銀行對應的配置文件,根據所述配置文件定時將所述第一提現報文轉發至第一目標銀行或者第二目標銀行對應的請求轉發伺服器;
s503,所述請求轉發伺服器接收所述第一提現報文,並對所述第一提現報文進行數據封裝後生成第二提現報文,然後將所述第二提現報文通過tomcat發送至第一目標銀行或者第二目標銀行的銀企前置機;
s504,所述請求轉發伺服器獲取第一目標銀行或者第二目標銀行返回的業務流水號或者業務參考號,並將所述業務流水號或者所述業務參考號發送至銀行api伺服器;
s505,所述銀行api伺服器記錄所述業務流水號或者所述業務參考號。
上述優選實施例中,不同銀行在銀行api伺服器中預設了對應的配置文件,配置文件記載了第一提現報文的發送時間,因此可以定時將銀行api伺服器的資料庫中沒有處理的提現請求批量進行處理,提高了提現請求的處理效率,從而提高了提現速度;同時請求轉發伺服器採用了tomcat,tomcat伺服器是一個免費的開放原始碼的web應用伺服器,屬於輕量級應用伺服器,在中小型系統和並發訪問用戶不是很多的場合下被普遍使用,是開發和調試jsp程序的首選,因此不僅配置過程簡單而且可以處理大量用戶請求,進一步提高了提現請求的處理速度和效率。
圖3為實施例3步驟s5中提現結果獲取步驟的流程示意圖,如圖3所示,所述提現結果獲取步驟具體為:
s510,所述銀行api伺服器對資料庫進行查詢,獲取處理中的所有提現請求以及所述提現請求對應的業務流水號或者業務參考號;
s511,所述銀行api伺服器根據所述業務流水號或者所述業務參考號將所述提現請求按照第一目標銀行或者第二目標銀行封裝為對應的第一查詢報文;
s512,所述銀行api伺服器根據所述配置文件定時將所述第一查詢報文轉發至所述第一目標銀行或者第二目標銀行對應的請求轉發伺服器;
s413,所述請求轉發伺服器接收所述第一查詢報文,並對所述第一查詢報文進行數據封裝後生成第二查詢報文,然後將所述第二查詢報文通過tomcat發送至第一目標銀行或者第二目標銀行的銀企前置機;
s514,所述請求轉發伺服器獲取第一目標銀行或者第二目標銀行返回的提現結果,並將所述提現結果發送至銀行api伺服器;
s515,所述銀行api伺服器接收提現結果並將所述提現結果發送至應用伺服器。
上述優選實施例中,通過查詢配置文件可以獲取不同銀行對應的第一查詢報文的發送時間,因此可以定時獲取第一目標銀行或者第二目標銀行返回的提現結果,獲取方法簡單且效率高,進一步提高了提現請求的處理速度和效率。
在另一優選的實施例中,所述步驟515中,提現結果包括提現狀態,所述提現狀態包括提現成功狀態和提現失敗狀態,當提現狀態為提現失敗狀態時,所述提現結果還包括失敗原因;所述銀行api伺服器接收所述提現結果後,當提現狀態為提現成功狀態時,將資料庫中對應提現請求標記為成功,當提現狀態為提現失敗狀態時,將資料庫中對應提現請求標記為失敗,並寫入所述失敗原因。通過以上方法可以及時獲取提現請求的狀態,當提現請求為失敗狀態時,也可以及時獲取失敗原因,從而對後續步驟進行改進。
在另一優選實施例的步驟s4中,所述銀行api伺服器包括主銀行api伺服器和備用銀行api伺服器,應用伺服器發送提現指令前,先獲取所述主銀行api伺服器的狀態,判斷所述主銀行api伺服器是否失效,若是,則將所述提現指令發送至備用銀行api伺服器;若否,則將所述提現指令發送至主銀行api伺服器。上述優選實施例設置了兩個銀行api伺服器,在其中一個銀行api伺服器處於失效狀態時,另一個銀行api伺服器還可以繼續使用,提高了提現成功率。當然在其他的實施例中也可以根據兩個或者多個銀行api伺服器的負載情況,選擇負載較小的的銀行api伺服器進行使用,從而防止銀行api伺服器發送崩潰或失效,進一步提高了提現成功率和提現速度。
圖4為實施例4一種基於銀行api伺服器的提現系統的結構示意圖,如圖4所示,包括至少一個應用伺服器、至少一個銀行api伺服器和至少一個請求轉發伺服器,所述至少一個應用伺服器包括:
第一接收模塊,用於接收用戶的提現請求;
獲取模塊,用於獲取在預先建立的支付系統中開設支付中心帳號的所有銀行名單;
解析模塊,用於對所述提現請求進行解析,生成提現金額和提現請求對應的第一目標銀行;
第一判斷模塊,用於判斷第一目標銀行是否在所述銀行名單上,若是,則獲取第一目標銀行對應支付中心帳號的第一餘額,以及銀行名單上其他銀行對應支付中心帳號的第二餘額;若否,則結束提現流程;
第二判斷模塊,用於判斷所述第一餘額是否大於或等於所述提現金額,若是,則向所述支付系統發送第一凍結指令,並生成提現指令發送到銀行api伺服器,所述第一凍結指令用於凍結第一目標銀行對應支付中心帳號中的所述提現金額;若否,則獲取銀行名單上第二餘額大於或者等於所述提現金額的第二目標銀行,則向所述支付系統發送第二凍結指令,並生成提現指令發送到銀行api伺服器,所述第二凍結指令用於凍結第二目標銀行對應支付中心帳號中的所述提現金額;
第二接收模塊,用於接收提現結果,並根據提現結果向所述支付系統發送用於解除提現金額凍結狀態的解凍指令或用於將所述提現金額從第一餘額或者第二餘額中扣除的扣除指令;
所述至少一個銀行api伺服器用於接收所述提現指令,並將所述提現指令發送給請求轉發伺服器;以及用於接收所述請求轉發伺服器發送的提現結果,並將所述提現結果發送至應用伺服器;
所述至少一個請求轉發伺服器用於將所述提現指令發送給所述第一目標銀行或者第二目標銀行,同時定時查詢所述第一目標銀行或者第二目標銀行返回的提現結果,且將所述提現結果發送給銀行api伺服器。
實施例的基於銀行api伺服器的提現系統,通過銀行api伺服器和請求轉發伺服器發送提現指令至對應的第一目標銀行或者第二目標銀行,在帳戶餘額不足需要跨行轉帳時也可以實現快速提現,確保用戶提現的效率和實時性,另外,該方法實現簡單,投入成本低。
在優選實施例中,所述第一接收模塊具體用於接收用戶的提現請求,記錄所述提現請求的接收時間,並判斷所述接收時間是否在預設時間範圍內,若是,則驅動獲取模塊,若否,則結束提現流程。
具體的實施例5中,包括兩個應用伺服器、一個主銀行api伺服器、一個備用銀行api伺服器和三個請求轉發伺服器,即有三個銀行在支付系統中開設支付中心帳號,所述第二判斷模塊還用於發送提現指令前,先獲取所述主銀行api伺服器的狀態,判斷所述主銀行api伺服器是否失效,若是,則將所述提現指令發送至備用銀行api伺服器;若否,則將所述提現指令發送至主銀行api伺服器。本實施例中,所述主銀行api伺服器和備用銀行api伺服器均包括:
第三接收模塊,用於接收所述提現指令,並將所述提現指令記錄到銀行api伺服器的資料庫;
第一查詢模塊,用於對資料庫進行查詢,獲取未處理的所有提現請求;
第一封裝模塊,用於將所有提現請求按照第一目標銀行或者第二目標銀行封裝為對應的第一提現報文;
第一發送模塊,用於獲取所述第一目標銀行或者所述第二目標銀行對應的配置文件,根據所述配置文件定時將所述第一提現報文轉發至所述第一目標銀行或者第二目標銀行對應的請求轉發伺服器;
記錄模塊,用於記錄業務流水號或者所述業務參考號;
第二查詢模塊,用於對資料庫進行查詢,獲取處理中的所有提現請求以及所述提現請求對應的業務流水號或者業務參考號;
第二封裝模塊,用於根據所述業務流水號或者所述業務參考號將所述提現請求按照第一目標銀行或者第二目標銀行封裝為對應的第一查詢報文;
第二發送模塊,用於根據所述配置文件定時將所述第一查詢報文轉發至所述第一目標銀行或者第二目標銀行對應的請求轉發伺服器;
轉發模塊,用於接收提現結果並將所述提現結果發送至應用伺服器。
所述實施例5中,每個請求轉發伺服器對應一個目標銀行的銀企前置機,每個所述請求轉發伺服器均包括:
第一收發模塊,用於接收所述第一提現報文,並對所述第一提現報文進行數據封裝後生成第二提現報文,然後將所述第二提現報文通過tomcat發送至第一目標銀行或者第二目標銀行的銀企前置機;
第二收發模塊,用於獲取第一目標銀行或者第二目標銀行返回的業務流水號或者業務參考號,並將所述業務流水號或者所述業務參考號發送至銀行api伺服器;
第三收發模塊,用於接收所述第一查詢報文,並對所述第一查詢報文進行數據封裝後生成第二查詢報文,然後將所述第二查詢報文通過tomcat發送至第一目標銀行或者第二目標銀行的銀企前置機;
第四收發模塊,用於獲取第一目標銀行或者第二目標銀行返回的提現結果,並將所述提現結果發送至銀行api伺服器。
在另一實施例中,在銀行api伺服器和請求轉發伺服器之間增加消息伺服器,應用伺服器首先將所述提現指令發送到消息伺服器進行存儲,所述銀行api伺服器對消息伺服器的提現指令進行監聽,當監聽到消息伺服器中存儲有提前指令時,獲取所述提現指令,並進行以上後續步驟。
流程圖中或在此以其他方式描述的任何過程或方法描述可以被理解為,表示包括一個或更多個用於實現特定邏輯功能或過程的步驟的可執行指令的代碼的模塊、片段或部分,並且本發明的優選實施方式的範圍包括另外的實現,其中可以不按所示出或討論的順序,包括根據所涉及的功能按基本同時的方式或按相反的順序,來執行功能,這應被本發明的實施例所屬技術領域的技術人員所理解。
在流程圖中表示或在此以其他方式描述的邏輯和/或步驟,例如,可以被認為是用於實現邏輯功能的可執行指令的定序列表,可以具體實現在任何計算機可讀介質中,以供指令執行系統、裝置或設備(如基於計算機的系統、包括處理器的系統或其他可以從指令執行系統、裝置或設備取指令並執行指令的系統)使用,或結合這些指令執行系統、裝置或設備而使用。就本說明書而言,"計算機可讀介質"可以是任何可以包含、存儲、通信、傳播或傳輸程序以供指令執行系統、裝置或設備或結合這些指令執行系統、裝置或設備而使用的裝置。計算機可讀介質的更具體的示例(非窮盡性列表)包括以下:具有一個或多個布線的電連接部(電子裝置),可攜式計算機盤盒(磁裝置),隨機存取存儲器(ram),只讀存儲器(rom),可擦除可編輯只讀存儲器(eprom或閃速存儲器),光纖裝置,以及可攜式光碟只讀存儲器(cdrom)。另外,計算機可讀介質甚至可以是可在其上列印所述程序的紙或其他合適的介質,因為可以例如通過對紙或其他介質進行光學掃描,接著進行編輯、解譯或必要時以其他合適方式進行處理來以電子方式獲得所述程序,然後將其存儲在計算機存儲器中。
應當理解,本發明的各部分可以用硬體、軟體、固件或它們的組合來實現。在上述實施方式中,多個步驟或方法可以用存儲在存儲器中且由合適的指令執行系統執行的軟體或固件來實現。例如,如果用硬體來實現,和在另一實施方式中一樣,可用本領域公知的下列技術中的任一項或他們的組合來實現:具有用於對數據信號實現邏輯功能的邏輯門電路的離散邏輯電路,具有合適的組合邏輯門電路的專用集成電路,可編程門陣列(pga),現場可編程門陣列(fpga)等。
本技術領域的普通技術人員可以理解實現上述實施例方法攜帶的全部或部分步驟是可以通過程序來指令相關的硬體完成,所述的程序可以存儲於一種計算機可讀存儲介質中,該程序在執行時,包括方法實施例的步驟之一或其組合。
此外,在本發明各個實施例中的各功能單元可以集成在一個處理模塊中,也可以是各個單元單獨物理存在,也可以兩個或兩個以上單元集成在一個模塊中。上述集成的模塊既可以採用硬體的形式實現,也可以採用軟體功能模塊的形式實現。所述集成的模塊如果以軟體功能模塊的形式實現並作為獨立的產品銷售或使用時,也可以存儲在一個計算機可讀取存儲介質中。
在本說明書的描述中,參考術語「一個實施例」、「一些實施例」、「示例」、「具體示例」、或「一些示例」等的描述意指結合該實施例或示例描述的具體特徵、結構、材料或者特點包含於本發明的至少一個實施例或示例中。在本說明書中,對上述術語的示意性表述不一定指的是相同的實施例或示例。而且,描述的具體特徵、結構、材料或者特點可以在任何的一個或多個實施例或示例中以合適的方式結合。
儘管已經示出和描述了本發明的實施例,對於本領域的普通技術人員而言,可以理解在不脫離本發明的原理和精神的情況下可以對這些實施例進行多種變化、修改、替換和變型,本發明的範圍由所附權利要求及其等同限定。