Payment service processing method, device and system and storage medium
By constructing a limit parameter configuration model and dynamically matching limit parameters based on deep learning technology, the problem of slow payment response caused by the large amount of limit list data was solved, thus improving the efficiency and security of payment services.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA CONSTRUCTION BANK
- Filing Date
- 2025-12-30
- Publication Date
- 2026-04-21
AI Technical Summary
When financial institutions process online payment transactions, the large amount of data in the limit list leads to high processing complexity, affecting payment response speed and customer experience.
A limit parameter configuration model is adopted. This model, built based on deep learning, dynamically matches the optimal limit parameters by acquiring the payment scenario and environment information of the target business users, and determines the transaction result by combining the payment amount and environment information.
It improves the response efficiency and accuracy of payment operations, reduces data processing pressure, and meets the requirements of financial institutions for business security and efficiency.
Smart Images
Figure CN121903594A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of financial technology, and more specifically to a method, apparatus, system and storage medium for processing payment transactions. Background Technology
[0002] With the rapid development of third-party payment apps linking bank cards for online payments, the online payment market has experienced explosive growth. To address this challenge, financial institutions have implemented numerous security control measures, including establishing blacklists, whitelists, and graylists, as well as various transaction limits, to strengthen risk control. Currently, the data volume of transaction limit lists and categories managed by banks for various payment services exceeds hundreds of millions. This has increased the complexity and time-consuming nature of limit control processing, leading to slower customer payment responses and impacting the payment experience. Summary of the Invention
[0003] In view of the above problems, this disclosure provides a method, apparatus, system, medium and program product for processing payment transactions.
[0004] According to a first aspect of this disclosure, a method for processing payment transactions is provided, the method comprising:
[0005] Obtain the spending limit parameters of target business users in different payment scenarios, as well as the payment environment information in the current payment scenario;
[0006] Input the payment environment information of the current payment scenario into the pre-trained limit parameter configuration model;
[0007] Among them, the limit parameter configuration model is used to determine the target limit parameter for the current payment scenario from the limit parameters; the limit parameter configuration model is trained based on the limit parameters for different payment scenarios and the transaction results in historical periods;
[0008] Based on the target limit parameter, in response to the target payment operation initiated by the target business user in the current payment scenario, the transaction result of the target payment operation is returned to the target business user.
[0009] According to embodiments of this disclosure, obtaining the limit parameters of the target business user under different payment scenarios includes:
[0010] Retrieve multiple limit sub-parameters for each payment scenario;
[0011] Each limit sub-parameter is configured through a different payment object, which is the payment object when the target business user initiates a payment operation.
[0012] One of the multiple limit sub-parameters in each payment scenario is determined as the limit parameter for the target business user in each payment scenario.
[0013] According to embodiments of this disclosure, based on a target limit parameter, in response to a target payment operation initiated by a target business user in the current payment scenario, the transaction result of the target payment operation is returned to the target business user, including:
[0014] Based on the payment amount of the target payment operation and the target limit parameter, the transaction result is obtained; among which,
[0015] If the payment amount does not exceed the target limit parameter, the target payment operation will be executed and a successful transaction result will be returned;
[0016] If the payment amount exceeds the target limit parameter, the target payment operation will be blocked, and a limit reminder will be pushed to the target business user.
[0017] According to embodiments of this disclosure, obtaining payment environment information in the current payment scenario includes at least one of the following:
[0018] Account information of target business users;
[0019] Identification information of the transaction terminal that performs the target payment operation;
[0020] Location information of the transaction terminal that performs the target payment operation.
[0021] According to embodiments of this disclosure, after inputting payment environment information under the current payment scenario into a pre-trained limit parameter configuration model, the method further includes:
[0022] Extract payment environment information for the current payment scenario;
[0023] Feature processing is performed on the extracted payment environment information;
[0024] The processed payment environment information is input into the limit parameter configuration model, which triggers the limit parameter configuration model to call the limit parameter dataset of the target business user in different payment scenarios.
[0025] Based on the scene matching algorithm built into the limit parameter configuration model, the similarity matching is performed between the feature-processed payment environment information and the historical scene features in the limit parameter dataset.
[0026] Based on the similarity matching results, the target limit parameters suitable for the current payment scenario are determined.
[0027] According to embodiments of this disclosure, the quota parameter configuration model is constructed based on a deep learning model, which includes an input layer, a feature extraction layer, a scene matching layer, and an output layer; wherein,
[0028] The input layer is used to receive the payment environment information after feature processing and the limit parameters under different payment scenarios;
[0029] The feature extraction layer is used to perform feature mapping on the input information and output a high-dimensional scene feature vector;
[0030] The scene matching layer is used to calculate the similarity between the current scene feature vector and the historical scene feature vector, and to determine the appropriate limit parameter range.
[0031] The output layer is used to output the target limit parameters for the current payment scenario.
[0032] According to embodiments of this disclosure, after returning the transaction result of the target payment operation to the target business user, the method further includes:
[0033] The payment environment information, target limit parameters, and transaction results of the current payment scenario are synchronized to the historical database, which is used to update the training samples of the limit parameter configuration model.
[0034] A second aspect of this disclosure provides a payment processing system, comprising:
[0035] The database server is used to obtain the quota parameters of target business users under different business scenarios;
[0036] The application server is used to respond to the target payment operation initiated by the target business user in the current payment scenario and to retrieve the target limit parameter of the target business user in the current payment scenario from the database server.
[0037] The database server is also used to respond to the application server's calls and obtain payment environment information for the current payment scenario; input the payment environment information for the current payment scenario into a pre-trained limit parameter configuration model; wherein, the limit parameter configuration model is used to determine the target limit parameter for the current payment scenario from the limit parameters; the limit parameter configuration model is trained based on the limit parameters for different payment scenarios and transaction results in historical periods;
[0038] The application server is also used to return the transaction results of the target payment operation to the target business user based on the target limit parameter.
[0039] A third aspect of this disclosure provides a payment processing apparatus, the apparatus comprising:
[0040] The parameter acquisition module is used to acquire the limit parameters of the target business user under different payment scenarios, as well as the payment environment information under the current payment scenario;
[0041] The model application module is used to input payment environment information under the current payment scenario into a pre-trained limit parameter configuration model; wherein, the limit parameter configuration model is used to determine the target limit parameter under the current payment scenario from the limit parameters; the limit parameter configuration model is trained based on the limit parameters under different payment scenarios and transaction results in historical periods;
[0042] The result acquisition module is used to respond to the target payment operation initiated by the target business user in the current payment scenario based on the target limit parameter, and return the transaction result of the target payment operation to the target business user.
[0043] A fourth aspect of this disclosure provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.
[0044] The fifth aspect of this disclosure also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.
[0045] A sixth aspect of this disclosure also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.
[0046] According to embodiments of this disclosure, by recording payment transaction information into a blockchain network and utilizing blockchain technology to verify and execute transaction proposals, the secure storage of customer information and the efficient execution of transactions are ensured. Through the immutability and decentralization of blockchain, the risk of fund misappropriation is effectively reduced, and the system processing capacity and risk management level of payment transactions in complex transaction scenarios are improved, meeting the higher requirements of financial institutions for business security and efficiency. Attached Figure Description
[0047] The foregoing contents, as well as other objects, features, and advantages of this disclosure, will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:
[0048] Figure 1 The illustration schematically depicts application scenarios of payment processing methods, apparatuses, devices, media, and program products according to embodiments of this disclosure;
[0049] Figure 2 One of the flowcharts illustrating a payment transaction processing method according to an embodiment of the present disclosure is shown schematically;
[0050] Figure 3 A flowchart illustrating a payment processing method according to an embodiment of the present disclosure is shown in the diagram.
[0051] Figure 4 A block diagram of a processing system suitable for implementing payment transactions according to an embodiment of the present disclosure is shown schematically.
[0052] Figure 5 The diagram schematically illustrates a structural block diagram of a payment processing apparatus according to an embodiment of the present disclosure;
[0053] Figure 6 A block diagram of an electronic device suitable for implementing a payment processing method according to an embodiment of the present disclosure is shown schematically. Detailed Implementation
[0054] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.
[0055] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.
[0056] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.
[0057] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).
[0058] In the technical solution disclosed herein, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, application, and application of related data all comply with relevant laws, regulations, and standards, and necessary measures have been taken to ensure that they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse.
[0059] Figure 1 The illustration schematically depicts application scenarios of payment processing methods, apparatuses, devices, media, and program products according to embodiments of the present disclosure.
[0060] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.
[0061] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).
[0062] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.
[0063] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.
[0064] It should be noted that the payment processing method provided in this embodiment can generally be executed by server 105. Correspondingly, the payment processing device provided in this embodiment can generally be located in server 105. The payment processing method provided in this embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the payment processing device provided in this embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.
[0065] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.
[0066] The following will be based on Figure 1 The described scene, through Figures 2-3 A method for processing payment transactions according to embodiments of this disclosure will be described in detail.
[0067] Figure 2 One of the flowcharts illustrating a payment transaction processing method according to an embodiment of the present disclosure is shown schematically.
[0068] like Figure 2 As shown, the payment processing method of this embodiment includes operations S210 to S230.
[0069] In operation S210, obtain the limit parameters of the target business user under different payment scenarios, as well as the payment environment information under the current payment scenario;
[0070] In the embodiments of this disclosure, the target business user is the entity that initiates the payment operation, including personal user accounts (such as personal bank card accounts, third-party payment personal accounts), corporate user accounts (such as corporate bank accounts, merchant acquiring accounts), and third-party payment institution accounts (such as payment company reserve fund accounts).
[0071] In the embodiments of this disclosure, the payment scenario represents the specific business scenario in which the payment behavior occurs, including but not limited to online shopping payment, offline QR code payment, cross-border payment, and transfer payment.
[0072] In the embodiments disclosed herein, the limit parameters are amount restriction standards set by banks or payment institutions to manage payment risks, including single payment limit, daily cumulative payment limit, monthly cumulative payment limit, and payment limit for specific merchants, etc.
[0073] In the embodiments of this disclosure, the payment environment information is scenario feature data related to the payment operation.
[0074] In operation S220, the payment environment information of the current payment scenario is input into the pre-trained limit parameter configuration model; wherein, the limit parameter configuration model is used to determine the target limit parameter of the current payment scenario from the limit parameters; the limit parameter configuration model is trained based on the limit parameters of different payment scenarios and the transaction results in historical periods;
[0075] In the embodiments of this disclosure, the limit parameter configuration model is built based on machine learning or deep learning algorithms and is used to match the optimal limit parameters according to payment environment information. The training data of the limit parameter configuration model consists of limit parameters for different payment scenarios and historical transaction results.
[0076] Specifically, by training the model with limit parameters under different payment scenarios and transaction results within historical periods, the model can learn how to determine the limit parameters that are most suitable for the current payment environment. This allows the target user to complete the payment operation as much as possible while reducing the risk of the payment operation after the limit parameters are determined.
[0077] Furthermore, in the application of the limit parameter configuration model, payment environment information is used to determine the similarity between the current payment scenario and historical payment scenarios, thereby determining the risk level of the payment operation in the current payment scenario. After determining the risk level of the payment operation in the current payment scenario, the default payment limit can be adjusted. As the payment limit is adjusted, the risk level can increase or decrease accordingly. If the risk level in the current payment scenario is high, the limit for user payment operations in the current payment scenario can be appropriately reduced; similarly, if the risk level in the current payment scenario is low, the limit parameter for user payment operations in the current payment scenario can be increased. In the process of adjusting the limit parameters, the limit parameter configuration model is used to determine an optimal solution between balancing the risk level and the limit parameters.
[0078] In operation S230, based on the target limit parameter, in response to the target payment operation initiated by the target business user in the current payment scenario, the transaction result of the target payment operation is returned to the target business user.
[0079] For example, the target user is User A, whose payment limits for different scenarios are as follows: 5,000 yuan per online shopping transaction, 2,000 yuan per offline QR code payment, and 10,000 yuan per day for cross-border payments. User A initiates a 3,000 yuan payment to an overseas merchant via mobile phone QR code (the current payment scenario is cross-border offline QR code payment). The obtained payment environment information includes: User A's account risk level is low risk, mobile phone identification code, and location information. The above payment environment information is input into a pre-trained limit parameter configuration model. The model calls User A's full-scenario limit parameter dataset and, combined with historical cross-border payment transaction results, determines the target limit parameters for the current scenario to be 3,500 yuan per transaction and 10,000 yuan per day. Since User A's payment amount of 3,000 yuan does not exceed the target limit parameters, and there is no risk warning in the payment environment information, the system executes the payment operation and returns a successful transaction result.
[0080] By adopting the above method, the target business users can obtain multi-scenario limit parameters and current payment environment information. With the help of a pre-trained limit parameter configuration model, the target limit parameters can be intelligently matched. Then, the payment operation can be responded to and the transaction result can be returned based on the parameters. This can accurately adapt to the massive processing needs of limit lists and transaction data, alleviate data processing pressure, and ensure the convenience of normal payment scenarios by dynamically matching limits through the model.
[0081] According to an embodiment of this disclosure, in operation S210, obtaining the limit parameters of the target business user under different payment scenarios includes: obtaining multiple limit sub-parameters in each payment scenario; wherein, each limit sub-parameter is configured through a different payment object, and the payment object is the payment object when the target business user initiates a payment operation; and determining one of the multiple limit sub-parameters in each payment scenario as the limit parameter of the target business user in each payment scenario.
[0082] Specifically, different payment institutions have multiple different dimensions of limits, such as risk control list limits, whitelist limits, customer-specific limits, merchant-specific limits, and scenario-based limits. Each dimension of limit is generally set with three limits: single transaction limit, daily cumulative limit, and monthly cumulative limit. When multiple payment objects have the same dimension of limit set, the strictest principle is generally adopted when they have the same priority. That is, the lowest principle is adopted. It is only necessary to calculate in advance the most stringent limit value among multiple limit parameters from different sources in the same dimension, and retain the most stringent requirement and source. That is, the smallest value among multiple limit sub-parameters in each payment scenario is used as the limit parameter for the target business user in each payment scenario.
[0083] Furthermore, during the subsequent payment process, only the most stringent limit parameter needs to be checked. If the parameter requirements are not met, the payment will be interrupted and the customer will be notified. If the most stringent parameter requirements are met, the limit sub-parameters of all other payment objects in the same dimension will also be met, and the payment process can continue without the need for additional queries and calculations, thus improving the efficiency of the payment process.
[0084] In the embodiments of this disclosure, the payment recipients refer to different business departments within the same payment institution.
[0085] For example, consider user A's payment account within a payment institution. This account is not on a whitelist or blacklist; only three departments (A, B, and C) within the institution have set their own limit sub-parameters, with all three departments having the same rule priority. In department A's X-class list, the single transaction limit is 3,000, the daily cumulative limit is 30,000, and the monthly cumulative limit is 300,000. In department B's Y-class list, the single transaction limit is 4,000, the daily cumulative limit is 20,000, and the monthly cumulative limit is 400,000. In department C's Z-class list, the single transaction limit is 5,000, the daily cumulative limit is 50,000, and the monthly cumulative limit is 100,000. After merging and calculating according to these conditions, the resulting parameter is: user A's payment account has a strictest single transaction limit of 3,000 (from department A's X-class rule), a strictest daily cumulative limit of 20,000 (from department B's Y-class rule), and a strictest monthly cumulative limit of 100,000 (from department C's Z-class rule). Therefore, the limit parameters for this payment scenario are: a single transaction limit of 3,000, a daily cumulative limit of 20,000, and a monthly cumulative limit of 100,000. When a user makes a payment, if the target limit parameter is the above limit parameter, then when another payment operation is required, the payment operation will be verified in turn to ensure that it meets the requirements of a single transaction limit of 3,000, a daily cumulative limit of 20,000, and a monthly cumulative limit of 100,000.
[0086] According to an embodiment of this disclosure, in operation S230, based on the target limit parameter, in response to the target payment operation initiated by the target business user in the current payment scenario, the transaction result of the target payment operation is returned to the target business user, including operations S2301 to S2303.
[0087] In operation S2301, based on the payment amount of the target payment operation and the target limit parameter, the transaction result is obtained; among which,
[0088] In operation S2302, if the payment amount does not exceed the target limit parameter, the payment operation is executed and a successful transaction result is returned;
[0089] When operating S2303, if the payment amount exceeds the target limit parameter, the target payment operation will be intercepted and a limit reminder will be pushed to the target business user.
[0090] Specifically, by comparing the payment amount of the target payment operation with the target limit parameter, and taking into account whether there are risk warnings in the payment environment information, different risk judgment dimensions are constructed; based on the judgment results, differentiated response strategies are executed: if the amount does not exceed the limit and there is no risk warning, the payment operation is executed and a successful transaction result is returned to ensure normal payment needs; if the amount exceeds the limit or there is a risk warning, the target payment operation is intercepted and a limit reminder or risk warning information is pushed to the target business user.
[0091] By adopting the above method, the payment operation is executed or intercepted and a corresponding prompt is pushed based on the comparison between the payment amount and the target limit parameter and whether there are risk warnings in the payment environment information. This ensures that the payment operation is carried out smoothly within the limit and without risk.
[0092] According to embodiments of this disclosure, obtaining payment environment information in the current payment scenario includes at least one of the following:
[0093] Account information of target business users;
[0094] Identification information of the transaction terminal that performs the target payment operation;
[0095] Location information of the transaction terminal that performs the target payment operation.
[0096] In the embodiments disclosed herein, account information refers to core data related to the target business user account, including account real-name authentication level, account opening duration, account historical risk records, and account transaction frequency in the past N days.
[0097] In the embodiments of this disclosure, the identification information of the transaction terminal is the unique identification data of the device used to initiate payment, including the mobile phone IMEI code, computer MAC address, and device universal identification code, etc.
[0098] In the embodiments of this disclosure, the location information of the transaction terminal is the geographical location data of the terminal device when the payment operation is initiated.
[0099] Specifically, the account information of the target business users reflects the credit and risk attributes of the transaction entity; the identification information of the transaction terminal reflects the uniqueness and security of the payment device; and the location information of the transaction terminal reflects the regional risk characteristics of the payment behavior. One or more of these are selected as the content of the payment environment information collection.
[0100] Furthermore, the aforementioned payment environment information can enable the limit parameter configuration model to more accurately determine the level of risk in the current payment scenario.
[0101] By adopting the above methods, the environmental characteristics of payment scenarios are determined from three levels: account credit, device security, and regional risk, thereby improving the model's accuracy in identifying abnormal payment behaviors.
[0102] Figure 3 The second flowchart illustrating a payment transaction processing method according to an embodiment of the present disclosure is shown schematically.
[0103] like Figure 3 As shown, according to an embodiment of this disclosure, after operation S220, in which the payment environment information of the current payment scenario is input into the pre-trained limit parameter configuration model, the method further includes operations S310 to S350.
[0104] When operating S310, extract payment environment information for the current payment scenario;
[0105] During operation S320, feature processing is performed on the extracted payment environment information;
[0106] When operating S330, the payment environment information after feature processing is input into the limit parameter configuration model, which triggers the limit parameter configuration model to call the limit parameter dataset of the target business user in different payment scenarios.
[0107] When operating S340, the scene matching algorithm built into the limit parameter configuration model is used to perform similarity matching between the feature-processed payment environment information and the historical scene features in the limit parameter dataset.
[0108] When operating S350, the target limit parameter is determined based on the similarity matching result to suit the current payment scenario.
[0109] Specifically, the limit parameter configuration model calls the limit parameter dataset of the target business user under different payment scenarios, and then selects a limit parameter in the limit parameter dataset so that the risk level under the limit parameter is adapted to the risk level determined based on the payment environment information.
[0110] By employing the above methods, the extraction of payment environment information, feature processing, access to the limit parameter dataset, and scenario similarity matching are carried out to ultimately determine the appropriate target limit parameters. This achieves a standardized and streamlined transformation from raw data to optimal limit parameters, improves the accuracy of model inference, and also uses scenario matching algorithms to ensure the degree of adaptation of limit parameters to the current payment scenario.
[0111] According to embodiments of this disclosure, the quota parameter configuration model is built based on a deep learning model, which includes an input layer, a feature extraction layer, a scene matching layer, and an output layer.
[0112] The input layer is used to receive the payment environment information after feature processing and the limit parameters under different payment scenarios;
[0113] The feature extraction layer is used to perform feature mapping on the input information and output a high-dimensional scene feature vector.
[0114] The scene matching layer is used to calculate the similarity between the current scene feature vector and the historical scene feature vector, and to determine the appropriate limit parameter range.
[0115] The output layer is used to output the target limit parameters for the current payment scenario.
[0116] Specifically, deep learning models are machine learning models built on neural network structures with multi-layer feature extraction capabilities. Compared to traditional machine learning models, they can better handle non-linear relationships in complex transaction scenarios. The input layer, the first layer of the deep learning model, receives the processed payment environment information and limit parameter dataset, serving as the model's information entry point. The feature extraction layer, the core layer, performs high-dimensional feature mapping on the input information. It includes structures such as convolutional layers (extracting local features), pooling layers (reducing dimensionality and removing redundancy), and fully connected layers (fusion of global features), outputting a high-dimensional scene feature vector that accurately characterizes the essential features of the payment scenario. The scene matching layer calculates the similarity between the current scene and historical scenes, incorporating a similarity calculation module and a limit parameter filtering module. It determines the appropriate limit parameter range based on feature vector similarity. The output layer, the final layer of the deep learning model, converts the output of the scene matching layer into executable target limit parameters, serving as the interface between the model and the business system.
[0117] In the embodiments of this disclosure, the high-dimensional scene feature vector refers to the vector data output by the feature extraction layer that contains the core features of the payment scene, and is the core basis for scene matching.
[0118] In the embodiments of this disclosure, the limit parameter range is a range of limit parameters adapted to the current scenario, which is selected based on the similarity matching results. The limit parameter configuration model selects the optimal value from this range as the target limit parameter.
[0119] For example, the input layer receives payment environment information and user limits after feature processing, with an input dimension of 128. The feature extraction layer contains two convolutional layers and one pooling layer. The convolutional layers extract local features from the input information, and the pooling layer reduces the feature dimension from 128 to 64. Finally, a fully connected layer outputs a 64-dimensional high-dimensional scene feature vector. The scene matching layer has a built-in cosine similarity calculation module and a limit parameter filtering module. It calculates the similarity between the current 64-dimensional feature vector and historical feature vectors, and filters out historical limit parameter intervals with a similarity ≥ 0.8. The output layer adopts a fully connected layer structure and selects the optimal value from the limit parameter interval as the target limit parameter for the current online shopping scenario.
[0120] By adopting the above method, the limit parameter configuration model is constructed as a deep learning model containing an input layer, a feature extraction layer, a scene matching layer, and an output layer. With its multi-level feature extraction structure, it can deeply explore the complex nonlinear relationship between payment environment information and limit parameters, thereby improving the accuracy of limit parameter matching. At the same time, the end-to-end automated processing flow eliminates the need for manual intervention in feature selection and matching, thus improving the response efficiency of payment operations.
[0121] According to an embodiment of this disclosure, after operation S230, which returns the transaction result of the target payment operation to the target business user, the method further includes operation S240.
[0122] During operation S240, the payment environment information, target limit parameters, and transaction results of the current payment scenario are synchronized to the historical database. The historical database is used to update the training samples of the limit parameter configuration model.
[0123] In the embodiments of this disclosure, the historical database stores payment environment information, target limit parameters, and transaction results for all payment scenarios, serving as a training sample library for the limit parameter configuration model.
[0124] Specifically, by updating the training samples, newly generated payment scenario data is added to the historical database for iterative training and optimization of the limit parameter configuration model.
[0125] By adopting the above method, relevant information of the current payment scenario is synchronized to the historical database to update the training samples of the limit parameter configuration model. With the continuous accumulation of new data, the model can continuously learn and optimize, and better adapt to the ever-changing payment scenarios and transaction behaviors.
[0126] The structure of the limit parameter configuration model in the embodiments of this disclosure will be described in detail below.
[0127] For the input layer of the limit parameter configuration model, the input data of the input layer is mapped to the same feature space by a fully connected layer to the payment environment feature data and the limit parameter dataset.
[0128] For the feature extraction layer of the quota parameter configuration model, a combination structure of convolutional layers, pooling layers, and fully connected layers is used. The first convolutional layer extracts local features, such as the correlation between account risk level and regional risk. The second convolutional layer extracts deep global features, such as the adaptation features between terminal security and quota parameters. The global average pooling layer converts the two-dimensional feature map into a one-dimensional feature vector, outputting a one-dimensional feature vector. The fully connected layer fuses the global features, outputting a high-dimensional scene feature vector.
[0129] For the scenario matching layer of the quota parameter configuration model, the scenario matching layer uses the cosine similarity algorithm to calculate the similarity between the current feature vector and the historical feature vector. Specifically, the calculation method is to calculate the similarity between the current feature vector and the historical feature vector.
[0130] Figure 4 A block diagram of a processing system suitable for implementing payment transactions according to an embodiment of the present disclosure is shown schematically.
[0131] Based on the above-described payment processing method, this disclosure also provides a payment processing system. The following will combine... Figure 4 The device is described in detail.
[0132] like Figure 4 As shown, the system includes a database server 410 and an application server 420.
[0133] Database server 410 is used to obtain the quota parameters of target business users under different business scenarios;
[0134] Specifically, when a business department acts as the payment recipient for a target business user's payment operation, it can configure its own limit sub-parameters in the database server based on business needs. Simultaneously, the database server, at regular intervals, determines the target business user's limit parameters for different business scenarios based on these various limit sub-parameters.
[0135] Application server 420 is used to respond to the target payment operation initiated by the target business user in the current payment scenario and to retrieve the target limit parameter of the target business user in the current payment scenario from the database server;
[0136] Specifically, the application server responds to the payment operation request initiated by the user and retrieves the limit parameters from the database server that are adapted to the payment scenario of the user's current payment operation as the target limit parameters.
[0137] Database server 410 is also used to respond to the call operation of application server, obtain payment environment information under the current payment scenario; input the payment environment information under the current payment scenario into a pre-trained limit parameter configuration model; wherein, the limit parameter configuration model is used to determine the target limit parameter under the current payment scenario from the limit parameters; the limit parameter configuration model is trained based on the limit parameters under different payment scenarios and the transaction results in historical periods;
[0138] Specifically, after the application server 420 retrieves the limit parameters adapted to the payment scenario of the user's current payment operation from the database server, the database server inputs the payment environment information of the current payment scenario into the pre-trained limit parameter configuration model, so that the limit parameter configuration model outputs the target limit parameters of the current payment scenario.
[0139] In the embodiments of this disclosure, the database server 420 can be configured with multiple quota modules for inputting quota sub-parameters to different business departments. A parameter processing module configured in the database server periodically updates the input of the quota sub-parameters and provides feedback on the update results in each quota module.
[0140] Application server 420 is also used to return the transaction result of the target payment operation to the target business user based on the target limit parameter.
[0141] Based on the above-described payment processing method, this disclosure also provides a payment processing apparatus. The following will be combined with... Figure 5 The device is described in detail.
[0142] Figure 5 The diagram illustrates a structural block diagram of a payment processing apparatus according to an embodiment of the present disclosure.
[0143] like Figure 5 As shown, the payment processing device 500 of this embodiment includes a parameter acquisition module 510, a model application module 520, and a result acquisition module 530.
[0144] The parameter acquisition module 510 is used to acquire the limit parameters of the target business user under different payment scenarios, as well as the payment environment information under the current payment scenario;
[0145] The model application module 520 is used to input the payment environment information of the current payment scenario into the pre-trained limit parameter configuration model; wherein, the limit parameter configuration model is used to determine the target limit parameter of the current payment scenario from the limit parameters; the limit parameter configuration model is trained based on the limit parameters of different payment scenarios and the transaction results in historical periods;
[0146] The result acquisition module 530 is used to return the transaction result of the target payment operation to the target business user in response to the target payment operation initiated by the target business user in the current payment scenario, based on the target limit parameter.
[0147] According to embodiments of this disclosure, the result acquisition module 530 is further configured to acquire the transaction result based on the payment amount of the target payment operation and the target limit parameter; wherein, if the payment amount does not exceed the target limit parameter and there is no risk warning in the payment environment information, the payment operation is executed and a successful transaction result is returned; if the payment amount exceeds the target limit parameter, or there is a risk warning in the payment environment information, the target payment operation is intercepted and a limit reminder or risk warning information is pushed to the target business user.
[0148] According to an embodiment of this disclosure, the parameter acquisition module 510 is used to acquire payment environment information in the current payment scenario. The payment environment information includes at least one of the following: account information of the target business user; identification information of the transaction terminal executing the target payment operation; and location information of the transaction terminal executing the target payment operation.
[0149] According to embodiments of this disclosure, the model application module 520 is further configured to extract payment environment information under the current payment scenario and perform feature processing on the extracted payment environment information;
[0150] The processed payment environment information is input into the limit parameter configuration model, which triggers the limit parameter configuration model to call the limit parameter dataset of the target business user in different payment scenarios. Based on the scenario matching algorithm built into the limit parameter configuration model, the processed payment environment information is matched with the historical scenario features in the limit parameter dataset. Based on the similarity matching results, the target limit parameter that is suitable for the current payment scenario is determined.
[0151] According to embodiments of this disclosure, the limit parameter configuration model is constructed based on a deep learning model, which includes an input layer, a feature extraction layer, a scene matching layer, and an output layer. The input layer is used to receive payment environment information after feature processing and limit parameters under different payment scenarios. The feature extraction layer is used to perform feature mapping on the input information and output a high-dimensional scene feature vector. The scene matching layer is used to calculate the similarity between the current scene feature vector and the historical scene feature vector and determine the appropriate limit parameter range.
[0152] The output layer is used to output the target limit parameters for the current payment scenario.
[0153] According to embodiments of this disclosure, the apparatus further includes a module training module.
[0154] The block training module is used to synchronize the payment environment information, target limit parameters, and transaction results of the current payment scenario to the historical database. The historical database is used to update the training samples of the limit parameter configuration model.
[0155] According to embodiments of this disclosure, any plurality of modules among the parameter acquisition module 510, model application module 520, and result acquisition module 530 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this disclosure, at least one of the parameter acquisition module 510, model application module 520, and result acquisition module 530 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in any one of software, hardware, and firmware methods, or in a suitable combination of any of these. Alternatively, at least one of the parameter acquisition module 510, model application module 520, and result acquisition module 530 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.
[0156] Figure 6 A block diagram of an electronic device suitable for implementing a payment processing method according to an embodiment of the present disclosure is shown schematically.
[0157] like Figure 6 As shown, an electronic device 600 according to an embodiment of this disclosure includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this disclosure.
[0158] RAM 603 stores various programs and data required for the operation of electronic device 600. Processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Processor 601 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 602 and / or RAM 603. It should be noted that programs may also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in one or more memories.
[0159] According to embodiments of this disclosure, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output (I / O) interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output (I / O) interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.
[0160] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the payment service processing method according to the embodiments of this disclosure.
[0161] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this disclosure, the computer-readable storage medium may include ROM 602 and / or RAM 603 and / or one or more memories other than ROM 602 and RAM 603 described above.
[0162] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code enables the computer system to implement the payment service processing method provided in the embodiments of this disclosure.
[0163] When the computer program is executed by the processor 601, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.
[0164] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.
[0165] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, it performs the functions defined in the system of this disclosure embodiment. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.
[0166] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages include, but are not limited to, languages such as Java, C++, Python, "C", or similar programming languages. The program code can execute entirely on a user's computing device, partially on a user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).
[0167] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0168] Those skilled in the art will understand that the features described in the various embodiments of this disclosure can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments of this disclosure can be combined and / or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.
Claims
1. A method for processing payment transactions, characterized in that, The method includes: Obtain the spending limit parameters of target business users in different payment scenarios, as well as the payment environment information in the current payment scenario; Input the payment environment information under the current payment scenario into the pre-trained limit parameter configuration model; The limit parameter configuration model is used to determine the target limit parameter for the current payment scenario from the limit parameters; the limit parameter configuration model is trained based on the limit parameters for different payment scenarios and transaction results within historical periods. Based on the target limit parameter, in response to the target payment operation initiated by the target business user in the current payment scenario, the transaction result of the target payment operation is returned to the target business user.
2. The method according to claim 1, obtaining the limit parameters of the target business user under different payment scenarios, including: Obtain multiple limit sub-parameters for each payment scenario; Each of the aforementioned limit sub-parameters is configured through a different payment object, which is the payment object when the target business user initiates a payment operation; One of the multiple limit sub-parameters in each payment scenario is determined as the limit parameter for the target business user in each payment scenario.
3. The method according to claim 1, characterized in that, Based on the target limit parameter, in response to the target payment operation initiated by the target business user in the current payment scenario, the transaction result of the target payment operation is returned to the target business user, including: Based on the payment amount of the target payment operation and the target limit parameter, the transaction result is obtained; wherein, If the payment amount does not exceed the target limit parameter, then the target payment operation is executed and a transaction success result is returned; If the payment amount exceeds the target limit parameter, the target payment operation is intercepted, and a limit reminder is pushed to the target business user.
4. The method according to claim 1, characterized in that, Obtain payment environment information for the current payment scenario, including at least one of the following: The target business user's account information; Identification information of the transaction terminal that performs the target payment operation; Location information of the transaction terminal that performs the target payment operation.
5. The method according to claim 1 or 4, after inputting the payment environment information under the current payment scenario into the pre-trained limit parameter configuration model, the method further includes: Extract payment environment information for the current payment scenario; The payment environment information is subjected to feature processing; The feature-processed payment environment information is input into the limit parameter configuration model, which triggers the limit parameter configuration model to call the limit parameter dataset of the target business user in different payment scenarios; Based on the scene matching algorithm built into the limit parameter configuration model, the payment environment information after feature processing is matched with the historical scene features in the limit parameter dataset for similarity matching. Based on the similarity matching results, the target limit parameters suitable for the current payment scenario are determined.
6. The method according to claim 1, wherein the quota parameter configuration model is constructed based on a deep learning model, the deep learning model comprising an input layer, a feature extraction layer, a scene matching layer, and an output layer; wherein, The input layer is used to receive the payment environment information after feature processing and the limit parameters under different payment scenarios; The feature extraction layer is used to perform feature mapping on the input information and output a high-dimensional scene feature vector; The scene matching layer is used to calculate the similarity between the current scene feature vector and the historical scene feature vector, and to determine the appropriate limit parameter range. The output layer is used to output the target limit parameters for the current payment scenario.
7. The method according to claim 1, characterized in that, After returning the transaction result of the target payment operation to the target business user, the method further includes: The payment environment information, target limit parameters, and transaction results of the current payment scenario are synchronized to the historical database, which is used to update the training samples of the limit parameter configuration model.
8. A payment processing system, characterized in that, include: The database server is used to obtain the quota parameters of target business users under different business scenarios; The application server is used to respond to the target payment operation initiated by the target business user in the current payment scenario, and to retrieve the target limit parameter of the target business user in the current payment scenario from the database server; The database server is also configured to respond to the call operation of the application server, obtain payment environment information under the current payment scenario, and input the payment environment information under the current payment scenario into a pre-trained limit parameter configuration model; wherein, the limit parameter configuration model is configured to determine the target limit parameter under the current payment scenario from the limit parameters; the limit parameter configuration model is trained based on the limit parameters under different payment scenarios and transaction results in historical periods; The application server is also used to return the transaction result of the target payment operation to the target business user based on the target limit parameter.
9. A payment processing apparatus, characterized in that, The device includes: The parameter acquisition module is used to acquire the limit parameters of the target business user under different payment scenarios, as well as the payment environment information under the current payment scenario; The model application module is used to input the payment environment information of the current payment scenario into a pre-trained limit parameter configuration model; wherein, the limit parameter configuration model is used to determine the target limit parameter of the current payment scenario from the limit parameters; the limit parameter configuration model is trained based on the limit parameters of different payment scenarios and transaction results in historical periods; The result acquisition module is used to return the transaction result of the target payment operation to the target business user in the current payment scenario, based on the target limit parameter.
10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.
11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.
12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.