Mobile web browser authentication and checkout using contactless cards

Abstract

A merchant page in a browser may receive a selection of a first financial institution. The merchant page may generate a uniform resource identifier (URI) that is directed to the application. At least a portion of the URI may be registered in the mobile operating system to an application and a first financial institution. In response to receiving the selection of the URI, the mobile OS may launch an application that may authenticate credentials for the account. The application may associate the user ID parameter and the session ID parameter with the account and receive a password from the contactless card. The application may receive, from the server, an indication specifying that the server has validated the password. The OS may launch the browser, which may refresh the page. The refreshed page may include a virtual card number (VCN) in a first form field. Transactions may be processed based on the VCN.

Description

Background Art

[0001] Account identifiers for payment cards may include long numbers and / or strings. As a result, it may be difficult for a user to manually type the account identifier correctly. In practice, users often make mistakes and type an incorrect account number into a payment interface on a computing device. Additionally, processes have been developed that allow cameras or other malicious entities to capture and identify account identifiers typed into a device, thereby posing a security risk. Furthermore, when an online transaction is processed using conventional technology, the transaction is considered a "card not present transaction," which may result in higher processing fees and a greater risk of fraud. Summary of the invention

[0002] Systems, methods, apparatus, and computer-readable media for mobile web browser authentication and checkout using contactless cards. In one aspect, a method includes: receiving, by a merchant web page in a web browser executing on a processor of a mobile device, a selection of a first financial institution among a plurality of financial institutions, wherein the merchant web page includes a plurality of form fields associated with a transaction; generating, by the merchant web page, a uniform resource identifier (URI) directed to an application, wherein the URI includes a merchant identifier (ID) parameter, a session ID parameter associated with the transaction, a user ID parameter, and an action ID parameter, wherein at least a portion of the URI is registered with the application and the first financial institution in a mobile operating system (OS) executing on the mobile device; launching, by the mobile OS, the application in response to receiving the selection of the URI; authenticating, by the application, login credentials for an account associated with the first financial institution; associating, by the application, the user ID parameter and the session ID parameter with the account; receiving, by the application, a password from a contactless card associated with the account; receiving, by the application, an indication from a server that the specified server verified the password; launching, by the mobile OS, the web browser based on the indication; refreshing, by the web browser, the merchant web page, wherein the refreshed merchant web page includes a virtual card number (VCN) in a first form field among the plurality of form fields, and processing, by the merchant web page, the transaction based at least in part on the VCN in the first form field. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] To easily identify the discussion of any particular element or act, the most significant digit(s) in a reference number refers to the figure number in which the element is first introduced.

[0004] Figure 1A An aspect of the subject matter according to one embodiment is shown.

[0005] Figure 1B An aspect of the subject matter according to one embodiment is shown.

[0006] Figure 1C An aspect of the subject matter according to one embodiment is shown.

[0007] Figure 1D An aspect of the subject matter according to one embodiment is shown.

[0008] Figure 1E An aspect of the subject matter according to one embodiment is shown.

[0009] Figure 1F An aspect of the subject matter according to one embodiment is shown.

[0010] Figure 2A An aspect of the subject matter according to one embodiment is shown.

[0011] Figure 2B An aspect of the subject matter according to one embodiment is shown.

[0012] Figure 2C An aspect of the subject matter according to one embodiment is shown.

[0013] Figure 2D An aspect of the subject matter according to one embodiment is shown.

[0014] Figure 2E An aspect of the subject matter according to one embodiment is shown.

[0015] Figure 2F An aspect of the subject matter according to one embodiment is shown.

[0016] Figure 3 A routine 300 is shown according to one embodiment.

[0017] Figure 4 A routine 400 is shown according to one embodiment.

[0018] Figure 5 Routine 500 is shown according to one embodiment.

[0019] Fig. 6A A contactless card according to one embodiment is shown.

[0020] Figure 6B A contactless card according to one embodiment is shown.

[0021] Figure 7 A data structure 700 is shown according to one embodiment.

[0022] Figure 8 A computer architecture 800 is shown according to one embodiment. DETAILED DESCRIPTION

[0023] Embodiments disclosed herein provide technologies for performing secure authentication and checkout in applications using contactless cards. For example, a user can use a mobile web browser on a mobile device to add one or more items to their shopping cart for purchase. On the checkout page, a user can select an option to use an automatic checkout process. The user can select a first financial institution from a list of financial institutions presented by a web page. Then, the web page can generate a uniform resource identifier (URI) directed to the application based on the selection. The application can be registered with the first financial institution in a mobile operating system (OS). The application can be an account management application provided by the first financial institution. As parameters of the URI, the browser can include a merchant identifier (ID) parameter, a user ID parameter, a session ID parameter, and an action ID parameter as parameters of the URI. The OS can process the URI to start the application.

[0024] The application can process the parameters of the URI and determine the account authentication page to output the application based on the action ID. The authentication page may include one or more functions to authenticate the account, such as via a login name / password, biometrics, and the like. Once authenticated, the account application can associate the user ID and session ID with the account (e.g., in an account database stored by the application and / or server). The application can then instruct the user to tap their contactless card to the device, which causes the contactless card to generate a password. The application can read the password and transmit the password to a server associated with the first financial institution for verification. The application can also transmit the parameters of the URI to the server.

[0025] The server may then verify the password (e.g., based at least in part on decrypting the password). Once verified, the server may generate a virtual card number (VCN), an expiration date for the VCN, and a card verification value (CVV) for the VCN. The server may restrict use of the VCN to a merchant associated with the transaction based on the merchant ID. The server may then transmit the VCN, CVV, expiration date, and contact information (e.g., account holder name, address, telephone number, email address, etc.) to a server associated with the merchant. The server may also transmit the session ID and user ID to the merchant server. In at least one embodiment, the merchant ID includes a URI directed to the merchant server. In other embodiments, the merchant server is identified based on the merchant ID.

[0026] The merchant server may receive information from a server associated with the first financial institution and identify the browsing session based on the session ID and / or the user ID. The merchant server may then cause one or more form fields on the checkout page to be populated with the received information from the server. In some embodiments, the merchant server may push these values ​​to the mobile web browser. In other embodiments, the merchant server causes the checkout page to be reloaded. Once reloaded, the form fields may include payment information (e.g., VCN, expiration date, CVV) received from the server associated with the first financial institution and any other personal information (e.g., name, address, email address, phone number, etc.).

[0027] In addition, a server associated with the first financial institution may transmit a decryption result to the account application. The decryption result may specify that the server verified (or decrypted) the password and generated the VCN. The decryption result may cause the account application to return the device to the mobile web browser. The checkout page may be refreshed in the web browser (e.g., by the merchant server and / or by the mobile device). Once refreshed, the payment information and personal information may be added to a form in the web page. The user may then submit the form to process the payment in the web browser.

[0028] Advantageously, the embodiments disclosed herein provide a secure, automated checkout process using a contactless card. By utilizing a password generated by a contactless card, the embodiments disclosed herein can securely verify the identity of a user with minimal risk of fraudulent activity. In addition, this ensures that automatic checkout is performed only when the user has access to a contactless card that facilitates password verification with a server. In addition, certain restrictions imposed on web browsers can be avoided. For example, some operating systems and / or web browsers may not allow web browsers to communicate directly with account applications. Therefore, by using a VCN sent to the back end of a merchant, these restrictions can be overcome, allowing payment information for purchases to be automatically added to a web form. In addition, by providing the disclosed automation functionality in a web browser, many different websites can utilize the functionality without the need to be integrated into each website or application. Further, when processing transactions according to the embodiments disclosed herein, costs can be reduced because transactions are processed as "card-present transactions", which have lower transaction fees and lower fraud risks than "card-absent transactions".

[0029] With general reference to the symbols and nomenclature used herein, one or more parts of the subsequent detailed description may be presented in terms of program processes executed on a computer or computer network. These procedural descriptions and representations are used by those skilled in the art to convey the essence of their work to other technicians in the field most effectively. Processes are generally conceived here as operations that lead to a self-consistent sequence of desired results. These operations are those that require physical manipulation of physical quantities. Typically, although not necessarily, these quantities take the form of electrical, magnetic or optical signals that can be stored, transmitted, combined, compared and otherwise manipulated. Mainly for idiomatic reasons, these signals are sometimes referred to as bits, values, elements, symbols, characters, items, numbers or the like, which have proven to be convenient. However, it should be noted that all of these and similar terms are associated with appropriate physical quantities and are merely convenient markers applied to those quantities.

[0030] Further, these manipulations are often referred to in terms such as addition or comparison, which are usually associated with mental operations performed by a human operator. However, in any operation described herein that constitutes a part of one or more embodiments, this ability of a human operator is not necessary or desirable in most cases. On the contrary, these operations are machine operations. Useful machines for performing the operations of various embodiments include digital computers selectively activated or configured by computer programs stored therein, which are written according to the teachings herein, and / or include devices or digital computers specially constructed for the desired purpose. Various embodiments also relate to devices or systems for performing these operations. These devices can be specially constructed for the desired purpose. The structure required for various these machines will be apparent from the description given.

