Payment platform message management method, device and computer readable storage medium

Abstract

The application discloses a payment platform message management method, equipment and computer readable storage medium, the payment platform message management method includes the following steps: based on the ISO message standard, the field classification is carried out to the to-be-classified message field; adding an extension field to the field classified message field, creating a corresponding standard field set; when detecting a user-created custom field, registering and adding the user custom field to the extension field, and configuring the verification rule of the custom field; when obtaining business information, generating a corresponding business application form based on the standard field set and the custom field; when the field verification in the business application form passes, creating a corresponding authorization process; when the authorization process ends and the authorization passes, generating a corresponding message based on the business application form. Through the above method, the message generation and management process of the payment platform can be simplified.

Description

Technical Field

[0001] This invention relates to the field of message processing, and more particularly to a method, apparatus, and computer-readable storage medium for managing messages on a payment platform. Background Technology

[0002] Payment platforms play a crucial role in cross-border transactions and remittances. Financial entities transfer funds by sending remittance messages in specific formats to the payment platform. Payment platforms need to support numerous payment service requirements and generate corresponding messages based on different channels and business needs. However, message formats are diverse and constantly changing, and the verification rules for different messages also vary. Previously, payment platforms faced highly complex message generation and management processes when dealing with scenarios such as message format upgrades, changes in message verification rules, and changes in message fields.

[0003] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main objective of this invention is to provide a payment platform message management method, device, and computer-readable storage medium, which aims to solve the technical problem that the message generation and management process becomes very complex when payment platforms face scenarios such as message format upgrades, changes in message verification rules, and changes in message fields.

[0005] To achieve the above objectives, the present invention provides a payment platform message management method, which includes the following steps:

[0006] Based on the ISO message standard, the fields of the message to be classified are classified.

[0007] Add extended fields to the message fields after the fields are classified, and create a corresponding standard field set;

[0008] When a user-created custom field is detected, the user-created custom field is registered and added to the extended fields, and the validation rules for the custom field are configured.

[0009] Upon obtaining business information, a corresponding business application form is generated based on the standard field set and the custom field.

[0010] When the fields in the business application form pass validation, a corresponding authorization process is created;

[0011] When the authorization process ends and authorization is approved, a corresponding message is generated based on the business application form.

[0012] Optionally, the step of registering and adding the user-created custom field to the extended fields and configuring the validation rules for the custom field when a user-created custom field is detected includes:

[0013] Retrieve user-added custom fields;

[0014] Register the custom field with the payment platform and add it to the extended field as a subfield of the extended field;

[0015] Determine the clearing channel and message type corresponding to the custom field, and configure the corresponding field rules and constraint rules.

[0016] Optionally, before the step of creating the corresponding authorization process based on the process component when the field validation in the business application form passes, the method further includes:

[0017] Obtain the message type and clearing channel corresponding to the business application form;

[0018] Based on the message type and clearing channel, determine the field rules and constraint rules corresponding to the business application form;

[0019] The business application form is parsed into a corresponding JsonNode object;

[0020] Iterate through the JsonNode objects to obtain the field values ​​in the business application form;

[0021] Based on the field rules, perform conditional validation to verify the field value;

[0022] When the condition validation of the field value passes, the result validation of the field value is performed based on the constraint rules.

[0023] Optionally, the step of creating the corresponding authorization process when the field validation in the business application form passes includes:

[0024] Determine the pending authorization business corresponding to the business application form;

[0025] Based on the authorized business and process components, determine the corresponding process nodes and the execution order between the process nodes;

[0026] Based on the input parameters and condition judgments of the process node, the data processing logic of the process node is set and the authorization process is generated.

[0027] Optionally, after the step of setting the data processing logic of the process node and generating the authorization process based on the input parameters and condition judgments of the process node, the method further includes:

[0028] Based on the process component, monitor the status of the authorization process and record the log of the authorization process;

[0029] When the authorization process is in an abnormal state, the cause of the abnormality is determined based on the logs.

[0030] Optionally, when the authorization process ends and authorization is successful, the step of generating a corresponding message based on the business application form includes:

[0031] Obtain the message type and clearing channel corresponding to the business application form;

[0032] Based on the message type and the clearing channel, determine the corresponding message template;

[0033] Based on auxiliary instructions, the content in the business application form is updated in the message template to generate the corresponding message.

[0034] Optionally, before the step of generating the corresponding message based on the business application form when the authorization process ends and authorization is approved, the method further includes:

[0035] When a template creation instruction is detected on the message management page, the message type and clearing channel set by the user are obtained;

[0036] Create a template file and determine the standard fields selected by the user based on the set of standard fields;

[0037] The standard fields are bound to the template file to generate message templates corresponding to the message type and clearing channel;

[0038] Save the message template and call the corresponding message template when a message needs to be generated based on the service application form.

[0039] Optionally, the payment platform message management method further includes:

[0040] Obtain the business logic, business functions, and business data corresponding to the business to be encapsulated;

[0041] Based on the aforementioned business logic, design the corresponding component interfaces;

[0042] Based on the aforementioned business logic, business functions, and business data, set up the corresponding business code;

[0043] Based on the component interface and the business code, a business component corresponding to the business to be encapsulated is generated.

[0044] When a user-triggered call command is detected, the corresponding business component is invoked and a payment page is generated.

[0045] In addition, to achieve the above objectives, the present invention also provides a payment platform message management device, the payment platform message management device comprising: a memory, a processor, and a payment platform message management program stored in the memory and executable on the processor, the payment platform message management program being configured to implement the steps of the payment platform message management method as described above.

[0046] In addition, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a payment platform message management program, which, when executed by a processor, implements the steps of the payment platform message management method as described above.

[0047] This invention provides a payment platform message management method, device, and computer-readable storage medium. Using the ISO message standard, it categorizes message fields to be classified and adds extra fields to the categorized fields, creating a standard field set. Simultaneously, users can create custom fields based on business needs. These custom fields are added to the extra fields after registration, and their validation rules must be configured. When the payment platform needs to generate a message based on business information, it first generates a business application form corresponding to the business information based on the standard field set and the custom fields. Then, based on the field rules and constraint rules, it validates the fields in the business application form. If the validation passes, it creates an authorization process corresponding to the current business. When the authorization process ends and all authorizations are approved, the corresponding message is generated. By creating a standard field set and allowing users to define custom fields, this method simplifies the message management process in scenarios involving message format upgrades, changes in message validation rules, and changes in message fields. Attached Figure Description

[0048] Figure 1 This is a flowchart illustrating the first embodiment of the payment platform message management method of the present invention;

[0049] Figure 2 This is a flowchart illustrating the second embodiment of the payment platform message management method of the present invention;

[0050] Figure 3 This is a flowchart illustrating the third embodiment of the payment platform message management method of the present invention;

[0051] Figure 4 This is a flowchart illustrating the fourth embodiment of the payment platform message management method of the present invention;

[0052] Figure 5 This is a flowchart illustrating the fifth embodiment of the payment platform message management method of the present invention;

[0053] Figure 6This is a schematic diagram illustrating the message generation steps of the payment platform of the present invention;

[0054] Figure 7 This is a schematic diagram of the terminal structure of the hardware operating environment involved in the embodiments of the present invention.

[0055] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0056] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0057] This invention provides a method for managing payment platform messages, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of a payment platform message management method according to the present invention.

[0058] In this embodiment, the payment platform message management method includes:

[0059] Step S10: Based on the ISO message standard, classify the fields of the message to be classified.

[0060] Step S20: Add extended fields to the message fields after the fields are classified, and create a corresponding standard field set.

[0061] In this embodiment, since the message format and message field verification rules are prone to change in previous message generation methods, this embodiment defines a standard field set and configures the mapping rules between the standard field set and the standard fields of the payment platform so that they can be mapped and used when generating messages. In addition, in order to expand the business scenarios of the payment platform, developers can also add custom fields to meet the personalized needs of message generation.

