Payment method, wallet server, credit server and storage medium

Abstract

The embodiment of the invention provides a payment method, a wallet server, a credit server and a storage medium. The method comprises the following steps: in response to a received payment request for requesting to use a target card to pay a target order, a wallet server determines a target user holding the target card, and determines a to-be-paid target credit account in accounts associated with the target card; the wallet server sends a quota freezing request to a credit server, and the credit server freezes a first quota in the credit quota of the target user based on the quota freezing request; in response to the received payment request corresponding to the target order, the wallet server sends a loan request to the credit server, and the credit server issues the first fund to the target credit account based on the loan request, so that the wallet server can execute the payment process of the target order by using the first fund.

Description

Technical Field

[0001] This specification relates to the field of Internet technology, and in particular to a payment method, a wallet server, a credit server, and a storage medium. Background Technology

[0002] With the development of payment services, card issuers have gradually expanded from traditional financial systems (such as banks) to new financial systems (such as unofficial wallets). These new financial systems are subject to restrictions imposed by relevant organizations or license holders, and their issued cards generally adopt a zero-credit-line model. This means that users can use the pre-deposited balance in their account when making payments with this type of card. While this model meets the payment needs of users with ample funds, the lack of overdraft functionality makes it difficult to meet the payment needs of users with tight cash flow, thus limiting the card's applicability.

[0003] The information in the background section is merely information known only to the inventor and does not imply that such information had entered the public domain before the date of this application, nor does it imply that it can be considered prior art in this disclosure. Summary of the Invention

[0004] This specification provides a payment method, a wallet server, a credit server, and a storage medium. The new financial system can work with the credit system to provide overdraft functionality for cards, which can meet the payment needs of users with tight cash flow and improve the applicability of cards.

[0005] In a first aspect, this specification provides a payment method applied to a wallet server, comprising: in response to receiving a payment request requesting payment for a target order using a target card, identifying a target user holding the target card, and identifying a target credit account to be paid from the accounts associated with the target card; sending a credit limit freeze request to a credit server to request the credit server to freeze a first credit limit in the target user's credit limit, the first credit limit being related to the order amount of the target order; in response to receiving a payment request corresponding to the target order, sending a loan disbursement request to the credit server to request the credit server to disburse first funds to the target credit account; and then using the first funds to execute the payment process of the target order.

[0006] Secondly, this specification provides a payment method applied to a credit server, comprising: receiving a credit limit freeze request from a wallet server, wherein the credit limit freeze request is sent by the wallet server upon receiving a payment request to use a target card to pay for a target order, and the account to be paid is a target credit account associated with the target card; freezing a first credit limit in the credit limit of a target user based on the credit limit freeze request, wherein the target user is a user holding the target card, and the first credit limit is related to the order amount of the target order; receiving a loan disbursement request from the wallet server; and then disbursing first funds to the target credit account based on the loan disbursement request, so that the wallet server uses the first funds to execute the payment process of the target order.

[0007] Thirdly, this specification also provides a wallet server, comprising: at least one storage medium storing at least one instruction set; and at least one processor communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and implements the payment method as described in the first aspect according to the instructions of the at least one instruction set.

[0008] Fourthly, this specification also provides a credit server, comprising: at least one storage medium storing at least one instruction set; and at least one processor communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and implements the payment method as described in the second aspect according to the instructions of the at least one instruction set.

[0009] Fifthly, this specification provides a computer-readable non-transitory storage medium, wherein the computer-readable non-transitory storage medium stores at least one instruction set, which, when executed by at least one processor, implements the payment method as described in the first or second aspect.

[0010] Other functionalities of the payment methods, wallet servers, credit servers, and storage media provided in this specification will be partially listed in the following description. The inventive aspects of the payment methods, wallet servers, credit servers, and storage media provided in this specification can be fully understood through practice or by using the methods, servers, and combinations described in the detailed examples below. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A schematic diagram illustrating an application scenario of payment provided according to embodiments of this specification is shown;

[0013] Figure 2 A hardware structure diagram of a computing system provided according to an embodiment of this specification is shown;

[0014] Figure 3 A flowchart of a payment method provided according to an embodiment of this specification is shown;

[0015] Figure 4 A schematic diagram of an account system provided according to an embodiment of this specification is shown;

[0016] Figure 5 A flowchart of the authorization revocation phase provided according to embodiments of this specification is shown; and

[0017] Figure 6 A flowchart of the credit limit application stage provided according to an embodiment of this specification is shown. Detailed Implementation

[0018] The following description provides specific application scenarios and requirements for this specification, intended to enable those skilled in the art to make and use the contents of this specification. Various partial modifications to the disclosed embodiments will be apparent 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 this specification. Therefore, this specification is not limited to the embodiments shown, but rather to the widest scope consistent with the claims.

[0019] The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not restrictive. For example, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” used herein may also include the plural forms. When used in this specification, the terms “comprising,” “including,” and / or “containing” mean that the associated integers, steps, operations, elements, and / or components are present, but do not exclude the presence of one or more other features, integers, steps, operations, elements, components, and / or groups, or that other features, integers, steps, operations, elements, components, and / or groups may be added to the system / method.

[0020] Considering the following description, these and other features of this specification, as well as the operation and function of the related components of the structure, and the economy of assembly and manufacture of the parts, can be significantly improved. All of these form part of this specification with reference to the accompanying drawings. 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 this specification. It should also be understood that the drawings are not drawn to scale.

[0021] The flowcharts used in this specification illustrate operations implemented according to some embodiments of this specification. It should be clearly understood that the operations in the flowcharts may not be implemented in a sequential order. Instead, the operations may be implemented in reverse order or simultaneously. Furthermore, one or more additional operations may be added to the flowcharts. One or more operations may be removed from the flowcharts.

[0022] The following is combined Figure 1 This manual introduces the application scenarios for the payment method.

[0023] Figure 1 A schematic diagram illustrating an application scenario of payment provided according to embodiments of this specification is shown. For example... Figure 1 As shown, the application scenario 100 includes target user 10, wallet server 20, credit server 30, merchant system 40, and acquiring system 50.

[0024] Target user 10 can be any user with transaction needs. For example, target user 10 can be an individual, or an employee of a business or company. Target user 10 can be a regular consumer or a merchant.

[0025] Target user 10 can apply for a card in the financial system and use the card to pay for related orders in the merchant system 40.

[0026] The card mentioned in this manual is a digital payment tool issued by the financial system. It can be a virtual card (without a physical form) or a digital replica of a physical card; this manual makes no restrictions on this. The financial system can issue cards through means such as websites or applications. Card-related information can be stored on a wallet server or in the cloud for online channel management. For example, users can apply for a card on a platform designated by the financial system. When using the card, users can also apply for the generation of account information (such as card number, which can be used once or indefinitely), expiration date, and security code (Card Verification Value, CVV) on the same platform to enhance payment security.

[0027] Wallet server 20 can be a server of a financial system that issues cards to target users. The financial system can provide financial services to target user 10 through wallet server 20. For example, during the card application phase, wallet server 20 can issue a card to target user 10 upon request, including but not limited to debit cards, credit cards, and cards combining debit and credit types. As another example, during the phase where target user 10 pays for a related order using the card, the order payment result (also known as payment authorization result) can be determined based on the order payment request and the credit service provided by credit server 30, and the order payment result can be returned.

[0028] In some embodiments, the financial system may include, but is not limited to, new financial institutions, payment service providers, and aggregation service providers that aggregate multiple financial institutions or multiple payment service providers. New financial systems include, for example, e-wallets, but this specification does not limit them.

[0029] Credit and debit are two ways of recording the flow of funds. A debit typically indicates an increase in assets or expenses, or a decrease in liabilities or owner's equity. A credit typically indicates a decrease in assets or expenses, or an increase in liabilities or owner's equity.

[0030] Debit cards: These can be understood as cards with debit functionality, referred to as debit cards in this article. They include accounts with a debit type (hereinafter referred to as debit accounts). Debit accounts allow funds to be deposited in advance, and the actual payment is deducted from the balance of the debit account. They can record the current asset status of the debit account in real time. The key feature is that payments depend on the actual funds in the account and there is no overdraft function.

[0031] Credit cards: These can be understood as cards with credit functionality, referred to as credit cards in this article. They include accounts with a credit type (hereinafter referred to as credit accounts). Credit accounts have a credit limit (also called a credit line) provided by financial institutions (such as credit systems). The credit limit can be used as working capital, and the funds usually need to be repaid after a certain period of time (i.e., repayment).

[0032] Cards that combine debit and credit functions: These can be understood as cards that have both debit and credit functions, referred to as debit cards in this article. They include at least one debit account and at least one credit account.

[0033] When target user 10 applies for a credit card or debit card, the financial system can cooperate with the credit system to provide a credit limit for the credit account in the credit card or debit card. During the payment process of the credit card or debit card, the wallet server 20 of the financial system can interact with the credit server 30 of the credit system to realize the credit function of the credit account.

[0034] Credit server 30 can be a server for a credit system. The credit system can provide credit services to target user 10 through credit server 30. Credit services may include, but are not limited to: credit assessment, credit limit, and fund allocation (such as credit limit freezing and loan disbursement). Credit limit refers to the financial activity in which the credit system, based on the target user's creditworthiness and repayment ability, approves a credit limit that can be used within a certain period, allowing the target user to engage in credit activities such as loans and overdrafts within the credit limit. Credit server 30 can provide different credit services at different stages. For example, during the card application stage, credit server 30 provides credit assessment and credit limit services upon request from wallet server 20. During the card payment stage, credit server 30 provides credit limit freezing and loan disbursement services upon request from wallet server 20. Specific details will be described in detail in the payment methods section below and will not be repeated here.

[0035] In some embodiments, the credit system may include, but is not limited to, traditional financial institutions, as well as new types of financial institutions that can provide credit services. Examples include banks, payment service providers, and aggregation service providers that aggregate multiple financial institutions or multiple payment service providers. This specification does not impose any limitations.

[0036] Merchant system 40 is the system for target user 10 to conduct order transactions. Target user 10 can bind a card applied for in the financial system to merchant system 40, and thus choose the card to pay for related orders in merchant system 40. Target user 10 can also choose the card for payment without binding it, and this specification does not restrict this. Merchant system 40 can interact with acquiring system 50, sending order payment requests during the payment authorization stage, receiving order payment results, and displaying order payment results to target user 10, etc.

[0037] In some embodiments, the merchant system 40 may be an online e-commerce platform for a single merchant or an online e-commerce platform that integrates multiple merchants; this specification does not impose any restrictions on this.

[0038] The acquiring system 50 refers to the platform or institution that has signed an agreement with the merchant and is responsible for processing the merchant's payment requests. The acquiring system 50 can also receive the order payment results of relevant orders from the wallet server 20 and forward the order payment results of relevant orders to the merchant system 40.

[0039] In some embodiments, the acquiring system 50 may be, for example, a financial system of an issuing bank, a payment service provider such as an e-wallet, or an aggregation service provider that aggregates multiple financial institutions or multiple payment service providers.

[0040] The acquiring system 50 and the wallet server 20 can communicate directly, without using an intermediary system for information forwarding. Alternatively, an intermediary system can exist between the acquiring system 50 and the wallet server 20 to forward information; this specification does not impose any restrictions on this. Intermediary systems include, but are not limited to, card pool systems, payment agent systems, etc. Similarly, Figure 1 Other nodes that interact with each other can communicate directly, or there may be intermediate nodes that forward information; this specification does not impose any restrictions on this.

[0041] It should be noted that, Figure 1 The payment requests and payment results in the examples are information exchanged between various nodes (such as wallet server 20, merchant system 40, and acquiring system 50) during the payment authorization phase. Figure 1 The information on the interactions between these nodes after the payment enters other stages (such as the authorization revocation stage, payment request stage, refund stage, or chargeback stage) is not shown. The specific interaction information of other stages will be introduced in detail later when describing the payment methods, and will not be repeated here.

[0042] In some embodiments, the wallet server 20 can cooperate with the credit server 30 to execute the payment method P300 provided in the embodiments of this specification. The wallet server 20 and the credit server 30 can store data and instructions for implementing the payment method P300, and can execute or be used to execute said data and instructions. In some embodiments, the wallet server 20 and the credit server 30 may include hardware devices with data processing capabilities and the necessary programs required to drive the hardware devices.

[0043] The specific technical details of the P300 payment method will be described later and will not be repeated here.

[0044] Figure 2 A hardware structure diagram of a computing system 200 provided according to an embodiment of this specification is shown. The computing system 200 may be... Figure 1 Wallet server 20 in the middle can also be Figure 1 Credit server 30 in the middle.

[0045] like Figure 2 As shown, the computing system 200 may include at least one storage medium 230 and at least one processor 220. In some embodiments, the computing system 200 may also include a communication port 250 and an internal communication bus 210. Furthermore, the computing system 200 may also include I / O components 260.

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

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

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

[0049] In some embodiments, the network can be any type of wired or wireless network, or a combination thereof. For example, the network may include a cable network, a wired network, a fiber optic network, a telecommunications 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 ZigBee™ short-range wireless network, a near field communication (NFC) network, or a similar network.

[0050] In some embodiments, the network may include one or more network access points. For example, the network may include wired or wireless network access points, such as base stations or internet switching points. Through these access points, one or more components of various devices corresponding to the computing system 200 can connect to the network to exchange data or information.

[0051] Storage medium 230 may include a data storage device. The data storage device may be a non-transitory storage medium or a temporary storage medium. For example, the data storage device may include one or more of a disk 232, a read-only storage medium (ROM) 234, or a random access storage medium (RAM) 236. Storage medium 230 also includes at least one instruction set stored in the data storage device. The instruction set may include computer program code, which may include programs, routines, objects, components, data structures, procedures, modules, etc., that execute the payment methods provided in this specification.

[0052] Processor 220 can be communicatively connected to storage medium 230. Processor 220 is used to execute at least one of the above-described instruction sets. When computing system 200 is running, processor 220 reads the at least one instruction set and executes the payment method provided in this specification according to the instructions of the at least one instruction set.

[0053] Processor 220 may be in the form of one or more processors. In some embodiments, processor 220 may include one or more hardware processors, such as microcontrollers, microprocessors, reduced instruction set computers (RISC), application-specific integrated circuits (ASICs), application-specific instruction set processors (ASIPs), central processing units (CPUs), graphics processing units (GPUs), physical processing units (PPUs), microcontroller units, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), advanced RISC machines (ARMs), programmable logic devices (PLDs), any circuit or processor capable of performing one or more functions, or any combination thereof.

[0054] For the purpose of illustrating the point only, in the appendix Figure 2 Only one processor 220 is shown in the computing system 200. However, it should be noted that the computing system 200 may also include multiple processors. Therefore, the operation and / or method steps disclosed in this specification may be executed by one processor as described in this specification, or they may be executed jointly by multiple processors. For example, if processor 220 of computing system 200 in this specification executes steps A and B, it should be understood that steps A and B may also be executed jointly or separately by two different processors 220 (e.g., the first processor executes step A, the second processor executes step B, or the first and second processors jointly execute steps A and B).

[0055] Figure 3 A flowchart of a payment method P300 according to an embodiment of this specification is shown. A wallet server and a credit server can cooperate to execute payment method P300.

[0056] like Figure 3 As shown, payment method P300 includes the following steps.

[0057] S310: The wallet server receives a payment request, which is used to request payment for the target order using the target card.

[0058] Target users can apply for one or more cards from the financial system to which the wallet server belongs. Each card can support payments in at least one currency. For example, a target user can open multiple stores, using one card for each store, thereby enabling independent fund management (payments, receipts, etc.) for each store.

[0059] For example, such as Figure 4 As shown, the target user applied for Card 1 and Card 2 in the financial system to which the wallet server belongs. Each card can include accounts for one or more currencies, thereby supporting payments in multiple currencies and meeting the user's cross-border payment needs. Card 1 and Card 2 both include debit account D1, debit account D2, debit account D3, credit account C1, credit account C2, and credit account C3.

[0060] See also Figure 4 Debit account D1 and credit account C1 both correspond to currency 1, debit account D2 and credit account C2 both correspond to currency 2, and debit account D3 and credit account C3 both correspond to currency 3. This means the wallet server can separate funds for different currencies and different account types at the account level. Taking debit account D1 and credit account C1 as an example, both debit account D1 and credit account C1 correspond to currency 1. The balance in debit account D1 is the amount of currency 1, and the amount in credit account C1 is the amount of currency 1. Other accounts follow the same principle.

[0061] Understandable, although Figure 4 In this example, Card 1 and Card 2 share the same set of debit accounts and the same set of credit accounts, but this specification is not limited to this. For example, Card 1 and Card 2 could also correspond to different sets of debit accounts and credit accounts, respectively.

[0062] All credit accounts under one card applied for by the target user can share the credit limit (the credit limit granted to the target user by the credit system), or all credit accounts under multiple cards applied for by the target user can share the credit limit; this instruction manual does not impose any restrictions on this.

[0063] like Figure 4 The account system shown allows a single card applied for by a target user to be linked to both a debit and a credit account, eliminating the need to apply for multiple cards with only one type of account (debit or credit) and avoiding complex fund management issues. This card system, which links multiple account types, can meet the personalized payment needs of different users, as well as the changing payment needs of the same user at different stages. It has a wide range of applications, ensuring users can flexibly allocate funds while also improving payment success rates.

[0064] When a target user pays for a target order in the merchant system, they can select the target card from at least one applied card. The target card can be a credit card or a debit card; this manual does not impose any restrictions. After the target user selects the target card to pay for the target order in the merchant system, the merchant system generates a payment request for the target order, requesting payment using the target card. The payment request includes, but is not limited to, the following information: target card, order amount, currency to be paid, order information for the target order (e.g., product, merchant to which the product belongs), and receiving account.

[0065] Once the payment request for the target order is generated by the merchant system, it can be transmitted through one or more intermediary systems to reach the wallet server. For example, when multiple intermediary systems exist, according to their position in the payment chain, these multiple intermediary systems can be, in sequence, an acquiring system, a card pool system, and a payment agent system.

[0066] S312: The wallet server responds to the payment request by identifying the target user holding the target card and then identifies the target credit account to be paid from the accounts associated with the target card.

[0067] The wallet server can determine the target card for payment from one or more cards applied for by the target user by parsing the payment request of the target order. It can also determine the target credit account for payment from multiple accounts in the target card by parsing the order amount or other preset information.

[0068] In some embodiments, the accounts associated with the target card include at least one debit account and at least one credit account. If at least one debit account does not support payment for the target order, or if the payment rules specified by the target user indicate that the credit account is preferred for payment, the wallet server determines the target credit account from among the at least one credit account.

[0069] For example, if the balance of all debit accounts in the target card is insufficient to pay for the target order, the wallet server can determine to use a credit account for payment. Alternatively, if the target user has pre-set payment rules, such as prioritizing credit accounts or authorizing only credit account payments, the wallet server can also determine to use a credit account for payment. When there are multiple credit accounts in the target card, the wallet server can determine the credit account corresponding to the currency corresponding to the order amount of the target order as the target credit account. Alternatively, the wallet server can also determine the credit account corresponding to the clearing currency negotiated with the card pool system as the target credit account; this specification does not limit this.

[0070] In this embodiment, users can preset payment rules that meet their current payment needs based on their own financial situation, avoiding subsequent problems such as payment failure when using a debit account due to insufficient funds, thus solving the problem of cash flow difficulties.

[0071] S314: The wallet server sends a credit limit freeze request to the credit server, requesting the credit server to freeze a first limit in the target user's credit limit, the first limit being related to the order amount of the target order; correspondingly, the credit server receives the credit limit freeze request.

[0072] Before sending a request to freeze the amount, the wallet server can also determine the amount to be frozen.

[0073] In some embodiments, the wallet server determines a first amount to be frozen based on the currency type corresponding to the target credit account and the order amount of the target order, and sends a limit freeze request to the credit server that includes at least the first amount.

[0074] For example, if the currency type corresponding to the target credit account is the same as the currency type corresponding to the order amount, the wallet server can determine the order amount as the first credit limit. If the currency type corresponding to the target credit account (i.e., the deduction currency) and the currency type corresponding to the order amount (i.e., the settlement currency) are different, the wallet server needs to determine the first credit limit based on the exchange rate between the order amount, the currency corresponding to the order amount, and the currency corresponding to the target credit account. In addition to the first credit limit, the credit limit freeze request can also include other information, such as the order information of the target order. Therefore, after receiving the credit limit freeze request, the credit server can perform risk control on the target order based on the order information to determine whether to freeze the first credit limit within the target user's credit limit. Alternatively, the wallet server can also perform risk control on the target order based on the order information, determine the first credit limit to be frozen if the risk control is successful, and send a credit limit freeze request.

[0075] In the above embodiments, the target card can be associated with multiple credit accounts corresponding to different currencies to meet the cross-border payment needs of the target user. When the settlement currency and the deduction currency are different, the wallet server can also automatically perform currency conversion without requiring any action from the target user, thus improving the user's cross-border payment experience. Furthermore, the method by which the wallet server determines the initial amount to be frozen also reduces the operational complexity of the credit server.

[0076] S316: The credit server freezes the first credit limit within the target user's credit limit based on the credit limit freeze request.

[0077] The credit server can perform risk control on target orders based on order information and other data. If the risk control is successful, the first credit limit can be frozen based on the target user's credit limit usage.

[0078] For example, if the target user's current credit limit (the limit available to the target user within this period) is greater than or equal to the first limit, the credit server can freeze the first limit from the target user's current credit limit and generate a limit freeze result indicating that the first limit has been frozen. If the risk control of the target order fails, or the target user's current credit limit is less than the first limit, the credit server does not need to freeze the first limit and generates a limit freeze result indicating that the limit is insufficient or the risk control has failed.

[0079] S318: The credit server sends the credit limit freeze result to the wallet server, and the wallet server receives the credit limit freeze result accordingly.

[0080] After receiving the credit limit freeze result, the wallet server can determine the payment result of the target order based on the representation content of the credit limit freeze result.

[0081] For example, if the credit limit freeze result indicates that the first credit limit has been frozen, the wallet server determines that the payment result for the target order is payment authorization approved. If the credit limit freeze result indicates that the credit limit is insufficient or risk control fails, the wallet server determines that the payment result for the target order is payment authorization failed.

[0082] S320: The wallet server sends the payment result of the target order, and the corresponding merchant system receives the payment result of the target order.

[0083] The payment result for the target order is forwarded through one or more intermediary systems before finally reaching the merchant's system. Upon receiving the payment result, if the merchant system confirms successful payment authorization, it can begin shipping the goods. If the payment result indicates unsuccessful authorization, it can inform the target user of the reason for the failure, such as insufficient credit limit or potential risks associated with the order.

[0084] S322: The wallet server receives the payment request corresponding to the target order.

[0085] Once a merchant system receives a payment result and the payment result indicates that the payment authorization has been approved, it can initiate a payment request. For example, the merchant system can periodically initiate payment requests, which may include the payment amounts for multiple orders (including the target order). The payment request for the target order can be forwarded sequentially through one or more intermediary systems to reach the wallet server.

[0086] S324: The wallet server sends a loan request to the credit server, requesting the credit server to release the first funds to the target credit account; in response, the credit server receives the loan request.

[0087] After receiving a payment request, the wallet server can associate it with the target order that was authorized during the authorization phase and determine the authorized amount for the target order (i.e., the initial limit). If the requested amount in the payment request is unreasonable, such as exceeding the initial limit, the wallet server can return a payment request result indicating a failure to the merchant system. If the requested amount in the payment request is less than or equal to the initial limit, the wallet server can send a loan disbursement request to the credit server. In this case, the initial funds requested in the loan disbursement request can be the amount specified in the payment request.

[0088] S326: The credit server disburses the first fund to the target credit account based on the loan request.

[0089] In some embodiments, the wallet server maintains a first debit account corresponding to the owner of the credit server (e.g., a credit system). The first funds are disbursed to the target credit account through the first debit account.

[0090] For example, see [link to previous article] Figure 4 The wallet server maintains three debit accounts for the credit system: debit account X1 (corresponding to currency 1), debit account X2 (corresponding to currency 2), and debit account X3 (corresponding to currency 3). Debit account X1 can lend to credit account C1. Debit account X2 can lend to credit account C2. Debit account X3 can lend to credit account C3. When the target credit account's currency type is currency 1, the first funds are disbursed to the target credit account through debit account X1 (an example of the first debit account).

[0091] The wallet server maintains debit accounts for the credit system, thus simplifying the fund transfer process within the wallet system during the request phase. This process doesn't involve other systems, reducing the complexity of disbursing funds to the target credit account and ensuring timely fund disbursement during the request process. If the primary debit account is outside the wallet system, the timeliness of fund disbursement during the request process cannot be guaranteed. Request process timeouts may lead to order cancellations and other anomalies, impacting the user's payment experience.

[0092] There are several ways for a credit server to issue initial funds. Two of them are illustrated below, but this manual does not impose any restrictions on them.

[0093] Method 1

[0094] The credit server disburses initial funds from a first debit account to a target credit account based on a loan request. The credit server then sends a first loan disbursement confirmation to the wallet server, which in turn receives the confirmation from the credit server. This confirmation signifies that the credit server has successfully disbursed the initial funds from the first debit account to the target credit account. This method of having the credit server execute the fund disbursement operation ensures the security of funds within the credit system.

[0095] For example, when the credit server performs the operation of disbursing the first fund from the first debit account to the target credit account, it can send a fund disbursement instruction to the wallet server, instructing the wallet server to disburse the first fund from the first debit account to the target credit account. After the wallet server successfully disburses the first fund, it can send a fund disbursement result to the credit server, informing the credit server that the operation of disbursing the first fund from the first debit account to the target credit account has been performed. Thus, the credit server sends a first loan disbursement confirmation to the wallet server.

[0096] Method 2

[0097] The credit server sends a second loan confirmation to the wallet server, and correspondingly, the wallet server receives the second loan confirmation from the credit server. This second loan confirmation signifies that the credit server agrees to disburse the first fund to the target credit account through the first debit account. Based on the second loan confirmation, the wallet server executes the transfer of the first fund from the first debit account to the target credit account. After completing the transfer, the wallet server can also send a successful transfer notification to the credit server.

[0098] Once the credit server approves the loan, the wallet server executes the fund disbursement. This approach reduces the operational complexity of the credit server, shortens the loan disbursement time, and speeds up the loan application process.

[0099] S328: The wallet server uses the initial funds to execute the payment process for the target order.

[0100] In some embodiments, in response to a first loan confirmation, the wallet server uses the first funds to execute the payment process for the target order.

[0101] In some embodiments, in response to a second loan confirmation, after the wallet server completes the transfer operation of the first funds based on the second loan confirmation, it uses the first funds to execute the payment process of the target order.

[0102] For example, the process of a wallet server executing a payment for a target order using the first fund includes: the wallet server determining the payment request result for the target order. For instance, if the wallet server determines that the first fund in the target credit account is sufficient to pay for the target order, it determines that the payment request result for the target order is successful. After determining the payment request result, the wallet server sends the payment request result to the merchant system through one or more intermediary systems.

[0103] In some embodiments, after the wallet server executes the payment process for the target order using the first funds, it can also generate a debt statement corresponding to the target order in the target credit account, so that the target user can make active repayments based on the debt statement and enjoy the interest-free period.

[0104] Debt statements can track order and spending details, helping target users manage their expenses and improve their payment experience. In case of fraud or disputes, debt statements can also serve as evidence for rights protection, enhancing the security of payments through credit limits. Furthermore, the wallet server can separate bills for target card payments at the account level, managing debit and credit account bills independently to ensure dedicated use of funds. That is, the credit limit in the credit account can be used exclusively for the target card's actual spending, reducing the risk of loans issued by the credit system being misused by users.

[0105] In some embodiments, the account associated with the target card may also include a second debit account, such as a debit account in the same currency as the target credit account. After S328 is completed, the wallet server and the credit server can also cooperate to execute the repayment process. See also... Figure 3 The repayment process includes the following steps:

[0106] S330: In response to the detection that the preset repayment conditions have been triggered, the wallet server sends a repayment request to the credit server to request the repayment of the second funds to the first debit account through the second debit account. Correspondingly, the credit server receives the repayment request.

[0107] Before executing S330, the wallet server can also determine the second fund to be repaid, so that the repayment request can include information about the second fund. The second fund can be the same as the first fund or different from the first fund (for example, in the case where some items in the target order are refunded), and this specification does not impose any restrictions on this.

[0108] S332: The credit server determines the repayment result based on the repayment request and sends the repayment result to the wallet server, which in turn receives the repayment result.

[0109] S334: The wallet server performs relevant operations based on the repayment results.

[0110] There are multiple ways to execute S332. Two of them are illustrated below. This manual does not limit the scope of the execution.

[0111] Method 1

[0112] The credit server transfers second funds from the second debit account to the first debit account based on a repayment request and sends a first repayment confirmation (an example of a repayment result) to the wallet server. The wallet server then receives this first repayment confirmation. This confirmation signifies that the credit server has successfully transferred the second funds from the second debit account to the first debit account. The credit server's execution of this fund transfer operation ensures the security of fund flows within the credit system's debit accounts.

[0113] For example, the credit server can send a fund transfer request to the wallet server, requesting the wallet server to transfer a second set of funds from a second debit account to a first debit account. After the wallet server successfully completes the transfer, it can send a fund transfer result to the credit server, informing it that the operation of transferring the second set of funds from the second debit account to the first debit account has been executed. Upon receiving the fund transfer result, the credit server can send a first repayment confirmation to the wallet server.

[0114] The operations performed by the wallet server after receiving the repayment result are related to the repayment conditions that were triggered. These will be described in detail later when discussing the triggering of repayment conditions, and will not be repeated here.

[0115] Method 2

[0116] The credit server sends a second repayment confirmation (an example of a repayment result) to the wallet server, which in turn receives the second repayment confirmation. This second repayment confirmation indicates that the credit server has agreed to repay the second fund to the first debit account through the second debit account. Based on this second repayment confirmation, the wallet server executes the transfer of the second fund from the second debit account to the first debit account. After completing the transfer, the wallet server can also send a successful transfer notification to the credit server.

[0117] Once the credit server approves the repayment, the wallet server executes the fund transfer operation. This reduces the operational complexity of the credit server, shortens the repayment time, and speeds up the repayment process.

[0118] In Method 2, after receiving the repayment result, in addition to performing the second fund transfer operation and sending feedback information to the credit server, the wallet server can also perform other related operations. These related operations are similar to those performed by the wallet server in Method 1. They will be described in detail later when discussing the triggering of repayment conditions, and will not be repeated here.

[0119] There are several scenarios in which the preset repayment conditions can be triggered. The following are some examples, but this manual does not impose any restrictions on them.

[0120] Scenario 1: Refund

[0121] The target user executes a refund request for the target order in the merchant system, which then generates a refund request for the target order and sends it to the wallet server through one or more intermediary systems. Upon receiving the refund request for the target order, the wallet server can execute S330.

[0122] For example, before executing S330, the wallet server can determine the second fund to be refunded based on the refund request. For instance, the second fund might be the refund amount specified in the refund request. Additionally, before executing S330, the wallet server can also determine whether the payment account of the target order corresponding to the refund request is a credit account. If the payment account of the target order is a credit account, then S330 is executed. If the payment account of the target order is a debit account, then after the second fund is refunded to the second debit account, the wallet server does not need to execute S330.

[0123] If the payment account for the target order is a credit account, after the wallet server determines the repayment result, it can determine the refund result for the target order. This refund result can then be sent to the merchant system through one or more intermediary systems. The merchant system can then notify the target user of the refund result for the target order.

[0124] In scenario 1, when the target user initiates a refund, the wallet server can promptly repay the loan to the first debit account in the credit system, reducing the risk of the target user defaulting on the loan.

[0125] Scenario 2: Chargeback

[0126] After a target user sees their debt statement on their wallet client (the client of the financial system to which the wallet server belongs), they can initiate a chargeback request for the target order. The wallet client can then send this chargeback request to the wallet server. Upon receiving the chargeback request, the wallet server can collect chargeback voucher information from the target user and send a chargeback request containing this voucher information to the chargeback adjudication system (e.g., a card system). Upon receiving the chargeback request, the chargeback adjudication system can notify the merchant system of the chargeback and conduct a preliminary review and adjudication based on the chargeback voucher information. If it is determined that the target user's chargeback application is approved—meaning the target user should not pay the chargeback funds (i.e., the second fund) specified in the chargeback request—the chargeback adjudication system can send a chargeback result indicating approval to the wallet server and disburse the chargeback funds. Upon receiving the chargeback result indicating approval, the wallet server can execute S330. After determining the repayment result, the wallet server can display the chargeback application result and the cancellation status of the debt statement to the target user through the wallet client.

[0127] Additionally, before executing S330, the wallet server needs to determine whether the target order's payment account is a credit account. If the target order's payment account is a credit account, then S330 is executed. If the target order's payment account is a debit account, the chargeback funds are refunded to a second debit account, and the wallet server does not need to execute S330.

[0128] In scenario 2, if the target user initiates a chargeback request and the chargeback result indicates that the application has been approved, the wallet server can promptly repay the loan to the first debit account in the credit system, reducing the risk of the target user defaulting on the loan.

[0129] It should be noted that if the target order's payment account is a credit account, and after the chargeback funds are successfully refunded, the merchant system initiates an appeal and provides supplementary supporting documentation to the chargeback adjudication system, the chargeback adjudication system can then re-adjudicate based on the supplementary documentation. If the re-adjudication determines that the target user should pay the aforementioned chargeback funds, the chargeback adjudication system can send a re-adjudication result indicating that the chargeback failed to pass to the wallet server. The wallet server can then resend a request to the credit server for the release of the chargeback funds. The credit server then releases the chargeback funds to the target credit account through the first debit account. The specific process is similar to the first fund release process described earlier and will not be repeated here. Subsequently, the wallet server can return the chargeback funds from the target credit account to the chargeback adjudication system, which will then return the chargeback funds to the receiving account designated by the merchant system.

[0130] Scenario 3: Proactive repayment

[0131] The target user initiates a repayment request on the wallet client, which the wallet server receives and executes S330. The repayment request can be for the target order or for multiple orders that include the target order. After receiving the repayment result, the wallet server can either store the result or display it to the target user.

[0132] Scenario 4: Repayment deadline has arrived

[0133] Once the credit server determines that the repayment deadline has arrived, if the target user has not yet made a repayment, it can send a deduction request to the wallet server, triggering the wallet server to execute S330. Alternatively, after receiving the deduction request, the wallet server can determine the deduction amount specified in the request and execute the operation of transferring the deduction funds (i.e., the second fund) from the second debit account to the first debit account. After completing the transfer of deduction funds, the wallet server can also send a successful deduction feedback message to the credit server.

[0134] Similar to scenario 3, after receiving the repayment result, the wallet server can store the repayment result or display it to the target user.

[0135] By triggering the aforementioned repayment conditions, the wallet server can promptly repay the first debit account in the credit system (including repayments initiated by the target user or by the wallet server itself in cases of refunds, etc.). This facilitates the timely restoration of the target user's credit limit by the credit system, allowing the target user to continue spending based on the restored credit limit, meeting urgent or high-frequency payment needs, avoiding payment failures due to delayed credit limit updates caused by untimely repayments, and improving user payment satisfaction.

[0136] In some embodiments, after the second fund is repaid, the credit server can also update the target user's credit limit based on the repayment status.

[0137] For example, if all of a target user's debt accounts have been repaid, the credit server can restore the target user's credit limit to the maximum limit applied for by the target user during the historical period. If the target user's debt accounts have been partially repaid, the credit server can restore the amount that has been repaid. Alternatively, the credit server can also increase or decrease the target user's credit limit based on the timeliness of their repayments. For instance, when a target user repays on time, their credit limit can be increased to help them cope with large or urgent expenditures and provide a financial buffer when funds are temporarily insufficient. When a target user repays late or consistently delays repayments, their credit limit can be decreased to prevent excessive overdrafts and debt spiraling out of control, and also to reduce the risk of financial losses for the credit system.

[0138] Figure 3 This document describes the operations performed by various systems and servers when a merchant system initiates a payment request for a target order after the credit limit has been frozen. This manual also provides information on another scenario, such as... Figure 5 As shown, this illustrates the actions taken by various systems and servers when the wallet server does not receive a withdrawal request.

[0139] For S310 to S320, please refer to the relevant descriptions above; they will not be repeated here.

[0140] S322': The wallet server receives the cancellation request corresponding to the target order.

[0141] The wallet server can obtain the cancellation request corresponding to the target order in a variety of ways. The following are some examples, but this manual is not limited to these.

[0142] (1) After a target user cancels a target order in the merchant system, the merchant system can generate a cancellation request for the target order and send the cancellation request corresponding to the target order to the wallet server through one or more intermediary systems. The wallet server then receives the cancellation request.

[0143] (2) An intermediate system (e.g., acquiring system, card group system, or payment agent system) sets a timer for the target order. If the intermediate system has not received a payment request for the target order after the timer expires, the intermediate system generates a cancellation request for the target order. The intermediate system can send the cancellation request to the wallet server through other intermediate systems located downstream of the payment link, thereby the wallet server receives the cancellation request.

[0144] (3) The wallet server sets a timer for the target order. If the timer expires and no payment request is received for the target order, the wallet server generates a cancellation request for the target order.

[0145] S324': The wallet server sends a credit limit release request to the credit server, requesting the credit server to release a second credit limit from the first credit limit that has been frozen for the target user; correspondingly, the credit server receives the credit limit release request.

[0146] For example, if the cancellation request for the target order is received by the wallet server from an external source, the wallet server can also associate the target order with its own limit before sending a limit release request, and determine the limit to be released based on the limit freeze status of the target order. If the deduction currency (the currency corresponding to the target credit account) and the settlement currency are different, the wallet server will also involve a currency exchange operation when determining the second limit. The first limit can be the same as the second limit, or the first limit can be different from the second limit; this specification does not impose any restrictions on this.

[0147] S326': The credit server releases the second credit line from the first credit line.

[0148] For example, if the first credit limit and the second credit limit are the same, the credit server can release the entire first credit limit. If the second credit limit is less than the first credit limit, the credit server can release the second credit limit within the first credit limit (such as when a target user cancels part of the goods in a target order).

[0149] S328': The credit server sends the credit limit release result to the wallet server, and the wallet server receives the credit limit release result accordingly.

[0150] If the cancellation request corresponding to the target order is generated internally by the wallet server, the wallet server can store the credit limit release result after receiving it, and can also update the status of the target order, thus ending the authorization cancellation stage of the target order payment.

[0151] If the cancellation request corresponding to the target order is received by the wallet server from an external source, the wallet server also needs to execute S330', or execute S330' and S332'.

[0152] S330': The wallet server determines the cancellation result of the target order based on the credit limit release result.

[0153] If the cancellation request for the target order is generated from the target intermediary system, the wallet server needs to send the cancellation result of the target order to the target intermediary system.

[0154] If the cancellation request for the target order is generated from the merchant system, the wallet server needs to execute S332' to send the cancellation result of the target order to the merchant system.

[0155] pass Figure 5 The process shown allows the wallet server to request the credit server to release the corresponding credit limit if the target order is cancelled or payment is not requested within the time limit. This unfreezes the occupied credit limit, preventing it from being frozen ineffectively. The released credit limit can then be used to pay for other orders of the target user, avoiding payment failures for other orders due to invalid credit limit freezing.

[0156] It should be noted that, Figure 3 or Figure 5In the example flowchart, for certain information that needs to be relayed through an intermediate system (such as payment requests, payment results, payment requests, payment results, cancellation requests, cancellation results, etc.), the intermediate system may either pass it through without processing or perform some processing operations before continuing transmission; this specification does not impose any restrictions on this. Furthermore, the intermediate system can also change the names of relevant information during the forwarding process. For example, the acquiring system can process the payment request for a target order received from the merchant system and change it to an authorization request for the target order before continuing transmission to the downstream of the payment chain (card set, wallet server, etc.). Other modification scenarios are similar and will not be illustrated further.

[0157] In some embodiments, the wallet server and credit server also need to execute a credit limit application process before starting to execute payment method P300. For example... Figure 6 As shown, the credit limit application process includes the following steps:

[0158] S301: The target user initiates a credit limit application request for the target card in the wallet client, and the wallet server receives the credit limit application request.

[0159] For example, a target user can initiate a credit limit application request for the target card on the operation page of the wallet client. During the process of filling in the application information, they can upload credit certificate information (such as identity certificate, qualification certificate, transaction certificate, etc.).

[0160] S303: In response to a credit limit application request, the wallet server sends a credit granting request to the credit server, which in turn receives the credit granting request. The credit granting request may include the target user's credit credentials information.

[0161] S305: The credit server determines the credit granting result based on the credit granting request.

[0162] For example, a credit server can conduct credit approval based on the target user's credit credentials, i.e., perform a credit assessment on the target user, thereby determining the credit approval result. If the credit approval is successful, the credit approval result represents the credit limit. If the credit approval is unsuccessful, the credit approval result represents not being approved, and may also represent the reason for the unsuccessful approval.

[0163] S307: The credit server sends the credit granting result to the wallet server, and the wallet server receives the credit granting result accordingly.

[0164] S309: The wallet server performs relevant operations based on the credit granting result and returns the credit limit application result to the wallet client.

[0165] For example, if the credit granting result indicates that the target user's credit limit application is unsuccessful, the wallet server can display the unsuccessful credit limit application result to the target user through the wallet client, and can also display the reason for the unsuccessful application to the target user.

[0166] For example, if the credit granting result indicates that the target user's credit limit application has been approved and the credit limit granted to the target user is the target limit, the wallet server can display the target limit to the target user through the wallet client. When the target card is the first card applied for by the target user, the wallet server can also open at least one credit account on the target card, including the target credit account. The at least one credit account shares the target limit. When the target card is not the first card applied for by the target user, if the target limit is higher than the credit limit previously applied for by the target user, the wallet server can also update the target user's credit limit to the target limit, and can also associate the target card with at least one credit account corresponding to other cards.

[0167] It is understood that the credit limit mentioned in this manual may be a limit jointly provided by the wallet server and the credit server for the target user in card spending scenarios. This credit limit is only supported for use by the target user in card payment scenarios, ensuring a close integration of credit limit usage with the payment scenario. The wallet server uses the loan funds from the credit system on demand according to the request, thereby achieving the goal of dedicated use of funds. Of course, the target user can also apply for other credit limits for other scenarios; the application process is similar and will not be elaborated further.

[0168] Through the credit limit application process described above, the credit server can provide users with appropriate credit limits based on their credentials, avoiding excessive limits that lead to overspending or insufficient limits that fail to meet their actual needs. This ensures precise matching of personalized payment requirements among different users. The credit server can also screen for high-quality users through credit approval, reducing the risk of bad debts and safeguarding the funds in the credit system.

[0169] In summary, the payment method, wallet server, and credit server provided in this manual enable the new financial system to collaborate with the credit system to provide credit limits for cards issued by the new financial system. This allows users to make payments using these cards. During the disbursement phase, the credit system can release funds to the credit account on the target user's card to meet the payment needs of users with limited funds, expand the user base of cards issued by the new financial system, and improve the success rate of user payments.

[0170] This specification, in another aspect, provides a computer-readable non-transitory storage medium storing at least one set of executable instructions for execution. When the executable instructions are executed by a processor, they instruct the processor to perform the steps of method P300 described herein. In some possible embodiments, various aspects of this specification may also be implemented as a program product comprising program code. When the program product is run on computing system 200, the program code causes computing system 200 to perform the steps of method P300 described herein. The program product for implementing the above method may employ a portable compact disc read-only memory (CD-ROM) containing program code and may run on computing system 200. However, the program product of this specification is not limited thereto. In this specification, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system. The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can send, propagate, or transmit programs for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof. Program code for performing the operations described herein can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on computing system 200, partially on computing system 200, as a standalone software package, partially on computing system 200 and partially on a remote computing device, or entirely on a remote computing device.

[0171] The term "and / or" in the embodiments of this specification describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0172] The terms “first”, “second”, etc., used in this specification are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence.

[0173] Unless otherwise stated, the term "multiple" in this specification shall be understood as two or more.

[0174] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0175] In summary, after reading this detailed disclosure, those skilled in the art will understand that the foregoing detailed disclosure is presented by way of example only and is not restrictive. Although not explicitly stated herein, those skilled in the art will understand that this specification requires various reasonable changes, improvements, and modifications to the embodiments. These changes, improvements, and modifications are intended to be made by this specification and are within the spirit and scope of the exemplary embodiments described herein.

[0176] Furthermore, certain terms in this specification have been used to describe embodiments of this specification. For example, "an embodiment," "an embodiment," and / or "some embodiments" mean that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment of this specification. Therefore, it is to be emphasized and understood that two or more references to "an embodiment" or "an embodiment" or "alternative embodiment" in various parts of this specification do not necessarily refer to the same embodiment. Moreover, specific features, structures, or characteristics may be suitably combined in one or more embodiments of this specification.

[0177] It should be understood that in the foregoing description of the embodiments in this specification, various features are combined in a single embodiment, drawing, or description for the purpose of simplifying the description and aiding in the understanding of a feature. However, this does not mean that the combination of these features is necessary, and those skilled in the art may readily identify some of the devices as separate embodiments when reading this specification. That is, the embodiments in this specification can also be understood as an integration of multiple secondary embodiments. It is also valid when each secondary embodiment contains fewer than all the features of a single foregoing disclosed embodiment.

[0178] Every patent, patent application, publication of a patent application, and other material, such as articles, books, specifications, publications, documents, and literature (excluding any related historical examination documents), cited in this disclosure is incorporated herein for all purposes, including, for example, in the specification and claims of this disclosure. However, in the event of any inconsistency or conflict between the descriptions, definitions, and / or terms used in the foregoing and those used in this disclosure, the descriptions, definitions, and / or terms used in this disclosure shall prevail.

[0179] Finally, it should be understood that the embodiments disclosed herein are illustrative of the principles of the embodiments described in this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are merely examples and not limitations. Those skilled in the art can implement the applications described in this specification using alternative configurations based on the embodiments in this specification. Therefore, the embodiments in this specification are not limited to the embodiments precisely described in the applications.

Claims

1. A payment method applied to a wallet server, the method comprising: In response to receiving a payment request to use the target card to pay for the target order, the target user holding the target card is identified, and the target credit account to be paid is identified in the account associated with the target card; Send a credit limit freeze request to the credit server to request the credit server to freeze a first credit limit in the target user's credit limit, the first credit limit being related to the order amount of the target order; In response to receiving a payment request corresponding to the target order, a loan disbursement request is sent to the credit server, requesting the credit server to release first funds to the target credit account; and The payment process for the target order is executed using the first funds.

2. The method according to claim 1, wherein, The wallet server maintains the first debit account corresponding to the owner of the credit server. The first fund was disbursed from the first debit account to the target credit account.

3. The method according to claim 2, wherein, After sending the loan request to the credit server, the method further includes: Receive a first loan confirmation from the credit server, the first loan confirmation indicating that the credit server has executed the operation of disbursing the first funds from the first debit account to the target credit account; The payment process for executing the target order using the first funds includes: In response to the first loan confirmation, the payment process for the target order is executed using the first funds.

4. The method according to claim 2, wherein, After sending the loan request to the credit server, the method further includes: Receive a second loan confirmation from the credit server, the second loan confirmation indicating that the credit server agrees to disburse the first funds to the target credit account through the first debit account; and Based on the second loan confirmation, the operation of transferring the first funds from the first debit account to the target credit account is executed.

5. The method according to claim 2, wherein, The target card is associated with a second debit account. After the payment process for the target order is executed using the first funds, the method further includes: In response to the detection that preset repayment conditions have been triggered, a repayment request is sent to the credit server to request the repayment of second funds to the first debit account through the second debit account.

6. The method according to claim 5, wherein, After sending the repayment request to the credit server, the method further includes: The credit server receives a first repayment confirmation, which indicates that the credit server has executed the operation of transferring the second funds from the second debit account to the first debit account.

7. The method according to claim 5, wherein, After sending the repayment request to the credit server, the method further includes: Receive a second repayment confirmation from the credit server, the second repayment confirmation indicating that the credit server has agreed to repay the second funds to the first debit account through the second debit account; and Based on the second repayment confirmation, the operation of transferring the second funds from the second debit account to the first debit account is executed.

8. The method according to claim 5, wherein, The preset repayment conditions are triggered, including at least one of the following: Received a refund request corresponding to the target order; Received a chargeback request from the target user for the target order; Received an active repayment request initiated by the target user; or The repayment deadline has arrived.

9. The method according to claim 1, wherein, The method further includes: Upon receiving a credit limit application initiated by the target user for the target card, a credit granting request is sent to the credit server, the credit granting request including the target user's credit certificate information; Receive credit granting results from the credit server; and When the credit granting result indicates that the credit limit granted to the target user is the target limit, at least one credit account is opened in the target card, and the at least one credit account shares the target limit, and the at least one credit account includes the target credit account.

10. The method according to claim 1, wherein, After sending a credit limit freeze request to the credit server, the method further includes: Upon receiving a cancellation request corresponding to the target order, a credit limit release request is sent to the credit server, requesting the credit server to release a second credit limit from the first credit limit that has been frozen for the target user; and Receive the credit limit release result from the credit server.

11. The method according to claim 1, wherein, The accounts associated with the target card include at least one debit account and at least one credit account. The target credit account to be paid is identified from the accounts associated with the target card, including: If the at least one debit account does not support payment for the target order, or if the payment rules specified by the target user indicate that the credit account is preferred for payment, the target credit account shall be identified from the at least one credit account.

12. The method according to claim 11, wherein, The at least one credit account corresponds to a different currency type, and sending a credit limit freeze request to the credit server includes: Based on the currency type corresponding to the target credit account and the order amount of the target order, the first amount to be frozen is determined; and Send a credit freeze request to the credit server, which includes at least the first credit limit.

13. The method according to claim 1, wherein, After using the first funds to execute the payment process for the target order, the method further includes: Generate a liability statement corresponding to the target order in the target credit account.

14. A payment method applied to a credit server, the method comprising: Receive a credit limit freeze request from the wallet server, wherein the credit limit freeze request is sent by the wallet server when it receives a payment request to use the target card to pay for the target order, and the account to be paid is the target credit account associated with the target card; Based on the credit limit freeze request, a first credit limit is frozen in the credit limit of the target user, the target user being the user holding the target card, and the first credit limit is related to the order amount of the target order; Receive a loan request from the wallet server; and Based on the loan request, first funds are disbursed to the target credit account so that the wallet server can use the first funds to execute the payment process for the target order.

15. The method according to claim 14, wherein, The wallet server maintains the first debit account corresponding to the owner of the credit server. The first fund was disbursed from the first debit account to the target credit account.

16. The method according to claim 15, wherein, The step of disbursing the first funds to the target credit account based on the loan request includes: Based on the loan request, the first funds are disbursed from the first debit account to the target credit account; and A first loan confirmation is sent to the wallet server, indicating that the credit server has executed the operation of disbursing the first funds from the first debit account to the target credit account.

17. The method according to claim 15, wherein, The step of disbursing the first funds to the target credit account based on the loan request includes: A second loan confirmation is sent to the wallet server, indicating that the credit server agrees to release the first funds to the target credit account through the first debit account, so that the wallet server can execute the transfer operation of the first funds.

18. The method according to claim 15, wherein, The target card is associated with a second debit account, and the method further includes: A repayment request is received from the wallet server, the repayment request being used to request the repayment of second funds to the first debit account through the second debit account.

19. The method according to claim 18, wherein, After receiving a repayment request from the wallet server, the method further includes: Based on the repayment request, the second funds are transferred from the second debit account to the first debit account; and A first repayment confirmation is sent to the wallet server, indicating that the credit server has executed the operation of transferring the second funds from the second debit account to the first debit account.

20. The method according to claim 18, wherein, After receiving a repayment request from the wallet server, the method further includes: A second repayment confirmation is sent to the wallet server, indicating that the credit server has agreed to repay the second funds to the first debit account through the second debit account, so that the wallet server can execute the transfer operation of the second funds.

21. The method according to claim 19 or 20, wherein, The method further includes: The credit limit of the target user is updated based on the repayment status.

22. The method according to claim 14, wherein, The method further includes: Receive a credit granting request from the wallet server, the credit granting request including the target user's credit credentials information; The credit granting result is determined based on the aforementioned credit certificate information; and The credit granting result is sent to the wallet server, and the credit granting result indicates that the credit limit granted to the target user is the target limit.

23. The method according to claim 14, wherein, The method further includes: Receive a credit limit release request from the wallet server, the credit limit release request being used to request the credit server to release a second credit limit from the first credit limit that has been frozen by the target user; Release the second quota from the first quota; and Send the credit limit release result to the wallet server.

24. A wallet server, comprising: At least one storage medium storing at least one instruction set; as well as At least one processor is communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and performs the method as described in any one of claims 1-13 according to the instructions of the at least one instruction set.

25. A credit server, comprising: At least one storage medium storing at least one instruction set; as well as At least one processor is communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and performs the method as described in any one of claims 14-23 according to the instructions of the at least one instruction set.

26. A computer-readable non-transitory storage medium, wherein, The computer-readable non-transitory storage medium stores at least one set of instructions, which, when executed by at least one processor, implement the method as described in any one of claims 1-23.

Images