[0031] Reference is now made to the accompanying drawings, in which the same reference numerals are used to refer to the same elements throughout. In the following description, for the purpose of explanation, many specific details are set forth in order to provide a thorough understanding thereof. However, it is apparent that novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate their description. It is intended to cover all modifications, equivalents, and substitutes within the scope of the claims.

[0032] Figure 1A An exemplary computing architecture 100, also referred to as a system, consistent with the disclosed embodiments is depicted. Figure 1A-1E The computing architecture 100 is shown as having a limited number of elements in certain topologies, but it is understood that the computing architecture 100 may include more or fewer elements in alternative topologies as desired for a given implementation.

[0033] The computing architecture 100 includes one or more computing devices 102, one or more authentication servers 106, one or more contactless cards 104, and one or more merchant servers 108. The contactless card 104 represents any type of card, such as a credit card, a debit card, an ATM card, a gift card, a payment card, a smart card, and the like. The contactless card 104 may include one or more communication interfaces 124, such as a radio frequency identification (RFID) chip, which is configured to communicate with the communication interface 124 (also referred to herein as a "card reader", "wireless card reader", and / or "wireless communication interface") of the computing device 102 via NFC, the EMV standard, or other short-range protocols in wireless communication. Although NFC is used as an example communication protocol herein, the present disclosure is equally applicable to other types of wireless communications, such as the EMV standard, Bluetooth, and / or Wi-Fi.

[0034] The computing device 102 represents any number and type of computing devices, such as a smartphone, a tablet computer, a wearable device, a laptop computer, a portable gaming device, a virtualized computing system, a merchant terminal, a point of sale system, a server, a desktop computer, and the like. A mobile device may be used as an example of the computing device 102, but should not be considered a limitation of the present disclosure. The authentication server 106 and the merchant server 108 represent any type of computing device, such as a server, a workstation, a computing cluster, a cloud computing platform, a virtualized computing system, and the like. Although not depicted for clarity, the computing device 102, the contactless card 104, the authentication server 106, and the merchant server 108 each include one or more processor circuits, for example, to execute programs, codes, and / or instructions.

[0035] As shown, the memory 110 of the contactless card 104 includes an applet 112, a counter 114, a master key 116, a diversified key 118, and a unique customer identifier (ID) 120. The applet 112 is an executable code configured to perform the operations described herein. The counter 114, the master key 116, the diversified key 118, and the customer ID 120 are used to provide security in the system 100, as described in more detail below.

[0036] As shown, the memory 126 of the authentication server 106 includes an authentication application 128 and an account database 130. The account database 130 generally includes information related to an account holder (e.g., one or more users), one or more accounts of the account holder, and one or more contactless cards 104 for the account. For each contactless card associated with the financial institution associated with the authentication server 106, the authentication server 106 may store a corresponding instance of the master key 116 and the counter 114.

[0037] As shown, the memory 134 of the computing device 102 includes an instance of an operating system 136. Example operating systems include OS, and Operating system. As shown, operating system 136 includes account application 138 and web browser 140. Account application 138 allows users to perform various account-related operations, such as activating payment cards, viewing account balances, purchasing goods, and processing payments. In some embodiments, users can use authentication credentials to authenticate to access certain features of account application 138. For example, authentication credentials may include a user name (or login name) and password, biometric credentials (e.g., fingerprint, facial ID, etc.), and the like. Web browser 140 is an application that allows computing device 102 to access information via network 154 (e.g., via the Internet). For example, using web browser 140, a user can access one or more resources in merchant server 108, such as web page 142 stored in memory 152 of merchant server 108, which can be one of multiple web pages hosted by merchant server 108 (or another hosting entity). Although a web browser is used as a reference example in this article, the technology of the present disclosure is equally applicable to other types of applications (e.g., dedicated shopping applications provided by merchants, other types of applications, etc.).

[0038] More generally, when accessing a web page provided by a merchant server 108, a user may select one or more products, services, or other items for purchase via a web browser 140. For example, a user may wish to purchase a basketball and a football, and may add these items to their shopping cart. To complete the purchase, a web page 142 may include a form with one or more payment fields. The payment fields may include fields for an account number, an expiration date, a CVV, a customer name, a customer billing address, a customer email address, a customer phone number, and the like. However, certain restrictions may prevent data from being automatically filled into these payment fields. For example, an OS and / or a web browser 140 may restrict an account application 138 from providing data to be automatically filled into a form. In addition, a user may not have an account with a merchant server 108. However, advantageously, embodiments disclosed herein provide solutions that overcome these restrictions using an automatic checkout process.

[0039] In some embodiments, web page 142 may include an optional element to start an automatic checkout process. In some embodiments, a merchant may provide an automatic checkout process for one or more of a plurality of financial institutions. Therefore, if more than one financial institution is supported, when the optional element is selected, web page 142 may present a list of financial institutions to the user. Then, the user may select a financial institution (e.g., a financial institution that has issued a contactless card 104) from the list. Doing so may enable web page 142 and / or web browser 140 to generate a uniform resource identifier (URI) 144. Based on account application 138 being registered to OS, at least a portion of URI 144 may be directed to account application 138. Examples of URI 144 and / or portions thereof may include "example: / / automatedcheckout" or "www.example.com / automatedcheckout". In addition, URI 144 may include one or more parameters. Parameters may include merchant ID parameters, user ID parameters, session ID parameters, and action ID parameters. If only one financial institution is supported, the user does not need to select the institution as a condition for generating URI 144. The web page 142 and / or web browser 140 may then provide the URI 144 to the operating system 136 for processing. In some embodiments, before the URI 144 is provided to the operating system 136, the URI 144 is displayed and selected by the user.

[0040] The merchant ID parameter may be associated with the merchant and / or merchant server 108 that provided the web page 142. Thus, the account application 138 may uniquely identify each of the multiple merchants using a corresponding merchant ID parameter in the plurality of merchant ID parameters. Doing so allows the account application 138 to identify the address of the merchant server 108 associated with the merchant ID and / or to identify the address of any web page 142 associated with the merchant ID. The user ID parameter may be a unique identifier of a user associated with a browsing session. Because the user may not be logged in and / or may not have an account with the merchant server 108, the user ID may uniquely identify the user. The session ID parameter may identify a browsing session in the web browser 140 relative to the merchant server 108. For example, the session ID parameter may be used to identify a shopping cart, previously visited pages, the current page (e.g., web page 142) displayed in the web browser 140, and the like. The action ID may generally specify an action or operation to be performed to the account application 138. For example, in some embodiments, the action ID may instruct the account application 138 to open an authentication page and / or an automatic checkout page for an automatic checkout process. Thus, URI 144 may be a deep link to one or more pages of account application 138. Examples of URI 144 may include “example: / / automatedcheckout?merchID=123&sessID=ABC&userID=XYZ&actID=456” or “www.example.com / ?merchID=123&sessID=ABC&userID=XYZ&actID=456”. In some embodiments, URI 144 may be an Android Universal Link or a App Link.

[0041] In some embodiments, the operating system 136, web browser 140, and / or web page 142 can determine whether the account application 138 is installed on the computing device 102. The operating system 136, web browser 140, and / or web page 142 can use any feasible technology to determine whether the account application 138 is installed. For example, in iOS, the operating system 136, web browser 140, and / or web page 142 can use the canOpenURL() method to determine whether a URI directed to the account application 138 can be opened. The method can generally return an indication of whether the URI can be opened. Doing so allows the operating system 136, web browser 140, and / or web page 142 to determine that the account application 138 is installed on the computing device 102.

[0042] In some operating systems such as Android OS, operating system 136, web browser 140, and / or web page 142 may use a content provider service to determine whether account application 138 is installed on the device. For example, operating system 136, web browser 140, and / or web page 142 may provide a URI directed to account application 138 to the content provider service, which may return an indication of whether the URI may be opened. Doing so allows operating system 136, web browser 140, and / or web page 142 to determine that account application 138 is installed on computing device 102.

[0043] If the account application 138 is not installed on the device 102, the operating system 136 can download the account application 138 and install it on the device 102. In some embodiments, the account application 138 can be an instant application, an app clip, a progressive web application, or any other non-persistent application. In other embodiments, a persistent version of the account application 138 is installed on the computing device 102 from an application store.

[0044] In the event that account application 138 is available on computing device 102, the OS may process URI 144, which causes the OS to open, access, launch, or otherwise display account application 138. Doing so also provides URI 144, including parameters, to account application 138. Based on the action ID parameter of URI 144, account application 138 may open an account authentication page to facilitate the autofill techniques described herein.

[0045] In some embodiments, operating system 136, web browser 140, and / or web page 142 may determine whether account application 138 is installed on computing device 102 before providing optional elements to begin automatic checkout and / or generating URI 144. In such embodiments, web page 142 and / or web browser 140 may refrain from providing optional elements and / or automatic checkout process if account application 138 is not installed on computing device 102. Similarly, in some embodiments, web browser 140 and / or web page 142 may refrain from generating URI 144 if account application 138 is not installed on computing device 102.

[0046] As described above, in some embodiments, the account application 138 may not be installed on the computing device 102. Therefore, in some embodiments, the web page 142 may encode a graphical representation of the URI 144 (including the merchant ID parameter, the user ID parameter, and the session ID parameter), which may be displayed in the web page 142. The graphical representation can generally be used to initiate the auto-fill technology described herein without requiring the user to select the URI 144 and / or select a financial institution from a list. The graphical representation may include a matrix code (also referred to as a matrix code, a matrix barcode, etc.). Examples of matrix codes include, but are not limited to, quick response (QR) codes, app clip codes, and the like. Therefore, in such embodiments, a camera (not shown) or other optical reader of the computing device 102 may detect, for example, a matrix code encoding the URI 144 in one or more images. Once the matrix code is detected, the operating system 136, the web browser 140, and / or the web page 142 may decode the URI 144 and determine whether the account application 138 is installed on the computing device 102 based on the URI 144, as described herein. If the account application 138 is not installed on the computing device 102, the OS 136 can download the account application 138 and install the account application 138 on the computing device 102. In some embodiments, the account application 138 is downloaded based on the approval input received from the user. As described above, the downloaded application can include a persistent or non-persistent (e.g., an instant application, an app clip, a progressive web application, etc.) version of the account application 138. The downloaded account application 138 can then be accessed, launched, or otherwise displayed. As described above, the parameters of the URI 144 can be provided to the account application 138, and the account application opens an account authentication page to facilitate the auto-fill technology described herein. The embodiments are not limited in these contexts.

[0047] Figure 1B An embodiment is depicted in which the OS has accessed URI 144 and the account application 138 has loaded an account authentication page. As described above, URI 144 may be accessed based on selection of URI 144 and / or based on a camera detecting a graphical representation (e.g., a matrix code) of URI 144. Generally, the account authentication page allows a user to authenticate their account, such as via a login name and password, biometrics, etc. Account application 138 and / or authentication server 106 may authenticate any received authentication credentials.

[0048] Once authenticated, the account application 138 may associate the user ID parameter and session ID parameter of the URI 144 with the authenticated account (and / or transmit the user ID parameter and session ID parameter to the authentication server 106 to be associated with the account). The account application 138 may then instruct the user to tap the contactless card 104 against the computing device 102 (or otherwise bring the contactless card 104 within communication range of the communication interface 124 of the device 102). Doing so may cause the applet 112 of the contactless card 104 to generate the password 122.

[0049] The cryptogram 122 may be based on the customer ID 120 of the contactless card 104. The cryptogram 122 may be generated based on any suitable cryptographic technique. In some embodiments, the applet 112 may include an unencrypted identifier (e.g., the customer ID 120, an identifier of the contactless card 104, and / or any other unique identifier) ​​as part of a data package that includes the cryptogram 122. In at least one embodiment, the data package is an NDEF file.

[0050] As described above, the computing architecture 100 is configured to implement key diversification to protect data, which may be referred to herein as a key diversification technique. Generally, the authentication server 106 (or another computing device) and the contactless card 104 may be equipped with the same master key 116 (also referred to as a master symmetric key). More specifically, each contactless card 104 is programmed with a different master key 116, which has a corresponding pairing in the authentication server 106. For example, when the contactless card 104 is manufactured, a unique master key 116 may be programmed into the memory 110 of the contactless card 104. Similarly, the unique master key 116 may be stored in the record of the customer associated with the contactless card 104 in the account database 130 of the authentication server 106 (and / or stored in a different secure location, such as a hardware security module (HSM) 132). The master key 116 may be kept confidential to all parties other than the contactless card 104 and the authentication server 106, thereby improving the security of the system 100. In some embodiments, the applet 112 of the contactless card 104 can use the master key 116 and the data (e.g., the customer ID 120) as inputs to a cryptographic algorithm to encrypt and / or decrypt the data. For example, encrypting the customer ID 120 using the master key 116 can generate the password 122. Similarly, the authentication server 106 can use the corresponding master key 116 to encrypt and / or decrypt the data associated with the contactless card 104.

[0051] In some embodiments, the master key 116 of the contactless card 104 and the authentication server 106 can be used in conjunction with the counter 114 to improve security using key diversification. The counter 114 includes a value synchronized between the contactless card 104 and the authentication server 106. For example, the counter 114 can include a number that changes each time data is exchanged between the contactless card 104 and the authentication server 106 (and / or the contactless card 104 and the computing device 102). Generally, the applet 112 can provide the master key 116, the unique customer ID 120, and the diversification factor as inputs to the cryptographic algorithm, thereby generating a diversification key 118. In some embodiments, the diversification factor is the counter 114. Then, the diversification key 118 can be used to encrypt some data, such as the diversification factor (e.g., counter 114) or other sensitive data. The applet 112 and the authentication server 106 can be configured to encrypt the same type of data to facilitate the decryption and / or verification process of the password 122.

[0052] More generally, when preparing to send data (e.g., to the authentication server 106 and / or the computing device 102), the applet 112 of the contactless card 104 can increment the counter 114. Then, the applet 112 of the contactless card 104 can provide the master key 116, the customer ID 120, and the counter 114 as inputs to a cryptographic algorithm that produces a diversified key 118 as output. The cryptographic algorithm may include an encryption algorithm, a hash-based message authentication code (hash-based MAC, HMAC) algorithm, a cipher-based message authentication code (cipher-based MAC, CMAC) algorithm, and the like. Non-limiting examples of cryptographic algorithms may include symmetric encryption algorithms, such as 3DES or AES107; symmetric HMAC algorithms, such as HMAC-SHA-256; and symmetric CMAC algorithms, such as AES-CMAC. U.S. patent application 16 / 205,119 filed on November 29, 2018 describes an example of key diversification technology in more detail. The aforementioned patent application is incorporated herein by reference in its entirety.

[0053] The applet 112 may then encrypt some data (e.g., unique customer ID 120, counter 114, commands, and / or any other data) using the diversified key 118 and the data as input to a cryptographic algorithm. For example, encrypting the unique customer ID 120 using the diversified key 118 may produce an encrypted unique customer ID (e.g., password 122).

[0054] In some embodiments, two diversified keys 118 can be generated, for example, based on one or more parts of the input to the cryptographic function. In some embodiments, two diversified keys 118 are generated based on two different master keys 116, unique customer ID 120 and counter 114. In such an embodiment, a message authentication code (MAC) is generated using one of the diversified keys 118, and the MAC can be encrypted using another of the diversified keys 118. MAC can be generated based on any suitable data (such as sensitive data, unique customer ID 120, counter 114, etc.) input to the MAC algorithm. More generally, the applet 112 and the authentication server 106 can be configured to generate a MAC based on the same data. In some embodiments, the password 122 is included in a data packet such as an NDEF file. Then, the account application 138 can read the data packet including the password 122 via the communication interface 124 of the computing device 102.

[0055] Figure 1C An embodiment is depicted in which the account application 138 transmits a data packet including the password 122 to the authentication server 106. As shown, the account application 138 may also transmit URI parameters 146 to the authentication server 106. The URI parameters 146 may include a merchant ID parameter, a user ID parameter, and a session ID parameter. The authentication server 106 may then associate the user ID and session ID with the account in the account database 130 (if it has not already done so).

[0056] The authentication server 106 may provide the password 122 to the authentication application 128 and / or the HSM 132 for verification based at least in part on an instance of the master key 116 stored by the authentication server 106. In some embodiments, the authentication application 128 and / or the HSM 132 may use the unencrypted client ID 120 provided to the server 106 along with the password 122 to identify the master key 116 and the counter 114. In some examples, the authentication application 128 may provide the master key 116, the unique client ID 120, and the counter 114 as inputs to a cryptographic algorithm that generates one or more diversified keys 118 as outputs. The resulting diversified key 118 may correspond to the diversified key 118 of the contactless card 104, which may be used to decrypt the password 122 and / or verify the MAC once decrypted. For example, the authentication server 106 may generate a MAC based on the same data as the applet 112 (e.g., sensitive data, the unique client ID 120, and / or the counter 114). If the MAC generated by authentication server 106 matches the decrypted MAC in password 122 , authentication server 106 may verify or otherwise authenticate password 122 .

[0057] Regardless of the verification technique used, the authentication application 128 and / or HSM 132 may successfully decrypt the cryptogram 122 and verify the MAC, thereby verifying or authenticating the cryptogram 122 .

[0058] If the decryption is successful, the authentication application 128 can transmit the decryption result to the account application 138 to indicate that the server has decrypted and / or verified the password 122. In addition, the authentication server 106 can generate a VCN, an expiration date, and a CVV for the transaction. A VCN is usually a one-time use account number associated with an account, but the VCN is different from the account number of the contactless card 104. The authentication server 106 can limit the use of the VCN to merchants (e.g., based on the merchant ID). Doing so ensures that the VCN can only be used to process payments with merchants. For example, if different merchants request to use the VCN to process transactions, or users request to use the VCN to process transactions with different merchants, the server can reject these transactions. The authentication server 106 can also place time limits, quantity limits, location limits, etc. on the VCN. The authentication server 106 can reject any transaction that does not meet these restrictions. The authentication server 106 can then transmit the VCN, expiration date, and CVV to the merchant server 108. The authentication server 106 may also transmit the session ID, user ID, and contact information (eg, user name, billing address, shipping address, email address, phone number, etc.) to the merchant server 108 .

