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

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202511099841.7 (22) Application Date 2025.08.06 (71) Applicant Ant International Business (Shanghai) Co., Ltd. Address Room 1408, No. 447, Nanquan North Road, China (Shanghai) Pilot Free Trade Zone, Pudong New Area, Shanghai 200131, China (72) Inventors Ren Tingting, Song Weiwei, Xiao Peijian (74) Patent Agency Beijing Liuli Intellectual Property Agency (General Partnership) 16049 Patent Attorney Li Zhe (51) Int.Cl. G06Q 20 / 10 (2012.01) G06Q 20 / 36 (2012.01) G06Q 20 / 34 (2012.01) G06Q 40 / 03 (2023.01) (54) Invention Title: Payment Method, Wallet Server, Credit Server, and Storage Medium (57) Abstract: This specification provides a payment method, a wallet server, a credit server, and a storage medium. In the method, in response to receiving a payment request to use a target card to pay for a target order, the wallet server identifies the target user holding the target card and determines the target credit account to be paid from the accounts associated with the target card; the wallet server sends a credit limit freeze request to the credit server, which freezes a first credit limit within the target user's credit limit based on the credit limit freeze request; in response to receiving a payment request corresponding to the target order, the wallet server sends a loan disbursement request to the credit server, which disburses first funds to the target credit account based on the loan disbursement request, thereby enabling the wallet server to execute the payment process for the target order using the first funds. Claims 4 pages, Description 16 pages, Drawings 5 ​​pages, CN 120996797 A 2025.11.21 CN 1 20 99 67 97 A 1. A payment method applied to a wallet server, the method comprising: in response to receiving a payment request requesting payment for a target order using a target card, determining a target user holding the target card, and determining 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 using the first funds to execute the payment process of the target order. 2. The method according to claim 1, wherein the wallet server maintains a first debit account corresponding to the credit server's owner.The first funds are disbursed from the first debit account to the target credit account. 3. The method of claim 2, wherein after sending the loan request to the credit server, the method further includes: receiving 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 step of using the first funds to execute the payment process of the target order includes: in response to the first loan confirmation, executing the payment process of the target order using the first funds. 4. The method of claim 2, wherein after sending the loan request to the credit server, the method further includes: receiving a second loan confirmation from the credit server, the second loan confirmation indicating that the credit server agrees to disburse the first funds from the first debit account to the target credit account; and based on the second loan confirmation, executing the operation of transferring the first funds from the first debit account to the target credit account. 5. The method of claim 2, wherein the account associated with the target card further includes a second debit account, and after executing the payment process of the target order using the first funds, the method further includes: in response to detecting that a preset repayment condition has been triggered, sending a repayment request to the credit server to request repayment of second funds from the second debit account to the first debit account. 6. The method of claim 5, wherein after sending the repayment request to the credit server, the method further includes: receiving a first repayment confirmation from the credit server, the first repayment confirmation indicating that the credit server has performed the operation of transferring the second funds from the second debit account to the first debit account. 7. The method of claim 5, wherein after sending the repayment request to the credit server, the method further includes: receiving a second repayment confirmation from the credit server, the second repayment confirmation indicating that the credit server has agreed to repay the second funds from the second debit account to the first debit account; and based on the second repayment confirmation, performing the operation of transferring the second funds from the second debit account to the first debit account. 8. The method according to claim 5, wherein the preset repayment condition is triggered by at least one of the following: receiving a refund request corresponding to the target order; receiving a chargeback request from the target user for the target order; receiving an active repayment request initiated by the target user; or reaching the repayment deadline. 9. The method according to claim 1, wherein the method further comprises: upon receiving a credit limit application initiated by the target user for the target card, sending a request to the credit server.Sending a credit granting request, the credit granting request including the credit credentials information of the target user; receiving a credit granting result from the credit server; and, if the credit granting result indicates that the credit limit granted to the target user is the target limit, opening at least one credit account in the target card, the at least one credit account sharing the target limit, the at least one credit account including the target credit account. 10. The method according to claim 1, wherein, after sending a limit freeze request to the credit server, the method further includes: upon receiving a cancellation request corresponding to the target order, sending a limit release request to the credit server to request the credit server to release a second limit from the first limit that has been frozen for the target user; and receiving a limit release result from the credit server. 11. The method of claim 1, wherein the accounts associated with the target card include at least one debit account and at least one credit account, and determining the target credit account to be paid from the accounts associated with the target card includes: determining the target credit account from the at least one credit account when the at least one debit account does not support payment for the target order, or when the payment rule specified by the target user indicates that the credit account has priority in payment. 12. The method of claim 11, wherein the at least one credit account corresponds to different currency types, and sending a credit limit freeze request to the credit server includes: determining the first credit limit to be frozen based on the currency type corresponding to the target credit account and the order amount of the target order; and sending a credit limit freeze request to the credit server that includes at least the first credit limit. 13. The method of claim 1, wherein after executing the payment process for the target order using the first funds, the method further includes: generating 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: 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 requesting payment for a target order using a target card, 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, the target user being a user holding the target card, the first credit limit being related to the order amount of the target order; receiving a loan disbursement request from the wallet server; and 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. Claims 2 / 4 pages 3 CN 120996797 A15. The method of claim 14, wherein the wallet server maintains a first debit account corresponding to the owner of the credit server, and the first funds are disbursed to the target credit account through the first debit account. 16. The method of claim 15, wherein disbursing the first funds to the target credit account based on the loan request comprises: disbursing the first funds from the first debit account to the target credit account based on the loan request; and sending a first loan confirmation to the wallet server, the first loan confirmation indicating that the credit server has performed the operation of disbursing the first funds from the first debit account to the target credit account. 17. The method of claim 15, wherein disbursing the first funds to the target credit account based on the loan request comprises: sending a second loan confirmation to the wallet 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, so that the wallet server performs the transfer operation of the first funds. 18. The method of claim 15, wherein the account associated with the target card further includes a second debit account, and the method further includes: receiving a repayment request from the wallet server, the repayment request being used to request repayment of second funds to the first debit account through the second debit account. 19. The method of claim 18, wherein after receiving the repayment request from the wallet server, the method further includes: transferring the second funds from the second debit account to the first debit account based on the repayment request; and sending a first repayment confirmation to the wallet server, the first repayment confirmation indicating that the credit server has performed the operation of transferring the second funds from the second debit account to the first debit account. 20. The method of claim 18, wherein after receiving the repayment request from the wallet server, the method further includes: sending a second repayment confirmation to the wallet 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, so that the wallet server performs the transfer operation of the second funds. 21. The method of claim 19 or 20, wherein the method further includes: updating the target user's credit limit based on the repayment status. 22. The method of claim 14, further comprising: receiving a credit granting request from the wallet server, the credit granting request including credit credential information of the target user; determining a credit granting result based on the credit credential information; and sending the credit granting result to the wallet server, the credit granting result indicating that the credit limit granted to the target user is a target limit. 23. The method of claim 14, further comprising:The system receives 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; releases the second credit limit from the first credit limit; and sends a credit limit release result to the wallet server. Claims 3 / 4 pages 4 CN 120996797 A 24. 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 performs the method of 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; 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 performs the method of 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 instruction set, which, when executed by at least one processor, implements the method as described in any one of claims 1-23. Claims 4 / 4 pages 5 CN 120996797 A Payment Method, Wallet Server, Credit Server and Storage Medium Technical Field

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

[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). New financial systems are restricted by relevant organizations or license holders, and the cards they issue generally adopt a zero-credit-line model, that is, users can use the pre-deposited balance in their account when paying with a card of this model. Although this model of card meets the payment needs of users with sufficient funds, it is difficult to meet the payment needs of some users with tight cash flow due to the lack of overdraft function, resulting in limited applicability of the card.

[0003] The background information 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 constitutes prior art. Summary of the Invention

[0004] This specification provides a payment method, a wallet server, a credit server, and a storage medium. This novel financial system can collaborate with a credit system to provide overdraft functionality for cards, meeting the payment needs of users with tight cash flow and improving 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] In a second aspect, 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 requesting payment for a target order using a target card, 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] In a third aspect, 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] In a fourth aspect, 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] In a fifth aspect, 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 functions of the payment method, wallet server, credit server, and storage medium provided in this specification will be discussed later.The following description lists some of the inventive aspects of the payment methods, wallet servers, credit servers, and storage media provided in this specification. These aspects can be fully explained through practice or use of the methods, servers, and combinations described in the detailed examples below. Brief Description of the Drawings

[0011] To more clearly illustrate the technical solutions in the embodiments of this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the 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 shows a schematic diagram of an application scenario of payment provided according to an embodiment of this specification;

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

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

[0015] Figure 4 shows a schematic diagram of an account system provided according to an embodiment of this specification;

[0016] Figure 5 shows a flowchart of the authorization revocation stage provided according to an embodiment of this specification; and

[0017] Figure 6 shows a flowchart of the credit limit application stage provided according to an embodiment of this specification. Detailed Description

[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 is 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] In view of the following description, these and other features of this specification, as well as the operation and function of the related elements of the structure, and the economy of the combination and manufacture of the components, can be significantly improved. All of these form a 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 the operations of a system implementation according to some embodiments of this specification. It should be clearly understood that the operations in the flowcharts may not be implemented in sequence. Instead, the operations may be implemented in reverse order or simultaneously. Page 2 / 16 of this specification, CN 120996797 A. In addition, one or more other operations may be added to the flowchart. One or more operations may be removed from the flowchart.

[0022] The application scenarios of payment provided in this specification are described below with reference to FIG1. ​​

[0023] FIG1 shows a schematic diagram of the application scenarios of payment provided according to embodiments of this specification. As shown in FIG1, the application scenario 100 includes a target user 10, a wallet server 20, a credit server 30, a merchant system 40, and an acquiring system 50.

[0024] The target user 10 can be any user with transaction needs. For example, the target user 10 can be an individual, or an employee of an enterprise or company, etc. The target user 10 can be an ordinary consumer or a merchant.

[0025] The target user 10 can apply for a card in the financial system and pay for related orders in the merchant system 40 through the applied card.

[0026] The card in this specification is a digital payment tool issued by a financial system. It can be a virtual card (without a physical form) or a digital copy of a physical card. This specification does not limit this. The financial system can issue cards through, for example, websites or applications. Card-related information can be stored on the wallet server 20 or in the cloud for online channel management. For example, a user can apply for a card on a platform designated by the financial system. When using the card, the user can also apply for the generation of card account information (such as card number, which can be used once or for a long time), expiration date, and security code (Card Verification Value, CVV) on the platform designated by the financial system to increase payment security.

[0027] The wallet server 20 can be the server of the financial system that issues cards to target users. The financial system can provide financial services to target user 10 through the wallet server 20. For example, during the card application stage of target user 10, the wallet server 20 can issue cards to target user 10 according to their needs, including but not limited to debit cards, credit cards, and cards that combine debit and credit types. For example, during the stage where target user 10 pays for related orders via card, the order payment result (also known as payment authorization result) of the related order can be determined based on the order payment request and the credit service provision of the 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 aggregated service providers that aggregate multiple financial institutions or multiple payment service providers. New financial systems include, for example, e-wallets, etc., which are not limited in this specification.

[0029] Credit and debit are two directions for recording the flow of funds. Debit usually indicates an increase in assets or expenses, or a decrease in liabilities or owner's equity. Credit usually indicates a decrease in assets or expenses, or an increase in liabilities or owner's equity.

[0030] Debit type card: This can be understood as a card with debit function, referred to as a debit card in this article. It includes accounts with debit type (hereinafter referred to as debit accounts). Debit accounts allow funds to be deposited in advance, and the payment is completed by deducting the balance of the debit account when making actual payments. It can record the current asset status of the debit account in real time. Its characteristic is that the payment depends on the actual funds in the account and there is no overdraft function.

[0031] Credit type card: This can be understood as a card with credit function, referred to as a credit card in this article. It includes accounts with credit type (hereinafter referred to as credit accounts). A credit account has a credit limit (also called a credit line) provided by a financial institution (such as a credit system). 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] A card with both debit and credit types: This can be understood as a card that has both debit and credit functions. It is referred to as a debit card in this article and includes at least one debit account and at least one credit account.

[0033] When the 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 instruction manual 3 / 16 page 8 CN 120996797 A 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] The credit server 30 can be the server of the credit system. The credit system can provide credit services to the target user 10 through the 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 behavior in which the credit system, based on the creditworthiness and repayment ability of the target user, 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. The credit server 30 can provide different credit services at different stages. For example, at the card application stage, the credit server 30 provides credit services such as credit assessment and credit limit in response to the credit service request from the wallet server 20. At the card payment stage, the credit server 30 provides credit services such as credit limit freezing and loan disbursement in response to the credit service request from the wallet server 20. Specific details will be described in detail in the payment method 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, and institutions that can provide creditNew types of financial institutions providing services. For example, banks, payment service providers, and aggregated service providers that aggregate multiple financial institutions or multiple payment service providers. This specification does not impose any restrictions.

[0036] Merchant system 40 is a 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, thereby selecting the card to pay for related orders in merchant system 40. Target user 10 can also select the card for payment without binding the card, and this specification does not impose any restrictions on this. Merchant system 40 can interact with acquiring system 50, send order payment requests during the payment authorization stage, receive order payment results, and also display order payment results to target user 10, etc.

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

[0038] Acquiring system 50 refers to a platform or institution that has signed a contract with a merchant and is responsible for processing payment requests on the merchant side. 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 can be, for example, a financial system of an issuing bank, or a payment service provider of 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, that is, without information forwarding through an intermediate system. Alternatively, there can be an intermediate system for forwarding information between the acquiring system 50 and the wallet server 20, which is not limited in this specification. Intermediate systems include, but are not limited to: card group systems, payment agent systems, etc. Similarly, other information interaction nodes shown in FIG1 can communicate directly, or there can be intermediate nodes for forwarding information, which is not limited in this specification.

[0041] It should be noted that the payment requests, payment results, etc. exemplified in FIG1 are information exchanged between various nodes (such as wallet server 20, merchant system 40, and acquiring system 50) in the authorization stage of payment. Figure 1 does not show the information exchanged between these nodes after the payment enters other stages (such as the authorization revocation stage, payment request stage, refund stage, or chargeback stage, etc.). The specific interaction information of other stages will be described in detail later when the payment method is introduced, 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 the data and instructions. In some embodiments, the wallet serverThe 20 and credit server 30 may include hardware devices with data processing functions and the necessary programs required to drive the hardware devices.

[0043] Specifically, the technical details of the payment method P300 will be described in detail later and will not be repeated here.

[0044] FIG2 shows a hardware structure diagram of a computing system 200 provided according to an embodiment of this specification. The computing system 200 may be the wallet server 20 in FIG1 or the credit server 30 in FIG1. ​​

[0045] As shown in FIG2, 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. In addition, the computing system 200 may also include an I / O component 260.

[0046] The internal communication bus 210 may 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.

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

[0048] 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 a network. The 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 this access point, 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 may be communicatively connected to storage medium 230. Processor 220 is used to execute the at least one instruction set described above. When computing system 200 is running, processor 220 reads the at least one instruction set and executes the payment methods 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 circuitry or processor capable of performing one or more functions, etc., or any combination thereof.

[0054] For illustrative purposes only, only one processor 220 is shown in the computing system 200 in Figure 2. However, it should be noted that the computing system 200 in this specification may also include multiple processors. Therefore, the operations and / or method steps disclosed in this specification (page 5 / 16, CN 120996797 A) may be performed by one processor as described in this specification, or may be performed jointly by multiple processors. For example, if the processor 220 of the computing system 200 in this specification executes steps A and B, it should be understood that steps A and B can 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] FIG3 shows a flowchart of a payment method P300 provided according to an embodiment of this specification. A wallet server and a credit server can cooperate to execute payment method P300.

[0056] As shown in FIG3, payment method P300 includes the following steps.

[0057] S310: The wallet server receives a payment request, the payment request being used to request the use of the target card for the target order.Payment is made.

[0058] The target user can apply for one or more cards in the financial system to which the wallet server belongs. Each card can support payment in at least one currency. For example, the target user opens multiple stores, and each store uses a card for transactions, thereby achieving independent fund management (payment, receipt, etc.) for each store.

[0059] For example, as shown in Figure 4, the target user applies for card 1 and card 2 in the financial system to which the wallet server belongs. Each card can include accounts in 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] Continuing to refer to 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. That is, the wallet server can achieve fund separation for different currencies and different types of accounts at the account level. Taking debit account D1 and credit account C1 as examples, 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 credit limit in credit account C1 is the amount of currency 1. Other accounts follow the same principle.

[0061] It is understood that although card 1 and card 2 in the example of Figure 4 share the same set of debit accounts and set of credit accounts, this specification is not limited to this. For example, card 1 and card 2 may also correspond to different sets of debit accounts and sets of credit accounts respectively.

[0062] All credit accounts in a 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 in multiple cards applied for by the target user can share the credit limit. This specification does not limit this.

[0063] As shown in the account system of Figure 4, a card applied for by the target user can be associated with debit accounts and credit accounts, thus eliminating the need to apply for multiple cards with only a single type of account (debit account or credit account), avoiding the problem of complex fund management. This type of card, 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 makes a payment for a target order in the merchant system, they can select the target card from at least one card they have applied for. The target card can be a credit card or a debit card; this specification does not impose any restrictions on this. 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 the use of the target card to pay for the target order. The payment request includes, but is not limited to, the following information: target card, order amount.The amount, currency to be paid, order information of the target order (e.g., goods, merchant to which the goods belong), and receiving account, etc.

[0065] After the payment request of the target order is generated from the merchant system, it can be transmitted through one or more intermediate systems to reach the wallet server. For example, when there are multiple intermediate systems, according to the position of each intermediate system in the payment link, the multiple intermediate systems can be the acquiring system, the card group system, and the payment agent system in sequence. Specification 6 / 16 pages 11 CN 120996797 A

[0066] S312: The wallet server responds to the payment request to determine the target user holding the target card, and determines the target credit account to be paid in the account associated with the target card.

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

[0068] In some embodiments, the account associated with the target card includes at least one debit account and at least one credit account. In cases where at least one debit account does not support payment for the target order, or where the payment rules specified by the target user indicate that credit accounts are given priority for payment, the wallet server determines the target credit account from 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. Or, if the target user has pre-set payment rules, such as credit account priority or only authorizing credit account payment, 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 as the target credit account based on the clearing currency negotiated with the card group system. This specification does not limit this.

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

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

[0072] Before sending the credit limit freeze request, the wallet server may also determine the credit limit to be frozen.

[0073] In some embodiments, the wallet server determines the amount to be frozen based on the currency type corresponding to the target credit account and the target order.The order amount is used to determine the first amount to be frozen, and a limit freeze request containing at least the first amount is sent to the credit server.

[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 amount. 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 amount 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, the limit freeze request may include other information besides the first amount, such as the order information of the target order. Thus, after receiving the limit freeze request, the credit server can perform risk control on the target order based on the order information, thereby determining whether to freeze the first amount in the target user's credit limit. In addition, the wallet server can also perform risk control on the target order based on the order information, determine the first amount to be frozen if the risk control is passed, and send a limit freeze request.

[0075] In the above embodiments, the target card can be associated with credit accounts corresponding to multiple currencies to meet the cross-border payment needs of the target user. When the clearing currency and the deduction currency are different, the wallet server can also perform currency exchange on its own without requiring the target user to perform related operations, thus improving the user's cross-border payment experience. Furthermore, the way the wallet server determines the first amount to be frozen can also reduce the operational complexity of the credit server.

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

[0077] The credit server can perform risk control on the target order through the order information of the target order, etc. In the case of successful risk control, the first amount can be frozen according to the usage of the target user's credit limit.

[0078] For example, if the target user's current credit limit (the amount available to the target user in this period) is greater than or equal to the first amount, the credit server can freeze the first amount in the target user's current credit limit and generate an amount freezing result representing the frozen first amount. 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 insufficient limit or failure of risk control.

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

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

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

[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 of the target order is forwarded through one or more intermediate systems and finally transmitted to the merchant system. After receiving the payment result of the target order, if the payment result indicates that the payment authorization of the target order is approved, the merchant system can start the shipment of goods. If the payment result indicates that the payment authorization of the target order fails, the target user can be informed of the reason for the failure of authorization, such as insufficient limit or the target order having certain risks.

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

[0085] The merchant system can initiate a payment request when it receives the payment result and the payment result indicates that the payment authorization is approved. For example, the merchant system can initiate payment requests periodically, and the payment request can include the payment amount corresponding to each of multiple orders (including the target order). The payment request corresponding to the target order can be forwarded sequentially through one or more intermediate systems to reach the wallet server.

[0086] S324: The wallet server sends a loan request to the credit server to request the credit server to release the first fund to the target credit account; correspondingly, the credit server receives the loan request.

[0087] After receiving the payment request, the wallet server can associate it with the target order that has been authorized in the authorization stage and determine the amount authorized for the target order (i.e., the first limit). When the payment amount in the payment request is unreasonable, such as the payment amount being greater than the first limit, the wallet server can return a payment result indicating that the payment request has failed to the merchant system. When the payment amount in the payment request is less than or equal to the first limit, the wallet server can send a loan request to the credit server. At this time, the first fund requested to be released in the loan request can be the payment amount specified in the payment request.

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

[0089] In some embodiments, the wallet server maintains the first debit account corresponding to the credit server's owner (e.g., the credit system). The first fund is disbursed from the first debit account to the target credit account.

[0090] For example, continuing to refer to Figure 4, the debit accounts maintained by the wallet server for the credit system include 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 disburse funds to credit account C1. Debit account X2 can disburse funds to credit account C2. Debit account X3 can disburse funds to credit account C3. When the target...When the currency type of the credit account is currency 1, the first fund is 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 the link for fund transfer operations within the wallet system during the request phase is relatively simple, not involving other systems, which can reduce the complexity of disbursing funds to the target credit account and ensure the timeliness of fund disbursement during the request process. If the first debit account is outside the wallet system, the timeliness of fund disbursement during the request process cannot be guaranteed, and timeouts in the request process may involve abnormal situations such as order cancellation, affecting the user's payment experience.

[0092] There are multiple ways for the credit server to disburse the first fund. Two examples are given below, and this specification does not limit this.

[0093] Method 1

[0094] The credit server disburses the first fund from the first debit account to the target credit account based on the loan request. The credit server sends a first loan confirmation to the wallet server, and correspondingly, the wallet server receives the first loan confirmation from the credit server. The first loan confirmation indicates that the credit server has executed the operation of disbursing the first funds from the first debit account to the target credit account. The method of having the credit server execute the fund disbursement operation can ensure the fund security of the credit system.

[0095] For example, when the credit server executes the operation of disbursing the first funds 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 funds from the first debit account to the target credit account. After the wallet server successfully disburses the first funds, it can send the fund disbursement result to the credit server, informing the credit server that the operation of disbursing the first funds from the first debit account to the target credit account has been executed. Thus, the credit server sends a first loan 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. The second loan confirmation indicates that the credit server agrees to disburse the first funds from the first debit account to the target credit account. Based on the second loan confirmation, the wallet server executes the operation of transferring the first funds from the first debit account to the target credit account. After completing the transfer of the first funds, the wallet server can also send feedback information indicating successful fund transfer to the credit server.

[0098] The method of having the wallet server execute the fund disbursement operation after the credit server agrees to the loan can reduce the operational complexity of the credit server, reduce the loan disbursement time, and speed up the loan request process.

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

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

[0101] In some embodiments, in response to the 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 wallet server's execution of the payment process of the target order using the first funds includes: the wallet server determining the payment request result of the target order. For example, if the wallet server determines that the first funds in the target credit account are sufficient to pay the target order, it determines that the payment request result of 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 intermediate systems.

[0103] In some embodiments, after the wallet server executes the payment process of 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 actively repay according to the debt statement and enjoy the interest-free period.

[0104] The debt statement can track order consumption details, help the target user manage expenditures, improve the user's payment experience, and when there is fraud or dispute, the debt statement can also serve as a right protection certificate, improving the security of payment through the credit limit. In addition, the wallet server can separate the bills paid by the target card at the account level, thereby managing the bills paid by the debit account and the bills paid by the credit account independently, so as to achieve the purpose of dedicated use of funds. That is, the credit limit of the credit account can be used exclusively for the actual consumption scenario of the target card, reducing the risk that the loan issued by the credit system is used by the user for other improper purposes.

[0105] In some embodiments, the account associated with the target card also includes a second debit account, such as a debit account of 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. Continuing to refer to Figure 3, the repayment process includes the following steps:

[0106] S330: In response to the detection that the preset repayment conditions are 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 carry information about the second fund. The second fund can be the same as the first fund, or it can be 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, and the wallet server receives the repayment result accordingly.

[0109] S334: The wallet server performs related operations based on the repayment result.

[0110] There are multiple ways to execute S332. Two examples are given below, and this specification 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 the repayment request, and sends a first repayment confirmation (an example of a repayment result) to the wallet server. Correspondingly, the wallet server receives the first repayment confirmation. The first repayment confirmation indicates that the credit server has performed the operation of transferring second funds from the second debit account to the first debit account. The credit server's execution of the fund transfer operation can ensure the security of fund flow in the debit accounts of the credit system.

[0113] For example, the credit server can send a fund transfer request to the wallet server, requesting the wallet server to transfer second funds from the second debit account to the first debit account. After the wallet server successfully transfers the funds, it can send a fund transfer result to the credit server, informing the credit server that it has performed the operation of transferring second funds from the second debit account to the first debit account. After 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 triggered repayment conditions, which will be described in detail later when discussing the triggering of repayment conditions.

[0115] Method 2

[0116] The credit server sends a second repayment confirmation (an example of a repayment result) to the wallet server, and the wallet server receives the second repayment confirmation. The second repayment confirmation indicates that the credit server has agreed to repay the second funds to the first debit account through the second debit account. Based on the second repayment confirmation, the wallet server performs the operation of transferring the second funds from the second debit account to the first debit account. After completing the transfer of the second funds, the wallet server can also send a successful transfer feedback message to the credit server.

[0117] The method of having the wallet server perform the fund transfer operation after the credit server agrees to the repayment can reduce the operational complexity of the credit server, reduce repayment time, and speed 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. The related operations are similar to those performed by the wallet server in Method 1. They will be described in detail later when the repayment conditions are triggered, and will not be repeated here.

[0119] There are many situations in which the preset repayment conditions are triggered. Several of them are given as examples below. This specification does not limit the scope of this specification, which is on page 10 / 16 of CN 120996797 A.

[0120] Situation 1: Refund

[0121] The target user performs a refund operation on the target order in the merchant system, thereby generating a refund for the target order in the merchant system.The wallet server sends a refund request for the target order to the wallet server through one or more intermediate systems. After receiving the refund request corresponding to 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 repaid based on the refund request. For example, the second fund is the refund amount specified in the refund request. In addition, 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] In the case that the payment account of the target order is a credit account, after the wallet server determines the repayment result, it can determine the refund result of the target order, and then send the refund result of the target order to the merchant system through one or more intermediate systems. Thus, the merchant system can notify the target user of the refund result of the target order.

[0124] In scenario 1, when the target user initiates a refund, the wallet server can promptly repay the first debit account in the credit system, reducing the risk of the target user's overdue repayment.

[0125] Scenario 2: Chargeback

[0126] After the target user sees the debt statement in the 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 send the chargeback request to the wallet server. After receiving the chargeback request, the wallet server can collect chargeback voucher information from the target user and send a chargeback request containing the chargeback voucher information to the chargeback assessment system (e.g., the card group system). After receiving the chargeback request, the chargeback assessment system can notify the merchant system of the target user's chargeback and conduct a preliminary review and assessment based on the chargeback voucher information. If it is determined that the target user's chargeback application is approved, that is, the target user should not pay the chargeback funds (i.e., the second funds) specified in the chargeback request, the chargeback assessment system can send a chargeback result indicating that the application has been approved to the wallet server and issue the chargeback funds. Upon receiving a chargeback result indicating that the application has been approved, 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 bill to the target user through the wallet client.

[0127] In addition, before executing S330, the wallet server also needs to determine whether the payment account of the target order 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 the chargeback funds are returned to the second debit account, and the wallet server does not need to execute S330.

[0128] In case 2, when the target user initiates a chargeback request and the chargeback result indicates that the application has been approved, the wallet server...The server can promptly repay the first debit account of the credit system, reducing the risk of overdue repayment for the target user.

[0129] It should be noted that, if the payment account of the target order is a credit account, and after the chargeback funds are successfully refunded, the merchant system initiates an appeal and provides supplementary supporting materials to the chargeback adjudication system, the chargeback adjudication system can re-adjudicate based on the supplementary supporting materials. 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. Thus, the wallet server can resend the request for the release of chargeback funds to the credit server, and the credit server releases the chargeback funds to the target credit account through the first debit account. The specific process is the same as the first fund release process described above, and will not be repeated here. Subsequently, the wallet server can return the chargeback funds in the target credit account to the chargeback adjudication system, and the chargeback adjudication system will return the chargeback funds to the receiving account designated by the merchant system.

[0130] Case 3: Proactive Repayment Instruction Manual 11 / 16 pages 16 CN 120996797 A

[0131] The target user initiates a proactive repayment request on the wallet client, thereby the wallet server receives the proactive repayment request from the wallet client and executes S330. The proactive repayment request can be a repayment request for the target order, or it can be a repayment request for multiple orders containing the target order. After obtaining the repayment result, the wallet server can store the repayment result or display the repayment result to the target user.

[0132] Case 4: Repayment Deadline Reached

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

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

[0135] Through the triggering of the above repayment conditions, the wallet server can make timely repayments to the first debit account of the credit system (including those initiated by the target user or those initiated by the wallet server itself in cases of refunds, etc.), which is conducive to the credit system restoring the target user's credit limit in a timely manner. Thus, the target user can continue to consume based on the restored credit limit, meet urgent or high-frequency payment needs, avoid payment failure due to delayed credit limit updates caused by untimely repayment, and improve user payment satisfaction.

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

[0137] For example, if all debt accounts of the target user have been repaid, the credit server can restore the target user's credit limit to the maximum limit applied for by the target user in the historical period. If the target user's debt accounts have been partially repaid, the credit server can restore the repaid amount. Alternatively, the credit server can also increase or decrease the target user's credit limit based on the timeliness of the target user's repayment. For example, when the target user repays on time, the target user's credit limit can be increased to help the user cope with large or urgent expenditures and provide a financial buffer when funds are temporarily scarce. When the target user does not repay on time or always delays repayment, the target user's credit limit can be decreased to avoid the user's excessive overdraft and debt out of control, and also to reduce the risk of financial loss of the credit system.

[0138] Figure 3 shows the operations performed by various systems and servers when the merchant system initiates a payment request for the target order after the credit limit is frozen. This specification also provides another situation, as shown in Figure 5, that is, the operations performed by various systems and servers when the wallet server does not receive a payment request.

[0139] S310~S320 can be referred to the relevant description above, and will not be repeated here.

[0140] S322': The wallet server obtains 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. Several examples are given below, but this specification is not limited to these.

[0142] (1) After the target user cancels the 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 intermediate systems. Thus, the wallet server receives the cancellation request.

[0143] (2) The intermediate system (e.g., acquiring system, card group system or payment agent system) sets a timer for the target order. When the timer expires and the intermediate system has not received the payment request for the target order, 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, so that the wallet server receives the cancellation request.

[0144] (3) The wallet server sets a timer for the target order. If no payment request for the target order is received after the timer expires, 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 to request the credit server to release the second credit limit from the first credit limit that has been frozen by 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...Before sending a credit limit release request, the server can also associate the target order and determine the amount to be released based on the credit 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 currency exchange operations when determining the second credit limit. The first credit limit can be the same as the second credit limit, or the first credit limit can be different from the second credit limit; this specification does not impose any restrictions on this.

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

[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 from the first credit limit (e.g., when the target user cancels part of the goods in the 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.

[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 externally by the wallet server, 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 corresponding to the target order is generated from the target intermediate system, the wallet server needs to send the cancellation result of the target order to the target intermediate system.

[0154] If the cancellation request of 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] Through the process shown in Figure 5, in the case of a target order being cancelled or payment not requested within the time limit, the wallet server can request the credit server to release the corresponding credit limit, thereby unfreezing the occupied credit limit, avoiding invalid freezing, and using the released credit limit for payment of other orders of the target user, avoiding the problem of payment failure of other orders due to invalid credit limit freezing.

[0156] It should be noted that in the flowcharts shown in Figure 3 or Figure 5, for some relevant information that needs to be relayed by the intermediate system (such as payment requests, payment results, payment requests, payment results, cancellation requests, cancellation results, etc.), the intermediate system may pass through without processing, or it may perform some processing operations and continue to transmit. This specification does not restrict this. In addition, the intermediate system may also change the name of the relevant information during the forwarding of relevant information. For example, the acquiring system can process the payment request of the target order received from the merchant system and change it to the authorization request of the target order.The data continues to be transmitted downstream of the payment link (card set, wallet server, etc.). Other changes are similar and will not be listed one by one.

[0157] In some embodiments, the wallet server and credit server need to perform a credit limit application process before starting to execute payment method P300. As shown in Figure 6, 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 described in the specification 13 / 16 pages 18 CN 120996797 A.

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

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

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

[0162] For example, the credit server can conduct credit granting review based on the credit certificate information of the target user, that is, conduct credit assessment on the target user, thereby determining the credit granting result. If the credit granting review is passed, the credit granting result represents the credit limit. If the credit granting review is not passed, the credit granting result represents the failure of the credit granting, and may also represent the reason for the failure of the credit granting.

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

[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 represents the failure of the target user's credit limit application, the wallet server can display the failure of the credit limit application to the target user through the wallet client, and may also display the reason for the failure of the 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 in 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 specification may be a limit jointly provided by the wallet server and the credit server for the target user in the card consumption scenario. The credit limit is only supported for the target user in the card payment scenario, so that the use of the credit limit is closely integrated with the payment scenario. The wallet server uses the loan funds of the credit system on demand according to the request, so as to achieve the purpose of dedicated use of funds. Of course, the target user can also apply for other limits for other scenarios. The application process is similar and will not be described again.

[0168] Through the above limit application process, the credit server can provide the user with a suitable limit according to the user's voucher information, avoiding excessive consumption due to excessive limit or insufficient limit to meet the user's actual needs, so as to accurately match the personalized payment needs of different users. The credit server can also screen high-quality users through credit review, reduce bad debt risk, and ensure the fund security of the credit system.

[0169] In summary, the payment method, wallet server and credit server provided in this specification, the new financial system can jointly provide credit limits for the cards issued by the new financial system, so that users can use the cards issued by the new financial system to realize limit payment. The credit system can disburse funds to the credit account in the target user's card during the disbursement stage to meet the payment needs of users with tight funds, expand the applicable user range of cards issued by the new financial system, and improve the user's payment success rate.

[0170] In another aspect, this specification provides a computer-readable non-transitory storage medium storing at least one set of executable instructions for payment as described on pages 14 / 16 of this specification, CN 120996797 A. When the executable instructions are executed by a processor, the executable instructions instruct the processor to implement the steps of method P300 described in this specification. In some possible embodiments, various aspects of this specification can also be implemented in the form of a program product comprising 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 method P300 described in this specification. The program product for implementing the above method can be a portable compact disk read-only memory (CD-ROM) containing program code and can run on the computing system 200. However, the program product described herein is not limited to this. In this specification, a 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 take any combination of one or more readable media. A readable medium can be a readable signal medium or a readable storage medium. A readable storage medium can 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: having one or moreThe computer-readable storage medium may be an electrical connection of a conductor, a portable disk, a hard disk, 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 device, magnetic storage device, 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. The readable storage medium may also be any readable medium other than a readable storage medium that can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the 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 operations of this specification may be written in any combination of one or more programming languages, including object-oriented programming languages—such as Java, C++, etc.—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the computing system 200, partially on the computing system 200, as a standalone software package, partially on the 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 related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the related objects before and after are in an "or" relationship.

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

[0173] The term "multiple" mentioned in this specification, unless otherwise stated, should be understood as two or more.

[0174] Specific embodiments of this specification have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also 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...The content may be presented by way of example only and may not be restrictive. Although not explicitly stated herein, those skilled in the art will understand that the requirements of this specification encompass 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 of this specification.

[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 “an alternative embodiment” in various parts of this specification do not necessarily refer to the same embodiment. Furthermore, particular features, structures or characteristics may be appropriately combined in one or more embodiments of this specification.

[0177] It should be understood that in the foregoing description of embodiments of this specification, in order to aid in understanding a feature, and for the purpose of simplifying this specification, various features are combined in a single embodiment, drawing or description thereof. However, this does not mean that the combination of these features is necessary, and those skilled in the art may well 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 sub-embodiments. And it is also true when the content of each sub-embodiment is less than all the features of a single foregoing disclosed embodiment.

[0178] Every patent, patent application, publication of patent application, and other materials, such as articles, books, specifications, publications, documents, literature, etc. (excluding any historical examination documents associated therewith), cited in this disclosure are cited for all purposes related to this disclosure, for example, in the specification and claims of this disclosure. However, if there is any inconsistency or conflict between the description, definition, and / or terminology of the foregoing materials and the description, definition, and / or terminology used in this disclosure, the description, definition, and / or terminology used in this disclosure shall prevail.

[0179] Finally, it should be understood that the embodiments of the applications disclosed herein are illustrative of the principles of the embodiments of 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 described herein. Therefore, the embodiments described herein are not limited to the embodiments precisely described in the applications. Specification 16 / 16 pages 21 CN 120996797 A Figure 1 Figure 2 Specification Drawings 1 / 5 pages 22 CN120996797 A Figure 3, page 2 / 5 of the drawings of the specification 23 CN 120996797 A Figure 4, page 3 / 5 of the drawings of the specification 24 CN 120996797 A Figure 5, page 4 / 5 of the drawings of the specification 25 CN 120996797 A Figure 6, page 5 / 5 of the drawings of the specification 26 CN 120996797 A Abstract Abdominal ultrasound examination method, system and device 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 serverissues 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.

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