A card manufacturing verification method and system based on object identifier

Abstract

The application relates to the technical field of card manufacturing verification, and discloses a card manufacturing verification method and system based on an object identifier, which comprises the following steps: locking a result lock record based on an order object identifier and a session number; performing unique comparison on the order object identifier, the session number and a result number; judging whether the order object identifier, the session number and the result number have a unique locking relationship based on the number of the order object identifier and the corresponding session number; if the order object identifier, the session number and the result number have a unique locking relationship, performing integrity verification based on the pointing relationship of the order object identifier, the session number, the result number and a version identifier; if the integrity verification is passed, performing association comparison on a printing task number, a card identifier and a verification identifier and the previous result number and the version identifier; and executing a card manufacturing strategy or a card manufacturing blocking strategy based on the association comparison result. The application avoids the risk of inconsistency between a physical card and an order result and the risk of wrong card delivery.

Description

Technical Field

[0001] This invention relates to the field of card verification technology, and more specifically, to a card verification method and system based on object identifiers. Background Technology

[0002] With the widespread adoption of self-service card issuance devices, instant card issuance terminals, and online application for offline card issuance, the card issuance process involves multiple stages, including order generation, payment confirmation, card data generation, print job issuance, card printing, lamination, card issuance, and card retrieval. Existing card issuance systems typically use the order number or print job number as the primary verification criterion. For example, after a user completes payment, the server generates a card issuance task based on the order information and issues the card data and print job to the card issuance terminal. Upon receiving the task, the terminal executes the printing, lamination, and card issuance operations based on the print job number. In actual card issuance scenarios, due to repeated user submissions, concurrent terminal requests, payment callback delays, and re-issuance of card issuance tasks, the same order may trigger the card issuance process repeatedly at different times or in different sessions. If the decision to continue card issuance is based solely on the order status or print job status, it can easily lead to duplicate card issuance results for the same order, or multiple result numbers for the same order. This disrupts the one-to-one correspondence between the order and the card issuance result, ultimately resulting in inconsistencies between the physical card and the order result, and the incorrect issuance of physical cards.

[0003] Therefore, it is necessary to design a card verification method and system based on object identifiers to solve the problems existing in the current technology. Summary of the Invention

[0004] In view of this, the present invention proposes a card production verification method and system based on object identifiers, aiming to solve the problem that judging whether to continue card production based solely on order status or printing task status is prone to generating duplicate card production results for the same order and having multiple result numbers for the same order, thereby disrupting the one-to-one correspondence between the order and the card production result, ultimately leading to inconsistencies between the physical card and the order result and the wrong physical card being issued.

[0005] This invention proposes a card verification method based on object identifiers, comprising: Obtain card production business data, generate order object identifiers and session numbers based on the card production business data, lock records based on query results using the order object identifiers and session numbers, and generate or reuse result numbers based on the query results; A unique association comparison is performed on the order object identifier, the session number, and the result number. Based on the number of the order object identifier and the corresponding session number, it is determined whether there is a unique locking relationship between the order object identifier, the session number, and the result number. The result number is then bound to the version identifier. If there is a unique locking relationship between the order object identifier, the session number, and the result number, then integrity verification is performed based on the pointing relationship between the order object identifier, the session number, the result number, and the version identifier; If the integrity verification passes, a printing task number is assigned and a card identifier and a verification identifier are determined. The printing task number, the card identifier, and the verification identifier are then compared with the preceding result number and the version identifier. Based on the comparison result, a card production strategy or a card production blocking strategy is executed.

[0006] Furthermore, the card manufacturing business data includes: The data includes payment order data, card-issuing user data, card face data, terminal session data, payment completion status, and card version data. The order object identifier is generated based on the payment order data and is used to identify a card issuance transaction. The session number is generated based on the terminal session data and is used to identify a terminal card issuance session.

[0007] Furthermore, when generating or reusing result numbers based on query results, this includes: Using the order object identifier and the session number as search criteria, query the valid lock records in the result lock records; If a valid lock record corresponding to the order object identifier and the session number is found, the record result number in the valid lock record is read and used as the result number of the current card issuance business; If no valid lock record corresponding to the order object identifier and the session number is found, the result number is generated, and the order object identifier, the session number, the result number, the lock status, and the lock time are written into the result lock record.

[0008] Furthermore, when performing a unique association comparison on the order object identifier, the session number, and the result number, the following steps are included: If the order object identifier has only one session number, and the order object identifier and the session number correspond to only one result number, then it is determined that the session number and the result number have a unique locking relationship, and the result number is bound to the version identifier.

[0009] Furthermore, when performing a unique association comparison on the order object identifier, the session number, and the result number, the method further includes: If the order object identifier has multiple session numbers, or the order object identifier and the session number correspond to multiple result numbers, then it is determined that the session number and the result number do not have a unique locking relationship, and there is an abnormal result identifier.

[0010] Furthermore, when binding the result number with the version identifier, it includes: Obtain the card template, card production parameters, and business rules corresponding to the current card production business; generate the version identifier based on the card template, card production parameters, and business rules; and write the version identifier into the result lock record. When a card production request corresponding to the same session number is received again, if the version identifier in the new request is consistent with the version identifier in the result lock record, the locked result number and version identifier are reused. If the version identifier in the subsequent request is inconsistent with the version identifier in the result lock record, it is determined that there is a version mismatch.

[0011] Furthermore, when performing integrity verification based on the pointing relationship between the order object identifier, the session number, the result number, and the version identifier, the process includes: If the order object identifier points to the session number, the session number points to the result number, and the result number points to the version identifier, then the integrity check is deemed to have passed; otherwise, the integrity check is deemed to have failed, and the generation of a print job is prohibited.

[0012] Furthermore, when assigning print job numbers and determining card identifiers and verification identifiers, the following steps are included: Assign the printing task number to the current card production business, bind the printing task number with the result number and the version identifier, read or write the card identifier corresponding to the physical card to be produced, bind the card identifier with the result number and the version identifier, generate a verification identifier corresponding to the card identifier, and bind the verification identifier with the result number and the card identifier.

[0013] Furthermore, when comparing and associating the print task number, the card identifier, and the verification identifier with the preceding result number and version identifier, the process includes: If the print task number, the card identifier, and the verification identifier all point to the same result number, and the version identifier bound to the result number is consistent with the current print data version, then the card production strategy is executed, allowing printing and lamination; otherwise, the card production blocking strategy is executed, prohibiting printing and lamination.

[0014] Compared with existing technologies, the advantages of this invention are as follows: By using the order object identifier and session number, and locking records based on the query results of both, it can prioritize identifying whether a result number already exists when the same order is submitted repeatedly, the terminal makes repeated requests, or payment callbacks are delayed. If a valid locked record already exists, the original result number is directly reused, avoiding the generation of multiple card production results for the same order object and the same session object, thereby ensuring a one-to-one correspondence between orders, sessions, and results. By performing a unique association comparison of the order object identifier, session number, and result number, it can determine whether a unique locking relationship exists based on the number of valid session numbers corresponding to the order object identifier and the number of result numbers, reducing the risk of duplicate physical card production and misissue. Binding the result number to the version identifier ensures the consistency of card templates, card production parameters, and business rules after the result is locked, avoiding version mismatches caused by template updates, old data cached on the terminal, or parameter replacement during the card production process. By associating and comparing the print task number, card identifier, and verification identifier with the preceding result number and version identifier, it can be ensured that the print task, physical card, and verification data all point to the same locked result. This forms a closed-loop verification mechanism from order generation, result locking, version binding, pre-print verification to card production execution, improving the uniqueness, integrity, and traceability of the card production process.

[0015] On the other hand, this application also provides a card verification system based on object identifiers, used to apply the above-mentioned card verification method based on object identifiers, including: The identification management unit is configured to acquire card production business data, generate order object identifiers and session numbers based on the card production business data, lock records based on query results using the order object identifiers and session numbers, and generate or reuse result numbers based on the query results. The first verification unit is configured to perform an association uniqueness comparison on the order object identifier, the session number and the result number, determine whether there is a unique locking relationship between the order object identifier, the session number and the result number based on the number of the order object identifier and the corresponding session number, and bind the result number to the version identifier; The second verification unit is configured to perform integrity verification based on the pointing relationship between the order object identifier, the session number, and the result number if there is a unique locking relationship between them. The third verification unit is configured to assign a printing task number and determine the card identifier and verification identifier if the integrity verification passes, and to compare the printing task number, the card identifier and the verification identifier with the preceding result number and the version identifier, and to execute a card production strategy or a card production blocking strategy based on the comparison result.

[0016] It is understandable that the above-mentioned card verification method and system based on object identifiers have the same beneficial effects, and will not be elaborated further here. Attached Figure Description

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

[0018] Figure 1 A flowchart of a card verification method based on object identifiers provided in an embodiment of the present invention; Figure 2 A logical flowchart for association uniqueness comparison provided in an embodiment of the present invention; Figure 3 This is a functional block diagram of a card verification system based on object identifiers provided in an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] See Figure 1-2 As shown in some embodiments of this application, a card verification method based on object identifiers includes: S100: Obtain card production business data, generate order object identifier and session number based on card production business data, lock records based on query results using order object identifier and session number, and generate or reuse result number based on query results; S200: Perform a unique comparison of the order object identifier, session number, and result number; determine whether there is a unique locking relationship between the order object identifier, session number, and result number based on the number of order object identifiers and corresponding session numbers; and bind the result number to the version identifier. S300: If there is a unique locking relationship between the order object identifier, session number, and result number, then integrity verification is performed based on the pointing relationship between the order object identifier, session number, result number, and version identifier; S400: If the integrity verification passes, a printing task number is assigned and the card identifier and verification identifier are determined. The printing task number, card identifier, and verification identifier are then compared with the preceding result number and version identifier. Based on the comparison result, a card production strategy or a card production blocking strategy is executed.

[0022] Specifically, this embodiment applies to self-service card issuance terminals, instant card issuance devices, ID card printing terminals, and other card-making scenarios that require binding and verifying online card issuance orders with the offline physical card production process. Card production typically includes multiple stages such as online application, payment confirmation, card data generation, card version confirmation, print job issuance, physical card identification, verification information generation, card printing, lamination, and card delivery. If these stages rely solely on single-point verification using the order number or print job number, duplicate card copies or physical card mismatches can easily occur due to repeated terminal requests or payment callback delays. Therefore, this embodiment uses object identifiers as the verification thread for the card production process, creating a hierarchical binding relationship between the order object, session object, result object, version object, print job object, physical card object, and verification object.

[0023] In S100, card production business data includes payment order data, card production user data, card face data, terminal session data, payment completion status, and card production version data. Specifically, payment order data indicates that a user has completed payment or met the card production trigger conditions; card production user data indicates the identity information, business type, account information, or card type information of the card production object; card face data indicates the name, number, pattern, QR code, barcode, photo, or other visual data to be printed on the card surface; terminal session data indicates which terminal, login, operation batch, or request chain the current card production request originated from; payment completion status confirms whether the card production business has met the conditions to enter the card production stage; and card production version data indicates the version status of data such as card face template, card production parameters, and business rules.

[0024] The order object identifier is used to identify a single card issuance transaction. This order object identifier is not the same as a regular order number. In this embodiment, it serves as the root object for the entire card issuance process. When generating the order object identifier, it can be a combination of the payment order number, transaction type, card code, user unique ID, payment completion time, and transaction system ID. Alternatively, it can be generated by digesting the above data to produce a fixed-length identifier. This method ensures that the same payment order has a unique object entry point within the card issuance system. In other words, regardless of whether the user repeatedly clicks to issue a card, the terminal re-fetches the task, or the server re-sends data, the system should first return to this order object identifier for judgment, rather than directly regenerating the card issuance result.

[0025] A session number identifies a single terminal card issuance session. It's not simply a network connection number, but rather a session object used to define the source of a valid card issuance request. Session numbers can be generated based on the terminal number, terminal login credentials, operator identifier, request batch number, session creation time, and transaction serial number. For self-service terminals, a session number corresponds to a card issuance session following payment by a user on the terminal. For counter card issuance equipment, a session number corresponds to a card issuance operation session performed by an operator on the current device. For batch card issuance equipment, a session number corresponds to the task issuance session for a specific order within a batch. By setting session numbers, the trigger source of the same order can be distinguished across different terminals, times, or request paths.

[0026] After generating the order object identifier and session number, the system searches for valid lock records in the result lock records using these identifiers and session numbers as search criteria. Result lock records store data such as the order object identifier, session number, result number, lock status, lock time, lock validity period, version identifier, and exception status. Lock status includes locked, completed, expired, and revoked states. The lock validity period limits whether the current result lock record remains valid during the card issuance process. For example, for self-service terminal instant card issuance, the lock validity period can be set to be valid for several minutes after payment completion; for counter manual card issuance, the lock validity period can be set according to the business processing time limit. Records that have already been issued, even if still stored in the database, are no longer considered reusable valid lock records for re-issuance of cards.

[0027] If a valid lock record corresponding to the order object identifier and session number is found, the record result number in that valid lock record is read and used as the result number for the current card issuance process. For example, if a user completes payment and the terminal requests card issuance for the first time, a result number has already been generated and written to the result lock record. However, if the terminal does not receive a response due to a network error and subsequently requests card issuance again, regenerating the result number would result in multiple result numbers for the same order. This embodiment avoids duplicate card issuance results by first querying the result lock record and reusing the existing result number.

[0028] The process of generating result numbers is not random; instead, seed data for result number generation is first established. This seed data includes at least the order object identifier, session number, card production service type, card production terminal number, and card production request time. Specifically, the order object identifier defines the card production service to which the result number belongs; the session number defines the terminal card production session to which the result number belongs; the card production service type distinguishes between different service sources such as instant card production, replacement card production, card exchange, or batch card production; the card production terminal number identifies which card production terminal generated the current result number; and the card production request time defines the time when the result number was generated. Before generating a new result number, a result generation lock is set based on the order object identifier and session number. This lock can be implemented using database row locks or distributed locks to ensure that only one card production request is allowed to enter the result number generation process at a time for the same order object identifier and the same session number. The result number is then encoded in the order of the object identifier, session number, card production service type, card production terminal number, and card production request time. Encoding can be implemented using fixed-length field concatenation encoding, TLV encoding, etc., and the final result number is determined based on the encoding result.

[0029] The result number is used to identify a locked card production result object. This result number does not correspond to a simple print job, but rather to the card production result to be generated by the current order under the current valid session. Once the result number is written to a valid lock record, no new result number can be generated for the same order object identifier and the same session number until the lock record expires, is revoked, or is abnormally released.

[0030] In S200, a unique association comparison is performed on the order object identifier, session number, and result number. This unique association comparison determines whether a unique locking relationship exists between the current order object, the current valid session object, and the current result object. Specifically, using the order object identifier as the primary index, the number of session numbers under that order object identifier is queried. Then, using the order object identifier and the current session number as a composite index, the number of result numbers under this combination is queried. Finally, it is verified whether the result number in the current request matches the result number in the result locking record. If the order object identifier has only one session number, and the order object identifier and the valid session number correspond to only one result number, then a unique locking relationship exists between the session number and the result number, and the result number is bound to the version identifier. In this case, it indicates that the current card issuance business has not been simultaneously taken over by multiple terminals, nor have multiple result numbers been generated under the same session. The pointing relationship between the order object, session object, and result object is clear, and the version binding and integrity verification process can proceed.

[0031] If an order object identifier has multiple session numbers, or if the order object identifier and session number correspond to multiple result numbers, it is determined that the session number and result number do not have a unique locking relationship, and there is an abnormal result identifier. Multiple session numbers can include situations such as the same order being retrieved by multiple terminals simultaneously, the same order being operated by both the user and the counter simultaneously, and payment callbacks being repeatedly triggered, forming multiple unexpired card issuance sessions. Multiple result numbers refer to situations where the same order is repeatedly generated under the same session, or where an old result number still exists after an abnormal replacement of a result number. For these abnormalities, card issuance data should not be sent further, nor should one of the result numbers be selected to continue execution. Instead, the card issuance business corresponding to the current order object identifier should be marked as having an abnormal result identifier, and the process should be manually reviewed or the card issuance process should be re-initiated.

