Patent Application
20200265420
This application claims priority to European Application Serial No. 19158096.8, filed Feb. 19, 2019, which is incorporated herein by reference in its entirety
The present disclosure relates to a secure remote payment mechanism. In particular, the disclosure relates to a payment mechanism which provides ease of use for consumers and security for all parties involved in a transaction.
Payment cards such as credit cards and debit cards are very widely used for all forms of financial transaction. A typical payment card now contains an integrated circuit (making it a “chip card” or “smart card”) which can be read by a smart card reader in a merchant POS (point of sale) terminal. Using this approach, a transaction is typically confirmed by a personal identification number (PIN) entered by the card user. Cards of this type typically operate under the EMV standard for interoperation of chip cards and associated apparatus (such as POS terminals and ATMs). ISO/IEC 7816 provides a standard for operation of cards of this type. Contactless payments are now possible between suitably enabled payment cards and merchant terminals by short range wireless technology using NFC protocols—under EMV, these are covered under the ISO/IEC 14443 standard. Payment cards and devices are provided under a transaction scheme (such as Mastercard, American Express or Visa) and the transaction mechanism is mediated by the transaction scheme infrastructure. EMV specifications relate to contact and contactless payment protocols and are publicly available at the EMVCo website (EMVCo is the industry body tasked with maintaining these specifications with the support of major transaction scheme providers)—https://www.emvco.com/document-search/— and would readily be consulted by the person skilled in the art. Terminology relating to EMV technology not expressly defined in this document is referenced and defined in EMV specifications, as will be appreciated by the person skilled in the art.
Increasingly, transactions are made in a digital domain. Contactless payments may for example be performed by a mobile phone running a mobile payment application and communicating with a POS terminal using the same protocols as a contactless card. It is therefore now appropriate to refer to a “payment device” rather than a “payment card” (when one term is used below, it should be understood to extend to the other—“payment card” will generally be used for convenience). It is increasingly common, however, to transact with payment cards online, for example at a merchant website. Transactions will then be fed into the transaction scheme by a payment service provider providing an internet gateway to the merchant.
Online transactions have generally been treated as “Cardholder Not Present” (CNP) transactions (other examples would be credit card payments made by telephone), which create security issues as a full EMV protocol contact or contactless interaction may not be available and there is no proximity between payment card and POS terminal to provide an additional measure of security. A normal approach to providing additional customer verification is to provide a card verification code printed on the card. Additional technologies have also been developed to improve security and efficiency of transactions carried out in the digital domain—particularly relevant are tokenisation and the 3D Secure standard.
One approach used for management of transactions in the digital domain is tokenisation. This is a process carried out by which the card number is tokenised—replaced by another number, which is used in its place in digital transactions. This provides additional security for the payment card, and enables digital transactions to be performed efficiently. Tokenisation is carried out by the transaction scheme or an appropriate service provider with the permission of the payment card issuer (the issuing bank with which the cardholder has an account). Tokenised transactions are routed in the transaction scheme so that the PAN (primary account number) associated with the tokenised card can be recovered from a digital vault allowing normal processing of the transaction. Tokenisation is typically used for mobile payment applications, but is often not used in online transactions between a cardholder using their own personal computer and a merchant website. 3-D Secure is a technology developed to provide an additional security layer for online transactions. It is based on a three domain model (issuer domain, acquirer domain and interoperability domain), the domains representing the issuer bank associated with the cardholder, the acquirer bank associated with the merchant, and the interoperability domain. Existing versions of the 3-D Secure protocols typically involve creation of an in-line window to the issuer domain enabling the cardholder to authenticate himself or herself to the issuer (if necessary) using elements of a password. This protocol is under active development to provide more effective authentication options and additional benefits to the participating parties, but at present can be inconvenient to users, particularly at the initial registration stage.
It is desirable to further develop existing protocols for online transaction to provide greater security and effectiveness without compromising ease of use for the user. This is challenging, as in order to provide more effective security measures, additional steps may be necessary which affect the user experience. This may be a disincentive to the user to register for and participate in more secure online protocols. The present disclosure has been devised to mitigate or overcome at least some of the above-mentioned problems.
According to a first aspect of the present disclosure there is provided a method of obtaining a digital product or service at a computing device, the computing device having installed thereon a service application for the digital product or service, the method comprising at the computing device: the service application obtaining a valid authentication from a user; the service application obtaining a request for the digital product or service from the user; the service application preparing a transaction authorisation request comprising a payment application cryptogram, the payment application cryptogram comprising a customer verification from the valid authentication of the user and transaction details for authorisation and settlement of a transaction for the digital product or service through a transaction processing system; and the service application providing the transaction authorisation request to the transaction processing system for authorisation and settlement.
In embodiments, the transaction authorisation request relates to a tokenised payment card, wherein tokenisation of the card has taken place in registration of the payment card with the service application.
The payment application cryptogram may comprise information to establish that a valid payment card was used by the user and that the valid authentication authenticated the user as cardholder of the payment card.
In embodiments, obtaining valid authentication from a user may comprise obtaining a user biometric.
The digital product or service may comprise access to a digital service, or may comprise delivery of digital content.
According to a second aspect, the disclosure provides a computing device comprising a processor and a memory, the computing device having a service application installed thereon, wherein the service application is adapted for provision of a digital product or service, wherein when installed the service application is adapted to: obtain a valid authentication from a user; obtain a request for the digital product or service from the user; prepare a transaction authorisation request comprising a payment application cryptogram, the payment application cryptogram comprising a customer verification from the valid authentication of the user and transaction details for authorisation and settlement of a transaction for the digital product or service through a transaction processing system; and provide the transaction authorisation request to the transaction processing system for authorisation and settlement.
Such a transaction authorisation request may relate to a tokenised payment card, wherein tokenisation of the card has taken place in registration of the payment card with the service application.
The payment application cryptogram may comprise information to establish that a valid payment card was used by the user and that the valid authentication authenticated the user as cardholder of the payment card.
The computing device may be adapted to receive a biometric input, and obtaining valid authentication from a user may comprise obtaining a user biometric. Such a biometric input may comprise a fingerprint reader.
The computing device may also have a payment application installed thereon. Such a computing device may have a digital wallet application installed thereon for use in management of the payment application and the service application.
This computing device may be a mobile telephone handset.
In a third aspect, the disclosure provides an information storage device having a service application stored thereon, wherein the service application is adapted when installed on a computing device to perform the method of the first aspect described above.
One or more embodiments of the disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:
General and specific embodiments of the disclosure will be described below with reference to the Figures.
Normally, card schemes—payment networks linked to payment cards—are based on one of two models: a three-party model or a four-party model (adopted by the present applicant). For the purposes of this document, the four-party model is described in further detail below.
The four-party model may be used as a basis for the transaction network. For each transaction, the model comprises four entity types: cardholder 110, merchant 120, issuer 130 and acquirer 140. In this model, the cardholder 110 purchases goods or services from the merchant 120. The issuer 130 is the bank or any other financial institution that issued the card to the cardholder 110. The acquirer 140 provides services for card processing to the merchant 120.
The model also comprises a central switch 150—interactions between the issuer 130 and the acquirer 140 are routed via the switch 150. The switch 150 enables a merchant 120 associated with one particular bank acquirer 140 to accept payment transactions from a cardholder 110 associated with a different bank issuer 130.
A typical transaction between the entities in the four-party model can be divided into two main stages: authorisation and settlement. The cardholder 110 initiates a purchase of a good or service from the merchant 120 using their card. Details of the card and the transaction are sent to the issuer 130 via the acquirer 140 and the switch 150 to authorise the transaction. The cardholder 110 may have provided verification information in the transaction, and in some circumstances may be required to undergo an additional verification process to verify their identity (such as 3-D Secure in the case of an online transaction). Once the additional verification process is complete the transaction is authorised.
On completion of the transaction between the cardholder 110 and the merchant 120, the transaction details are submitted by the merchant 120 to the acquirer 140 for settlement.
The transaction details are then routed to the relevant issuer 130 by the acquirer 140 via the switch 150. Upon receipt of these transaction details, the issuer 130 provides the settlement funds to the switch 150, which in turn forwards these funds to the merchant 120 via the acquirer 140.
Separately, the issuer 130 and the cardholder 110 settle the payment amount between them. In return, a service fee is paid to the acquirer 140 by the merchant 120 for each transaction, and an interchange fee is paid to the issuer 130 by the acquirer 140 in return for the settlement of funds.
In practical implementations of a four-party system model, the roles of a specific party may involve multiple elements acting together. This is typically the case in implementations that have developed beyond a contact-based interaction between a customer card and a merchant terminal to digital implementations using proxy or virtual cards on user computing devices such as a smart phone.
For a conventional transaction, a cardholder will use their payment card 6—or a mobile computing device such as smartphone 11 adapted for use as a contactless payment device—to transact with a POS terminal 7 of a merchant 2. However, in embodiments relevant to the present disclosure, the cardholder will use his or her computing device—which may be any or all of a cellular telephone handset, a tablet, a laptop, a static personal computer or any other suitable computing device (here alternative computing devices are shown—cellular telephone handset or smartphone 11 and laptop computer 10—and other computing devices such as a smart watch or other wearable device may also be used)—to act either as a proxy for a physical payment card 6 or as a virtual payment card operating only in a digital domain. The smartphone 11 may achieve this with a mobile payment application and a digital wallet, as described below. The smart phone 11 can use this to transact with a merchant POS terminal 7 using NFC or another contactless technology, or to make a payment in association with its wallet service as discussed below. However, online transactions with a merchant are of particular interest in connection with embodiments of the disclosure, rather than contact or contactless transactions with a merchant POS terminal 7. To make an online transaction, the smartphone 11 may also be able to interact with a merchant server 12 representing the merchant 2 over any appropriate network connection, such as the public internet—the connection to the merchant may be provided by an app or application on the computing device, as will be discussed below.
The transaction processing system (also here termed transaction scheme infrastructure, payment network or transaction infrastructure) 5 here provides not only the computing infrastructure necessary to operate the card scheme and provide routing of transactions and other messaging to parties such as the acquirer 3 and the issuer 4, but also a wallet service 17 to support a digital wallet on the cardholder computing device, and an internet gateway 18 to accept internet based transactions for processing by the transaction infrastructure. In other embodiments, the wallet service 17 may be provided similarly by a third party with an appropriate trust relationship with the transaction scheme provider. To support tokenisation, a token service provider 19 is present (again, this is shown as part of transaction infrastructure 5 but may be provided by a third party with appropriate trust relationships), and the transaction scheme infrastructure provides a digital enablement service 16 to support the performance of tokenised digital transactions, and to interact with other elements of the system to allow transactions to be performed correctly—this digital enablement service may include other elements, such as token service provision.
For a tokenised transaction, the transaction is validated in the transaction scheme by mapping the cardholder token to their card PAN, checking the status of the token (to ensure that it is in date and otherwise valid) and any customer verification approach used. This allows the issuer to authorise the transaction in the normal manner.
The Mastercard Digital Enablement Service (MDES) 42 performs a variety of functions to support mobile payments and digitized transactions. As indicated above, the MDES 42 is exemplary only, and is not essential to the disclosure—other embodiments may use digitisation, tokenisation and provisioning services associated with other transaction processing infrastructures, for example. The MDES 42 may be considered a part of the transaction processing system 5, though it is broken out as a separate element in
The Account Enablement System (AES) 43 is used in card digitisation and user establishment. It will interact with the mobile payment application (here through the wallet server 17) for card digitisation requests, and will populate the Token Vault 45 on tokenisation and will interact with the CMS 44 to establish a card profile with associated keys for digital use of the card.
The Credentials Management System (CMS) 44 supports management of cardholder credentials, and is a key system within the MDES 42. The core system 441 manages synchronisation with the transaction system as a whole through interaction with the TMS 46 and manages the channel to the AES 43. The dedicated system 442 provides delivery of necessary elements to the mobile payment application such as the digitized card and credentials and keys in the form needed for use. This system may also interact with the wallet server 17 for management of the mobile payment application.
The Token Vault 45—which is shown here as within the MDES 42, but which may be a separate element under separate control—is the repository for token information including the correspondence between a token and the associated card. In processing tokenised transactions, the MDES 42 will reference the Token Vault 45, and tokenisation of a card will result in creation of a new entry in the Token Vault 45.
Transaction Management System (TMS) 46 is used when processing tokenised transactions. If a transaction is identified by the transaction processing system 5 as being tokenised, it is routed to the TMS 46 which detokenises the transaction by using the Token Vault 45. The detokenised transaction is then routed to the issuer (here represented by Financial Authorisation System 47) for authorisation in the conventional manner. The TMS 46 also interacts with the CMS 44 to ensure synchronisation in relation to the cardholder account and credentials.
The service application obtains 410 a valid authentication from a user. In this case, the user is also a cardholder of a payment card, and the authentication action also serves as a cardholder verification action.
The service application obtains 420 a request for the digital product or service from the user. This may be at a checkout screen or in some other manner appropriate to the service application interface.
The service application prepares 430 a transaction authorisation request comprising a payment application cryptogram. In embodiments, this payment application cryptogram is provided in accordance with EMV specifications so that it can be processed directly by a transaction scheme operating in accordance with EMV specifications. The payment application cryptogram may here comprise a customer verification derived from the valid authentication of the user together with transaction details for authorisation and settlement of a transaction for the digital product or service through a transaction processing system.
The service application then provides 440 the transaction authorisation request to the transaction processing system for authorisation and settlement. Success or failure of the transaction will then be communicated back to the service application, which presents the results (and provides the digital product or service) to the user.
After this the relevant elements of a Mobile Payment SDK used in constructing a payment application are made available 620 to the merchant so that these can be built into the merchant app 630. Alternatively, relevant specification elements may be provided to the merchant under license to allow the merchant to build the relevant functionality into the merchant app. This provides the merchant app with the capability to create a cryptogram according to EMV standards. Such a Mobile Payment SDK is typically provided by a transaction scheme provider to payment application providers to allow payment applications to be constructed compliant with that transaction scheme (for example, for Mastercard Cloud-Based Payments applications through https://developer.mastercard.com/product/mobile-payments-sdk). In this case, the relevant elements of the Mobile Payment SDK are those which allows the mobile payment application to construct a Application Cryptogram for processing by the transaction scheme. Generation of an Application Cryptogram—such as an Authorization Request Cryptogram (ARQC) to request online approval of a transaction by an issuer—is fully defined under EMV specifications (in particular Book 3—EMV Book 3—Application Specification—version 4.3, which may be found at https://www.emvco.com/document-search/?action=search_documents&publish_date=&emvco_document_version=4-3&emvco_document_book=&px_search=). For the present applicant, this may be to allow Digital Secure Remote Payment (DSRP) transactions to be performed using the merchant app—this requires the ability to construct a remote payment transaction using EMV cryptograms. While this would normally only be possible with a mobile payment application (MPA), in embodiments according to the present disclosure this is achieved within a service application such as a merchant app by including EMV payment capability within the merchant app (in this embodiment by inclusion of relevant parts of the Mobile Payment SDK in the service application) with authentication of the cardholder when initiating a remote payment transaction.
This approach can be used in a number of practical contexts. A particularly significant one is purchase of mobile phone credit. In this case, the service application may be a mobile phone operator merchant application, and the user action may be used to purchase more phone credit. Another context may be the provision of gaming credit as a better-controlled alternative to existing approaches to in-app purchase. Another may be for direct purchase of digital content—such as music, films or books.
Many modifications may be made to the above examples without departing from the scope of the present disclosure as defined in the accompanying claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 19158096.8 | Feb 2019 | EP | regional |
