Multi-card organization data processing method and device, equipment, medium and program product

Abstract

The invention provides a multi-card organization data processing method and device, equipment, a medium and a program product, and relates to the field of distributed data. The method comprises the following steps: screening credit cards of a user based on card holding information and right activity information to obtain credit cards conforming to the right activity information; performing activity matching on the credit card conforming to the right activity information and a first target activity selected by the user to generate activity registration request data; and organizing a credit card corresponding to the activity registration request data to a server through asynchronous thread parallelism so as to complete activity registration of the user. According to the scheme, the cards meeting the activity conditions in the cards owned by the user are screened based on the right and interest activity information, so that the manual selection burden of the user is reduced, centralized processing of cross-card organization right and interest activities is realized, and the registration efficiency is improved; and meanwhile, the registration requests are sent to a plurality of card organization servers through asynchronous thread parallelism, so that the risk of registration failure caused by manual input errors is reduced.

Description

Technical Field

[0001] This application relates to the field of distributed data, and in particular to a method, apparatus, device, medium, and program product for processing multi-card organization data. Background Technology

[0002] In the current financial consumption landscape, banks launch exclusive benefit programs for their own bank cards, such as discounts on transactions, cashback on purchases, and points redemption. These programs have become a core means of enhancing users' card usage enthusiasm and payment stickiness, and they cover a wide range of scenarios, including daily consumption, cross-border payments, and high-frequency transactions.

[0003] Currently, the registration channels for various bank card organizations' benefit activities are independent of each other. Users need to complete the registration process through different official platforms (such as dedicated apps and independent web pages). This not only requires frequent switching of access points but also necessitates repeatedly entering the same personal data such as card number, mobile phone number, and identity information on each platform. At the same time, users need to identify the matching relationship between the benefit activity and their card, including distinguishing card types (credit cards and debit cards), confirming the card organization to which the card belongs, and the participation threshold for the activity. This process not only leads to low activity registration efficiency but is also prone to registration failures due to issues such as incorrect card number input and misunderstanding of activity rules, seriously affecting the user experience.

[0004] Therefore, there is an urgent need for an efficient and convenient solution for processing multi-card organization data. Summary of the Invention

[0005] This application provides a method, apparatus, device, medium, and program product for processing multi-card organization data, in order to solve the technical problem of low registration efficiency when registering for multi-card organization activities.

[0006] Firstly, this application provides a method for processing multi-card organization data, including:

[0007] Determine the user's card information and the user's first target activity. Card information includes card type and card status.

[0008] Determine the corresponding benefits and activities information for each card type; based on the card type, card status, and benefits and activities information, filter the user's cards to obtain cards that match the benefits and activities information;

[0009] The card that meets the rights and benefits activity information is matched with the first target activity selected by the user to generate activity registration request data. The activity registration request data includes multiple second target activity registration requests and the corresponding card organization server.

[0010] The second target activity registration request is sent to the card organization server corresponding to the second target activity via an asynchronous thread to complete the user's registration for the second target activity.

[0011] In one possible implementation, the method further includes:

[0012] Obtain activity information from multiple card organizations, including the activities and conditions for each card organization.

[0013] The activities and conditions corresponding to each card organization are standardized to obtain the benefits and activities information;

[0014] The information on benefits and activities is stored in a database so that the corresponding information can be retrieved from the database when filtering user cards.

[0015] In one possible implementation, determining the user's card information and the user's selected first target activity includes:

[0016] Obtain the user's card information, current activity data corresponding to the activity, and the user's historical transaction data;

[0017] Based on the user's card information, current activity data, and historical transaction data, determine the primary weight for each activity.

[0018] The activities are sorted in descending order according to their respective weights and displayed on the visualization interface so that users can select their first target activity.

[0019] In one possible implementation, based on the user's card information, current activity data, and historical transaction data, a first weight is determined for each activity, including:

[0020] Based on the user's card information and current activity data, determine the second weight for each activity;

