Virtual resource processing method, device and equipment, computer readable storage medium and computer program product

Abstract

The invention provides a virtual resource processing method and device, electronic equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: in response to a customer, selecting a payment mode for a merchant as a target payment mode, jumping from a merchant platform to an acquirer platform corresponding to the target payment mode, and displaying a payment order in the acquirer platform; in response to a selection operation for a payment bank, displaying collection account information of the merchant; in response to a copy operation for the payment account information, skipping to a payment page of a payment bank from the acquirer platform, and displaying collection account information in the payment page; and in response to payment operation triggered based on the payment page, transferring the virtual resource of the payment amount from the payment account to a transition account associated with the collection account, and transferring the virtual resource of the payment amount from the transition account to the collection account under the condition that the risk identification of the acquirer platform on the payment account is passed. According to the invention, the security of the collection account can be improved.

Description

Technical Field

[0001] This application relates to the field of information processing technology, and in particular to a method, apparatus, device, storage medium, and program product for processing virtual resources. Background Technology

[0002] Currently, when customers pay for transactions purchased on merchant platforms, they can do so directly through bank transfers. For example, if a customer transfers funds directly from their paying bank to the receiving bank, the receiving bank will immediately credit the funds to the merchant's account at that bank. However, if the customer's payment is at risk (e.g., the paying account is an illegal or fraudulent card), the inflow of these funds into the receiving account will contaminate it. Summary of the Invention

[0003] This application provides a method, apparatus, electronic device, computer-readable storage medium, and computer program product for processing virtual resources, which can improve the security of receiving accounts.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a method for processing virtual resources, including:

[0006] In response to a customer selecting the target payment method for a merchant, the merchant platform redirects the user to the acquiring platform corresponding to the target payment method, and displays the payment order pushed by the merchant platform on the acquiring platform.

[0007] In response to the selection of a payment bank associated with the acquiring platform, the merchant's receiving account information is displayed, which includes at least one of the following: payee name, payee account, payee bank, payment amount, and order remarks;

[0008] In response to the copying operation of the payment account information, the acquiring platform redirects to the payment page of the paying bank, and displays the receiving account information on the payment page;

[0009] In response to a payment operation triggered by the payment page, the virtual resources of the payment amount are transferred from the payment account associated with the payment bank to the transit account associated with the receiving account. If the acquiring platform passes the risk identification of the payment account, the virtual resources of the payment amount are transferred from the transit account to the receiving account.

[0010] This application provides a virtual resource processing apparatus, including:

[0011] The payment order display module is configured to, in response to selection of a payment method of a merchant by a customer as a target payment method, jump, by a merchant platform, to an acquirer platform corresponding to the target payment method, and display a payment order pushed by the merchant platform in the acquirer platform.

[0012] The account information display module is configured to, in response to a selection operation for a payment bank associated with the acquirer platform, display payment account information of the merchant, the payment account information including at least one of a payment account holder, a payment account, a payment bank, a payment amount, and an order note.

[0013] The payment page display module is configured to, in response to a copy operation for the payment account information, jump, by the acquirer platform, to a payment page of the payment bank, and display the payment account information in the payment page.

[0014] The resource transfer processing module is configured to, in response to a payment operation triggered based on the payment page, transfer virtual resources of the payment amount from a payment account associated with the payment bank to a transition account associated with the payment account, and, in a case where risk identification of the payment account by the acquirer platform is passed, transfer the virtual resources of the payment amount from the transition account to the payment account.

[0015] In the above scheme, the resource transfer processing module is further configured to, in a case where risk identification of the payment account by the acquirer platform is not passed, return the virtual resources of the payment amount from the transition account to the payment account, and send, by the acquirer platform, a payment failure prompt information to a customer corresponding to the payment account, the payment failure prompt information being configured to prompt a reason for payment failure.

[0016] In the above scheme, before jumping, in response to selection of a payment method of a merchant as a target payment method, to an acquirer platform corresponding to the target payment method, the device further includes a registration module configured to, in response to a registration operation of the merchant for the acquirer platform triggered by the merchant platform, open a custody account for payment of the merchant in the payment bank associated with the acquirer platform; wherein the custody account includes the transition account and the payment account having an association relationship.

[0017] In the scheme, before the jumping to the payment page of the target payment method corresponding to the target payment method, the device further comprises a payment method determination module configured to: in response to a purchase operation of a transaction object in the merchant platform by a user corresponding to the payment account, determine a payment order generated by the merchant platform for the transaction object, and display a plurality of candidate payment methods available for the payment of the payment order; and in response to a selection operation of a target payment method from the plurality of candidate payment methods, set the target payment method as a payment method used by the user to pay the merchant.

[0018] In the scheme, the payment page display module is further configured to: in response to the copy operation on the payment account information, start a bank application corresponding to the payment bank, and jump to the payment page of the started bank application from the acquirer platform.

[0019] In the scheme, the payment page display module is further configured to: in response to the copy operation on the payment account information, exit the acquirer platform; and in response to an opening operation on the bank application corresponding to the payment bank, display a payment page of the bank application and fill the payment account information into the payment page.

[0020] In the scheme, the resource transfer processing module is further configured to: in a case where the risk identification of the payment account and the risk identification of the payment account by the acquirer platform are both passed, transfer the virtual resource of the payment amount from the transition account to the payment account.

[0021] In the scheme, before the transferring the virtual resource of the payment amount from the transition account to the payment account, the resource transfer processing module is further configured to: perform a legality detection on the payment account through the acquirer platform to obtain a legality detection result, and detect whether the payment account triggers a preset risk rule to obtain a rule detection result; in a case where at least one of the legality detection result indicating that the payment account is a legal account and the rule detection result indicating that the payment account does not trigger the preset risk rule is satisfied, determine that the risk identification of the payment account by the acquirer platform is passed; and in a case where at least one of the legality detection result indicating that the payment account is an illegal account and the rule detection result indicating that the payment account triggers the preset risk rule is satisfied, determine that the risk identification of the payment account by the acquirer platform is not passed.

[0022] In the scheme, the resource transfer processing module is further configured to determine that the payment account is a potential risk account when at least one of the following conditions is met: the legitimacy detection result indicates that the payment account is a potential illegal account, or the rule detection result indicates that the payment account has a potential condition triggering the preset risk rule; and send a risk warning prompt information to the payment account through the acquirer platform; wherein the risk warning prompt information is used to prompt the reason why the payment account is a potential risk account, and provide a proof channel for proving that the payment account is not a potential risk account; in response to the fact that the customer submits proof materials through the proof channel, control the acquirer platform to verify the reason why the payment account has a potential risk based on the proof materials, and determine that the risk identification of the payment account by the acquirer platform is passed when the verification result indicates that the payment account is not a potential risk account.

[0023] In the scheme, before the virtual resource of the payment amount is transferred from the transition account to the payment account, the resource transfer processing module is further configured to perform risk identification on the payment account through the acquirer platform in response to the fact that the triggering time of the payment operation is not within the valid period of the risk assessment corresponding to the payment account; wherein the valid period is determined based on the transaction frequency of the payment account on the merchant platform.

[0024] In the scheme, when the resource transfer processing module includes a stage payment option in the payment page, in response to a stage payment operation triggered based on the stage payment option, for each payment stage, the virtual resource of a part of the amount indicated by the payment stage is transferred from the payment account associated with the payment bank to the transition account associated with the payment account, and when the risk identification of the payment account by the acquirer platform in the payment stage is passed, the virtual resource of the part of the amount is transferred from the transition account to the payment account; wherein the total amount of the part of the amount corresponding to each payment stage is the payment amount.

[0025] In the scheme, before the virtual resource of the payment amount is transferred from the transition account to the payment account, the resource transfer processing module is further configured to determine an account parameter that affects the risk level of the payment account, the account parameter including at least one of the following: historical transaction records, credit rating, and account activity level, the historical transaction records including transaction time, location and transaction amount; based on the account parameter, predict the risk level of the payment account and a risk identification strategy matched with the risk level through a risk identification model; and perform risk identification on the payment account through the acquirer platform using the risk identification strategy.

[0026] In the scheme, after the virtual resource of the payment amount is transferred from the payment account associated with the payment bank to the transition account associated with the receiving account, the resource transfer processing module is further configured to: transfer the virtual resource of the payment amount from the transition account to a value-added account, so as to provide value-added services for the virtual resource of the payment amount during the risk identification of the payment account by the platform of the collecting party; and in the case that the risk identification of the payment account by the platform of the collecting party is passed, redeem the virtual resource of the payment amount from the value-added account to the transition account, and transfer the virtual resource of the payment amount from the transition account to the receiving account, so as to transfer the resource income obtained by the value-added services for the virtual resource of the payment amount during the risk identification of the payment account by the platform of the collecting party to the payment account.

[0027] In the scheme, after the virtual resource of the payment amount is transferred from the transition account to the receiving account, the device further includes a payment result prompting module configured to: display a payment success prompt information in the payment page, and send the payment success prompt information to the merchant platform through the platform of the collecting party.

[0028] In the scheme, after the virtual resource of the payment amount is transferred from the payment account associated with the payment bank to the transition account associated with the receiving account, the resource transfer processing module is further configured to: control the receiving bank to package a message based on the payment account information corresponding to the payment order, to obtain an identification prompt message; wherein the identification prompt message is used to prompt the platform of the collecting party to perform risk identification on the payment account information; the payment account information includes at least one of the following: payment record identifier, payment account, payment bank, payment amount, order note; and control the receiving bank to send the identification prompt message to the platform of the collecting party through a target sending mode.

[0029] In the scheme, the resource transfer processing module is further configured to perform at least one of the following: control the receiving bank to send the identification prompt information to a target callback interface address pre-configured by the receiving bank; control the receiving bank to send the identification prompt information to a target queue, so that the platform of the collecting party obtains the identification prompt information from the target queue, and the target queue is used to store relevant information between the receiving bank and the platform of the collecting party for the risk identification; and control the receiving bank to send the identification prompt information to a contact person of the platform of the collecting party in the form of a short message or an email.

[0030] The embodiment of the application provides an electronic device, including:

[0031] a memory configured to store computer executable instructions or computer programs;

[0032] The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the virtual resource processing method provided in the embodiments of this application.

[0033] This application provides a computer-readable storage medium storing computer-executable instructions or computer programs for implementing the virtual resource processing method provided in this application when executed by a processor.

[0034] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the virtual resource processing method provided in this application.

[0035] The embodiments of this application have the following beneficial effects:

[0036] In this embodiment, when a customer selects the target payment method on the merchant platform, the terminal seamlessly redirects the customer from the merchant platform to the acquiring platform corresponding to the target payment method, and simultaneously pushes payment order information, ensuring the continuity of the customer's operation and avoiding operational interruptions or information loss due to platform switching. After the customer selects a payment bank on the acquiring platform, the terminal responds immediately, displaying the receiving account information associated with the merchant, ensuring the accuracy and timeliness of the information. Simultaneously, displaying key information such as the receiving account name, receiving account, receiving bank, payment amount, and order remarks helps the customer verify the information before payment, reducing errors and ensuring transaction accuracy. After the customer copies the receiving account information, the terminal captures this operation and triggers a redirection logic, redirecting the customer from the acquiring platform to the payment bank's payment page, where the receiving account information is automatically filled and displayed. This not only reduces the tedious manual input of information by the customer but also lowers the risk of transaction failure due to manual input errors, further improving the convenience and accuracy of the operation. After a customer triggers a payment on the payment page, the terminal first transfers the virtual funds of the payment amount from the payment account linked to the paying bank to the transit account linked to the receiving account. This initial transfer ensures the temporary locking and secure storage of funds. Subsequently, when the acquiring platform passes the risk identification of the payment account, the virtual funds of the payment amount are transferred from the transit account to the receiving account. This not only prevents risky funds from being transferred into the receiving account and contaminating it, thus ensuring the security of the transaction, but also ensures the timely arrival of funds and protects the interests of the merchant. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the architecture of the virtual resource processing system 100 provided in this application embodiment;

[0038] Figure 2 is a structural schematic diagram of an electronic device 500 provided by an embodiment of the present application;

[0039] Figure 3 is a flowchart of a virtual resource processing method provided by an embodiment of the present application;

[0040] Figure 4 is a selection schematic diagram of a payment method provided by an embodiment of the present application;

[0041] Figure 5 is a display schematic diagram of a payment account information provided by an embodiment of the present application;

[0042] Figure 6 is a payment feedback schematic diagram provided by an embodiment of the present application;

[0043] Figure 7 is a flowchart of a virtual resource processing method provided by an embodiment of the present application. DETAILED DESCRIPTION

[0044] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the drawings, and the described embodiments should not be regarded as limiting the present application, and all other embodiments obtained by those of ordinary skill in the art without making creative efforts fall within the scope of protection of the present application.

[0045] It can be understood that, in the embodiments of the present application, related data such as user information (for example, user account, financial account, etc.) are involved, when the embodiments of the present application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards.

[0046] In the following description, “some embodiments” are involved, which describe a subset of all possible embodiments, but it can be understood that “some embodiments” can be the same subset or different subset of all possible embodiments, and can be combined with each other without conflict.

[0047] In the following description, the term “first\second…” is only to distinguish similar objects, and does not represent a specific order of the objects, and it can be understood that “first\second…” can be interchanged with a specific order or sequence as allowed, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0048] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined target, and can be implemented entirely or partially by using software, hardware (such as a processing circuit or a memory) or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an integral module or unit that includes the functions of the module or unit.

[0049] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this application is for the purpose of describing embodiments of this application only and is not intended to be limiting of this application.

[0050] Before the embodiments of the present application are further described in detail, the terms and phrases involved in the embodiments of the present application are explained, and the terms and phrases involved in the embodiments of the present application are applicable to the following explanations.

[0051] 1) Client, an application or platform running in a terminal for providing various services, such as a video playing client, a shopping client, a merchant platform, a bank client, etc.

[0052] 2) In response to, used to indicate the condition or state on which the operation is performed, when the dependent condition or state is met, the performed one or more operations can be real-time or have a set delay; in the absence of a specific description, there is no limitation on the execution sequence of the multiple operations performed.

[0053] 3) Custodian bank, also known as collecting bank, refers to a bank that provides fund custodian services for the collecting party or its cooperative merchants. The bank account has special management functions, such as the ability to configure the to-be-credited funds (i.e. payment funds) as a suspense account state and notify the collecting party to handle when the customer triggers a payment operation. For example, the merchant's account in the collecting bank includes a transition account and a collecting account (also known as a basic account) with an associated relationship. After the collecting bank receives the virtual resources transferred from the payment bank's payment account, it first stores the virtual resources in the transition account and notifies the collecting party to identify the risk of the platform to the payment account, and then transfers the virtual resources from the transition account to the collecting account when the risk identification is passed, so as to avoid the pollution of the collecting account caused by the transfer of risk funds into the collecting account, and to ensure the safety of the transaction.

[0054] 4) Collecting party platform, refers to an institution that provides payment acceptance, fund settlement and other services for merchants. In the embodiments of the present application, the collecting party platform is responsible for interfacing with the custodian bank, identifying or reviewing the risk of the to-be-credited funds, and deciding the final crediting or return of the to-be-credited funds.

[0055] The embodiment of the present application provides a virtual resource processing method and device, electronic equipment, computer readable storage medium and computer program product, which can improve the security of a payment account. The following describes an exemplary application of the electronic equipment provided by the embodiment of the present application. The electronic equipment provided by the embodiment of the present application can be implemented as a notebook computer, a tablet computer, a desktop computer, a set-top box, a mobile device (for example, a mobile phone, a portable music player, a personal digital assistant, a dedicated message device, a portable game device), a smart phone, a smart speaker, a smart watch, a smart television, a vehicle-mounted terminal, and various types of user terminals. The electronic equipment can also be implemented as a server. The following describes an exemplary application when the electronic equipment is implemented as a terminal.

