Patent Application
20170103396
It is increasingly common for consumers to make purchases using devices such as mobile phones or the like. These remote purchase transactions pose challenges to financial institutions and other entities. For example, these transactions present challenges related to the authentication of users and other fraud related matters. A number of approaches have been proposed to improve user authentication and to reduce fraud in remote transactions. For example, one desirable approach is to utilize the authentication and security features provided by the EMV Standards (at www.emvco.com) in remote transactions. However, not all online or remote merchant systems support these standards. It would be desirable to provide systems and methods that allow remote transactions from a browser, on mobile devices, in-application or the like to provide a good user experience while reducing fraud.
Features and advantages of some embodiments of the present invention, and the manner in which the same are accomplished, will become more readily apparent upon consideration of the following detailed description of the invention taken in conjunction with the accompanying drawings, which illustrate preferred and exemplary embodiments and which are not necessarily drawn to scale, wherein:
Embodiments of the present invention provide systems, methods, apparatus and computer programming code for operating a device to complete a transaction. Embodiments are described herein which include receiving a request to initiate a transaction with a merchant, transmitting a payment transaction initiation message to a merchant server associated with the merchant, receiving a request message from the merchant server for remote payment data, the request message including information identifying whether the merchant server supports a selected one of a first data format and an alternative data format, and providing the remote payment data to the merchant server in the selected data format for use by the merchant server to initiate authorization processing of the transaction.
As shown, the system 100 further includes a merchant server 106 in communication with the mobile device 102. Although only a single mobile device 102 and merchant server 106 are depicted, the system 100 likely involves a multitude of both devices. For example, a number of consumers operating a number of mobile devices 102 may interact with a variety of different merchants operating merchant servers 106 to facilitate transactions pursuant to the present invention. An interaction between a mobile device 102 and a merchant server 106 may be, for example, a wireless interaction over a network interface. For example, a mobile device 102 may interact with a merchant server 106 to conduct a purchase transaction over a mobile telephone communication network using a protocol such as HTTP (HyperText Transfer Protocol) or the like. In some embodiments, the communication between the mobile device 102 and the merchant server 106 may be facilitated or controlled via a mobile application installed on the mobile device 102 (e.g., such as, for example, a merchant application on the mobile device).
Pursuant to some embodiments, the mobile device 102 may conduct transactions with the merchant server 106 from a browser on the mobile device 102 or from an application on the mobile device 102 which interacts with a payment server 104 (which may also be referred to herein as a “wallet server”). The mobile device 102 may store information associated with one or more payment wallets which correspond to one or more wallets on the wallet server. Pursuant to some embodiments, transactions are processed using a secure payment protocol which may be referred to herein as “Digital Secure Remote Payment” (DSRP) which provides improved fraud prevention (which, in some embodiments, may allow reduced fraud liability for the merchant). As will be described, embodiments provide a number of benefits including, for example, a better user experience for users conducting transactions using a mobile device 102, a variety of mobile specific use-cases (such as in-aisle shopping or the like), a potential liability shift (from the merchant and user perspective), and improved user authentication.
Features of transactions pursuant to some embodiments will now be described by reference to the components of
As a specific example, the first data format may be a data format that supports a full data cryptogram pursuant to the EMV standards (available at http://www.emvco.com the contents of which are hereby incorporated by reference in their entirety for all purposes). If the merchant server 106 indicates it supports the first data format, in some embodiments, the merchant server 106 is capable of receiving an EMV Authorization Request Cryptogram (ARQC) returned in Data Element 55 (“DE 55”) of the EMV Integrated Circuit Card (ICC) System-Related Data, and is generated using the full set of inputs for the ARQC generation pursuant to the EMV standards. If the merchant server 106 is capable of receiving a message in the first data format, the cryptogram may be validated using a standard EMV authorization host system.
If the merchant server 106 does not support messages in the first data format, it will support messages in an alternative data format. For example, in some embodiments, a different data format (e.g., an “alternative data format”, “second data format” or a “third data format”) may be used for transactions where some counter information needs to be carried as part of the authorization transaction. In this case, the ARQC is generated using a partial set of the inputs that are available. That is, some fields are set to default values rather than values specific to the transaction. The ARQC and associated EMV data is compressed (for example, static values based on the defaults are removed and a bit map coding may be used) and packaged in a standard message field such as the “UCAF” field. In order to validate the cryptogram, the value in the UCAF (or other standard message field) must be converted back into a first data format (e.g., the DE 55 format) by adding the default and the static values. This may be performed as a pre-processing step by the issuer authorizing the transaction or by a stand in processing entity. The converted value may then be validated by a standard authorization host system (e.g., such as the issuer or a stand in entity).
In some embodiments, if the merchant server 106 does not support messages in the first data format, it may support messages in a different data format (e.g., an “alternative data format, a “second data format’ or a “third data format”). For example, an alternative data format may be used in transactions which require, or benefit from, the inclusion of additional information about user consent and user authentication to the authorization system.
In this manner, embodiments allow transactions to be performed between a mobile device 102 and different merchant servers 106, including merchant servers 106 that are not capable or configured to receive full EMV format messages. As a result, merchant servers 106 which are only capable of or configured to process normal payment transactions can enjoy the benefit of increased fraud protection of EMV in remote payment transactions.
Depending on the nature of the response from the merchant server 106 (regarding whether it supports a first data format or an alternative data format), the mobile device 102 generates remote payment data for transmission to the merchant server 106 to process the transaction. Details of the generation of the remote payment data will be provided below in conjunction with
For example, if the merchant server 106 supported the first data format, the remote payment data received from the mobile device 102 is contained in a standard EMV ARQC in Data Element 55 of a remote payment message, and the system will process the transaction using standard EMV processing to validate the ARQC. However, if the merchant server 106 did not support (or was not configured to support) the first data format, the remote payment message is received in the alternative data format and the ARQC is generated from a partial set of the inputs available, and the ARQC and associated EMV data is compressed (for example, static values based on the defaults are removed and a bit map coding may be used) and received by the merchant server 106 in a standard payment transaction message field such as the “UCAF” field. In such embodiments the system rebuilds or reconstructs a DE 55 field from the received data. This rebuilding is performed before performing its regular mapping processing. The rebuilding may consist of a process such as: (1) adding a tag length to the data received from the UCAF field, (2) adding the defaulted data to the reconstructed DE 55 field, and (3) extracting the payment account number (“PAN”) from the payment transaction message (e.g., by retrieving it from a standard transaction message field such as DE2) and adding it to the reconstructed DE 55 field in field “5A” (the EMV “Application Primary Account Number (PAN)” field) as well as in field “5F34” (the EMV “Application Primary Account Number (PAN) Sequence Number” field). In this way, merchant servers 106 that do not (or are not configured to) process standard EMV messages may be adapted to process such messages.
A computer 110 operated by an acquirer (acquiring financial institution) is also shown as part of the system 100 in
The payment network may be entirely or substantially conventional; one example of a suitable payment network is the well-known Banknet system operated by MasterCard International Incorporated, which is the assignee hereof.
The systems or computers operated by or on behalf of the issuer of the payment card used in the transaction may be conventional and may be operated by or on behalf of a financial institution (“FI”; not separately shown) that issues payment card accounts to individual users. For example, the systems or computers operated by or on behalf of the payment card issuer may perform conventional functions, such as (a) receiving and responding to requests for authorization of payment card account transactions to be charged to payment card accounts issued by the FI; and (b) tracking and storing transactions and maintaining account records.
The components of the system 100 as depicted in
It should also be understood that the mobile device 102 is operable as a conventional mobile telephone for communication—both voice and data—over a conventional mobile telecommunications network, which is not depicted in the drawing. Thus, the mobile device 102 may be in communication from time to time in a conventional manner with a mobile network operator (“MNO”—also not shown). An over-the air communication channel (not shown in
The mobile device 102 may include a conventional housing (indicated by dashed line 202 in
The mobile device 102 further includes conventional control circuitry 204, for controlling over-all operation of the mobile device 102. For example, the control circuitry 204 may include a conventional processor of the type designed to be the “brains” of a mobile device.
Other components of the mobile device 102, which are in communication with and/or controlled by the control circuitry 204, include: (a) one or more memory devices 206 (e.g., program and working memory, etc.); (b) a conventional SIM (subscriber identification module) card 208; (c) a conventional touchscreen 212 which serves as the primary input/output device for the mobile device 102, and which thus receives input information from the user and displays output information to the user. As is the case with many models of mobile device, in some embodiments the mobile device 102 may also include a few physically-actuatable switches/controls (not shown), such as an on/off/reset switch, a menu button, a “back” button, a volume control switch, etc. It may also be the case that the smartphone includes a conventional digital camera, which is not shown.
The mobile device 102 also includes conventional receive/transmit circuitry 216 that is also in communication with and/or controlled by the control circuitry 204. The receive/transmit circuitry 216 is coupled to an antenna 218 and provides the communication channel(s) by which the mobile device 102 communicates via the mobile telephone communication network (not shown). The receive/transmit circuitry 216 may operate both to receive and transmit voice signals, in addition to performing data communication functions.
The mobile device 102 further includes a conventional microphone 220, coupled to the receive/transmit circuitry 216. Of course, the microphone 220 is for receiving voice input from the user. In addition, a loudspeaker 222 is included to provide sound output to the user, and is coupled to the receive/transmit circuitry 216.
The receive/transmit circuitry 216 may operate in a conventional fashion to transmit, via the antenna 218, voice signals generated by the microphone 220, and to reproduce, via the loudspeaker 222, voice signals received via the antenna 218. The receive/transmit circuitry 216 may also handle transmission and reception of text messages and other data communications via the antenna 218.
The mobile device 102 may also include circuitry 224 that is partly or wholly dedicated to implementing the NFC communications circuitry functionality of the mobile device 102. The mobile device 102 may further include a loop antenna 226, coupled to the NFC circuitry 224. In some embodiments, the NFC circuitry 224 may partially overlap with the control circuitry 204 for the mobile device 102. Moreover, the payment circuitry is associated with, and may also overlap with, a secure element 228 that is part of the mobile device 102 and is contained within the housing 202, or the NFC circuitry could be omitted in embodiments that do not utilize NFC. The term “secure element” is well known to those who are skilled in the art, and typically refers to a device that may include a small processor and volatile and nonvolatile memory (not separately shown) that are secured from tampering and/or reprogramming by suitable measures.
Further details relating to the secure element 228, and particularly relating to the programming thereof, will be described below with reference to
In accordance with aspects of the present invention, the secure element 228 has stored therein a plurality of mobile payment cardlets (payment card applications) 306. Although only a single mobile payment cardlet 306 is explicitly shown in
As shown in
Pursuant to some embodiments, the cardlets may be personalized such that additional data may be returned in a response to a merchant transaction. For example, the Application PAN and Application PAN sequence number may be personalized such that they can be returned in a command response message.
Once the transaction is initiated, processing continues at 40 where the mobile device 102 (e.g., under control of the merchant applet 310, the payment applet 312 and/or the client applet 308) transmits a payment transaction initiation request message to a merchant server 106 associated with the merchant with whom the transaction is to be conducted. The payment transaction initiation request message may be transmitted over a network connection between the mobile device 102 and the merchant server 106.
Processing continues at 406 where the mobile device 102 receives information identifying a data format supported by the merchant server 106. For example, the merchant server 106 may indicate to the mobile device 102 whether it supports a first data format or an alternative data format for the transaction. In some embodiments, merchant servers 106 may support full EMV style transactions (e.g., as used herein, the “first data format” in which the mobile device is to transmit a cryptogram to the merchant server 106 in the full EMV format). In some embodiments, merchant servers 106 may not support full EMV style transactions (e.g., as used herein, the “alternative data format” in which the mobile device is to provide information allowing an entity to generate a cryptogram using a partial set of inputs and the message is not provided in the full EMV format). In some embodiments, the alternative data format may also be used to provide cardholder verification results. For example, as shown in Table 2, below, the alternative “Format 1” may provide cardholder verification result data in a data object labeled “Card Verification Results” computed using a script or PIN counter.
Once the mobile device 102 has received information indicating which data format is supported by the merchant server 106, processing continues at 408 where the mobile device 102 operates to provide remote payment data to the merchant server 106 in the supported data format.
If the merchant server 106 supports the first data format, the software of the mobile device 102 will be operated to provide remote payment data to the merchant server 106 using a cryptogram (such as the EMV Authentication Request Cryptogram (“ARQC”)) in the full EMV data format in Data Element 55 (as specified in the EMV specifications). The cryptogram may then be used by the merchant server 106 (and/or the payment gateway 108, the acquirer 110 or the issuer systems) to be validated using a standard EMV authorization host system.
If the merchant server 106 does not support the first data format (and, instead, supports an alternative data format), the cryptogram will be generated using a partial set of input data from the selected payment cardlet 306. In one specific illustrative example, the table below illustrates the data the payment cardlet 306 will provide as input to the remote payment cryptogram depending on whether the merchant server supports the first data format or an alternative data format.
As shown in Table 1, when the merchant server 106 supports the second data format, some of the data used to generate the remote payment cryptogram is defaulted to zero, while the data used to generate the remote payment cryptogram for the first data format takes the value from the input data (e.g., from the cardlet or the payment applet) or uses a value personalized in the secure element.
As shown in Table 2 and Table 4 (below), a number of different alternative data formats may be provided. For example, “Alt Format 0” may be used for transactions involving mobile devices with a secure element or for MCBP transactions. “Alt Format 1” may be used for transactions involving mobile devices with a secure element where counter information has to be carried as part of the authorization transaction. “Alt Format 2” may be used for transactions involving MCBP transactions which also benefit from, or require information about user consent or user authentication (referred to as “CDCVM” data) to the issuer or payment network.
In some embodiments, when the merchant server 106 supports data in the first data format, the remote payment data is returned to the merchant server 106 in an ISO “format 2” response and the data object returned in the response message is a constructed data object with a tag equal to “ABC”. The value field contains several Basic Encoding Rules tag, length, value (“BER-TLV”) coded data objects. For example, the content of the “ABC” part of the input to the transaction for a first data element transaction is shown below in Table 2.
In some embodiments, when the merchant server 106 supports data in an alternative data format, the remote payment data is returned to the merchant server 106 in the equivalent of an ISO “format 1” response and the data object returned in the response message is a primitive data object with tag equal to “DEF”. The value field consists of the concatenation without delimiters (tag and length) of the value fields of the data objects as shown below in Table 3. Pursuant to some embodiments, the Application Cryptogram field of Table 3 may be used to store one or two cryptograms. For example, in some embodiments, an implementation associated with a secure element which requires one cryptogram may be supported as well as implementations which use one or two cryptograms (such as implementations without secure elements such as a cloud based payments system).
Pursuant to some embodiments, in the case that the merchant server 106 supports an alternative data format, the ARQC is generated using a partial set of the inputs available (as shown in Table 1 above). The ARQC and associated EMV data is compressed and packaged in a field of a standard ISO payment authorization request message (e.g., in the UCAF field). The data is provided the merchant server 106 for processing. In some embodiments, the merchant server 106 generates an authorization request for transmission to the payment network as follows. The authorization request is submitted with the “Point of Service Entry Mode” (DE 22 SF1) set to “81” (indicating an entry mode of “e-commerce including chip”). The e-commerce indicators are set to: (1) Subfield 1 (Electronic Commerce Security Level Indicator and UCAF Collection Indicator) is set to a value of “212” with the following values (i) Position 1 (Security Protocol) set to “2” (“channel”), (ii) Position 2 (Cardholder Authentication) is set to “1” (cardholder certificate not used), (iii) Position 3 (UCAF Collection Indicator) is set to “2” (UCAF data collection is supported by the merchant, and UCAF data must be present), (2) the cryptogram is contained in the DE 48 SE 43 field (also known as the UCAF field).
Continuing the description of processing of an alternative data format transaction, once the remote payment data is generated by the cardlets and applets of the mobile device 102, the data is transmitted to the merchant applet 310 for transmission to the merchant server 106. The merchant server 106 (possibly via a merchant payment gateway) packages the remote payment data in an authorization request for transmission to an acquirer 110. The authorization request, response and clearing will be processed between the merchant server 106 (or gateway 108), the payment server 104, and the issuer. These transactions are mapped by the payment server. For an alternative data format transaction, the payment server (or other entity) rebuilds the alternative data format message into a first data format message. The rebuilding may consist of adding a tag length to the data received in the UCAF field, adding the defaulted data (of Table 1) to recreate a first data format message, and extracting the PAN from the message and adding it to the first data format (as item ‘5A’ and item ‘5F34’ of Table 2). In this way, a merchant that supports only an alternative data format can enjoy the benefits of transactions conducted using the first data format.
Aspects of the invention have been described above in the context of a mobile device such as a mobile telephone. However, the principles of the present invention are equally applicable to other types of devices, including tablet computers, or other computing devices.
As used herein and in the appended claims, the term “computer” should be understood to encompass a single computer or two or more computers in communication with each other.
As used herein and in the appended claims, the term “processor” should be understood to encompass a single processor or two or more processors in communication with each other.
As used herein and in the appended claims, the term “memory” should be understood to encompass a single memory or storage device or two or more memories or storage devices.
The flow charts and descriptions thereof herein should not be understood to prescribe a fixed order of performing the method steps described therein. Rather the method steps may be performed in any order that is practicable.
As used herein and in the appended claims, the term “payment card account” or “payment device” includes a credit card account or a deposit account that the account holder may access using a debit card. The term “payment card account number” includes a number that identifies a payment card system account or a number carried by a payment card, or a number that is used to route a transaction in a payment system that handles debit card and/or credit card transactions. The term “payment card” includes a credit card or a debit card or other payment device.
As used herein and in the appended claims, the term “payment card system” refers to a system for handling purchase transactions and related transactions. An example of such a system is the one operated by MasterCard International Incorporated, the assignee of the present disclosure. In some embodiments, the term “payment card system” may be limited to systems in which member financial institutions issue payment card accounts to individuals, businesses and/or other organizations.
Although the present invention has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims.
