Virtual resource processing method and device, electronic 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, and jumping from a merchant platform to an acquirer platform corresponding to the target payment mode; in response to a selection operation for a target payment bank associated with the acquirer platform, skipping to a payment interface of the target payment bank from the acquirer platform, and displaying a first target transition account associated with the merchant in the target collection bank in the payment interface; in response to a payment operation triggered based on a payment interface, transferring virtual resources of a to-be-paid amount from a payment account associated with a target payment bank to the first target transition account, and transferring the virtual resources to a basic withdrawal account of a merchant in a target collection bank in real time through the first target transition account, and transferring the virtual resource to a collection account of the merchant through the basic withdrawal account. According to the invention, the security of the collection account can be improved.

Description

Technical Field

[0001] This application relates to information processing technology, and more particularly to a method, apparatus, electronic device, computer-readable storage medium, and computer program product for processing virtual resources. Background Technology

[0002] Currently, when customers pay for transactions purchased on merchant platforms, they can directly transfer funds from their paying bank to the merchant's receiving bank. Upon receiving the funds, the receiving bank immediately credits the payment to the merchant's account. However, if the customer's payment is at risk (e.g., the payment account is an illegal or fraudulent card), the inflow of these funds into the receiving bank could lead to a freeze on the account. This would result in the freezing of all order amounts received by the receiving bank, weakening the merchant's account resilience. 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: This application provides a method for processing virtual resources, the method comprising: In response to a customer selecting the target payment method for a merchant, the merchant platform redirects 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 a selection of a target payment bank associated with the acquiring platform, the acquiring platform redirects to the payment interface of the target payment bank, and displays the first target transition account associated with the merchant at the target receiving bank on the payment interface. In response to a payment operation triggered based on the payment interface, the virtual resources of the pending payment amount are transferred from the payment account associated with the target payment bank to the first target transition account. Through the first target transition account, the virtual resources of the pending payment amount are transferred in real time to the merchant's basic withdrawal account at the target receiving bank, and through the basic withdrawal account, the virtual resources of the pending payment amount are transferred to the merchant's receiving account.

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

[0006] The first display module is used to respond to the customer selecting the target payment method for the merchant, and to redirect the merchant platform to the acquiring platform corresponding to the target payment method, and display the payment order pushed by the merchant platform in the acquiring platform; The second display module is used to respond to the selection operation of the target payment bank associated with the acquiring platform, and to jump from the acquiring platform to the payment interface of the target payment bank, and display the first target transit account associated with the target receiving bank in the payment interface; The resource transfer module is used to respond to a payment operation triggered by the payment interface, transfer the virtual resources of the amount to be paid from the payment account associated with the target payment bank to the first target transition account, transfer the virtual resources of the amount to be paid to the merchant's basic withdrawal account in the target receiving bank in real time through the first target transition account, and transfer the virtual resources of the amount to be paid to the merchant's receiving account through the basic withdrawal account.

[0007] In the above scheme, the virtual resource processing device further includes a registration module, which is used to open multiple transitional accounts of the merchant in multiple receiving banks associated with the acquiring platform in response to the merchant's registration operation for the acquiring platform, and open the merchant's basic account in the target receiving bank among the multiple receiving banks.

[0008] In the above scheme, the first display module is further configured to display some payment banks associated with the acquiring platform and a first viewing entry for other payment banks associated with the acquiring platform in the acquiring platform; in response to a trigger operation on the first viewing entry, the displayed partial payment banks are switched to the other payment banks, or the other payment banks are displayed while the partial payment banks are displayed, or the other payment banks are displayed in a pop-up window.

[0009] In the above scheme, the first display module is further configured to display a second viewing entry for the first target transition account on the acquiring platform; if the target payment bank is not included among the partial payment banks and other payment banks associated with the acquiring platform, the first target transition account is displayed on the acquiring platform in response to a triggering operation for the second viewing entry; the resource transfer module is further configured to exit the acquiring platform in response to a copying operation triggered by the acquiring platform for the first target transition account; in response to an opening operation for the bank application corresponding to the target payment bank, the transfer interface of the bank application is displayed, and the first target transition account is filled into the transfer interface; in response to a transfer operation triggered by the transfer interface, the virtual resources of the pending payment amount are transferred from the payment account associated with the target payment bank to the first target transition account.

[0010] In the above scheme, the second display module is further configured to obtain multiple transition accounts associated with the merchant, bank information corresponding to each transition account, and priority markings for each transition account; based on the bank corresponding to each transition account, determine at least one first transition account belonging to the same bank as the basic account among the multiple transition accounts; determine the first transition account with the highest priority among the at least one first transition account; if the merchant type, the amount to be paid, and the payment method of the amount to be paid do not match the activation strategy of all second transition accounts, and the first transition account with the highest priority is in a normal state, the first transition account with the highest priority is used as the first target transition account, and the first target transition account is displayed in the payment interface; the second transition account is a transition account other than the first transition account with the highest priority among the multiple transition accounts.

[0011] In the above scheme, the second display module is further configured to, when the first transition account with the highest priority is in an abnormal state, use the second transition account with the highest priority among the second transition accounts as the first target transition account, or use any of the second transition accounts as the first target transition account.

[0012] In the above scheme, the second display module is further configured to, when the first transitional account with the highest priority is in a normal state, determine the third transitional account as the first target transitional account if the merchant type, the amount to be paid, and the payment method of the amount to be paid all match the activation strategy of the third transitional account; wherein, the activation strategy is used to reactivate the third transitional account or maintain the normal operation of the third transitional account; the third transitional account and the basic account belong to different banks.

[0013] In the above scheme, the basic account includes a basic settlement account and a basic withdrawal account; the resource transfer module is further configured to, in response to the first target transition account and the basic account belonging to the same bank, transfer the virtual resources of the pending payment amount to the basic withdrawal account through the first target transition account, transfer the virtual resources of the pending payment amount to the basic settlement account through the basic withdrawal account, and after the basic settlement account performs the splitting processing on the virtual resources of the pending payment amount, transfer the remaining virtual resources of the splitting processing amount to the basic withdrawal account, and transfer the remaining virtual resources of the basic withdrawal account to the merchant's receiving account through the basic withdrawal account.

[0014] In the above scheme, the resource transfer module is also used to perform consistency verification on the account entity corresponding to the first target transition account and the account entity corresponding to the basic account to obtain a first verification result; if the first verification result indicates that the account entity corresponding to the first target transition account and the account entity corresponding to the basic account are consistent, the virtual resources of the amount to be paid are transferred to the basic withdrawal account through the first target transition account.

[0015] In the above scheme, the basic account includes a basic settlement account and a basic withdrawal account; the resource transfer module is further configured to, in response to the merchant's first target transition account associated with the target receiving bank being in an abnormal state, display the merchant's second target transition account associated with another receiving bank in the payment interface; transfer the virtual resources of the pending payment amount to the basic settlement account through the second target transition account, and after the basic settlement account performs the splitting processing on the virtual resources of the pending payment amount, transfer the remaining virtual resources of the splitting processing amount to the basic withdrawal account, and transfer the remaining virtual resources of the basic withdrawal account to the merchant's receiving account.

[0016] In the above scheme, the resource transfer module is also used to perform consistency verification on the account name of the basic withdrawal account and the account name of the receiving account to obtain a second verification result; if the second verification result indicates that the account name of the basic withdrawal account and the account name of the receiving account are consistent, the remaining amount of virtual resources is transferred from the basic withdrawal account to the merchant's receiving account.

[0017] In the above scheme, the resource transfer module is also used to respond to the merchant platform receiving the customer's refund request, and send the refund request to the acquiring platform, so that when the acquiring platform determines based on the refund request that the balance in the basic withdrawal account is greater than the refund amount indicated by the refund request, it transfers the virtual resources corresponding to the refund amount from the basic withdrawal account to the payment account.

[0018] In the above scheme, the resource transfer module is further configured to, in response to a confirmation operation for the first target transition account displayed on the payment interface, control the target payment bank to send a first verification code to the contact associated with the payment account via SMS or email, and display a verification code filling interface; in response to receiving a filling operation for the verification code on the verification code filling interface, control the target payment bank to verify the filled second verification code and the first verification code to obtain a verification result; in response to a payment confirmation operation triggered based on the verification code filling interface, if the verification result indicates that the first verification code and the second verification code are the same, transfer the virtual resources of the amount to be paid from the payment account associated with the target payment bank to the first target transition account.

[0019] In the above scheme, the resource transfer module is also used to control the acquiring platform to perform risk identification on the payment account; in response to the successful risk identification of the payment account, the virtual resources of the amount to be paid are transferred from the payment account associated with the target payment bank to the first target transition account.

[0020] In the above scheme, the resource transfer module is also used to display a payment failure message on the payment interface in response to the failure of risk identification of the payment account. The payment failure message is used to indicate the reason for the payment failure.

[0021] In the above scheme, after transferring the virtual resources of the amount to be paid from the payment account associated with the target payment bank to the first target transition account, the resource transfer module is also used to display a payment success prompt on the payment interface and send the payment success prompt to the merchant platform through the acquiring platform.

[0022] This application provides an electronic device, the electronic device comprising: Memory is used to store executable instructions or computer programs. 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.

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

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

[0025] The embodiments of this application have the following beneficial effects: Through the embodiments of this application, when a customer selects a target payment method to pay a merchant on the merchant platform, the merchant platform can redirect to the acquiring platform corresponding to the target payment method. The acquiring platform displays the payment order and multiple payment banks associated with the acquiring platform. In response to the selection operation for the target payment bank, the acquiring platform redirects to the payment interface of the target payment bank, where the first target transition account associated with the merchant's target receiving bank is displayed. Subsequently, after the customer triggers the payment operation, the virtual resources of the amount to be paid are transferred from the payment account associated with the target payment bank to the first target transition account, and then the virtual resources are transferred in real time through the first target transition account. The funds are transferred to the merchant's basic withdrawal account, and then from the basic withdrawal account to the merchant's receiving account. This process, by opening a transitional account and a basic withdrawal account for the merchant, allows the transitional account to receive virtual resources transferred from the customer's payment account, while the basic withdrawal account aggregates and withdraws the virtual resources transferred from the transitional account. If the payment account is at risk and receives risky funds, only the corresponding primary transitional account needs to be frozen. Thus, for the merchant, only the outstanding payment amount related to this order is frozen in the primary transitional account, preventing risky funds from directly transferring to the receiving account and contaminating it. This improves the merchant's account disaster recovery capabilities and the security of the receiving account. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the architecture of the virtual resource processing system provided in the embodiments of this application; Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application; Figure 3 This is a first flowchart illustrating the virtual resource processing method provided in this application embodiment; Figure 4 This is a first schematic diagram of the merchant platform provided in the embodiments of this application; Figure 5 This is a first schematic diagram of the acquiring platform provided in the embodiments of this application; Figure 6 This is a schematic diagram illustrating the switching of the payment interface provided in an embodiment of this application; Figure 7 This is a schematic diagram of the merchant account relationships provided in the embodiments of this application; Figure 8 This is a schematic diagram of the registration interface for the acquiring platform provided in an embodiment of this application; Figure 9 This is a schematic diagram of the verification and contract signing interface during registration for the acquiring platform provided in an embodiment of this application; Figure 10 This is a schematic diagram of the account opening waiting interface provided in an embodiment of this application; Figure 11 This is a schematic diagram of the registration completion interface provided in an embodiment of this application; Figure 12 This is a second schematic diagram of the payment interface provided in the embodiments of this application; Figure 13 This is a second flowchart illustrating the virtual resource processing method provided in the embodiments of this application; Figure 14 This is a schematic diagram of the third process of the virtual resource processing method provided in the embodiments of this application; Figure 15 This is a first flowchart illustrating the routing strategy provided in an embodiment of this application; Figure 16 This is a second flowchart illustrating the routing strategy provided in an embodiment of this application; Figure 17 This is a flowchart illustrating the liveness detection strategy hit method provided in the embodiments of this application; Figure 18 This is a flowchart illustrating the multi-party interaction provided in the embodiments of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0029] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0030] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

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

[0032] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0033] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0034] 1) Client: An application or platform running on a terminal to provide various services, such as video playback clients, shopping clients, merchant platforms, and banking clients.

[0035] 2) In response, used to indicate the conditions or states on which the operation performed depends. When the conditions or states on which it depends are met, one or more operations performed may be performed in real time or with a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations are performed.

[0036] 3) The receiving bank refers to the bank that provides fund custody services for the acquiring party or its partner merchants. This bank account has special management functions, such as the ability to configure incoming funds (i.e., the amount to be paid) as pending accounts and notify the acquiring party to process them when a customer triggers a payment operation. For example, a merchant's account in the receiving bank includes a transit account and a basic account that are related. After receiving virtual resources transferred from the target paying bank's payment account, the receiving bank first deposits the virtual resources into the transit account, then transfers the virtual resources from the transit account to the basic account. Finally, the basic account is used for splitting the transaction, and the remaining funds after splitting are transferred to the merchant's receiving account. This avoids the direct transfer of risky funds into the receiving account, which could contaminate the receiving account and ensures the security of the transaction.

[0037] 4) Acquiring platform refers to an institution that provides payment acceptance, fund settlement and other services to merchants. In this embodiment, the acquiring platform is responsible for connecting with the custodian bank, conducting risk identification or risk control review of incoming funds, and deciding on the final crediting or return of the incoming funds.

[0038] This application provides a method, apparatus, device, computer-readable storage medium, and computer program product for processing virtual resources, which can improve the disaster recovery capability of merchants' accounts and the security of their payment accounts.

[0039] See Figure 1 , Figure 1 This is a schematic diagram of the architecture of the virtual resource processing system 100 provided in the embodiments of this application. In order to support the processing application of a virtual resource, the terminal (terminal 400-1 and terminal 400-2 are shown as examples) connects to the server 200 through the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0040] In practical applications, taking customer-related terminal 400-1 and merchant-related terminal 400-2 as examples, terminal 400-1 is equipped with a merchant platform (such as a shopping client), a payment bank, and an acquiring platform; terminal 400-2 is equipped with a merchant platform (such as a shopping client), a receiving bank, and an acquiring platform, and merchants can register the acquiring platform on terminal 400-2. When a customer selects a transaction object (such as goods or services) on the merchant platform in terminal 400-1 and chooses the target payment method for the merchant, terminal 400-1 responds to this selection operation by redirecting from the merchant platform to the acquiring platform corresponding to the target payment method, and displaying the payment order pushed by the merchant platform in the acquiring platform; responding to the selection operation for the target payment bank associated with the acquiring platform, the acquiring platform redirects to the payment interface of the target payment bank, and displays the first target transition account associated with the merchant in the target receiving bank in the payment interface; responding to the payment operation triggered based on the payment interface, the virtual resources of the amount to be paid are transferred from the payment account associated with the target payment bank to the first target transition account, and through the first target transition account, the virtual resources of the amount to be paid are transferred in real time to the merchant's basic withdrawal account in the target receiving bank, and through the basic withdrawal account, the virtual resources of the amount to be paid are transferred to the merchant's receiving account.

[0041] In some embodiments, the terminal (such as terminal 400-1 and terminal 400-2) can be implemented as various types of terminals such as laptops, tablets, desktop computers, set-top boxes, smartphones, smart speakers, smartwatches, smart TVs, and vehicle terminals, or it can be implemented as a server.

[0042] In some embodiments, server 200 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Terminals and servers can be connected directly or indirectly via wired or wireless communication, which is not limited in this embodiment.

[0043] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the electronic device 400 provided in the embodiments of this application. Figure 2 The illustrated electronic device 400 includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components in the electronic device 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 440.

[0044] Processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0045] User interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0046] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices physically located away from the processor 410.

[0047] The memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0048] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0049] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks; The network communication module 452 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc. Presentation module 453 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 associated with user interface 430 (e.g., a display screen, a speaker, etc.). The input processing module 454 is used to detect and translate one or more user inputs or interactions from one or more input devices 432.

[0050] In some embodiments, the virtual resource processing apparatus provided in this application can be implemented in software. Figure 2 A processing device 455 for virtual resources stored in memory 450 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a first display module 4551, a second display module 4552, and a resource transfer module 4553. These modules are logically linked and can therefore be arbitrarily combined or further divided according to their implemented functions. The functions of each module will be described below.

[0051] In other embodiments, the virtual resource processing apparatus provided in this application can be implemented in hardware. As an example, the virtual resource processing apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the virtual resource processing method provided in this application. For example, the processor in the form of a hardware decoding processor can be 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 components.

[0052] In some embodiments, the terminal or server can implement the virtual resource processing method provided in this application embodiment by running various computer-executable instructions or computer programs. For example, computer-executable instructions can be microprogram-level commands, machine instructions, or software instructions. Computer programs can be native programs or software modules in an operating system; they can be native applications (APPs), i.e., programs that need to be installed in the operating system to run, such as shopping APPs or instant messaging APPs; or they can be applets that can be embedded in any APP, i.e., programs that only need to be downloaded to a browser environment to run. In summary, the aforementioned computer-executable instructions can be any form of instruction, and the aforementioned computer programs can be any form of application, module, or plugin.

[0053] As mentioned above, the virtual resource processing method provided in this application embodiment can be implemented by various types of electronic devices, such as... Figure 1 Either the terminal or the server 200 can be executed independently, or it can be... Figure 1 The terminal and server 200 in the process work together. Next, [the process will be carried out by...] Figure 1 The method for processing virtual resources provided in this application embodiment is illustrated using an example of a terminal executing the virtual resource processing method independently. See also... Figure 3 , Figure 3 This is a first flowchart illustrating the virtual resource processing method provided in this application embodiment, which will be combined with... Figure 3 The steps shown are explained.

[0054] In step 101, in response to the customer selecting the target payment method for the merchant, the merchant platform redirects to the acquiring platform corresponding to the target payment method, and the payment order pushed by the merchant platform is displayed on the acquiring platform.

[0055] In practical applications, when customers browse goods or services on the merchant platform on the terminal, they can add their favorite goods or services to their shopping cart or directly select to purchase them; during the payment process, customers can select the target payment method when making payments to the merchant. The target payment method is a specific payment method, such as a mini-program embedded in the instant messaging client to provide payment or payment services.

[0056] When a customer completes a purchase and selects a payment method on the merchant platform, the terminal can redirect the customer to the acquiring platform corresponding to the chosen payment method. The merchant platform then pushes the payment order to the acquiring platform, where it is displayed for customer confirmation and payment. The information transmission between the merchant platform and the acquiring platform is handled as follows: The merchant platform initiates a redirection request to the acquiring platform via a pre-defined Application Programming Interface (API) (such as a RESTful API based on HTTPS). Simultaneously, it uses digital signatures (such as RSA asymmetric encryption) to encrypt and transmit the payment order (including merchant identifier, order number, transaction amount, product description, payment validity period, etc.). After receiving the redirection request, the acquiring platform first verifies the validity of the merchant's signature (by decrypting it using the public key that the merchant has pre-registered on the acquiring platform). Once it confirms that the payment order is genuine and has not been tampered with, it parses and displays the details of the payment order on the acquiring platform (i.e., the terminal's display page), thus forming a trusted information transmission link between the merchant platform and the acquiring platform, avoiding the risk of payment order forgery or information tampering.

[0057] In practical applications, when a customer completes the selection of a transaction object (such as goods or services) on the merchant platform and initiates a purchase operation (such as clicking the checkout button or submitting the order button), the merchant platform initiates the order generation process: First, order information aggregation: The merchant platform's backend system automatically aggregates core transaction data, including transaction object details (product identifier, name, quantity, unit price), order amount (i.e., the amount to be paid, which may include the total price of the goods, shipping costs, taxes, discounts, etc., automatically calculated and displayed in detail through algorithms), merchant information (merchant identifier, name), customer information (customer's identifier on the merchant platform, shipping address, service recipient information), and order validity period (e.g., automatic cancellation if not paid within 15 minutes). A unique order number can be generated using the rule of "date + random number + last digit of merchant identifier" to ensure the uniqueness of paid orders. Second, order status initialization: In the merchant platform's order management system, the order status is marked as pending payment, and the atomicity of order information storage is ensured through a database transaction mechanism (avoiding the loss of some information). Finally, the payment method is displayed: After the order is generated, the front-end page automatically redirects from the product confirmation page to the payment method selection page, carrying key parameters such as the order number and order amount (payment amount), to provide a basis for subsequent payment method matching.

[0058] The merchant platform can display multiple payment options on the payment method selection page. The core implementation logic includes: Candidate payment method pool retrieval: The merchant platform's backend system filters available payment methods from a pre-defined payment method pool based on order information (such as amount and merchant industry) and merchant configuration. For example, if the merchant has already integrated acquirer A's target payment method, acquirer B's quick payment, and bank C's online banking payment, it first verifies the activation status of each method (whether the merchant has signed a contract and whether the interface is working properly); combined with order amount filtering (such as small-amount password-free payment limited to orders under 500 yuan) and industry restrictions (such as the medical industry not supporting certain credit payment methods), it finally determines the list of candidate payment methods available for the current order. The front-end page displays candidate payment methods sorted by preset priority (such as merchant cooperation priority and user historical selection frequency). Each candidate payment method includes the following: visual identifier (such as acquirer platform icon, bank icon), name description (such as target payment method (acquirer A), XX bank quick payment), additional information (such as discount labels such as "first order discount of 5 yuan", "supports installment payment", or service descriptions such as "arrival time: T+1"), and selection controls (such as radio buttons, clickable areas, supporting touch or mouse operation). The backend system can also access the customer's payment preference records on the merchant platform (such as selecting the target payment method for the past 3 times), and place the method at the top of the list by default through frontend logic, highlighting the "Frequently Used" label to improve selection efficiency.

[0059] The terminal (the merchant platform's front-end) captures the customer's click or checkmark operation on the target payment method through event detection (such as the onclick event), and simultaneously triggers anti-duplicate selection logic (such as automatically unchecking other methods after selection to ensure unique selection). The terminal temporarily stores the identifier of the selected target payment method (such as the acquirer identifier and method code) in the page's local storage and sends a method selection notification (including order number, target method code, and operation timestamp) to the merchant platform's back-end. After receiving the notification, the merchant platform's back-end verifies whether the order status is "pending payment" (the purpose of verification is to prevent invalid operations on canceled or paid orders). After confirmation, it associates the target payment method information in the order record (such as payment method: acquirer A - target payment method) and updates the order status to "pending redirection to acquirer". The back-end generates redirection parameters containing the order number, target payment method code, and signature information (to prevent tampering) and returns them to the front-end. After receiving the parameters, the front end can also display a prompt that "You are about to go to the XX platform to make payment" (including a countdown, such as automatic redirection after 3 seconds), and allow the customer to manually click the "Go Now" button to trigger the subsequent redirection process to the acquiring platform.

[0060] In some embodiments, after the terminal is redirected from the merchant platform to the acquiring platform corresponding to the target payment method, and the payment order pushed by the merchant platform is displayed on the acquiring platform, it can also display some payment banks associated with the acquiring platform and a first viewing entry for other payment banks associated with the acquiring platform on the acquiring platform; in response to the triggering operation of the first viewing entry, the displayed partial payment banks can be switched to other payment banks, or, while displaying partial payment banks, other payment banks can be expanded to be displayed, or, other payment banks can be displayed in a pop-up window.

[0061] In practical applications, while the acquiring platform receives payment orders pushed by the merchant platform and completes order parsing and display, the backend system can immediately call the preset "Payment Bank Association Database." This database stores information on all payment banks that the acquiring platform has signed cooperation agreements with. Each piece of information includes core fields such as bank identifier, bank name, bank icon resource address, whether it is a frequently used bank (preset label), and supported payment scenarios (such as large-amount payments, real-time arrival). The acquiring platform's backend can filter some payment banks from the payment bank association database according to the "frequently used priority + cooperation priority" rule and display them along with the payment orders. First, banks marked as frequently used banks are extracted (such as banks frequently used by customers); if the number of frequently used banks is insufficient (e.g., less than 5), the filtering is supplemented according to the depth of cooperation between the acquiring platform and the banks (such as years of cooperation, transaction volume), finally determining 5-8 payment banks as the initial display list. After obtaining the data of the filtered payment banks, the acquiring platform's frontend can render and display the data using horizontal scrolling or a grid layout. Each bank display unit includes: a bank icon (loaded from the associated library) and a bank name (e.g., "XX Bank"); at the same time, a "first viewing entry" is rendered in a fixed position below or to the right of the "Partial Payment Banks" list. The style of the first viewing entry includes viewing prompt text (e.g., "View more payment banks"), entry icon (e.g., down arrow, expand icon), and is bound to trigger events (e.g., click event, touch event).

[0062] In practical applications, the acquiring platform's front end captures the customer's triggered action on the "first viewing entry" through event detection (such as onclick event, touchstart event), and then executes one of the following three display logics according to preset interaction rules: Display switching logic: The front end immediately hides the currently displayed partial list of payment banks, and at the same time retrieves other payment bank data (i.e., the remaining banks in the payment bank association database other than the partial payment banks) from the acquiring platform backend, sorts them by the first letter of the bank name, and renders and replaces the original display area of ​​"partial payment banks" to achieve a complete switch from "partial" to "others". A loading animation (such as a rotating icon) can be displayed during the switch to avoid blank pages.

[0063] Expand the display logic: The front end does not hide the current "partial payment banks", but adds a display area below or to the right of it, retrieves the data of "other payment banks" from the back end and renders it according to the preset layout (such as a vertical list), and updates the prompt text of "first viewing entry" to "collapse more payment banks". When the customer triggers the first viewing entry of "collapse more payment banks" again, "other payment banks" can be hidden and the initial display state of "partial payment banks" can be restored.

[0064] Pop-up display logic: The acquiring platform's front-end responds to the trigger operation for the first viewing entry point, triggering the pop-up component. The pop-up overlay covers the current order display area (preserving the core information of the payment order, such as order amount and order number). The pop-up retrieves "Other Payment Banks" data from the backend and renders it according to a grid layout. The title (such as "More Payment Banks") is displayed at the top of the pop-up, and a "Close" button is set at the bottom. The pop-up automatically closes after the customer selects a bank. If no bank is selected, the "Close" button can be clicked to cancel the operation and return to the original "Partial Payment Banks" display page.

[0065] As an example, Figure 4 This is a first schematic diagram of the merchant platform provided in the embodiments of this application. Figure 5 This is a first schematic diagram of the acquiring platform provided in this application embodiment. When a customer browses goods or services on the merchant platform on the terminal and decides to purchase a target product, the customer is redirected from the product confirmation page to... Figure 4 The payment method selection page shown can be found here. Figure 4 The merchant platform can display the order information of the target product (at least including the amount to be paid, such as a text label indicating 12,000.00) on the payment method selection page. It can also display multiple candidate payment methods associated with the merchant platform, such as the target payment method of acquiring platform A (i.e., acquiring party A) already connected to the merchant, and online banking payment methods of XX bank (such as XX bank savings card). Subsequently, the merchant platform can capture the customer's selection of the target payment method 110 (such as acquiring platform A) through event detection. After the target payment method 110 (such as acquiring platform A) is selected, the terminal responds to the customer's trigger operation on the "Confirm Payment" control 120, and the merchant platform redirects to a page such as... Figure 5 For the acquiring platform corresponding to the target payment method shown (e.g., acquiring platform A), please refer to [link / reference]. Figure 5 The acquiring platform can display the merchant name of the order information (e.g., "XX Mall") and the corresponding amount to be paid (e.g., 12000.00). It can also display some of the payment banks associated with the acquiring platform (e.g., BB Bank savings card, CC Bank savings card, DD Bank savings card, EE Bank savings card) and a primary viewpoint for other payment banks ("Show More Banks" control 130). In response to the customer's triggering action on the primary viewpoint ("Show More Banks" control 130), the acquiring platform can switch the currently displayed partial payment banks to other payment banks, or expand to display other payment banks while displaying partial payment banks, or display other payment banks in a pop-up window.

[0066] By initially displaying a subset of payment banks (such as frequently used banks), the acquiring platform reduces initial browsing costs for customers. Most customers can directly find their preferred banks in the initial list without additional steps, improving selection efficiency. Simultaneously, the full range of bank options is retained through the primary viewing entry point, catering to the personalized needs of a minority of customers. Furthermore, the acquiring platform offers three interaction methods: switching, expanding, and pop-ups, adaptable to different terminal scenarios (e.g., pop-ups / expands are suitable for mobile devices, while switching is suitable for PCs). This avoids excessive scrolling due to a long bank list, maintains the visibility of core payment order information, reduces customer operational interference, and optimizes the page interaction experience. Without compromising the simplicity of the initial page, displaying other payment banks through an entry trigger mechanism ensures that all payment banks associated with the acquiring platform are visible to customers, preventing situations where incomplete bank display leads to customers being unable to find their preferred banks and abandoning payment.

[0067] See also Figure 3 The following explanation follows step 101 above.

[0068] In step 102, in response to the selection operation of the target payment bank associated with the acquiring platform, the acquiring platform redirects to the payment interface of the target payment bank and displays the merchant's first target transit account associated with the target receiving bank in the payment interface.

[0069] In practical applications, customers can select the target payment bank from the payment banks displayed on the acquiring platform. In response to the customer's selection of the target payment bank, the terminal can first identify the first target transit account associated with the merchant at the target receiving bank and in a normal state. The acquiring platform will then redirect the customer to the payment interface of the target payment bank, where the first target transit account will be displayed. Here, displaying the first target transit account can mean displaying the receiving account information of the first target transit account. The receiving account information can include at least one of the following: account name, account number of the first target transit account, bank to which the first target transit account belongs, amount to be paid, and order remarks.

[0070] As an example, Figure 6 This is a schematic diagram illustrating the switching of the payment interface provided in the embodiments of this application. Figure 5 After the customer selects the target payment bank (e.g., XX Bank savings card) from the multiple payment banks displayed on the acquiring platform, the terminal responds to the customer's trigger operation on the "Enable Service" control 140 and redirects to the display. Figure 6 The switching confirmation interface shown in Figure (A) can display prompts indicating whether to switch to the target payment bank (e.g., about to leave the acquiring platform to open other applications). In response to the customer's "Allow" control on the switching confirmation interface, the terminal can jump to... Figure 6 The payment interface shown in Figure (B) displays the merchant's primary target transit account's receiving account information, including: recipient name (i.e., the name of the primary target transit account), recipient account (i.e., the account number of the primary target transit account), receiving bank (i.e., the bank to which the primary target transit account belongs), transfer amount (i.e., the amount paid on behalf of the merchant), and remarks (i.e., order notes). The payment interface may also display payment account information associated with the customer's payment account in the target payment bank. This payment account information may include: the transferring account (including the payment account's account number and corresponding balance information) and the reserved number (i.e., the mobile phone number associated with the payment account in the target payment bank).

[0071] In this way, customers can intuitively understand the relevant information of the payment recipient and their own payment account on the payment interface without having to consult the merchant or platform for the receiving account. This reduces communication costs, shortens the payment operation process, improves customer payment efficiency and certainty, and reduces payment interruption rate. Furthermore, by first identifying the first target transit account in a normal state before jumping to the payment interface to display the first target transit account, abnormal accounts (such as frozen or canceled transit accounts) can be filtered out in advance, ensuring that the virtual funds paid by the customer can enter the merchant's valid account and avoiding the retention or loss of virtual funds due to account abnormalities.

[0072] The following section explains the transitional and basic accounts for merchants.

[0073] In some embodiments, before the terminal is redirected from the merchant platform to the acquiring platform corresponding to the target payment method in response to the customer selecting the target payment method, the merchant can pre-register on the acquiring platform to support customers of the merchant platform to make payments through the acquiring platform. Specifically, in response to the merchant's registration operation for the acquiring platform triggered on the merchant platform, the merchant's terminal can open multiple transit accounts among multiple receiving banks associated with the acquiring platform, and open a basic account for the merchant at the target receiving bank among the multiple receiving banks. The multiple transit accounts include at least a first target transit account.

[0074] In practical applications, merchants log in to the merchant platform via their own terminals (such as computers and mobile phones). In the platform's "Payment Management" or "Account Activation" modules, they find the registration entry for the acquiring platform (e.g., the "Activate Acquiring Platform Service" button). When a merchant clicks this registration entry, the terminal captures the triggered operation and sends a registration request to the merchant platform's backend. This request includes the merchant's entity identifier on the merchant platform (e.g., merchant ID, business registration number). Upon receiving the registration request, the merchant platform's backend first verifies the merchant's current status (e.g., whether business registration has been completed, whether real-name authentication has been passed). If the registration requirements are met, the frontend displays the acquiring platform's registration form. The merchant fills in the registration form information on their terminal, including basic merchant information (merchant name, business registration number, business address), contact information (name, mobile phone number, email), business category (e.g., retail, catering), and uploads relevant qualification documents (scanned copies of business license and account opening permit). After the merchant submits the completed registration form, the merchant's terminal will encrypt and transmit the registration form information to the merchant platform backend. The backend will then verify the integrity and authenticity of the registration form information. If there are no errors, the registration form information will be synchronized to the acquiring platform interface.

[0075] In practical applications, after receiving and approving merchant registration data (including registration form information), the acquiring platform can return a list of multiple associated receiving banks (e.g., Bank A, Bank B, Bank C, Bank D) to the merchant's terminal. The terminal displays this list on the acquiring platform's "Account Activation" page. Each receiving bank entry includes the bank name, supported account types (e.g., transitional account), and required documents for account opening. Merchants can select the receiving banks (multiple selections are allowed, such as selecting Bank A, Bank B, and Bank C simultaneously) for which they wish to open an account (transitional account and basic account) and submit an account opening request. Upon receiving the request, the acquiring platform calls the interfaces of each selected receiving bank to synchronize the merchant's main information (business registration number, merchant name) and account opening application information to the corresponding receiving bank. Each receiving bank reviews the merchant's qualifications in its backend. Once the merchant meets the account opening requirements, the acquiring bank automatically generates a transitional account number and sets the account status to normal. The receiving bank will send the transitional account information (account number, account name, and bank of origin) to the acquiring platform, which will then synchronize it to the merchant's terminal. The terminal will then display the details of the multiple transitional accounts that have been opened on the "Account Management" page.

[0076] In practical applications, after receiving merchant registration data, the acquiring platform can directly call the interfaces of multiple pre-set receiving banks to synchronize the merchant's main information and account opening application information to the corresponding receiving banks. This allows each receiving bank to review the merchant's qualifications in its backend and automatically open multiple transitional accounts for the merchant once the account opening conditions are confirmed.

[0077] Here, the merchant entity information and account opening application information are extracted by the acquiring platform based on the merchant registration data.

[0078] In practice, the acquiring platform will apply to open multiple bridging accounts for merchants at multiple receiving banks, meaning each receiving bank opens at least one bridging account for the merchant. During actual transactions, only one receiving bank needs to be relied upon as the primary bank for virtual resource transactions (i.e., the target receiving bank). Other receiving banks can serve as auxiliary banks, receiving virtual resources only when the primary bank's bridging account experiences an anomaly. To aggregate, settle, and withdraw the merchant's virtual resources, a basic account can also be opened for the merchant at the target receiving bank among the multiple receiving banks. Specifically, the acquiring platform can select a target receiving bank (i.e., the primary bank) from among the multiple receiving banks and apply to the target receiving bank to open a basic account for the merchant. After the target receiving bank approves the merchant's entity information and account opening application information, it will open a basic account for the merchant, generate a basic account number, and bind it to the merchant's entity information.

[0079] From the perspective of the target receiving bank, the transitional account and the basic account opened by the target receiving bank for the merchant have the same account nature, both containing two types of sub-accounts: settlement account and withdrawal account. Specifically, the transitional account includes a transitional settlement account and a transitional withdrawal account, while the basic account includes a basic settlement account and a basic withdrawal account. The settlement account has an independent account number and account name, and the account name is consistent with the merchant's entity information (such as the business registration name). It serves as a clear identifier for the merchant to receive funds externally and supports receiving "external transfers," i.e., virtual resources from outside the target receiving bank's system (such as virtual resources transferred by customers through other bank accounts or payment platforms). The withdrawal account can only receive virtual resources transferred from internal bank accounts and cannot directly receive virtual resources transferred from external accounts (such as virtual resources transferred by customers from other banks). The source of virtual resources is strictly limited to accounts within the same receiving bank and under the same entity (such as transferring virtual resources from a settlement account within the same bank). Furthermore, direct transfers and receipts of virtual resources are not allowed between settlement accounts within the same bank.

[0080] Figure 7 This is a diagram illustrating the account relationships of merchants provided in this application embodiment. See [link / reference]. Figure 7After the acquiring platform completes the merchant registration process through the bank, the merchant has multiple transit accounts (such as transit account 1, transit account 2, and transit account 3), one basic account, and one receiving account. The receiving account is opened by the merchant independently at the corresponding bank and is their personal account. When a customer purchases goods or services from a merchant on the platform and pays the corresponding amount due, the virtual resources of the amount paid through the customer's payment account are first transferred to one of the merchant's transit accounts. The transit account then transfers (allocates) the virtual resources of the amount due to the transit account to the basic account. Finally, the basic account transfers the corresponding virtual resources to the merchant's receiving account. Here, the transit accounts are used to receive virtual resources transferred from the customer's payment account in real time and transfer the received virtual resources to the basic account in real time. Therefore, the transit accounts only serve as a transitional receiving medium for the merchant's virtual resources, while the basic account can be used to aggregate, settle, and withdraw the virtual resources transferred from the transit accounts.

[0081] This section uses an example to illustrate the merchant registration process on the acquiring platform. Figure 8 This application provides a schematic diagram of the registration interface for an acquiring platform. When a merchant requests registration on the merchant platform, the terminal displays the following on the front end of the merchant platform: Figure 8 The registration interface shown includes a registration form where merchants can fill in basic information (merchant name, business registration number, business address), contact information (such as the name, mobile phone number, and email address of the legal representative, shareholders, beneficiaries, and super administrator), and business information (such as industry, full merchant name, and credit code). Merchants can also upload relevant qualification documents (such as scanned copies of their business license, bank account opening permit, and ID card). Additionally, merchants can fill in information about their receiving account in the bank account information section of the registration form. This receiving account refers to the merchant's corporate bank account opened at the relevant bank.

[0082] Figure 9 This is a schematic diagram of the verification and contract signing interface during registration on the acquiring platform provided in this application embodiment, which is intended to support... Figure 8 After the merchant completes the relevant information in the registration form, the merchant platform responds to the trigger operation of the "Next" control on the registration interface and redirects to... Figure 9The verification interface is used to verify the merchant's entered payment account. The verification interface displays relevant information about the merchant's payment account, such as the account name, bank account number, and bank. Verification can also be done by transferring a random amount to the payment account. After verifying the payment account, the merchant platform responds to the "Next" button by displaying the signing interface, which shows a prompt message to the merchant to complete the signing (e.g., "Please have the super administrator scan the QR code to enter the official account, bind your credit account, and complete the service agreement signing. Please complete the signing before 10:45 AM on December 9, 2022"). Figure 10 This is a schematic diagram of the account opening waiting interface provided in an embodiment of this application. Figure 11 This is a schematic diagram of the registration completion interface provided in the embodiments of this application, which is intended to... Figure 9 Once the merchant platform receives confirmation that the merchant has completed the signing process via the corresponding official WeChat account, it will redirect the user to... Figure 10 The account opening waiting interface shown illustrates this process. During this time, the merchant platform can send a registration request to the acquiring platform. Based on the merchant's entity information and account opening application information, the acquiring platform opens multiple transitional accounts and one basic account for the merchant at multiple receiving banks. After receiving confirmation of account opening completion from each receiving bank, the acquiring platform sends a registration success message to the merchant platform. Accordingly, the merchant platform can then... Figure 10 Jump to Figure 11 The registration completion screen shown displays a notification indicating registration is complete (e.g., "Acquiring platform activated") and a "Return to Merchant Platform" control. This completes the merchant's registration process with the acquiring platform. Afterward, when customers purchase items from the merchant through their own merchant platform, they can use the target payment method to pay the outstanding amount to the merchant.

[0083] Through the merchant-based approach, merchants can complete the registration of acquiring platforms, the opening of multiple transitional accounts, and the opening of basic accounts in one stop on their terminal merchant platform. This eliminates the need to log in to each receiving bank's system separately, reducing cross-platform switching costs, shortening the account opening cycle, simplifying the account opening process, and improving operational efficiency. Furthermore, this account opening method strengthens the binding between the account and the merchant entity. Throughout the account opening process, the merchant entity identifier (business registration number, merchant name) is the core, ensuring that all transitional accounts and basic accounts belong to the same merchant entity, avoiding account ownership confusion, and complying with regulatory requirements for "real-name account system," thus ensuring the compliance of the flow of virtual resources.

[0084] In some embodiments, the terminal may determine the first target transition account and display it on the payment interface in the following ways: in response to the merchant having multiple first transition accounts associated with the target receiving bank, the priority of each first transition account is obtained; the first transition account with the highest priority is determined among the multiple first transition accounts; if the merchant type, amount to be paid, and payment method of the amount to be paid do not match the activation strategy of all second transition accounts, and the first transition account with the highest priority is in a normal state, the first transition account with the highest priority is taken as the first target transition account and displayed on the payment interface; the second transition accounts include transition accounts other than the first transition account with the highest priority among the multiple first transition accounts and transition accounts associated with the merchant at other receiving banks.

[0085] In practical applications, before the terminal is redirected from the acquiring platform to the target payment bank's payment interface, the terminal's backend system can access a pre-set merchant account information database. This database stores data on all transitional accounts associated with the merchant, including the account number, account name, corresponding bank information (such as bank name and bank code) for each transitional account, and the priority assigned to each transitional account by the acquiring platform (e.g., sorted by numbers "1-5", with 1 being the highest priority). The terminal can also extract the bank to which the merchant's basic account belongs from the aggregated data (e.g., the basic account belongs to Bank A), and then compare the bank information corresponding to each of the merchant's transitional accounts one by one. Transitional accounts whose corresponding banks match the banks to which the basic account belongs are marked as first transitional accounts. Subsequently, the terminal can read the priority labels of each first transitional account, sort the first transitional accounts in descending order of priority, and determine the highest priority first transitional account (e.g., the transitional account marked with priority "1" is the highest).

[0086] In practical applications, the acquiring platform can access a user activation strategy library, which stores activation strategies for each second transition account (such as account availability rules corresponding to different merchant types, outstanding payment amounts, and payment methods). The terminal extracts key information from the current transaction order: the merchant type (e.g., retail, service), outstanding payment amount (e.g., 5000 yuan), and the payment method for the outstanding payment amount (e.g., bank transfer, quick payment), and matches this information with the activation strategies for all second transition accounts. If the matching result is "the merchant type, outstanding payment amount, and payment method do not match the activation strategies for all second transition accounts," then, assuming the highest-priority first transition account is in a normal state, the highest-priority first transition account can be used as the first target transition account. Here, "normal state" means that the account is in a state of normal receiving and transferring virtual resources. Second transition accounts include transition accounts other than the highest-priority first transition account among multiple first transition accounts, as well as transition accounts associated with other receiving banks, which are different from the target receiving bank.

[0087] By prioritizing the selection of first-tier transition accounts belonging to the same bank as the primary account, the bank affiliation of the transition accounts and primary accounts is ensured to be consistent. This reduces potential delays and costs associated with inter-bank transfers, and allows for real-time resource transfers between accounts within the same bank, guaranteeing that virtual resources can be promptly transferred to the primary account for each transaction. Furthermore, prioritizing and directly locking in the "highest priority first-tier transition account" eliminates the need for manual selection by merchants or customers, shortening account confirmation time. Simultaneously, assuming the account is in a "normal status," payment failures due to account anomalies are avoided, improving the efficiency of account selection and ensuring smooth payment operations.

[0088] In some embodiments, if the highest priority first transition account is in an abnormal state, the acquiring platform in the terminal may also use the highest priority second transition account among the second transition accounts as the first target transition account, or use any of the first transition accounts among the second transition accounts as the first target transition account.

[0089] In practical applications, if the highest priority first transition account is currently in an abnormal state, for example, due to a customer transferring illegal funds to the highest priority first transition account through their payment account in a previous transaction, resulting in the highest priority first transition account being frozen by the bank's risk control system, then another transition account can be selected from the second transition account as the first target transition account. This virtual resource is used to receive the amount of payment pending payment from the customer in this transaction order, in order to ensure the normal execution of this transaction order.

[0090] In practical applications, the acquiring platform can determine the first target transition account from the second transition account according to one of the following two rules: Firstly, the selection rule is based on priority: The acquiring platform can sort all second transition accounts by their marked priority from highest to lowest, and extract the first second transition account after sorting (i.e., the account with the highest priority among the second transition accounts). The "Account Status Query Interface" is called to confirm the status of this second transition account. If the highest-priority second transition account is in a normal state, it is directly used as the first target transition account; if it is still in an abnormal state, the next second transition account after sorting is filtered until an account in a normal state is found, which is then used as the first target transition account.

[0091] Secondly, the random selection rule: Since resource transfers between accounts in the same industry can be carried out in real time, the acquiring platform can also randomly select a first transition account from the second transition accounts, determine any first transition account, and call the "account status query interface" to confirm the status of the first transition account. If it is in a normal state, it will be used as the first target transition account; if it is in an abnormal state, other second transition accounts will be randomly selected again until an account in a normal state is found and used as the first target transition account.

[0092] In some cases, if all first transition accounts of the second transition account are in an abnormal state, a random selection may be made from transition accounts belonging to other receiving banks within the second transition account to determine the first target transition account.

[0093] By employing the above method, when the highest-priority first transition account is in an abnormal state, a second transition account is selected to supplement the first target transition account. This avoids payment process interruptions due to a single account's abnormality, ensuring customers can complete payment operations normally and thus guaranteeing payment continuity. Furthermore, by providing both "select by priority" and "random selection" rules, it can adapt to different business needs of the acquiring platform (e.g., selecting the priority rule when prioritizing account usage stability, and selecting the random rule when prioritizing account load balancing), enhancing the process's adaptability to different scenarios. The selection of the second transition account implicitly verifies the account status (only accounts in a normal state can serve as the first target transition account), avoiding displaying abnormal accounts to customers, reducing payment failures due to account issues, and improving the customer payment experience.

[0094] In some embodiments, if the merchant type, the amount to be paid, and the payment method of the amount to be paid are all compatible with the activation strategy of the third transition account, the third transition account is identified as the first target transition account; wherein, the activation strategy is used to reactivate the third transition account or maintain the normal operation of the third transition account; the third transition account is a second transition account belonging to a different bank than the basic withdrawal account.

[0095] In practical applications, each transition account of a merchant can be pre-configured with a corresponding activation strategy. The activation strategy is used to reactivate the transition account when it is inactive, or to maintain the normal operation of the transition account.

[0096] Here, even if the highest priority first transition account is in normal status, if the merchant type, amount to be paid, and payment method of the current transaction order happen to match the activation strategy of the third transition account, the third transition account is directly identified as the first target transition account. In this transaction, the virtual resources of the amount to be paid by the customer are transferred through the third transition account. In this way, the normal progress of the transaction can be guaranteed, and the deactivation caused by the third transition account being idle can be avoided.

[0097] Through the above methods and the activation strategy adaptation mechanism, even if the highest priority first transition account is in a normal state, a third transition account belonging to a different bank than the basic withdrawal account can still be activated. This fully utilizes the diverse transition account resources associated with the merchant, avoids the idleness of transition accounts, and ensures the continuous availability of accounts. The application of the activation strategy (reactivating or maintaining the normal operation of the third transition account) can improve the activity and stability of the third transition account, reserve usable accounts for subsequent payment scenarios, and enhance the risk resistance of the account system.

[0098] See also Figure 3 The following explanation follows step 102 above.

[0099] In step 103, in response to a payment operation triggered by the payment interface, the virtual resources of the amount to be paid are transferred from the payment account associated with the target payment bank to the first target transition account. The virtual resources of the amount to be paid are then transferred in real time to the merchant's basic withdrawal account at the target receiving bank through the first target transition account, and finally transferred to the merchant's receiving account through the basic withdrawal account.

[0100] In some embodiments, the terminal can transfer virtual resources of the amount to be paid from the payment account associated with the target payment bank to the first target transition account in the following ways: in response to a confirmation operation for the first target transition account displayed on the payment interface, the terminal controls the target payment bank to send a first verification code to the contact person associated with the payment account via SMS or email, and displays a verification code filling interface; in response to receiving a verification code filling operation on the verification code filling interface, the terminal controls the target payment bank to verify the filled second verification code and the first verification code to obtain a verification result; in response to a payment confirmation operation triggered based on the verification code filling interface, if the verification result indicates that the first verification code and the second verification code are the same, the terminal transfers the virtual resources of the amount to be paid from the payment account associated with the target payment bank to the first target transition account.

[0101] In practical applications, after viewing the information of the first target transitional account on the payment interface, the customer clicks the confirmation control on the payment interface. The terminal captures this confirmation operation for the first target transitional account and immediately sends an operation instruction to the acquiring platform. The instruction carries the target payment bank identifier, payment account identifier, first target transitional account identifier, and the amount to be paid. After receiving the operation instruction, the acquiring platform simultaneously initiates a verification code request to the target payment bank, requesting the target payment bank to send the first verification code to the contact person associated with the payment account (sent via SMS or email). At the same time, the acquiring platform returns a pop-up trigger signal to the terminal. The terminal responds to this trigger signal and displays a verification code return interface in a pop-up window on the payment interface. The verification code return interface may include a verification code input box, a "Confirm" button, a "Resend" button, and input prompts (such as "Please enter the 6-digit verification code received on your mobile phone or email"). The customer checks the contact's mobile phone number or email address associated with the payment account to obtain the first verification code. Then, the customer enters the code (numbers or characters) in the input box on the terminal's verification code entry interface. The terminal captures this entry in real time, temporarily storing the customer's input as the second verification code, and allows the customer to modify or re-enter it. After completing the entry, the customer clicks the "OK" button on the verification code entry interface. In response to this trigger, the terminal sends a "Verification Code Verification Request" to the acquiring platform, carrying the second verification code, the target payment bank identifier, and the payment account identifier. The acquiring platform synchronizes the second verification code to the target payment bank, controlling the bank to compare the first and second verification codes for consistency, generating a verification result (indicating sameness or difference), and returning the result to the acquiring platform, which then synchronizes it to the terminal. When the customer clicks the "OK" button on the verification code entry interface, this action is also considered a payment confirmation triggered by the verification code entry interface. The terminal sends a "Payment Confirmation Instruction" to the acquiring platform, carrying the amount to be paid and the first target transition account identifier. After receiving the payment confirmation instruction, the acquiring platform first checks the verification result returned by the target paying bank. If the verification result indicates that the first verification code and the second verification code are the same, the acquiring platform immediately sends a "transfer instruction" to the target paying bank, controlling the target paying bank to transfer the virtual resources of the amount to be paid from its associated payment account directly to the first target transition account. After the transfer is completed, the target paying bank returns a "transfer successful" notification to the acquiring platform, which then synchronizes it to the terminal. The terminal displays a "payment successful / transfer successful" message on the payment interface and shows the transfer result (e.g., "XX yuan has been transferred from the payment account to the first target transition account").

[0102] As an example, Figure 12 This is a second schematic diagram of the payment interface provided in the embodiments of this application, which is to inherit... Figure 6In Figure (B), the terminal responds to the customer's trigger action on the "Agree to the Agreement, Next" control in the payment interface, determines the confirmation action for the first target transit account displayed in the payment interface, and responds to the confirmation action, see [reference needed]. Figure 12 In Figure (A), a pop-up window displays a verification code return interface 160 on the payment interface. In response to a trigger operation on the "Get Verification Code" control in the verification code return interface 160, the terminal sends a first verification code (e.g., a random number with a fixed number of digits) to the customer's pre-registered contact information (e.g., a mobile phone number) at the target payment bank. After receiving the verification code entry operation on the verification code return interface, the terminal controls the target payment bank to verify the entered second verification code and the first verification code, obtaining the verification result. Subsequently, in response to a payment confirmation operation triggered based on the verification code return interface, if the verification result indicates that the first and second verification codes are the same, the terminal transfers the virtual resources of the payment amount from the payment account associated with the target payment bank to the first target transition account, and then... Figure 12 The (A) diagram in the image is switched to display as Figure 12 The successful transfer notification page shown in Figure (B) is shown in the middle.

[0103] The above-described verification mechanism, involving "sending the first verification code + filling in the second verification code + consistency verification," ensures that the payment operation represents the genuine intention of the contact person associated with the payment account, preventing unauthorized use of the payment account for fund transfers and guaranteeing the security of fund transfers. Throughout the process, key operations (confirming the account, filling in the verification code, and confirming payment) are all initiated by the customer, making the operation traceable and ensuring compliance. The verification code is filled in via a pop-up window on the same payment interface, eliminating the need to navigate to other pages. Furthermore, the steps (confirming the account → receiving the verification code → filling in the verification code → confirming payment → transfer) are seamlessly integrated, reducing customer steps, improving workflow continuity, and enhancing the payment experience.

[0104] In some embodiments, the terminal may also control the acquiring platform to transfer virtual resources of the amount to be paid from the payment account associated with the target payment bank to the first target transition account by: controlling the acquiring platform to perform risk identification on the payment account; and in response to the successful risk identification of the payment account, transferring the virtual resources of the amount to be paid from the payment account associated with the target payment bank to the first target transition account.

[0105] In practical applications, after the customer confirms the first target transit account on the payment interface (or when the payment confirmation operation is triggered), the terminal can send a "risk identification request" to the acquiring platform. The risk identification request can include the target paying bank identifier, paying account identifier (such as account number and account name), the amount to be paid, and current payment scenario information (such as payment time and terminal device identifier), which the acquiring platform uses to conduct risk identification. Upon receiving and responding to the "risk identification request," the acquiring platform immediately activates its risk identification system, invokes a pre-set risk identification rule base (containing judgment criteria for account security, transaction anomalies, etc.), matches the key information in the risk identification request with the risk identification rule base, and conducts risk identification on the paying account.

[0106] As an example, the acquiring platform's risk identification system can verify payment accounts from multiple dimensions: basic account security, verifying whether the payment account is in an abnormal state (such as frozen or reported lost), and whether there are recent logins from other locations or operation records from unfamiliar devices; transaction rationality, verifying whether the amount to be paid exceeds the daily transaction limit of the payment account, whether it matches the historical payment amount pattern of the account, and whether the current payment time belongs to the high-frequency payment period of the account; and associated risk screening, verifying whether the payment account is associated with risky lists (such as fraud-related accounts or illegal accounts), and whether there are abnormal behaviors such as multiple consecutive payments of the same amount in a short period of time.

[0107] Subsequently, the acquiring platform generates a "risk identification passed" or "risk identification failed" result based on the above multi-dimensional verification results. If all verification dimensions comply with security rules, it can be determined as "risk identification passed"; if any dimension triggers a risk rule (such as the account being operated by an unfamiliar device in a different location), it is determined as "risk identification failed". If the acquiring platform's risk identification result is "risk identification passed", the terminal can immediately trigger the acquiring platform to execute a "confirm transfer instruction", which clearly specifies the amount to be paid, the payment account identifier associated with the target payment bank, and the identifier of the first target transition account. In response to the "confirm transfer instruction", the acquiring platform initiates a fund transfer request to the target payment bank, requesting the target payment bank to transfer the virtual resources of the amount to be paid from its associated payment account. After verifying the legality of the fund transfer request (such as the acquiring platform's permissions and whether the account balance is sufficient), the target payment bank executes the transfer operation, transferring the virtual resources of the amount to be paid to the first target transition account. After the transfer is completed, the target paying bank returns a "transfer successful" notification to the acquiring platform. The acquiring platform then synchronizes this notification to the terminal, which displays a "payment successful / transfer successful" message and transfer details (such as "XX yuan has been transferred from the payment account to the first target transition account") on the payment interface.

[0108] By employing the above methods and enabling the acquiring platform to conduct multi-dimensional risk identification of payment accounts, risks such as account anomalies and transaction irregularities can be detected in advance. This prevents risky accounts from participating in fund transfers, reduces the probability of virtual resources being misappropriated or mistransferred, and improves the security of fund transfers. "Risk identification passed" as a prerequisite for resource transfer effectively intercepts abnormal payment operations (such as payments made using stolen accounts from unfamiliar devices), reducing financial losses for merchants or customers due to risky transactions.

[0109] In some embodiments, in response to a failure to identify the risk of the payment account, the terminal may display a payment failure message on the payment interface, which indicates the reason for the payment failure.

[0110] In practical applications, after the acquiring platform completes the risk identification of the payment account, if the risk identification result is "risk identification failed," it can generate a corresponding failure reason (such as account abnormality, transaction exceeding limits, or unfamiliar device) and synchronize it to the terminal. The terminal receives this result information and extracts the core conclusion and specific failure reason of "risk identification failed" through preset parsing logic, ensuring that the information is complete and can be converted into a prompt that the customer can understand, and displays this prompt content (i.e., payment failure prompt information) on the payment interface.

[0111] By clearly displaying the reasons for payment failures, the system avoids customers repeatedly attempting the payment due to "unknown failures," reducing customer confusion and increasing trust in the payment process and transparency. Furthermore, suspending subsequent payment operations prevents customers from continuing payments without addressing risks (such as account theft), further protecting the security of payment account funds and preventing risky transactions.

[0112] In some embodiments, after the terminal transfers the virtual resources of the amount to be paid from the payment account associated with the target payment bank to the first target transit account through the acquiring platform, a payment success message can be displayed on the payment interface, and the payment success message can be sent to the merchant platform through the acquiring platform.

