SYSTEM AND METHOD TO SECURE PAYMENT TRANSACTIONS

The disclosure includes systems and methods for authenticating a user with a one-time password having a one-time password offset parameter. The system receives a transaction authorization request message that includes a payment card identifier. A database is searched using the payment card identifier. The system retrieves contact details for a cardholder from the database. The system generates a one-time password and transmits the generated one-time password to the cardholder using the contact details. The system also receives a calculated one-time password response from the cardholder. The system retrieves a rule for producing the calculated one-time password response and a one-time password offset parameter from the database. A test one-time password is produced from the one-time password offset parameter based on the retrieved rule. The calculated one-time password response is compared to the test one-time password, and the calculated one-time password response value is authenticated based on a match.

FIELD OF THE DISCLOSURE

The present disclosure relates to systems and methods for processing one-time passwords and in particular to enabling a cardholder to predefine an offset function to be applied to a one-time password.

BACKGROUND OF THE DISCLOSURE

One-time passwords (OTPs) are often used in the verification of payment transactions. In the transaction authorization process, an OTP is sent as a text message, an email message, or other type of electronic communication to a cardholder's mobile telephone number or his or her email address. In order to verify that the transaction originated with the cardholder, the customer is prompted to enter the OTP at the time of checkout. Thus the use of OTPs can prevent or reduce fraudulent use of stolen payment cards by requiring an additional level of security. However, if a fraudster is able to intercept the transmission of the OTP, then the fraudster may still be able to perform fraudulent transactions using the cardholder's payment card.

SUMMARY OF THE DISCLOSURE

This brief description is provided to introduce a selection of concepts in a simplified form that are further described in the detailed description below. This brief description is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Other aspects and advantages of the present disclosure will be apparent from the following detailed description of the embodiments and the accompanying figures.

In one aspect, a system for authenticating a user with a one-time password is provided. The one-time password is associated with an offset parameter. The system includes a database and a processor. The database includes cardholder information for a cardholder. The cardholder information includes a payment card identifier, contact details for the cardholder, the one-time password offset parameter, and a rule for producing a calculated one-time password response value using the one-time password offset parameter. The processor is programmed to receive a transaction authorization request message. The transaction authorization request message includes the payment card identifier. The processor is programmed to search the database using the payment card identifier and retrieve the contact details for the cardholder based on the payment card identifier. Furthermore, the processor is programmed to generate a one-time password and transmit the generated one-time password to the cardholder using the contact details for the cardholder. The processor is programmed to receive the calculated one-time password response value from the cardholder and to retrieve, from the database, the rule for producing the calculated one-time password response value and the one-time password offset parameter. The processor is also programmed to produce a test one-time password from the one-time password offset parameter and the generated one-time password based on the retrieved rule. Moreover, the processor is programmed to compare the calculated one-time password response value to the test one-time password, and to authenticate the calculated one-time password response value based on the calculated one-time password response value matching the test one-time password.

In another aspect, a method for authenticating a user with a one-time password having a one-time password offset parameter is provided. The method includes receiving a transaction authorization request message. The transaction authorization request message includes the payment card identifier. The method also includes searching a database using the payment card identifier and retrieving, from the database, contact details for the cardholder based on the payment card identifier. The method includes generating a one-time password and transmitting the generated one-time password to the cardholder using the contact details for the cardholder. Furthermore, the method includes receiving a calculated one-time password response value from the cardholder. In addition, the method includes retrieving, from the database, a rule for producing the calculated one-time password response value and a one-time password offset parameter and producing a test one-time password from the one-time password offset parameter and the generated one-time password based on the retrieved rule. The method further includes comparing the calculated one-time password response value to the test one-time password and authenticating the calculated one-time password response value based on the calculated one-time password response value matching the test one-time password.

A variety of additional aspects will be set forth in the detailed description that follows. These aspects can relate to individual features and to combinations of features. Advantages of these and other aspects will become more apparent to those skilled in the art from the following description of the exemplary embodiments which have been shown and described by way of illustration. As will be realized, the present aspects described herein may be capable of other and different aspects, and their details are capable of modification in various respects. Accordingly, the figures and description are to be regarded as illustrative in nature and not as restrictive.

Unless otherwise indicated, the figures provided herein are meant to illustrate features of embodiments of this disclosure. These features are believed to be applicable in a wide variety of systems comprising one or more embodiments of this disclosure. As such, the figures are not meant to include all conventional features known by those of ordinary skill in the art to be required for the practice of the embodiments disclosed herein.

DETAILED DESCRIPTION OF THE DISCLOSURE

The following detailed description of embodiments of the invention references the accompanying figures. The embodiments are intended to describe aspects of the invention in sufficient detail to enable those with ordinary skill in the art to practice the invention. The embodiments of the invention are illustrated by way of example and not by way of limitation. Other embodiments may be utilized, and changes may be made without departing from the scope of the claims. The following description is, therefore, not limiting. The scope of the present invention is defined only by the appended claims, along with the full scope of equivalents to which such claims are entitled.

As used herein, the term “database” includes either a body of data, a relational database management system (RDBMS), or both. As used herein, a database includes, for example, and without limitation, a collection of data including hierarchical databases, relational databases, flat file databases, object-relational databases, object oriented databases, and any other structured collection of records or data that is stored in a computer system. Examples of RDBMS's include, for example, and without limitation, Oracle® Database (Oracle is a registered trademark of Oracle Corporation, Redwood Shores, Calif.), MySQL, IBM® DB2 (IBM is a registered trademark of International Business Machines Corporation, Armonk, N.Y.), Microsoft® SQL Server (Microsoft is a registered trademark of Microsoft Corporation, Redmond, Wash.), Sybase® (Sybase is a registered trademark of Sybase, Dublin, Calif.), and PostgreSQL. However, any database may be used that enables the systems and methods to operate as described herein.

As used herein, the terms “transaction card,” “financial transaction card,” and “payment card” may include any suitable transaction card, such as a credit card, a debit card, a charge card, a membership card, a promotional card, an identification card, a prepaid card, a gift card, and/or any other device that may hold payment account information, such as a mobile phone, smart phone, personal digital assistant (PDA), key fobs, and/or computer. Each type of transaction card can be used as a method of payment for performing a transaction.

Exemplary Payment Network Systems

FIG. 1is a block diagram illustrating an example multi-party payment card network system10, in accordance with one embodiment of the present disclosure. The example payment card network system10generally includes merchants12, acquirers14, interchange networks16, and card issuers18, coupled in communication via a network20. As used herein, the term “interchange network” includes an electronic network that exchanges data relating to the value of card sales and credits among the card issuers18and the acquirers14.

The payment card network system10facilitates providing interchange network services offered by the interchange network16. In addition, the payment card network system10enables payment card transactions in which the merchants12, the acquirers14, and/or the card issuers18do not need to have a one-to-one relationship. As an example, the payment card network system10may be utilized by the merchants12as part of a process of initiating a pre-authorization request for performing a transaction (as described herein). Although parts of the payment card network system10are presented in one arrangement, other embodiments may include the same or different parts arranged otherwise, depending, for example, on pre-authorization processes for purchase transactions, communication between computing devices, etc.

The network20includes, for example and without limitation, one or more of a local area network (LAN), a wide area network (WAN) (e.g., the Internet, etc.), a mobile network, a virtual network, and/or any other suitable public and/or private network capable of facilitating communication among the merchants12, the acquirers14, the interchange network16, the issuers18, and/or a consumer or cardholder22(also referred to herein as a “user”). Additionally, the network20may include more than one type of network, such as a private payment transaction network provided by the interchange network16to the acquirers14and/or the card issuers18, and separately, the public Internet, which may facilitate communication between the merchants12, the interchange network16, the acquirers14, and/or the cardholders22.

Embodiments described herein relate to a payment card system, such as a credit card payment system using the Mastercard® interchange network. (Mastercard is a registered trademark of Mastercard International Incorporated.) The Mastercard interchange network is a set of proprietary communications standards promulgated by Mastercard for the exchange of financial transaction data and the settlement of funds between financial institutions that are members of Mastercard. As used herein, financial transaction data includes a unique account number associated with an account holder using a payment card issued by a card issuer, purchase data representing a purchase made by the consumer, including a type of merchant, amount of purchase, date of purchase, and other data, which may be transmitted between any parties of the multi-party payment card network system10.

In a typical payment card system, a financial institution called the “issuer” issues a payment card30, such as a debit card or credit card, to the user or cardholder22, who uses the payment card30to tender payment for a purchase from the merchant12. The cardholder22may, in some instances, enter the payment card information into a digital wallet (shown inFIG. 3) on a cardholder mobile device40, which can then be used to tender payment for a purchase from the merchant12. The merchant12is typically associated with products, for example, and without limitation, goods and/or services, that are offered for sale and are sold to the cardholders22. The merchant12includes, for example, a physical location and/or a virtual location. A physical location includes, for example, a brick-and-mortar store, etc., and a virtual location includes, for example, an Internet-based store-front.

To accept payment with the payment card30, the merchant12must normally establish an account with a financial institution that is part of the payment card network system10. This financial institution is usually called the “merchant bank,” the “acquiring bank,” or the acquirer14.

When the cardholder22provides payment for a purchase with the payment card30or the cardholder mobile device40, the merchant12requests authorization from the acquirer14for the purchase amount. The request may be performed over the telephone but is usually performed using a point-of-sale (POS) terminal, such as a POS terminal32, that reads the consumer's account information from a magnetic stripe, a chip, or embossed characters on the payment card30and/or receives a payment token from the mobile device, and communicates electronically with the transaction processing computers of the acquirer14. However, in some embodiments, the payment card transaction is a card-not-present (CNP) account-on-file transaction in which a payment card is not presented to the merchant12during a transaction. In such CNP transactions, for example, the merchant12may have stored the cardholder's payment card account information from a previous transaction or may have stored the information based on an agreement for initiating recurring transactions. This information is then communicated electronically with the transaction processing computers of the acquirer14. In some embodiments, the acquirer14may authorize a third party (not shown) to perform transaction processing on its behalf. In this case, the POS terminal32will be configured to communicate with the third party. Such a third party is usually called a “merchant processor,” an “acquiring processor,” or a “third party processor.”

Using the interchange network16, computers of the acquirer14or merchant processor will communicate with computers of the card issuer18to determine whether the cardholder's account is in good standing and whether the purchase is covered by the cardholder's available credit line. Upon submission of an authorization request to the card issuer18via the interchange network16, the interchange network identifies the payment transaction authorization request as requiring one-time password (OTP) verification. An OTP service system28retrieves contact information for the cardholder22from a database26. This retrieval process may involve using a payment card identifier (e.g., a primary account number (PAN)) to identify the cardholder's contact details, such as a mobile telephone number for the cardholder22. The interchange network16sends an OTP request to the merchant12, for example, via the POS terminal32, requesting an OTP from the cardholder22. In addition, the interchange network16sends an OTP message to the cardholder22, via the cardholder mobile device40.

In the exemplary embodiment, when the cardholder22opts-in or registers with the interchange network16to receive a one-time password (also referred to as a one-time use short code) before completing transactions, the cardholder determines an “offset” to be applied to the one-time password. For example, the cardholder22may choose a simple value to be added or subtracted from the one-time password or he or she may define a mathematical formula to be applied. After applying the “offset” to the received one-time password, the cardholder22provides a response to the OTP request. If the cardholder22provides a valid OTP response to the OTP request at the POS terminal32, the authorization request message is transmitted to the card issuer18. Based on a determination regarding the cardholder's account standing and funds availability, the request for authorization will be declined or accepted. If the request is accepted, an authorization code is issued to the merchant12. If the OTP response is invalid, the authorization request may be automatically declined by the interchange network16.

When a request for authorization is accepted, the available funds or a credit line of the cardholder's account is decreased. Normally, a charge for a payment card transaction is not posted immediately to the cardholder's account because bankcard associations, such as Mastercard, have promulgated rules that do not allow the merchant12to charge, or “capture,” a transaction until the purchased goods are shipped or the purchased services are delivered. However, with respect to at least some debit card transactions, a charge may be posted at the time of the transaction. When the merchant12ships or delivers the goods or services, the merchant12captures the transaction by, for example, appropriate data entry procedures on the point-of-sale terminal. This may include bundling of approved transactions daily for standard retail purchases. If the cardholder22cancels a transaction before it is captured, a “void” is generated. If the cardholder22returns goods after the transaction has been captured, a “credit” is generated. In some instances, if the cardholder22did not authorize the transaction, such as a previously cancelled recurring payment or a card-not-present (CNP) account-on-file transaction, a “chargeback” is generated. The interchange network16and/or the card issuer18stores the transaction data, such as, and without limitation, the PAN and expiry date of the payment card30, a type of merchant, a merchant identifier, a location where the transaction was performed, a dollar amount of the transaction, a merchant category code, a date and time of the transaction, products purchased and related descriptions or identifiers, etc., in a transaction database (not shown).

After the transaction has been authorized, a clearing process occurs to transfer additional transaction data related to the transaction among the parties to the transaction, such as the acquirer14and the card issuer18. More specifically, during and/or after the clearing process, additional data, such as a time of purchase, a merchant name, a type of merchant, purchase information, consumer account information, a type of transaction, itinerary information, information regarding the purchased item and/or service, and/or other suitable information, is associated with the transaction and transmitted between parties to the transaction as transaction data, and may be stored by any of the parties to the transaction.

While only one merchant12, acquirer14, interchange network16, and card issuer18are shown inFIG. 1(for ease of reference), it should be appreciated that a variety of other embodiments may include multiple ones of these parties in various combinations.

FIG. 2is a block diagram of a transaction card account system200showing data flow among the payment card30and/or the cardholder's mobile device40, a payment processor202, and a merchant processor204. In the example embodiment, the system200is a transaction card account system such as the payment card network system10(shown inFIG. 1). In some embodiments, the payment processor202is an interchange network, such as the interchange network16(shown inFIG. 1). The cardholder mobile device40is configured to allow the cardholder22(shown inFIG. 1) to access the payment processor202and the merchant processor204, for example, via the POS terminal32(shown inFIG. 1), and electronically transact with the payment processor202and/or the merchant processor204to purchase goods or services associated with the merchant12(shown inFIG. 1). In the example embodiment, the cardholder mobile device40is coupled in communication with one or more of the POS terminal32and the payment processor202.

In the example embodiment, the merchant processor204includes a merchant computer device206. The merchant computer device206is a computer device such as the POS terminal32. The merchant computer device206is a service-provided device that is coupled in communication with the merchant processor204.

In the exemplary embodiment, the payment card30and/or the cardholder mobile device40transmit transaction data208to the merchant computer device206when making a purchase from the merchant12. In one embodiment, the cardholder mobile device40is configured to transmit the transaction data208wirelessly via a transceiver312(shown inFIG. 3) to the merchant computer device206(i.e., the POS terminal32). In certain embodiments, the payment card30is configured to transmit the transaction data208via a magnetic swipe, EMV chip, or wirelessly, via NFC-enabled circuitry. The transaction data208may include, for example, transaction information that indicates a purchased item identifier associated with the goods and/or services the cardholder22would like to purchase and a payment credential (e.g., digital wallet data306(shown inFIG. 3)).

The merchant processor204receives the transaction data208and generates a payment authorization request message210. The payment authorization request message210is transmitted to the payment computer device212for processing and further transmission to an issuing bank for approval. In one embodiment, the payment computer device212includes an interchange computer associated with an interchange.

If the cardholder22has registered or is otherwise participating in the one-time password (OTP) service, an OTP service system214retrieves cardholder information from a cardholder information database216. The OTP service system214generates a one-time password and transmits the password to the cardholder mobile device40as an OTP message218. In addition, the OTP service system214transmits an OTP request message220to the merchant computer device206to request entry of the one-time password.

In one embodiment, the cardholder mobile device40is configured to transmit OTP data222(e.g., the one-time password with an “offset”) to the POS terminal32. In certain other embodiments, the cardholder mobile device40displays the OTP data222to the cardholder22, who applies an “offset” value/calculation to the one-time password and transmits the OTP data222manually into the merchant computer device206. The merchant computer device206is configured to transmit an OTP response message224to the OTP service system214via, for example, the payment computer device212. The OTP response message includes, for example, the OTP data222received from the cardholder22and/or the cardholder mobile device40. A payment authorization response message226is received from the issuing bank and transmitted to the merchant computer device206by the payment computer device212.

Exemplary Computer Systems

FIG. 3is an example configuration of a user system300operated by a user301, such as the cardholder22(shown inFIG. 1). In some embodiments, the user system300is the cardholder mobile device40and/or the merchant POS terminal32. In the example embodiment, the user system300includes a processor302for executing instructions. In some embodiments, executable instructions are stored in a memory device304. The processor302includes one or more processing units, for example, a multi-core configuration. The memory device304is any device allowing information such as the digital wallet data306, executable instructions, and/or written works to be stored and retrieved. The memory device304includes one or more computer readable media.

The user system300also includes at least one media output component308for presenting information to the user301. The media output component308is any component capable of conveying information to the user301. In some embodiments, the media output component308includes an output adapter such as a video adapter and/or an audio adapter. An output adapter is operatively coupled to the processor302and operatively connectable to an output device such as a display device, a liquid crystal display (LCD), organic light emitting diode (OLED) display, or “electronic ink” display, or an audio output device, a speaker, or headphones.

The user system300includes an input device310for receiving input from the user301. The input device310may include, for example, a touch sensitive panel, a touch pad, a touch screen, a stylus, a gyroscope, an accelerometer, a position detector, a keyboard, a pointing device, a mouse, or an audio input device. A single component, such as a touch screen, may function as both an output device of the media output component308and the input device310. The user system300may also include a communication interface312, which is communicatively connectable to a remote device such as the interchange network16and/or the POS terminal32(shown inFIG. 1). The communication interface312may include, for example, a wired or wireless network adapter or a wireless data transceiver for use with Bluetooth communication, radio frequency communication, near field communication (NFC), and/or with a mobile phone network, Global System for Mobile communications (GSM),3G, or other mobile data network, and/or Worldwide Interoperability for Microwave Access (WiMax) and the like.

The user system300includes a software application/user interface314, which may be embodied, controlled, and/or executed by the processor302. The application/user interface314may be hosted by a cloud-based computing device (e.g., a web server or the like (not shown)) without departing from the spirit of the present disclosure, for instance where the application/user interface314is accessed remotely by the user system300that is external to an organization managing the application/user interface314, such as the interchange network16. In certain embodiments, access to the application/user interface314is granted via a common authentication framework, such as through known single sign-on (SSO) processes.

Stored in the memory device304are, for example, computer readable instructions for providing the user interface314to the user301via the media output component308and, optionally, receiving and processing input from the input device310. A user interface may include, among other possibilities, a web browser and/or a client application. Web browsers enable users, such as the user301, to display and interact with media and other information typically embedded on a web page or a website provided, for example, by a merchant12, the interchange network16, the card issuer18, and the like, whereas a client application allows the user301to interact with a server application provided, for example, by a merchant12, the interchange network16, the card issuer18, and the like.

In the example embodiment, the user system300is a cardholder mobile device from which the user301may engage with a digital wallet306, an online merchant (e.g., the merchant12shown inFIG. 1), an interchange network (e.g., the interchange network16shown inFIG. 1), and an issuer of a payment card (e.g., the card issuer18shown inFIG. 1) to perform a payment transaction that undergoes a one-time password authentication process.

FIG. 4is an example configuration of a server system400, such as the interchange network16(shown inFIG. 1). The server system400includes and/or is coupled to, but is not limited to, the database26(shown inFIG. 1) and/or the cardholder information database216(shown inFIG. 2). In the example embodiment, the server system400includes a processor402for executing instructions. The instructions may be stored in a memory area404, for example. The processor402includes one or more processing units (e.g., in a multi-core configuration) for executing the instructions. The instructions may be executed within a variety of different operating systems on the server system400, such as UNIX, LINUX, Microsoft Windows®, etc. More specifically, the instructions may cause various data manipulations on data stored in a storage device410(e.g., create, read, update, and delete procedures). It should also be appreciated that upon initiation of a computer-based method, various instructions may be executed during initialization. Some operations may be required to perform one or more processes described herein, while other operations may be more general and/or specific to a programming language (e.g., C, C#, C++, Java, or other suitable programming languages, etc.).

The processor402is operatively coupled to a communication interface406such that the server system400can communicate with a remote device such as a user system300(shown inFIG. 3) or another server system. For example, the communication interface406may receive communications from a client system32via the Internet, as illustrated inFIG. 2.

The processor402is operatively coupled to the storage device410. The storage device410is any computer-operated hardware suitable for storing and/or retrieving data. In some embodiments, the storage device410is integrated in the server system400. In other embodiments, the storage device410is external to the server system400and is similar to the database26and/or the cardholder information database216. For example, the server system400may include one or more hard disk drives as the storage device410. In other embodiments, the storage device410is external to the server system400and may be accessed by a plurality of server systems400. For example, the storage device410may include multiple storage units such as hard disks or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. The storage device410may include a storage area network (SAN) and/or a network attached storage (NAS) system.

In some embodiments, the processor402is operatively coupled to the storage device410via a storage interface408. The storage interface408is any component capable of providing the processor402with access to the storage device410. The storage interface408may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor402with access to the storage device410.

Exemplary One-Time Password Service System

FIG. 5is a block diagram of an example OTP service system500, such as the OTP service system28(shown inFIG. 1), illustrating the functional modules of the system, in accordance with one embodiment of the present disclosure. In the exemplary embodiment, the OTP service system500is part of the interchange network16(shown inFIG. 1). However, it is noted that various operations or functions of the OTP service system500may be implemented on other parts of the system10(shown inFIG. 1). For example, and without limitation, in certain embodiments, the card issuer18may carry out OTP verification. Furthermore, various operations or functions of the OTP service system500may be implemented in other systems not shown, such as transaction systems configured for authorizing automated teller machine (ATM) transactions.

In the exemplary embodiment, the OTP service system500includes an OTP authentication server502having an OTP offset credential module504, and a credential database506, such as the cardholder information database216(shown inFIG. 2). The OTP authentication server502is a specially programmed computer system that enables the cardholder22(shown inFIG. 1) to implement user-selected offset value OTP login credentials to facilitate identifying and authenticating the cardholder22, for example, when performing a payment transaction, for example, at a merchant12via a POS terminal32.

The components illustrated inFIG. 5are shown as functional components of the OTP service system500. In some embodiments, the individual components may be a hardware component, a software component, or a combination of hardware and software components. Some of the components may include application level software, while other components may be execution environment level components. It is contemplated that two or more of the components may operate on a single hardware platform. Each embodiment described herein may use different combinations of hardware, software, and interconnections to achieve the methods and/or techniques described herein.

While the OTP service system500is shown inFIG. 1as multiple components implemented on a standalone computing device, it is noted that the OTP service system500may be implemented on or distributed among a plurality of computing devices. The configuration of the OTP service system500is flexible and may be implemented in various different environments and configurations without compromising any major functionality. The systems and processes are not limited to the specific embodiments described herein. In addition, components of each system and each process can be practiced independent and separate from other components and processes described herein. Each component and process can also be used in combination with other assembly packages and processes.

In the exemplary embodiment, the OTP authentication server502is a server computing device, such as the server system400as described inFIG. 4. In alternative embodiments, the OTP authentication server502may include, without limitation, a conventional desktop computing device, a laptop computing device, a netbook computing device, a tablet or slate computing device, a wireless handset, a cellular telephone, a game console, or any other type of computing device that can store and/or execute the OTP offset credential module504thereon and communicate with, for example, the cardholder mobile device40and the POS terminal32(each shown inFIG. 1). In some embodiments, the OTP authentication server502may be implemented in a cloud computing environment. For example, and without limitation, the functionality of the OTP authentication server502disclosed herein may be provided by executing one or more applications, such as the OTP offset credential module504, in a cloud computing environment. Cloud computing typically includes providing computing services via a network connection, such as the network20(shown inFIG. 1), using dynamically scalable computing resources. A cloud computing environment may be established by an enterprise and/or may be hired on an as-needed basis from a third-party provider.

The credential database506is a data store configured to store cardholder information for the cardholders22. For example, and without limitation, the credential database506includes payment card identifiers (e.g., primary account numbers (PANs)), a cardholder's contact details (e.g., a mobile telephone number and/or email address for cardholders), and OTP offset parameters and/or rules. The credential database506may include a single database having separated sections or partitions or may include multiple databases, each being separate from each other. In one suitable embodiment, the credential database506is a relational database where the payment card identifiers, contact details, and OTP offset parameters and/or rules are stored in tables.

As described inFIG. 3, a user system300(e.g., the cardholder mobile device40) includes an application/user interface314that a user, such as the cardholder22, utilizes to register with the OTP service system500and/or input OTP offset parameters and/or rules. For example, and without limitation, the application/user interface314enables the cardholder22to input information to the cardholder mobile device40and the cardholder mobile device40to output information to the cardholder22(e.g., on a display of the user interface314). As described herein, the application/user interface314includes, for example, a web browser that receives webpages from the OTP authentication server502, such that the OTP authentication server502is accessible to the cardholder mobile device40via the network20. In some embodiments, the application/user interface314may include a discrete software program that interfaces directly with the OTP authentication server502.

As disclosed herein, the OTP authentication server502includes the OTP offset credential module504. The OTP offset credential module504includes, for example, and without limitation, a database server508, a transaction message module510, an OTP generation module512, an OTP message module514, and an OTP processing module516.

In the exemplary embodiment, the OTP offset credential module504receives OTP offset data corresponding to a user, such as the cardholder22, from a cardholder mobile device40or another cardholder computing device. As described herein, the OTP offset data includes, for example, a payment card identifier, a cardholder's contact details, and OTP offset parameters and/or rules. The payment card identifier, contact details, and OTP offset parameters and/or rules are stored, for example, on the credential database506for later retrieval.

As is described herein, when a merchant submits a payment authorization request message, such as the payment authorization request message210(shown inFIG. 2), the OTP offset credential module504attempts to match the payment card identifier contained in the payment authorization request message to a payment card identifier stored on the credential database506. When a match is identified, the OTP offset credential module504identifies the corresponding cardholder contact information, such as a mobile telephone number or email address, generates an OTP, and transmits the OTP to the cardholder mobile device40based on the contact information. In addition, the OTP offset credential module504transmits an OTP request message to the merchant12. The OTP offset credential module504searches the credential database506, e.g., an OTP offset parameters table, for any OTP offset parameters and/or rules, and based on the defined parameters and/or rules found therein, generates a test OTP.

The cardholder22submits OTP data to the merchant POS terminal32in response to an OTP request presented to the cardholder22by the POS terminal. In particular, the cardholder22receives the OTP from the OTP offset credential module504, applies his or her selected offset value based on the previously defined offset parameters and/or rules, and enters his or her response (e.g., the OTP data222(shown inFIG. 2)) into the POS terminal32. The merchant transmits an OTP response message back to the OTP offset credential module504containing the cardholder's OTP data.

If the test OTP and the OTP data submitted by the cardholder22match, the OTP offset credential module504passes a payment authorization response message226to the merchant, thereby enabling the transaction to be completed. If the test OTP and the OTP data submitted by the cardholder22do not match, the OTP offset credential module504declines the transaction.

In the exemplary embodiment, the database server508is coupled in communication to the credential database506, which is configured to store information on a variety of matters, including the payment card identifier, the cardholder's contact details, and the OTP offset parameters and/or rules, as described above. In one embodiment, the credential database506is a centralized database stored on the OTP authentication server502. In an alternative embodiment, the credential database506is stored remotely from the OTP authentication server502and may be a distributed or non-centralized database, as described herein.

The database server508operates, in part, to receive input data from a cardholder, such as the cardholder22, during a registration process. The database server508receives the cardholder's payment card identifier, contact details, and OTP offset parameters and/or rules from the cardholder22, for example, via the cardholder mobile device40, and stores this information in the credential database506.

The transaction message module510is coupled to a payment network (such as the interchange network16) or other network which allows the OTP service system28to send and receive transaction related messages to and from other computing devices involved in a payment transaction authorization process. In addition, the transaction message module510parses the incoming payment authorization request messages to identify the associated PANs and passes this information to the database server508to perform one or more lookup operations.

The OTP generation module512is configured to generate an OTP, for example, as a random sequence of characters. Typically, the OTP has a fixed number of elements as defined by a system administrator, where the elements generally include ASCII characters. Alternatively, the OTP can have a variable number of elements, usually with a minimum number of elements, as defined by a system administrator. The OTP generation module512may include, for example, a random number generator (RNG) for determining the elements of the OTP.

The OTP message module514is a communication module that is configured to transmit the OTP generated by the OTP generation module512to the cardholder22. For example, the OTP message module514is connected to the network20and transmits the OTP to the cardholder mobile device40via, for example, an SMS message and/or an email message (based on the cardholder's contact information). In addition, the OTP message module514is in communication with the merchant POS terminal32for transmitting the OTP request message220to and receiving the OTP response message224therefrom.

The OTP processing module516generates a rule to be stored and associated with the cardholder information in the credential database506. Using the application/user interface314(shown inFIG. 3) of the cardholder mobile device40or other computing device, the cardholder22enters an offset value or calculation to be applied to the generated OTP when performing a transaction. The rule is defined by one or more user selected parameter components during the registration process. As described herein, the rule is stored in the credential database506.

In addition, the OTP processing module516receives from the merchant12, via the POS terminal32, an OTP response message that contains the cardholder's OTP data. The OTP processing module516searches the credential database506for a matching payment card identifier based on the payment authorization request message. After identifying an entry matching the payment card identifier, the OTP processing module516retrieves the one or more parameters and/or rules associated with the entry. Based on parameters and/or rules retrieved from the credential database506, the OTP processing module516generates a test OTP, compares the test OTP to the received OTP data, and authenticates the cardholder22if the comparison operation indicates a match.

The computer-implemented method600is described below, for ease of reference, as being executed by exemplary devices and components introduced with the embodiments illustrated inFIGS. 1-5. In one embodiment, the computer-implemented method600is implemented by the OTP service system28(shown inFIG. 1). In the exemplary embodiment, the computer-implemented method600relates to an OTP having a user-selected offset. While operations within the computer-implemented method600are described below regarding the OTP service system28, according to some aspects of the present invention, the computer-implemented method600may be implemented using any other computing devices and/or systems through the utilization of processors, transceivers, hardware, software, firmware, or combinations thereof. A person having ordinary skill will also appreciate that responsibility for all or some of such actions may be distributed differently among such devices or other computing devices without departing from the spirit of the present disclosure.

One or more computer-readable medium(s) may also be provided. The computer-readable medium(s) may include one or more executable programs stored thereon, wherein the program(s) instruct one or more processors or processing units to perform all or certain of the steps outlined herein. The program(s) stored on the computer-readable medium(s) may instruct the processor or processing units to perform additional, fewer, or alternative actions, including those discussed elsewhere herein.

The method600includes, in operation602, receiving an offset parameter component for applying to an OTP. For example, and without limitation, the cardholder22enters or selects, for example, via the application/user interface314, an offset parameter component to be applied to an OTP when processing a payment transaction. In particular, the application/user interface314presents an option to the cardholder22for configuring an offset parameter component to be applied to an OTP that will be transmitted to the cardholder during a payment transaction. The application/user interface314may present a list of user-selectable mathematical operations along with user-selectable offset parameter components. It is noted that the user-selectable offset parameter components may include any numerical variable that is determinable at a specific time by both the cardholder22and the OTP authentication server502, such that an OTP response value is determinable.

For example, the cardholder22may select to perform a mathematical operation, such as addition, subtraction, multiplication, or division, to combine the offset parameter component and the generated OTP. In another embodiment, the cardholder22may select to combine the generated OTP and the offset parameter component by prepending or appending the offset parameter component to the generated OTP.

The offset parameter component may include stock values, market index values, exchange rates, temperatures, locations, and the like. Furthermore, and without limitation, the offset parameter components may include a DATE association (e.g., day of the month, year, etc.), a TIME (e.g., a time of the transaction attempt, etc.), or any other dynamic offset parameter component that enables the subsequent determination of the OTP response value. As such, the offset parameter component may be a discrete determinable parameter, such as a number, DAY, TIME, etc., or may be a class of determinable parameters, such as stock values, that include a plurality of subcomponents that are discrete determinable parameters. The list of acceptable offset parameter components is predetermined by the administrator of the OTP authentication server502.

At operation604, the OTP authentication server502, and more particularly, the OTP processing module516, generates a rule for producing the offset OTP value (also referred to herein as the test OTP value). For example, and without limitation, the OTP processing module516generates a rule for storing in the credential database506(shown inFIG. 5). The rule serves to instruct the OTP authentication server502to perform the predetermined operation on the generated OTP using the offset parameter component, as defined by the cardholder22.

At operation606, the database server508stores the offset parameter component and the generated rule in the credential database506. In particular, in the exemplary embodiment, the OTP processing module516passes the generated rule to the database server508for storage. As described above, the offset parameter component is determined by the cardholder22and input to the database server508using, for example, the application/user interface314. The database server508communicates with the credential database56and stores the offset parameter component and the rule as retrievable data for subsequent use by the OTP authentication server502. Furthermore, at operation608, the OTP processing module516instructs the database server508to associate, within the credential database506, the rule with the offset parameter component and the cardholder payment card identifier.

FIG. 7is a flowchart illustrating an exemplary computer-implemented method700for processing a one-time password (OTP) having a user-selected offset, in accordance with one embodiment of the present disclosure. The operations described herein may be performed in the order shown inFIG. 7or, according to certain inventive aspects, may be performed in a different order. Furthermore, some operations may be performed concurrently as opposed to sequentially, and/or some operations may be optional, unless expressly stated otherwise or as may be readily understood by one of ordinary skill in the art.

The computer-implemented method700is described below, for ease of reference, as being executed by exemplary devices and components introduced with the embodiments illustrated inFIGS. 1-5. In one embodiment, the computer-implemented method700is implemented by the OTP service system28(shown inFIG. 1). While operations within the computer-implemented method700are described below regarding the OTP service system28, according to some aspects of the present invention, the computer-implemented method700may be implemented using any other computing devices and/or systems through the utilization of processors, transceivers, hardware, software, firmware, or combinations thereof. A person having ordinary skill will also appreciate that responsibility for all or some of such actions may be distributed differently among such devices or other computing devices without departing from the spirit of the present disclosure.

One or more computer-readable medium(s) may also be provided. The computer-readable medium(s) may include one or more executable programs stored thereon, wherein the program(s) instruct one or more processors or processing units to perform all or certain of the steps outlined herein. The program(s) stored on the computer-readable medium(s) may instruct the processor or processing units to perform additional, fewer, or alternative actions, including those discussed elsewhere herein.

In operation step702, the transaction message module510of the OTP service system28receives a transaction authorization request message, such as the transaction authorization request message2210(shown inFIG. 2). The transaction authorization request message may be received from a merchant, such as the merchant12, or an acquirer, such as the acquirer14(each shown inFIG. 1). The transaction authorization request message includes, for example, and without limitation, a payment card identifier, a transaction amount, a merchant name, a merchant identifier, a merchant category code (MCC), a merchant location, and the like.

In operation704, the database server508of the OTP service system28parses the transaction authorization request message and uses the payment card identifier to retrieve (e.g., look up) contact details for the cardholder, such as the cardholder22(shown inFIG. 1). The contact details include, for example, a mobile telephone number, email address, or other messaging information for contacting the cardholder. It is noted that the contact details may include more than one messaging system for contacting the cardholder and may include a preferred method of contact.

In operation706, the OTP generation module512of the OTP service system28generates an OTP to be transmitted to the cardholder. As described herein, the OTP is a random sequence of characters, typically of a defined length. In a preferred embodiment, the OTP includes six (6) characters, forming a random 6-digit number. In operation708, the OTP is transmitted to the cardholder by the OTP message module514of the OTP service system28. In particular, the OTP is transmitted to the cardholder using the cardholder's preferred method of contact. It should be noted, that in some embodiments, the cardholder may not select a preferred method of contact. In such instances, the OTP may be transmitted using each of the cardholder's stored methods of contact, or a system administrator of the OTP service system28may designate a particular form of contact as a default preferred method.

In operation710, an OTP request message is transmitted to the merchant associated with the transaction authorization request message by the OTP message module514. In particular, the OTP request message is transmitted to the merchant's POS terminal, such as the POS terminal32, requesting the cardholder to enter his or her OTP data before further processing of the transaction is performed. In the exemplary embodiment, the OTP service system28delays further processing for a predetermined period after transmitting the OTP to the cardholder and the OTP request message to the merchant. This provides the cardholder with a period in which to respond to the OTP request message. For example, and without limitation, in one suitable embodiment, the OTP service system28may delay further processing for a period of sixty (60) seconds.

In operation712, the OTP message module514receives OTP data from the cardholder, for example, via the merchant. The OTP data includes a calculated OTP response value that was entered into the merchant POS by the cardholder22. As described herein, the cardholder determines an appropriate OTP response value based on the generated OTP and his or her predetermined offset. After determining the appropriate response values, the cardholder submits the value to the POS terminal in response to the OTP request.

In operation714, the OTP processing module516searches a credential database, such as the credential database506(shown inFIG. 5), using the payment card identifier. In the exemplary embodiment, the credential database506includes a rules table including one or more rules table records. Each rules table record includes a primary key and a rule entry of a rule for producing an offset OTP value. In addition, the credential database506includes a cardholder information table including one or more cardholder table records. Each cardholder table record includes a foreign key and a payment card identifier entry. The foreign key references a primary key of the rules table, which is associated with a specific rule for generating an offset OTP associated with the respective payment card identifier.

In one embodiment, the search operation714includes searching the cardholder information table and identifying a cardholder table record having a payment card identifier entry that matches the payment card identifier extracted from the transaction authorization request message. The foreign key of the identified cardholder table record is retrieved, and the referenced rule is identified in the rule table based on a matching primary key.

At operation716, the OTP processing module516retrieves one or more rules associated with the entry payment card identifier. The rule(s) identifies an offset parameter component and an instruction for applying the offset parameter component to the generated OTP (e.g., appending, prepending, or applying a mathematical function) to generate a test OTP. Based on one or more rules retrieved from the credential database506, at operation718, the OTP processing module516generates the test OTP. More specifically, the OTP processing module516retrieves a value for the offset parameter component identified by the rule. The generated OTP and the value for the offset parameter component are combined as specified by the rule. The result is the test OTP.

At operation720, the OTP processing module516compares the test OTP to the received OTP data (e.g., the calculated OTP response value), and if the comparison operation indicates a match, the OTP processing module516authenticates the cardholder. At operation722, the transaction message module510passes a payment authorization response message, such as the payment authorization response message226(shown inFIG. 2), to the merchant, thereby enabling the transaction to be completed. If the test OTP and the OTP data submitted by the cardholder22do not match, at operation724, the OTP offset credential module504declines the transaction.

Additional Considerations

Although the present application sets forth a detailed description of numerous different embodiments, it should be understood that the legal scope of the description is defined by the words of the claims and equivalent language. The detailed description is to be construed as exemplary only and does not describe every possible embodiment because describing every possible embodiment would be impractical. Numerous alternative embodiments may be implemented, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims.

Throughout this specification, plural instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order recited or illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein. The foregoing statements in this paragraph shall apply unless so stated in the description and/or except as will be readily apparent to those skilled in the art from the description.

In various embodiments, computer hardware, such as a processor, may be implemented as special purpose or as general purpose. For example, the processor may comprise dedicated circuitry or logic that is permanently configured, such as an application-specific integrated circuit (ASIC), or indefinitely configured, such as a field-programmable gate array (FPGA), to perform certain operations. The processor may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement the processor as special purpose, in dedicated and permanently configured circuitry, or as general purpose (e.g., configured by software) may be driven by cost and time considerations.

Accordingly, the term “processor” or equivalents should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering embodiments in which the processor is temporarily configured (e.g., programmed), each of the processors need not be configured or instantiated at any one instance in time. For example, where the processor comprises a general-purpose processor configured using software, the general-purpose processor may be configured as respective different processors at different times. Software may accordingly configure the processor to constitute a particular hardware configuration at one instance of time and to constitute a different hardware configuration at a different instance of time.

Although the disclosure has been described with reference to the embodiments illustrated in the attached figures, it is noted that equivalents may be employed, and substitutions made herein, without departing from the scope of the disclosure as recited in the claims.

Having thus described various embodiments of the disclosure, what is claimed as new and desired to be protected by Letters Patent includes the following: