CN117635133A - Personalized verification system for card - Google Patents

Abstract

The system comprises a client, an auditing end, a testing terminal and a testing card to be verified, wherein the client, the auditing end, the testing terminal and the testing card to be verified are logically processed, so that an entity card does not need to be sent in the personal testing process of the testing card, and a testing card interaction log is transmitted from the client to the auditing end in a file mode, thereby saving card sending time in the prior art, reducing the testing period from original 2 weeks to 2-3 days, improving the efficiency of personalized verification and reducing the cost; meanwhile, the cost of manpower and material resources for managing the test sample card in a laboratory is reduced; because the test card of the entity does not need to be sent, the related information of the production card does not need to be worried about, and the card is always positioned in the personalized center during the test, so that the safety of the card is ensured.

Description

Personalized verification system for card

Technical Field

The application relates to the field of computer technology, in particular to a personalized verification system for a card.

Background

The card organization is called a bank card transfer clearing organization (also called a credit card organization/a bank card organization) and is an international or regional bank card organization composed of member institutions. The card organization is responsible for constructing and operating a global or regional unified bank card information exchange network, authorizing the card issuing organization to issue the bank card, authorizing the acquirer to accept the bank card transaction, and responsible for information conversion and fund clearing of the bank card transaction, and making and pushing the bank card cross-bank transaction service specification and technical standard.

The EMVCo organization is commonly initiated by a plurality of international card organizations and is responsible for managing, maintaining and perfecting EMV standards related to EMV intelligent (chip) cards. According to EMV specification requirements, authentication of EMV is divided into the following three layers:

EMV Level1, hardware layer and protocol layer, provides the correct physical, electrical and protocol characteristics for the next layer.

The EMV Level2, EMV kernel layer, is responsible for the data interaction of cards and terminals (POS machine, ATM machine, etc.), and provides an interface for the next layer to handle EMV business capabilities.

The EMV Level3 and EMV application layer uses the application developed by the kernel provided by the EMV Level2 to ensure the compatibility and correctness of transaction flows of various cards and terminal applications, ensure the correctness of data in the whole transaction flow from the card to the terminal, to the acquiring mechanism and then to the card organization.

EMVCo organization provides EMV Level1 and EMV Level2 authentication; level3 authentication is currently self-specified by the respective card organization for standards and implementations.

As shown in fig. 1, a schematic diagram of a card authentication architecture in the prior art is shown, and in fig. 1, the card authentication architecture is divided into three layers of Level1, level2 and Level3 from bottom to top. Fig. 2 is a schematic diagram of a card personalization flow in the prior art, including a card management system, a key management system, an IC card data preparation system, a personalization device, a personalization verification system, a card formation system, and the like, where the card management system is used to manage a cardholder account, generate basic data such as a cardholder card number, a magnetic stripe, and a validity period; the key management system is used for managing the IC card transaction master key, the public and private key pairs of the card issuing bank and the certificates and issuing IC card public key certificates; the IC card data preparation system is used for calling the key management system by using the cardholder basic data and generating card making data meeting the requirements of card organization specifications based on the personalized data template provided by the card organization; the personalization equipment is used for personalizing the blank card and comprises a writing chip, a writing magnetic stripe and a card number of a printing card surface; the personalized verification system is used for verifying that the personalized program of the card is correct, verifying that the personalized data of the card meets the personalized data template requirement of the card organization, verifying that the symmetric transaction key, the asymmetric key and the certificate of the card are correct, and ensuring that the card can be normally used in the market; the card forming is used for indicating a card with complete functions, and the card can be normally used in the market.

As shown in fig. 3, a schematic diagram of a personalized verification process in the prior art specifically includes the following six steps:

step1, a card issuing mechanism submits a standing application, and a card organization examines and generates a project number;

step2, the card issuing organization submits a certificate request file, and the card organization issues an issuer certificate;

step3, the card issuing organization generates test data based on the personalized relevant specification;