[0113] In practical applications, after the target paying bank completes the transfer of virtual resources for the amount to be paid from the paying account to the first target transition account, the terminal can control the target paying bank to return a "transfer successful" notification to the acquiring platform. This notification includes information such as the paying account identifier, the first target transition account identifier, the amount to be paid, the transfer time, and the transaction serial number. Upon receiving the "transfer successful" notification, the acquiring platform verifies the completeness of the notification information (e.g., confirming the uniqueness of the transaction serial number and that the amount matches the amount to be paid) to ensure the transfer result is genuine and valid. After successful verification, the acquiring platform synchronizes the "payment successful" result and associated information (transaction serial number, transfer time) to the terminal. The terminal displays the generated payment success message in the current payment interface via a pop-up, full-screen, or fixed-area highlight, enhanced with a success icon (such as a green checkmark) to enhance visual feedback. After the customer clicks the "Complete" control, the terminal can close the pop-up notification, redirect to the order details page (displaying the complete transaction record), or return to the merchant platform homepage for the customer to choose subsequent operations.

[0114] Here, while synchronizing the "payment successful" result to the terminal, the acquiring platform automatically encapsulates the payment success notification information required by the merchant platform. This encapsulation includes: merchant identifier (associated with the acquiring merchant), order number (corresponding to the original shopping order on the merchant platform), amount due, transaction serial number, transfer time, and information of the first target intermediary account (for merchant reconciliation). After encapsulation, the acquiring platform encrypts and sends the information to the merchant platform via a pre-defined interface (such as a RESTful interface). Upon receiving the payment success notification from the acquiring platform, the merchant platform verifies the information's legitimacy (e.g., confirming ownership through the merchant identifier and verifying the signature to prevent tampering). If verification is successful, the merchant platform synchronizes the information to its own order management system, updates the corresponding order status to "paid," and records key information such as the transaction serial number for subsequent reconciliation and fund management.

[0115] By employing the above methods, customers are shown real-time payment success notifications, allowing them to immediately confirm the payment result. Information is synchronized with merchants, enabling them to promptly grasp the order payment status and avoid questions or disputes arising from information asymmetry, thus improving transparency. Furthermore, a closed loop of "payment completion - result synchronization - order update" is formed through the acquiring platform, ensuring full traceability of the transaction chain and facilitating subsequent reconciliation, refunds, and other operations, guaranteeing the integrity of the transaction process. Moreover, customers do not need to manually check payment results, and merchants do not need to manually verify payment information, reducing operational costs for both parties.

[0116] In some embodiments, if the payment banks displayed in the acquiring platform do not include the target payment bank that the customer wants to use, the terminal can also display the first target transition account on the payment interface in the following ways: displaying a second viewing entry for the first target transition account in the acquiring platform; if the target payment bank is not included in some payment banks and other payment banks associated with the acquiring platform, the first target transition account is displayed in response to the triggering operation of the second viewing entry; correspondingly, the terminal can transfer the virtual resources of the pending payment amount from the payment account associated with the target payment bank to the first target transition account in the following ways: exiting the acquiring platform in response to the copying operation triggered by the acquiring platform for the first target transition account; displaying the transfer interface of the bank application in response to the opening operation of the bank application corresponding to the target payment bank, and filling the transfer interface with the first target transition account; transferring the virtual resources of the pending payment amount from the payment account associated with the target payment bank to the first target transition account in response to the transfer operation triggered by the transfer interface.

[0117] In practical applications, the terminal can also display a second viewing entry for the primary target transition account on the acquiring platform. Customers can trigger this second entry to view the merchant's primary target transition account information, copy the account, and then execute transfer operations themselves in the target payment bank's banking application based on the copied account. For example, see... Figure 5 , Figure 5 The interface shown also includes a "View Payment Card Number" control 150 (i.e., the second viewing entry point). In response to the trigger operation of the "View Payment Card Number" control 150, a pop-up window can be displayed to show the account information of the first target transition account.

[0118] Specifically, in response to the copy operation, the customer's terminal can first exit the acquiring platform, and then, in response to the customer's operation of opening the bank application corresponding to the target payment bank, display the bank application's transfer interface, realizing cross-application data transfer of "copy → exit → open application → fill". The implementation details of the above process will be explained below.

[0119] First, the copy operation is detected and the information is stored locally. During copy event capture and information structuring, the acquiring platform captures the copy operation by triggering events (such as the clipboard event), records the account information (structured data) of the first target transit account, and not only copies the information to the system clipboard, but also encrypts and stores it in the terminal's secure storage area, generating a unique identifier (valid for 10 minutes) associated with the information. After the copy operation is completed, in response to the exit operation for the acquiring platform, the acquiring platform is exited, such as through navigator.app.exitApp() (mobile H5) or by closing the current page (mini-program or APP), and an exit prompt is displayed (such as "Payment information has been copied, please open the XX Bank APP to complete the payment"), while sensitive data in memory is cleared (to avoid residual data).

[0120] Secondly, the customer's opening of the bank application triggers information retrieval. After exiting the acquiring platform, the customer manually opens the bank application corresponding to the target payment bank from the terminal desktop or application list. When the bank application starts, the homepage or the "Transfer or Payment" entry will check for pending information from the acquiring platform (by detecting the unique identifier in the system's secure storage area). The bank application requests to read the information in the terminal's secure storage through a preset interface (agreed with the acquiring platform) to verify the validity of the unique identifier (whether it is within the validity period and whether it was legally written by the acquiring platform). If the verification is successful, the complete receiving account information is decrypted; if the verification fails, it is not read (e.g., if the unique identifier has expired, the message "Information has expired, please copy again" is displayed).

[0121] Finally, the bank application displays and populates the transfer interface. After obtaining the recipient's account information, the bank application automatically guides the customer to the transfer interface (instead of the default homepage) and displays a prompt at the top of the transfer interface (e.g., "Payment information detected, autofill?"). After the customer confirms, the bank application populates the payment form with the decrypted target transition information (recipient's name, account number, and bank are automatically matched), and simultaneously synchronizes the information to the system clipboard (as a backup for the customer to manually check or modify). If the customer chooses not to autofill, only a clipboard prompt is displayed (e.g., "Payment information has been copied to the clipboard, you can paste it manually"). After completing the information population, the bank application automatically deletes the unique identifier and associated information from the terminal's secure storage (to avoid duplicate reading). Then, in response to the transfer operation triggered by the transfer interface, the virtual resources of the payment amount are transferred from the payment account associated with the target payment bank to the first target transition account.

[0122] The above approach, centered on customers actively opening the bank application, is suitable for scenarios where the bank application is not installed or the protocol is not compatible, and has strong compatibility. Furthermore, it ensures the security of payment information through encrypted transmission and permission verification, while reducing customer manual input errors through structured data filling, laying the foundation for subsequent payment operations.

[0123] In some embodiments, as described above, the basic account includes a basic settlement account and a basic withdrawal account, that is, the merchant's basic withdrawal account belongs to the merchant's basic account at the target receiving bank; the terminal can transfer the virtual resources of the amount to be paid in real time to the merchant's basic withdrawal account at the target receiving bank through the first target transition account, and transfer the virtual resources of the amount to be paid to the merchant's receiving account through the basic withdrawal account in the following manner: the virtual resources of the amount to be paid are transferred in real time to the basic withdrawal account through the first target transition account, the virtual resources of the amount to be paid are transferred to the basic settlement account through the basic withdrawal account, and after the virtual resources of the amount to be paid are split in the basic settlement account, the remaining amount of virtual resources after splitting is transferred to the basic withdrawal account, and the remaining amount of virtual resources is transferred to the merchant's receiving account through the basic withdrawal account.

[0124] In practical applications, the transfer and receipt of virtual resources cannot be performed between settlement accounts belonging to the same merchant entity and the same bank. Therefore, when a merchant's primary target transit account and basic withdrawal account belong to the same bank, the basic withdrawal account can be used as a transit point for virtual resources. First, the virtual resources of the amount to be paid are transferred to the basic withdrawal account in real time through the primary target transit account. Then, the virtual resources of the amount to be paid are transferred to the basic settlement account in real time through the basic withdrawal account, so that the splitting process can be performed in the basic settlement account. The remaining amount of virtual resources after the splitting process is transferred to the basic withdrawal account, and the remaining amount of virtual resources is transferred to the merchant's receiving account through the basic withdrawal account.

[0125] Here, the first target transitional account also includes a transitional settlement account and a transitional withdrawal account. Since the transitional withdrawal account cannot receive virtual resources from outside the bank, the virtual resources of the pending payment amount transferred from the customer's payment account can be received through the transitional settlement account within the first target transitional account. The virtual resources of the pending payment amount are then directly transferred to the basic withdrawal account through the transitional settlement account of the first target transitional account. The entire process does not require the use of a transitional withdrawal account. By leveraging the characteristic that "the first target transitional account and the basic account belong to the same bank," real-time transfers within the bank's accounts replace inter-bank transfers, reducing delays and costs associated with inter-institutional transfers, improving the overall efficiency of virtual resource transfers, and mitigating the risk of transfer failures due to differences in inter-bank systems, thus ensuring transfer efficiency and stability. The pending payment amount is first transferred to the basic settlement account for splitting, and then the remaining amount is transferred back to the basic withdrawal account. Through the division of labor—"dedicated splitting in the settlement account and dedicated transfer in the withdrawal account"—the confusion between splitting operations and fund flows can be avoided, ensuring the accuracy of splitting amount calculations and remaining amount retention.

[0126] In some embodiments, the terminal may also transfer the virtual resources of the amount to be paid to the basic withdrawal account in real time through the first target transition account in the following manner: perform consistency verification on the account subject corresponding to the first target transition account and the account subject corresponding to the basic account to obtain a first verification result; if the first verification result indicates that the account subject corresponding to the first target transition account and the account subject corresponding to the basic account are consistent, transfer the virtual resources of the amount to be paid to the basic withdrawal account in real time through the first target transition account.

[0127] In practical applications, after the acquiring platform determines that the primary target transitional account and the basic account belong to the same bank, it can automatically access the "Account Entity Information Database" to extract the account entity information (such as merchant entity name and business registration number) corresponding to the primary target transitional account, as well as the account entity information (same as merchant entity name and business registration number) corresponding to the basic account. The acquiring platform performs a completeness check on the extracted two types of account entity information to confirm whether they contain core identifiers (such as business registration number and entity name). Subsequently, the acquiring platform compares the account entity information of the primary target transitional account with the account entity information of the basic account using core fields, focusing on comparing the "merchant entity name" (such as "XX Trading Co., Ltd.") and the "business registration number" (such as "91XXXXXXXXXXXXXXX"). The comparison logic is an exact match, meaning that the entity names of the two accounts must be completely identical, and the business registration numbers must be exactly the same. If all core fields match, the acquiring platform generates a "first verification result" indicating that "the account holder corresponding to the first target transition account and the account holder corresponding to the basic account are consistent." If any core field is inconsistent (e.g., the account holder name contains a typo, or the registration number has a different number of digits), the first verification result indicates "account holders are inconsistent." When the first verification result indicates "account holders are consistent," the virtual resource transfer process from the first target transition account to the basic withdrawal account is triggered. If the first verification result indicates "account holders are inconsistent," the transfer operation is terminated, and a message "account holders are inconsistent, transfer failed" is returned.

[0128] By employing the above methods and verifying account entity consistency, it is ensured that funds flow under the same merchant entity throughout the transfer of virtual resources from the primary target transition account to the basic withdrawal account. This avoids fund mismatches caused by inconsistent account entities (such as transfers to other merchant accounts), preventing fund ownership risks from the outset and ensuring fund security. Account entity consistency verification complies with financial regulatory requirements that "fund transfers must match the identity of the entity," ensuring that each virtual resource transfer has a clear entity affiliation, providing a compliance basis for subsequent reconciliation and auditing, and reducing compliance risks caused by entity mismatches. Furthermore, by comparing core fields (entity name, registration number) in advance to eliminate entity inconsistencies, complex refund or adjustment operations are avoided if incorrect fund ownership is discovered after the transfer, reducing process redundancy and improving the accuracy and efficiency of virtual resource transfers.

[0129] In some cases, if there is no need to perform splitting the payment for the outstanding amount paid by the customer, the virtual resources of the outstanding amount can be transferred directly to the merchant's receiving account through the basic withdrawal account after the virtual resources of the outstanding amount are transferred to the basic withdrawal account in real time through the first target transit account.

[0130] In some embodiments, in response to the merchant's first target transition account associated with the target receiving bank being in an abnormal state, the terminal displays the merchant's second target transition account associated with another receiving bank in the payment interface; the virtual resources of the amount to be paid are transferred to the basic settlement account through the second target transition account, and after the basic settlement account performs the splitting processing of the virtual resources of the amount to be paid, the remaining amount of virtual resources after the splitting processing is transferred to the basic withdrawal account, and the remaining amount of virtual resources is transferred to the merchant's receiving account through the basic withdrawal account.

[0131] In practical applications, when a merchant's first target transitional account associated with the target receiving bank is in an abnormal state and the merchant's other transitional accounts associated with the target receiving bank (which are different from the first target transitional account) are also in an abnormal state, cross-bank transfer of virtual resources can be performed. Therefore, a second target transitional account can be determined from the merchant's other transitional accounts associated with the receiving bank (e.g., randomly selected, determined based on priority, determined based on the hit of the activity detection strategy, etc.), and the determined second target transitional account can be displayed on the payment interface.

[0132] Subsequently, the virtual resource transfer operation needs to be executed according to the preset transfer frequency. When the terminal receives the virtual resource transfer operation triggered by the preset transfer frequency, it can directly transfer the virtual resource amount to be paid to the basic settlement account through the transition settlement account of the second target transition account (this is because the settlement accounts of different banks can directly transfer and receive virtual resources). After the basic settlement account processes the virtual resource amount to be paid, the remaining amount of virtual resources is transferred to the basic withdrawal account, and then the remaining amount of virtual resources is transferred to the merchant's collection account through the basic withdrawal account.

[0133] The above method is suitable for scenarios where the transit accounts in the target receiving bank are all in an abnormal state. In order to ensure that customers can conduct normal transactions, cross-bank transit accounts can be used to receive funds paid by customers. In this way, the combination of cross-bank clearing and intra-bank transfer can ensure that virtual resources can break through bank barriers and complete the flow, thus meeting the business needs of merchants with multiple bank accounts.

[0134] In some embodiments, the terminal can transfer the remaining amount of virtual resources from the basic withdrawal account to the merchant's receiving account in the following manner: perform consistency verification on the account name of the basic withdrawal account and the account name of the receiving account to obtain a second verification result; if the second verification result indicates that the account name of the basic withdrawal account and the account name of the receiving account are consistent, transfer the remaining amount of virtual resources from the basic withdrawal account to the merchant's receiving account.

[0135] In practical applications, after the remaining amount of virtual resources after sub - account processing is transferred to the basic withdrawal account in the basic settlement account, and after receiving the "successful transfer of remaining amount" notification, the back - end system of the acquirer platform automatically calls the "account name information database" to extract the account name of the basic withdrawal account (such as the full name of the merchant entity) and the account name of the merchant's receiving account (such as the same full name of the merchant entity) respectively. The acquirer platform can perform an integrity check on the two types of extracted account name information to confirm whether the account name is complete (such as no missing characters, extra characters or ambiguous characters). The acquirer platform precisely compares the account name of the basic withdrawal account with the account name of the receiving account. The comparison rule is character - level exact match (including the order and content of Chinese characters, letters, and punctuation marks must be the same). For example, "Company B Technology Co., Ltd." and "Company B Technology Co., Ltd." are considered consistent, while "Company B Technology Company" and "Company B Technology Co., Ltd." are considered inconsistent. If the account name exact comparison is consistent, the acquirer platform generates a "second verification result" and indicates that "the account name of the basic withdrawal account and the account name of the receiving account are the same"; if the comparison is inconsistent, the second verification result indicates that "the account names are different". The acquirer platform receives the second verification result. If the second verification result indicates that "the account names are the same", it triggers the process of transferring the remaining amount of virtual resources from the basic withdrawal account to the merchant's receiving account; if the result indicates that "the account names are different", the transfer operation is terminated, and a prompt message of "the account names are different, transfer failed" is returned to the merchant platform. In the case where the second verification result is "the account names are the same", the acquirer platform sends a transfer instruction to the bank where the basic withdrawal account belongs. The instruction clearly states the transfer direction (basic withdrawal account → merchant's receiving account), the remaining amount, the basic withdrawal account identifier, and the merchant receiving account identifier. After receiving the instruction, the target receiving bank verifies the balance of the basic withdrawal account (whether it contains sufficient remaining amount of virtual resources) and the status of the receiving account (whether it is normal). After passing the verification, it performs the transfer operation, transfers the virtual resources of the remaining amount from the basic withdrawal account to the merchant's receiving account, and returns a "successful transfer of remaining amount to receiving account" notification to the acquirer platform.

[0136] Through the above method, by verifying the consistency of the account names, it is ensured that the virtual resources of the remaining amount can be accurately transferred to the merchant - designated receiving account, avoiding mis - transfer of funds caused by inconsistent account names (such as transferring to other accounts with similar names), and guaranteeing the accuracy of fund transfer from key links.

[0137] In some embodiments, the terminal can also respond to the merchant platform receiving a customer's refund request, send the refund request to the acquirer platform, so that when the acquirer platform determines that the balance in the basic withdrawal account is greater than the refund amount indicated by the refund request, it transfers the virtual resources corresponding to the refund amount from the basic withdrawal account to the payment account.

[0138] In practical applications, customers can initiate a refund request on the merchant platform (e.g., by clicking the "Apply for Refund" button). The terminal captures this refund request and submits the refund request (including the order number, refund amount, and refund reason) to the merchant platform. Upon receiving the refund request, the merchant platform verifies the order status (e.g., whether payment has been made, whether the refund period has expired). If the refund conditions are met, it generates standardized refund request data (including merchant identifier, order number, refund amount, and original payment account identifier) ​​and sends the encrypted standardized refund request to the acquiring platform via a preset interface, along with the merchant's signature information (used by the acquiring platform to verify the request's authenticity). The acquiring platform receives and responds to the refund request, verifying the merchant's signature validity (decrypted using the merchant's registered public key) and confirming the request's authenticity and lack of tampering. After successful verification, it parses the core information in the request: order number, refund amount, and original payment account identifier, and then queries the corresponding basic withdrawal account information (account identifier, current balance). When the acquiring platform determines that the balance in the basic withdrawal account is greater than the refund amount, it determines that the balance is "sufficient" and triggers the subsequent refund transfer process. Then, the acquiring platform controls the basic withdrawal account to transfer the virtual resources of the refund amount to the customer's original payment account to complete the refund operation.

[0139] By connecting the merchant platform and the target receiving bank through the acquiring platform, a closed loop of "customer application → merchant forwarding → acquiring processing → bank transfer" is formed, ensuring the efficient transmission and execution of refund requests, avoiding process interruptions, and guaranteeing the smoothness of the refund process.

[0140] In one example Figure 13 This is a second flowchart illustrating the virtual resource processing method provided in this application embodiment. See also... Figure 13 The terminal's processing of virtual resources may include: Under normal circumstances (i.e., when the transitional account belonging to the same bank as the merchant's basic account is in a normal state), the customer can make payment from the target payment bank's payment account to the main bank's transitional account (i.e., the first target transitional account belonging to the same bank as the basic account). Correspondingly, the virtual resources of the amount to be paid can be transferred from the payment account to the merchant's main bank's transitional account (i.e., the first target transitional account). The virtual resources of the amount to be paid can then be transferred in real time from the main bank's transitional account to the merchant's basic withdrawal account. The virtual resources of the amount to be paid can then be transferred from the basic withdrawal account to the merchant's basic settlement account. The distribution processing of the virtual resources of the amount to be paid is completed in the basic settlement account. Subsequently, the virtual resources of the remaining amount after distribution processing are transferred from the basic settlement account to the merchant's basic withdrawal account. The remaining amount can then be withdrawn from the basic withdrawal account (i.e., the virtual resources of the remaining amount are transferred to the merchant's receiving account), thus completing the processing of the virtual resources for one transaction order for the customer.

[0141] After the above processing is completed, if the customer initiates a refund operation on the merchant platform, the acquiring platform's refund system will respond to the refund request sent by the merchant platform, verify whether the balance of the merchant's basic withdrawal account is sufficient for the refund amount. If the balance of the merchant's basic withdrawal account is greater than the refund amount, an automatic refund will be triggered, and the virtual resources of the refund amount will be transferred from the merchant's basic withdrawal account to the customer's payment account at the target payment bank.

[0142] It should be noted that when a customer makes a payment, if the primary bank's interbank transfer account is in an abnormal state, the acquiring platform can switch to an interbank transfer account in the backup bank (such as a second target transfer account belonging to a different bank than the primary account) to receive the customer's pending payment amount. In this case, after the interbank transfer account receives the virtual resources of the pending payment amount paid by the customer through the payment account, it can perform interbank transfer, transferring the virtual resources of the customer's pending payment amount from the interbank transfer account to the merchant's basic settlement account in the primary bank, and then carry out the process of splitting accounts and withdrawing funds.

[0143] Through the embodiments of this application, when a customer selects a target payment method to pay a merchant on the merchant platform, the merchant platform can redirect to the acquiring platform corresponding to the target payment method. The acquiring platform displays the payment order and multiple payment banks associated with it. In response to the selection of a target payment bank, the acquiring platform redirects to the target payment bank's payment interface, which displays the merchant's first target transit account associated with the target receiving bank. Subsequently, after the customer triggers the payment operation, the virtual resources of the amount to be paid are transferred from the payment account associated with the target payment bank to the first target transit account, and then the virtual resources are transferred to the merchant in real time through the first target transit account. Finally, the virtual resources are transferred to the merchant's receiving account through the basic withdrawal account. In this way, by opening a transitional account and a basic withdrawal account for the merchant, the transitional account is used to receive virtual resources transferred from the customer's payment account, and the basic account is used to aggregate and withdraw the virtual resources transferred from the transitional account. If there is a risk in the payment account and risky funds are transferred in, only the corresponding first target transitional account needs to be frozen. In this way, for the merchant, only the amount of payment involved in this order is frozen in the first target transitional account, and the risky funds are prevented from being directly transferred to the receiving account and contaminating the receiving account. This improves the merchant's account disaster recovery capability and the security of the receiving account.

[0144] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0145] The following section will first explain the terms used in the embodiments of this application, including: Acquiring platform: It has the ability to connect to the paying bank for fund transfers and the receiving bank for account management, providing professional services such as procurement payment, intelligent revenue sharing, account management, and financial management for small and micro enterprises, chain brands and other merchants.

[0146] Receiving bank: The bank used by businesses or individuals to receive payments from customers when conducting sales activities.

[0147] A basic custodian account (i.e., a basic account) is a special account opened by a bank or other financial institution for a merchant to safeguard and manage the merchant's virtual resources. The special characteristic of a basic custodian account is that its operation usually requires joint confirmation from both the merchant and the custodian institution (such as a bank), and the merchant's virtual resources are protected by law within the account and cannot be disposed of arbitrarily.

[0148] Basic Settlement Account: A settlement sub-account belonging to the basic custody account. It can directly receive customer deposits and can also be used for settlement, distribution and other processing of virtual resources.

[0149] Basic withdrawal account: A withdrawal sub-account belonging to the basic custody account. It can only receive virtual resources transferred from the same main settlement account and is used for processing virtual resource withdrawals, refunds, etc.

[0150] Transitional Custody Account (also known as Transitional Account): Also known as Multi-level Custody Account, it is a custody account opened by a merchant when joining the acquiring platform. There are usually multiple accounts, which are used to receive virtual resources from customers to pay the merchant. During settlement, the virtual resources are transferred from the transitional custody account to the basic custody account. The acquiring platform names the accounts as multi-level custody accounts according to their functions and uses.

[0151] In related technologies, since there is no transfer capability between settlement accounts of the same merchant entity within the same bank, interbank transfers are typically used to transfer and allocate customer payments. For example, if a merchant's basic custody account and transitional custody account are opened in different banks, when a customer makes a payment, the virtual resources of the customer's payment amount are first transferred to the transitional custody account, and then the transitional custody account transfers the virtual resources to the basic custody account in real time or after aggregation. However, if the transfer frequency is too fast, the interbank transfer cost will be high, while if the transfer frequency is too slow, a large amount of money will be affected if the transitional custody account is frozen due to risk control. Therefore, the disaster recovery capability of the solutions in related technologies is low, and the problem of interbank transfer costs cannot be avoided.

[0152] The virtual resource processing method in this application embodiment establishes resource allocation capabilities between the transition account of the main bank (i.e., the target receiving bank) and the basic withdrawal account of the basic account, as well as between the basic withdrawal account and the settlement account of the basic account, through a multi-level custodian account system. This enables the main bank account to achieve the ability to control and recover from disasters, while effectively avoiding the channel cost problem caused by cross-bank transition account allocation.

[0153] Below, in conjunction with Figures 8-11 This document explains the process of merchants registering with the acquiring platform and opening basic and transitional escrow accounts, specifically including: The first step is for merchants to initiate registration with the acquiring platform on the merchant platform. According to the registration requirements, merchants upload various materials required for registration, including basic business information, legal representative information, authorization letter, and bank account information for receiving payments.

[0154] The second step involves the merchant platform reviewing the information submitted by the merchant, verifying the payment to the merchant's receiving account, and then scanning the code to sign the agreement.

[0155] The third step is to submit an account opening application to the cooperating receiving bank through the acquiring platform after the signing is completed, so that the receiving bank can open a basic custody account and a transitional custody account for the merchant.

[0156] The fourth step is for the receiving bank to review the merchant's information. Once the review is approved, the bank will open a basic custody account and a transitional custody account for the merchant. The acquiring platform will then synchronize the opening results with the receiving bank and complete the merchant's registration process on the acquiring platform.

[0157] See Figure 7 After a merchant completes registration (onboarding) with the acquiring platform, the acquiring platform opens multiple transit accounts for the merchant at various receiving banks and a primary account at the target receiving bank (i.e., the main bank). When a customer purchases goods or services from a merchant on the platform and pays the corresponding amount due, the virtual resources of that amount are first transferred to one of the merchant's transit accounts. The transit account then transfers (allocates) the virtual resources to the primary account. Finally, the primary account transfers the virtual resources to the merchant's receiving account. Here, the transit accounts receive virtual resources transferred from the customer's payment account in real time and transfer them to the primary account immediately. Therefore, the transit accounts only serve as a temporary receiving medium for the merchant's virtual resources, while the primary account is used to aggregate, settle, and withdraw the virtual resources transferred from the transit accounts.

[0158] After merchants register on the acquiring platform, customers can pay the outstanding amount to the merchant through the acquiring platform when purchasing goods or services from the merchant. Below, we will combine... Figures 4 to 6 as well as Figure 12 To illustrate the process of a customer making a payment for an outstanding amount at their terminal, the following is included: The first step is for the customer to place an order and make payment on the purchasing platform (i.e., the merchant platform). See [link / reference]. Figure 4 When a customer chooses to use the target payment method, the procurement platform sends the transaction order to the acquiring platform of the target payment method.

[0159] The second step involves the acquiring platform returning a link to the payment gateway to the purchasing platform. (See below.) Figure 5 This guides customers from the purchasing platform to the acquiring platform's checkout.

[0160] The third step involves the customer selecting their target bank and confirming payment on the checkout screen. See below. Figure 6 The acquiring platform routes and confirms the multi-level custodian account of the receiving merchant, designates the virtual resources of the multi-level custodian account to receive the amount of payment from the customer, and calls the transfer push interface of the target payment bank selected by the customer. Based on the address returned by the bank's push interface, the customer is guided to the payment interface of the target payment bank's client.

[0161] Step 4, see Figure 12 The customer will complete the authentication process by verifying the password and password on the payment interface of the target payment bank. The target payment bank will then call the SuperNet interface to transfer the funds. At the same time, the front-end and back-end of the terminal will send the transfer results back to the acquiring platform.

[0162] The fifth step involves the acquiring platform calling the receiving bank's interface to confirm payment. Once the payment amount is received, the transaction order is updated to successful, and the merchant's payment result is sent back.

[0163] At this point, the customer has completed the purchase of a specific product (such as an item or service) from the merchant.

[0164] Figure 14 This is a schematic diagram of the third process of the virtual resource processing method provided in this application embodiment. See also... Figure 14 When the client executes actions through the front end of the terminal, such as... Figures 4 to 6 as well as Figure 12 The process of making payments to merchants involves the following virtual resource processing procedures performed by the customer, the bank, the customer's terminal system, and the acquiring platform in response to the customer's payment operations: 1. The customer initiates a payment operation for the merchant's target product in the scenario system.

[0165] 1.1 The scenario system responds to the payment operation by calling the acquiring platform to place the payment order.

[0166] Buyers (i.e., customers) place orders for target products from the scenario system (various merchant platforms) as needed. When paying for the target products, customers can choose the corresponding target payment method. The scenario system transmits the transaction information to the acquiring platform corresponding to the target payment method to place the order and make payment (i.e., call the acquiring platform's payment service interface). At this time, the acquiring platform's payment service receives an order to be paid, which may include information such as the merchant platform identifier, order number, amount to be paid, merchant ID, and acquiring platform's order number.

[0167] 2. The terminal is redirected from the scenario system to the acquiring platform.

[0168] 2.1 The acquiring platform obtains the list of payment methods through the cashier service.

[0169] The scenario system guides customers to the acquiring platform (i.e., the cashier) via the redirect address returned by the acquiring platform when placing an order. The cashier interface can obtain a list of payment methods available to the customer based on the account channels opened by the acquiring merchant, and display information such as the receiving account, the amount to be paid, and the list of receiving banks to the customer.

[0170] 3. The customer selects the target bank and confirms payment on the acquiring platform's cashier interface.

[0171] 3.1 The cashier service obtains a transitional account based on the payment method, order, amount, etc.

[0172] 3.2 The acquiring platform's account system performs target transition account routing.

[0173] 3.3 After the acquiring platform's payment system designates the target transit account, it pushes the order to the target payment bank selected by the customer.

[0174] After the customer selects the target payment bank on the checkout interface, the checkout can call the account system to obtain multiple transit accounts of the merchant based on the customer's selected target payment bank (i.e. payment method), the order number of the acquiring platform, the amount to be paid, etc. The account system can select the target transit account (bank type, card number, account name) of the merchant corresponding to this transaction according to the preset dynamic routing strategy, and return the receiving account information of the target transit account to the checkout.

[0175] Here, the routing strategy for the target transition account is explained in detail.

[0176] Figure 15 This is a schematic diagram of the first process of the routing strategy provided in the embodiments of this application. See also: Figure 15The process by which the acquiring platform determines the target transit account may include: S201, querying all multi-level custodian accounts of the merchant; S202, distinguishing between the primary transit account and the alternative transit account based on the account attributes of each multi-level custodian account; S203, querying whether the primary transit account is under control; S204, if yes, taking the highest priority alternative transit account as the second target transit account (i.e., the second target transit account), and executing S206; S205, if no, taking the primary transit account as the first target transit account (i.e., the first target transit account); S206, returning the bank account information corresponding to the target transit account to the cashier service.

[0177] Specifically, the acquiring platform's account system first queries all multi-tiered custodian accounts corresponding to the merchant. Each multi-tiered custodian account is marked with account attributes, which indicate the bank to which it belongs. Based on these attributes, multi-tiered custodian accounts belonging to the same bank as the merchant's basic custodian account are designated as the primary transition account, while those belonging to different banks are designated as backup transition accounts. The account system then determines whether the primary transition account is under bank control (e.g., frozen by risk control). If controlled, the primary transition account is in an abnormal state; otherwise, it is in a normal state. When the primary transition account is under control, the highest-priority backup transition account is selected as the merchant's target transition account. When the primary transition account is not under control, it is directly selected as the target transition account. If there is only one primary transition account, it is directly selected as the target transition account; if there are multiple primary transition accounts, the one with the highest priority is selected.

[0178] In practical applications, since the primary transition account is usually used more frequently than the alternative transition account, the alternative transition accounts with lower priority may be temporarily suspended by the bank due to long-term inactivity. Therefore, corresponding activation strategies can be set for each alternative transition account. When the activation strategy of the alternative transition account is triggered, it can be used to reactivate the alternative transition account or maintain the normal status of the alternative transition account.

[0179] Figure 16 This is a schematic diagram of the second process of the routing strategy provided in the embodiments of this application. See also: Figure 16The process of determining the target transit account by the acquiring platform may also include: S301, querying all multi-level custodian accounts of the merchant; S302, distinguishing between the primary transit account and the alternative transit account based on the account attributes of each multi-level custodian account; S303, checking whether the primary transit account is under control; S304, if yes, taking the highest priority alternative transit account as the second target transit account (i.e., the second target transit account), and executing S308; S305, if no, determining whether the automatic activation strategy of each alternative transit account is matched; S306, if matched, taking the activated alternative transit account as the second target transit account, and executing S308; S307, if not matched, taking the primary transit account as the first target transit account, and executing S308; S308, returning the bank account information corresponding to the target transit account to the cashier service.

[0180] Figure 17 This is a flowchart illustrating the liveness detection strategy hit method provided in this application embodiment. See also... Figure 17 The process by which the account system determines whether the activation strategy for the candidate transition account is matched includes: S401, obtaining information such as payment method, payment amount (i.e., amount to be paid), and merchant type from the current transaction order; S402, determining whether the payment method is matched; S403, if so, determining whether the payment amount is matched; S404, if so, determining whether the merchant type is matched; S405, if all are matched, routing to the candidate transition account matched by the activation strategy (as the target transition account); S406, if the payment method, payment amount, and merchant type are not matched, routing to the preferred transition account (as the target transition account).

[0181] 4. The receiving bank acknowledges the payment.

[0182] After selecting a target payment bank, customers can control the process from the cashier to the target payment bank on their terminal. Authentication is then completed on the target payment bank's client-side using password verification. The target payment bank can then call the SuperNet interface to transfer funds. Simultaneously, the front-end and back-end of the terminal send the transfer results back to the acquiring platform. The acquiring platform calls the target receiving bank's interface through the pre-payment service and confirms the payment based on information such as the payment amount, remarks, payer's account, and payee's account. Once the virtual resources are confirmed to have arrived, the payment order is updated to successful, and the merchant's payment result is sent back.

[0183] Next, combined Figure 13 This section explains the process by which the acquiring platform controls the bank's handling of virtual resources. (See also...) Figure 13 The processing may include: The first step, under normal circumstances (i.e., when the primary transit account belonging to the same bank as the merchant's basic account is in a normal state), after the customer successfully pays to the primary bank transit account (i.e., the primary transit account, or the first target transit account) through the target payment bank's payment account, the payment system notifies the settlement system. The settlement system then creates a settlement statement based on the information of the multi-level custodian accounts in the account system, recording the account name, card number, and bank code of the payer account (primary bank transit account) and the account name, bank code, settlement amount, settlement time, payment order number, settlement order number, and settlement status (initial state) of the depositor account (i.e., the merchant's basic withdrawal account).

[0184] The second step involves the settlement system verifying whether the payment recipient's account and the depositor's account belong to the same merchant entity. If they do, the settlement system can call the receiving bank's transfer interface based on the settlement time to trigger the settlement operation, transferring the virtual resources of the customer's payment amount from the main bank's transit account to the basic withdrawal account, and then from the basic withdrawal account to the basic settlement account. If they do not belong to the same merchant entity, the settlement system will report an error and block the transfer.

[0185] The third step is for the revenue sharing system to verify the revenue sharing relationship and permissions between the receiving merchant and the revenue sharing recipient. When the verification is successful, it triggers automatic revenue sharing in the basic settlement account, so that the virtual resources of the revenue sharing amount are transferred from the merchant's basic settlement account to the revenue sharing recipient's basic withdrawal account, and then from the revenue sharing recipient's basic withdrawal account to the revenue sharing recipient's receiving account.

[0186] The fourth step is that after the settlement system verifies and processes the split order, the settlement system automatically clears and settles the account, and transfers the remaining amount of virtual resources from the merchant's basic settlement account to the merchant's basic withdrawal account, and then transfers the remaining amount of virtual resources from the merchant's basic withdrawal account to the merchant's receiving account.

[0187] Fifth, if the customer initiates a refund on the merchant platform, the acquiring platform's refund system responds to the refund request sent by the merchant platform, verifies whether the balance of the merchant's basic withdrawal account is sufficient for the refund amount. If the balance of the merchant's basic withdrawal account is greater than the refund amount, an automatic refund is triggered, and the virtual resources of the refund amount are transferred from the merchant's basic withdrawal account to the customer's payment account at the target payment bank.

[0188] The sixth step involves verifying the consistency between the name of the merchant's basic withdrawal account and the name of the merchant's receiving account before allowing the merchant to withdraw virtual resources. Once the consistency verification is successful, the withdrawal of the receiving merchant (i.e., the remaining amount is transferred from the merchant's basic withdrawal account to the merchant's receiving account) and the withdrawal of the splitting recipient (i.e., the virtual resources of the splitting amount are transferred from the splitting recipient's basic withdrawal account to the splitting recipient's receiving account) are automatically triggered.

[0189] It should be noted that when a customer makes a payment, if the primary bank's interbank transfer account is in an abnormal state, the acquiring platform can switch to the interbank transfer account in the backup bank (e.g., the alternative transfer account) to receive the customer's payment. In this case, after the interbank transfer account receives the virtual resources of the amount paid by the customer through the payment account, it can perform interbank transfer, transferring the virtual resources of the customer's payment amount from the interbank transfer account to the merchant's basic settlement account in the primary bank, and then proceeding with the processes shown in steps three, four, and five.

[0190] Figure 18 This is a flowchart illustrating the multi-party interaction provided in the embodiments of this application. Below, through... Figure 18 Come to Figure 13 This section explains the interaction process between the various accounts, specifically including two scenarios: Firstly, when the primary bank's transit account, which belongs to the same bank as the merchant's basic account (including the basic settlement account and the basic withdrawal account), is in a normal state, when a customer performs a payment operation to a merchant, the virtual resources for receiving the pending payment amount are received through the primary bank's transit account. Specifically, this includes: S501, the customer makes normal payments to the main bank's transit account through the payment account.

[0191] S502, the principal bank's transition account transfers the amount due for payment to the basic cash withdrawal account in real time.

[0192] S503, the amount to be paid is transferred from the basic withdrawal account to the basic settlement account.

[0193] S504, Basic settlement account performs split accounting.

[0194] The revenue sharing system verifies the revenue sharing relationship and permissions between the receiving merchant and the revenue sharing recipient. When the verification is successful, it triggers automatic revenue sharing in the basic settlement account, so that the virtual resources of the revenue sharing amount are transferred from the merchant's basic settlement account to the revenue sharing recipient's basic withdrawal account, and then from the revenue sharing recipient's basic withdrawal account to the revenue sharing recipient's receiving account.

[0195] S505, the remaining amount is transferred from the basic settlement account to the basic withdrawal account.

[0196] After the settlement system verifies and processes the split order, it automatically clears and settles the transaction, transferring the remaining virtual resources from the merchant's basic settlement account to the merchant's basic withdrawal account.

[0197] S506, the basic withdrawal account withdraws the remaining amount to the receiving account.

[0198] Secondly, when all primary bank interbank accounts are in an abnormal state, or when the activation strategy of a certain interbank interbank account is triggered, the interbank interbank interbank account can be used to receive the customer's outstanding payment amount, specifically including: S601, the customer pays the amount due to the interbank bridging account through the payment account.

[0199] S602, Interbank transfer of pending payment amount from interbank transit account to basic settlement account.

[0200] Here, when transferring outstanding payments from interbank accounts, it is usually necessary to do so according to a preset transfer frequency. That is, it may be necessary to aggregate the outstanding payments from multiple customers before transferring them to the basic settlement account.

[0201] S603, Basic settlement account performs split accounting.

[0202] S604, the remaining amount is transferred from the basic settlement account to the basic withdrawal account.

[0203] S605, the basic withdrawal account withdraws the remaining amount to the receiving account.

[0204] By adopting the above methods, such as setting up a multi-level custody account system for merchants, dynamic account routing technology, and the ability to transfer funds between the main bank's transitional account and the basic withdrawal account, the following problems can be solved: when a single collection account is frozen for risk control, funds cannot be collected in a timely manner, affecting the normal operation of merchants; the channel cost problem brought about by using cross-bank transitional accounts for collection affects the revenue of merchants.

[0205] The following description continues to illustrate the exemplary structure of the virtual resource processing device 455 provided in the embodiments of this application as a software module. In some embodiments, such as... Figure 2 As shown, the software modules in the processing device 455 storing virtual resources in the memory 450 may include: The first display module 4551 is used to respond to the customer selecting the target payment method for the merchant's payment method, and to redirect the merchant platform to the acquiring platform corresponding to the target payment method, and display the payment order pushed by the merchant platform in the acquiring platform.

[0206] The second display module 4552 is used to respond to the selection operation of the target payment bank associated with the acquiring platform, and to redirect the acquiring platform to the payment interface of the target payment bank, and display the first target transit account associated with the target receiving bank in the payment interface.

[0207] The resource transfer module 4553 is used to respond to payment operations triggered by the payment interface, transfer the virtual resources of the amount to be paid from the payment account associated with the target payment bank to the first target transition account, transfer the virtual resources of the amount to be paid to the merchant's basic withdrawal account in the target receiving bank in real time through the first target transition account, and transfer the virtual resources of the amount to be paid to the merchant's receiving account through the basic withdrawal account.

[0208] In some embodiments, the virtual resource processing apparatus 455 further includes a registration module, configured to, in response to a merchant’s registration operation for the acquiring platform triggered by the merchant on the merchant platform, open multiple transitional accounts for the merchant among multiple receiving banks associated with the acquiring platform, and open a basic account for the merchant at a target receiving bank among the multiple receiving banks; wherein the multiple transitional accounts include at least a first target transitional account.

[0209] In some embodiments, the first display module 4551 is further configured to display a portion of the payment banks associated with the acquiring platform and a first viewing entry for other payment banks associated with the acquiring platform in the acquiring platform; in response to a trigger operation on the first viewing entry, the portion of the payment banks to be displayed can be switched to other payment banks, or, while displaying the portion of the payment banks, the other payment banks can be expanded to be displayed, or, a pop-up window can be displayed for other payment banks.

[0210] In some embodiments, the first display module 4551 is further configured to display a second viewing entry for the first target transition account in the acquiring platform; if the target payment bank is not included among the payment banks and other payment banks associated with the acquiring platform, the first target transition account is displayed in the acquiring platform in response to a triggering operation for the second viewing entry; the resource transfer module 4553 is further configured to exit the acquiring platform in response to a copying operation triggered by the acquiring platform for the first target transition account; in response to an opening operation for the bank application corresponding to the target payment bank, the transfer interface of the bank application is displayed, and the first target transition account is filled into the transfer interface; in response to a transfer operation triggered by the transfer interface, the virtual resources of the amount to be paid are transferred from the payment account associated with the target payment bank to the first target transition account.

[0211] In some embodiments, the second display module 4552 is further configured to, in response to the merchant having multiple first transition accounts associated with the target receiving bank, obtain the priority marked on each first transition account; determine the first transition account with the highest priority among the multiple first transition accounts; if the merchant type, amount to be paid, and payment method of the amount to be paid do not match the activation strategy of all second transition accounts, and the first transition account with the highest priority is in a normal state, use the first transition account with the highest priority as the first target transition account, and display the first target transition account in the payment interface; the second transition accounts include transition accounts other than the first transition account with the highest priority among the multiple transition accounts and transition accounts associated with the merchant in other receiving banks.

