本申請涉及數(shù)據(jù)處理領域，尤其涉及一種資金追償?shù)姆椒把b置。

背景技術：

隨著互聯(lián)網支付的日益普及，通過第三方支付系統(tǒng)進行的各種業(yè)務層出不窮。在一些業(yè)務場景中，業(yè)務系統(tǒng)在特定條件下會為用戶或商戶先行墊付資金，然后通過支付系統(tǒng)向預授權的賬戶進行資金追償。

例如，當具有極速退款資質的用戶退貨時，處理退貨的業(yè)務系統(tǒng)可以從商戶的保證金賬戶中先行將需要退還的款項通過支付系統(tǒng)支付給用戶，然后向支付系統(tǒng)提交追償申請，請求支付系統(tǒng)從商戶的預授權賬戶中追償保證金不足的部分。

現(xiàn)有技術中，每個業(yè)務系統(tǒng)分別進行各自的資金追償，這樣每個業(yè)務系統(tǒng)都需要實現(xiàn)資金追償?shù)墓δ埽斐闪舜罅康闹貜蛣趧?。另外，支付系統(tǒng)在針對某個業(yè)務系統(tǒng)的追償請求進行資金操作時，需要對一些與欠款金額或賬戶金額相關的變量加鎖；隨著進行追償請求的業(yè)務系統(tǒng)數(shù)量的增加，資金操作因這些變量處于加鎖狀態(tài)而失敗的可能性也不斷提高，重復進行追償請求會降低業(yè)務系統(tǒng)和支付系統(tǒng)的性能。

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

有鑒于此，本申請?zhí)峁┮环N資金追償?shù)姆椒?，包括?/p>

接收并保存業(yè)務系統(tǒng)發(fā)送的欠款明細；

篩選滿足追償申請條件的欠款明細，生成追償申請單；

根據(jù)追償申請單進行資金操作；

按照預置的資金回填規(guī)則，將獲得的資金分配給用于生成追償申請單的欠款明細。

本申請還提供了一種資金追償?shù)难b置，包括：

欠款明細接收單元，用于接收并保存業(yè)務系統(tǒng)發(fā)送的欠款明細；

追償申請生成單元，用于篩選滿足追償申請條件的欠款明細，生成追償申請單；

資金操作單元，用于根據(jù)追償申請單進行資金操作；

資金分配單元，用于按照預置的資金回填規(guī)則，將獲得的資金分配給用于生成追償申請單的欠款明細。

由以上技術方案可見，本申請的實施例通過將各個業(yè)務系統(tǒng)的欠款明細集中后統(tǒng)一進行追償，不再需要每個業(yè)務系統(tǒng)分別實現(xiàn)追償功能，避免了大量的重復勞動，提高了業(yè)務系統(tǒng)的性能；根據(jù)欠款明細生成追償申請單后進行統(tǒng)一的資金操作避免了針對支付系統(tǒng)的來自多個業(yè)務系統(tǒng)的大量并發(fā)追償申請，降低了支付系統(tǒng)的負荷。

附圖說明

圖1是現(xiàn)有技術中一種實現(xiàn)資金追償?shù)木W絡結構圖；

圖2是本申請實施例中一種實現(xiàn)資金追償?shù)木W絡結構示例圖；

圖3是本申請實施例中另一種實現(xiàn)資金追償?shù)木W絡結構示例圖；

圖4是本申請實施例中一種資金追償方法的流程圖；

圖5是本申請應用示例中一種追償系統(tǒng)的功能模塊示意圖；

圖6是的一種服務器的硬件結構圖；

圖7是本申請實施例提供的一種資金追償?shù)难b置的邏輯結構圖。

具體實施方式

現(xiàn)有技術中，每個需要進行資金追償?shù)臉I(yè)務系統(tǒng)都包括用于追償?shù)能浖? 模塊，如圖1所示，這些軟件模塊通過與支付系統(tǒng)交互來實現(xiàn)所在業(yè)務系統(tǒng)的資金追償。本申請的實施例提出一種新的資金追償方法，通過統(tǒng)一的追償機制來為各個業(yè)務系統(tǒng)提供資金追償接口，不再需要由每個業(yè)務系統(tǒng)分別實現(xiàn)追償功能。