[0032] After determining that a unique locking relationship exists, the result number is bound to the version identifier. The version identifier is used to limit the card version corresponding to the current result number. The card template, card production parameters, and business rules corresponding to the current card production business jointly determine the version identifier. The card template includes card layout, graphic and text positions, background pattern, anti-counterfeiting area, QR code position, photo area, and barcode area. The card production parameters include printing color parameters, lamination parameters, printing resolution, card specifications, printing media type, and terminal device adaptation parameters. The business rules include card type rules, validity period rules, verification rules, and card issuance rules. It should be noted that the generation of the version identifier based on the card template, card production parameters, and business rules corresponding to the current card production business in this application can preferably be implemented using existing technology in the field. This is not the focus of the improvement claimed in this application. The focus of the improvement in this application lies in the data connection relationship and constraint processing logic in card production verification. Those skilled in the art can combine existing public technologies or conventional engineering methods to complete the adaptation, replacement, or equivalent implementation without affecting the implementation of the technical solution of this application.

[0033] When binding the result number with the version identifier, the version identifier is written to the result locking record. This transforms the result number from a simple card production result number into a card production result object with defined version constraints. In other words, the card template, card production parameters, and business rules corresponding to the same result number cannot be arbitrarily switched after locking. If the terminal subsequently retrieves the task again or the user repeatedly initiates a card production request, the version identifier already bound in the result locking record is first read and then compared with the version identifier carried in the current request or regenerated. When a card production request corresponding to the same session number is received again, if the version identifier in the subsequent request matches the version identifier in the result locking record, the locked result number and version identifier are reused. This situation typically involves a normal retry or task re-issuance, such as when the terminal recovers from a network outage or re-acquires card data before printing. Since the version identifier remains unchanged, reusing the original result number and version identifier will not compromise the consistency of the card production result.

[0034] If the version identifier in the subsequent request is inconsistent with the version identifier in the result lock record, a version mismatch is determined to exist. Version mismatches include situations such as the card template being updated, card production parameters being replaced by the terminal, changes in business rules, changes in verification rule versions, or inconsistencies in version after the server regenerates the card data. For version mismatches, the new version identifier should not be directly overwritten with the old version identifier. Since the result number has already formed a lock relationship with the old version identifier, direct overwriting could lead to the same result number corresponding to different card data, resulting in inconsistencies between the printed content of the physical card and the verification data. Therefore, this embodiment blocks the card production process when a version mismatch occurs and processes it by canceling the original lock record and re-initiating card production after manual verification, rather than directly modifying the original lock record.

[0035] In S300, if a unique locking relationship exists between the order object identifier, session number, and result number, integrity verification is performed based on the pointing relationship between these three identifiers. The pointing relationship refers to the consistent chain-like correspondence between the result lock record, card production business data, and the object identifier in the terminal's pending task. Specifically, the order object identifier should point to the current session number, the session number should point to the unique result number, and the result number should point to the locked version identifier. If the order object identifier points to the session number, the session number points to the result number, and the result number points to the version identifier, the integrity verification is considered successful. This indicates that the card data, result lock record, and terminal execution task in the current card production task all belong to the same card production object chain, and the terminal can enter the print task allocation stage. If any one of the order object identifier, session number, result number, or version identifier is missing, or the session number corresponding to the order object identifier is not the current session number, or the version identifier bound to the result number is inconsistent with the current card data version, the integrity verification is considered unsuccessful, and the generation of a print task is prohibited. It should be noted that integrity checks failing include at least the following types of exceptions: First, a missing identifier exception, meaning the order object identifier, session number, result number, or version identifier is empty. Second, a broken pointer exception, meaning the session number exists but the corresponding result number cannot be found. Third, a broken version exception, meaning the result number exists but is not bound to a version identifier.

[0036] If the integrity verification passes, the process proceeds to S400, where a print task number is assigned to the current card production operation, and the card identifier and verification identifier are determined. The print task number identifies a specific print execution task. The result number indicates which locking result is being produced, while the print task number indicates which print task is currently executing that locking result. The card identifier identifies the physical card to be produced. For physical cards with chips, the card identifier can be obtained by reading the chip's unique serial number, the card's factory serial number, or a pre-set card number. For ordinary PVC cards, membership cards, or cards without chips, the card identifier can be determined before card production by writing a QR code, barcode, magnetic stripe, or card management record. For physical cards in the blank card slot, the card identifier can be generated by the card reader, scanner, or card slot serial number combined with the device number when the card enters the printing channel. Regardless of the method used, the card identifier should be bound to the result number and version identifier before printing or before printing begins to avoid confusion regarding the ownership of the physical card during the printing process.

[0037] The verification identifier is used to identify the verification object corresponding to the physical card. The verification identifier can be generated based on the card identifier, result number, user business information, verification rule version, and generation time, or it can be returned by the verification service. The purpose of the verification identifier is to enable the physical card to be verified as consistent with the card production result after issuance through scanning, card reading, background query, or terminal verification. There should be a one-to-one correspondence between the verification identifier and the card identifier. When assigning a print task number and determining the card identifier and verification identifier, a print task number is assigned to the current card production business, and the print task number is bound to the result number and version identifier. The card identifier corresponding to the physical card to be produced is read or written, and the card identifier is bound to the result number and version identifier. A verification identifier corresponding to the card identifier is generated, and the verification identifier is bound to the result number and card identifier. The print data version is not a new business version, but rather the version information corresponding to the print data packet that the card production terminal will actually send. It is used to represent the card content and printing parameters to be printed, including card layout, background image, photo position, QR code position, ID number, printing resolution, color parameters, printing media parameters, lamination position, etc.

[0038] The print task number, card identifier, and verification identifier are compared and correlated with the preceding result number and version identifier. This correlation comparison aims to confirm whether the print task, physical card, and verification data belong to the same locked card production result. Specifically, the result number pointed to by the print task number, the card identifier, and the verification identifier are read respectively. Then, the version identifier bound to that result number is read and compared with the current print data version. If the print task number, card identifier, and verification identifier all point to the same result number, and the version identifier bound to the result number matches the current print data version, the card production strategy is executed, allowing printing and lamination. Executing the card production strategy does not mean that verification is completely stopped; rather, it indicates that the conditions for entering the printing and lamination stage have been met. The card identifier and verification identifier can still be read for consistency confirmation during the subsequent card issuance stage.

[0039] If any of the print task number, card identifier, or verification identifier does not point to the result number, or if the result number pointed to by the print task number does not match the result number pointed to by the card identifier, or if the result number pointed to by the verification identifier does not match the result number pointed to by the card identifier, or if the version identifier bound to the result number does not match the current print data version, then a card production blocking policy will be implemented, prohibiting printing and lamination. Card production blocking policies include suspending the print task, releasing unused physical cards, returning the cards to the card tray, prohibiting card dispensing, or manual processing. Physical cards that have entered the printing channel but have not yet been printed will be recycled. Physical cards that have been printed but not laminated will be marked as invalid. Physical cards that have been laminated but not dispensed will also be recycled and prohibited from being delivered to the user.

[0040] In one specific embodiment, when a user applies for a membership card online and completes the payment, the system retrieves payment order data, card-issuing user data, card face data, terminal session data, payment completion status, and card version data. An order object identifier (OID-202605-0001) is generated based on the payment order number, user ID, and service type; a session number (SID-T01-0008) is generated based on the terminal ID. A search for locked records is performed using OID-202605-0001 and SID-T01-0008 as search criteria. If no valid locked record is found, a result number (RID-900001) is generated, and OID-202605-0001, SID-T01-0008, RID-900001, the locked status, and the locked time are written to the result locked record. Using OID-202605-0001 as the index, the number of session numbers is counted, and the result is 1. Using OID-202605-0001 and SID-T01-0008 as a combined index, the number of valid result numbers is counted, and the result is 1. Therefore, a unique locking relationship is determined to exist. The card template M-01, card production parameter P-03, and business rule R-02 corresponding to the current card production business are read to generate a version identifier VID-M01-P03-R02. VID-M01-P03-R02 is written to the result locking record and bound to RID-900001. If the terminal submits a card production request corresponding to the same session number SID-T01-0008 again due to a network anomaly, RID-900001 and VID-M01-P03-R02 can be read when the result locking record is queried again. If the version identifier in the subsequent request is still VID-M01-P03-R02, the locked result number and version identifier will be reused, and no new result number will be generated. If the version identifier in the subsequent request changes to VID-M01-P04-R02, it indicates that the card production parameter version has changed. In this case, a version mismatch is determined, and the new version identifier is not allowed to overwrite the locked version identifier. The card production task will then be blocked from continuing.

[0041] When the terminal prepares to issue a card, it reads OID-202605-0001, SID-T01-0008, RID-900001, and VID-M01-P03-R02. If the order object identifier points to the session number, the session number points to the result number, and the result number points to the version identifier, the integrity verification passes, and a print task number PID-30001 is assigned. The terminal reads the card identifier CID-CARD-7788 from the blank physical card and generates a verification identifier AID-AUTH-6601. It binds PID-30001 with RID-900001 and VID-M01-P03-R02, and binds CID-CARD-7788 with... Bind RID-900001 and VID-M01-P03-R02, bind AID-AUTH-6601 to RID-900001 and CID-CARD-7788. Before printing, read the result number pointed to by PID-30001 as RID-900001, read the result number pointed to by CID-CARD-7788 as RID-900001, read the result number pointed to by AID-AUTH-6601 as RID-900001, and confirm that VID-M01-P03-R02 bound to RID-900001 matches the current print data version. If so, execute the card production policy, allowing printing and lamination. If the physical card identifier read at this time is CID-CARD-7799, but this card identifier is not bound to RID-900001, or is bound to other result numbers, then a physical card mismatch is determined, and a card production blocking policy is executed, prohibiting printing and lamination.

[0042] In summary, by using the order object identifier and session number, and locking records based on the query results of both, it can prioritize identifying whether a result number already exists when the same order is submitted repeatedly, the terminal makes repeated requests, or payment callbacks are delayed. If a valid locked record already exists, the original result number is directly reused, preventing the generation of multiple card production results for the same order object and the same session object, thus ensuring a one-to-one correspondence between orders, sessions, and results. By performing a unique association comparison of the order object identifier, session number, and result number, it can determine whether a unique locking relationship exists based on the number of valid session numbers corresponding to the order object identifier and the number of result numbers, reducing the risk of duplicate physical card production and misissue. Binding the result number to the version identifier ensures the consistency of card templates, card production parameters, and business rules after the result is locked, avoiding version mismatches caused by template updates, old data cached on the terminal, or parameter replacement during the card production process. By associating and comparing the print task number, card identifier, and verification identifier with the preceding result number and version identifier, it can be ensured that the print task, physical card, and verification data all point to the same locked result. This forms a closed-loop verification mechanism from order generation, result locking, version binding, pre-print verification to card production execution, improving the uniqueness, integrity, and traceability of the card production process.

[0043] Based on another preferred embodiment described above, see [link to preferred embodiment]. Figure 3 As shown, this embodiment provides a card verification system based on object identifiers, used to apply the above-described card verification method based on object identifiers, including: The identification management unit is configured to acquire card production business data, generate order object identifiers and session numbers based on the card production business data, lock records based on query results using order object identifiers and session numbers, and generate or reuse result numbers based on query results. The first verification unit is configured to perform a uniqueness comparison of the order object identifier, session number and result number, determine whether there is a unique locking relationship between the order object identifier, session number and result number based on the number of order object identifiers and corresponding session numbers, and bind the result number to the version identifier; The second verification unit is configured to perform integrity verification based on the pointing relationship between the order object identifier, session number, result number, and version identifier if there is a unique locking relationship between the order object identifier, session number, result number, and version identifier. The third verification unit is configured to assign a printing task number and determine the card identifier and verification identifier if the integrity verification passes. It then compares the printing task number, card identifier, and verification identifier with the preceding result number and version identifier, and executes a card production strategy or blocks card production based on the comparison result.

[0044] It is understandable that the above-mentioned card verification method and system based on object identifiers have the same beneficial effects, and will not be elaborated further here.

[0045] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A card verification method based on object identifiers, characterized in that, include: Obtain card production business data, generate order object identifiers and session numbers based on the card production business data, lock records based on query results using the order object identifiers and session numbers, and generate or reuse result numbers based on the query results; A unique association comparison is performed on the order object identifier, the session number, and the result number. Based on the number of the order object identifier and the corresponding session number, it is determined whether there is a unique locking relationship between the order object identifier, the session number, and the result number. The result number is then bound to the version identifier. If there is a unique locking relationship between the order object identifier, the session number, and the result number, then integrity verification is performed based on the pointing relationship between the order object identifier, the session number, the result number, and the version identifier; If the integrity verification passes, a printing task number is assigned and a card identifier and a verification identifier are determined. The printing task number, the card identifier, and the verification identifier are then compared with the preceding result number and the version identifier. Based on the comparison result, a card production strategy or a card production blocking strategy is executed.

2. The card verification method based on object identifiers according to claim 1, characterized in that, The card manufacturing business data includes: The data includes payment order data, card-issuing user data, card face data, terminal session data, payment completion status, and card version data. The order object identifier is generated based on the payment order data and is used to identify a card issuance transaction. The session number is generated based on the terminal session data and is used to identify a terminal card issuance session.

3. The card verification method based on object identifiers according to claim 2, characterized in that, When generating or reusing result numbers based on query results, the following applies: Using the order object identifier and the session number as search criteria, query the valid lock records in the result lock records; If a valid lock record corresponding to the order object identifier and the session number is found, the record result number in the valid lock record is read and used as the result number of the current card issuance business; If no valid lock record corresponding to the order object identifier and the session number is found, the result number is generated, and the order object identifier, the session number, the result number, the lock status, and the lock time are written into the result lock record.

4. The card verification method based on object identifiers according to claim 3, characterized in that, When performing a unique association comparison of the order object identifier, the session number, and the result number, the following is included: If the order object identifier has only one session number, and the order object identifier and the session number correspond to only one result number, then it is determined that the session number and the result number have a unique locking relationship, and the result number is bound to the version identifier.

5. The card verification method based on object identifiers according to claim 4, characterized in that, When performing a unique association comparison of the order object identifier, the session number, and the result number, the method further includes: If the order object identifier has multiple session numbers, or the order object identifier and the session number correspond to multiple result numbers, then it is determined that the session number and the result number do not have a unique locking relationship, and there is an abnormal result identifier.

6. The card verification method based on object identifiers according to claim 5, characterized in that, When binding the result number with the version identifier, the following is included: Obtain the card template, card production parameters, and business rules corresponding to the current card production business; generate the version identifier based on the card template, card production parameters, and business rules; and write the version identifier into the result lock record. When a card production request corresponding to the same session number is received again, if the version identifier in the new request is consistent with the version identifier in the result lock record, the locked result number and version identifier are reused. If the version identifier in the subsequent request is inconsistent with the version identifier in the result lock record, it is determined that there is a version mismatch.

7. The card verification method based on object identifiers according to claim 6, characterized in that, When performing integrity verification based on the relationship between the order object identifier, the session number, the result number, and the version identifier, the following is included: If the order object identifier points to the session number, the session number points to the result number, and the result number points to the version identifier, then the integrity check is deemed to have passed; otherwise, the integrity check is deemed to have failed, and the generation of a print job is prohibited.

8. The card verification method based on object identifiers according to claim 7, characterized in that, When assigning print job numbers and determining card identifiers and verification identifiers, the following is included: Assign the printing task number to the current card production business, bind the printing task number with the result number and the version identifier, read or write the card identifier corresponding to the physical card to be produced, bind the card identifier with the result number and the version identifier, generate a verification identifier corresponding to the card identifier, and bind the verification identifier with the result number and the card identifier.

9. The card verification method based on object identifiers according to claim 8, characterized in that, When comparing and associating the print task number, the card identifier, and the verification identifier with the preceding result number and version identifier, the process includes: If the print task number, the card identifier, and the verification identifier all point to the same result number, and the version identifier bound to the result number is consistent with the current print data version, then the card production strategy is executed, allowing printing and lamination; otherwise, the card production blocking strategy is executed, prohibiting printing and lamination.

10. A card verification system based on object identifiers, used to apply the card verification method based on object identifiers as described in any one of claims 1-9, characterized in that, include: The identification management unit is configured to acquire card production business data, generate order object identifiers and session numbers based on the card production business data, lock records based on query results using the order object identifiers and session numbers, and generate or reuse result numbers based on the query results. The first verification unit is configured to perform an association uniqueness comparison on the order object identifier, the session number and the result number, determine whether there is a unique locking relationship between the order object identifier, the session number and the result number based on the number of the order object identifier and the corresponding session number, and bind the result number to the version identifier; The second verification unit is configured to perform integrity verification based on the pointing relationship between the order object identifier, the session number, and the result number if there is a unique locking relationship between them. The third verification unit is configured to assign a printing task number and determine the card identifier and verification identifier if the integrity verification passes, and to compare the printing task number, the card identifier and the verification identifier with the preceding result number and the version identifier, and to execute a card production strategy or a card production blocking strategy based on the comparison result.

Images