Payment method, wallet system and storage medium

Abstract

The embodiment of the invention provides a payment method, a wallet system and a storage medium. In the method, a wallet system receives a payment request of a target order initiated by a target user, and the payment request represents that the target order is paid through a target payment medium and the currency requested to be paid is a first currency; under the condition that a first account capable of paying the target order with the first currency does not exist in the N accounts of the target payment medium, obtaining a target area position corresponding to the target user, and dynamically determining M candidate accounts from the N accounts based on the target area position; and under the condition that a second account capable of paying the target order exists in the M candidate accounts, performing payment processing on the target order by using the second account.

Description

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202511615122.6 (22) Application Date 2025.11.05 (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) Inventor Xu Jianxin (74) Patent Agency Beijing Liuli Intellectual Property Agency (General Partnership) 16049 Patent Attorney Zhu Lefang (51) Int.Cl. G06Q 20 / 38 (2012.01) G06Q 20 / 36 (2012.01) G06Q 20 / 10 (2012.01) G06Q 20 / 34 (2012.01) (54) Invention Title: Payment Method, Wallet System, and Storage Medium (57) Abstract: This specification provides a payment method, a wallet system, and a storage medium. In the method, the wallet system receives a payment request for a target order initiated by a target user. This payment request indicates that the target order is being paid through a target payment medium, and the requested currency is a first currency. If none of the N accounts on the target payment medium can pay for the target order in the first currency, the system obtains the target area location corresponding to the target user and dynamically determines M candidate accounts from the N accounts based on the target area location. If a second account capable of paying for the target order exists among the M candidate accounts, the second account is used to process the payment for the target order. Claims (3 pages), Description (15 pages), Drawings (5 pages), CN 121391262 A, 2026.01.23, CN 1 21 39 12 62 A. 1. A payment method applied to a wallet system, comprising: receiving a payment request for a target order initiated by a target user, the payment request indicating payment of the target order through a target payment medium and the requested currency being a first currency, the target payment medium comprising N accounts, each account corresponding to a currency, wherein N is greater than or equal to 1; if there is no first account among the N accounts capable of paying the target order in the first currency, obtaining a target area location corresponding to the target user, dynamically determining M candidate accounts from the N accounts based on the target area location, wherein M is less than or equal to N; and if there is a second account among the M candidate accounts capable of paying the target order, using the second account to process the payment for the target order. 2. The method according to claim 1, wherein the wallet system has a preset set of multiple candidate currencies for supplementary payments, each candidate currency set corresponding to a regional location and including at least one candidate currency, the step of [based on the target]The method dynamically determines M candidate accounts from the N accounts regarding the regional location, including: determining a target candidate currency set corresponding to the target regional location from the multiple candidate currency sets; and determining the M candidate accounts from the N accounts based on the target candidate currency set, wherein the M candidate accounts do not include the account corresponding to the first currency. 3. The method according to claim 2, wherein M is greater than 1, each candidate currency set further includes the payment order of the at least one candidate currency, and the existence of a second account among the M candidate accounts capable of paying the target order includes: determining the payment priority of each of the M candidate accounts based on the payment order of the currencies corresponding to the M candidate accounts in the target candidate currency set; and performing a search process on the M candidate accounts in descending order of payment priority, wherein if a target candidate account is determined to meet the payment conditions during the search process, the search is stopped, and the target candidate account is designated as the second account. 4. The method according to claim 2, wherein determining the M candidate accounts from the N accounts based on the target candidate currency set comprises: determining M accounts from the N accounts corresponding to candidate currencies in the target candidate currency set, and using the M accounts as the M candidate accounts. 5. The method according to claim 1, wherein the target area location includes any one of the following: the area where the target user applies for the target payment medium; or the area where the target user initiates the target order. 6. The method according to claim 1, wherein the second account corresponds to the second currency, and processing the target order using the second account comprises: deducting the amount corresponding to the second currency from the second account; determining the pre-clearing currency of the target order according to a pre-clearing strategy, wherein the pre-clearing strategy characterizes the method of determining the pre-clearing currency when the first currency exists among multiple preset currencies, and the transaction frequency of each preset currency is higher than or equal to a preset frequency; and pre-depositing the pre-clearing amount corresponding to the pre-clearing currency for the target order based on the deduction amount. 7. The method according to claim 6, wherein determining the pre-clearing currency of the target order according to the pre-clearing strategy comprises: if the first currency exists among the plurality of preset currencies, using the first currency as the pre-clearing currency; or if the first currency does not exist among the plurality of preset currencies, using a target clearing currency preset by the wallet system as the pre-clearing currency, wherein the target clearing currency is one of the plurality of preset currencies. 8. The method according to claim 6, wherein using the second account to pay for the target order.The processing further includes: upon receiving a payment request for the target order, obtaining the payment currency specified in the payment request; if the payment currency and the pre-settlement currency are the same, advancing the payment process for the target order based on the pre-settlement amount; or if the payment currency and the pre-settlement currency are different, converting the pre-settlement amount into a target settlement amount corresponding to the payment currency, and advancing the payment process for the target order based on the target settlement amount. 9. The method according to claim 6, wherein the step of using the second account to process payment for the target order further includes: upon receiving a refund request corresponding to the target order, obtaining the refund currency and refund amount in the refund request; and determining the pending refund account corresponding to the refund currency from the N accounts, and returning the refund amount to the pending refund account. 10. The method of claim 6, wherein the step of using the second account to process payment for the target order further comprises: upon receiving a cancellation request corresponding to the target order, if the pre-settlement currency and the second currency are the same, then proceeding with the cancellation process of the target order based on the deduction amount; or if the pre-settlement currency and the second currency are different, then converting the pre-settlement amount into a refundable amount corresponding to the second currency, and proceeding with the cancellation process of the target order based on the refundable amount. 11. The method of claim 1, wherein the method further comprises: if the second account is not present among the M candidate accounts, generating a payment authorization result for the target order, the payment authorization result indicating that the payment authorization for the target order has failed; and sending the payment authorization result. 12. The method of claim 1, wherein the situation where there is no first account among the N accounts capable of paying the target order in the first currency includes: the N accounts not including the account corresponding to the first currency; or the N accounts including the account corresponding to the first currency, and the account corresponding to the first currency does not meet the payment conditions. 13. A wallet system 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, when running, reads the at least one instruction set and executes the method as described in any one of claims 1-12 according to the instructions of the at least one instruction set. Claims 2 / 3 pages 3 CN 121391262 A 14. 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 the at least one processor, implements the method as described in any one of claims 1-12. ClaimsPage 3 / 3 4 CN 121391262 A Payment Method, Wallet System and Storage Medium Technical Field

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

[0002] With the development of global science and technology and the popularization of Internet technology, information transmission and communication have become more convenient, and consumption scenarios have become more diverse. Payment services have gradually covered multiple consumption scenarios such as online, offline, and cross-border.

[0003] In cross-border scenarios, users' transaction objects are no longer limited to local merchants. When users transact with merchants in other regions, they need to exchange for currencies other than their local currency. When users frequently transact with merchants in other regions, they need to exchange for currencies frequently, which is time-consuming and affects the user's payment experience.

[0004] The content of the background art section is merely information known only to the inventor and does not represent that the above information had entered the public domain before the date of this disclosure, nor does it represent that it can be considered prior art of this disclosure.

[0005] This specification provides a payment method, a wallet system, and a storage medium. In cross-border scenarios, when a user's account corresponding to the transaction currency cannot make a payment, the wallet system can dynamically determine candidate accounts based on the user's location to supplement the payment, reducing the payment failure rate and improving the user's payment experience. Furthermore, selecting candidate accounts based on location can also reduce the probability of currency exchange and lower foreign exchange costs.

[0006] In a first aspect, this specification provides a payment method applied to a wallet system, comprising: receiving a payment request for a target order initiated by a target user, the payment request indicating payment of the target order through a target payment medium and the requested currency being a first currency, the target payment medium including N accounts, each account corresponding to a currency, the N being greater than or equal to 1; if there is no first account among the N accounts capable of paying the target order in the first currency, obtaining a target area location corresponding to the target user, dynamically determining M candidate accounts from the N accounts based on the target area location, the M being less than or equal to the N; and then, if there is a second account among the M candidate accounts capable of paying the target order, using the second account to process the payment for the target order.

[0007] In some embodiments, the wallet system has a preset set of multiple candidate currencies for supplementary payments. Each set of candidate currencies corresponds to a regional location and includes at least one candidate currency. The step of dynamically determining M candidate accounts from the N accounts based on the target regional location includes: determining a target candidate currency set corresponding to the target regional location from the multiple set of candidate currencies; and determining M candidate accounts from the N accounts based on the target candidate currency set.The M candidate accounts are determined, and the M candidate accounts do not include the account corresponding to the first currency.

[0008] In some embodiments, M is greater than 1, and each candidate currency set also includes the payment order of the at least one candidate currency. The case where there is a second account among the M candidate accounts that can pay the target order includes: determining the payment priority of each of the M candidate accounts based on the payment order of the currencies corresponding to the M candidate accounts in the target candidate currency set; and performing a search process on the M candidate accounts in descending order of payment priority. During the search process, if it is determined that the target candidate account meets the payment conditions, the search is stopped, and the target candidate account is used as the second account. Specification 1 / 15 page 5 CN 121391262 A

[0009] In some embodiments, the step of determining the M candidate accounts from the N accounts based on the target candidate currency set includes: determining the M accounts from the N accounts that correspond to the candidate currencies in the target candidate currency set, and using the M accounts as the M candidate accounts.

[0010] In some embodiments, the target area location includes any one of the following: the area where the target user applies for the target payment medium; or the area where the target user initiates the target order.

[0011] In some embodiments, the second account corresponds to a second currency, and the payment processing of the target order using the second account includes: deducting the deduction amount corresponding to the second currency from the second account; determining the pre-clearing currency of the target order according to a pre-clearing strategy, wherein the pre-clearing strategy characterizes the method of determining the pre-clearing currency when the first currency exists among multiple preset currencies, and the transaction frequency of each preset currency is higher than or equal to a preset frequency; and pre-depositing the pre-clearing amount corresponding to the pre-clearing currency for the target order based on the deduction amount.

[0012] In some embodiments, determining the pre-liquidation currency of the target order according to the pre-liquidation strategy includes: if the first currency exists among the plurality of preset currencies, using the first currency as the pre-liquidation currency; or if the first currency does not exist among the plurality of preset currencies, using the target liquidation currency preset by the wallet system as the pre-liquidation currency, wherein the target liquidation currency is one of the plurality of preset currencies.

[0013] In some embodiments, processing the payment of the target order using the second account further includes: upon receiving a payment request for the target order, obtaining the payment request currency specified in the payment request; if the payment request currency and the pre-liquidation currency are the same, advancing the payment of the target order based on the pre-liquidation amount.The payment process; or, if the requested currency and the pre-settlement currency are different, the pre-settlement amount is converted into the target settlement amount corresponding to the requested currency, and the payment process for the target order is advanced based on the target settlement amount.

[0014] In some embodiments, the payment processing of the target order using the second account further includes: upon receiving a refund request corresponding to the target order, obtaining the refund currency and refund amount in the refund request; and determining the pending refund account corresponding to the refund currency from the N accounts, and returning the refund amount to the pending refund account.

[0015] In some embodiments, the payment processing of the target order using the second account further includes: upon receiving a cancellation request corresponding to the target order, if the pre-settlement currency and the second currency are the same, the cancellation process for the target order is advanced based on the deduction amount; or if the pre-settlement currency and the second currency are different, the pre-settlement amount is converted into the pending refund amount corresponding to the second currency, and the cancellation process for the target order is advanced based on the pending refund amount.

[0016] In some embodiments, the method further includes: generating a payment authorization result for the target order when the second account is not present among the M candidate accounts, the payment authorization result indicating that the payment authorization for the target order has failed; and sending the payment authorization result.

[0017] In some embodiments, the case where there is no first account among the N accounts capable of paying the target order in the first currency includes: the N accounts do not include the account corresponding to the first currency; or the N accounts include the account corresponding to the first currency, and the account corresponding to the first currency does not meet the payment conditions.

[0018] In a second aspect, this specification also provides a wallet system, including: 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 one aspect of the specification, page 2 / 15 of CN 121391262 A, according to the instructions of the at least one instruction set.

[0019] In a third aspect, this specification provides 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 the first aspect.

[0020] Other functions of the payment method, wallet system, and storage medium provided in this specification will be partially listed in the following description. The inventive aspects of the payment method, wallet system, and storage medium provided in this specification can be fully understood through practice or use of the methods, systems, and combinations described in the detailed examples below.

[0021] Brief Description of the Drawings 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.

[0022] Figure 1 shows a schematic diagram of an application scenario of payment provided according to an embodiment of this specification; Figure 2 shows a hardware structure diagram of a computing system provided according to an embodiment of this specification; Figure 3 shows a flowchart of a payment method provided according to an embodiment of this specification; Figure 4 shows a schematic diagram of an account in a payment medium provided according to an embodiment of this specification; Figure 5 shows a schematic diagram of the stages involved in the payment method provided according to an embodiment of this specification; Figure 6 shows a flowchart of determining the deduction account and deduction provided according to an embodiment of this specification; and Figure 7 shows another schematic diagram of the stages involved in the payment method provided according to an embodiment of this specification. Detailed Description of the Embodiments

[0023] The following description provides specific application scenarios and requirements of this specification, with the aim of enabling those skilled in the art to create and use the contents of this specification. Various partial modifications to the disclosed embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and applications without departing from the spirit and scope of this specification. Therefore, this specification is not limited to the embodiments shown, but rather to the widest scope consistent with the claims.

[0024] 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 the presence of the associated integers, steps, operations, elements, and / or components, but do not exclude the presence of one or more other features, integers, steps, operations, elements, components, and / or groups, or the possibility of adding other features, integers, steps, operations, elements, components, and / or groups to the system / method.

[0025] These and other features of this specification, as well as the operation and function of the associated elements of the structure, and the economy of the combination and manufacture of components, can be significantly improved in consideration of the following description. All of these form part of this specification with reference to the accompanying drawings. However, it should be clearly understood that the accompanying 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.

[0026] The flowcharts used in this specification illustrate operations implemented according to some embodiments of this specification. It should be clearly understood that the operations in the flowcharts may not be performed sequentially. Instead, the operations may be performed in reverse order or simultaneously.Implementation. In addition, one or more other operations can be added to the flowchart. One or more operations can be removed from the flowchart.

[0027] The application scenarios of payment provided in this specification are described below with reference to Figure 1.

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

[0029] The application scenario 100 can be an online payment scenario or an offline payment scenario, and this specification does not limit it.

[0030] When the application scenario 100 is an online payment scenario, the merchant system 30 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 limit it. The merchant system 30 can display the items or services for sale to the user, and the user can place an order in the merchant system 30 and pay for the relevant order using the target payment medium.

[0031] When the application scenario 100 is an offline payment scenario, the merchant system 30 can be the merchant's POS system. After the user and the merchant agree on the items or services to be traded, the merchant's staff can place an order in the merchant system 30, and the user can use the target payment medium to pay for the relevant order in the merchant system 30.

[0032] The target payment medium is a payment tool applied for by the target user 10 in the wallet system 20 (as a financial system). It can be a virtual card (without a physical form), a physical card, or a digital copy of a physical card; this specification does not limit this. The wallet system 20 can issue payment mediums through, for example, a website or application. The relevant information of the payment medium can be stored on the server of the wallet system 20 or in the cloud for online channel management. For example, the target user can apply for the target payment medium on a platform designated by the wallet system 20. When using the target payment medium, the target user can also apply for the generation of account information (such as card number, which can be used once or for a long time), validity period, and security code (Card Verification Value, CVV) of the target payment medium on a platform designated by the financial system to increase payment security.

[0033] Target user 10 can be any user with transaction needs. For example, target user 10 can be an individual, or an employee of a company or enterprise. Target user 10 can be an ordinary consumer or a merchant; this specification does not impose any restrictions on this.

[0034] Wallet system 20 can include, but is not limited to, new financial institutions, payment service providers, or aggregation service providers that aggregate multiple financial institutions or multiple payment service providers. New financial systems such as e-wallets are not limited in this specification.

[0035] In some embodiments, the wallet system 20 includes a client providing front-end services and a server providing back-end services. For example, during the stage where the target user 10 applies for a target payment medium, the target user 10 can initiate a relevant application on the client, and the server in the wallet system 20 can issue the target payment medium to the target user 10 upon request. During the stage where the target user 10 uses the target payment medium to pay for the relevant order, the server in the wallet system 20 can receive the order payment request for the relevant order and determine the order payment result (also known as the payment authorization result) for the relevant order, and return the order payment result.

[0036] The merchant system 30 is the system for the target user 10 to conduct order transactions. In online payment scenarios, the target user 10 can bind the target payment medium in the merchant system 30, thereby selecting the target payment medium to pay for the relevant order in the merchant system 30. Alternatively, the target user 10 can also select the target payment medium for payment without binding the target payment medium, and this specification does not limit this.

[0037] After the target user 10 uses the target payment medium to pay for the relevant order in the merchant system 30, the merchant system 30 can generate an order payment request to enter the order payment authorization stage. During the authorization phase, the order payment request can be transmitted from the acquiring system 40 to the wallet system 20. After receiving the order payment request, the wallet system 20 can deduct the payment from the account specified on page 4 / 15 of the instruction manual (CN 121391262 A) in the target payment medium, thereby determining and sending the order payment result for the relevant order. The order payment result can be transmitted from the acquiring system 40 to the merchant system 30. The merchant system can display the order payment result (i.e., the payment authorization result) to the target user 10.

[0038] For example, if the payment authorization result is successful, and the target user 10 or the merchant system 30 cancels the relevant order, a cancellation request for the relevant order can be initiated in the merchant system 30 or the wallet system 20 to cancel the payment for the relevant order. After receiving the cancellation request, the wallet system 20 can return the amount deducted during the authorization phase to the deduction account.

[0039] For example, if the payment authorization result is successful, the merchant system 30 can also initiate a payment request for the relevant order to request the wallet system 20 to settle the amount corresponding to the relevant order to the merchant account. After receiving a payment request, the wallet system 20 can settle the corresponding amount to the merchant's account.

[0040] The acquiring system 40 refers to a platform or institution that has signed an agreement with the merchant and is responsible for processing the merchant's payment requests. It is a bridge connecting the merchant system and the financial system (such as a wallet system or card system) and can provide acquiring services for different merchants. The acquiring system 40 may be, for example, a financial system, an e-wallet payment service provider, or an aggregation service provider that aggregates multiple financial institutions or multiple payment service providers. This specification does not limit this.

[0041] The acquiring system 40 and the wallet system 20 can communicate directly, that is, without information forwarding through an intermediate system. Alternatively, there may be an intermediate system for forwarding information between the acquiring system 40 and the wallet system 20, which is not limited in this specification. The intermediate system includes, but is not limited to: card group system, payment agent system, etc. The payment agent system can act as a bridge between the wallet system 20 and the card group system. The card group system can formulate standards and rules for processing payment transactions and provide infrastructure and services for the wallet system, the acquiring system and other participants in the transaction. During the order payment authorization stage, it provides authorization services and verifies the validity of each order. After authorization, the card group system can also be responsible for handling the order clearing process, that is, calculating and transferring funds to relevant parties (such as merchants or other participants with service revenue). In addition, the other information interaction nodes shown in Figure 1 can communicate directly, or there may be intermediate nodes for forwarding information, which is not limited in this specification.

[0042] It can be understood that the wallet system 20, merchant system 30, acquiring system 40 and card group system can correspond to one system or multiple systems, which is not limited in this specification.

[0043] It should be noted that the order payment request and order payment result shown in Figure 1 are information exchanged between various nodes (such as wallet system 20, merchant system 30, and acquiring system 40) during the authorization stage. Figure 1 does not show the information exchanged between these nodes in other stages (such as authorization revocation stage, payment request stage, refund stage, etc.). The information exchanged in other stages will be described in detail later when the payment method P300 is introduced, and will not be repeated here.

[0044] In some embodiments, wallet system 20 may store data and instructions for implementing payment method P300, and may execute or be used to execute the data and instructions. In some embodiments, wallet system 20 may include a hardware device with data information processing function and the necessary programs required to drive the hardware device to work. Specifically, the technical details of payment method P300 will be described in detail later, and will not be repeated here.

[0045] Figure 2 shows a hardware structure diagram of computing system 200 provided according to an embodiment of this specification. Computing system 200 may be wallet system 20 in Figure 1.

[0046] 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 further include a communication port 250 and an internal communication bus 210. Furthermore, the computing system 200 may also include an I / O component 260.

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

[0048] The I / O component 260 supports input / output between the computing system 200 and other components.Page 5 / 15, CN 121391262 A

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

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

[0051] In some embodiments, the network can 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 exchange points. Through this access point, one or more components of the various devices corresponding to the computing system 200 can connect to the network to exchange data or information.

[0052] The 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. The 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.

[0053] The processor 220 may be communicatively connected to the storage medium 230. The processor 220 is used to execute the at least one instruction set described above. When the computing system 200 is running, the 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.

[0054] 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), and application-specific integrated circuits (ASICs).Application-Specific Instruction Set Processor (ASIP), Central Processing Unit (CPU), Graphics Processing Unit (GPU), Physical Processing Unit (PPU), Microcontroller Unit, Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA), Advanced RISC Machine (ARM), Programmable Logic Device (PLD), any circuit or processor capable of performing one or more functions, etc., or any combination thereof.

[0055] 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 steps of operation and / or method disclosed in this specification may be performed by one processor as described in this specification, or may be performed jointly by multiple processors. For example, if processor 220 of computing system 200 in this specification performs steps A and B, it should be understood that steps A and B may also be performed jointly or separately by two different processors 220 (e.g., a first processor performs step A, a second processor performs step B, or the first and second processors jointly perform steps A and B).

[0056] Figure 3 shows a flowchart of a payment method P300 provided according to an embodiment of this specification. The wallet system can execute the payment method P300.

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

[0058] S310: Receive a payment request for a target order initiated by a target user. The payment request indicates that the target order is paid through a target payment medium and the requested currency is a first currency. The target payment medium includes N accounts, each account corresponding to one currency, and N is greater than or equal to 1. Specification 6 / 15 pages 10 CN 121391262 A

[0059] The target user can apply for one or more payment mediums in the wallet system. Each payment medium can support payment of at least one currency.

[0060] For example, as shown in Figure 4, the target user applies for payment medium 1 and payment medium 2 in the wallet system. Each payment medium can include multiple accounts, each account corresponding to one currency, thereby having the ability to make payments through multiple currencies to meet the user's cross-border payment needs. Payment medium 1 and payment medium 2 can share the same set of accounts (multiple accounts as shown in Figure 4), or they can correspond to different sets of accounts (not shown in Figure 4). This specification does not impose any restrictions on this. The following description mainly uses the example of different payment mediums sharing the same set of accounts.

[0061] After the target user applies for a payment medium, they may not necessarily authorize the opening of all accounts in the payment medium for subsequent payments. The N accounts included in the target payment medium (such as payment medium 1 or payment medium 2) can be understood as the accounts authorized by the target user in the wallet system. They can be all the accounts in the multiple accounts, or some of the multiple accounts.Sub-accounts are not limited in this specification.

[0062] It should be noted that when different payment media correspond to the same or different sets of accounts, the accounts authorized by the target user in different payment media can be different. For example, the number of accounts authorized by the target user for payment media 1 and payment media 2 or the currencies corresponding to the accounts can be different.

[0063] Referring to Figure 4, the N accounts include: account 1 supporting payment of currency 1, account 2 supporting payment of currency 2, ..., account N supporting payment of currency N.

[0064] The N accounts can be debit accounts, credit accounts, or a combination of both. This specification does not limit this. Debit accounts allow funds to be deposited in advance, and the payment is completed by deducting the balance from the debit account when making the actual payment. Credit accounts have a credit limit (also called a credit line) provided by financial institutions (such as wallet systems), which can be used as working capital and needs to be repaid after a certain period of time (i.e., repayment).

[0065] For example, as shown in FIG5, when a target user pays for a target order through a target payment medium in a merchant system, the merchant system generates a payment request for the target order and sends the payment request to the acquiring system. The acquiring system receives and forwards the payment request for the target order. The wallet system can receive the payment request for the target order, which is used to request payment for the target order in a first currency. The payment request includes, but is not limited to: relevant information of the target payment medium, the order amount corresponding to the first currency, the order information of the target order (e.g., product, merchant, logistics information, etc.), and the merchant's receiving account.

[0066] After parsing the payment request for the target order, the wallet system can determine from the N accounts of the target payment medium whether there is a first account that can pay for the target order in the first currency.

[0067] In some embodiments, as shown in FIG6, if the N accounts include an account corresponding to the first currency and the account corresponding to the first currency meets the payment conditions, the wallet system determines that there is a first account among the N accounts, which is the account corresponding to the first currency. The wallet system can deduct funds from the account corresponding to the first currency, and the deduction amount can be the order amount in the payment request. After deducting funds, the wallet system can also generate a payment authorization result indicating successful (or approved) payment authorization, which is sent to the merchant system through an acquiring system or other intermediary systems.

[0068] For example, the payment conditions for the account corresponding to the first currency include, but are not limited to: the balance of the account corresponding to the first currency is greater than or equal to the order amount corresponding to the target order, the account status of the account corresponding to the first currency meets the requirements, the account corresponding to the first currency is free from risk, and the order amount of the target order does not exceed the single transaction limit of the account corresponding to the first currency. The payment conditions for accounts corresponding to other currencies are similar and will not be elaborated further.

[0069] Referring again to Figure 6, if the N accounts do not include the account corresponding to the first currency, or if the N accounts include the account corresponding to the first currency (see page 7 / 15 of the specification, CN 121391262 A) but the account corresponding to the first currency does not meet the payment conditions, then the wallet system determines that the first account does not exist among the N accounts.

[0070] For example, the first currency is not included among the currencies corresponding to the multiple accounts in the example of Figure 4, or the first currency is included among the currencies corresponding to the multiple accounts in the example of Figure 4, but the target user has not authorized the opening of the account corresponding to the first currency, thus the wallet system determines that the N accounts do not include the account corresponding to the first currency, that is, the first account does not exist in the target payment medium.

[0071] For example, the target payment medium includes the account corresponding to the first currency. For example, if the target user has authorized the opening of the account corresponding to the first currency in the wallet system, but the account corresponding to the first currency does not meet the payment conditions, then the wallet system can also determine that the first account does not exist in the target payment medium.

[0072] If the first account is not found among the N accounts, the wallet system can execute S320 to flexibly select other accounts for supplementary payment, reduce the payment failure rate, and improve the user's payment experience.

[0073] S320: If there is no first account among the N accounts that can pay for the target order in the first currency, obtain the target area location corresponding to the target user, and dynamically determine M candidate accounts from the N accounts based on the target area location, where M is less than or equal to N.

[0074] In some embodiments, the target area location includes any one of the following: the area location where the target user applies for the target payment medium; or, the area location where the target user initiates the target order.

[0075] The area location in this specification may be divided by the wallet system according to the geographical location range (such as country or region) of users using the same currency, but this specification is not limited to this.

[0076] For example, when the target area location is the area location where the target user applies for the target payment medium, the wallet system can read the target area location through a preset database. The preset database stores the application information filled in by the target user when applying for the target payment medium, including the target area location. Alternatively, the target area location can also be determined by the wallet system based on the location of the terminal used by the target user when applying for the target payment medium and stored in a preset database. This specification does not limit this.

[0077] For example, when the target area location is the area where the target user initiates the target order, the wallet system can determine the target area location from merchant information, logistics information, etc. in the payment request, or it can determine the target area location based on the location of the terminal used by the target user when initiating the order. This specification does not limit this.

[0078] Users in different areas use different legal tender currencies, and some users in different areas use different legal tender currencies.There is more than one transaction currency. Therefore, when there is no account corresponding to the transaction currency (such as the first currency) among the N accounts, the candidate account for supplementary payment determined by the wallet system based on the target area location is more likely to be an account that the user can accept or frequently use, which can improve the user's payment experience. In addition, the currency corresponding to the candidate account determined by the target area location is likely to be close to the local legal tender, which can reduce the probability of currency exchange during the clearing process and reduce foreign exchange costs.

[0079] For payment requests for orders initiated by different users, or for payment requests for different orders initiated by the same user, the wallet system can flexibly select a suitable candidate account for supplementary payment based on the area location to meet the personalized payment needs of different users. That is, the currency corresponding to the candidate account selected by the wallet system for different users or different orders is dynamically changing and relatively flexible.

[0080] In some embodiments, the wallet system has a preset set of multiple candidate currencies for supplementary payment, each set of candidate currencies corresponds to an area location and includes at least one candidate currency. After the wallet system determines that the first account does not exist among the N accounts, it can determine the target candidate currency set corresponding to the target region location from the multiple candidate currency sets, and then determine the M candidate accounts from the N accounts based on the target candidate currency set. The M candidate accounts do not include the account corresponding to the first currency.

[0081] For example, the wallet system has three preset candidate currency sets, where candidate currency set 1 corresponds to region location 1, candidate currency set 2 corresponds to region location 2, and candidate currency set 3 corresponds to region location 3. Taking candidate currency set 1 as an example, the candidate currencies in candidate currency set 1 can be the currency corresponding to the account that is preferentially selected from the other accounts held by the user (the user is located in region location 1, or the user is transacting with a merchant located in region location 1) when the account held by the user in region location 1 cannot make payment in the transaction currency. The candidate currencies in candidate currency set 1 are, for example, the fiat transaction currency of region location 1 or the currency that the user in region location 1 uses frequently. Other candidate currency sets are similar and will not be elaborated further. Assuming the target region is region 2, the wallet system can use candidate currency set 2 as the target candidate currency set.

[0082] In this embodiment, the wallet system pre-sets candidate currency sets for different regions based on the fiat currencies used or frequently used currencies. Therefore, if the wallet system automatically uses the account corresponding to the candidate currency for supplementary payment during the actual payment process, it can reduce the probability of currency exchange during the clearing process, reduce the complexity of the clearing process, and reduce financial losses caused by currency exchange.

[0083] For example, after determining the target candidate currency set, the wallet system can identify M accounts from the N accounts that correspond to the candidate currencies in the target candidate currency set, and use these M accounts as the M candidate accounts.

[0084] For example, the N accounts include accounts corresponding to currency 1 and currency 2 respectively. The target candidate currency set includes currency 2 and currency 3. The wallet system can use the account corresponding to currency 2 from the N accounts as the M candidate accounts.

[0085] For another example, the N accounts include accounts corresponding to currency 1 and currency 2 respectively. The target candidate currency set includes currency 1, currency 2, and currency 3. The wallet system can use the account corresponding to currency 2 from the N accounts as the M candidate accounts.

[0086] In this example, the wallet system can select accounts corresponding to currencies that intersect with the target candidate currency set from the N accounts as candidate accounts, avoiding the problem that the user of the account corresponding to a certain candidate currency selected from the target candidate currency set has not authorized activation, resulting in supplementary payment failure and poor user payment experience.

[0087] S330: If there is a second account among the M candidate accounts that can pay for the target order, the second account is used to process the payment for the target order.

[0088] In some embodiments, M equals 1, that is, the wallet system determines that there is only one candidate account among the M candidate accounts. At this time, the wallet system determines whether the candidate account meets the payment conditions. If the candidate account meets the payment conditions, the wallet system uses the candidate account as the second account to process the payment for the target order. If the candidate account does not meet the payment conditions, the wallet system determines that there is no second account among the M candidate accounts and generates a payment authorization result for the target order. The payment authorization result indicates that the payment authorization for the target order has failed (or the payment authorization is not approved). The wallet system can also send the payment authorization result for the target order, which is forwarded to the merchant system through an intermediate system such as the acquiring system.

[0089] In some embodiments, M is greater than 1, and each candidate currency set also includes the payment order of each candidate currency. The wallet system can determine the payment priority of each of the M candidate accounts based on the payment order of the currencies corresponding to the M candidate accounts in the target candidate currency set, and then perform a search process on the M candidate accounts in descending order of payment priority. During the search process, if it is determined that the target candidate account meets the payment conditions, the search stops and the target candidate account is used as the second account.

[0090] It is understood that different candidate currency sets may include different candidate currencies. When different candidate currency sets include the same candidate currencies, the payment order of each candidate currency may also be different, thereby adapting to the payment habits of users in different regions. This specification does not impose any restrictions on this.

[0091] In this embodiment, the wallet system can prioritize using accounts with high payment priority to supplement the target order, making the candidate accounts for supplementary payment more in line with the payment habits of local users and improving the user's payment experience.

[0092] For example, the N accounts include accounts corresponding to currency 1, currency 2, and currency 4. The target candidate currency set includes currency 2, currency 3, and currency 4, and the payment order is currency 2, currency 3, and currency 4 in sequence. The wallet system can determine the accounts corresponding to currency 2 and currency 4 among the N accounts as the M candidate accounts, and the payment priority of the account corresponding to currency 2 is higher than that of the account corresponding to currency 4.

[0093] After determining the payment priority of each candidate account, the wallet system can perform a search process on the M candidate accounts in descending order of payment priority to determine whether there is a second account among the M candidate accounts that can pay the target order.

[0094] For example, as shown in Figure 6, the M candidate accounts include candidate account 1, ... and candidate account M. The payment priorities of the M candidate accounts are, in descending order, candidate account 1, ... and candidate account M. When the wallet system determines during the search process that candidate account 1, ... and candidate account M do not meet the payment conditions, it can determine that there is no second account among the M candidate accounts, and then generate a payment authorization result indicating that the target order payment authorization has failed. The payment authorization result is sent to the merchant system through an intermediate system such as the acquiring system.

[0095] Referring again to Figure 6, if the wallet system determines that candidate account 1 with the highest payment priority meets the payment conditions, then candidate account 1 is used as the second account. If it determines that candidate account 1 does not meet the payment conditions, the wallet system determines whether other accounts with payment priorities lower than candidate account 1 meet the payment conditions, and so on. In other words, the wallet system prioritizes determining whether accounts with high payment priorities meet the payment conditions, thereby making it easier for supplementary payment candidate accounts to meet the user's payment habits. If a candidate account with high payment priority does not meet the payment conditions, the wallet system can also use a candidate account with low payment priority as a backup account for supplementary payment to improve the payment success rate and avoid other adverse effects on users caused by payment failure.

[0096] After the wallet system determines that there is a second account among the M candidate accounts, it can use the second account to process the payment for the target order. The second account corresponds to the second currency, that is, the second account supports payment through the second currency. Continuing to refer to Figure 5, S330 includes S332~S338.

[0097] S332: If there is a second account among the M candidate accounts, the wallet system can deduct the amount corresponding to the second currency from the second account.

[0098] For example, the wallet system can use the order amount corresponding to the first currency, the first currency andThe exchange rate between the two currencies determines the deduction amount corresponding to the second currency. After the wallet system determines the deduction amount of the second currency, it can deduct the deduction amount from the second account.

[0099] S334: The wallet system determines the pre-clearing currency of the target order according to the pre-clearing strategy, and the pre-clearing amount corresponding to the pre-clearing currency of the target order is based on the deduction amount.

[0100] The pre-clearing currency is the currency determined by the wallet system for the transfer in the request process. The pre-clearing amount is the amount prepared in advance by the wallet system for the transfer in the subsequent request process.

[0101] The pre-clearing strategy represents the method of determining the pre-clearing currency when the first currency exists among multiple preset currencies. The transaction frequency of each preset currency among the multiple preset currencies is higher than or equal to the preset frequency, or the flow frequency of each preset currency among the multiple preset currencies in the foreign exchange market is higher than or equal to the preset frequency. The wallet system can negotiate with the clearing system to determine the multiple preset currencies. Instruction manual, pages 10 / 15, CN 121391262 A

[0102] For example, if the first currency exists among the plurality of preset currencies, the wallet system uses the first currency as the pre-liquidation currency. Alternatively, if the first currency does not exist among the plurality of preset currencies, the wallet system uses a preset target liquidation currency as the pre-liquidation currency, and the target liquidation currency is one of the plurality of preset currencies. The target liquidation currency may be a liquidation currency pre-negotiated between the wallet system and the liquidation system. The liquidation system is, for example, a card deck system.

[0103] In this example, the wallet system can flexibly select a suitable pre-liquidation currency based on the transaction currency (first currency), covering multiple transaction scenarios using different transaction currencies, to meet the user's multilateral transaction needs, and has strong scalability.

[0104] Specifically, if the pre-liquidation currency is the same as the second currency, the wallet system deposits the deduction amount corresponding to the second currency as the pre-liquidation amount corresponding to the pre-liquidation currency into the pre-liquidation account (such as the wallet system's internal account). If the pre-clearing currency is different from the second currency, the wallet system needs to convert the deduction amount corresponding to the second currency into the pre-clearing amount corresponding to the pre-clearing currency, and deposit the converted pre-clearing amount into the pre-clearing account.

[0105] S336: The wallet system generates the payment authorization result of the target order and sends the payment authorization result of the target order to the acquiring system through the relevant intermediate system.

[0106] S338: After receiving the payment authorization result of the target order, the acquiring system forwards the payment authorization result of the target order to the merchant system.

[0107] The payment authorization result in S336 and S338 indicates that the payment authorization of the target order is successful (or the payment authorization is approved). In addition, S336 can also be executed before S334, and this specification does not restrict this.

[0108] Under normal circumstances, the exchange rate used by the clearing system to determine the clearing amount is the exchange rate at the time of order payment.Accurate. Therefore, in this embodiment, the wallet system pre-exchanges the deduction currency and the pre-clearing currency, which can avoid currency exchange losses caused by the change in the exchange rate between the deduction currency and the pre-clearing currency relative to the exchange rate at the order payment time after the clearing system initiates the clearing process.

[0109] In some embodiments, referring to Figure 5, the payment processing of the target order by the wallet system also includes a request stage, and the process of the request stage includes S340~S348.

[0110] S340: The merchant system generates a request for payment of the target order and sends the request for payment of the target order to the acquiring system.

[0111] The merchant system can initiate a request for payment when it receives the payment authorization result and the payment authorization result indicates that the authorization is successful. The merchant system can initiate a request for payment periodically, and the request for payment can include the request amount and request currency corresponding to each of the multiple orders.

[0112] S342: After receiving the request for payment of the target order, the acquiring system can forward the request for payment of the target order to the wallet system through the relevant intermediate system. The payment request includes the payment amount and payment currency specified by the clearing system.

[0113] S344: After receiving the payment request for the target order, if the payment currency and the pre-clearing currency are the same, the wallet system will proceed with the payment process for the target order based on the pre-clearing amount. Alternatively, if the payment currency and the pre-clearing currency are different, the pre-clearing amount will be converted into the target clearing amount corresponding to the payment currency, and the payment process for the target order will proceed based on the target clearing amount.

[0114] For example, if the payment currency and the pre-clearing currency are the same, the wallet system can transfer the pre-clearing amount in the pre-clearing account to the merchant account of the merchant associated with the target order. If the payment currency and the pre-clearing currency are different, and the payment amount is less than or equal to the target clearing amount, the wallet system can transfer part or all of the target clearing amount (the same as the payment amount) to the merchant account. If the payment amount exceeds the target clearing amount, the wallet system will make up the difference and then transfer the target clearing amount to the merchant account.

[0115] S346: The wallet system generates the payment request result for the target order and sends the payment request result to the acquiring system through the relevant intermediate system.

[0116] S348: After receiving the payment request result for the target order, the acquiring system can forward the payment request result for the target order to the merchant system.

[0117] The payment request result in S346 and S348 can indicate that the payment request for the target order was successful.

[0118] In this embodiment, after receiving the payment request, the wallet system transfers the corresponding payment amount to the merchant's account, which can accelerate the merchant's cash flow. Merchants can view the payment settlement status of each transaction in a timely manner, improving financial efficiency. And in the payment request...In cases where the payment currency and the pre-settlement currency are different, the payment process for the target order can continue through automated currency exchange within the wallet system, reducing manual exchange costs and avoiding payment failures due to differences between the payment currency and the pre-settlement currency, thereby improving payment success rate and user payment experience.

[0119] In some embodiments, referring to Figure 5, the wallet system's payment processing for the target order also includes a refund stage, the process of which includes S350~S358.

[0120] S350: In response to the target user performing a refund operation for the target order in the merchant system, the merchant system generates a refund request for the target order and sends the refund request to the acquiring system.

[0121] S352: After receiving the refund request for the target order, the acquiring system can forward the refund request to the wallet system through a relevant intermediary system. The refund request for the target order includes the refund currency and the refund amount.

[0122] S354: After receiving the refund request for the target order, the wallet system determines the account to be refunded corresponding to the refund currency from the N accounts and refunds the amount to the account to be refunded.

[0123] For example, if the refund currency is a second currency, the wallet system determines the account to be refunded to be the account corresponding to the second currency among the N accounts and refunds the amount to the account corresponding to the second currency.

[0124] S356: After refunding, the wallet system generates the refund result for the target order and sends the refund result for the target order to the acquiring system through the relevant intermediate system.

[0125] S358: After receiving the refund result for the target order, the acquiring system can forward the refund result for the target order to the merchant system.

[0126] The refund result in S356 and S358 indicates that the target order refund was successful.

[0127] It should be noted that the refund stage can be after the request stage, or some processes in the refund stage and some processes in the request stage can overlap in execution time. This specification does not restrict the execution order of specific processes in the request stage and the refund stage.

[0128] In this embodiment, the wallet system refunds based on the refund currency specified in the refund request, without currency exchange, which can reduce the financial loss caused by currency exchange.

[0129] In some embodiments, referring to Figure 7, after the authorization stage, the wallet system's payment processing for the target order also includes an authorization revocation stage. The authorization revocation stage includes S344'~S348'.

[0130] When the wallet system obtains the revocation request corresponding to the target order, it executes S344'.

[0131] The wallet system can obtain the revocation request corresponding to the target order in a variety of ways. Several of them are given as examples below, and this specification is not limited to them.

[0132] (1) After the target user performs the revocation operation of the target order in the merchant system, the merchant system can generate the target orderThe wallet system receives the cancellation request of the target order through one or more intermediate systems. (e.g., S340'~S342') (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 of the target order, the intermediate system generates a cancellation request of the target order. The intermediate system can send the cancellation request of the target order to the wallet system, so that the wallet system receives the cancellation request of the target order. (e.g., S342') (3) The wallet system sets a timer for the target order. When the timer expires and the wallet system has not received the payment request of the target order, the wallet system generates a cancellation request of the target order.

[0133] S344': If the pre-clearing currency is the same as the second currency, the wallet system promotes the cancellation process of the target order based on the deduction amount. If the pre-settlement currency and the second currency are different, the wallet system will convert the pre-settlement amount into the refundable amount corresponding to the second currency, and proceed with the cancellation process of the target order based on the refundable amount.

[0134] For example, if the pre-settlement currency and the second currency are the same, the wallet system will refund the deducted amount in the pre-settlement account to the second account. If the pre-settlement currency and the second currency are different, the wallet system will convert the pre-settlement amount in the pre-settlement account to obtain the refundable amount corresponding to the second currency. If the refundable amount is greater than or equal to the deducted amount, the wallet system will refund part or all of the refundable amount (the same as the deducted amount) to the second account. If the refundable amount is less than the deducted amount, the wallet system will make up the difference and refund the refundable amount to the second account together, so as to ensure that the deducted amount in the authorization stage and the refund amount in the authorization cancellation stage are consistent, and avoid problems such as poor user payment experience caused by the refundable amount being less than the deducted amount.

[0135] S346': After the wallet system refunds the deducted amount to the second account, it generates a cancellation result for the target order and sends the cancellation result to the acquiring system through the relevant intermediate system.

[0136] S348': After receiving the cancellation result of the target order, the acquiring system can forward the cancellation result of the target order to the merchant system.

[0137] The cancellation results in S346' and S348' can indicate that the target order was successfully cancelled.

[0138] In Figures 5 and 7, the data transmitted between the acquiring system and the wallet system is forwarded through the intermediate system (card group system, payment agent system, etc.), but this specification is not limited to this. The acquiring system and the wallet system can also communicate directly. In addition, the merchant system and the wallet system can also communicate directly without forwarding through the acquiring system.

[0139] In addition, the relevant entities in Figures 5 and 7 (such as the acquiring system) forward data (payment request, request for payment, refund)When processing payment requests, cancellation requests, payment authorization results, payment requests, refund results, cancellation results, etc., the data may or may not be processed before forwarding; this specification does not impose any restrictions on this. Data with the same name transmitted between different entities may be identical or different; this specification does not impose any restrictions on this either.

[0140] In summary, the payment method, wallet system, and storage medium provided in this specification allow users to make payments in multiple currencies, avoiding the problem of high payment failure rates caused by a single account. During the payment process, when the user's account cannot pay in the currency specified in the payment request, the wallet system can dynamically decide on candidate accounts to supplement the payment based on the user's corresponding regional location, in order to ensure the smooth progress of the payment and improve the payment success rate. Furthermore, the candidate accounts selected by the wallet system based on regional location can also reduce the probability of currency exchange and reduce foreign exchange costs. In addition, if currency exchange is involved in the payment process, it can be automatically exchanged by the wallet system without the user's awareness, avoiding the time-consuming problem of users exchanging currency themselves, and improving the user's payment experience.

[0141] In another aspect, this specification provides a computer-readable non-transitory storage medium storing at least one set of executable instructions for execution. When the executable instructions are executed by a processor, the executable instructions instruct the processor to perform the steps of method P300 described in this specification. In some possible embodiments, various aspects of this specification may also be implemented as a program product comprising program code. When the program product is run on computing system 200, the program code is used to cause computing system 200 to perform the steps of method P300 described in this specification. The program product for implementing the above method may employ a portable compact disk read-only memory (CD-ROM) comprising program code and may run on computing system 200. However, the program product of this specification is not limited thereto. In this specification, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system. The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. Readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, and magnetic storage.The computer-readable storage medium may include a data signal 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 may be executed entirely on computing system 200, partially on computing system 200, as a standalone software package, partially on computing system 200 and partially on a remote computing device, or entirely on a remote computing device.

[0142] 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.

[0143] 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.

[0144] Unless otherwise stated, "multiple" mentioned in this specification should be understood as two or more.

[0145] 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 those in the embodiments and still achieve the desired result. In addition, the processes depicted in the drawings do not necessarily require a specific order or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0146] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can be indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving data sent by B, or it can be understood as A indirectly receiving data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B...Sending data directly to A can also be understood as B indirectly sending data to A through other entities such as C. Here, C can be one entity or two or more entities.

[0147] In summary, after reading this detailed disclosure, those skilled in the art will understand that the foregoing detailed disclosure 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 this specification requires various reasonable changes, improvements and modifications to the embodiments. These changes, improvements and modifications are intended to be made by this specification and are within the spirit and scope of the exemplary embodiments of this specification.

[0148] 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 can be emphasized and should be 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, specific features, structures, or characteristics may be appropriately combined in one or more embodiments of this specification.

[0149] It should be understood that in the foregoing description of the embodiments of this specification, various features are combined in a single embodiment, drawing, or description for the purpose of simplifying this specification in order to aid in understanding a feature. However, this does not mean that the combination of these features is necessary, and it is entirely possible for someone skilled in the art to 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.

[0150] 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), referenced in this disclosure are referenced 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.

[0151] Finally, it should be understood that the embodiments disclosed herein are illustrative of the principles of the embodiments described in this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are merely illustrative examples.Examples are provided, not limitations. Those skilled in the art can implement the applications described herein using alternative configurations based on the embodiments described. Therefore, the embodiments described herein are not limited to the embodiments precisely described in the applications. Instruction Manual 15 / 15 Page 19 CN 121391262 A Figure 1 Figure 2 Instruction Manual Drawings 1 / 5 Page 20 CN 121391262 A Figure 3 Figure 4 Instruction Manual Drawings 2 / 5 Page 21 CN 121391262 A Figure 5 Instruction Manual Drawings 3 / 5 Page 22 CN 121391262 A Figure 6 Instruction Manual Drawings 4 / 5 Page 23 CN 121391262 A Figure 7 Instruction Manual Drawings 5 / 5 Page 24 CN 121391262 A Abstract Abdominal ultrasound examination method, system and device Payment method, wallet system and storage medium The embodiment of the invention provides a payment method, a wallet system and a storage medium. In the method, a wallet system receives a payment request of a target order initiated by a target user, and the payment request represents that the target order is paid through a target payment medium and the currency requested to be paid is a first currency; under the condition that a first account capable of paying the target order with the first currency does not exist in the N accounts of the target payment medium, obtain a target area position corresponding to the targetuser, and dynamically determining M candidate accounts from the N accounts based on the target area position; and under the condition that a second account capable of paying the target order exists in the M candidate accounts, performing payment processing on the target order by using the second account.

Claims

1. A payment method applied to a wallet system, comprising: Receive a payment request for a target order initiated by a target user. The payment request indicates that the target order is paid through a target payment medium and the requested currency is a first currency. The target payment medium includes N accounts, each account corresponding to a currency, and N is greater than or equal to 1. If there is no first account among the N accounts that can pay for the target order in the first currency, the target area location corresponding to the target user is obtained, and M candidate accounts are dynamically determined from the N accounts based on the target area location, where M is less than or equal to N; as well as If there is a second account among the M candidate accounts that can pay for the target order, the second account shall be used to process the payment for the target order.

2. The method according to claim 1, wherein, The wallet system has a pre-defined set of multiple candidate currencies for supplementary payments. Each candidate currency set corresponds to a regional location and includes at least one candidate currency. The step of dynamically determining M candidate accounts from the N accounts based on the target regional location includes: From the plurality of candidate currency sets, determine the target candidate currency set corresponding to the target region location; and Based on the target candidate currency set, M candidate accounts are determined from the N accounts, wherein the M candidate accounts do not include the account corresponding to the first currency.

3. The method according to claim 2, wherein, Where M is greater than 1, each candidate currency set also includes the payment order of the at least one candidate currency, and the situation where there is a second account among the M candidate accounts capable of paying the target order includes: The payment priority of each of the M candidate accounts is determined based on the payment order of the currencies corresponding to the M candidate accounts in the target candidate currency set; and The search process is performed on the M candidate accounts in descending order of payment priority. During the search process, if the target candidate account is determined to meet the payment conditions, the search is stopped and the target candidate account is used as the second account.

4. The method according to claim 2, wherein, The process of determining the M candidate accounts from the N accounts based on the target candidate currency set includes: From the N accounts, M accounts corresponding to the candidate currencies in the target candidate currency set are determined, and the M accounts are used as the M candidate accounts.

5. The method according to claim 1, wherein, The target area location includes any of the following: The target user applies for the regional location of the target payment medium; or The target user initiates the target order in a specific region.

6. The method according to claim 1, wherein, The second account corresponds to a second currency, and the process of using the second account to process payment for the target order includes: The amount corresponding to the second currency will be deducted from the second account; The pre-liquidation currency for the target order is determined according to a pre-liquidation strategy, wherein the pre-liquidation strategy characterizes the method for determining the pre-liquidation currency when the first currency exists among multiple preset currencies, and the transaction frequency of each preset currency is higher than or equal to a preset frequency; and The deduction amount is used to pre-deposit the pre-clearing amount corresponding to the pre-clearing currency for the target order.

7. The method according to claim 6, wherein, The step of determining the pre-clearing currency of the target order according to the pre-clearing strategy includes: If the first currency exists among the plurality of preset currencies, the first currency shall be used as the pre-clearing currency; or If the first currency does not exist among the plurality of preset currencies, the target liquidation currency preset by the wallet system shall be used as the pre-liquidation currency, and the target liquidation currency shall be one of the plurality of preset currencies.

8. The method according to claim 6, wherein, The step of using the second account to process payment for the target order further includes: Upon receiving a payment request for the target order, obtain the payment currency specified in the payment request; If the requested currency and the pre-settlement currency are the same, the payment request process for the target order proceeds based on the pre-settlement amount; or If the requested currency and the pre-clearing currency are different, the pre-clearing amount is converted into the target clearing amount corresponding to the requested currency, and the request process for the target order is advanced based on the target clearing amount.

9. The method according to claim 6, wherein, The step of using the second account to process payment for the target order further includes: Upon receiving a refund request corresponding to the target order, obtain the refund currency and refund amount from the refund request; and From the N accounts, determine the account to be refunded corresponding to the refund currency, and return the refund amount to the account to be refunded.

10. The method according to claim 6, wherein, The step of using the second account to process payment for the target order further includes: Upon receiving a cancellation request corresponding to the target order If the pre-clearing currency is the same as the second currency, then the cancellation process for the target order will proceed based on the deduction amount; or If the pre-clearing currency is different from the second currency, the pre-clearing amount is converted into the amount to be refunded corresponding to the second currency, and the cancellation process of the target order is advanced based on the amount to be refunded.

11. The method according to claim 1, wherein, The method further includes: If the second account is not among the M candidate accounts, a payment authorization result for the target order is generated, indicating that the payment authorization for the target order has failed; and Send the payment authorization result.

12. The method according to claim 1, wherein, The situation where none of the N accounts has a first account capable of paying for the target order in the first currency includes: The N accounts do not include the accounts corresponding to the first currency; or The N accounts include the accounts corresponding to the first currency, and the accounts corresponding to the first currency do not meet the payment conditions.

13. A wallet system, 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-12 according to the instructions of the at least one instruction set.

14. 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-12.

Images