本申請實施例中的追償方法可以獨立運行在邏輯服務器(如虛擬機、服務器集群等)或物理服務器上，例如，在圖2所示網絡中，應用本申請實施例的追償系統(tǒng)連接在業(yè)務系統(tǒng)和支付系統(tǒng)之間，為業(yè)務系統(tǒng)實現(xiàn)資金追償。本申請實施例中的追償方法也可以作為支付系統(tǒng)中的一個組成部分來運行，例如圖3所示的網絡中為多個業(yè)務系統(tǒng)進行追償?shù)能浖K。為表述方便，以下將運行本申請實施例方法的主體稱為追償系統(tǒng)。

本實施例中，資金追償方法的流程如圖4所示。

步驟410，接收并保存業(yè)務系統(tǒng)發(fā)送的欠款明細。

當業(yè)務系統(tǒng)發(fā)生需要進行資金追償?shù)臉I(yè)務項目時，生成欠款明細發(fā)送給追償系統(tǒng)。欠款明細的格式通用于各個業(yè)務系統(tǒng)，每條欠款明細包括欠款金額、以及扣款的預授權賬戶或者其他用來確定從哪個預授權賬戶扣款的信息，此外還可以包括其他信息，如業(yè)務類型、欠款發(fā)生的時間、追償時限等。欠款明細中的具體內容可以根據(jù)實際應用場景的需要來確定。

各個業(yè)務系統(tǒng)可以隨時將生成的欠款明細發(fā)送給追償系統(tǒng)，也可以以一定時間為周期、或以一定欠款明細條數(shù)為周期向追償系統(tǒng)發(fā)送欠款明細。追償系統(tǒng)保存從各個業(yè)務系統(tǒng)收到的欠款明細。

步驟420，篩選滿足追償申請條件的欠款明細，生成追償申請單。

管理員可以設置并保存追償申請條件，追償系統(tǒng)讀取這些追償申請條件，在從業(yè)務系統(tǒng)接收的欠款明細中將符合追償申請條件的欠款明細篩選出來，根據(jù)篩選出的欠款明細生成追償申請單。

通?？梢岳们房蠲骷氈械膬热輥碓O置追償申請條件，例如，追償申請條件可以是欠款時間條件、業(yè)務類型條件、或欠款金額條件，也可以是以上各個條件的組合。具體而言，追償申請條件可以是欠款時間為某個月，可以 是欠款金額小于某個設定值，可以是設定業(yè)務類型和欠款時間為設定區(qū)間等等。

在一些應用場景中，可以預置調度規(guī)則，由追償系統(tǒng)按照調度規(guī)則，從欠款明細中篩選滿足追償申請條件的明細條目，來生成追償申請單。例如，調度規(guī)則可以包括設定的時間頻率和設定的預授權賬戶數(shù)量，當調度周期到時，追償系統(tǒng)從滿足追償申請條件的欠款明細中取出針對設定數(shù)量的預授權賬戶的欠款明細，用取出的欠款明細來生成追償申請單。

追償申請單中包括追償系統(tǒng)通過支付系統(tǒng)追索資金所需的信息，如預授權賬戶、以及某一個預授權賬戶在本次追償中需要追償?shù)目偨痤~。在追償系統(tǒng)將篩選出的欠款明細生成追償申請單的過程中，可以將針對一個預授權賬戶的多個欠款明細的欠款金額進行匯總，這樣追償系統(tǒng)與支付系統(tǒng)之間只需進行一次資金操作即可完成多個欠款明細的追償，減少了支付系統(tǒng)的操作，提高了支付系統(tǒng)的性能。

步驟430，根據(jù)追償申請單進行資金操作。

根據(jù)追償申請單，追償系統(tǒng)向支付系統(tǒng)提出追償申請，與支付系統(tǒng)之間進行資金操作，獲得追償資金。提出追償申請以及資金操作的過程可以參照現(xiàn)有技術來進行，不再贅述。

