Accounting information processing method and device, computer device and storage medium
By obtaining user account identifiers to determine role categories and performing resource transfer processing, the high cost problem caused by the separation of roles between issuing banks and acquiring banks is solved, and the system's integration and user activity are improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHANGHAI PUDONG DEVELOPMENT BANK
- Filing Date
- 2022-11-30
- Publication Date
- 2026-06-02
AI Technical Summary
The separation of roles between issuing and acquiring banks leads to high costs for developing and maintaining two separate systems, and the independence of the systems results in weak overlap between issuing and acquiring users.
By obtaining the user's account identifier, determining their role category, and performing resource transfer processing when the target category is determined, the system development and maintenance costs are reduced by combining the roles of the issuing bank and the acquiring bank.
It enables resource transfer processing for pending tasks of target category users, reducing the development and maintenance costs of building two systems in traditional technologies, and improving user activity and system integration.
Smart Images
Figure CN116308834B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, computer equipment, storage medium, and computer program product for processing accounting information. Background Technology
[0002] With the continuous development of technology, various payment methods have emerged. In payment transactions, banks play a crucial role. When acting as an issuer, a bank's main responsibilities are issuing bank cards and maintaining the accounts associated with them. When acting as an acquiring bank, it is primarily responsible for developing and managing merchants, authorization requests, and billing settlements.
[0003] In traditional technology, when a user makes a payment through a bank's acquiring product, the bank acts as the acquiring bank, routing the order information to the corresponding issuing bank for accounting processing based on third-party routing. However, when a user selects a bank card for payment through a non-bank acquiring product, the bank acts as the issuing bank, processing the accounting information upon receiving the order information from the third party.
[0004] However, in the current payment business, issuing banks and acquiring banks are in a state of separation of roles, resulting in a division of responsibilities where issuing banks manage cardholders and acquiring banks manage merchants. Under this separation of roles, each bank needs to build two separate systems to process card issuance orders and acquiring orders, and these two systems are independent of each other, resulting in high system development, use, and maintenance costs. Summary of the Invention
[0005] Therefore, it is necessary to address the issue of high costs associated with developing and maintaining two separate systems due to the separation of roles between issuing and acquiring banks, and to provide a method, apparatus, computer equipment, storage medium, and computer program product that can reduce system costs for accounting information processing.
[0006] Firstly, this application provides a method for processing accounting information. The method includes:
[0007] Obtain the user's pending tasks, wherein the pending tasks carry the user's account identifier;
[0008] The user's role category is determined based on the user's account identifier;
[0009] When the user's role category is determined to be the target category, resource transfer processing is performed according to the task to be processed.
[0010] In one embodiment, determining the user's role category based on the user's account identifier includes: obtaining a preset first account list and a second account list, wherein the first account list includes account identifiers of several card issuers and the second account list includes account identifiers of several acquiring users; when both the first account list and the second account list contain a target account identifier that matches the user's account identifier, the user's role category is determined to be the target category.
[0011] In one embodiment, the method further includes: when there is a target account identifier matching the user's account identifier in the first account list and no target account identifier matching the user's account identifier in the second account list, determining the user's role category as the card issuing role category; returning an acquiring role binding request; in response to the user's confirmation operation of the acquiring role binding request, obtaining the user's acquiring role binding information; and performing resource transfer processing based on the acquiring role binding information and the pending task.
[0012] In one embodiment, the method further includes: storing the user's account identifier in the second account list according to the acquiring role binding information, so as to update the second account list.
[0013] In one embodiment, the method further includes: when there is no target account identifier matching the user's account identifier in the first account list, and there is a target account identifier matching the user's account identifier in the second account list, determining the user's role category as the acquiring role category; and returning a prompt message indicating that the resource transfer failed.
[0014] In one embodiment, the method further includes: receiving a card issuer role binding request from the user, the card issuer role binding request carrying the user's account identifier; when the card issuer role binding request passes verification, storing the user's account identifier in the first account list to update the first account list.
[0015] In one embodiment, the step of performing resource transfer processing based on the task to be processed includes: parsing the task to be processed and extracting corresponding decryption information; generating corresponding resource transfer data based on the decryption information; and updating the remaining resources of the account corresponding to the user's account identifier based on the resource transfer data.
[0016] Secondly, this application also provides an accounting information processing device. The device includes:
[0017] The task acquisition module is used to acquire the user's pending tasks, wherein the pending tasks carry the user's account identifier;
[0018] The role determination module is used to determine the user's role category based on the user's account identifier;
[0019] The processing module, when determining that the user's role category is the target category, performs resource transfer processing according to the task to be processed.
[0020] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method described in the first aspect above.
[0021] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps of the method described in the first aspect above.
[0022] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the steps of the method described in the first aspect above.
[0023] The aforementioned accounting information processing method, apparatus, computer equipment, storage medium, and computer program products involve a server acquiring users' pending tasks and determining the user's role category based on the user's account identifier. When the user's role category is determined to be the target category, resource transfer processing is performed according to the pending tasks. This combines the roles of the issuing bank and the acquiring bank to achieve resource transfer processing for pending tasks of target category users, reducing the development and maintenance costs of building two separate systems required for task processing in traditional technologies. Attached Figure Description
[0024] Figure 1 This is a schematic diagram of payment processing in traditional technology;
[0025] Figure 2 This is an application environment diagram of an accounting information processing method in one embodiment;
[0026] Figure 3 This is a flowchart illustrating an accounting information processing method in one embodiment;
[0027] Figure 4 This is a flowchart illustrating the steps for determining user role categories in one embodiment;
[0028] Figure 5 This is a flowchart illustrating the process of processing accounting information based on role category in one embodiment.
[0029] Figure 6 This is a flowchart illustrating the process of processing accounting information based on role category in another embodiment;
[0030] Figure 7 This is a flowchart illustrating the user role binding steps in one embodiment;
[0031] Figure 8 This is a flowchart illustrating the resource transfer processing steps in one embodiment;
[0032] Figure 9 This is a flowchart illustrating the accounting information processing method in another embodiment;
[0033] Figure 10 This is a structural block diagram of an accounting information processing device in one embodiment;
[0034] Figure 11 This is a schematic diagram illustrating an application scenario of the accounting information processing device in one embodiment;
[0035] Figure 12 This is a timing diagram of the accounting information processing device in one embodiment;
[0036] Figure 13 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0037] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0038] In traditional payment transactions, issuing banks and acquiring banks operate with separate roles, resulting in a division of responsibilities where issuing banks manage cardholders and acquiring banks manage merchants. For example... Figure 1As shown, when a user makes a payment using a bank's acquiring product, the bank acts as the acquiring institution (i.e., the acquiring bank). The user's payment request is pushed to the acquiring bank through the merchant. The acquiring bank returns an order voucher, causing the front-end gateway to redirect payment and display the login page. The acquiring bank obtains the user's payment authentication information through the login page and sends the order information to the corresponding issuing bank through a third-party router. The issuing bank processes the accounting information and returns the transaction result. However, when a user selects a bank card for payment, the bank acts as the issuing bank. When the issuing bank receives the order information from the third party, it processes the corresponding accounting information. In this role separation, each bank needs to build two separate systems to handle issuing and acquiring orders, resulting in high development, usage, and maintenance costs. Furthermore, the two systems are independent, leading to weak overlap between issuing and acquiring users.
[0039] Based on this, embodiments of this application provide an accounting information processing method that can be applied to, for example... Figure 2 In the application environment shown, terminal 202 communicates with server 204 via a network. A data storage system can store the data that server 204 needs to process. The data storage system can be integrated onto server 204 or located on a cloud or other network server. In this embodiment, a user can send a task to be processed to server 204 via terminal 202, where the task carries the user's account identifier. After receiving the task, server 204 can determine the user's role category based on the user's account identifier. When the user's role category is determined to be the target category, resource transfer processing is performed according to the task, thereby realizing a method for processing accounting information that combines the roles of issuing bank and acquiring bank. Terminal 202 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, etc. Server 204 can be implemented using a standalone server or a server cluster composed of multiple servers.
[0040] In one embodiment, such as Figure 3 As shown, an accounting information processing method is provided, which can be applied to... Figure 2 Taking the server in the example, the following steps are included:
[0041] Step 302: Obtain the user's pending tasks.
[0042] The pending task can be a task that requires resource transfer processing. Specifically, the pending task can be a task generated when a user acquires ownership of a target object through a terminal. The pending task carries the user's account identifier, which can be a unique identifier or mark used to distinguish different users.
[0043] In this embodiment, when a user acquires ownership of a target object through a terminal, a corresponding task to be processed is generated, such as a payment task for the target object. This task is then sent to the server, which can then retrieve it and process it through subsequent steps.
[0044] Step 304: Determine the user's role category based on the user's account identifier.
[0045] In this context, a role category is a typical user abstracted from a user group. One role category represents a collection of users, meaning that a role category typically includes multiple users. Furthermore, since an account identifier is a unique identifier or symbol used to distinguish different users, in this embodiment, the server can determine a user's role category based on the user's account identifier.
[0046] Step 306: When the user's role category is determined to be the target category, resource transfer processing is performed according to the task to be processed.
[0047] The target category can be a pre-defined user role category capable of resource transfer processing. Resource transfer processing can be a process of updating or transferring user resources based on pending tasks. In this embodiment, when the server determines that the user's role category is the target category, it can perform resource transfer processing on the user's resources according to the pending tasks.
[0048] In the aforementioned accounting information processing method, the server obtains the user's pending tasks and determines the user's role category based on the user's account identifier. When the user's role category is determined to be the target category, resource transfer processing is performed according to the pending tasks. This combines the roles of the issuing bank and the acquiring bank to achieve resource transfer processing for pending tasks of the target category user, reducing the development and maintenance costs of building two separate systems required for task processing in traditional technologies.
[0049] In one embodiment, such as Figure 4 As shown, in step 304, the user's role category is determined based on the user's account identifier, which may specifically include the following steps:
[0050] Step 402: Obtain the preset first account list and second account list.
[0051] The first account list includes account identifiers for several card issuers, and the second account list includes account identifiers for several acquiring users. Specifically, card issuers are users associated with the issuing bank, i.e., user accounts linked to bank cards issued by the issuing bank. The first account list can be a list storing user information for all card issuers. Acquiring users, on the other hand, are users whose personal information is verified and linked in the corresponding acquiring product when the bank acts as the acquiring bank. The second account list can be a list storing user information for all acquiring users.
[0052] In this embodiment, the server obtains a first account list and a second account list, and then determines the current user's role category based on subsequent steps.
[0053] Step 404: When there is a target account identifier that matches the user's account identifier in both the first account list and the second account list, determine the user's role category as the target category.
[0054] Specifically, when both the first and second account lists contain a target account identifier that matches the account identifier of the user corresponding to the task to be processed, the server can determine that the user's role category is the target category. That is, if the user's account identifier exists in both the first and second account lists, it means that the user is both an issuer and an acquirer; that is, the user has user accounts associated with both the issuing bank and the acquiring bank, and therefore the user's role category can be determined as the target category.
[0055] In the above embodiments, the server obtains a preset first account list and a second account list. When a target account identifier matching the user's account identifier exists in both the first and second account lists, the user's role category is determined to be the target category. By combining the first and second account lists, the server can quickly and accurately identify the user's role category.
[0056] In one embodiment, such as Figure 5 As shown, the above method may further include:
[0057] Step 502: Based on the first account list and the second account list, determine the user's role category as the card issuing role category.
[0058] Specifically, when there is a target account identifier in the first account list that matches the user's account identifier, but there is no target account identifier in the second account list that matches the user's account identifier, it means that the user is an issuer but not an acquirer. Therefore, the server can determine that the user's role category is the issuer role category.
[0059] Step 504: Return the acquiring role binding request.
[0060] The acquiring role binding request is used to request the user to bind an acquiring user role so that the user has the corresponding acquiring user role. Specifically, when the server determines that the user's role category is the card issuing role category through the above steps, it returns an acquiring role binding request to request the user to bind the acquiring user role.
[0061] Step 506: In response to the user's confirmation of the acquiring role binding request, obtain the user's acquiring role binding information.
[0062] The acquiring role binding information is required for binding acquiring user roles; for example, it can be the corresponding user's account identifier. In this embodiment, after the server returns the acquiring role binding request, the user can perform a corresponding operation on the request. For example, the user can reject the request (i.e., refuse the operation) or accept the request (i.e., confirm the operation). The server can then respond accordingly based on the user's operation. For example, when the user accepts the request (i.e., confirms the request), the server responds to the confirmation operation and obtains the user's acquiring role binding information to facilitate the binding of acquiring roles and convert card issuers into acquiring users, thereby improving user activity.
[0063] In one scenario, when a user refuses the request to bind an acquiring role, i.e., rejects the request, the server can also respond to the rejection by exiting the accounting information processing flow, thereby achieving role integration in accounting information processing.
[0064] Step 508: Perform resource transfer processing based on the acquiring role binding information and the pending tasks.
[0065] Specifically, the server performs resource transfer processing based on the user's acquiring role binding information and the pending tasks. This not only enables the conversion of card issuers into acquiring users and improves user activity, but also saves processing costs by combining the roles of the card issuer and the acquiring bank for resource transfer processing.
[0066] In one embodiment, the method may further include: storing the user's account identifier in a second account list based on the acquiring role binding information, thereby updating the second account list. Specifically, when the card issuer accepts the acquiring role binding request and provides the corresponding acquiring role binding information, the server can also store the user's account identifier in the second account list based on the acquiring role binding information, thereby binding the user's acquiring role and enabling the user to have an acquiring role. Simultaneously, storing the user's account identifier in the second account list also enables real-time updates to the second account list, thus ensuring the accuracy and timeliness of the second account list.
[0067] In one embodiment, such as Figure 6 As shown, the above method may further include:
[0068] Step 602: Based on the first account list and the second account list, determine the user's role category as the acquiring role category.
[0069] Specifically, if there is no target account identifier matching the user's account identifier in the first account list, but there is a target account identifier matching the user's account identifier in the second account list, it means that the user is an acquiring user but not a card issuer. Therefore, the server can determine that the user's role category is the acquiring role category.
[0070] Step 604 returns a message indicating that the resource transfer failed.
[0071] Since the server determines the user's role category to be acquiring through the above steps, it means the user is not an issuing user, i.e., the user does not have a user account associated with the issuing bank, and therefore resource transfer processing cannot be performed. Consequently, the server returns a resource transfer failure message. Specifically, this message can also include the specific reason for the resource transfer failure, allowing the user to make targeted adjustments.
[0072] In one embodiment, such as Figure 7 As shown, the above method may further include:
[0073] Step 702: Receive the user's card-issuing role binding request.
[0074] The card issuer role binding request is used to bind the card issuer user's role, and the request carries the user's account identifier. Specifically, the server can also receive the user's card issuer role binding request and bind the role for the user through subsequent steps.
[0075] Step 704: When the card-issuing role binding request is verified, the user's account identifier is stored in the first account list.
[0076] The verification process involves checking the current user against the conditions required for a card-issuing role. Specifically, when the server verifies the card-issuing role binding request for the current user, it indicates that the user meets the conditions for a card-issuing role. Therefore, the server binds the user to the card-issuing role, granting the user that role. Furthermore, the server stores the user's account identifier in a first account list and implements real-time updates to this list, ensuring its accuracy and timeliness.
[0077] In one embodiment, such as Figure 8As shown, in step 306, resource transfer processing is performed according to the task to be processed, which may specifically include:
[0078] Step 802: Perform task parsing on the task to be processed and extract the corresponding decryption information.
[0079] Task parsing can be the process of decrypting a task. Decrypted information refers to the relevant information extracted after decrypting the task to be processed.
[0080] In this embodiment, the server extracts the corresponding decryption information by parsing the task to be processed.
[0081] Step 804: Generate corresponding resource transfer data based on the decrypted information;
[0082] The resource transfer data may include specific resource transfer values and methods. Specifically, the resource transfer method may include transfer-in or transfer-out. In this embodiment, the server can generate corresponding resource transfer data based on the extracted decryption information.
[0083] Step 806: Update the remaining resources of the account corresponding to the user's account identifier based on the resource transfer data.
[0084] Specifically, the server can process the user account's resources according to the resource transfer data. For example, the server can increase or decrease the user account's resources based on the resource transfer value and method, thereby updating the user account's remaining resources and completing the resource transfer process.
[0085] In one embodiment, such as Figure 9 As shown, the above accounting information processing method is further explained below, which may include the following steps:
[0086] Step 901: Obtain the user's pending tasks.
[0087] Specifically, the task to be processed can be a task to be paid, and the task to be processed carries the user's account identifier.
[0088] Step 902: Determine whether there is a target account identifier in the first account list that matches the user's account identifier.
[0089] If a target account identifier that matches the user's account identifier exists in the first account list, proceed to step 903; if no target account identifier that matches the user's account identifier exists in the first account list, proceed to step 909.
[0090] Step 903: Determine whether there is a target account identifier in the second account list that matches the user's account identifier.
[0091] If a target account identifier matching the user's account identifier exists in the second account list, proceed to step 904; if no target account identifier matching the user's account identifier exists in the second account list, proceed to step 905.
[0092] Step 904: Perform resource transfer processing based on the tasks to be processed.
[0093] For details, please refer to the following: Figure 8 The processing flow shown in this embodiment will not be described in detail here.
[0094] Step 905: Return the acquiring role binding request.
[0095] Step 906: Obtain the user's operation on the acquiring role binding request and determine whether it is a confirmation operation.
[0096] If the operation is determined to be a confirmation operation, proceed to step 907; if the operation is determined not to be a confirmation operation, proceed to step 909.
[0097] Step 907: In response to the user's confirmation, obtain the user's acquiring role binding information.
[0098] Step 908: Bind the acquiring role according to the acquiring role binding information and update the second account list.
[0099] After completing the binding of the acquiring role, proceed to step 904 to perform resource transfer processing according to the pending tasks.
[0100] Step 909, end the process.
[0101] In the aforementioned accounting information processing method, the user's pending tasks are obtained, and the user's role category is determined based on the user's account identifier. Resource transfer processing is only performed based on the pending tasks when a target account identifier matching the user's account identifier exists in both the first and second account lists. If a target account identifier matching the user's account identifier exists in the first account list but not in the second account list, an acquiring role is bound according to the acquiring role binding request, and the second account list is updated. This binds the user's acquiring role, enabling resource transfer processing for the user's pending tasks. This reduces the development and maintenance costs of building two separate systems for task processing, as required by traditional technologies.
[0102] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0103] Based on the same inventive concept, this application also provides an accounting information processing apparatus for implementing the accounting information processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more accounting information processing apparatus embodiments provided below can be found in the limitations of the accounting information processing method described above, and will not be repeated here.
[0104] In one embodiment, such as Figure 10 As shown, an accounting information processing device is provided, including: a task acquisition module 1002, a role determination module 1004, and a processing module 1006, wherein:
[0105] The task acquisition module 1002 is used to acquire the user's pending tasks, wherein the pending tasks carry the user's account identifier;
[0106] The role determination module 1004 is used to determine the user's role category based on the user's account identifier;
[0107] The processing module 1006, when determining that the user's role category is the target category, performs resource transfer processing according to the task to be processed.
[0108] In one embodiment, the role determination module is further configured to: obtain a preset first account list and a second account list, wherein the first account list includes account identifiers of several card issuers and the second account list includes account identifiers of several acquiring users; when there is a target account identifier matching the user's account identifier in both the first account list and the second account list, the role category of the user is determined to be the target category.
[0109] In one embodiment, the role determination module is further configured to: determine the user's role category as the card issuing role category when there is a target account identifier matching the user's account identifier in the first account list and no target account identifier matching the user's account identifier in the second account list; return an acquiring role binding request; in response to the user's confirmation operation of the acquiring role binding request, obtain the user's acquiring role binding information; and perform resource transfer processing based on the acquiring role binding information and the pending task.
[0110] In one embodiment, the apparatus further includes an update module for storing the user's account identifier in the second account list based on the acquiring role binding information, so as to update the second account list.
[0111] In one embodiment, the role determination module is further configured to: determine the user's role category as acquiring role category when there is no target account identifier matching the user's account identifier in the first account list and there is a target account identifier matching the user's account identifier in the second account list; and return a prompt message indicating that the resource transfer failed.
[0112] In one embodiment, the update module is further configured to: receive the user's card-issuing role binding request, the card-issuing role binding request carrying the user's account identifier; when the card-issuing role binding request passes verification, store the user's account identifier in the first account list to update the first account list.
[0113] In one embodiment, the processing module is further configured to: perform task parsing on the task to be processed and extract corresponding decryption information; generate corresponding resource transfer data based on the decryption information; and update the remaining resources of the account corresponding to the user's account identifier based on the resource transfer data.
[0114] Each module in the aforementioned accounting information processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.
[0115] In one embodiment, such as Figure 11 As shown, the following further explains the application scenarios of the aforementioned accounting information processing device. Here, the user is an individual using a bank acquiring product (i.e., an e-commerce payment platform), the merchant is a business providing specific products, and the UnionPay control is an authoritative program used to ensure payment security. The corresponding processing method using the aforementioned accounting information processing device includes the following steps:
[0116] Step 1101: The user initiates payment on the merchant's order page.
[0117] Step 1102: The merchant pushes the order to the UnionPay control and uploads the order information.
[0118] Step 1103: UnionPay returns a unique token number to the merchant.
[0119] Step 1104: The UnionPay control is launched on the merchant page.
[0120] Step 1105: The UnionPay control polls the payment apps installed on the user's mobile phone.
[0121] Step 1106: The user selects a payment method based on the payment apps displayed in the poll.
[0122] Step 1107: The front-end gateway redirects the user to the payment app selected by the user.
[0123] Step 1108: The user submits payment authentication information and submits the payment task to the accounting information processing device.
[0124] Step 1109: The accounting information processing device processes the accounting information. (For specific processing procedures, please refer to the above.) Figures 3 to 9 The method described.
[0125] Step 1110: The accounting information processing device returns a transaction result notification.
[0126] Step 1111: The accounting information processing device redirects the front-end page back to the UnionPay control.
[0127] Step 1112: The UnionPay control returns the transaction result notified by the accounting information processing device to the merchant.
[0128] Step 1113: Finally, you will be redirected back to the merchant's page.
[0129] Furthermore, the aforementioned accounting information processing device may include an e-commerce payment platform, a payment app, and an internet payment front-end. Specifically, the payment app may be a mobile banking app, which, as the transaction recipient, can receive large fields of payment data sent from the UnionPay control and process the transaction data. The e-commerce payment platform, as the transaction transmitter, provides user system support for the transaction. The internet payment front-end, as the transaction processor, processes accounting information. The specific payment scheme's sequence is as follows: Figure 12 As shown, it can specifically include:
[0130] 1201: The payment app obtains a large field of payment data sent by the UnionPay control.
[0131] 1202: The payment app parses large fields of payment data and extracts payment information, such as encrypted information, including but not limited to the encryption certificate serial number, the symmetric encryption algorithm type of the encrypted information, the signature certificate serial number of the encrypted information, and the symmetric encryption key of the encrypted information.
[0132] 1203: The payment app will send the extracted encrypted payment information to the internet payment front end.
[0133] 1204: The internet payment process decrypts the received information and sends back payment information in JSON format to the payment app.
[0134] 1205: The payment app will send the decrypted payment information and user information to the e-commerce payment platform.
[0135] 1206: The user performs a user system operation.
[0136] This involves binding the card issuer role and the acquiring role. Specifically, this can include: users logging in via mobile phone number and verification code; or users binding their cards and setting a payment password using their mobile phone number, card number, ID number, name, SMS verification code, and transaction password. This then retrieves the user's list of signed cards, allowing the user to choose a payment method.
[0137] 1207: E-commerce payment platforms send transaction information to the internet payment front end.
[0138] 1208: Internet payment pre-processing involves accounting information based on transaction information (e.g., Figure 8 (The resource transfer process shown).
[0139] 1209: Internet payment pre-processing returns the payment status to the e-commerce payment platform.
[0140] The payment status includes both the status of resource transfer failure and the status of resource transfer success.
[0141] 1210: After successful payment, the user clicks "Complete" to return to the merchant's page.
[0142] In this combined payment method, merchants can easily access the payment processing device provided by UnionPay with a single click, significantly reducing their integration costs. For users, this provides a richer and more secure payment experience while ensuring the security of user and transaction information. For banks, by combining the user system (i.e., the second account list) with the accounting system (i.e., the first account list), the acquiring bank and the issuing bank are integrated, effectively reducing development and maintenance costs and achieving a sustainable, win-win mobile payment ecosystem.
[0143] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 13 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data such as tasks to be processed, a first account list, and a second account list. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements an accounting information processing method.
[0144] Those skilled in the art will understand that Figure 13 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0145] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:
[0146] Obtain the user's pending tasks, wherein the pending tasks carry the user's account identifier;
[0147] The user's role category is determined based on the user's account identifier;
[0148] When the user's role category is determined to be the target category, resource transfer processing is performed according to the task to be processed.
[0149] In one embodiment, when the processor executes the computer program, it further performs the following steps: obtaining a preset first account list and a second account list, wherein the first account list includes account identifiers of several card issuers and the second account list includes account identifiers of several acquiring users; when there is a target account identifier matching the user's account identifier in both the first account list and the second account list, the user's role category is determined as the target category.
[0150] In one embodiment, when the processor executes the computer program, it further implements the following steps: when there is a target account identifier matching the user's account identifier in the first account list and no target account identifier matching the user's account identifier in the second account list, the user's role category is determined to be the card issuing role category; a receiving role binding request is returned; in response to the user's confirmation operation of the receiving role binding request, the receiving role binding information of the user is obtained; and resource transfer processing is performed based on the receiving role binding information and the pending task.
[0151] In one embodiment, when the processor executes the computer program, it further performs the following steps: storing the user's account identifier in the second account list according to the acquiring role binding information, so as to update the second account list.
[0152] In one embodiment, when the processor executes the computer program, it further implements the following steps: when there is no target account identifier matching the user's account identifier in the first account list, and there is a target account identifier matching the user's account identifier in the second account list, the user's role category is determined to be the acquiring role category; and a resource transfer failure prompt message is returned.
[0153] In one embodiment, when the processor executes the computer program, it further implements the following steps: receiving a card-issuing role binding request from the user, the card-issuing role binding request carrying the user's account identifier; when the card-issuing role binding request passes verification, storing the user's account identifier in the first account list to update the first account list.
[0154] In one embodiment, when the processor executes the computer program, it further performs the following steps: parsing the task to be processed and extracting the corresponding decryption information; generating corresponding resource transfer data based on the decryption information; and updating the remaining resources of the account corresponding to the user's account identifier based on the resource transfer data.
[0155] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:
[0156] Obtain the user's pending tasks, wherein the pending tasks carry the user's account identifier;
[0157] The user's role category is determined based on the user's account identifier;
[0158] When the user's role category is determined to be the target category, resource transfer processing is performed according to the task to be processed.
[0159] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: obtaining a preset first account list and a second account list, wherein the first account list includes account identifiers of several card issuers and the second account list includes account identifiers of several acquiring users; when there is a target account identifier matching the user's account identifier in both the first account list and the second account list, the user's role category is determined as the target category.
[0160] In one embodiment, when the computer program is executed by the processor, it further implements the following steps: when there is a target account identifier matching the user's account identifier in the first account list and no target account identifier matching the user's account identifier in the second account list, the user's role category is determined to be the card issuing role category; a acquiring role binding request is returned; in response to the user's confirmation operation of the acquiring role binding request, the acquiring role binding information of the user is obtained; and resource transfer processing is performed based on the acquiring role binding information and the pending task.
[0161] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: storing the user's account identifier in the second account list according to the acquiring role binding information, so as to update the second account list.
[0162] In one embodiment, when the computer program is executed by the processor, it further implements the following steps: when there is no target account identifier matching the user's account identifier in the first account list and there is a target account identifier matching the user's account identifier in the second account list, the user's role category is determined to be the acquiring role category; and a resource transfer failure prompt message is returned.
[0163] In one embodiment, when the computer program is executed by a processor, it further implements the following steps: receiving a card issuer role binding request from the user, the card issuer role binding request carrying the user's account identifier; when the card issuer role binding request is verified, storing the user's account identifier in the first account list to update the first account list.
[0164] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: parsing the task to be processed and extracting the corresponding decryption information; generating corresponding resource transfer data based on the decryption information; and updating the remaining resources of the account corresponding to the user's account identifier based on the resource transfer data.
[0165] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:
[0166] Obtain the user's pending tasks, wherein the pending tasks carry the user's account identifier;
[0167] The user's role category is determined based on the user's account identifier;
[0168] When the user's role category is determined to be the target category, resource transfer processing is performed according to the task to be processed.
[0169] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: obtaining a preset first account list and a second account list, wherein the first account list includes account identifiers of several card issuers and the second account list includes account identifiers of several acquiring users; when there is a target account identifier matching the user's account identifier in both the first account list and the second account list, the user's role category is determined as the target category.
[0170] In one embodiment, when the computer program is executed by the processor, it further implements the following steps: when there is a target account identifier matching the user's account identifier in the first account list and no target account identifier matching the user's account identifier in the second account list, the user's role category is determined to be the card issuing role category; a acquiring role binding request is returned; in response to the user's confirmation operation of the acquiring role binding request, the acquiring role binding information of the user is obtained; and resource transfer processing is performed based on the acquiring role binding information and the pending task.
[0171] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: storing the user's account identifier in the second account list according to the acquiring role binding information, so as to update the second account list.
[0172] In one embodiment, when the computer program is executed by the processor, it further implements the following steps: when there is no target account identifier matching the user's account identifier in the first account list and there is a target account identifier matching the user's account identifier in the second account list, the user's role category is determined to be the acquiring role category; and a resource transfer failure prompt message is returned.
[0173] In one embodiment, when the computer program is executed by a processor, it further implements the following steps: receiving a card issuer role binding request from the user, the card issuer role binding request carrying the user's account identifier; when the card issuer role binding request is verified, storing the user's account identifier in the first account list to update the first account list.
[0174] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: parsing the task to be processed and extracting the corresponding decryption information; generating corresponding resource transfer data based on the decryption information; and updating the remaining resources of the account corresponding to the user's account identifier based on the resource transfer data.
[0175] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions.
[0176] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.
[0177] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0178] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A method for processing accounting information, characterized in that, The method includes: Obtain the user's pending tasks, wherein the pending tasks carry the user's account identifier; Obtain a preset first account list and a second account list. The first account list includes account identifiers of several card issuers, and the second account list includes account identifiers of several acquiring users. When both the first account list and the second account list contain a target account identifier that matches the user's account identifier, the user's role category is determined as the target category. When the user's role category is determined to be the target category, resource transfer processing is performed according to the task to be processed; wherein, the target category is used to characterize the role category of the user who is capable of performing resource transfer processing.
2. The method according to claim 1, characterized in that, The method further includes: When there is a target account identifier in the first account list that matches the user's account identifier, and there is no target account identifier in the second account list that matches the user's account identifier, the user's role category is determined to be the card issuing role category; Return the acquiring role binding request; In response to the user's confirmation of the request to bind the acquiring role, obtain the user's acquiring role binding information; Resource transfer is performed based on the acquiring role binding information and the pending tasks.
3. The method according to claim 2, characterized in that, The method further includes: The user's account identifier is stored in the second account list based on the acquiring role binding information to update the second account list.
4. The method according to claim 1, characterized in that, The method further includes: When there is no target account identifier matching the user's account identifier in the first account list, but there is a target account identifier matching the user's account identifier in the second account list, the user's role category is determined to be the acquiring role category; The system returned a message indicating that the resource transfer failed.
5. The method according to claim 4, characterized in that, The method further includes: Receive the user's card-issuing role binding request, wherein the card-issuing role binding request carries the user's account identifier; When the card-issuing role binding request is verified, the user's account identifier is stored in the first account list to update the first account list.
6. The method according to any one of claims 1 to 5, characterized in that, The resource transfer process based on the task to be processed includes: The task to be processed is parsed to extract the corresponding decryption information; Generate corresponding resource transfer data based on the decrypted information; Update the remaining resources of the account corresponding to the user's account identifier based on the resource transfer data.
7. An accounting information processing device, characterized in that, The device includes: The task acquisition module is used to acquire the user's pending tasks, wherein the pending tasks carry the user's account identifier; The role determination module is used to determine the user's role category based on the user's account identifier; the role determination module is also used to: obtain a preset first account list and a second account list, the first account list including account identifiers of several card issuers, and the second account list including account identifiers of several acquiring users; when there is a target account identifier that matches the user's account identifier in both the first account list and the second account list, the user's role category is determined to be the target category; The processing module, when determining that the user's role category is the target category, performs resource transfer processing according to the task to be processed; wherein, the target category is used to characterize the role category of the user who can perform resource transfer processing.
8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.