[0056] Referring to Figure 1 , Figure 1 FIG. 1 is an architecture schematic diagram of a virtual resource processing system 100 provided by the embodiment of the present application. To support an exemplary application, a terminal (exemplarily shown as a terminal 400-1 and a terminal 400-2) connects a server 200 through a network 300. The network 300 can be a wide area network or a local area network, or a combination of the two. The server 200 can be a standalone physical server, or a server cluster or a distributed system formed by multiple physical servers. The terminal (the terminal 400-1 and the terminal 400-2) and the server 200 can be directly or indirectly connected through wired or wireless communication, which is not limited in the embodiment of the present application.

[0057] In actual application, taking a customer corresponding to the terminal 400-1 and a merchant corresponding to the terminal 400-2 as an example, the terminal 400-1 is provided with a merchant platform, a payment bank and an acquirer platform; the terminal 400-2 is provided with a merchant platform, a payment bank and can register an acquirer platform. When the customer selects a transaction object (such as a commodity or a service, etc.) on the merchant platform in the terminal 400-1 and selects a target payment method for the merchant, the terminal 400-1 responds to the selection operation, jumps to the acquirer platform corresponding to the target payment method through the merchant platform, and displays the payment order pushed by the merchant platform through the server 200 in the acquirer platform; responds to the selection operation for the payment bank associated with the acquirer platform, displays the payment account information of the merchant, and the payment account information includes at least one of the following: the payment account name, the payment account, the payment bank, the payment amount, and the order note; responds to the copy operation for the payment account information, jumps to the payment page of the payment bank through the acquirer platform, and displays the payment account information in the payment page; and responds to the payment operation triggered based on the payment page, transfers the virtual resource of the payment amount from the payment account associated with the payment bank to the transition account associated with the payment account, and transfers the virtual resource of the payment amount from the transition account to the payment account when the risk identification of the payment account in the acquirer platform is passed.

[0058] Referring to Figure 2 , Figure 2 is a structural schematic diagram of an electronic device 500 provided by an embodiment of the present application, and the electronic device 500 is taken as an example in the description below. Figure 1 The terminal in the electronic device 500 is taken as an example, Figure 2 The electronic device 500 shown in the figure includes at least one processor 510, a memory 550, at least one network interface 520, and a user interface 530. The various components in the electronic device 500 are coupled together through a bus system 540. It can be understood that the bus system 540 is used to realize the connection communication between the components. In addition to including a data bus, the bus system 540 also includes a power bus, a control bus, and a status signal bus. However, for the purpose of clear illustration, all the various buses are marked as the bus system 540 in the figure. Figure 2 The processor 510 can be an integrated circuit chip with a signal processing capability, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc.

[0059] The processor 510 can be an integrated circuit chip with a signal processing capability, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc.

[0060] The memory 550 includes a volatile memory or a non-volatile memory, and can also include both a volatile memory and a non-volatile memory. The non-volatile memory can be a read-only memory (ROM), and the volatile memory can be a random access memory (RAM). The memory 550 described in the embodiments of the present application is intended to include any suitable type of memory. The memory 550 can optionally include one or more storage devices that are physically remote from the processor 510.

[0061] In some embodiments, the memory 550 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, which are exemplarily described below.

[0062] The operating system 551 includes system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks; the network communication module 552 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 520, and exemplary network interfaces 520 include Bluetooth, wireless compatibility authentication (WiFi), and universal serial bus (USB), etc.

[0063] In some embodiments, the virtual resource processing apparatus provided by the embodiments of the present application can be implemented in a software manner, and the virtual resource processing apparatus provided by the embodiments of the present application can be provided in various software embodiments, including various forms of application programs, software, software modules, scripts or codes. Figure 2 The virtual resource processing apparatus 555 stored in the memory 550 is software in the form of programs and plug-ins, and includes a series of modules, including a payment order display module 5551, an account information display module 5552, a payment page display module 5553 and a resource transfer processing module 5554. These modules are logical, and thus can be combined or further divided according to the implemented functions. The functions of each module will be described below.

[0064] In other embodiments, the apparatus provided by the embodiments of the present application can be implemented in a hardware manner. As an example, the apparatus provided by the embodiments of the present application can be a processor in the form of a hardware decoding processor, which is programmed to execute the virtual resource processing method provided by the embodiments of the present application. For example, the processor in the form of a hardware decoding processor can use one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs) or other electronic elements.

[0065] In some embodiments, the terminal or server can implement the virtual resource processing method provided by the embodiments of the present application by running various computer executable instructions or computer programs. For example, the computer executable instructions can be microprogram level commands, machine instructions or software instructions. The computer program can be a native program in the operating system or a software module; can be a native application program (APP), i.e. a program that needs to be installed in the operating system to run, such as a shopping APP, an instant messaging APP; or can be a small program that can be embedded into any APP, i.e. a program that only needs to be downloaded into a browser environment to run. In summary, the above computer executable instructions can be any form of instructions, and the above computer programs can be any form of application programs, modules or plug-ins.

[0066] As described above, the virtual resource processing method provided by the embodiments of the present application can be implemented by various types of electronic devices, for example, can be implemented by Figure 1 any one of the terminal and the server 200 in Figure 1 , or can be implemented by the terminal and the server 200 in Figure 1 cooperatively. Next, taking the implementation of the virtual resource processing method provided by the embodiments of the present application by the terminal in Figure 3 as an example, the implementation of the virtual resource processing method provided by the embodiments of the present application by the terminal in Figure 3 is described. Referring to Figure 3 , the steps shown in

[0067] Step 101: In response to the customer selecting a payment method for a merchant as a target payment method, the terminal jumps to the acquirer platform corresponding to the target payment method from the merchant platform, and displays the payment order pushed by the merchant platform in the acquirer platform.

[0068] In actual application, in the process of browsing goods or services on the merchant platform of the terminal, the customer can add the desired goods or services to the shopping cart or directly select to purchase; in the payment link, the customer can select a payment method for the merchant as a target payment method, and the target payment method is a specific payment method, which can be a small program embedded in an instant messaging client for providing payment or payment services.

[0069] When the customer completes the selection and purchase of the transaction object on the merchant platform and selects the target payment method, the terminal can guide the customer to the acquirer platform corresponding to the target payment method through the merchant platform, and push the payment order to the acquirer platform through the merchant platform, so as to display the payment order pushed by the merchant platform in the acquirer platform, facilitating the customer to confirm and pay. The information transmission processing mode between the merchant platform and the acquirer platform is as follows: the merchant platform initiates a jump request to the acquirer platform through a preset application programming interface (API, Application Programming Interface) interface (such as a RESTful interface based on HTTPS), and uses digital signature (such as RSA asymmetric encryption) to encrypt the transmission of the payment order (including merchant identifier, order number, transaction amount, goods description, payment validity period, etc.). After receiving the jump request, the acquirer platform first verifies the validity of the merchant signature (decrypted by the public key of the merchant previously recorded in the acquirer platform), confirms that the payment order is real and has not been tampered with, and then parses and displays the details of the payment order in the acquirer platform (i.e. the display page of the terminal), forming a trusted information transmission link between the merchant platform and the acquirer platform, avoiding the risk of forgery or information tampering of the payment order.

[0070] In some embodiments, in response to selecting a payment method of a merchant as a target payment method, the terminal can determine the selected payment method by the following method before jumping to the platform of the acquirer corresponding to the target payment method: in response to a purchase operation of a client on a transaction object in a merchant platform, determining a payment order generated by the merchant platform for the transaction object, and displaying a plurality of candidate payment methods available for the payment of the payment order; in response to a selection operation on a target payment method in the plurality of candidate payment methods, the target payment method is used as the payment method for the client to pay the merchant.

[0071] In actual application, when the client completes the selection and purchase of a transaction object (such as a commodity, a service, etc.) in a merchant platform and initiates a purchase operation (such as clicking a settlement button or submitting an order button), the merchant platform starts an order generation process: first, order information aggregation: the background system of the merchant platform automatically aggregates transaction core data, including transaction object details (commodity identifier, name, quantity, unit price), order amount (including total commodity price, freight, tax, discount, etc., which is automatically calculated and displayed by algorithm), merchant information (merchant identifier, name), client information (client identifier in the merchant platform, delivery address, service object information), order validity period (such as 15 minutes without payment automatically cancelled), etc., a unique order number can be generated by the rule of "date + random number + last number of merchant identifier" to ensure the uniqueness of the payment order. Secondly, order state initialization: in the order management system of the merchant platform, the order state is marked as to be paid, and the atomicity of order information storage is ensured by database transaction mechanism (to avoid partial information loss). Finally, trigger payment method display: after the order is generated, the front-end page automatically jumps from the commodity confirmation page to the payment method selection page, and carries the order number, order amount and other key parameters, which provides the basis for subsequent payment method matching.

[0072] The merchant platform displays multiple candidate payment methods on the payment method selection page, and the core implementation logic includes: candidate method pool calling: the background system of the merchant platform filters the available methods from the preset payment method pool according to the order information (such as the amount, the industry of the merchant) and the merchant configuration. For example, if the merchant has accessed the target payment method of acquirer A, the fast payment of acquirer B, the online banking payment of bank C, etc., first check the enable state of each method (whether the merchant has signed up, whether the interface is normal); combined with order amount filtering (such as small amount password-free payment limit 500 yuan below order), industry restriction (such as medical industry does not support some credit payment methods), finally determine the list of candidate methods available for the current order. The front-end page displays the candidate methods in a preset priority (such as merchant cooperation priority, user historical selection frequency), each candidate method includes the following contents: visual identifier (such as acquirer platform icon, bank icon), name description (such as target payment method (acquirer A), XX bank fast payment), additional information (such as "first order discount 5 yuan", "support installment" and other preferential labels, or "arrival time: T+1" and other service instructions), selection control (such as radio button, click area, supporting touch or mouse operation). The background system can also call the payment preference record of the customer on the merchant platform (such as the past 3 times all choose the target payment method), through the front-end logic, the method is defaulted to the top of the list, and the "commonly used" label is highlighted, improving the selection efficiency.

[0073] The terminal (front-end of the merchant platform) captures the customer's click or check operation on the target payment method through event detection (such as onclick event), and at the same time triggers the anti-repetition selection logic (such as after being selected, other methods are automatically unchecked, ensuring unique selection). The terminal temporarily stores the identification of the selected target payment method (such as acquirer identification, method code) in the local storage of the page, and sends a method selection notification (including order number, target method code, operation timestamp) to the backend of the merchant platform. After receiving the notification, the backend of the merchant platform verifies whether the order state is "to be paid" (the purpose of verification is to prevent invalid operations on canceled or paid orders), confirms that there is no error, associates the target payment method information (such as payment method: acquirer A-target payment method) in the order record, and updates the order state to "to be jumped to acquirer". The backend generates jump parameters containing order number, target payment method code, signature information (to prevent tampering), and returns them to the front-end. After receiving the parameters, the front-end can also display a prompt "about to go to XX platform for payment" (with a countdown, such as 3 seconds later, automatically jump), while allowing the customer to manually click the "go now" button to trigger the subsequent jump process to the acquirer platform.

[0074] In this way, the merchant platform realizes a closed loop from order generation to payment method selection, ensures the availability of the candidate method through dynamic filtering, simplifies the customer selection process through clear display and interaction design, and finally accurately locks the target payment method, providing a basis for smooth connection of subsequent cross-platform payment.

[0075] Step 102: In response to the selection operation for the payment bank associated with the acquirer platform, display the merchant's collection account information.

[0076] The collection account information includes at least one of the following: collection account name, collection account, collection bank, payment amount, order note.

[0077] In actual application, when the customer selects the associated payment bank on the acquirer platform (the acquirer pre-establishes cooperation with multiple banks through the bank-enterprise direct interface, and the interface complies with industry standards), the acquirer platform calls its own merchant management system based on the merchant identifier, obtains the collection account information (including collection account name, collection account, bank, and order note) of the merchant recorded in the custodian bank, and displays it through front-end desensitization (such as hiding the middle 6 digits of the collection account), which not only ensures information security but also meets user verification needs.

[0078] For example, see Figure 4 , Figure 4 is a selection diagram of the payment method provided by the embodiment of the application. The terminal displays multiple selectable candidate methods in the merchant platform, such as but not limited to bank card payment (such as Ping An Bank, Construction Bank, and Postal Bank) and acquirer platform (such as the target payment method). When the customer selects the target payment method 401, the terminal responds to the selection operation and jumps to the acquirer platform corresponding to the target payment method from the merchant platform, and displays multiple candidate banks (such as AA bank savings card, BB bank savings card, CC bank savings card, …, other bank savings card) associated with the acquirer platform on the acquirer platform. When the customer selects the payment bank (i.e. the selected other bank savings card 402 as the payment bank), the terminal responds to the selection operation and displays the merchant's collection account information 403, such as the collection account name (such as Shenzhen XXXXXXX), the collection account (such as 5840XXXXXXXX), the collection bank (such as “BB Bank”), the transfer amount (i.e. the payment amount, such as 10000.00 yuan), and the transfer note (i.e. the order note, such as purchase of goods A WQXX).

[0079] Step 103: In response to the copy operation for the payment account information, jump from the acquirer platform to the payment page of the payment bank, and display the collection account information in the payment page.

[0080] In actual application, the copy operation of the client on the displayed collection account information on the platform page of the acquirer can be manual copy, or copy item by item by clicking the "copy" button, or one-key copy by clicking the "copy all" button, as shown in Figure 5 Figure 5 is a display schematic diagram of the collection account information provided by the embodiment of the application. After the acquirer platform detects the copy operation of the client on the collection account information, the copy operation is captured through front-end event detection, and an encrypted temporary token (validity period of 5 minutes) containing the collection information is generated, and the deep link protocol (such as "bank APP Scheme: / / payment?token=xxx") of the payment bank is called to realize jump. When the payment bank loads the page, the token is used to initiate a verification request to the acquirer platform, the decrypted collection account information is obtained, and the payment form is automatically filled in to avoid errors caused by manual input of the user, and the information leakage risk is reduced through the token validity period limit. In this way, after the terminal loads the payment page, the previously copied collection account information (collection account name, collection account, collection bank, etc.) can be automatically displayed on the payment page of the payment bank, which facilitates the client to confirm whether the payment information is correct.

[0081] In some embodiments, the terminal can be jumped to the payment page of the payment bank by the acquirer platform in response to the copy operation on the payment account information in the following manner: in response to the copy operation on the payment account information, the bank application corresponding to the collection bank is started, and the payment page of the started bank application is jumped by the acquirer platform.

[0082] In actual application, the terminal responds to the copy operation, and in the case that the acquirer platform and the payment bank have completed the application protocol docking in advance, the bank application can be directly started and jumped to the payment page. This way, through the deep protocol linkage of the acquirer platform and the bank application, seamless connection of "copy operation→application start→page jump" is realized, and the core implementation details of the above process will be described next.

[0083] ​First, the detection of the copy operation and the identification of the bank application, wherein when capturing the copy event, the front-end page of the acquirer platform (i.e., the view interface of the terminal) captures the user's copy operation on the payee account information (such as the payee's name, account number, amount, etc.) by triggering an event (clipboard) detection (such as document.addEventListener('copy', handleCopy)). When the customer triggers the copy operation, the terminal automatically records the complete information (including structured data: {accountName: "xxx", accountNo: "xxx", bankCode: "xxx", amount: "xxx"} ) that is copied and marks the copy source as the acquirer platform payment process. When matching the bank application, the acquirer platform matches the corresponding application wake-up protocol (such as the icbcbank: / / of the ICBC, the cmbchina: / / of the China Merchants Bank, etc. Scheme protocol, or iOS Universal Link) from the preset bank application protocol library according to the "payee bank" field in the payee account information. The protocol library pre-stores the starting path and parameter format of each bank application (such as bankAppScheme + " / payment?params=xxx").

[0084] Second, bank application startup and data encryption transmission. When starting the bank application, the acquirer platform confirms the completion of the copy operation, and calls the matching bank application protocol through the terminal window.location.href or intent jump (Android) to trigger the terminal to start the corresponding bank application. If the terminal does not install the bank application, the terminal will automatically detect and display a prompt (such as "XX bank APP not detected, please install first") and provide a download link. When transmitting data, to avoid leakage of sensitive information during transmission, the acquirer platform generates a temporary encrypted string through asymmetric encryption (such as RSA) for the structured payee account information, and attaches a unique verification parameter (such as timestamp, nonce, acquirer platform signature sign), and combines it into a parameter package (such as params=encryptData&sign=xxx×tamp=xxx) that the bank application can parse, and embeds the encrypted parameter package into the bank application payment page path to form a complete startup link (such as icbcbank: / / payment?params=xxx&sign=xxx), ensuring that the bank application can directly locate the payment page and read the parameters after starting.

[0085] Finally, the bank application receives the payment page display. After the bank application is started, the parameter in the starting link is extracted by the protocol analysis module, the signature of the platform of the collecting party is verified (the public key of the platform of the collecting party is pre-recorded) to ensure that the parameter is not tampered with, and the complete collection account information is obtained by decrypting the temporary encryption string with a private key. After verification, the bank application automatically jumps to the active payment page (not the home page), and the decrypted collection information is automatically filled into the form (such as the collection account name, account number, and bank automatically matched as the collection bank, and the payment amount is pre-filled with the order amount). The user does not need to manually input, and the prompt such as "payment request from XX platform of the collecting party" can also be displayed on the page to clearly indicate the source of the operation. If the bank application fails to start (such as not supporting the protocol or parameter error), the platform of the collecting party will capture the exception through the event and display a backup solution (such as "start failed, manually open XX bank APP and paste the collection information"). After the bank application successfully loads the payment page, the "payment request received" state is fed back to the platform of the collecting party through the background interface, and the front end (i.e., the terminal) of the platform of the collecting party displays a guide prompt such as "jumped to XX bank APP, please complete the payment" to maintain the coherence of the user operation.

[0086] In the above manner, when the customer triggers the copy operation, the bank application of the collection bank is started and directly jumps to the payment page to complete the payment operation, relying on the inter-application protocol linkage, suitable for the scene where the terminal has installed the bank application and pursues non-perception jump, and the operation fluency can be improved; and the security of the collection information is ensured through encryption transmission and permission verification, and the user manual input error is reduced through structured data filling, laying a foundation for subsequent payment operation.

[0087] In some embodiments, the terminal can be jumped to the payment page of the payment bank by the platform of the collecting party in response to the copy operation for the payment account information in the following manner: in response to the copy operation for the payment account information, the platform of the collecting party is exited; in response to the opening operation of the bank application corresponding to the collection bank, the payment page of the bank application is displayed, and the collection account information is filled into the payment page.

[0088] In actual application, the terminal responds to the copy operation, can first exit the platform of the collecting party, and then fill the payment account information by opening the bank application. This way takes the user's active operation as the core link, realizes the cross-application data transmission of "copy→exit→open application→fill" through local secure storage, and the implementation details of the above process are described next.

[0089] First, the detection of copy operation and local storage of information. When capturing the copy event and structuring the information, the acquirer platform captures the copy operation by triggering an event (such as a clipboard event), records the complete collection account information (structured data), not only copies the information to the system clipboard, but also stores it in the secure storage area of the terminal, and generates a unique identifier (valid for 10 minutes) associated with the information. After the copy operation is completed, the acquirer platform front end automatically triggers the exit logic, such as navigator.app.exitApp()(mobile H5) or closing the current page (mini program or APP), and displays an exit prompt (such as "collection information has been copied, please open XX bank APP to complete the payment"), while clearing the sensitive data in the memory (to avoid residual).

[0090] Second, the user opens the bank application and the information reading trigger. After the user exits the acquirer platform, manually opens the corresponding collection bank application from the terminal desktop or application list. When the bank application starts, the homepage or "transfer or payment" entry will detect whether there is pending information from the acquirer platform (by detecting the unique identifier in the system secure storage area). The bank application requests to read the information in the terminal secure storage through a pre-set interface (agreed with the acquirer platform), verifies the validity of the unique identifier (whether it is within the valid period, whether it is legally written by the acquirer platform). After verification, the complete collection account information is decrypted and obtained; if the verification fails, it will not be read (such as the unique identifier is expired, prompt "information has been invalidated, please copy again").

[0091] Finally, the payment page display and information filling. After the bank application obtains the collection account information, it automatically guides the user to the manual payment page (instead of the default homepage), and displays a prompt at the top of the page (such as "detected pending payment information, do you want to automatically fill it in?"). After the user confirms, the bank application fills in the decrypted collection information into the payment form (collection name, account number, bank automatic matching), and synchronizes the information to the system clipboard (as a backup, for the user to manually check or modify). If the user chooses not to automatically fill in, only the clipboard prompt will be displayed (such as "collection information has been copied to the clipboard, you can manually paste it"). After the bank application completes the information filling, it automatically deletes the unique identifier and associated information in the terminal secure storage (to avoid repeated reading), and sends a "read collection information" notification to the acquirer platform through the background interface, and the acquirer platform records the status (for subsequent payment result reconciliation matching).

[0092] Through the above method, the user actively opens the application as the core, which is suitable for scenarios where the bank application is not installed or the protocol is not connected, and has strong compatibility; and through encryption transmission and permission verification, the safety of the collection information is guaranteed, while through structured data filling, the user's manual input error is reduced, laying a foundation for subsequent payment operations.

[0093] Step 104: in response to the payment operation triggered based on the payment page, transferring the virtual resource of the payment amount from the payment account associated with the payment bank to the transition account associated with the collection account, and in the case that the risk identification of the payment account by the acquirer platform is passed, transferring the virtual resource of the payment amount from the transition account to the collection account.

[0094] In some embodiments, before the terminal jumps to the acquirer platform corresponding to the target payment method in response to selecting the payment method of the merchant as the target payment method, the registration and association between the merchant and the acquirer platform can be achieved by the following method: in response to the registration operation triggered by the merchant on the merchant platform for the acquirer platform, opening a custodian account for the merchant to collect money in the collection bank associated with the acquirer platform; wherein the custodian account includes a transition account and a collection account having an association relationship.

[0095] In actual application, the merchant can find the registration entrance (such as "access to payment service" or "open collection function" and the like) related to the acquirer platform on the merchant platform of his own. The merchant can trigger the registration operation for the acquirer platform through the registration entrance, including: basic information filling: the merchant needs to enter the subject information (such as enterprise name, unified social credit code, legal person ID number, contact number), business information (such as industry type, business scope, business address), settlement demand (such as settlement period, single / daily collection limit) and the like, and upload relevant proof materials (business license scan, legal person ID card front and back, operating place photo and the like), all information is structured collected through the front-end form of the merchant platform, and sensitive information (such as ID number) is stored after front-end encryption (such as AES algorithm). Agreement signing: the merchant platform automatically calls the standardized "payment service agreement" (including custodian account use rules, fund settlement terms, risk responsibility division and the like) provided by the acquirer platform, completes online signing through the electronic seal system (such as the digital certificate of China gold financial authentication center), and the signing result generates an unalterable electronic contract, which is synchronously uploaded to the joint debugging database of the merchant platform and the acquirer platform.

[0096] After receiving the merchant's registration request, the acquirer platform initiates a multi-dimensional audit process to verify the completeness and compliance of the information submitted by the merchant: information verification: the acquirer platform automatically verifies the authenticity of the information submitted by the merchant through API interface connection with the national enterprise credit information public system and the legal person identity verification system (such as the relevant department population information library), such as whether the enterprise is in existence, whether the legal person identity is matched; at the same time, through manual verification, the consistency of the operating information and the proof materials is verified (such as whether the scope of business is matched with the industry type, whether the operating address is real and traceable). Risk rating: based on the risk level of the industry of the merchant (such as the risk coefficient of the financial and e-commerce industries is different), the operating scale, etc., the risk rating of the merchant (such as A / B / C level) is automatically generated by the risk control system of the acquirer platform, and the risk control threshold of subsequent fund settlement is preset according to the rating (such as the single payment limit of C-level merchants is lower than that of B-level merchants, and the single payment limit of B-level merchants is lower than that of A-level merchants). Account opening request generation: after the audit is passed, the acquirer platform generates a unique merchant registration voucher (including merchant identification, audit passing time, acquirer digital signature), and initiates an account opening request to the cooperative collection bank through the bank-enterprise direct interface, which contains the basic information of the merchant, the risk rating, and the type of the account to be opened (transitional account + collection account).

[0097] After receiving the request from the acquirer platform, the collection bank completes the opening and association of the custodian account, and the core operations are as follows: account opening: the core system of the collection bank automatically opens a transitional account and a collection account for the merchant according to the request information, the account nature of the transitional account is a temporary account, the account number rule can be "acquirer identification + merchant identification + '00' suffix" (convenient for identifying the attribution), which supports receiving payment funds, transferring funds to the corresponding collection account or returning the payment account, and does not support direct cash withdrawal or transfer to other accounts. The account nature of the collection account is a settlement account, and the account number rule can be "acquirer identification + merchant identification + '01' suffix", which supports receiving funds from the corresponding transitional account and supports the merchant to withdraw to the merchant's public account according to the settlement rules (such as T+1 settlement). The collection bank establishes a unique association between the two accounts in the core system, uses the merchant identification as the association identifier, ensures that the funds of the transitional account can only be transferred to the collection account associated with it, or returned to the original payment account due to risk control, avoiding mis-transfer of funds; the collection account only receives funds from the associated transitional account and refuses other sources of transfer (such as direct transfer from external accounts), ensuring controllable fund flow. The collection bank generates an account opening reply containing the account numbers of the two accounts, the opening date, and the state (activated), and feeds back to the acquirer platform through an encrypted interface.

[0098] The acquirer platform synchronizes account information with the merchant platform to complete the registration closed loop: account information storage: after receiving the receipt of the collection bank, the acquirer platform stores the account number information of the transition account and the collection account in association with the merchant identifier to its own merchant management system, and performs desensitization processing (such as hiding the middle 6 digits) on the account number. Merchant platform synchronization: the acquirer platform pushes a registration success notification to the merchant platform through the callback interface, including the unique identifier of the merchant in the acquirer platform (such as the acquirer merchant number), the desensitized information of the collection account (such as the collection account name, the collection bank), and the subsequent access to the payment channel. Guide (such as API key acquisition method). Activation and test transaction: after the merchant confirms the receipt of information on the merchant platform, the acquirer platform automatically triggers a test transaction (such as a 0.01 yuan test payment) to verify whether the process of receiving funds by the transition account and transferring to the collection account is smooth. After the test transaction is successful, the registration association between the merchant and the acquirer platform is formally effective, and the target payment method can be supported.

[0099] In the above manner, the merchant and the acquirer platform complete the registration association, and form a closed loop fund channel between the transition account and the collection account in the collection bank. Both the account isolation ensures the safety of temporary storage of funds, and the association binding ensures the controllability of the fund flow, laying a foundation for the compliance of the subsequent payment process.

[0100] In some embodiments, after the terminal transfers the virtual resource of the payment amount from the transition account to the collection account, the payment success prompt information is displayed in the payment page, and the payment success prompt information is sent to the merchant platform through the acquirer platform. For example, see Figure 6 , Figure 6 is a payment feedback schematic diagram provided by the embodiments of the present application. When the merchant triggers the payment operation, the virtual resource of the payment amount is first transferred from the payment account to the transition account, and after the virtual resource of the payment amount is transferred from the transition account to the collection account, the payment success prompt information is displayed in the payment page.

[0101] In some embodiments, in the case where the risk identification of the payment account by the acquirer platform fails, the virtual resource of the payment amount is returned to the payment account from the transition account, and the payment failure prompt information is sent to the customer through the acquirer platform. The payment failure prompt information is used to prompt the reason for the payment failure.

[0102] In actual application, after the customer completes the payment operation on the payment bank page, the payment bank transfers the virtual resources to the transition account of the custodian bank (the transition account is set up by the custodian bank for the acquirer, is independent of the basic account of the merchant, and is only used for temporary storage of funds) through the clearing system (such as the large-value payment system and the network connection platform), and synchronously pushes the payment result notification (including the payment flow number, the payment amount, the payment account, etc.) to the acquirer platform. After the acquirer platform receives the notification, it immediately calls the risk control engine (integrating anti-fraud models, illegal account blacklists, and transaction behavior analysis dimensions) of itself to perform risk identification on the payment account. If the identification passes, the acquirer platform sends a transfer instruction (the instruction includes the digital signature of the acquirer) to the custodian bank, the custodian bank verifies the validity of the instruction, transfers the funds from the transition account to the payment account, and updates the account status to “settled”, and at the same time, displays the payment success prompt information in the payment page, and sends the payment success prompt information to the merchant platform through the acquirer platform; if the identification does not pass, the acquirer platform notifies the custodian bank to return the funds from the transition account to the payment account, and at the same time, informs the customer and the merchant through short message or APP push, forming a closed-loop control of “payment-risk-clearing”, which not only realizes temporary storage buffer through the transition account, but also relies on the cooperation of acquirer risk control and custodian bank fund management to ensure that the funds are finally transferred only under the premise that the risk is controllable.

[0103] In some embodiments, after the virtual resources of the payment amount are transferred from the payment account associated with the payment bank to the transition account associated with the payment account, the identification prompt information can be sent to the acquirer platform in the following way: controlling the payment bank to encapsulate the payment account information corresponding to the payment order based on the payment account information to obtain an identification prompt message; wherein the identification prompt message is used to prompt the acquirer platform to perform risk identification on the payment account information; the payment account information includes at least one of the following: payment record identifier, payment account, payment bank, payment amount, order note; controlling the payment bank to send the identification prompt message to the acquirer platform through a target sending mode.

[0104] Here, the implementation details of "the collection bank sending identification prompt information to the platform of the acquirer" will be explained from four dimensions: trigger mechanism, message packaging, sending method and interaction verification. I. Trigger mechanism: event capture after the transition account of the fund arrives. After the virtual resources are transferred to the transition account of the collection bank, the core system of the collection bank captures the event through the "account change detection mechanism". Specifically, it includes: account flow generation: after the transition account receives the fund, the accounting system of the collection bank automatically generates transaction flow, including payment record identification (i.e. transaction flow identification associated with the order number of the merchant platform), payment account (the bank account of the payer, stored desensitively), payment bank (such as "xx bank"), payment amount (accurate to the fraction, such as 100.00 yuan), order note (remark information transmitted by the merchant platform, such as "the identification of purchased goods A is 12345"), arrival time (time stamp accurate to millisecond), transition account number (unique identification) and other key information. Trigger signal sending: the accounting system sends a trigger signal to the "payment notification module" of the collection bank through the event bus (such as Kafka), which carries the transition account number and transaction flow identification. The notification module determines that "identification prompt needs to be sent to the platform of the acquirer" (because the transition account is pre-bound with the platform of the acquirer).

[0105] II. Message packaging: structured and secure processing based on payment account information. After receiving the trigger signal, the payment notification module of the collection bank packages the identification prompt message based on the transaction flow information. The core steps include: information structured extraction: complete payment account information is retrieved from the database through the transaction flow identification, and is assembled into structured data in the preset format (such as JSON). For example:

[0106]

[0107] Security encryption and signature: to prevent information from being tampered with or leaked during transmission, double security mechanisms are adopted, such as symmetric encryption of structured data (key is the session key pre-negotiated by the collection bank and the platform of the acquirer), generating encrypted message body (encryptedMsg); using the private key of the collection bank to sign the encrypted message body and the timestamp, ensuring that the platform of the acquirer can verify the authenticity of the message source through the public key of the collection bank.

[0108] III. Target sending mode: multi-channel adaptation and reliable delivery. The payee bank sends the identification prompt message through the target mode according to the pre-configuration of the acquirer platform (agreed during the merchant registration and association stage). Among them, the target sending mode can be real-time interface calling for synchronous sending, which is suitable for scenarios requiring low latency, such as high-frequency small-amount transactions, which require the acquirer platform to process risk identification immediately. The payee bank sends a POST request through the RESTful API interface (such as https: / / payee-platform.com / api / risk / notify) provided by the acquirer platform in advance, the request header carries the timestamp and signature, and the request body is the encrypted message body generated above; the interface calling adopts HTTPS protocol, and sets the timeout time (such as 3 seconds), if the acquirer platform returns the correct status code (such as 200 indicating correct or OK) and the reply information (including the acquirer signature), it is determined that the sending is successful; if it is timed out or returns an error status code (such as 500 indicating that the service is unavailable), the automatic retry mechanism (at most 3 times, each time interval 10 seconds) is triggered.

[0109] The target sending mode can also be message queue delivery for asynchronous sending, which is suitable for high-concurrency transaction scenarios (such as e-commerce promotion) to avoid message loss caused by interface congestion. The payee bank interfaces with the acquirer platform to distribute the distributed message queue, and both parties agree on a dedicated topic; the payee bank encapsulates the encrypted message body, timestamp, and signature as a message body and delivers it to the topic, and sets the message expiration time (such as 1 hour); the acquirer platform consumes messages by subscribing to the topic, sends "confirmation of receipt" (ACK) to the queue after successful consumption, and the uncollected messages will enter the dead letter queue for troubleshooting and processing by the operation and maintenance systems of both parties.

[0110] In addition, the target sending mode can also be an alternative mode of file transmission, which is suitable for batch scenarios where the acquirer platform supports batch processing (such as centralized identification before daily settlement), or a bottom-up solution when the real-time interface or message queue fails. The collecting bank aggregates the identification prompt messages into an encrypted file (in CSV or XML format, transmitted through SFTP) at a fixed frequency (such as every 10 minutes); the acquirer platform downloads the file from the specified SFTP directory at regular intervals, decrypts and parses it after processing, and uploads a processing completion receipt file after processing is completed, by which the collecting bank confirms that the message has been sent. After receiving the identification prompt message, the acquirer platform needs to return the confirmation information containing its own signature within 1 minute, and the collecting bank marks the message as "delivered" after verifying the signature; messages that have not received confirmation will be included in the retry queue. If the acquirer platform interface temporarily fails, the notification module of the collecting bank will store the message in the local database, and automatically resend it after the interface is restored; if the message is rejected by the acquirer platform due to format errors, the collecting bank records error details (such as missing fields) through the log system and triggers manual intervention for verification, and re-sends after correction; if it is not completed within 24 hours, the collecting bank sends an alarm email (including transaction flow key information) to the operation and maintenance systems of both parties to avoid long-term detention of funds in the transition account due to delayed identification.

[0111] In the above manner, the collecting bank can safely and reliably send the payee account information to the acquirer platform in the form of an identification prompt message, ensuring that the acquirer platform can start risk identification based on this information in a timely manner, providing a decision basis for subsequent fund transfer from the transition account to the payee account or returning the funds from the transition account to the payee account, forming a closed loop of fund transfer and risk control.

[0112] In some embodiments, the collecting bank can send the identification prompt message to the acquirer platform through the target sending mode in at least one of the following ways: controlling the collecting bank to send the identification prompt information to the target callback interface address of the acquirer platform pre-configured by the collecting bank; controlling the collecting bank to send the identification prompt information to the target queue for the acquirer platform to obtain the identification prompt information from the target queue, the target queue being used to store relevant information between the collecting bank and the acquirer platform for risk identification; controlling the collecting bank to send the identification prompt information to the contact person of the acquirer platform in the form of a short message or an email.

[0113] Here, we further elaborate on the target message sending method. Method 1: Sending to the target callback interface address pre-configured on the acquiring platform. This method achieves real-time message push through direct interface connection, relying heavily on the interface information pre-registered by the acquiring platform with the receiving bank. In actual implementation, during the registration and association phase between the merchant and the acquiring platform, the acquiring platform needs to submit a risk identification callback interface configuration application to the receiving bank. This application includes: the target callback interface address (e.g., https: / / merchant-payee.com / risk / callback, supporting HTTPS protocol), interface authentication information (e.g., the acquiring platform's API key, public key used for signature verification), interface parameter format (e.g., JSON / XML), character encoding (e.g., UTF-8), and timeout (e.g., 5 seconds). The receiving bank stores this information in the partner interface configuration library and generates a unique identifier for this interface, binding it to the acquiring platform identifier and merchant identifier to ensure that messages are only received from the corresponding entity. After the receiving bank's payment notification module generates an identification prompt message, it queries the target callback interface address and authentication rules using a unique identifier. This includes serializing the message body (including payment account information) according to the format specified by the acquiring platform (e.g., JSON); generating a signature based on the API key and timestamp (e.g., sign = MD5(message body + key + timestamp)); and placing the signature and timestamp in the request header; and sending a POST request to the target interface via an HTTP client (e.g., OkHttp), with the serialized message body as the request body. Upon receiving the request, the acquiring platform first verifies the signature validity (by calculating and comparing it using the same algorithm), confirming that the message originates from the receiving bank and has not been tampered with, before parsing the message content. If the interface returns the correct status code (e.g., 200 indicates a correct status code) and business receipt (e.g., {"code":0,"msg":"successful reception","receiptId":"xxx"}), the receiving bank record will be sent successfully and the receipt identifier will be displayed. If a non-200 status code is returned (e.g., 400 indicates parameter error, 503 indicates service unavailable) or a timeout occurs, retry logic will be triggered. For example, the first 3 retries will be spaced 10 seconds apart, the 4th to 6th retries will be spaced 1 minute apart, and if more than 6 retries are made, it will be marked as a sending failure, and the operations and maintenance personnel will be notified to investigate the interface fault.

[0114] The second mode is sending to the target queue for acquirer platform to obtain, which is based on message queue to realize asynchronous decoupling, suitable for high concurrency scenarios, and the core isolates risk identification related information through a dedicated queue. In actual implementation, the collecting bank and the acquirer platform jointly create a dedicated risk identification message queue (such as risk_identify_queue) in the distributed message middleware at the initial stage of docking, and configure the following information: queue attributes: set message expiration time (such as 24 hours), maximum accumulation amount (such as 1 million), and enable dead letter queue (store messages that cannot be consumed); access rights: only allow the producer account (producer_id) of the collecting bank to send messages, and the consumer account (consumer_id) of the acquirer platform to subscribe and consume, and control the rights through secret keys to prevent unauthorized access. After the collecting bank generates the identification prompt message, it is delivered to the target queue according to the following process: encapsulate the payee account information (including payee record identifier, payee account, etc.) into a message object, add custom attributes (such as msgType = "risk_identify", sender = "receiving_bank"); use the SDK (such as RocketMQ SDK) of the message middleware to serialize (such as JSON format) the message object and specify the target queue name; call the message sending (sendMessage) interface to deliver the message and synchronously obtain the message identifier (msgId) for subsequent detection. The acquirer platform continuously detects the target queue through the consumer client, and when a new message arrives, it pulls the message from the queue and deserializes it, verifies the message signature (to ensure that it comes from the collecting bank); parses the payee account information and starts the risk identification process; after the identification process is started, send an acknowledgement consumption feedback (ACK) to the message queue to avoid message duplication; if the processing fails (such as system exception), do not send ACK, and the message will enter the dead letter queue after the number of retries is exhausted, which is handled manually by both parties. The collecting bank detects the delivery amount and consumption success rate of the queue message in real time through the management console of the message middleware to ensure smooth message flow.

[0115] Third way: send to the acquirer platform contact by SMS or email. This way is a backup solution for the first two ways and is suitable for emergency scenarios or system failure. In actual implementation, the acquirer platform files the risk identification emergency contact information with the payee bank, including: SMS receiving number (such as business responsible person's mobile phone number, supporting multiple numbers separated by commas), email receiving address (such as risk@merchant-payee.com, supporting email group), receiving priority (such as SMS instant sending, email sent after 5 minutes). The payee bank stores these information in the contact information database and associates it with the acquirer platform identifier, supporting dynamic update (the acquirer platform can modify it through the management background). When the identification prompt message needs to be sent by SMS or email, the notification module of the payee bank first converts the structured payment account information into readable text: SMS content example:

Payee Bank Notification

XX Payee Bank

Emergency

[0116] Among the above three ways, interface direct connection (way one) and message queue (way two) are the main options for regular scenarios, the former is suitable for transactions with high real-time requirements, and the latter is suitable for high concurrency scenarios; SMS or email (way three) is a supplement or backup way after the failure of the first two ways, to ensure that key risk identification messages are not lost. The notification system of the payee bank will try way one first, switch to way two if it fails, and trigger way three if both fail, forming a multi-level guarantee to ensure that the acquirer platform can obtain the identification prompt information in time and start the risk identification process.

[0117] In some embodiments, the step 104 of "transferring the virtual resource of the payment amount from the transition account to the payee account if the risk identification of the payee account at the acquirer platform passes", can be implemented as follows: transferring the virtual resource of the payment amount from the transition account to the payee account if the risk identification of both the payee account and the payer account at the acquirer platform passes.

[0118] In practical applications, the acquirer platform can automatically perform bidirectional risk identification on the payer account and the payee account. Specifically, the risk control system of the acquirer platform retrieves the complete information of the payee account (such as the payee account number, the business qualification of the merchant, the historical transaction record, the account status, etc.) from the merchant management library of itself through the merchant identifier, integrates the payee account information (the payer account, the payer bank, the transaction amount, etc.) in the identification prompt message, and forms a basic data set for bidirectional evaluation. The risk control system generates a unique risk identification task identifier (such as RISK20231001001), associates the payer account identifier and the payee account identifier, and triggers a parallel evaluation process through a task scheduling center (such as a distributed scheduling framework based on XXL-Job) to ensure that the risk identification of the payer account and the payee account is started synchronously, thereby reducing the overall time consumption.

[0119] The risk control engine of the acquirer platform calls differentiated evaluation models for the two types of accounts respectively, and ensures risk controllability through multi-dimensional verification. For example, the risk identification of the payer account (focusing on the safety of the source of funds) evaluation dimensions include: account basic risk: through the interface of the fraud-related account library, the court's list of dishonest persons subject to enforcement, the bank blacklist, etc., to verify whether the payer account is a illegal card, a fraudulent account, or a frozen account; transaction behavior anomaly: analyze the historical transaction characteristics of the payer account (such as transaction frequency, amount fluctuation, and whether the transfer object is concentrated), determine whether the current transaction deviates from the normal state (such as an account that has been making small transactions for a long time suddenly initiates a large payment), and check whether there are high-risk accounts (such as accounts marked as pyramid scheme funding pools) in the transaction counterpart of the payer account in the past few months (such as 3 months) to avoid the inflow of risky funds. When identifying the risk of the payer account, the risk control engine calls a pre-trained machine learning model (such as an abnormality detection model based on XGBoost), inputs various dimensional feature data of the payer account (such as account opening duration, number of transactions in the past six months, whether there is a record of logging in from a different place, etc.), and outputs a risk score (0-100 points, below 60 points is high risk) and a risk label (such as fraud-related suspicion, transaction anomaly, etc.).

[0120] The evaluation dimensions of risk identification of the collection account (focusing on merchant compliance and fund destination safety) include: merchant qualification validity: check whether the business qualification of the merchant associated with the collection account is expired (such as whether the business license and industry license are within the valid period), and whether there is operating abnormity (such as being listed in the operating abnormity list by the market supervision department); merchant historical risk: query the transaction complaint record of the merchant in the past 1 year (such as whether it involves false transaction or refund dispute, etc.), whether it is punished by the acquirer platform (such as limiting the collection permission) due to violation; collection purpose matching: combined with the order note (such as purchasing medical devices) and the business scope of the merchant (such as the main business of the merchant is daily commodities), judge whether the collection purpose is matched with the business scope of the merchant (avoid fund risk caused by over-range operation). When identifying the risk of the collection account, the risk verification rule library of the merchant (containing multiple rules, such as “medical device merchants must have “medical device operation license”) is configured based on the rule engine (such as Drools), and the risk level of the collection account (pass or fail) and the reason for failure (such as expired qualification, over-range operation, etc.) are output by combining the merchant risk level model (such as grading based on the number of historical violations: A level without violation, D level with multiple violations).

[0121] After completing the risk identification of the two types of accounts, the risk control system of the acquirer platform performs unified verification through the result aggregation module, for example, only when the risk score of the payment account is ≥60 points and there is no high-risk label, and the risk level of the collection account is passed, it is determined that the two-way identification is passed; if any account fails (such as the payment account involves fraud, or the collection account qualification is expired), it is determined that the two-way identification is failed. The risk control system stores the two-way identification results (including score, label, level, determination conclusion) and risk identification task identification into the risk control audit library, and generates an unalterable identification report (including data source, model version, rule hit situation) for supervision backtracking and problem troubleshooting. If the identification process of an account is abnormal (such as data interface timeout, model calculation error), the risk control system automatically triggers retry (up to 3 times); if the retry fails, it is marked as identification abnormal, and the risk control personnel is notified through the alarm mechanism for manual intervention evaluation, to avoid fund retention caused by technical failure.

[0122] In the above manner, the acquirer platform realizes two-way risk control of the payment account (fund source) and the collection account (fund destination), which not only avoids the risk of fund flowing into the merchant account, but also prevents the fund safety problem caused by the violation of the merchant itself, further strengthens the role of the transition account as a risk isolation belt, and finally realizes the safe transfer of virtual resources under the premise of compliance.

[0123] In some embodiments, before the virtual resource of the payment amount is transferred from the transition account to the payee account, the risk identification result of the payee account can be determined by the following method: the acquirer platform detects the legality of the payee account to obtain a legality detection result, and detects whether the payee account triggers a preset risk rule to obtain a rule detection result; in the case that the legality detection result indicates that the payee account is a legal account and the rule detection result indicates that the payee account does not trigger the preset risk rule, it is determined that the risk identification of the payee account by the acquirer platform is passed; when at least one of the legality detection result indicates that the payee account is an illegal account and the rule detection result indicates that the payee account triggers the preset risk rule is met, it is determined that the risk identification of the payee account by the acquirer platform is not passed.

[0124] Here, the risk identification of the payee account is further described from the aspects of legality detection and rule detection. The purpose of legality detection is to determine whether the account is a legal account. The acquirer platform verifies the basic legality of the payee account through multi-dimensional verification: account subject legality verification: the detection content is to verify whether the user or enterprise corresponding to the payee account is a legal subject. If the payee account is a personal account, it is detected whether the name and ID number of the payer match (interface connected to the relevant department identity information verification), whether it is a person subject to public credit information management (interface connected to the Supreme People's Court credit blacklist database); if the payee account is a corporate account, it is detected whether the enterprise name and the unified social credit code match (interface connected to the national enterprise credit information public system), whether it is a serious law-violating and credit-untrustworthy enterprise. When verifying, the acquirer platform calls a third-party authoritative data source through an HTTPS encrypted interface, inputs the identity identifiers (such as ID number, enterprise code) associated with the payee account, and receives the matching result (consistent or inconsistent) and risk identifier (such as credit, law violation, etc.) returned. If all identity identifiers match and there is no risk identifier, it is determined that the account subject is legal.

[0125] Account state legality verification: the detection content is to check whether the state of the payee account in the payee bank is normal (not frozen, not cancelled, not involved in case control), whether the account has the right to pay (such as whether the credit card is within the available limit, whether the savings card is not limited to non-cash transactions). When verifying, based on the direct connection agreement between the acquirer platform and the payee bank, the account state query interface provided by the bank is used to input the payee account number, obtain the account state code (such as 0 = normal, 01 = frozen) and permission identifier, and when the state code is normal and the payee right is valid, it is determined that the account state is legal.

[0126] Fund source legality verification: The detection content is to preliminarily judge whether the payment fund comes from a legal channel, and the focus is to investigate whether the payment account has received illegal funds such as fraud and gambling in the past 30 days (for suspicious transaction list of the anti-money laundering system of the central bank); whether the fund is matched with the work / salary level of the payer (such as a student account suddenly having a large amount of funds). When verifying, the platform of the receiving party matches the transaction flow characteristics of the payment account (such as whether the counterparty is on the blacklist and whether the source of the large amount of funds is abnormal) through the rule engine, and cross- verifies with the characteristic data of the user (such as work, labor remuneration level). When there is no abnormal characteristic, it is determined that the fund source is legal.

[0127] Based on the above three detections, when the subject is legal + the state is legal + the fund source is legal, the final legality detection result is that the payment account is a legal account; if any dimension is illegal, the result is that the payment account is an illegal account. The detection process and result are stored synchronously in the risk control log, and the log includes detection time, data source, and specific illegal reasons (such as account state being frozen).

[0128] The purpose of risk rule detection is to determine whether the payment account triggers a risk rule. Based on the preset risk rule library, the acquirer platform performs multi-dimensional scanning on the transaction behavior of the payment account: construction and classification of the risk rule library: according to the business scenario, multiple types of core rules are preset (which can be dynamically updated), including threshold type rules: such as single payment amount exceeding 500,000 yuan, single day cumulative payment exceeding 3 times, payment amount accounting for more than 90% of the account balance; behavior type rules: such as the first transaction between the payment account and the receiving account, initiating payment across 3 or more regions within 24 hours, frequently changing the payment bank in a short period of time; correlation type rules: such as the payment account has transaction with the account marked as fraudulent, the receiving account belongs to a merchant with more than 3 times of refund disputes in the past 7 days. When performing detection, the rule library is configured through a visual rule engine (such as Drools, URule), and each rule contains a unique rule identifier, trigger conditions (such as amount threshold, behavior characteristics), and risk level (high, medium, low). Support merchants to customize some rules according to industry characteristics (such as e-commerce merchants can increase the single day payment frequency threshold). The rule engine inputs structured data such as payment account information (account number, historical transaction records), current transaction information (amount, time, region, receiving party information), etc. The rule engine checks whether the current transaction meets the rule trigger conditions one by one according to the high-risk rule priority matching principle. For example, if the transaction amount is 1,000,000 yuan and there is a rule in the rule library that "single amount > 500,000 triggers high risk", then it is determined that this rule is triggered; if the transaction is initiated in Beijing, and the payment account has been in Shanghai for the past 3 transactions, and there is a rule in the rule library that "cross-region transaction triggers medium risk", then it is determined that this rule is triggered. The generated rule detection result can include the list of triggered rule identifiers, the highest risk level (such as triggering a high-risk rule marked as high risk); if no rule is triggered, the result is that no preset risk rule is triggered.

[0129] The acquirer platform determines the final risk identification result by comprehensively considering the legality detection result and the rule detection result through a logical judgment module. Only when both of the following conditions are met, such as the legality detection result is that the payment account is a legal account (subject, state, and source of funds are all normal), and the rule detection result is that the payment account has not triggered the preset risk rule (no rule is triggered, or only a low-risk rule is triggered but is determined to be negligible by the system), the risk identification is determined to be passed. If any of the following conditions is met, such as the legality detection result is that the payment account is an illegal account (such as the subject is a dishonest person, the account is frozen, and the source of funds is suspicious), or the rule detection result is that the payment account triggers the preset risk rule (especially high and medium risk rules, such as triggering fraud-related rules and large transaction threshold rules), the risk identification is determined to be failed.

[0130] If the risk identification is determined to be passed, the acquirer platform sends a payment instruction to the payee bank to allow the fund to be transferred from the transition account to the payee account; if the risk identification is determined to not be passed, a risk report (including the reason for not passing, such as triggering the single-amount over-limit rule, the account state being frozen, etc.) is generated, and the payee bank is notified to return the fund in the transition account to the payer account, and the merchant platform is simultaneously notified of the result of the payment failure (risk reason).

[0131] Through the above-mentioned double-layer verification mechanism of "legitimacy detection (basic threshold + rule detection (behavior scanning)", the acquirer platform can comprehensively identify the potential risks of the payer account, which not only prevents illegal accounts from participating in transactions, but also intercepts abnormal transaction behaviors in real time through the rule engine, thereby providing strict risk filtering protection for the fund transfer from the transition account to the payee account.

[0132] In some embodiments, when at least one of the following conditions is met: the legitimacy detection result indicates that the payer account is a potential illegal account, or the rule detection result indicates that the payer account exists potential triggering of preset risk rules, it is determined that the payer account is a potential risk account, and a risk warning prompt information is sent to the payer account through the acquirer platform; wherein the risk warning prompt information is used to prompt the reason why the payer account is a potential risk account, and to provide a proof channel for proving that the payer account is not a potential risk account; in response to the customer submitting the proof materials through the proof channel, the acquirer platform verifies the reason why the payer account exists potential risks based on the proof materials, and when the verification result indicates that the payer account is not a potential risk account, it is determined that the risk identification of the acquirer platform to the payer account is passed.

[0133] In practical applications, the acquirer platform can determine whether the payment account is a potential risk account through cross-analysis of legality detection and rule detection. For example, when the legality detection result does not directly determine that the payment account is an illegal account, but there are suspicious features such as slight inconsistencies in the account subject information (such as the identity card number is verified, but the name has a similar character difference, which may be an input error), indirect association between the account and fraudulent or illegal accounts (such as the transaction counterpart of the payment account has had a small amount of transaction with the illegal account, the association strength is lower than the illegal account threshold), and ambiguity in the source of funds (such as one anonymous transfer in the past 30 days, the amount does not reach the large suspicious standard), the payment account is marked as a potential illegal account. For another example, when the rule detection does not directly trigger the preset risk rule, but the payment account has features close to the threshold of transaction behavior (such as a single payment amount of 490,000 yuan, close to the "50,000 yuan large amount rule" threshold; transactions across 2 regions within 24 hours, close to the "cross 3 regions rule" threshold), ambiguous rule matching (such as the payment account and the receiving account are the first transaction, but there is a record of indirect cooperation in history, and the rule engine cannot completely determine whether it belongs to the risk of stranger transaction), and other features close to triggering, the payment account is marked as a potential risk rule. If at least one of the potential illegal account or the potential risk rule is met, the acquirer platform's risk control system automatically marks the payment account as a potential risk account and generates a risk identifier (such as risk_level=potential), which is different from the explicit risk account (risk_level=high).

[0134] The acquirer platform generates and sends structured risk warning information for potential risk accounts. The risk warning information needs to clearly indicate the risk reason (specific suspicious points), proof channel, proof material type (such as contract, voucher, explanation, etc.), and submission deadline (such as within 24 hours, otherwise it will be treated as a risk failure). For example, for potential illegal accounts:

Risk Warning

Risk Warning

[0135] When sending risk warning information, priority is given to sending SMS (including short links) and bank app push notifications (redirecting to the verification entry) via the mobile phone number bound to the payment account to ensure real-time delivery. If the SMS is sent through the operator's gateway (carrying the acquirer platform's signature to ensure credibility), the app push is based on the manufacturer's push service and records the sending time and read status (through front-end tracking). If the read status is not confirmed within 1 hour, a secondary reminder is sent via the acquirer platform's in-app message and email (if reserved).

[0136] The acquiring platform provides multiple verification channels to facilitate customer document submission while ensuring information security. These channels include online self-service options, a risk appeal section on the acquiring platform's app or website (accessible directly via a short link in the warning message), providing structured forms (for filling out rebuttals of risk reasons) and file upload portals (supporting PDF and JPG formats, with individual files ≤10MB); and a risk verification module embedded in the paying bank's app (jointly developed by the acquiring platform and the bank, with data synchronized via an encrypted interface). Additionally, verification channels can be assisted manually, such as a customer service hotline (400-XXX) for elderly customers or complex situations, supporting document submission via SMS to a designated number, or mailing of paper documents (with the risk warning number included in the message).

[0137] When a customer accesses the verification channel, they must complete identity verification via a verification code on the mobile phone number linked to their payment account and facial recognition (connected to the facial database of relevant departments) to prevent others from impersonating their account to submit materials. The uploaded supporting documents are transmitted in encrypted form and stored using a specified encryption method, which can only be decrypted and viewed by risk control personnel. After the materials are successfully uploaded, a unique verification number (such as PROVE20231001001) is generated and sent to the customer's mobile phone simultaneously for checking the progress.

[0138] The acquirer platform verifies the effectiveness of the proof materials through a double-layer mechanism of automatic verification and manual review. For automatic verification (for standardized materials), the acquirer platform automatically checks whether the required materials are included (such as checking whether there is an ID scan and transaction evidence for a potentially illegal account), and verifies the effectiveness of the materials through authoritative data sources. For example, if a housing purchase contract is submitted, the contract number is verified for authenticity through the housing department interface. If a salary slip is submitted, the slip is verified for authenticity through the bank interface (with the client's authorization for the bank to provide data). If identity information is supplemented with an explanation, it is cross-compared with the relevant department identity library to correct errors. For manual review (for non-standardized materials), when the automatic verification of the acquirer platform cannot determine the risk (such as a non-standardized text for transaction background explanation) or the materials have ambiguities (such as unclear key pages of a contract), the case is assigned to a risk review team (processed according to risk level priority). The reviewer determines whether the risk reason is effectively refuted based on the risk reason. For example, if the transaction counterparty of a potentially illegal account is a regular enterprise (with searchable business information) and the transaction is a normal payment, the risk reason is determined to be invalid. If the procurement contract amount submitted by an account that potentially triggers a large amount rule is consistent with the payment amount, and the business scope of the enterprise matches, the transaction is determined to be reasonable. If the risk reason is not established through both automatic verification and manual review, a verification pass result is generated, and the proof number and review opinion (such as a true transaction background, excluding risk) are associated. If the materials are incomplete, false, or cannot refute the risk reason (such as an invalid contract number), a verification failure result is generated, and the specific reason (such as the contract authenticity has not been verified) is noted.

[0139] The acquirer platform updates the risk identification conclusion based on the verification result and promotes subsequent fund processing. For example, the risk identification result of the payment account is automatically updated to pass by the risk control system, and the proof number and review time of the verification pass are recorded. The settlement system triggers the fund transfer process, such as sending a transfer instruction to the receiving bank to transfer the funds in the transition account to the receiving account, and notifying the merchant through the merchant platform that the payment has been credited. If the verification fails or the materials are not submitted before the submission deadline, the risk identification conclusion remains invalid. The settlement system sends a refund instruction to the receiving bank to refund the funds in the transition account to the payment account, and sends a prompt to the client through SMS or APP that the funds have been refunded due to the risk failure, along with the specific reason (such as failure to provide valid proof materials).

[0140] It should be noted that all the above operations (potential risk determination, warning sending, material submission, verification process, result application) are recorded in the non-tamperable risk control log system, including time stamp, operator, and key data hash value, which meets the requirements of regulatory audits (such as anti-money laundering checks).

[0141] In this way, the acquirer platform provides a "complaint-proof-verification" relief channel for potential risk accounts, avoiding misjudgment due to information errors (protecting the rights and interests of legitimate users), and preventing risk accounts from circumventing audits through strict material verification mechanisms, ultimately achieving a balance between controllable risk and user experience.

[0142] In some embodiments, before the virtual resource of the payment amount is transferred from the transition account to the payee account, the payer account can also be risk-identified by the acquirer platform in the following way: in response to the trigger time of the payment operation not being within the valid period of the risk assessment corresponding to the payer account, the payer account is risk-identified by the acquirer platform; wherein the valid period is determined based on the transaction frequency of the payer account on the merchant platform.

[0143] In actual application, the periodicity of risk assessment can be set according to the transaction frequency of the payer account on the merchant platform, such as using "the number of valid transactions of the payer account on the merchant platform in the last 30 days" as the transaction frequency determination standard (preferably counting successful transactions, excluding test transactions, refund transactions and other non-valid records), determining the threshold based on industry transaction data (such as e-commerce industry high-frequency user average monthly transaction 25 times), risk control model backtesting results (verify that high-frequency user risk fluctuation ≤5% within 7-day period), and supporting merchants to fine-tune according to industry characteristics (such as live e-commerce can increase the high-frequency threshold to 30 times). For example, for frequent transaction scenarios such as e-commerce platform regular customers and enterprise procurement accounts, if the transaction frequency in the last 30 days is greater than or equal to 20, the risk assessment period is set to 7 days, i.e. risk assessment is performed once a week, rather than every transaction, reducing the number of assessments and improving transaction efficiency; for personal accounts with stable monthly consumption (such as 2-3 times of shopping per week), if the transaction frequency in the last 30 days is less than 20 and greater than or equal to 10, the risk assessment period is set to 3 days, i.e. risk assessment is performed every 3 days; for occasional transaction accounts (such as 1-2 times of large consumption per half year), if the transaction frequency in the last 30 days is less than 10, the risk assessment period is set to 0 days, i.e. risk assessment is performed every transaction; in this way, personalized payment solutions are provided for different types of merchants and payers.

[0144] When the user triggers the payment operation, the acquirer platform determines whether risk identification needs to be performed through time window verification. The acquirer platform stores the completion time of the latest risk assessment for each payment account. After determining the risk assessment period according to the user level, the effective period is the completion time of the latest risk assessment + the period length. For example, if the last assessment time of a high-frequency user is January 5, 10:00, the effective period is from January 5, 10:00 to January 12, 10:00. When the user triggers the payment operation, the trigger time of the payment operation is recorded. If the trigger time is within the effective period, this risk identification is exempted, and the latest assessment result is directly reused. If the trigger time is not within the effective period, risk identification is triggered immediately, and the completion time of the latest risk assessment is updated to the completion time of this assessment. For example, assuming that the risk assessment period of a high-frequency user A is 7 days, and the risk assessment is completed on January 5, 10:00, the effective period is from January 5, 10:00 to January 12, 10:00. If user A triggers a payment operation at 15:00 on January 8, because 15:00 on January 8 is within the effective period from 10:00 on January 5 to 10:00 on January 12, the assessment is exempted, and the low-risk result of January 5 is directly reused. If high-frequency user A triggers a payment operation at 9:00 on January 13, because 9:00 on January 13 exceeds the effective period of 10:00 on January 12, risk identification is immediately performed, and after completion, the completion time of the latest risk assessment is updated to 9:30 on January 13, and the new effective period is until 9:30 on January 20.

[0145] It should be noted that the transaction frequency changes with the user's behavior, and the risk assessment period needs to be dynamically updated to avoid using a long period even if the frequency decreases or not using a short period even if the frequency increases. The transaction number of all payment accounts in the past 30 days is recalculated through an offline task every morning, and compared with the current level threshold. If the frequency crosses the level (such as from high frequency to medium frequency), the period adjustment is triggered. If the user has abnormal transactions (such as a 500% increase in transaction number in 3 days), even if it is not the daily recalculation time, the frequency recalculation and period adjustment are immediately triggered (to avoid maliciously using a long period to avoid assessment). If the level increases (such as low frequency to high frequency), the new period takes effect immediately, for example, if a user reaches the high-frequency standard on the same day, the payment on the same day is performed according to the 7-day period. If the level decreases (such as high frequency to medium frequency), the new period takes effect after the current period ends, for example, a high-frequency user's effective period is until January 12, and on January 10, it is determined to be medium frequency, and it is still used until January 12, and from January 13, it is performed according to the 3-day period. All period adjustments are recorded in the risk control log (including the period before and after adjustment, the trigger reason, and the operation time) for audit and backtracking.

[0146] In some embodiments, the step 104 of "in response to the payment operation triggered based on the payment page, transferring the virtual resources of the payment amount from the payment account associated with the payment bank to the transition account associated with the payee account, and in the case that the risk identification of the payment account by the acquirer platform is passed, transferring the virtual resources of the payment amount from the transition account to the payee account" can be implemented as follows: in the case that the stage payment option is included in the payment page, in response to the stage payment operation triggered based on the stage payment option, for each payment stage, transferring the virtual resources of the partial amount indicated by the payment stage from the payment account associated with the payment bank to the transition account associated with the payee account, and in the case that the risk identification of the payment account by the acquirer platform is passed at the payment stage, transferring the virtual resources of the partial amount from the transition account to the payee account; wherein the total amount between the partial amounts corresponding to each payment stage is the payment amount.

[0147] In actual application, the division rule of the payment stage is determined based on transaction characteristics and industry standards, and the stage division is the basis for the stage payment, which needs to be dynamically determined in combination with the transaction amount, industry characteristics and merchant rules. The number of stages and the allocation of amounts can be automatically divided into stages based on the total payment amount according to the default rule, for example: amount ≤ 500,000 yuan: divided into 2 stages (first stage 40%, tail stage 60%); 50,000 < amount ≤ 2,000,000 yuan: divided into 3 stages (30%, 30%, 40%); amount > 2,000,000 yuan: support up to 5 stages (customizable proportion, total = 100%). The number of stages and the allocation of amounts can also be divided based on the merchant self-defined rules, such as the industry-specific stage rules configured by the merchant on the acquirer platform (such as the real estate industry divided into 20% down payment → 30% first payment → 50% final payment), which needs to include stage number, proportion or fixed amount, trigger condition (such as paying the second stage within 7 days after the first stage payment). Automatically check whether the total amount of each stage is equal to the total payment amount (error ≤ 0.01 yuan), and if not, prompt that the stage amount configuration is incorrect to ensure the accuracy of the account allocation.

[0148] When setting the stage time node, if it is set according to the relative time, the next stage payment window period is set by default as "N days after the completion of the previous stage" (such as the second stage needs to be paid within 3 days after the first stage payment, and the merchant can configure N = 1-30 days); if it is set according to the absolute time, the large customized transaction (such as engineering procurement) supports manual setting of the absolute date (such as paying the first stage on 2023-10-01 and paying the second stage on 2023-12-01), which needs to be explicitly marked in the stage information.

[0149] In the payment page, the stage information can be displayed and the user can confirm the selection, such as the stage overview showing all stages in the form of a progress bar and a list, including: stage number (such as stage 1), amount (such as ￥100,000.00 (30%)), payment window period (such as within 3 days after the first stage payment), risk assessment prompt (such as account risk verification will be conducted at each stage). According to the industry of the merchant, the necessity of stage payment is displayed, such as the staged payment in real estate transactions can ensure the safety of funds and pay according to the progress of the project. The payment page provides a "confirm staged payment" button (default selected) and a "switch to one-time payment" option (if the amount does not exceed the limit). After the user selects, a second confirmation is required (such as a pop-up window displaying a prompt such as "staged payment will be executed according to the progress, and overdue payment may affect the transaction").

[0150] After the user confirms the staged payment, the terminal adds stage configuration information (stage_config) to the order record, including: stage total number (stage_count), stage amount (stage_amounts), time rule (time_rules), current stage to be paid (current_stage = 1), and generates a unique stage transaction identifier (stage_trade_id) associated with the original order number.

[0151] The staged fund transfer and risk identification process progresses by stage, and the fund transfer of each stage follows a closed loop of "payment operation → transitional account temporary storage → risk identification → collection account transfer", as follows: When the merchant triggers the stage payment operation, the merchant clicks the "go to payment" button of the corresponding stage in the "my order-stage payment" page of the platform of the acquirer to trigger the stage payment operation, so as to jump to the stage payment page of the payment bank (automatically fill in the stage amount and collection account information). The terminal reminds through SMS or APP push (such as "your second stage payment will be overdue in 2 days, please handle it in time") with a payment short link, and clicks to directly enter the corresponding stage payment page.

[0152] After the user completes the payment operation at this stage on the payment page, the payment bank transfers part of the amount (e.g., 300,000 yuan) at this stage from the payment account to the transition account (a special transition account associated with the original order to avoid mixing with other stage funds) of the receiving bank through the clearing system; the receiving bank generates a stage receipt slip (labeled "Stage X funds, associated order number XXX") and synchronously sends a "stage fund receipt notification" (containing stage number, amount, and receipt time) to the platform of the collecting party. After the platform of the collecting party receives the stage receipt notification, it immediately starts the risk identification of the payment account at this stage, with the difference from the single transaction evaluation being that the evaluation dimension is iterative: dynamically adjust the dimension in combination with the risk results of the previous stages, for example: if the first stage identification is passed, the second stage can focus on the continuity of transaction behavior (such as the payment account location and whether the device is consistent with the first stage); if there is a slight risk in the previous stage, the source of funds verification is strengthened in this stage. In addition, industry-specific adaptation can also be performed, such as in the e-commerce industry, each stage focuses on identifying the frequency of changes in the delivery address and the matching degree of the payment account and the delivery information (to prevent fraud delivery); in the financial industry, the focus is on verifying whether the payment account has been in compliance with the fund inflow in the past 7 days and whether there is a transaction with a high-risk financial account; in the engineering industry, the progress of the project is associated (the merchant needs to upload the file, and the system verifies the authenticity of the file), and if the progress does not meet the standard, the fund transfer at this stage is suspended.

[0153] If the risk identification at this stage is passed, the platform of the collecting party sends a stage transfer instruction (containing the stage number, amount, and signature) to the receiving bank, which transfers the funds for the corresponding stage in the transition account to the receiving account, and updates the stage status to settled; if the risk identification at this stage is not passed, the funds are retained in the transition account, and the user is notified (e.g., if the risk at the second stage is not passed, the funds are temporarily stored, please submit proof materials), and the processing logic is the same as the risk relief process of the single transaction (see the potential risk account processing in the previous section).

[0154] The payment bank maintains the status identification for each stage, such as pending payment, payment in progress, transition account receipt, risk identification in progress, and settled / risk not passed; all status changes are synchronized in real time to the merchant platform and user end (e.g., the APP order detail page displays "Stage 1 completed, Stage 2 pending payment"). After the fund transfer at the last stage is completed, the actual settlement amount of each stage is automatically checked to see if it equals the total payment amount (allowing a ±0.01 yuan error due to rounding), if the check is passed, the order status is marked as completed at all stages, and a full payment receipt notification is pushed to the merchant; if the check is not passed, an abnormal alarm is triggered, and the financial system manually checks and adjusts the account.

[0155] If the user does not pay the amount of a certain stage within the window period, mark the stage as overdue and suspend the subsequent stage; send an overdue reminder to the user (e.g. if the second stage has expired, the user can make up the payment within 24 hours, otherwise the transaction will be cancelled), resume the stage process after successful payment, otherwise trigger full refund (return the funds of the paid stage from the transition account to the payment account). If the risk identification of a certain stage fails and the user does not submit valid proof materials, the system terminates the subsequent stage and returns all paid stage funds from the transition account; push a transaction termination notice (including termination reason) to the merchant and record the stage risk record of the payment account (affecting the risk rating of future transactions). Ensure consistency between stage status and fund flow through distributed transactions, generate a unique transaction identifier for each stage transaction, and reconcile accounts regularly (T+1); if data is lost, backtrack the stage status through bank statements and order snapshots, and automatically repair or trigger manual intervention.

[0156] In the above manner, the phased payment not only meets the needs of large transaction fund splitting (reducing single payment pressure), but also realizes full-process risk control through phased risk identification (each stage is a risk filtering node), and dynamically adjusts the evaluation focus according to industry characteristics, ultimately improving the feasibility and flexibility of large transactions while ensuring the safety of funds.

[0157] In some embodiments, before the virtual resources of the payment amount are transferred from the transition account to the collection account, the payment account can be identified by the following method: determining the account parameters that affect the risk level of the payment account, the account parameters including at least one of the following: historical transaction records, credit rating, account activity, historical transaction records including transaction time, location and transaction amount; based on the account parameters, the risk level of the payment account and the risk identification strategy matched with the risk level are predicted through the risk identification model; and the risk identification strategy is used by the acquirer platform to identify the risk of the payment account.

[0158] In practical applications, account parameters are the basis for risk identification, and need to be extracted from multiple data sources and converted into features that can be analyzed by the model, such as historical transaction records (e.g. transaction time, location (home city), amount, transaction counterparty, transaction type (consumption / transfer), whether to refund or have disputes, etc.) from acquirer platform transaction logs, payment bank interfaces, and merchant platform order libraries; credit rating including external credit score (e.g. Sesame Credit Score, Baihang Credit Score) and internal credit score (based on historical performance records) from third-party credit interfaces and acquirer credit scoring systems; and account activity (e.g. login frequency, transaction volume, account balance fluctuation frequency, device replacement frequency, etc.) from payment bank account behavior logs and user behavior libraries on the acquirer platform.

[0159] To make the parameters input the model, structured processing is needed, such as for the characteristics of historical transaction records, extracting the average transaction interval (hours) from the time dimension, and the proportion of transactions from 2-5 am (high risk of abnormal time transaction); calculating the number of transaction cities in the past 30 days, the matching degree of the current transaction city and the commonly used city (weight of transaction in different places) from the location dimension; generating the maximum single amount / account balance proportion, transaction amount standard deviation (the greater the amount fluctuation, the higher the risk weight) from the amount dimension. For credit rating features, external credit inquiry is mapped to 0-10 points (such as mapping Sesame points 600 to 5 points, and Sesame points 700 to 7 points); internal credit score combined with historical overdue times and risk identification pass rate (such as no overdue and 100% pass rate mapped to 10 points). For account activity features, activity score = (number of transactions in the past 30 days / industry average) x 30% + (number of logins / historical average) x 30% + (device stability) x 40% (device replacement ≤1 time is stable); quantified to 0-10 points (8 points or more is high activity, 3 points or less is low activity).

[0160] Based on the quantified account parameter features, the risk level of the payment account is predicted through a machine learning model. The architecture of the machine learning model can be various, such as considering both interpretability and prediction accuracy, and the “XGBoost+ensemble learning” architecture can be used, with the input being the quantified account parameter features described above and the output being the risk level (0-100 points, corresponding to low / medium / high risk). Among them, the sample source of the training data of the machine learning model can be the historical transaction data of the past 1 year (containing 80% risk pass samples and 20% risk fail samples); whether a fraudulent transaction or a fund violation occurs is the positive label (1), and normal transaction is the negative label (0). During the training process, feature preprocessing is performed, such as missing value filling (such as filling the credit score with the industry average), outlier truncation (such as taking the 99% quantile value of the amount feature), and feature normalization; the best parameters are determined through grid search (such as learning rate 0.05, tree depth 5); 5-fold cross-validation is used to ensure that the model is stable on different time interval samples. When dividing the risk level, low risk: model output score ≥80 points (risk probability ≤1%); medium risk: 50-79 points (risk probability 1%-5%); high risk: <50 points (risk probability >5%).

[0161] After the model outputs the risk level, the preset risk identification strategy (strategy library corresponding to the level) is automatically matched, for example, for high credit and high-frequency normal transaction accounts, the risk identification strategy corresponding to low risk is simplified identification, only verifying the account status (whether normal) and the consistency of current transaction and historical behavior (such as address, device); for accounts with occasional small abnormality but no violation record, the risk identification strategy corresponding to medium risk is standard identification, that is, verifying the account status, credit rating validity, and whether the counterparty of the last 3 transactions is in the whitelist; for low credit and historical risk record accounts, the risk identification strategy corresponding to high risk is enhanced identification, that is, standard identification, fund source verification (whether the recent 7-day account balance is compliant), associated account risk penetration (whether the transaction counterparty is in the blacklist), and manual review. For example, for low-risk accounts, the upper limit of the single payment amount can be appropriately increased, and the risk assessment process can be simplified to reduce the assessment time and improve the payment efficiency; the medium-risk accounts maintain the normal risk assessment standard and amount; and the high-risk accounts reduce the upper limit of the amount and increase the assessment link, such as requiring additional identity verification. At the same time, the risk level and the corresponding amount of the account are dynamically adjusted according to the change of the account risk, so that the risk assessment is more flexible and targeted.

[0162] It should be noted that, in order to avoid model aging and strategy rigidification, a closed-loop optimization mechanism can be established, such as daily statistics of model prediction accuracy (matching degree of actual risk and predicted level) and misjudgment rate (proportion of low risk actually being high risk), and when the accuracy is < 85%, a warning is triggered; the model is retrained every month with new transaction data (including the latest risk cases) to update the feature weights (such as adding virtual resource transaction associated features); the risk interception rate (proportion of actual violation transactions intercepted by high-risk strategy) and the misinterception rate (proportion of normal transactions intercepted) of different risk identification strategies are analyzed every week, and the misinterception rate of low-risk strategy should be ≤ 0.5%; the matched strategy is dynamically adjusted, for example, if the whitelist verification of the medium-risk strategy frequently leads to misinterception, the number of matched transactions can be adjusted from 2 to 3 for the last 5 transactions. At the same time, feedbacks (such as reasonable transactions being misjudged) of merchants and users on the risk identification strategy can be collected, and after verification, the risk identification strategy rules (such as adding customized whitelist for specific industry merchants) are updated.

[0163] Through the above-mentioned manner, the acquirer platform realizes a full-link risk identification mechanism of data driving (account parameters) → model prediction (risk level) → strategy execution (differentiated identification) → closed-loop optimization. Compared with fixed rule identification, this scheme can more accurately capture account risk characteristics (such as predicting potential risks through historical transaction patterns), and balance safety and efficiency through differentiated strategies (low risk for fast pass, high risk for strict control), providing more intelligent risk protection for transitional account fund transfer.

[0164] In some embodiments, after the virtual resource of the payment amount is transferred from the payment account associated with the payment bank to the transition account associated with the payee account, the virtual resource of the payment amount is transferred from the transition account to the value-added account to provide value-added services to the virtual resource of the payment amount during the risk identification of the payment account by the platform of the acquirer; accordingly, the transfer of the virtual resource of the payment amount from the transition account to the payee account in the case that the risk identification of the payment account by the platform of the acquirer is passed can be realized by the following way: in the case that the risk identification of the payment account by the platform of the acquirer is passed, the virtual resource of the payment amount is redeemed from the value-added account to the transition account, and the virtual resource of the payment amount is transferred from the transition account to the payee account, and the resource income obtained by the value-added service to the virtual resource of the payment amount during the risk identification of the payment account by the platform of the acquirer is transferred to the payment account.

[0165] In actual application, the value-added account is a special account for providing short-term value-added services for virtual resources, which usually needs to meet the characteristics of high liquidity, low risk and real-time settlement. The value-added account is a payment and settlement value-added special account opened by the platform of the acquirer and the licensed financial institution (such as bank, fund company), which is a T+0 redeemed cash management account (such as money market fund, bank demand finance sub-account), ensuring that the funds can be redeemed in real time (redeemed to the transition account takes ≤1 minute). The value-added account is strictly isolated from the self-funds of the platform of the acquirer, and the virtual resource of each transaction order corresponds to a unique sub-account identifier, avoiding the mixing of funds of different orders, and being supervised by the financial regulatory authorities (such as the reserve fund management regulations of the central bank). The platform of the acquirer and the financial institution sign an agreement to clearly define the interface standard of fund transfer or redemption, the income calculation rules (such as daily interest calculation), the settlement period (the income of the previous day is settled before the morning of each day), and the risk bottom (the financial institution promises to keep the principal, ensuring that the principal is not lost).

[0166] The acquiring platform's fund settlement system detects transit account arrival events via a message queue (such as Kafka). These events include the order number, virtual resource amount, arrival time, and transit account identifier. The fund settlement system verifies that the order status corresponding to the funds is pending risk identification (not initiated or in progress), and that the value-added service switch is enabled (merchants can configure whether to enable value-added services in the backend). Upon successful verification, a transfer instruction is generated. This instruction includes: the target value-added account sub-account identifier (bound to the order number), the transfer amount (consistent with the transit account arrival amount), order association information (payment account identifier, receiving account identifier), and a digital signature from the acquiring platform (ensuring the instruction's authenticity). The transfer instruction is sent through a batch transfer interface provided by the financial institution, using HTTPS encrypted transmission. The interface timeout is set to 5 seconds (three retries are triggered if the timeout occurs). After the financial institution receives the instruction and completes the fund transfer, it returns a successful transfer receipt (including the sub-account balance and transfer timestamp). The acquiring platform updates the order fund status to "in progress" and records the transfer voucher (such as the financial institution's transaction number).

[0167] During the risk assessment window of the acquiring platform for payment accounts (usually 1-30 minutes, no more than 24 hours), virtual resources generate returns in the value-added account. The default value-added service type is linked to money market funds (7-day annualized yield of 2%-3%), but merchants can choose other products based on their risk preferences (such as bank current account wealth management products, with slightly higher yields but the same redemption time). The interest calculation period is from the successful transfer of funds into the value-added account to the initiation of the redemption instruction (accurate to the second), calculated based on the actual storage time. For example, the return amount = transferred amount × daily annualized yield ÷ 365 ÷ 86400 × actual storage seconds. For instance, a transfer of 100,000 yuan with an annualized yield of 2.5%, stored for 3600 seconds (1 hour), would yield approximately 100,000 × 2.5% ÷ 365 ÷ 86400 × 3600 ≈ 0.27 yuan.

[0168] Financial institutions push sub-account earnings details (including order number, sub-account identifier, cumulative earnings, and interest calculation period) to the acquiring platform every hour. The acquiring platform stores this data in the value-added earnings database and links it to the order information. Every day at midnight, the acquiring platform and the financial institution reconcile earnings (comparing the earnings amounts recorded by both parties, with an error ≤ 0.01 yuan) to ensure the accuracy of earnings data. Any discrepancies are manually verified and adjusted.

[0169] When the acquirer platform determines that the risk identification passes, the whole process of transferring funds from the value-added account to the payee account is started, and the return of the income is completed. The acquirer platform generates a redemption instruction, including the sub-account identifier, the redemption amount (the full amount of the principal), and the order number, and sends it through the real-time redemption interface of the financial institution, indicating that the risk identification passes and the emergency redemption. The financial institution will return the principal from the value-added account to the transition account within 1 minute, and return a redemption success feedback (including redemption time and principal amount). The acquirer platform verifies whether the balance of the transition account has increased by the corresponding amount, and updates the order fund status to "redeemed to the transition account" after confirming the receipt. The acquirer platform sends a transfer instruction (consistent with the regular process) to the payee bank, indicating the transfer from the transition account to the payee account, including the principal amount, the payee account information, and the order number. The bank returns a transfer success feedback after execution, and the order status is updated to "settled to the payee account". The acquirer platform retrieves the cumulative income amount of the order from the value-added income library, and extracts the income through the financial institution's income settlement interface (the financial institution will transfer the income from its reserve fund account to the acquirer platform's income distribution account). The acquirer platform transfers the income amount (e.g. 0.27 yuan) to the payer account through the "small amount payment interface" of the payment bank, with a note indicating "transaction XXX value-added income", and sends a short message to the mobile phone number bound to the payer account (e.g. "Your order PAY20231001001 has obtained value-added income of 0.27 yuan, which has been credited").

[0170] If the risk identification does not pass, the principal is redeemed from the value-added account to the transition account, and then transferred back to the payer account through the payer bank (consistent with the regular refund process). The income is returned to the payer account along with the principal, ensuring that the user does not lose value-added income due to the risk identification not passing.

[0171] It should be noted that if the funds cannot be transferred to the value-added account (e.g. financial institution interface failure), the funds will be automatically retained in the transition account, which does not affect the risk identification process (only no income is generated), and the failure reason for the transfer is recorded for subsequent troubleshooting. If the risk identification passes but the redemption fails, the acquirer platform will immediately trigger manual intervention (contact the financial institution for emergency handling), and at the same time start a backup channel (manually transfer funds from the financial institution's reserve fund account), to ensure that the funds are transferred to the payee account on time.

[0172] Through the above-mentioned manner, the virtual resource realizes value-added during the waiting period of risk identification, which not only improves the efficiency of user funds (even if it is short-term storage, it can also generate income), but also does not affect the core process of risk identification and fund transfer, while ensuring the safety of funds through strict fund isolation and compliance design, forming a win-win mechanism of risk control and user income. This service can increase the income of the user's funds and improve the user's recognition of the payment method.

[0173] In the following, an exemplary application of the embodiments of the present application in an actual application scenario will be described.

[0174] Referring to Figure 7 , Figure 7 is a flowchart of a processing method of a virtual resource provided by an embodiment of the present application, mainly involving a merchant platform, an acquirer platform, a payment bank, a collection bank, etc., and the flow steps include:

[0175] 1. Merchant registration and opening of an account:

[0176] 1.1. The merchant completes registration on the acquirer platform.

[0177] 1.2. The merchant opens a deposit account for collection in a designated collection bank (i.e., a custodian bank) of the acquirer platform according to the guidance of the acquirer, and the deposit account has the capability of first hanging the account and notifying the acquirer, and the deposit account includes a transition account and a collection account having an associated relationship.

[0178] 2. Order generation and collection information display:

[0179] 2.0. A payment user (i.e., the customer mentioned above) selects goods or services on the merchant platform (such as an e-commerce website or an APP).

[0180] 2.1. The merchant places an order.

[0181] 2.2. A payment order is generated. The merchant platform generates a payment order, calls an interface of the acquirer platform to create a payment request for the order, specifies a collection merchant, and passes the payment order to the acquirer platform.

[0182] 2.3. After the user selects a target payment method in the payment link, the user is redirected to the payment page of the acquirer platform, and the payment account information is displayed in the payment page.

[0183] Here, the acquirer platform displays the collection account information (including the collection account number and the collection account name of the custodian bank) and an order note uniquely associated with the order to the payment user according to the order information.

[0184] 3. User transfer operation:

[0185] 2.4. The payment user copies the collection account information and the order note provided by the acquirer platform to trigger the payment operation.

[0186] Here, the payment user logs in to the APP or online bank of the payment bank selected by the user, initiates a bank transfer transaction, transfers the funds to the designated collection account, and accurately fills in the order note provided by the acquirer in the transfer remarks or note column.

[0187] 4. Fund arrival and account hanging notification:

[0188] 2.5, the payment bank transfers funds to the receiving merchant's transitional account in the receiving bank through the payment system of the People's Bank of China (such as Super Network and Large / Medium Amount Payment System).

[0189] 2.6, the receiving bank sends a credit notification to the platform of the acquirer.

[0190] Here, after receiving the credit funds, the receiving bank does not immediately credit the funds to the final available balance of the merchant, that is, does not transfer the funds to the receiving account or basic account of the receiving merchant, but places the funds in a pre-set transitional account or buffer pool (i.e. in a suspended state).

[0191] At the same time, the receiving bank actively notifies the acquirer according to the pre-set notification mechanism (such as API callback, message queue, etc.), informing that there is a new credit fund arrival, and attaching a summary of relevant credit information (such as bank serial number, amount, credit card number, etc.).

[0192] 5. Acquirer processing and decision:

[0193] 2.7, the acquirer platform calls the acquirer risk control system to conduct risk control review on the payment account.

[0194] Here, after receiving the credit notification from the receiving bank, the acquirer platform immediately calls the interface of the receiving bank, and according to the serial number or other identifier provided by the bank, reversely queries the detailed information of the credit, including but not limited to: accurate credit card number (i.e. card number of the payment account), credit account name (i.e. account name of the payment account), actual credit amount, bank record remarks, etc.

[0195] The acquirer platform transmits the obtained credit card number, credit account name, etc. to its internal risk control system (or connected third-party risk control service), and the risk control system conducts risk assessment on the payment account, for example, assesses whether the payment account is a known illegal card, a fraudulent account, or assesses whether the payment account triggers other risk rules (such as abnormally high frequency of transactions in a short period of time, inconsistent with historical behavior of the account, etc.).

[0196] 2.8, the acquirer platform sends an entry control instruction to the receiving bank.

[0197] If the risk identification fails (for example, it is confirmed as an illegal card), the acquirer platform will mark the order as payment failure or close the order, and at the same time, immediately call the interface of the receiving bank, instructing the receiving bank to perform quasi-real-time refund on the credit serial number in the suspended state, and refund the funds back to the credit card number (i.e. the payment account) of the payment user. If the risk identification passes, the acquirer platform notifies the receiving bank to enter the credit of the credit serial number in the suspended state.

[0198] 2.9.1, When the risk identification is passed, the incoming account fund (i.e. the fund transferred from the payer account to the transition account) is debited, i.e. the incoming account fund is transferred from the transition account to the payee account (basic account).

[0199] 2.9.2, When the risk identification is not passed, the incoming account fund is returned to the original route, i.e. the incoming account fund is returned from the transition account to the payer account.

[0200] 2.10, The payee bank returns the debit prompt information to the acquirer platform.

[0201] Here, when the debit is successful, the payee bank returns the debit success prompt information to the acquirer platform, and the acquirer platform notifies the payer user through the merchant platform or directly.

[0202] When the incoming account fund is returned to the original route, the payee bank returns the debit failure prompt information to the acquirer platform, the acquirer platform updates the order state to payment failure, and notifies the payer user through the merchant platform or directly that the order fails to pay due to the risk of the transfer account.

[0203] 2.11, The acquirer platform updates the order state.

[0204] Here, the acquirer platform performs accurate matching of the order and the flow according to the debit prompt confirmation returned by the bank and the order note obtained previously. After successful matching, the acquirer platform updates the order state to payment success and notifies the merchant platform that the order has been successfully paid, and the merchant can proceed with subsequent delivery or service provision. If the debit prompt indicates that the fund is returned to the original route, the order state is updated to payment failure.

[0205] 2.12.1, The acquirer platform sends the debit prompt information to the payer user.

[0206] Here, if the debit prompt information indicates that the debit is successful, the payer user is informed of the payment success prompt, and if the debit prompt information indicates that the debit fails, the payer user is informed that the order fails to pay due to the risk of the transfer account.

[0207] 2.12.2, The acquirer platform sends the debit prompt information to the merchant platform.

[0208] At least the following beneficial effects are achieved through the embodiments of the present application: 1) Ensure the safety of funds, effectively protect the account of the merchant: through the mandatory risk control identification review of the account payment account by the acquirer before the actual entry of funds into the merchant settlement account, funds from illegal cards, fraudulent accounts and other high-risk sources can be found and intercepted in time; for the identified risk funds, the collection bank is instructed to directly and quasi-instantly return from the account suspension state, avoiding the inflow of these illegal funds into the merchant account, thereby effectively protecting the collection merchant from the involvement of financial fraud, money laundering and other activities, and reducing the risk of loss and compliance risk of the merchant.

[0209] 2) Realize the controllability and scalability of the acquirer funds: the "account suspension first, processing later" mechanism gives the acquirer unprecedented control over incoming funds, funds are no longer simply "inflowed and owned", but are finally credited under the explicit instructions of the acquirer, and this control not only reflects in risk identification and interception, but also provides great business scalability for the acquirer, such as different merchant types, transaction amounts, and payment party risk levels.

[0210] 3) Improve risk response efficiency and reduce processing cost: compared with the traditional "first account, then reconciliation, and then risk processing" mode, the embodiments of the present application front-end risk identification and disposal, and process when the funds are in the account suspension state, avoiding complex operations such as tracing, freezing, and refunding after the funds enter the merchant account; quasi-instantly returning risk funds greatly shortens the processing cycle of risk events, reduces the complexity and cost of manual intervention, and avoids indirect losses and time costs caused by receiving illegal funds, such as account freezing and investigation cooperation.

[0211] 4) Optimize the merchant experience and establish trust: although the background processing step is added, the probability of receiving problem funds can be significantly reduced for the merchant, improving the overall safety and reliability of the collection; clear risk prompts and processing procedures help the merchant to understand and cooperate with the risk management measures of the acquirer, and establish a more stable cooperative relationship.

[0212] Having thus described the exemplary application and implementation of the electronic device provided by the embodiments of the present application, the processing method of the virtual resource provided by the embodiments of the present application is described below, and the cooperation of each module in the virtual resource processing device 555 provided by the embodiments of the present application is described below.

[0213] The payment order display module 5551 is configured to, in response to selection of a payment method for a merchant as a target payment method, jump to a platform of an acquirer corresponding to the target payment method by a merchant platform, and display a payment order pushed by the merchant platform in the platform of the acquirer; the account information display module 5552 is configured to, in response to a selection operation for a payment bank associated with the platform of the acquirer, display account information of a payment account of the merchant, the account information including at least one of a payment account holder, a payment account, a payment bank, a payment amount, and an order note; the payment page display module 5553 is configured to, in response to a copy operation for the payment account information, jump to a payment page of the payment bank by the platform of the acquirer, and display the account information in the payment page; and the resource transfer processing module 5554 is configured to, in response to a payment operation triggered based on the payment page, transfer virtual resources of the payment amount from a payment account associated with the payment bank to a transition account associated with the payment account, and in a case where risk identification of the payment account by the platform of the acquirer is passed, transfer the virtual resources of the payment amount from the transition account to the payment account.

[0214] In some embodiments, the resource transfer processing module is further configured to, in a case where the risk identification of the payment account by the platform of the acquirer is not passed, return the virtual resources of the payment amount from the transition account to the payment account, and send a payment failure prompt information to a client corresponding to the payment account by the platform of the acquirer, the payment failure prompt information being used to prompt a reason for the payment failure.

[0215] In some embodiments, before the jumping to the platform of the acquirer corresponding to the target payment method in response to the selection of the payment method for the merchant as the target payment method, the apparatus further includes a registration module configured to, in response to a registration operation for the platform of the acquirer triggered by the merchant in the merchant platform, open a custodian account for the merchant to receive payment in the payment bank associated with the platform of the acquirer; and the custodian account includes the transition account and the payment account in an associated relationship.

[0216] In some embodiments, before the jumping to the platform of the acquirer corresponding to the target payment method in response to the selection of the payment method for the merchant as the target payment method, the apparatus further includes a payment method determination module configured to, in response to a purchase operation for a transaction object by a client corresponding to the payment account in the merchant platform, determine a payment order generated by the merchant platform for the transaction object, and display a plurality of candidate methods available for payment of the payment order; and in response to a selection operation for a target payment method in the plurality of candidate methods, determine the target payment method as a payment method used by the client to make payment to the merchant.

[0217] In some embodiments, the payment page display module is further configured to, in response to the copy operation on the payment account information, start a bank application corresponding to the payee bank, and jump to a payment page of the started bank application from the acquirer platform.

[0218] In some embodiments, the payment page display module is further configured to, in response to the copy operation on the payment account information, exit the acquirer platform; and in response to an open operation on the bank application corresponding to the payee bank, display a payment page of the bank application and fill the payment account information into the payment page.

[0219] In some embodiments, the resource transfer processing module is further configured to, in a case where the risk identification of the payment account and the risk identification of the payee account by the acquirer platform are both passed, transfer the virtual resource of the payment amount from the transition account to the payee account.

[0220] In some embodiments, before the virtual resource of the payment amount is transferred from the transition account to the payee account, the resource transfer processing module is further configured to perform legality detection on the payment account by the acquirer platform to obtain a legality detection result, and detect whether the payment account triggers a preset risk rule to obtain a rule detection result; in a case where at least one of the legality detection result indicating that the payment account is a legal account and the rule detection result indicating that the payment account does not trigger the preset risk rule is satisfied, determine that the risk identification of the payment account by the acquirer platform is passed; and in a case where at least one of the legality detection result indicating that the payment account is an illegal account and the rule detection result indicating that the payment account triggers the preset risk rule is satisfied, determine that the risk identification of the payment account by the acquirer platform is not passed.

[0221] In some embodiments, the resource transfer processing module is further configured to, when the legitimacy detection result indicates that the payment account is a potential illegal account, or the rule detection result indicates that the payment account exists a potential situation triggering the preset risk rule, at least one of which is satisfied, determine that the payment account is a potential risk account, and send a risk warning prompt information to the payment account through the acquirer platform; wherein the risk warning prompt information is used to prompt the reason why the payment account is a potential risk account, and provide a proof channel for proving that the payment account is not a potential risk account; in response to the customer submitting proof materials through the proof channel, control the acquirer platform to verify the reason why the payment account exists a potential risk based on the proof materials, and when the verification result indicates that the payment account is not a potential risk account, determine that the risk identification of the payment account by the acquirer platform is passed.

[0222] In some embodiments, before the virtual resource of the payment amount is transferred from the transition account to the collection account, the resource transfer processing module is further configured to, in response to a trigger time of the payment operation not being within a valid period of risk assessment corresponding to the payment account, perform risk identification on the payment account through the acquirer platform; wherein the valid period is determined based on a transaction frequency of the payment account on the merchant platform.

[0223] In some embodiments, when the resource transfer processing module includes a stage payment option in the payment page, in response to a stage payment operation triggered based on the stage payment option, for each payment stage, the virtual resource of a part of the amount indicated by the payment stage is transferred from the payment account associated with the payment bank to the transition account associated with the collection account, and when the risk identification of the payment account by the acquirer platform in the payment stage is passed, the virtual resource of the part of the amount is transferred from the transition account to the collection account; wherein the total amount of the part of the amount corresponding to each payment stage is the payment amount.

[0224] In some embodiments, before the virtual resource of the payment amount is transferred from the transition account to the collection account, the resource transfer processing module is further configured to determine an account parameter affecting the risk level of the payment account, the account parameter including at least one of the following: historical transaction records, credit rating, account activity, the historical transaction records including transaction time, location and transaction amount; based on the account parameter, predict the risk level of the payment account and a risk identification strategy matched with the risk level through a risk identification model; and perform risk identification on the payment account through the acquirer platform by using the risk identification strategy.

[0225] In some embodiments, after the virtual resource of the payment amount is transferred from the payment account associated with the payment bank to the transition account associated with the payment account, the resource transfer processing module is further configured to: transfer the virtual resource of the payment amount from the transition account to a value-added account to provide value-added services to the virtual resource of the payment amount during risk identification of the payment account by the acquirer platform; and, in a case where the risk identification of the payment account by the acquirer platform is passed, redeem the virtual resource of the payment amount from the value-added account to the transition account, transfer the virtual resource of the payment amount from the transition account to the payment account, and transfer resource income obtained by the value-added services to the virtual resource of the payment amount during the risk identification of the payment account by the acquirer platform to the payment account.

[0226] In some embodiments, after the virtual resource of the payment amount is transferred from the transition account to the payment account, the device further includes a payment result prompting module configured to display a payment success prompt information in the payment page and send the payment success prompt information to the merchant platform by the acquirer platform.

[0227] In some embodiments, after the virtual resource of the payment amount is transferred from the payment account associated with the payment bank to the transition account associated with the payment account, the resource transfer processing module is further configured to: control the payment bank to package a message based on payment account information corresponding to the payment order to obtain an identification prompt message, wherein the identification prompt message is used to prompt the acquirer platform to perform risk identification on the payment account information, and the payment account information includes at least one of the following: payment record identifier, payment account, payment bank, payment amount, and order note; and control the payment bank to send the identification prompt message to the acquirer platform by a target sending mode.

[0228] In some embodiments, the resource transfer processing module is further configured to at least one of the following: control the payment bank to send the identification prompt information to a target callback interface address pre-configured by the payment bank and configured to the acquirer platform; control the payment bank to send the identification prompt information to a target queue for the acquirer platform to obtain the identification prompt information from the target queue, wherein the target queue is used to store relevant information between the payment bank and the acquirer platform for the risk identification; and control the payment bank to send the identification prompt information to a contact of the acquirer platform in the form of a short message or an email.

[0229] This application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. An electronic device's processor reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the virtual resource processing method described above in this application.

[0230] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the virtual resource processing method provided in this application, for example, such as... Figure 3 The method for processing virtual resources is shown.

[0231] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0232] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0233] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0234] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0235] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for processing virtual resources, characterized in that, The method includes: In response to a customer selecting the target payment method for a merchant, the merchant platform redirects the user to the acquiring platform corresponding to the target payment method, and displays the payment order pushed by the merchant platform on the acquiring platform. In response to the selection of a payment bank associated with the acquiring platform, the merchant's receiving account information is displayed, which includes at least one of the following: payee name, payee account, payee bank, payment amount, and order remarks; In response to the copying operation of the payment account information, the acquiring platform redirects to the payment page of the paying bank, and displays the receiving account information on the payment page; In response to a payment operation triggered by the payment page, the virtual resources of the payment amount are transferred from the payment account associated with the payment bank to the transit account associated with the receiving account. If the acquiring platform passes the risk identification of the payment account, the virtual resources of the payment amount are transferred from the transit account to the receiving account.

2. The method according to claim 1, characterized in that, The method further includes: If the acquiring platform fails to identify the risk of the payment account, the virtual resources of the payment amount will be returned from the transit account to the payment account, and The acquiring platform sends a payment failure notification to the customer, which indicates the reason for the payment failure.

3. The method according to claim 1, characterized in that, Before redirecting to the acquiring platform corresponding to the target payment method after selecting the merchant's payment method as the target payment method, the method further includes: In response to the merchant's registration operation for the acquiring platform triggered on the merchant platform, a custody account for the merchant to receive payments is opened in the receiving bank associated with the acquiring platform. The custodian account includes the transit account and the receiving account, which are related.

4. The method according to claim 1, characterized in that, Before redirecting to the acquiring platform corresponding to the target payment method after selecting the merchant's payment method as the target payment method, the method further includes: In response to the customer's purchase operation on the merchant platform for the transaction object, the payment order generated by the merchant platform for the transaction object is determined, and multiple candidate methods for making payment on the payment order are displayed; In response to the selection operation of a target payment method among the multiple candidate methods, the target payment method is selected as the payment method used by the customer to make payment to the merchant.

5. The method according to claim 1, characterized in that, The step of redirecting the acquiring platform to the payment bank's payment page in response to a copying operation of the payment account information includes: In response to the copying operation of the payment account information, the bank application corresponding to the receiving bank is launched, and the acquiring platform redirects to the payment page of the launched bank application.

6. The method according to claim 1, characterized in that, The step of redirecting the acquiring platform to the payment bank's payment page in response to a copying operation of the payment account information includes: In response to the copying operation of the payment account information, exit the acquiring platform; In response to the opening operation of the bank application corresponding to the receiving bank, the payment page of the bank application is displayed, and the receiving account information is filled into the payment page.

7. The method according to claim 1, characterized in that, If the risk identification of the payment account is successful on the acquiring platform, the transfer of the virtual resources of the payment amount from the transit account to the receiving account includes: If the acquiring platform passes the risk identification of both the payment account and the receiving account, the virtual resources of the payment amount will be transferred from the transit account to the receiving account.

8. The method according to claim 1, characterized in that, Before transferring the virtual resources of the payment amount from the transit account to the receiving account, the method further includes: The acquiring platform performs a legality check on the payment account to obtain a legality check result, and checks whether the payment account triggers a preset risk rule to obtain a rule check result. If the legality detection result indicates that the payment account is a legitimate account, and the rule detection result indicates that the payment account has not triggered the preset risk rule, then the acquiring platform is deemed to have passed the risk identification of the payment account. When the legality detection result indicates that the payment account is an illegal account and the rule detection result indicates that the payment account has triggered at least one of the preset risk rules, it is determined that the acquiring platform has failed to identify the risk of the payment account.

9. The method according to claim 8, characterized in that, The method further includes: When at least one of the following conditions is met: the legality detection result indicates that the payment account is a potentially illegal account, or the rule detection result indicates that the payment account has the potential to trigger the preset risk rule, the payment account is determined to be a potential risk account, and a risk warning message is sent to the payment account through the acquiring party platform. The risk warning information is used to indicate why the payment account is a potential risk account and to provide a way to prove that the payment account is not a potential risk account. In response to the customer submitting supporting documents through the verification channel, the acquiring platform verifies the reasons for the potential risk of the payment account based on the supporting documents, and determines that the acquiring platform has passed the risk identification of the payment account when the verification result indicates that the payment account is not a potentially risky account.

10. The method according to claim 1, characterized in that, Before transferring the virtual resources of the payment amount from the transit account to the receiving account, the method further includes: In response to the fact that the trigger time of the payment operation is not within the validity period of the risk assessment corresponding to the payment account, the risk identification of the payment account is performed through the acquiring party platform; The validity period is determined based on the transaction frequency of the payment account on the merchant platform.

11. The method according to claim 1, characterized in that, In response to a payment operation triggered by the payment page, the virtual resources of the payment amount are transferred from the payment account associated with the paying bank to the transit account associated with the receiving account. If the acquiring platform passes the risk identification of the payment account, the virtual resources of the payment amount are then transferred from the transit account to the receiving account, including: If the payment page includes a staged payment option, in response to a staged payment operation triggered based on the staged payment option, for each payment stage, a portion of the virtual resources indicated by the payment stage is transferred from the payment account associated with the payment bank to the transition account associated with the receiving account. If the acquiring platform passes the risk identification of the payment account in the payment stage, the portion of the virtual resources is transferred from the transition account to the receiving account. The total amount among the partial amounts corresponding to each payment stage is the payment amount.

12. The method according to claim 1, characterized in that, Before transferring the virtual resources of the payment amount from the transit account to the receiving account, the method further includes: Determine the account parameters that affect the risk level of the payment account, the account parameters including at least one of the following: historical transaction records, credit rating, account activity, the historical transaction records including transaction time, location and transaction amount; Based on the account parameters, a risk identification model is used to predict the risk level of the payment account and a risk identification strategy that matches the risk level. The risk identification strategy is used by the acquiring platform to identify the risk of the payment account.

13. The method according to claim 1, characterized in that, After transferring the virtual resources of the payment amount from the payment account associated with the payment bank to the transit account associated with the receiving account, the method further includes: The virtual resources of the payment amount are transferred from the transit account to the value-added account to provide value-added services for the virtual resources of the payment amount during the period when the acquiring platform performs risk identification on the payment account; If the risk identification of the payment account is successful on the acquiring platform, the transfer of the virtual resources of the payment amount from the transit account to the receiving account includes: If the acquiring platform passes the risk identification of the payment account, the virtual resources of the payment amount will be redeemed from the value-added account to the transition account, and the virtual resources of the payment amount will be transferred from the transition account to the receiving account. The resource revenue obtained from providing value-added services to the virtual resources of the payment amount during the risk identification of the payment account by the acquiring platform will be transferred to the payment account.

14. The method according to claim 1, characterized in that, After transferring the virtual resources of the payment amount from the transit account to the receiving account, the method further includes: The payment success message is displayed on the payment page and sent to the merchant platform through the acquiring platform.

15. The method according to claim 1, characterized in that, After transferring the virtual resources of the payment amount from the payment account associated with the payment bank to the transit account associated with the receiving account, the method further includes: The receiving bank is controlled to encapsulate a message based on the payment account information corresponding to the payment order to obtain an identification prompt message; The identification prompt message is used to prompt the acquiring platform to perform risk identification on the payment account information; the payment account information includes at least one of the following: payment record identifier, payment account, payment bank, payment amount, and order remarks; The receiving bank is controlled to send the identification prompt message to the acquiring platform via a target sending method.

16. The method according to claim 15, characterized in that, The control of the receiving bank to send the identification prompt message to the acquiring platform via a target sending method includes at least one of the following: The receiving bank is controlled to send the identification prompt information to the acquiring platform at the target callback interface address pre-configured by the receiving bank; The receiving bank is controlled to send the identification prompt information to the target queue, so that the acquiring platform can obtain the identification prompt information from the target queue. The target queue is used to store relevant information between the receiving bank and the acquiring platform regarding the risk identification. The receiving bank is controlled to send the identification prompt information to the contact person on the acquiring platform via SMS or email.

17. A virtual resource processing device, characterized in that, The device includes: The payment order display module is used to respond to a customer selecting the target payment method for the merchant, redirecting the merchant platform to the acquiring platform corresponding to the target payment method, and displaying the payment order pushed by the merchant platform on the acquiring platform. The account information display module is used to display the merchant's receiving account information in response to the selection operation of the payment bank associated with the acquiring platform. The receiving account information includes at least one of the following: receiving account name, receiving account, receiving bank, payment amount, and order remarks. The payment page display module is used to respond to the copying operation of the payment account information by redirecting the acquiring platform to the payment page of the paying bank and displaying the receiving account information on the payment page; The resource transfer processing module is used to respond to a payment operation triggered by the payment page, transfer the virtual resources of the payment amount from the payment account associated with the payment bank to the transit account associated with the receiving account, and transfer the virtual resources of the payment amount from the transit account to the receiving account if the acquiring platform passes the risk identification of the payment account.

18. An electronic device, characterized in that, include: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the virtual resource processing method according to any one of claims 1 to 16.

19. A computer-readable storage medium, characterized in that, The device stores computer-executable instructions or computer programs, which, when executed by a processor, implement the virtual resource processing method according to any one of claims 1 to 16.

20. A computer program product comprising a computer program or computer-executable instructions, characterized in that, When the computer program or computer-executable instructions are executed by the processor, the method for processing virtual resources as described in any one of claims 1 to 15 is implemented.

Images