Method and apparatus for performing request conversion between card payment acquiring institution and digital wallet and computer system

Abstract

Embodiments of this specification disclose a method and an apparatus for performing request conversion between a card payment acquiring institution and a digital wallet and a computer system. The method is performed by a processing system and includes: first, a first request is received from the card payment acquiring institution, where the first request is used to request an authorization freeze of funds and includes a transaction ID of a to-be-paid transaction and a first token; next, a first account in a first digital wallet corresponding to the first token is determined; and then, a second request, including the transaction ID and the first account, is sent to the first digital wallet.

Description

METHOD AND APPARATUS FOR PERFORMING REQUEST CONVERSION BETWEEN CARD PAYMENT ACQUIRING INSTITUTION AND DIGITAL WALLET AND COMPUTER SYSTEMTECHNICAL FIELD

[0001] One or more embodiments of this specification relate to the field of computer technologies, and in particular, to a method and an apparatus for performing request conversion between a card payment acquiring institution and a digital wallet, a computer system, and a computer-readable storage medium.BACKGROUND

[0002] Payment systems and financial infrastructures in different countries and regions differ to a greater or lesser extent, resulting in many challenges for overseas consuming payment and cross-border payment. Therefore, there is a need for a transaction service solution that can provide users smooth and seamless payment experience.SUMMARY

[0003] Embodiments of this specification describe a method and an apparatus for performing request conversion between a card payment acquiring institution and a digital wallet, to enable a user to use a digital wallet to obtain smooth and seamless payment experience overseas.

[0004] According to a first aspect, a method for performing request conversion between a card payment acquiring institution and a digital wallet is provided. The method is performed by a processing system and includes the following steps: receiving a first request from the card payment acquiring institution, where the first request is used to request an authorizationfreeze of funds and includes a transaction ID of a to-be-paid transaction and a first token; determining a first account in a first digital wallet corresponding to the first token; and sending a second request, including the transaction ID and the first account, to the first digital wallet.

[0005] According to a second aspect, an apparatus for performing request conversion between a card payment acquiring institution and a digital wallet is provided and is integrated in a processing system. The apparatus includes the following functional modules: a first request receiving module, configured to receive a first request from the card payment acquiring institution, where the first request is used to request an authorization freeze of funds and includes a transaction ID of a to-be-paid transaction and a first token; an account information determining module, configured to determine a first account in a first digital wallet corresponding to the first token; and a second request sending module, configured to send a second request, including the transaction ID and the first account, to the first digital wallet.

[0006] According to a third aspect, a computer system is provided, including a storage, a processor, and a computer program that is stored in the storage and that can run on the processor; and the processor performs the following steps: receiving a first request from the card payment acquiring institution, where the first request is used to request an authorization freeze of funds and includes a transaction ID of a to-be-paid transaction and a first token; determining a first account in a first digital wallet corresponding to the first token; and sending, including the transaction ID and the first account, a second request to the first digital wallet.

[0007] According to a fourth aspect, a computer-readable nonvolatile storage medium is provided, where the storage medium stores a computer program, and when executed by a processor, the computer program implements the method according to the first aspect.

[0008] According to the above-mentioned methods and apparatuses disclosed in embodiments of this specification, integration between two different payment links corresponding to card payment and wallet payment can be implemented, so that a user can also perform payment by using digital wallet even at an acquiring institution that supportsonly card payment.BRIEF DESCRIPTION OF DRAWINGS

[0009] To describe the technical solutions in embodiments of the present invention more clearly, the following briefly describes the accompanying drawings required for describing the embodiments. Clearly, the accompanying drawings in the following description show merely some embodiments of the present invention, and a person of ordinary skill in the art can still derive other drawings from these accompanying drawings without creative efforts.

[0010] FIG. 1 shows a system structure that uses a credit card or a debit card supported by a card organization as a payment way,

[0011] FIG. 2 shows a link of performing transaction based on the system structure shown in FIG. 1,

[0012] FIG. 3 shows a system structure of a transaction service solution that integrates card payment and wallet payment according to an embodiment of this specification;

[0013] FIG. 4 shows a link that is at a transaction authorization stage and that is based on the system structure shown in FIG. 3 according to an embodiment of this specification;

[0014] FIG. 5 is a schematic flowchart of sub-steps of step S43 in FIG 4 according to an embodiment of this specification;

[0015] FIG. 6 is a schematic diagram of design for a sub-account system of a service account according to an embodiment of this specification;

[0016] FIG. 7 is a schematic diagram of a page of a payment document of an incremental authorization request generated in an authorization stage according to an embodiment of this specification;

[0017] FIG. 8 shows a link that is at a capture stage and that is based on the system architecture shown in FIG. 3 according to an embodiment of this specification;

[0018] FIG. 9 is a schematic diagram of a link of transaction in a final authorization scenario according to an embodiment of this specification;

[0019] FIG. 10 is a schematic diagram of a link of transaction in which a user does notpay in advance and over capture is performed in a pre-authorization scenario according to an embodiment of this specification,

[0020] FIG. 11 is a schematic diagram of a notification provided by a wallet to recover funds from a user and a repayment entry interface according to an embodiment of this specification;

[0021] FIG. 12 is a schematic diagram of opening a temporary account at a service party by a digital wallet according to an embodiment of this specification;

[0022] FIG. 13 is a schematic diagram of a link of a transaction in which a user does not pay in advance and partial capture is performed in a pre-authorization scenario according to an embodiment of this specification;

[0023] FIG. 14 is a schematic diagram of a link of a transaction in which a user pays in advance and equal capture is performed in a pre-authorization scenario according to an embodiment of this specification;

[0024] FIG. 15 is a schematic diagram of a link of a transaction in which a user pays in advance and over capture is performed in a pre-authorization scenario according to an embodiment of this specification,

[0025] FIG. 16 is a schematic diagram of a link of a transaction in which a user pays in advance and partial capture is performed in a pre-authorization scenario according to an embodiment of this specification;

[0026] FIG. 17 is a schematic flowchart of canceling authorization after steps in a method of FIG 4 are performed according to an embodiment of this specification;

[0027] FIG. 18 shows a substitute link of a transaction based on the system architecture shown in FIG. 3 according to an embodiment of this specification;

[0028] FIG. 19 is a schematic diagram of dual-stage conversion performed by a processing system between a payment acquiring system and a digital wallet according to an embodiment of this specification;

[0029] FIG. 20 is a schematic diagram of a link of a process of processing the authorization (Auth) request in FIG. 19;

[0030] FIG. 21 is a schematic diagram of a link of a process of processing a capturerequest in FIG. 10;

[0031] FIG. 22 shows a link that is at a transaction chargeback stage and that is based on the system architecture shown in FIG. 3 according to an embodiment of this specification;

[0032] FIG. 23 is a schematic diagram of a link of a transaction in which a service party compensates in advance before receiving feedback from a merchant, when a user initiates a chargeback, according to an embodiment of this specification;

[0033] FIG. 24 is a schematic diagram of a link of a transaction in which a service party does not compensate in advance and a wallet does not advance funds for compensation, when a user initiates a chargeback, according to an embodiment of this specification;

[0034] FIG. 25 is a schematic diagram of a link of a transaction in which a digital wallet advances funds for compensation, when a user initiates a chargeback, according to an embodiment of this specification;

[0035] FIG. 26 is a schematic diagram of a link of a transaction in which a service party does not compensate in advance before receiving feedback from a merchant, when a digital wallet initiates a chargeback, according to an embodiment of this specification;

[0036] FIG. 27 is a schematic diagram of a structure of a transaction service apparatus integrated in a processing system according to an embodiment of this specification; and

[0037] FIG. 28 is a schematic diagram of a structure of a computer system according to an embodiment of this specification.DESCRIPTION OF EMBODIMENTS

[0038] The solutions provided in this specification are described below with reference to the accompanying drawings.

[0039] As mentioned above, payment systems in different countries and regions differ, resulting in many challenges for overseas payment and cross-border payment. Typically, in some regions, a digital wallet (or an e-wallet, or briefly referred to as a wallet) already becomes one of the mainstream payment methods. However, there are still many merchants, in many regions, that use acquiring machines (for example, POS machines) that support onlybank card payment but do not support digital wallets and corresponding acquiring institutions (providers of the acquiring machines, and processors of corresponding orders) that support only bank card payment but do not support digital wallets. Consequently, some digital wallet users who go overseas may have to pay with only cash because digital wallets cannot be used and the users don't have bank cards that support overseas payment. This causes inconvenience to the users.

[0040] Tn this case, in this specification, a solution for performing request conversion between a card payment acquiring institution and a digital wallet (or briefly referred to as a transaction service solution) is designed, to realize that a user can feel non-differentiated and smooth payment experience by using a digital wallet in different countries or regions. It is worthwhile to note that the "card payment acquiring institution" is an acquiring institution that can process a payment transaction that is based on a bank card, and is referred to as the "acquiring institution” in this specification for simplicity of description.

[0041] To facilitate understanding, the following first briefly describes a system architecture and a payment link that use the bank card as a payment method, and a difference between the payment method and digital wallet payment, and then describes the transaction service solution according to embodiments of this specification.

[0042] As shown in FIG. 1, a system architecture that enables bank card payment usually includes a merchant, an acquiring institution, a card organization, and a financial institution that has been granted card-issuing qualification by the card organization. The financial institution is usually a bank and can be briefly referred to as a card issuer The merchant can be reflected as an acquiring machine, for example, a POS machine, that is used by the merchant The acquiring institution processes customer payment on behalf of the merchant, and a main responsibility includes one or more of the following: setting up and maintaining a merchant account for the merchant, providing the acquiring machine for the merchant, aggregating and processing transaction orders generated by the merchant, connecting the orders to the card organization, performing transaction processing on the orders in accordance with a rule of the card organization, regularly settling funds into the account of the merchant, and performing risk management. The card organization represents a paymentnetwork that regulates and manages use of a payment card issued by a bank or another financial institution, and a main responsibility includes one or more of the following: connecting the card issuer and the acquiring institution, establishing a rule and a process for transactions, and regularly conducting clearing and settlement of funds. Examples of the card organization include both international card organizations such as Mastercard, VISA, and UnionPay, and national card organizations such as Dankort, RuPay, and mada. Some card organizations offer three-party scheme services To be specific, the card organization directly serves both a merchant and a customer. Tn this case, the card organization acts as both the acquiring institution and the card issuer Tn addition, in some cases (for example, when both the merchant and the customer hold accounts with a same bank and when some countries or regions provide infrastructure used for easy transfer of funds between different banks), bank card payment can be completed without intervention of the card organization.

[0043] It is worthwhile to note that the card organization can be replaced with another acquiring management institution that supports a same or similar function, for example, some financial service banks that also have an acquiring management function. It is considered that the card organization is a mainstream entity in a card payment system. The following is mainly described with the card organization as an example, and the card organization and the acquiring management institution can be used interchangeably in this specification. The acquiring institution and the acquiring management institution that is represented by the card organization together form a card payment acquiring system. It may be understood that there can be one or more entities assuming each of the roles, and each of the entities can be realized as any apparatus, platform, server, device cluster, etc that has computational and processing capabilities.

[0044] Usually, the card organization externally provides the following types of information flow interfaces (or types of acceptable requests):authorization / Auth: used for credit line checking and reserving or freezing requested funds, and including pre-authorization, final authorization, and incremental authorization as described below;cancellation / cancel: used to unfreeze reserved funds;capture / capture: a capture instruction after the Auth, used to request to transfer funds from an account of a customer to an account of a merchant, and sometimes referred to as presentment or clearing;refund / refund: used to refund funds to an account of a customer.

[0045] In the above information flow interfaces, the authorization is a first-stage information flow interface, while a second-stage information flow interface includes one of the cancellation and the capture. A complete payment link for a transaction includes both stages of the authorization / Auth and the capture / capture. FIG. 2 shows a payment link of performing card payment based on the system architecture in FIG 1, including an authorization stage and a capture stage.

[0046] At the authorization stage, a merchant sends an acquiring request, including card information, a transaction amount, etc., to an acquiring institution based on a bank card payment operation (for example, a user swipes a POS machine when checking in to a hotel) of the user for a current transaction. The acquiring institution generates an order number (namely, a transaction ID) for the acquiring request and further sends an authorization request to a card organization to request that funds be frozen for the transaction amount. Afterwards, the card organization forwards, based on card information included in the authorization request, the authorization request to a bank that issues the card. In this case, the bank freezes, based on the authorization request, an indicated amount in a card account indicated by the authorization request.