步驟440，按照預置的資金回填規(guī)則，將獲得的資金分配給用于生成追償申請單的欠款明細。

如果預授權賬戶中的余額小于在一次追償申請中該預授權賬戶需要扣除的總金額，這次追償將無法獲得足額的資金。根據(jù)實際應用的需求，對這種情況可以扣除預授權賬戶中能夠扣除的最大金額，也可以不扣除。

對獲得的追償資金，追償系統(tǒng)按照預置的資金回填規(guī)則分配給用于生成追償申請單的欠款明細。資金回填規(guī)則可以根據(jù)實際應用的需求來設置，例如，可以是優(yōu)先償還欠款時間長的欠款明細，可以是優(yōu)先償還欠款金額小的欠款明細，或者還可以是優(yōu)先償還設定業(yè)務類型的欠款明細。

在一種實現(xiàn)中，可以將分配到足額資金的欠款明細從追償系統(tǒng)保存的欠 款明細中刪除，并將未分配到足額資金的欠款明細的欠款金額修改為還未追償?shù)降臄?shù)額，這樣每次生成追償申請單時，從所有保存的欠款明細中進行篩選即可。

在另一種實現(xiàn)中，可以為每條欠款明細設置追償狀態(tài)，包括未追償、已追償和部分追償三種，其中，未追償表示該條欠款明細尚未用于生成追償申請單或者曾經用于生成追償申請單但未被分配追償資金；已追償表示該條欠款明細已經獲得足額追償資金；部分追償表示該條欠款明細已被分配追償資金但尚未足額，對部分追償?shù)那房蠲骷氝€需記錄已分配的金額或者還需追償?shù)那房罱痤~。在這種實現(xiàn)中，生成追償申請單前，在追償狀態(tài)為未追償或部分追償?shù)那房蠲骷氈泻Y選滿足追償申請條件的欠款明細；當根據(jù)追償申請單獲得資金后，如果追償系統(tǒng)分配給某條欠款明細的資金足額，則將這條欠款明細的追償狀態(tài)更改為已追償；如果不足額則將這條欠款明細的追償狀態(tài)更改為部分追償，并記錄或更新已分配的金額或者還需追償?shù)那房罱痤~。

本實施例中，通過將各個業(yè)務系統(tǒng)的欠款明細集中后統(tǒng)一進行追償，不再需要每個業(yè)務系統(tǒng)分別實現(xiàn)追償功能，避免了大量的重復勞動，提高了業(yè)務系統(tǒng)的性能；根據(jù)欠款明細生成追償申請單后進行資金操作避免了針對支付系統(tǒng)的大量并發(fā)追償申請，降低了支付系統(tǒng)的負荷，提高了支付系統(tǒng)的性能。

追償系統(tǒng)可以對追償申請和資金分配的過程進行記錄。為了便于業(yè)務系統(tǒng)了解追償?shù)木唧w情況，追償系統(tǒng)可以生成根據(jù)獲得資金的分配結果生成對應于欠款明細的追償明細，記錄一條欠款明細進行了幾次追償，每次獲得的金額是多少，以及其他信息，如追償時間等。一條欠款明細對應于一條追償明細(例如一次足額追償?shù)那樾?或一條以上的追償明細(例如多次部分追償?shù)那樾?。

追償系統(tǒng)可以采用多任務或多線程的方式，來生成追償申請單以及進行資金操作。為了避免不同的任務或線程同時對同一條欠款明細進行追償，生成追償申請單前，在未被標記為追償中的欠款明細中篩選滿足追償申請條件 的欠款明細；當篩選出用于生成追償申請單的欠款明細后，追償系統(tǒng)將這些欠款明細標記為追償中；在將獲得的資金分配給欠款明細后，清除這條欠款明細的追償中標記。這樣，在一個線程或任務從發(fā)起到完成對一條欠款明細的追償操作時，可以確保這條欠款明細不會被其他線程或任務選中。

在本申請的一個應用示例中，運行本申請實施例中追償方法的追償系統(tǒng)包括4個功能模塊：追償設置模塊、欠款登記模塊、調度模塊和追償執(zhí)行模塊，如圖5所示。

追償設置模塊向管理員提供接口，由管理員對追償系統(tǒng)所采用的追償申請條件、資金回填規(guī)則和調度規(guī)則進行設置。其中，調度規(guī)則包括以怎樣的頻率和幅度進行追償，比如每10分鐘追償20個預授權賬戶；追償申請條件包括按欠款時間、業(yè)務類型、欠款明細條數(shù)、最大申請金額、是否部分追償?shù)葪l件來篩選欠款明細以生成追償申請單，如將當月未追償完成的欠款明細形成追償申請單；資金回填規(guī)則用于確定如何將根據(jù)追償申請單獲得的資金分配到用于生成追償申請單的欠款明細，或者說在部分追償?shù)那闆r下優(yōu)先償還哪些欠款明細。

當業(yè)務系統(tǒng)發(fā)生墊資或保證金使用等需要進行追償?shù)臉I(yè)務時，向追償系統(tǒng)發(fā)送消息，登記欠款明細。欠款登記模塊接收并保存來自業(yè)務系統(tǒng)的欠款明細，每條欠款明細包括已追償、未追償、部分追償三個追償狀態(tài)，處于部分追償狀態(tài)的欠款明細還會記錄已追償金額；處于追償過程中的欠款明細還會被追償執(zhí)行模塊標記為追償中。

調度模塊根據(jù)預置的調度規(guī)則，調用追償執(zhí)行模塊來進行追償。

當追償執(zhí)行模塊被調用時，從追償狀態(tài)為未追償或部分追償、并且未被標記為追償中的欠款明細中篩選出滿足追償申請條件的欠款明細，根據(jù)篩選出的欠款明細生成追償申請單，追償申請單中記錄需要追償各個預授權賬戶的金額、以及追償?shù)目偨痤~。追償執(zhí)行模塊按照追償申請單向支付系統(tǒng)發(fā)起追償申請，進行真實的資金操作，如轉賬、凍結等。追償申請可能部分成功，即如果賬戶余額不足，則按實際賬戶余額進行追償。獲得追償資金后，根據(jù) 預置的資金回填規(guī)則，追償執(zhí)行模塊將獲得的資金分配給用于生成追償申請單的欠款明細，將這些欠款明細的追償中標記清除，并生成追償明細。追償明細對應于欠款明細，通過追償明細可以查找到對應的欠款明細，同時通過欠款明細也可以查找到對應的一條到多條追償明細。根據(jù)資金分配的結果，追償執(zhí)行模塊更新用于生成追償申請單的欠款明細的追償狀態(tài)，若欠款金額足額分配，則將欠款明細的追償狀態(tài)改為已追償；未足額分配則將欠款明細的追償狀態(tài)改為部分追償，并更新欠款明細的已追償金額。

與上述流程實現(xiàn)對應，本申請的實施例還提供了一種資金追償?shù)难b置。該裝置可以獨立應用在服務器上，也可以應用在支付系統(tǒng)所在的服務器上。該裝置均可以通過軟件實現(xiàn)，也可以通過硬件或者軟硬件結合的方式實現(xiàn)。以軟件實現(xiàn)為例，作為邏輯意義上的裝置，該裝置是通過所在服務器的CPU將對應的計算機程序指令讀取到內存中運行形成的。從硬件層面而言，除了圖6所示的CPU、內存以及非易失性存儲器之外，該裝置所在的服務器通常還包括用于實現(xiàn)網絡通信功能的板卡等其他硬件。

圖7所示為本實施例提供的一種資金追償?shù)难b置，從功能上劃分，包括欠款明細接收單元、追償申請生成單元、資金操作單元和資金分配單元，其中：欠款明細接收單元用于接收并保存業(yè)務系統(tǒng)發(fā)送的欠款明細；追償申請生成單元用于篩選滿足追償申請條件的欠款明細，生成追償申請單；資金操作單元用于根據(jù)追償申請單進行資金操作；資金分配單元用于按照預置的資金回填規(guī)則，將獲得的資金分配給用于生成追償申請單的欠款明細。

