WO2016168509A1

WO2016168509A1 - Fund recovery method and apparatus

Info

Publication number: WO2016168509A1
Application number: PCT/US2016/027609
Authority: WO
Inventors: Dasong JI
Original assignee: Alibaba Group Holding Limited
Priority date: 2015-04-16
Filing date: 2016-04-14
Publication date: 2016-10-20
Also published as: CN106157015A; TW201638854A; TWI701631B

Abstract

A fund recovery method includes receiving and storing details of arrears sent from a transaction system; selecting details of arrears that meet one or more recovery application conditions and generating a recovery application form; conducting a fund operation according to the recovery application form; and allocating an obtained fund to the details of arrears from which the recovery application form is generated according to one or more preset fund refilling rules. Using technical solutions of the present disclosure, each transaction system does not need to implement a recovery function individually, thus avoiding a large amount of repeated work and improving the performance of transaction systems and payment systems.

Description

FUND RECOVERY METHOD AND APPARATUS

Cross Reference to Related Patent Application

This application claims foreign priority to Chinese Patent Application No. 201510181317.4 filed on April 16, 2015, entitled "Fund Recovery Method and Apparatus", which is hereby incorporated by reference in its entirety.

Technical Field

The present disclosure relates to the field of data processing, and in particular, to fund recovery methods and apparatuses.

Background

With the increasing popularity of Internet payment, a variety of different types of transactions that are conducted via third-party payment systems continue to emerge. In some transaction scenarios, a transaction system may make an advance payment for a user or a merchant under specific condition(s), and recover the fund from a pre-authorized account through a payment system.

For example, when a user, having an aptitude for quick refund, returns a product, a transaction system that deals with sales returns may first pay an amount of funds to be returned from a margin account of a merchant to the user through a payment system, and then submit a fund recovery application to the payment system, requesting the payment system to recover an insufficient portion of a margin from a pre-authorized account of the merchant.

In existing technologies, each transaction system conducts fund recovery individually. As such, each transaction system needs to implement a fund recovery function, thus resulting in a great deal of repeated work. Furthermore, when conducting a fund operation for a recovery request from a certain transaction system, a payment system needs to lock up variables that are relevant to an amount in arrears or an amount in an associated account. As the number of transaction systems that make recovery requests increases, the possibility of having a failure in a fund operation due to locked states of these variables also increases accordingly. Performing recovery requests repeatedly may reduce the performance of transaction systems and payment systems. Summary

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify all key features or essential features of the claimed subject matter, nor is it intended to be used alone as an aid in determining the scope of the claimed subject matter. The term "techniques/' for instance, may refer to device(s), system(s), method(s) and/or computer-readable instructions as permitted by the context above and throughout the present disclosure.

In view of the aforementioned situations, the present disclosure provides a fund recovery method, which may include receiving and storing details of arrears that are sent from transaction system(s); selecting details of arrears that satisfy recovery application condition(s) to generate a recovery application form; performing a fund operation according to the recovery application form; and allocating a fund that is obtained to the details of arrears from which the recovery application form is generated according to preset fund refilling rule(s).

The present disclosure further provides a fund recovery apparatus, which may include an arrear details receiving unit that receives and stores details of arrears that are sent from transaction system(s); a recovery application generation unit that select details of arrears that meet a recovery application condition to generate a recovery application form; a fund operation unit that performs a fund operation according to the recovery application form; and a fund allocation unit that allocates a fund that is obtained to the details of arrears from which the recovery application form is generated according to preset fund refilling rule(s).

As can be seen from the above technical solutions, the embodiments of the present disclosure collect details of arrears of respective transaction systems and conduct a fund recovery in a unified way. Therefore, each transaction system does not need to implement a fund recovery function individually, thus avoiding a large amount of repeated work and improving the performance of the transaction systems. By conducting a unified fund operation after generating a recovery application form based on details of arrears, a situation in which a large number of concurrent fund recovery applications that may be sent from multiple transaction systems to a payment system is avoided, thus reducing the workload of the payment system.

Brief Description of the Drawings

FIG. 1 is a connected diagram illustrating a structure of implementing a fund recovery in existing technologies.

FIG. 2 is a connected diagram illustrating a structure of implementing a fund recovery according to an embodiment of the present disclosure.

FIG. 3 is a connected diagram illustrating another structure of implementing a fund recovery according to an embodiment of the present disclosure.

FIG. 4 is a flowchart illustrating a fund recovery method according to an embodiment of the present disclosure.

FIG. 5 is a schematic diagram illustrating functional modules of a recovery system according to an application example of the present disclosure.

FIG. 6 is a diagram illustrating a hardware structure of a server.

FIG. 7 is a structural diagram illustrating a fund recovery apparatus according to an embodiment of the present disclosure.

Detailed Description

In existing technologies, each transaction system that needs to conduct a fund recovery includes software modules used for fund recovery. As shown in FIG. 1, software modules 102-1, 102-N (where N is an integer greater than zero) implement respective fund recoveries of corresponding transaction systems 104-1, 104-N thereof by interacting with a payment system 106. Embodiments of the present disclosure provide a new fund recovery method, which provides a fund recovery interface for each transaction system through a unified recovery mechanism, and each transaction system therefore no longer needs to implement a recovery function respectively. A recovery method in embodiments of the present disclosure may independently run on a logic server (for example, a virtual machine, a server cluster, etc.) or a physical server. For example, a recovery system 202 implementing the embodiments of the present disclosure is connected between transaction system(s) 204-1, 204-M (where M is an integer than zero) and a payment system 206 as shown in a network of FIG. 2, to achieve a fund recovery for the transaction system(s). The recovery method in the embodiments of the present disclosure may also run as an integral part of a payment system 302. For example, a network of FIG. 3 shows a software module 304 that performs a recovery for multiple transaction systems 306-1, 306-K (where K is an integer greater than one). For ease of description, an entity that implements an exemplary method of the present disclosure is referred to as a recovery system.

In implementations, FIG. 4 shows a flowchart illustrating a fund recovery method 400. S410 receives and stores details of arrears that are sent from transaction system(s). When a transaction item that needs a fund recovery takes place, a transaction system generates and sends details of arrears to a recovery system. A format of the details of arrears is universal to each transaction system, a nd each detail of arrears includes an amount in arrears, and a pre-authorized account for fund deduction or other information that is used for determining from which pre-authorized account the fund is deducted. Other information, such as a transaction type, a time in arrears, a recovery time limit, etc., may further be included. Particular content of the details of arrears may be determined according to the need of actual real application scenario.

Each transaction system may send the generated details of arrears to the recovery system at any time, and may also send the details of arrears to the recovery system periodically using a certain time or a certain number of details of arrears as a cycle. The recovery system stores the details of arrears that are received from each transaction system.

S420 selects details of arrears that satisfy recovery application condition(s), and generates a recovery application form.

An administrator may set and store recovery application condition(s). The recovery system reads the recovery application condition(s), selects details of arrears that satisfy the recovery application condition(s) from among the details of arrears received from the transaction system(s), and generates a recovery application form based on the selected details of arrears.

Generally, content in the details of arrears may be used to set up the recovery application condition(s). For example, the recovery application condition(s) may include a condition for a time in arrears, a condition for a transaction type, a condition for an amount in arrears, or any combination of the above conditions. For example, the recovery application condition(s) may include a time in arrears being a certain month, an amount in arrears being less than a certain set value, a configured transaction type, a time in arrears within a set interval, etc.

In application scenarios, scheduling rule(s) may be configured in advance. The recovery system selects entries of the details that meet a recovery application condition(s) from the details of arrears according to the scheduling rule(s) to generate a recovery application form. For example, the scheduling rule(s) may include a defined time frequency and a defined number of pre-authorized accounts. When a scheduling cycle is due, the recovery system extracts details of arrears of the defined number of pre-authorized accounts from the details of arrears that meet the recovery application condition(s), and generates a recovery application form using the extracted details of arrears.

The recovery application form includes information needed by the recovery system to recover a fund through the payment system, for example, a pre-authorized account, and a total amount that is needed to be recovered from a certain pre-authorized account in this recovery. In a process of generating a recovery application form from the selected details of arrears by the recovery system, summing up a total amount in arrears of a plurality of details of arrears with respect to a pre-authorized account may be performed. In this way, a single fund operation between the recovery system and the payment system may be performed to complete a recovery of the plurality of details of arrears, thus reducing operations of the payment system and improving the performance of the payment system.

S430 performs a fund operation according to the recovery application form.

According to the recovery application form, the recovery system submits a recovery application to the payment system, and conducts a fund operation with the payment system to obtain a recovery fund. Reference may be made to existing technologies for a process of submitting a recovery application and a process of a fund operation, which are not redundantly described herein.

S440 allocates the obtained fund to the details of arrears from which the recovery application form is generated according to predefined fund refilling rule(s).

If a balance in a pre-authorized account is less than a total amount that needs to be deducted from the pre-authorized account in a recovery application, an enough amount of fund cannot be obtained in this recovery. According to the need of a real application, the largest amount that is deductible from the pre-authorized account may be deducted in this situation. Alternatively, a deduction may not be performed.

In implementations, the recovery system may allocate the obtained recovery fund to the details of arrears from which the recovery application form is generated according to predefined fund refilling rule(s). The fund refilling rule(s) may be configured according to the needs of a real application. For example, a priority is given to pay back a detail of arrears having a long time in arrears, for example, having a time longer than a predetermined time period such as one week, two weeks, one month, etc. Additionally or alternatively, a priority is given to pay back a detail of arrears having a small amount in arrears, for example, having an amount smaller than a predetermined amount such as 10 dollars, 20 dollars, 50 dollars, 100 dollars, etc. Additionally or alternatively, a priority is given to pay back details of arrears of a set transaction type.

In implementations, details of arrears to which a respective full amount of fund is allocated may be deleted from details of arrears stored in the payment system. An amount in arrears of details of arrears to which a corresponding full amount of fund is not allocated is revised to an amount that has not been recovered. In this way, details of arrears may be selected from all the stored details of arrears each time when a recovery application form is generated.

In implementations, a recovery state may be set for each detail of arrears, which includes one of three states, namely, no recovery, a completed recovery and a partially completed recovery. No recovery indicates that a respective detail of arrears has not been used for generating a recovery application form or has once been used for generating a recovery application form but has not been allocated with a recovery fund. Completed recovery indicates that a respective detail of arrears has already obtained a recovery fund in full amount. Partially completed recovery indicates that a respective detail of arrears has already been allocated with a recovery fund but an amount of the recovery fund is not enough. For a detail of arrears having a state of partially completed recovery, an amount that has been allocated or an amount in arrears that still needs to be recovered is needed to be recorded. I n implementations, before a recovery application form is generated, details of arrears that fulfill the recovery application condition(s) are selected from details of arrears which recovery state indicates no recovery or a partially completed recovery. After a fund is obtained according to the recovery application form, a recovery state of a certain detail of arrears is changed to recovery completed if the recovery system allocates an enough amount of fund to that detail of arrears. If the amount is not enough, the recovery state of the detail of arrears is changed to a partially completed recovery, and an amount that has been allocated or an amount in arrears that still needs to be recovered is recorded or updated.

In implementations, by collecting details of arrears of respective transaction systems and conducting a fund recovery in a unified way, each transaction system does not need to implement a fund recovery function individually, thus avoiding a large amount of repeated work and improving the performance of the transaction systems. By conducting a fund operation after generating a recovery application form based on details of arrears, a situation in which a large number of concurrent fund recovery applications that may be sent from multiple transaction systems to a payment system is avoided, thus reducing the workload of the payment system a nd improving the performance of the payment system.

The recovery system may record respective processes of a recovery application and a fund allocation. In order to facilitate a transaction system to understand details of a recovery, the recovery system may generate recovery details corresponding to details of arrears based on an allocation result of the obtained fund, and record how many times a recovery has been conducted for a detail of arrears, a respective amount obtained each time, and other information such as a recovery time, etc. A detail of arrears corresponds to a detail of recovery (for example, in a single attempt of full recovery) or multiple details of recovery (for example, in multiple attempts of partial recovery). The recovery system may generate a recovery application form and conduct a fund operation in a multitasking or multithreading manner. In order to prevent different tasks or threads from conducting a recovery for a same detail of arrears at the same time, details of arrears that fulfill recovery application condition(s) are selected from details of arrears that are not marked as a recovery in progress prior to generating a recovery application form. After selecting the details of arrears that are used for generating the recovery application form, the recovery system marks these details of arrears as a recovery in progress. After allocating an obtained fund to the details of arrears, respective marks of the details of arrears indicating a recovery in progress are cleared. In this way, when a thread or a task initiates and completes a recovery operation on a detail of arrears, this detail of arrears can be guaranteed not to be chosen by other threads or tasks.

In an example implementation of the present disclosure, a recovery system 500 that implements the recovery method 400 in accordance with the embodiments of the present disclosure may include one or more processors 502, an input/output (I/O) interface 504, a network interface 506 and memory 508.

The memory 508 may include a form of computer-readable media, e.g., a non-permanent storage device, random-access memory (RAM) and/or a nonvolatile internal storage, such as read-only memory (ROM) or flash RAM. The memory 508 is an example of computer-readable media.

The computer-readable media may include a permanent or non-permanent type, a removable or non-removable media, which may achieve storage of information using any method or technology. The information may include a computer-readable instruction, a data structure, a program module or other data. Examples of computer storage media include, but not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electronically erasable programmable read-only memory (EEPROM), quick flash memory or other internal storage technology, compact disk read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission media, which may be used to store information that may be accessed by a computing device. As defined herein, the computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

In implementations, the memory 508 may include program modules 510 and program data 512. The program modules 510 may include four functional modules, namely, a recovery setting module 514, an arrears registration module 516, a scheduling module 518 and a recovery implementation module 520, as shown in FIG. 5.

The recovery setting module 514 provides an interface for an administrator. The administrator may configure recovery application condition(s) 522, fund refilling rule(s) 524 and scheduling rule(s) 526 used by a payment system. In implementations, the scheduling rule(s) 526 may include that at what frequency and magnitude a recovery is conducted, e.g., 20 pre-authorized accounts are recovered in every 10 minutes. The recovery application condition(s) 522 may include selecting a detail of arrears according to condition(s) such as a time in arrears, a transaction type, a number of details of arrears, a maximum application amount, whether a partial recovery is conducted, etc., to generate a recovery application form. For example, a recovery application form is generated from details of arrears which recovery is not completed in a current month. The fund refilling rule(s) 524 is/are used for determining how to allocate a fund that is obtained according to the recovery application form to the details of arrears from which the recovery application form is generated, or which details of arrears are preferentially refunded in an event of a partial recovery.

When transaction(s) that need(s) a recovery, such as a prepayment or margin use, occurs, an associated transaction system sends a message to the payment system to register respective detail(s) of arrears. The arrears registration module 516 receives and stores detail(s) of arrears 528 sent from transaction system(s). Each detail of arrears includes one of three recovery states: a completed recovery, no recovery and a partially completed recovery. An amount that has been recovered is also recorded in a detail of arrears that is in a state of partially completed recovery. A detail of arrears that is in a state of a recovery in progress may also be marked by the recovery implementation module 516 as a state of a recovery in progress.

The scheduling module 518 invokes the recovery implementation module 520 to perform a recovery according to the preset scheduling rule(s) 526. When the recovery implementation module 520 is invoked, the details of arrears that fulfill the recovery application condition(s) 522 are selected from details of arrears which recovery state is no recovery or a partially completed recovery and which are not marked as a recovery in progress. A recovery application form 530 is generated based on the selected details of arrears. A respective amount to be recovered from each pre-authorized account and a total amount to be recovered are recorded in the recovery application form 530. The recovery implementation module 520 initiates a recovery application to the payment system according to the recovery application form 530, and conducts real fund operations 532, for example, transferring, freezing, etc. The recovery a pplication may be partially successful, i.e., the recovery is conducted based on a n actual account balance if the account balance is not enough. After a recovery fund is obtained, the recovery implementation module 520 may allocate 534 the obtained fund to the details of arrears from which the recovery application form 530 is generated according to the preset fund refilling rule(s) 524, clear respective marks of the details of arrears that indicate a recovery in progress, and generate recovery details 536. The recovery details 536 correspond to the details of arrears, and corresponding details of arrears may be found through the recovery details 536. Furthermore, one or more corresponding recovery details through a detail of arrears. Based on a fund allocation result, the recovery implementation module 520 updates respective recovery states of the details of arrears from which the recovery application form 530 is generated. If a respective amount in arrears is allocated in a full amount, a recovery state of an associated detail of arrears is changed into a completed recovery. If not allocated in a full amount, a recovery state of an associated detail of arrears is changed into a partially completed recovery, and a recovered amount of the detail of arrears is updated.

Corresponding to the implementations of the aforementioned processes, embodiments of the present disclosure further provide a fund recovery apparatus is also provided. The apparatus may be independently applied in a server, or may be applied in a server where a payment system is located. The apparatus may be implemented using software component(s), or may be implemented using hardware component(s) or a combination of software and hardware components. An implementation through softwa re component(s) is used as an example. As an apparatus in a logical sense, the apparatus is formed by reading corresponding computer program instruction(s) into memory and running the instruction(s) by central processing unit(s) CPU(s) of a server where the apparatus is located. From the perspective of a hardware layer, in addition to CPU(s) 602, memory 604 and the non-volatile memory 606, a server 600 where the apparatus is located usually includes other hardware component(s) 608 such as a board card used for achieving a function of network communication as shown in FIG. 6.

FIG. 7 illustrates a fund recovery apparatus 700 according to the embodiments of the present disclosure, which may include an arrear details receiving unit 702, a recovery application generation unit 704, a fund operation unit 706 and a fund allocation unit 708 in terms of functional division. The arrear details receiving 702 receives and stores details of arrears sent from transaction system(s). The recovery application generation unit 704 selects details of arrears that meet recovery application condition(s), and generates a recovery application form. The fund operation unit 706 conducts a fund operation according to the recovery application form. The fund allocation unit 708 allocates an obtained fund to the details of arrears used for generating the recovery application form according to preset fund refilling rule(s).

Optionally, the recovery application generation unit 704 selects the details of arrears that meet the recovery application condition(s), and generates the recovery application form according to preset scheduling rule(s).

Optionally, a recovery state of a detail of arrears may include one of no recovery, a completed recovery or a partially completed recovery. The recovery application generation unit 704 selects the details of arrears that meet the recovery application condition(s) and which recovery state is no recovery or the partially completed recovery, a nd generates the recovery application form. The apparatus 700 may further include a recovery state maintenance unit 710, which changes a recovery state of a detail of arrears into the completed recovery when a fund allocated to the detail of arrears is in a full amount, or changes the recovery state of the detail of arrears into the partially completed recovery when not in the full amount.

Optionally, the apparatus 700 may further include a recovery details unit 712, which generates recovery details corresponding to the details of arrears according to an allocation result of the fund that is obtained, one or more recovery details corresponding to a detail of arrears.

Optionally, the recovery application generation unit 704 may select the details of arrears that meet the recovery application condition(s) and are not marked as a recovery in progress, and generate the recovery application form. The apparatus 700 may further include a recovery-in-progress marking unit 714 and a mark clearing unit 716. In implementations, the recovery-in-progress marking unit 714 marks the details of arrears that are selected and used for generating the recovery application form as the recovery in progress. The mark clearing unit 716 clears respective marks of the details of arrears used for generating the recovery application form after the obtained fund is allocated to the details of arrears.

As can be seen from the above implementations of the methods and apparatuses, compared to the existing technologies in which each transaction system individually implements a fund recovery function, the embodiments of the present disclosure conducts a recovery in a unified way after respective details of arrears of each transaction system are collected. Thus, each transaction system does not need to implement a recovery function individually, and therefore avoids a great deal of repeated work. Performing a fund operation in a unified way avoids an application failure that is caused by a large number of concurrent recovery applications directed to a payment system, and improves the performance of transaction systems and the payment system.

In a typical configuration, the apparatus 700 may include one or more computing devices. By way of example and not limitation, the apparatus 700 may include one or more processors or central processing units (CPUs) 718, an input/output interface 720, a network interface 722 and memory 724.

The memory 724 may include a form of computer-readable media, e.g., a non-permanent storage device, random-access memory (RAM) and/or a nonvolatile internal storage, such as read-only memory (ROM) or flash RAM. The memory 724 is an example of computer-readable media as described in the foregoing description.

In implementations, the memory 724 may include program units 726 and program data 728. The program units 726 may include one or more of the units as described in the foregoing description, which include, for example, the arrear details receiving unit 702, the recovery application generation unit 704, the fund operation unit 706, the fund allocation unit 708, the recovery state maintenance unit 710, the recovery details unit 712, the recovery-in-progress marking unit 714 and the mark clearing unit 716.

It should further be noted that terms such as "comprise", "include" and any other variants thereof are intended to cover a non-exclusive inclusion. A process, method, product or device that includes a series of elements not only includes those elements, but also includes other elements that are not explicitly listed, or further includes elements that already existed in such process, method, product or device. In a condition without further limitations, an element defined by a phrase "include a/an ..." does not exclude any other similar elements from existing in the process, method, product or device.

Furthermore, one skilled in the art should understand that the embodiments of the present disclosure may be provided as a method, a system or a computer program product. Therefore, the present disclosure may be implemented as a completely hardware embodiment, a completely software embodiment, or an embodiment of a combination of software and hardware. Moreover, the present disclosure may be a computer program product im plemented on one or more computer usable storage media (including, but not limited to, magnetic disk memory, CD-ROM, optical memory, and the like) including computer usable program codes.

The above are only exemplary embodiments of the present disclosure, and are not used as a limitation to the present disclosure. Any modifications, equivalent replacements, improvements, etc., that are made within the spirit and principles of the present disclosure, shall fall within the scope of protection of the present disclosure.

Claims

Claims What is claimed is:

1. A method comprising:

receiving and storing details of arrears that are sent from one or more transaction systems;

selecting details of arrears that meet one or more recovery application conditions; generating a recovery application form from the selected details of arrears;

conducting a fund operation according to the recovery application form; and allocating an obtained fund to the selected details of arrears from which the recovery application form is generated according to one or more preset fund refilling rules.

2. The method of claim 1, wherein selecting the details of arrears that meet the one or more recovery application conditions comprises selecting the details of arrears that meet the one or more recovery application conditions according to one or more scheduling rules, the one or more scheduling rules comprising:

selecting the details of arrears that meet the one or more recovery application conditions at a defined time frequency, or

selecting the details of arrears that meet the one or more recovery application conditions from a defined number of pre-authorized accounts.

3. The method of claim 1, wherein a recovery state of a detail of arrears of the selected details of arrears comprises a state of no recovery, a state of a completed recovery or a state of a partially completed recovery, and wherein selecting the details of arrears that meet the one or more recovery application conditions comprises selecting one or more details of arrears that meet the one or more recovery application conditions and which recovery state is the state of no recovery or the partially completed recovery.

4. The method of claim 3, further comprising:

changing respective one or more recovery states of the one or more details of arrears into the state of completed recovery in response to respective one or more funds allocated to the one or more details of arrears are in a full amount; or

changing the respective one or more recovery states of the one or more details of arrears into the state of the partially completed recovery in response to the respective one or more funds allocated to the one or more details of arrears are not in the full amount.

5. The method of claim 1, further comprising generating details of recovery corresponding to the selected details of arrears based on an allocation result of the obtained fund, one or more details of recovery corresponding to a detail of arrears of the selected details of arrears.

6. The method of claim 1, wherein selecting the details of arrears that meet the one or more recovery application conditions comprises selecting one or more details of arrears that meet the one or more recovery application conditions and are not marked with a state of a recovery in progress.

7. The method of claim 6, further comprising:

marking the one or more selected details of arrears with the state of the recovery in progress; and

clearing respective marks of the one or more details of arrears from the state of the recovery in progress after the obtained fund is allocated to the one or more selected details of arrears.

8. The method of claim 1, wherein the recovery application form comprises a total amount to be recovered by a single pre-authorized account.

9. The method of claim 1, wherein the one or more recovery application conditions comprise one or more of a condition of a time in arrears, a condition of a transaction type, a condition of an amount in arrears, and wherein the one or more preset fund refilling rules comprise one or more of giving a priority to pay back a detail of arrears having a time in arrears longer than a predetermined time period, giving a priority to pay back a detail of arrears having an amount in arrears smaller than a predetermined amount, or giving a priority to pay back a detail of arrears of a predetermined transaction type.

10. An apparatus comprising:

one or more processors;

memory;

an arrear details receiving unit stored in the memory and executable by the one or more processors to receive and store details of arrears sent from one or more transaction systems;

a recovery application generation unit stored in the memory and executable by the one or more processors to select details of arrears that meet one or more recovery application conditions, and generate a recovery application form from the selected details of arrears; a fund operation unit stored in the memory and executable by the one or more processors to conduct a fund operation according to the recovery application form; and a fund allocation unit stored in the memory and executable by the one or more processors to allocate an obtained fund to the selected details of arrears from which the recovery application form is generated according to one or more preset fund refilling rules.

11. The apparatus of claim 10, wherein the recovery application generation unit selects the details of arrears that meet the one or more recovery application conditions at a set time frequency or from a set number of pre-authorized accounts.

12. The apparatus of claim 10, wherein a recovery state of a detail of arrears of the selected details of arrears comprises a state of no recovery, a state of a completed recovery or a state of a partially completed recovery, and wherein respective recovery states of the details of arrears selected by the recovery application generation unit correspond to the state of no recovery or the partially completed recovery.

13. The apparatus of claim 12, further comprising a recovery state maintenance unit that changes the respective recovery states of the selected details of arrears into the state of completed recovery in response to respective funds allocated to the selected details of arrears are in a full amount, or changes the respective recovery states of the selected details of arrears into the state of the partially completed recovery in response to the respective funds allocated to the selected details of arrears are not in the full amount.

14. The apparatus of claim 10₇ further comprising a recovery details unit that generates details of recovery corresponding to the selected details of arrears, one or more details of recovery corresponding to a detail of arrears of the selected details of arrears.

15. The apparatus of claim 10, wherein the selected details of arrears that meet the one or more recovery application conditions are not marked with a state of a recovery in progress.

16. The apparatus of claim 15, further comprising:

a recovery-in-progress marking unit that marks the selected details of arrears with the state of the recovery in progress; and

a mark clearing unit that clears respective marks of the selected details of arrears from the state of the recovery in progress after the obtained fund is allocated to the selected details of arrears.

17. The apparatus of claim 10, wherein the one or more recovery application conditions comprise one or more of a condition of a time in arrears, a condition of a transaction type, a condition of an amount in arrears, and wherein the one or more preset fund refilling rules comprise one or more of giving a priority to pay back a detail of arrears having a time in arrears longer than a predetermined time period, giving a priority to pay back a detail of arrears having an amount in arrears smaller than a predetermined amount, or giving a priority to pay back a detail of arrears of a predetermined transaction type.

18. One or more computer-readable media storing executable instructions that, when executed by one or more processors, cause the one or more processors to perform acts comprising:

19. The one or more computer-readable media of claim 18, wherein the one or more recovery application conditions comprise one or more of a condition of a time in arrears, a condition of a transaction type, a condition of an amount in arrears, and wherein the one or more preset fund refilling rules comprise one or more of giving a priority to pay back a detail of arrears having a time in arrears longer than a predetermined time period, giving a priority to pay back a detail of arrears having an amount in arrears smaller than a predetermined amount, or giving a priority to pay back a detail of arrears of a predetermined transaction type.

20. The one or more computer-readable media of claim 18, wherein a recovery state of a detail of arrears of the selected details of arrears comprises a state of no recovery, a state of a completed recovery or a state of a partially completed recovery, and selecting the details of arrears that meet the one or more recovery application conditions comprises selecting one or more details of arrears that meet the one or more recovery application conditions and which recovery state is the state of no recovery or the partially completed recovery, wherein the method further comprises: