Method and apparatus for managing user benefit card

Abstract

This invention discloses a method and apparatus for managing user benefit cards, relating to the field of computer technology. One specific embodiment of the method includes: receiving a card / coupon redemption request message from an external system; obtaining a message salt value for the card / coupon redemption request message; decrypting the card / coupon redemption request message using the obtained salt value to obtain card / coupon data; performing a non-empty check on at least some fields in the card / coupon data; and generating benefit card order data corresponding to the card / coupon redemption request message if the check passes. This embodiment, by decrypting and checking the received card / coupon redemption request message from the external system, and generating benefit card order data corresponding to the card / coupon redemption request message if the check passes, can handle management needs such as card / coupon redemption from users in external systems.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and apparatus for managing user rights cards. Background Technology

[0002] With the development of internet technology, the connections between different service platforms are becoming increasingly close. While providing services to users, a service platform can also offer users a way to purchase or redeem services from other platforms, allowing users to exchange their membership cards for benefits from those other platforms and enjoy their various privileges. Therefore, how to manage users' membership cards is a pressing issue that needs to be addressed. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a method and apparatus for managing user benefit cards. By decrypting and verifying the card redemption request message received from an external system, and generating benefit card order data corresponding to the card redemption request message if the verification is successful, the method can handle management needs such as card redemption from users of external systems.

[0004] To achieve the above objectives, according to one aspect of the present invention, a method for managing user benefit cards is provided, comprising: receiving a card redemption request message from an external system and obtaining a message salt value of the card redemption request message; decrypting the card redemption request message using the obtained salt value to obtain card data; performing non-empty validation on at least some fields in the card data, and generating benefit card order data corresponding to the card redemption request message if the validation passes.

[0005] Optionally, the coupon data includes service type; the method further includes: before generating the benefit card order data corresponding to the coupon redemption request message, determining whether there is coupon configuration information corresponding to the service type in the database; if not, sending an alarm reminder.

[0006] Optionally, the method further includes setting a distributed lock for the card redemption request message before generating the rights card order data corresponding to the card redemption request message.

[0007] Optionally, the method further includes: after generating the benefit card order data corresponding to the card redemption request message, writing the benefit card order data into a database and a local cache.

[0008] Optionally, the benefit card order data includes an order identifier field, a user identifier field, and a user benefit card identifier field; initially, the values ​​of the user identifier field and the user benefit card identifier field are empty.

[0009] The method further includes:

[0010] In response to receiving a user fulfillment request message, the system parses the user identifier and the first order identifier from the message; obtains the first benefit card order data corresponding to the first order identifier; determines whether the user benefit card identifier field in the first benefit card order data is empty; if so, it generates a user benefit card identifier, updates the first benefit card order data based on the user identifier and the user benefit card identifier to bind the service package corresponding to the user benefit card identifier to the user identifier, and returns the user benefit card identifier to the external system; otherwise, it obtains the field value of the user benefit card identifier field in the first benefit card order data and returns it to the external system.

[0011] Optionally, the method further includes:

[0012] Before obtaining the target benefit card order data corresponding to the first order identifier, the first card data is parsed from the user fulfillment request message, and at least some fields in the first card data are checked for non-emptiness and the check is confirmed to be successful.

[0013] After obtaining the target benefit card order data corresponding to the first order identifier, at least one of the following verifications is performed and the verification is confirmed to be successful: verifying the validity of the first benefit card order data and verifying the consistency between the preset fields in the first card data and the preset fields in the first benefit card order data.

[0014] Optionally, the method further includes: before obtaining the field value of the user rights card identifier field in the first rights card order data and returning it to the external system, determining that the first rights card order is valid based on the order status field value in the first rights card order data, and determining that the user rights card in the first rights card order data is valid based on the activation status field value in the first rights card order data.

[0015] Optionally, the first coupon data includes a first service type; before generating the user benefits card identifier, the method further includes at least one of the following:

[0016] Confirm that the database contains coupon configuration information corresponding to the first service type;

[0017] Confirm that the rights card issuance switch corresponding to the first service type is turned on;

[0018] Determine the inventory of user benefit cards corresponding to the first service type, and send an alarm reminder if the inventory of user benefit cards is less than or equal to the inventory threshold.

[0019] Optionally, updating the first benefit card order data based on the user identifier and the user benefit card identifier includes: updating the first benefit card order data by calling an asynchronous thread based on the user identifier and the user benefit card identifier.

[0020] Optionally, obtaining the first benefit card order data corresponding to the first order identifier includes: determining whether there is benefit card order data corresponding to the first order identifier in the local cache; if there is, obtaining the first benefit card order data from the local cache; otherwise, obtaining the first benefit card order data from the database and writing the first benefit card order data into the local cache;

[0021] The method further includes: after updating the first benefit card order data according to the user identifier and the user benefit card identifier, deleting the first benefit card order data in the local cache using a delayed double-delete method.

[0022] Optionally, the rights card order data includes an order identifier field, an order status field, and a user rights card identifier field;

[0023] The method further includes:

[0024] In response to receiving a card cancellation request message from the external system, the system parses out the second order identifier from the card cancellation request message; obtains the second benefit card order data corresponding to the second order identifier; and, if the second benefit card order data meets the following conditions, adjusts the order status in the second benefit card order data to an invalid status and sends a benefit card cancellation response message to the external system:

[0025] The second benefit card order is determined to be valid based on the order status field value in the second benefit card order data, the user benefit card identifier field in the second benefit card order data is not empty, and the user benefit card in the second benefit card order data is determined to be valid based on the activation status field value in the second benefit card order data.

[0026] Optionally, the method further includes:

[0027] Before obtaining the second benefit card order data corresponding to the second order identifier, the second card data is parsed from the card cancellation request message, and at least some fields in the second card data are checked for non-emptiness and the check is confirmed to be successful.

[0028] After obtaining the second benefit card order data corresponding to the second order identifier, at least one of the following verifications is performed and the verification is confirmed to be successful: verifying the validity of the second benefit card order data, and verifying the consistency between the preset fields in the second card data and the preset fields in the second benefit card order data.

[0029] Optionally, obtaining the second benefit card order data corresponding to the second order identifier includes: determining whether there is benefit card order data corresponding to the second order identifier in the local cache; if there is, obtaining the second benefit card order data from the local cache; otherwise, obtaining the second benefit card order data from the database and writing the second benefit card order data into the local cache;

[0030] The method further includes: after adjusting the order status in the second benefit card order data to invalid status, deleting the second benefit card order data in the local cache using a delayed double deletion method.

[0031] Optionally, the method further includes setting a distributed lock for the card cancellation request message before obtaining the second benefit card order data corresponding to the second order identifier.

[0032] According to a second aspect of the present invention, an apparatus for managing user rights cards is provided, comprising:

[0033] The message receiving module receives coupon redemption request messages from external systems, obtains the message salt value of the coupon redemption request message, and uses the obtained salt value to decrypt the coupon redemption request message to obtain coupon data.

[0034] The parameter verification module performs non-empty verification on at least some fields in the coupon data;

[0035] The message execution module generates the rights card order data corresponding to the card redemption request message if the verification passes.

[0036] Optionally, the coupon data includes service type; the message receiving module is further configured to: determine whether there is coupon configuration information corresponding to the service type in the database before generating the benefit card order data corresponding to the coupon redemption request message; if not, send an alarm reminder.

[0037] Optionally, the message execution module is further configured to: set a distributed lock for the card redemption request message before generating the benefit card order data corresponding to the card redemption request message.

[0038] Optionally, the message execution module further includes: after generating the benefit card order data corresponding to the card redemption request message, writing the benefit card order data into the database and local cache.

[0039] Optionally, the benefit card order data includes an order identifier field, a user identifier field, and a user benefit card identifier field; initially, the values ​​of the user identifier field and the user benefit card identifier field are empty.

[0040] The message receiving module is further configured to: in response to receiving a user performance request message, parse the user identifier and the first order identifier from the user performance request message;

[0041] The message execution module is further configured to: obtain the first benefit card order data corresponding to the first order identifier; determine whether the user benefit card identifier field in the first benefit card order data is empty; if so, generate a user benefit card identifier, update the first benefit card order data according to the user identifier and the user benefit card identifier, so as to bind the service package corresponding to the user benefit card identifier with the user identifier, and return the user benefit card identifier to the external system; otherwise, obtain the field value of the user benefit card identifier field in the first benefit card order data and return it to the external system.

[0042] Optionally, the parameter verification module is further configured to: before obtaining the target benefit card order data corresponding to the first order identifier, parse the first card data from the user fulfillment request message, perform non-empty verification on at least some fields in the first card data, and confirm that the verification is successful;

[0043] The message execution module is further configured to: after obtaining the target benefit card order data corresponding to the first order identifier, perform at least one of the following verifications and confirm that the verification is passed: verify the validity of the first benefit card order data, and verify the consistency between the preset fields in the first card data and the preset fields in the first benefit card order data.

[0044] Optionally, the message execution module is further configured to: before obtaining the field value of the user rights card identifier field in the first rights card order data and returning it to the external system, determine that the first rights card order is valid based on the order status field value in the first rights card order data, and determine that the user rights card in the first rights card order data is valid based on the activation status field value in the first rights card order data.

[0045] Optionally, the first card data includes a first service type; before generating the user benefits card identifier, the message execution module is further used for at least one of the following:

[0046] Confirm that the database contains coupon configuration information corresponding to the first service type;

[0047] Confirm that the rights card issuance switch corresponding to the first service type is turned on;

[0048] Determine the inventory of user benefit cards corresponding to the first service type, and send an alarm reminder if the inventory of user benefit cards is less than or equal to the inventory threshold.

[0049] Optionally, the message execution module updates the first benefit card order data according to the user identifier and the user benefit card identifier, including: updating the first benefit card order data by calling an asynchronous thread according to the user identifier and the user benefit card identifier.

[0050] Optionally, the message execution module obtains the first benefit card order data corresponding to the first order identifier, including: determining whether there is benefit card order data corresponding to the first order identifier in the local cache; if there is, obtaining the first benefit card order data from the local cache; otherwise, obtaining the first benefit card order data from the database and writing the first benefit card order data into the local cache;

[0051] The message execution module is further configured to: after updating the first benefit card order data according to the user identifier and the user benefit card identifier, delete the first benefit card order data in the local cache using a delayed double-delete method.

[0052] Optionally, the rights card order data includes an order identifier field, an order status field, and a user rights card identifier field;

[0053] The message receiving module is further configured to: in response to receiving a coupon cancellation request message from the external system, parse out the second order identifier from the coupon cancellation request message;

[0054] The message execution module is further configured to: obtain the second benefit card order data corresponding to the second order identifier; and, if the second benefit card order data meets the following conditions, adjust the order status in the second benefit card order data to an invalid status and send a benefit card cancellation response message to the external system:

[0055] The second benefit card order is determined to be valid based on the order status field value in the second benefit card order data, the user benefit card identifier field in the second benefit card order data is not empty, and the user benefit card in the second benefit card order data is determined to be valid based on the activation status field value in the second benefit card order data.

[0056] Optionally, the message receiving module is further configured to:

[0057] Before obtaining the second benefit card order data corresponding to the second order identifier, the second card data is parsed from the card cancellation request message, and at least some fields in the second card data are checked for non-emptiness and the check is confirmed to be successful.

[0058] The message execution module is further configured to: after obtaining the second benefit card order data corresponding to the second order identifier, perform at least one of the following verifications and confirm that the verification is passed: verify the validity of the second benefit card order data, and verify the consistency between the preset fields in the second card data and the preset fields in the second benefit card order data.

[0059] Optionally, the message execution module obtains the second benefit card order data corresponding to the second order identifier, including: determining whether there is benefit card order data corresponding to the second order identifier in the local cache; if there is, obtaining the second benefit card order data from the local cache; otherwise, obtaining the second benefit card order data from the database and writing the second benefit card order data into the local cache;

[0060] The message execution module is further configured to: after adjusting the order status in the second benefit card order data to invalid status, delete the second benefit card order data in the local cache using a delayed double-delete method.

[0061] Optionally, the message execution module is further configured to: set a distributed lock for the card cancellation request message before obtaining the second benefit card order data corresponding to the second order identifier.

[0062] According to a third aspect of the present invention, an electronic device for managing user rights cards is provided, comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the user rights card management method of the present invention.

[0063] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the user rights card management method of the present invention.

[0064] One embodiment of the above invention has the following advantages or beneficial effects: by decrypting and verifying the card redemption request message received from the external system, and generating the rights card order data corresponding to the card redemption request message if the verification is successful, it is possible to handle the management needs of users from the external system, such as card redemption.

[0065] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0066] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0067] Figure 1 This is a schematic diagram illustrating the main steps of the user rights card management method according to an embodiment of the present invention;

[0068] Figure 2 This is a schematic diagram of card and coupon configuration information in an optional embodiment of the present invention;

[0069] Figure 3 This is a schematic diagram of the main process of card and coupon redemption in an optional embodiment of the present invention;

[0070] Figure 4 This is a schematic diagram of the main process of user fulfillment in an optional embodiment of the present invention;

[0071] Figure 5 This is a schematic diagram of the main process for invalidating coupons in an optional embodiment of the present invention;

[0072] Figure 6 This is a schematic diagram of the main modules of the user rights card management device in an embodiment of the present invention;

[0073] Figure 7 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied;

[0074] Figure 8 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation

[0075] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0076] It should be noted that, unless otherwise specified, the embodiments of the present invention and the technical features thereof can be combined with each other.

[0077] According to one aspect of the present invention, a method for managing user rights cards is provided.

[0078] Figure 1 This is a schematic diagram illustrating the main steps of a user rights card management method according to an embodiment of the present invention. Figure 1 As shown, the user rights card management method of this invention mainly includes the following steps: step S101, step S102, step S103 and step S104.

[0079] Step S101: Receive a card redemption request message from an external system and obtain the message salt value of the card redemption request message.

[0080] An external system, in relation to the executing entity of the method in this embodiment of the invention, refers to a system other than the system of the executing entity. An external system can be considered a channel for the executing entity's system. By enabling users of the external system to redeem benefit cards, the executing entity's system helps increase its own system's GMV (Gross Merchandise Volume) and user base. For example, if a bank user redeems a benefit card on an e-commerce platform, the external system can be the bank's system, and the system executing the method of this embodiment of the invention is the e-commerce platform system; similarly, if an insurance user redeems a benefit card on an e-commerce platform, the external system can be the insurance system, and the system executing the method of this embodiment of the invention is the e-commerce platform system.

[0081] The salt value is a random number used for decryption verification, primarily for decrypting encrypted messages. The salt value can be a pre-configured value or a value generated using a preset encryption algorithm. For example, a coupon redemption request message includes a `channelNo` field. When obtaining the salt value, first check if the `channelNo` field is empty. If it is, use the pre-set value from the configuration center as the salt value; otherwise, use the value generated by the encryption algorithm used when configuring the channel in the external system.

[0082] Step S102: Use the obtained salt value to decrypt the coupon redemption request message to obtain coupon data.

[0083] The coupon redemption request message is used to redeem a benefits card. The message carries coupon data, the content of which can be selectively set according to actual needs. For example, the coupon data may include any one or more of the following: coupon number (the user's card number in the external system), card password (the user's card number in the external system), service type code, redemption time, name, mobile phone number, last 6 digits of ID card number, user's unique identifier, date of birth, and gender.

[0084] Step S103: Perform non-empty validation on at least some fields in the coupon data; if the validation passes, proceed to step S104; otherwise, the process ends.

[0085] When performing a non-empty validation, all fields in the coupon data can be validated, or only a subset of fields can be validated. The validation passes when all fields to be validated are not empty. For example, mandatory and optional fields in the coupon redemption request message can be pre-defined. During non-empty validation, only the mandatory fields are validated. The content of the mandatory and optional fields can be selectively set according to actual needs. For example, mandatory fields include coupon number, card password, service type code, and redemption time, while optional fields include name, mobile phone number, last 6 digits of ID card number, user unique identifier, date of birth, and gender.

[0086] In practical applications, after receiving a card redemption request message from an external system, the user's token can be verified. If the verification passes, subsequent steps are performed; otherwise, the process ends and an error message is returned. Verifying the user's token further enhances system security.

[0087] Step S104: Generate the rights card order data corresponding to the card redemption request message.

[0088] Benefit card order data refers to relevant data about benefit card orders, such as the corresponding coupon data, order status, activation status, etc. If a coupon redemption request has generated corresponding benefit card order data, it indicates that the coupon redemption has been successful and the user has redeemed the benefit card. The process of the user binding the redeemed benefit card to their user identifier is called user fulfillment. After fulfilling the fulfillment, the user can enjoy the various benefits on the benefit card. For example, benefit card order data includes one or more of the following components:

[0089] (1) User Benefit Card ID. The User Benefit Card ID is used to indicate the benefit card identifier bound to the user. When generating benefit card order data, this field has a default value or is empty; after the user fulfills the order, this field has the benefit card identifier bound to the user.

[0090] (2) Card and coupon data;

[0091] (3) Order status, including valid and invalid status. When generating benefit card order data, the order validity period (e.g., 30 days) can be calculated based on the benefit card configuration information. Within this validity period, the order is in a valid status; otherwise, the order is in an invalid status.

[0092] (4) Activation status, including pending activation status and activated status. The benefit card is in pending activation status when generating benefit card order data, and the benefit card is in activated status after the user fulfills the order;

[0093] (5) User ID (userPin). When generating benefit card order data, this field has a default value or is empty. After the user fulfills the order, this field indicates the user ID bound to the benefit card.

[0094] In some optional embodiments, the coupon data includes the service type. Before generating the benefit card order data corresponding to the coupon redemption request message, it is determined whether coupon configuration information corresponding to the service type exists in the database; if not, an alarm is sent. It should be noted that coupon redemption data can be generated regardless of whether coupon configuration information corresponding to the service type exists in the database. The content of the coupon configuration information can be selectively set according to the actual situation. Figure 2 A schematic diagram of card configuration information in an optional embodiment of the present invention is shown, such as... Figure 2 As shown, the coupon configuration information includes the benefit card name, benefit card code, service validity period (the expiration time of the benefit is calculated by adding the service validity period to the redemption time pushed by the external system), benefit card icon, benefit card type, service type code, service package ID (a collection of benefit items used to indicate the benefits a user can enjoy), daily redemption limit, total redemption amount, inventory alert, alert email, channel identifier, and other information. By sending an alarm reminder when the corresponding coupon configuration information does not exist in the database, users can be promptly informed of the progress and status of their coupon redemption.

[0095] In practical applications, the coupon data may include coupon numbers. Before executing step S104, it is checked whether the coupon number is duplicated, that is, whether there is a corresponding benefit card order data in the database. If it exists, it means that the coupon number has already been redeemed for a benefit card, at which point the process ends and an error message is returned; if it does not exist, it means that the coupon number has already been redeemed for a benefit card, and step S104 can be executed. By checking whether the coupon number is duplicated, it is possible to prevent users from repeatedly redeeming coupons based on the same coupon number.

[0096] Of course, to prevent duplicate redemptions and storage, a distributed lock can be set for the coupon redemption request message before generating the corresponding rights card order data. For example, a Redis distributed lock can be added to the coupon number and channel identifier currently being redeemed, thereby preventing external systems from concurrently pushing coupon redemption requests with the same channel identifier and coupon number.

[0097] Typically, after generating the benefit card order data corresponding to the card redemption request message, the benefit card order data can be directly written to the database (e.g., a relational database). Alternatively, the generated benefit card order data can be written to a local cache for quick response when a user fulfills their request. After redeeming a card, a user may fulfill their request immediately or at some later time. To minimize resource consumption, when writing benefit card order data to the local cache, an expiration date (e.g., 1 day) can be set for the cached data. After this expiration date, the data should be deleted from the local cache. In practical applications, the cache can be set based on the card number + channel number + service type code + userId.

[0098] Figure 3 A schematic diagram illustrating the main process of card redemption in an optional embodiment of the present invention is shown. Figure 3 In the optional embodiment shown, the external system pushes the coupon data to the execution entity system of the method of this embodiment for coupon redemption. The coupon redemption is mainly achieved through the following steps in the execution entity system:

[0099] (1) Receive encrypted data of the card redemption request message;

[0100] (2) Obtain the salt value of the coupon redemption request message;

[0101] (3) Use salt value to decrypt ciphertext;

[0102] (4) Perform token verification. If the verification passes, proceed to step (5); otherwise, return an error message.

[0103] (5) Perform parameter validation. This step mainly performs non-empty validation, and the relevant content can be found in step S103, which will not be repeated here. If the validation passes, proceed to step (6); otherwise, return an error message.

[0104] (6) Set up a Redis distributed lock;

[0105] (7) Verify if the card number in the message exists. That is, check if there is a corresponding benefit card order data in the database. If it exists, it means that the card number has been redeemed for a benefit card. At this time, the process ends and an error message is returned; if it does not exist, it means that the card number has been redeemed for a benefit card. Step (8) can be executed.

[0106] (8) Verify if the service type code exists in the card redemption message; if not, return an error message. Generate benefit card order data;

[0107] (9) Write the generated rights card order data to the database and local cache.

[0108] After a user redeems a benefits card, the redeemed card can be bound to the user through the fulfillment process, allowing the user to enjoy the various benefits included on the card. In some optional embodiments, the benefits card order data includes an order identifier field, a user identifier field, and a user benefits card identifier field; initially, the user identifier field and the user benefits card identifier field have empty values. The main process during user fulfillment includes the following steps:

[0109] Step S201: In response to receiving a user fulfillment request message, the user identifier and the first order identifier are parsed from the user fulfillment request message;

[0110] Step S202: Obtain the first benefit card order data corresponding to the first order identifier;

[0111] Step S203: Determine whether the user rights card identifier field in the first rights card order data is empty; if yes, proceed to step S204; otherwise, proceed to step S205.

[0112] Step S204: Generate a user rights card identifier, update the first rights card order data according to the user identifier and the user rights card identifier (that is, write the user identifier and the user rights card identifier into the corresponding fields of the rights card order data) to bind the service package corresponding to the user rights card identifier with the user identifier, and then return the user rights card identifier to the external system;

[0113] Step S205: Obtain the field value of the user rights card identifier field in the first rights card order data and return it to the external system.

[0114] In some optional embodiments, before obtaining the target benefit card order data corresponding to the first order identifier, the first card data is parsed from the user fulfillment request message, and at least some fields in the first card data are checked for non-emptiness and the check is confirmed to pass. After obtaining the target benefit card order data corresponding to the first order identifier, at least one of the following checks is performed and the check is confirmed to pass: checking the validity of the first benefit card order data, and checking the consistency between preset fields in the first card data and preset fields in the first benefit card order data. Through the above checks, the system security can be further improved.

[0115] Optionally, before retrieving the value of the user benefit card identifier field in the first benefit card order data and returning it to the external system, the validity of the first benefit card order is determined based on the order status field value in the first benefit card order data, and the validity of the user benefit card in the first benefit card order data (activated but not invalidated) is determined based on the activation status field value in the first benefit card order data. Confirming the validity of the order and user benefit card before returning the value of the user benefit card identifier field in the first benefit card order data to the external system avoids user misunderstanding, allowing users to enjoy various benefits based on a valid benefit card.

[0116] Optionally, the first coupon data includes a first service type; before generating the user benefit card identifier, it also includes at least one of the following: confirming that coupon configuration information corresponding to the first service type exists in the database; confirming that the benefit card issuance switch corresponding to the first service type is turned on; determining the user benefit card inventory corresponding to the first service type, and sending an alarm reminder when the user benefit card inventory is less than or equal to the inventory threshold. Determining the coupon configuration information facilitates quick identification of the benefit items corresponding to the user benefit card. Setting the benefit card issuance switch facilitates flexible control over whether or not benefit cards are issued. Sending an alarm reminder when the user benefit card inventory is less than or equal to the inventory threshold promptly reminds users of the remaining amount of benefit items, facilitating reasonable planning and use by users.

[0117] Optionally, updating the first benefit card order data based on the user identifier and the user benefit card identifier includes: updating the first benefit card order data by calling an asynchronous thread based on the user identifier and the user benefit card identifier. Using an asynchronous thread to update the benefit card order data facilitates distributed deployment and is highly efficient.

[0118] Optionally, obtaining the first benefit card order data corresponding to the first order identifier includes: determining whether benefit card order data corresponding to the first order identifier exists in the local cache; if it exists, retrieving the first benefit card order data from the local cache; otherwise, retrieving the first benefit card order data from the database, and then writing the first benefit card order data into the local cache. After updating the first benefit card order data according to the user identifier and the user benefit card identifier, the first benefit card order data in the local cache is deleted using a delayed double-delete method.

[0119] Delayed Double Delete Cache: Before updating the benefits card order table, the cache is deleted once, then the database is updated. After a certain delay (e.g., 10 milliseconds), the cache is deleted a second time. Before updating the database, concurrent threads might read old data and write it to the local cache simultaneously. This results in the local cache containing the old data from before the database update, causing inconsistency between the database and the local cache. To solve this problem, the cache data is deleted a second time after the database update (e.g., 10 milliseconds). The delay ensures that the old data is written to the local cache before being deleted, even if some threads read old data before the database update.

[0120] Figure 4 A schematic diagram illustrating the main process of user fulfillment in an optional embodiment of the present invention is shown. Figure 3 In the optional embodiment shown, the external system displays a page redirection link to the user, such as a "Go to Use" button on the page. The user clicks this page redirection link to access the user fulfillment page provided by the execution entity of the method in this embodiment of the invention. In this execution entity system, user fulfillment is mainly achieved through the following steps:

[0121] (1) Receive front-end request parameters, i.e., the encrypted data of the user's performance request message;

[0122] (2) Perform parameter decryption and verification. The relevant process of ciphertext decryption and parameter verification can be found in the introduction of steps S102 and S103, which will not be repeated here.

[0123] (3) Determine if the verification passes. If the verification passes, proceed to step (4); otherwise, the process ends and an error message is returned.

[0124] (4) Query benefit card orders. This step checks the local cache or database for corresponding order data based on the card number in the message;

[0125] (5) Determine if an order is found. If yes, it means the coupon number exists. If the corresponding order data does not exist in the local cache, the order data retrieved from the database will be written to the local cache, and proceed to step (6); otherwise, it means the coupon number does not exist, and an error message will be returned.

[0126] (6) Determine whether the order is valid based on the order status in the benefit card order data. If the order is invalid, the process ends and an error message is returned; if the order is valid, proceed to step (7).

[0127] (7) Determine whether the card code in the message matches the card code in the order data; if yes, proceed to step (8); otherwise, the process ends and an error message is returned.

[0128] (8) Query the user rights card ID based on the order ID, that is, query the field value of the user rights card ID field in the corresponding order data based on the order ID;

[0129] (9) Determine if the user rights card ID is found. If yes, it means the user has fulfilled the agreement and proceeds to step (10); otherwise, it means the user has not yet fulfilled the agreement and proceeds to step (13).

[0130] (10) Determine whether the user PIN in the message is consistent with the user PIN in the order data; if yes, proceed to step (11); otherwise, end the process and return an error message.

[0131] (11) Verify whether the user rights card is valid based on the order status in the order data, that is, verify whether the order is valid; if yes, proceed to step (12), otherwise the process ends and an error message is returned.

[0132] (12) Verify whether the user's rights card has expired based on the activation status of the rights card; if so, the process ends and the user's rights card ID in the order data is returned; otherwise, the process ends and an error message is returned.

[0133] (13) Check the privilege card configuration;

[0134] (14) Determine if the rights card configuration is empty; if yes, the process ends and an error message is returned; otherwise, proceed to step (15).

[0135] (15) Determine if the rights card issuance switch is on (setting a user rights card switch can improve security and prevent accidents). If yes, proceed to step (16); otherwise, the process ends and an error message is returned.

[0136] (16) Calculate the total number of benefit cards currently claimed by users. An alarm will be triggered when the benefit card inventory is less than 30% (this can also be set to other values, such as 20%).

[0137] (17) Generate user rights card fulfillment data;

[0138] (18) Collect card-related data, including but not limited to: the total number of cards claimed by users, the number of cards claimed by users for a specific card, the number of cards claimed for a specific card on a given day, and the total number of cards claimed for a specific card. The collected card-related data can be displayed when users inquire about their benefits;

[0139] (19) Call the asynchronous fulfillment thread. The thread pool is used for asynchronous calls. If the call fails, the fulfillment will be compensated by a scheduled task. After generating the rights card order data, the rights card does not yet have the ability to provide services. It is necessary to bind the service package and user identifier (userpin) under the rights card. If the binding is successful, the user can use the rights card. If the binding fails, it is necessary to repeat the binding of the service package and user identifier (userpin) periodically through technical means. This step mainly involves writing the user identifier and rights card identifier into the corresponding fields in the rights card order data, and updating the rights card activation status in the rights card order data to activated, thereby realizing the binding of the user identifier and rights card identifier.

[0140] (20) Send the fulfilled message queue (the main purpose of this message queue is to notify the external system of the processing result of the current user's fulfillment request message). The external system updates the rights card order information and deletes the local cache using a delayed double-delete method.

[0141] (21) Return the fulfilled user rights card ID. The user rights card ID does not have the ability to actually serve the user; it needs to wait until the service package and userpin are successfully bound before it can provide the user with various rights items. Since the interface calls between systems are all data transmitted over the network, fulfillment will fail if there is a network anomaly, or if the internal interface processing fails. Therefore, after the asynchronous thread in step (18) returns the fulfillment success information, it can delay for a period of time (e.g., 2 seconds) before returning the bound user rights card ID to the front end.

[0142] In this embodiment, user benefit card information can be queried based on the user benefit card ID and displayed on the external system homepage. When a user actually uses a benefit card, such as video consultation, the internet hospital will call the execution entity system of the method in this embodiment to check whether the user has that benefit. After the user uses the benefit, the internet hospital will call the execution entity system of the method in this embodiment to deduct the benefit usage once.

[0143] The benefit card management method of this invention can also provide a card cancellation function. Specifically, the benefit card order data includes an order identifier field, an order status field, and a user benefit card identifier field. When cancelling a card, in response to receiving a card cancellation request message from an external system, the second order identifier is parsed from the card cancellation request message; the second benefit card order data corresponding to the second order identifier is obtained; if the second benefit card order data meets the following conditions, the order status in the second benefit card order data is adjusted to an invalid status, and then a benefit card cancellation response message is sent to the external system: the second benefit card order is determined to be valid based on the order status field value in the second benefit card order data; the user benefit card identifier field in the second benefit card order data is not empty; and the user benefit card in the second benefit card order data is determined to be valid based on the activation status field value in the second benefit card order data.

[0144] Before obtaining the second benefit card order data corresponding to the second order identifier, the second card data can be parsed from the card cancellation request message. At least some fields in the second card data can be validated for non-emptiness, and the validation must be confirmed to pass. After obtaining the second benefit card order data corresponding to the second order identifier, at least one of the following validations can be performed and confirmed to pass: validating the second benefit card order data, and verifying the consistency between preset fields in the second card data and preset fields in the second benefit card order data. These validations further enhance security.

[0145] Optionally, retrieving the second benefit card order data corresponding to the second order identifier includes: determining whether benefit card order data corresponding to the second order identifier exists in the local cache; if it exists, retrieving the second benefit card order data from the local cache; otherwise, retrieving the second benefit card order data from the database and then writing the second benefit card order data into the local cache; after adjusting the order status in the second benefit card order data to invalid, deleting the second benefit card order data in the local cache using a delayed double-delete method. Deleting data in the local cache using a delayed double-delete method can improve data consistency.

[0146] Before obtaining the second benefit card order data corresponding to the second order identifier, a distributed lock can be set for the card cancellation request message. For example, a Redis distributed lock can be added to the card number and channel identifier of the card currently being cancelled, thereby preventing external systems from concurrently pushing card cancellation requests with the same channel identifier and card number.

[0147] Figure 5 A schematic diagram illustrating the main process of card cancellation in an optional embodiment of the present invention is shown. Figure 5In the optional embodiment shown, after a user triggers a redirect link (e.g., a "Use Now" button) in an external system, they are redirected to the page (e.g., an H5 page) of the execution entity of the method of this embodiment. The external system pushes a coupon cancellation request message to the execution entity system of the method of this embodiment to cancel the coupon. In this execution entity system, coupon cancellation is mainly achieved through the following steps:

[0148] (1) Receive encrypted data of the card cancellation request message;

[0149] (2) Obtain the salt value of the coupon redemption request message;

[0150] (3) Use salt value to decrypt ciphertext;

[0151] (4) Perform token verification;

[0152] (5) Determine if the token verification passes. If the verification passes, proceed to step (6); otherwise, return an error message.

[0153] (6) Perform parameter validation. This step mainly performs non-empty validation, and the relevant content can be found in step S103, which will not be repeated here.

[0154] (7) Determine if the parameter validation passes. If the validation passes, proceed to step (8); otherwise, return an error message.

[0155] (8) Set up a Redis distributed lock;

[0156] (9) Verify whether the order data corresponding to the card number in the message exists. That is, verify whether there is a benefit card order data corresponding to the card number in the database. If it exists, proceed to step (10); otherwise, it indicates that there is no benefit card corresponding to the card number, and return an error message.

[0157] (10) Update the rights card order data and change the order status to invalid;

[0158] (11) Send an MQ void message;

[0159] (12) Delay double-delete the data in the local cache, and then the process ends.

[0160] In practical applications, after fulfillment, JMQ (a message queue) can be used to update the rights card order data of external systems (such as the SOA (service-oriented architecture) system of an insurance platform) to achieve data consistency. There are three reasons for using JMQ: First, JMQ's reliability guarantees no data loss. In the event of a consumer failure, it will retry until successful, providing automatic compensation. Second, using an RPC interface, synchronous interfaces increase the response time of the fulfillment interface, while asynchronous interfaces increase system design complexity. Whether synchronous or asynchronous, the failure of downstream system calls must be considered, requiring additional compensation design and increasing system complexity. Third, asynchronous and decoupled mechanisms reduce strong dependencies between systems, and asynchronous operations improve system performance.

[0161] After the insurance SOA fulfillment (C-end interface) is completed, the benefit card order data on the Open side is updated via JMQ. There are three reasons for using JMQ: First, JMQ's reliability guarantees no data loss; in case of consumption failure, it will retry until successful, and JMQ can provide automatic compensation. Second, using an RPC interface, synchronous interfaces would increase the response time of the fulfillment interface, while asynchronous interfaces would increase the complexity of the system design. Whether synchronous or asynchronous, the failure of downstream system calls must always be considered, requiring additional compensation design, thus increasing system complexity. Third, asynchronous and decoupling: JMQ reduces strong dependencies between systems, and asynchronous operation improves system performance. In summary, JMQ achieves eventual data consistency.

[0162] According to a second aspect of the present invention, an apparatus for implementing the above-described method is provided.

[0163] Figure 6 This is a schematic diagram of the main components of the user rights card management device according to an embodiment of the present invention. Figure 6 As shown, the user rights card management device 600 includes:

[0164] The message receiving module 601 receives a card redemption request message from an external system, obtains the message salt value of the card redemption request message, and uses the obtained salt value to decrypt the card redemption request message to obtain card data.

[0165] The parameter verification module 602 performs non-empty verification on at least some fields in the card data;

[0166] The message execution module 603 generates the rights card order data corresponding to the card redemption request message if the verification passes.

[0167] Optionally, the coupon data includes service type; the message receiving module is further configured to: determine whether there is coupon configuration information corresponding to the service type in the database before generating the benefit card order data corresponding to the coupon redemption request message; if not, send an alarm reminder.

[0168] Optionally, the message execution module is further configured to: set a distributed lock for the card redemption request message before generating the benefit card order data corresponding to the card redemption request message.

[0169] Optionally, the message execution module further includes: after generating the benefit card order data corresponding to the card redemption request message, writing the benefit card order data into the database and local cache.

[0170] Optionally, the benefit card order data includes an order identifier field, a user identifier field, and a user benefit card identifier field; initially, the values ​​of the user identifier field and the user benefit card identifier field are empty.

[0171] The message receiving module is further configured to: in response to receiving a user performance request message, parse the user identifier and the first order identifier from the user performance request message;

[0172] The message execution module is further configured to: obtain the first benefit card order data corresponding to the first order identifier; determine whether the user benefit card identifier field in the first benefit card order data is empty; if so, generate a user benefit card identifier, update the first benefit card order data according to the user identifier and the user benefit card identifier, so as to bind the service package corresponding to the user benefit card identifier with the user identifier, and return the user benefit card identifier to the external system; otherwise, obtain the field value of the user benefit card identifier field in the first benefit card order data and return it to the external system.

[0173] Optionally, the parameter verification module is further configured to: before obtaining the target benefit card order data corresponding to the first order identifier, parse the first card data from the user fulfillment request message, perform non-empty verification on at least some fields in the first card data, and confirm that the verification is successful;

[0174] The message execution module is further configured to: after obtaining the target benefit card order data corresponding to the first order identifier, perform at least one of the following verifications and confirm that the verification is passed: verify the validity of the first benefit card order data, and verify the consistency between the preset fields in the first card data and the preset fields in the first benefit card order data.

[0175] Optionally, the message execution module is further configured to: before obtaining the field value of the user rights card identifier field in the first rights card order data and returning it to the external system, determine that the first rights card order is valid based on the order status field value in the first rights card order data, and determine that the user rights card in the first rights card order data is valid based on the activation status field value in the first rights card order data.

[0176] Optionally, the first card data includes a first service type; before generating the user benefits card identifier, the message execution module is further used for at least one of the following:

[0177] Confirm that the database contains coupon configuration information corresponding to the first service type;

[0178] Confirm that the rights card issuance switch corresponding to the first service type is turned on;

[0179] Determine the inventory of user benefit cards corresponding to the first service type, and send an alarm reminder if the inventory of user benefit cards is less than or equal to the inventory threshold.

[0180] Optionally, the message execution module updates the first benefit card order data according to the user identifier and the user benefit card identifier, including: updating the first benefit card order data by calling an asynchronous thread according to the user identifier and the user benefit card identifier.

[0181] Optionally, the message execution module obtains the first benefit card order data corresponding to the first order identifier, including: determining whether there is benefit card order data corresponding to the first order identifier in the local cache; if there is, obtaining the first benefit card order data from the local cache; otherwise, obtaining the first benefit card order data from the database and writing the first benefit card order data into the local cache;

[0182] The message execution module is further configured to: after updating the first benefit card order data according to the user identifier and the user benefit card identifier, delete the first benefit card order data in the local cache using a delayed double-delete method.

[0183] Optionally, the rights card order data includes an order identifier field, an order status field, and a user rights card identifier field;

[0184] The message receiving module is further configured to: in response to receiving a coupon cancellation request message from the external system, parse out the second order identifier from the coupon cancellation request message;

[0185] The message execution module is further configured to: obtain the second benefit card order data corresponding to the second order identifier; and, if the second benefit card order data meets the following conditions, adjust the order status in the second benefit card order data to an invalid status and send a benefit card cancellation response message to the external system:

[0186] The second benefit card order is determined to be valid based on the order status field value in the second benefit card order data, the user benefit card identifier field in the second benefit card order data is not empty, and the user benefit card in the second benefit card order data is determined to be valid based on the activation status field value in the second benefit card order data.

[0187] Optionally, the message receiving module is further configured to:

[0188] Before obtaining the second benefit card order data corresponding to the second order identifier, the second card data is parsed from the card cancellation request message, and at least some fields in the second card data are checked for non-emptiness and the check is confirmed to be successful.

[0189] The message execution module is further configured to: after obtaining the second benefit card order data corresponding to the second order identifier, perform at least one of the following verifications and confirm that the verification is passed: verify the validity of the second benefit card order data, and verify the consistency between the preset fields in the second card data and the preset fields in the second benefit card order data.

[0190] Optionally, the message execution module obtains the second benefit card order data corresponding to the second order identifier, including: determining whether there is benefit card order data corresponding to the second order identifier in the local cache; if there is, obtaining the second benefit card order data from the local cache; otherwise, obtaining the second benefit card order data from the database and writing the second benefit card order data into the local cache;

[0191] The message execution module is further configured to: after adjusting the order status in the second benefit card order data to invalid status, delete the second benefit card order data in the local cache using a delayed double-delete method.

[0192] Optionally, the message execution module is further configured to: set a distributed lock for the card cancellation request message before obtaining the second benefit card order data corresponding to the second order identifier.

[0193] According to a third aspect of the present invention, an electronic device for managing user rights cards is provided, comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the user rights card management method of the present invention.

[0194] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the user rights card management method of the present invention.

[0195] Figure 7 An exemplary system architecture 700 is shown, in which the method or apparatus for user rights card management can be applied according to embodiments of the present invention.

[0196] like Figure 7 As shown, system architecture 700 may include terminal devices 701, 702, and 703, a network 704, and a server 705. Network 704 serves as the medium for providing communication links between terminal devices 701, 702, and 703 and server 705. Network 704 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0197] Users can use terminal devices 701, 702, and 703 to interact with server 705 via network 704 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 701, 702, and 703, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0198] Terminal devices 701, 702, and 703 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0199] Server 705 can be a server providing various services, such as a backend management server supporting shopping websites browsed by users using terminal devices 701, 702, and 703. The backend management server can analyze and process received data such as product information query requests, and feed back the processing results (such as target push information and product information) to the terminal devices.

[0200] It should be noted that the user rights card management method provided in this embodiment of the invention is generally executed by server 705, and correspondingly, the user rights card management device is generally set in server 705.

[0201] It should be understood that Figure 7The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0202] The following is for reference. Figure 8 It shows a schematic diagram of the structure of a computer system 800 suitable for implementing a terminal device of the present invention. Figure 8 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0203] like Figure 8 As shown, the computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 802 or programs loaded from storage section 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the system 800. The CPU 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0204] The following components are connected to I / O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to I / O interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 810 as needed so that computer programs read from it can be installed into storage section 808 as needed.

[0205] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by central processing unit (CPU) 801, it performs the functions defined above in the system of this invention.

[0206] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0207] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0208] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor can be described as including: a message receiving module, a parameter verification module, and a message execution module. The names of these modules do not necessarily limit the module itself; for example, the message receiving module can also be described as "a module that generates benefit card order data corresponding to the card redemption request message."

[0209] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs that, when executed by the device, cause the device to include: receiving a coupon redemption request message from an external system; obtaining a message salt value of the coupon redemption request message; decrypting the coupon redemption request message using the obtained salt value to obtain coupon data; performing a non-empty check on at least some fields in the coupon data; and generating benefit card order data corresponding to the coupon redemption request message if the check passes.

[0210] According to the technical solution of the present invention, by decrypting and verifying the card redemption request message received from the external system, and generating the benefit card order data corresponding to the card redemption request message if the verification is successful, the management needs such as card redemption from users of the external system can be processed.

[0211] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for managing user rights cards, characterized in that, Applicable to cross-platform scenarios, including: Receive a card redemption request message from an external system. The card redemption request message is used to redeem a benefit card. The card redemption request message includes a channelNo field and card data. The user's token is verified. If the verification passes, the next steps are performed; otherwise, the process ends and an error message is returned. Obtain the message salt value of the card redemption request message: Determine whether the channelNo field is empty. If it is, take the value preset in the configuration center as the salt value. Otherwise, take the value generated by the encryption algorithm when configuring the channel in the external system as the salt value. The obtained salt value is used to decrypt the coupon redemption request message to obtain the coupon data; Based on the pre-agreed mandatory and optional fields in the coupon redemption request message, only the mandatory fields are checked for non-emptiness, and if the check passes, the corresponding benefit card order data is generated.

2. The method as described in claim 1, characterized in that, The coupon data includes service types; the method further includes: before generating the benefit card order data corresponding to the coupon redemption request message, determining whether there is coupon configuration information corresponding to the service type in the database; if not, sending an alarm reminder.

3. The method as described in claim 1, characterized in that, The method further includes: Before generating the rights card order data corresponding to the card redemption request message, a distributed lock is set for the card redemption request message.

4. The method as described in claim 1, characterized in that, The method further includes: After generating the benefit card order data corresponding to the card redemption request message, the benefit card order data is written to the database and local cache.

5. The method as described in claim 1, characterized in that, The rights card order data includes an order identifier field, a user identifier field, and a user rights card identifier field; initially, the values ​​of the user identifier field and the user rights card identifier field are empty. The method further includes: In response to receiving a user fulfillment request message, the system parses the user identifier and the first order identifier from the message; obtains the first benefit card order data corresponding to the first order identifier; determines whether the user benefit card identifier field in the first benefit card order data is empty; if so, it generates a user benefit card identifier, updates the first benefit card order data based on the user identifier and the user benefit card identifier to bind the service package corresponding to the user benefit card identifier to the user identifier, and returns the user benefit card identifier to the external system; otherwise, it obtains the field value of the user benefit card identifier field in the first benefit card order data and returns it to the external system.

6. The method as described in claim 5, characterized in that, The method further includes: Before obtaining the target benefit card order data corresponding to the first order identifier, the first card data is parsed from the user fulfillment request message, and at least some fields in the first card data are checked for non-emptiness and the check is confirmed to be successful. After obtaining the target benefit card order data corresponding to the first order identifier, at least one of the following verifications is performed and the verification is confirmed to be successful: verifying the validity of the first benefit card order data and verifying the consistency between the preset fields in the first card data and the preset fields in the first benefit card order data.

7. The method as described in claim 5, characterized in that, The method further includes: before obtaining the field value of the user rights card identifier field in the first rights card order data and returning it to the external system, determining that the first rights card order is valid based on the order status field value in the first rights card order data, and determining that the user rights card in the first rights card order data is valid based on the activation status field value in the first rights card order data.

8. The method as described in claim 6, characterized in that, The first card data includes a first service type; before generating the user benefits card identifier, the method further includes at least one of the following: Confirm that the database contains coupon configuration information corresponding to the first service type; Confirm that the rights card issuance switch corresponding to the first service type is turned on; Determine the inventory of user benefit cards corresponding to the first service type, and send an alarm reminder if the inventory of user benefit cards is less than or equal to the inventory threshold.

9. The method as described in claim 5, characterized in that, Updating the first benefit card order data based on the user identifier and the user benefit card identifier includes: updating the first benefit card order data by calling an asynchronous thread based on the user identifier and the user benefit card identifier.

10. The method as described in claim 5, characterized in that, Obtaining the first benefit card order data corresponding to the first order identifier includes: determining whether there is benefit card order data corresponding to the first order identifier in the local cache; if there is, obtaining the first benefit card order data from the local cache; otherwise, obtaining the first benefit card order data from the database and writing the first benefit card order data into the local cache; The method further includes: after updating the first benefit card order data according to the user identifier and the user benefit card identifier, deleting the first benefit card order data in the local cache using a delayed double-delete method.

11. The method as described in claim 1, characterized in that, The rights card order data includes an order identifier field, an order status field, and a user rights card identifier field; The method further includes: In response to receiving a card cancellation request message from the external system, the system parses out the second order identifier from the card cancellation request message; obtains the second benefit card order data corresponding to the second order identifier; and, if the second benefit card order data meets the following conditions, adjusts the order status in the second benefit card order data to an invalid status and sends a benefit card cancellation response message to the external system: The second benefit card order is determined to be valid based on the order status field value in the second benefit card order data, the user benefit card identifier field in the second benefit card order data is not empty, and the user benefit card in the second benefit card order data is determined to be valid based on the activation status field value in the second benefit card order data.

12. The method as described in claim 11, characterized in that, The method further includes: Before obtaining the second benefit card order data corresponding to the second order identifier, the second card data is parsed from the card cancellation request message, and at least some fields in the second card data are checked for non-emptiness and the check is confirmed to be successful. After obtaining the second benefit card order data corresponding to the second order identifier, at least one of the following verifications is performed and the verification is confirmed to be successful: verifying the validity of the second benefit card order data, and verifying the consistency between the preset fields in the second card data and the preset fields in the second benefit card order data.

13. The method as described in claim 11, characterized in that, Obtaining the second benefit card order data corresponding to the second order identifier includes: determining whether there is benefit card order data corresponding to the second order identifier in the local cache; if there is, obtaining the second benefit card order data from the local cache; otherwise, obtaining the second benefit card order data from the database and writing the second benefit card order data into the local cache; The method further includes: after adjusting the order status in the second benefit card order data to invalid status, deleting the second benefit card order data in the local cache using a delayed double deletion method.

14. The method as described in claim 11, characterized in that, The method further includes: Before obtaining the second benefit card order data corresponding to the second order identifier, a distributed lock is set for the card cancellation request message.

15. A device for managing user rights cards, characterized in that, Applicable to cross-platform scenarios, including: The message receiving module receives a card redemption request message from an external system. The card redemption request message is used to redeem a benefit card and includes a channelNo field and card data. The module obtains the message salt value of the card redemption request message: it checks if the channelNo field is empty; if so, it uses a pre-set value in the configuration center as the salt value; otherwise, it uses the value generated by the encryption algorithm when configuring the channel in the external system as the salt value. The module then uses the obtained salt value to decrypt the card redemption request message to obtain the card data. The parameter validation module, based on the pre-agreed mandatory and optional fields in the coupon redemption request message, only performs non-empty validation on the mandatory fields. The message execution module generates the rights card order data corresponding to the card redemption request message if the verification passes. The device is also used to: after receiving a card redemption request message from an external system, verify the user's token; if the verification passes, proceed with subsequent steps; otherwise, the process ends and an error message is returned.

16. An electronic device for managing user rights cards, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-14.

17. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-14.

Images