[0059] However, if the authentication application 128 cannot decrypt the password 122 to produce the expected result (e.g., the customer ID 120 of the account associated with the contactless card 104), the authentication application 128 does not verify the password 122. In such an example, the authentication application 128 determines to terminate the automatic checkout process. The authentication application 128 can transmit an indication of the decryption failure to the computing device 102.

[0060] Figure 1D An embodiment is depicted in which the authentication application 128 transmits a decryption result 148 to the account application 138 and transmits the payment information 150 to the merchant server 108. The decryption result 148 generally reflects whether the password 122 is decrypted. Figure 1D In the depicted example, decryption result 148 may indicate that authentication server 106 decrypted or otherwise verified password 122. Doing so may allow account application 138 to determine that password 122 has been successfully decrypted and / or verified before continuing the autofill process, thereby increasing security.

[0061] The payment information 150 may generally include the VCN, the expiration date of the VCN, the CVV of the VCN, the session ID, the user ID, and the user's contact information (e.g., username, billing address, shipping address, email address, phone number, etc.). In some embodiments, the URI 144 includes, as a parameter, an indication of the address of the merchant server 108. Doing so allows the authentication server 106 to transmit the payment information 150 to the merchant server 108 based on the address. In other embodiments, the authentication server 106 may store a list of addresses for multiple different merchants, with each entry indexed by a corresponding merchant ID. In such an example, the authentication server 106 may identify the address of the merchant server based on the merchant ID in the URI 144.

[0062] Once received, the merchant server 108 can identify the user's browsing session based on the user ID and / or session ID. Doing so allows the merchant server 108 to inject, append, or otherwise populate the received payment information 150 into one or more form fields of the web page 142 corresponding to the session ID and / or user ID. For example, the merchant server 108 can append the VCN to the card number form field, the expiration date to the expiration date form field, the CVV to the CVV form field, and the like. More generally, the merchant server 108 can store the payment information 150 for later use.

[0063] In response to receiving the decrypted result 148, the account application 138 can cause the computing device 102 to switch back to the web browser 140. For example, the account application 138 can instruct the operating system 136 to launch the web browser 140. As another example, the account application 138 can output a selectable element directed to the web browser 140, which, when selected, causes the operating system 136 to launch the web browser 140.

[0064] In some embodiments, the user may not return to the web browser 140 and / or may not complete the purchase using the VCN within a threshold amount of time. The amount of time may be measured based on the time when the VCN was generated. In such embodiments, the authentication server 106 and / or the merchant server 108 may transmit a notification to the computing device 102 that may remind the user to complete the purchase using the VCN. The notification may include a push notification, an email, a text message, etc. Thus, the authentication server 106 and the merchant server 108 may communicate to exchange timing information (e.g., to determine whether a time threshold has been exceeded), indicate whether the purchase is complete, and cause the transmission of a notification to the computing device 102.

[0065] Figure 1EAn embodiment is depicted in which the web page 142 is refreshed to include the payment information 150 in the form fields of the web page 142. The web page 142 can be refreshed according to any technique. For example, the user can refresh the web page 142 in the web browser 140, which causes the merchant server 108 to transmit the web page 142 including the payment information 150 populated in the form fields. As another example, the merchant server 108 can automatically cause the web page 142 to be reloaded in the web page 142, such as a server-initiated refresh. As yet another example, the merchant server 108 can transmit executable instructions (e.g., JavaScript, etc.) to cause the web browser 140 to update the web page 142 to include the payment information 150 in the form fields.

[0066] Regardless of the technique used to refresh the web page 142, once refreshed, the web page 142 includes payment information 150 automatically typed into the form fields. For example, the account number field may include the VCN, the expiration date field may include the expiration date, the CVV field may include the CVV, one or more name fields may include the name of the account holder, the billing address field may include the account billing address, the email field may include the account email address, the phone number field may include the account phone number, and the like.

[0067] Additionally, the refreshed web page 142 also maintains the browsing session from the web browser 140. For example, a web page 142 including a payment form may be presented in the web browser 140, allowing the user to purchase one or more items that the user previously added to their shopping cart in the web browser 140. Continuing with the example above, the web browser 140 may load a web page 142 reflecting the user's shopping cart, which includes a basketball and a football.

[0068] Advantageously, when refreshed, payment information 150 is automatically added to one or more payment fields of web page 142. The user may optionally modify the information entered into the form fields. The user may then submit the form including payment information 150 to complete the purchase.

[0069] Figure 1FAn embodiment is depicted in which a web browser 140 and / or web page 142 generates a transaction package 156 to process a payment using payment information 150 populated into a form field of the web page 142. Generally, the transaction package 156 can be transmitted according to a hypertext transfer protocol (HTTP). Once received, the merchant server 108 can process the payment using the payment information 150 for the transaction. The authentication server 106 can approve the transaction based at least in part on the VCN used as payment for the transaction with the merchant because the VCN is bound or restricted to the merchant. The merchant server 108 can then create a transaction record 160 for the transaction in the transaction database 158. A confirmation of the transaction can then be displayed in the web browser 140.

[0070] Because the transaction is processed using the VCN generated by the authentication server 106, the transaction can be processed as a "card present transaction" even though the transaction is conducted online. Advantageously, this reduces the fees for processing the transaction and further reduces the risk of fraud. Thus, in some embodiments, merchants can offer discounts (e.g., percentage discounts, dollar discounts, etc.) for purchases completed using the automated mobile web authentication and checkout process disclosed herein. The embodiments are not limited in these contexts.

[0071] In some embodiments, the merchant server 108 may allow the user to create an account after (and / or concurrently with) completing a purchase. In such embodiments, the merchant server 108 may create the account based at least in part on the account holder's name and contact information (e.g., address, phone number, email address, etc.) received from the authentication server 106. In some embodiments, the merchant server 108 may also use a user ID parameter of the URI 144 to identify the user to create the account. The user may also provide any other additional information (e.g., login name / password, biometrics, other attributes, etc.) to create the account.

[0072] In some embodiments, by storing the payment information 150, the merchant server 108 need not process the transaction using the payment information 150 in the transaction package 156. Instead, in such embodiments, the merchant server 108 processes the transaction based on the stored payment information 150, with the transaction package 156 acting as the user's consent to process the purchase using the stored payment information 150. However, if the user edits any of the payment information 150 presented in the web page 142, the merchant server 108 may process the transaction using the payment information 150 edited by the user.

[0073] Figure 2A2 is a schematic diagram 210 depicting an example embodiment of automatic mobile web browser authentication and checkout using a contactless card. As shown, Figure 3 A includes a depiction of a mobile computing device 102 executing a web browser 140. The web browser 140 can display a web page, such as a web page 142. For example, the web page 142 can be a web page 142 that allows a user to place an order and provide payment information for the order via one or more form fields. As shown, the web page 142 includes a payment form with fields 201-207, where field 201 is a name field, field 202 is an account number field, field 203 is an expiration date field, field 204 is a CVV field, field 205 is an address field, field 206 is an email address field, and field 207 is a phone number field.

[0074] The web page 142 also includes a selectable element 208 that allows the user to initiate an automatic checkout process for server-side populating of payment information into the form fields 201 - 207. The embodiments are not limited in this context.

[0075] Figure 2B 210 is a diagram illustrating an embodiment in which a user has selected element 208 to initiate an automatic checkout process. As shown, web page 142 prompts the user to select a financial institution from a list of financial institutions that support automatic checkout. The user can then select one of the financial institutions from the list. Doing so can cause web browser 140 to generate a URI (e.g., URI 144) directed to account application 138, which causes computing device 102 to open or otherwise display account application 138. Parameters of the URI may include a merchant ID, a user ID, a session ID, and an action ID.

[0076] Figure 2C 220 is a diagram depicting an embodiment in which a URI is accessed and an account application 138 is loaded on a computing device 102. Based on the parameters of the URI (e.g., action ID), the account application 138 outputs an authentication page that requests the user to authenticate their account using a login name / password for an automated checkout process. For example, the user may type a username in field 221, a password in field 222, and select a submit button 223 to submit the username and password for verification. The account application 138 may then authenticate the credentials (and / or transmit the credentials to the authentication server 106 for authentication).

[0077] Figure 2D230 is a diagram reflecting an embodiment in which a user successfully logs into their account. Once authenticated, the account application 138 and / or the authentication server 106 may associate the user ID and session ID with the authenticated account (e.g., by storing an indication of the association in the account database 130). In some embodiments, the account application 138 includes an instance of the account database 130. The account application 138 may then instruct the user to tap the contactless card 104 against the computing device 102.

[0078] The user may then tap the contactless card 104 against the computing device 102. Doing so causes the contactless card 104 to generate a password, which is verified by the authentication server 106. As shown, the authentication server 106 verifies the password. Doing so may cause the authentication server 106 to generate payment information (e.g., VCN, expiration date, CVV, name, address, contact information, session ID, user ID, etc.) and transmit the payment information to the merchant server 108. Doing so allows the merchant server 108 to associate the payment information with the user ID and / or session ID. In addition, the merchant server 108 may perform server-initiated filling of the payment information into the form fields of the web page 142.

[0079] The authentication server 106 may also transmit an indication to the account application 138 that the server verified the password, a VCN was generated, and the VCN was sent along with other information to the merchant server 108. The account application 138 may then cause the operating system 136 to switch back to the web browser 140, or otherwise bring the web browser 140 to the foreground of the computing device 102. For example, the account application 138 may determine a URI for the web browser 140 based on the merchant ID parameter and / or the action ID parameter. Doing so may allow the account application 138 to switch the computing device 102 back to the web browser 140 to complete the automatic checkout.

[0080] Figure 2E 240 is a diagram showing a web page 142 including data populated into form fields 201-207 by a merchant server 108. As shown, the user's name has been added to name field 201, the VCN has been added to account field 202, the expiration date has been added to expiration date field 203, the CVV has been added to CVV field 204, the address has been added to address field 205, the email address has been added to email address field 206, and the phone number has been added to phone number field 207.

[0081] The user can then complete the purchase using the submit button, which causes the merchant server 108 to process the payment using the VCN and associated data. In some embodiments, the user can edit the information added to the form fields 201-207. The embodiments are not limited in this context.

[0082] Figure 2F is a schematic diagram 250 showing the confirmation web page 142 in the web browser 140. The confirmation page generally reflects that the purchase is completed using the VCN and associated data that were automatically entered into the form fields 201-207.

[0083] Because the transaction is processed using the VCN generated by the authentication server 106, the transaction can be processed as a "card present transaction" even if the transaction is conducted online. Advantageously, this reduces the fees for processing the transaction and further reduces the risk of fraud. The embodiments are not limited in this context.

[0084] The operation for the disclosed embodiments can be further described with reference to the following figures. Some figures may include logic flows. Although the figures presented herein may include specific logic flows, it is understood that the logic flows only provide examples of how the general functions described herein can be implemented. Further, unless otherwise stated, a given logic flow does not necessarily have to be performed in the order presented. In addition, not all actions shown in the logic flow may be required in some embodiments. In addition, a given logic flow may be implemented by hardware elements, software elements executed by a processor, or any combination thereof. The embodiments are not limited to this context.

[0085] Figure 3 An embodiment of a logic flow or routine 300 is shown. The logic flow 300 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 300 may include some or all of the operations for secure authentication and checkout in a mobile web browser 140 using a contactless card 104. The embodiments are not limited in this context.

[0086] In block 302, the routine 300 receives a selection of a first financial institution among a plurality of financial institutions by a merchant web page 142 in a web browser 140 executing on a processor of a mobile computing device 102, wherein the merchant web page 142 includes a plurality of form fields associated with a transaction. In block 304, the routine 300 generates a URI 144 directed to an application, such as an account application 138, by the merchant web page 142. The URI 144 may include a merchant identifier (ID) parameter, a session ID parameter associated with the transaction, a user ID parameter, and an action ID parameter, wherein at least a portion of the URI is registered with the account application 138 and the first financial institution in the mobile operating system 136 executing on the mobile device.

[0087] In box 306, the routine 300, in response to receiving the selection of the URI 144, launches the account application 138 by the mobile operating system 136. In box 308, the routine 300, by the account application 138, authenticates the login credentials of the account associated with the first financial institution. In box 310, the routine 300, by the account application 138, associates the user ID parameter and the session ID parameter with the account. In box 312, the routine 300, by the account application 138, receives a password (e.g., the password 122) from the contactless card 104 associated with the account. In box 314, the routine 300, by the account application 138, receives an indication from the authentication server 106 that the authentication server 106 has verified the password 122. In box 316, the routine 300, by the mobile operating system 136, launches the web browser 140 based on the indication. In box 318, the routine 300, by the web browser 140, refreshes the merchant web page 142. The refreshed merchant web page 142 includes a virtual card number (VCN) in a first form field of the plurality of form fields. The remaining form fields may include other attributes, such as an expiration date, a CVV, and customer contact information (e.g., account holder name, address, phone number, email address, etc.). In block 320, the routine 300 processes the transaction by the merchant web page 142 based at least in part on the VCN in the first form field.

[0088] Figure 4 An embodiment of a logic flow or routine 400 is shown. The logic flow 400 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 400 may include some or all of the operations for secure authentication and checkout in a mobile web browser 140 using a contactless card 104. The embodiments are not limited in this context.

[0089] In block 402, the routine 400 generates, by the merchant web page 142, a URI 144 directed to the account application 138, wherein the URI 144 includes a session identifier (ID) associated with the transaction, a merchant ID, an action ID, and a user ID, wherein at least a portion of the URI 144 is registered with the application and the financial institution in the mobile operating system 136 executing on the mobile computing device 102, wherein the merchant web page 142 includes a plurality of form fields associated with the transaction. In block 404, the routine 400 launches, by the mobile operating system 136, the account application 138 based on selection of the URI 144. In block 406, the routine 400 associates, by the account application 138, the user ID and the session ID with the account based on credentials of the account.

[0090] In box 408, the routine 400 transmits, by the account application 138, to the authentication server 106, the merchant ID, the session ID, the user ID, and the password 122 received by the account application 138 from the contactless card 104. In box 410, the routine 400 receives, by the account application 138, from the authentication server 106 an indication specifying that the authentication server 106 verified the password 122. In box 412, the routine 400 generates, by the authentication server 106, a virtual card number (VCN), an expiration date associated with the VCN, and a card verification value (CVV) associated with the VCN based on the verification of the password 122, wherein the authentication server 106 restricts use of the VCN to the merchant and / or the merchant server 108 based on the merchant ID. In box 414, the routine 400 transmits, by the authentication server 106, based on the merchant ID, the verification of the password, and the authentication of the credentials, to the merchant server 108 associated with the web page: the VCN, the expiration date, the CVV, the account holder's name, and contact information (e.g., mailing address, phone number, email address, etc.). In block 416, the routine 400 refreshes, by the web browser 140, the merchant web page 142, wherein the refreshed merchant web page 142 includes the VCN, expiration date, CVV, account holder name, and contact information in corresponding fields of the plurality of form fields. In block 418, the routine 400 submits, by the merchant web page 142, the transaction based at least in part on the VCN, expiration date, CVV, account holder name, and contact information in the form fields.

[0091] Figure 5 An embodiment of a logic flow or routine 500 is shown. The logic flow 500 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 500 may include some or all of the operations for secure authentication and checkout in a dedicated merchant application using a contactless card 104. The embodiments are not limited in this context.

[0092] As mentioned above, web browser 140 represents any type of application. Figure 5 An embodiment is reflected in which a dedicated application is used for secure authentication and checkout using a contactless card 104. In block 502, routine 500 receives a selection of a first financial institution among a plurality of financial institutions by a first application executed on a processor of a mobile device. In block 504, routine 500 generates a uniform resource identifier (URI) directed to a second application by the first application, wherein at least a portion of the URI is registered to the second application and the first financial institution in a mobile operating system (OS) executed on the mobile device. The URI may include parameters of the URI 144, such as a user ID, a session ID, a merchant ID, and / or an action ID.

[0093] In box 506, routine 500 starts a second application based on a URI by the mobile OS. In box 508, routine 500 receives a password from a contactless card associated with an account by the second application. The second application can transmit the password and any URI parameters to a first server associated with the issuer of the contactless card. In box 510, routine 500 generates a virtual card number (VCN), an expiration date of the VCN, and a card verification value (CVV) of the VCN by the first server based on the verification of the password. In box 512, routine 500 transmits the VCN, expiration date, CVV, and contact information of the account associated with the contactless card to a second server associated with the merchant providing the first application by the first server. The first server can also transmit a user ID, a session ID, a merchant ID, and / or an action ID to the second server. In box 514, routine 500 generates an account in the merchant based on the VCN, expiration date, CVV, and contact information by the second server. Doing so allows the second server to store payment information for later use. In block 516, routine 500 processes the transaction for the account with the merchant based at least in part on the stored VCN, expiration date, and CVV by the second application. For example, at a later time, the user may log into their account with the merchant in the first application. The user may specify in the first application that the sandwich is to be purchased from the merchant. The merchant may process the purchase of the sandwich using the stored VCN, expiration date, CVV associated with the account without providing payment information into the first application.

[0094] Fig. 6A600 is a schematic diagram showing an example construction of a contactless card 104, which may include a payment card, such as a credit card, debit card, or gift card, issued by a service provider displayed as a service provider mark 602 on the front or back of the contactless card 104. In some examples, the contactless card 104 is not related to a payment card and may include, but is not limited to, an identification card. In some examples, the transaction card may include a dual interface contactless payment card, a rewards card, etc. The contactless card 104 may include a substrate 604, which may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 104 may have physical characteristics of an ID-1 format that conforms to the ISO / IEC 7816 standard, and the transaction card may additionally conform to the ISO / IEC 14443 standard. However, it is understood that a contactless card 104 according to the present disclosure may have different characteristics and the present disclosure does not require that a transaction card be implemented in a payment card.

[0095] The contactless card 104 may also include identification information 606 displayed on the front and / or back of the card and a contact pad 608. The contact pad 608 may include one or more pads and is configured to establish contact with another client device (such as an ATM, user device, smartphone, laptop, desktop, or tablet) via a transaction card. The contact pad may be designed according to one or more standards such as the ISO / IEC 7816 standard and enable communication according to the EMV protocol. As will be described in Figure 6B As discussed further in , contactless card 104 may also include processing circuitry, an antenna, and other components. These components may be located behind contact pads 608 or elsewhere on substrate 604, for example, within different layers of substrate 604, and may be electrically and physically coupled to contact pads 608. Contactless card 104 may also include a magnetic stripe or tape that may be located on the back of the card ( Fig. 6A ). The contactless card 104 may also include a Near-Field Communication (NFC) device coupled to an antenna capable of communicating via the NFC protocol. The embodiments are not limited in this manner.

[0096] like Figure 6BAs shown, the contact pad 608 of the contactless card 104 may include a processing circuit 610 for storing, processing, and communicating information, the processing circuit including a processor 612, a memory 110, and one or more communication interfaces 124. It will be appreciated that the processing circuit 610 may include additional components, including a processor, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tampering hardware, as necessary to perform the functions described herein.

[0097] The memory 110 can be a read-only memory, a write-once read-many memory or a read / write memory, for example, a RAM, a ROM and an EEPROM, and the contactless card 104 can include one or more of these memories. The read-only memory can be programmable by the manufacturer to be read-only or one-time programmable. One-time programmability provides the opportunity to write once and then read multiple times. The write-once / read-many memory can be programmed at a certain point in time after the memory chip has been shipped. Once the memory is programmed, it cannot be rewritten, but can be read multiple times. The read / write memory can be programmed and reprogrammed multiple times after shipping. The read / write memory can also be read multiple times after shipping. In some instances, the memory 110 can be an encrypted memory, which uses an encryption algorithm executed by the processor 612 to encrypt data.

[0098] The memory 110 may be configured to store one or more applets 112, one or more counters 114, a customer ID 120, one or more master keys 116, and one or more diversified keys 118. The one or more applets 112 may include one or more software applications configured to execute on one or more contactless cards 104, such as Card applet. However, it is understood that applet 112 is not limited to Java Card applet, but can be any software application that can operate on a contactless card or other device with limited memory. One or more counters 114 may include a digital counter sufficient to store an integer. Customer ID 120 may include a unique alphanumeric identifier assigned to a user of contactless card 104, and the identifier may distinguish the user of contactless card 104 from users of other contactless cards 104. In some examples, customer ID 120 may identify both the customer and the account assigned to the customer, and may also identify the contactless card 104 associated with the customer's account.

[0099] The processor 612 and memory elements of the aforementioned exemplary embodiments are described with reference to the contact pad 608, but the present disclosure is not limited thereto. It is understood that these elements may be implemented outside of the contact pad 608 or completely separated therefrom, or as further elements in addition to the processor 612 and memory 110 elements located within the contact pad 608.

[0100] In some examples, the contactless card 104 may include one or more antennas 614. The one or more antennas 614 may be placed within the contactless card 104 and around the processing circuit 610 of the contact pad 608. For example, the one or more antennas 614 may be integral with the processing circuit 610, and the one or more antennas 614 may be used with an external booster coil. For another example, the one or more antennas 614 may be external to the contact pad 608 and the processing circuit 610.

[0101] In an embodiment, the coil of the contactless card 104 can act as the secondary coil of an air-core transformer. The terminal can communicate with the contactless card 104 by cutting off power or amplitude modulation. The contactless card 104 can use the gap in the power connection of the contactless card 104 to infer the data transmitted from the terminal, which can be functionally maintained by one or more capacitors. The contactless card 104 can communicate back by switching the load or load modulation on the coil of the contactless card 104. Load modulation can be detected in the coil of the terminal by interference. More generally, using (one or more) antennas 614, processors 612 and / or memory 110, the contactless card 104 provides a communication interface to communicate via NFC, Bluetooth and / or Wi-Fi communications.

[0102] As explained above, the contactless card 104 can be built on a software platform such as JavaCard that can operate on a smart card or other device with limited memory, and one or more applications or applets can be securely executed. The applet 112 can be added to the contactless card to provide a one-time password (OTP) for multifactor authentication (MFA) in various mobile application-based use cases. The applet 112 can be configured to respond to one or more requests such as near-field data exchange requests from a reader such as (e.g., a mobile computing device 102 or a point-of-sale terminal) a mobile NFC reader, and generate an NDEF message including a cryptographically secure OTP encoded as an NDEF text tag. The NDEF message can include a password 122 and any other data.

[0103] One example of an NDEF OTP is an NDEF short record layout (SR=1). In such an example, one or more applets 112 may be configured to encode the OTP as a text tag of a well-known type of NDEF Type 4. In some examples, an NDEF message may include one or more records. In addition to the OTP record, the applet 112 may be configured to also add one or more static tag records.

[0104] In some examples, one or more applet applications 112 can be configured to simulate an RFID tag. The RFID tag can include one or more polymorphic tags. In some examples, different cryptographic data is presented each time the tag is read, which can indicate the authenticity of the contactless card. Based on one or more applet applications 112, the NFC reading of the tag can be processed, the data can be transmitted to a server such as a server of a banking system, and the data can be verified at the server.

[0105] In some examples, the contactless card 104 and the server may include certain data so that the card can be correctly identified. The contactless card 104 may include one or more unique identifiers (not shown). Each time a read operation occurs, the counter 114 may be configured to increment. In some examples, each time data from the contactless card 104 is read (e.g., by a mobile device), the counter 114 is transmitted to the server for verification, and it is determined whether the counter 114 is equal to (as part of the verification) the server's counter.

[0106] One or more counters 114 can be configured to prevent replay attacks. For example, if a password has been obtained and replayed, the password is immediately rejected if the counter 114 has been read or used or otherwise ignored. If the counter 114 has not been used, it can be replayed. In some examples, the counter incremented on the contactless card 104 is different from the counter incremented for the transaction. The contactless card 104 cannot determine the application transaction counter 114 because there is no communication between the small applications 112 on the contactless card 104. In some examples, the contactless card 104 can include a first small application 440-1 (which can be a transaction small application) and a second small application 440-2. Each small application 440-1 and 440-2 can include a corresponding counter 114.

[0107] In some examples, counter 114 may become out of sync. In some examples, to account for unexpected reads that initiate transactions, such as reading at an angle, counter 114 may be incremented, but the application does not process counter 114. In some examples, when mobile device 10 is awake, NFC may be enabled, and computing device 102 may be configured to read available tags, but not take action in response to the reads.

[0108] In order to keep the counter 114 synchronized, an application, such as a background application, can be executed, which will be configured to detect when the mobile device 102 wakes up, and synchronize with the server of the banking system to indicate the reading that occurred due to the detection, and then move the counter 114 forward. In other examples, a hashed one-time password can be used to accept an unsynchronized window. For example, if within a threshold of 10, the counter 114 can be configured to move forward. But if within a different threshold number, such as within 10 or 1000, a request for performing resynchronization can be processed, which requests the user to tap, gesture or otherwise indicate one or more times via the user device via one or more applications. If the counter 114 increases in the appropriate order, it is possible to know that the user has done so.

[0109] The key diversification technique described herein with reference to the counter 114, the master key, and the diversification key is an example of an encryption and / or decryption key diversification technique. This example key diversification technique should not be considered a limitation of the present disclosure, as the present disclosure is equally applicable to other types of key diversification techniques.

[0110] During the creation process of the contactless card 104, two cryptographic keys may be uniquely assigned to each card. The cryptographic keys may include a symmetric key that may be used in both encryption and decryption of data. The Triple DES (3DES) algorithm may be used by EMV, and it is implemented by hardware in the contactless card 104. Using a key diversification process, one or more keys may be derived from a master key based on uniquely identifiable information for each entity that requires a key.

[0111] In some examples, in order to overcome the defects that the 3DES algorithm may be susceptible to vulnerabilities, session keys (such as unique keys for each session) can be derived instead of using a master key, and keys and counters derived from unique cards can be used as diversified data. For example, each time the contactless card 104 is used in operation, different keys can be used to create a message authentication code (MAC) and perform encryption. This will result in a three-layer password. The session key can be generated by one or more applets and derived using an application transaction counter with one or more algorithms (as defined in EMV 4.3Book 2A1.3.1 Public Session Key Derivation).

[0112] Further, the increments for each card may be unique and assigned by personalization or algorithmically assigned by some identifying information. For example, odd cards may increment by 2 and even cards may increment by 5. In some examples, the increments may also vary in sequential reading, such that a card may increment by 1, 3, 5, 2, 2, ... repeatedly. The specific sequence or algorithmic sequence may be defined at personalization, or in one or more processes derived from a unique identifier. This can make it more difficult for a replay attacker to generalize from a small number of card instances.

[0113] The authentication message may be delivered as the content of a text NDEF record in hexadecimal ASCII format. In another example, the NDEF record may be encoded in hexadecimal format.

[0114] Figure 7 An NDEF short record layout (SR=1) data structure 700 is shown according to an example embodiment. One or more applets may be configured to encode the OTP as a well-known type text tag of NDEF type 4. In some examples, the NDEF message may include one or more records. The applet may be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include, but are not limited to: Tag type: well-known type, text, encoding English (en); Applet ID: D2760000850101; Capabilities: read-only access; Encoding: The authentication message may be encoded as ASCII hexadecimal; Type-length-value (TLV) data may be provided as personalized parameters that can be used to generate the NDEF message. In an embodiment, the authentication template may include a first record with a well-known index for providing the actual dynamic authentication data. The data structure 700 may include the password 122 and any other data provided by the applet 112.

[0115] Figure 8An embodiment of an exemplary computer architecture 800 suitable for implementing various embodiments as previously described is shown. In one embodiment, computer architecture 800 may include or be implemented as a portion of computing architecture 100.

[0116] As used in this application, the terms "system" and "component" are intended to refer to computer-related entities, hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by exemplary computing computer architecture 800. For example, a component can be, but is not limited to, a process running on a processor, a processor, a hard drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer. By way of example, both an application running on a server and a server can be a component. One or more components can reside in a process and / or an execution thread, and a component can be located on a computer and / or distributed between two or more computers. Further, components can be communicatively coupled to each other by various types of communication media to coordinate operations. The coordination can involve unidirectional or bidirectional information exchange. For example, a component can transmit information in the form of a signal transmitted through a communication medium. Information can be implemented as a signal assigned to various signal lines. In such an assignment, each message is a signal. However, alternatively, a further embodiment can adopt a data message. Such a data message can be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0117] The computer architecture 800 includes various common computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, etc. However, the embodiments are not limited to implementation by the computing architecture 800.

[0118] like Figure 8 As shown, computer architecture 800 includes computer 812, which includes processor 802, system memory 804, and system bus 806. Processor 802 can be any of a variety of commercially available processors. Computer 812 can represent computing device 102 and / or authentication server 106.

[0119] The system bus 806 provides an interface for system components, including but not limited to the system memory 804 to the processor 802. The system bus 806 can be any of several types of bus structures, which can further be interconnected with a memory bus (whether or not having a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters can be connected to the system bus 806 via a slot architecture. Example slot architectures can include but are not limited to Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), Network User Bus (NuBus), Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), etc.

[0120] Computer architecture 800 may include or implement various articles of manufacture. Articles of manufacture may include computer-readable storage media to store logic. Examples of computer-readable storage media may include any tangible media capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, etc. Embodiments may also be implemented at least in part as instructions contained in or on a non-transitory computer-readable medium, which may be read and executed by one or more processors to enable the operations described herein to be performed.

[0121] The system memory 804 may include various types of computer-readable storage media in the form of one or more high-speed memory cells, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, bidirectional memory, phase change or ferroelectric memory, silicon-silicon oxide-silicon nitride-silicon oxide-silicon (SONOS) memory, magnetic or optical cards, device arrays such as redundant array of independent disks (RAID) drives, solid-state storage devices (e.g., USB memory, solid-state drive (SSD)), and any other type of storage medium suitable for storing information. Figure 8 In the illustrative embodiment shown, system memory 804 may include non-volatile memory 808 and / or volatile memory 810. A basic input / output system (BIOS) may be stored in non-volatile memory 808.

[0122] The computer 812 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive 814, a magnetic disk drive 816 that reads from or writes to a removable magnetic disk 818, and an optical disk drive 820 that reads from or writes to a removable optical disk 822 (e.g., a CD-ROM or DVD). The hard disk drive 814, magnetic disk drive 816, and optical disk drive 820 may be connected to the system bus 806 via a HDD interface 824, an FDD interface 826, and an optical drive interface 828, respectively. The HDD interface 824 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0123] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. For example, a number of program modules may be stored in the drives and nonvolatile 808 and volatile 810, including an operating system 830, one or more applications 832, other program modules 834, and program data 836. In one embodiment, one or more applications 832, other program modules 834, and program data 836 may include, for example, various applications and / or components of system 100.

[0124] A user may enter commands and information into the computer 812 through one or more wired / wireless input devices (e.g., a keyboard 838 and a pointing device such as a mouse 840). Other input devices may include a microphone, an infrared (IR) remote control, a radio-frequency (RF) remote control, a game pad, a stylus, a card reader, a dongle, a fingerprint reader, a glove, a graphics tablet, a joystick, a keyboard, a retina reader, a touch screen (e.g., capacitive, resistive, etc.), a trackball, a trackpad, a sensor, a stylus, etc. These and other input devices are often connected to the processor 802 through an input device interface 842 coupled to the system bus 806, but may also be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

[0125] A monitor 844 or other type of display device is also connected to the system bus 806 via an interface, such as a video adapter 846. The monitor 844 may be internal or external to the computer 812. In addition to the monitor 844, computers typically include other peripheral output devices, such as speakers, printers, and the like.

[0126] The computer 812 can operate in a networked environment using logical connections via wired and / or wireless communications with one or more remote computers, such as remote computer(s) 848. The remote computer(s) 848 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment appliance, peer device, or other public network node, and typically includes many or all of the elements described relative to the computer 812, although for purposes of simplicity, only a memory / storage device 850 is shown. The depicted logical connections include wired / wireless connections to a local area network 852 and / or a larger network, such as a wide area network 854. Such LAN and WAN networking environments are common in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which can be connected to a global communications network, such as the Internet.

[0127] When used in a LAN 852 networking environment, the computer 812 is connected to the LAN 852 through a wired and / or wireless communication network interface or network adapter 856. The network adapter 856 can facilitate wired and / or wireless communications to the LAN 852, which can also include a wireless access point disposed thereon for communicating with the wireless functionality of the network adapter 856.

[0128] When used in a wide area network 854 networking environment, the computer 812 may include a modem 858, or be connected to a communication server on the wide area network 854, or have other means for establishing communications on the wide area network 854, such as by means of the Internet. The modem 858 may be an internal or external wired and / or wireless device connected to the system bus 806 via the input device interface 842. In a networked environment, program modules or portions thereof depicted relative to the computer 812 may be stored in the remote memory / storage device 850. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

[0129] The computer 812 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged in wireless communications (e.g., IEEE 802.11 over-the-air modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth, among others. TM Wireless technology. Therefore, the communication can be a predefined structure like a conventional network, or just an ad hoc communication between at least two devices. Wi-Fi networks use radio technology called IEEE 802.11 (a, b, g, n, ac, ax, etc.) to provide secure, reliable, and fast wireless connections. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3 related media and functions).

[0130] As previously shown in Figure 1- Figure 7The various elements of the described devices may include various hardware elements, software elements, or a combination of the two. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), memory cells, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements may include software components, programs, applications, computer programs, applications, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, processes, software interfaces, application program interfaces (APIs), instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof. However, determining whether an embodiment is implemented using hardware elements and / or software elements may vary depending on many factors, such as desired computing rates, power levels, thermal tolerances, processing cycle budgets, input data rates, output data rates, memory resources, data bus speeds, and other design or performance constraints desired for a given implementation.

[0131] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium, which represents various logics within a processor, and when read by a machine, the instructions cause the machine to manufacture logic to perform the technology described herein. Such a representation, referred to as an "IP core", may be stored on a tangible machine-readable medium and supplied to various customers or manufacturing facilities to be loaded into a manufacturing machine that manufactures logic or a processor. Some embodiments may be implemented, for example, using a machine-readable medium or article, which may store instructions or instruction sets, which, if executed by a machine, may cause the machine to perform methods and / or operations according to an embodiment. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware and / or software. The machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disk, floppy disk, compact disk read only memory (CD-ROM), compact disk recordable (CD-R), compact disk rewritable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of digital versatile disks (DVDs), magnetic tapes, cassettes, etc. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0132] The foregoing description of example embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of the disclosure. It is intended that the scope of the disclosure is not limited by this detailed description, but rather by the appended claims. Applications filed in the future claiming priority to the present application may claim the disclosed subject matter in different ways, and may generally include any set of one or more limitations as variously disclosed herein or otherwise demonstrated.

Claims

1. A method comprising: receiving, by a merchant web page in a web browser executing on a processor of a mobile device, a selection of a first financial institution among a plurality of financial institutions, wherein the merchant web page includes a plurality of form fields associated with a transaction; generating, by the merchant web page, a uniform resource identifier (URI) directed to an application, wherein the URI includes a session identifier (ID) parameter associated with the transaction and a user ID parameter, wherein at least a portion of the URI is registered with the application and the first financial institution in a mobile operating system (OS) executing on the mobile device; In response to receiving the selection of the URI, launching the application by the mobile OS; authenticating, by the application, login credentials for an account associated with the first financial institution; Associating, by the application, the user ID parameter and the session ID parameter with the account; receiving, by the application, a password from a contactless card associated with the account; receiving, by the application, from a server an indication specifying that the server verified the password; Launching the web browser by the mobile OS based on the instruction; refreshing, by the web browser, the merchant web page, wherein the refreshed merchant web page includes a virtual card number (VCN) in a first form field of the plurality of form fields; and The transaction is processed by the merchant web page based at least in part on the VCN in the first form field.

2. The method according to claim 1, wherein: Associating the user ID parameter and the session ID parameter with the account comprises: The application associates the user ID parameter and the session ID parameter with an account in: (i) an account database stored on the mobile device or (ii) an account database stored by the server, wherein associating the user ID parameter and the session ID parameter with the account associates the account with a browsing session in the web browser for transactions.

3. The method according to claim 1, wherein: The URI also includes a merchant ID parameter and an action ID parameter of a merchant associated with the merchant web page, wherein the VCN is generated by the server based on authentication of the login credentials and verification of the password, wherein use of the VCN is restricted to the merchant associated with the merchant web page, wherein the server transmits the VCN to a merchant server associated with the merchant, and wherein the application loads an authentication page of the application based on the action ID parameter.

4. The method according to claim 3, further comprising: The application transmits the user ID parameter, the session ID parameter, the merchant ID parameter, and the action ID parameter to the server, wherein the server further generates the VCN based on the user ID parameter, the session ID parameter, the merchant ID parameter, and the action ID parameter.

5. The method of claim 1 , further comprising, before processing the transaction: A notification is received by the mobile device from one or more of: (i) a merchant server associated with the merchant web page, or (ii) the server, wherein the notification is received based on the transaction not being processed within a threshold amount of time relative to generation of the VCN.

6. The method according to claim 1, wherein: The URI is a universal link or an App link directed to the application, and the method further includes, before launching the application: Determining, by the mobile OS, that the application is not installed on the mobile device; downloading the application by the mobile OS; and The application is installed on the mobile device by the mobile OS.

7. The method according to claim 1, wherein: The web browser determines that the application is installed on the mobile device based on functions provided by the mobile OS, wherein the refreshed merchant web page further includes: (i) a name associated with the account in a second form field of the plurality of form fields, (ii) an expiration date associated with the VCN in a third form field in the plurality of form fields, (iii) a card verification value (CVV) associated with the VCN in a fourth form field of the plurality of form fields, (iv) a telephone number associated with the account in a fifth form field of the plurality of form fields, and (v) an email address associated with the account in a sixth form field in the plurality of form fields.

8. A non-transitory computer-readable storage medium comprising instructions that, when executed by a processor of a mobile device, cause the processor to: receiving, by a merchant web page in a web browser, a selection of a first financial institution among a plurality of financial institutions, wherein the merchant web page includes a plurality of form fields associated with a transaction; generating, by the merchant web page, a uniform resource identifier (URI) directed to an application, wherein the URI includes a session identifier (ID) parameter associated with the transaction and a user ID parameter, wherein at least a portion of the URI is registered with the application and the first financial institution in a mobile operating system (OS) executing on the mobile device; In response to receiving a selection of the URI, launching, by the mobile OS, the application; authenticating, by the application, login credentials for an account associated with the first financial institution; Associating, by the application, the user ID parameter and the session ID parameter with the account; receiving, by the application, a password from a contactless card associated with the account; receiving, by the application, from a server an indication specifying that the server verified the password; Launching the web browser by the mobile OS based on the instruction; refreshing, by the web browser, the merchant web page, wherein the refreshed merchant web page includes a virtual card number (VCN) in a first form field of the plurality of form fields; and The transaction is processed by the merchant web page based at least in part on the VCN in the first form field.

9. The computer-readable storage medium of claim 8, wherein: Associating the user ID parameter and the session ID parameter with the account comprises: The application associates the user ID parameter and the session ID parameter with an account in: (i) an account database stored on the mobile device or (ii) an account database stored by the server, wherein associating the user ID parameter and the session ID parameter with the account associates the account with a browsing session in the web browser for transactions.

10. The computer-readable storage medium of claim 8, wherein: The URI also includes a merchant ID parameter of a merchant associated with the merchant web page and an action ID parameter, wherein the VCN is generated by the server based on authentication of the login credentials and verification of the password, wherein use of the VCN is restricted to the merchant associated with the merchant web page, wherein the server transmits the VCN to a merchant server associated with the merchant, and wherein the application loads an authentication page of the application based on the action ID parameter.

11. The computer-readable storage medium of claim 10, wherein: The instructions also cause the processor to: The application transmits the user ID parameter, the session ID parameter, the merchant ID parameter, and the action ID parameter to the server, wherein the server further generates the VCN based on the user ID parameter, the session ID parameter, the merchant ID parameter, and the action ID parameter.

12. The computer-readable storage medium of claim 8, wherein: The instructions further cause the processor, before processing the transaction: A notification is received by the mobile device from one or more of: (i) a merchant server associated with the merchant web page, or (ii) the server, wherein the notification is received based on the transaction not being processed within a threshold amount of time relative to generation of the VCN.

13. The computer-readable storage medium of claim 8, wherein: The URI is a universal link or an App Link directed to the application, wherein the instructions further cause the processor, before launching the application: Determining, by the mobile OS, that the application is not installed on the mobile device; downloading the application by the mobile OS; and The application is installed on the mobile device by the mobile OS.

14. The computer-readable storage medium of claim 8, wherein: The web browser determines that the application is installed on the mobile device based on functions provided by the mobile OS, wherein the refreshed merchant web page further includes: (i) a name associated with the account in a second form field of the plurality of form fields, (ii) an expiration date associated with the VCN in a third form field in the plurality of form fields, (iii) a card verification value (CVV) associated with the VCN in a fourth form field of the plurality of form fields, (iv) a telephone number associated with the account in a fifth form field of the plurality of form fields, and (v) an email address associated with the account in a sixth form field in the plurality of form fields.

15. A computing device, comprising: processor; and a memory storing instructions that, when executed by the processor, cause the processor to: receiving, by a merchant web page in a web browser, a selection of a first financial institution among a plurality of financial institutions, wherein the merchant web page includes a plurality of form fields associated with a transaction; generating, by the merchant web page, a uniform resource identifier (URI) directed to an application, wherein the URI includes a session identifier (ID) parameter associated with the transaction and a user ID parameter, wherein at least a portion of the URI is registered with the application and the first financial institution in a mobile operating system (OS) executing on the processor; In response to receiving a selection of the URI, launching, by the mobile OS, the application; authenticating, by the application, login credentials for an account associated with the first financial institution; Associating, by the application, the user ID parameter and the session ID parameter with the account; receiving, by the application, a password from a contactless card associated with the account; receiving, by the application, from a server an indication specifying that the server verified the password; Launching the web browser by the mobile OS based on the instruction; refreshing, by the web browser, the merchant web page, wherein the refreshed merchant web page includes a virtual card number (VCN) in a first form field of the plurality of form fields; and The transaction is processed by the merchant web page based at least in part on the VCN in the first form field.

16. The computing device of claim 15, wherein: Associating the user ID parameter and the session ID parameter with the account comprises: The application associates the user ID parameter and the session ID parameter with an account in: (i) an account database stored by the device or (ii) an account database stored by the server, wherein associating the user ID parameter and the session ID parameter with the account associates the account with a browsing session in the web browser for transactions.

17. The computing device of claim 15, wherein: The URI also includes a merchant ID parameter of a merchant associated with the merchant web page and an action ID parameter, wherein the VCN is generated by the server based on authentication of the login credentials and verification of the password, wherein use of the VCN is restricted to the merchant associated with the merchant web page, wherein the server transmits the VCN to a merchant server associated with the merchant, and wherein the application loads an authentication page of the application based on the action ID parameter.

18. The computing device of claim 17, wherein: The instructions also cause the processor to: The application transmits the user ID parameter, the session ID parameter, the merchant ID parameter and the action ID parameter to the server, wherein the server further generates the VCN based on the user ID parameter, the session ID parameter, the merchant ID parameter and the action ID parameter.

19. The computing device of claim 15, wherein: The instructions further cause the processor, before processing the transaction: A notification is received from one or more of: (i) a merchant server associated with the merchant web page, or (ii) the server, wherein the notification is received based on the transaction not being processed within a threshold amount of time relative to generation of the VCN.

20. The computing device of claim 15, wherein: The URI is a universal link or an App Link directed to the application, wherein the instructions further cause the processor, before launching the application: determining, by the mobile OS, that the application is not installed on the device; downloading the application by the mobile OS; and The application is installed on the device by the mobile OS.

Images