Transaction processing method, device, apparatus, and storage medium

Abstract

The application provides a transaction processing method, device and equipment and a storage medium. The method comprises the following steps: a first business system acquires a transaction processing request sent by a second business system, wherein the processing request comprises a user identifier and a transaction amount; the user identifier is verified to determine whether the user identifier is a legal user in the first business system; and in the case that the user identifier is a legal user in the first business system, the user identifier is subjected to a deduction process in an associated account of the first business system according to the transaction amount. According to the application, the demand for expanding external transaction scenarios of a business system can be met, and the payment function is improved.

Description

Technical Field

[0001] This application relates to the field of payment technology, and in particular to a method, apparatus, equipment and storage medium for processing transaction business. Background Technology

[0002] Electronic payment is a monetary payment transaction that involves sending payment information to a processing institution using electronic means. With the development of internet technology, electronic payment has become a common method for processing transactions.

[0003] Currently, when processing transaction business through the business system, it relies on existing transaction scenarios and has a limited payment function. There is a need for a solution that can meet the requirements of expanding external transaction scenarios for the business system. Summary of the Invention

[0004] This application aims to at least partially address one of the technical problems in the related art.

[0005] Therefore, this application proposes a transaction processing method, apparatus, equipment, and storage medium that can meet the needs of expanding external transaction scenarios for business systems and improve payment functions.

[0006] The first aspect of this application provides a method for processing transaction business, including:

[0007] The first business system receives a transaction processing request sent by the second business system, wherein the processing request includes a user identifier and a transaction amount;

[0008] The user identifier is verified to determine whether the user identifier is a legitimate user in the first business system;

[0009] If the user identifier is a legitimate user in the first business system, the transaction amount will be deducted from the user identifier's associated account in the first business system.

[0010] A second aspect of this application provides a transaction processing apparatus, comprising:

[0011] The acquisition module is used by the first business system to acquire a transaction processing request sent by the second business system, wherein the processing request includes a user identifier and a transaction amount;

[0012] The verification module is used to verify the user identifier to determine whether the user identifier is a legitimate user in the first business system;

[0013] The transaction module is used to deduct funds from the user's associated account in the first business system based on the transaction amount when the user is identified as a legitimate user in the first business system.

[0014] A third aspect of this application provides an electronic device including at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a transaction processing method as described in the first aspect embodiment.

[0015] A fourth aspect of this application provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform a transaction processing method as described in the first aspect embodiment.

[0016] An embodiment of the above application has the following advantages or beneficial effects: by obtaining a transaction processing request sent by the second business system through the first business system, verifying the user identifier in the processing request to determine whether the user identifier is a legitimate user in the first business system, and deducting the amount from the associated account of the user identifier in the first business system according to the transaction amount in the processing request, it can meet the needs of expanding external transaction scenarios for the business system and improve the payment function.

[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0018] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this application. Wherein:

[0019] Figure 1 A flowchart illustrating a transaction processing method provided in an embodiment of this application;

[0020] Figure 2 A flowchart illustrating another transaction processing method provided in this application embodiment;

[0021] Figure 3 A flowchart illustrating another transaction processing method provided in this application embodiment;

[0022] Figure 4 A schematic diagram of the structure of a transaction processing device provided in an embodiment of this application;

[0023] Figure 5 A block diagram is shown that is suitable for implementing an exemplary electronic device according to embodiments of the present application. Detailed Implementation

[0024] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0025] Figure 1 The following is a flowchart illustrating a transaction processing method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes:

[0026] Step 101: The first business system obtains the transaction processing request sent by the second business system, wherein the processing request includes the user identifier and the transaction amount.

[0027] The method described in this application embodiment can be applied to transaction processing in scenarios where an external transaction is expanded for a first business system.

[0028] In this embodiment of the application, the second business system sends a transaction processing request to the first business system. For example, when a user initiates a transaction, the merchant's acquiring institution sends the transaction information to the second business system, the second business system generates a transaction processing request, and sends the transaction processing request to the first business system.

[0029] The first business system can be a system that supports transaction business. For example, the first business system can process transaction business through a mobile wallet.

[0030] The second business system is used to expand external transaction scenarios for the first business system. Optionally, to expand external transaction scenarios, the first business system binds the user's existing first business system account to the second business system and displays it as a quick card to support transaction processing for payment scenarios in the second business system. The second business system can be, for example, UnionPay payment.

[0031] User identifiers are used to indicate a user's identity. User identifiers may include the user's account name (e.g., the user's account name in the first business system) and characters assigned to the user.

[0032] Step 102: Verify the user identifier to determine whether the user identifier is a legitimate user in the first business system.

[0033] In this embodiment, the correspondence between user identifiers and user categories can be determined. User categories include legitimate users and illegitimate users. The first business system parses the transaction business processing request to obtain the user identifier carried in the processing request, and determines whether the user identifier is a legitimate user in the first business system based on the parsed user identifier and the correspondence.

[0034] As an example, the first business system can perform verification based on the user identifier to determine the status of the account corresponding to the user identifier in the first business system. The status of the account may include whether it is available, whether the authentication information is complete, etc., and determine whether the user identifier is a legitimate user in the first business system based on the status of the account.

[0035] As another example, the first business system can further determine whether the type corresponding to the processing request is a transaction business type associated with the second business system. If it is determined that the corresponding type is a transaction business type associated with the second business system, the user is identified as a legitimate user in the first business system.

[0036] In this embodiment, when the first business system receives a transaction processing request sent by the second business system, it can determine whether to execute the transaction processing request. Specifically, the user identifier in the processing request is verified to determine whether the user identifier is a legitimate user in the first business system. If it is determined that the user identifier is not a legitimate user in the first business system, the transaction processing request sent by the second business system is not executed.

[0037] Step 103: If the user is identified as a legitimate user in the first business system, deduct the amount from the associated account of the user in the first business system based on the transaction amount.

[0038] In this embodiment, the first business system includes associated accounts corresponding to user identifiers. Each user identifier may correspond to one or more associated accounts, which are used for deduction processing. For example, associated accounts may be bank cards, credit cards, etc. When a user identifier is a legitimate user in the first business system, the first business system parses and processes the request to obtain the transaction amount and may deduct an amount equal to the transaction amount from the associated accounts.

[0039] In one embodiment of this application, a user identifier may correspond to multiple associated accounts in a first business system. When processing a deduction, one of the multiple associated accounts can be selected for the deduction. In this embodiment, processing the deduction of the user identifier's associated account in the first business system based on the transaction amount includes: obtaining the user identifier's associated accounts in the first business system and the priority information between the associated accounts; determining the target associated account to be deducted based on the priority information; and processing the deduction of the target associated account.

[0040] In this system, user identifiers are associated with priority information among the linked accounts. Based on this priority information, the highest-priority target linked account can be determined, and the deduction can be processed from that account. Optionally, after determining the highest-priority target linked account, if the amount in that account is insufficient, the target linked account can be determined from the remaining linked accounts in descending order of priority, and the deduction can be processed from that account.

[0041] The transaction processing method of this application embodiment obtains a transaction processing request sent by a second business system through a first business system, verifies the user identifier in the processing request to determine whether the user identifier is a legitimate user in the first business system, and deducts funds from the associated account of the user identifier in the first business system according to the transaction amount in the processing request if the user identifier is a legitimate user in the first business system. According to the solution of this application, the first business system can deduct funds from the associated account based on the transaction processing request sent by the second business system, meeting the need to expand external transaction scenarios for the business system and improving payment functionality.

[0042] Based on the above embodiments, in order to expand the external transaction scenarios of the first business system, before the first business system obtains the transaction business processing request sent by the second business system, the user identifier and the second business system can be bound. The business system binding process is described below. Figure 2 The following is a flowchart illustrating a transaction processing method provided in an embodiment of this application, as shown below. Figure 2 As shown, the method also includes:

[0043] Step 201: The first business system sends a binding request to the second business system. The binding request includes the user's four-element information in the first business system.

[0044] In this embodiment, the user can trigger the first business system to send a binding request to the second business system. The four key elements of user information—card number, name, ID number, and phone number—are used to verify the authenticity of the user's information.

[0045] As an example, the first business system's display interface includes a "Bind" button. Users can click the "Bind" button and check the agreement. In response to this click, the page displays an authentication prompt, such as a prompt for the user to enter their payment password. Once authentication is successful, the first business system sends the user's four key identity documents to the second business system via an interface.

[0046] Step 202: Obtain the serial number returned by the second business system.

[0047] In this embodiment, the second business system receives the four-element information and generates a serial number. The second business system sends the serial number to the first business system so that the first business system can obtain the page based on the serial number.

[0048] Step 203: Obtain the binding page in the second business system based on the serial number.

[0049] The binding page can be a page in the second business system, used to display the user's four-element information in the first business system.

[0050] Step 204: In response to the obtained binding verification instruction, send binding verification information to the second business system.

[0051] Optionally, a binding button can be set on the binding page to trigger the binding process. Binding verification instructions may include, for example, a verification code entered by the user on the binding page. This verification code can be sent from the second business system to the user's mobile terminal or the first business system. When the user enters the verification code on the binding page, the first business system, in response to the received verification code, sends it to the second business system so that the second business system receives the verification code and verifies its validity.

[0052] Step 205: Obtain the binding result returned by the second business system and determine the binding status between the user identifier and the second business system.

[0053] In this embodiment, the second business system receives the verification code and verifies its validity. If the verification code is valid, the binding is considered successful; otherwise, the binding is considered unsuccessful. The second business system generates a binding result and sends it to the first business system. The first business system determines the binding status between the user's corresponding user identifier and the second business system based on the binding result and displays it.

[0054] In one embodiment of this application, before the first business system sends a binding request to the second business system, the method further includes: determining that the user is a preset user in the first business system.

[0055] In the business system, users can be divided into multiple categories, such as debit cards, credit cards, virtual cards, etc., and users are pre-defined to belong to one or more of these categories.

[0056] In this embodiment, if the user is determined to be a preset user, the condition for binding the execution user identifier with the second business system is met; if the user is determined not to be a preset user, the condition for binding the execution user identifier with the second business system is not met. Thus, it is possible to avoid binding users who do not meet the conditions to the second business system.

[0057] In one embodiment of this application, before the first business system sends a binding request to the second business system, the method further includes: determining that the device currently in which the first business system is located is a legitimate device and that the network type currently used by the device is a specified type.

[0058] Specifically, if the current device is determined to be a legitimate device and the network type currently used by the device is the specified type, then the conditions for binding the user identifier with the second business system are met. Otherwise, the binding of the user identifier with the second business system is refused.

[0059] Optionally, it can be determined whether the device currently in use by the first business system is a frequently used device by the user. If it is determined to be a frequently used device, the device is deemed legitimate. Optionally, it can be determined whether the device currently in use is a frequently used device by the user based on the device's unique identifier and IP address. Network types include, for example, personal mobile networks, home wireless networks, etc., and the specified type belongs to one or more of multiple network types.

[0060] For example, the following explanation uses the second business system, which includes an application, as an example.

[0061] In the first business system, if risk control information determines that no interception will be executed, that the user is a preset user in the first business system, that the device currently in the first business system is a legitimate device, that the network type currently used by the device is a specified type, and that the user's real-name authentication document type is an ID card, then a button for binding the user identifier to the second business system is displayed. The button triggers a payment password verification layer. After successful verification, the first business system sends four-factor information to the application of the second business system through an interface. The application of the second business system returns a serial number. The first business system then redirects to the application's binding page based on the serial number. The binding interface displays the four-factor information, and binding verification is triggered through the binding interface. If the verification passes, the account is bound. This expands the external transaction scenarios for the first business system, binding the user's account in the first business system to the application and displaying it as a quick card to support transactions in the application's payment scenarios.

[0062] In this embodiment, the first business system sends a binding request to the second business system, obtains the serial number returned by the second business system, obtains the binding page in the second business system based on the serial number, sends binding verification information to the second business system, and obtains the binding result returned by the second business system to determine the binding status between the user identifier and the second business system. This enables the binding of the user identifier with the second business system. For example, it can expand the external transaction scenario for the first business system that has been bound to a mobile wallet, thus meeting the need for the business system to expand the external transaction scenario.

[0063] In practical applications, there are usually multiple transaction types such as online payment and physical store payment. Based on the above embodiments, this embodiment can deduct funds from associated accounts according to the associated accounts associated with the transaction type and the priority information between the associated accounts. Figure 3 The following is a flowchart illustrating a transaction processing method provided in an embodiment of this application, as shown below. Figure 3 As shown, the method of deducting funds from the user's associated account in the first business system based on the transaction amount includes:

[0064] Step 301: Obtain the user identifier associated with each related account and the priority information between each related account in the first business system.

[0065] In this embodiment, the processing request also includes a transaction type, which is used to indicate different transaction scenarios. The transaction type may include online payment, physical store payment, or payment through a certain platform. For different transaction types, users can set different accounts to make payments.

[0066] In the first business system, for a user identifier, associated accounts can be set for each transaction type, and each transaction type can have one or more associated accounts.

[0067] Priority information among linked accounts can be determined based on the account's payment frequency and account balance.

[0068] Step 302: Determine the target associated account to be deducted based on priority information.

[0069] Step 303: Deduct funds from the target associated account.

[0070] Specifically, the highest-priority target associated account is determined from all associated accounts linked to the transaction type, and the deduction is processed from the target associated account. Optionally, after determining the highest-priority target associated account, if the amount in the highest-priority associated account is insufficient, the target associated account can be determined from the remaining associated accounts in descending order of priority, and the deduction can be processed from the target associated account.

[0071] In this embodiment of the application, by obtaining the associated accounts of each transaction type and the priority information between each associated account, and performing deduction processing according to the priority information, the needs of users to use different accounts for payment under different transaction types can be met, thus improving the payment function.

[0072] To implement the above embodiments, this application also proposes a transaction processing apparatus.

[0073] Figure 4This is a schematic diagram of the structure of a transaction processing apparatus provided in an embodiment of this application, as shown below. Figure 4 As shown, the device includes: an acquisition module 10, a verification module 20, and a transaction module 30.

[0074] The acquisition module 10 is used by the first business system to acquire a transaction processing request sent by the second business system, wherein the processing request includes a user identifier and a transaction amount.

[0075] The verification module 20 is used to verify the user identifier to determine whether the user identifier is a legitimate user in the first business system.

[0076] The transaction module 30 is used to deduct funds from the associated account of the user in the first business system based on the transaction amount when the user identifier is a legitimate user in the first business system.

[0077] In one embodiment of this application, the transaction module 30 is specifically used to: obtain the user identifier in the first business system for each associated account and the priority information between each associated account; determine the target associated account to be deducted based on the priority information; and deduct the payment from the target associated account.

[0078] In one embodiment of this application, the processing request further includes a transaction type, and the transaction module 30 is specifically used to: obtain the associated accounts of the user identifier in the first business system associated with the transaction type and the priority information between the associated accounts; determine the target associated account to be deducted based on the priority information; and deduct the payment from the target associated account.

[0079] In one embodiment of this application, the device further includes: a binding module, configured to: send a binding request from the first business system to the second business system, the binding request including the user's four-factor information in the first business system; obtain a serial number returned by the second business system; obtain a binding page in the second business system based on the serial number, wherein the binding page is used to display the user's four-factor information in the first business system; send binding verification information to the second business system in response to a obtained binding verification instruction; obtain a binding result returned by the second business system, and determine the binding status of the user identifier with the second business system.

[0080] In one embodiment of this application, the device further includes: a first determining module, configured to determine that the user is a preset user in the first business system.

[0081] In one embodiment of this application, the apparatus further includes: a second determining module, configured to determine that the device currently in which the first business system is located is a legitimate device and that the network type currently used by the device is a specified type.

[0082] The explanations and descriptions of the transaction processing methods in the foregoing embodiments also apply to the transaction processing apparatus of this embodiment, and will not be repeated here.

[0083] The transaction processing apparatus of this application embodiment obtains a transaction processing request sent by a second business system through a first business system, verifies the user identifier in the processing request to determine whether the user identifier is a legitimate user in the first business system, and deducts funds from the associated account of the user identifier in the first business system according to the transaction amount in the processing request. According to the solution of this application, the first business system can deduct funds from the associated account based on the transaction processing request sent by the second business system, meeting the need to expand external transaction scenarios for the business system and improving payment functionality.

[0084] To implement the above embodiments, this application also proposes an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the transaction processing method proposed in the foregoing embodiments of this application.

[0085] To implement the above embodiments, this application also proposes a non-transitory computer-readable storage medium storing a computer program, which, when executed by a processor, implements the transaction processing method proposed in the foregoing embodiments of this application.

[0086] To implement the above embodiments, this application also proposes a computer program product that, when the instruction processor in the computer program product is executed, performs the transaction processing method as proposed in the foregoing embodiments of this application.

[0087] To implement the above embodiments, this application also proposes an electronic device.

[0088] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0089] like Figure 5 As shown, the above-mentioned electronic device 200 includes:

[0090] The memory 210 and processor 220 are connected by a bus 230, which connects different components (including the memory 210 and the processor 220). The memory 210 stores a computer program, and when the processor 220 executes the program, it implements the transaction processing method described in the embodiments of this application.

[0091] Bus 230 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. Examples of these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0092] Electronic device 200 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 200, including volatile and non-volatile media, removable and non-removable media.

[0093] Memory 210 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 240 and / or cache memory 250. Electronic device 200 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 260 may be used to read and write non-removable, non-volatile magnetic media (… Figure 5 Not shown; usually referred to as a "hard drive"). Although Figure 5 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 230 via one or more data media interfaces. Memory 210 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0094] A program / utility 280 having a set (at least one) of program modules 270 may be stored in, for example, memory 210. Such program modules 270 include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 270 typically perform the functions and / or methods described in the embodiments of this application.

[0095] Electronic device 200 can also communicate with one or more external devices 290 (e.g., keyboard, pointing device, display 291, etc.), and with one or more devices that enable a user to interact with electronic device 200, and / or with any device that enables electronic device 200 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 292. Furthermore, electronic device 200 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 293. As shown, network adapter 293 communicates with other modules of electronic device 200 via bus 230. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 200, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0096] The processor 220 performs various functional applications and data processing by running programs stored in the memory 210.

[0097] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the transaction processing method in the embodiment of this application, and will not be repeated here.

[0098] The electronic device provided in this application embodiment can perform the transaction processing method described above.

[0099] To implement the above embodiments, this application also proposes a computer-readable storage medium.

[0100] The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the transaction processing method described in the embodiments of this application.

[0101] To implement the above embodiments, another aspect of this application provides a computer program that, when executed by a processor, implements the transaction processing method described in the embodiments of this application.

[0102] In one alternative implementation, this embodiment may employ any combination of one or more computer-readable media. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0103] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0104] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0105] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's electronic device, partially on the user's electronic device, as a standalone software package, partially on the user's electronic device and partially on a remote electronic device, or entirely on a remote electronic device or server. In cases involving remote electronic devices, the remote electronic device can be connected to the user's electronic device via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external electronic device (e.g., via the Internet using an Internet service provider).

[0106] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention filed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not invented herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0107] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method of processing a transaction service, characterized by, The method comprises the following steps: A first business system acquires a transaction business processing request sent by a second business system, wherein the processing request comprises a user identifier and a transaction amount, the second business system is a UnionPay payment, and the second business system is used to expand external transaction scene modes for the first business system, wherein the transaction business processing request is generated by the second business system according to transaction information sent by an acquirer, and the first business system processes transaction business through a mobile wallet; The user identifier is verified to determine whether the user identifier is a legal user in the first business system; In the case that the user identifier is a legal user in the first business system, the associated account of the user identifier in the first business system is debited according to the transaction amount; Before the first business system acquires the transaction business processing request sent by the second business system, the method further comprises the following steps: The first business system sends a binding request to the second business system, wherein the binding request comprises four-element information of the user in the first business system; A serial number returned by the second business system is acquired; A binding page in the second business system is acquired based on the serial number, wherein the binding page is used to display the four-element information of the user in the first business system; Binding verification information is sent to the second business system in response to the acquired binding verification instruction; A binding result returned by the second business system is acquired to determine the binding state of the user identifier and the second business system; After the first business system is bound to the second business system, the first business system is displayed in the form of a quick card in the second business system to support transaction business of the second business system payment scene; The method further comprises the following steps: Each associated account of the user identifier in the first business system and the priority information between each associated account are acquired; A target associated account to be debited is determined according to the priority information; The target associated account is debited.

2. The method of claim 1, wherein, The processing request further comprises a transaction type, and the method further comprises the following steps: Each associated account of the user identifier in the first business system associated with the transaction type and the priority information between each associated account are acquired; A target associated account to be debited is determined according to the priority information; The target associated account is debited.

3. The method according to any one of claims 1 to 2, wherein, Before the first business system sends the binding request to the second business system, the method further comprises the following steps: It is determined that the user is a preset user in the first business system.

4. The method according to any one of claims 1 to 2, wherein Before the first business system sends the binding request to the second business system, the method further comprises the following steps: It is determined that the device currently used by the first business system is a legal device, and the network type of the device is a specified type.

5. A processing apparatus of a transaction service, characterized by comprising: The method comprises the following steps: The acquisition module is configured to acquire, by a first business system, a transaction service processing request sent by a second business system, wherein the processing request comprises a user identifier and a transaction amount, the second business system is a UnionPay payment, and the second business system is configured to expand an external transaction scenario mode for the first business system, the transaction service processing request is generated by the second business system according to transaction information sent by an acquirer, and the first business system processes a transaction service through a mobile wallet. The verification module is configured to verify the user identifier to determine whether the user identifier is a legal user in the first business system. The transaction module is configured to, in a case where the user identifier is a legal user in the first business system, perform a deduction processing on an associated account of the user identifier in the first business system according to the transaction amount. The device further comprises: The binding module is configured to send, by the first business system, a binding request to the second business system, wherein the binding request comprises four-element information of the user in the first business system. The sequence number returned by the second business system is acquired. The binding page in the second business system is acquired based on the sequence number, wherein the binding page is configured to display the four-element information of the user in the first business system. Binding verification information is sent to the second business system in response to the acquired binding verification instruction. The binding result returned by the second business system is acquired to determine a binding state of the user identifier and the second business system. After the first business system is bound to the second business system, the first business system is displayed in the second business system in the form of a quick card to support transaction services of the second business system payment scenario. The transaction module is specifically configured to: Acquire each associated account of the user identifier in the first business system and priority information between the associated accounts. Determine a target associated account to be deducted according to the priority information. Perform a deduction processing on the target associated account.

6. The apparatus of claim 5, wherein, The processing request further comprises a transaction type, and the transaction module is specifically configured to: Acquire each associated account of the user identifier in the first business system and priority information between the associated accounts. Determine a target associated account to be deducted according to the priority information. Perform a deduction processing on the target associated account.

7. The device of any of claims 5-6, wherein, Further comprising: The first determination module is configured to determine that the user is a preset user in the first business system.

8. The apparatus of any one of claims 5-6, wherein, Further comprising: The second determination module is configured to determine that a device currently used by the first business system is a legal device and a network type currently used by the device is a specified type.

9. An electronic device comprising: at least one processor; and a memory connected with the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the transaction service processing method in any one of claims 1-4. ​ 10. A non-transitory computer readable storage medium storing computer instructions for causing a computer to perform the processing method of the transaction service of any one of claims 1-4.

Images