Patent Grant
10504116
This application is a U.S. National Stage filing under 35 U.S.C. § 119, based on and claiming benefits of and priority to GB Provisional Patent Application No. 1516617.6 filed Sep. 18, 2015.
The present disclosure relates to verification for payment transactions and particularly for verification associated with the use of payment devices.
In payment transactions using a payment device (e.g. a contact integrated circuit card, a contactless integrated circuit card or a mobile device with a digital wallet), authorisation and consent are used to secure payment transactions. Authorisation ensures that a payment device is permitted to perform a payment transaction, and this is typically carried out by checking with an issuer of a payment device. For example, authorisation may be revoked by the issuer if the payment device is reported as lost or stolen by a user.
Consent ensures that a user of a payment device agrees to the payment device being used in a particular payment transaction. For example, in a ‘chip-and-PIN’ payment transaction using an integrated circuit card as the payment device, as the user of the payment device verifies their identity by providing their PIN on a Point of Interaction (POI, e.g. a payment transaction terminal) once the payment device is connected to the POI, consent from the user is implied.
The combination of authorisation and consent means that a fraudulent user cannot perform contactless pick-pocketing, eavesdropping attacks or perform two consecutive transactions while the user of the payment device only intended to perform one.
Typically, contactless payment transaction employ an upper limit to the value of the payment transaction is imposed unless a Cardholder Verification Method (CVM) is used. This provides speed and convenience to users as they do not have to undertake a verification method.
Consumer Device Cardholder Verification Methods (CDCVMs) are increasingly being used for payment devices comprising a mobile device with a digital wallet. The use of CDCVMs generally allows the value of a payment transaction to be increased due to the security provided by verification. CDCVMs involve a user of the payment device verifying their identity on the payment device itself. During a payment transaction using CDCVM, no additional customer action is required on the POI or paper receipt to verify the customer, such as a signature or PIN. For example, the mobile device may be arranged to receive a PIN and/or comprise a biometric sensor for verifying the identity of a user. The payment device can then be used with a POI to undertake a payment transaction.
It is an aim of the present disclosure to address disadvantages associated with the prior art.
In one aspect, the disclosure provides a method for providing user authentication and user consent for a transaction made with a payment device, comprising a user authentication step to verify that a user is entitled to use the payment device and a user consent step to verify that the user consents to the transaction, wherein the user authentication step is discrete from the user consent step. The user authentication step may comprise a consumer device cardholder verification method (CDCVM). This user authentication step may be taken outside a transaction context, but may persist into a transaction context. The user consent step may be an explicit user consent made within a transaction process. The user consent may in embodiments be an implicit user consent inferred from user or device actions or user or device context. In another aspect, apparatus adapted to perform the methods described above are also provided.
Within the scope of this application it is expressly intended that the various aspects, embodiments, examples and alternatives set out in the preceding paragraphs, in the claims and/or in the following description and drawings, and in particular the individual features thereof, may be taken independently or in any combination. That is, all embodiments and/or features of any embodiment can be combined in any way and/or combination, unless such features are incompatible. The applicant reserves the right to change any originally filed claim or file any new claim accordingly, including the right to amend any originally filed claim to depend from and/or incorporate any feature of any other claim although not originally claimed in that manner.
One or more embodiments of the disclosure will now be described in detail by way of example only, with reference to the remaining drawings, in which:
CDCVM schemes for contactless payment transactions may involve Instant CDCVM, Prolonged CDCVM or Persistent CDCVM. Instant CDCVM is verification that occurs in the context of a specific payment transaction.
Prolonged CDCVM is a verification mechanism carried out in a context different from a payment transaction, and may precede the actual payment transaction. For example, if the payment device uses a passcode to unlock other functionality such as email access, a user verification performed at the time of accessing emails on the payment device may be re-used (within a predetermined time limit) to deliver verification as part of a payment transaction without requiring the user to provide verification again.
Persistent CDCVM involves an initial user verification on the payment device, after which the payment device can be used in subsequent payment transactions without requiring specific user verification for each transaction. Typically, a payment device used for Persistent CDCVM maintains the verification status until a change occurs to the payment device. For example a smart watch monitoring the pulse of a user can be used to keep a CVM persistent after a first verification. In the event that the smart watch is removed from the user, the verification ceases to be valid until another successful verification is performed.
The Consent is defined as any action or series of events indicating that the person holding the device agrees to the payment transaction. Consent can be expressed explicitly through an action performed within context of a payment transaction or implicitly by a series of events and actions performed prior to or during the payment transaction. In case of the latter, it is the combination and the sequence of events and actions that indicates Consent (rather than each event or action on its own) as such sequence or combination is very unlikely to happen if the user were not to consent to the transaction
When using an Instant CDCVM for user verification, Consent is automatically performed (i.e. explicitly given) as the user has to interact with the payment device or with a payment consumer device to capture authentication and consent.
Currently, explicit Consent must be given from a user in the form of CDCVM when using a digital wallet on a mobile device as a payment device. Explicit Consent relies on one-for-all validation mechanisms such as pressing a button, providing the value of a secret, or making a gesture (such as screen unlock). A disadvantage of explicit Consent is that it requires a payment application to be open before validation mechanisms can be entered.
In some cases, payment applications are opened at the time that the transaction is performed—for instance by tapping the phone on the terminal. If then the user has to push a button or make a gesture before the transaction can complete, it means that the transaction in progress would need to be interrupted to let the user provide the explicit Consent before continuing the transaction—resulting in a two tap scenario, with the explicit Consent given between the first tap and the second tap when performing a contactless transaction.
As result of the technical constraints of the acceptance environment (for example when using a point of sale terminal not supporting the concept of dual tap), a merchant will have to restart the transaction after the decline at the first tap. This can be seen as a blocking factor for deployment of mobile payment solutions using explicit Consent for low or high value transactions when prolonged or persistent CDCVM is used. A similar problem occurs in remote payment processes, for example cloud-based payments.
Embodiments of the present disclosure provide a digital wallet arranged to determine whether a user has implicitly provided Consent to undertake a payment transaction. The determination is made based on context that may not be directly related to the payment application and correlation of different events, bypassing the need for any additional user action (or interaction) with the digital wallet as would be required for explicit Consent discussed by way of background.
The consent risk manager module 106 is arranged to determine whether or not implicit consent of a user is given to undertake a payment transaction, as described below in greater detail with reference to
The digital wallet module 102 makes use of available information from the user behaviour and their interaction with the payment device 100 or from the payment device 100 itself, for example by creating a specific order of events, in order to determine that the user has explicitly performed an action that is consistent with the intent to pay prior to the actual payment. If this action provides sufficient evidence to assume consent, then it is rated as a satisfactory condition to report that consent was provided to a payment application in the payment application module 110, avoiding the need for the payment application to seek explicit consent from the user.
The decision module 124 is arranged to process input information 148 available from the payment device 100 including:
User actions and behavioural information 150 comprises one or more of:
Transaction context information 152 is information associated with a payment transaction for which implicit Consent is being determined by the consent risk manager module 106.
Payment device information 154 comprises one or more of:
Terminal data 156 comprises one or more of:
Environment information 158 comprises one or more of:
Proprietary check data 160 includes information determined from the outcome of proprietary checks. For example, proprietary checks may be defined to answer some specific needs linked with the delivery of a digital wallet associated with a given merchant brand (such as digital wallet from shop ABC/retailer XYZ).
When the decision module 124 outputs that implicit Consent is granted, then the payment transaction can be completed without an additional interaction from the user (this is separate to the conditions of authentication being satisfied). In the event that implicit Consent cannot be granted by the decision module 124, explicit Consent would be obtained using CDCVM on the payment device 100.
CDCVM data is used to carry information about user consent and user authentication to the Issuer Authorization System (or Transaction Management System). CDCVM applies both to remote and contactless Payments. CDCVM data is carried using two bytes (Byte1 or B1, Byte 2 or B2) in a contactless EMV solution (EMV specifications may be found at emvco.com/specifications.aspx) and for Digital Secure Remote Payment (DSRP). This CDCVM data may also be used for generation of the cryptogram in EMV transaction protocols. An exemplary composition of CDCVM data is described in detail below, as is also a Mag Stripe based solution. For a Mag Stripe solution there is only one digit available for CDCVM data so a codebook solution is used—this is also described in detail below.
In the CDCVM data according to embodiments of the disclosure, not only the nature of the CVM and the existence (and nature) of consent is provided, but also the strengths of the CDCVM method, of the control on prolonged or persistent consent, and of the consent method. These strengths may be rated by the transaction scheme provider or by the card issuer.
CDCVM data according to this approach may be considered to have three layers: CDCVM method, CDCVM quality and CDCVM integrity. Methods may include PIN, password, pattern, biometrics (fingerprint, iris, face) or combinations of methods (typically “something you are” and “something you know”). Quality may relate to number of digits of a PIN, number of characters of a password (and requirements for character types), number of dots or complexity of a pattern and false acceptance rate of a biometric.
In considering integrity, both the component C used to capture the CDCVM and the component A being the application using the outcome of CDCVM validation need to be considered. Of significance here is whether a Trusted User Input is employed to provide a cryptographic security mechanism to assure the validity of the process—this needs to be supported by the operating system of the device.
The embodiments described here identify ratings as undefined, weak, medium or strong, but do not provide a specific mapping of values for the qualities discussed above on to ratings—this will typically be determined by a card issuer according to the card issuer's own security model. This applies to the CDCVM method, and also applies to the control of Prolonged or Persistent CDCVM.
CDCVM may not always be required for a low value transaction (LVT)—for example, when a card-like model is used for the payment application on the device. Consent is used to ensure that the holder of the device agrees to the current transaction.
In the absence of Prolonged CDCVM and Persistent CDCVM, data collected from the card by a fraudster could only qualify for Low Value Transactions—unless the fraudster can persuade the user to authenticate using instant CDCVM. However, if the payment application is using a Prolonged CDCVM or a Persistent CDCVM, data collected fraudulently could be used for High Value Transactions as well. In that case the Consent is the gatekeeper to ensure that the holder of the device agrees to a high value transaction.
As noted above, Consent may be explicit or implicit (for example, contextually derived)—this should be communicated with the CDCVM. It is possible to improve the quality of the information with the delivery of a rating of the consent. That way without delivering proprietary information about the methods used to deliver the implicit consent, it would be possible for the Issuer to qualify the transaction. Consequently it is desirable also to give a rating for the consent. It is also desirable to determine and convey whether the CDCVM was captured on the same device as used to provide the consent.
Explicit Consent is the standard approach to provision of consent. Such approaches rely on a standard mechanism such as pressing a button, providing the value of a secret (essentially an authentication) or making a gesture (such as screen unlock). Any of these mechanisms are captured and processed by the payment application. They are applied systematically and they do not rely on additional context information—for instance the fact that the user opened their wallet and selected a card within the last few seconds.
The basic idea of implicit Consent is to let the wallet on the payment device determine that the Consent was actually provided based on context that may not be directly related to the payment application and correlation of different events, bypassing the need for an additional user action that needs to be entered in the wallet application. This may be achieved by a Consent Risk Manager, as described above and illustrated in
Preferably, CDCVM and Consent information using a defined set of codes and values that are agnostic of the technology used to obtain the CDCVM and Consent information. An exemplary approach is set out in more detail below. In using a Wallet on a device to provide such information, it is preferable for this information to be secured, such as by inclusion in the cryptogram used in the transaction process (AC for an EMV based solution, CVC3 for a Mag Stripe based solution).
Where such information is carried as part of the transaction, the following principles may be employed:
EMV and Mag Stripe solutions will now be described in more detail.
In the EMV solution, the following information can be carried.
In working according to EMV specifications, field DE55 or DE48 could be used—in using DE55, for example, the CDCVM data could be added to the Issuer Application Data (IAD) in carrying information as part of the transaction data.
The CDCVM data is a 2-byte field. The first byte may be represented as shown in Table 1 below, whereas the second byte may be provided as shown in Table 2. Note that these tables also contain information about the input to be used to determine the value of the CDCVM Codebook described in detail below in relation to the Mag Stripe based solution.
The value of CDCVM B2 b5 may be set by the Wallet according to the use cases set out below in Table 3.
The Mag Stripe solution will now be described in detail. As the Mag Stripe based solution is much more constrained, it is not possible to carry 2 bytes of information. An approach that can be employed is to assign one digit in the track data and use it to carry one value taken from a codebook of ten values. An exemplary codebook is set out in Table 4 below.
Using a new subelement to the DE48 field (DE48 SE28), CDCVM Data or CDCVM Codebook information can be delivered as part of the transaction as a series of codes or values agnostic of the technical details required to carry the information. The information can be presented in a readily interpretable format for the user using a series of subfields as below:
An exemplary format for each subfield is set out below.
Subfield 1—Type of Consent
This is an area in which the information provided by the CDCVM Codebook may be more limited than in an EMV solution. There are three possible values of Type of Consent:
A translation table is provided as Table 5 below:
Subfield 2—Rating of Consent Method
This information may not be provided in the CDCVM Codebook solution. There are five possible values for Rating of Consent Method:
Table 6 below is a translation table for Rating of Consent Method.
Subfield 3—Security Level
This subfield is used to report the security level—integrity—of the CDCVM and Consent information. Three values are possible for this subfield:
Table 7 below is a translation table for Security Level
Subfield 4—CDCVM Method Category
This subfield is relevant both to EMV and Mag Stripe approaches. Four values are possible for this subfield:
Table 8 below is a translation table for CDCVM Method Category
Subfield 5—CDCVM Method
This subfield is relevant both to EMV and Mag Stripe approaches, but only limited information may be provided in the Mag Stripe approach. The following values may be provided
Table 9 below is a translation table for CDCVM Method
Subfield 6—Type of CDCVM
This subfield is relevant both to EMV and Mag Stripe approaches, but only limited information may be provided in the Mag Stripe approach. There are six possible values.
Table 10 below is a translation table for Type of CDCVM
Subfield 7-TUI Information
This subfield is relevant both to EMV and Mag Stripe approaches, but only limited information may be provided in the Mag Stripe approach. There are six possible values.
Table 11 below is a translation table for TUI Information 5
Subfield 8—Rating of CDCVM Method
This subfield may not be provided in the Mag Stripe approach. There are six possible values.
Table 12 below is a translation table for Rating of CDCVM Method
Subfield 9—Rating of the Control on Prolonged/Persistent CDCVM
This subfield may not be provided in the Mag Stripe approach. There are seven possible values.
Table 13 below is a translation table for Rating of the control on Prolonged/Persistent CDCVM
Subfield 10—Capture of CDCVM and Consent
This subfield may not be provided in the Mag Stripe approach. There are three possible values.
Table 14 below is a translation table for Capture of CDCVM and Consent
Adaptation of existing Mag Stripe implementation to deliver the additional information in the CDCVM Codebook will now be described with reference to
Mag Stripe data is encoded according to a bitmap. The PAN (Primary Account Number) may be extended from a conventional 16 digit PAN up to 19 digits allow additional information to be conveyed through the Mag Stripe Model. Management of track data is described below so as to minimise impact on the authorization system while using one common model to deliver the Application Transaction Counter (ATC) of 2 digits, the cryptogram (CVC3) of 3 digits, the Unpredictable Number (UN) of three digits, and the 1 digit nUN value (all these terms are described further in EMV specifications referenced above).
The general principles of bitmap management according to this embodiment are as follows:
The following information is carried:
Full bitmaps are not shown here, but may be derived as needed by the person skilled in the art using these principles. The five steps required to support an end-to-end contactless Mag Stripe transaction flow using a cloud-based payment system using a single cryptogram (AES) are shown below with reference to
Many modifications may be made to the above examples without departing from the scope of the present disclosure.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1516617.6 | Sep 2015 | GB | national |
| Number | Name | Date | Kind |
|---|---|---|---|
| 7801825 | Kranzley | Sep 2010 | B2 |
| 9355393 | Purves | May 2016 | B2 |
| 10185958 | Henderson | Jan 2019 | B2 |
| 20110112920 | Mestre | May 2011 | A1 |
| 20130197998 | Buhrmann | Aug 2013 | A1 |
| 20130227651 | Schultz | Aug 2013 | A1 |
| 20140101036 | Phillips | Apr 2014 | A1 |
| 20140156531 | Poon | Jun 2014 | A1 |
| 20140250016 | Kranzley | Sep 2014 | A1 |
| 20140289822 | Wilson | Sep 2014 | A1 |
| 20150178724 | Ngo et al. | Jun 2015 | A1 |
| 20150186864 | Jones | Jul 2015 | A1 |
| 20150339664 | Wong | Nov 2015 | A1 |
| Number | Date | Country |
|---|---|---|
| 2011239307 | Nov 2011 | AU |
| 2522929 | Aug 2015 | GB |
| Entry |
|---|
| Ram Pratap Sharma and Gyanendra K. Verma, “Human Computer Interaction using Hand Gesture,” Elsevier, Procedia Computer Science, (Year: 2015). |
| Anonymous, “How EMV Credit Card Technology Provides Increased Security,” level 10, www.leve110.com (Year: 2015). |
| Wikipedia, “Apple Pay,” (2013) (Year: 2013). |
| PCT Search Report and Written Opinion for PCT/US2016/051880 dated Nov. 7, 2016, 12 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20170083915 A1 | Mar 2017 | US |
