System, method and computer program product for verifying card images

Abstract

Methods, systems, and computer program products for validating card image files are provided. A system can include at least one processor programmed or configured to: parse a card image file to determine card data represented by the card image file; generate a plurality of simulated payment transactions based on the card data, each simulated payment transaction including simulated transaction data; issue a plurality of commands to the payment device emulator, the plurality of commands based on the simulated transaction data of the plurality of simulated payment transactions; receive a plurality of command responses generated by the payment device emulator based on the plurality of commands; and validate the card image file based on the plurality of command responses and the card data.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Application No. 62 / 900,870, filed September 16, 2019, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure relates generally to verifying card images and, in one specific non-limiting embodiment, to systems, methods, and computer program products for verifying card images. Background Art

[0004] When testing a transaction terminal, such as a point-of-sale (POS) system that includes a card reader, the testing entity may provide one or more test cards that are preconfigured to provide card data to the terminal being tested. Each test card, after being appropriately preconfigured, may then cause the POS system to initiate a payment transaction during testing, and depending on whether the payment transaction is approved or not approved within the payment network, individual testing of the POS system may determine whether the POS system is operating as expected or whether an error exists.

[0005] In some embodiments, the present invention relates to a method for testing a POS system that is not operated as expected. However, when troubleshooting a POS system that is not operated as expected, this method for testing may not provide the required level of detail. For example, when one or more test cards are not properly pre-configured, an error can be identified during the test transaction terminal. When there is an error, the individual performing the test may not be able to determine whether the error is due to the error relevant to the card data provided to the POS system, such as card data is not properly pre-configured, or may not be able to determine whether the error is due to the incorrect operation of the POS. Therefore, the individual may need to provide an additional test card to determine whether the POS system is not operated as expected or card data is not properly pre-configured. This may require taking additional steps to the troubleshooting process of the POS system, which may allow additional errors to be generated during the verification process of the POS system. This may also make it possible to consume additional network resources when processing a payment transaction during each test, especially in a payment processing system and / or a test system. Summary of the Invention

[0006] According to a non-limiting embodiment or aspect, a computer-implemented method is provided, comprising: parsing a card image file using at least one processor to determine card data represented by the card image file, the card image file being configured to be embedded on an integrated circuit of a payment device; generating a plurality of simulated payment transactions based on the card data using at least one processor, each simulated payment transaction including simulated transaction data; issuing a plurality of commands to a payment device emulator using at least one processor, the plurality of commands being based on the simulated transaction data of the plurality of simulated payment transactions; receiving a plurality of command responses generated by the payment device emulator based on the plurality of commands using at least one processor; and verifying the card image file based on the plurality of command responses and the card data using at least one processor.

[0007] In a non-limiting embodiment or aspect, generating the plurality of simulated payment transactions comprises identifying a subset of predefined payment transactions from a plurality of predefined payment transactions based on the card data. In a non-limiting embodiment or aspect, at least one of the plurality of command responses comprises dynamic card data, the dynamic card data comprising at least one of a cryptogram and a digital signature generated by the payment device emulator. In a non-limiting embodiment or aspect, the method further comprises: generating, using at least one processor, a report based on validating the card image file; and sending, using at least one processor, the report to a computing device. In a non-limiting embodiment or aspect, the card data comprises: application data associated with at least one supported application; supported transaction data associated with at least one supported transaction type; and account data associated with a payment account. In a non-limiting embodiment or aspect, the payment device emulator comprises a payment device or probe that is inserted into a card reader. In a non-limiting embodiment or aspect, validating the card image file comprises: comparing the plurality of command responses to expected values ​​based on the card data; validating each of the plurality of command responses if the command response matches the expected value; and validating the card image file in response to validating each of the plurality of command responses.

[0008] According to a non-limiting embodiment or aspect, a system is provided, comprising: a payment device emulator comprising a payment device inserted into a card reader; and at least one processor in communication with the payment device emulator, the at least one processor being programmed or configured to: parse a card image file to determine card data represented by the card image file, the card image file being configured to be embedded on an integrated circuit of the payment device; generate a plurality of simulated payment transactions based on the card data, each simulated payment transaction comprising simulated transaction data; issue a plurality of commands to the payment device emulator, the plurality of commands being based on the simulated transaction data of the plurality of simulated payment transactions; receive a plurality of command responses generated by the payment device emulator based on the plurality of commands; and verify the card image file based on the plurality of command responses and the card data.

[0009] In a non-limiting embodiment, the at least one processor generates the plurality of simulated payment transactions by identifying a subset of predefined payment transactions from a plurality of predefined payment transactions based on the card data. In a non-limiting embodiment, at least one of the plurality of command responses includes dynamic card data, the dynamic card data including at least one of a cryptogram and a digital signature generated by the payment device emulator. In a non-limiting embodiment, the at least one processor is further configured to: generate a report based on validating the card image file; and send the report to a computing device. In a non-limiting embodiment, the card data includes: application data associated with at least one supported application; supported transaction data associated with at least one supported transaction type; and account data associated with a payment account. In a non-limiting embodiment, validating the card image file includes: comparing the plurality of command responses to expected values ​​based on the card data; validating each of the plurality of command responses if the command response matches the expected value; and validating the card image file in response to validating each of the plurality of command responses.

[0010] In a non-limiting embodiment or aspect, a computer program product is provided, comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising one or more instructions that, when executed by at least one processor, cause the at least one processor to: parse a card image file to determine card data represented by the card image file; generate a plurality of simulated payment transactions based on the card data, each simulated payment transaction comprising simulated transaction data; issue a plurality of commands to a payment device emulator, the plurality of commands being based on the simulated transaction data of the plurality of simulated payment transactions; receive a plurality of command responses generated by the payment device emulator based on the plurality of commands; and validate the card image file based on the plurality of command responses and the card data.

[0011] In a non-limiting embodiment or aspect, the at least one processor generates the plurality of simulated payment transactions by identifying a subset of predefined payment transactions from a plurality of predefined payment transactions based on the card data. In a non-limiting embodiment or aspect, at least one of the plurality of command responses includes dynamic card data, the dynamic card data including at least one of a cryptogram and a digital signature generated by the payment device emulator. In a non-limiting embodiment or aspect, the instructions further cause the at least one processor to: generate a report based on validating the card image file; and send the report to a computing device. In a non-limiting embodiment or aspect, the card data includes: application data associated with at least one supported application; supported transaction data associated with at least one supported transaction type; and account data associated with a payment account. In a non-limiting embodiment or aspect, validating the card image file includes: comparing the plurality of command responses to expected values ​​based on the card data; validating each of the plurality of command responses if the command response matches the expected value; and validating the card image file in response to validating each of the plurality of command responses.

[0012] Other non-limiting embodiments or aspects are set forth in the following numbered clauses:

[0013] Clause 1: A computer-implemented method comprising: parsing a card image file, using at least one processor, to determine card data represented by the card image file, the card image file being configured to be embedded on an integrated circuit of a payment device; generating, using at least one processor, a plurality of simulated payment transactions based on the card data, each simulated payment transaction including simulated transaction data; issuing, using at least one processor, a plurality of commands to a payment device emulator, the plurality of commands being based on the simulated transaction data of the plurality of simulated payment transactions; receiving, using at least one processor, a plurality of command responses generated by the payment device emulator based on the plurality of commands; and validating, using at least one processor, the card image file based on the plurality of command responses and the card data.

[0014] Clause 2: The computer-implemented method of Clause 1, wherein generating the plurality of simulated payment transactions comprises identifying a subset of predefined payment transactions from a plurality of predefined payment transactions based on the card data.

[0015] Clause 3: The computer-implemented method of clause 1 or 2, wherein at least one command response of the plurality of command responses includes dynamic card data, the dynamic card data comprising at least one of a cryptogram and a digital signature generated by the payment device emulator.

[0016] Clause 4: The computer-implemented method of any of clauses 1 to 3, further comprising: generating, with at least one processor, a report based on verifying the card image file; and sending, with at least one processor, the report to a computing device.

[0017] Clause 5: A computer-implemented method according to any one of clauses 1 to 4, wherein the card data comprises: application data associated with at least one supported application; supported transaction data associated with at least one supported transaction type; and account data associated with a payment account.

[0018] Clause 6: The computer-implemented method of any one of clauses 1 to 5, wherein the payment device emulator comprises a payment device or probe inserted into a card reader.

[0019] Clause 7: A computer-implemented method according to any one of clauses 1 to 6, wherein verifying the card image file comprises: comparing the multiple command responses with expected values ​​based on the card data; verifying each of the multiple command responses if the command response matches the expected value; and verifying the card image file in response to verifying each of the multiple command responses.

[0020] Clause 8: A system comprising: a payment device emulator comprising a payment device inserted into a card reader; and at least one processor in communication with the payment device emulator, the at least one processor being programmed or configured to: parse a card image file to determine card data represented by the card image file, the card image file being configured to be embedded on an integrated circuit of the payment device; generate a plurality of simulated payment transactions based on the card data, each simulated payment transaction comprising simulated transaction data; issue a plurality of commands to the payment device emulator, the plurality of commands being based on the simulated transaction data of the plurality of simulated payment transactions; receive a plurality of command responses generated by the payment device emulator based on the plurality of commands; and verify the card image file based on the plurality of command responses and the card data.

[0021] Clause 9: The system of clause 8, wherein the at least one processor generates the plurality of simulated payment transactions by identifying a subset of predefined payment transactions from a plurality of predefined payment transactions based on the card data.

[0022] Clause 10: The system of clause 8 or 9, wherein at least one command response of the plurality of command responses includes dynamic card data comprising at least one of a cryptogram and a digital signature generated by the payment device emulator.

[0023] Clause 11: The system of any of clauses 8 to 10, wherein the at least one processor is further configured to: generate a report based on verifying the card image file; and send the report to a computing device.

[0024] Clause 12: A system according to any one of clauses 8 to 11, wherein the card data includes: application data associated with at least one supported application; supported transaction data associated with at least one supported transaction type; and account data associated with a payment account.

[0025] Clause 13: A system according to any one of clauses 8 to 12, wherein verifying the card image file includes: comparing the multiple command responses with expected values ​​based on the card data; verifying each of the multiple command responses if the command response matches the expected value; and verifying the card image file in response to verifying each of the multiple command responses.

[0026] Clause 14: A computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising one or more instructions that, when executed by at least one processor, cause the at least one processor to: parse a card image file to determine card data represented by the card image file; generate a plurality of simulated payment transactions based on the card data, each simulated payment transaction comprising simulated transaction data; issue a plurality of commands to a payment device emulator, the plurality of commands being based on the simulated transaction data of the plurality of simulated payment transactions; receive a plurality of command responses generated by the payment device emulator based on the plurality of commands; and validate the card image file based on the plurality of command responses and the card data.

[0027] Clause 15: The computer program product of clause 14, wherein the at least one processor generates the plurality of simulated payment transactions by identifying a subset of predefined payment transactions from a plurality of predefined payment transactions based on the card data.

[0028] Clause 16: The computer program product of clause 14 or 15, wherein at least one command response of the plurality of command responses includes dynamic card data comprising at least one of a cryptogram and a digital signature generated by the payment device emulator.

[0029] Clause 17: The computer program product of any of clauses 14 to 16, wherein the instructions further cause the at least one processor to: generate a report based on verifying the card image file; and send the report to a computing device.

