Ticket credit management and control method and system

Abstract

The invention discloses a ticket credit management and control method and system. The method comprises the following steps: receiving a to-be-synchronized limit list and an associated routing identifier of a first ticket server; wherein the to-be-synchronized limit list comprises a grey list and a black list; the routing identifier comprises an identifier of a server needing to synchronize the to-be-synchronized limit list; pre-configured message subscription modes of a plurality of message queues are obtained, and each message queue is associated with one type of ticket service servers; the message subscription mode comprises a target server identifier; when the routing identifier is matched with the message subscription mode, distributing the to-be-synchronized limit list to a message queue of which the message subscription mode is matched with the routing identifier; and synchronizing the to-be-synchronized limit list in the message queue to a corresponding second ticketing server. Through a real-time synchronization mechanism based on the message queue, the risk user information (grey / black list) identified by any channel or venue can be synchronized to all ticket sales channels.

Description

Technical Field

[0001] This application relates to the field of ticketing technology, and in particular to a ticketing credit management method and system. Background Technology

[0002] Currently, in the field of ticketing management, with the diversification of sales channels and the decentralization of venue resources, traditional user credit and risk control systems are facing severe challenges. Various ticketing sales channels (such as self-operated mini-programs, third-party OTA platforms, offline ticket windows, etc.) and different venues (such as science museums, museums, planetariums, etc.) usually adopt independent or closed user management and risk control systems, resulting in the problem of "data silos" of risk information.

[0003] Therefore, existing technologies lack a way to synchronize high-risk user information while ensuring the independence and stability of systems across different channels and venues. This makes it difficult for ticketing operators to build an effective global joint prevention and control system, failing to create sufficient deterrence against violators. This not only harms the interests of operators (such as wasted resources and lost revenue) but also affects the fair ticketing experience and resource access opportunities for other compliant users. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a ticketing credit management method and system.

[0005] Firstly, this application provides a ticketing credit control method, including: Receive the list of restricted servers to be synchronized and the associated routing identifiers from the first ticketing server; wherein, the list of restricted servers to be synchronized includes a gray list and a black list; the routing identifier includes the identifier of the server whose list of restricted servers to be synchronized needs to be synchronized. Obtain the pre-configured message subscription mode for each of multiple message queues, with each message queue associated with a type of ticketing server; the message subscription mode includes the target server identifier. When the routing identifier matches the message subscription pattern, the list of restrictions to be synchronized is distributed to the message queues whose message subscription patterns match the routing identifier. The list of restrictions to be synchronized in the message queue is synchronized to the corresponding second ticketing server; wherein the second ticketing server includes one or more types of ticketing servers.

[0006] In one implementation, the ticketing credit control method further includes: The cumulative number of non-fulfillment behaviors of target users within a first preset statistical period is counted; wherein, the non-fulfillment behavior refers to ticket refund behavior that occurs within the preset observation period; When the cumulative number of times reaches a first preset threshold, a gray list record of the target user is generated; If, within the first preset validity period of the gray list, the cumulative number of new non-compliance behaviors of the target user is detected to reach a second preset threshold, a blacklist record of the target user is generated; wherein, the blacklist record has a second preset validity period, which is longer than the first preset validity period; In response to the generation of the gray list or black list records, the generation and transmission of the restricted list to be synchronized are triggered.

[0007] In one implementation, the ticketing credit control method further includes: If no new non-compliance behavior is detected within the first preset validity period, the target user will be removed from the gray list and a new gray list record will be generated. If, within the first preset validity period, the cumulative number of new non-compliance behaviors detected by the target user does not reach the second preset threshold, the gray list record of the target user is retained.

[0008] In one implementation, the ticketing credit control method further includes: Upon receiving the request to remove a record from the blacklist, the user is required to input and verify the authorization credentials of the operator who initiated the request. After successful verification of the authorization credentials, the target user is removed from the blacklist, and a new list of restricted users to be synchronized is generated. The system persistently stores the removal operation log, which includes: the removal operation time of the gray list and black list, the target user identifier, the reason for removal, the operator identifier, and the authorization timestamp.

[0009] In one implementation, the ticketing credit control method further includes: After sending the list of restricted items to be synchronized, the first ticketing server waits for and verifies the confirmation receipt of the list of restricted items to be synchronized; when executing the main refund business process, the first ticketing server asynchronously executes the synchronization processing of the list of restricted items to be synchronized. When the second ticketing server receives the synchronization message for the restricted list to be synchronized, if the unique identifier of the synchronization message exists in the processed message record table, the synchronization of the restricted list to be synchronized has been completed; if it does not exist, the restricted list to be synchronized is synchronized and the unique identifier is recorded.

[0010] In one implementation, the ticketing credit control method further includes: When the first ticketing server sends the list of restrictions to be synchronized, a network failure occurs, and the list of restrictions to be synchronized is persisted to the database.

[0011] In one implementation, the ticketing credit control method further includes: In response to a user's ticket booking request, a restricted list is read from a cache storage device to identify whether the user is on the restricted list; wherein, the cache storage device caches the restricted list from the database; the restricted list includes the gray list and the black list; When it is determined that the user is not on the restricted list, order information is generated and stored; the order information includes user ID, date of action, and order number; When a user is identified as belonging to the restricted list, the user's identity information is required to be entered and verified; after the identity information is verified, order information is generated and stored.

[0012] In one implementation, the ticketing credit control method further includes: Define multiple business configuration dimensions, including ticketing type dimension, ordering channel dimension, and user identifier dimension; Each business dimension combination provides an independent rule parameter set configuration interface; different rule parameters can be configured for different business application scenarios. The rule parameter set includes at least a preset observation period, a first preset statistical period, a first preset threshold, a second preset threshold, a first preset validity period, and a second preset validity period.

[0013] Secondly, this application provides a ticketing credit control system, including: A subscription message exchange is configured to receive a list of restricted items to be synchronized and associated routing identifiers from a first ticketing server; wherein the list of restricted items to be synchronized includes a gray list and a black list; the routing identifier includes the identifier of the server that needs to synchronize the list of restricted items; and the server identifier includes at least one server category identifier. The subscription message exchange is also configured to obtain pre-configured message subscription modes for multiple message queues, each message queue being associated with a type of second ticketing server; the message subscription mode includes a target server identifier. The subscription message exchange is further configured to distribute the list of restrictions to be synchronized to the message queues whose message subscription patterns match the routing identifier when the routing identifier matches the message subscription pattern. The subscription message exchange is further configured to synchronize the list of restrictions to be synchronized in the message queue to the corresponding second ticketing server; wherein the second ticketing server includes one or more types of ticketing servers.

[0014] In one implementation, the ticketing credit control system also includes: The first ticketing server is configured to count the cumulative number of non-fulfillment behaviors of target users within a first preset statistical period; wherein, the non-fulfillment behavior refers to ticket refund behavior that occurs within the preset observation period; The first ticketing server is also configured to generate a gray list record of the target user when the cumulative number of times reaches a first preset threshold. The first ticketing server is also configured to generate a blacklist record for the target user if the cumulative number of new non-performance behaviors detected by the target user reaches a second preset threshold within the first preset validity period of the gray list. The blacklist record has a second preset validity period and is longer than the first preset validity period. In response to the generation of the gray list or black list records, the generation and transmission of the restricted list to be synchronized are triggered.

[0015] Compared with the prior art, this application has at least one of the following beneficial effects: This application utilizes a message queue-based synchronization mechanism to synchronize gray / black lists to all ticketing sales channels (including different channels for the same ticket type and different channels for different ticket types), ensuring that risky user information identified by any channel or venue is protected. This allows for real-time interception before seat locking or payment when a user attempts to purchase tickets on any platform, achieving a closed-loop control system of "one violation, restrictions everywhere," completely eliminating opportunities for cross-platform arbitrage by violators.

[0016] This application replaces the traditional, sluggish process that relies on manual screening, calculations, and back-end operations by constructing an automated risk control chain. Leveraging high-speed caching, it can complete behavior determination, list triggering, and synchronization when a user cancels a ticket, enabling immediate and precise crackdowns on scalping, malicious ticket hoarding, and other similar behaviors. This not only improves risk handling efficiency and eliminates human error and delays but also significantly reduces operational labor costs, transforming risk control management from a passive response to proactive intelligent interception.

[0017] This application introduces a "grey list" as a buffer layer for tiered risk control, achieving a balance between control intensity and user experience through dynamic credit management: on the one hand, it gives first-time or minor violators a chance to correct their behavior, and the list is automatically removed and credit is restored upon expiration, reflecting humane governance; on the other hand, it automatically upgrades persistent malicious violations (such as being on the gray list twice) to the "blacklist" for long-term restrictions, both warning ordinary users and accurately cracking down on stubborn violators, thereby enhancing the credibility and deterrent effect of the rules while building a more flexible and intelligent risk prevention and control system.

[0018] All key operations, such as the removal of individuals from gray and black lists, in this application have been fully recorded and formed into an audit trail. This greatly facilitates operational inquiries, liability determination, dispute review, and compliance audits, providing a data foundation for continuous optimization of risk control strategies.

[0019] This application provides a highly flexible, visual rule configuration interface and a multi-dimensional rule engine. Through differentiated parameter settings for channels, venues, ticket types, user identities, and behavioral characteristics (such as refund time), it can accurately identify different types of behavior, such as legitimate refunds and malicious seat hogging, thereby supporting refined operations. Simultaneously, it enhances the system's adaptability and scalability, dynamically responding to seasonal passenger flow changes, special event needs, and differentiated ticket management, truly achieving business-driven, flexibly configurable risk control governance. Attached Figure Description

[0020] The accompanying drawings used in the description of the embodiments of this application are briefly introduced below: Figure 1 This is a flowchart of a ticketing credit management method provided in an embodiment of this application; Figure 2 This is another flowchart of the ticketing credit control method provided in the embodiments of this application; Figure 3 This is another flowchart of the ticketing credit control method provided in the embodiments of this application; Figure 4 This is another flowchart of the ticketing credit control method provided in the embodiments of this application; Figure 5 This is a schematic diagram of a ticketing credit management system provided in an embodiment of this application; Figure 6 This is another block diagram of the ticketing credit management system provided in the embodiments of this application. Detailed Implementation

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the specific implementation methods of this application will be described below with reference to the accompanying drawings. The drawings and implementation methods described below are merely some embodiments of this application. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings and implementation methods without creative effort. Any adjustments and improvements made without departing from the concept of this application are within the protection scope of this application.

[0022] To keep the drawings concise, only the parts relevant to this application are shown schematically in each drawing, and they do not represent the actual structure of the product. In addition, to make the drawings concise and easy to understand, some parts with the same structure or function are only shown schematically in some drawings, and there may actually be more or fewer parts with the same structure or function.

[0023] In this application, unless otherwise expressly specified and limited, ordinal numbers, such as "first" and "second," are used only to distinguish and describe related objects, and should not be construed as indicating or implying the relative importance or order between related objects; furthermore, they do not represent the number of related objects. The terms "installation" and "connection" should be interpreted broadly; for example, "installation" can mean direct installation or installation via other components; "connection" can mean direct connection or connection via other components.

[0024] Currently, in the field of ticketing management, with the diversification of sales channels and the decentralization of venue resources, traditional user credit and risk control systems are facing severe challenges. Various ticketing sales channels (such as self-operated mini-programs, third-party OTA platforms, offline ticket windows, etc.) and different venues (such as science museums, museums, planetariums, etc.) usually adopt independent or closed user management and risk control systems, resulting in the problem of "data silos" of risk information.

[0025] For example, when a user commits serious violations (such as multiple unfulfilled reservations, malicious ticket hoarding, or purchasing tickets with false information) on a specific channel (e.g., an OTA platform) or at a specific venue (e.g., a science museum) and is identified as a high-risk user (e.g., placed on a gray or blacklist), the user's risk status and control instructions cannot be effectively synchronized to other ticketing channels or related venues. Due to the lack of a unified global risk information synchronization mechanism, violating users can still successfully purchase tickets on other channels or venues that have not received synchronized information (e.g., mini-programs, other OTA platforms, or on-site ticket windows), rendering the control measures for high-risk users ineffective.

[0026] Therefore, existing technologies lack a way to synchronize high-risk user information while ensuring the independence and stability of systems across different channels and venues. This makes it difficult for ticketing operators to build an effective global joint prevention and control system, failing to create sufficient deterrence against violators. This not only harms the interests of operators (such as wasted resources and lost revenue) but also affects the fair ticketing experience and resource access opportunities for other compliant users.

[0027] To address the aforementioned issues, this application provides a ticketing credit control method and system. The server of any ticketing sales channel (such as a mini-program or OTA platform) or any venue (such as a science museum or museum) identifies and generates a list of high-risk users (such as a gray list or black list) locally, and then synchronizes this list information to all associated terminal business systems. This solves the problem of the inability to share risk information under traditional distributed architectures, integrating the previously isolated risk control capabilities of various channels and venues into a coordinated and consistent joint prevention and control network.

[0028] The following explanation is based on the accompanying drawings: like Figure 1 As shown, this application provides a ticketing credit control method, including: S210, Receive the list of restrictions to be synchronized and the associated routing identifier from the first ticketing server; wherein, the list of restrictions to be synchronized includes a gray list and a black list; the routing identifier includes the server identifier of the list of restrictions to be synchronized; the server identifier includes at least one type of server identifier.

[0029] S220. Obtain the pre-configured message subscription mode for each of the multiple message queues. Each message queue is associated with a type of ticketing server. The message subscription mode includes the target server identifier.

[0030] S230. When the routing identifier matches the message subscription pattern, the list of restrictions to be synchronized is distributed to the message queues whose message subscription patterns match the routing identifier.

[0031] S240. Synchronize the list of restrictions to be synchronized in the message queue to the corresponding second ticketing server; wherein, the second ticketing server includes one or more types of ticketing servers.

[0032] In this embodiment, a ticketing system with multiple venues (such as science and technology museums, natural history museums, and planetariums) and multiple sales channels (such as self-operated mini-programs and third-party OTA platforms) is used as an example. Figure 6 As shown. The online ticketing system is deployed according to venue type: systems for venues of the same type share a single online server, while systems for different types of venues are deployed on different offline servers. The offline ticketing system is deployed independently for each venue, meaning each venue's offline system has its own offline server. If a user makes three consecutive ticket reservations on the science museum's self-operated mini-program (corresponding to the science museum's online server), and then cancels a ticket within a preset observation period (i.e., a "non-fulfillment"), the first ticketing server (i.e., the science museum's online server) determines, based on preset rules (such as "three non-fulfillments within 180 days"), that the first user must be added to a "gray list," generating a list of users to be synchronized and restricted.

[0033] The science museum's online server constructs associated routing identifiers based on the scope of the restriction list to be synchronized. For example, the restriction list to be synchronized needs to be synchronized to all natural history museum servers ( Figure 6 The term "Zibo Server" is used to refer to servers for natural history museums (both online and offline), and all planetarium servers (both online and offline). This allows natural history museums and planetariums to intercept the first user during ticket sales. The generated routing identifier (tw.zb) includes: the planetarium server category identifier (tw) and the natural history museum server category identifier (zb). The science museum's online server publishes the list of restricted users to be synchronized along with the routing identifier to the subscription message exchange in the central message queue service.

[0034] The central message queue service pre-configures multiple message queues, which are bound to a subscription message exchange via binding keys to implement a message subscription pattern based on the target server type. Each message queue is associated with a type of ticketing server, and the type identifier of the ticketing server is implicitly contained in the message subscription pattern of the binding key. For example, the binding key (Binding Key=#.tw.#) of message queue A (Queue Astronomy) corresponds to a planetarium server. The binding key (Binding Key=#.zb.#) of message queue B (Queue Natural History Museum) corresponds to a natural history museum server. The binding key (Binding Key=#.kj.#) of message queue C (Queue Science and Technology) corresponds to a science and technology museum server. The "Pending Synchronization Restriction List" message is matched by the subscription message exchange according to the message subscription pattern based on its carried routing identifier and then distributed to the corresponding target queue.

[0035] After receiving the "List of Restricted Users to be Synchronized" message and the routing identifier tw.zb, the subscription message exchange matches the routing identifier tw.zb with the binding keys of all queues; that is, it successfully matches the binding key #.tw.# of message queue A and the binding key #.zb.# of message queue B, but fails to match the binding key #.kj.# of message queue C. Based on the matching results, the "List of Restricted Users to be Synchronized" message carrying the first user as a graylist is delivered to message queues A and B. Message queue A distributes the list of restricted users to planetarium-type servers (i.e., the second ticketing server or the planetarium's online / offline server); message queue B distributes the list of restricted users to natural history museum-type servers (i.e., the second ticketing server or the natural history museum's online / offline server). All planetarium servers and all natural history museum servers update the first user's information and its restricted list to their local cache storage device or database; in this restricted list, the first user is on the graylist.

[0036] All planetarium servers associated with message queue A (i.e., one online planetarium server and multiple offline planetarium servers) continuously listen to message queue A. When a new message appears in message queue A, all planetarium servers retrieve the list of restrictions to be synchronized. All natural history museum servers associated with message queue B (i.e., one online natural history museum server and multiple offline natural history museum ticketing servers) continuously listen to message queue B. When a new message appears in message queue B, all natural history museum servers retrieve the list of restrictions to be synchronized.

[0037] When the first user on the gray list attempts to purchase tickets through the Natural History Museum's official WeChat account or the Planetarium's online travel agency (OTA) partner platform, the Natural History Museum's online server checks the local restricted list during the ticket purchase process. Upon discovering the first user's gray list status, the system rejects the first user's ticket purchase request or requires the first user to complete the credit repair process, thus achieving real-time interception across channels and venues.

[0038] If the graylist of the online ticketing system for science museums only needs to be synchronized to the offline ticketing system for similar science museums, and not to other types of ticketing servers such as museums, a routing identifier, such as kj (representing science and technology venues), can be used. In this case, only message queues with binding keys in the pattern #.kj.# can be successfully matched, thus achieving targeted synchronization. If a blacklisted user needs to be simultaneously prohibited from purchasing tickets for all venues and all transportation tickets (such as train tickets and plane tickets), the primary ticketing server can generate a routing identifier that can simultaneously match message queues subscribed to venue tickets and message queues subscribed to transportation tickets, achieving batch synchronization to multiple servers of different categories.

[0039] In one implementation, such as Figure 2 As shown, before receiving the list of restrictions to be synchronized and the associated route identifier from the first ticketing server in step S210, the process further includes: S110. Count the cumulative number of non-performance behaviors of target users within the first preset statistical period; where non-performance behavior refers to ticket refund behavior that occurs within the preset observation period.

[0040] S120. When the cumulative number of times reaches the first preset threshold, a gray list record of the target user is generated.

[0041] S130. If, within the first preset validity period of the gray list, the cumulative number of new non-compliance behaviors of the target user is detected to reach the second preset threshold, a blacklist record of the target user is generated. The blacklist record has a second preset validity period, which is longer than the first preset validity period.

[0042] S140. In response to the generation of gray list or black list records, trigger the generation and sending of the restriction list to be synchronized.

[0043] In this embodiment, the ticketing system (or ticketing server) of each venue continuously monitors users' ticket purchase and fulfillment behavior. Taking the planetarium as an example, when a second user (i.e., the target user) purchases a planetarium ticket, the system continuously tracks the second user's activity. If it is detected that the second user completes a ticket refund operation within a preset observation period (such as 48 hours before the visit date to 7 days after the visit date) (whether through self-service refund via a mini-program or by contacting customer service), this behavior is marked as a "non-fulfillment behavior".

[0044] The system calculates the total number of non-fulfillment transactions by the second user within a first preset statistical period (e.g., 180 days). Simultaneously, it automatically cleans up second user records older than the first preset statistical period to ensure timely statistics. The system periodically (e.g., daily) or in real-time scans the cumulative number of non-fulfillment transactions by the second user. When the cumulative number of non-fulfillment transactions by the second user reaches a first preset threshold (e.g., 3 times), a gray list record for that second user is automatically created. This record includes the second user ID, list type (gray list), trigger reason ("3 refunds within 180 days"), effective time (current time), and a first preset validity period (e.g., "locked for 60 days after the current time").

[0045] Within the first preset validity period (e.g., 60 days) of the gray list record, the second user's non-compliance behavior continues to be monitored. If the cumulative number of new non-compliance behaviors detected by the second user within the gray list validity period reaches the second preset threshold (e.g., 1 or 3 times), the gray list record is upgraded to a blacklist record. The blacklist record has a second preset validity period (e.g., "permanently effective," or a very long period such as 365 days), and the second preset validity period is longer than the first preset validity period. The second preset threshold and the first preset threshold can be the same or different.

[0046] When a graylist record (or blacklist record) is generated, the process of generating and sending a restricted list to be synchronized is immediately triggered. The newly generated graylist or blacklist record is encapsulated into a "restricted list to be synchronized" message. Following the synchronization mechanism described in the preceding embodiments, for example, the planetarium ticketing system generates a "restricted list to be synchronized" message, attaches a routing identifier (such as kj.zb) to the message, and publishes it to the central message queue. Subsequently, the "restricted list to be synchronized" message is distributed to the Natural History Museum server and the Science and Technology Museum server through a subscription message exchange and message queue. After receiving the restricted list to be synchronized, the Natural History Museum server and the Science and Technology Museum server update the user information and their graylist (or blacklist) to their local cache storage device or database. When a second user listed on the graylist (or blacklist) attempts to purchase any type of ticket on any platform, the corresponding ticketing server, during the ticket purchase process, queries the local restricted list to discover the second user's graylist (or blacklist) status, thereby rejecting the second user's ticket purchase request or requiring the second user to complete a credit repair process.

[0047] In one embodiment, the ticketing credit control method further includes: if no new non-performance behavior of the target user is detected within a first preset validity period, removing the target user from the gray list and generating a new gray list record.

[0048] If, within the first preset validity period, the cumulative number of new non-compliance behaviors detected by the target user does not reach the second preset threshold, the gray list record of the target user will be retained.

[0049] In this embodiment, taking the planetarium ticketing system as an example, if a target user (such as Li Si) is detected to have engaged in multiple "ticket refunds within the observation period" (i.e., non-fulfillment of obligations) within a first preset statistical period (e.g., "the last 180 days") and this exceeds a first preset threshold (e.g., 3 times), Li Si will be added to a gray list. Within the first preset validity period of the gray list (e.g., 60 days), Li Si's ticket purchase and fulfillment behavior will be continuously monitored to analyze whether he has engaged in ticket refunds (i.e., "non-fulfillment of obligations") within the "preset observation period".

[0050] If Li Si does not commit any new breach of contract within the first preset validity period of the gray list, the planetarium ticketing system will automatically remove Li Si's gray list record on the expiration date. The change in Li Si's gray list status will immediately trigger a synchronization mechanism, generating a new "Pending Synchronization Restriction List" synchronization message. This list will include Li Si, who has already been removed from the gray list. The "Pending Synchronization Restriction List" will be distributed to all relevant ticketing servers via a message queue. Each server will update its local restriction list based on the new "Pending Synchronization Restriction List," and Li Si's ticket purchase restrictions will be lifted.

[0051] If, within the first preset validity period of the gray list, a new non-compliance behavior is detected in Li Si, and the cumulative number of such new non-compliance behaviors does not reach the trigger condition of the blacklist (i.e., the second preset threshold), then Li Si's gray list record is retained; only this non-compliance behavior is accumulated, without changing Li Si's gray list status or validity period. If the cumulative number of new non-compliance behaviors exceeds the second preset threshold, Li Si is directly added to the blacklist; or, Li Si's gray list status is extended from the first preset validity period to the second preset validity period (e.g., 180 days), where the second preset validity period is longer than the first preset validity period. If operations such as extending the validity period of the gray list are taken, a new "Pending Synchronization Restricted List" synchronization message (such as status and validity period changes) will be generated and distributed to each server through a message queue. Each server updates its local restricted list according to the new "Pending Synchronization Restricted List".

[0052] By distinguishing between three situations—"no new non-compliance behavior," "new non-compliance behavior but not meeting the blacklist criteria," and "new non-compliance behavior meeting the blacklist criteria"—and correspondingly handling them with three actions—"removal," "maintenance / moderate strengthening," and "upgrade"—the severity of punishment for graylist users has been refined and differentiated.

[0053] In one implementation, such as Figure 3 As shown, the ticketing credit control method also includes: S310. When a request to remove a blacklisted record is received, the user is required to enter and verify the authorization credentials of the operator who initiated the request.

[0054] S320. After successful verification of the authorization credential, the target user is removed from the blacklist, and a new list of restricted users to be synchronized is generated.

[0055] S330. Persistently store the removal operation log. The removal operation log includes: the removal operation time of the gray list and black list, the target user ID, the removal reason, the operator ID, and the authorization timestamp.

[0056] In this embodiment, the blacklist is manually intervened. When an individual user is mistakenly blacklisted for reasons beyond their control, the user can be manually removed from the blacklist. For example, a user might be mistakenly identified as someone else, resulting in their account being associated with non-compliance and being mistakenly blacklisted. After the user appeals, it is verified that the misjudgment was indeed made, and the user needs to be removed from the blacklist.

[0057] Upon receiving a request to remove a blacklist record, the blacklist record of the target user can be located in the "Blacklist Management" interface by user ID or mobile phone number. When performing the deletion operation, an authentication page for the "Blacklist Record Removal Request" pops up. This page requires the input of the "operator's authorization credentials" (e.g., a secondary password, dynamic token, or a call to a specific approval workflow interface) to verify the validity of the authorization credentials.

[0058] The removal operation is only performed after the authorization credentials are successfully verified, removing the user from the blacklist. Furthermore, all key information from this removal operation is persistently stored in the audit database as a "Removal Operation Log." The "Removal Operation Log" can also record related operations for removing users from the gray list. The log includes at least: the specific time of the removal operation, the target user's ID, the reason for removal, the employee ID of the operator performing the removal, and the timestamp of successful authorization credential verification. This ensures that all modifications to the blacklist are traceable and auditable, meeting compliance requirements.

[0059] Optionally, two-factor authentication can be configured. After successful operator authentication, it is recorded as Level 1 authorization, generating a removal work order pending approval with a status of "awaiting Level 2 authorization," and the target user remains on the blacklist. The pending removal work order is then pushed to the workbench of the risk control administrator with higher privileges. Upon receiving the task, if the risk control administrator agrees to the removal, they click the "Approve and Execute" button, which pops up a Level 2 authorization verification window, requiring the risk control administrator to enter their personal password or complete other authentications. If the risk control administrator refuses, they can fill in the rejection reason, the process terminates, and the blacklist status remains unchanged. After the risk control administrator completes identity verification (Level 2 authorization) and approves, confirming that the "two-factor authentication" process has been completed and is effective, the target user is removed from the blacklist. Simultaneously, a new "Pending Synchronization Restricted List" message is generated, indicating that the target user has been removed from the blacklist; this message is sent in real-time to all relevant ticketing servers via message queues to ensure that the restricted lists on all associated servers are updated.

[0060] Persistent storage of operation logs fully records the personnel, time, reason, and specific operations involved in removing blacklist members, ensuring traceability and accountability. After execution, the blacklist removal operation automatically triggers synchronization with other servers, ensuring consistency of the restricted list and avoiding user experience issues or business risks caused by unsynchronized restricted lists.

[0061] In one implementation, the ticketing credit control method further includes: after sending the list of restricted items to be synchronized, the first ticketing server waits for and verifies the confirmation receipt of the list of restricted items to be synchronized; when executing the main business process of ticket refund, the first ticketing server asynchronously performs the synchronization processing of the list of restricted items to be synchronized.

[0062] When the second ticketing server receives a synchronization message for the restricted list to be synchronized, if the unique identifier of the synchronization message exists in the processed message record table, the synchronization of the restricted list to be synchronized has been completed; if it does not exist, the restricted list to be synchronized is synchronized and the unique identifier is recorded.

[0063] In this embodiment, taking the science museum server (first ticketing server) and the museum server (second ticketing server) as examples: A user purchases a ticket through the science museum's mini-program and applies for a refund close to the opening time. The science museum system executes the refund process, including verifying refund conditions, calculating the refund amount, updating inventory and order status, and invoking payment for the refund. Simultaneously, it determines that this refund action means the user has accumulated 3 refunds within 180 days, triggering the generation of a gray list record, which is then stored locally. For the gray list that needs to be synchronized to the venue server, an asynchronous processing method is used; that is, the newly generated gray list record is encapsulated as a "pending synchronization restricted list" message, a globally unique message ID is added as an identifier, and the local message status is updated to "sending".

[0064] The science museum server sends the "List of Restrictions to be Synchronized" message to the subscription message exchange (a RabbitMQ topic exchange), carrying a routing identifier. After sending, the science museum server waits for an acknowledgment from the subscription message exchange. If a success acknowledgment is received, the status of the "List of Restrictions to be Synchronized" message is updated to "Sent"; if a timeout occurs or a failure acknowledgment is received, the status of the "List of Restrictions to be Synchronized" message remains "Sending," and it continues to resend periodically until successful.

[0065] The museum server listens to the corresponding message queue. Upon receiving a "Pending Synchronization Restricted List" message, it extracts the message ID and queries the local "Processed Message Record Table" for that ID. If the ID already exists, it means the "Pending Synchronization Restricted List" message has been processed, and the synchronization of the restricted list is complete. If the ID does not exist, the corresponding record is inserted or updated in the local gray list table, and the message ID is stored in the "Processed Message Record Table." Other ticketing servers, such as those for the planetarium, also execute the same process in parallel, ultimately achieving consistency of the restricted lists across all museums.

[0066] In one implementation, the ticketing credit control method further includes: when a network failure occurs while the first ticketing server is sending a list of restrictions to be synchronized, the list of restrictions to be synchronized is persisted to the database.

[0067] In this embodiment, when the first ticketing server prepares to send a synchronization message for the restricted list to be synchronized, it first updates the status of the local list record, and then attempts to send the synchronization message (including list data, routing identifier, unique message ID, etc.). If a network interruption or temporary service unavailability occurs, the status of the synchronization message for the restricted list to be synchronized is updated to "sending failed," and the restricted list to be synchronized is stored in the database. Additionally, records with a synchronization message status of "sending failed" or "pending sending" are periodically (e.g., every 30 seconds), and the sending step is retried. When the network connection is restored, the message for the restricted list to be synchronized is successfully sent to the message queue, and an acknowledgment is awaited. Upon receiving the acknowledgment, the status of the synchronization message for the restricted list to be synchronized is updated to "sent."

[0068] In one implementation, such as Figure 4 As shown, the ticketing credit control method also includes: S410, in response to a user's ticket booking request, reads the restricted list from the cache storage device and identifies whether the user is on the restricted list; wherein, the cache storage device caches the restricted list from the database; the restricted list includes a gray list and a black list.

[0069] S420. When it is identified that a user is not on the restricted list, generate and store order information; the order information includes user ID, date of action, and order number.

[0070] S430. When a user is identified as belonging to a restricted list, the user's identity information is required to be entered and verified; after the identity information is verified, order information is generated and stored.

[0071] In this embodiment, when a user purchases tickets online (such as through a self-operated mini-program or a third-party OTA platform), a user credit risk check needs to be completed within a short period to determine whether the user is allowed to place an order. For example, when the museum server (acting as a second ticketing server) receives a user's ticketing request, it queries a cache storage device that stores a restricted list (including a gray list and a black list) synchronized from the database. Using the user identifier (such as user ID), it checks the cache storage device to see if the user is on any restricted list. If the user is not on any restricted list, the user is considered low-risk, an order is generated, and the order information (including user identifier, date of action, unique order number, etc.) is stored in the order database. The purchase result is then returned to the user. If the user is on a restricted list, appropriate restrictions are imposed based on the specific circumstances. For example, if the user is on a gray list, an order is generated normally, and the user is reminded not to engage in any further non-compliance behavior; if the user is on a blacklist, order generation is interrupted, the purchase request is rejected, or the user is required to complete a credit repair process.

[0072] When a user purchases tickets offline (such as at the venue's ticket office), the ticket seller logs into the museum's ticketing system on the server and checks the user's information (such as ID number and mobile phone number) in a cached storage device to see if the user is on a restricted list. If the user is not on the restricted list, the ticket purchase is processed. If the user is on the restricted list, the user is required to enter their identity information, and the authenticity and consistency are verified by calling an authoritative verification interface or comparing it with pre-registered identity information. After the user's identity information is verified, the ticket is purchased for the user.

[0073] In one implementation, the ticketing credit management method further includes defining multiple business configuration dimensions, including ticketing type dimension, ordering channel dimension, and user identification dimension.

[0074] Each business dimension combination provides an independent rule parameter set configuration interface; different business scenarios can be configured with different rule parameters; the rule parameter set includes at least a preset observation period, a first preset statistical period, a first preset threshold, a second preset threshold, a first preset validity period, and a second preset validity period.

[0075] In this embodiment, highly flexible parameterization and differentiation configuration of user credit control rules are supported. During configuration, core business dimensions are first predefined, including channel type (mini-program, on-site, third-party OTA, etc.), venue type (science museum, museum, planetarium, etc.), ticketing type (tickets, movie tickets), and user identification type (mobile phone number, ID number, mini-program ID, etc.). Then, in the rule configuration interface, these dimension conditions can be freely combined, and independent rule parameters (such as statistical period, trigger threshold, etc.) can be set for each combination to achieve precise risk control. The rule parameter set includes at least a preset observation period, a first preset statistical period, a first preset threshold, a second preset threshold, a first preset validity period, and a second preset validity period.

[0076] For example, a dimension combination might be "venue type: cinema, ticket type: movie ticket, ordering channel: partner OTA_A, user identifier type: mobile phone number." The corresponding rule parameter set would be: "preset observation period: 4 hours before opening," "first preset statistical period: 90 days," "first preset threshold: 2 times," "first preset validity period: 90 days," "second preset threshold: 1 time," and "second preset validity period: 180 days." When a user initiates a movie ticket purchase request, after identifying the current business dimension values ​​as "cinema," "movie ticket," "partner OTA_A," and "mobile phone number," the rule parameters corresponding to this dimension combination (such as the first preset statistical period of 90 days and the first preset threshold of 2 times) are loaded. Based on these rule parameters, it is determined whether the user meets the conditions for being placed on the restricted list: it is checked whether the user has cancelled tickets 4 hours before opening twice in the past 90 days to determine whether they should be added to the gray list. The preset observation period, first preset statistical period, first preset threshold, second preset threshold, first preset validity period, and second preset validity period can all be adjusted to flexibly adapt to the control intensity requirements of different venues, different time periods, or different marketing strategies.

[0077] In one implementation, such as Figure 5 As shown, a ticketing credit control system includes: The subscription message exchange 200 is configured to receive the list of restrictions to be synchronized and the associated routing identifiers from the first ticketing server 100; wherein the list of restrictions to be synchronized includes a gray list and a black list; the routing identifier includes the server identifier of the list of restrictions to be synchronized; and the server identifier includes at least one server category identifier.

[0078] The subscription message exchange 200 is also configured to acquire pre-configured message subscription modes for multiple message queues, each message queue being associated with a type of ticketing server; the message subscription mode includes a target server identifier.

[0079] The subscription message exchange is also configured to distribute the list of restrictions to be synchronized to the message queues whose message subscription patterns match the routing identifier when the routing identifier matches the routing identifier.

[0080] The subscription message exchange is also configured to synchronize the list of restrictions to be synchronized in the message queue to the corresponding second ticketing server 200; wherein the second ticketing server 200 includes one or more types of ticketing servers.

[0081] Specifically, this embodiment is a system embodiment corresponding to the above method embodiment. For specific effects, please refer to the above method embodiment, which will not be repeated here.

[0082] Based on the foregoing embodiments, a ticketing credit management system further includes: The first ticketing server 100 is configured to count the cumulative number of non-performance behaviors of target users within a first preset statistical period; where non-performance behavior refers to ticket refund behavior that occurs within the preset observation period.

[0083] The first ticketing server 100 is configured to generate a gray list record of the target user when the cumulative number of times reaches a first preset threshold.

[0084] The first ticketing server 100 is also configured to generate a blacklist record for the target user if the cumulative number of new non-performance behaviors detected by the target user reaches a second preset threshold within the first preset validity period of the gray list. The blacklist record has a second preset validity period that is longer than the first preset validity period.

[0085] The first ticketing server 100 is also configured to trigger the generation and sending of the restriction list to be synchronized in response to the generation of gray list or black list records.

[0086] In this embodiment, the functions configured for the first ticketing server and the second ticketing server are the same. Functions such as generating the restricted list, changing its status, and generating orders are all completed on either the first or second ticketing server. For details, please refer to the above method embodiments; they will not be repeated here. As a preferred implementation, the ticketing credit management system further includes: a central server configured to define multiple business configuration dimensions, including ticketing type dimension, ordering channel dimension, and user identifier dimension; providing an independent rule parameter set configuration interface for each business dimension combination; allowing different rule parameters to be configured for different business scenarios; wherein the rule parameter set includes at least a preset observation period, a first preset statistical period, a first preset threshold, a second preset threshold, a first preset validity period, and a second preset validity period.

[0087] It should be noted that the above embodiments can be freely combined as needed. The above are only some embodiments of this application. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principles of this application, and these improvements and modifications should also be considered within the protection scope of this application.

Claims

1. A ticket credit management method, characterized in that, The method comprises: receiving a to-be-synchronized restriction list and an associated routing identifier of a first ticket server; wherein the to-be-synchronized restriction list comprises a gray list and a black list; the routing identifier comprises a server identifier that needs to synchronize the to-be-synchronized restriction list; obtaining a message subscription mode pre-configured for each of a plurality of message queues, each message queue being associated with a type of ticket server; the message subscription mode comprises a target server identifier; when the routing identifier and the message subscription mode are matched, distributing the to-be-synchronized restriction list to a message queue in which the message subscription mode and the routing identifier are matched; synchronizing the to-be-synchronized restriction list in the message queue to a corresponding second ticket server; wherein the second ticket server comprises one or more types of ticket servers.

2. The ticket credit management method of claim 1, wherein, Further comprising: counting a cumulative number of non-performance behaviors of a target user within a first preset statistical period; wherein the non-performance behavior refers to a refund behavior occurring within a preset observation period; when the cumulative number reaches a first preset threshold, generating a gray list record of the target user; within a first preset validity period of the gray list, if it is monitored that the cumulative number of new non-performance behaviors of the target user reaches a second preset threshold, a black list record of the target user is generated; wherein the black list record has a second preset validity period and is longer than the first preset validity period; in response to the generation of the gray list record or the black list record, triggering the generation and sending of the to-be-synchronized restriction list.

3. The ticket credit management method of claim 2, wherein, Further comprising: within the first preset validity period, if it is monitored that the target user does not have new non-performance behaviors, the target user is removed from the gray list, and a new gray list record is generated; within the first preset validity period, if it is monitored that the cumulative number of new non-performance behaviors of the target user does not reach the second preset threshold, the gray list record of the target user is retained.

4. The ticket credit management method of claim 3, wherein, Further comprising: upon receiving a black list record removal request, requiring input and verifying the authorization credentials of an operator initiating the request; after the target user is removed from the black list upon successful authorization credential verification, a new to-be-synchronized restriction list is generated; persistently storing a removal operation log, the removal operation log comprising: removal operation time of the gray list and the black list, target user identifier, removal reason, operator identifier, and authorization timestamp.

5. The ticket credit management method according to any one of claims 1 to 4, wherein, Further comprising: after the first ticket server sends the to-be-synchronized restriction list, the first ticket server waits for and verifies a confirmation reply of the to-be-synchronized restriction list; when the first ticket server executes a refund main business process, the first ticket server asynchronously executes synchronization processing of the to-be-synchronized restriction list; when the second ticket server receives a synchronization message of the to-be-synchronized restriction list, if a unique identifier of the synchronization message exists in a processed message record table, synchronization of the to-be-synchronized restriction list is completed; if not, the to-be-synchronized restriction list is synchronized and the unique identifier is recorded.

6. The ticket credit management method according to any one of claims 1 to 4, wherein Further comprising: when the first ticket server sends the to-be-synchronized restriction list, a network failure occurs, and the to-be-synchronized restriction list is persisted to a database.

7. The ticket credit management method of claim 6, wherein, Further comprising: In response to a ticket booking request of a user, read a restriction list from a cache storage device to identify whether the user is in the restriction list; wherein the cache storage device caches the restriction list from the database; the restriction list includes the gray list and the black list; When it is identified that the user is not in the restriction list, generate and store order information; the order information includes user identification, action date, and order number; When it is identified that the user belongs to the restriction list, require input and verify the identity information of the user; after the identity information is verified, generate and store order information.

8. The method of claim 1-4, wherein, Further comprising: Define a plurality of business configuration dimensions, including a ticket type dimension, a booking channel dimension, and a user identification dimension; Provide an independent rule parameter set configuration interface for each business dimension combination; different business scenarios can apply different configurable rules; Wherein, the rule parameter set at least includes a preset observation period, a first preset statistical period, a first preset threshold, a second preset threshold, a first preset validity period, and a second preset validity period.

9. A ticket credit management system, comprising: Comprising: A subscription message exchange machine configured to receive a to-be-synchronized restriction list of a first ticket server and an associated routing identifier; wherein the to-be-synchronized restriction list includes a gray list and a black list; the routing identifier includes a server identifier that needs to synchronize the to-be-synchronized restriction list; the server identifier includes at least one server category identifier; The subscription message exchange machine is further configured to obtain a plurality of message queues each preconfigured with a message subscription mode; each message queue is associated with a type of second ticket server; the message subscription mode includes a target server identifier; The subscription message exchange machine is further configured to distribute the to-be-synchronized restriction list to a message queue matched with the routing identifier and the message subscription mode when the routing identifier and the message subscription mode are matched; The subscription message exchange machine is further configured to synchronize the to-be-synchronized restriction list in the message queue to the corresponding second ticket server; wherein the second ticket server includes one or more types of ticket servers.

10. The ticket credit management system of claim 9, wherein, Further comprising: A first ticket server configured to count the cumulative number of non-performance behaviors of a target user within a first preset statistical period; wherein the non-performance behavior refers to a refund behavior occurring within a preset observation period; The first ticket server is further configured to generate a gray list record of the target user when the cumulative number reaches a first preset threshold; The first ticket server is further configured to generate a black list record of the target user within a first preset validity period of the gray list if it is monitored that the cumulative number of new non-performance behaviors of the target user reaches a second preset threshold; wherein the black list record has a second preset validity period and is longer than the first preset validity period; In response to the generation of the gray list record or the black list record, trigger the generation and sending of the to-be-synchronized restriction list.

Images