[0062] When defining the standard field set, it is necessary to classify the message fields to be classified according to the pre-stored message standard, which is the ISO message standard. The ISO message standard defines common data exchange scenarios in different business domains, such as payment and clearing transactions in the financial field and order and shipping notifications in the e-commerce field, and specifies the data fields, data structures, and data formats required in these scenarios. The message fields to be classified refer to all unclassified platform standard fields, including but not limited to pacs.008.001.08 and pacs.009.001.08. Based on the ISO message standard, the fields are classified according to message type, for example, pacs.008 in one category and pacs.009 in another category. Then, the union of all fields in each category is obtained. The platform's standard field set is built based on these fields. The standard field set is also divided into multiple sets according to message type. The platform standard fields correspond to the standard fields in the union of the standard message fields. The field names use more general names to mask the differences between specific messages, thereby reducing the platform's susceptibility to restrictions imposed by external standards. Simultaneously, a mapping relationship between platform standard fields and standard message fields needs to be established for use during message generation. When establishing this mapping, first, the meaning, definition, and purpose of the platform standard fields and standard message fields are obtained. Then, the structure, data type, length limits, and other attributes of the platform standard fields and standard message fields are analyzed. A field mapping table or mapping table is created to map the platform standard fields and standard message fields. One-to-one or many-to-one mapping relationships can be established as needed. This means determining whether a one-to-one mapping relationship exists, with each platform field corresponding to one message field, or a many-to-one mapping relationship, where multiple platform fields correspond to one message field, based on the semantics and rules between the platform standard fields and standard message fields. If there are differences in data type or encoding methods between the platform standard fields and standard message fields, corresponding conversion and transcoding requirements need to be considered to ensure accurate data transmission and parsing. After establishing the mapping relationship, verification and testing are performed to ensure that the values ​​of the platform standard fields can be correctly mapped to the corresponding standard message fields and can be correctly restored during reverse operations. By establishing a mapping relationship between platform standard fields and standard message fields, it is convenient to maintain and update platform standard fields based on the maintenance mapping table.

[0063] In this embodiment, by creating a standard field set and establishing a mapping relationship between the standard field set and the platform's standard fields, when the payment platform needs to generate a business application form, there is no need for excessive manual intervention, thereby improving the processing efficiency of payment business.

[0064] Step S30: When a user-created custom field is detected, the user-created custom field is registered and added to the extended fields, and the validation rules for the custom field are configured.

[0065] Because different payment services have different business requirements, application forms and messages may require field modifications. To meet the personalized business needs of business personnel, in this embodiment, the standard field set established by the payment platform also includes an "extra" field. This extra field stores additional details or attributes related to a specific record. Its data type is string, and it stores serialized JSON (JavaScript Object Notation, a lightweight data interchange format) information. This JSON information contains all custom fields and values. Typically, developers create custom field components on the front-end form-filling page according to their own business characteristics and needs, and business personnel fill in the values ​​when applying for payment services. Before submitting to the payment platform, the front-end needs to serialize the extra field. After adding a custom field, developers also need to register the field in the platform's standard field table. Only after the custom field is registered can validation rules and constraint rules be configured in the dynamic rules module. Otherwise, the custom field can only perform storage operations and cannot perform other personalized operations. After registration, the custom field is added under the extra field, becoming a subfield of the extra field. After registering and adding custom fields, you also need to configure the validation rules for these fields. Validation rules include field rules and constraint rules. Constraint rules and field rules can ensure the integrity and validity of data during message generation, and in business logic, they can prevent invalid data from being processed or saved.

[0066] Field rule configuration supports operators such as equal to, greater than, less than, range, and regular expressions. Required fields can be configured, and supported data types include strings, numbers, and booleans. Constraint rule configuration supports operators such as equal to, or, and, not equal to, greater than, less than, range, and regular expressions. Supported data types include strings, numbers, and booleans. Constraint rules are used for conditional and result validation of fields. Conditional validation is typically used to verify data based on specific conditions or rules, helping to ensure that data is only validated if it meets expected conditions, avoiding unnecessary validation operations. Result validation refers to verifying the result of an operation or processing to ensure it meets expected requirements, thereby checking whether the output, calculation result, or state of the operation meets expectations. The next step of validation will only proceed if the conditional validation passes. Field conditions and results are stored in a tree structure, allowing for the combination of multiple operations to meet complex validation needs. Furthermore, the payment platform supports configuring global field rules and constraint rules. When a field has custom field rules and constraint rules, and the platform also has global field rules and constraint rules, the more narrowly defined field rules and constraint rules will take effect. Optionally, the payment platform also supports controlling whether a field rule or constraint is effective via a switch.

[0067] In this embodiment, by establishing a standard field set, the mapping of message fields is facilitated, enabling adaptation to scenarios involving the generation of multiple message types. Simultaneously, the payment platform supports adding custom fields and dynamically validating and generating messages for these custom fields. This allows payment services to flexibly add custom fields according to business needs and achieve flexible validation and processing of these custom fields through dynamic validation and message generation. This approach provides flexibility and scalability for business requirements, enabling payment services to better meet evolving business needs.

[0068] Step S40: When business information is obtained, a corresponding business application form is generated based on the standard field set and the custom field.

[0069] Step S50: When the field verification in the business application form passes, create the corresponding authorization process.

[0070] Step S60: When the authorization process ends and the authorization is approved, generate the corresponding message based on the business application form.

[0071] In this embodiment, refer to Figure 6 When a business person enters remittance information into a remittance application form, the payment platform will create a corresponding business application form based on the defined standard field set and custom fields.

[0072] First, the collected business information is matched against standard fields. Information that perfectly matches the standard fields is directly associated. For example, required fields such as name and contact information can be directly mapped to standard fields. For business information that cannot be directly matched, custom fields can be used to record it. Based on business requirements, the name, data type, description, and whether it is required are defined for each custom field. Based on the matched standard and custom fields, the data structure of the business application form is constructed. Structured data formats or similar formats can be used to ensure the completeness and consistency of the business information. Before generating the business application form, validation and verification are performed to ensure the validity and correctness of the required fields. For example, the format of the mobile phone number and the legality of the ID card number are verified. After verification, the values ​​of the matched standard and custom fields are filled into the corresponding positions in the business application form, generating the corresponding business application form.

[0073] Once a business application form is created and its fields pass validation, the process component generates process nodes and determines their execution order based on the business requirements (i.e., the businesses to be authorized). The data processing logic for each process node is set using its input parameters and conditional checks, ultimately generating the authorization process. When the authorization process concludes and all required authorizations are completed, a corresponding message is generated and sent to the receiving bank.

[0074] In this embodiment, by creating a standard field set and custom fields, corresponding business application forms can be generated according to the business needs of different business scenarios. At the same time, corresponding authorization processes can be created. After all pending authorizations are completed, the final message is generated, which ensures the security of business content and simplifies the business processing.

[0075] Furthermore, refer to Figure 2 In the second embodiment of the payment platform message management method of the present invention, step S50 includes the following specific steps:

[0076] Step S51: Obtain the message type and clearing channel corresponding to the business application form.

[0077] Step S52: Based on the message type and clearing channel, determine the field rules and constraint rules corresponding to the business application form.

[0078] Step S53: Parse the business application form into the corresponding JsonNode object.

[0079] Step S54: Traverse the JsonNode object to obtain the field values ​​in the business application form;

[0080] Step S55: Based on the field rules, perform conditional validation to verify the field values.

[0081] Step S56: When the condition validation of the field value passes, perform result validation of the field value based on the constraint rules.

[0082] In this embodiment, during message generation, the fields in the business application form need to be validated to ensure the formality and rationality of each field in the final generated message. This step relies on the previously established standard field set. Fields in the standard field set are registered by default, while user-defined fields need to be registered manually. Since the rules differ for different message types and different clearing channels, the applicable clearing channel and message type need to be clearly defined when adding field rules and constraint rules.

[0083] When performing field validation, it's necessary to first determine the message type and clearing channel corresponding to the remittance application. Based on the message type and clearing channel, the corresponding validation rules and constraints are determined. Then, the remittance form is parsed to obtain the corresponding JsonNode object (a lightweight data exchange format object). This JsonNode object is traversed to obtain its field values. The field values ​​are then validated against the validation rules. If all field values ​​pass validation, the next step of constraint validation is performed; otherwise, the validation error result is returned to the business personnel. Validation rules include at least the following: Data type validation: Based on the field definition, verify whether the input data conforms to the expected data type, such as integers, floating-point numbers, dates, and times. Length limit validation: For string fields, verify whether the length of the input data is within the specified range. Format validation: For specific format requirements, verify whether the input data conforms to the specified format. For example, email addresses must conform to a standard email format, and mobile phone numbers must conform to a specific country / region format. Uniqueness validation: For fields requiring uniqueness, verify whether the input data already exists in the system. For example, usernames and ID numbers need to be unique. Logical Validation: Perform logical validation based on the relationships between fields. For example, the start date cannot be later than the end date, and the entered amount cannot be negative. Custom Validation: Other custom validation rules can be defined according to specific business needs. For example, validating the legality of an ID card number or the validity of a bank card number. Taking the Jackson application library based on Java as an example, the remittance application data is parsed into JsonNode objects. The JsonNode objects are traversed to obtain the field values ​​in the remittance application, and the validation rules corresponding to each field are used to check whether the field value passes the validation. After all fields pass validation, constraint validation is further performed. Constraint validation includes condition validation and result validation. The result validation is only performed after the condition validation passes; only if the result passes is the constraint rule considered valid. If the condition validation fails, the constraint rule validation is ignored. In constraint validation, the validation methods for conditions and results are similar. First, an inorder traversal of the tree is performed on the condition (or result). When the traversal reaches a leaf node, which is the platform's standard field name, the corresponding field value is retrieved from the JsonNode object using that field name and validated. Then, the result is returned to the parent node for further validation. If any node fails validation, the condition (or result) validation will fail. Only when all nodes pass validation is the condition (or result) considered validated successfully.

[0084] In this embodiment, by validating the field values ​​in the business application form, the legitimacy and rationality of each field in the final generated message can be guaranteed. Furthermore, developers can customize validation rules according to the needs of different channels and messages, thereby enhancing the flexibility of the business. In this way, the payment business can automatically apply the corresponding validation rules according to different channels and needs, ensuring the compliance and security of payment operations.

[0085] Reference Figure 3 In the third embodiment of the payment platform message management method of the present invention, step S60 further includes the following steps:

[0086] Step S61: Determine the business to be authorized corresponding to the business application form.

[0087] Step S62: Based on the authorized business and process components, determine the corresponding process nodes and the execution order between the process nodes.

[0088] Step S63: Based on the input parameters and condition judgment of the process node, set the data processing logic of the process node and generate the authorization process.

[0089] In this embodiment, after a business personnel fills out and submits a remittance application form, the application form's status changes to "unauthorized," a process referred to as "processing." Only when authorized business personnel authorize the application form is the application complete. The payment backend then records the transaction. This process can be customized using a workflow engine, allowing for multiple authorizations, and the workflow arrangement is decoupled from the code. This payment business low-code development platform provides payment workflow components to adapt to workflow engine calls. Before generating a message, the business application form needs to undergo multiple approval authorizations to ensure the security of business data. However, different businesses require diverse review processes. Previously, payment platforms implemented business workflow arrangement through hard coding, requiring separate maintenance of the business code, which was cumbersome when faced with changes to the business workflow. To quickly generate corresponding authorization processes for different payment businesses, this invention provides payment workflow components. Simultaneously, the workflow engine allows for the free combination and connection of different stages in the payment business process, thereby achieving business workflow generation and visualization. Taking the outward remittance business process as an example, this payment platform provides workflow components such as temporary storage, processing, authorization, and message sending. The process components provide different data processing logic based on the input parameters corresponding to the remittance application form and the conditions of the process engine. For example, nodes that authorize multiple times, send multiple messages, and send different messages are handled through control variables and counter variables.

[0090] Optionally, the process of generating the authorization flow can be designed and implemented according to specific business needs and the rules of the flow engine. The payment flow component determines the necessary nodes based on business requirements, with each node representing a specific processing logic or task. Furthermore, it is necessary to design the relationships between flow nodes, i.e., determine the dependencies and execution order between nodes. Flowcharts or similar visualization tools can be used to help design and understand the relationships between nodes. Then, the required input parameters and output results are determined for each node. These parameters and results can be data objects, function calls, API requests, etc. Within each node, based on the input parameters and the flow engine's conditional judgments, the next node to be executed is determined. Conditions can be based on various factors, such as data content, status, and time. The designed flow nodes and logic are then integrated into the flow engine. The flow engine can provide various functions, such as node management, flow control, error handling, and logging. Through the above steps, a flow with multiple nodes and conditional judgments can be generated. In practical applications, it is necessary to flexibly design and adjust the flow according to the payment business requirements and the characteristics of the flow engine to meet the requirements of the actual scenario.

[0091] Furthermore, the payment process component supports process monitoring and logging. Process monitoring not only tracks the processing stage of an outward remittance transaction within the platform, but also, after integration with third-party systems, allows business personnel to view the processing stage and results of the transaction in other systems within the bank. After a message is sent, the platform can proactively query the communication network to obtain the message's location information within the network. This facilitates process tracking and troubleshooting for users, thereby ensuring the secure and stable operation of payment services.

[0092] Reference Figure 4 In the fourth embodiment of the payment platform message management method of the present invention, the following steps are included before step S60:

[0093] Step S70: When a template creation instruction is detected on the message management page, obtain the message type and clearing channel set by the user.

[0094] Step S80: Create a template file and determine the standard fields selected by the user based on the standard field set.

[0095] Step S90: Bind the standard fields to the template file to generate message templates corresponding to the message type and clearing channel.

[0096] Step S100: Save the message template, and call the corresponding message template when it is necessary to generate a message based on the service application form.

[0097] In this embodiment, the payment backend generates a remittance message after recording the transaction and sends it to the receiving bank. Developers pre-configure the mapping relationship between business elements and fields in the message template module. Once the template is enabled, communication messages are automatically generated according to the mapping rules. Message templates can be defined or modified by developers or business personnel on the message management page. When the payment platform detects a template creation instruction on the message management page, it first determines the message type and clearing channel set by the user, then creates a template file, determines the user-selected annotation fields, binds the user-selected standard fields to the template file, generates a message template corresponding to the current message type and clearing channel, and saves the message template. When a message needs to be generated based on a business application form, the corresponding message template is called through the message type and clearing channel of the business application form.

[0098] It should be noted that when developers add message templates in the message template management page according to different clearing channels and message types, the payment platform will create template files on the front end and display them in a tree structure. Leaf nodes are editable, and developers can select and bind platform standard fields. The template with bound fields becomes a message template instance. During the message generation stage, the platform will select the corresponding template instance based on the clearing channel and message type in the remittance application form, replacing the variables in the template instance with the content from the remittance application form to quickly generate the message.

[0099] Optionally, FreeMarker (a template engine) can be used to simplify variable replacement in the template. Considering that the message generation logic is relatively fixed, only requiring value retrieval, judgment, and looping by field name, this payment platform has agreed on the following judgment and looping instructions to assist in the creation of FreeMarker templates:

[0100] (1) X-ARRAY: Used to mark the label to be looped and to specify the array variable to loop through. If this instruction exists, it indicates that this label needs to be looped.

[0101] (2) X-SWITCH: A label used to mark a conditional switch, and a variable used to determine whether the label is turned on.

[0102] (3) X-CASE: Used to store the condition values ​​that the variables bound to X-SWITCH must meet. If the conditions are not met, this tag is deleted when the message is generated.

[0103] After developers select and bind the platform's standard fields, a message template instance is created, containing the three instructions mentioned above. The platform's backend then converts this template instance into a FreeMarker template, thereby reducing the development workload related to variable substitution.

[0104] In this embodiment, the payment service low-code development platform (hereinafter referred to as the platform) supports custom message formats for different channels and messages through message templates. Developers can flexibly configure message templates to generate customized messages according to different channels and requirements, improving the flexibility and customization capabilities of message processing. In this way, the payment service can better adapt to the requirements of different channels and message formats, improving the integration efficiency and stability with various payment systems.

[0105] Reference Figure 5 The fifth embodiment of the payment platform message management method of the present invention further includes the following steps:

[0106] Step S110: Obtain the business logic, business functions, and business data corresponding to the business to be encapsulated.

[0107] Step S120: Design the corresponding component interface according to the business logic.

[0108] Step S130: Based on the business logic, business functions, and business data, set the corresponding business code.

[0109] Step S140: Based on the component interface and the business code, encapsulate and generate the business component corresponding to the business to be encapsulated.

[0110] Step S150: When a user-triggered call instruction is detected, the corresponding business component is invoked and a payment page is generated.

[0111] In this embodiment, the standard field set of the payment platform can be semantically divided into many sets, including creditor information, debit information, fee information, beneficiary information, audit information, etc. To facilitate payment business development, this platform has developed corresponding business components, encapsulating interface calls and default behavior events within them. It also configures the mapping between page display names and platform standard field names, front-end validation rules, and default style attributes. Furthermore, we have retained the ability to modify configurations and customize behavior events, allowing developers to flexibly adjust business components according to changes in business needs.

[0112] Furthermore, when encapsulating business logic into business components, the business logic, along with the data and functions involved, is first determined. Then, the inputs and outputs of the components are determined based on the business logic, and appropriate interfaces are designed to interact with other modules or objects. Subsequently, developers use appropriate algorithms, data structures, and design patterns to write code to implement the specific business logic and encapsulate the business logic into an independent business component.

[0113] In this embodiment, by developing payment page components, developers can quickly build personalized payment business pages, greatly improving development efficiency. These payment page components encapsulate business logic, simplifying the page development process. Under normal circumstances, developers can easily assemble payment business pages that meet business needs simply by dragging and dropping, avoiding the tedious work of managing dozens of small components. At the same time, business personnel can flexibly select and configure components according to their own needs, thereby building payment pages that meet business processes and style requirements, achieving a more personalized and superior user experience.

[0114] Reference Figure 7 , Figure 7 This is a schematic diagram of the payment platform message management device structure in the hardware operating environment involved in the embodiments of the present invention.

[0115] like Figure 7 As shown, the payment platform message management device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be a high-speed random access memory (RAM) or a stable non-volatile memory (NVM), such as a disk drive. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0116] Those skilled in the art will understand that Figure 7 The structure shown does not constitute a limitation on the payment platform message management device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0117] like Figure 7 As shown, the memory 1005, which serves as a storage medium, may include an operating system, a data storage module, a network communication module, a user interface module, and a payment platform message management program.

[0118] exist Figure 7In the payment platform message management device shown, the network interface 1004 is mainly used for data communication with other devices; the user interface 1003 is mainly used for data interaction with users; the processor 1001 and memory 1005 in the payment platform message management device of the present invention can be set in the payment platform message management device, and the payment platform message management device calls the payment platform message management program stored in the memory 1005 through the processor 1001 and executes the following steps:

[0119] Based on the ISO message standard, the fields of the message to be classified are classified.

[0120] Add extended fields to the message fields after the fields are classified, and create a corresponding standard field set;

[0121] When a user-created custom field is detected, the user-created custom field is registered and added to the extended fields, and the validation rules for the custom field are configured.

[0122] Upon obtaining business information, a corresponding business application form is generated based on the standard field set and the custom field.

[0123] When the fields in the business application form pass validation, a corresponding authorization process is created;

[0124] When the authorization process ends and authorization is approved, a corresponding message is generated based on the business application form.

[0125] Furthermore, the payment platform message management device, through processor 1001, calls the payment platform message management program stored in memory 1005 and performs the following steps:

[0126] Retrieve user-added custom fields;

[0127] Register the custom field with the payment platform and add it to the extended field as a subfield of the extended field;

[0128] Determine the clearing channel and message type corresponding to the custom field, and configure the corresponding field rules and constraint rules.

[0129] Furthermore, the payment platform message management device, through processor 1001, calls the payment platform message management program stored in memory 1005 and performs the following steps:

[0130] Obtain the message type and clearing channel corresponding to the business application form;

[0131] Based on the message type and clearing channel, determine the field rules and constraint rules corresponding to the business application form;

[0132] The business application form is parsed into a corresponding JsonNode object;

[0133] Iterate through the JsonNode objects to obtain the field values ​​in the business application form;

[0134] Based on the field rules, perform conditional validation to verify the field value;

[0135] When the condition validation of the field value passes, the result validation of the field value is performed based on the constraint rules.

[0136] Furthermore, the payment platform message management device, through processor 1001, calls the payment platform message management program stored in memory 1005 and performs the following steps:

[0137] Determine the pending authorization business corresponding to the business application form;

[0138] Based on the authorized business and process components, determine the corresponding process nodes and the execution order between the process nodes;

[0139] Based on the input parameters and condition judgments of the process node, the data processing logic of the process node is set and the authorization process is generated.

[0140] Furthermore, the payment platform message management device, through processor 1001, calls the payment platform message management program stored in memory 1005 and performs the following steps:

[0141] Based on the process component, monitor the status of the authorization process and record the log of the authorization process;

[0142] When the authorization process is in an abnormal state, the cause of the abnormality is determined based on the logs.

[0143] Furthermore, the payment platform message management device, through processor 1001, calls the payment platform message management program stored in memory 1005 and performs the following steps:

[0144] Based on the message type and the clearing channel, determine the corresponding message template;

[0145] Based on auxiliary instructions, the content in the business application form is updated in the message template to generate the corresponding message.

[0146] Furthermore, the payment platform message management device, through processor 1001, calls the payment platform message management program stored in memory 1005 and performs the following steps:

[0147] When a template creation instruction is detected on the message management page, the message type and clearing channel set by the user are obtained;

[0148] Create a template file and determine the standard fields selected by the user based on the set of standard fields;

[0149] The standard fields are bound to the template file to generate message templates corresponding to the message type and clearing channel;

[0150] Save the message template and call the corresponding message template when a message needs to be generated based on the service application form.

[0151] Furthermore, the payment platform message management device, through processor 1001, calls the payment platform message management program stored in memory 1005 and performs the following steps:

[0152] Obtain the business logic, business functions, and business data corresponding to the business to be encapsulated;

[0153] Based on the aforementioned business logic, design the corresponding component interfaces;

[0154] Based on the aforementioned business logic, business functions, and business data, set up the corresponding business code;

[0155] Based on the component interface and the business code, a business component corresponding to the business to be encapsulated is generated.

[0156] When a user-triggered call command is detected, the corresponding business component is invoked and a payment page is generated.

[0157] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0158] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0159] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0160] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for managing payment platform messages, characterized in that, The payment platform message management method includes the following steps: Based on the ISO message standard, the fields of the message to be classified are classified. Add extended fields to the message fields after the fields are classified, and create a corresponding standard field set; When a user-created custom field is detected, the user-created custom field is registered and added to the extended fields, and the validation rules for the custom field are configured. Upon obtaining business information, a corresponding business application form is generated based on the standard field set and the custom field. When the fields in the business application form pass validation, a corresponding authorization process is created; When the authorization process ends and authorization is approved, a corresponding message is generated based on the business application form.

2. The payment platform message management method as described in claim 1, characterized in that, The steps of registering and adding the user-created custom field to the extended fields and configuring the validation rules for the custom field when a user-created custom field is detected include: Retrieve user-added custom fields; Register the custom field with the payment platform and add it to the extended field as a subfield of the extended field; Determine the clearing channel and message type corresponding to the custom field, and configure the corresponding field rules and constraint rules.

3. The payment platform message management method as described in claim 1, characterized in that, Before the step of creating the corresponding authorization process based on the process component when the field validation in the business application form passes, the following is also included: Obtain the message type and clearing channel corresponding to the business application form; Based on the message type and clearing channel, determine the field rules and constraint rules corresponding to the business application form; The business application form is parsed into a corresponding JsonNode object; Iterate through the JsonNode objects to obtain the field values ​​in the business application form; Based on the field rules, perform conditional validation to verify the field value; When the condition validation of the field value passes, the result validation of the field value is performed based on the constraint rules.

4. The payment platform message management method as described in claim 1, characterized in that, When the field validation in the business application form passes, the steps for creating the corresponding authorization process include: Determine the pending authorization business corresponding to the business application form; Based on the authorized business and process components, determine the corresponding process nodes and the execution order between the process nodes; Based on the input parameters and condition judgments of the process node, the data processing logic of the process node is set and the authorization process is generated.

5. The payment platform message management method as described in claim 4, characterized in that, After the step of setting the data processing logic of the process node and generating the authorization process based on the input parameters and condition judgments of the process node, the method further includes: Based on the process component, monitor the status of the authorization process and record the log of the authorization process; When the authorization process is in an abnormal state, the cause of the abnormality is determined based on the logs.

6. The payment platform message management method as described in claim 1, characterized in that, When the authorization process ends and authorization is approved, the step of generating the corresponding message based on the business application form includes: Obtain the message type and clearing channel corresponding to the business application form; Based on the message type and the clearing channel, determine the corresponding message template; Based on auxiliary instructions, the content in the business application form is updated in the message template to generate the corresponding message.

7. The payment platform message management method as described in claim 1, characterized in that, Before the step of generating the corresponding message based on the business application form when the authorization process ends and authorization is approved, the method further includes: When a template creation instruction is detected on the message management page, the message type and clearing channel set by the user are obtained; Create a template file and determine the standard fields selected by the user based on the set of standard fields; The standard fields are bound to the template file to generate message templates corresponding to the message type and clearing channel; Save the message template and call the corresponding message template when a message needs to be generated based on the service application form.

8. The payment platform message management method as described in claim 1, characterized in that, The payment platform message management method also includes: Obtain the business logic, business functions, and business data corresponding to the business to be encapsulated; Based on the aforementioned business logic, design the corresponding component interfaces; Based on the aforementioned business logic, business functions, and business data, set up the corresponding business code; Based on the component interface and the business code, a business component corresponding to the business to be encapsulated is generated. When a user-triggered call command is detected, the corresponding business component is invoked and a payment page is generated.

9. A payment platform message management device, characterized in that, The payment platform message management device includes: a memory, a processor, and a payment platform message management program stored in the memory and executable on the processor, wherein the payment platform message management program is configured to implement the steps of the payment platform message management method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a payment platform message management program, which, when executed by a processor, implements the steps of the payment platform message management method as described in any one of claims 1 to 8.

Images