Right and interest registration method and device based on payment behavior, equipment and storage medium

Abstract

According to the right registration method and device based on the payment behavior, the equipment and the storage medium provided by the invention, the payment completion information is received, the key data is automatically extracted, then the deserved right and interests are intelligently matched and calculated based on the preset right and interests rule base, and finally the right and interests information is automatically registered to the corresponding personal account. And a set of complete automatic process of payment and registration is realized. The method effectively overcomes the defects of cumbersome right and interest receiving and separation of payment and right and interest in the prior art, and has the main beneficial effects that firstly, non-sensitization and automation of right and interest obtaining are realized, a user silently completes right and interest registration while completing payment, and the convenience of operation and the fluency of user experience are greatly improved; and secondly, payment behaviors and right rules are automatically associated through the system, so that the right issuing accuracy and timeliness are ensured, and omission or errors possibly caused by manual operation are reduced.

Description

Technical Field

[0001] This invention relates to the field of electronic payment technology, and in particular to a method, apparatus, device, and storage medium for registering rights based on payment behavior. Background Technology

[0002] In the current digital payment and benefits ecosystem, users often receive various forms of rewards such as points, coupons, and red envelopes after completing transactions through identity-based payment tools (such as social security cards and membership cards). However, existing technologies generally suffer from the following pain points: payment systems and benefits management systems are usually independent, and benefits distribution rules are scattered across various partner merchants or third-party platforms. This leads to a severe disconnect between users' payment behavior and the benefits acquisition process. Benefit registration often requires users to manually apply for or redeem benefits on multiple platforms, a cumbersome process with a fragmented user experience. Furthermore, due to the lack of automated linkage mechanisms, the accuracy and timeliness of benefits distribution are difficult to guarantee, and users are also prone to forgetting or missing out on benefits they have already obtained, thereby reducing the overall efficiency of benefits usage and user satisfaction.

[0003] In summary, the problems existing in the current technology urgently need to be solved. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and storage medium for rights registration based on payment behavior, which addresses the deficiencies in the prior art and ensures the accuracy and timeliness of rights issuance.

[0005] This invention provides a method for registering rights based on payment behavior, comprising: Receive payment completion information from the payment system, which is associated with a transaction completed by the user through an identity verification payment tool; Extract user identifier and transaction feature data from the payment completion information; Based on the transaction feature data and the preset rights and interests rule base, the rights and interests information corresponding to this transaction is matched and calculated; The calculated rights and interests information will be registered in the personal rights and interests account that is bound to the user identifier.

[0006] According to a payment behavior-based rights registration method provided by the present invention, after the step of registering the calculated rights information to the personal rights account bound to the user identifier, the method further includes: In response to a query request, an interactive interface is provided to uniformly display the rights and interests information under the aforementioned personal rights and interests account.

[0007] According to a payment behavior-based rights registration method provided by the present invention, after the step of registering the calculated rights information to the personal rights account bound to the user identifier, the method further includes: Monitor the status of various rights in the personal rights account, and automatically initiate prompts for specific rights based on preset trigger conditions and user preferences.

[0008] According to the payment behavior-based rights registration method provided by the present invention, the preset triggering condition includes a rights validity period threshold, and the rights validity period threshold is determined based on the user's historical usage rate of similar rights.

[0009] According to the present invention, a method for registering rights based on payment behavior, the step of matching and calculating the rights information corresponding to this transaction based on the transaction feature data and a preset rights rule base specifically includes: Based on the merchant identifier in the transaction feature data, match one or more corresponding rights calculation rules from the rights rule base; Based on the matched rights calculation rules, the corresponding third-party rights service is called through a preset adaptation interface to obtain the rights information.

[0010] According to the payment behavior-based rights registration method provided by the present invention, the step of obtaining the rights information by calling the corresponding third-party rights service through a preset adaptation interface according to the matched rights calculation rules specifically includes: If the matched rule type is a local calculation rule, the equity information is generated directly based on the rule logic and the transaction feature data; If the matched rule type is an external call rule, a query is initiated to the specified third-party rights platform through the adaptation interface, and the data returned by the platform is parsed and validated to obtain the rights information.

[0011] According to a payment behavior-based rights registration method provided by the present invention, before the step of registering the calculated rights information to the personal rights account bound to the user identifier, the method further includes: Verify the validity of the rights information. The validity verification includes checking at least one of the following: whether the rights are within the validity period, whether the rights type is supported by the personal rights account, and whether the current rights issuance conflicts with existing rights rules.

[0012] The present invention also provides a rights registration device based on payment behavior, comprising: The information receiving module is used to receive payment completion information from the payment system, which is associated with the transaction completed by the user through the identity recognition payment tool; The information extraction module is used to extract user identifier and transaction feature data from the payment completion information; The rule matching module is used to match and calculate the equity information corresponding to this transaction based on the transaction feature data and the preset equity rule base. The information registration module is used to register the calculated rights information into the personal rights account bound to the user identifier.

[0013] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the rights registration method based on payment behavior as described above.

[0014] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the rights registration method based on payment behavior as described above.

[0015] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the rights registration method based on payment behavior as described above.

[0016] This invention provides a payment-based rights registration method, apparatus, device, and storage medium. By receiving payment completion information and automatically extracting key data, it intelligently matches and calculates the entitlement rights based on a preset rights rule base, ultimately automatically registering the rights information to the corresponding personal account, thus realizing a complete automated "payment-as-registration" process. This method effectively overcomes the shortcomings of existing technologies, such as cumbersome rights acquisition and the separation of payment and rights. Its beneficial effects are mainly reflected in the following aspects: First, it achieves seamless and automated rights acquisition, allowing users to silently complete rights registration while completing payment, greatly improving the convenience of operation and the smoothness of user experience; second, by automatically associating payment behavior with rights rules, it ensures the accuracy and timeliness of rights issuance, reducing omissions or errors that may be caused by human operation; finally, this method lays a reliable data foundation for the unified management, intelligent reminders, and efficient use of subsequent rights, helping to improve the overall operational efficiency and user stickiness of the rights system. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating the rights registration method based on payment behavior provided by the present invention; Figure 2 This is a schematic diagram of the structure of the rights registration device based on payment behavior provided by the present invention; Figure 3 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0020] To address the problems in existing technologies, this invention proposes a rights registration method based on payment behavior to ensure the accuracy and timeliness of rights issuance. The following describes this rights registration method based on payment behavior, as follows: Figure 1 As shown, including but not limited to the following steps: Step 110: Receive payment completion information from the payment system, which is associated with a transaction completed by the user through an identity verification payment tool.

[0021] In step 110, after a user successfully completes a transaction using an identity verification payment tool (such as a social security card, bank card, payment code of a mobile payment application, digital identity certificate, etc.), the payment system generates a payment completion message in real time or near real time. This message is typically sent to the rights registration system in which this method is implemented, in the form of a structured data message, through asynchronous communication mechanisms such as application programming interfaces (APIs), message queues (such as Kafka, RocketMQ), or event buses.

[0022] The payment completion information shall include at least the following key fields: User identifier: Used to uniquely identify a user's identity information, such as user ID, encrypted ID card number, mobile phone number, OpenID of a third-party platform, etc.

[0023] Transaction identifier: such as a unique order number or transaction serial number generated by the payment system, used for subsequent tracking and reconciliation.

[0024] Transaction characteristic data: describes the specific attributes of this transaction, typically including: Merchant identification: such as merchant ID, store number.

[0025] Transaction amount: The total amount paid.

[0026] Transaction time: The precise timestamp of when the payment occurred.

[0027] Product / service information: Optional product code, category, or name.

[0028] Payment channels: such as POS machines, QR code payments, online gateways, etc.

[0029] Payment status: Indicates that the transaction has been successfully completed.

[0030] Upon receiving the information, the system first performs basic validity checks, such as data format checks, signature verification (if the information is signed), or decryption operations (if the information is encrypted), to ensure the authenticity and integrity of the information. Step 120: Extract user identifier and transaction feature data from the payment completion information.

[0031] In step 120, after verifying the validity of the payment completion information, the system parses and extracts two core data elements required for subsequent calculations: User ID: It is directly extracted and used as the primary key for the associated user's rights account.

[0032] Transaction feature data: Structured fields such as merchant identifier, transaction amount, transaction time, and product category are extracted from the message. This feature data is the core basis for determining what benefits a user can obtain and how many benefits they can obtain.

[0033] The extraction process may involve data cleaning and format standardization, such as unifying the time format from different payment channels to ISO standard time, or mapping product classification codes to the system's internal standard classification system to ensure the accuracy of subsequent rule matching.

[0034] Step 130: Based on the transaction feature data and the preset rights and interests rule base, match and calculate the rights and interests information corresponding to this transaction.

[0035] In step 130, the system maintains a preset rights and benefits rule base. This rule base stores the triggering conditions and calculation logic for various rights and benefits distributions, and its rules can be configured, for example: Rule format: "If a merchant is a Class A partner and the transaction amount is over 100 yuan, 10 points will be awarded."

[0036] The rules may come from various sources, including general points rules of the system platform, exclusive promotional rules for specific merchants, and joint rules agreed upon with third-party rights platforms (such as banks and brands).

[0037] The matching and calculation process is as follows: Rule matching: The system uses extracted transaction feature data (especially merchant ID, product category, and transaction amount) as input conditions to search and match in the rights and interests rule base. The matching algorithm may include exact matching (such as merchant IDs being exactly the same), conditional matching (such as the amount being greater than a certain threshold), and priority judgment (when multiple rules match at the same time, the one with the highest priority or the most specific one is selected).

[0038] Stake Calculation: Based on the specific rules matched, execute the stake calculation logic defined therein. For example: If the rule is to award points proportionally, then the calculation is: Number of benefits = Transaction amount × Points ratio.

[0039] If the rule is to issue coupons with a fixed face value, then an electronic coupon of the specified type will be generated directly.

[0040] If the rule requires calling external services (such as third-party platforms to verify user qualifications), a query is initiated through a predefined adapter interface, and the returned result is used as the rights and interests information.

[0041] Generate rights and benefits information: Finally, a structured rights and benefits information object is generated, which typically includes: rights and benefits type (such as points, coupons, discount eligibility), number or face value of rights and benefits, start and end dates of validity, source rule ID or activity ID, etc.

[0042] Step 140: Register the calculated rights and interests information into the personal rights and interests account bound to the user identifier.

[0043] In step 140, the system retrieves or creates a corresponding personal rights account in the rights account database based on the extracted user identifier. This account is the user's unique overview of rights in the rights system and may exist in the form of database table records or documents.

[0044] The rights and interests information calculated in step 130 is written to the individual's rights and interests account as a new detailed record. The registration operation is typically a database transaction to ensure data consistency. The registered information includes at least the details of the rights and interests obtained this time and is linked to the original payment transaction identifier to achieve end-to-end traceability.

[0045] Based on the registered type of benefits, the summary information in the individual benefits account is updated synchronously. For example, if points are received, the total points balance is increased; if coupons are received, a new record is added to the available coupons list.

[0046] At this point, a complete closed-loop process of "payment-automatic registration of rights" has been completed. Users do not need to take any additional action; their due rights have been accurately and automatically recorded in their names.

[0047] Through the aforementioned automated steps, this invention efficiently and accurately connects discrete payment behaviors with decentralized rights management, greatly improving user experience and operational efficiency.

[0048] It should be noted that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0049] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0050] As a further optional embodiment, after the step of registering the calculated rights information to the personal rights account bound to the user identifier, the method further includes: In response to a query request, an interactive interface is provided to uniformly display the rights and interests information under the aforementioned personal rights and interests account.

[0051] In this embodiment, after step 140, "registering the calculated rights information into the personal rights account bound to the user identifier," the method further includes: responding to a query request by providing an interactive interface for uniformly displaying the rights information under the personal rights account. This step aims to solve the problem of scattered user rights information and inconvenient querying. The specific implementation process is as follows: Users initiate queries for their personal rights information through front-end applications (such as government service apps, social security card partner mini-programs, dedicated web portals, etc.). These requests include the user's authentication token or a securely processed user identifier to verify query permissions.

[0052] After verifying the legitimacy of the request, the system backend accesses the rights and interests account database based on the user identifier in the request, and retrieves the personal rights and interests account bound to that user identifier. From this account, the system extracts summary information and a detailed list of all rights and interests records. This data has been standardized and centrally managed through the aforementioned steps.

[0053] The system organizes and encapsulates the acquired rights and benefits data, and returns the data to the front-end for rendering. The front-end application then generates a unified interactive interface that centrally displays all of the user's rights and benefits information in a visual and structured manner. Typical display content includes: Benefits Overview: such as total points balance, number of available coupons, total amount or quantity of various benefits.

[0054] Detailed list of benefits: Each item includes the type of benefit (e.g., "General Points", "Merchant A Discount Coupon", "Partner Platform Member Day Discount"), quantity / value of benefits, acquisition time, expiry date, usage status (e.g., "Unused", "Used", "Expired"), and source (e.g., "Gift for Shopping", "Obtained by Participating in Activities").

[0055] Intelligent organization and prompts: The interface can intelligently group or sort benefits according to preset rules (e.g., by benefit type, by partner platform) or sort them (e.g., by proximity to expiration). For benefits nearing their expiration date (e.g., expiring within the next 3 days), the interface can provide prominent visual prompts, such as highlighting, adding a "Expiring Soon" label, or pinning the benefit to the top.

[0056] As a further optional embodiment, after the step of registering the calculated rights information to the personal rights account bound to the user identifier, the method further includes: Monitor the status of various rights in the personal rights account, and automatically initiate prompts for specific rights based on preset trigger conditions and user preferences.

[0057] This embodiment aims to address the issue of benefits silently expiring due to user forgetfulness, and improves benefit usage and user experience through proactive and intelligent services. Its implementation process constitutes an independent backend service workflow, as detailed below: The system establishes a background monitoring service, which runs either as a periodic scheduled task (such as executing at midnight every day) or as an event-based listener (listening for rights registration and status update events). Its core task is to continuously or periodically scan the rights details records in all individual rights accounts, checking the current status of each rights (especially the "unused" status) and its attributes.

[0058] The monitoring service evaluates each scanned benefit based on a pre-defined, configurable rule base of trigger conditions. The main trigger conditions include: Approaching expiration date: This is the most crucial condition. The system calculates the difference between the "expiration date" of the benefit and the current time. When this difference is less than or equal to a preset threshold, it is determined that a reminder condition has been triggered. For example, the rule can be set to "trigger a reminder 3 days or 1 day before the benefit expires."

[0059] Usage conditions met: Some benefits may have additional usage conditions, such as "available for purchases over 100 yuan". The system will combine the user's recent consumption intention data (such as the total amount of items in the shopping cart) or real-time transaction context to determine whether the benefit is about to be or has already met the usage conditions, and trigger a "best time to use" prompt accordingly.

[0060] Other business rules: such as benefits that will expire due to a decrease in user level, or related activities that are about to end.

[0061] To provide personalized prompts and avoid information overload, the system incorporates user preferences when determining trigger conditions. These preferences can be actively set by the user or intelligently inferred by the system through analysis of historical user behavior, including: Alert Channel Preferences: Users select the channels for receiving alerts, such as in-app messages, SMS, email, and mobile app push notifications.

[0062] Reminder time preference: Users can set time periods during which they do not want to receive reminders (such as at night).

[0063] Benefit type attention: Users can mark benefit types they are particularly interested in (such as large coupons), and the reminder threshold for such benefits can be brought forward or the reminder frequency can be increased.

[0064] Dynamic Threshold Adjustment (Creative Feature): As an optimization, the threshold in the "expiration date approaching" condition is not entirely fixed. The system can analyze the user's historical "timeliness of use" for similar benefits (i.e., the time interval characteristic from acquisition to use). For users who habitually use benefits close to their expiration date, the system may automatically shorten the reminder threshold (e.g., reminding them only 1 day before expiration); for users who habitually use benefits early or are prone to forgetting, the system may automatically extend the reminder threshold (e.g., sending multiple reminders 5 days, 3 days, and 1 day before expiration). This makes the reminder strategy more personalized and effective.

[0065] When a certain benefit meets the triggering conditions and aligns with user preferences, the monitoring service will automatically initiate a notification action: Information assembly: The system generates personalized prompts based on the type of rights, content, remaining validity period, recommended usage scenarios, etc.

[0066] Channel routing: Based on user preferences, the notification information is routed to the corresponding communication service module, such as SMS gateway, email server, and push platform.

[0067] Execution and Recording: Call the corresponding interface to send a reminder and record the reminder event in the database (such as reminder time, method, and benefit ID) for subsequent analysis and to avoid duplicate reminders.

[0068] Through this embodiment, the present invention achieves a leap from passive rights registration to proactive rights lifecycle management. It ensures that rights value can be more effectively delivered and reach users, significantly reduces the rights forgetting rate, and enhances user satisfaction and activity, thereby forming a virtuous cycle of "payment - obtaining rights - being reminded - using rights", enhancing the vitality and stickiness of the entire rights ecosystem.

[0069] As a further optional embodiment, the preset triggering condition includes a rights validity period threshold, and the rights validity period threshold is determined based on the user's historical usage rate of similar rights.

[0070] In this embodiment, the validity period threshold of the rights (i.e., the time point at which to determine whether the rights are "close to expiration" and trigger a reminder, such as "3 days before expiration") is not a globally unified static configuration of the system, but is determined based on the user's historical usage timeliness of similar rights.

[0071] The system maintains a historical profile of the user's benefits, recording information on all benefits they have previously acquired and completed (including used and expired) in the past. For each completed record, key fields include: benefit type (e.g., "supermarket discount coupon", "coffee voucher"), benefit acquisition time, benefit expiration time, and actual usage time of the benefit (if used).

[0072] For a specific type of benefit (i.e., "same type of benefit"), the system calculates the user's historical usage timeliness rate. This metric aims to quantify the user's active use of the benefit within its validity period. A feasible calculation formula is as follows: Timeliness = Number of valid historical uses / Total number of historical acquisitions Among them, "historical effective usage count" refers to the number of times the type of benefit was successfully used before its expiration, and "historical total acquisition count" refers to the total number of times a user has obtained the type of benefit. Another more refined algorithm can consider the usage time point, such as calculating the ratio of the average "early use period" (expiration time - usage time) to the average validity period of the benefit.

[0073] The system pre-defines a "timeliness rate - threshold" mapping table or adjustment function. Its core logic is: the more delayed a user's historical usage (lower timeliness rate), the earlier the system will intervene with reminders (increased threshold); the more timely a user's behavior (higher timeliness rate), the closer the system reminders will be to the due date (decreased threshold), thus avoiding unnecessary reminders.

[0074] Example: For benefits like "supermarket discount coupons", if user A's historical on-time usage rate is as high as 90% (almost always using them in advance), the system can set a small threshold for them, such as triggering a reminder only 1 day before the expiration date.

[0075] If user B's historical timely usage rate for similar coupons is only 30% (often forgetting to use them until they expire), the system will set a larger threshold for them, such as sending multiple reminders 5 days and 2 days before the expiration date.

[0076] When monitoring and determining the "expiration date is approaching" condition, the system first identifies the type of current benefit, then queries the user's historical usage rate of this type of benefit, and finally dynamically determines the specific threshold to be used for this reminder based on the preset mapping strategy, and then performs a time comparison.

[0077] This embodiment upgrades the unified reminder strategy into a personalized, adaptive intelligent reminder service by introducing dynamic threshold adjustments based on users' historical behavior data. It not only significantly improves the effective reach and final conversion rate of reminder information, reducing user neglect or resentment caused by untimely reminders, but also demonstrates the system's ability to provide proactive services through machine learning of user habits. This further strengthens the technical advantages of this invention in improving user experience and the efficiency of rights usage, enabling rights management to move from "standardized service" to "intelligent service."

[0078] As a further optional embodiment, the step of matching and calculating the equity information corresponding to this transaction based on the transaction feature data and the preset equity rule base specifically includes: Based on the merchant identifier in the transaction feature data, match one or more corresponding rights calculation rules from the rights rule base; Based on the matched rights calculation rules, the corresponding third-party rights service is called through a preset adaptation interface to obtain the rights information.

[0079] In this embodiment, based on the merchant identifier in the transaction feature data, one or more corresponding benefit calculation rules are matched from the benefit rule base. The system uses the merchant identifier (such as merchant ID, store code) extracted from the payment completion information as the primary key or core condition to query the preset benefit rule base. Each rule in the benefit rule base is associated with at least one or more merchant identifiers and defines how benefits should be calculated or obtained when a transaction occurs with these merchants. The rules contain key call pointing information, such as indicating which third-party platform the benefit corresponding to the rule originates from (such as "Bank A's points platform", "Brand B's coupon system"), and the specific service interface identifier to be called. After a successful match, the system will obtain one or more applicable benefit calculation rules. These rules themselves may not contain specific calculation logic, but rather instructions on "where to obtain" and "under what conditions to obtain".

[0080] Next, based on the matched rights calculation rules, the corresponding third-party rights service is called through a preset adaptation interface to obtain the rights information.

[0081] Since different third-party rights service platforms (hereinafter referred to as "third-party platforms") may have different interface protocols, data formats, and authentication methods, this invention shields this heterogeneity through a pre-set adaptation interface (i.e., an interface adapter). Each third-party platform that needs to be connected corresponds to an adapter module that has been pre-developed and configured in the system.

[0082] The system selects the corresponding adaptation interface based on the call information in the matched rules. Then, it encapsulates the user identifier and necessary transaction characteristic data (such as order amount and product information) into a specific request message according to the format and protocol required by the third-party platform. The request is sent to the third-party platform's service interface via a secure network channel (such as HTTPS). This process typically includes identity authentication (such as using API Key and Secret) and data signing to ensure the legitimacy of the call. The system then receives the response from the third-party platform. The response contains the platform's final determined benefits information for this transaction and the user (e.g., "50 points awarded" or "A 10 RMB cash coupon can be used"). The adaptation interface parses the returned response, extracts key benefit details (such as type, quantity / value, and validity period), and converts it into a unified benefit information data model within the system for subsequent registration and processing.

[0083] This embodiment clearly demonstrates how the present invention achieves open integration with external ecosystems. By determining the source of rights through "rule matching" and then actually acquiring the rights through "adaptive interface calls," this design allows the system to flexibly connect to numerous third-party rights providers without needing to customize core business logic for each platform. This greatly expands the richness of rights sources while maintaining the stability and maintainability of the system core, and is a key technical path to achieving the invention's objective of "one-stop aggregation of multiple rights."

[0084] As a further optional embodiment, the step of invoking the corresponding third-party rights service through a preset adaptation interface to obtain the rights information according to the matched rights calculation rules specifically includes: If the matched rule type is a local calculation rule, the equity information is generated directly based on the rule logic and the transaction feature data; If the matched rule type is an external call rule, a query is initiated to the specified third-party rights platform through the adaptation interface, and the data returned by the platform is parsed and validated to obtain the rights information.

[0085] In this embodiment, the system intelligently selects two different execution paths to obtain rights information based on the attributes of the matched rules, as follows: If the matched benefit calculation rule is defined as a local calculation rule, the system will directly calculate and generate the corresponding benefit information locally based on the logic algorithm embedded in the rule, combined with the transaction feature data (such as transaction amount and quantity of goods) of this transaction. This type of rule is typically applicable to benefit activities operated independently by the system platform with fixed and clearly defined calculation logic, such as platform-wide points accumulation (e.g., "1 point for every 1 yuan spent") or standardized merchant gift promotions. This path does not rely on external network calls, has fast processing speed, low system resource consumption, and is unaffected by the stability of external services, making it suitable for benefit distribution scenarios with high real-time requirements and simple logic.

[0086] If the matched rights calculation rule is defined as an external call rule, it indicates that the final interpretation, qualification verification, or complex calculation logic of the rights is the responsibility of a third-party rights platform (such as a partner bank or brand marketing system). In this case, the system will initiate a query request to the designated third-party rights platform through a pre-defined interface. The request will carry necessary user identification and transaction characteristic data. The subsequent processing is crucial: the system will parse and validate the response data returned by the third-party platform. First, format parsing involves converting and extracting the third-party platform's unique data format (such as non-standard JSON structures or custom field names) into a unified rights data model within the system. Next, the validation process performs logical and security checks on the parsed data, such as verifying whether the rights value is a valid number, whether the validity period format is correct, and whether the returned rights ID matches the context of this query. Only data that passes the parsing and validation will be accepted by the system as valid rights information, thus continuing the subsequent registration process. Although this path involves network communication, it ensures that the system can securely and reliably integrate diverse external rights and benefits services through strict adaptation and verification mechanisms, thereby expanding its ecosystem capabilities while guaranteeing the consistency of its own data and the rigor of its business logic.

[0087] This dual-path mechanism demonstrates the flexibility and robustness of this invention. It enables the system to make the optimal choice between efficient processing and robust integration based on the complexity of the business scenario, thereby improving the processing performance of core high-frequency transactions while ensuring data security and system stability when interfacing with complex external ecosystems. This is a key technical feature supporting the core objective of "one-stop aggregation of multiple rights and interests".

[0088] As a further optional embodiment, before the step of registering the calculated rights information to the personal rights account bound to the user identifier, the method further includes: Verify the validity of the rights information. The validity verification includes checking at least one of the following: whether the rights are within the validity period, whether the rights type is supported by the personal rights account, and whether the current rights issuance conflicts with existing rights rules.

[0089] In this embodiment, the verification step is automatically triggered after the rights and interests information is calculated and before the formal registration operation is performed. Its core is to review the calculated rights and interests information based on preset multi-dimensional rules, specifically including one or more of the following checks: Checking if benefits are within their validity period: The system extracts the "Validity Start Time" and "Validity End Time" fields embedded in the benefit information and compares them with the server's current system time. This check is considered successful only if the current time is within the explicitly defined validity window (i.e., satisfying: Validity Start Time ≤ Current Time ≤ Validity End Time). This check aims to intercept expired or ineffective benefit issuances due to rule configuration errors, data synchronization delays, or system clock anomalies.

[0090] The system checks whether the type of benefit is supported by the individual benefit account. Different types of user accounts (such as regular users, VIP users, and specific partner accounts) may be preset to support different types of benefits. The system queries the attribute configuration or level permissions of the individual benefit account bound to the current user identifier to obtain a whitelist of benefit types supported by that account. Subsequently, the verification process determines whether the "benefit type" (e.g., "cross-border exclusive coupon," "co-branded points") in the benefit information to be registered is included in the whitelist. If it is not within the supported range, it is determined to be incompatible, and the verification fails. This mechanism ensures the accuracy and compliance of benefit distribution and avoids issuing invalid assets to accounts that are not authorized to use or cannot identify such benefits.

[0091] Checking whether the current rights issuance conflicts with existing rights: This is a higher-level business logic check. The system maintains a business conflict rule base, which defines various rights exclusivity, quantity limits, or stacking restrictions. During the check, the system will: Retrieve all existing rights records that are still valid in the user's personal rights account.

[0092] Based on the information of the rights to be issued this time (such as its associated activity ID, rule ID, and type) and the user's account status, condition matching is performed in the conflict rule base.

[0093] Typical conflict scenarios include: the same user cannot claim the same benefit repeatedly in the same activity (preventing duplicate claims), the total number of specific coupons held cannot exceed the prescribed limit (preventing hoarding), and certain benefits cannot be effective simultaneously with other specific benefits already held by the user (mutual exclusion rules).

[0094] Verification Execution and Subsequent Processing: The above checks can be performed sequentially or in parallel. The system sets a unified decision logic for the entire verification process: the entire validity verification is considered successful only when all enabled checks pass, and the system then allows the process to continue to the rights registration step. If any check fails, the system will immediately terminate the current registration process, mark the rights issuance record as "verification failed," and record a detailed failure reason log. Optionally, an alarm notification can be sent to the system management terminal, or a user-friendly failure message (such as "You have already claimed this offer") can be returned to the user terminal according to the configuration.

[0095] By introducing this embodiment, the present invention significantly enhances the robustness, fairness, and business accuracy of the system while achieving a high degree of automation. It proactively prevents invalid, incorrectly issued, or over-issued rights from entering user accounts from a technical perspective, protecting the marketing resources of merchants and the platform, ensuring the fair execution of activity rules, and maintaining the clarity and validity of user rights assets, thereby improving the reliability of the entire rights system and user trust.

[0096] The following describes the rights registration device based on payment behavior provided by the present invention, such as... Figure 2 As shown, the rights registration device based on payment behavior described below and the rights registration method based on payment behavior described above can be referred to in correspondence.

[0097] A rights registration device based on payment behavior includes: The information receiving module 210 is used to receive payment completion information from the payment system, the payment completion information being associated with a transaction completed by the user through an identity verification payment tool; Information extraction module 220 is used to extract user identifier and transaction feature data from the payment completion information; The rule matching module 230 is used to match and calculate the equity information corresponding to this transaction based on the transaction feature data and the preset equity rule library; The information registration module 240 is used to register the calculated rights information into the personal rights account bound to the user identifier.

[0098] Figure 3 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 3As shown, the electronic device may include: a processor 310, a communications interface 320, a memory 330, and a communication bus 340, wherein the processor 310, the communications interface 320, and the memory 330 communicate with each other via the communication bus 340. The processor 310 can invoke logical instructions in the memory 330 to execute a rights registration method based on payment behavior, the method including: Receive payment completion information from the payment system, which is associated with a transaction completed by the user through an identity verification payment tool; Extract user identifier and transaction feature data from the payment completion information; Based on the transaction feature data and the preset rights and interests rule base, the rights and interests information corresponding to this transaction is matched and calculated; The calculated rights and interests information will be registered in the personal rights and interests account that is bound to the user identifier.

[0099] Furthermore, the logical instructions in the aforementioned memory 330 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0100] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program that can be stored on a non-transitory computer-readable storage medium, wherein when the computer program is executed by a processor, the computer is able to execute the rights registration method based on payment behavior provided by the above methods, the method comprising: Receive payment completion information from the payment system, which is associated with a transaction completed by the user through an identity verification payment tool; Extract user identifier and transaction feature data from the payment completion information; Based on the transaction feature data and the preset rights and interests rule base, the rights and interests information corresponding to this transaction is matched and calculated; The calculated rights and interests information will be registered in the personal rights and interests account that is bound to the user identifier.

[0101] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the payment-based rights registration method provided by the methods described above, the method comprising: Receive payment completion information from the payment system, which is associated with a transaction completed by the user through an identity verification payment tool; Extract user identifier and transaction feature data from the payment completion information; Based on the transaction feature data and the preset rights and interests rule base, the rights and interests information corresponding to this transaction is matched and calculated; The calculated rights and interests information will be registered in the personal rights and interests account that is bound to the user identifier.

[0102] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0103] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0104] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for registering rights based on payment behavior, characterized in that, include: Receive payment completion information from the payment system, which is associated with a transaction completed by the user through an identity verification payment tool; Extract user identifier and transaction feature data from the payment completion information; Based on the transaction feature data and the preset rights and interests rule base, the rights and interests information corresponding to this transaction is matched and calculated; The calculated rights and interests information will be registered in the personal rights and interests account that is bound to the user identifier.

2. The method for registering rights based on payment behavior according to claim 1, characterized in that, After the step of registering the calculated rights information to the personal rights account bound to the user identifier, the following is also included: In response to a query request, an interactive interface is provided to uniformly display the rights and interests information under the aforementioned personal rights and interests account.

3. The rights registration method based on payment behavior according to claim 1, characterized in that, After the step of registering the calculated rights information to the personal rights account bound to the user identifier, the following is also included: Monitor the status of various rights in the personal rights account, and automatically initiate prompts for specific rights based on preset trigger conditions and user preferences.

4. The method for registering rights based on payment behavior according to claim 1, characterized in that, The preset triggering conditions include a rights validity period threshold, and the rights validity period threshold is determined based on the user's historical usage rate of similar rights.

5. The method for registering rights based on payment behavior according to claim 1, characterized in that, The step of matching and calculating the equity information corresponding to this transaction based on the transaction feature data and the preset equity rule base specifically includes: Based on the merchant identifier in the transaction feature data, match one or more corresponding rights calculation rules from the rights rule base; Based on the matched rights calculation rules, the corresponding third-party rights service is called through a preset adaptation interface to obtain the rights information.

6. The method for registering rights based on payment behavior according to claim 1, characterized in that, The step of obtaining the rights information by calling the corresponding third-party rights service through a preset adaptation interface based on the matched rights calculation rules specifically includes: If the matched rule type is a local calculation rule, the equity information is generated directly based on the rule logic and the transaction feature data; If the matched rule type is an external call rule, a query is initiated to the specified third-party rights platform through the adaptation interface, and the data returned by the platform is parsed and validated to obtain the rights information.

7. The method for registering rights based on payment behavior according to claim 1, characterized in that, Before the step of registering the calculated rights information to the personal rights account bound to the user identifier, the following steps are also included: Verify the validity of the rights information. The validity verification includes checking at least one of the following: whether the rights are within the validity period, whether the rights type is supported by the personal rights account, and whether the current rights issuance conflicts with existing rights rules.

8. A rights registration device based on payment behavior, characterized in that, include: The information receiving module is used to receive payment completion information from the payment system, which is associated with the transaction completed by the user through the identity recognition payment tool; The information extraction module is used to extract user identifier and transaction feature data from the payment completion information; The rule matching module is used to match and calculate the equity information corresponding to this transaction based on the transaction feature data and the preset equity rule base. The information registration module is used to register the calculated rights information into the personal rights account bound to the user identifier.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the rights registration method based on payment behavior as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the rights registration method based on payment behavior as described in any one of claims 1 to 7.

Images