Payment method, wallet system and storage medium

Abstract

The embodiment of the invention provides a payment method, a wallet system and a storage medium. The payment method comprises the following steps: in response to a received authorization request of a target order, executing a first authorization process to reserve a first authorization fund for the target order, in response to a received payment request of the target order, in the case that the value of a payment request specified by the payment request is greater than the value of the first authorization fund, executing a second authorization process to reserve a second authorization fund for the target order, and in the case that the value of the payment request specified by the payment request is greater than the value of the first authorization fund. Executing a second authorization process to reserve a second authorization fund for the target order, and further completing payment request processing for the target order based on the first authorization fund and the second authorization fund; wherein the sum of the value of the first authorized fund and the value of the second authorized fund is not less than the value of the payment request fund.

Description

TECHNICAL FIELD

[0001] The present specification relates to the technical field of Internet technology, and particularly relates to a payment method, a wallet system and a storage medium. BACKGROUND

[0002] With the development of Internet technology, non-cash payment has been popularized in various consumption scenarios. In the current payment system, the payment process of an order usually adopts a two-stage mode of "authorization-capture". After a user initiates payment for an order through a payment card held by the user in a merchant system, the order enters an authorization stage. In the authorization stage, a wallet system can verify the payment card and reserve funds for subsequent capture operation of the order through the payment card. After the order authorization is successful, a staff of the merchant system can perform the capture operation so that the order enters a capture stage. If an exception occurs in the capture stage, for example, the capture funds are excessive, causing the funds reserved by the wallet system in the authorization stage to be insufficient, the wallet system cannot complete the capture processing, which may cause the interruption or failure of the order payment process, and affect the payment success rate.

[0003] The contents in the background section are only the information known by the inventor, and do not represent that the above information has been in the public domain before the filing date of the present disclosure, nor that it can be prior art of the present disclosure. SUMMARY

[0004] The present specification provides a payment method, a wallet system and a storage medium, which can supplement the reserved funds by re-authorization in the case of excessive capture funds, ensure the smooth progress of the capture stage, reduce the payment failure rate caused by excessive capture, and improve the payment experience of users.

[0005] In a first aspect, the present specification provides a payment method, comprising: in response to receiving an authorization request of a target order, performing a first authorization process to reserve first authorization funds for the target order; in response to receiving a capture request of the target order, performing a second authorization process to reserve second authorization funds for the target order in the case that a value of capture funds specified in the capture request is greater than a value of the first authorization funds, wherein the sum of the values of the first authorization funds and the second authorization funds is not less than the value of the capture funds; and completing the capture processing of the target order based on the first authorization funds and the second authorization funds.

[0006] In a second aspect, the present specification also provides a wallet system, comprising: at least one storage medium, storing at least one instruction set; and at least one processor, communicatively connected with the at least one storage medium, wherein the at least one processor reads the at least one instruction set when running, and implements the payment method according to the indication of the at least one instruction set.

[0007] In a third aspect, the present specification provides a computer-readable non-transitory storage medium, wherein the computer-readable non-transitory storage medium stores at least one instruction set, and the at least one instruction set is executed by at least one processor to implement the method according to the first aspect.

[0008] Other functions of the payment method, the wallet system and the storage medium provided by the present specification will be partially listed in the following description. The creative aspects of the payment method, the wallet system and the storage medium provided by the present specification can be fully explained by practicing or using the methods, systems and combinations described in the following detailed examples. BRIEF DESCRIPTION OF DRAWINGS

[0009] In order to more clearly illustrate the technical solutions in the embodiments of the present specification, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the present specification, and other drawings can also be obtained by those skilled in the art without creative labor based on these drawings.

[0010] Figure 1 A schematic diagram of an application scenario of payment is shown according to the embodiments of the present specification; Figure 2 A hardware structure diagram of a computing system is shown according to the embodiments of the present specification; Figure 3 A flowchart of a payment method is shown according to the embodiments of the present specification; Figure 4 A schematic diagram of fund transfer in each stage is shown according to the embodiments of the present specification; Figure 5 A flowchart of fund recovery is shown according to the embodiments of the present specification; and Figure 6 A schematic diagram of traversing multiple accounts during fund recovery is shown according to the embodiments of the present specification. DETAILED DESCRIPTION

[0011] The following description provides specific applications and requirements of the present specification, which is intended to enable a person skilled in the art to manufacture and use the contents of the present specification. Various local modifications of the disclosed embodiments are obvious to those skilled in the art, and the general principles defined herein can be applied to other embodiments and applications without departing from the spirit and scope of the present specification. Therefore, the present specification is not limited to the embodiments shown, but is consistent with the widest scope of the claims.

[0012] The terms used herein are only for the purpose of describing specific example embodiments, and are not limiting. For example, unless the context clearly indicates otherwise, as used herein, the singular forms "a", "an", and "the" can also include the plural forms. When used in the present specification, the terms "comprise", "include" and / or "contain" mean that the associated whole, step, operation, element and / or component exists, but do not exclude the presence of one or more other features, whole, step, operation, element, component and / or group or other features, whole, step, operation, element, component and / or group can be added in the system / method.

[0013] In view of the following description, these features of the present specification and other features, and the operation and function of related elements of the structure, and the economy of combination and manufacture of components can be obviously improved. Referring to the drawings, all of which form part of the present specification. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to limit the scope of the present specification. It should also be understood that the drawings are not drawn to scale.

[0014] The flowchart used in the present specification shows the operation of system implementation according to some embodiments of the present specification. It should be clearly understood that the operations of the flowchart can not be implemented in sequence. On the contrary, the operations can be implemented in reverse order or simultaneously. In addition, one or more other operations can be added to the flowchart. One or more operations can be removed from the flowchart.

[0015] The following will be described in conjunction with Figure 1 The application scenario of payment provided by the present specification is introduced.

[0016] Figure 1 The application scenario of payment provided by the embodiments of the present specification is shown. As Figure 1 shown, the application scenario 100 includes a target user 10, a wallet system 20, a merchant system 30 and a card group system 40.

[0017] The application scenario 100 can be an online payment scenario or an offline payment scenario, which is not limited by the present specification.

[0018] When the application scenario 100 is an online payment scenario, the merchant system 30 can be an e-commerce platform specific to a merchant or an e-commerce platform integrated with multiple merchants, and the present specification does not limit this. The merchant system 30 can display items or services for sale to a user, and the user can place an order on the merchant system 30 and use a target payment card applied for on the wallet system 20 to pay for the relevant order.

[0019] When the application scenario 100 is an offline payment scenario, the merchant system 30 can be a cash register system of a merchant. After the user and the merchant staff negotiate the items or services for a transaction, the merchant staff can place an order on the merchant system 30, and the user can use the target payment card to pay for the relevant order on the merchant system 30.

[0020] The target payment card is a payment tool applied for by the target user 10 on the wallet system 20, which can be a virtual card (does not have a physical form of a card, and the user holds the account information of the card), can be a physical card, or can be a digital twin of a physical card (such as account information of a payment card), and the present specification does not limit this. The wallet system 20 can issue a payment card through, for example, a website or an application program. The relevant information of the payment card can exist on the server or in the cloud of the wallet system 20 for online channel management. For example, the target user can apply for a target payment card on a platform designated by the wallet system 20. When using the target payment card, the target user can also apply for account information (such as a card number, which can be used once or for a long time), an expiration date, and a security code (Card Verification Value, CVV) of the target payment card on a platform designated by the wallet system 20 to increase payment security.

[0021] The target user 10 can be any user with a transaction demand. For example, the target user 10 can be an individual, a staff member of an enterprise or a company, or the like. The target user 10 can be an ordinary consumer or a merchant, and the present specification does not limit this.

[0022] The wallet system 20 can be a traditional financial institution (such as a bank), a new type of financial institution, a payment service provider, or an aggregation service provider that aggregates multiple financial institutions or multiple payment service providers. The new type of financial system is, for example, an electronic wallet, and the present specification does not limit this.

[0023] In some embodiments, the wallet system 20 includes clients providing front-end services and servers providing back-end services. For example, in the stage of applying for the target payment card by the target user 10, the target user 10 can initiate the related application in the client, and the server in the wallet system 20 can issue the target payment card for the target user 10 according to the demand of the target user 10. In the stage of using the target payment card to pay for the related order by the target user 10, the server in the wallet system 20 can receive the payment-related request (such as an authorization request, a billing request, etc.) of the related order and feedback the request processing result.

[0024] The merchant system 30 is a system for the target user 10 to conduct order transactions. In an online payment scenario, the target user 10 can bind the target payment card in the merchant system 30, so that the target payment card can be selected to pay for the related order in the merchant system 30. Alternatively, the target user 10 can also select the target payment card to pay without pre-binding the target payment card, which is not limited in the present specification.

[0025] The card group system 40 is responsible for information conversion and fund clearing in the payment process of the payment card, formulates and implements technical standards and process specifications for the payment card to pay, and can provide infrastructure and services for the wallet system 20, the acquirer system, and other participants in the transaction. In the authorization stage of order payment, the card group system 40 provides authorization services to verify the validity of each order. After authorization, the card group system 40 can also be responsible for processing the clearing process of the order, that is, calculating and transferring funds to the relevant parties (such as merchants or other service beneficiaries). The card group system 40 is, for example, a card organization, which is also known as a credit card organization / bank card organization.

[0026] The acquirer system refers to a platform or institution that signs a contract with a merchant and is responsible for processing authorization requests on the merchant side, and is a bridge connecting the merchant system and the financial system (such as the wallet system or the card group system), which can provide acquirer services for different merchants.

[0027] The authorization stage is a process in which the merchant system requests approval for the order payment to the wallet system 20 after the user initiates the payment of the order. For example, the merchant system 30 generates an authorization request for the order, and the authorization request can be transmitted to the wallet system 20 through the card group system 40. After receiving the authorization request for the order, the wallet system 20 can determine whether the balance of the target payment card is sufficient, reserve funds (or freeze funds) in the case of sufficiency, and send the authorization result of the order. The authorization result can be transmitted to the merchant system 30 through the card group system 40. The merchant system can display the authorization result to the target user 10. In the case of authorization success, the merchant system 30 can initiate a billing request for the order, so that the order enters the billing stage.

[0028] The payment request stage is the process of the wallet system transferring the reserved funds (hereinafter referred to as authorized funds) to the designated account after the order authorization is successful. For example, after the merchant system 30 generates and sends a payment request for an order, the payment request can be transmitted to the wallet system 20 through the card group system 40. After the wallet system 20 receives the payment request, the wallet system 20 can transfer the payment funds specified in the payment request to the designated account.

[0029] When the value of the payment funds specified in the payment request is greater than the value of the authorized funds, it is called overpayment. At this time, the wallet system cannot transfer the payment funds to the designated account to complete the payment process due to insufficient authorized funds, resulting in the interruption or failure of the payment process, so that the order payment process is in a semi-completed or failed state. The goods or services in the order cannot be normally delivered to the user, and the authorized funds will not be automatically released or released with a time difference, resulting in the user being unable to use the authorized funds for normal consumption in a short period of time, and poor user experience. If the merchant has delivered the goods or services to the user after the authorization is successful, the failure of the payment will cause the merchant to face the risk of "goods / service has been delivered, but the payment has not been received", and the merchant needs to invest manpower to contact the user to cancel the order, increasing the operating cost.

[0030] In view of this, the present application provides a payment method P300 and a wallet system to overcome the above problems.

[0031] In some embodiments, the wallet system 20 (such as a server in the wallet system 20) can store data and instructions for implementing the payment method P300, and can execute or be used to execute the data and instructions. In some embodiments, the wallet system 20 can include a hardware device with data information processing function and the necessary programs required to drive the hardware device to work. Specifically, the technical details of the payment method P300 are described below, and will not be repeated here.

[0032] It should be noted that the merchant system 30 and the card group system 40 can directly communicate, i.e. without forwarding information through an intermediate system. Alternatively, the merchant system 30 and the card group system 40 can exist an intermediate system for forwarding information, such as an acquirer system. In addition, the wallet system 20 and the card group system 40 can directly communicate, or there can be other systems for forwarding information, which are not limited in the present specification.

[0033] The wallet system 20, the merchant system 30, the acquirer system, and the card group system 40 can be multiple subsystems provided by one service provider, or independent systems provided by multiple service providers, or part of the systems can be multiple subsystems provided by one service provider, and the other part of the systems can be independent systems provided by other service providers, which are not limited in the present specification.

[0034] In the present specification, the messages (e.g. authorization request, payment request, authorization result, payment result) sent by the intermediate system (e.g. card group system) between the merchant system 30 and the wallet system 20 can be generated by the intermediate system after processing the received messages of the same type, or can be directly forwarded without processing, and the present specification does not limit this. The message name of the intermediate system can change when receiving and sending the same type of message, and does not require to remain consistent. For example, the card group system can receive a "payment request", and send an "authorization request" to the wallet system. For ease of description, the messages transmitted between the systems in the present specification are uniformly named as the same name in logic, but the naming method does not affect the actual protection scope.

[0035] Figure 2 A hardware structure diagram of a computing system 200 provided according to an embodiment of the present specification is shown. The computing system 200 can be Figure 1 the wallet system 20 in the present specification.

[0036] As shown in Figure 2 , the computing system 200 can include at least one storage medium 230 and at least one processor 220. In some embodiments, the computing system 200 can also include a communication port 250 and an internal communication bus 210. In addition, the computing system 200 can also include an I / O component 260.

[0037] The internal communication bus 210 can connect different system components. For example, the internal communication bus 210 can connect the storage medium 230, the processor 220, the communication port 250 and the I / O component 260.

[0038] The I / O component 260 supports the input / output between the computing system 200 and other components.

[0039] The communication port 250 is used for data communication between the computing system 200 and the outside world. For example, the communication port 250 can be used for data communication between the computing system 200 and the network. The communication port 250 can be a wired communication port or a wireless communication port.

[0040] In some embodiments, the network can be any type of wired or wireless network, or a combination thereof. For example, the network can include a cable network, a wired network, a fiber optic network, a telecommunication network, an intranet, the Internet, a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), a Metropolitan Area Network (MAN), a Public Switched Telephone Network (PSTN), a Bluetooth network™, a short-range wireless network (ZigBee™), a Near Field Communication (NFC) network, or the like.

[0041] In some embodiments, the network can include one or more network access points. For example, the network can include wired or wireless network access points, such as a base station or an Internet exchange point. Through the access point, one or more components of each device corresponding to the computing system 200 can connect to the network to exchange data or information.

[0042] The storage medium 230 can include a data storage device. The data storage device can be a non-transitory storage medium or a transitory storage medium. For example, the data storage device can include one or more of a disk 232, a read-only memory (ROM) 234, or a random access memory (RAM) 236. The storage medium 230 further includes at least one instruction set stored in the data storage device. The instruction set can include computer program code, which can include programs, routines, objects, components, data structures, procedures, modules, and the like, that perform the payment methods provided in the present specification.

[0043] The processor 220 can be communicatively connected to the storage medium 230. The processor 220 is configured to execute the at least one instruction set. When the computing system 200 is running, the processor 220 reads the at least one instruction set and performs the payment methods provided in the present specification according to the instructions of the at least one instruction set.

[0044] The processor 220 can be in the form of one or more processors. In some embodiments, the processor 220 can include one or more hardware processors, such as a microcontroller, a microprocessor, a reduced instruction set computer (RISC), an application specific integrated circuit (ASIC), an application specific instruction set processor (ASIP), a central processing unit (CPU), a graphics processing unit (GPU), a physics processing unit (PPU), a microcontroller unit, a digital signal processor (DSP), a field programmable gate array (FPGA), an advanced RISC machine (ARM), a programmable logic device (PLD), any circuit or processor capable of executing one or more functions, or the like, or any combination thereof.

[0045] For the sake of illustration only, the flowchart of the payment method P300 is shown in the form of a sequence of steps, but the steps of the payment method P300 can also be performed in parallel or in another sequence. Figure 2 Only one processor 220 is shown in the computing system 200. However, it should be noted that the computing system 200 can also include multiple processors in the present specification. Therefore, the operations and / or method steps disclosed in the present specification can be performed by one processor as described in the present specification, or jointly performed by multiple processors. For example, if the processor 220 of the computing system 200 performs step A and step B in the present specification, it should be understood that step A and step B can also be performed jointly or separately by two different processors 220 (for example, a first processor performs step A, and a second processor performs step B, or the first and second processors jointly perform steps A and B).

[0046] Figure 3 A flowchart of a payment method P300 according to an embodiment of the present specification is shown. The wallet system can perform the payment method P300.

[0047] As shown in the flowchart of the payment method P300, the payment method P300 includes the following steps. Figure 3

[0048] S310: In response to receiving the authorization request of the target order, performing a first authorization process to reserve a first authorized fund for the target order.

[0049] The target user can select an intended commodity or service for ordering in the merchant system, and the merchant system generates a target order in response to the ordering operation of the target user. The target user can select a target payment card applied for in the wallet system to pay for the target order. In response to the payment operation of the target user, the merchant system generates and sends an authorization request of the target order, which is transmitted to the wallet system through the card group system.

[0050] ​The authorization request of the target order includes, but is not limited to, information of the target payment card and information of the target order. The information of the target payment card, for example, a card number, an issuer identification, etc. The information of the target order, for example, a commodity, a merchant, a logistics address, a transaction fund of the commodity, a transaction time, etc. The transaction fund can be understood as a price of the commodity or service displayed by the merchant system to the target user. The transaction fund includes a transaction currency and a quantity. The transaction currency can be understood as a currency type corresponding to the transaction fund. The quantity of the transaction fund can be understood as a currency quantity of the transaction currency or an amount of the transaction fund. The currency and quantity of a certain fund referred to hereinafter are understood in the same way, and will not be repeated.

[0051] After the wallet system receives the authorization request of the target order, the authorization request can be parsed to obtain the target payment card associated with the target order. The association of the target order with the target payment card can be understood as that the target payment card is a payment card specified by the target user for the target order.

[0052] After the wallet system determines the target payment card, it can verify whether the target payment card meets the authorization condition. When the target payment card meets the authorization condition, the wallet system can perform a first authorization process to reserve a first authorization fund for the target order. The authorization condition includes that the target payment card is in a normal state and the balance value is greater than the value of the transaction fund. The normal state of the target payment card means that the target payment card has not been canceled or frozen by the target user, and can be used for normal payment at the current time. After the wallet system reserves the first authorization fund, the target user can observe that the balance (or limit, hereinafter referred to as balance) of the target payment card decreases by the first authorization fund. The first authorization fund is used for subsequent payment.

[0053] Exemplarily, the target payment card contains at least one account, and the at least one account belongs to the target payment card in the wallet system. The at least one account can be a debit account or a credit account, or a part of the accounts is a debit account and the other part is a credit account, which is not limited in the present specification. The debit account allows pre-deposit of funds, and the deduction from the balance of the debit account is performed to complete the fund reservation in the authorization process. The credit account has a credit limit (also known as credit limit) provided by a financial institution (such as the wallet system), which can be used as working capital, and needs to be repaid (i.e., repayment) after a certain period of time. Each account contained in the target payment card can be used for fund management, such as transferring in, storing or transferring out funds. The funds or limits in each account are visible to the user.

[0054] The wallet system can reserve the first authorization fund through one or more accounts in the target payment card when performing the first authorization process. This specification mainly takes one account (e.g., the first account) reserving the first authorization fund as an example. The currency of the first authorization fund (hereinafter referred to as the first authorization currency) can be the same as the transaction currency, or can be different from the transaction currency, which is not limited in this specification. When the first authorization currency is different from the transaction currency, the value of the first authorization fund is the same as the value of the transaction fund. The wallet system can determine the first authorization fund through the exchange rate between the first authorization currency and the transaction currency, and the transaction fund. In this specification, the comparison of the values of funds of different currencies refers to the comparison of the amounts of funds converted into the same currency. For example, the value of the first authorization fund being the same as the value of the transaction fund can be understood as: the amount of the first authorization fund converted into the transaction currency is the same as or close to the amount of the transaction fund. If the funds to be compared belong to the same currency, the wallet system can directly compare the amounts of the funds.

[0055] For example, as shown in FIG. 1, the wallet system reserves the first authorization fund through the first account in the target payment card, which includes that the wallet system transfers the first authorization fund (or the fund with the same value as the first authorization fund) from the first account to the first temporary storage account. Figure 4 The first authorization fund stored in the first temporary storage account can be frozen and not used for authorization of other orders, thereby guaranteeing the subsequent payment request of the target order. The temporary storage account is an account for temporarily storing funds after authorization, and the funds in the temporary storage account are invisible to the user. After the payment request, the wallet system transfers the corresponding funds in the temporary storage account to the clearing account. There can be multiple temporary storage accounts in the wallet system, and one user can correspond to one or more temporary storage accounts. When one user corresponds to multiple temporary storage accounts, each temporary storage account can correspond to a different currency. The first account and the first temporary storage account can correspond to the first authorization currency.

[0056] In some embodiments, after performing the first authorization process, the wallet system can further generate the first authorization information corresponding to the target order, and store the first authorization information in the database. The first authorization information includes the amount and currency of the first authorization fund. The currency of the first authorization fund is the first authorization currency.

[0057] The payment card industry data security standard requires payment-related institutions to retain relevant vouchers or operation logs. In this embodiment, the wallet system generates and stores the first authorization information to guarantee the authorization compliance in the payment process. The first authorization information can be used as authorization vouchers to support the subsequent payment request process, and can be used as evidence when disputes occur due to abnormal payment request. The first authorization information can also record the source (e.g., the first account) and transfer time of the first authorization fund, thereby realizing the traceability of the first authorization fund.

[0058] After the first authorization procedure is performed, the wallet system can further generate an authorization result representing that the authorization is successful. The authorization result can be transmitted to the merchant system through the card group system. After the merchant system receives the authorization result representing that the authorization is successful, the merchant system can generate and send a request for payment of the target order. The request for payment can be transmitted to the wallet system through the card group system.

[0059] The database can be an internal database of the wallet system or an external database of the wallet system, and the present specification does not limit this. The first authorization information can be stored in the database in the form of a bill or in other forms, and the present specification does not limit this.

[0060] S320: In response to receiving the request for payment of the target order, if the value of the payment fund specified in the request for payment is greater than the value of the first authorization fund, a second authorization procedure is performed to reserve a second authorization fund for the target order, wherein the sum of the values of the first authorization fund and the second authorization fund is not less than the value of the payment fund.

[0061] The request for payment can include the currency (hereinafter referred to as the payment currency) and the amount of the payment fund. After the wallet system receives the request for payment, the wallet system can determine whether the value of the payment fund is greater than the value of the first authorization fund.

[0062] In some embodiments, in response to receiving the request for payment of the target order, the wallet system obtains the first authorization information from the database, and obtains the amount and currency of the first authorization fund from the first authorization information, and then can determine whether the value of the payment fund specified in the request for payment is greater than the value of the first authorization fund based on the amount and currency of the first authorization fund.

[0063] For example, the wallet system can find the first authorization information from the database through the field value of a specific field in the request for payment. The field value of the specific field can be an order number generated by the merchant system, or other identifiers generated by the acquirer system or the card group system based on the order number, and the present specification does not limit this. When the payment fund and the first authorization fund correspond to the same currency, the wallet system can directly determine whether the value of the payment fund is greater than the value of the first authorization fund through the amount of the payment fund and the amount of the first authorization fund. When the payment fund and the first authorization fund correspond to different currencies, assuming that the amount of the payment fund is n1, the wallet system determines the amount of the fund after the first authorization fund is exchanged according to the exchange rate between the payment currency and the first authorization currency as n2. At this time, if n1>n2, it indicates that the value of the payment fund is greater than the value of the first authorization fund. If n1≤n2, it indicates that the value of the payment fund is less than or equal to the value of the first authorization fund. The value comparison between the other two funds mentioned in the present specification is similar and will not be repeated.

[0064] Continuing to refer toFigure 4 In the case where the value of the requested funds is less than or equal to the value of the first authorized funds, the wallet system determines that the request is a regular request and the request can be processed by the first authorized funds. When the value of the requested funds is equal to the first authorized funds, the wallet system transfers the requested funds (or funds of the same value as the requested funds) from the first temporary account to a settlement pending account. The settlement pending account is an internal public account of the wallet system and does not belong to the user, and is used to store funds that have not yet been settled between the wallet system and other financial systems. When the relevant order is checked, the wallet system will transfer the funds in the settlement pending account to the account of the card group system or the merchant account designated by the card group system. When the value of the requested funds is less than the first authorized funds (i.e. partial request), the wallet system transfers the requested funds (or funds of the same value as the requested funds) from the first temporary account to the settlement pending account, and can release the part of the first authorized funds that is not requested to return to the first account after a preset time according to specific circumstances (e.g. authorization type).

[0065] If the currency of the requested funds and the currency of the first authorized funds are the same, the wallet system can directly transfer the requested funds from the first temporary account to the settlement pending account. If the currency of the requested funds and the currency of the first authorized funds are different, the wallet system can exchange the funds of the same value as the requested funds in the first temporary account into the currency of the requested funds and then transfer them to the settlement pending account.

[0066] In the case where the value of the requested funds is greater than the value of the first authorized funds, the wallet system performs a second authorization process to reserve second authorized funds for the target order. The second authorized funds are used to support the smooth progress of the request processing together with the first authorized funds.

[0067] In some embodiments, the first authorized funds come from the target payment card. The second authorized funds come from at least one of the target payment card or a funding account of the wallet system. The funding account is an account in which the wallet system provides funds to users to ensure the smooth progress of the payment process, and does not belong to any user. It can be an account for the wallet system to calculate internal profits and losses.

[0068] There can be various cases of the source of the second authorized funds, and some of them are exemplified below.

[0069] Example 1: The target payment card contains multiple accounts, and the second authorized funds can come from one or more accounts in the target payment card. When multiple accounts correspond to different currencies, the wallet system involves currency exchange calculation when combining and deducting the second authorized funds from multiple accounts in the target payment card. The second authorized funds and the first authorized funds can come from different accounts in the target payment card or from the same account, which is not limited in this specification.

[0070] In some embodiments, the target payment card supports multi-currency accounts (i.e., the target payment card contains multiple accounts corresponding to different currencies), and the first authorized fund comes from a first account in the target payment card. Continuing to refer to FIG. 1, the target payment card 102 contains a first account 104 and a second account 106, and the first account 104 corresponds to a first currency (e.g., USD) and the second account 106 corresponds to a second currency (e.g., CNY). The first authorized fund comes from the first account 104.

[0071] In some embodiments, the target payment card supports multi-currency accounts (i.e., the target payment card contains multiple accounts corresponding to different currencies), and the first authorized fund comes from a first account in the target payment card. Continuing to refer to FIG. 1, the target payment card 102 contains a first account 104 and a second account 106, and the first account 104 corresponds to a first currency (e.g., USD) and the second account 106 corresponds to a second currency (e.g., CNY). The first authorized fund comes from the first account 104.

[0072] In some embodiments, the target payment card supports multi-currency accounts (i.e., the target payment card contains multiple accounts corresponding to different currencies), and the first authorized fund comes from a first account in the target payment card. Continuing to refer to FIG. 1, the target payment card 102 contains a first account 104 and a second account 106, and the first account 104 corresponds to a first currency (e.g., USD) and the second account 106 corresponds to a second currency (e.g., CNY). The first authorized fund comes from the first account 104. In some embodiments, the target payment card supports multi-currency accounts (i.e., the target payment card contains multiple accounts corresponding to different currencies), and the first authorized fund comes from a first account in the target payment card. Continuing to refer to FIG. 1, the target payment card 102 contains a first account 104 and a second account 106, and the first account 104 corresponds to a first currency (e.g., USD) and the second account 106 corresponds to a second currency (e.g., CNY). The first authorized fund comes from the first account 104. Figure 4 In some embodiments, the target payment card supports multi-currency accounts (i.e., the target payment card contains multiple accounts corresponding to different currencies), and the first authorized fund comes from a first account in the target payment card. Continuing to refer to FIG. 1, the target payment card 102 contains a first account 104 and a second account 106, and the first account 104 corresponds to a first currency (e.g., USD) and the second account 106 corresponds to a second currency (e.g., CNY). The first authorized fund comes from the first account 104.

[0073] In some embodiments, the target payment card supports multi-currency accounts (i.e., the target payment card contains multiple accounts corresponding to different currencies), and the first authorized fund comes from a first account in the target payment card. Continuing to refer to FIG. 1, the target payment card 102 contains a first account 104 and a second account 106, and the first account 104 corresponds to a first currency (e.g., USD) and the second account 106 corresponds to a second currency (e.g., CNY). The first authorized fund comes from the first account 104.

[0074] In some embodiments, the target payment card supports multi-currency accounts (i.e., the target payment card contains multiple accounts corresponding to different currencies), and the first authorized fund comes from a first account in the target payment card. Continuing to refer to FIG. 1, the target payment card 102 contains a first account 104 and a second account 106, and the first account 104 corresponds to a first currency (e.g., USD) and the second account 106 corresponds to a second currency (e.g., CNY). The first authorized fund comes from the first account 104.

[0075] In some embodiments, the target payment card supports multi-currency accounts (i.e., the target payment card contains multiple accounts corresponding to different currencies), and the first authorized fund comes from a first account in the target payment card. Continuing to refer to FIG. 1, the target payment card 102 contains a first account 104 and a second account 106, and the first account 104 corresponds to a first currency (e.g., USD) and the second account 106 corresponds to a second currency (e.g., CNY). The first authorized fund comes from the first account 104.

[0076] The account information of the first account includes state information and balance information of the first account. If the state information of the first account is closed or not opened or unavailable, the wallet system determines that the first account does not support the supplementary authorization for the target order. If the state information of the first account is opened or available, and the balance value of the first account is less than the value of the second authorized fund, the wallet system determines that the first account does not support the supplementary authorization for the target order. If the state information of the first account is opened or available, and the balance value of the first account is greater than or equal to the value of the second authorized fund, the wallet system determines that the first account supports the supplementary authorization for the target order.

[0077] In the above example, when the state of the target payment card is normal and the first account supports the supplementary authorization, the wallet system can make a supplementary payment through the first account, ensuring that the request process can proceed smoothly. When the state of the target payment card is normal and the first account does not support the supplementary authorization, the wallet system makes a supplementary authorization through the advance account, which can reduce the disturbance to the user, avoid the problem of payment failure caused by the interruption of the request process, and also avoid the complex operation problem of currency exchange caused by selecting other accounts for supplementary authorization in the target payment card.

[0078] In some embodiments, continuing to refer to Figure 4 , after the wallet system determines the target account, the second authorization process performed includes: transferring the second authorized fund (or the fund with the same value as the second authorized fund) from the target account to the second temporary account. So that there is enough fund in the temporary account that can be transferred to the to-be-cleared account in the subsequent request processing, ensuring the smooth progress of the request processing.

[0079] In some embodiments, after the second authorization process is performed, the wallet system can also generate second authorization information corresponding to the target order, and store the second authorization information in the database. The second authorization information includes the number and currency of the second authorized fund. The currency of the second authorized fund is recorded as the second authorized currency. The second authorized currency can be the same as the first authorized currency, or can be different (such as when the first authorized fund and the second authorized fund come from accounts corresponding to different currencies), which is not limited in the present specification.

[0080] The wallet system generates and stores the second authorization information to ensure the compliance of the supplementary authorization process. The second authorization information can be used as a supplementary authorization certificate to support the request processing or subsequent fund recovery, and can be used as evidence when the subsequent request processing or fund recovery abnormally causes a dispute. The second authorization information can also record the source (for example, the target account) and the transfer time of the second authorized fund, realizing the traceability of the second authorized fund.

[0081] S330: Complete the payment request processing of the target order based on the first authorized fund and the second authorized fund.

[0082] In some embodiments, the first authorized fund and the second authorized fund are stored in a temporary account (e.g., the first temporary account and the second temporary account). The wallet system transfers the first authorized fund and the second authorized fund from the temporary account to the to-be-settled account.

[0083] The first temporary account and the second temporary account can be the same account or different accounts, which is not limited in the specification. When the first temporary account and the second temporary account are the same account, the wallet system can transfer the first authorized fund and the second authorized fund from the first temporary account or the second temporary account to the to-be-settled account at the same time to complete the payment request processing of the target order.

[0084] Continuing to refer to Figure 4 When the first temporary account and the second temporary account correspond to different accounts, the wallet system can transfer the first authorized fund (or the fund with the same value as the first authorized fund) from the first temporary account to the to-be-settled account, and transfer the second authorized fund (or the fund with the same value as the second authorized fund) from the second temporary account to the to-be-settled account at the same time to complete the payment request processing of the target order. The currency corresponding to the to-be-settled account can be the payment request currency, and when the first authorized currency or the second authorized currency is different from the payment request currency, the wallet system needs to exchange the first authorized fund or the second authorized fund into the payment request currency before transferring it to the to-be-settled account.

[0085] In this embodiment, the wallet system combines the two authorized funds into the to-be-settled account, which can avoid the cumbersome problem of subsequent reconciliation and fund settlement caused by batch transfer, and improve the payment settlement efficiency.

[0086] If part or all of the second authorized fund comes from one or more fund-advance accounts, the wallet system can also perform a fund recovery process after completing the payment request processing of the target order to avoid the capital loss problem caused by fund advance of the wallet system.

[0087] Hereinafter, mainly taking the example that the second authorized fund is entirely from one fund-advance account (e.g., fund-advance account 1) to introduce the fund recovery process of the second authorized fund advanced by the fund-advance account 1 by the wallet system. The fund recovery process of the second authorized fund partially from one fund-advance account is similar and will not be repeated. When part or all of the second authorized fund comes from multiple fund-advance accounts, the wallet system can recover the fund advanced by each fund-advance account according to the fund recovery process of the example below, which will not be repeated.

[0088] Figure 5 A schematic diagram of the fund recovery process is shown. As Figure 5As shown, the steps of the fund recovery process include: S410: generating a fund recovery task for the cushioning account 1 and setting a trigger condition for the fund recovery task.

[0089] In some embodiments, the fund recovery task is used by the wallet system to recover the second authorized fund that the cushioning account 1 has cushioned for the user. The trigger condition is a periodic trigger condition. The periodic trigger ensures that the fund recovery task will not be terminated due to a single failure, ensures that the cushioning of the wallet system can be successfully recovered, and reduces the cushioning loss of the wallet system.

[0090] When the wallet system performs the second authorization process, if the status of the target payment card is normal, and the first account does not support supplementary authorization for the target order, the wallet system can directly generate a fund recovery task for the cushioning account 1 after completing the second authorization process and set a trigger condition, thereby improving the fund recovery efficiency, reducing the disturbance to the cardholder, and providing a better payment experience for the cardholder.

[0091] When the wallet system performs the second authorization process, if the status of the target payment card is abnormal, indicating that the target order is more likely to be stolen by a criminal, the wallet system cannot directly generate a fund recovery task and needs to inquire the holder of the target payment card.

[0092] For example, the wallet system sends a confirmation request to the holder of the target payment card about the target order, and generates a fund recovery task for the cushioning account 1 in the case of detecting a confirmation operation of the holder on the target order. This example avoids the problem that the user experience is poor due to the loss of fund of the target payment card after the cardholder freezes the target payment card due to theft. If the wallet system does not detect a confirmation operation of the holder of the target payment card on the target order within a preset time period, or the wallet system detects a refusal confirmation operation of the holder of the target payment card on the target order, the fund recovery task for the cushioning account 1 is not generated. The wallet system can record the contents related to the authorization request and the payment request of the target order for risk analysis to reduce the occurrence of similar situations in the future.

[0093] S420: In response to the fund recovery task being triggered, the wallet system detects whether the target payment card meets the recovery condition, and in the case of yes, transfers the second authorized fund from the target payment card to the cushioning account 1. The recovery condition includes whether the balance value is greater than or equal to the value of the second authorized fund.

[0094] Exemplarily, the trigger condition of the fund recovery task includes a trigger time and a fund recovery period. The wallet system detects that the current time is the trigger time of the current fund recovery period, i.e., determines that the fund recovery task is triggered. For example, the trigger time is 00:00, and the fund recovery period is 24 hours. After the wallet system generates the fund recovery task, the wallet system detects whether the current time is 00:00. If it is detected that the current time is 00:00, it is determined that the fund recovery task is triggered. If the second authorized fund is not successfully recovered in the current fund recovery period, the wallet system triggers the fund recovery task again at 00:00 after 24 hours until the second authorized fund is successfully recovered.

[0095] The wallet system can recover funds from one account in the target payment card or from multiple accounts in the target payment card, and the present specification does not limit this. Hereinafter, the fund recovery through one account is mainly taken as an example for introduction, and the fund recovery through multiple accounts is similar and will not be repeated.

[0096] The wallet system can detect whether the target payment card meets the recovery condition and recover the second authorized fund in multiple ways. Hereinafter, two of them are taken as examples, but the present specification is not limited thereto.

[0097] Example 1: The wallet system detects whether the account in the target payment card that is of the same currency as the fund account 1 (hereinafter referred to as the fund currency account) meets the recovery condition. If the fund currency account meets the recovery condition, such as the balance value of the fund currency account being greater than or equal to the value of the second authorized fund, the wallet system transfers the second authorized fund from the fund currency account to the fund account 1. This process does not involve currency exchange, which can reduce the loss caused by currency exchange and improve the payment experience of the user. If the fund currency account does not meet the recovery condition, the fund recovery task in the current fund recovery period ends, and the fund recovery task at the trigger time of the next fund recovery period is executed. The wallet system executes the fund recovery task at the trigger time of the next fund recovery period in a similar way, which will not be repeated.

[0098] Example 2: The wallet system traverses the multiple accounts contained in the target payment card according to a target order, detects whether each account meets the recovery condition in turn, determines the first account that meets the recovery condition as the second account, and transfers the second authorized fund from the second account to the fund account 1. If none of the multiple accounts meets the recovery condition, the fund recovery task in the current fund recovery period ends, and the fund recovery task at the trigger time of the next fund recovery period is executed. The wallet system executes the fund recovery task at the trigger time of the next fund recovery period in a similar way, which will not be repeated.

[0099] The example can ensure that when the cushion currency account does not meet the recovery condition, the wallet system can also recover funds from other accounts in the target payment card, thereby improving the success rate and efficiency of fund recovery.

[0100] Each account in the target payment card corresponds to a currency. Before traversing the plurality of accounts in the target order, the wallet system can obtain a preset recovery priority of a plurality of currencies, and determine the target order based on the recovery priority of the plurality of currencies and the currency corresponding to each account in the plurality of accounts. In order to make the currency of fund recovery consistent with the currency use preference of the target user, the wallet system can set the currency recovery priority consistent with the implicit intention of the target user, and preferentially recover the second authorized fund from the account of the target user's habitual currency, so as to improve the experience of the target user.

[0101] For example, the recovery priority of the plurality of currencies is in descending order of the currency corresponding to the cushion account 1 (hereinafter referred to as the cushion currency), the clearing currency, the preset authorized currency of the target region, and other currencies. The target region is the region corresponding to the holder of the target payment card. The region corresponding to the holder of the target payment card can be the region where the target user applies for the target payment card, or the region where the target user initiates the target order, which is not limited in the present specification.

[0102] In this example, the wallet system can preferentially use the cushion currency account for fund recovery, avoiding currency exchange due to different currencies, which is complex and has exchange loss and gain, affecting user experience. When the balance of the cushion currency account is insufficient, the wallet system can use the account corresponding to the clearing currency or the preset authorized currency of the target region in the target payment card for fund recovery, so that the currency of fund recovery is biased towards the user's currency use habit. When the balance of the account corresponding to the above-mentioned currencies in the target payment card is insufficient, the wallet system can use the account corresponding to other currencies for fund recovery, thereby ensuring the success rate and efficiency of fund recovery. The preset authorized currency of the target region can be determined by the transaction currency. For example, when the transaction currency is a currency in the first currency set, the preset authorized currency of the target region can be the transaction currency. The transaction frequency of each currency in the first currency set is higher than or equal to a preset frequency, or each currency in the first currency set is a currency with strong influence or a basic currency used in most regions. When the transaction currency is not a currency in the first currency set, the preset authorized currency of the target region can be a specific currency negotiated by the wallet system and the card group system.

[0103] Figure 6 The flow of traversing the plurality of accounts according to the recovery priority of the plurality of currencies is shown.

[0104] Referring to Figure 6, the wallet system first determines whether the account of the currency provided by the payment card meets the recovery condition. If the account of the currency provided by the payment card meets the recovery condition, the wallet system determines the account of the currency provided by the payment card as the second account. If the account of the currency provided by the payment card does not meet the recovery condition, the wallet system determines whether the account of the settlement currency meets the recovery condition. If the account of the settlement currency meets the recovery condition, the wallet system determines the account of the settlement currency as the second account. If the account of the settlement currency does not meet the recovery condition, the wallet system determines whether the account of the alternative currency meets the recovery condition. If the account of the alternative currency meets the recovery condition, the wallet system determines the account of the alternative currency as the second account. If the account of the alternative currency does not meet the recovery condition, the wallet system determines whether the account of the other currency meets the recovery condition. If the account of the other currency meets the recovery condition, the wallet system determines the account of the other currency as the second account. If the account of the other currency does not meet the recovery condition, the wallet system suspends the fund recovery task, i.e., the fund recovery task in the current fund recovery period ends, and waits for the next fund recovery period to trigger the execution of the fund recovery task.

[0105] In the formula, the account of the currency provided by the payment card is the account corresponding to the currency provided by the payment card in the target payment card. The account of the settlement currency is the account corresponding to the settlement currency in the target payment card. The account of the alternative currency is the account corresponding to the preset authorized currency of the target region in the target payment card. The account of the other currency is the account corresponding to the other currency in the target payment card. The other currency is a currency other than the currency provided by the payment card, the settlement currency, and the preset authorized currency of the target region.

[0106] When the alternative currency or the other currency includes multiple currencies, the wallet system can preset the recovery priority of the multiple currencies. For example, the alternative currency includes currency 1 and currency 2, and the recovery priority of currency 1 is higher than that of currency 2. The other currency includes currency 3 and currency 4, and the recovery priority of currency 3 is higher than that of currency 4.

[0107] Continuing to refer to Figure 6 In the alternative currency account, the wallet system first determines whether account 1 (the account corresponding to currency 1 in the target payment card) meets the recovery condition, and determines the account that first meets the recovery condition among account 1 and account 2 (the account corresponding to currency 2 in the target payment card) as the second account. In the other currency account, the wallet system first determines whether account 3 (the account corresponding to currency 3 in the target payment card) meets the recovery condition, and determines the account that first meets the recovery condition among account 3 and account 4 (the account corresponding to currency 4 in the target payment card) as the second account. The wallet system determines whether a certain account meets the recovery condition in Example 2 in a manner similar to that in Example 1, and thus the details are not repeated.

[0108] After the wallet system determines the second account, there are multiple ways to deduct funds from the second account for fund recovery, and two of the ways are exemplified below, but the present specification is not limited thereto.

[0109] Method 1 When the second account and the advance account 1 correspond to the same currency, the wallet system transfers the second authorized fund from the second account to the advance account 1. Alternatively, the wallet system transfers the second authorized fund from the second account to the temporary account, and transfers the second authorized fund from the temporary account to the advance account 1. At this point, the fund recovery ends.

[0110] Method 2 When the second account and the advance account 1 correspond to different currencies, the wallet system determines the target fund to be deducted from the second account according to the exchange rate between the advance currency and the currency corresponding to the second account, and the second authorized fund, and then transfers the target fund from the second account to the temporary account 1, and transfers the target fund in the temporary account 1 to the advance account 1 after the target fund is exchanged into the advance currency. Alternatively, the wallet system stores the target fund in the temporary account 1 into the temporary account 2 after the target fund is exchanged into the advance currency, and then transfers the fund in the temporary account 2 to the advance account 1. At this point, the fund recovery ends.

[0111] The fund in the specification can be understood as a digital asset, which can be a digital currency or other assets that can be used for quantitative payment, and the specification does not limit this.

[0112] In summary, the payment method, wallet system and storage medium provided by the specification can supplement the authorized fund through re-authorization when the value of the requested fund specified by the request exceeds the value of the reserved authorized fund, so as to ensure the smooth progress of the request process, avoid the interruption or failure of the request process due to the excess of the request, and reduce the payment failure rate caused by the excess of the request. The scheme can also avoid the abnormal freezing of the authorized fund caused by the excess of the request, so that the user cannot use the fund to place an order again or pay for other orders in a short time, thereby improving the payment experience of the user, and reducing the operating cost of the merchant caused by the interruption of the request process, so as to reduce the payment in "half completion" or failure.

[0113] Another aspect of the present specification provides a computer-readable non-transitory storage medium storing at least one set of executable instructions for payment. When the executable instructions are executed by a processor, the executable instructions direct the processor to implement the steps of the payment method P300 described in the present specification. In some possible implementation, various aspects of the present specification can also be implemented in the form of a program product including program code. When the program product is run on the computing system 200, the program code is used to cause the computing system 200 to perform the steps of the payment method P300 described in the present specification. The program product for implementing the above method can include program code in a portable compact disc read-only memory (CD-ROM) and can be run on the computing system 200. However, the program product of the present specification is not limited to this, and in the present specification, the readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system. The program product can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium may, for example, be but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination of the above. More specific examples of the readable storage medium include an electrical connection having one or more wires, a portable disc, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. The computer-readable storage medium can include a data signal propagating in a baseband or as a carrier wave in a propagated signal, in which readable program code is borne. Such a propagated data signal can take on many forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The readable storage medium can also be any readable medium that is not a storage medium and that can transmit, propagate or transport program for use by or in connection with an instruction execution system, apparatus or device. The program code contained in the readable storage medium can be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, and the like, or any suitable combination of the above. The program code for performing the operations of the present specification can be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, C++, and the like, and a conventional procedural programming language such as the "C" programming language or the like. The program code can be executed entirely on the computing system 200, partially on the computing system 200, as an independent software package, partially on the computing system 200 and partially on a remote computing device, or entirely on a remote computing device.

[0114] The term "and / or" in the embodiments of the present specification describes an associated relationship with the associated objects, which means that there can be three kinds of relationships. For example, A and / or B can represent the following three cases: A exists alone, A and B exist together, and B exists alone. The character " / " generally represents that the associated objects before and after it are in an "or" relationship.

[0115] The terms "first", "second", and the like in the present specification are used to distinguish similar or identical objects or entities, and do not necessarily mean to limit a specific order or sequence.

[0116] The present specification refers to "a plurality of", which should be understood as two or more, unless there is a special declaration.

[0117] The above describes specific embodiments of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different than the order in the embodiments and still achieve the desired result. In addition, the processes depicted in the accompanying drawings do not necessarily require the particular order or sequential order to achieve the desired results. In some embodiments, multi-task processing and parallel processing are possible or can be advantageous.

[0118] In summary, after reading the detailed disclosure, those skilled in the art can understand that the foregoing detailed disclosure can be presented only in an exemplary manner, and can not be limiting. Although it is not explicitly stated here, those skilled in the art can understand that the present specification requires to encompass various reasonable changes, improvements and modifications to the embodiments. These changes, improvements and modifications are intended to be presented by the present specification, and are within the spirit and scope of the exemplary embodiments of the present specification.

[0119] In addition, certain terms in the present specification have been used to describe the embodiments of the present specification. For example, "one embodiment", "embodiment" and / or "some embodiments" mean that the specific features, structures or characteristics described in connection with the embodiment can be included in at least one embodiment of the present specification. Therefore, it can be emphasized and should be understood that two or more references to "embodiments" or "one embodiment" or "alternative embodiments" in various parts of the present specification do not necessarily all refer to the same embodiment. In addition, specific features, structures or characteristics can be appropriately combined in one or more embodiments of the present specification.

[0120] It is to be understood that the foregoing description of the embodiments of the present specification is intended to be illustrative only and that other embodiments of the present specification are possible being encompassed by the present specification. For the purpose of simplicity of the present specification, various features of the present specification are grouped together in one or more embodiments, drawings or descriptions thereof. However, the features described as grouped together are not to be understood as being indispensable to a single embodiment of the present specification. In fact, some of the features as described above can be implemented independently of all other features and thus may be implemented in one or more embodiments, in any combination. Similarly, the description of the embodiments of the present specification is to be understood as meaning that the various embodiments of the present specification can also be understood as a combination of the various sub-embodiments. In other words, the embodiments of the present specification can be understood as a combination of the various sub-embodiments, each of which is characterized by less than all features of the single embodiment as described above.

[0121] Each patent, patent application, publication of a patent application, and other material, such as articles, books, specifications, publications, documents, literature, and the like (to the extent relevant-associated history files, if any, are excluded) cited herein that are not common general knowledge are hereby incorporated by reference in their entirety for all purposes to the same extent as if each were specifically and individually indicated to be incorporated by reference herein. In the case of any inconsistencies, the present disclosure, including definitions and terminology, will prevail.

[0122] Finally, it should be understood that the embodiments of the application disclosed herein are illustrative of the principles of the present specification. Other modifications that fall within the scope of the present specification can also be made to embodiments of the present specification. Accordingly, the disclosure of embodiments is intended to be illustrative, but not limiting, of the scope of the present specification. Thus, the embodiments disclosed herein are merely exemplary and are not intended to limit the present specification.

Claims

1. A payment method applied to a wallet system, comprising: in response to receiving an authorization request of a target order, performing a first authorization procedure to reserve a first authorization fund for the target order; in response to receiving a request for funds of the target order, performing a second authorization procedure to reserve a second authorization fund for the target order if a value of the requested funds specified in the request for funds is greater than a value of the first authorization fund, wherein a sum of the values of the first authorization fund and the second authorization fund is not less than the value of the requested funds; and completing the request for funds of the target order based on the first authorization fund and the second authorization fund. the first authorization fund is from a target payment card associated with the target order; 2. The method of claim 1, wherein, the second authorization fund is from at least one of the target payment card or a top-up account of the wallet system. the target payment card supports a multi-currency account, and the first authorization fund is from a first account in the target payment card, and the performing the second authorization procedure comprises:

3. The method of claim 2, wherein, determining a target account from the first account or the top-up account based on a status of the target payment card and / or account information of the first account; and performing the second authorization procedure based on the target account. the determining the target account from the first account or the top-up account based on the status of the target payment card and / or the account information of the first account comprises:

4. The method of claim 3, wherein, if the status of the target payment card is normal and the account information indicates that the first account supports supplementary authorization for the target order, determining the first account as the target account; if the status of the target payment card is normal and the account information indicates that the first account does not support supplementary authorization for the target order, determining the top-up account as the target account; or if the status of the target payment card is abnormal, determining the top-up account as the target account. in the first authorization procedure, the first authorization fund is transferred from the first account to a first temporary account, and the performing the second authorization procedure based on the target account comprises:

5. The method of claim 3, wherein, transferring the second authorization fund from the target account to a second temporary account. the second authorization fund is from the top-up account, and after the completing the request for funds of the target order, the method further comprises:

6. The method of claim 2, wherein, generating a fund recovery task for the top-up account and setting a trigger condition of the fund recovery task; and in response to the fund recovery task being triggered, detecting whether the target payment card meets a recovery condition, and if so, transferring the second authorization fund from the target payment card to the top-up account, wherein the recovery condition comprises whether a balance value is greater than or equal to the value of the second authorization fund. the target payment card comprises a plurality of accounts, and the detecting whether the target payment card meets the recovery condition and, if so, transferring the second authorization fund from the target payment card to the top-up account comprises:

7. The method of claim 6, wherein, ​ According to the target order, the plurality of accounts are traversed in sequence, and it is detected whether each account meets the recourse condition, a first account meeting the recourse condition is determined as a second account, and the second authorized fund is transferred from the second account to the fund account.

8. The method of claim 7, wherein, Each account of the plurality of accounts corresponds to a currency, and before the plurality of accounts are traversed according to the target order, the method further comprises: obtaining a recourse priority of a plurality of currencies; and determining the target order based on the recourse priority of the plurality of currencies and the currency corresponding to each account of the plurality of accounts.

9. The method of claim 8, wherein, The recourse priority of the plurality of currencies is in descending order of the currency corresponding to the fund account, a settlement currency, a preset authorized currency of a target region, and other currencies, and the target region is a region corresponding to a holder of the target payment card.

10. The method of claim 6, wherein, The generating of the fund recovery task for the fund account comprises: sending a confirmation request about the target order to the holder of the target payment card; and generating the fund recovery task for the fund account when detecting a confirmation operation of the target order by the holder.

11. The method of claim 6, wherein, The trigger condition is a periodic trigger condition.

12. The method of claim 1, wherein, The first authorized fund and the second authorized fund are stored in a temporary account, and the fund collection processing of the target order based on the first authorized fund and the second authorized fund comprises: transferring the first authorized fund and the second authorized fund from the temporary account to a settlement account.

13. The method of claim 1, wherein, After executing the first authorization process, the method further comprises: generating first authorization information corresponding to the target order, and storing the first authorization information in a database, wherein the first authorization information comprises the amount and currency of the first authorized fund; in response to receiving a fund collection request of the target order, the method further comprises: obtaining the first authorization information from the database, and obtaining the amount and currency of the first authorized fund from the first authorization information; and judging whether the value of the fund collection fund specified by the fund collection request is greater than the value of the first authorized fund based on the amount and currency of the first authorized fund.

14. The method of claim 13, wherein, After executing the second authorization process, the method further comprises: generating second authorization information corresponding to the target order, the second authorization information comprising the amount and currency of the second authorized fund; and storing the second authorization information in the database.

15. A wallet system, comprising: at least one storage medium storing at least one instruction set; and at least one processor in communication connection with the at least one storage medium, wherein the at least one processor reads the at least one instruction set when running, and executes the method according to any one of claims 1-14 according to the instruction of the at least one instruction set.

16. A computer-readable non-transitory storage medium, wherein, The computer readable non-transitory storage medium stores at least one instruction set, and the at least one instruction set is executed by at least one processor to implement the method according to any one of claims 1-14.

Images