[0047] At the capture stage, the merchant initiates, to the acquiring institution, a capture request for the transaction order, for example, initiates capture after the user checks out of the hotel. Next, the acquiring institution forwards the capture request to the card organization. Afterwards, the card organization forwards the capture request to the bank based on card information in the capture request. In this case, the bank deducts, based on the capture request, the transaction amount from a card account indicated by the capture request, and transfers the transaction amount to the card organization. Afterwards, the card organization performs clearing with the merchant through the acquiring institution.

[0048] The above is a brief description of the system structure and the payment link inthe bank card payment method. It can be learned that in the bank card payment system, the card organization is a center, and one time of bank card payment is completed through a dual information flow (two requests) and two-stage payment link. Different from such dual information flow and two-stage payment, information flow interfaces of most digital wallets include only: pay, used for payment, and refund, used for refunding (which needs to correspond to an original transaction). Correspondingly, payment links of most digital wallets usually have only one stage, to be specific, deduction of funds is completed as soon as the user initiates the payment operation. This creates difficulty in integrating a digital wallet into the bank card payment system.

[0049] Based on the above observation and analysis, a newly designed processing system is introduced, used to integrate the digital wallet into a system architecture of bank card payment, to realize integration of two different payment links corresponding to bank card payment and wallet payment. Specifically, the processing system performs request conversion between a card payment acquiring institution and the digital wallet, to convert a request that is from a card payment system and that is not originally supported by the digital wallet into a request that can be support by the digital wallet. The card payment acquiring system does not need to change an original link process and request form, the digital wallet still only needs to perform an original basic operation thereof without adding identification of a request form of the card payment system and without adding additional service logic for the card payment system; and the user does not need to apply for a credit card or a debit card, and when the digital wallet is used to perform cross-border payment, experience is the same as using the digital wallet for local payment.

[0050] FIG. 3 shows a system architecture of a transaction service solution that integrates wallet payment into a card payment system according to an embodiment of thi s specification. Compared to FIG. 1 , the bank is replaced with a processing system and a digital wallet. It is worthwhile to note that a relationship between a service party to which the processing system in FIG. 3 belongs and another entity in the system architecture is not specifically limited in embodiments of this specification, for example, the service party can be a third party that is independent of other digital wallets, for another example, the service party can alternativelybe a developer of a particular digital wallet. In addition, a quantity of digital wallets in FIG.3 can be one or more, that is, n is a positive integer. For brevity, the digital wallet is used in this specification to refer to a wallet server or a wallet client, or both, the processing system is used to refer to a processing system server or a processing system client (for example, an SDK that works in collaboration with the wallet client), or both; and a person of skill in the art has a capability to deduce a specific referent based on context.

[0051] An acquiring system shown in FIG 3 is a card payment acquiring system, and can include only the card payment acquiring institution in FIG. 1, or can further include the card organization shown in FIG. 1.

[0052] To connect the digital wallet to a payment system using the acquiring system as a center, in advance, a wallet account that opens the service can be tokenized through the above-mentioned processing system and acquiring system (for example, the card organization in the acquiring system), to obtain a token that can be identified by an acquiring machine. The processing system can record a mapping relationship between each wallet account and a token. In this specification, the token refers to a substitute value for account information. In an example, a token that replaces account information of the digital wallet can be generated by a token service provider according to a predetermined rule based on the account information or information of a card allocated to the account, and the mapping relationship between each wallet account and a token is provided for the processing system.A process of tokenization is not limited here. In this way, when a user uses a digital wallet for payment, the acquiring machine can identify a token of a wallet account, use the token as card information, and transfer the token to the acquiring system, for example, first transfer the token to the acquiring institution, and then the acquiring institution transfers the token to the card organization as normal.

[0053] Based on the system architecture shown in FIG. 3, the acquiring system, after identifying that a request received from a merchant includes a token of a corresponding digital wallet, forwards the request to the processing system, and the processing system performs subsequent processing based on the request and collaborates with the digital wallet to complete a subsequent transaction process. The following describes in detail how theprocessing system collaborates with the digital wallet to complete the transaction process, by using various scenarios as examples for each of the above request types. Detailed descriptions are provided for authorization / Auth, cancellation / Cancel, and capture / Capture that are usually not supported by the digital wallet, but for refund / refund that is supported by the digital wallet, a description of processing of the request is omitted below because the processing system only needs to forward a corresponding request to the digital wallet without performing conversion.

[0054] Tn an example implementation, the processing system can convert an authorization request to a payment request, where the payment request indicates the digital wallet to deduct funds from an account of the user and transfer the deducted funds to a service account corresponding to the processing system, and afterwards, at a capture stage, the processing system can transfer, based on the capture request sent by the acquiring system, funds corresponding to a capture amount in the service account to an account of the card payment acquiring institution.

[0055] A transaction link of the above-mentioned example implementation is described in detail below with reference to more accompanying drawings and embodiments. As shown in FIG. 4, the transaction link includes the following process steps at an authorization stage:

[0056] Step S41 : A server of an acquiring system generates / obtains a first request, where the first request is used to request an authorization freeze of funds and includes a transaction ID of a to-be-paid transaction, a first fund share, and a first token.

[0057] It is worthwhile to note that when the acquiring system includes only a card payment acquiring institution but does not include a card organization, the acquiring server is a server of the acquiring institution, and the server of the acquiring institution directly interfaces with the processing system; or when the card payment acquiring system includes both an acquiring institution and a card organization, a server of the acquiring institution forwards the first request to a server of the card organization, and the server of the card organization interfaces with the processing system. For brevity of description, the server of the acquiring system is briefly referred to as a target server below.

[0058] In addition, similar terms such as "first" in "first request" and "first fund share"and "second" and "third" elsewhere in this specification are all intended to clearly distinguish between things of a same type and do not have another limitation function such as ranking.

[0059] The transaction ID in the first request can uniquely identify a transaction, and a transaction object of the transaction can be any product or service, such as a retail product, a hotel service, a car rental service, or a medical service. The first fund share can indicate both a currency type and a fund amount and the first fund share is intuitively denoted as M1below. The first token can come from a wallet client that initiates a payment operation for the to-be-paid payment transaction and is sent to the target server through the acquiring machine.

[0060] The first request is an authorization request corresponding to an Auth interface and can usually be subdivided into a pre-authorization request and a final authorization request. For a difference between the two types of requests, references can be made to Table 1 below.Table 1

[0061] Usually, the first request is generated by the acquiring institution based on an acquiring request sent by a merchant. For details, references can be made to the above relateddescriptions of the acquiring request and the authorization request in FIG. 2. A main difference lies in that, in this solution, the user pays by using the digital wallet rather than a bank card, and what the acquiring machine identifies is not card information of the bank card but a wallet token that is used as the card information.

[0062] It is worthwhile to note that an information link on which the target server obtains the first request is not limited in embodiments of this specification

[0063] Step S42: The target server sends the first request to the processing system.

[0064] Specifically, first, the target server can analyze the first request and determine, based on a token included in the first request, that the first request needs to be forwarded to the processing system rather than a financial institution, such as a bank, that is qualified to issue cards. Specifically, the target server provides the first request for the processing system if determining that the token included in the request does not correspond to a regular bank card but rather corresponds to a particular wallet account (or is considered to be a virtual bank card allocated to the account).

[0065] Step S43: The processing system generates a second request, including the transaction ID, a first account in a first digital wallet corresponding to the first token, and a first amount determined based on the first fund share. Specifically, this step can include sub-steps below shown in FIG. 5:

[0066] Step S51: The processing system analyzes the first request to obtain the transaction ID, a first fund share Mr, and the first token that are included in the first request.

[0067] Step S52: The processing system queries, based on the first token / xobtained through analysis, a pre-stored mapping relationship between a digital wallet account and a token, to obtain the first digital wallet and the first account that correspond to the first token. For example, the first digital wallet and the first account can be obtained by first locating a record in a user information table based on the first token and then reading digital wallet and wallet account fields in the record.

[0068] Step S53: The processing system determines, based on the first fund share Af1;a first amount N±to be sent to the first digital wallet.

[0069] In a cross-border payment scenario, a merchant and a digital wallet of a user in atransaction belong to different regulatory regions, where the different regulatory regions usually support different currencies. In this case, this step may include calculating an exchange amount based on an exchange rate. Specifically, it is assumed that a regulatory region to which the merchant belongs supports a first currency and a regulatory region to which the first digital wallet belongs supports a second currency. In this case, the first amount N- can be obtained through calculation based on an exchange rate of exchanging the first currency to the second currency.

[0070] It is worthwhile to note that the transaction service solution disclosed in embodiments of this specification is provided for a cross-border payment service scenario, but is also applicable to a local payment service scenario, where in this case, the above-mentioned first currency and second currency are the same and the first amountcan be directly determined based on the first fund share N±.

[0071] In different cases, the first amountof funds can be equivalent funds of the first fund shareor are greater than the equivalent funds. For ease of understanding, specific descriptions are provided below with reference to a capture process.

[0072] After calculating the first amount N , in step S54, the processing system generates the second request, including the transaction ID obtained through analysis, the first digital wallet and the first account that are obtained through query, and the determined first amount N .

[0073] The above provides, with reference to FIG. 5, descriptions in which the processing system generates the second request based on the first request.

[0074] Still refer to FIG. 4. Step S44: The processing system sends the second request to the first digital wallet.

[0075] Step S45: The first digital wallet deducts the first amount of funds from the first account.

[0076] Specifically, the first digital wallet can first analyze a received second request to obtain the transaction ID, the first account, and the first amount that are included in the second request, and then deduct the first amount of funds from the first account based on these data items.

[0077] Step S46: The first digital wallet transfers the deducted funds to a service account corresponding to the processing system.

[0078] It can be understood that the first digital wallet can spontaneously transfer the deducted funds to the service account or can transfer the deducted funds to the service account in response to a request of the processing system. The service account corresponding to the processing system can be a service account of a service party to which the processing system belongs or any other account that can be used (accessed) by the processing system.

[0079] For step S45 and step S46 above, in some embodiments, the first digital wallet can immediately (or instantly or in real time) transfer the first amount of funds from the first account to a corporate account of the first digital wallet based on an indication of the second request and transfer the first amount of funds from the corporate account to the service account within a predetermined time range (for example, one day).

[0080] According to another aspect of the embodiments, in the cross-border payment service scenario, after step S46 above is performed, the following step can be further performed: The processing system exchanges the first amount of funds transferred to the service account to a fund share, for example, the first fund share, in the first currency, to wait for the acquiring system to initiate capture.

[0081] According to an example, as shown in FIG. 6, the service account can include a first sub-account and a second sub-account, a first device in the processing system performs first fund interaction with an account of the card organization based on the first sub-account through the first currency, and a second device performs second fund interaction with the first digital wallet based on the second sub-account through the second currency. In this case, in step S46, the first digital wallet can transfer deducted funds in the second currency to the second sub-account, and then the second device exchanges the funds transferred to the second sub-account to a fund share in the first currency and transfers the funds to the first subaccount, to wait for the acquiring system to initiate the capture. It should be understood that the above-mentioned first device and second device are usually different devices located in different regions but can alternatively be a same device.

[0082] According to a further aspect of the embodiments, when the first request is a pre-authorization request, after step S41 above is performed, to be specific, after the target server obtains the first request, the authorization stage can further include the following steps:

[0083] The processing system receives an incremental authorization request, including the transaction ID, an incremental fund share, and the first token, that is sent by the target server for the first request; and then, the processing system determines the first account in the first digital wallet corresponding to the first token, and sends, to the first digital wallet, an incremental payment request, including the transaction ID, the first account, and an incremental amount determined based on the incremental fund share, that is for the second request, so that the first digital wallet deducts the incremental amount of funds from the first account and transfers the funds to the service account. It is worthwhile to note that, for descriptions of these steps, references can be made to the descriptions of similar steps in the above-mentioned embodiments, and details are omitted. In addition, incremental authorization implies incremental deduction of funds, and a page including a fund supplement document can be added for display in the digital wallet to inform the user in a friendly way. For this, refer to FIG. 7.

[0084] The above describes process steps performed at the authorization stage of the transaction service solution disclosed in embodiments of this specification.

[0085] Next, process steps that are further performed at the capture stage after the authorization is completed are described. It is worthwhile to note that, in the following embodiments, if not specifically mentioned, no incremental authorization request for the first request exists by default at the authorization stage, and a capture process in which an incremental authorization request exists can be simply deduced. As shown in FIG. 8, the capture stage includes the following steps.

[0086] Step S81 : The target server obtains a third request, where the third request is used to capture funds and includes the transaction ID and a second fund share M2.

[0087] It can be understood that the third request is a capture request and the second fund share included in the third request is an actual capture amount corresponding to the transaction ID. The second fund share M2may or may not be equal to the first fund share requested at the authorization stage; and correspondingly may or may not be equivalentto the first amountof funds already deducted at the authorization stage.

[0088] Usually, the third request is generated by a merchant. For example, the merchant can automatically generate capture requests, including the third request, in bulk at a predetermined moment each day for transactions that were marked as complete a previous day.

[0089] Based on this, in this step, the target server can obtain the third request generated by the merchant, and a specific acquisition link is not limited in embodiments of this specification.

[0090] Step S82: The target server sends the third request to the processing system.

[0091] Step S83 : The processing system transfers funds corresponding to the second fund share M2from a service account to the card payment acquiring institution. In one case, the processing system can directly transfer the funds to an account of the card payment acquiring institution. More typically, when a card payment acquiring system includes an acquiring management institution represented by a card organization, the acquiring management institution collaborates with the processing system and the acquiring institution to perform clearing and settlement, thereby transferring funds from the processing system to the acquiring institution. In this way, the processing system indirectly transfers the funds to the card payment acquiring institution.

[0092] For example, the service account includes the above-mentioned first sub-account and second sub-account. In this case, in this step, the processing system can directly or indirectly transfer the second fund share M2from the first sub-account (refer to FIG. 6) to the account of the acquiring institution. It should be understood that the processing system transfers the funds corresponding to the second fund share M2from the service account to the acquiring institution no matter whether the second fund share M2is of equal value compared to the first amountof funds already deducted at the authorization stage.

[0093] In one branch, the second fund share M2is equivalent to the first amountof funds already deducted at the authorization stage. In this case, the processing system can notify the first digital wallet that payment for the transaction ID is completed.

[0094] In another branch, the second fund share M2is not equivalent to the first amountN-L of funds, and after step S83 is performed, the processing system and the first digital wallet need to process funds corresponding to a difference in value, such as recovering and refunding the funds.

[0095] For the above two types of branches, it is considered that the capture stage is adapted to the authorization stage. To help understanding, the following performs comprehensive descriptions of the authorization stage and the capture stage by refining different branches into different implementation scenarios For ease of understanding, the following implementation scenarios are described by using an example with reference to a typical case in which a card payment acquiring system includes a card organization. For a case in which a processing system directly interfaces with an acquiring institution, a processing process can be obtained through similar inference.

[0096] Implementation scenario I: Final authorization

[0097] In this implementation scenario, the first request is a final authorization request (Final Auth), and a capture amount is the same as an authorization amount. Specifically, a transaction link can include the following steps shown in FIG. 9.

[0098] Step S901 : A server of a card organization obtains a first request, where the first request is a final authorization request and includes a transaction ID of a to-be-paid transaction, a first fund shareand a first token. The final authorization request is usually applicable to a transaction in which the price is clear, for example, sale of a physical product. A merchant can include a corresponding identifier in a sent acquiring request so that the card organization can identify a segmentation type of the request as the final authorization request.

[0099] For example, the first fund shareis 100 SGD.

[0100] Step S902: The server of the card organization sends the first request to a processing system.

[0101] Step S903: The processing system generates a second request, including the transaction ID, a first account in a first digital wallet corresponding to the first token, and a first amount N±directly determined based on the first fund share M1.

[0102] For example, a currency supported by the first digital wallet is HKD, and it is assumed that a current exchange rate is SGD:HKD = 1 :5. In this case, the processing systemcan determine, based on the exchange rate, that the first fund shareof 100 SGD can be exchanged for 500 HKD, and use 500 as the first amount Ni.

[0103] Step S904: The processing system sends the second request to the first digital wallet.

[0104] Step S905: The first digital wallet deducts the first amount N1of funds from the first account.

[0105] For example, the first digital wallet deducts 500 HKD from the first account and transfer the funds to a corporate account thereof.

[0106] Step S906: The first digital wallet transfers the deducted funds to a service account corresponding to the processing system.

[0107] F or example, the first digital wallet transfers 500 HKD from the corporate account thereof to a first sub-account (refer to FIG. 6) in the service account, to trigger the processing system to exchange, through a first device thereof, the transferred 500 HKD to 100 SGD and transfer the funds to a second sub-account, to wait for the card organization to perform capture.

[0108] Step S907 : The server of the card organization obtains a third request, where the third request is used to capture funds and includes the transaction ID and a second fund share M2.

[0109] It can be understood that the second fund share M2actually used for capture in the third request here is equal to the first fund share M1in the first request because the prior first request is the final authorization request.

[0110] For example, the second fund share M2is 100 SGD.

[0111] Step S908: The server of the card organization sends the third request to the processing system.

[0112] Step S909: The processing system transfers funds corresponding to the second fund share M2from the service account to an account of the card organization.

[0113] For example, the processing system transfers, through a second device thereof, 100 SGD from the second sub-account in the service account to the account of the card organization.

[0114] Step S910: The processing system sends a payment completion notification, including the transaction ID, to the first digital wallet.

[0115] It is worthwhile to note that, for the descriptions of the above steps in FIG. 9, references can alternatively be made to related descriptions in other embodiments above.

[0116] The above describes the transaction link of the transaction service solution in the final authorization scenario.

[0117] Implementation scenario II: Pre-authorization + no user buffer payment in advance

[0118] In this implementation scenario, the first request is a pre-authorization request, and the first fund share M1is equivalent to the first amount N1of funds. Further, the second fund share M2may be greater than, equal to, or less than the first fund shareas described separately below.

[0119] (1) Equal capture: The second fund share M2is equal to the first fund share

[0120] In this case, the second fund share M2is equal to the first amountof funds. For a related process, references can be made to the descriptions of FIG. 9, and a main difference lies only in that the first request is a pre-authorization request and is not a final authorization request.

[0121] (2) Over capture: The second fund share M2is greater than the first fund share

[0122] Further, in one embodiment, neither a digital wallet nor a user advances funds, and correspondingly, a transaction link can include the following steps shown in FIG. 10.

[0123] Step S1001 : A server of a card organization obtains a first request, where the first request is a pre-authorization request and includes a transaction ID of a to-be-paid transaction, a first fund shareand a first token.

[0124] For example, the first fund shareis 100 SGD.

[0125] Step SI 002: The server of the card organization sends the first request to a processing system.

[0126] Step SI 003: The processing system generates a second request, including the transaction ID, a first account in a first digital wallet corresponding to the first token, and afirst amount N±directly determined based on the first fund share M±.

[0127] For example, a currency supported by the first digital wallet is HKD, and the first amountis 500 determined based on the first fund share 100 SGD.

[0128] Step S1004: The processing system sends the second request to the first digital wallet.

[0129] Step SI 005: The first digital wallet deducts the first amount N±of funds from the first account.

[0130] For example, the first digital wallet deducts 500 HKD from the first account and transfer the funds to a corporate account thereof.

[0131] Step S1006: The first digital wallet transfers the deducted funds to a service account corresponding to the processing system.

[0132] F or example, the first digital wallet transfers 500 HKD from the corporate account thereof to a first sub-account in the service account, to trigger the processing system to exchange, through a first device thereof, the transferred 500 HKD to 100 SGD and transfer the funds to a second sub-account, to wait for the card organization to perform capture.

[0133] Step S 1007: The server of the card organization obtains a third request, where the third request is used to capture funds and includes the transaction ID and a second fund share M2, and the second fund share M2is greater than the first fund share M .

[0134] For example, the second fund share M2is 103 SGD.

[0135] Step SI 008: The server of the card organization sends the third request to the processing system.

[0136] Step S1009: The processing system transfers funds corresponding to the second fund share M2from the service account to an account of the card organization.

[0137] For example, the processing system transfers, through a second device thereof, 103 SGD from the second sub-account in the service account to the account of the card organization.

[0138] Step SlOlOa: The processing system sends a fourth request to the first digital wallet, to indicate the first digital wallet to transfer a second amount N2of funds to the service account, where the funds are equivalent funds of a difference share between thesecond fund share M2and the first fund share M±.

[0139] For example, the second amount N2of funds are 15 HKD, which are equivalent funds of 3 SGD that are a difference between 103 SGD and 100 SGD.

[0140] Step S 101 la: The first digital wallet transfers the second amount N2of funds from the corporate account thereof to the service account.

[0141] For example, the first digital wallet transfers 15 HKD of funds to the second subaccount of the service account.

[0142] Step SI 012a: The first digital wallet initiates, to the first account, recovery of the second amount N2of funds.

[0143] For example, recovery of 15 HKD is initiated.

[0144] For example, a server of the first digital wallet can push a notification to a client to which the first account is bound or send a private message reminder, and display a repayment entry on the client, where for this, references can be made to a terminal interface shown in FIG. 11.

[0145] The above describes the transaction link on which over capture is performed and a wallet advances funds in the implementation scenario II.

[0146] In another embodiment, a digital wallet advances funds so that the processing system helps the wallet digest fund supplement logic. In this case, the processing system needs to test a use status of an account used to advance funds in a wallet, to ensure that the account can be used to advance funds when there is a surplus of funds, and enable, by default, the digital wallet to be replenished with funds in a timely manner.

[0147] Specifically, as shown in FIG. 12, a service party and a first digital wallet each open a corporate account, where the corporate account of the service party is referred to as the service account in this specification, and the first digital wallet further opens a temporary account at the service party, where the temporary account belongs to the first digital wallet, but the service party has particular management rights over the temporary account, such as monitoring an account balance and performing automatic deduction of funds.

[0148] Based on this, a link of the transaction service solution can include the following steps shown in FIG. 10.

[0149] Step SI 001 to step SI 009, where for this, references can be made to the descriptions in the above-mentioned embodiments.

[0150] Step SlOlOb: The processing system transfers the second amount N2of funds from the temporary account to the service account, where the second amount N2of funds are equivalent funds of a difference share between the second fund share M2and the first fund share

[0151] For example, the processing system transfers 15 HKD from the temporary account to the second sub-account in the service account, where 15 HKD are equivalent funds of 3 SGD that are a difference between 103 SGD and 100 SGD.

[0152] Step S 1011b: The processing system sends a fifth request, indicating the first digital wallet to transfer the second amount N2of funds to the temporary account, to the first digital wallet.

[0153] Step S1012b: The first digital wallet transfers the second amount N2of funds from the corporate account thereof to the temporary account.

[0154] For example, the first digital wallet transfers 15 HKD to the temporary account.

[0155] Step S 1013b: The first digital wallet initiates, to the first account, recovery of the second amount N2of funds.

[0156] For example, recovery of 15 HKD is initiated.

[0157] The above describes the transaction link on which over capture is performed and a wallet advances funds in the implementation scenario II.

[0158] (3) Partial capture: The second fund share M2is less than the first fund share M1.

[0159] In this case, the transaction link can include the following steps shown in FIG. 13.

[0160] Step S1301 to step S1306, where for this, references can be made to the above-mentioned descriptions of step SI 001 to step SI 006.

[0161] Step SI 307: A server of a card organization obtains a third request, where the third request is used to capture funds and includes the transaction ID and a second fund share M2, and the second fund share M2is less than a first fund share Mt.

[0162] For example, the second fund share M2is 98 SGD.

[0163] Step S1308: The server of the card organization sends the third request to theprocessing system.

[0164] Step S1309: The processing system transfers funds corresponding to the second fund share M2from a service account to an account of the card organization.

[0165] For example, the processing system transfers, through a second device thereof, 98 SGD from a second sub-account in the service account to the account of the card organization.

[0166] Step S1310: The processing system refunds a fourth amount N4of funds from the service account to a corporate account of a first digital wallet and indicates the first digital wallet to perform refunding, where the fourth amount N4of funds are difference funds between a first amount N±of funds and equivalent funds of the second fund share M2.

[0167] For example, the fourth amount N4of funds are 10 HKD, which are difference funds (equivalent funds of 98 SGD) between 500 HKD and 490 HKD.

[0168] Step S 1311 : The first digital wallet refunds the fourth amount N4of funds to the first account.

[0169] For example, 10 HKD are refunded to a wallet account of a user.

[0170] The above describes the transaction link on which partial capture is performed in the implementation scenario II.

[0171] Implementation scenario III: Pre-authorization + user buffer payment in advance

[0172] In this implementation scenario, the first request is a pre-authorization request, where the user buffer payment in advance means that a first amount N4is determined after adding a fund share as a buffer to a first fund share M4requested to be frozen through authorization. This can effectively avoid an advance of funds from a service party or a wallet party and avoid a loss risk of the funds.

[0173] For the buffer share described above, in one embodiment, a product of the first fund share M4and a predetermined percentage (5%) can be calculated as the buffer share, and in another embodiment, the buffer share can be determined based on a predetermined laddering system.

[0174] Further, in one embodiment, a first amount N4obtained by exchanging the first fund share M4+ the buffer share to a second currency can be calculated based on an exchange rate between a first currency and the second currency. In another embodiment, afirst amount N±in a same currency can be directly determined.

[0175] In addition, for ease of management, a service account can be provided with a primary account and a temporary account, where the primary account is used to manage a first sub-amount of funds equal to the first fund sharein the first amountof funds, and the temporary account is used to manage a second sub-amount of funds equal to the buffer share.

[0176] In this implementation scenario, a second fund share M2can also be greater than, equal to, or less than the first fund share Mt, as described separately below.

[0177] (1) Equal capture: The second fund share M2is equal to the first fund share

[0178] A transaction link in this case can include the following steps shown in FIG. 14.

[0179] Step S1401 : A server of a card organization obtains a first request, where the first request is a pre-authorization request and includes a transaction ID of a to-be-paid transaction, a first fund share Mx, and a first token.

[0180] For example, the first fund shareis 100 SGD.

[0181] Step S1402: The server of the card organization sends the first request to a processing system.

[0182] Step S1403: The processing system generates a second request, including the transaction ID, a first account in a first digital wallet corresponding to the first token, and a first amount N1determined by adding a buffer share to the first fund share M1.

[0183] For example, it is assumed that the first fund share M1is 100 SGD, which becomes 105 SGD after adding 5% buffer share thereto. It is further assumed that a currency supported by the first digital wallet is HKD, and in this case, it can be determined that 105 SGD can be exchanged to 525 HKD based on an exchange rate of SGDHKD = 1:5, where 525 is the first amount N1.

[0184] Step SI 404: The processing system sends the second request to the first digital wallet.

[0185] Step S1405: The first digital wallet deducts the first amount / V, of funds from the first account.

[0186] For example, the first digital wallet deducts 525 HKD from the first account to acorporate account thereof.

[0187] Step S1406: The first digital wallet transfers the deducted funds to a service account corresponding to the processing system.

[0188] For example, the first digital wallet transfers 525 HKD from the corporate account thereof to the service account, where a first sub-amount of 500 HKD is transferred to the primary account of the service account, and a second sub-amount of 25 HKD is transferred to the temporary account of the service account.

[0189] For example, the first digital wallet transfers 500 HKD to the primary account and transfers 25 HKD to the temporary account.

[0190] For example, the first sub-account and the second sub-account in the service account can each be provided with a primary account and a temporary account. Therefore, for example, the first digital wallet transfers 500 HKD from the corporate account thereof to the primary account of the first sub-account and 25 HKD to the temporary account, to further trigger a first device in the processing system to exchange 500 HKD and 25 HKD to 100 SGD and 5 SGD, and then correspondingly transfers the funds to the primary account and the temporary account of the second sub-account, to wait for the card organization to perform capture.

[0191] Step S1407: The server of the card organization obtains a third request, where the third request is used to capture funds and includes the transaction ID and a second fund share M2, and the second fund share M2is equal to the first fund share M1.

[0192] For example, the second fund share M2is 100 SGD.

[0193] Step S1408: The server of the card organization sends the third request to the processing system.

[0194] Step SI 409: The processing system transfers funds corresponding to the second fund share M2from the primary account of the service account to an account of the card organization.

[0195] For example, the processing system transfers 100 SGD to the account of the card organization by using the primary account of the service account.

[0196] Step S 1410: The processing system refunds the second sub-amount of funds fromthe temporary account of the service account to the corporate account of the first digital wallet and indicates the first digital wallet to perform refunding.

[0197] For example, the processing system refunds 25 HKD to the first digital wallet by using the temporary account of the service account.

[0198] Step S1411: The first digital wallet refunds the second sub-amountoffundstothe first account.

[0199] For example, the first digital wallet refunds 25 HKD to the first account.

[0200] The above describes the transaction link on which equal capture is performed in the implementation scenario TIT.

[0201] (2) Over capture: The second fund share M2is greater than the first fund share

[0202] A transaction link in this case can include the following steps shown in FIG. 15.

[0203] Step SI 501 to step SI 506, where for this, references can be made to the descriptions of step S 1401 to step S1406 in the above-mentioned embodiments.

[0204] Step S 1507: The server of the card organization obtains a third request, where the third request is used to capture funds and includes the transaction ID and a second fund share M2, and the second fund share M2is greater than the first fund share

[0205] For example, the second fund share M2is 103 SGD.

[0206] Step SI 508: The server of the card organization sends the third request to the processing system.

[0207] Step SI 509: The processing system transfers funds corresponding to the second fund share M2from the primary account of the service account to an account of the card organization.

[0208] For example, the processing system transfers 103 SGD to the account of the card organization by using the primary account.

[0209] Step S1510: The processing system transfers the second amount N2of funds from the temporary account of the service account to the primary account, where the second amount N2of funds are equivalent funds of a difference share between the second fund share M2and the first fund share M, .

[0210] For example, the processing system transfers 15 HKD, which are equivalent to 3 SGD that are a difference between 103 SGD and 100 SGD, to the primary account by using the temporary account.

[0211] Step S1511: The processing system refunds a third amount N3of funds from the temporary account of the service account to the corporate account of the first digital wallet and indicates the first digital wallet to perform refunding, where the third amount N3is a difference between the second sub-amount and the second amount N2.

[0212] For example, the processing system refunds 10 HKD, which are a difference between 25 HKD and 15 HKD, to the first digital wallet by using the temporary account

[0213] Step SI 512: The first digital wallet refunds the third amount N3of funds to the first account.

[0214] For example, the first digital wallet refunds 10 HKD to the first account.

[0215] The above describes the transaction link on which over capture is performed in the implementation scenario III.

[0216] (3) Partial capture: The second fund share M2is less than the first fund share M1

[0217] In this case, the transaction link can include the following steps shown in FIG. 16.

[0218] Step S1601 to step S1606, where for this, references can be made to the above-mentioned descriptions of step S1401 to step S1406.

[0219] Step S 1607 : A server of a card organization obtains a third request, where the third request is used to capture funds and includes the transaction ID and a second fund share M2, and the second fund share M2is less than a first fund share M .

[0220] For example, the second fund share M2is 98 SGD.

[0221] Step SI 608: The server of the card organization sends the third request to the processing system.

[0222] Step SI 609: The processing system transfers funds corresponding to the second fund share M2from the primary account of the service account to an account of the card organization.

[0223] For example, the processing system transfers 98 SGD to the account of the card organization by using the primary account.

[0224] Step S1610: The processing system transfers the second amount N2of funds from the primary account of the service account to the temporary account, where the second amount N2of funds are equivalent funds of a difference share between the second fund share M2and the first fund share M1.

[0225] For example, the processing system transfers 10 HKD to the temporary account by using the primary account, where 10 HKD are equivalent funds of a difference share between 98 SGD and 100 SGD.

[0226] Step SI 611 : The processing system refunds a fourth amount N4of funds from the temporary account of the service account to the corporate account of the first digital wallet and indicates the first digital wallet to perform refunding, where the fourth amount N4is a sum of the second sub-amount and the second amount N2, and is also difference funds between the first amount N4of funds and equivalent funds of the second fund share M2.

[0227] F or example, the processing system refunds 35 HKD, which are a sum of 25 HKD (the second sub-amount) and 10 HKD (the second amount), to the first digital wallet by using the temporary account.

[0228] Step S 1612: The first digital wallet refunds the fourth amount N4offundstothe first account.

[0229] For example, the first digital wallet refunds 35 HKD to the first account.

[0230] The above describes the transaction link on which partial capture is performed in the implementation scenario III.

[0231] The above describes an overall process of the authorization stage and the capture stage with reference to different implementation scenarios after refinement. According to another aspect of the embodiments, after transaction authorization is completed, for the transaction, a capture process may be performed, or authorization may be canceled due to transaction cancellation. As shown in FIG 17, authorization cancellation includes the following steps.

[0232] Step S 171 : A target server obtains a cancellation request for a first request.

[0233] It can be understood that the cancellation request, including a transaction ID, is used to request to cancel frozen of funds. For example, the cancellation request can furtherinclude a first token and optionally further includes a first fund share

[0234] Usually, the first request is generated by a merchant system. For example, the merchant system can generate the cancellation request in response to a cancellation operation of a user on a transaction order corresponding to a transaction ID thereof, or the merchant system can set a transaction order corresponding to a transaction ID to "closed", to trigger to generate the cancellation request.

[0235] Based on this, in this step, the target server can obtain the cancellation request generated by the merchant system, and a specific link for implementing the acquisition is not limited in embodiments of this specification.

[0236] From the above, the target server can obtain the cancellation request.

[0237] Step SI 72: The target server sends the cancellation request to the processing system.

[0238] Step S 173 : The processing system refunds the first amountof funds from the service account to the corporate account of the first digital wallet based on the cancellation request and sends a refund notification to the first digital wallet.

[0239] Step SI 74: The first digital wallet refunds the first amount N±of funds to the first account based on the refund notification.

[0240] The above provides an example for description of process steps of canceling authorization after the authorization stage. It should be understood that the process steps described above are for full cancellation, and actually partial cancellation can alternatively be performed, where in this case, an amount canceled in the cancellation request is a fund share less than the first fund sharespecific process steps can be simply deduced, and details are omitted In addition, capture for the transaction ID does not occur after the full cancellation, but capture can still occur after the partial cancellation.

[0241] In summary, the transaction service method disclosed in embodiments of this specification is used so that integration of two different payment links corresponding to card payment and wallet payment can be realized. Specifically, for a card payment system whose transaction link includes an authorization stage and a capture stage, there is no need to change an original link process and request form; for a digital wallet whose transaction link includesonly a payment stage, it still only needs to perform a basic transfer operation, and there is no need to additionally implement service logic such as freezing an amount; for a user, there is no need to apply for a credit card or a debit card, and experience is the same as that of local payment by using the digital wallet when performing cross-border payment by using the digital wallet.

[0242] Based on the above-mentioned transaction service method, this specification also discloses another transaction service method that can be substituted for the method

[0243] In an i plementation A of the substitute method, deduction of funds may not be performed on a user at an authorization stage, the user is simply be notified that deduction of funds is pending for a target transaction, and then deduction of funds is initiated to the user at a capture stage.

[0244] In another implementation B of the substitute method, a type of an authorization request can be first determined at the authorization stage. Further, if it is determined that the request is a pre-authorization request, no deduction of funds is performed for the time being. This is because it is considered that a fund share in the pre-authorization request is usually estimated, there is usually a difference with a final consumption amount of the user, and then deduction of funds is initiated to the user at the capture stage. If it is determined that the request is a final authorization request, deduction of funds can be performed on the user, this is because a fund share in the final authorization request is the same as a final consumption amount of the user, and there is no need to initiate deduction of funds to the user at the capture stage.

[0245] Specific implementation steps in the above-mentioned two implementations are described in sequence below in combination with embodiments.

[0246] In the i ple entation A, a transaction link can include the following steps shown in FIG. 18.

[0247] Step SI 801: A target server obtains a first request, where the first request is used to request an authorization freeze of funds and includes a transaction ID of a to-be-paid transaction and a first token.

[0248] It can be understood that the first request can be a pre-authorization request or afinal authorization request. For example, the first request can further include a first fund share M , such as 100 SGD.

[0249] It is worthwhile to note that, for descriptions of this step, references can alternatively be made to the related descriptions of step S41.

[0250] Step S1802: The target server sends the first request to a processing system.

[0251] It is worthwhile to note that, for descriptions of this step, references can be made to the related descriptions of step S42, and details are omitted.

[0252] Step SI 803: The processing system generates a second request based on the first request, where the second request includes the transaction ID and a first account in a first digital wallet corresponding to the first token.

[0253] In one embodiment, the first request includes a first fund share M, . Further, in one specific embodiment, the second request can include a first amountof equivalent funds determined based on the first fund share M±. For example, a currency supported by the first digital wallet is HKD. In this case, based on an exchange rate of SGD:HKD = 1:5, it can be determined that the first fund share M1100 SGD can be exchanged for 500 HKD, and 500 thereof is used as the first amount N±. In another specific embodiment, the second request can alternatively not include an amount field.

[0254] It is worthwhile to note that, for descriptions of this step, references can alternatively be made to the related descriptions of step S43.

[0255] Step SI 804: The processing system sends the second request to the first digital wallet.

[0256] Step SI 805: The first digital wallet sends a transaction notification associated with the transaction ID to the first account based on the second request.

[0257] It should be understood that in this step, the transaction notification can be pushed to a wallet client logged in to the first account, or in other words, the transaction notification is pushed to a user holding the first account.

[0258] For content of the transaction notification, in an example, the transaction notification can include a merchant name of the transaction, details of a transaction object, etc. In another example, the transaction notification can indicate that deduction of funds fora transaction is pending, specifically, for example, indicating that deduction of a first amount of funds is pending. In another example, a display interface of the transaction notification can include a confirmation authorization icon for automatic deduction of funds so that the user can click the icon to authorize the first digital wallet to automatically deduct funds from the first account after the transaction is completed.

[0259] From the above, authorization can be completed by performing step SI 801 to step SI 805 After authorization is completed, there may be a capture stage or an authorization cancellation stage. It is worthwhile to note that, for authorization cancellation, references can be made to the related descriptions in the above-mentioned embodiments. The following mainly describes process steps of the capture stage. In addition, in the following descriptions of a capture process, there is no incremental authorization for the first request at an authorization stage by default, and a capture process in which an incremental authorization request exists can be simply deduced.

[0260] Step SI 806: The target server obtains a third request, where the third request is used to capture funds and includes the transaction ID and a second fund share M2.

[0261] It should be understood that the second fund share M2may or may not be equal to the first fund share M1in the first request. For example, the second fund share M2is 110 SGD.

[0262] It is worthwhile to note that, for descriptions of this step, references can alternatively be made to the related descriptions of step S81.

[0263] Step SI 807: The target server sends the third request to the processing system.

[0264] Step SI 808: The processing system transfers funds corresponding to the second fund share M2from a service account to a card payment acquiring institution.

[0265] It is worthwhile to note that, for descriptions of this step, references can alternatively be made to the related descriptions of step S83.

[0266] Step SI 809: The processing system sends a fourth request, including the transaction ID, the first account, and a second amount N2of equivalent funds determined based on the second fund share M2, to the first digital wallet.

[0267] For example, a currency supported by the first digital wallet is HKD. In this case,based on an exchange rate of SGD:HKD = 1:5, it can be determined that the second fund share M2110 SGD can be exchanged for 550 HKD, and 550 thereof is used as the second amount N2.

[0268] Step S1810: The first digital wallet transfers the second amount N2of funds from a corporate account thereof to the service account based on the fourth request.

[0269] Step SI 811 : The first digital wallet initiates, to the first account, deduction of the second amount N2of funds. It should be understood that this step can be performed before, after, or at the same time as step SI 810.

[0270] The above describes the transaction link in the implementation A, where the user is only notified of pending deduction of funds at the authorization stage, and then actual deduction of funds is initiated at the capture stage.

[0271] In an implementation B, the first request at the authorization stage can be a final authorization request and a pre-authorization request. When the request is the final authorization request, for a transaction link for authorization and capture stages, references can be made to the above-mentioned descriptions of FIG. 9, and details are omitted. When the request is the pre-authorization request, for a transaction link for authorization and capture stages, references can be made to the above-mentioned descriptions of FIG. 18, and details are omitted. The above describes two implementations of the substitute transaction service method.

[0272] The transaction service method and the substitute method thereof described above are both applicable to a digital wallet of which a transaction link has only a payment stage. Actually, there are a handful of digital wallets for which freeze and unfreeze functions similar to Auth and cancel are developed. In view of this, in embodiments of this specification, a processing system is introduced, to integrate such digital wallets into a system structure for bank card payment through conversion of request forms For this, references can be made to FIG. 3. In addition, FIG. 19 shows a processing system interfacing an information flow between an acquiring system and a digital wallet to support the various requests for authorization / Auth, cancellation / cancel, capture / capture, and refund / refund described above.

[0273] Next, process steps included in processing of different types of requests in FIG.19 are described. As shown in FIG. 20, an authorization stage includes the following steps.

[0274] Step S2001: A target server obtains a first request, where the first request is used to request an authorization freeze of funds and includes a transaction ID of a to-be-paid transaction, a first fund share, and a first token.

[0275] It is worthwhile to note that, for descriptions of this step, references can alternatively be made to the above- entioned related descriptions of step S41.

[0276] Step S2002: The target server sends the first request to a processing system.

[0277] It is worthwhile to note that, for descriptions of this step, references can alternatively be made to the above-mentioned related descriptions of step S42.

[0278] Step S2003 : The processing system generates a second request based on the first request, where the second request includes the transaction ID and a first account in a first digital wallet corresponding to the first token and indicates the first digital wallet to freeze at least part of funds in the first account. It should be understood that the at least part of funds means that funds that need to be frozen can be part or all of the funds in the first account.

[0279] In an implementation C, the second request further includes a first amount determined based on the first fund share. In one embodiment, the first amount of funds are equivalent funds of the first fund share. In another embodiment, the first amount of funds include equivalent funds of the first fund share and additional buffer funds. It is worthwhile to note that, for the implementation C, references can alternatively be made to the above-mentioned related descriptions of step 43.

[0280] In another implementation D, the second request further includes the first fund share in a first currency and a first exchange rate between the first currency and a second currency. In other words, the processing system provides reference exchange rate information for the digital wallet.

[0281] Step S2004: The processing system sends the second request to the first digital wallet.

[0282] Step S2005 : The first digital wallet freezes the at least part of funds in the first account.

[0283] Being adapted to the implementation C, in one embodiment, in embodiments ofthis specification, the first amount of funds can be directly used as the at least part of funds for freezing. In another embodiment, additional funds can be added based on the first amount of funds as the at least part of funds for freezing.

[0284] Being adapted to the implementation D, in one embodiment, the digital wallet can calculate equivalent funds of the first fund share in the second currency based on the first exchange rate, and can further add a buffer amount based on the equivalent funds as the at least part of funds for freezing. It should be understood that, because the exchange rate is volatile and there are cases of over capture after pre-authorization, the additional buffer amount is frozen so that an advance of funds of the wallet caused by fluctuations in the exchange rate and over capture after pre-authorization can be avoided, thereby further avoiding an additional fund recovery process and fund loss of the wallet due to the advance of funds.

[0285] Usually, a plurality of payment channel accounts, such as a wallet balance account, a wallet credit borrowing account, and a bank card, are bound to the first account (wallet account), and a user may be required to specify, as soon as the user opens credit payment at a wallet side, funds of which sub-account are frozen, or the first digital wallet may restrict to freezing only funds in the wallet balance account. This is not limited in embodiments of this specification.

[0286] From the above, a freeze of the funds in the first account can be realized. It can be understood that the user cannot use the frozen funds, including payment, transfer, etc. In addition, when there are insufficient funds in the first account, the first digital wallet can indicate to a user holding the first account that the authorization freeze fails

[0287] The above describes process steps related to processing an authorization request in a dual information flow interfacing solution After the authorization freeze of the funds is completed, a capture request initiated for the frozen funds can be processed at a capture stage As shown in FIG. 21, the capture stage includes the following steps.

[0288] Step S2101 : A target server obtains a third request, where the third request is used to capture funds and includes a transaction ID and a second fund share.

[0289] It is worthwhile to note that, for descriptions of this step, references can be madeto the above-mentioned descriptions of step S81, and details are omitted.

[0290] Step S2102: The target server sends the third request to a processing system.

[0291] Step S 103: The processing system transfers funds corresponding to the second fund share from an account of a service party to which the processing system belongs to a card payment acquiring institution.

[0292] It is worthwhile to note that, for descriptions of this step, references can be made to the above-mentioned descriptions of step S83, and details are omitted

[0293] Step S2104: The processing system sends a sixth request to a first digital wallet.

[0294] Tn an implementation E, the sixth request includes a second amount, and the second amount of funds are equivalent funds of the second fund share.

[0295] In another implementation F, the sixth request includes the second fund share in a first currency and a second exchange rate between the first currency and a second currency.

[0296] Step S2105: The first digital wallet transfers the second amount of funds to the service account and deducts the second amount of funds therefrom after unfreezing at least part of funds in the first account.

[0297] Being adapted to the implementation E, in this step, the first digital wallet can directly extract the second amount from the sixth request and implement corresponding transfer and deduction of funds.

[0298] Being adapted to the implementation F, in this step, the first digital wallet can calculate a second amount in the second currency based on the second exchange rate and the second fund share, and then implement operations of transfer and deduction of funds.

[0299] The above describes unfreezing and deduction of funds in a frozen wallet account at the capture stage.

[0300] An authorization cancellation stage can alternatively be performed after the authorization stage. Specifically, the authorization cancellation stage can include the following steps: First, the processing system receives, from the target server, a cancellation request, including the transaction ID, for the first request; and then, the processing system sends an eighth request to the first digital wallet, used to indicate the first digital wallet to unfreeze funds for the first account.

[0301] In the above-mentioned descriptions of the transaction link, the authorization stage and the capture stage are mainly described. It is worthwhile to note that a sequence between transfer of funds from the processing system to the acquiring system and operations such as refunding funds to / recovering funds from the wallet at the authorization stage and the capture stage is not limited in embodiments of this specification. The processing system can be configured to first transfer funds to the acquiring system, and then refund funds to / recover funds from the wallet; can be configured to first refund funds to / recover funds from the wallet, and then transfer the funds to the acquiring system; or can be configured to simultaneously perform the two operations. Neither an order in which these operations are described in this specification and the claims nor step numbering of these operations in the accompanying drawings should be construed as limiting an order in which these operations are performed.

[0302] In practice, a chargeback / chargeback may further occur after capture (not limited to the capture process shown in FIG. 8 and FIG. 16) is completed. As a consumer protection mechanism, the chargeback allows a customer to initiate a dispute over completed payment and request a refund of paid funds. Different from a refund usually initiated by a merchant, the chargeback is usually initiated by the customer. For example, the customer can initiate the chargeback because of existence of fraud, an unauthorized transaction, or dissatisfaction with a service or product provided by the merchant. In a current card payment acquiring system, after the customer initiates the chargeback, a card issuer determines whether the chargeback is reasonable, and if determining that the chargeback is reasonable, notifies an acquiring institution, and the acquiring institution eventually notifies the merchant of the information. During this period, according to a rule, the acquiring institution deducts funds from an account of the merchant for the disputed transaction, and the card issuer temporarily refunds the funds for the disputed transaction to an account of the customer.

[0303] After receiving chargeback information, the merchant can decide whether to accept the chargeback or contest the chargeback. The process ends if the merchant accepts the chargeback. If the merchant decides to make a contest, the merchant needs to gather corresponding evidence (including, for example, communication with the customer, a bill,evidence of product shipment, customer payment history, etc.) and submit the evidence to the card issuer through the acquiring institution. The acquiring institution temporarily refunds funds to the account of the merchant in response to the contest made by the merchant.

[0304] Finally, the card issuer decides, based on the evidence provided by the merchant and other information, whether to authorize the chargeback of the customer. If the chargeback is approved, the customer can keep the previously temporarily refunded funds, and the funds temporarily refunded to the account of the merchant are deducted again; if the chargeback is not approved, the merchant can keep the previously temporarily refunded funds, and the funds temporarily refunded to the account of the customer are deducted again. In a rare case in which there is a dispute of the acquiring institution or the card issuer as to whether the chargeback should be approved, the dispute can be escalated to a card organization for arbitration. In addition, in addition to the customer, the card issuer may actively initiate a chargeback for a suspicious transaction.

[0305] Currently, most digital wallets do not provide the above-mentioned chargeback function, or if a wallet has a similar function for initiating a dispute over completed payment, a process thereof is not the same as that of the above-mentioned chargeback function in card payment. In view of this, a processing system continues to be introduced for interfacing and integration so that a customer performing payment by using a digital wallet can also enjoy protection of the chargeback function. The following describes in detail a role that is acted by the processing system and that is similar as that of the card issuer in a chargeback process.

[0306] FIG. 22 shows a transaction link that is at a chargeback stage and that is based on the system architecture shown in FIG. 3 according to an embodiment of this specification. As shown in FIG. 22, the transaction link includes the following process steps at the chargeback stage.

[0307] Step S2201 : A first digital wallet sends a fund refunding request, including a transaction ID, to a processing system.

[0308] It is worthwhile to note that, for a transaction corresponding to the transaction ID in the fund refunding request, a service account of the processing system already transfers the second fund share M2to a card payment acquiring institution and deducts fundsequivalent to the second fund share M2from a corporate account of the first digital wallet. In addition, for content included in this paragraph, references can be made to the related descriptions of the authorization and capture stages in the above-mentioned embodiments, but are not limited thereto.

[0309] An initiator of the fund refunding request can be a user or the first digital wallet. Specifically, in an implementation case A, the user can initiate the fund refunding request through the first digital wallet, mainly for misrepresentation of goods, non-recognition of related payment, etc After receiving the fund refunding request from the user, the first digital wallet may independently determine, before submitting the request to the processing system, whether the request is reasonable, or may choose to directly submit all fund refunding requests to the processing system without any judgment. In another implementation case B, the first digital wallet can alternatively actively initiate a fund refunding request for a suspicious transaction.

[0310] On the other hand, for the above-mentioned two implementation cases, the first digital wallet can submit the fund refunding request by invoking different interfaces (or backend websites) provided by the processing system. In the implementation case A, the first digital wallet submits the fund refunding request by invoking a first interface provided by the processing system, where an initiator identification field transmitted to the first interface in a submission process is a first account, and the first account is a wallet account of the user corresponding to the transaction ID.

[0311] In the implementation case B, the first digital wallet can submit the fund refunding request by invoking a second interface provided by the processing system, where an initiator identification field transmitted to the second interface in a submission process is an identifier of the first digital wallet.

[0312] For example, the fund refunding request can further include an applied amount, which is part of paid funds for the transaction ID, for a refund that is applied, and / or some evidence materials, such as a photograph, a video, and a document.

[0313] The above describes content, the initiator, and an initiation way of the fund refunding request.

[0314] Step S2202: The processing system submits a chargeback request to the card payment acquiring institution based on the fund refunding request. For example, the processing system submits the chargeback request to a card organization so that the card organization forwards the chargeback request to the card payment acquiring institution.

[0315] It is worthwhile to note that the processing system can analyze the fund refunding request and then use content obtained through the analysis to generate a chargeback request that conforms to a data specification of the card payment acquiring institution.

[0316] Step S2203: The card payment acquiring institution sends, to the processing system, merchant feedback for the chargeback request.

[0317] It is worthwhile to note that interaction and processing between a card payment acquiring institution side and a merchant side are not limited in embodiments of this specification. In an example, references can be made to the previous descriptions of the chargeback process.

[0318] It can be understood that, the merchant feedback can include merchant acceptance of the chargeback or the merchant contesting / defending against the chargeback request.

[0319] Step S2204: The processing system determines, based on the merchant feedback, whether to approve the chargeback request.

[0320] In an implementation case, the merchant feedback includes merchant acceptance of the chargeback, and the processing system can directly determine, based on this, to approve the chargeback request.

[0321] In another implementation, the merchant feedback includes a contest request provided by the merchant, and the processing system can determine, based on related evidence information included in the contest request, whether to approve the chargeback of the customer. It is worthwhile to note that determining whether to approve the chargeback request in such an implementation case can be realized by using a trained machine learning model or a predetermined determining rule, and is not limited.

[0322] The above describes a basic processing process of the fund refunding request. It can be learned that the processing system realizes data and information transfer between the card payment acquiring institution and the first digital wallet, and in this case, in oneembodiment, the processing system can include a first device and a second device, where the first device is used to interact with the card payment acquiring institution, the second device is used to interact with the first digital wallet, and it can be understood that there is a communication connection established between the first device and the second device. Further, in an example, the first device and the card payment acquiring institution belong to a same regulatory area, and the second device and the first digital wallet belong to another regulatory area

[0323] Tn addition, a plurality of compensation policies are provided for compensation related to the fund refunding request in embodiments of this specification. Tn one compensation policy, the card payment acquiring institution deducts funds of a disputed transaction from an account of the merchant after receiving a chargeback request and transfers the funds to a service account. In this case, a service party can temporarily refund the funds for the disputed transaction to an account of an initiator before receiving the merchant feedback sent by the card payment acquiring institution for the chargeback request, or a service party can refund the funds to an initiator when determining, based on the merchant feedback, to approve the chargeback request.

[0324] In another compensation policy, a service party can compensate, after the user initiates a chargeback, the user in advance by advancing funds.

[0325] In still another compensation policy, a service party does not provide an advance, but rather the digital wallet compensates the user in advance by advancing funds.

[0326] To facilitate understanding, next, more detailed descriptions of a link of a chargeback process in a typical implementation scenario are provided in combination with the above-mentioned different compensation policies, and two types of initiators, namely, the user and the digital wallet. A chargeback initiator in an implementation scenario 1 to an implementation scenario 3 is the user, and a chargeback initiator in an implementation scenario 4 is the first digital wallet.

[0327] Implementation scenario 1: The service party compensates in advance before receiving feedback + the user initiates a chargeback

[0328] A link of a chargeback process in this implementation scenario can include thefollowing steps shown in FIG. 23.

[0329] Step S2300: The first digital wallet receives a fund refunding request, further including a transaction ID, initiated by the user based on a first account thereof.

[0330] Step S2301 : The first digital wallet submits the fund refunding request, including the transaction ID and the first account, by invoking a first interface provided by a processing system.

[0331] Step S2302: The processing system submits a chargeback request to a card payment acquiring institution based on the fund refunding request

[0332] Step S2303: The card payment acquiring institution deducts funds from an account of a merchant for a disputed transaction based on the chargeback request and transfers the funds to a service account.

[0333] Step S2304: The processing system transfers the funds for the disputed transaction to a corporate account of the first digital wallet based on the service account.

[0334] It is worthwhile to note that this step can be performed before or after the service account receives the funds transferred from the card payment acquiring institution. In one embodiment, the processing system can immediately transfer the funds for the disputed transaction to the corporate account of the first digital wallet after receiving the funds transferred from the card payment acquiring institution for the disputed transaction.

[0335] In another embodiment, the processing system can transfer the funds for the disputed transaction from the service account to the corporate account of the first digital wallet when receiving no merchant feedback returned from the card payment acquiring institution and within a predetermined time length range (for example, within 20 days) after submitting the chargeback request.

[0336] In still another embodiment, the processing system can immediately transfer the funds for the disputed transaction to the corporate account of the first digital wallet based on the service account after determining, based on the fund refunding request, that the chargeback initiated by the user is reasonable.

[0337] Step S2305 : The first digital wallet transfers the funds for the disputed transaction from the corporate account thereof to the first account.

[0338] Step S2306: The card payment acquiring institution sends, to the processing system, merchant feedback for the chargeback request.

[0339] Step S2307a: The processing system marks the fund refunding request as processing completed when determining, based on the merchant feedback, to approve the chargeback request, or when an appeal of the user succeeds.

[0340] Tn one implementation case, the processing system directly determines, based on merchant acceptance of the chargeback included in the merchant feedback, to approve the chargeback request. Tn another implementation case, the processing system determines, based on a defense request included in the merchant feedback, to approve the chargeback request

[0341] For example, the processing system can further send a compensation success notification to the first digital wallet.

[0342] Step S2307b: The processing system refunds the funds for the disputed transaction to an account of the card payment acquiring institution based on the service account when determining, based on the merchant feedback, not to approve the chargeback request, or when an appeal of the user fails.

[0343] Specifically, the processing system determines, based on a defense request included in the merchant feedback, not to approve the chargeback request, to trigger to refund the funds to the card payment acquiring institution.

[0344] Step S2308b: The processing system sends, to the first digital wallet, a recovery request for funds with which compensation is already performed.

[0345] Step S2309b: The first digital wallet deducts, from the first account based on the recovery request, the funds with which compensation is performed, and transfers the funds to the service account.

[0346] Tt should be understood that by performing step S2308b and step S2309b described above, the processing system subsequently recovers the funds from the first account, but actually may not perform recovery, this can be designed as needed, and details are omitted.

[0347] The above describes the chargeback process in the implementation scenario 1. In this process, when the user initiates a chargeback, the service party compensates, beforereceiving the merchant feedback, the user in advance with the funds deducted from the account of the merchant by the card payment acquiring institution.

[0348] Implementation scenario 2: The service party does not compensate in advance + the wallet does not advance funds for compensation + the user initiates a chargeback

[0349] A link of a chargeback process in this implementation scenario can include the following steps shown in FIG. 24.

[0350] Step S2400: The first digital wallet receives a fund refunding request, further including a transaction ID, initiated by the user based on a first account thereof.

[0351] Step S2401 : The first digital wallet submits the fund refunding request, including the transaction ID and the first account, by invoking a first interface provided by a processing system.

[0352] Step S2402: The processing system submits a chargeback request to a card payment acquiring institution based on the fund refunding request.

[0353] Step S2403: The card payment acquiring institution deducts funds for a disputed transaction from an account of a merchant based on the chargeback request and transfers the funds to a service account.

[0354] Step S2404: The card payment acquiring institution sends, to the processing system, merchant feedback for the chargeback request.

[0355] Step S2405a: The processing system transfers the funds for the disputed transaction to a corporate account of the first digital wallet when determining, based on the merchant feedback, to approve the chargeback request.

[0356] Step S2406a: The first digital wallet transfers the funds for the disputed transaction from the corporate account to the first account.

[0357] Step S2405b: The processing system sends an appeal failure notification to the first digital wallet when determining, based on the merchant feedback, not to approve the chargeback request.

[0358] Step S2406b: The processing system refunds the funds for the disputed transaction from the service account to an account of the card payment acquiring institution.

[0359] The above describes the chargeback process in the implementation scenario 2. Inthis process, when the user initiates a chargeback, the service party compensates, after determining, based on the merchant feedback, to approve the chargeback request, the user with the funds deducted from the account of the merchant by the card payment acquiring institution.

[0360] Implementation scenario 3: The wallet advances funds for compensation + the user initiates a chargeback

[0361] It can be understood that the service party does not compensate in advance before obtaining feedback A link of a specific chargeback process can include the following steps shown in FIG. 25

[0362] Step S2500: The first digital wallet receives a fund refunding request, further including a transaction ID, initiated by the user based on a first account thereof.

[0363] Step S2501: The first digital wallet acquires advanced funds as compensation payment based on a corporate account thereof, and transfers the compensation payment to the first account.

[0364] In one embodiment, the first digital wallet can compensate the user in advance when determining that the fund refunding request initiated by the user is reasonable, or in other words, when accepting a related appeal of the user; otherwise, does not perform compensation. When compensation is not performed, subsequent steps may continue to be performed, or the subsequent steps may not be performed, but an appeal failure notification may be sent to the first account.

[0365] In another embodiment, the first digital wallet may alternatively not determine whether the fund refunding request is reasonable, but directly perform compensation in advance.

[0366] Step S2502: The first digital wallet submits the fund refunding request, including the transaction ID and the first account, by invoking a first interface provided by a processing system.

[0367] Step S2503: The processing system submits a chargeback request to a card payment acquiring institution based on the fund refunding request.

[0368] Step S2504: The card payment acquiring institution deducts funds from anaccount of a merchant for a disputed transaction based on the chargeback request and transfers the funds to a service account.

[0369] Step S2505: The card payment acquiring institution sends, to the processing system, merchant feedback for the chargeback request.

[0370] Step S2506a: The processing system transfers the funds for the disputed transaction to a corporate account of the first digital wallet when determining, based on the merchant feedback, to approve the chargeback request.

[0371] For example, the processing system can further send a compensation success notification to the first digital wallet.

[0372] Step S2506b: The processing system sends an appeal failure notification to the first digital wallet when determining, based on the merchant feedback, not to approve the chargeback request.

[0373] It should be understood that the first digital wallet already advances compensation funds, whether to recover the compensation funds from the first account can be designed as needed, and details are omitted.

[0374] Step S2507b: The processing system refunds the funds for the disputed transaction from the service account to an account of the card payment acquiring institution.

[0375] The above describes the chargeback process in the implementation scenario 3. In this process, when the user initiates a chargeback, a wallet party compensates, before receiving a processing result from the card payment acquiring institution, the user in advance by advancing funds

[0376] Implementation scenario 4: The service party does not compensate in advance before receiving feedback + the wallet initiates a chargeback

[0377] A link of a chargeback process in this implementation scenario can include the following steps shown in FIG. 26.

[0378] Step S2601 : The first digital wallet initiates a fund refunding request, including a transaction ID and a chargeback amount, by invoking a second interface provided by a processing system.

[0379] Step S2602: The processing system submits a chargeback request to a cardpayment acquiring institution based on the fund refunding request.

[0380] Step S2603: The card payment acquiring institution deducts funds from an account of a merchant for a disputed transaction based on the chargeback request and transfers the funds to a service account.

[0381] Step S2604: The card payment acquiring institution sends, to the processing system, merchant feedback for the chargeback request.

[0382] Step S2605a: The processing system transfers the funds for the disputed transaction to a corporate account of the first digital wallet when determining, based on the merchant feedback, to approve the chargeback request.

[0383] For example, the processing system further marks the fund refunding request as processing completed and sends a compensation success notification to the first digital wallet.

[0384] Step S2605b: The processing system sends an appeal failure notification to the first digital wallet when determining, based on the merchant feedback, not to approve the chargeback request.

[0385] Step S2606b: The processing system refunds the funds for the disputed transaction from the service account to an account of the card payment acquiring institution.

[0386] The above describes the chargeback process in the implementation scenario 4. In this process, when the digital wallet initiates a chargeback, the processing system provides compensation payment for the digital wallet only after determining, based on the merchant feedback, that an appeal succeeds.

[0387] For the case in which the digital wallet initiates the chargeback, the processing system can alternatively compensate the digital wallet in advance with reference to the way in the implementation scenario 1. This processing way can be designed as needed with reference to the above-mentioned implementation scenarios and details are omitted.

[0388] The above describes an overall process of the chargeback stage with reference to different implementation scenarios after refinement.

[0389] Corresponding to the above-mentioned transaction service method, an embodiment of this specification also discloses a transaction service apparatus, integrated into a processing system. As shown in FIG. 27, the transaction service apparatus 2700includes the following functional modules:a first request receiving module 2701, configured to receive a first request from a card payment acquiring institution, where the first request is used to request an authorization freeze of funds and includes a transaction ID of a to-be-paid transaction and a first token; an account information determining module 2702, configured to determine a first account in a first digital wallet corresponding to the first token; and a second request sending module 2703, configured to send a second request, including the transaction ID and the first account, to the first digital wallet.

[0390] In one embodiment, the account information determining module 2702 is specifically configured to determine the first account in the first digital wallet corresponding to the first token, including: querying a prestored mapping relationship between a digital wallet account and a token, to obtain the first digital wallet and the first account.

[0391] In one embodiment, the first request further includes a first fund share; and the second request further includes a first amount determined based on the first fund share, and is used to request the first digital wallet to deduct the first amount of funds from the first account and transfer the funds to a service account corresponding to the processing system.

[0392] Further, in one specific embodiment, the transaction service apparatus 2700 further includes a third request receiving module, configured to receive a third request from the card payment acquiring institution, where the third request is used to capture funds and includes the transaction ID and a second fund share; and transfer funds corresponding to the second fund share to the card payment acquiring institution.

[0393] Further, in one example, the first request is a final authorization request, the first amount of funds are equivalent funds of the first fund share, and the second fund share is equal to the first fund share.

[0394] In another example, the first request is a pre-authorization request, the first amount of funds are equivalent funds of the first fund share, and the second fund share is greater than the first fund share. The transaction service apparatus 2700 further includes a fourth request sending module, configured to send a fourth request to the first digital wallet, where the fourth request is used to request the first digital wallet to initiate, to the first account,recovery of equivalent funds whose amount is a difference share between the second fund share and the first fund share.

[0395] In still another example, the first request is a pre-authorization request, the first amount of funds are more than equivalent funds of the first fund share, and the second fund share is equal to the first fund share. The transaction service apparatus 2700 further includes a fund refunding module, configured to refund difference funds between the first amount of funds and equivalent funds of the second fund share to the first account of the first digital wallet.

[0396] In yet another example, the first request is a pre-authorization request, the first amount of funds are more than equivalent funds of the first fund share, and the second fund share is greater than the first fund share. The transaction service apparatus 2700 further includes a fund refunding module, configured to: when the first amount of funds are more than equivalent funds of the second fund share, refund difference funds between the first amount of funds and the equivalent funds of the second fund share to the first account of the first digital wallet; and a fifth request sending module, configured to: when the first amount of funds are less than equivalent funds of the second fund share, send a fifth request to the first digital wallet, where the fifth request is used to request the first digital wallet to initiate, to the first account, recovery of an amount of difference funds between the equivalent funds of the second fund share and the first amount of funds.

[0397] In a further example, the first request is a pre-authorization request, the second fund share is less than the first fund share, and the transaction service apparatus 2700 further includes a fund refunding module, configured to refund difference funds between the first amount of funds and equivalent funds of the second fund share to the first account of the first digital wallet.

[0398] In another specific embodiment, the transaction service apparatus 2700 further includes a cancellation request receiving module, configured to receive, from the card payment acquiring institution, a cancellation request for the first request; and a fund refunding module, configured to refund the first amount of funds to the first account of the first digital wallet.

[0399] In still another specific embodiment, the transaction service apparatus 2700 further includes an incremental authorization request processing module, configured to receive, from the card payment acquiring institution, an incremental authorization request for the first request, where the incremental authorization request includes the transaction ID, an incremental fund share, and the first token; determine the first account in the first digital wallet corresponding to the first token; and send an incremental payment request to the first digital wallet, where the incremental payment request includes the transaction ID, the first account, and an incremental amount determined based on the incremental fund share, and is used to request the first digital wallet to deduct the incremental amount of funds from the first account and transfer the funds to the service account.

[0400] In yet another specific embodiment, the first fund share is an amount in a first currency, and the first amount is an amount in a second currency.

[0401] In one embodiment, the second request is used to request the first digital wallet to send, to a user of the first account, a notification associated with the first request. The transaction service apparatus 2700 further includes a third request receiving module, configured to receive a third request from the card payment acquiring institution, where the third request is used to capture funds and includes the transaction ID and a second fund share; a fund transfer module, configured to transfer funds corresponding to the second fund share to the card payment acquiring institution; and a sixth request sending module, configured to send a sixth request to the first digital wallet, where the sixth request includes the transaction ID, the first account, and a second amount determined based on the second fund share, and is used to request the first digital wallet to deduct the second amount of funds from the first account and transfer the funds to a service account corresponding to the processing system, where the second amount of funds are equivalent funds of the second fund share.

[0402] In one embodiment, the second request is used to indicate the first digital wallet to freeze at least part of funds of the first account.

[0403] Further, in one specific embodiment, the first request further includes a first fund share, and the second request further includes a first amount determined based on the first fund share, and is used to request the first digital wallet to freeze funds that are of the firstaccount and whose amount is not less than the first amount.

[0404] In another specific embodiment, the transaction service apparatus 2700 further includes a third request receiving module, configured to receive a third request from the card payment acquiring institution, where the third request is used to capture funds and includes the transaction ID and a second fund share; a fund transfer module, configured to transfer funds corresponding to the second fund share to the card payment acquiring institution; and a seventh request sending module, configured to send a seventh request to the first digital wallet, where the seventh request includes the transaction ID, the first account, and a second amount determined based on the second fund share, and is used to request the first digital wallet to unfreeze the first account, deduct the second amount of funds from the first account, and transfer the funds to the service account corresponding to the processing system, where the second amount of funds are equivalent funds of the second fund share.

[0405] In yet another specific embodiment, the transaction service apparatus 2700 further includes a cancellation request receiving module, configured to receive, from the card payment acquiring institution, a cancellation request for the first request; and an eighth request sending module, configured to send an eighth request to the first digital wallet, where the eighth request is used to request the first digital wallet to unfreeze the first account.

[0406] In one embodiment, the transaction service apparatus 2700 further includes a refunding request receiving module, configured to receive a fund refunding request from the first digital wallet, where the fund refunding request is used to apply for a refund of paid funds for a paid transaction and includes a transaction ID of the paid transaction; and a chargeback request sending module, configured to send, to the card payment acquiring institution based on the fund refunding request, a chargeback request related to the paid transaction

[0407] Further, in one specific embodiment, the transaction service apparatus 2700 further includes a feedback receiving module, configured to receive, from the card payment acquiring institution, feedback for the chargeback request; and a defense processing module, configured to: when the feedback includes a defense request for the chargeback request, determine, based on information included in the defense request, whether to approve thechargeback request.

[0408] Further, in one example, the transaction service apparatus 2700 further includes a compensation module, configured to acquire funds from the service account corresponding to the processing system and compensate an initiator of the fund refunding request.

[0409] In another example, the transaction service apparatus 2700 further includes a compensation module, configured to receive, in response to the chargeback request, funds refunded from the card payment acquiring institution, and compensate an initiator of the fund refunding request with the funds

[0410] According to one specific example, the transaction service apparatus 2700 further includes a ninth request sending module, configured to send a ninth request to the first digital wallet after determining not to approve the chargeback request, where the ninth request is used to request the first digital wallet to deduct, from an account of the initiator of the fund refunding request, the funds that the compensation is performed with, and transfer the funds to the service account corresponding to the processing system.

[0411] In another specific embodiment, the transaction service apparatus 2700 further includes a compensation module, configured to compensate, in response to the chargeback request after determining to approve the chargeback request, an initiator of the fund refunding request with the funds refunded from the card payment acquiring institution.

[0412] In one embodiment, the initiator of the fund refunding request includes the first digital wallet or a user of the first digital wallet.

[0413] The specification also provides a computer-readable non-transitory storage medium, where the storage medium stores a computer program, which, when executed by a processor, can be used to perform one or more steps of one or more methods described or illustrated herein or provides functionality described or illustrated herein Herein, the computer-readable non-transitory storage medium or media may include one or more semiconductor-based or other integrated circuits (ICs) (such, as for example, field-programmable gate arrays (FPGAs) or application-specific ICs (ASICs)), hard disk drives (HDDs), hybrid hard drives (HHDs), optical discs, optical disc drives (ODDs), magnetooptical discs, magneto-optical drives, floppy diskettes, floppy disk drives (FDDs), magnetictapes, solid-state drives (SSDs), RAM-drives, SECURE DIGITAL cards or drives, any other suitable computer-readable non-transitory storage media, or any suitable combination of two or more of these, where appropriate. A computer-readable non-transitory storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate.

[0414] The specification also provides a computer system. FIG 28 illustrates an example computer system 2800. Tn particular embodiments, one or more computer systems 2800 perform one or more steps of one or more methods described or illustrated herein. Tn particular embodiments, one or more computer systems 2800 provide functionality described or illustrated herein. In particular embodiments, software running on one or more computer systems 2800 performs one or more steps of one or more methods described or illustrated herein or provides functionality described or illustrated herein. Particular embodiments include one or more portions of one or more computer systems 2800. Herein, reference to a computer system may encompass a computing device, and vice versa, where appropriate. Moreover, reference to a computer system may encompass one or more computer systems, where appropriate.

[0415] This disclosure contemplates any suitable number of computer systems 2800. This disclosure contemplates computer system 2800 taking any suitable physical form. As example and not by way of limitation, computer system 2800 may be an embedded computer system, a system-on-chip (SOC), a single-board computer system (SBC) (such as, for example, a computer-on-module (COM) or system-on-module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a mesh of computer systems, a mobile telephone, a personal digital assistant (PDA), a server, a tablet computer system, or a combination of two or more of these Where appropriate, computer system 2800 may include one or more computer systems 2800; be unitary or distributed; span multiple locations; span multiple machines; span multiple data centers; or reside in a cloud, which may include one or more cloud components in one or more networks. Where appropriate, one or more computer systems 2800 may perform without substantial spatial or temporal limitation one or more steps of one or more methods described or illustrated herein.As an example and not by way of limitation, one or more computer systems 2800 may perform in real time or in batch mode one or more steps of one or more methods described or illustrated herein. One or more computer systems 2800 may perform at different times or at different locations one or more steps of one or more methods described or illustrated herein, where appropriate.

[0416] Tn particular embodiments, computer system 2800 includes a processor 2802, memory 2804, storage 2806, an input / output (T / O) interface 2808, a communication interface 2810, and a bus 2812. Although this disclosure describes and illustrates a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement.

[0417] In particular embodiments, processor 2802 includes hardware for executing instructions, such as those making up a computer program. As an example and not by way of limitation, to execute instructions, processor 2802 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 2804, or storage 2806; decode and execute them; and then write one or more results to an internal register, an internal cache, memory 2804, or storage 2806. In particular embodiments, processor 2802 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor 2802 including any suitable number of any suitable internal caches, where appropriate. As an example and not by way of limitation, processor 2802 may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLB s). Instructions in the instruction caches may be copies of instructions in memory 2804 or storage 2806, and the instruction caches may speed up retrieval of those instructions by processor 2802 Data in the data caches may be copies of data of 100 in memory 2804 or storage 2806 for instructions executing at processor 2802 to operate on; the results of previous instructions executed at processor 2802 for access by subsequent instructions executing at processor 2802 or for writing to memory 2804 or storage 2806; or other suitable data. The data caches may speed up read or write operations by processor 2802. The TLBs may speed up virtual -address translation for processor 2802. In particularembodiments, processor 2802 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates processor 2802 including any suitable number of any suitable internal registers, where appropriate. Where appropriate, processor 2802 may include one or more arithmetic logic units (ALUs); be a multi-core processor; or include one or more processors 2802. Although this disclosure describes and illustrates a particular processor, this disclosure contemplates any suitable processor.

[0418] In particular embodiments, memory 2804 includes main memory for storing instructions for processor 2802 to execute or data for processor 2802 to operate on. As an example and not by way of limitation, computer system 2800 may load instructions from storage 2806 or another source (such as, for example, another computer system 2800) to memory 2804. Processor 2802 may then load the instructions from memory 2804 to an internal register or internal cache. To execute the instructions, processor 2802 may retrieve the instructions from the internal register or internal cache and decode them. During or after execution of the instructions, processor 2802 may write one or more results (which may be intermediate or final results) to the internal register or internal cache. Processor 2802 may then write one or more of those results to memory 2804. In particular embodiments, processor 2802 executes only instructions in one or more internal registers or internal caches or in memory 2804 (as opposed to storage 2806 or elsewhere) and operates only on data in one or more internal registers or internal caches or in memory 2804 (as opposed to storage 2806 or elsewhere). One or more memory buses (which may each include an address bus and a data bus) may couple processor 2802 to memory 2804. Bus 2812 may include one or more memory buses, as described below In particular embodiments, one or more memory management units (MMUs) reside between processor 2802 and memory 2804 and facilitate accesses to memory 2804 requested by processor 2802. In particular embodiments, memory 2804 includes random access memory (RAM) This RAM may be volatile memory, where appropriate. Where appropriate, this RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, where appropriate, this RAM may be single-ported or multi-ported RAM. This disclosure contemplates any suitable RAM. Memory 2804 may include one or more memories 2804, where appropriate. Although this disclosure describes and illustratesparticular memory, this disclosure contemplates any suitable memory.

[0419] In particular embodiments, storage 2806 includes mass storage for data or instructions. As an example and not by way of limitation, storage 2806 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these Storage 2806 may include removable or non-removable (or fixed) media, where appropriate. Storage 2806 may be internal or external to computer system 2800, where appropriate In particular embodiments, storage 2806 is non-volatile, solid-state memory. In particular embodiments, storage 2806 includes read-only memory (ROM). Where appropriate, this ROM may be mask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these. This disclosure contemplates mass storage 2806 taking any suitable physical form. Storage 2806 may include one or more storage control units facilitating communication between processor 2802 and storage 2806, where appropriate. Where appropriate, storage 2806 may include one or more storages 2806. Although this disclosure describes and illustrates particular storage, this disclosure contemplates any suitable storage.

[0420] In particular embodiments, I / O interface 2808 includes hardware, software, or both, providing one or more interfaces for communication between computer system 2800 and one or more I / O devices. Computer system 2800 may include one or more of these I / O devices, where appropriate. One or more of these VO devices may enable communication between a person and computer system 2800. As an example and not by way of limitation, an I / O device may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, another suitable I / O device or a combination of two or more of these. An I / O device may include one or more sensors. This disclosure contemplates any suitable I / O devices and any suitable I / O interfaces 2808 for them. Where appropriate, VO interface 2808 may include one or more device or software drivers enabling processor 2802 to drive one or more of these VO devices. I / O interface 2808 may include one or more I / O interfaces 2808, where appropriate. Althoughthis disclosure describes and illustrates a particular I / O interface, this disclosure contemplates any suitable I / O interface.

[0421] In particular embodiments, communication interface 2810 includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) between computer system 2800 and one or more other computer systems 2800 or one or more networks. As an example and not by way of limitation, communication interface 2810 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. This disclosure contemplates any suitable network and any suitable communication interface 2810 for it. As an example and not by way of limitation, computer system 2800 may communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. As an example, computer system 2800 may communicate with a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WI-FI network, a WLMAX network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network), or other suitable wireless network or a combination of two or more of these. Computer system 2800 may include any suitable communication interface 2810 for any of these networks, where appropriate. Communication interface 2810 may include one or more communication interfaces 2810, where appropriate. Although this disclosure describes and illustrates a particular communication interface, this disclosure contemplates any suitable communication interface.

[0422] In particular embodiments, bus 2812 includes hardware, software, or both coupling components of computer system 2800 to each other. As an example and not by way of limitation, bus 2812 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, anINFINIBAND interconnect, a low-pin-count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a serial advanced technology attachment (SATA) bus, a Video Electronics Standards Association local (VLB) bus, or another suitable bus or a combination of two or more of these. Bus 2812 may include one or more buses 2812, where appropriate. Although this disclosure describes and illustrates a particular bus, this disclosure contemplates any suitable bus or interconnect.

[0423] A person skilled in the art should be aware that in the above-mentioned one or more examples, functions described in this application can be implemented by hardware, software, firmware, or any combination thereof. When being implemented by software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0424] In the above-mentioned specific implementations, the objectives, technical solutions, and beneficial effects of the present invention are further described in detail. It should be understood that the above descriptions are merely specific implementations of the present invention, but are not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, and the like made based on the technical solutions of the present invention shall fall within the protection scope of the present invention.

Claims

CLAIMS1. A method for performing request conversion between a card payment acquiring institution and a digital wallet, performed by a processing system and comprising:receiving a first request from the card payment acquiring institution, wherein the first request is used to request an authorization freeze of funds and comprises a transaction ID of a to-be-paid transaction and a first token;determining a first account in a first digital wallet corresponding to the first token; and sending a second request, comprising the transaction ID and the first account, to the first digital wallet.

2. The method according to claim 1, wherein the determining a first account in a first digital wallet corresponding to the first token comprises:querying a prestored mapping relationship between a digital wallet account and a token, to obtain the first digital wallet and the first account.

3. The method according to claim 1, wherein the first request further comprises a first fund share; andthe second request further comprises a first amount determined based on the first fund share, and is used to request the first digital wallet to deduct the first amount of funds from the first account and transfer the funds to a service account corresponding to the processing system.

4. The method according to claim 3, wherein after the sending a second request to the first digital wallet, the method further comprises:receiving a third request from the card payment acquiring institution, wherein the third request is used to capture funds and comprises the transaction ID and a second fund share; andtransferring funds corresponding to the second fund share to the card payment acquiring institution.

5. The method according to claim 4, wherein the first request is a final authorization request, the first amount of funds are equivalent funds of the first fund share, and the secondfund share is equal to the first fund share.

6. The method according to claim 4, wherein the first request is a pre-authorization request, the first amount of funds are equivalent funds of the first fund share, and the second fund share is greater than the first fund share; andthe method further comprises: sending a fourth request to the first digital wallet, wherein the fourth request is used to request the first digital wallet to initiate, to the first account, recovery of equivalent funds whose amount is a difference share between the second fund share and the first fund share.

7. The method according to claim 4, wherein the first request is a pre-authorization request, the first amount of funds are more than equivalent funds of the first fund share, and the second fund share is equal to the first fund share; andthe method further comprises: refunding difference funds between the first amount of funds and equivalent funds of the second fund share to the first account of the first digital wallet.

8. The method according to claim 4, wherein the first request is a pre-authorization request, the first amount of funds are more than equivalent funds of the first fund share, and the second fund share is greater than the first fund share; andthe method further comprises:when the first amount of funds are more than equivalent funds of the second fund share, refunding difference funds between the first amount of funds and the equivalent funds of the second fund share to the first account of the first digital wallet; andwhen the first amount of funds are less than equivalent funds of the second fund share, sending a fifth request to the first digital wallet, wherein the fifth request is used to request the first digital wallet to initiate, to the first account, recovery of an amount of difference funds between the equivalent funds of the second fund share and the first amount of funds.

9. The method according to claim 4, wherein the first request is a pre-authorization request, and the second fund share is less than the first fund share; andthe method further comprises: refunding difference funds between the first amount of funds and equivalent funds of the second fund share to the first account of the first digitalwallet.

10. The method according to claim 3, wherein the method further comprises: receiving, from the card payment acquiring institution, a cancellation request for the first request; andrefunding the first amount of funds to the first account of the first digital wallet.

11. The method according to claim 3, wherein the method further comprises: receiving, from the card payment acquiring institution, an incremental authorization request for the first request, wherein the incremental authorization request comprises the transaction ID, an incremental fund share, and the first token;determining the first account in the first digital wallet corresponding to the first token; andsending an incremental payment request to the first digital wallet, wherein the incremental payment request comprises the transaction ID, the first account, and an incremental amount determined based on the incremental fund share, and is used to request the first digital wallet to deduct the incremental amount of funds from the first account and transfer the funds to the service account.

12. The method according to claim 3, wherein the first fund share is an amount in a first currency, and the first amount is an amount in a second currency.

13. The method according to claim 1, wherein the second request is used to request the first digital wallet to send, to a user of the first account, a notification associated with the first request; andthe method further comprises:receiving a third request from the card payment acquiring institution, wherein the third request is used to capture funds and comprises the transaction ID and a second fund share;transferring funds corresponding to the second fund share to the card payment acquiring institution; andsending a sixth request to the first digital wallet, wherein the sixth request comprises the transaction ID, the first account, and a second amount determined based on the second fund share, and is used to request the first digital wallet to deduct the second amount of funds fromthe first account and transfer the funds to a service account corresponding to the processing system, wherein the second amount of funds are equivalent funds of the second fund share.

14. The method according to claim 1, wherein the second request is used to indicate the first digital wallet to freeze at least part of funds of the first account.

15. The method according to claim 14, wherein the first request further comprises a first fund share, and the second request further comprises a first amount determined based on the first fund share, and is used to request the first digital wallet to freeze funds that are of the first account and whose amount is not less than the first amount.

16. The method according to claim 14, wherein the method further comprises: receiving a third request from the card payment acquiring institution, wherein the third request is used to capture funds and comprises the transaction ID and a second fund share;transferring funds corresponding to the second fund share to the card payment acquiring institution; andsending a seventh request to the first digital wallet, wherein the seventh request comprises the transaction ID, the first account, and a second amount determined based on the second fund share, and is used to request the first digital wallet to unfreeze the first account, deduct the second amount of funds from the first account, and transfer the funds to a service account corresponding to the processing system, wherein the second amount of funds are equivalent funds of the second fund share.

17. The method according to claim 14, wherein the method further comprises: receiving, from the card payment acquiring institution, a cancellation request for the first request; andsending an eighth request to the first digital wallet, wherein the eighth request is used to request the first digital wallet to unfreeze the first account.

18. The method according to claim 1, wherein the method further comprises: receiving a fund refunding request from the first digital wallet, wherein the fund refunding request is used to apply for a refund of paid funds for a paid transaction and comprises a transaction ID of the paid transaction; andsending, to the card payment acquiring institution based on the fund refunding request,a chargeback request related to the paid transaction.

19. The method according to claim 18, wherein after the sending, to the card payment acquiring institution, a chargeback request related to the paid transaction, the method further comprises:receiving, from the card payment acquiring institution, feedback for the chargeback request; andwhen the feedback comprises a defense request for the chargeback request, determining, based on information comprised in the defense request, whether to approve the chargeback request.

20. The method according to claim 19, wherein after the receiving a fund refunding request from the first digital wallet, the method further comprises:obtaining funds from a service account corresponding to the processing system and compensating an initiator of the fund refunding request with the funds.

21. The method according to claim 19, after the sending, to the card payment acquiring institution, a chargeback request related to the paid transaction, the method further comprises:receiving, in response to the chargeback request, funds refunded from the card payment acquiring institution, and compensating an initiator of the fund refunding request with the funds.

22. The method according to claim 20 or 21, wherein the method further comprises: sending a ninth request to the first digital wallet after determining not to approve the chargeback request, wherein the ninth request is used to request the first digital wallet to deduct, from an account of the initiator of the fund refunding request, the funds that the compensation is performed with, and transfer the funds to the service account corresponding to the processing system.

23. The method according to claim 19, wherein the method further comprises: compensating, in response to the chargeback request after determining to approve the chargeback request, an initiator of the fund refunding request with the funds refunded from the card payment acquiring institution.

24. The method according to claim 18, wherein an initiator of the fund refunding requestcomprises the first digital wallet or a user of the first digital wallet.

25. An apparatus for performing request conversion between a card payment acquiring institution and a digital wallet, integrated in a processing system, wherein the apparatus comprises:a first request receiving module, configured to receive a first request from the card payment acquiring institution, wherein the first request is used to request an authorization freeze of funds and comprises a transaction ID of a to-be-paid transaction and a first token;an account information determining module, configured to determine a first account in a first digital wallet corresponding to the first token; anda second request sending module, configured to send a second request, comprising the transaction ID and the first account, to the first digital wallet.

26. A computer system, comprising a storage, a processor, and a computer program that is stored in the storage and that can run on the processor; and the processor performs the following steps:receiving a first request from the card payment acquiring institution, wherein the first request is used to request an authorization freeze of funds and comprises a transaction ID of a to-be-paid transaction and a first token;determining a first account in a first digital wallet corresponding to the first token; and sending a second request, comprising the transaction ID and the first account, to the first digital wallet.

27. A computer-readable nonvolatile storage medium, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 24 is implemented.

Images