[0021] User transaction features are extracted from historical transaction data to obtain user transaction features; based on user transaction features and current activity data, the user preference weight corresponding to each activity is determined.

[0022] Based on the second weight and the user preference weight, the first weight corresponding to each activity is determined.

[0023] In one possible implementation, the user's cards are filtered based on card type, card status, and benefits / activities information to obtain cards that match the benefits / activities information, including:

[0024] Determine if the card is valid. If the card is valid, then the card is eligible for the benefits / activities.

[0025] And / or,

[0026] Determine if the card type is a preset card type. If the card type is a preset card type, then the card is determined to meet the requirements of the benefit activity information.

[0027] In one possible implementation, the method further includes:

[0028] We receive activity registration information from multiple card organizations. The activity registration information includes a status code and the corresponding data. The data corresponding to the status code includes the reason for the registration failure or the activity for which the registration was successful.

[0029] If the status code indicates that the registration failed, the reason for the registration failure will be displayed on the visual interface.

[0030] If the status code indicates successful registration, the successfully registered event will be displayed on the visualization interface.

[0031] Secondly, this application provides a multi-card organization data processing apparatus, comprising:

[0032] The acquisition module is used to determine the user's card information and the user's selected first target activity. The card information includes card type and card status.

[0033] The filtering module is used to filter users' cards based on card type, card status, and benefit activity information to obtain cards that match the benefit activity information;

[0034] The processing module is used to match cards that meet the rights and benefits activity information with the first target activity selected by the user, and generate activity registration request data. The activity registration request data includes multiple second target activity registration requests and the corresponding card organization servers.

[0035] The processing module is also used to send the second target activity registration request to the card organization server corresponding to the second target activity in parallel via asynchronous threads, so as to complete the user's second target activity registration.

[0036] In one possible implementation, the processing module is further configured to:

[0037] Obtain activity information from multiple card organizations, including the activities and conditions for each card organization.

[0038] The activities and conditions corresponding to each card organization are standardized to obtain the benefits and activities information;

[0039] The information on benefits and activities is stored in a database so that the corresponding information can be retrieved from the database when filtering user cards.

[0040] In one possible implementation, the processing module is further configured to:

[0041] Obtain the user's card information, current activity data corresponding to the activity, and the user's historical transaction data;

[0042] Based on the user's card information, current activity data, and historical transaction data, determine the primary weight for each activity.

[0043] The activities are sorted in descending order according to their respective weights and displayed on the visualization interface so that users can select their first target activity.

[0044] In one possible implementation, the processing module is further configured to:

[0045] Based on the user's card information and current activity data, determine the second weight for each activity;

[0046] User transaction features are extracted from historical transaction data to obtain user transaction features; based on user transaction features and current activity data, the user preference weight corresponding to each activity is determined.

[0047] Based on the second weight and the user preference weight, the first weight corresponding to each activity is determined.

[0048] In one possible implementation, the filtering module is also used for:

[0049] Determine if the card is valid. If the card is valid, then the card is eligible for the benefits / activities.

[0050] And / or,

[0051] Determine if the card type is a preset card type. If the card type is a preset card type, then the card is determined to meet the requirements of the benefit activity information.

[0052] In one possible implementation, the processing module is further configured to:

[0053] We receive activity registration information from multiple card organizations. The activity registration information includes a status code and the corresponding data. The data corresponding to the status code includes the reason for the registration failure or the activity for which the registration was successful.

[0054] If the status code indicates that the registration failed, the reason for the registration failure will be displayed on the visual interface.

[0055] If the status code indicates successful registration, the successfully registered event will be displayed on the visualization interface.

[0056] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the aforementioned method.

[0057] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the aforementioned method.