[0212] In some embodiments, the second display module 4552 is further configured to, when the highest priority first transition account is in an abnormal state, use the highest priority second transition account among the second transition accounts as the first target transition account, or use any first transition account among any second transition accounts as the first target transition account.

[0213] In some embodiments, the second display module 4552 is further configured to determine the third transition account as the first target transition account if the merchant type, the amount to be paid, and the payment method of the amount to be paid are all compatible with the activation strategy of the third transition account; wherein, the activation strategy is used to reactivate the third transition account or maintain the normal operation of the third transition account; the third transition account is a second transition account belonging to a different bank than the basic withdrawal account.

[0214] In some embodiments, the basic withdrawal account belongs to the merchant's basic account at the target receiving bank, and the basic account also includes a basic settlement account; the resource transfer module 4553 is further configured to transfer the virtual resources of the amount to be paid to the basic withdrawal account in real time through the first target transition account, transfer the virtual resources of the amount to be paid to the basic settlement account through the basic withdrawal account, and after the basic settlement account performs the splitting processing on the virtual resources of the amount to be paid, transfer the remaining amount of virtual resources after the splitting processing to the basic withdrawal account, and transfer the remaining amount of virtual resources to the merchant's receiving account through the basic withdrawal account.

[0215] In some embodiments, the resource transfer module 4553 is further configured to perform consistency verification on the account subject corresponding to the first target transition account and the account subject corresponding to the basic account to obtain a first verification result; if the first verification result indicates that the account subject corresponding to the first target transition account and the account subject corresponding to the basic account are consistent, the virtual resources of the amount to be paid are transferred to the basic withdrawal account in real time through the first target transition account.

[0216] In some embodiments, the basic withdrawal account belongs to the merchant's basic account at the target receiving bank, and the basic account also includes a basic settlement account; the resource transfer module 4553 is further configured to, in response to the merchant's first target transition account associated with the target receiving bank being in an abnormal state, display the merchant's second target transition account associated with other receiving banks in the payment interface; transfer the virtual resources of the amount to be paid to the basic settlement account through the second target transition account, and after the basic settlement account performs the splitting processing of the virtual resources of the amount to be paid, transfer the remaining amount of virtual resources after the splitting processing to the basic withdrawal account, and transfer the remaining amount of virtual resources to the merchant's receiving account through the basic withdrawal account.

[0217] In some embodiments, the resource transfer module 4553 is further configured to perform consistency verification on the account name of the basic withdrawal account and the account name of the receiving account to obtain a second verification result; if the second verification result indicates that the account name of the basic withdrawal account and the account name of the receiving account are consistent, the remaining amount of virtual resources is transferred from the basic withdrawal account to the merchant's receiving account.

[0218] In some embodiments, the resource transfer module 4553 is further configured to, in response to the merchant platform receiving a customer's refund request, send a refund request to the acquiring platform, so that when the acquiring platform determines, based on the refund request, that the balance in the basic withdrawal account is greater than the refund amount indicated in the refund request, it transfers the virtual resources corresponding to the refund amount from the basic withdrawal account to the payment account.

[0219] In some embodiments, the resource transfer module 4553 is further configured to, in response to a confirmation operation for the first target transition account displayed on the payment interface, control the target payment bank to send a first verification code to the contact person associated with the payment account via SMS or email, and display a verification code filling interface; in response to receiving a verification code filling operation on the verification code filling interface, control the target payment bank to verify the filled second verification code and the first verification code to obtain a verification result; in response to a payment confirmation operation triggered based on the verification code filling interface, if the verification result indicates that the first verification code and the second verification code are the same, transfer the virtual resources of the amount to be paid from the payment account associated with the target payment bank to the first target transition account.

[0220] In some embodiments, the resource transfer module 4553 is further configured to control the acquiring platform to perform risk identification on the payment account; in response to the successful risk identification of the payment account, the virtual resources of the amount to be paid are transferred from the payment account associated with the target payment bank to the first target transit account.

[0221] In some embodiments, the resource transfer module 4553 is further configured to display a payment failure message on the payment interface in response to the failure of risk identification of the payment account. The payment failure message is used to indicate the reason for the payment failure.

[0222] In some embodiments, after transferring the virtual resources of the amount to be paid from the payment account associated with the target payment bank to the first target transition account, the resource transfer module 4553 is further configured to display a payment success message in the payment interface and send the payment success message to the merchant platform through the acquiring platform.

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

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

[0225] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, 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.

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

[0227] 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 Hyper Text 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).

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

[0229] In summary, through the embodiments of this application, when a customer selects a target payment method to make a payment to a merchant on the merchant platform, the merchant platform can redirect to the acquiring platform corresponding to the target payment method. The acquiring platform displays the payment order and multiple payment banks associated with it. In response to the selection of a target payment bank, the acquiring platform redirects to the payment interface of the target payment bank, displaying the merchant's first target transit account associated with the target receiving bank. Subsequently, after the customer triggers the payment operation, the virtual resources of the amount to be paid are transferred from the payment account associated with the target payment bank to the first target transit account, and then the virtual resources are transferred to the merchant in real time through the first target transit account. Finally, the virtual resources are transferred to the merchant's receiving account through the basic withdrawal account. In this way, by opening a transitional account and a basic withdrawal account for the merchant, the transitional account is used to receive virtual resources transferred from the customer's payment account, and the basic withdrawal account is used to aggregate and withdraw the virtual resources transferred from the transitional account. If there is a risk in the payment account and risky funds are transferred in, only the corresponding first target transitional account needs to be frozen. In this way, for the merchant, only the amount of payment involved in this order is frozen in the first target transitional account, and the risky funds are prevented from being directly transferred to the receiving account and contaminating the receiving account. This improves the merchant's account disaster recovery capability and the security of the receiving account.

[0230] 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 target payment bank associated with the acquiring platform, the acquiring platform redirects to the payment interface of the target payment bank, and displays the merchant's first target transit account associated with the target receiving bank in the payment interface; In response to a payment operation triggered by the payment interface, the virtual resources of the amount to be paid are transferred from the payment account associated with the target payment bank to the first target transition account. The virtual resources of the amount to be paid are then transferred in real time to the merchant's basic withdrawal account at the target receiving bank through the first target transition account, and finally transferred to the merchant's receiving account through the basic withdrawal account.

2. The method according to claim 1, characterized in that, Before the merchant platform redirects to the acquiring platform corresponding to the target payment method after the customer selects the target payment method as the payment method for the merchant, the method further includes: In response to the merchant's registration operation for the acquiring platform triggered by the merchant platform, multiple transit accounts of the merchant are opened among multiple receiving banks associated with the acquiring platform, and the merchant's basic account is opened at the target receiving bank among the multiple receiving banks. The plurality of transition accounts includes at least the first target transition account.

3. The method according to claim 1, characterized in that, After displaying the payment order pushed by the merchant platform on the acquiring platform, the method further includes: The acquiring platform displays a selection of payment banks associated with the acquiring platform, as well as a first viewing entry for other payment banks associated with the acquiring platform. In response to a trigger operation on the first viewing entry, the displayed partial payment bank will be switched to the other payment bank, or the other payment bank will be expanded and displayed while the partial payment bank is being displayed, or the other payment bank will be displayed in a pop-up window.

4. The method according to claim 3, characterized in that, The provision that displays the merchant's first target transit account associated with the target receiving bank on the payment interface includes: A second viewing entry point for the first target transit account is displayed on the acquiring platform; If the target payment bank is not included among the partial payment banks and other payment banks associated with the acquiring platform, the first target transition account is displayed on the acquiring platform in response to a trigger operation for the second viewing entry. The step of transferring virtual resources of the amount to be paid from the payment account associated with the target payment bank to the first target transit account in response to a payment operation triggered by the payment interface includes: In response to a replication operation triggered by the acquiring platform for the first target transition account, exit the acquiring platform; In response to the opening operation of the bank application corresponding to the target payment bank, the transfer interface of the bank application is displayed, and the first target transit account is filled into the transfer interface; In response to a transfer operation triggered by the transfer interface, the virtual resources of the amount to be paid are transferred from the payment account associated with the target payment bank to the first target transit account.

5. The method according to claim 1, characterized in that, The provision that displays the merchant's first target transit account associated with the target receiving bank on the payment interface includes: In response to the fact that the merchant has multiple first transit accounts associated with the target receiving bank, the priority marked on each first transit account is obtained; Among the plurality of first transition accounts, determine the first transition account with the highest priority; If the merchant type, the amount due, and the payment method of the amount due do not match the activation strategies of all second transition accounts, and the first transition account with the highest priority is in a normal state, the first transition account with the highest priority will be used as the first target transition account, and the first target transition account will be displayed on the payment interface; wherein, the second transition account includes the transition accounts other than the first transition account with the highest priority among the plurality of first transition accounts, as well as the transition accounts associated with the merchant at other receiving banks.

6. The method according to claim 5, characterized in that, The method further includes: If the highest priority first transition account is in an abnormal state, the highest priority second transition account among the second transition accounts shall be used as the first target transition account, or any first transition account among the second transition accounts shall be used as the first target transition account.

7. The method according to claim 5, characterized in that, The method further includes: If the merchant type, the amount to be paid, and the payment method of the amount to be paid are all compatible with the activation strategy of the third transition account, the third transition account will be identified as the first target transition account. The activation strategy is used to reactivate the third transition account or maintain its normal operation. The third transition account is a second transition account belonging to a different bank than the basic withdrawal account.

8. The method according to claim 1, characterized in that, The basic withdrawal account belongs to the merchant's basic account at the target receiving bank, and the basic account also includes a basic settlement account; the step of transferring the virtual resources of the pending payment amount to the merchant's basic withdrawal account at the target receiving bank through the first target transit account, and transferring the virtual resources of the pending payment amount to the merchant's receiving account through the basic withdrawal account, includes: The virtual resources of the pending payment amount are transferred in real time from the first target transition account to the basic withdrawal account. The virtual resources of the pending payment amount are then transferred from the basic withdrawal account to the basic settlement account. After the basic settlement account processes the virtual resources of the pending payment amount through a splitting process, the remaining virtual resources of the splitting process are transferred to the basic withdrawal account. Finally, the remaining virtual resources of the basic withdrawal account are transferred to the merchant's receiving account.

9. The method according to claim 8, characterized in that, The step of transferring the virtual resources of the pending payment amount to the basic withdrawal account in real time through the first target transition account includes: A consistency check is performed on the account entity corresponding to the first target transitional account and the account entity corresponding to the basic account to obtain a first check result; If the first verification result indicates that the account holder corresponding to the first target transition account and the account holder corresponding to the basic account are consistent, the virtual resources of the amount to be paid are transferred to the basic withdrawal account in real time through the first target transition account.

10. The method according to claim 1, characterized in that, The basic withdrawal account belongs to the merchant's basic account at the target receiving bank, and the basic account also includes a basic settlement account; the method further includes: In response to the merchant’s first target transit account associated with the target receiving bank being in an abnormal state, the second target transit account associated with the merchant at another receiving bank is displayed on the payment interface. The virtual resources of the pending payment amount are transferred to the basic settlement account through the second target transition account. After the basic settlement account performs the splitting process on the virtual resources of the pending payment amount, the remaining virtual resources of the splitting process are transferred to the basic withdrawal account. The remaining virtual resources are then transferred to the merchant's receiving account through the basic withdrawal account.

11. The method according to claim 8 or 10, characterized in that, The step of transferring the remaining virtual resources to the merchant's receiving account through the basic withdrawal account includes: A consistency check is performed on the account name of the basic withdrawal account and the account name of the receiving account to obtain a second check result; If the second verification result indicates that the account name of the basic withdrawal account and the account name of the receiving account are consistent, the remaining virtual resources will be transferred from the basic withdrawal account to the merchant's receiving account.

12. The method according to claim 8 or 10, characterized in that, The method further includes: In response to the merchant platform receiving the customer's refund request, the merchant platform sends the refund request to the acquiring platform, so that when the acquiring platform determines that the balance in the basic withdrawal account is greater than the refund amount indicated in the refund request, the virtual resources corresponding to the refund amount are transferred from the basic withdrawal account to the payment account.

13. The method according to claim 1, characterized in that, The step of transferring virtual resources of the amount to be paid from the payment account associated with the target payment bank to the first target transit account in response to a payment operation triggered by the payment interface includes: In response to the confirmation operation of the first target transit account displayed on the payment interface, the target payment bank is controlled to send a first verification code to the contact person associated with the payment account via SMS or email, and a verification code filling interface is displayed. In response to receiving a verification code filling operation on the verification code filling interface, the target payment bank is controlled to verify the filled second verification code and the first verification code to obtain the verification result; In response to a payment confirmation operation triggered by the verification code filling interface, if the verification result indicates that the first verification code and the second verification code are the same, the virtual resources of the amount to be paid will be transferred from the payment account associated with the target payment bank to the first target transit account.

14. The method according to claim 1, characterized in that, The step of transferring the virtual resources of the pending payment amount from the payment account associated with the target payment bank to the first target transit account includes: The acquiring platform is controlled to perform risk identification on the payment account; In response to the successful risk identification of the payment account, the virtual resources of the amount to be paid are transferred from the payment account associated with the target payment bank to the first target transit account.

15. The method according to claim 14, characterized in that, The method further includes: In response to the failure of risk identification of the payment account, a payment failure message is displayed on the payment interface, which indicates the reason for the payment failure.

16. The method according to claim 1, characterized in that, After transferring the virtual resources of the pending payment amount from the payment account associated with the target payment bank to the first target transit account, the method further includes: The payment interface displays a payment success message, and the payment success message is sent to the merchant platform through the acquiring platform.

17. A virtual resource processing device, characterized in that, The device includes: The first display module is used to respond to the customer selecting the target payment method for the merchant, and to redirect the merchant platform to the acquiring platform corresponding to the target payment method, and display the payment order pushed by the merchant platform in the acquiring platform; The second display module is used to respond to the selection operation of the target payment bank associated with the acquiring platform, and to jump from the acquiring platform to the payment interface of the target payment bank, and display the first target transit account associated with the target receiving bank in the payment interface; The resource transfer module is used to respond to a payment operation triggered by the payment interface, transfer the virtual resources of the amount to be paid from the payment account associated with the target payment bank to the first target transition account, transfer the virtual resources of the amount to be paid to the merchant's basic withdrawal account in the target receiving bank in real time through the first target transition account, and transfer the virtual resources of the amount to be paid to the merchant's receiving account through the basic withdrawal account.

18. An electronic device, characterized in that, The electronic device includes: 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 storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the virtual resource processing method according to any one of claims 1 to 16.

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

Images