Method and system for enhanced password verification for variable account length
By storing formatted templates associated with account length in the computing device and generating and formatting data strings, the problem that existing systems are difficult to adapt to transaction accounts of different lengths is solved, and the effective transmission of data required for payment transactions is achieved and data restrictions are avoided.
Patent Information
- Application Number
- CN202111238713.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2015-12-31
- Filing Date
- 2016-08-15
- Publication Date
- 2025-03-21
- Estimated Expiration
- 2036-08-15
AI Technical Summary
It is difficult for existing systems to adapt to transaction accounts of different lengths, while ensuring that the passwords and other data required for payment transactions are transmitted without exceeding the data limit.
By storing multiple formatted templates in a computing device, each template associated with a specific account length, a data string is generated and formatted to accommodate transaction accounts of different lengths and unpredictable numbers.
It realizes adaptability to transaction accounts of different lengths, ensures the effective transmission of passwords and other data required for payment transactions, and avoids the problem of data exceeding the limit.
Smart Images

Figure CN113962698B_ABST
Abstract
Description
[0001] This application is a divisional application of the invention patent application with application number 201680063377.9 filed on August 15, 2016.
[0002] CROSS-REFERENCE TO RELATED APPLICATIONS
[0003] This application claims priority to and the benefit of the filing dates of U.S. Patent Application No. 62 / 210,659, filed on August 27, 2015, and U.S. Patent Application No. 14 / 985,664, filed on December 31, 2015, which are hereby incorporated by reference in their entireties. Technical Field
[0004] The present disclosure relates to enhancing password authentication for use in cloud-based systems, and more particularly, to enhancing password authentication based on the length of an account number and unpredictable numbers used therein and including the password in a data string of different data. Background Art
[0005] During a payment transaction involving a payment card, a cryptogram is typically generated for payment card authentication and transaction authorization. In many cases, the cryptogram may be generated by the payment card itself (e.g., in a payment card with an integrated circuit) or by a computing device (e.g., a smartphone or tablet) that is used to transmit the payment details. However, there are limits on the amount of data that can be transmitted from a payment card or computing device to a point of sale for inclusion in a transaction message for a payment transaction. As a result, payment cards and computing devices typically use a specific format for the data that is transmitted, which includes at least the cryptogram and the transaction account number.
[0006] However, as the number and types of transaction accounts increase, many financial institutions and other entities prefer to use account numbers of different lengths. In particular, many entities prefer to extend the transaction account number beyond an additional 16 digits to improve routing, accommodate a greater number of transaction accounts, etc. Existing systems are configured to use the limits of the data space available for transmission to the point of sale and included in the transaction message. Therefore, conventional computing systems are not equipped to use transaction account numbers of different lengths, because the rest of the data to be transmitted to the point of sale must be changed, especially when ensuring that the correct password and additional data are included.
[0007] Therefore, a technical solution is needed in which a computing device can be appropriately configured to accommodate transaction account numbers of varying lengths while still including passwords and other data required for payment transactions and not exceeding data limits. Summary of the invention
[0008] This disclosure describes systems and methods for enhancing password verification for different account lengths.
[0009] A method for enhancing password verification for variable account lengths, comprising: storing one or more primary account numbers and multiple formatting templates in a memory of a computing device, wherein each template is associated with at least one account length; receiving, by an input device of the computing device, an indication of selection of a specific primary account number from the one or more primary account numbers; executing, by a query module of the computing device, a query in the memory to identify a specific formatting template from the multiple formatting templates, wherein the associated account length corresponds to the length of the specific primary account number; receiving, by a receiving device of the computing device, at least an unpredictable number from a point-of-sale device; generating, by a generation module of the computing device, a password based at least on the unpredictable number and one or more algorithms; generating, by the generation module of the computing device, a data string, wherein the data string includes at least the generated password, the specific primary account number, and the unpredictable number, and wherein the data string is formatted based on the identified specific formatting template; and sending, by a sending device of the computing device, electronically sending the generated data string to the point-of-sale device.
[0010] A system for enhancing verification of passwords for variable account lengths, comprising: a memory of a computing device configured to store one or more primary account numbers and a plurality of formatting templates, wherein each template is associated with at least one account length; an input device of the computing device configured to receive an indication of a selection of a particular primary account number among the one or more primary account numbers; a query module of the computing device configured to perform a query in the memory to identify a particular formatting template among the plurality of formatting templates, wherein the associated account length corresponds to the length of the particular primary account number; a receiving device of the computing device configured to receive at least an unpredictable number from a point-of-sale device; a generating module of the computing device configured to generate a password based on at least the unpredictable number and one or more algorithms, and to generate a data string, wherein the data string includes at least the generated password, the particular primary account number and the unpredictable number, and wherein the data string is formatted based on the identified particular formatting template; and a sending device of the computing device configured to electronically send the generated data string to the point-of-sale device. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] The scope of the present disclosure may be best understood by reading the following detailed description of exemplary embodiments in conjunction with the accompanying drawings. The drawings included are as follows:
[0012] Figure 1 is a block diagram illustrating a high-level system architecture for enhancing password verification for different account lengths according to an exemplary embodiment.
[0013] Figure 2is a diagram showing a method for generating and providing a data string according to an exemplary embodiment. Figure 1 A block diagram of a computing device, wherein the data string is used to enhance password verification for accounts of different lengths.
[0014] Figure 3 is a diagram showing the use of Figure 1 A flowchart of a system for enhancing password generation and verification for different account lengths.
[0015] Figure 4 is a diagram showing the use of Figure 1 A flowchart of a process for a computing device to generate and transmit a data string, wherein the data string is used to verify enhanced passwords for accounts of different lengths.
[0016] Figure 5 is a schematic diagram showing different formats of data strings for transmitting passwords of account numbers and other transaction data of different lengths according to an exemplary embodiment.
[0017] Figure 6 is a flow chart illustrating an exemplary method of enhancing password verification for different account lengths according to an exemplary embodiment.
[0018] Figure 7 is a flow chart illustrating payment transaction processing according to an exemplary embodiment.
[0019] Figure 8 is a block diagram illustrating a computer system architecture according to an exemplary embodiment.
[0020] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter.It should be understood that the detailed description of the exemplary embodiments is for illustrative purposes only and is not intended to limit the scope of the present disclosure. DETAILED DESCRIPTION
[0021] Professional terminology
[0022] Payment Network - A system or network used to transfer money by using cash substitutes. Payment networks may use a variety of different protocols and processes to process the transfer of money for various types of transactions. Transactions that may be performed through a payment network may include product or service purchases, credit purchases, debit transactions, funds transfers, account withdrawals, etc. A payment network may be configured to perform transactions through cash substitutes, which may include payment cards, letters of credit, checks, transaction accounts, etc. Examples of networks or systems configured to perform as payment networks include those composed of The term "payment network" as used herein may refer to a payment network as an entity and a physical payment network, for example, including the equipment, hardware and software of the payment network.
[0023] Payment Rails - Infrastructure associated with payment networks for payment transaction processing and the transmission of transaction messages and other similar data between payment networks and other entities interconnected with the payment networks. Payment rails may include hardware for establishing payment networks and interconnections between payment networks and other associated entities (e.g., financial institutions, gateway processors, etc.). In some instances, payment rails may also be affected by software, such as by special programming of the communication hardware and devices that make up the payment rails. For example, a payment rail may include a specially configured computing device that is specifically configured to route transaction messages, which may be specially formatted data messages that are electronically transmitted via the payment rails, as discussed in more detail below.
[0024] Payment Card - A card or data associated with a transaction account that can be presented to a merchant to fund a financial transaction through the associated transaction account. Payment cards can include credit cards, debit cards, charge cards, stored value cards, prepaid cards, gas cards, virtual payment numbers, virtual card numbers, controlled payment numbers, etc. A payment card can be a physical card that can be presented to a merchant or can be data representing an associated transaction account (e.g., data stored in a communication device such as a smartphone or computer). For example, in some cases, data including a payment account number can be considered a payment card for processing transactions funded by an associated transaction account. In some cases, checks can be considered payment cards when applicable.
[0025] Merchant - an entity that offers products (e.g., goods and / or services) for purchase to another entity (e.g., a consumer or other merchant). It will be apparent to those skilled in the relevant art that a merchant may be a consumer, a retailer, a wholesaler, a manufacturer, or any other type of entity that may offer products for purchase. In some cases, a merchant may have special knowledge of the goods and / or services offered for purchase. In other cases, a merchant may not have or may not require any special knowledge of the products offered. In some embodiments, an entity participating in a single transaction may be considered a merchant. In some cases, as used herein, the term "merchant" may refer to a device or equipment of a merchant entity.
[0026] Issuer - An entity that establishes (e.g., opens) a letter of credit or a line of credit in favor of a beneficiary, and a check drawn by the beneficiary in accordance with the amount specified in the letter of credit or line of credit. In many cases, an issuer may be a bank or other financial institution authorized to open a line of credit. In some cases, any entity that provides a line of credit to a beneficiary may be considered an issuer. The line of credit opened by an issuer may be represented in the form of a payment account and may be paid by the beneficiary using a payment card. It will be apparent to those skilled in the relevant art that an issuer may also provide consumers with additional types of payment accounts, such as debit accounts, prepaid accounts, electronic wallet accounts, savings accounts, checking accounts, etc., and may provide consumers with physical or non-physical means of accessing and / or using such accounts, such as debit cards, prepaid cards, ATM cards, electronic wallets, checks, etc.
[0027] Acquirer - An entity that processes payment card transactions on behalf of a merchant. An acquirer may be a bank or other financial institution authorized to process payment card transactions on behalf of a merchant. In many cases, an acquirer may open a line of credit to a merchant as a beneficiary. In the event that a consumer transacts via a payment card with a merchant represented by an acquirer, the acquirer may exchange funds with an issuer, wherein the consumer may be the beneficiary of the line of credit provided by the issuer.
[0028] A system for enhancing password authentication
[0029] Figure 1 A system 100 for enhancing password verification for transaction account numbers of varying lengths is shown.
[0030] The system 100 may include a computing device 102. The computing device 102, discussed in more detail below, may be configured to generate a cryptogram included in a data string that takes into account transaction account numbers of varying lengths included in a transaction message for processing a payment transaction. The computing device 102 may be any suitable type of computing device, which may be a computing device specifically configured to perform the methods discussed herein, such as a cellular phone, a smart phone, a laptop, a tablet computer, a desktop computer, a smart watch, a smart television, a wearable computing device, an implantable computing device, etc.
[0031] In the system 100, a consumer 104 may use a computing device 102 to transmit payment details for a payment transaction. The consumer 104 may have a transaction account established with an issuer 106, which may be a financial institution (e.g., an issuing bank) or other entity configured to own or otherwise manage a transaction account used by the consumer 104 to fund a payment transaction. The issuer 106 may issue a transaction account to the consumer 104, which may be used to fund a payment transaction. The computing device 102 may be configured to store payment details associated with the transaction account, which may include at least a transaction account number and additional data associated therewith that may be used in the payment transaction processing, such as a transaction counter, name, expiration date, security code, algorithm data, cryptographic data, etc. In some instances, the computing device 102 may be configured to store payment details for multiple transaction accounts, such as additional transaction accounts associated with the issuer 106 or one or more transaction accounts associated with one or more additional issuers 106.
[0032] Consumer 104 may use computing device 102 to participate in a payment transaction with a merchant. As part of participating in a payment transaction, consumer 104 may submit computing device 102 to a point-of-sale device 108 associated with the merchant to transmit payment details to point-of-sale device 108. As discussed in more detail below, point-of-sale device 108 and computing device 102 may establish a communication channel and may use the communication channel to exchange data used in processing the payment transaction. The communication channel may use any suitable type of communication, such as cellular communication, radio frequency communication, near field communication, Bluetooth communication, etc.
[0033] The point of sale device 108 may generate an unpredictable number using a method that is obvious to a person skilled in the relevant art (e.g., using a random or pseudo-random number generator), and may electronically transmit the generated unpredictable number to the computing device 102 using a communication channel. In some instances, the unpredictable number may have different lengths. For example, the unpredictable number may be two, three, four, or even more digits (as appropriate). In some embodiments, the length of the unpredictable number may be based on the length of the transaction account number used to fund the payment transaction. In this embodiment, the consumer 104 may first select a transaction account to be used in the payment transaction through the computing device 102. The computing device 102 may electronically transmit the length of the selected transaction account number or the length of the desired unpredictable number to the point of sale device 108 through the established communication channel. The point of sale device 108 may then generate and provide an unpredictable number of a suitable length accordingly, for example, by using a random number generator configured to generate a random, specified length of unpredictable numbers to generate and provide an unpredictable number of a suitable length. In other embodiments, point of sale device 108 may generate unpredictable numbers of a certain length based on one or more internal rules, and computing device 102 may adjust its process accordingly to account for varying unpredictable number lengths.
[0034] The computing device 102 may receive an unpredictable number and may subsequently generate one or more cryptograms for a payment transaction based on the unpredictable number. Each cryptogram may be generated using one or more related algorithms, and the algorithms may be applied to at least one unpredictable number received from the point of sale device 108. In some instances, the algorithms may also be applied to a transaction counter and an initialization vector associated with a selected transaction account. The initialization vector may be a diversified value input to a cryptogram calculation that is not dependent on transaction data. In some instances, each cryptogram may be generated using a different algorithm or set of algorithms.
[0035] The computing device 102 may be configured to generate a data string. The data string may be formatted based on a specific formatting template. The specific formatting template may be one of a plurality of different formatting templates stored therein and configured to format the data string. The plurality of formatting templates may include a formatting template associated with each account length in a transaction account number stored in the computing device 102. For example, the computing device 102 may store formatting templates for 16-digit account numbers, 17-digit account numbers, 18-digit account numbers, and the like. In some cases, the formatting template may also be based on unpredictable digit lengths. For example, the formatting template may be associated with both an account length (e.g., 16, 17, 18, 19, or 20 digits) and an unpredictable digit length (e.g., 2, 3, or 4 digits).
[0036] In some embodiments, each formatting template can represent a data string having the same total length, wherein the formatting template can specify the length and position of the data included in the data string. For example, each formatting template can be used to generate a 28-bit data string or 28-bit data located in a longer data string, and can specify the length and position of the transaction account number and the unpredictable numbers included in the data string, as well as the position of additional data to be included in the data string. The additional data that can be included in the data string can include a transaction counter associated with a transaction account for funding the payment transaction, a password generated for the transaction, and additional bits suitable for use that can depend on additional criteria. For example, the additional bits can be used by the cardholder to verify the method data, for example, the additional bits can be requested by the point of sale device 108 or specified by the computing device 102.
[0037] In some embodiments, each formatting template may be associated with one of Level 1, Level 2, or Level 3 data, as these terms are known to those skilled in the relevant art. In this case, the formatting template may specify the length and location of the transaction account number, unpredictable digits, and additional data in the Level 1, Level 2, or Level 3 data. For example, the formatting template may specify the location of the data in a longer data string that is configured to store Level 1 data as described in a standard associated with Level 1 data. In some cases, the formatting template may specify the entire data string of Level 1, Level 2, or Level 3 data, which may include the location and length of the transaction account number and unpredictable digits.
[0038] In some instances, each formatting template may also be associated with a number and / or type of passwords. For example, a formatting template may specify that one, two, or three passwords to be generated are included in a corresponding data string, and the one, two, or three passwords may indicate an algorithm used to generate them. In other cases, each formatting template may be associated with multiple passwords, such that computing device 102 may select a formatting template based on the number of passwords being generated, such as the number of passwords that may be specifically requested by point of sale device 108 or issuer 106. For example, issuer 106 may specify that a particular transaction account must generally use two passwords. Computing device 102 may then select a formatting template that accommodates the two passwords and the unpredictable number provided by point of sale device 108 accordingly.
[0039] The computing device 102 may generate a data string using an appropriate formatting template and may electronically transmit the data string to the point of sale device 108 using the established communication channel. In some embodiments, the data string may be accompanied by a bitmap. The bitmap may be configured to indicate the format of the data string. The bitmap may be generated by the computing device 102 based on the formatting template, or may be stored in the computing device 102 and identified as being accompanied by a corresponding formatting template.
[0040] The point-of-sale device 108 may receive the data string from the computing device 102 using the communication channel, and may also receive the attached bitmap if applicable. The point-of-sale device 108 may then electronically transmit the data string and additional transaction data related to the payment transaction to an acquirer 110 or other entity that processes via a payment track. The additional transaction data may include, for example, transaction amounts, product data, offer data, point-of-sale device data, reward data, loyalty data, etc. The acquirer 110 may be a financial institution or other entity that is configured to own or otherwise manage a transaction account associated with a merchant involved in the payment transaction, through which the merchant receives funds from the consumer 104. The acquirer 110 may receive the transaction data and the data string directly from the point-of-sale device 108, or may receive the transaction data and the data string via another entity (e.g., a gateway) through a payment track associated with a payment network 112.
[0041] Acquirer 110 may generate a transaction message for a payment transaction, which may be submitted to payment network 112 for processing. A transaction message may be a specially formatted data message, which may be formatted according to one or more standards governing the exchange of financial transaction messages (e.g., ISO 8583 standards of the International Organization for Standardization). A transaction message may include a plurality of data elements, which may be configured to store data as proposed in the relevant standards. For example, a transaction message may include a data element configured to store a transaction amount, a data element configured to store a transaction time, a data element configured to store a transaction date, and the like. One or more data elements may also be configured to store a data string received from computing device 102. In some instances, a data string may be stored in a data element configured to store level 1, level 2, or level 3 data. In some instances, a data string may be included in a larger data string, which is stored in a data element configured to store level 1, level 2, or level 3 data.
[0042] The transaction message may also be configured to store a message type indicator that may indicate the type of the transaction message. For example, the message type indicator may indicate that the transaction message is an authorization request, an authorization response, etc. The acquirer 110 may electronically transmit the transaction message to the payment network 112 via the payment track for processing. The payment network 112 may then process the payment transaction based on the data included in the received transaction message using conventional methods and systems, including exchanging transaction information with the issuer 106. Additional data regarding the transaction message, the processing of the payment transaction, and the exchange of transaction messages and transaction data via the payment track are described below in accordance with Figure 7 Process 700 is shown for discussion.
[0043] The methods and systems discussed herein are capable of processing payment transactions through enhanced cryptogram generation and verification that can accommodate transaction account numbers of varying lengths and unpredictable numbers. Using a specialized formatting template with a specially configured computing device, a data string including a cryptogram can be generated, wherein the cryptogram is generated based on the length of the account number of a transaction account used to fund the payment transaction and the length of the unpredictable numbers used in the transaction.
[0044] Computing equipment
[0045] Figure 2 An embodiment of a computing device 102 of the system 100 is shown. It will be apparent to those skilled in the relevant art that Figure 2 The illustrated embodiments of computing device 102 are illustrative only and may not be exhaustive of all possible configurations of computing device 102 suitable for performing the functions discussed herein. Figure 8 Computer system 800 , shown in FIG. 8 and discussed in greater detail below, may be a suitable configuration for computing device 102 .
[0046] The computing device 102 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some embodiments, the receiving device 202 may be configured to receive data over a payment track, for example, using a specially configured infrastructure associated with the payment network 112 to transmit transaction messages including sensitive financial data and information. In some instances, the receiving device 202 may also be configured to receive data from the issuer 106, the point of sale device 108, the payment network 112, and other entities via an alternative network (e.g., the Internet). In some embodiments, the receiving device 202 may be composed of multiple devices, for example, different receiving devices that receive data over different networks, for example, a first receiving device that receives data over a payment track and a second receiving device that receives data over the Internet. The receiving device 202 may electronically receive a transmitted data signal, wherein the data may be superimposed on the data signal, and the receiving device 202 decodes, parses, reads, or otherwise obtains the data by receiving the data signal. In some instances, the receiving device 202 may include a parsing module for parsing the received data signal to obtain the data superimposed on the data signal. For example, receiving device 202 may include a parser program configured to receive data signals and transform the received data signals into usable inputs for functions executed by a processing device to perform the methods and systems described herein.
[0047] The receiving device 202 may be configured to receive a data signal electronically transmitted by the issuer 106, on which the payment account details may be superimposed. For example, the issuer 106 may provide payment credentials for a transaction account to the computing device 102, which may be received by the receiving device 202, and the payment credentials for the transaction account may include a corresponding transaction account number, a transaction counter, and other data suitable for use in performing the functions discussed herein. The receiving device 202 may also be configured to receive a data signal electronically transmitted by the point of sale device 108 during the performance of a payment transaction. Unpredictable numbers, other transaction data, transaction confirmation information, data request information, data instructions, etc. may be superimposed on the data signal. For example, the point of sale device 108 may specify the level of data requested by the computing device 102, and may also request the length of the unpredictable number.
[0048] The computing device 102 may also include a communication module 204. The communication module 204 may be configured to transmit data between modules, engines, databases, memories, and other components of the computing device 102 for performing the functions discussed herein. The communication module 204 may be composed of one or more types of communication devices and may utilize various communication methods for communication within the computing device. For example, the communication module 204 may include a bus, a contact pin connector, a wire, etc. In some embodiments, the communication module 204 may also be configured to communicate between internal components of the computing device 102 and external components of the computing device 102 (e.g., externally connected databases, display devices, input devices, etc.). The computing device 102 may also include a processing device. It is obvious to those skilled in the relevant art that the processing device may be configured to perform the functions of the computing device 102 discussed herein. In some embodiments, the processing device may include multiple engines and / or modules (e.g., query module 206, generation module 208, input module 210, transaction processing module 212, etc.) that are specifically configured to perform one or more functions of the processing device, and / or the processing device may be composed of the above multiple engines and / or modules. As used herein, the term "module" may be software executed on hardware that enables a specifically programmed computer to receive input signals, perform one or more processes using the input signals, and provide output signals in a manner that a general-purpose computer cannot perform. Based on the content of this disclosure, the inputs, outputs, and processes performed by the various modules will be apparent to those skilled in the art.
[0049] The computing device 102 may also include a memory 216. The memory 216 may be configured to store data for use by the computing device 102 in performing the functions discussed herein. The memory 216 may be configured to store data using suitable data formatting methods and schemes, and may be any suitable type of memory, such as read-only memory, random access memory, etc. The memory 216 may include, for example, encryption keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and applications of processing devices, and other data that may be suitable for use by the computing device 102 in performing the functions disclosed herein, which will be apparent to those skilled in the relevant art after reading this disclosure.
[0050] The memory 216 may also be configured to store a plurality of formatting templates. Each formatting template may be associated with the length of the transaction account number. In some instances, each formatting template may also be associated with an unpredictable length of numbers. The formatting template may also be associated with additional criteria, such as data levels (e.g., level 1, level 2, or level 3), multiple passwords, additional numeric specifications, etc. In some instances, the formatting template may also be associated with a corresponding bitmap stored in the memory 216. The memory 216 may also be configured to store payment transaction numbers and additional transaction account data suitable for use in payment transaction processing, such as transaction counters, account names, zip codes or postal codes, expiration dates, security numbers, etc. In some instances, the data stored in the memory 216 may be stored in one or more relational databases, which may utilize structured query languages to store, identify, modify, update, access, etc., structured data sets stored therein.
[0051] The computing device 102 may include a query module 206. The query module 206 may be configured to perform a query on a database to identify information. The query module 206 may receive one or more data values or query strings, and may perform a query of the string on an indicated database (e.g., memory 216) based on the received one or more data values or query strings to identify information stored in the database. The query module 206 may then output the identified information to an appropriate engine or module of the computing device 102 as needed. For example, the query module 206 may perform a query on the memory 216 to identify account data associated with a transaction account and a specific formatting template for generating a data string used in processing a payment transaction. The identified account data (which may include at least a transaction account number and a transaction counter) and the specific formatting template may be passed to the generation module 208.
[0052] The generation module 208 may be configured to generate passwords and data strings. The generation module 208 may receive instructions and corresponding data, may generate data based on the received instructions and corresponding data, and may output the generated data to one or more other modules or engines of the computing device 102 to perform the functions discussed herein. For example, the generation module 208 may receive account and / or transaction data and one or more algorithms (e.g., identified by the query module 206 in the memory 216) and generate one or more passwords accordingly. In some instances, each password may be generated using a separate algorithm but the same data. The generation module 208 may also use the account and transaction data and a specific formatting template and generate a formatted data string according to the specific formatting template, and the generated data string may include a transaction account number, an unpredictable number, a password, and other data having a corresponding length and being in a corresponding position. The generated data string may be output to the transaction processing module 212 and / or the sending device 214. In some embodiments, the generation module 208 may also be configured to generate a bitmap corresponding to a specific formatting template, which may be included in the corresponding generated data string.
[0053] In some embodiments, the computing device 102 may include an input module 210. The input module 210 may be configured to receive input from a user of the computing device 102 (e.g., the consumer 104). The input module 210 may be connected to one or more input devices (e.g., a keyboard, a mouse, a touch screen, a scroll wheel, a click wheel, a microphone, a camera, etc.) to receive data signals from the one or more input devices. The input module 210 may receive input from the consumer 104 and may transmit the data to a corresponding module or engine of the computing device 102. For example, the input module 210 may receive an instruction from the consumer 104 to conduct a payment transaction, which may instruct the receiving device 202 to establish a communication channel with the point of sale device 108 to receive transaction data and indicate a selection of a transaction account for funding the payment transaction.
[0054] In some examples, the computing device 102 may include a transaction processing module 212. The transaction processing module 212 may be configured to perform additional functions of the computing device 102 suitable for processing payment transactions. For example, the transaction processing module 212 may be configured to increase a transaction counter of a transaction account each time a data signal is transmitted for a payment transaction, for example, by submitting a query to the query module 206 to update the transaction counter in the memory 216. In another example, the transaction processing module 212 may be configured to verify the transaction data received by the receiving device 202 from the point of sale device 108 to ensure that the point of sale device 108 is authentic, using methods that are apparent to those skilled in the relevant art.
[0055] The sending device 214 may be configured to send data over one or more networks via one or more network protocols. In some embodiments, the sending device 214 may be configured to send data over a payment track, for example, using a specially configured infrastructure associated with the payment network 112 to send a transaction message including sensitive financial data and information (e.g., an identified payment credential). In some instances, the sending device 214 may be configured to send data to the issuer 106, the point of sale device 108, the acquirer 110, the payment network 112, and other entities via an alternative network (e.g., the Internet). In some embodiments, the sending device 214 may be composed of multiple devices, for example, different sending devices for sending data over different networks, for example, a first sending device for sending data over a payment track and a second sending device for sending data over the Internet. The sending device 214 may electronically send a data signal that has been superimposed with data that can be parsed by a receiving computing device. In some instances, the sending device 214 may include one or more modules for superimposing, encoding, or otherwise formatting data into a data signal suitable for transmission.
[0056] Transmitting device 214 may be configured to electronically transmit the data signal with the generated data string superimposed thereon to point of sale device 108 using a communication channel established with point of sale device 108. In some examples, transmitting device 214 may also electronically transmit a bitmap to point of sale device 108, which may correspond to the format of the data string transmitted to point of sale device 108. Transmitting device 214 may also be configured to electronically transmit the data message to an additional entity, such as, for example, to issuer 106 requesting payment credentials.
[0057] Enhanced password verification process for different account lengths
[0058] Figure 3 A process for enhancing password verification using system 100 for transaction account numbers of varying lengths and unpredictable numbers is shown.
[0059] At step 302, computing device 102 and point of sale device 108 may establish a communication channel. In some instances, the communication channel may be a secure connection such that other devices and / or entities may not be able to access data electronically transmitted between the devices using the connection. The communication channel may utilize any type of communication method and / or protocol suitable for performing the functions discussed herein, such as near field communication, radio frequency communication, cellular network communication, etc.
[0060] At step 304, point of sale device 108 may generate an unpredictable number. In some embodiments, the length of the unpredictable number may be set by point of sale device 108, but may also be inconsistent with all other point of sale devices. The length may be fixed (e.g., the same in every transaction) or may vary. The variation in length may be random, may be based on internal standards of point of sale device 108, or may be based on a requested unpredictable number length, such as requested by computing device 102 to point of sale device 108 via electronic transmission using a communication channel.
[0061] At step 306, the point of sale device 108 may electronically send the unpredictable number to the computing device 102 using the communication channel. At step 308, the receiving device 202 of the computing device 102 may receive the unpredictable number. At step 310, one or more payment cryptograms may be generated by the generation module 208 of the computing device 102. Each cryptogram may be generated by applying one or more algorithms (e.g., as queried from the memory 216 by the query module 206) to the unpredictable number. Each algorithm may also be applied to a transaction counter and an initialization vector associated with a transaction account used to fund the payment transaction.
[0062] In some instances, the number and / or type of passwords may be based on a specific formatting template identified for the transaction. The specific formatting template may be based on at least the length of the transaction account number used to fund the payment transaction. The transaction account number may be identified as a default number to be used in the transaction, or the transaction account number may be specified in a selection made by the consumer 104 through the input module 210 of the computing device 102. In some instances, the number and / or type of passwords may be specified by the point of sale device 108, and the number and / or type of passwords may be specified when the attached unpredictable number is submitted (e.g., when sent to the computing device 102 at step 306 and received at step 308).
[0063] Once the one or more passwords have been generated, the generation module 208 may generate a data string at step 312. The data string may be formatted based on a particular formatting template, and the data string may include data indicated in a length and position specified in the formatting template. For example, the formatting template may specify the length of the transaction account number and the unpredictable number and the position of each of the transaction account number and the unpredictable number in the data string, as well as the position of additional data (e.g., a transaction counter and one or more additional bits) that may be included in the data string.
[0064] At step 314, sending device 214 of computing device 102 may electronically send the generated data string to point of sale device 108 using the established communication channel. In some examples, sending device 214 may also send a bitmap corresponding to a particular formatting template to point of sale device 108. At step 316, point of sale device 108 may receive the data string, and at step 318, may electronically send transaction data and payment data (including the received data string) to acquirer 110 or other entity for use in processing the payment transaction.
[0065] The process of generating data strings formatted based on different account lengths
[0066] Figure 4 A process 400 is shown for generating and transmitting a data string that includes a transaction account number and one or more passwords for enhanced authentication, wherein the passwords are formatted based on the length of the transaction account number and the unpredictable number, which may vary from transaction to transaction.
[0067] At step 402, computing device 102 may receive an instruction to initiate a payment process to conduct a payment transaction, which may be received via input module 210. Receiving the instruction may include consumer 104 making one or more selections via input module 210. At step 404, computing device 102 may determine whether a default payment account is established in computing device 102, for example, based on data stored in memory 216 with account details of a stored transaction account. In some examples, if memory 216 stores account details for a single transaction account, it may be designated as the default transaction account. In some examples, the determination may be based on the received instruction, for example, based on whether consumer 104 indicates not to use a default transaction account.
[0068] If no default transaction account is selected or not used, then at step 406, computing device 102 may prompt consumer 104 to select one of the transaction accounts for which account data is stored in memory 216 of the computing device. The prompting may be performed using one or more audio or video display devices (e.g., a display screen or speakers). At step 408, input module 210 may receive the consumer's selection of a transaction account to be used in funding the payment transaction. In the event that the instruction received at step 402 may include a specified transaction account (e.g., as determined at step 404), steps 406 and 408 may be skipped.
[0069] Once the transaction account has been determined, at step 410, the computing device 102 may determine whether a number of digits of the unpredictable digit (UN) is specified. The length of the unpredictable digit may be specified by a specific formatting template determined by the computing device 102 based on the length of the selected transaction account number. For example, the memory 216 may include a single formatting template for the length of the transaction account number, which may require a specific length of the unpredictable digit, which may specify the number of digits of the unpredictable digit. In another example, the memory 216 may include multiple formatting templates for specific transaction account lengths to accommodate any unpredictable digit lengths that may be provided by the point of sale device 108.
[0070] If the length of the unpredictable number is specified, then at step 412, the generation module 208 may generate a data request including the specified number of digits of the unpredictable number. At step 414, the sending device 214 may electronically send the request for the unpredictable number to the point of sale device 108. In the event that a specific length is specified, the sent request may include the specified number of digits. If the length of the unpredictable number is not specified in step 410, then step 412 may be skipped and the process 400 proceeds to step 414 as described above. At step 416, the receiving device 202 may receive the unpredictable number and any additional transaction data from the point of sale device 108. The additional transaction data may include, for example, a transaction amount, a password request, point of sale data, merchant data, etc.
[0071] At step 418, the generation module 208 may generate one or more passwords based at least on the unpredictable number. Each password may also be based at least on a transaction counter and an initialization vector associated with the selected transaction account. In some instances, the same data may be used to generate each password, but each password may be generated by applying a different one or more algorithms to the data. In some embodiments, the password and / or the number of algorithms used in generating the password may be based on the transaction details received from the point of sale device 108 or a specific formatting template. In the event that the length of the unpredictable number is not specified, the specific formatting template may be one associated with the transaction account number length and the length of the unpredictable number received from the point of sale device 108.
[0072] At step 420, the generation module 208 may generate and format the data string. The data string may be formatted based on a specific formatting template, and the data string may include data in locations specified by the specific formatting template. For example, the data string may include a transaction account number, an unpredictable number, a transaction counter, additional data specified in the formatting template (e.g., additional Level 1, Level 2, or Level 3 data), cardholder verification method data, etc. At step 422, the sending device 214 may electronically send the data string to the point of sale device 108 using the established communication channel. At step 424, a transaction counter associated with the selected transaction account may be incremented to account for the transaction so that it may be accurately used to generate a cryptogram in future transactions.
[0073] Formatting data strings for different accounts and unpredictable number lengths
[0074] Figure 5 A plurality of different data strings 500 are shown, wherein each data string 500 may be formatted based on a specific formatting template according to different transaction account numbers and unpredictable number lengths and the number of passwords included.
[0075] like Figure 5 As shown, each data string 500 may include a primary account number (PAN) 502, which may be a transaction account number corresponding to a transaction account that has been selected for payment of a payment transaction. PAN 502 may include at least 16 digits, and in some instances, may include more than 16 digits, for example, Figure 5 The PAN 502 of four of the six data strings 500 shown is greater than 16 bits. Each data string 500 may also include an unpredictable number (UN) 504. The length of the unpredictable number may vary, for example, Figure 5 As shown, its length is 2 or 3 bits.
[0076] Each data string 500 may also include a transaction counter (ATC) 506, which may be a number associated with a transaction account used to fund a payment transaction, indicating the number of transactions that have been initiated using the associated transaction account. Computing device 102 may update ATC 506 to match an ATC stored by payment network 112 or issuer 106 for use in generating a corresponding cryptogram, which is used for authentication and authorization of payment transactions. Figure 5 Each ATC 506 is shown as 2 bits, but it will be apparent to one skilled in the relevant art that the ATC 506 may include additional bits.
[0077] Each data string 500 may also include a first cryptogram (CG1) 508. The first cryptogram 508 may be a cryptogram generated by applying one or more algorithms to at least the UN 504 and ATC 506 included in the corresponding data string 500. In some examples, the data string 500 may also include a second cryptogram (CG2) 510. The second cryptogram 510 may be generated using the same data but by applying one or more different algorithms to the data. Figure 5 Each of the passwords 508 and 510 shown in the figure includes 3 digits, but it is obvious to those skilled in the relevant art that the length of each password may be different from each other and may be different from Figure 5 The lengths shown and discussed herein.
[0078] In some examples, the data string 500 may also include one or more additional bits (E) 512. Each additional bit may be configured to store additional data suitable for use in payment transaction processing, such as cardholder verification method data. In some examples, based on other data included in the data string 500 and its length, the data string 500 may not include any additional bits.
[0079] It is obvious to those skilled in the relevant art that the data included in each data string 500 may be included in Figure 5 , and each data string 500 may include additional data. For example, a data string configured to store level 1 data may include additional data and may be formatted differently than a data string configured to store level 2 data for a transaction. In this example, Figure 5 The data shown may be included in each data string in a different order and may be combined with additional data as appropriate for conventional transaction processing. Figure 5 Other data elements shown are spaced apart.
[0080] Exemplary method for enhancing password verification for different account lengths
[0081] Figure 6 A method 600 of enhancing verification of a cryptogram for a payment transaction is shown that accounts for variations in the length of transaction account numbers and unpredictable numbers.
[0082] At step 602, one or more primary accounts and a plurality of formatting templates may be stored in a memory (e.g., memory 216) of a computing device (e.g., computing device 102), wherein each template is associated with at least an account length. At step 604, a selection indicating a particular primary account of the one or more primary accounts may be received by an input device (e.g., input module 210) of the computing device.
[0083] At step 606, a query can be performed in memory by a query module of the computing device (e.g., query module 206) to identify a specific formatting template from a plurality of formatting templates, wherein the length of the associated account number corresponds to the length of the specific primary account number. At step 608, at least an unpredictable number can be received by a receiving device of the computing device (e.g., receiving device 202) from a point of sale device (e.g., point of sale device 108).
[0084] At step 610, a passcode may be generated by a generation module of the computing device (e.g., generation module 208) based at least on the unpredictable number and one or more algorithms. At step 612, a data string may be generated by the generation module of the computing device, wherein the data string includes at least the generated passcode, the specific primary account number, and the unpredictable number, and wherein the data string is formatted based on the identified specific formatting template. At step 614, the generated data string may be electronically transmitted to a point-of-sale device by a transmission device of the computing device (e.g., transmission device 214).
[0085] In one embodiment, each of the plurality of formatting templates may be further associated with a plurality of digits, and a particular formatting template may be identified based on a correspondence between the associated number of digits and the number of digits of the received unpredictable number. In some embodiments, method 600 may further include generating, by a generation module of the computing device, a second password based at least on the unpredictable number and at least one additional algorithm, wherein the data string further includes the second password.
[0086] In one embodiment, the generated data string may be transmitted electronically in a data message that also includes a bitmap indicating the format of the generated data message. In a further embodiment, method 600 may also include generating, by a generation module of the computing device, a bitmap based at least on the identified specific formatting template. In yet another embodiment, each of the plurality of formatting templates may also include a bitmap, and the bitmap included in the data message may correspond to the bitmap included in the identified specific formatting template.
[0087] In some embodiments, the memory may further include a transaction counter for each of the one or more primary accounts, and the generated data string may further include a transaction counter associated with the particular primary account. In another embodiment, the password may be further based on the transaction counter associated with the particular primary account. In one embodiment, the data string may further include at least one additional digit, and wherein the number of additional digits is based on the length of the particular primary account and the number of digits of the received unpredictable number. In another embodiment, the at least one additional digit may store cardholder verification method data.
[0088] Payment transaction processing systems and processes
[0089] Figure 7 A transaction processing system and process 700 for processing payment transactions in the system are shown. Process 700 and the steps included in process 700 may be performed by one or more components of system 100 discussed above (e.g., computing device 102, consumer 104, issuer 106, point of sale device 108, acquirer 110, payment network 112, etc.). Figure 7 The system and process 700 shown and discussed below may use a payment rail for processing payment transactions, which may include computing devices and infrastructure for performing the steps of process 700 as specifically configured and programmed by entities discussed below, including a transaction processing server 712 that may be associated with one or more payment networks configured to process payment transactions. It will be apparent to those skilled in the relevant art that process 700 may be incorporated into one or more of the steps involved in processing payment transactions discussed above. Figure 3 , 4 In the process shown in Figure 6. In addition, the entities discussed herein for performing process 700 may include one or more computing devices or systems configured to perform the functions discussed below. For example, merchant 706 may include one or more point of sale devices, local communication networks, computing servers, and other devices configured to perform the functions discussed below.
[0090] At step 720, the issuing financial institution 702 may issue a payment card or other suitable payment instrument to the consumer 704. The issuing financial institution may be a financial institution such as a bank, or other suitable type of entity that manages and controls payment accounts and / or payment instruments that may be used with payment accounts that provide funding for payment transactions. The consumer 704 may have a transaction account of the issuing financial institution 702 associated with the issued payment card, so that when used for a payment transaction, the payment transaction may be funded by the associated transaction account. In some embodiments, the payment card may be physically issued to the consumer 704. In other embodiments, the payment card may be a virtual payment card or other means provided to the consumer 704 in an electronic format.
[0091] At step 722, consumer 704 may submit the issued payment card to merchant 706 for funding the payment transaction. Merchant 706 may be a business, another consumer, or any entity that may participate in a payment transaction with consumer 704. Consumer 704 may submit the payment card by presenting the physical card to merchant 706, electronically sending (e.g., via near field communication, wireless transmission, or other suitable electronic transmission types and protocols) payment details of the payment card, or by initiating the sending of payment details to merchant 706 via a third party. Merchant 706 may receive payment details (e.g., via electronic transmission, by reading payment details from a physical payment card, etc.), which may include at least a transaction account number associated with the payment card and / or an associated transaction account. In some instances, the payment details may include one or more application passwords that may be used in the processing of the payment transaction.
[0092] At step 724, the merchant 706 may enter the transaction details into a point-of-sale computing system. The transaction details may include payment details provided by the consumer 704 associated with the payment card and additional details associated with the transaction, such as transaction amount, time and / or date, product data, selling price, loyalty data, reward data, merchant data, consumer data, point-of-sale data, etc. The transaction details may be entered into the merchant 706 point-of-sale system through one or more input devices (e.g., an optical barcode scanner configured to scan a product barcode, a keyboard configured to receive a product code entered by a user, etc.). The merchant point-of-sale system may be a specially configured computing device and / or a dedicated computing device specifically for the purpose of processing electronic financial transactions and communicating with a payment network (e.g., via a payment track). The merchant point-of-sale system may be an electronic device running a point-of-sale system application, wherein the application causes the electronic device to receive electronic financial transaction information and transmit it to a payment network. In some embodiments, the merchant 706 may be an online retailer in an e-commerce transaction. In such an embodiment, the transaction details may be entered into a shopping cart or other repository for storing transaction data in an electronic transaction, which will be apparent to those skilled in the relevant art.
[0093] At step 726, the merchant 706 may electronically send a data signal with the transaction data superimposed thereon to the gateway processor 708. The gateway processor 708 may be configured to receive transaction details from the merchant 706 to format and send them to the acquiring financial institution 710. In some instances, the gateway processor 708 may be associated with multiple merchants 706 and multiple acquiring financial institutions 710. In this instance, the gateway processor 708 may receive transaction details for multiple different transactions involving various merchants, which may be forwarded to the appropriate acquiring financial institution 710. By establishing relationships with multiple acquiring financial institutions 710 and having the necessary infrastructure to communicate with the financial institutions using payment rails (e.g., using an application programming interface associated with the gateway processor 708 or financial institution for submitting, receiving, retrieving data), the gateway processor 708 may act as an intermediary for the merchant 706 to enable payment transactions to be conducted through a single communication channel and in the format of the gateway processor 708 without having to maintain relationships with multiple acquiring financial institutions 710 and payment processors and the hardware associated therewith. Acquiring financial institution 710 may be a financial institution such as a bank or other entity that manages and controls payment accounts and / or payment instruments used with payment accounts. In some instances, acquiring financial institution 710 may manage transaction accounts for merchant 706. In some instances, a single financial institution may operate as both issuing financial institution 702 and acquiring financial institution 710.
[0094] The data signal sent from the merchant 706 to the gateway processor 708 may be superimposed with the transaction details of the payment transaction, which may be formatted based on one or more standards. In some embodiments, the standard may be proposed by the gateway processor 708, which may use a unique proprietary format to transmit transaction data to / from the gateway processor 708. In other embodiments, a public standard may be used, such as the ISO 8783 standard of the International Organization for Standardization. The standard may indicate the type of data that may be included, the format of the data, how the data is stored and transmitted, and other standards for transmitting transaction data to the gateway processor 708.
[0095] In step 728, the gateway processor 708 may parse the transaction data signal to obtain the transaction data superimposed thereon, and may format the transaction data as needed. The formatting of the transaction data may be performed by the gateway processor 708 based on a proprietary standard of the gateway processor 708 or the acquiring financial institution 710 associated with the payment transaction. The proprietary standard may specify the type of data contained in the transaction data and the format of data storage and transmission. The gateway processor 708 may use the transaction data to identify the acquiring financial institution 710, for example, by parsing the transaction data (e.g., deconstructing it into data elements) to obtain an account identifier associated with the acquiring financial institution 710 included in the transaction data, thereby identifying the acquiring financial institution 710. In some instances, the gateway processor 708 may then format the transaction data based on the identified acquiring financial institution 710, for example, formatting the transaction data according to the formatting standard specified by the acquiring financial institution 710. In some embodiments, the identified acquiring financial institution 710 may be associated with the merchant 706 participating in the payment transaction, and in some cases, the acquiring financial institution 710 may manage a transaction account associated with the merchant 706.
[0096] At step 730, the gateway processor 708 may electronically send a data signal superimposed with formatted transaction data to the identified acquiring financial institution 710. The acquiring financial institution 710 may receive the data signal and parse the signal to obtain the formatted transaction data superimposed thereon. At step 732, the acquiring financial institution may generate an authorization request for the payment transaction based on the formatted transaction data. The authorization request may be a transaction message specifically formatted according to one or more standards (e.g., the ISO 8783 standard and standards set by payment processors for processing payment transactions, such as payment networks). The authorization request may be a transaction message including a message type indicator indicating an authorization request, which may indicate that the merchant 706 participating in the payment transaction is requesting payment or a payment commitment of the issuing financial institution 702 for the transaction. The authorization request may include a plurality of data elements, each of which is configured to store data as set forth in the relevant standard, for example, for storing an account number, an application password, a transaction amount, information of the issuing financial institution 702, and the like.
[0097] At step 734, the acquiring financial institution 710 may electronically send the authorization request to the transaction processing server 712 for processing. The transaction processing server 712 may be composed of one or more computing devices that are part of a payment network configured to process payment transactions. In some embodiments, the authorization request may be transmitted by a transaction processor at the acquiring financial institution 710 or other entity associated with the acquiring financial institution. The transaction processor may be one or more computing devices that include multiple communication channels for communicating with the transaction processing server 712 to transmit transaction messages and other data to and from the transaction processing server 712. In some embodiments, the payment network associated with the transaction processing server 712 may own or operate each transaction processor so that the payment network may maintain control of transmitting transaction messages to and from the transaction processing server 712 to ensure network and information security.
[0098] At step 736, the transaction processing server 712 may perform a value-added service for the payment transaction. A value-added service may be a service specified by the issuing financial institution 702 that may provide value-added to the issuing financial institution 702 or the consumer 704 when processing the payment transaction. The value-added service may include, for example, fraud scoring, transaction or account control, account mapping, offer redemption, loyalty processing, and the like. For example, when the transaction processing server 712 receives the transaction, a fraud score for the transaction may be calculated based on data included in the transaction message and one or more fraud scoring algorithms and / or engines. In some instances, the transaction processing server 712 may first identify the issuing financial institution 702 associated with the transaction, and then identify any services that the issuing financial institution 702 indicates are to be performed. For example, the issuing financial institution 702 may be identified by data included in a particular data element included in the authorization request (e.g., an issuer identification code). In another example, the issuing financial institution 702 may be identified by a primary account number stored in the authorization request, for example, by using a portion of the primary account number (e.g., a bank identification number) to identify the issuing financial institution 702.
[0099] At step 738, the transaction processing server 712 may electronically transmit the authorization request to the issuing financial institution 702. In some instances, the authorization request may be modified, or additional data may be included in or transmitted with the authorization request as a result of the value-added service performed by the transaction processing server 712. In some embodiments, the authorization request may be transmitted to a transaction processor located at the issuing financial institution 702 (e.g., a transaction processor owned or operated by the transaction processing server 712), or to a transaction processor located at an entity associated with the issuing financial institution 702, which forwards the authorization request to the issuing financial institution 702.
[0100] At step 740, the issuing financial institution 702 may authorize the transaction account to pay the payment transaction. The authorization may be based on the available credit of the transaction account and the transaction amount of the payment transaction, the fraud score provided by the transaction processing server 712, and other considerations that are apparent to those skilled in the relevant art. The issuing financial institution 702 may modify the authorization request to include a response code indicating approval of the payment transaction (e.g., if the transaction is declined, an indication of a decline in the payment transaction). The issuing financial institution 702 may also modify the message type indicator of the transaction message to indicate that the transaction message is changed to an authorization response. At step 742, the issuing financial institution 702 may send the authorization response to (e.g., via a transaction processor) the transaction processing server 712.
[0101] At step 744, the transaction processing server 712 may forward the authorization response to the acquiring financial institution 710 (e.g., via a transaction processor). At step 746, the acquiring financial institution may generate a response message indicating approval or denial of the payment transaction as indicated in the response code of the authorization response, and may transmit the response message to the gateway processor 708 using the standards and protocols set by the gateway processor 708. At step 748, the gateway processor 708 may forward the response message to the merchant 706 using appropriate standards and protocols. At step 750, assuming the transaction is approved, the merchant 706 may then provide the merchandise purchased by the consumer 704 to the consumer 704 as part of the payment transaction.
[0102] In some embodiments, once process 700 has been completed, payment can be made from issuing financial institution 702 to acquiring financial institution 710. In some instances, payment can be made immediately or within one business day. In other instances, payment can be made after a period of time and in response to a clearing request submitted from acquiring financial institution 710 to issuing financial institution 702 via transaction processing server 702. In this instance, clearing requests for multiple payment transactions can be aggregated into a single clearing request, which transaction processing server 712 can use to identify all payments by and to whom in the payment transaction settlement.
[0103] In some instances, the system may also be configured to perform processing of payment transactions in situations where the communication path may be unavailable. For example, if the issuing financial institution is unable to perform authorization on the transaction account (e.g., in step 740), the transaction processing server 712 may be configured to perform authorization on the transaction on behalf of the issuing financial institution 702. This action may be referred to as "backup processing," wherein the transaction processing server is used as a "backup" for the issuing financial institution 702. In this instance, the transaction processing server 712 may utilize rules set by the issuing financial institution 702 to determine whether to approve or deny the payment transaction, and may modify the transaction message accordingly before forwarding the transaction message to the acquiring financial institution 710 in step 744. The transaction processing server 712 may retain transaction-related data that is backed up by the transaction processing server 712, and send the retained data to the issuing financial institution 702 once communication is reestablished. The issuing financial institution 702 may then process the transaction account accordingly to make up for the time that communication was disconnected.
[0104] In another example, if the transaction processing server 712 is not available to submit the authorization request of the acquiring financial institution 710, the transaction processor of the acquiring financial institution 710 can be configured to perform the processing of the transaction processing server 712 and the issuing financial institution 702. The transaction processor may include rules and data suitable for making a decision to approve or reject the payment transaction based on the data included in the payment transaction. For example, the issuing financial institution 702 and / or the transaction processing server 712 may set restrictions on transaction types, transaction amounts, etc., which may be stored in the transaction processor and used to determine whether to approve or reject the payment transaction based on this. In this example, even if the transaction processing server 712 is unavailable, the acquiring financial institution 710 can receive an authorization response to the payment transaction, thereby ensuring that the transaction can be processed even when communication is unavailable, and there will be no stoppage. In this example, the transaction processor can store the transaction details of the payment transaction, and once communication is reestablished, the transaction details can be sent to the transaction processing server 712 (for example, and the transaction details are sent from the transaction processing server 712 to the associated issuing financial institution 702).
[0105] In some embodiments, the transaction processor may be configured to include multiple different communication channels that may use multiple communication cards and / or devices to communicate with the transaction processing server 712 to send and receive transaction messages. For example, the transaction processor may be composed of multiple computing devices, each of which has multiple communication ports connected to the transaction processing server 712. In this embodiment, the transaction processor may cycle through the communication channels when sending transaction messages to the transaction processing server 712 to alleviate network congestion and ensure faster and smoother communication. In addition, in the event that a communication channel may be interrupted or unavailable, an alternative communication channel may be used to further increase the uptime of the network.
[0106] In some embodiments, the transaction processor can be configured to communicate directly with other transaction processors. For example, the transaction processor at the acquiring financial institution 710 can identify that the authorization request involves the issuing financial institution 702 that does not require the value-added service (e.g., by identifying the bank identification code included in the transaction message). The transaction processor at the acquiring financial institution 710 can then send the authorization request directly to the transaction processor at the issuing financial institution 702 (e.g., the authorization request does not need to pass through the transaction processing server 712), where the issuing financial institution 702 can process the corresponding transaction.
[0107] The method for processing payment transactions discussed above uses a communication method that utilizes multiple communication channels, and includes a fail-safe mechanism that can process payment transactions at multiple nodes of the processing process and multiple locations of the system, and also includes a redundant mechanism that ensures that the message is successfully transmitted to the destination even in the event of a communication interruption, so that the method discussed above can provide a stable system that can always successfully process payment transactions with minimal errors and interruptions. Such advanced networks and their infrastructure and topology can generally be referred to as "payment rails", where transaction data can be submitted from merchants to payment rails at millions of different sales points, and the transaction data is routed to the appropriate transaction processing server 712 through the infrastructure for processing. The payment rail can be a general-purpose computing device that may not be properly formatted or unable to submit messages to the rail, without the need for special programming and / or configuration of the general-purpose computing device. Through the special use of the computing device, the computing device can be configured to submit transaction data to the appropriate entity (e.g., gateway processor 708, acquiring financial institution 710, etc.) for processing using the advanced network, and can quickly and efficiently receive a response about the consumer 704 being able to provide funds for the payment transaction.
[0108] Computer system architecture
[0109] Figure 8 The computer system 800 is shown, in which the embodiments of the present disclosure or parts thereof may be implemented as computer readable code. For example, hardware, software, firmware, a non-transitory computer readable medium having instructions stored thereon, or a combination thereof may be used to implement the embodiments of the present disclosure in the computer system 800. Figure 1 The computing device 102 may be implemented in one or more computer systems or other processing systems. Figure 1 The computing device 102 of FIG. Hardware, software, or any combination thereof may be embodied to implement Figure 3 , 4 , 6 and 7 methods.
[0110] If programmable logic is used, the logic can be executed on a commercially available processing platform or dedicated device. It will be appreciated by those skilled in the art that various computer system configurations (including multi-core multi-processor systems, minicomputers, mainframe computers, computers linked or aggregated by distributed functions, and ordinary or microcomputers that can be virtually embedded in any device) can be used to practice the embodiments of the disclosed subject matter. For example, at least one processor device and memory can be used to implement the above embodiments.
[0111] The processor unit or processor device discussed herein may be a single processor, multiple processors, or a combination thereof. A processor device may have one or more processor "cores". As discussed herein, the terms "computer program medium", "non-transitory computer readable medium", and "computer usable medium" are generally used to refer to tangible media, such as removable storage unit 818, removable storage unit 822, and a hard disk installed in hard disk drive 812.
[0112] Various embodiments of the present disclosure are described based on this exemplary computer system 800. After reading this specification, those skilled in the relevant art will understand how to use other computer systems and / or computer architectures to implement the present disclosure. Although operations can be described as sequential processes, some operations can actually be performed in parallel, concurrently, and / or in a distributed environment, and program code can be stored locally or remotely for access by single or multiple processor machines. In addition, in some embodiments, the order of operations can be rearranged without departing from the spirit of the disclosed subject matter.
[0113] Processor device 804 can be a dedicated or general processor device specially configured to perform the functions discussed herein. Processor device 804 can be connected to communication infrastructure 806, for example, bus, message queue, network, multi-core message delivery scheme, etc. The network can be any network suitable for performing the functions disclosed herein, and can include local area network (LAN), wide area network (WAN), wireless network (such as WiFi), mobile communication network, satellite network, Internet, optical fiber, coaxial cable, infrared, radio frequency (RF) or any combination thereof. Other suitable network types and configurations will be apparent to those skilled in the art. Computer system 800 can also include main memory 808 (for example, random access memory, read-only memory, etc.), and can also include auxiliary memory 810. Auxiliary memory 810 can include hard disk drive 812 and removable storage drive 814, for example, floppy disk drive, tape drive, CD-ROM drive, flash memory, etc.
[0114] The removable storage drive 814 can read from and / or write to a removable storage unit 818 in a known manner. The removable storage unit 818 can include a removable storage medium that the removable storage drive 814 can read and write to. For example, if the removable storage drive 814 is a floppy disk drive or a universal serial bus port, the removable storage unit 818 can be a floppy disk or a portable flash drive, respectively. In one embodiment, the removable storage unit 818 can be a non-transitory computer-readable recording medium.
[0115] In some embodiments, secondary memory 810 may include optional means for allowing computer programs or other instructions to be loaded into computer system 800, such as removable storage units 822 and interfaces 820. Examples of such means may include program cartridges and cartridge interfaces (e.g., as found in video game systems), removable memory chips (e.g., EEPROM, PROM, etc.) and associated sockets, as well as other removable storage units 822 and interfaces 820, as will be apparent to those skilled in the art.
[0116] Data stored in the computer system 800 (e.g., the main memory 808 and / or the secondary memory 810) may be stored on any type of suitable computer-readable medium, such as optical storage (e.g., compact disks, digital versatile disks, Blu-ray disks, etc.) or magnetic tape storage (e.g., hard drives). The data may be configured in any suitable type of database configuration, such as a relational database, a structured query language (SQL) database, a distributed database, an object database, etc. Suitable configurations and storage types will be apparent to those skilled in the art.
[0117] The computer system 800 may also include a communication interface 824. The communication interface 824 may be configured to allow software and data to be transmitted between the computer system 800 and external devices. Exemplary communication interfaces 824 may include a modem, a network interface (e.g., an Ethernet card), a communication port, a PCMCIA slot and card, etc. The software and data transmitted via the communication interface 824 may be in the form of a signal, which may be an electronic, electromagnetic, optical or other signal, which is apparent to those skilled in the relevant art. The signal may travel via a communication path 826, which may be configured to carry the signal and may be implemented using wires, cables, optical fibers, telephone lines, cellular phone links, radio frequency links, etc.
[0118] The computer system 800 may also include a display interface 802. The display interface 802 may be configured to allow data to be transmitted between the computer system 800 and an external display 830. Exemplary display interfaces 802 may include a high-definition multimedia interface (HDMI), a digital video interface (DVI), a video graphics array (VGA), etc. The display 830 may be any suitable type of display for displaying data transmitted via the display interface 802 of the computer system 800, including a cathode ray tube (CRT) display, a liquid crystal display (LCD), a light emitting diode (LED) display, a capacitive touch display, a thin film transistor (TFT) display, etc.
[0119] Computer program media and computer usable media may refer to memory, for example, main memory 808 and secondary memory 810, which may be memory semiconductors (e.g., DRAM, etc.). These computer program products may be means for providing software to the computer system 800. Computer programs (e.g., computer control logic) may be stored in the main memory 808 and / or the secondary memory 810. The computer programs may also be received via the communication interface 824. These computer programs, when executed, may enable the computer system 800 to implement the present methods discussed herein. In particular, the computer programs, when executed, may enable the processor device 804 to implement the methods discussed herein. Figure 3 , 4 , 6 and 7. Accordingly, such a computer program may represent a controller of the computer system 800. In the case of implementing the present disclosure using software, the software may be stored in a computer program product and loaded into the computer system 800 using the removable storage drive 814, the interface 820, and the hard disk drive 812 or the communication interface 824.
[0120] The processor device 804 may include one or more modules or engines configured to perform the functions of the computer system 800. Each module or engine may be implemented using hardware, and in some instances, may also be implemented using software (e.g., corresponding to program code and / or programs stored in the main memory 808 or the auxiliary memory 810). In this instance, the program code may be compiled by the processor device 804 (e.g., by compiling a module or engine) before being executed by the hardware of the computer system 800. For example, the program code may be a source code written in a programming language, which is compiled into a lower-level language such as an assembly language or a machine code to be executed by the processor device 804 and / or any additional hardware components of the computer system 800. The compilation process may include the use of lexical analysis, preprocessing, parsing, semantic analysis, syntax-directed translation, code generation, code optimization, and any other technology applicable to translating the program code into a lower-level language suitable for controlling the computer system 800 to perform the functions disclosed herein. Those skilled in the relevant art will appreciate that this process makes the computer system 800 a specially configured computer system 800 that is specially configured to perform the above-mentioned functions.
[0121] Among other features, the technology according to the present disclosure provides a system and method for enhancing the verification of passwords for variable account lengths. Although various exemplary embodiments of the disclosed systems and methods have been described above, it should be understood that they are provided for the purpose of illustration only, not limitation. This is not exhaustive, and the disclosure is not limited to the exact form disclosed. Modifications and changes may be made according to the above teachings, or modifications or changes may be obtained from the practice of the present disclosure without departing from the breadth or scope of the present invention.
Claims
1. A method for enhancing password verification for variable account lengths, comprising: receiving, by a receiving device of a computing device, at least an unpredictable number from a point-of-sale device, wherein the unpredictable number is generated by the point-of-sale device and a length of the unpredictable number is based on an indication received from the computing device or on a length of a transaction account number used to fund a payment transaction; generating, by a generation module of the computing device, a password based at least on the unpredictable number and one or more algorithms; A query module of the computing device executes a query in a memory of the computing device to identify a specific formatting template from among a plurality of stored formatting templates, wherein (i) the specific formatting template is associated with an account length; and (ii) the associated account length corresponds to a length of a specific primary account; generating, by a generation module of the computing device, a data string, wherein the data string includes at least the generated password, the specific primary account number, and the unpredictable number, and wherein the data string is formatted based on the identified specific formatting template; and The generated data string is sent by a sending device of the computing device to the point of sale device.
2. The method according to claim 1, wherein: The specific formatting template is identified based on a correspondence between the number of digits associated with the specific formatting template and the number of digits of the received unpredictable number.
3. The method according to claim 1, wherein: The generated data string is sent in a data message that also includes a bitmap indicating the formatting of the generated data message.
4. The method according to claim 3, further comprising: The bitmap is generated by a generation module of the computing device based at least on the specific formatting template.
5. The method according to claim 3, wherein: The bitmap included in the data message corresponds to the bitmap included in the specific formatting template.
6. The method according to claim 1, wherein: The generated data string also includes a transaction counter associated with the particular primary account number.
7. The method according to claim 6, wherein: The password is also based on the transaction counter associated with the particular primary account number.
8. The method according to claim 1, further comprising: A second password is generated by a generation module of the computing device based at least on the unpredictable number and at least one additional algorithm, wherein: The data string also includes the second password.
9. The method according to claim 1, wherein: The data string also includes at least one additional digit, and wherein the number of additional digits is based on the length of the specific primary account number and the number of digits of the received unpredictable number.
10. The method according to claim 9, wherein: The at least one additional bit stores cardholder verification method data.
11. A system for enhancing password verification for variable account lengths, comprising: a receiving device of a computing device configured to receive at least an unpredictable number from a point of sale device, wherein the unpredictable number is generated by the point of sale device and a length of the unpredictable number is based on an indication received from the computing device or based on a length of a transaction account number used to fund a payment transaction; a query module of the processing device configured to perform a query in a memory of the computing device to identify a specific formatting template among a plurality of stored formatting templates, wherein (i) the specific formatting template is associated with an account length; and (ii) the associated account length corresponds to a length of a specific primary account; The generating module of the processing device of the computing device is configured to: generating a password based at least on the unpredictable number and one or more algorithms, and generating a data string, wherein the data string includes at least the generated password, the specific primary account number, and the unpredictable number, and wherein the data string is formatted based on the identified specific formatting template; and The sending device of the computing device is configured to send the generated data string to the point-of-sale device.
12. The system according to claim 11, wherein: The specific formatting template is identified based on a correspondence between the number of digits associated with the specific formatting template and the number of digits of the received unpredictable number.
13. The system according to claim 11, wherein: The generated data string is sent in a data message that also includes a bitmap indicating the formatting of the generated data message.
14. The system according to claim 13, wherein: The generation module of the computing device is further configured to generate the bitmap based on at least the specific formatting template.
15. The system of claim 13, wherein: The bitmap included in the data message corresponds to the bitmap included in the specific formatting template.
16. The system according to claim 11, wherein: The generated data string also includes a transaction counter associated with the particular primary account number.
17. The system of claim 16, wherein: The password is also based on the transaction counter associated with the particular primary account number.
18. The system of claim 11, wherein: The generation module of the computing device is further configured to generate a second password based at least on the unpredictable number and at least one additional algorithm, and The data string also includes a second password.
19. The system of claim 11, wherein: The data string also includes at least one additional digit, and wherein the number of additional digits is based on the length of the specific primary account number and the number of digits of the received unpredictable number.
20. The system of claim 19, wherein: The at least one additional bit stores cardholder verification method data.
Citation Information
Patent Citations
Processing transactions with an extended application id and dynamic cryptograms
US20120317035A1
Authentication arrangement and method for use with financial transaction
WO2010030362A1