[0058] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0059] This application provides a method, apparatus, device, medium, and program product for processing multi-card organization data. The method involves determining a user's card information and their selected first target activity. Card information includes credit card type and status. It then determines the corresponding benefits and activities for each card type. Based on the card type, card status, and benefits and activities, the user's cards are filtered to obtain cards that match the benefits and activities. These matching cards are then matched with the user's selected first target activity to generate activity registration request data. This data includes multiple second target activity registration requests and their corresponding card organization servers. Finally, through asynchronous parallel threads, the second target activity registration requests are sent to the corresponding card organization servers to complete the user's registration for the second target activity. This solution reduces the burden of manual selection by filtering cards from the user's possession based on benefits and activities information, achieving centralized processing of cross-card organization benefits and activities, significantly reducing user operational complexity, and improving registration efficiency. Simultaneously, by using asynchronous parallel threads to send registration requests to multiple card organization servers, the user is not required to perform repetitive operations, reducing the risk of registration failure due to manual input errors or page redirection. Attached Figure Description

[0060] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0061] Figure 1 A schematic diagram illustrating a scenario for a multi-card organization data processing method provided in this application;

[0062] Figure 2 An interactive schematic diagram illustrating a multi-card organization data processing method provided in this application;

[0063] Figure 3 A flowchart illustrating a method for processing multi-card organization data provided in this application;

[0064] Figure 4 A schematic diagram of a multi-card organization data processing device provided in this application;

[0065] Figure 5This is a schematic diagram of the structure of an electronic device provided in this application.

[0066] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0067] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0068] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0069] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0070] It should be noted that the multi-card organization data processing methods, apparatus, devices, media, and program products provided in this application can be used in the field of distributed data, or in any field other than distributed data. The application fields of the multi-card organization data processing methods, apparatus, devices, media, and program products in this application are not limited.

[0071] In the current financial consumption landscape, banks launch exclusive benefit programs for their own bank cards, such as discounts on transactions, cashback on purchases, and points redemption. These programs have become a core means of enhancing users' card usage enthusiasm and payment stickiness, and they cover a wide range of scenarios, including daily consumption, cross-border payments, and high-frequency transactions.

[0072] Currently, the registration channels for various bank card organizations' benefit activities are independent. Users must complete the registration process through different official platforms (such as dedicated apps and separate websites), requiring frequent switching between different entry points and repeated input of the same personal data such as card numbers, mobile phone numbers, and identity information on each platform. Furthermore, users must manually identify the compatibility between the benefit activity and their card, including distinguishing card types (credit cards and debit cards), confirming the card organization to which the card belongs, and understanding the participation threshold. This process not only leads to low registration efficiency but also easily results in registration failures due to incorrect card number input or misunderstanding of activity rules, severely impacting user experience. In addition, banks and related service institutions need to develop, deploy, and maintain separate benefit activity registration systems for each card organization. Data cannot be shared between systems, and functions are duplicated, resulting in concentrated server load, wasted computing resources, and increased difficulty in system iteration and troubleshooting.

[0073] Therefore, there is an urgent need for an efficient and convenient solution for processing multi-card organization data.

[0074] This application provides a method, apparatus, device, medium, and program product for processing multi-card organization data. It determines a user's card information and the user's selected first target activity. The card information includes card type and card status. It then determines the corresponding benefit activity information for each card type. Based on the card type, card status, and benefit activity information, it filters the user's cards to obtain cards that match the benefit activity information. It matches the cards matching the benefit activity information with the user's selected first target activity, generating activity registration request data. This registration request data includes multiple second target activity registration requests and their corresponding card organization servers. Through asynchronous parallel threads, it sends the second target activity registration requests to the corresponding card organization servers to complete the user's second target activity registration. This solution reduces the burden of manual selection for users by filtering cards from the user's possession based on benefit activity information, achieving centralized processing of cross-card organization benefit activities, significantly reducing user operational complexity, and improving registration efficiency. Simultaneously, by using asynchronous parallel threads to send registration requests to multiple card organization servers, it eliminates the need for repeated user operations, reducing the risk of registration failure due to manual input errors or page redirection.

[0075] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0076] Figure 1A schematic diagram illustrating a method for processing multi-card organization data provided in this application, such as... Figure 1 As shown, the event registration system 100 is connected to the card organization server 200; the card organization server connected to the event registration system includes multiple card organization servers.

[0077] The activity registration system 100 obtains the user's card information and the user's first target activity; and determines the activity registration request data based on the user's card information, the first target activity, and the benefit activity information; and sends the activity registration request data to the corresponding card organization server 200 so that the card organization server 200 can complete the user's activity registration based on the activity registration request data.

[0078] Card organization server 200 processes the received event registration requests and generates event registration results.

[0079] Understandably, the activity registration system, based on the user's card information and benefit activity information, centrally filters the cards owned by the user that meet the activity conditions, reducing the burden of manual selection for the user and realizing centralized processing of cross-card organization benefit activities; at the same time, through asynchronous threads in parallel, registration requests are sent to multiple card organization servers simultaneously, eliminating the need for users to perform repeated operations and reducing the risk of registration failure due to manual input errors or page redirection.

[0080] Figure 2 This is an interactive diagram illustrating a multi-card organization data processing method provided in this application. Figure 2 As shown, the multi-card organization data processing method provided in this embodiment includes:

[0081] S201. Determine the user's card information and the user's first target activity;

[0082] Card information includes card type and card status. Card type can be, for example, Card Organization 1 - Credit Card, Card Organization 1 - Debit Card, etc. Card status includes expired card and valid card. The first target activity refers to the activity that the user is interested in selecting on the activity registration interface. For example, multiple card organizations have launched multiple benefit activities: "Card Organization 1 - Activity A1, Activity A2, Activity A3", "Card Organization 2 - Activity B1, Activity B2, Activity B3", "Card Organization 3 - Activity C1, Activity C2, Activity C3, Activity C4, Activity C5"; the user's first target activity is "Activity A1, Activity A2, Activity B3, Activity C1, Activity C5".

[0083] In one possible implementation, the user's card information and the user's selected first target activity are determined, as follows:

[0084] Obtain the user's card information, current activity data corresponding to the activity, and the user's historical transaction data;

[0085] Based on the user's card information, current activity data, and historical transaction data, determine the primary weight for each activity.

[0086] The activities are sorted in descending order according to their respective weights and displayed on the visualization interface so that users can select their first target activity.

[0087] The current activity data includes remaining slots and the number of registered users, etc.; user historical transaction data includes behavioral data, activity participation records, etc. For example, to obtain user A's information, the system calls the bank's interface to obtain user A's card information; for example, user A owns card a, card b, card c, and card d. Multiple benefit activities launched by various card organizations: "Card Organization 1 - Activity A1, Activity A2, Activity A3", "Card Organization 2 - Activity B1, Activity B2, Activity B3", "Card Organization 3 - Activity C1, Activity C2, Activity C3, Activity C4, Activity C5".

[0088] In one possible implementation, based on the user's card information, current activity data, and historical transaction data, a first weight is determined for each activity, as follows:

[0089] Based on the user's card information and current activity data, determine the second weight for each activity;

[0090] User transaction features are extracted from historical transaction data to obtain user transaction features; based on user transaction features and current activity data, the user preference weight corresponding to each activity is determined.

[0091] Based on the second weight and the user preference weight, the first weight corresponding to each activity is determined.

[0092] For example, obtain the current remaining slots and the number of users who have registered for each activity. For instance, for activity A1 of card organization 1, there are currently 100 remaining slots and 400 users who have registered for activity A1.

[0093] The weighting calculation formula is used to calculate the weight based on the remaining slots for each activity and the number of user registrations; the weighting calculation formula is as follows: N represents the number of registered users, and R represents the remaining slots for the event; based on this, the second weight corresponding to event A1 can be obtained. Similarly, the second weights for the benefits activities launched by multi-card organizations are as follows: Activity A2 -0.6, Activity A3 -0.75, Activity B1 -0.46, Activity B2 -0.55, Activity B3 -0.64, Activity C1 -0.47, Activity C2 -0.38, Activity C3 -0.52, Activity C4 -0.63, and Activity C5 -0.74.

[0094] By analyzing user behavior data and activity participation records, the system predicts user preferences for different card organization promotions and dynamically adjusts the order in which promotions are displayed. For example, if a user frequently uses Type 1 cards for cross-border spending, Type 1 card cross-border cashback promotions will be displayed first.

[0095] User transaction features are extracted from historical transaction data to obtain user transaction features. Based on user transaction features and current activity data, the user preference weights for each activity are determined as follows: Activity A1 -0.95, Activity A2 -0.40, Activity A3 -0.58, Activity B1 -0.82, Activity B2 -0.63, Activity B3 -0.73, Activity C1 -0.68, Activity C2 -0.88, Activity C3 -0.78, Activity C4 -0.45, Activity C5 -0.90.

[0096] The first weight is calculated using the weight calculation formula, which is as follows: ; Indicates the second weight. Indicates preference weights, This represents the second weighting coefficient. This represents the preference weighting coefficient; the weighting coefficient can be set according to needs, for example, , Therefore, the first weights corresponding to each activity are as follows: Activity A1 -0.66, Activity A2 -0.50, Activity A3 -0.67, Activity B1 -0.64, Activity B2 -0.59, Activity B3 -0.69, Activity C1 -0.58, Activity C2 -0.63, Activity C3 -0.65, Activity C4 -0.54, and Activity C5 -0.82.

[0097] Based on the first weight corresponding to each activity, the benefit activities launched by multiple card organizations are sorted in descending order and displayed on the visualization interface. At this time, the activities shown to user A in the visualization interface are in the following order: "Activity C5-Activity B3-Activity C4-Activity A3-Activity A1-Activity C3-Activity B1-Activity C2-Activity B2-Activity C4-Activity A2". Based on the benefit activities displayed in the visualization interface, user A selects the first target activity as "Activity A1, Activity A2, Activity B3, Activity C1, Activity C5".

[0098] This step solves the problem of low user participation caused by fixed activity display order by calculating the weight of each activity and displaying them in a visual interface according to their weight. Personalized recommendations reduce the time users spend filtering activities, increase the overall registration rate, and optimize the utilization of card organization activity resources to ensure that high-priority activities are seen by users first. At the same time, it can avoid wasting activity slots and increase the participation rate of card organization activities.

[0099] S202. Determine the benefits and activities information corresponding to the card type; based on the card type, card status, and benefits and activities information, filter the user's cards to obtain cards that match the benefits and activities information;

[0100] The information on benefits and activities is compiled from the activity rules corresponding to the benefits and activities launched by each card organization. For example, the benefit and activity information for activity A1 is "activity A1 only supports credit cards and only supports cards in a valid state". Based on the benefit and activity information, cards that do not meet the requirements of activity A1 will be excluded from the user's possession to avoid the user accidentally selecting invalid cards.

[0101] In one possible implementation, Figure 3 A flowchart illustrating a method for processing multi-card organization data provided in this application is shown below. Figure 3 As shown, the method also includes:

[0102] S301. Obtain activity information from multiple card organizations, including the activities and conditions for each card organization.

[0103] S302. Standardize the activities and conditions corresponding to each card organization to obtain benefits and activity information;

[0104] S303. Store the benefit activity information in the database so that when filtering user cards, the corresponding benefit activity information can be retrieved from the database.

[0105] To address the fragmentation issue in existing technologies where users need to access different platforms and repeatedly input information, this application uses an activity aggregation engine to dynamically capture activity information from multiple card organizations, standardizes this information, and stores the resulting benefits and activities information in a database. This allows for the unified retrieval of benefits and activities information when filtering user cards.

[0106] In summary, the multi-card organization benefits and activities information includes: "Card Organization 1 - Activities A1, A2, and A3", "Card Organization 2 - Activities B1, B2, and B3", and "Card Organization 3 - Activities C1, C2, C3, C4, and C5". The activities and conditions corresponding to Card Organization 1, Card Organization 2, and Card Organization 3 are standardized and converted into benefits and activities information in a unified data format. Since the data formats of different card organizations are inconsistent, the heterogeneous data from multiple card organizations is standardized into a unified data format for benefits and activities information and stored in a database. This allows for dynamic aggregation of activity rules from various card organizations, facilitating rapid selection of eligible activities later.

[0107] In one possible implementation, the user's cards are filtered based on card type, card status, and benefits / activities information to obtain cards that match the benefits / activities information, including:

[0108] Determine if the card is valid. If the card is valid, then the card is eligible for the benefits / activities.

[0109] And / or,

[0110] The system determines whether the card type is a preset card type. If the card type is a preset card type, then the card is deemed to meet the requirements of the benefit activity. For example, user A owns the following cards: "Card 1, Card 2, Card 3, Card 4, Card 5, Card 6, Card 7"; where the card type and status of each card are as follows: "Card 1 - Type 1, Valid; Card 2 - Type 2, Invalid; Card 3 - Type 2, Valid; Card 4 - Type 1, Invalid; Card 5 - Type 3, Valid; Card 6 - Type 2, Valid; Card 7 - Type 3, Invalid."

[0111] For example, regarding the benefit activity information for Activity B1, which states "only cards in a valid state are supported," it can be determined that the cards matching the benefit activity information include "Card 1, Card 3, Card 5, and Card 6." Alternatively, if the benefit activity information for Activity B1 states "only cards of type 1 and type 2 are supported," it can be determined that the cards matching the benefit activity information include "Card 1, Card 2, Card 3, Card 4, and Card 6." Or, if the benefit activity information for Activity BA states "only valid cards of type 1 and type 2 are supported," it can be determined that the cards matching the benefit activity information include "Card 1, Card 3, and Card 6."

[0112] This step reduces the burden of manual selection for users by filtering eligible cards based on benefits and activity information.

[0113] S203. Match the cards that meet the rights and benefits activity information with the first target activity selected by the user to generate activity registration request data; the activity registration request data includes multiple second target activity registration requests and the corresponding card organization servers;

[0114] In conjunction with the foregoing, for example, cards that match the activity information include: "Activity A1 - Card 1, Card 3, Card 6", "Activity A3 - Card 3, Card 5", "Activity B1 - Card 1", "Activity B2 - Card 2", "Activity C2 - Card 4, Card 7", "Activity C3 - Card 4, Card 5", and "Activity C5 - Card 5, Card 7". Matching these cards with the user's selected first target activity yields the second target registration activity and its corresponding card organization: Activity A1 - Card Organization 1, Activity C5 - Card Organization 3.

[0115] S204. Send the second target activity registration request to the card organization server corresponding to the second target activity through an asynchronous thread;

[0116] S205. Based on the second target activity registration request, complete the user's registration request.

[0117] By using asynchronous threads, multiple registration requests can be submitted in parallel to servers of different card organizations. For example, after a user selects an activity from card organization 1 and card organization 3, two threads send requests to the servers of card organization 1 and card organization 3 respectively. This allows the system to continue processing other tasks without waiting for either request to complete, reducing server waiting time, improving the processing speed of registration requests, and enabling efficient batch submission of cross-card organization activities, thus enhancing the user registration experience. This also solves the inefficiency problem caused by serial processing of cross-card organization registrations and avoids operation interruptions due to page redirects.

[0118] In one possible implementation, the method further includes:

[0119] We receive activity registration information from multiple credit card organizations. The activity registration information includes the status code and the corresponding data for the status code. The data corresponding to the status code includes the reason for the registration failure or the activity for which the registration was successful.

[0120] If the status code indicates that the registration failed, the reason for the registration failure will be displayed on the visual interface.

[0121] If the status code indicates successful registration, the successfully registered event will be displayed on the visualization interface.

[0122] To address the issue of information gaps caused by fragmented feedback of registration results across different card organizations, a centralized display mechanism is implemented to allow users to quickly understand the registration status of all activities, avoid operational confusion caused by fragmented feedback, and improve user experience.

[0123] Specifically, the system receives status codes returned by each card organization's server in real time, such as status code -200 and status code -400. Status code 200 indicates successful registration, while status code 400 indicates failure. For example, if card organization 1 returns a status code of 200 among the registration statuses received from multiple credit card organizations, then registration for activity A1 is confirmed as successful. The status code is then mapped to the user-understandable visual message "Registration Successful," and the successfully registered activity is displayed on the visual interface as "Activity A1 Registration Successful."

[0124] This embodiment provides a method for processing multi-card organization data. It determines a user's card information and the user's selected first target activity. The card information includes card type and card status. It then determines the corresponding benefit activity information for each card type. Based on the card type, card status, and benefit activity information, it filters the user's cards to obtain cards that match the benefit activity information. The method matches the cards matching the benefit activity information with the user's selected first target activity, generating activity registration request data. This data includes multiple second target activity registration requests and their corresponding card organization servers. Finally, it sends the second target activity registration requests to the corresponding card organization servers using asynchronous threads in parallel, thus completing the user's registration for the second target activity. This solution reduces the burden of manual selection for users by filtering cards from the user's possession based on benefit activity information, achieving centralized processing of cross-card organization benefit activities, significantly reducing user operational complexity, and improving registration efficiency. Simultaneously, by using asynchronous threads in parallel, it synchronously sends registration requests to multiple card organization servers, eliminating the need for repeated user operations and reducing the risk of registration failure due to manual input errors or page redirection.

[0125] Figure 4 This is a schematic diagram of the structure of a multi-card organization data processing device provided in this application, as shown below. Figure 4 As shown, the multi-card organization data processing device 400 provided in this embodiment includes:

[0126] The acquisition module 401 is used to determine the user's card information and the first target activity selected by the user. The card information includes card type and card status.

[0127] The filtering module 402 is used to determine the benefit activity information corresponding to the card type; based on the card type, card status and benefit activity information, the user's cards are filtered to obtain cards that meet the benefit activity information;

[0128] Processing module 403 is used to match the cards that meet the rights and benefits activity information with the first target activity selected by the user, and generate activity registration request data. The activity registration request data includes multiple second target activity registration requests and the corresponding card organization server.

[0129] The processing module 403 is also used to send the second target activity registration request to the card organization server corresponding to the second target activity in parallel via an asynchronous thread, so as to complete the user's second target activity registration.

[0130] In one possible implementation, the processing module 403 is further configured to:

[0131] Obtain activity information from multiple card organizations, including the activities and conditions for each card organization.

[0132] The activities and conditions corresponding to each card organization are standardized to obtain the benefits and activities information;

[0133] The information on benefits and activities is stored in a database so that the corresponding information can be retrieved from the database when filtering user cards.

[0134] In one possible implementation, the processing module 403 is further configured to:

[0135] Obtain the user's card information, current activity data corresponding to the activity, and the user's historical transaction data;

[0136] Based on the user's card information, current activity data, and historical transaction data, determine the primary weight for each activity.

[0137] The activities are sorted in descending order according to their respective weights and displayed on the visualization interface so that users can select their first target activity.

[0138] In one possible implementation, the processing module 403 is further configured to:

[0139] Based on the user's card information and current activity data, determine the second weight for each activity;

[0140] User transaction features are extracted from historical transaction data to obtain user transaction features; based on user transaction features and current activity data, the user preference weight corresponding to each activity is determined.

[0141] Based on the second weight and the user preference weight, the first weight corresponding to each activity is determined.

[0142] In one possible implementation, the filtering module 402 is further configured to:

[0143] Determine if the card is valid. If the card is valid, then the card is eligible for the benefits / activities.

[0144] And / or,

[0145] Determine if the card type is a preset card type. If the card type is a preset card type, then the card is determined to meet the requirements of the benefit activity information.

[0146] In one possible implementation, the processing module 403 is further configured to:

[0147] We receive activity registration information from multiple card organizations. The activity registration information includes a status code and the corresponding data. The data corresponding to the status code includes the reason for the registration failure or the activity for which the registration was successful.

[0148] If the status code indicates that the registration failed, the reason for the registration failure will be displayed on the visual interface.

[0149] If the status code indicates successful registration, the successfully registered event will be displayed on the visualization interface.

[0150] The multi-card tissue data processing device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0151] Figure 5 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0152] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0153] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0154] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method; its implementation principle and technical effect are similar and will not be described in detail here.

[0155] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the technical solution of the above method embodiments. Its implementation principle and technical effects are similar, and will not be repeated here.

[0156] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0157] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0158] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0159] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0160] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0161] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 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 of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0162] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0163] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0164] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for processing multi-card organization data, characterized in that, include: Determine the user's card information and the user's selected first target activity, wherein the card information includes card type and card status; Determine the benefits and activities corresponding to the card type; Based on the card type, card status, and benefits / activities information, the user's cards are filtered to obtain cards that match the benefits / activities information; The card that meets the rights and benefits activity information is matched with the first target activity selected by the user to generate activity registration request data. The activity registration request data includes multiple second target activity registration requests and corresponding card organization servers. The second target activity registration request is sent to the card organization server corresponding to the second target activity via an asynchronous thread to complete the user's registration for the second target activity.

2. The method according to claim 1, characterized in that, The method further includes: Obtain activity information from multiple card organizations, including the activities and conditions corresponding to each card organization; The activities and conditions corresponding to each card organization are standardized to obtain the benefits and activities information; The information on the benefits and activities is stored in a database so that when filtering a user's card, the corresponding information on the benefits and activities can be retrieved from the database.

3. The method according to claim 2, characterized in that, The process of determining the user's card information and the user's selected first target activity includes: Obtain the user's card information, current activity data corresponding to the activity, and the user's historical transaction data; Based on the user's card information, current activity data, and historical transaction data, a first weight is determined for each activity. The activities are sorted in descending order according to their respective weights and displayed on the visualization interface so that users can select their first target activity.

4. The method according to claim 3, characterized in that, The information is based on the user's card information, the current activity data, and the user's historical transaction data. Determine the primary weight for each activity, including: Based on the user's card information and the current activity data, determine the second weight corresponding to each activity; The user's historical transaction data is used to extract features to obtain user transaction features; based on the user transaction features and the current activity data, the user preference weight corresponding to each activity is determined. Based on the second weight and the user preference weight, a first weight is determined for each activity.

5. The method according to claim 1, characterized in that, The step of filtering user cards based on the card type, card status, and benefit activity information to obtain cards that meet the benefit activity information includes: determining whether the card status is within a valid period; if the card status is within a valid period, then determining that the card meets the benefit activity information. And / or, Determine whether the card type is a preset card type. If the card type is a preset card type, then determine that the card conforms to the benefit activity information.

6. The method according to claim 1, characterized in that, The method further includes: The system receives activity registration information from multiple card organizations. The activity registration information includes a status code and the data corresponding to the status code. The data corresponding to the status code includes the reason for the registration failure or the activity for which the registration was successful. If the status code indicates that the registration failed, the reason for the registration failure will be displayed on the visualization interface. If the status code indicates successful registration, the successfully registered event will be displayed on the visualization interface.

7. A processing apparatus for multi-card organization data, characterized in that, include: The acquisition module is used to determine the user's card information and the first target activity selected by the user. The card information includes card type and card status. The filtering module is used to determine the benefits and activities corresponding to the card type; Based on the card type, card status, and benefits / activities information, the user's cards are filtered to obtain cards that match the benefits / activities information; The processing module is used to match the card that meets the rights and benefits activity information with the first target activity selected by the user, and generate activity registration request data. The activity registration request data includes multiple second target activity registration requests and corresponding card organization servers. The processing module is also used to send the second target activity registration request to the card organization server corresponding to the second target activity via an asynchronous thread, so as to complete the user's registration for the second target activity.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 6.

Images