CN116957512A - Payment platform message management method, device and computer readable storage medium - Google Patents
Payment platform message management method, device and computer readable storage medium Download PDFInfo
- Publication number
- CN116957512A CN116957512A CN202310950598.XA CN202310950598A CN116957512A CN 116957512 A CN116957512 A CN 116957512A CN 202310950598 A CN202310950598 A CN 202310950598A CN 116957512 A CN116957512 A CN 116957512A
- Authority
- CN
- China
- Prior art keywords
- field
- message
- service
- application form
- authorization
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000007726 management method Methods 0.000 title claims abstract description 59
- 238000013475 authorization Methods 0.000 claims abstract description 58
- 238000012795 verification Methods 0.000 claims abstract description 52
- 238000000034 method Methods 0.000 claims abstract description 51
- 230000008569 process Effects 0.000 claims description 32
- 238000012545 processing Methods 0.000 claims description 18
- 230000006870 function Effects 0.000 claims description 13
- KLPWJLBORRMFGK-UHFFFAOYSA-N Molindone Chemical compound O=C1C=2C(CC)=C(C)NC=2CCC1CN1CCOCC1 KLPWJLBORRMFGK-UHFFFAOYSA-N 0.000 claims description 8
- 229940028394 moban Drugs 0.000 claims description 8
- 238000012544 monitoring process Methods 0.000 claims description 5
- 238000004806 packaging method and process Methods 0.000 claims description 4
- 230000001960 triggered effect Effects 0.000 claims description 4
- 230000002159 abnormal effect Effects 0.000 claims description 3
- 230000005856 abnormality Effects 0.000 claims description 3
- 238000013507 mapping Methods 0.000 description 15
- 238000012546 transfer Methods 0.000 description 8
- 238000004891 communication Methods 0.000 description 7
- 238000011161 development Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 5
- 238000013461 design Methods 0.000 description 4
- 230000006399 behavior Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000012800 visualization Methods 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000002372 labelling Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
- G06Q10/103—Workflow collaboration or project management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F18/00—Pattern recognition
- G06F18/20—Analysing
- G06F18/24—Classification techniques
- G06F18/241—Classification techniques relating to the classification model, e.g. parametric or non-parametric approaches
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/166—Editing, e.g. inserting or deleting
- G06F40/186—Templates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/085—Payment architectures involving remote charge determination or related payment systems
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Human Resources & Organizations (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Artificial Intelligence (AREA)
- Entrepreneurship & Innovation (AREA)
- General Business, Economics & Management (AREA)
- Marketing (AREA)
- Evolutionary Biology (AREA)
- Quality & Reliability (AREA)
- Finance (AREA)
- Life Sciences & Earth Sciences (AREA)
- Operations Research (AREA)
- Bioinformatics & Cheminformatics (AREA)
- Bioinformatics & Computational Biology (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Tourism & Hospitality (AREA)
- Evolutionary Computation (AREA)
- Economics (AREA)
- Health & Medical Sciences (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Computational Linguistics (AREA)
- General Health & Medical Sciences (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention discloses a payment platform message management method, equipment and a computer readable storage medium, wherein the payment platform message management method comprises the following steps: based on ISO message standard, classifying the field of the message segment to be classified; adding an extension field to the field-classified text field, and creating a corresponding standard field set; when a custom field created by a user is detected, adding the user custom field registration to the extension field, and configuring a verification rule of the custom field; when the service information is acquired, generating a corresponding service application form based on the standard field set and the custom field; when the field verification in the service application form passes, a corresponding authorization flow is created; and when the authorization flow is finished and the authorization passes, generating a corresponding message based on the service application form. By the method, the message generation and management flow of the payment platform can be simplified.
Description
Technical Field
The present invention relates to the field of message processing, and in particular, to a method, an apparatus, and a computer readable storage medium for managing a message on a paymate.
Background
The payment platform plays a key role in the transnational transaction, transborder transfer and other remittance processes, and financial entities complete funds transfer by sending remittance messages in specific formats to the payment platform. The payment platform needs to support a plurality of payment business requirements and generate corresponding messages according to different channels and business requirements. However, the formats of the messages are various and changeable, and the verification rules of different messages are different, so that the generation and management flow of the messages can become very complex when the conventional payment platform faces the scenes of message format upgrading, message verification rule changing, message segment changing and the like.
The foregoing is provided merely for the purpose of facilitating understanding of the technical solutions of the present invention and is not intended to represent an admission that the foregoing is prior art.
Disclosure of Invention
The invention mainly aims to provide a method, equipment and a computer readable storage medium for managing a message of a payment platform, and aims to solve the technical problem that the generation and management flow of the message becomes very complex when the conventional payment platform faces to the scenes of message format upgrading, message verification rule changing, message segment changing and the like.
In order to achieve the above object, the present invention provides a paymate message management method, which includes the following steps:
Based on ISO message standard, classifying the field of the message segment to be classified;
adding an extension field to the field-classified text field, and creating a corresponding standard field set;
when a custom field created by a user is detected, adding the user custom field registration to the extension field, and configuring a verification rule of the custom field;
when the service information is acquired, generating a corresponding service application form based on the standard field set and the custom field;
when the field verification in the service application form passes, a corresponding authorization flow is created;
and when the authorization flow is finished and the authorization passes, generating a corresponding message based on the service application form.
Optionally, the step of adding the user-defined field registration to the extension field and configuring the verification rule of the user-defined field when the user-created user-defined field is detected includes:
acquiring a user-defined field added by a user;
registering the custom field to a payment platform and adding the custom field to the extension field as a subfield of the extension field;
and determining a clearing channel and a message type corresponding to the custom field, and configuring corresponding field rules and constraint rules.
Optionally, before the step of creating the corresponding authorization flow based on the flow component when the field verification in the service application form passes, the method further includes:
acquiring a message type and a clearing channel corresponding to the service application form;
determining field rules and constraint rules corresponding to the service application form based on the message type and the clearing channel;
analyzing the service application form into a corresponding Jsonnode object;
traversing the JsonNode object to obtain a field value in the service application form;
performing a conditional check to check the field value based on the field rule;
and when the condition verification of the field value passes, executing the result verification of the field value based on the constraint rule.
Optionally, the step of creating the corresponding authorization procedure when the field verification in the service application form passes includes:
determining a service to be authorized corresponding to the service application form;
determining an execution sequence between a corresponding flow node and the flow node based on the service to be authorized and the flow component;
and setting data processing logic of the flow node and generating the authorization flow based on the parameter entering and condition judgment of the flow node.
Optionally, after the step of setting the data processing logic of the flow node and generating the authorization flow based on the parameter entering and the condition judging of the flow node, the method further includes:
based on the flow component, monitoring the state of the authorization flow and recording the log of the authorization flow;
and when the state of the authorization process is abnormal, determining the reason of the abnormality of the authorization process based on the log.
Optionally, when the authorization process ends and the authorization passes, the step of generating the corresponding message based on the service application form includes:
acquiring a message type and a clearing channel corresponding to the service application form;
determining a corresponding report Wen Moban based on the message type and the clearing channel;
based on the auxiliary instruction, updating the content in the service application form to the message template to generate the corresponding message.
Optionally, before the step of generating the corresponding message based on the service application form when the authorization flow ends and the authorization passes, the method further includes:
when a template creation instruction is detected based on a message management page, a message type and a clearing channel set by a user are acquired;
Creating a template file and determining standard fields selected by a user based on the standard field set;
binding the standard field with the template file to generate a report Wen Moban corresponding to the message type and the clearing channel;
and storing the message template, and calling the corresponding message template when the message is required to be generated based on the service application form.
Optionally, the payment platform message management method further includes:
acquiring service logic, service functions and service data corresponding to a service to be packaged;
according to the service logic, designing a corresponding component interface;
setting corresponding service codes based on the service logic, the service functions and the service data;
based on the component interface and the service code, a service component corresponding to the service to be packaged is generated in a packaging mode;
and when detecting a call instruction triggered by a user, calling the corresponding service component and generating a payment page.
In addition, in order to achieve the above object, the present invention further provides a paymate message management device, including: the system comprises a memory, a processor and a paymate message management program stored on the memory and capable of running on the processor, wherein the paymate message management program is configured to realize the steps of the paymate message management method.
In addition, in order to achieve the above object, the present invention further provides a computer readable storage medium, on which a paymate message management program is stored, which when executed by a processor, implements the steps of the paymate message management method as described above.
The embodiment of the invention provides a payment platform message management method, equipment and a computer readable storage medium, which are used for carrying out field classification on a message field to be classified through ISO message standards, adding an extra extension field to the message field after the field classification to create a standard field set, simultaneously, creating a custom field according to service requirements, adding the custom field to the extra extension field after registration is completed, configuring a verification rule of the custom field, when the payment platform needs to generate a message according to service information, firstly generating a service application form corresponding to the service information based on the standard field set and the custom field, then verifying the field in the service application form based on the field rule and the constraint rule, creating an authorization flow corresponding to the current service when verification is passed, and generating a corresponding message when the authorization flow is ended and all authorization is passed. The method creates the standard field set, allows the user to customize the fields, and can simplify the management flow of the message when facing the scenes such as message format upgrading, message verification rule changing, message segment changing and the like.
Drawings
FIG. 1 is a flow chart of a first embodiment of a paymate message management method of the present invention;
FIG. 2 is a flow chart of a second embodiment of a paymate message management method of the present invention;
FIG. 3 is a flowchart illustrating a third embodiment of a method for managing a paymate message according to the present invention;
FIG. 4 is a flowchart of a fourth embodiment of a method for managing a paymate message according to the present invention;
FIG. 5 is a flowchart of a fifth embodiment of a paymate message management method according to the present invention;
FIG. 6 is a schematic diagram of a message generation step of the paymate of the present invention;
fig. 7 is a schematic diagram of a terminal structure of a hardware running environment according to an embodiment of the present invention.
The achievement of the objects, functional features and advantages of the present invention will be further described with reference to the accompanying drawings, in conjunction with the embodiments.
Detailed Description
It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.
The embodiment of the invention provides a payment platform message management method, and referring to fig. 1, fig. 1 is a flow diagram of a first embodiment of a payment platform message management method according to the invention.
In this embodiment, the method for managing a message of a payment platform includes:
And step S10, carrying out field classification on the text segment to be classified based on the ISO message standard.
And step S20, adding an extension field to the field-classified message field, and creating a corresponding standard field set.
In this embodiment, since the message format and the message field verification rule are easy to change in the previous message generation manner, in this embodiment, a standard field set is defined, and a mapping rule between the standard field set and a standard field of a payment platform is configured so as to map the message when the message is generated, and in addition, in order to expand a service scenario of the payment platform, a developer can also add a custom field to meet the personalized requirement of the message generation.
When the standard field set is defined, the message segments to be classified are required to be classified according to a pre-stored message standard, wherein the message standard is an ISO message standard, and the ISO message standard defines common data exchange scenes in different business fields, such as payment and clearing transactions in the financial field, orders and delivery notices in the electronic commerce field, and the like, and specifies data fields, data structures and data formats required in the scenes. The message field to be classified refers to all platform standard fields without classification, including but not limited to pacs.008.001.08 and pacs.009.001.08, the fields are classified according to message types based on the ISO message standard, for example, pacs.008 is a type and pacs.009 is a type, then a union set of all the fields in each classification is obtained, a standard field set of the platform is established according to the fields, the standard field set is also divided into a plurality of sets according to the message types, the platform standard field corresponds to the standard field in the standard message field union set, the field names adopt more common names, and the differences among specific messages are shielded, so that the limitation of the platform caused by external standards is reduced. Meanwhile, a mapping relation between the standard field of the platform and the standard message field is required to be established so as to be mapped and used when the message is generated. When the mapping relation is established, firstly, the meaning, definition and purpose of the standard field and the standard message field of the platform are obtained, and then the structure, data type, length limitation and other attributes of the standard field and the standard message field of the platform are analyzed. And creating a field corresponding relation table or mapping table, and corresponding the standard field of the platform and the standard message field. And establishing a one-to-one or many-to-one mapping relation as required, namely determining whether a one-to-one mapping relation exists according to semantics and rules between the standard field and the standard message field of the platform, wherein each platform field corresponds to one message field, or a many-to-one mapping relation, namely a plurality of platform fields correspond to one message field. If the difference of data types or coding modes exists between the standard field of the platform and the standard message field, corresponding conversion and transcoding requirements need to be considered so as to ensure accurate transmission and analysis of data. After the mapping relation is established, verification and test are carried out, so that the value of the standard field of the platform can be correctly mapped to the corresponding standard message field, and the value can be correctly restored in the reverse operation. By establishing the mapping relation between the standard field and the standard message field of the platform, the standard field of the platform can be conveniently maintained and updated based on a maintenance mapping relation table.
In this embodiment, by creating the standard field set and establishing a mapping relationship between the standard field set and the standard field of the platform, when the payment platform needs to generate the service application form, excessive manual intervention is not required, and the processing efficiency of the payment service is improved.
And step S30, when the custom field created by the user is detected, adding the user custom field registration to the extension field, and configuring the verification rule of the custom field.
Because the service requirements of different payment services are different, the service application form and the message are subjected to field modification, in order to meet the personalized service requirements of service personnel, in this embodiment, an extra field (extension field) is further added to a standard field set established by the payment platform, and the extension field is used for storing additional details or attributes related to a specific record, and the data type of the extension field is a character string and is used for storing serialized JSON (JavaScript Object Notation, a lightweight data exchange format) information. The JSON information contains all custom fields and values, typically components of custom fields are created by developers on front-end form-filling pages according to their own business characteristics and requirements, and values are filled in by business personnel when applying for payment business. The front end needs to serialize extra fields before submitting to the present paymate. After the developer adds the custom field, the field needs to be registered in the platform standard field table, and only if the custom field is registered, the verification rule and the constraint rule can be configured in the dynamic rule module, otherwise, the custom field can only be used for storing operation and cannot be used for other personalized operation. The user-defined field after registration is added under the extra field to become a sub-field of the extra field. After the registration of the custom field is added, a check rule of the custom field is also required to be configured, and the check rule comprises a field rule and a constraint rule. Constraint rules and field rules can ensure the integrity and validity of data in the process of generating a message, and invalid data can be prevented from being processed or stored in business logic.
The field rule configuration supports operators such as equal to, greater than, less than, interval range, regular, and the like, can configure whether filling is necessary, and the supported data types comprise character strings, numbers and Boolean. Constraint rule configuration supports operators equal to, or, and, not, greater than, less than, interval range, regular and the like, and supported data types comprise character strings, numbers and Boolean. Constraint rules are used to verify the conditional checksum results of the fields, which are typically used to verify the data based on specific conditions or rules, which can help ensure that the data is only verified if the expected conditions are met, avoiding unnecessary verification operations. Result verification refers to verifying the operation result after a certain operation or process is performed to ensure that the operation result meets the expected requirement, so as to check whether the output, calculation result or state of the operation meets the expected requirement. Only if the condition check is passed, the next check result is performed. The condition and result of the field are stored in tree structure, and multiple operation operations can be combined to meet the requirement of complex verification. In addition, the payment platform also supports configuration global field rules and constraint rules, and when the field self-defines the field rules and constraint rules and the platform also has the global field rules and constraint rules, the field rules and constraint rules with narrower ranges can be effective. Optionally, the paymate also supports controlling whether a field rule or constraint is in effect via a switch.
In this embodiment, the standard field set is established, so that mapping of the message field is facilitated, and the payment platform can adapt to the scene of generating the multi-type message, meanwhile, the payment platform supports adding of the custom field and supports dynamic checksum message generation of the custom field, so that the payment service can flexibly add the custom field according to service requirements, and the flexible checksum processing of the custom field is realized through the dynamic checksum message generation function. This approach provides flexibility and scalability of business requirements, enabling payment businesses to better meet changing business requirements.
And step S40, when the service information is acquired, generating a corresponding service application form based on the standard field set and the custom field.
And step S50, when the field verification in the service application form passes, a corresponding authorization flow is created.
And step 60, when the authorization flow is finished and the authorization is passed, generating a corresponding message based on the service application form.
In this embodiment, referring to fig. 6, when a business person enters money transfer information into a money transfer application form, the paymate creates a corresponding business application form based on a defined standard field set and custom fields.
First, the collected service information is matched with the standard field. For information that matches exactly to the standard field, the corresponding association is made directly. For example, the mandatory fields for name, contact, etc. may be mapped directly to the standard fields. Whereas for traffic information that cannot be directly matched, custom fields may be used for recording. The name, data type and description of the custom field, and whether the custom field has to be filled in or not are defined according to the service requirements. And constructing a data structure of the service application form according to the matched standard field and the custom field, wherein the data structure can be represented by using structured data or an equal format, and the integrity and consistency of the service information are ensured. Before the service application form is generated, checksum verification is performed to ensure the validity and correctness of the required fields. Such as verifying the cell phone number format, the legitimacy of the identification card number, etc. And after checking, filling the values of the standard field and the custom field after matching to corresponding positions in the service application form to generate a corresponding service application form.
After the service application form is established, and when the field verification in the service application form passes, generating flow nodes and determining the execution sequence among the flow nodes through a flow component according to the service requirement of the service application form, namely the service to be authorized, setting the data processing logic of the flow nodes and finally generating the authorization flow through the parameter entering and condition judgment of the flow nodes. When the authorization process is finished and all the services requiring authorization are authorized, a corresponding message is generated and sent to the bank receiving the message.
In this embodiment, through the created standard field set and the custom field, a corresponding service application form can be generated according to service requirements of different service scenarios, and a corresponding authorization flow is created at the same time, after all the services to be authorized are authorized, a final message is generated, so that the security of service content is ensured, and meanwhile, the service processing process is simplified.
Further, referring to fig. 2, in a second embodiment of the payment platform message management method of the present invention, step S50 includes the following specific steps:
and S51, acquiring a message type and a clearing channel corresponding to the service application form.
Step S52, determining field rules and constraint rules corresponding to the service application form based on the message type and the clearing channel.
And step S53, analyzing the service application form into a corresponding Jsonnode object.
Step S54, traversing the JsonNode object to obtain a field value in the service application form;
step S55, based on the field rule, executing the condition check for checking the field value.
And step S56, executing the result verification of the field value based on the constraint rule when the condition verification of the field value is passed.
In this embodiment, in the process of generating a message, the fields in the service application form need to be checked first to ensure the regularity and rationality of each field in the finally generated message. This link relies on a set of standard fields established previously, with the fields in the standard field set being registered by default, and the user-defined fields requiring manual registration. Because of the difference between the different message types and the rules of different clearing channels, when field rules and constraint rules are added, clear applicable clearing channels and message types are needed.
When the field verification is carried out, the message type and the clearing channel corresponding to the remittance application form are required to be determined, the corresponding verification rule and the constraint rule are determined through the message type and the clearing channel, then the corresponding Jsonnode object (an object in a lightweight data exchange format) is analyzed from the remittance form, the Jsonnode object is traversed to obtain the field value, whether the field value passes the verification is checked through the verification rule of the field, after all the field values pass the verification, the next constraint verification is executed, and otherwise, the checked error result is returned to prompt to the service personnel. The verification rules include at least the following rules: and (3) checking the data type: based on the definition of the field, it is verified whether the input data meets the expected data type, such as integer, floating point number, date, time, etc. Length limit checking: for the field of the character string type, it is verified whether the length of the input data is within a specified range. And (5) checking a format: for a particular format requirement, it is verified whether the input data conforms to the specified format. For example, the email address may be required to conform to a standard email format, the phone number may be required to conform to a particular country/region format, etc. Uniqueness checking: for fields that require uniqueness, it is verified whether the input data is already present in the system. For example, a user name, an identification card number, etc. need to ensure uniqueness. And (3) logic verification: and carrying out logical verification according to the relation among the fields. For example, the start date cannot be later than the end date, the input amount cannot be negative, or the like. And (3) custom checking: other custom verification rules may be defined according to specific business requirements. Such as verifying the validity of an identification card number, the validity of a bank card number, etc. Taking a Java-based Jackson application library as an example, the remittance application form data is parsed into Jsonnode objects. Traversing the Jsonnode object to obtain a field value in the remittance application form, and checking whether the field value can pass the check by using a check rule corresponding to the field. After all the field checks pass, constraint checks are further executed, wherein the constraint checks comprise conditional check sum result checks, whether the result passes or not can be checked after the conditional check passes, and the constraint rule checks can be considered to pass only if the result passes. If the condition check does not pass, the constraint rule check is ignored. In constraint verification, the verification modes of the condition and the result are similar, firstly, the condition (or the result) is traversed in a tree in a medium sequence, when traversing to a leaf node, namely a platform standard field name, a corresponding field value is obtained from a Jsonnode object through the field name and verified, and then the result is returned to a node at the upper layer to participate in verification operation. If one node check fails, the condition (or result) check fails, and only if all the node checks pass, the condition (or result) check is considered successful.
In this embodiment, by checking the field value in the service application form, the regularity and rationality of each field in the finally generated message can be ensured, and in addition, the developer can customize the checking rule according to the requirements of different channels and messages, thereby enhancing the flexibility of the service. In this way, the payment service can automatically apply corresponding check rules according to different channels and requirements, and compliance and safety of payment operation are ensured.
Referring to fig. 3, in a third embodiment of the payment platform message management method of the present invention, step S60 further includes the following steps:
step S61, determining the service to be authorized corresponding to the service application form.
Step S62, based on the service to be authorized and the flow components, determining the execution sequence between the corresponding flow nodes and the flow nodes.
Step S63, setting data processing logic of the flow node and generating the authorization flow based on the parameter entering and condition judgment of the flow node.
In this embodiment, after the business person has filled out and submitted the money transfer application, the status of the application becomes "unauthorized," a process called "sponsoring. The application is completed only by requiring a service person with authorization rights to authorize the application form. The payment background will be billed. This process is personalized using a process engine, e.g., multiple authorizations may be performed, with the process programming being decoupled from the code. The payment business low code development platform provides payment flow components to adapt flow engine calls. Before a message is generated, the business application form is required to be subjected to multiple approval authorizations so as to ensure the safety of business data, however, the auditing flows required by different businesses are various, the business flow arrangement of the conventional payment platform is realized through hard coding, the business codes are also required to be independently maintained, and the realization is troublesome when the situation of changing the business flow is faced. In order to quickly generate corresponding authorization flows according to different payment services, the invention provides a payment flow component, and different links in the flow engine free combination and serial payment service flows are used at the same time, so that the generation and visualization of the service flows are realized. Taking the remittance business process as an example, the payment platform provides process components such as temporary storage, manager, authorization, message sending and the like. The flow component provides different data processing logic according to the entry and flow engine conditions corresponding to the money transfer application form. For example, multiple grants, multiple messages sent, and nodes sending different messages are handled by control variables and count variables.
Alternatively, the process of generating the authorization process may be designed and implemented according to the specific business needs and rules of the process engine. The payment flow component determines the various nodes required for the flow, each representing a particular processing logic or task, based on business requirements. In turn, there is a need to design relationships between flow nodes, i.e., determine dependencies and execution order between nodes, and flow diagrams or similar visualization tools may be used to help design and understand relationships between nodes. Then, the required input parameters and the resulting output results are determined for each node. These parameters and results may be data objects, function calls, API requests, etc. In each node, the next node to be executed is determined based on the condition judgment of the admission and flow engine, and the condition can be based on various factors such as data content, state, time and the like. And integrating the designed flow nodes and logic into a flow engine. The flow engine may provide various functions such as node management, flow control, error handling, logging, etc. Through the above steps, a flow having a plurality of nodes and condition judgment can be generated. In practical application, design and adjustment are required to be flexibly carried out according to payment service requirements and characteristics of a flow engine so as to meet requirements of practical scenes.
In addition, the payment flow component also supports flow monitoring and log recording, and the flow monitoring not only can monitor the processing stage of a remittance transaction in the platform, but also can check the processing stage and the result of the transaction in other systems in the bank by service personnel after the third party system is accessed. After the message is sent, the platform can also obtain the position information of the message in the network by actively inquiring the communication network. Therefore, the user can conveniently track the flow and check the problems, and the safe and stable operation of the payment service is ensured.
Referring to fig. 4, in a fourth embodiment of the payment platform message management method of the present invention, before step S60, the method further includes the following steps:
and step S70, when a template creation instruction is detected based on the message management page, the message type and the clearing channel set by the user are acquired.
And S80, creating a template file and determining standard fields selected by a user based on the standard field set.
Step S90, binding the standard field with the template file to generate a message template corresponding to the message type and the clearing channel.
And step S100, storing the message template, and calling the corresponding message template when the message is required to be generated based on the service application form.
In this embodiment, the payment background generates a money transfer message after accounting and sends the money transfer message to the receiving line. The developer configures the mapping relation between the business elements and the fields in the template in the text template module in advance. After the template is started, a communication message is automatically generated according to the mapping rule. The message templates can be defined or modified by a developer or business personnel on the message management page. When the payment platform detects a template creation instruction based on a message management page, firstly determining a message type and a clearing channel set by a user, further creating a template file, determining a labeling field selected by the user, binding the standard field selected by the user with the template file, generating a message template corresponding to the current message type and the clearing channel, storing the message template, and calling the message template corresponding to the message type and the clearing channel through the message type and the clearing channel of the service application form when the message is required to be generated based on the service application form.
It should be noted that, when a developer adds a message template in a message template management page according to different clearing channels and message types, a payment platform creates a template file at the front end and displays the template file in a tree structure. The leaf nodes are editable, a developer can select the standard fields of the platform to bind, and the templates after the fields are bound become message template examples. In the stage of generating the message, the platform selects a corresponding template example according to the clearing channel and the message type in the remittance application form, and replaces the content in the remittance application form with the variable in the template example so as to quickly generate the message.
Optionally, a FreeMarker (a template engine) can be used to simplify the replacement of variables in the template, and the fact that the generation logic of the message is relatively fixed is considered, and only the value, judgment and circulation are needed according to the field name, so that the payment platform agrees with the following judgment and circulation instructions to assist the creation of the FreeMarker template:
(1) X-ARRAY: a tag for marking a cycle to be executed, and an array variable for specifying the cycle. If the instruction is present, this indicates that the tag needs to be cycled.
(2) X-SWITCH: a tag for marking the condition switch, and a variable for specifying whether to turn on the tag.
(3) X-CASE: the variable used to store the X-SWITCH binding needs to satisfy the condition value. If the condition is not satisfied, the tag is deleted when the message is generated.
After the developer selects the platform criteria field for binding, a Wen Moban instance is created that contains the three instructions. The back end of the platform converts the template instance into a FreeMarker template, so that the development workload of variable replacement is reduced.
In this embodiment, a payment service low-code development platform (hereinafter referred to as the present platform) can support custom message formats of different channels and messages through a message template. The developer can flexibly configure the message Wen Moban, and generate customized messages according to different channels and requirements, so that the flexibility and the customization capability of message processing are improved. Thus, the payment service can better adapt to the requirements of different channels and message formats, and the integration efficiency and stability with various payment systems are improved.
Referring to fig. 5, in a fifth embodiment of the payment platform message management method of the present invention, the payment platform message management method of the present invention further includes the following steps:
step S110, service logic, service functions and service data corresponding to the service to be packaged are obtained.
And step 120, designing a corresponding component interface according to the business logic.
Step S130, setting corresponding service codes based on the service logic, the service functions and the service data.
And step 140, packaging and generating a service component corresponding to the service to be packaged based on the component interface and the service code.
And step S150, when a call instruction triggered by a user is detected, a corresponding service component is called and a payment page is generated.
In this embodiment, the standard field set of the paymate may be semantically divided into a number of sets including lender information, debit information, fee information, beneficiary information, audit information, etc. In order to facilitate the development of payment services for developers, the platform develops corresponding service components on the platform, packages interface calls and default behavior events therein, and configures mapping of page display names and platform standard field names, front-end verification rules and default style attributes. Meanwhile, the functions of modifying configuration and customizing behavior events are reserved, so that a developer can flexibly adjust service components according to the development change of the service.
Further, when the business logic is packaged into a business component, the business logic, the data and the functions related to the business logic are determined first, then the input and the output of the component are determined according to the business logic, and a proper interface is designed to interact with other modules or objects, then a developer writes codes by using proper algorithms, data structures and design modes, so that specific business logic is realized, and the business logic is packaged into an independent business component.
In the embodiment, through developing the payment page component, a developer can quickly build a personalized payment service page, so that development efficiency is greatly improved. The service logic is packaged in the payment page components, the development process of the page is simplified, under the general condition, a developer can easily splice the payment service page meeting service requirements only by simply dragging operation, the tedious work brought by managing up to tens of small components is avoided, and meanwhile, the service person can flexibly select and configure the components according to own requirements, so that the payment page meeting the service flow and style requirements is constructed, and more personalized and better user experience is realized.
Referring to fig. 7, fig. 7 is a schematic structural diagram of a payment platform packet management device in a hardware running environment according to an embodiment of the present invention.
As shown in fig. 7, the paymate message management device may include: a processor 1001, such as a central processing unit (Central Processing Unit, CPU), a communication bus 1002, a user interface 1003, a network interface 1004, a memory 1005. Wherein the communication bus 1002 is used to enable connected communication between these components. The user interface 1003 may include a Display, an input unit such as a Keyboard (Keyboard), and the optional user interface 1003 may further include a standard wired interface, a wireless interface. The network interface 1004 may optionally include a standard wired interface, a WIreless interface (e.g., a WIreless-FIdelity (WI-FI) interface). The Memory 1005 may be a high-speed random access Memory (Random Access Memory, RAM) Memory or a stable nonvolatile Memory (NVM), such as a disk Memory. The memory 1005 may also optionally be a storage device separate from the processor 1001 described above.
Those skilled in the art will appreciate that the structure shown in fig. 7 is not limiting of the paymate message management device and may include more or fewer components than shown, or may combine certain components, or a different arrangement of components.
As shown in fig. 7, an operating system, a data storage module, a network communication module, a user interface module, and a paymate message management program may be included in the memory 1005 as one type of storage medium.
In the paymate message management device shown in fig. 7, the network interface 1004 is mainly used for data communication with other devices; the user interface 1003 is mainly used for data interaction with a user; the processor 1001 and the memory 1005 in the payment platform message management device of the present invention may be disposed in the payment platform message management device, where the payment platform message management device invokes a payment platform message management program stored in the memory 1005 through the processor 1001, and performs the following steps:
based on ISO message standard, classifying the field of the message segment to be classified;
adding an extension field to the field-classified text field, and creating a corresponding standard field set;
when a custom field created by a user is detected, adding the user custom field registration to the extension field, and configuring a verification rule of the custom field;
when the service information is acquired, generating a corresponding service application form based on the standard field set and the custom field;
When the field verification in the service application form passes, a corresponding authorization flow is created;
and when the authorization flow is finished and the authorization passes, generating a corresponding message based on the service application form.
Further, the paymate message management device invokes the paymate message management program stored in the memory 1005 through the processor 1001, and further performs the following steps:
acquiring a user-defined field added by a user;
registering the custom field to a payment platform and adding the custom field to the extension field as a subfield of the extension field;
and determining a clearing channel and a message type corresponding to the custom field, and configuring corresponding field rules and constraint rules.
Further, the paymate message management device invokes the paymate message management program stored in the memory 1005 through the processor 1001, and further performs the following steps:
acquiring a message type and a clearing channel corresponding to the service application form;
determining field rules and constraint rules corresponding to the service application form based on the message type and the clearing channel;
analyzing the service application form into a corresponding Jsonnode object;
traversing the JsonNode object to obtain a field value in the service application form;
Performing a conditional check to check the field value based on the field rule;
and when the condition verification of the field value passes, executing the result verification of the field value based on the constraint rule.
Further, the paymate message management device invokes the paymate message management program stored in the memory 1005 through the processor 1001, and further performs the following steps:
determining a service to be authorized corresponding to the service application form;
determining an execution sequence between a corresponding flow node and the flow node based on the service to be authorized and the flow component;
and setting data processing logic of the flow node and generating the authorization flow based on the parameter entering and condition judgment of the flow node.
Further, the paymate message management device invokes the paymate message management program stored in the memory 1005 through the processor 1001, and further performs the following steps:
based on the flow component, monitoring the state of the authorization flow and recording the log of the authorization flow;
and when the state of the authorization process is abnormal, determining the reason of the abnormality of the authorization process based on the log.
Further, the paymate message management device invokes the paymate message management program stored in the memory 1005 through the processor 1001, and further performs the following steps:
Determining a corresponding report Wen Moban based on the message type and the clearing channel;
based on the auxiliary instruction, updating the content in the service application form to the message template to generate the corresponding message.
Further, the paymate message management device invokes the paymate message management program stored in the memory 1005 through the processor 1001, and further performs the following steps:
when a template creation instruction is detected based on a message management page, a message type and a clearing channel set by a user are acquired;
creating a template file and determining standard fields selected by a user based on the standard field set;
binding the standard field with the template file to generate a report Wen Moban corresponding to the message type and the clearing channel;
and storing the message template, and calling the corresponding message template when the message is required to be generated based on the service application form.
Further, the paymate message management device invokes the paymate message management program stored in the memory 1005 through the processor 1001, and further performs the following steps:
acquiring service logic, service functions and service data corresponding to a service to be packaged;
According to the service logic, designing a corresponding component interface;
setting corresponding service codes based on the service logic, the service functions and the service data;
based on the component interface and the service code, a service component corresponding to the service to be packaged is generated in a packaging mode;
and when detecting a call instruction triggered by a user, calling the corresponding service component and generating a payment page.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or system that comprises the element.
The foregoing embodiment numbers of the present invention are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments.
From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. ROM/RAM, magnetic disk, optical disk) as described above, comprising instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the method according to the embodiments of the present invention.
The foregoing description is only of the preferred embodiments of the present invention, and is not intended to limit the scope of the invention, but rather is intended to cover any equivalents of the structures or equivalent processes disclosed herein or in the alternative, which may be employed directly or indirectly in other related arts.
Claims (10)
1. The payment platform message management method is characterized by comprising the following steps of:
based on ISO message standard, classifying the field of the message segment to be classified;
adding an extension field to the field-classified text field, and creating a corresponding standard field set;
when a custom field created by a user is detected, adding the user custom field registration to the extension field, and configuring a verification rule of the custom field;
when the service information is acquired, generating a corresponding service application form based on the standard field set and the custom field;
when the field verification in the service application form passes, a corresponding authorization flow is created;
and when the authorization flow is finished and the authorization passes, generating a corresponding message based on the service application form.
2. The paymate message management method of claim 1, wherein upon detecting a user-created custom field, adding the user-custom field registration to the extension field and configuring the verification rules of the custom field comprises:
acquiring a user-defined field added by a user;
registering the custom field to a payment platform and adding the custom field to the extension field as a subfield of the extension field;
and determining a clearing channel and a message type corresponding to the custom field, and configuring corresponding field rules and constraint rules.
3. The paymate message management method of claim 1, wherein the step of creating a corresponding authorization flow based on a flow component when the field verification in the service application passes further comprises:
acquiring a message type and a clearing channel corresponding to the service application form;
determining field rules and constraint rules corresponding to the service application form based on the message type and the clearing channel;
analyzing the service application form into a corresponding Jsonnode object;
traversing the JsonNode object to obtain a field value in the service application form;
Performing a conditional check to check the field value based on the field rule;
and when the condition verification of the field value passes, executing the result verification of the field value based on the constraint rule.
4. The paymate message management method of claim 1, wherein the step of creating a corresponding authorization procedure when the field verification in the service application form passes comprises:
determining a service to be authorized corresponding to the service application form;
determining an execution sequence between a corresponding flow node and the flow node based on the service to be authorized and the flow component;
and setting data processing logic of the flow node and generating the authorization flow based on the parameter entering and condition judgment of the flow node.
5. The paymate message management method of claim 4, wherein after the step of setting the data processing logic of the process node and generating the authorization process based on the parameter entry and the condition determination of the process node, further comprising:
based on the flow component, monitoring the state of the authorization flow and recording the log of the authorization flow;
and when the state of the authorization process is abnormal, determining the reason of the abnormality of the authorization process based on the log.
6. The paymate message management method of claim 1, wherein the step of generating a corresponding message based on the service application form when the authorization process is ended and authorization is passed comprises:
acquiring a message type and a clearing channel corresponding to the service application form;
determining a corresponding report Wen Moban based on the message type and the clearing channel;
based on the auxiliary instruction, updating the content in the service application form to the message template to generate the corresponding message.
7. The paymate message management method according to claim 1, wherein before the step of generating the corresponding message based on the service application form when the authorization process is ended and authorization is passed, the method further comprises:
when a template creation instruction is detected based on a message management page, a message type and a clearing channel set by a user are acquired;
creating a template file and determining standard fields selected by a user based on the standard field set;
binding the standard field with the template file to generate a report Wen Moban corresponding to the message type and the clearing channel;
and storing the message template, and calling the corresponding message template when the message is required to be generated based on the service application form.
8. The paymate message management method of claim 1, wherein the paymate message management method further comprises:
acquiring service logic, service functions and service data corresponding to a service to be packaged;
according to the service logic, designing a corresponding component interface;
setting corresponding service codes based on the service logic, the service functions and the service data;
based on the component interface and the service code, a service component corresponding to the service to be packaged is generated in a packaging mode;
and when detecting a call instruction triggered by a user, calling the corresponding service component and generating a payment page.
9. The utility model provides a payment platform message management equipment which characterized in that, payment platform message management equipment includes: a memory, a processor, and a paymate message management program stored on the memory and executable on the processor, the paymate message management program configured to implement the steps of the paymate message management method of any one of claims 1 to 8.
10. A computer readable storage medium having stored thereon a paymate message management program which when executed by a processor implements the steps of a paymate message management method according to any of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310950598.XA CN116957512A (en) | 2023-07-28 | 2023-07-28 | Payment platform message management method, device and computer readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310950598.XA CN116957512A (en) | 2023-07-28 | 2023-07-28 | Payment platform message management method, device and computer readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116957512A true CN116957512A (en) | 2023-10-27 |
Family
ID=88456373
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310950598.XA Pending CN116957512A (en) | 2023-07-28 | 2023-07-28 | Payment platform message management method, device and computer readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116957512A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117974062A (en) * | 2024-02-22 | 2024-05-03 | 苏州思客科技(集团)有限公司 | Multi-platform use method and system based on business trip application form |
-
2023
- 2023-07-28 CN CN202310950598.XA patent/CN116957512A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117974062A (en) * | 2024-02-22 | 2024-05-03 | 苏州思客科技(集团)有限公司 | Multi-platform use method and system based on business trip application form |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9201920B2 (en) | Creating data in a data store using a dynamic ontology | |
| US11392393B2 (en) | Application runtime configuration using design time artifacts | |
| EP1683009B1 (en) | Systems and methods for configuring software | |
| US6920474B2 (en) | Method and system for enterprise business process management | |
| US8533207B2 (en) | Information processing method, apparatus and program in XML driven architecture | |
| US20060020641A1 (en) | Business process management system and method | |
| US9026580B2 (en) | Validation pipeline | |
| US20120246122A1 (en) | Integrating data-handling policies into a workflow model | |
| CN111290742A (en) | Parameter verification method and device, electronic equipment and readable storage medium | |
| US20130073531A1 (en) | Integrating custom policy rules with policy validation process | |
| US20060085761A1 (en) | Text masking provider | |
| CN110309099A (en) | Interface managerial method, device, equipment and computer readable storage medium | |
| CN112765102B (en) | File system management method and device | |
| CN111880839A (en) | API processing method and device | |
| CN116957512A (en) | Payment platform message management method, device and computer readable storage medium | |
| CN113627145A (en) | Method, device, equipment and medium for generating file of parameterized configuration | |
| CN111831365A (en) | Interface route forwarding method, system, computer equipment and readable storage medium | |
| CN112348326A (en) | Bank business processing method and system | |
| CN117522094A (en) | Seal management method, platform, electronic equipment and storage medium | |
| CN115408009A (en) | Code file generation method, device, equipment and storage medium | |
| US12079866B1 (en) | Cross-system integration platform | |
| CN116737141B (en) | Flow configuration type development method based on flow engine | |
| KR20190122462A (en) | Method and apparatus for providing contract management service | |
| US8209647B1 (en) | Extensible verification system | |
| CN117541409A (en) | Adjustment method of auxiliary accounting field and accounting method of financial certificate |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |