A payment callback processing method and device, electronic equipment and storage medium

Abstract

This invention discloses a payment callback processing method, apparatus, electronic device, and storage medium. The method includes: dynamically registering corresponding callback endpoints for multiple payment channels based on preset channel configuration information, wherein the channel configuration information includes message parsing rules, signature verification rules, data mapping rules, and response templates corresponding to the payment channel; responding to a callback notification request received through the callback endpoint, sequentially performing message parsing, signature verification, and data mapping processing on the callback notification request according to the channel configuration information corresponding to the callback endpoint to obtain standard payment data; performing business processing based on the standard payment data, and generating a response message according to the response template and returning it to the third-party platform that sent the callback notification request. This invention unifies the callback notification processing logic of multiple third-party platforms through a configuration-driven pipeline processing mode, reducing the development cost and deployment complexity of new platform integration.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) data processing technology, specifically to a payment callback processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the development of IoT technology, prepaid recharge scenarios in energy management systems require integration with various third-party platforms to implement payment functions. Different third-party platforms exhibit significant differences in callback notification message formats, signature verification rules, field naming, and response message requirements. Different platforms may use structured text formats, markup language formats, or form formats to transmit callback data. The algorithms used for signature verification and the rules for the fields involved in the signature also differ, and the naming and units of fields with the same business meaning are inconsistent across different platforms. For example, regarding message formats, some platforms use XML, some use Form formats, and some use JSON, requiring the writing of multiple sets of different parsing code; regarding signature verification, the algorithms and rules used by different platforms vary, including MD5 lexicographical concatenation, RSA2 certificate verification, SHA256withRSA, etc., and the fields involved in the signature, the sorting method, and the concatenation rules all differ; regarding field naming, fields with the same business meaning are named inconsistently on different platforms, and the monetary unit also differs between yuan and fen; regarding response messages, different platforms have different requirements for the format of callback responses, and if the response format does not meet the requirements, the third-party platform will continuously resend the notification.

[0003] Currently, addressing these differences typically requires developing separate processing code for each third-party platform, leading to significant logic duplication and lengthy development cycles and redeployment for each new platform integration. Therefore, finding a way to implement multi-platform callback notification processing through configuration rather than coding is a pressing issue that needs to be resolved. Summary of the Invention

[0004] The purpose of this invention is to overcome the defects existing in the prior art and provide a payment callback processing method, apparatus, electronic device and storage medium.

[0005] To achieve the above objectives, the first aspect of the present invention provides a payment callback processing method, comprising: Based on preset channel configuration information, corresponding callback endpoints are dynamically registered for multiple payment channels. The channel configuration information includes message parsing rules, signature verification rules, data mapping rules, and response templates corresponding to the payment channels. In response to the callback notification request received through the callback endpoint, the callback notification request is processed sequentially by message parsing, signature verification and data mapping according to the channel configuration information corresponding to the callback endpoint to obtain standard payment data. The business process is executed based on the standard payment data, and a response message is generated based on the response template and returned to the third-party platform that sent the callback notification request.

[0006] Furthermore, based on preset channel configuration information, corresponding callback endpoints are dynamically registered for multiple payment channels, including: Load configuration information for multiple channels that are enabled from persistent storage; For each channel configuration information, a corresponding callback path is determined. When the channel configuration information contains a custom path, the custom path is used as the callback path. When the channel configuration information does not contain a custom path, the callback path is generated by concatenating a preset prefix with the channel identifier of the payment channel. Based on the callback path, the callback endpoint is dynamically registered using the route registration component.

[0007] Furthermore, the message parsing process includes: Based on the message format identifier specified in the message parsing rules, the parsing mode corresponding to the callback notification request is determined, wherein the parsing mode includes structured text parsing mode, markup language parsing mode and form parsing mode; Based on the determined parsing pattern, the request body of the callback notification request is parsed to obtain structured data.

[0008] Furthermore, the signature verification process includes: Based on the algorithm identifier in the signature verification rule, select the target signature verification strategy corresponding to the algorithm identifier from multiple preset signature verification strategies; Based on the target signature verification strategy, the structured data is subjected to signature verification to obtain the verification result; When the verification result is a verification failure, the processing status is marked as failed, and subsequent processing steps continue to be executed.

[0009] Furthermore, based on the target signature verification strategy, the structured data is subjected to signature verification, including: Based on the participating field information and exclusion field information configured in the signature verification rules, target fields for participating in the signature are filtered from the structured data; According to the sorting and concatenation methods configured in the signature verification rules, multiple target fields are sorted and concatenated to obtain the string to be signed; The key is obtained according to the key source information configured in the signature verification rule. Based on the signature algorithm corresponding to the target signature verification strategy, the key is used to calculate the string to be signed to obtain the expected signature value. The expected signature value is compared with the actual signature value carried in the callback notification request to obtain the verification result.

[0010] Furthermore, the signature verification rules also include a signature prefix template and template variable definitions; After obtaining the string to be signed, the method further includes: Parse the placeholders in the signature prefix template, and obtain the corresponding variable values ​​from the request header, request body, or the string to be signed in the callback notification request according to the template variable definition; Replace the placeholders in the signature prefix template with the obtained variable values ​​to obtain the final string to be signed; The calculation of the string to be signed using the key includes: calculating the final string to be signed using the key.

[0011] Furthermore, the data mapping process includes: According to the field extraction path configured in the data mapping rule, the field values ​​to be mapped are extracted from the structured data, wherein the field extraction path supports nested path access; When the value of the field to be mapped is an amount field, the value of the field to be mapped is converted to a unit according to the scaling factor and scaling mode configured in the data mapping rule; When the value of the field to be mapped is a transaction status field, the value of the field to be mapped is converted into a preset standard status value according to the status mapping table configured in the data mapping rules. The standard payment data is generated based on the converted field values.

[0012] Furthermore, performing business processing based on the standard payment data includes: When the transaction status in the standard payment data is successful and the signature verification processing status is passed, the business processing interface is called to perform the recharge operation. When the recharge operation fails, the original data of the callback notification request is persisted to the retry record table for retry processing.

[0013] A second aspect of the present invention provides a payment callback processing apparatus, comprising: The registration module is used to dynamically register corresponding callback endpoints for multiple payment channels based on preset channel configuration information. The channel configuration information includes message parsing rules, signature verification rules, data mapping rules, and response templates corresponding to the payment channel. The processing module is used to respond to the callback notification request received through the callback endpoint, and perform message parsing, signature verification and data mapping processing on the callback notification request in sequence according to the channel configuration information corresponding to the callback endpoint to obtain standard payment data. The business module is used to perform business processing based on the standard payment data and generate a response message based on the response template to return to the third-party platform that sent the callback notification request.

[0014] A third aspect of the present invention provides an electronic device, including a memory and a processor, wherein the memory stores a computer program that, when executed by the processor, implements the method described in the first aspect.

[0015] A fourth aspect of the present invention provides a computer-readable storage medium having program instructions stored thereon, which, when executed, implement the method described in the first aspect.

[0016] The advantages and beneficial effects of this invention are as follows: By dynamically registering a corresponding callback endpoint for each payment channel through preset channel configuration information, upon receiving a callback notification request through the callback endpoint, the request is sequentially processed through message parsing, signature verification, and data mapping according to the channel configuration information corresponding to the endpoint, resulting in the corresponding standard payment data. Then, business processing is executed based on the standard payment data, and a response message is generated and returned to the third-party platform that sent the callback notification request. This unifies the callback notification processing logic of various third-party platforms into a configuration-driven pipeline processing mode. Through the message parsing rules, signature verification rules, data mapping rules, and response templates in the channel configuration information, it can adapt to the differences in message format, signature algorithm, field naming, and response requirements of different platforms, eliminating the need to write separate processing code for each platform and reducing the development cost and deployment complexity of new platform integration. Attached Figure Description

[0017] Figure 1 This is a flowchart of the payment callback processing method of the present invention; Figure 2 This is a schematic diagram of the payment callback processing system in this invention; Figure 3 This is a schematic diagram of the processing flow of the pipeline engine of the present invention; Figure 4 This is a schematic diagram of the payment callback processing device of the present invention; Figure 5 This is a schematic diagram of the structure of the electronic device of the present invention. Detailed Implementation

[0018] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings and examples. The following examples are only used to more clearly illustrate the technical solutions of the present invention and should not be construed as limiting the scope of protection of the present invention.

[0019] like Figure 1 As shown, the payment callback processing method of the present invention includes the following steps: S101. Based on preset channel configuration information, dynamically register corresponding callback endpoints for multiple payment channels respectively, wherein the channel configuration information includes message parsing rules, signature verification rules, data mapping rules and response templates corresponding to the payment channel.

[0020] During startup, the system loads all enabled channel configuration information from persistent storage (such as a database). This channel configuration information includes message parsing rules, signature verification rules, data mapping rules, and response templates for each payment channel. The system determines the corresponding callback path for each channel configuration: if the channel configuration contains a custom path, that custom path is used as the callback path; if the channel configuration does not contain a custom path, a callback path is generated by concatenating a preset prefix with the channel identifier of the payment channel. Subsequently, based on the determined callback path, the system dynamically registers an independent callback endpoint for each payment channel through a routing registration component. In this way, each payment channel has a unique callback endpoint, and the payment channel to which it belongs can be directly determined upon request arrival, without the need to additionally parse channel information from the request content.

[0021] In one implementation, when channel configuration information changes (such as being added, modified, or deleted), the system can automatically unregister all registered callback endpoints and re-execute dynamic registration based on the changed channel configuration information, thereby achieving hot updates of callback endpoints without restarting the application.

[0022] S102. In response to the callback notification request received through the callback endpoint, according to the channel configuration information corresponding to the callback endpoint, the callback notification request is sequentially processed by message parsing, signature verification and data mapping to obtain standard payment data.

[0023] When a third-party platform sends a callback notification request to a registered callback endpoint, the system receives the request and extracts the request header and request body to construct a callback processing context. Based on the channel identifier bound to the callback endpoint, the system retrieves the corresponding message parsing rules, signature verification rules, and data mapping rules from the channel configuration information. Then, it sequentially performs message parsing, signature verification, and data mapping processing on the callback notification request in a pipelined manner.

[0024] During the message parsing and processing phase, the system determines the corresponding parsing mode (structured text parsing mode, markup language parsing mode, or form parsing mode) based on the message format identifier specified in the message parsing rules, and parses the request body based on the determined parsing mode to obtain structured data.

[0025] During the signature verification process, the system selects a matching target signature verification strategy from multiple preset signature verification strategies based on the algorithm identifier in the signature verification rules, and performs signature verification on the parsed data based on this strategy. It should be noted that when signature verification fails, the system marks the processing status as failed but does not interrupt subsequent processing steps to ensure that a response message conforming to the requirements of the third-party platform is still returned.

[0026] During the data mapping process, the system extracts fields from the parsed data and performs necessary unit conversions and status value mappings based on the field extraction paths and transformation rules configured in the data mapping rules, ultimately generating standard payment data.

[0027] S103. Perform business processing based on the standard payment data, and generate a response message based on the response template to return to the third-party platform that sent the callback notification request.

[0028] When the transaction status in the standard payment data is successful and the signature verification processing status is passed, the system calls the business processing interface to execute the recharge operation. If the recharge operation fails, the system persists the original data of the callback notification request to the retry record table for subsequent automatic retries. Finally, the system assembles a response message that meets the requirements of the third-party platform based on the response template in the channel configuration information and returns it. Different payment channels may require different response message formats. The response template defines the response content type, message body, and status code, and the system generates the corresponding response accordingly.

[0029] This invention dynamically registers a corresponding callback endpoint for each payment channel through preset channel configuration information. Upon receiving a callback notification request through the callback endpoint, the request is sequentially processed through message parsing, signature verification, and data mapping according to the channel configuration information corresponding to the endpoint, yielding the corresponding standard payment data. Business processing is then executed based on this standard payment data, and a response message is generated and returned to the third-party platform that sent the callback notification request. This unifies the callback notification processing logic of various third-party platforms into a configuration-driven pipeline processing mode. By utilizing the message parsing rules, signature verification rules, data mapping rules, and response templates in the channel configuration information, it can adapt to differences in message format, signature algorithm, field naming, and response requirements across different platforms, eliminating the need to write separate processing code for each platform and reducing the development cost and deployment complexity of integrating new platforms.

[0030] To ensure that each payment channel has an independent callback endpoint and that the callback path can be flexibly specified through configuration, avoiding the limitations of hard-coded routing, a preferred embodiment of the present invention dynamically registers corresponding callback endpoints for multiple payment channels based on preset channel configuration information. This includes: loading multiple channel configuration information that is in an enabled state from persistent storage; determining the corresponding callback path for each channel configuration information, wherein when the channel configuration information contains a custom path, the custom path is used as the callback path; when the channel configuration information does not contain a custom path, the callback path is generated by concatenating a preset prefix with the channel identifier of the payment channel; and dynamically registering the callback endpoint using a routing registration component based on the callback path.

[0031] In practice, during application startup, the system queries the database for all channel configuration records with an enabled status (enabled=1). Each channel configuration record is stored in a channel configuration data table (e.g., named pay_notify_channel_config), which includes fields such as channel identifier (channel_id), channel name (channel_name), message format (body_format), custom callback path (callback_path), signature verification rule (signature_rule), data mapping rule (data_mapping_rule), response template (response_template), maximum number of retry attempts (retry_count), retry interval (retry_interval_ms), and enabled flag (enabled). The signature verification rule, data mapping rule, and response template are stored in structured text fields.

[0032] It should be noted that the specific field design of the channel configuration data table can be flexibly adjusted according to actual business needs. This embodiment of the invention does not limit this, and the above field structure is used as an example for explanation.

[0033] The system caches the loaded channel configuration information in memory (e.g., using a ConcurrentHashMap data structure) and indexes it with the channel identifier as the key, so that the database does not need to be queried every time a callback notification request is processed, thus improving processing efficiency.

[0034] Subsequently, the system iterates through all channel configuration information and determines the callback path for each channel. The specific path resolution logic is as follows: when the custom callback path field in the channel configuration information is not empty (e.g., configured as " / callback / wechatpay / notify"), the custom path is directly used as the callback path; when the custom callback path field is empty, the system automatically generates the callback path by concatenating a preset prefix with the channel identifier (e.g., " / api / payment / notify / STARPAY"). After the path is determined, the system creates a handler object for each channel, binds the channel identifier and the pipeline engine reference to the handler, and then calls the registration method of the route registration component (e.g., the RequestMappingHandlerMapping component in the Spring framework) to register the determined callback path as a callback endpoint that only accepts POST requests.

[0035] It should be noted that the specific implementation of the route registration component can adopt the dynamic route registration capabilities provided by different web frameworks. This embodiment of the invention does not limit this, and the Spring framework's RequestMappingHandlerMapping is used as an example for illustration.

[0036] In addition, the system retains a general fallback endpoint based on path variables (such as " / api / payment / notify / {channelId}"). When a channel's dynamic endpoint is not registered due to a brief gap during configuration changes, callback notification requests can still enter the processing flow through this fallback endpoint.

[0037] When channel configuration information changes, the system performs a hot update operation: first, it unregisters all registered callback endpoints one by one, then clears the registration records, and then re-executes the above registration process. In this way, configuration changes take effect without restarting the application.

[0038] An example of the core algorithm flow for the above dynamic endpoint registration and callback processing is as follows: Algorithm 1: registerAllEndpoints() — Batch registration of dynamic endpoints Input: None (automatically retrieved from the database) Output: Register a separate POST endpoint for each enabled channel. 1. channelConfigs ← Retrieves all channel configurations with enabled=1 from the database. 2. FOR EACH config IN channelConfigs DO 3. path ← resolvePath(config) 4. IF path already exists in registeredEndpoints THEN 5. Skip to avoid path conflicts 6. END IF 7. handler ← Creates a NotifyHandler instance and binds it: 8. channelId = config.channelId 9. pipelineEngine = Current pipeline engine 10. mappingInfo ← RequestMappingInfo.builder() 11. .path(path) / / Callback URL path 12. .method(POST) / / Only accepts POST requests 13. .build() 14. handlerMapping.registerMapping(mappingInfo, handler) 15. registeredEndpoints[path] ← config.channelId 16. END FOR Algorithm 2: resolvePath(config) — Resolve the channel callback path Input: Channel configuration config Output: The callback URL path for this channel. 1. IF config.callback_path is not empty THEN 2. / / The administrator has configured a custom path, such as " / callback / wechatpay / notify". 3. RETURN normalized callback_path (ensure it starts with " / ") 4. ELSE 5. / / No custom path configured, automatically generated. 6. RETURN " / api / payment / notify / " + config.channel_id 7. / / Such as " / api / payment / notify / STARPAY" 8. END IF Algorithm 3: reRegister() — Hot update endpoint when configuration changes 1. FOR EACH path IN registeredEndpoints.keys() DO 2. mappingInfo ← RequestMappingInfo.builder() 3. .path(path).method(POST).build() 4. handlerMapping.unregisterMapping(mappingInfo) / / Unregister the old endpoint 5. END FOR 6. registeredEndpoints.clear() 7. registeredHandlers.clear() 8. Call registerAllEndpoints() / / Re-register Algorithm 4: NotifyHandler.handle(request) — Single-channel callback handling Input: HTTP request Output: HTTP response 1. headers ← Extract all request headers from the request into a Map 2. rawBody ← Reads the request's input stream as a string. 3. context ← Create NotifyContext(this.channelId, headers, rawBody) 4. result ← pipelineEngine.process(context) 5. / / The above pipelineEngine.process() will then be executed. Figure 2 The 6-step production line shown 6. IF result.responseEntity is not empty THEN 7. RETURN result.responseEntity 8. ELSE 9. RETURN ResponseEntity.ok("success") / / Fallback response 10. END IF The key points of the example above are: First, the callback URL for each channel is entirely determined by the `callback_path` field in the database, not by a fixed path in the code, thus enabling each channel to have its own independent URL. Second, the Handler object is bound to the specific `channelId` during registration, so after a request arrives, there's no need to parse the channel identifier from the URL; the context can be directly constructed and passed to the pipeline. Third, the hot update implementation is relatively simple: all old endpoints are unregistered and then re-registered. The advantage of this is that the service doesn't need to be restarted; the disadvantage is a very short downtime during updates, but this is practically negligible.

[0039] Using the above method, the system can automatically register callback endpoints for all enabled channels at startup and perform hot updates when configurations change. At the same time, the callback request processing logic for a single channel is clear and reusable.

[0040] Below is a complete example of channel configuration information. The following is the configuration data for a payment channel named StarPay, represented in structured text (JSON) format: { "requestParseRule": { "bodyPath": "$", "signHeaderName": "X-StarPay-Signature", "timestampHeaderName": "X-StarPay-Timestamp", "nonceHeaderName": "X-StarPay-Nonce" }, "signatureRule": { "algorithm": "HMAC_SHA256", "signLocation": "HEADER", "signField": "X-StarPay-Signature", "keyLocation": "CONSTANT", "keyValue": "starpay_secret_key", "excludeFields": ["sign"], "sortMethod": "KEY_ASC", "concatMethod": "KV_EQUALS_AMPERSAND", "hashOutputFormat": "HEX_UPPER", "preSignTemplate": "{timestamp}\n{nonce}\n{signing_string}\n", "preSignVariables": { "timestamp": {"source": "HEADER", "field": "X-StarPay-Timestamp"}, "nonce": {"source": "HEADER", "field": "X-StarPay-Nonce"}, "signing_string": {"source": "CONSTRUCTED"} }, "enableVerify": true }, "dataMappingRule": { "fieldMappings": { "outTradeNo": {"path": "$.out_trade_no", "type": "STRING"}, "amount": {"path": "$.trade_amount", "type": "INTEGER", "scale": 100, "scaleMode": "MULTIPLY"}, "meterId": {"path": "$.attach.meter_id", "type": "STRING"}, "status": {"path": "$.trade_status", "type": "STRING"}, "thirdPartyOrderNo": {"path": "$.trade_no", "type": "STRING"} }, "statusMapping": { "SUCCESS": "SUCCESS", "PAID": "SUCCESS", "FAILED": "FAIL" } }, "responseTemplate": { "success": { "contentType": "application / json", "body": "{\"code\":\"000000\",\"message\":\"OK\"}", "httpStatus": 200 }, "failure": { "contentType": "application / json", "body": "{\"code\":\"999999\",\"message\":\"FAIL\"}", "httpStatus": 200 } } } In the above configuration, the `algorithm` field of the `signatureRule` section specifies the signature algorithm type, i.e., which verification algorithm to choose. For example, it can support MD5_SORT, SHA256_WITH_RSA, HMAC_SHA256, RSA_CERT, and NONE. `signLocation` and `signField` specify the actual storage location of the signature value: `HEADER` indicates it's in the request header, and `BODY` indicates it's in the request body. `excludeFields` specifies fields to be excluded during signature calculation; for example, the `sign` field should not participate in the signature calculation. `concatMethod` is the field concatenation method; for example, `KV_EQUALS_AMPERSAND` concatenates in the format "key=value&key=value". `preSignTemplate` is the signature prefix template, which can use placeholders like `{variable name}`, which will be replaced with the actual values ​​during runtime. `preSignVariables` defines the source of its variables. `scaleMode` and `scale` are used for currency conversion; for example, configuring `scale=100` in MULTIPLY mode means multiplying by 100, converting the unit from yuan to yuan. The `dataMappingRule` section defines the extraction path (JSONPath expression) and type conversion rules for each field through `fieldMappings`. `statusMapping` is a mapping table of status values, defining the mapping relationship of transaction statuses, and can uniformly convert various status values ​​from third-party platforms into `SUCCESS` or `FAIL` in the system. The `responseTemplate` section defines the response formats for both success and failure scenarios. It should be noted that the above JSON structure is only an exemplary configuration organization method, and this disclosure does not limit the specific data format and hierarchical structure of channel configuration information.

[0041] To adapt to the differences in message formats used by different third-party platforms and achieve unified message parsing processing, a preferred embodiment of the present invention includes the following message parsing processing: determining the parsing mode corresponding to the callback notification request based on the message format identifier specified in the message parsing rules, wherein the parsing mode includes a structured text parsing mode, a markup language parsing mode, and a form parsing mode; and parsing the request body of the callback notification request based on the determined parsing mode to obtain structured data.

[0042] When receiving a callback notification request from a third-party platform, the request header and request body are extracted to construct a callback processing context. Specifically, when the third-party platform sends a payment result notification to a registered callback endpoint, the processor object bound to that endpoint receives the request. The processor extracts all request header information (stored as key-value pairs) and the raw string content of the request body from the request, and then constructs a callback processing context object (e.g., named NotifyContext). This context object contains the channel identifier, request header information, and the raw request body, serving as a shared data carrier for subsequent pipeline steps.

[0043] It should be noted that the pipeline engine in this embodiment of the invention contains six ordered processing steps, which are the core logic for handling callback notification requests. Each step is an independent component. Taking one implementation as an example, these six steps can be named as follows: Configuration Loading Step, Request Parse Step, Signature Verification Step, Data Extraction Step, Business Processing Step, and Response Assemble Step. The execution order of each step is controlled by sequence annotations (such as the @Order annotation). All steps share the aforementioned callback processing context object (NotifyContext) and can read and write intermediate processing results within it. During pipeline engine execution, if a step is marked as failing or throws an exception, subsequent steps will not be executed (short-circuit mechanism); however, the signature verification step is an exception when verification fails, and the pipeline will continue to execute until the response assembly step even after the signature verification step is marked as failing.

[0044] Then, the channel configuration information corresponding to that channel is loaded from the memory cache. In specific implementations, such as... Figure 2 As shown, the pipeline engine searches for the corresponding channel configuration information in the memory cache based on the channel identifier in the callback processing context. This channel configuration information contains all the configuration data required for processing, including message parsing rules, signature verification rules, data mapping rules, and response templates for that channel. If the corresponding channel configuration information is not found in the cache, it means that the channel is not enabled or does not exist. The system marks the processing status as failed and directly jumps to the response assembly step, returning a failure response.

[0045] Then, the request body is parsed according to the message parsing rules. In practice, the system determines the corresponding parsing mode based on the message format identifier specified in the message parsing rules within the channel configuration information. For example... Figure 3As shown, in the message parsing step of the pipeline, when the message format is identified as JSON, a structured text parsing mode is used to parse the request body into a structured data object in key-value pair format; when the message format is identified as XML, a markup language parsing mode is used to parse the markup language document in the request body into a structured data object; and when the message format is identified as FORM, a form parsing mode is used to parse the form-encoded data in the request body into a structured data object. After parsing, the structured data is written to the callback processing context for use in subsequent steps.

[0046] It should be noted that the parsing modes are not limited to the three mentioned above, and can be extended to support other message formats as needed. Furthermore, when an encryption algorithm is specified in the channel configuration information, the system will decrypt the request body before performing message parsing.

[0047] To adapt to signature verification algorithms on different platforms and ensure that a response message conforming to platform requirements is returned even after signature verification failure, thus avoiding duplicate notifications due to incorrect response formats, a preferred embodiment of this invention includes the following steps for the signature verification process: selecting a target signature verification strategy corresponding to the algorithm identifier from multiple preset signature verification strategies based on the algorithm identifier in the signature verification rules; performing signature verification on the structured data based on the target signature verification strategy to obtain a verification result; and marking the processing status as failed when the verification result is a verification failure, and continuing to execute subsequent processing steps.

[0048] This invention performs signature verification on the parsed data using signature verification rules. Specifically, the signature verification process is implemented using the strategy pattern. For example, in one implementation, the system defines a signature verification strategy interface (e.g., named CryptoStrategy), which includes a verify() method. For different signature algorithms, the following strategy classes are implemented: MD5 lexicographical concatenation strategy (Md5SortStrategy), which arranges parameters in lexicographical order according to field names, concatenates them into the format "key=value&key=value", appends the key to the end, calculates the MD5 digest, and compares the results; SHA256withRSA strategy (Sha256WithRsaStrategy), which parses the timestamp, nonce_str, and signature parameters from the request header, concatenates them in the format "{timestamp}\n{nonce_str}\n{body}\n", and performs RSA verification using the platform's public key; HMAC-SHA256 strategy (HmacSha256Strategy), which supports configuring a signature prefix template (preSignTemplate), allowing different platforms to adapt even if they use the same HMAC-SHA256 algorithm but have different data arrangement before signing, by modifying the template configuration; and NoopVerifyStrategy, which directly returns a successful verification result, used in test environments or channels that do not require signature verification. The system uses a strategy factory class (e.g., named CryptoStrategyFactory) to automatically return the corresponding strategy instance based on the algorithm identifier in the signature verification rule (such as MD5_SORT, SHA256_WITH_RSA, HMAC_SHA256, RSA_CERT, or NONE).

[0049] It should be noted that the signature verification strategy is not limited to the above types, and new signature algorithm strategies can be extended according to actual needs. The specific type of signature algorithm is not limited in the embodiments disclosed herein.

[0050] When the verification result is a failure, the system marks the processing status as failed, but does not interrupt subsequent processing steps. Instead, it continues to execute the data mapping processing and response assembly steps. The reason for this is that if processing is directly interrupted and an unexpected response is returned when signature verification fails, third-party platforms may consider the notification undelivered and continuously resend the callback notification.

[0051] To allow for adaptation of signature rule differences across different platforms through configuration modifications, a preferred embodiment of this invention involves performing signature verification on the structured data based on the target signature verification strategy. This includes: filtering target fields for signature participation from the structured data according to the participating and excluding field information configured in the signature verification rules; sorting and concatenating multiple target fields according to the sorting and concatenation methods configured in the signature verification rules to obtain a string to be signed; obtaining a key according to the key source information configured in the signature verification rules; calculating the string to be signed using the key based on the signature algorithm corresponding to the target signature verification strategy to obtain an expected signature value; and comparing the expected signature value with the actual signature value carried in the callback notification request to obtain the verification result.

[0052] The specific execution process of signature verification is as follows: First, the system filters the target fields for signature participation from the parsed data based on the participating field information and excluded field information configured in the signature verification rules. Specifically, the system iterates through all fields in the parsed data, skips fields with empty values, excludes fields specified in the excluded field list of the signature verification rules (such as the signature value field itself), and retains only the fields listed in the whitelist when a participating field whitelist is configured in the signature verification rules.

[0053] Then, the system sorts and concatenates the filtered target fields according to the sorting method (e.g., ascending order by field name) and concatenation method (e.g., "key=value&key=value" format or value-only concatenation format) configured in the signature verification rules to obtain the string to be signed. It should be noted that the sorting method and concatenation method can be flexibly configured according to the requirements of different platforms, and this embodiment does not limit them. Here, we take sorting by field name in ascending order and concatenation in "key=value&" format as an example for illustration.

[0054] Subsequently, the system obtains the key according to the key source information configured in the signature verification rules. The key source supports multiple methods, including obtaining it directly from the configuration (CONSTANT method), obtaining it from the database parameter table (DB_PARAM method), obtaining it from the request header (HEADER method), and obtaining it from the request body (BODY method). It should be noted that the key source is not limited to the above methods, and this disclosure does not limit it.

[0055] After obtaining the key, the system uses the key to calculate the expected signature value based on the signature algorithm corresponding to the target signature verification strategy. Then, according to the signature location configuration (signLocation) in the signature verification rules, the system extracts the actual signature value from a specified field in the request header or request body, compares the expected signature value with the actual signature value, and obtains the verification result.

[0056] To achieve differentiated processing through configuration of signature prefix templates and variable sources, avoiding the need to write independent signature logic for each platform, a preferred embodiment of this invention includes a signature prefix template and template variable definitions in the signature verification rules. After obtaining the string to be signed, the method further includes: parsing the placeholders in the signature prefix template, obtaining corresponding variable values ​​from the request header, request body, or the string to be signed according to the template variable definitions; replacing the placeholders in the signature prefix template with the obtained variable values ​​to obtain the final string to be signed; wherein, calculating the string to be signed using the key includes: calculating the final string to be signed using the key.

[0057] When the signature verification rule also includes a signature prefix template (preSignTemplate) and template variable definitions (preSignVariables), the system further performs template expansion after obtaining the string to be signed. The system parses the placeholders in the signature prefix template (such as "{timestamp}", "{nonce}", "{signing_string}", etc.), and according to the source configuration of each variable in the template variable definition (such as from the request header HEADER, from the request body BODY, or referencing the already constructed string to be signed CONSTRUCTED), retrieves the corresponding variable value from the callback processing context, and then replaces the placeholder with the actual variable value to obtain the expanded final string to be signed. For example, the signature prefix template "{timestamp}\n{nonce}\n{signing_string}\n" can be expanded to "1712345678\nabc123\namount=100&merchant_no=M001&out_trade_no=T20260401\n". With this template mechanism, even if different platforms use the same signature algorithm but have different data arrangement methods before signing, they can be adapted simply by modifying the configuration of the signature prefix template and variable source, without writing new code.

[0058] To more clearly illustrate the construction of the string to be signed, the expansion of the signature prefix template, and the specific implementation of the complete signature verification process described above, an example of the relevant core algorithms is shown below: Algorithm 5: buildSigningString(parsedData, signatureRule) — Constructs the string to be signed. Input: parsedData (parsed message data), signatureRule (signature verification rule) Output: The string to be signed (signingString) 1. sortedMap ← Creates a new sorted Map (TreeMap, sorted in ascending order by key) 2. FOR EACH (key, value) IN parsedData DO 3. / / Skip null values 4. If the value is null or an empty string THEN, skip the END IF statement. 5. / / Exclude fields that do not need to participate in the signing (such as "sign" itself) 6. IF key IN signatureRule.excludeFields THEN skip END IF 7. / / If a whitelist of participating fields is specified, only the fields in the list will be retained. 8. IF signatureRule.participatingFields is not empty THEN 9. IF key NOT IN signatureRule.participatingFields 10. THEN (Skip END IF) 11. END IF 12. effectiveKey ← signatureRule.caseSensitive ? key :key.toLowerCase() 13. sortedMap[effectiveKey] ← value.toString() 14. END FOR 15. / / Connect according to the configured splicing method 16. signingString ← "" 17. FOR EACH (key, value) IN sortedMap DO 18. IF signingString non-empty THEN signingString += "&" 19. IF concatMethod == "KV_EQUALS_AMPERSAND" THEN 20. signingString += key + "=" + value / / "a=1&b=2&c=3" 21. ELSE IF concatMethod == "VALUE_ONLY" THEN 22. signingString += value / / "1&2&3" 23. END IF 24. END FOR 25. RETURN signingString Algorithm 6: expandPreSignTemplate(rule, context, signingString) — Signature prefix expansion Input: rule (signature verification rule), context (callback context), signingString (constructed signature string) Output: The final string to be signed after expanding the variables. 1. template ← rule.preSignTemplate 2. / / Example: "{timestamp}\n{nonce}\n{signing_string}\n" 3. IF template is empty OR rule.preSignVariables is empty THEN 4. RETURN signingString / / No prefix template, uses the original signature string directly. 5. END IF 6. FOR EACH (varName, varDef) IN rule.preSignVariables DO 7. placeholder ← "{" + varName + "}" / / such as "{timestamp}" 8. value ← resolveVariable(varDef, context, signingString) 9. template ← template.replace(placeholder, value) 10. END FOR 11. RETURN template Function: resolveVariable(varDef, context, signingString) — resolves a single variable. 1. SWITCH varDef.source 2. CASE "HEADER": 3. / / Retrieve from the request header, such as context.headers["X-Timestamp"] 4. RETURN context.headers[varDef.field] or an empty string 5. CASE "BODY": 6. / / Retrieved from the request body, such as parsedData["merchant_no"] 7. RETURN parsedData.getString(varDef.field) or an empty string 8. CASE "CONSTRUCTED": 9. / / Referencing the already constructed signature string itself 10. RETURN signingString 11. DEFAULT: 12. RETURN (empty string) 13. End Switch Function: resolveKey(rule, context) — Resolves the signature verification key. 1. SWITCH rule.keyLocation 2. CASE "CONSTANT": RETURN rule.keyValue / / The key directly entered in the configuration. 3. CASE "DB_PARAM": RETURN configManager.get(rule.keyParamCode) / / Retrieves the key from the database parameter table 4. CASE "HEADER": RETURN context.headers[rule.keyParamCode] / / From request headers 5. CASE "BODY": RETURN parsedData[rule.keyParamCode] / / From the request body 6. End Switch Algorithm 7: Complete Signature Verification Process (using HMAC_SHA256 as an example) 1. signingString ← buildSigningString(parsedData, rule) 2. / / Result: "amount=100&merchant_no=M001&out_trade_no=T20260401" 3. 4. signingString ← expandPreSignTemplate(rule, context,signingString) 5. / / Result as follows: "1712345678\nabc123\namount=100&merchant_no=M001&out_trade_no=T20260401\n" 6. / / Where {timestamp} is replaced with the value of the X-Timestamp header. 7. / / Where {nonce} is replaced with the value of the X-Nonce header. 8. / / Where {signing_string} is replaced with the result of step 1. 9. 10. secretKey ← resolveKey(rule, context) 11. expectedSign ← HMAC_SHA256(signingString, secretKey).toUpperCase() 12. 13. / / Retrieve the actual signature from the corresponding location based on signLocation 14. IF signLocation == "HEADER" THEN 15. actualSign ← context.headers[signField] 16. ELSE 17. actualSign ← parsedData[signField] 18. END IF 19. 20. RETURN expectedSign == actualSign Algorithm 5 describes the construction process of the string to be signed: First, fields participating in the signing are filtered from the parsed message data, excluding null values ​​and fields specified in the configuration, and whether to retain whitelisted fields is determined according to the configuration; then, the fields are concatenated into a string according to the specified sorting method (such as ascending field name) and concatenation method (such as "key=value&key=value" format) to obtain the string to be signed. Algorithm 6 describes the expansion process of the signature prefix template: When the signature verification rule includes a signature prefix template, the placeholders in the template are traversed, and the corresponding variable values ​​are obtained from the request header, request body, or the constructed string to be signed according to the variable source configuration and replaced to obtain the final string used for signature calculation. Algorithm 7, taking the HMAC-SHA256 algorithm as an example, demonstrates the complete signature verification process from the construction of the string to be signed, template expansion, key acquisition, to the calculation of the expected signature value and comparison with the actual signature value.

[0059] The aforementioned signature prefix template mechanism decouples the data arrangement logic before signing from the program code, achieving differentiated processing through template definitions in the configuration information. For example, if two third-party platforms both use the HMAC-SHA256 signature algorithm, but one platform requires appending a timestamp and a random string separated by newlines before the string to be signed, while the other platform only requires appending a timestamp and a random number, the traditional approach would require writing independent signature concatenation code for each platform. However, in this invention, only the signature prefix template configuration in the signature verification rules needs to be modified to adapt to the signature arrangement requirements of different platforms, without writing new program code, significantly reducing the development and maintenance costs of multi-channel access.

[0060] To enable the unified mapping of heterogeneous messages from different platforms to a standardized data model, a preferred embodiment of the present invention includes the following data mapping processing: extracting field values ​​to be mapped from the structured data according to the field extraction path configured in the data mapping rules, wherein the field extraction path supports nested path access; when the field value to be mapped is an amount field, performing unit conversion on the field value to be mapped according to the scaling factor and scaling mode configured in the data mapping rules; when the field value to be mapped is a transaction status field, converting the field value to be mapped into a preset standard status value according to the status mapping table configured in the data mapping rules; and generating the standard payment data based on the converted field values.

[0061] This invention extracts fields from parsed data and maps them to standard payment data using data mapping rules. Specifically, the system extracts target field values ​​one by one from the parsed structured data according to the field mapping relationships configured in the data mapping rules. Each field mapping relationship specifies the field extraction path (using a JSONPath expression, such as "$.out_trade_no" indicating extraction of the out_trade_no field under the root object, and "$.attach.meter_id" indicating extraction of the meter_id field in the nested object attach), the field type, and optional conversion rules.

[0062] It should be noted that the expression syntax for extracting the path in this field can use JSONPath or other structured query syntax. This embodiment of the disclosure does not limit this, and the JSONPath expression is used as an example for explanation here.

[0063] For the amount field, the system performs unit conversion on the extracted raw amount value according to the scaling factor and scaling mode configured in the data mapping rules. For example, when a third-party platform transmits the amount in yuan, if the scaling factor is configured to 100 and the scaling mode is multiplied (MULTIPLY), the system will multiply the raw amount value by 100 to convert it into an amount value in fen (cents). It should be noted that the specific values ​​and methods of the scaling factor and scaling mode can be flexibly configured according to the amount unit of different platforms. This embodiment of the disclosure does not limit this; the example here uses a scaling factor of 100 and a multiplied mode for illustration.

[0064] For the transaction status field, the system converts various status values ​​returned by third-party platforms into standard status values ​​preset by the system, based on the status mapping table configured in the data mapping rules. For example, "TRADE_SUCCESS" and "PAID" are both mapped to "SUCCESS", and "FAILED" is mapped to "FAIL".

[0065] After extracting and transforming all fields, the system generates standard payment data (i.e., standard payment model) based on the values ​​of each field, which includes fields such as internal order number (outTradeNo), amount (in cents), device identifier (meterId), transaction status (status), purchase method (buyType), third-party order number (thirdPartyOrderNo), and remark.

[0066] To ensure the security of business processing, prevent data loss, and automatically recover from processing failures caused by temporary faults, thereby improving the system's fault tolerance and processing reliability, a preferred embodiment of the present invention performs business processing based on the standard payment data, including: when the transaction status in the standard payment data is successful and the signature verification processing status is passed, calling the business processing interface to perform a recharge operation; when the recharge operation fails, persisting the original data of the callback notification request to a retry record table for retry processing.

[0067] In one embodiment, the method further includes: periodically scanning the retry record table through a timed task to obtain target retry records that are in a pending retry state and have reached a preset retry time; and re-sending the original data corresponding to the target retry record into the processing flow for processing, wherein the maximum number of retry attempts and the retry interval for each payment channel are configured independently through the channel configuration information.

[0068] In practice, the system first checks whether the transaction status in the standard payment data is successful and whether the signature verification processing status is passed. When both conditions are met, the system calls the business processing interface to execute the recharge operation and sends the recharge fee to the corresponding device account.

[0069] When a recharge operation fails (e.g., due to network anomalies, temporary service unavailability), the system serializes and persists the original request header and body of the callback notification request to a retry record table (e.g., named pay_notify_retry_record). The retry record contains information such as the retry status (initially pending retry), the number of retries already attempted, the maximum allowed number of retries, and the next retry time. The system periodically scans the retry record table using a scheduled task (e.g., named NotifyRetryTask) (e.g., every 60 seconds) to obtain target retry records that are pending retry and have reached the preset retry time, and re-enters their corresponding raw data into the processing flow. When a retry succeeds, the record status is updated to successful; when the maximum number of retries is reached and the retry attempt still fails, the record status is updated to exhausted, and no further retries are made. The maximum number of retries and the retry interval for each payment channel can be configured independently through the channel configuration information.

[0070] The scanning interval of the scheduled task can be flexibly adjusted according to actual business needs. This embodiment does not limit this, but 60 seconds is used as an example for explanation.

[0071] In one implementation, when assembling a response message based on a response template and returning it to a third-party platform, the system generates a response message that meets the requirements of the third-party platform based on the response template in the channel configuration information. The response template defines the response content for both successful and failed processing scenarios, including the content type (e.g., application / json, application / xml, or text / plain), the response body, and the HTTP status code (httpStatus). The system selects the corresponding template and assembles the response based on the current processing result. For example, a channel's successful response template is configured with the content type application / json, the response body {"code":"000000","message":"OK"}, and the HTTP status code 200; the failed response template is configured with the response body {"code":"999999","message":"FAIL"}. Different third-party platforms have different format requirements for response messages. For example, some platforms require the return of responses in markup language format (such as XML documents containing return_code SUCCESS), while others require the return of plain text "success". These differences can be adapted by configuring the response template.

[0072] The following two example application scenarios illustrate the actual usage of this method.

[0073] For example, when integrating a new payment channel, administrators configure the channel information in the management interface, filling in the channel identifier (e.g., "STARPAY"), channel name (e.g., "StarPay Payment Gateway"), message format (JSON), and custom callback path (e.g., " / callback / starpay / notify"). Then, they configure signature verification rules, selecting the HMAC-SHA256 algorithm, specifying the signature value in a designated field of the request header, configuring the key as a fixed value, excluding the signature value field from signature calculation, sorting by field name in ascending order, and configuring the signature prefix template as "{timestamp}\n{nonce}\n{signing_string}\n". Next, they configure data mapping rules, mapping the third-party platform's order number field to the system's internal order number, multiplying the amount field by 100 to convert it to cents, and extracting the device identifier from nested objects. Finally, they configure response templates, defining success and failure response formats respectively. After saving the configuration, the system automatically registers the callback endpoint on the configured custom callback path. Administrators then notify the third-party platform of this path, completing the integration. The entire process requires no coding and no application redeployment.

[0074] For example, administrators can also view all registered callback endpoints in the current system through the endpoint query interface. Administrators access the preset endpoint query path (e.g., " / api / payment / notify / config / endpoints"), and the system returns all registered dynamic endpoints and their corresponding channel identifiers. An example of the returned results is shown below: { " / callback / starpay / notify": "STARPAY", " / api / payment / notify / TEST_NO_SIGN": "TEST_NO_SIGN", " / callback / wechatpay / v2": "WECHAT_V2" } This allows administrators to confirm whether the callback endpoints for each payment channel have been correctly registered and to configure the corresponding endpoint paths in the backend of the relevant third-party platform. This endpoint query function provides supporting management and maintenance tools for dynamic endpoint registration.

[0075] The present invention also provides a payment callback processing device, such as... Figure 4 As shown, it includes: The registration module 401 is used to dynamically register corresponding callback endpoints for multiple payment channels based on preset channel configuration information. The channel configuration information includes message parsing rules, signature verification rules, data mapping rules, and response templates corresponding to the payment channel. Processing module 402 is used to respond to the callback notification request received through the callback endpoint, and perform message parsing, signature verification and data mapping processing on the callback notification request in sequence according to the channel configuration information corresponding to the callback endpoint to obtain standard payment data; Business module 403 is used to perform business processing based on the standard payment data and generate a response message based on the response template to return to the third-party platform that sent the callback notification request.

[0076] In one implementation, when the registration module 401 dynamically registers corresponding callback endpoints for multiple payment channels based on preset channel configuration information, it specifically performs the following steps: loading multiple channel configuration information that are in an enabled state from persistent storage; determining a corresponding callback path for each channel configuration information, wherein when the channel configuration information contains a custom path, the custom path is used as the callback path, and when the channel configuration information does not contain a custom path, the callback path is generated by concatenating a preset prefix with the channel identifier of the payment channel; and dynamically registering the callback endpoints using a routing registration component based on the callback paths.

[0077] In one implementation, when performing message parsing, the processing module 402 is specifically used to: determine the parsing mode corresponding to the callback notification request according to the message format identifier specified in the message parsing rules, wherein the parsing mode includes a structured text parsing mode, a markup language parsing mode, and a form parsing mode; and based on the determined parsing mode, parse the request body of the callback notification request to obtain structured data.

[0078] In one embodiment, during signature verification processing, the processing module 402 performs the following steps: selecting a target signature verification strategy corresponding to the algorithm identifier from multiple preset signature verification strategies based on the algorithm identifier in the signature verification rules; performing signature verification on the structured data based on the target signature verification strategy to obtain a verification result; and marking the processing status as failed when the verification result is a verification failure, and continuing to execute subsequent processing steps.

[0079] In one implementation, when processing module 402 performs signature verification on the structured data based on the target signature verification strategy, it specifically performs the following steps: First, it filters target fields for signature participation from the structured data according to the participating field information and excluded field information configured in the signature verification rules. Second, it sorts and concatenates multiple target fields according to the sorting and concatenation methods configured in the signature verification rules to obtain a string to be signed. Third, it obtains a key according to the key source information configured in the signature verification rules, calculates the string to be signed using the key based on the signature algorithm corresponding to the target signature verification strategy, and obtains the expected signature value. Fourth, it compares the expected signature value with the actual signature value carried in the callback notification request to obtain the verification result.

[0080] In one implementation, the signature verification rule further includes a signature prefix template and template variable definitions; after obtaining the string to be signed, the processing module 402 is further configured to: parse the placeholders in the signature prefix template, and obtain the corresponding variable values ​​from the request header, request body, or the string to be signed according to the template variable definitions; replace the placeholders in the signature prefix template with the obtained variable values ​​to obtain the final string to be signed; wherein, when the processing module 402 calculates the string to be signed using the key, it is specifically configured to: calculate the final string to be signed using the key.

[0081] In one embodiment, when performing data mapping processing, the processing module 402 is specifically used to: extract the field values ​​to be mapped from the structured data according to the field extraction path configured in the data mapping rules, wherein the field extraction path supports nested path access; when the field value to be mapped is an amount field, perform unit conversion on the field value to be mapped according to the scaling factor and scaling mode configured in the data mapping rules; when the field value to be mapped is a transaction status field, convert the field value to be mapped into a preset standard status value according to the status mapping table configured in the data mapping rules; and generate the standard payment data based on the converted field values.

[0082] In one implementation, when the business module 403 performs business processing based on the standard payment data, it is specifically used to: when the transaction status in the standard payment data is a successful status and the processing status of the signature verification processing is passed, call the business processing interface to perform a recharge operation; when the recharge operation fails, persist the original data of the callback notification request to the retry record table for retry processing.

[0083] Figure 4The payment callback processing device in the illustrated embodiment can be used to execute the technical solution of the above method embodiment. Its implementation principle and technical effect are similar, and will not be repeated here.

[0084] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. The electronic device provided in this embodiment can execute the processing flow provided in the payment callback processing method embodiment, such as... Figure 5 As shown, the electronic device 1100 includes: a memory 1101, a processor 1102, a computer program, and a communication interface 1103; wherein the computer program is stored in the memory 1101 and is configured to be executed by the processor 1102 as described above in the payment callback processing method.

[0085] In addition, embodiments of the present invention also provide a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the payment callback processing method described in the above embodiments.

[0086] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus 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 apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0087] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A payment callback processing method, characterized by, include: Based on preset channel configuration information, corresponding callback endpoints are dynamically registered for multiple payment channels. The channel configuration information includes message parsing rules, signature verification rules, data mapping rules, and response templates corresponding to the payment channels. In response to the callback notification request received through the callback endpoint, the callback notification request is processed sequentially by message parsing, signature verification and data mapping according to the channel configuration information corresponding to the callback endpoint to obtain standard payment data. The business process is executed based on the standard payment data, and a response message is generated based on the response template and returned to the third-party platform that sent the callback notification request.

2. The payment callback processing method of claim 1, wherein, Based on preset channel configuration information, corresponding callback endpoints are dynamically registered for multiple payment channels, including: Load configuration information for multiple channels that are enabled from persistent storage; For each channel configuration information, a corresponding callback path is determined. When the channel configuration information contains a custom path, the custom path is used as the callback path. When the channel configuration information does not contain a custom path, the callback path is generated by concatenating a preset prefix with the channel identifier of the payment channel. Based on the callback path, the callback endpoint is dynamically registered using the route registration component.

3. The payment callback processing method of claim 1, wherein, The message parsing process includes: Based on the message format identifier specified in the message parsing rules, the parsing mode corresponding to the callback notification request is determined, wherein the parsing mode includes structured text parsing mode, markup language parsing mode and form parsing mode; Based on the determined parsing pattern, the request body of the callback notification request is parsed to obtain structured data.

4. The payment callback processing method of claim 3, wherein, The signature verification process includes: Based on the algorithm identifier in the signature verification rule, select the target signature verification strategy corresponding to the algorithm identifier from multiple preset signature verification strategies; Based on the target signature verification strategy, the structured data is subjected to signature verification to obtain the verification result; When the verification result is a verification failure, the processing status is marked as failed, and subsequent processing steps continue to be executed.

5. The payment callback processing method according to claim 4, characterized in that, Based on the target signature verification strategy, the structured data is subjected to signature verification, including: Based on the participating field information and exclusion field information configured in the signature verification rules, target fields for participating in the signature are filtered from the structured data; According to the sorting and concatenation methods configured in the signature verification rules, multiple target fields are sorted and concatenated to obtain the string to be signed; The key is obtained according to the key source information configured in the signature verification rule. Based on the signature algorithm corresponding to the target signature verification strategy, the key is used to calculate the string to be signed to obtain the expected signature value. The expected signature value is compared with the actual signature value carried in the callback notification request to obtain the verification result.

6. The payment callback processing method of claim 5, wherein, The signature verification rules also include signature prefix templates and template variable definitions; After obtaining the string to be signed, the method further includes: Parse the placeholders in the signature prefix template, and obtain the corresponding variable values ​​from the request header, request body, or the string to be signed in the callback notification request according to the template variable definition; Replace the placeholders in the signature prefix template with the obtained variable values ​​to obtain the final string to be signed; The calculation of the string to be signed using the key includes: calculating the final string to be signed using the key.

7. The payment callback processing method of claim 3, wherein, The data mapping process includes: According to the field extraction path configured in the data mapping rule, the field values ​​to be mapped are extracted from the structured data, wherein the field extraction path supports nested path access; When the value of the field to be mapped is an amount field, the value of the field to be mapped is converted to a unit according to the scaling factor and scaling mode configured in the data mapping rule; When the value of the field to be mapped is a transaction status field, the value of the field to be mapped is converted into a preset standard status value according to the status mapping table configured in the data mapping rules. The standard payment data is generated based on the converted field values.

8. The method of claim 1, wherein, Perform business processing based on the standard payment data, including: When the transaction status in the standard payment data is successful and the signature verification processing status is passed, the business processing interface is called to perform the recharge operation. When the recharge operation fails, the original data of the callback notification request is persisted to the retry record table for retry processing.

9. A payment callback processing apparatus characterized by comprising: include: The registration module is used to dynamically register corresponding callback endpoints for multiple payment channels based on preset channel configuration information. The channel configuration information includes message parsing rules, signature verification rules, data mapping rules, and response templates corresponding to the payment channel. The processing module is used to respond to the callback notification request received through the callback endpoint, and perform message parsing, signature verification and data mapping processing on the callback notification request in sequence according to the channel configuration information corresponding to the callback endpoint to obtain standard payment data. The business module is used to perform business processing based on the standard payment data and generate a response message based on the response template to return to the third-party platform that sent the callback notification request.

10. An electronic device, comprising: It includes a memory and a processor, wherein the memory stores a computer program that, when executed by the processor, implements the method as described in any one of claims 1-8.

11. A computer readable storage medium, characterized in that, It stores program instructions that, when executed, implement the method as described in any one of claims 1-8.

Images