可選的，所述追償申請生成單元具體用于：根據(jù)預置的調度規(guī)則，篩選滿足追償申請條件的欠款明細，生成追償申請單。

可選的，所述欠款明細的追償狀態(tài)包括未追償、已追償和部分追償；所述追償申請生成單元具體用于：篩選滿足追償申請條件、并且追償狀態(tài)為未追償或部分追償?shù)那房蠲骷?，生成追償申請單；所述裝置還包括：追償狀態(tài)維護單元，用于當分配給某條欠款明細的資金足額時，將所述欠款明細的追償狀態(tài)更改為已追償；當不足額時將所述欠款明細的追償狀態(tài)更改為部分追 償。

可選的，所述裝置還包括：追償明細單元，用于根據(jù)獲得資金的分配結果生成對應于欠款明細的追償明細；一條或一條以上的追償明細對應于一條欠款明細。

可選的，所述追償申請生成單元具體用于：篩選滿足追償申請條件、并且欠款明細未被標記為追償中的欠款明細，生成追償申請單；所述裝置還包括追償中標記單元和標記清除單元，其中：追償中標記單元用于將篩選出來用于生成追償申請單的欠款明細標記為追償中；標記清除單元用于在將獲得的資金分配給欠款明細后，清除所述用于生成追償申請單的欠款明細的追償中標記。

從以上各種方法和裝置的實施方式中可以看出，相對于現(xiàn)有技術中在各個業(yè)務系統(tǒng)上分別實現(xiàn)資金追償?shù)墓δ埽旧暾埖膶嵤├ㄟ^將各個業(yè)務系統(tǒng)的欠款明細集中后統(tǒng)一進行追償，不再需要每個業(yè)務系統(tǒng)分別實現(xiàn)追償功能，避免了大量的重復勞動；統(tǒng)一進行資金操作避免了針對支付系統(tǒng)的大量并發(fā)追償申請導致的請求不成功，提高了業(yè)務系統(tǒng)和支付系統(tǒng)的性能。

在一個典型的配置中，計算設備包括一個或多個處理器(CPU)、輸入/輸出接口、網絡接口和內存。

內存可能包括計算機可讀介質中的非永久性存儲器，隨機存取存儲器(RAM)和/或非易失性內存等形式，如只讀存儲器(ROM)或閃存(flash RAM)。內存是計算機可讀介質的示例。

計算機可讀介質包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現(xiàn)信息存儲。信息可以是計算機可讀指令、數(shù)據(jù)結構、程序的模塊或其他數(shù)據(jù)。計算機的存儲介質的例子包括，但不限于相變內存(PRAM)、靜態(tài)隨機存取存儲器(SRAM)、動態(tài)隨機存取存儲器(DRAM)、其他類型的隨機存取存儲器(RAM)、只讀存儲器(ROM)、電可擦除可編程只讀存儲器(EEPROM)、快閃記憶體或其他內存技術、只讀光盤只讀存儲器(CD-ROM)、數(shù)字多功能光盤(DVD)或其他光學存儲、磁盒式磁帶，磁帶磁磁盤存儲或其 他磁性存儲設備或任何其他非傳輸介質，可用于存儲可以被計算設備訪問的信息。按照本文中的界定，計算機可讀介質不包括暫存電腦可讀媒體(transitory media)，如調制的數(shù)據(jù)信號和載波。

還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。

本領域技術人員應明白，本申請的實施例可提供為方法、系統(tǒng)或計算機程序產品。因此，本申請可采用完全硬件實施例、完全軟件實施例或結合軟件和硬件方面的實施例的形式。而且，本申請可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(包括但不限于磁盤存儲器、CD-ROM、光學存儲器等)上實施的計算機程序產品的形式。

以上所述僅為本申請的較佳實施例而已，并不用以限制本申請，凡在本申請的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本申請保護的范圍之內。