step4, the personalization center compiles a card personalization program based on the chip and card issuing organization data;

and 5, the personalized center makes the test card, sends the entity card to a laboratory, and detects the entity card in the laboratory, and if the card does not meet the standard requirement, the personalized center needs to re-make and send the test card.

And step6, if the laboratory test is passed, issuing a test report to the card organization for auditing, and issuing a personalized certification approval letter to the card issuing organization after the auditing is passed.

In the personalized verification practice in the prior art, for example, for card organizations such as VISA, masterCard and Union, the test card is usually manufactured and finished in a test environment, and the entity card is sent to a card organization or a laboratory authorized by the card organization for testing, and a test report is sent after the test is finished. For another example, for the U.S. express card organization, it is issued in china as a dual application card, with applications in the card for use in the interior and also for use in the exterior. The in-home application needs to complete the test in a laboratory that makes a card and sends authorization in the test environment, and the out-of-home application uses an on-line verification tool provided by the american express to perform the test. After the personalized card test of the test environment passes, the test of the production environment is entered, and a laboratory for manufacturing a sending authorization of the production card is required to complete the test and the test is performed by using an online verification tool provided by America.

The traditional personalized verification mode has the following pain points: the entity card is required to be sent, and as the entity card is required to be sent for a period of time, part of card organization or laboratory is overseas, the time of one test is basically more than 2-3 weeks, and especially if the card does not meet the standard requirement, the test card is required to be sent for a plurality of times, so that personalized authentication can be completed in more than one month; firstly, the authentication cost is increased, and secondly, the time of marketing the slow card product influences the card issuing of the product. When an entity card is sent, the card needs to pass through hands of a plurality of people, and for producing the card, the risk of card information leakage exists. The laboratory needs to manage the test card.

Disclosure of Invention

The personal verification system of the card is characterized in that the entity card does not need to be sent, and the tested card interaction log is transmitted to the auditing end from the client end in a file mode, so that card sending time in the prior art is saved, the testing period is reduced to 2-3 days from original 2 weeks, the personalized verification efficiency is improved, and the cost is reduced; meanwhile, the cost of manpower and material resources for managing the test sample card in a laboratory is reduced; because the test card of the entity does not need to be sent, the related information of the production card does not need to be worried about, and the card is always positioned in the personalized center during the test, so that the safety of the card is ensured.

According to one aspect of the present application, there is provided a personal verification system for cards, the system comprising a client, an auditing end, a testing terminal and a testing card to be verified, wherein the system comprises:

creating a personal verification project at the auditing end to generate a project file;

importing the project file into the client, and selecting to test the test card placed on the test terminal according to the case of the client so as to capture a card interaction log between the test terminal and the test card in the test process and submit the card interaction log to the auditing terminal;

the auditing end analyzes and normalizes the card interaction log and displays the processed metadata to a UI interface of the auditing end;

the auditing end obtains the script file of each test case in the target test case set from at least one test case set in the auditing end according to the list number carried in the card interaction log, traverses each check point in the script file of each test case and displays the result of each check point in the UI interface;

after all the test cases in the target test case set are verified, the auditing end generates a test report of the target test case set according to metadata displayed by the UI interface and results of all check points.

Further, in the personalized verification system of a card, the creating a personal verification project at the auditing end to generate a project file includes:

in response to receiving a verification application form for the test card, creating a personal verification project at the auditing end;

determining project information of the personal verification project in response to a creation input operation performed at a creation interface of the auditing end, wherein the project information comprises card issuing organization information, card merchant and chip information and personalized verification case list information, and the personalized verification case information comprises the target test case set;

and generating a project file for personalized verification based on the project information of the personal verification project, and signing the project file in an encryption mode.

Further, in the personalized verification system for cards, the step of importing the project file at the client, and selecting to test the test card placed on the test terminal according to the case of the client, so as to capture a card interaction log between the test terminal and the test card in the test process and submit the card interaction log to the auditing terminal includes:

importing the project file at the client and verifying whether the project file is modified;

if the project file is not modified, responding to a case selection operation of a test operator on a case in the target case set on the client, and prompting the test card to be placed by the client so that the test operator places the test card on the test terminal;

the test terminal tests the test card; the client is in communication connection with the test terminal;

in the testing process, the client side grabs instructions and responses between the testing terminal and the testing card and writes a card interaction log;

and the client submits the card interaction log to the auditing end in a file mode.

Further, in the personalized verification system of a card, the test report of the target test case set includes a total number of test cases in the target test case set, a number of test passing cases, a number of test failing cases, a number of unavailable cases, and a passing ratio.

Further, in the personalized verification system of a card, the system further includes:

acquiring at least one test case set under different test scenes and different test functions, wherein each test case set comprises at least one case, and each case comprises at least one check point;

software identifiable and executable scripting processing is carried out on the check points of each case in each test case set to obtain script files of each case, wherein the script files of the case comprise at least one scripted check point

Compared with the prior art, the personal verification system of the card provided by one aspect of the application comprises a client, an auditing end, a testing terminal and a testing card to be verified, wherein the system comprises: creating a personal verification project at the auditing end to generate a project file; importing the project file into the client, and selecting to test the test card placed on the test terminal according to the case of the client so as to capture a card interaction log between the test terminal and the test card in the test process and submit the card interaction log to the auditing terminal; the auditing end analyzes and normalizes the card interaction log and displays the processed metadata to a UI interface of the auditing end; the auditing end obtains the script file of each test case in the target test case set from at least one test case set in the auditing end according to the list number carried in the card interaction log, traverses each check point in the script file of each test case and displays the result of each check point in the UI interface; after all the test cases in the target test case set are verified, the auditing end generates a test report of the target test case set according to metadata displayed by the UI interface and the results of each check point, so that an entity card does not need to be sent in the personal verification process of a test card, and a test card interaction log is transmitted from a client to the auditing end in a file mode, thereby saving card sending time in the prior art, reducing the test period from original 2 weeks to 2-3 days, improving the efficiency of personalized verification and reducing the cost; meanwhile, the cost of manpower and material resources for managing the test sample card in a laboratory is reduced; because the test card of the entity does not need to be sent, the related information of the production card does not need to be worried about, and the card is always positioned in the personalized center during the test, so that the safety of the card is ensured.

Drawings

Other features, objects and advantages of the present application will become more apparent upon reading of the detailed description of non-limiting embodiments, made with reference to the following drawings, in which:

FIG. 1 is a schematic diagram of a card authentication architecture of the prior art;

FIG. 2 is a schematic diagram of a card personalization process in the prior art;

FIG. 3 shows a schematic diagram of a prior art personalized verification process;

FIG. 4 illustrates a system frame diagram of a personal verification system for a card in accordance with an aspect of the subject application;

FIG. 5 illustrates a personalized verification flow diagram in a personalized verification system for a card in accordance with an aspect of the subject application;

FIG. 6 illustrates an exemplary diagram of a preferred case of a card personalization verification system in accordance with an aspect of the present application in a preferred embodiment;

FIG. 7 illustrates a complete exemplary diagram of a script file corresponding to a preferred case in a preferred embodiment of a personalized verification system for cards in accordance with an aspect of the subject application;

FIG. 8 illustrates a schematic diagram of a personalized verification system for cards that creates a creation interface for a personal verification item at an audit side in accordance with an aspect of the subject application;

FIG. 9 illustrates an exemplary diagram of a project file of a personalized verification project for a card in accordance with an aspect of the subject application in a preferred embodiment;

FIG. 10 illustrates an example diagram of a card interaction log in a preferred embodiment of a personalized verification system for cards in accordance with an aspect of the subject application;

FIG. 11 is a schematic diagram of a format of a personalized verification system for cards according to an aspect of the present application after a card interaction log parsing normalization process in a preferred embodiment;

FIG. 12 is an interface diagram of a personalized verification system for cards of an aspect of the present application showing the verification of pass or fail of a case in a preferred embodiment;

FIG. 13 illustrates a schematic diagram of a test report in a preferred embodiment of a card personalization verification system in accordance with an aspect of the present application.

The same or similar reference numbers in the drawings refer to the same or similar parts.

Detailed Description

The present application is described in further detail below with reference to the accompanying drawings.

In one typical configuration of the present application, the terminal, the device of the service network, and the trusted party each include one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer readable media, as defined herein, does not include non-transitory computer readable media (transmission media), such as modulated data signals and carrier waves.

As shown in fig. 4, fig. 4 is a system frame diagram of a personal verification system for cards according to an aspect of the present application, the system including a client (i.e., a personalization center) for personalized verification, an audit (i.e., a laboratory) for personalized verification, a test terminal, a test card to be verified, and a card organization, wherein the system includes:

creating a personal verification project at the auditing end to generate a project file;

importing the project file into the client, and selecting to test the test card placed on the test terminal according to the case of the client so as to capture a card interaction log between the test terminal and the test card in the test process and submit the card interaction log to the auditing terminal;

the auditing end analyzes and normalizes the card interaction log and displays the processed metadata to a UI interface of the auditing end;

the auditing end obtains the script file of each test case in the target test case set from at least one test case set in the auditing end according to the list number carried in the card interaction log, traverses each check point in the script file of each test case and displays the result of each check point in the UI interface;

after all the test cases in the target test case set are verified, the auditing end generates a test report of the target test case set according to metadata displayed by the UI interface and results of all check points.

In the system of the embodiment, the entity card does not need to be sent in the personal verification process of the test card, and the test card interaction log is transmitted from the client to the auditing end in a file mode, so that the card sending time in the prior art is saved, the test period is reduced from original 2 weeks to 2-3 days, the personalized verification efficiency is improved, and the cost is reduced; meanwhile, the cost of manpower and material resources for managing the test sample card in a laboratory is reduced; because the test card of the entity does not need to be sent, the related information of the production card does not need to be worried about, and the card is always positioned in the personalized center during the test, so that the safety of the card is ensured.

In a preferred embodiment of the present application, the personalized verification process shown in fig. 5 includes Step1, step2, step3, step4, step5 and Step6, which specifically includes the following steps:

step1, the card issuing mechanism submits a stand application and initiates an authentication application so that the card organization reviews the stand and generates a project number;

step2, submitting a file of the certificate request by the card issuing organization, and issuing an issuer certificate by the card organization;

step3, the card issuing mechanism generates test data based on the personalized relevant specifications, and the personalized center compiles a card personalized program based on the test data of the chip and the card issuing mechanism;

step4, the personalized center makes a test card, and submits a test result (card interaction log and the like) to a laboratory in a mail form so that the laboratory can verify according to the personalized specification;

step5, feeding back the problem verified by the personalized specification performed by the laboratory to the personalized center, performing problem correction by the personalized center, and submitting updated test results to the laboratory in the form of mails.

Step6, the laboratory sends out a report according to the test result, and uploads the report to a card organization, the card organization reviews the report, and the report is archived in a card issuing organization, so that personalized verification of the test card is completed.

Prior to performing the personalized verification of the test card, one aspect of the present application proposes a personalized verification system of a card further comprising:

acquiring at least one test case set under different test scenes and different test functions, wherein each test case set comprises at least one case, and each case comprises at least one check point;

and carrying out software identifiable and executable scripting processing on the check points of each case in each test case set to obtain a script file of each case, wherein the script file of each case comprises at least one scripted check point.

In this embodiment, the auditing end has different test case sets according to different test scenarios and/or different test functions, and each test case set includes at least one case, and each case includes one or more checkpoints; the test case set for personalized verification is generally composed of various card organizations according to the terminal specifications, card application specifications, card personalized specifications and card personalized templates, cases applicable to different transaction scenes are composed to verify that personalized data of the card are written correctly, various data elements in the card accord with the personalized templates, card keys are written correctly, and various functions of the card are normal. Before personal verification is performed on the test card, different test case sets need to be scripted at the auditing end, so that for each test case set, the inspection point of each case in each test case set needs to be scripted into a script file which can be identified and executed by software, so that the script file of each case is obtained, and personal verification can be performed later. In a preferred embodiment of the present application, as shown in fig. 6, a preferred case of the present application, in which a check point "PSE entry 1Tag4F for verifying a card in the case exists, and the value 'a000000790010502'" script is a check point in a script file of the case, that is:

APDU.PSE.00A4.I1.ICC.TAG.4F＝A000000790010502

tag4F used to represent the check return must be "a000000790010502" so that the strip program can be parsed and executed. As shown in fig. 7, a complete example of a script file corresponding to a preferred case (case in fig. 6) of the present application is shown.

Following the above-described embodiments of the present application, a personal verification project is created at the auditing end to generate a project file, specifically including:

in response to receiving a verification application form for the test card, creating a personal verification project at the auditing end;

determining project information of the personal verification project in response to a creation input operation performed at a creation interface of the auditing end, wherein the project information comprises card issuing organization information, card merchant and chip information and personalized verification case list information, and the personalized verification case information comprises the target test case set;

and generating a project file for personalized verification based on the project information of the personal verification project, and signing the project file in an encryption mode.

In a preferred embodiment of the application, when the auditing end establishes a personalized verification project, the card issuing mechanism submits a verification application form for personalized verification of the test card to a card organization, and the card organization sends the verification application form to the auditing end to establish the personal verification project through the auditing end; in creating the personal verification project, a creation input operation including, but not limited to, input of card issuing organization information, card vendor and chip information, personalized verification case information, etc. is required to be performed in a creation interface of the auditing end as shown in fig. 8, so as to determine project information of the personal verification project, including card issuing organization information, card vendor and chip information, and personalized verification case column information, including the target test case set determined by the selection made in the personalized case set as shown in fig. 8, thereby completing creation of the personal verification project. After the personal verification project is created, the auditing end needs to generate a project file for personalized verification according to the project information of the personal verification project, and sign the project file in an encrypted manner, as shown in fig. 9, which is an example of the project file in a preferred embodiment of the present application.

In the above embodiment of the present application, the importing the project file at the client, and selecting, according to the case of the client, to test the test card placed on the test terminal, so as to capture a card interaction log between the test terminal and the test card in the test process, and submit the card interaction log to the auditing terminal, specifically includes:

firstly, manufacturing a test card, opening a client for personalized verification by a test operator, importing a project file corresponding to a personalized verification project at the client, and verifying whether the project file is modified or not; here, it includes, but is not limited to, verifying whether the hash file or the like in the item file is modified.

If the project file is not modified, responding to a case selection operation of a test operator on a case in the target case set on the client, and prompting the test card to be placed by the client so that the test operator places the test card on the test terminal;

the test terminal tests the test card; wherein the client is communicatively connected to the test terminal, including but not limited to, connecting through a USB interface as in fig. 4;

in the test process, the client captures instructions and responses between the test terminal and the test card and writes a card interaction log, namely the card interaction log is the instructions and responses between the test terminal and the test card in the test process;

the client submits the card interaction log to the auditing end in a file mode, wherein the format of the card interaction log submitted to the auditing end in the file mode accords with the format requirement of the file about the card interaction log in EMVCo specification EMVCo_level 3_frame_implementation_guide lines. In a preferred embodiment of the present application, as shown in FIG. 10, an example of a preferred embodiment of a card interaction log is shown.

In this embodiment, the auditing end analyzes and normalizes the card interaction log, where the format of the card interaction log after analysis and normalization can be refined to the minimum unit in the card interaction process: the metadata, as shown in fig. 11, is a schematic format diagram of the card interaction log after normalization processing in a preferred embodiment of the present application.

In the embodiment of the application, the personal verification project is opened at the auditing end, and after the card interaction log submitted by the client is imported, all necessary information of personalized verification, such as a case tester, a card interaction log and the like, is obtained; at the auditing end, analyzing and normalizing the card interaction log, and displaying the processed metadata to a UI interface of the auditing end; meanwhile, according to the list number carried in the card interaction log, after a script file of each test case in a target test case set is obtained from at least one test case set in the auditing end, traversing each check point in the script file of each test case and displaying the result of each check point in the UI interface;

after all the test cases in the target test case set are verified, the auditing end generates a test report of the target test case set according to metadata displayed by the UI interface and results of all check points. The test report includes, but is not limited to, a report interface for enabling an auditor to pass the case according to the auditing result of the tool and the result of manually judging whether the case passes the case or not, as shown in fig. 12. When all cases in the target test case set are verified, a test report corresponding to the target test case set is generated, as shown in fig. 13, where the test report of the target test case set includes, but is not limited to, a total number of test cases in the target test case set, a number of test passing cases, a number of test failing cases, a number of unavailable cases, and a passing ratio.

The personalized verification system of the card provided by one aspect of the application has the following beneficial effects:

and (3) optimizing the flow: the entity card does not need to be sent, and the test result is transmitted in a file mode, so that the card sending time is saved, and the test period is reduced from original 2 weeks to 2-3 days. The cost of manpower and material resources for managing the test sample card in a laboratory is reduced; the risk of card information leakage in the process of producing the card mailing is reduced.

The card interaction log is transferred by means of a file, instead of acquiring the detection instruction from the server in real time. No server with high construction cost is needed, and no operation and maintenance personnel are required to ensure continuous availability of service.

Data normalization: preprocessing the card interaction log, converting the data into the same format, and being applicable to Level3 authentication of a plurality of kernel tools and different card organizations;

accuracy improves: the cases of the test case set are scripted into script files corresponding to the cases which can be identified by the program, the program automatically checks check points, and the possible missed check and the false check of the auditor are avoided;

reporting accuracy: the program automatically generates the test report, so that the manual filling of the report is avoided, and the time and the labor are saved;

the script file corresponding to the case can be updated under the condition of not modifying the program according to the requirement;

the project file is signed in an encryption mode, sensitive information such as a card number, a validity period and the like are desensitized, and card information safety is guaranteed.

In summary, according to one aspect of the present application, a personal verification system for a card is provided, the system includes a client, an audit end, a test terminal, and a test card to be verified, where the system includes: creating a personal verification project at the auditing end to generate a project file; importing the project file into the client, and selecting to test the test card placed on the test terminal according to the case of the client so as to capture a card interaction log between the test terminal and the test card in the test process and submit the card interaction log to the auditing terminal; the auditing end analyzes and normalizes the card interaction log and displays the processed metadata to a UI interface of the auditing end; the auditing end obtains the script file of each test case in the target test case set from at least one test case set in the auditing end according to the list number carried in the card interaction log, traverses each check point in the script file of each test case and displays the result of each check point in the UI interface; after all the test cases in the target test case set are verified, the auditing end generates a test report of the target test case set according to metadata displayed by the UI interface and the results of each check point, so that an entity card does not need to be sent in the personal verification process of a test card, and a test card interaction log is transmitted from a client to the auditing end in a file mode, thereby saving card sending time in the prior art, reducing the test period from original 2 weeks to 2-3 days, improving the efficiency of personalized verification and reducing the cost; meanwhile, the cost of manpower and material resources for managing the test sample card in a laboratory is reduced; because the test card of the entity does not need to be sent, the related information of the production card does not need to be worried about, and the card is always positioned in the personalized center during the test, so that the safety of the card is ensured.

It should be noted that the present application may be implemented in software and/or a combination of software and hardware, for example, using Application Specific Integrated Circuits (ASIC), a general purpose computer or any other similar hardware device. In one embodiment, the software programs of the present application may be executed by a processor to implement the steps or functions as described above. Likewise, the software programs of the present application (including associated data structures) may be stored on a computer readable recording medium, such as RAM memory, magnetic or optical drive or diskette and the like. In addition, some steps or functions of the present application may be implemented in hardware, for example, as circuitry that cooperates with the processor to perform various steps or functions.

Furthermore, portions of the present application may be implemented as a computer program product, such as computer program instructions, which when executed by a computer, may invoke or provide methods and/or techniques in accordance with the present application by way of operation of the computer. Program instructions for invoking the methods of the present application may be stored in fixed or removable recording media and/or transmitted via a data stream in a broadcast or other signal bearing medium and/or stored within a working memory of a computer device operating according to the program instructions. An embodiment according to the present application comprises an apparatus comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein the computer program instructions, when executed by the processor, trigger the apparatus to operate a method and/or a solution according to the embodiments of the present application as described above.

It will be evident to those skilled in the art that the present application is not limited to the details of the foregoing illustrative embodiments, and that the present application may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive, the scope of the application being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned. Furthermore, it is evident that the word "comprising" does not exclude other elements or steps, and that the singular does not exclude a plurality. A plurality of units or means recited in the apparatus claims can also be implemented by means of one unit or means in software or hardware. The terms first, second, etc. are used to denote a name, but not any particular order.

Claims (5)

1. A personal verification system for cards, the system comprising a client, an auditing end, a testing terminal and a testing card to be verified, wherein the system comprises:

creating a personal verification project at the auditing end to generate a project file;

importing the project file into the client, and selecting to test the test card placed on the test terminal according to the case of the client so as to capture a card interaction log between the test terminal and the test card in the test process and submit the card interaction log to the auditing terminal;

the auditing end analyzes and normalizes the card interaction log and displays the processed metadata to a UI interface of the auditing end;

the auditing end obtains the script file of each test case in the target test case set from at least one test case set in the auditing end according to the list number carried in the card interaction log, traverses each check point in the script file of each test case and displays the result of each check point in the UI interface;

after all the test cases in the target test case set are verified, the auditing end generates a test report of the target test case set according to metadata displayed by the UI interface and results of all check points.

2. The method of claim 1, wherein the creating a personal verification project at the auditing end to generate a project file comprises:

in response to receiving a verification application form for the test card, creating a personal verification project at the auditing end;

determining project information of the personal verification project in response to a creation input operation performed at a creation interface of the auditing end, wherein the project information comprises card issuing organization information, card merchant and chip information and personalized verification case list information, and the personalized verification case information comprises the target test case set;

and generating a project file for personalized verification based on the project information of the personal verification project, and signing the project file in an encryption mode.

3. The method according to claim 2, wherein the importing the project file at the client and selecting to test the test card placed on the test terminal according to the case of the client to capture a card interaction log between the test terminal and the test card during the test and submit the card interaction log to the auditing terminal includes:

importing the project file at the client and verifying whether the project file is modified;

if the project file is not modified, responding to a case selection operation of a test operator on a case in the target case set on the client, and prompting the test card to be placed by the client so that the test operator places the test card on the test terminal;

the test terminal tests the test card; the client is in communication connection with the test terminal;

in the testing process, the client side grabs instructions and responses between the testing terminal and the testing card and writes a card interaction log;

and the client submits the card interaction log to the auditing end in a file mode.

4. The method of claim 1, wherein the test report of the set of target test cases includes a total number of test cases in the set of target test cases, a number of test passing cases, a number of test failing cases, a number of unavailable cases, and a passing ratio.

5. The method of any one of claims 1 to 4, wherein the system further comprises:

acquiring at least one test case set under different test scenes and different test functions, wherein each test case set comprises at least one case, and each case comprises at least one check point;

and carrying out software identifiable and executable scripting processing on the check points of each case in each test case set to obtain a script file of each case, wherein the script file of each case comprises at least one scripted check point.