[0030] Clause 18: A computer program product according to any one of clauses 14 to 17, wherein the card data comprises: application data associated with at least one supported application; supported transaction data associated with at least one supported transaction type; and account data associated with a payment account.

[0031] Clause 19: A computer program product according to any one of clauses 14 to 18, wherein verifying the card image file comprises: comparing the plurality of command responses with expected values ​​based on the card data; verifying each of the plurality of command responses if the command response matches the expected value; and verifying the card image file in response to verifying each of the plurality of command responses.

[0032] The features and characteristics of the present disclosure, as well as the methods of operation and function of the related structural elements and combinations of parts, and the economies of manufacturing will become more apparent when considering the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification wherein like reference numerals designate corresponding parts in the various figures. However, it is to be expressly understood that the drawings are for illustration and description purposes only and are not intended to be construed as definitions of the limits of the present disclosure. As used in this specification and claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Additional advantages and details of the present disclosure are explained in more detail below with reference to exemplary embodiments illustrated in the accompanying drawings, in which:

[0034] Figure 1 is a diagram of a system for verifying a card image according to a non-limiting embodiment or aspect;

[0035] Figure 2 is a diagram of a system for verifying a card image according to a non-limiting embodiment or aspect;

[0036] Figure 3 is a diagram of a system for verifying a card image according to a non-limiting embodiment or aspect;

[0037] Figure 4 is a flow chart of a method for verifying a card image according to a non-limiting embodiment or aspect;

[0038] Figure 5A and 5B A card image file according to a non-limiting embodiment or aspect is shown;

[0039] Figure 6 shows a card personalization data map according to a non-limiting embodiment or aspect;

[0040] Figure 7 illustrates verification of a transaction sequence according to a non-limiting embodiment or aspect; and

[0041] Figure 8 for Figure 1-3 A diagram of a non-limiting embodiment of components of one or more devices. DETAILED DESCRIPTION

[0042] For descriptive purposes hereinafter, the terms "end," "upper," "lower," "right," "left," "vertical," "horizontal," "top," "bottom," "lateral," "longitudinal," and their derivatives shall refer to the present disclosure as it is oriented in the accompanying drawings. However, it will be understood that the present disclosure may employ various alternative variations and step sequences, unless expressly specified to the contrary. It will also be understood that the specific devices and processes illustrated in the accompanying drawings and described in the following description are merely exemplary embodiments or aspects of the present disclosure. Accordingly, specific dimensions and other physical characteristics associated with the embodiments or aspects of the embodiments disclosed herein should not be considered as limiting unless otherwise indicated.

[0043] As used herein, aspects, components, elements, structures, actions, steps, functions, instructions, etc. should not be understood as being critical or necessary unless explicitly described as such. Also, as used herein, the article "one" is intended to include one or more items and can be used interchangeably with "one or more" and "at least one". In addition, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, a combination of related items and unrelated items, etc.), and can be used interchangeably with "one or more" or "at least one". In the case of wishing only one item, the term "one" or similar language is used. Also, as used herein, the term "having" etc. is intended to be an open term. Additionally, unless explicitly stated otherwise, the phrase "based on" is intended to mean "at least partially based on".

[0044] As used herein, the terms "communication" and "transmission" may refer to the reception, admission, transmission, transmission, provision, etc. of information (e.g., data, signals, messages, instructions, commands, etc.). A unit (e.g., a device, a system, a component of a device or system, a combination thereof, etc.) communicating with another unit means that the unit is able to directly or indirectly receive information from the other unit and / or transmit (e.g., send) information to the other unit. This may refer to a direct or indirect connection that is wired and / or wireless in nature. In addition, the two units may communicate with each other even if the information sent may be modified, processed, relayed, and / or routed between the first unit and the second unit. For example, even if the first unit passively receives information and does not actively send information to the second unit, the first unit may communicate with the second unit. As another example, if at least one intermediate unit (e.g., a third unit located between the first unit and the second unit) processes the information received from the first unit and sends the processed information to the second unit, the first unit may communicate with the second unit. In some non-limiting embodiments or aspects, a message may refer to a network packet (e.g., a data packet, etc.) comprising data.

[0045] As used herein, the terms "issuer," "issuer institution," "issuer bank," or "payment device issuer" may refer to one or more entities that provide an individual (e.g., a user, customer, etc.) with an account for conducting payment transactions, such as credit payment transactions and / or debit payment transactions. For example, an issuer institution may provide a customer with an account identifier, such as a primary account number (PAN), that uniquely identifies one or more accounts associated with the customer. In some non-limiting embodiments or aspects, an issuer may be associated with a bank identification number (BIN) that uniquely identifies the issuer institution. As used herein, an "issuer system" may refer to one or more computer systems operated by or on behalf of an issuer, such as a server that executes one or more software applications. For example, an issuer system may include one or more authorization servers for authorizing transactions.

[0046] As used herein, the term "account identifier" may include one or more types of identifiers associated with an account (e.g., a PAN associated with an account, a card number associated with an account, a payment card number associated with an account, a token associated with an account, etc.). In some non-limiting embodiments or aspects, an issuer may provide an account identifier (e.g., a PAN, a token, etc.) to a user (e.g., an account holder), wherein the account identifier uniquely identifies one or more accounts associated with the user. The account identifier may be embodied on a payment device (e.g., a physical instrument used to conduct payment transactions, such as a payment card, credit card, debit card, gift card, etc.) and / or may be electronic information transmitted to the user, which the user may use for electronic payment transactions. In some non-limiting embodiments or aspects, the account identifier may be an original account identifier, which is provided to the user when the account associated with the account identifier is created. In some non-limiting embodiments or aspects, the account identifier may be a supplemental account identifier, which may include an account identifier provided to the user after the original account identifier is provided to the user. For example, the supplemental account identifier may be provided to the user if the original account identifier is forgotten, stolen, etc. In some non-limiting embodiments or aspects, the account identifier may be directly or indirectly associated with an issuing institution, such that the account identifier may be a token mapped to a PAN or other type of account identifier. The account identifier may be any combination of alphanumeric characters, symbols, and / or the like.

[0047] As used herein, the term "merchant" may refer to one or more entities (e.g., operators of retail businesses) that provide goods, services, and / or access to goods and / or services to users (e.g., clients, customers, etc.) based on transactions such as payment transactions. As used herein, the term "merchant system" may refer to one or more computer systems operated by or on behalf of a merchant, such as a server that executes one or more software applications. As used herein, the term "product" may refer to one or more goods and / or services provided by a merchant.

[0048] As used herein, the term "point of sale (POS) device" may refer to one or more electronic devices, such as a transaction terminal, that can be used by a merchant to initiate a transaction (e.g., a payment transaction). POS devices may include peripheral devices, card readers, scanning devices (e.g., code scanners, etc.), Communication receiver, near field communication (NFC) receiver, radio frequency identification (RFID) receiver and / or other contactless transceiver or receiver, contact-based receiver, payment terminal, etc. As used herein, the term "point of sale (POS) system" may refer to one or more client devices and / or peripheral devices used by merchants to conduct transactions. For example, a POS system may include one or more POS devices, and / or other similar devices that can be used to conduct payment transactions. In some non-limiting embodiments or aspects, a POS system (e.g., a merchant POS system) may include one or more server computers programmed or configured to process online payment transactions through a web page, mobile application, etc.

[0049] As used herein, the term "transaction service provider" may refer to an entity that receives transaction authorization requests from merchants or other entities and, in some cases, provides payment assurance through an agreement between the transaction service provider and an issuer organization. In some non-limiting embodiments or aspects, the transaction service provider may include a credit card company, a debit card company, e.g., American , or any other entity that processes transactions. As used herein, the term "transaction service provider system" may refer to one or more computer systems operated by or on behalf of a transaction service provider, such as a transaction service provider system that executes one or more software applications. The transaction service provider system may include one or more processors and, in some non-limiting embodiments or aspects, may be operated by or on behalf of a transaction service provider.

[0050] As used herein, the term "computing device" may refer to one or more electronic devices configured to process data. In some examples, a computing device may include the necessary components to receive, process, and output data, such as a processor, a display, a memory, an input device, a network interface, and the like. A computing device may be a mobile device. By way of example, a mobile device may include a cellular phone (e.g., a smartphone or a standard cellular phone), a portable computer, a wearable device (e.g., a watch, glasses, lenses, clothing, etc.), a personal digital assistant (PDA), and / or other similar devices. A computing device may also be a desktop computer or other form of non-mobile computer.

[0051] As used herein, the term "server" may refer to or include one or more computing devices that are operated by or facilitate communications and processing by multiple parties in a network environment such as the Internet, but it should be understood that communications may be facilitated through one or more public or private network environments, and that various other arrangements may be possible. In addition, multiple computing devices (e.g., servers, POS devices, mobile devices, etc.) that communicate directly or indirectly in a network environment may constitute a "system." As used herein, references to "server" or "processor" may refer to previously described servers and / or processors, different servers and / or processors, and / or combinations of servers and / or processors that are stated to implement previous steps or functions. For example, as used in the specification and claims, a first server and / or first processor stated to implement a first step or function may refer to the same or different servers and / or processors stated to implement a second step or function.

[0052] Non-limiting embodiments or aspects of the present disclosure relate to methods, systems and computer program products for verifying card images and / or testing transaction terminals. By means of the features described herein, POS systems can be tested without involving additional processing by external systems or entities (e.g., transaction service provider systems, payment gateway service provider systems, etc.). This allows saving computing resources and prevents unnecessary business on existing payment processing networks. In addition, in non-limiting embodiments, the systems and methods described herein can allow individuals testing POS systems to obtain the enhanced level of detail required when troubleshooting POS systems. For example, one or more test cards can be checked to verify that the test cards are correctly pre-configured before testing the POS system, and therefore, additional test cards may not be needed to determine whether the POS system is operating as expected. In addition, network resources can be saved that would otherwise be consumed to determine whether the POS system is not operating as expected or whether the card images are correctly pre-configured.

[0053] Reference Figure 1 , a system 1000 for verifying a card image is shown according to a non-limiting embodiment. The system 1000 includes a verification system 102, which can be a computing device executing one or more software applications. In a non-limiting embodiment, the card image verification system 102 can replace a transaction terminal for the purpose of verifying a card image file 104 in a general test implementation scheme for testing a transaction terminal and / or a payment device. The verification system 102 communicates with a verification database 112 and a payment device emulator 106. The payment device emulator 106 can include a computing device that is configured to provide a simulated output for a payment device, such as an EMV chip. The payment device emulator 106 can include a physical payment device, such as a card including an EMV chip, or can include a simulated payment device, such as a probe, that is inserted into a card reader (in a Figure 2) and communicates with a computing device that generates a signal representing the payment device and transmits the signal via the probe. In a non-limiting embodiment, the payment device emulator 106 emulates a payment device including the card data represented by the card image file 104. As used herein, the term "payment device" may refer to an integrated circuit having stored thereon data configured for contact and / or contactless payment functionality at a transaction terminal. A payment device may also refer to a physical payment card, such as a credit or debit card, having an integrated circuit embedded thereon. The verification system 102 may communicate with a verification database 112 that stores verification results and a transaction database 114 that stores predefined transactions.

[0054] exist Figure 2 Another diagram of a system 1002 for verifying a card image is shown in FIG. 1 according to a non-limiting embodiment or aspect. Figure 2 As shown, the verification system 102 can communicate with a card reader 202. The card reader 202 may include a device configured to receive a payment device, such as an EMV chip, and access data stored on the payment device. For example, the card reader 202 may be internal to the verification system (e.g., the verification system may be a desktop or laptop computer with an internal card reader) and / or may be an external peripheral device. The card reader 202 may be configured for contact-based communication via a physical connection (e.g., via one or more electrical contacts) and / or via short-range wireless communication (e.g., NFC communication connection, RFID communication connection, Communication connection, etc.) for contactless communication.

[0055] Continue to refer Figure 1 and 2 , the verification system 102 issues a command 108 (e.g., generates and transmits a command) to the payment device emulator 106 and receives a command response 110. The command 108 may include instructions configured to cause the payment device emulator 106 to return one or more values ​​and / or perform one or more functions. In this manner, the verification system 102 verifies the card image file 104 and the card data stored therein by comparing the card data with the command response 110 received from the payment device emulator 106 and verifying various portions of the card image file 104. The results of such verification may be stored in a verification database 112. In some non-limiting embodiments, the results of the verification may be transmitted via one or more networks to a separate system, such as a transaction processing system (not shown).

[0056] Reference Figure 3 , a system 1003 for verifying a card image is shown according to a non-limiting embodiment. Figure 3The verification system 102 in FIG. 1 includes a parsing module 302, a transaction generator module 304, a transaction execution module 306, and a verification module 308. Each of the modules may include one or more software and / or hardware components. For example, each of the modules 302, 304, 306, and 308 may be a function of one or more software applications executed by one or more computing devices, and / or may each be a separate computing device. In addition, one or more of the modules 302, 304, 306, and 308 may be a remote server ( Figure 3 308 ) upon request, for example, via an application programming interface (API). It should be appreciated that various arrangements of modules 302, 304, 306, 308 may be used.

[0057] Continue to refer Figure 3 Parsing module 302 may parse card data from card image file 104. For example, parsing module 302 may parse the card data to determine application data associated with at least one supported application. In another example, parsing module 302 may parse the card data to determine supported transaction data associated with at least one supported transaction type. In another example, parsing module 302 may parse the card data to determine account data associated with a payment account. Parsing the card data may include moving and / or copying the card data to another location, such as a memory of a computing device. Parsing the card data may separate the card data into different data groups specified by one or more rules. The data groups may be predefined or customized based on user requirements. In a non-limiting embodiment, the parsed card data may maintain the same data structure as the card data in card image file 104.

[0058] Continue to refer Figure 3 , the transaction generator module 304 may generate one or more simulated transactions based on the card data. For example, the transaction generator module 304 may identify one or more predefined transactions from the transaction database 114, where each predefined transaction includes simulated transaction data, such as a transaction amount, date / time, PAN, expiration date, etc. In other examples, the transaction generator module 304 may dynamically generate transactions with random values ​​and / or determined values ​​based on the card data. The transaction generation module determines the transaction and simulated transaction data based on the card data (e.g., application data indicating available applications, supported transaction data indicating available transaction types, account data identifying characteristics or parameters of a user account, etc.).

[0059] For example, the transaction generator module 304 may determine that the card image is associated with a contactless payment transaction and, in response, may generate simulated transaction data for the contactless transaction. In this case, the simulated transaction data for the generated transaction may specify a contactless protocol (e.g., ISO 14443). As another example, the transaction generator module 304 may determine that the card image is associated with a contactless payment transaction and, in response, may generate simulated transaction data for a contactless transaction that specifies a contact-based protocol (e.g., ISO 7816). It should be understood that transactions and / or simulated transaction data may also be retrieved by the verification system 102 from a separate system. In some non-limiting embodiments, the verification system 102 may utilize emulation of a POS device to generate transaction data. For example, the image verification system 102 may provide card data, application data, supported transaction data, and / or account data as input to the emulation of the POS device, so that the emulation of the POS device provides transaction data as output.

[0060] Still refer to Figure 3 , the transaction execution module 306 can use the payment device emulator 106 to execute the transactions based on the simulated transaction data for each transaction. The transaction execution module 306 can generate a plurality of commands 108 to be sent to (e.g., transmitted to) the payment device emulator 106. The commands 108 can be generated based on the simulated transaction data for each transaction. Each command 108 can be for an intermittent transaction and / or a specific function associated with the intermittent transaction. For example, a command 108 can involve reading account data from the payment device emulator 106. The command 108 can also request the generation of a cryptogram based on the account data and an encryption key. The transaction execution module 306 also receives a command response 110 from the payment device emulator 106 for each command 108 or a batch of commands 108.

[0061] Continue to refer Figure 3 , the verification module 308 may determine a verification result based on the verification command response 110. For example, the verification system 102 (e.g., the parsing module 302) may derive static transaction data (e.g., PAN, expiration date, name, etc.) associated with the valid payment transaction response from the card data. The verification module 308 may compare the static data and / or the valid payment transaction response generated based on the static transaction data with the command response 110. In this example, the verification module 308 may determine whether the simulated payment transaction is valid or invalid based on comparing the static data or the valid simulated payment transaction response generated based on the static transaction data with the simulated payment transaction response data received or derived from the command response 110. In response to determining that the values ​​match (e.g., the static data is valid), the verification module 308 may determine that the card image file 104 is verified or partially verified. In response to determining that the values ​​do not match, the verification module 308 may determine that the card image file 104 is not verified or is invalid.

[0062] In another non-limiting example, verification system 102 (e.g., transaction generator module 304) may derive dynamic transaction data associated with a valid payment transaction response from the card data. For example, verification system 102 may generate a cryptogram based on account data from the card data and at least one encryption key. Verification module 308 may compare the dynamic data (e.g., the cryptogram) with the dynamic transaction data returned in command response 110 (e.g., a cryptogram generated using a payment device emulator). In this example, verification module 308 may determine whether the cryptogram is valid or invalid based on comparing the two cryptograms or other dynamically generated data. In response to determining that the values ​​match, verification module 308 may determine that card image file 104 is verified or partially verified. In response to determining that the values ​​do not match, verification module 308 may determine that card image file 104 is unverified or invalid.

[0063] In another non-limiting example, the verification module 308 may compare the simulated response code returned from the command response 110 with a predetermined valid response code. For example, the verification module 308 may compare the simulated response code with a predetermined valid response code from the valid response code index. In response to determining that the codes match, the verification module 308 may determine that the card image file 104 is verified or partially verified. In response to determining that the codes do not match, the verification module 308 may determine that the card image file 104 is not verified or is invalid.

[0064] Still refer to Figure 3 In some non-limiting embodiments, the verification module 308 may determine whether the card image file 104 is verified or unverified based on one or more command responses 110 and the comparison. For example, the verification module 308 may determine that the card image file 104 is verified in response to each command response 110 in the plurality of command responses being verified. Similarly, the verification module 308 may determine that the card image file 104 is unverified in response to a single command response 110, a specific command response 110, and / or a predetermined number of command responses 110 being determined to be invalid. In a non-limiting embodiment, if each of the received command responses 110 is verified, then the card image file 104 is verified.

[0065] In a non-limiting embodiment, the verification module 308 may automatically generate a report based on the determination that the card image file 104 is verified or not verified. The report may include a summary of the commands 108 and command responses 110 that were executed and / or determined to be valid and / or invalid. The report may be automatically transmitted to the computing device based on the results or regardless of the results. For example, the report may be transmitted from the verification system 102 to the transaction processing system ( Figure 3In some non-limiting embodiments or aspects, the report can be presented in a machine-readable equivalent format, such as Extensible Markup Language (XML) and / or Hypertext Markup Language (HTML).

[0066] Reference Figure 4 , a flow chart illustrating a non-limiting embodiment of a process for verifying a card image file. In some non-limiting embodiments, one or more steps of the process may be performed (e.g., completely, partially, etc.) by the verification system 102 (e.g., one or more devices of the verification system 102). In some non-limiting embodiments or aspects, one or more steps of the process may be performed (e.g., completely, partially, etc.) by another device or group of devices that is separate from or includes the verification system 102 (e.g., a computing device). Figure 4 The steps shown are for example purposes only. Additional, fewer, different steps and / or a different order of steps may be used.

[0067] Referring to the first step 400, the card image file is parsed to extract card data from the card image file. For example, the verification system 102 may parse the card data to determine application data associated with at least one supported application, supported transaction data associated with at least one supported transaction type, account data associated with a payment account, etc. At the next step 402, a plurality of transactions are generated based on the card data determined in step 400. For example, one or more predefined transactions may be identified, each of which includes simulated transaction data, such as a transaction amount, date / time, PAN, expiration date, etc. In other examples, the transactions and simulated transaction data are determined based on the card data (e.g., application data indicating available applications, supported transaction data indicating available transaction types, account data identifying characteristics or parameters of a user account, etc.).

[0068] refer to Figure 4 At step 404, the multiple transactions generated at step 402 are executed, starting with generating multiple commands to be sent to (e.g., transmitted to) the payment device emulator. The commands may be generated based on the simulated transaction data for each transaction. Each command may be specific to an intermittent transaction and / or a specific function associated with the intermittent transaction. For example, a command may involve reading account data from the payment device emulator. The command may also request the generation of a password based on the account data and an encryption key. At step 406, the command is sent to (e.g., transmitted to) the payment device emulator, which executes the command and returns a command response. The command response is received at step 408. It should be understood that the commands and responses may be separate and / or batched.

[0069] At step 410, the command response is verified by comparing the command response or the date included in the command response to the expected value from the card data obtained at step 400, the transaction data generated at step 402, and / or any other value derived therefrom. If the match fails (e.g., the data does not match), the method proceeds to step 412 and determines that the card image file is invalid and therefore unverified. If the values ​​do match at step 410, the method proceeds to step 414 to iterate any additional transactions and / or commands. Steps 404 to 414 may be repeated until the method ends at step 412 with an invalid value or completes all transactions generated at step 402. In some instances, even if an invalid value is found at step 412, the method may continue to test other aspects of the card image file and therefore not terminate at step 412.

[0070] At step 416, once all transactions and / or commands have been processed, the card image file is verified. For example, in response to reaching step 416 without invalidating any static data and / or dynamic data, the card image file may be automatically determined to be verified. In a non-limiting embodiment, the card image file is verified at step 416 if each of the command responses received at step 410 is verified. At step 416, a report may be automatically generated based on the determination that the card image file is verified or not. The report may include a summary of the commands and command responses executed and / or determined to be valid and / or invalid.

[0071] Figure 5A and 5B A card image file is shown according to a non-limiting embodiment. In the depicted example, the card image file is in Extensible Markup Language (XML) format, but various other forms of structured data may be used. The card data in the depicted card image file is in EMV L3 format, but it should be understood that other formats and protocols may be used.

[0072] Figure 6 The card data is shown in the form of a card personalization data map 600 extracted from a card image file. The card data is divided into different indexed data groups 602, 604, 606 specified by one or more rules. The data groups can be predefined or customized based on the user's requirements. The system, for example Figure 3The transaction generator module 304 of the illustrated verification system 102 determines which data to verify from each data group. The supported transaction types (e.g., contactless, contactless, and / or protocol type) may be specified in the card data or derived from the data. For example, transaction protocols may include Visa Smart Debit / Credit (VSDC), Quick VSDC (qVSDC), Magstripe (MSD), and / or any other type of payment protocol. Once the transaction type is identified, the transaction generated using the simulated transaction data may include a transaction sequence 604 for execution, such that the transaction sequence 604 represents one or more sequential commands to be issued to the payment device emulator.

[0073] Figure 7 The verification of transaction sequences involving different protocols (VSDC, qVSDC, MSD) is shown, where each transaction sequence includes several commands 702, which are issued and matched against expected values ​​for verification. If all commands are determined to return valid values, the card image file is determined to be verified. The response to the command can return static and / or dynamic transaction data. Static transaction data can be verified by comparing the static transaction data with expected values. Dynamic transaction data can be calculated based on the transaction sequence. The calculated dynamic transaction data can then be verified by comparing it with the expected value of the dynamic transaction data.

[0074] Reference Figure 8 , which shows a diagram of example components of an apparatus 900. As an example, the apparatus 900 may correspond to Figure 1 In some non-limiting embodiments, such a system or device may include at least one device 900 and / or at least one component of device 900. The number and arrangement of components shown are provided as examples. In some non-limiting embodiments, Figure 1 The device 900 may include additional components, fewer components, different components, or components arranged differently than those shown. Additionally or alternatively, one or more components of the device 900 may perform one or more functions described as being performed by another set of components of the device 900.

[0075] like Figure 8As shown, the device 900 may include a bus 902, a processor 904, a memory 906, a storage component 908, an input component 910, an output component 912, and a communication interface 914. The bus 902 may include components that permit communication between the components of the device 900. In some non-limiting embodiments, the processor 904 may be implemented in hardware, firmware, or a combination of hardware and software. For example, the processor 904 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, a digital signal processor (DSP), and / or any processing component that can be programmed to perform a function (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.). The memory 906 may include a random access memory (RAM), a read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions for use by the processor 904.

[0076] Continue to refer Figure 8 The storage component 908 may store information and / or software related to the operation and use of the device 900. For example, the storage component 908 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, a solid-state disk, etc.) and / or another type of computer-readable medium. The input component 910 may include a component that allows the device 900 to receive information, for example, via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, a microphone, etc.). Additionally or alternatively, the input component 910 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). The output component 912 may include a component that provides output information from the device 900 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.). The communication interface 914 may include a transceiver-type component (e.g., a transceiver, a separate receiver and transmitter, etc.) that enables the device 900 to communicate with other devices, for example, via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 914 may allow the device 900 to receive information from another device and / or provide information to another device. For example, the communication interface 914 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, interface, cellular network interface, etc.

[0077] Device 900 can perform one or more processes described herein. Device 900 can perform these processes based on processor 904 executing software instructions stored by computer-readable media such as memory 906 and / or storage component 908. Computer-readable media may include any non-transitory memory device. Memory devices include memory space located within a single physical storage device or memory space distributed across multiple physical storage devices. Software instructions can be read from another computer-readable medium or from another device into memory 906 and / or storage component 908 via communication interface 914. When executed, the software instructions stored in memory 906 and / or storage component 908 can cause processor 904 to perform one or more processes described herein. In addition or alternatively, hard-wired circuitry can replace or be used in conjunction with software instructions to perform one or more processes described herein. Therefore, the embodiments described herein are not limited to any specific combination of hardware circuitry and software. As used herein, the term "programmed or configured" refers to the arrangement of software, hardware circuitry, or any combination thereof on one or more devices.

[0078] Although the embodiments have been described in detail for purposes of illustration, it should be understood that such detail is solely for that purpose and that the present disclosure is not limited to the disclosed embodiments, but, on the contrary, is intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it should be understood that the present disclosure contemplates that, to the extent possible, one or more features of any embodiment can be combined with one or more features of any other embodiment.

Claims

1. A computer-implemented method comprising: parsing a card image file with at least one processor to extract card data stored on the card image file, the card image file being configured to be embedded on an integrated circuit of a payment card; generating, with at least one processor, at least one first cryptogram based on the card data and at least one cryptographic key; generating, with at least one processor, a plurality of simulated payment transactions based on the card data, each simulated payment transaction comprising simulated transaction data, wherein the simulated transaction data is generated via emulation of a point-of-sale (POS) device, and wherein the emulation of the POS device receives at least the card data as input and provides the simulated transaction data as output; generating, using at least one processor, a transaction sequence comprising a plurality of sequential commands based on the simulated transaction data of the plurality of simulated payment transactions, wherein each of the plurality of sequential commands is associated with an intermittent transaction in the plurality of simulated payment transactions; transmitting, with at least one processor, the plurality of sequential commands to a payment device emulator, the payment device emulator comprising a simulated payment device, the simulated payment device comprising a probe inserted into a card reader, wherein the probe is in communication with a first computing device, the first computing device generates a signal representative of the payment device and transmits the signal via the probe to the payment device emulator, and wherein the plurality of sequential commands comprises instructions configured to cause the card reader to return dynamic transaction data, the dynamic transaction data comprising at least one second cryptogram generated using the simulated payment device; receiving, using at least one processor, a plurality of command responses generated by the simulated payment device based on the plurality of sequential commands, the plurality of command responses including at least one second password; as well as comparing, using at least one processor, at least one second password to at least one first password; matching, using at least one processor, the at least one second password with the at least one first password based on the comparison; determining, with at least one processor, whether each command response in the plurality of command responses is a valid command response or an invalid command response based on matching the at least one second ciphertext with the at least one first ciphertext; verifying, with at least one processor, that the card image file is a valid command response based on determining a predetermined number of command responses from the plurality of command responses; automatically generating, with at least one processor, a report based on verifying the card image file, the report including a summary of a plurality of sequential commands and a plurality of command responses determined to be valid command responses; as well as The report is automatically transmitted, using at least one processor, to a second computing device separate from the first computing device. 2 . The computer-implemented method of claim 1 , wherein generating the plurality of simulated payment transactions comprises identifying a subset of predefined payment transactions from a plurality of predefined payment transactions based on the card data. 3 . The computer-implemented method of claim 1 , wherein at least one command response of the plurality of command responses comprises dynamic card data, the dynamic card data comprising a digital signature generated by the payment device emulator.

4. The computer-implemented method of claim 1 , wherein the card data comprises: application data associated with at least one supported application; supported transaction data associated with at least one supported transaction type; as well as Account data associated with the payment account.

5. A system comprising: a payment device emulator, which includes a probe that inserts into a card reader; as well as at least one processor in communication with the payment device emulator, the at least one processor being programmed or configured to: parsing a card image file to extract card data stored on the card image file, the card image file being configured to be embedded on an integrated circuit of a payment card; generating at least one first cryptogram based on the card data and at least one cryptographic key; generating a plurality of simulated payment transactions based on the card data, each simulated payment transaction comprising simulated transaction data, wherein the simulated transaction data is generated via emulation of a point-of-sale (POS) device, and wherein the emulation of the POS device receives at least the card data as input and provides the simulated transaction data as output; generating a transaction sequence, the transaction sequence comprising a plurality of sequential commands, the plurality of sequential commands being based on the simulated transaction data of the plurality of simulated payment transactions, wherein each of the plurality of sequential commands is associated with an intermittent transaction in the plurality of simulated payment transactions; transmitting the plurality of sequential commands to a payment device emulator, the payment device emulator comprising a simulated payment device, the simulated payment device comprising a probe inserted into a card reader, wherein the probe is in communication with a first computing device, the first computing device generates a signal representative of the payment device and transmits the signal via the probe to the payment device emulator, and wherein the plurality of sequential commands comprises instructions configured to cause the card reader to return dynamic transaction data, the dynamic transaction data comprising at least one second cryptogram generated using the simulated payment device; receiving a plurality of command responses generated by the simulated payment device based on the plurality of sequential commands, the plurality of command responses including at least one second password; and comparing, with at least one processor, at least one second code to at least one first code; matching, with at least one processor, the at least one second password with the at least one first password based on the comparison; determining whether each of the plurality of command responses is a valid command response or an invalid command response based on matching the at least one second ciphertext with the at least one first ciphertext; verifying that the card image file is a valid command response based on determining a predetermined number of command responses of the plurality of command responses; automatically generating a report based on verifying the card image file, the report including a summary of a plurality of sequential commands and a plurality of command responses determined to be valid command responses; as well as The report is automatically transmitted to a second computing device separate from the first computing device.

6. The system of claim 5, wherein the at least one processor generates the plurality of simulated payment transactions by identifying a subset of predefined payment transactions from a plurality of predefined payment transactions based on the card data.

7. The system of claim 5, wherein at least one of the plurality of command responses comprises dynamic card data, the dynamic card data comprising a digital signature generated by the payment device emulator.

8. The system of claim 5, wherein the card data comprises: application data associated with at least one supported application; supported transaction data associated with at least one supported transaction type; as well as Account data associated with the payment account.

9. A computer program product comprising at least one non-transitory computer-readable medium comprising one or more instructions that, when executed by at least one processor, cause the at least one processor to: parsing a card image file to extract card data stored on the card image file, the card image file being configured to be embedded on an integrated circuit of a payment device card; generating at least one first cryptogram based on the card data and at least one cryptographic key; generating a plurality of simulated payment transactions based on the card data, each simulated payment transaction comprising simulated transaction data, wherein the simulated transaction data is generated via emulation of a point-of-sale (POS) device, and wherein the emulation of the POS device receives at least the card data as input and provides the simulated transaction data as output; generating a transaction sequence, the transaction sequence comprising a plurality of sequential commands, the plurality of sequential commands being based on the simulated transaction data of the plurality of simulated payment transactions, wherein each of the plurality of sequential commands is associated with an intermittent transaction in the plurality of simulated payment transactions; transmitting the plurality of sequential commands to a payment device emulator, the payment device emulator comprising a simulated payment device, the simulated payment device comprising a probe inserted into a card reader, wherein the probe is in communication with a first computing device, the first computing device generates a signal representative of the payment device and transmits the signal via the probe to the payment device emulator, and wherein the plurality of sequential commands comprises instructions configured to cause the card reader to return dynamic transaction data, the dynamic transaction data comprising at least one second cryptogram generated using the simulated payment device; receiving a plurality of command responses generated by the simulated payment device based on the plurality of sequential commands, the plurality of command responses including at least one second password; and comparing at least one second password to at least one first password; matching, with at least one processor, the at least one second password with the at least one first password based on the comparison; determining whether each of the plurality of command responses is a valid command response or an invalid command response based on matching the at least one second ciphertext with the at least one first ciphertext; verifying that the card image file is a valid command response based on determining a predetermined number of command responses of the plurality of command responses; automatically generating a report based on verifying the card image file, the report including a summary of a plurality of sequential commands and a plurality of command responses determined to be valid command responses; as well as The report is automatically transmitted to a second computing device separate from the first computing device.

10. The computer program product of claim 9, wherein the at least one processor generates the plurality of simulated payment transactions by identifying a subset of predefined payment transactions from a plurality of predefined payment transactions based on the card data.

11. The computer program product of claim 9, wherein at least one command response of the plurality of command responses comprises dynamic card data comprising at least one of a cryptogram and a digital signature generated by the payment device emulator.

12. The computer program product of claim 9, wherein the card data comprises: application data associated with at least one supported application; supported transaction data associated with at least one supported transaction type; as well as Account data associated with the payment account.

Images