Technology for performing tap-to-pay operations in iOS and Android operating system environments

Abstract

The software development kit (SDK) within the application can receive the selection of a Uniform Resource Locator (URL) in a form regarding a transaction. The SDK can present an SDK interface overlaid on the application. The SDK can receive the selection of interface elements within the SDK interface. The SDK can present commands to the SDK interface. The SDK may receive payment information and a ciphertext from a contactless card and send the ciphertext to the server. The SDK can receive a result indicating that the server has decrypted the ciphertext and present a permission element. The SDK can input payment information into one or more fields of the form and receive an input specifying to process a transaction using the payment information. The application can send the payment information to a server associated with the seller to process the transaction.

Description

Technical Field

[0001] This application claims the benefit and priority of U.S. Provisional Patent Application No. 63 / 352,074, filed on June 14, 2022, entitled "TECHNIQUES TO PERFORM TAP TO PAY OPERATIONS IN THE IOS AND ANDROID OPERATING SYSTEM ENVIRONMENTS", which is hereby incorporated by reference in its entirety.

[0002] This application is a continuation-in-part of U.S. Patent Application No. 17 / 235,082, filed on April 20, 2021, entitled "ON-DEMAND APPLICATIONS TO EXTEND WEB SERVICES", which is hereby incorporated by reference in its entirety.

Background Art

[0003] Account identifiers for payment cards can include long numbers and / or strings. As such, it can be difficult for a user to correctly manually enter the account identifier. In fact, users often make mistakes and enter incorrect account numbers into the payment interface on a computing device. Furthermore, processes have been developed that allow a camera or other malicious entity to capture and identify the account identifier entered into the device, thereby causing a security risk. Additionally, when online transactions are processed using conventional techniques, the transaction is treated as a "card not present (CNP) transaction", which can involve higher processing fees and a greater risk of fraud.

Summary of the Invention

[0004] In one aspect, a method implemented on a computer includes steps of: receiving, by a software development kit (SDK) within an application executing on a device's processor, an instruction to select a uniform resource locator (URL) in a form for a transaction, where the transaction is associated with a seller; presenting, by the SDK, an SDK interface overlaid on the application's interface; receiving, by the SDK, a selection of an interface element within the SDK interface, where the interface element is associated with using payment information associated with a contactless card for the transaction; presenting, by the SDK within the SDK interface based on the selection of the interface element, an orientation instruction indicating the orientation of the contactless card with respect to the device, where the orientation enables wireless communication between the contactless card and the device; receiving, by the SDK, payment information and a ciphertext from the contactless card via wireless communication; sending, by the SDK, the ciphertext to an authentication server; receiving, by the SDK, an authentication result indicating that the authentication server has decrypted the ciphertext; presenting, by the SDK within the SDK interface based on the authentication result, a permission element, where the permission element is selectable to permit the use of payment information for the transaction; inputting, by the SDK based on the selection of the permission element, payment information into one or more fields of the form; receiving, by the application, an input specifying to process the transaction using the payment information input into one or more fields of the form; and sending, by the application based on the input specifying to process the transaction, the payment information to a server associated with the seller to process the transaction.

Brief Description of the Drawings

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

[0006]

Figure 1A

Figure 1B

Figure 2A

Figure 2B

Figure 3A

Figure 3B

Figure 4A

Figure 4B

Figure 4C

Figure 4D

Figure 4E

Figure 4F

Figure 5A

Figure 5B

Figure 5C

Figure 5D

Figure 5E

Figure 5F

Figure 6A

Figure 6B

Figure 6C

Figure 6D

Figure 6E

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12A

Figure 12B

Figure 13

Figure 14

DETAILED DESCRIPTION OF THE INVENTION

[0007] Embodiments can generally be directed to tap-to-pay technology on mobile devices. Specifically, a user can tap a contactless card on their mobile device during a checkout process to pay for goods or services via a mobile application or a web browser application. The extension from tap-to-pay to the mobile web enables full mobile coverage and enhances the value returned to merchants and issuers. The main advantages for retailers can include capturing mobile web shoppers, who are likely to represent the retailer's untapped user base, via streamlined account creation and express checkout, and providing frictionless payment and card-on-file options for retailers who already leverage mobile web technology. The mobile web is a preferred destination for digital marketing campaigns and provides a greater opportunity to acquire new users. The main advantages for issuers can include providing highly secure authentication options for the mobile web, which lacks robust authentication options available in native applications. Tap-to-pay on the mobile web enables high-security solutions across all mobile channels, enhances the offering of tap-to-pay products, and increases their marketability.

[0008] Tap to Pay supports a mobile web experience on a mobile platform (iOS®, Android®) by leveraging App Clip, a JavaScript® software development kit (SDK) with WebNFC™, and / or a native Android SDK that can support NFC functionality. In the case of iOS, embodiments include providing a Tap to Pay SDK that includes functionality and services for running the operations herein on an iOS platform. The SDK may be installed in or otherwise integrated with a host application, such as a native app or a web browser app, and includes App Clip support. The SDK provides functionality to support near-field wireless communication between a mobile device and a contactless card. The SDK may further include functionality for installing a native app when the user is on a website associated with a retailer via an App Clip. Thirdly, the SDK may include functionality to obscure portions of data and / or the display. In embodiments, the SDK may be configured to download and install an application from an app store such as the Apple® App Store or the Google® Play Store.

[0009] In an Android operating system environment, embodiments include utilizing the native Android SDK and / or JavaScript SDK. The JavaScript SDK can be installed on or otherwise integrated with a website, for example, via the website source code. The native Android SDK can be installed in a native Android application. The native Android SDK and / or JavaScript SDK also include functionality to support NFC communication between a mobile device and a contactless card via WebNFC. The native Android SDK and / or JavaScript SDK can also include customizable user interface (UI) functionality and functionality to provide obfuscation. In embodiments, the native Android SDK and / or JavaScript SDK support websites that utilize the Hypertext Transfer Protocol Secure (HTTPS) and support the React® library. Embodiments are not so limited and any UI library may be supported.

[0010] The embodiments disclosed in this specification provide techniques for secure authentication and settlement 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 settlement page, the user can select the option to use an automated settlement process. The user can select a first financial institution from a list of financial institutions presented by the web page. The web page can then 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 the mobile operating system (OS). The application may be an account management application provided by the first financial institution. The browser may include a seller 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 launch the application.

[0011] The application can process the parameters of the URI and determine to output an account authentication page of the application based on the action ID. The authentication page can include one or more functions for authenticating the account via login / password, biometrics, etc. When authenticated, the account application can associate the user ID and session ID with the account (e.g., in an account database stored by a server and / or the application). The application can then instruct the user to tap a contactless card on the device, whereby the contactless card generates a ciphertext. The application can read the ciphertext and transmit the ciphertext to a server associated with the first financial institution for verification. The application may further include the parameters of the URI to the server.

[0012] Next, the server can verify the ciphertext (e.g., at least partially based on decrypting the ciphertext). Once verified, the server can generate a virtual card number (VCN), the expiration date of the VCN, and the card verification value (CVV) of the VCN. The server can restrict the use of the VCN for the seller associated with the transaction based on the seller ID. Next, the server can send the VCN, CVV, expiration date, and contact information (e.g., the name of the account holder, address, phone number, email address, etc.) to the server associated with the seller. The server can further send the session ID and user ID to the seller server. In at least one embodiment, the seller ID includes a URI directed to the seller server. In other embodiments, the seller server is identified based on the seller ID.

[0013] The seller server can receive information from the server associated with the first financial institution and identify the browsing session based on the session ID and / or user ID. Next, the seller server can cause the information received from the server to be entered into one or more form fields on the payment page. In some embodiments, the seller server can push these values to the mobile web browser. In other embodiments, the seller server causes the payment page to be reloaded. When reloaded, the form fields can include payment information (e.g., VCN, expiration date, CVV), as well as any other personal information received from the server associated with the first financial institution (e.g., name, address, email address, phone number, etc.).

[0014] In addition, the server associated with the first financial institution may send the decryption result to the account application. The decryption result can indicate that the server has verified (or decrypted) the ciphertext and generated the VCN. The decryption result can cause the account application to return the device to the mobile web browser. The payment page may be refreshed in the web browser (e.g., by the seller server and / or by the mobile device). When refreshed, payment information and personal information can be entered into the form on the web page. The user can then submit the form to process the payment in the web browser.

[0015] Advantageously, the embodiments disclosed herein provide a secure automated payment process using a contactless card. By leveraging the ciphertext generated by the contactless card, the embodiments of the present disclosure can safely verify the identity of the user while minimizing the risk of fraud. Further, doing so ensures that the automated payment is only executed when the user has access to the contactless card that facilitates ciphertext verification with the server. Additionally, certain restrictions imposed on the web browser can be avoided. For example, some operating systems and / or web browsers may not permit the web browser to communicate directly with the account application. Thus, by using the VCN sent to the seller's backend, these restrictions can be overcome and payment information for the purchase can be automatically imported into the web form. Further, by providing the disclosed automated functionality to the web browser, many different websites can utilize the functionality without the need for integration into all websites or applications. Still further, when transactions are processed in accordance with the embodiments disclosed herein, the transactions are processed as "card present (CP) transactions" which have lower transaction fees and fraud risk than "card not present transactions", thus reducing costs.

[0016] Referring generally to the notations and nomenclature used herein, one or more portions of the following detailed description may be presented with respect to program procedures executed on a computer or a network of computers. The description and representation of these procedures are used by those skilled in the art to most effectively convey the substance of their work to other skilled artisans. A procedure is generally considered here to be a self-consistent series of operations that yields a desired result. These operations are those requiring physical actions of physical quantities. Although not necessarily so, usually these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise operated upon. It will be appreciated that it is sometimes convenient, mainly for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. However, it should be noted that all of these and similar terms should be associated with appropriate physical quantities and are nothing more than convenient labels applied to those quantities.

[0017] Furthermore, these operations are often referred to by terms such as addition or comparison, which are generally associated with mental operations performed by a human operator. However, in any of the operations described herein that form part of one or more embodiments, such capabilities of a human operator are not required or, in most cases, desirable. Rather, these operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by a computer program stored in a digital computer written in accordance with the teachings herein, and / or include digital computers or devices specially configured for the required purpose. The various embodiments also relate to apparatuses or systems for performing these operations. These apparatuses may be specially configured for the required purpose. The necessary structures for the various such machines will become apparent from the given description.

[0018] Reference is now made to the drawings, where like reference numerals are used throughout to refer to like elements. In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding. It will be apparent, however, that the 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 simplify the description. The intention is to cover all modifications, equivalents, and alternatives falling within the scope of the claims.

[0019] The operation of the disclosed embodiments can be further described with reference to the following figures. Some of the figures can include a logical flow. Such figures presented herein can include a particular logical flow, but it should be understood that the logical flow merely provides an example of how the general functionality described herein can be implemented. Further, unless otherwise indicated, a given logical flow need not be executed in the order presented. Still further, in some embodiments, not all of the operations shown in a logical flow are required. Additionally, a given logical flow may be implemented by hardware elements, software elements executed by a processor, or any combination thereof. Embodiments are not limited in this context.

[0020] FIG. 1A and FIG. 1B respectively show examples of graphical user interfaces (GUIs) 100a and 100b according to the embodiments disclosed herein. GUIs 100a, 100b may be presented, for example, during a payment process in a mobile application on a mobile device. The mobile applications shown in FIGS. 1A and 1B represent dedicated applications such as shopping applications provided by a seller or any type of application such as a web browser. FIG. 1A shows an exemplary GUI 100a that can be presented in a mobile application executed on an iOS operating system (OS) and utilizing App Clip. In an embodiment, GUI 100a can include a selectable tap-to-pay interface 102 (e.g., button, icon, interface, etc.), which, as shown in FIGS. 2A-2B, can be selected by a user to cause the user to perform several steps for executing a payment with tap-to-pay. In some embodiments, an open button 104 selectable by the user can be presented to further initiate and execute tap-to-pay. In some embodiments, the application shown in FIG. 1A is a mobile web browser, and the mobile web browser can launch App Clip.

[0021] Figure 1B shows a second example of the GUI 100b that can be provided to a mobile application on the Android OS. Similarly, the GUI 100b can include a tap-to-pay interface 106 (or button or icon) that can be involved in initiating the tap-to-pay function. As described above, the mobile application can be a mobile web browser or a dedicated application such as a shopping application provided by a vendor. In an embodiment where the mobile application is a web browser, the Android web browser can launch another application and / or use WebNFC. Generally, the checkout process shown in the GUIs 100a, 100b can be for the checkout of one or more goods and / or services. More generally, checkout can be providing payment for any purpose.

[0022] Figures 2A-2B show an exemplary sequence flow 200 of GUIs that can be presented during a checkout process using tap-to-pay. In Figures 2A-2B, the sequence flow 200 is executed in a mobile application running in an Apple iOS operating system environment.

[0023] In step 202, the mobile device can present a first GUI to the user on the display. The GUI is associated with the retailer's mobile application and can present several options to the user. In the illustrated example, the GUI includes options for a "Tap to Pay" button or interface 102 that is embedded in the GUI and can be implemented via one or more iOS SDKs. The iOS SDK can include App Clip support and can be embedded in a native application (e.g., a web browser, a dedicated vendor application, etc.) that provides the GUI of FIGS. 2A-2B. More generally, each interface shown in FIGS. 2A-2B can be at least partially supported via the iOS SDK (e.g., in the case of App Clip 216). The "Tap to Pay" button or interface 102 can be configured to launch a Smart App Banner 214 in the mobile application as shown in the GUI in step 204. The Smart App Banner 214 can include selectable options for opening the Tap to Pay App Clip card on the GUI of the mobile application as shown in the third GUI in step 206. For example, the selectable option can be an Open button 104. The Open button 104 can be implemented via the SDK.

[0024] When the Open button 104 is selected, the App Clip 216 can be presented (e.g., can be executed on the mobile device). The App Clip 216 can be supported or provided by the SDK. Selecting the Open button 218 of the App Clip 216 can execute the Tap to Pay function. Thus, in step 206, the mobile device executes the App Clip 216 configured to execute the Tap to Pay function in response to the selection of the Open button 218. However, in some embodiments, the selection of the Open button 104 executes the App Clip 216 without requiring the selection of the Open button 218.

[0025] In step 208, App Clip 216 includes a GUI having an instruction 220 for placing a contactless card on the mobile device. The instruction 220 may be provided by the SDK. Based on the contactless card entering the NFC range, the mobile device that executes App Clip 216 is configured to perform an NFC exchange. In some embodiments, App Clip 216 includes one or more native NFC APIs for performing an NFC exchange, for example when a web page calls App Clip 216. The NFC exchange can include the contactless card sending payment information such as, for example, an account number, name, address, phone number, email, etc. to the mobile device. In some embodiments, the NFC exchange is performed using the SDK. The tap-to-pay App Clip 216 may be configured to present another GUI having a selectable payment response interface 222, which, when selected, enables the user to consent to sharing payment information with the retailer's mobile application in step 210. The user can approve (or reject) the sharing of payment information. In step 212, another GUI including settlement information can be presented to place an order via the order button 224. When the order button 224 is selected, the order can be processed using the payment information received from the contactless card in step 208.

[0026] Figures 3A - 3B show an exemplary sequence flow 300 of a payment process using Tap to Pay on a mobile device operating the Android OS. At step 302, the mobile device can present a first GUI to the user on the display. The GUI can be associated with a retailer's mobile application or website and can present several options to the user. In the illustrated example, the GUI includes a selectable Tap to Pay button 314 or interface that can be embedded in the GUI and implemented via the native Android SDK and / or JavaScript SDK. The use of the JavaScript SDK as an example with respect to Figures 3A - 3B is not limiting of the present disclosure as the present disclosure is equally applicable to other SDKs such as the native Android SDK.

[0027] The Tap to Pay button 314 can be configured to launch a Tap to Pay snippet of code implemented in an SDK such as the JavaScript SDK and / or native Android SDK. More generally, each interface shown in Figures 3A - 3B can be at least partially supported via the JavaScript SDK and / or native Android SDK. The JavaScript SDK and / or native Android SDK can be embedded in a native application (e.g., a web browser, a dedicated vendor application, etc.) that provides the GUI of Figures 3A - 3B. At step 304, the display can be updated with a Tap to Pay SDK bottom sheet 316 rendered on top of the mobile application or web browser. The GUI of step 304 can include another Tap to Pay button such as, for example, Tap to Pay button 318.

[0028] The Tap-to-Pay SDK can present a permission page 320 to permit WebNFC in step 306 in response to the interaction with the Tap-to-Pay button 318 in step 304 for the first user. In other examples, the Tap-to-Pay SDK can present instructions to execute Tap-to-Pay using a contactless card in step 308 in response to the user permitting WebNFC or having previously permitted its use.

[0029] In step 308, the GUI includes instructions 322 to position a contactless card in proximity to the mobile device. Based on the contactless card entering the NFC range, the mobile device executing the Tap-to-Pay JavaScript SDK (and / or the native Android SDK) is configured to perform an NFC exchange. The NFC exchange can include, in step 308, the contactless card sending payment information such as, for example, account number, name, address, phone number, email, etc. to the mobile device. In some embodiments, the JavaScript SDK uses WebNFC to perform the NFC exchange when the web browser 444 does not natively support NFC, for example, when the web page calls the JavaScript SDK. In embodiments where the SDK is the native Android SDK, the native Android SDK includes one or more APIs to support the NFC exchange. The Tap-to-Pay SDK can be configured to present another GUI that enables the user to accept that the payment information is shared with the retailer's mobile application in step 310. The user can use a payment permission interface 324 (e.g., selectable elements) to approve (or reject) the sharing of the information. If the payment permission interface 324 is selected, in step 312, another GUI including settlement information may be presented to place an order via the order button 326. When the order button 326 is selected, the payment can be processed using the payment information received from the contactless card in step 308.

[0030] Figure 4A shows an exemplary computing architecture 400, also referred to as a system, that is consistent with the disclosed embodiments. Although the computing architecture 400 shown in FIGS. 4A - 4E has a limited number of elements in a particular topology, it will be understood that the computing architecture 400 can include more or fewer elements in alternative topologies as desired for a given implementation.

[0031] The computing architecture 100 includes one or more computing devices 402, one or more authentication servers 406, one or more contactless cards 404, and one or more vendor servers 408. The contactless card 404 represents any type of card such as a credit card, debit card, ATM card, gift card, payment card, smart card, etc. The contactless card 404 can include one or more communication interfaces 428 (also referred to herein as a "card reader", "wireless card reader", and / or "wireless communication interface") configured to communicate with the communication interface 428 of the computing device 402 (referred to herein as a "card reader", "wireless card reader", and / or "wireless communication interface") via NFC, EMV standard, or other short - range protocols in wireless communication. Although NFC is used herein as an exemplary communication protocol, the present disclosure is equally applicable to other types of wireless communication such as the EMV standard, Bluetooth, and / or Wi - Fi.

[0032] Computing device 402 represents any number and type of computing devices such as smartphones, tablet computers, wearable devices, laptops, portable gaming devices, virtual computing systems, seller terminals, point-of-sale management systems, servers, desktop computers, etc. A mobile device can be used as an example of computing device 402, but should not be considered as limiting the present disclosure. Authentication server 406 and seller server 408 represent any type of computing device such as a server, workstation, computing cluster, cloud computing platform, virtual computing system, etc. Although not shown for clarity, computing device 402, contactless card 404, authentication server 406, and seller server 408 each include one or more processor circuits for executing, for example, programs, code, and / or instructions.

[0033] As shown, memory 410 of contactless card 404 includes applet 412, counter 414, master key 416, diversification key 418, and unique customer identifier (ID) 424. Applet 412 is executable code configured to perform the operations described herein. Counter 414, master key 416, diversification key 418, and customer ID 424 are used to provide security to system 400 or 600 as will be described in more detail below.

[0034] As shown, memory 430 of authentication server 406 includes authentication application 432 and account database 434. Account database 434 generally includes information regarding account holders (e.g., one or more users), one or more accounts of the account holders, and one or more contactless cards 404 of the accounts. For each contactless card associated with the financial institution associated with authentication server 406, authentication server 406 can store the corresponding instances of master key 416 and counter 414.

[0035] As shown, the memory 438 of computing device 402 includes an instance of operating system 440. Examples of operating systems include Android OS, iOS, macOS®, Linux®, and Windows® operating systems. As shown, operating system 440 includes account application 442 and web browser 444. Account application 442 enables a user to perform various account-related operations such as activating a payment card, viewing account balance, purchasing goods, and processing payments. In some embodiments, a user can authenticate using authentication credentials to access specific features of account application 442. For example, the authentication credentials can include a username (or login) and password, biometric authentication credentials (e.g., fingerprint, face ID, etc.). Web browser 444 is an application that enables computing device 402 to access information via network 454 (e.g., via the Internet). For example, using web browser 444, a user can access one or more resources of seller server 408, such as web page 446 stored in the memory 452 of seller server 408, which can be one of a plurality of web pages hosted by seller server 408 (or another hosting entity). Although a web browser is used herein as an example, the techniques of the present disclosure are equally applicable to other types of applications (e.g., a dedicated shopping application provided by a seller, other types of applications, etc.). Account application 442 and / or web page 446 can provide the GUIs 100a, 100b, and each GUI shown in FIGS. 1A-1B, FIGS. 2A-2B, and FIGS. 3A-3B.Furthermore, the account application 442 and / or the web page 446 can include an iOS SDK (with App Clip), a JavaScript SDK, and / or a native Android SDK to execute the automatic settlement function described herein.

[0036] More generally, when accessing the web page 446 provided by the seller server 408, the user can select one or more products, services, or other items for purchase via the web browser 444. For example, the user may wish to purchase a basketball and a soccer ball and add those items to the shopping cart. To complete the purchase, the web page 446 can include a form with one or more payment fields. The payment fields can include fields such as account number, expiration date, CVV, customer name, customer billing address, customer email address, customer phone number, etc. However, certain restrictions may prevent data from being autofilled into these payment fields. For example, the OS and / or the web browser 444 can restrict the account application 442 from providing data to be autofilled into the form. Also, the user may not have an account with the seller server 408. Advantageously, however, the embodiments disclosed herein provide a solution for overcoming these limitations using an automatic settlement process.

[0037] In some embodiments, the web page 446 can include an SDK that provides selectable elements (e.g., interface 102, tap-to-pay button 314) for initiating an automated checkout process. In some embodiments, the seller can provide an automated checkout process to one or more of a plurality of financial institutions. Thus, if multiple financial institutions are supported, the web page 446 can present a list of financial institutions to the user when the selectable element is selected. The list may be provided via one or more SDKs. The user can then select a financial institution (e.g., the financial institution that issued the contactless card 404) from the list. By doing so, the web page 446 and / or the web browser 444 can generate a Uniform Resource Identifier (URI) 422 (e.g., via the SDK). At least a portion of the URI 422 may be directed to the account application 442 based on the account application 442 being registered with the operating system. Examples of the URI 422 and / or portions thereof may include "example: / / automatedcheckout" or "www.example.com / automatedcheckout". Also, the URI 422 may include one or more parameters. The parameters can include a seller ID parameter, a user ID parameter, a session ID parameter, and an action ID parameter. If only one financial institution is supported, the user does not need to select that institution as a condition for generating the URI 422. The web page 446 and / or the web browser 444 can then provide the URI 422 to the operating system 440 for processing. In some embodiments, the URI 422 is displayed and selected by the user before being provided to the operating system 440.

[0038] The seller ID parameter can be associated with the seller that provides the web page 446 and / or the seller server 408. Thus, the account application 442 can uniquely identify each of the plurality of sellers using each seller ID parameter of the plurality of seller ID parameters. By doing so, the account application 442 can identify the address of the seller server 408 associated with the seller ID and / or the address of any web page 446 associated with the seller ID. The user ID parameter may be a unique identifier of the user associated with the browsing session. Since the user may not be logged in and / or may not have an account with the seller server 408, the user ID can uniquely identify the user. The session ID parameter can identify the browsing session in the web browser 444 with respect to the seller server 408. For example, the session ID parameter can be used to identify a shopping cart, previously visited pages, the current page displayed on the web browser 444 (e.g., the web page 446), and the like. The action ID can generally specify the action or operation to be performed to the account application 442. For example, in some embodiments, the action ID can instruct the account application 442 to open the authentication page and / or the automatic checkout page of the automatic checkout process. Thus, the URI 422 may be a deep link to one or more pages of the account application 442. Examples of the URI 422 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, the URI 422 may be an Android Universal Link or an Apple App Link generated via the associated SDK.

[0039] In some embodiments, the operating system 440, the web browser 444, and / or the web page 446 can determine whether the account application 442 is installed on the computing device 402. The operating system 440, the web browser 444, and / or the web page 446 can use any executable technique to determine whether the account application 442 is installed. For example, in iOS, the operating system 440, the web browser 444, and / or the web page 446 can use the canOpenURL() method to determine whether it can open the URI directed to the account application 442. This method can generally return an indication of whether the URI can be opened. By doing so, the operating system 440, the web browser 444, and / or the web page 446 can determine that the account application 442 is installed on the computing device 402.

[0040] In some operating systems such as the Android OS, the operating system 440, the web browser 444, and / or the web page 446 can (e.g., via one or more SDKs) use the content provider service to determine whether the account application 442 is installed on the device. For example, the operating system 440, the web browser 444, and / or the web page 446 can provide the URI directed to the account application 442 to the content provider service, and the content provider service can return an indication of whether the URI can be opened. By doing so, the operating system 440, the web browser 444, and / or the web page 446 can determine that the account application 442 is installed on the computing device 402.

[0041] If the account application 442 is not installed on the device 402, the operating system 440 can download and install the account application 442 on the device 402. In some embodiments, the account application 442 may 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 442 is installed from an application store onto the computing device 402.

[0042] Using the account application 442 available on the computing device 402, the OS can process the URI 422, whereby the OS opens, accesses, launches, or displays the account application 442. By doing so, the URI 422 including parameters is further provided to the account application 442. Based on the action ID parameter of the URI 422, the account application 442 can open an account authentication page to facilitate the autofill technique described herein.

[0043] In some embodiments, the operating system 440, web browser 444, and / or web page 446 can determine whether the account application 442 is installed on the computing device 402 (e.g., via one or more SDKs) before providing selectable elements for initiating automatic billing and / or before generating the URI 422. In such embodiments, if the account application 442 is not installed on the computing device 402, the web page 446 and / or web browser 444 can refrain from providing selectable elements and / or the automatic billing process. Similarly, in some embodiments, if the account application 442 is not installed on the computing device 402, the web browser 444 and / or web page 446 can refrain from generating the URI 422.

[0044] As described above, in some embodiments, the account application 442 may not be installed on the computing device 402. Thus, in some embodiments, the web page 446 can encode a graphical representation of the URI 422 (including a seller ID parameter, a user ID parameter, and a session ID parameter) that can be displayed on the web page 446 (e.g., via one or more SDKs). The graphical representation can generally be used to initiate the autofill techniques described herein without requiring the user to select the URI 422 and / or select a financial institution from a list. The graphical representation can include a matrix code (also referred to as a matrixed code, a matrix bar code, etc.). Examples of matrix codes include, but are not limited to, Quick Response (QR) codes, App Clip codes, etc. Thus, in such embodiments, a camera (not shown) or other optical reader of the computing device 402 can detect, for example, a matrix code encoding the URI 422 in one or more images. When the matrix code is detected, the operating system 440, the web browser 444, and / or the web page 446 can (e.g., via one or more SDKs) decrypt the URI 422 and determine whether the account application 442 is installed on the computing device 402 based on the URI 422 as described herein. If the account application 442 is not installed on the computing device 402, the account application 442 can be downloaded and installed on the computing device 402. As described above, the downloaded application can include a persistent or non-persistent (e.g., instant application, app clip such as App Clip 216, progressive web application, etc.) version of the account application 442. The downloaded account application 442 can then be accessed, launched, or displayed.As described above, the parameters of URI422 may be provided to the account application 442, and the account application may open an account authentication page to facilitate the autofill technology described herein. Embodiments are not limited to these contexts.

[0045] FIG. 4B shows an embodiment in which the OS accesses URI422 and the account application 442 loads an account authentication page. As described above, URI422 can be accessed based on the selection of URI422 and / or based on detecting a graphical representation (e.g., a matrix code) of the camera URI422. Generally, the account authentication page enables the user to authenticate their account, for example, via login and password, biometrics, etc. The account application 442 and / or the authentication server 406 can authenticate the received authentication credentials.

[0046] Once authenticated, the account application 442 can associate the user ID parameter and session ID parameter of URI422 with the authenticated account (and / or send the user ID parameter and session ID parameter to the authentication server 406 to associate with the account). The account application 442 can then instruct the user to tap the contactless card 404 on the computing device 402 (or bring the contactless card 404 within the communication range of the communication interface 428 of the device 402). By doing so, the applet 412 of the contactless card 404 can generate a ciphertext 426. In some embodiments, WebNFC is used to cause the applet 412 to generate the ciphertext 426.

[0047] The ciphertext 426 may be based on the customer ID 424 of the contactless card 404. The ciphertext 426 may be generated based on any suitable encryption technique. In some embodiments, the applet 412 may include an unencrypted identifier (e.g., customer ID 424, identifier of the contactless card 404, and / or any other unique identifier) as part of a data package that includes the ciphertext 426. In at least one embodiment, the data package is an NDEF file.

[0048] As described above, the computing architecture 400 is configured to implement key diversification to protect data, which can be referred to herein as a key diversification technique. Generally, the authentication server 406 (or another computing device) and the contactless card 404 may be provisioned with the same master key 416 (also referred to as a master symmetric key). More specifically, each contactless card 404 is programmed with a separate master key 416 that has a corresponding pair within the authentication server 406. For example, when the contactless card 404 is manufactured, a unique master key 416 may be programmed into the memory 410 of the contactless card 404. Similarly, the unique master key 416 can be stored in a customer record associated with the contactless card 404 in the account database 434 of the authentication server 406 (and / or stored in a different secure location such as a hardware security module (HSM) 436). The master key 416 may be kept secret from all parties other than the contactless card 404 and the authentication server 406, thereby enhancing security. In some embodiments, the applet 412 of the contactless card 404 can use the master key 416 and data as an encryption algorithm to encrypt and / or decrypt data (e.g., customer ID 424). For example, when the customer ID 424 is encrypted with the master key 416, the ciphertext 426 is obtained. Similarly, the authentication server 406 can use the corresponding master key 416 to encrypt and / or decrypt data associated with the contactless card 404.

[0049] In some embodiments, the master keys 416 of the contactless card 404 and the authentication server 406 can be used with the counter 414 to enhance security by using key diversification. The counter 414 includes a value synchronized between the contactless card 404 and the authentication server 406. For example, the counter 414 can include a number that changes each time data is exchanged between the contactless card 404 and the authentication server 406 (and / or between the contactless card 404 and the computing device 402). Generally, the applet 412 can provide the master key 416, the unique customer ID 424, and a diversification factor as inputs to an encryption algorithm, thereby generating a diversified key 418. In some embodiments, the diversification factor is the counter 414. Thereafter, the diversified key 418 can be used to encrypt some data such as the diversification factor (e.g., the counter 414) or other confidential data. The applet 412 and the authentication server 406 may be configured to encrypt the same type of data to facilitate the decryption and / or verification process of the ciphertext 426.

[0050] More generally, when preparing to send data (e.g., to the authentication server 406 and / or the computing device 402), the applet 412 of the contactless card 404 can increment the counter 414. Next, the applet 412 of the contactless card 404 can provide the master key 416, the customer ID 424, and the counter 414 as inputs to the cryptographic algorithm, and the cryptographic algorithm generates the diversification key 418 as an output. The cryptographic algorithm can include a cryptographic algorithm, a hash-based message authentication code (HMAC) algorithm, a cipher-based message authentication code (CMAC) algorithm, etc. Non-limiting examples of the cryptographic algorithm can include symmetric cryptographic algorithms such as 3DES or AES107, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. Examples of key diversification techniques are described in more detail in U.S. Patent Application No. 16 / 205,119, filed on November 29, 2018. The foregoing patent application is hereby incorporated by reference in its entirety.

[0051] Next, the applet 412 can encrypt some data (e.g., the unique customer ID 424, the counter 414, the command, and / or any other data) using the diversification key 418 and the data as an input to the cryptographic algorithm. For example, by encrypting the unique customer ID 424 and the diversification key 418, an encrypted unique customer ID 424 (e.g., the ciphertext 426) can be obtained.

[0052] In some embodiments, two diversification keys 418 can be generated, for example, based on one or more portions of the input to the cryptographic function. In some embodiments, the two diversification keys 418 are generated based on two different master keys 416, a unique customer ID 424, and a counter 414. In such embodiments, a message authentication code (MAC) can be generated using one of the diversification keys 418, and the MAC can be encrypted using the other of the diversification keys 418. The MAC can be generated based on any suitable data input to the MAC algorithm, such as confidential data, the unique customer ID 424, the counter 414, etc. More generally, the applet 412 and the authentication server 406 can be configured to generate the MAC based on the same data. In some embodiments, the ciphertext 426 is included in a data package such as an NDEF file. The account application 442 can then read the data package containing the ciphertext 426 via the communication interface 428 of the computing device 402.

[0053] Figure 4C shows an embodiment in which the account application 442 sends one or more data packages containing the ciphertext 426 to the authentication server 406. As shown, the account application 442 can further send URI parameters 448 to the authentication server 406. The URI parameters 448 can include a vendor ID parameter, a user ID parameter, and a session ID parameter. The authentication server 406 can then associate the user ID and session ID (if not already done) with the account in the account database 434.

[0054] The authentication server 406 can provide the ciphertext 426 to the authentication application 432 and / or the HSM 436 for verification based at least in part on an instance of the master key 416 stored by the authentication server 406. In some embodiments, the authentication application 432 and / or the HSM 436 can use the unencrypted customer ID 424 provided to the server 406 along with the ciphertext 426 to identify the master key 416 and the counter 414. In some examples, the authentication application 432 can provide the master key 416, the unique customer ID 424, and the counter 414 as inputs to a cryptographic algorithm, which generates one or more diversified keys 418 as outputs. The resulting diversified keys 418 can correspond to the diversified keys 418 of the contactless card 404 and can be used to decrypt the ciphertext 426 and / or verify the MAC when the ciphertext 426 is decrypted. For example, the authentication server 406 can generate a MAC based on the same data as the applet 412, such as confidential data, the unique customer ID 424, and / or the counter 414. If the MAC generated by the authentication server 406 matches the decrypted MAC within the ciphertext 426, the authentication server 406 can verify or authenticate the ciphertext 426.

[0055] Regardless of the verification technique used, the authentication application 432 and / or the HSM 436 can verify or authenticate the ciphertext 426 by successfully decrypting the ciphertext 426 and verifying the MAC.

[0056] If the decryption is successful, the authentication application 432 can send a decryption result indicating that the server has decrypted and / or verified the ciphertext 426 to the account application 442. Further, the authentication server 406 can generate a VCN, expiration date, and CVV for the transaction. The VCN is generally a one-time use account number associated with the account, but the VCN is different from the account number of the contactless card 404. The authentication server 406 may limit the use of the VCN to the seller (e.g., based on the seller ID). By doing so, it is ensured that the VCN can only be used to process payments with the seller. For example, if different sellers request to use the VCN to process transactions, or if the user requests to use the VCN to process transactions with different sellers, the server can reject these transactions. The authentication server 406 can further impose time limits, quantity limits, location limits, etc. on the VCN. The authentication server 406 can reject any transaction that does not comply with these limits. The authentication server 406 can then send the VCN, expiration date, and CVV to the seller server 408. The authentication server 406 can further send the session ID, user ID, and contact information (e.g., username, billing address, shipping address, email address, phone number, etc.) to the seller server 408.

[0057] However, if the authentication application 432 cannot decrypt the ciphertext 426 to obtain the expected result (e.g., the customer ID 424 of the account associated with the contactless card 404), the authentication application 432 does not verify the ciphertext 426. In such an example, the authentication application 432 decides to end the automatic settlement process. The authentication application 432 can send an indication of the failed decryption to the computing device 402.

[0058] Figure 4D shows an embodiment in which the authentication application 432 sends the decryption result 450 to the account application 442 and sends the payment information 420 to the seller server 408. The decryption result 450 generally reflects whether the ciphertext 426 has been decrypted. In the example shown in Figure 4D, the decryption result 450 can indicate that the authentication server 406 has decrypted or verified the ciphertext 426. By doing so, the account application 442 can determine that the ciphertext 426 has been successfully decrypted and / or verified before continuing with the autofill process, thereby improving security.

[0059] The payment information 420 can generally include a VCN, the expiration date of the VCN, the CVV of the VCN, a session ID, a user ID, and the user's contact information (e.g., user name, billing address, shipping address, email address, phone number, etc.). In some embodiments, the URI 422 can include an indication of the address of the seller server 408 as a parameter. Thereby, the authentication server 406 can send the payment information 420 to the seller server 408 based on the address. In other embodiments, the authentication server 406 can store a list of addresses of multiple different sellers, and each entry is indexed by its respective seller ID. In such an example, the authentication server 406 can identify the address of the seller server based on the seller ID within the URI 422.

[0060] Upon receiving, the seller server 408 can identify the user's browsing session based on the user ID and / or session ID. By doing so, the seller server 408 can insert, import, or fill in the received payment information 420 into one or more form fields of the web page 446 corresponding to the session ID and / or user ID. For example, the seller server 408 can import the VCN into the card number form field, the expiration date into the expiration date form field, the CVV into the CVV form field, and so on. More generally, the seller server 408 can store the payment information 420 for later use.

[0061] In response to receiving the decryption result 450, the account application 442 can cause the web browser 444 to be returned to the computing device 402. For example, the account application 442 can instruct the operating system 440 to launch the web browser 444. As another example, the account application 442 can output a selectable element directed to the web browser 444 that causes the operating system 440 to launch the web browser 444 when selected.

[0062] In some embodiments, the user may not need to return to the web browser 444 and / or may not need to complete the purchase using the VCN within a threshold time. The amount of time can be measured based on the time when the VCN was generated. In such embodiments, the authentication server 406 and / or the seller server 408 can send a notification to the computing device 402, which can remind the user to complete the purchase using the VCN. The notification can include a push notification, an email, a text message, and so on. Thus, the authentication server 406 and the seller server 408 can communicate to exchange timing information (e.g., to determine whether the time threshold has been exceeded), indicate whether the purchase has been completed, and cause a notification to be sent to the computing device 402.

[0063] Figure 4E shows an embodiment in which web page 446 is refreshed to include payment information 420 in a form field of web page 446. Web page 446 can be refreshed according to any technique. For example, a user can refresh web page 446 in web browser 444, whereby seller server 408 transmits web page 446 including payment information 420 entered in one or more form fields. As another example, seller server 408 can cause web page 446 to be automatically reloaded into web page 446, for example, a refresh initiated by the server using one or more SDKs supported by web page 446. As yet another example, seller server 408 can send executable instructions (e.g., JavaScript, etc.) to web browser 444 to cause web page 446 to be updated to include payment information 420 in a form field.

[0064] Regardless of the technique used to refresh web page 446, when refreshed, web page 446 includes payment information 420 automatically entered in a form field. For example, the account number field can include the VCN, the expiration date field can include the expiration date, the CVV field can include the CVV, one or more name fields can include the name of the account owner, the billing address field can include the account billing address, the email field can include the account email address, the phone number field can include the account phone number, and so on.

[0065] Furthermore, the refreshed web page 446 further maintains the browsing session from the web browser 444. For example, the web page 446 including a payment form may be rendered within the web browser 444 that enables the user to purchase one or more items previously added to the shopping cart within the web browser 444. Continuing with the above example, the web browser 444 can load the web page 446 that reflects the user's shopping cart including a basketball and a soccer ball.

[0066] Advantageously, the payment information 420 is automatically imported into one or more payment fields of the web page 446 upon refresh. The user can optionally modify the information entered in the form fields. The user can then submit the form including the payment information 420 to complete the purchase.

[0067] FIG. 4F shows an embodiment in which the web browser 444 and / or the web page 446 generates a transaction package 456 for processing a payment using the payment information 420 entered in the form fields of the web page 446. Generally, the transaction package 456 can be transmitted according to the Hypertext Transfer Protocol (HTTP). Upon receipt, the seller server 408 can process the payment of the transaction using the payment information 420. The authentication server 406 can approve the transaction at least in part based on the fact that the VCN is being used as payment for the transaction with the seller since the VCN is associated with or restricted to the seller. The seller server 408 can then create a transaction record 460 of the transaction within the transaction database 458. Subsequently, a confirmation of the transaction may be displayed to the web browser 444.

[0068] Since transactions are processed using the VCN generated by the authentication server 406, even if a transaction is conducted online, the transaction can be processed as a "card-present transaction". Advantageously, doing so reduces the fees for processing the transaction and further reduces the risk of fraud. Thus, in some embodiments, the seller can provide a discount (e.g., a discount rate, a dollar discount, etc.) for purchases completed using the automated mobile web authentication and settlement processes disclosed herein. The embodiments are not limited to these contexts.

[0069] In some embodiments, the seller server 408 can enable the user to create an account after (and / or simultaneously with) the completion of a purchase. In such embodiments, the seller server 408 can create an account based at least in part on the account owner name and contact information (e.g., address, phone number, email address, etc.) received from the authentication server 406. In some embodiments, the seller server 408 can further create an account using the user ID parameter of the URI 422 to identify the user. The user can further provide any other additional information (e.g., login / password, biometrics, other attributes, etc.) to create the account.

[0070] In some embodiments, by storing the payment information 420, the seller server 408 does not need to use the payment information 420 within the transaction package 456 to process the transaction. Instead, in such embodiments, the seller server 408 processes the transaction based on the stored payment information 420, and the transaction package 456 functions as the user's consent to use the stored payment information 420 to process the purchase. However, if the user edits any of the payment information 420 presented on the web page 446, the seller server 408 can process the transaction using the payment information 420 edited by the user.

[0071] Figure 5A is a schematic diagram 500 showing an exemplary embodiment of automatic mobile web browser authentication and settlement using the contactless card 404. As shown, Figure 5A shows a mobile computing device 402 running a web browser 444. The web browser 444 can display a web page such as the web page 446. For example, the web page 446 may be a web page that enables a user to place an order and provide payment information for the order via one or more form fields. As shown, the web page 446 includes a payment form having fields 501-507, where field 501 is a name field, field 502 is an account number field, field 503 is an expiration date field, field 504 is a CVV field, field 505 is an address field, field 506 is an email address field, and field 507 is a phone number field.

[0072] The web page 446 further includes a selectable element 508 that enables the user to initiate an automatic settlement process for server-side entry of payment information into the form fields 201-207. Embodiments are not limited to this context.

[0073] Figure 5B is a schematic diagram 510 showing an embodiment in which the user selects the element 508 to initiate the automatic settlement process. As shown, the web page 446 prompts the user to select a financial institution from a list of financial institutions that support automatic settlement. The user can then select one of the financial institutions from the list. By doing so, the web browser 444 can be caused to generate a URI (e.g., URI 422) directed to the account application 442, thereby causing the computing device 402 to open or display the account application 442. The parameters of the URI may include a seller ID, a user ID, a session ID, and an action ID.

[0074] Figure 5C is a schematic diagram 520 showing an embodiment in which a URI is accessed and an account application 442 is loaded onto a computing device 402. Based on the parameters of the URI (e.g., action ID), the account application 442 outputs an authentication page that requests the user to authenticate the account using a login / password for an auto-settlement process. For example, the user can enter a username in field 521, enter a password in field 522, and select a send button 523 to send the username and password for verification. The account application 442 can then authenticate the credentials (and / or send the credentials to an authentication server 406 for authentication).

[0075] Figure 5D is a schematic diagram 530 reflecting an embodiment in which a user successfully logs into their account. Once authenticated, the account application 442 and / or the authentication server 406 can associate a user ID and a session ID with the authenticated account (e.g., by storing an association instruction in an account database 434). In some embodiments, the account application 442 includes an instance of the account database 434. The account application 442 can then instruct the user to tap a contactless card 404 on the computing device 402.

[0076] Next, the user can tap the contactless card 404 on the computing device 402. Thereby, the contactless card 404 generates a ciphertext verified by the authentication server 406. As shown, the authentication server 406 verifies the ciphertext. By doing so, the authentication server 406 can generate payment information (e.g., VCN, expiration date, CVV, name, address, contact information, session ID, user ID, etc.) and send it to the seller server 408. By doing so, the seller server 408 can associate the payment information with the user ID and / or session ID. Further, the seller server 408 can perform server-initiated filling of the payment information into the form fields of the web page 446.

[0077] The authentication server 406 can further send an instruction to the account application 442 indicating that the server has verified the ciphertext, a VCN has been generated, and the VCN has been sent to the seller server 408 along with other information. Thereafter, the account application 442 can cause the operating system 440 to return to the web browser 444 or bring the web browser 444 to the foreground of the computing device 402. For example, the account application 442 can determine the URI of the web browser 444 based on the seller ID parameter and / or action ID parameter. By doing so, the account application 442 can return the computing device 402 to the web browser 444 to complete the automatic payment.

[0078] FIG. 5E is a schematic diagram 540 showing a web page 446 including data entered in form fields 501-507 by the seller server 408. As shown, the user's name is entered in the name field 501, the VCN is entered in the account number field 502, the expiration date is entered in the expiration date field 503, the CVV is entered in the CVV field 504, the address is entered in the address field 505, the email address is entered in the email address field 506, and the phone number is entered in the phone number field 507.

[0079] The user can then complete the purchase using the send button, whereupon the seller server 408 processes the payment using the VCN and related data. In some embodiments, the user can edit the information entered in form fields 501-507. The embodiments are not limited to this context.

[0080] FIG. 5F is a schematic diagram 550 showing the confirmation web page 446 in the web browser 444. The confirmation page generally reflects that the purchase has been completed using the VCN and related data automatically entered in form fields 501-507.

[0081] Since the transaction is processed using the VCN generated by the authentication server 406, even if the transaction is conducted online, the transaction can be processed as a "card-present transaction". Advantageously, doing so reduces the fees for processing the transaction and further reduces the risk of fraud. The embodiments are not limited to this context.

[0082] FIG. 6A shows an exemplary computing architecture 600, also referred to as a system, that is consistent with the disclosed embodiments. The computing architecture 600 shown in FIGS. 6A-6E has a limited number of elements within a particular topology, but it will be understood that the computing architecture 600 can include more or fewer elements within alternative topologies as desired for a given implementation.

[0083] As shown in FIG. 6A, a web browser 444 running on a computing device 402 can access a web page 446 hosted by a seller server 408. As illustrated, the web page 446 includes an SDK 606. The SDK 606 can be a native Android SDK, a JavaScript SDK, an iOS SDK, and / or an App Clip SDK. In some embodiments, the SDK 606 includes a plurality of application programming interfaces (APIs) for exposing the functionality disclosed herein. Although a web browser 444 is used herein as an example, the techniques of the present disclosure are equally applicable to other types of applications (e.g., one or more seller applications 608, other types of applications, such as a dedicated shopping application provided by a seller). The SDK 606 and / or the web page 446 can provide the GUIs 100a, 100b, and each GUI shown in FIGS. 1A-1B, FIGS. 2, 3, and FIGS. 5A-5F. In some embodiments, the SDK 606 can be an instant application, an App Clip, a progressive web application, or any other non-persistent on-demand application.

[0084] As described above, when accessing the web page 446 provided by the seller server 408, a user can select one or more products, services, or other items for purchase via the web browser 444. For example, a user may wish to purchase a basketball and a soccer ball and add those items to the shopping cart. To complete the purchase, the web page 446 can include a form having one or more payment fields. The payment fields can include fields such as an account number, expiration date, CVV, customer name, customer billing address, customer email address, customer phone number, etc. However, certain restrictions can prevent data from being autofilled into these payment fields, thereby limiting the tap-to-pay functionality. For example, the OS and / or the web browser 444 can restrict the account application 442 from providing data to be autofilled into the form. Also, the user may not have an account with the seller server 408. Advantageously, however, the embodiments disclosed herein provide a solution for overcoming these limitations using an automatic settlement process.

[0085] As described above, the SDK 606 can provide selectable elements such as the URI 610 to initiate an automated tap-to-pay settlement process. The URI 610 represents the interface 102 and / or the tap-to-pay button 314. In some embodiments, selection of the URI 610 initiates the automatic tap-to-pay settlement process. For example, selection of the URI 610 can cause the SDK 606 to open one or more automatic settlement GUIs such as the GUIs shown in FIGS. 1A-3B. Thus, the URI 610 may be a deep link to one or more pages of the SDK 606. In some embodiments, the URI 610 can be an Android Universal Link or an Apple App Link directed to one or more functions provided by the SDK 606.

[0086] In some embodiments, a seller can provide an automated settlement process for one or more of a plurality of financial institutions. Thus, if a plurality of financial institutions are supported, the web page 446 can present a list of financial institutions to the user when a selectable element is selected. The list may be provided via one or more SDKs 606. The user can then select a financial institution (e.g., the financial institution that issued the contactless card 404) from the list. Thus, each financial institution can have its own SDK 606. As such, the selection of the financial institution can cause the web page 446 to generate a URI 610, which can be the same as or similar to the URI 422. At least a portion of the URI 610 may be targeted at the SDK 606 associated with the financial institution based on the SDK 606. Examples of the URI 610 and / or portions thereof may include "example: / / automatedcheckout" or "www.example.com / automatedcheckout". Also, the URI 610 may include one or more parameters. The parameters can include a seller ID parameter, a user ID parameter, a session ID parameter, and an action ID parameter. If only one financial institution is supported, the user does not need to select that institution as a condition for selecting the URI 610. The web page 446 and / or the web browser 444 can then provide the URI 610 to the SDK 606 for processing.

[0087] As described above, the seller ID parameter can be associated with the seller that provides the web page 446 and / or the seller server 408. Thus, the account application 442 can use each seller ID parameter of the plurality of seller ID parameters to uniquely identify each of the plurality of sellers. By doing so, the SDK 606 can identify the address of the seller server 408 associated with the seller ID and / or the address of any web page 446 associated with the seller ID. The user ID parameter may be a unique identifier of the user associated with the browsing session. Since the user may not be logged in and / or may not have an account with the seller server 408, the user ID can uniquely identify the user. The session ID parameter can identify the browsing session in the web browser 444 with respect to the seller server 408. For example, the session ID parameter can be used to identify a shopping cart, previously visited pages, the current page displayed on the web browser 444 (e.g., the web page 446), and the like. The action ID can generally specify an action or operation to be performed on the SDK 606. For example, in some embodiments, the action ID can instruct the SDK 606 to open one or more automatic checkout GUIs, such as the GUIs shown in FIGS. 1A-3B. Thus, the URI 610 may be a deep link to one or more pages of the SDK 606. Examples of the URI 610 may include ''example: / / automatedcheckout?merchID=123&sessID=ABC&userID=XYZ&actID=456'' or ''www.example.com / ?merchID=123&sessID=ABC&userID=XYZ&actID=456''.

[0088] FIG. 6B shows an embodiment in which the user selects URI 610 and the SDK 606 loads a tap-to-pay interface provided by the SDK 606. The tap-to-pay interface includes, for example, an App Clip 216 or a bottom sheet 316.

[0089] In some embodiments, the SDK 606 requests the user to authenticate via a login / password, biometrics, etc. In embodiments where multiple seller web pages 446 are hosted on the seller server 408, the SDK 606 can associate the user ID parameter and session ID parameter of the URI 610 with the authenticated account (and / or can send the user ID parameter and session ID parameter to the authentication server 406 to associate them with the account).

[0090] Once authenticated, the SDK 606 can instruct the user to tap the contactless card 404 on the computing device 402 (or bring the contactless card 404 within the communication range of the communication interface 428 of the device 402). By doing so, the applet 412 of the contactless card 404 can generate a ciphertext 426. In some embodiments, the SDK 606 uses WebNFC to cause the applet 412 to generate the ciphertext 426. Details of the generation of the ciphertext 426 have been described above with reference to FIGS. 4A-4F.

[0091] The SDK 606 can then read a data package containing the ciphertext 426 via the communication interface 428 of the computing device 402. As shown, the SDK 606 can further read payment information 612 from the contactless card 404 (e.g., via NFC). The payment information 612 can include an account number (and / or VCN stored by the contactless card 404) associated with the contactless card 404, an expiration date, and a CVV. In some embodiments, the payment information 612 includes the user's contact information (e.g., username, billing address, shipping address, email address, phone number, etc.). However, in some embodiments, the SDK 606 receives the payment information 612 from the authentication server 406 based on verification of the ciphertext 426.

[0092] FIG. 6C shows an embodiment in which the SDK 606 sends one or more data packages containing the ciphertext 426 to the authentication server 406.

[0093] In some embodiments (e.g., when multiple seller web pages 446 are hosted on the seller server 408), the account application 442 can further send URI parameters 602 from the URI 610 to the authentication server 406. The URI parameters 602 can include a seller ID parameter, a user ID parameter, and a session ID parameter. The authentication server 406 can then associate the user ID and session ID with an account in the account database 434 (if not already done).

[0094] The authentication server 406 can provide the ciphertext 426 to the authentication application 432 and / or the HSM 436 for verification, at least partially based on an instance of the master key 416 stored by the authentication server 406. In some embodiments, the authentication application 432 and / or the HSM 436 can use the unencrypted customer ID 424 provided to the server 406 along with the ciphertext 426 to identify the master key 416 and the counter 414. In some examples, the authentication application 432 can provide the master key 416, the unique customer ID 424, and the counter 414 as inputs to a cryptographic algorithm, which generates one or more diversified keys 418 as outputs. The resulting diversified keys 418 can correspond to the diversified keys 418 of the contactless card 404, and can be used to decrypt the ciphertext 426 and / or verify the MAC when the ciphertext 426 is decrypted. For example, the authentication server 406 can generate a MAC based on the same data as the applet 412, such as confidential data, the unique customer ID 424, and / or the counter 414. If the MAC generated by the authentication server 406 matches the decrypted MAC within the ciphertext 426, the authentication server 406 can verify or authenticate the ciphertext 426.

[0095] Regardless of the verification technique used, the authentication application 432 and / or the HSM 436 can verify or authenticate the ciphertext 426 by successfully decrypting the ciphertext 426 and verifying the MAC.

[0096] However, if the authentication application 432 cannot decrypt the ciphertext 426 to obtain the expected result (e.g., the customer ID 424 of the account associated with the contactless card 404), the authentication application 432 does not verify the ciphertext 426. In such an example, the authentication application 432 decides to terminate the automatic settlement process. The authentication application 432 can send an indication of the failed decryption to the computing device 402.

[0097] Figure 6D shows an embodiment in which the authentication application 432 sends the decryption result 604 to the SDK 606. The decryption result 604 generally reflects whether the ciphertext 426 has been decrypted. In the example shown in Figure 6D, the decryption result 604 can indicate the authentication server 406 that decrypted or verified the ciphertext 426. By doing so, the SDK 606 can determine that the ciphertext 426 has been successfully decrypted and / or verified before continuing the automatic settlement process, thereby improving security. In some embodiments, the authentication server 406 sends the payment information 612 to the SDK 606 together with the decryption result 604 (for example, when the SDK 606 does not receive the payment information 612 from the contactless card 404).

[0098] Based on the decryption result 604, the SDK 606 can provide the payment information 612 to the web page 446. In some embodiments, the SDK 606 can autofill the payment information 612 into one or more form fields within the web page 446. As described above, in some embodiments, the SDK 606 receives permission from the user to share the payment information 612 with the web page 446. For example, the SDK can fill in the account number or VCN of the contactless card 404 into the account number field of the web page 446, fill in the expiration date into the expiration date field of the web page 446, fill in the CVV into the CVV field of the web page 446, fill in the name of the account owner into one or more name fields of the web page 446, fill in the account billing address into the billing address field of the web page 446, fill in the email address into the email field of the web page 446, fill in the phone number into the phone number field of the web page 446, and so on.

[0099] In some embodiments, the decoding result 604 includes one or more instructions among the parameters from the URI 610 (e.g., the seller ID parameter, the user ID parameter, and the session ID parameter). Accordingly, the SDK 606 can compare one or more of the parameters with the parameters of the URI 610. If the comparison results match, the SDK 606 can provide the payment information 612 to the web page 446. Otherwise, if one or more of the comparisons do not match, the SDK 606 may refrain from providing the payment information 612 to the web page 446.

[0100] FIG. 6E shows an embodiment in which the web page 446 is transmitted together with the payment information 612 within the form fields of the web page 446. The user can optionally modify the information entered in the form fields. The user can then send the form including the payment information 612 to the seller server 408 to complete the purchase. The seller server 408 can store a transaction record, such as a transaction record 460 for the purchase, in a transaction database 458 (not shown for clarity).

[0101] FIG. 7 is a timing diagram 700 showing an exemplary sequence for using an SDK 606 integrated into an application such as a web page 446 or a seller application 608 to facilitate one - tap payment according to one or more embodiments disclosed herein. As shown, at line 702, a user can select a URL within an application running on a device such as a computing device 402. The application may be a web browser 444, a dedicated seller application 608, or any other kind of application. In an embodiment where the application is a web browser, a web page such as web page 446 can include the SDK 606. In an embodiment where the application is a native seller application such as seller application 608, the application can include the SDK 606. More generally, the URL can be specified to use one - tap payment for a transaction processed by the application.

[0102] At line 704, the SDK 606 overlays an SDK UI on the application. Examples of the SDK UI are shown in step 204 or step 206 of FIG. 2A. Other examples of the SDK UI include the bottom sheet 316 of FIG. 3A. The SDK UI can include a tap - to - pay element such as an open button 218 or a tap - to - pay button 318. At line 706, the user selects the tap - to - pay element. In response to the selection of the tap - to - pay element at line 706, the SDK 606 presents an orientation instruction to the user at line 708. Exemplary orientation instructions include instruction 220 or instruction 322.

[0103] At line 710, the user can tap the contactless card 404 on the computing device 402. By doing so, the computing device 402 receives payment information such as payment information 420 or payment information 612, and a ciphertext such as ciphertext 426. Payment information generally includes an account number (which may be a virtual account number), an expiration date, and / or a CVV. In some embodiments, the payment information includes other attributes such as the cardholder name, shipping address, billing address, email address, phone number, or any other account attribute within the account database 434. The payment information is shown as being received from the contactless card 404, but the payment information may be received from other sources. Thus, embodiments are not limited to receiving payment information from the contactless card 404.

[0104] At line 712, the SDK 606 sends the ciphertext to an authentication server such as the authentication server 406. At line 714, the authentication server authenticates the ciphertext as described herein, for example, by recreating the diversification key 418 based on the counter 414 of the contactless card 404 and decrypting the ciphertext based on the diversification key. At line 716, the authentication server sends the authentication result to the SDK 606. The authentication result indicates whether the ciphertext has been authenticated. At line 718, the SDK presents a permission element to the user. The permission element enables the user to consent to the use of the payment information as payment for the transaction. Exemplary permission elements include the payment response interface 222 or the payment permission interface 324.

[0105] At line 720, the SDK 606 receives a selection of permission elements from the user. At line 722, the SDK 606 provides payment information to the application. For example, the SDK can autofill payment information into one or more forms within the application. At line 724, the user specifies to process the payment for the transaction using the payment information autofilled into the form within the application. The application can then send the payment information and any other attributes to the seller server to process the transaction.

[0106] FIG. 8 shows one embodiment of a logical flow or routine 800. The logical flow 800 can represent some or all of the operations executed by one or more embodiments described herein. For example, the logical flow 800 can include some or all of the operations for secure tap-to-pay settlement in other applications such as the mobile web browser 444, or a seller application 608 that includes the SDK and uses the contactless card 404. Embodiments are not limited to this context.

[0107] In block 802, the routine 800 receives an indication of a selection of a Uniform Resource Locator (URL) in a form for a transaction by a software development kit (SDK) such as the SDK 606 within an application executing on a processor of a device such as the computing device 402. The URI may be the same as or similar to the URI 422 or URI 610. As described above, in some embodiments, the application may be a web browser 444 that accesses the web page 446 and / or the dedicated seller application 608 to process the transaction. In block 804, the routine 800 presents an SDK interface overlaid on the interface of the application by the SDK 606.

[0108] In block 806, routine 800 receives, by SDK 606, a selection of an interface element within the SDK interface, where the interface element is associated with the use of payment information associated with a contactless card for a transaction. In block 808, routine 800 presents, by SDK 606 within the SDK interface, an orientation instruction indicating the orientation of the contactless card with respect to computing device 402 based on the selection of the interface element, where the orientation enables wireless communication between contactless card 404 and computing device 402. In block 810, routine 800 receives, by SDK 606, payment information 612 and ciphertext 426 from contactless card 404 via wireless communication (e.g., NFC and NDEF formats). In an embodiment where the application is web browser 444, SDK 606 can receive payment information 612 and ciphertext 426 via WebNFC.

[0109] In block 812, routine 800 transmits the ciphertext 426 to the authentication server 406 by means of the SDK 606. In block 814, routine 800 receives an authentication result such as a decryption result 450 or a decryption result 604 indicating that the authentication server 406 has decrypted the ciphertext 426 by means of the SDK 606. In block 816, routine 800 presents a permission element by means of the SDK 606 within the SDK interface based on the authentication result, and the permission element is selectable to permit the use of payment information for a transaction. In block 818, routine 800 inputs payment information into one or more fields of a form by means of the SDK 606 based on the selection of the permission element. As described above, the form may be included in the web page 446 or the seller application 608. In block 820, routine 800 receives an input that designates to process a transaction using the payment information entered into one or more fields of the form by means of the seller application 608 and / or the web browser 444. In block 822, routine 800 transmits the payment information to a server associated with the seller for processing the transaction by means of the seller application 608 and / or the web browser 444 based on the input that designates to process the transaction.

[0110] FIG. 9 shows an embodiment of a logical flow or routine 900. The logical flow 900 can represent some or all of the operations performed by one or more embodiments described herein. For example, the logical flow 900 can include some or all of the operations for secure authentication and settlement in the mobile web browser 444 that uses the contactless card 404. Embodiments are not limited to this context.

[0111] In block 902, routine 900 receives a selection of a first financial institution among a plurality of financial institutions from a seller web page 446 within a web browser 444 that executes on a processor of mobile computing device 402. The seller web page 446 includes a plurality of form fields associated with a transaction. In block 904, routine 900 generates a URI 422 directed to an application such as account application 442 by the seller web page 446. The URI 422 can include a seller identifier (ID) parameter, a session ID parameter associated with the transaction, a user ID parameter, and an action ID parameter, and at least a portion of the URI is registered with the account application 442 within the mobile operating system 440 that executes on the mobile device and the first financial institution.

[0112] In block 906, in response to receiving the selection of URI 422, routine 900 launches account application 442 by mobile operating system 440. In block 908, routine 900 authenticates the login credential information of the account associated with the first financial institution by account application 442. In block 910, routine 900 associates the user ID parameter and the session ID parameter with the account by account application 442. In block 912, routine 900 receives a ciphertext (e.g., ciphertext 426) from contactless card 404 associated with the account by account application 442. In block 914, routine 900 receives an instruction from authentication server 406 indicating that authentication server 406 has verified ciphertext 426 by account application 442. In block 916, routine 900 launches web browser 444 by mobile operating system 440 based on the instruction. In block 918, routine 900 refreshes seller web page 446 by web browser 444. The refreshed seller web page 446 includes a virtual card number (VCN) in a first form field of a plurality of form fields. The remaining form fields can include other attributes such as expiration date, CVV, and customer contact information (e.g., name of the account holder, address, phone number, email address, etc.). In block 920, routine 900 processes a transaction by seller web page 446 based at least in part on the VCN in the first form field.

[0113] Figure 10 shows one embodiment of a logical flow or routine 1000. The logical flow 1000 can represent some or all of the operations performed by one or more embodiments described herein. For example, the logical flow 1000 can include some or all of the operations for secure authentication and settlement in mobile web browser 444 using contactless card 404. The embodiments are not limited to this context.

[0114] In block 1002, routine 1000 generates a URI 422 directed to account application 442 by seller web page 446. URI 422 includes a session identifier (ID) associated with the transaction, a seller ID, an action ID, and a user ID. At least a portion of URI 422 is registered with an application within mobile operating system 440 running on mobile computing device 402 and a financial institution. Seller web page 446 includes a plurality of form fields associated with the transaction. In block 1004, routine 1000 launches account application 442 by mobile operating system 440 based on the selection of URI 422. In block 1006, routine 1000 associates a user ID and a session ID with the account by account application 442 based on the account's qualification information.

[0115] In block 1008, routine 1000 transmits, by account application 442, the seller ID, session ID, user ID, and ciphertext 426 received from contactless card 404 by account application 442 to authentication server 406. In block 1010, routine 1000 receives, by account application 442 from authentication server 406, an instruction indicating that authentication server 406 has verified ciphertext 426. In block 1012, routine 1000 generates, by authentication server 406, based on verification of ciphertext 426, a virtual card number (VCN), an expiration date associated with the VCN, and a card verification value (CVV) associated with the VCN, and authentication server 406 restricts use of the VCN to the seller and / or seller server 408 based on the seller ID. In block 1014, routine 1000 transmits, by authentication server 406, to seller server 408 associated with the web page, based on the seller ID, verification of the ciphertext, and authentication of the qualification information, the VCN, expiration date, CVV, account owner name, and contact information (e.g., address, phone number, email address, etc.). In block 1016, routine 1000 refreshes, by web browser 444, seller web page 446, and the refreshed seller web page 446 includes the VCN, expiration date, CVV, account owner name, and contact information in each of a plurality of form fields. In block 1018, routine 1000 transmits, by seller web page 446, a transaction based at least in part on the VCN, expiration date, CVV, account owner name, and contact information within the form fields.

[0116] FIG. 11 shows an embodiment of a logical flow or routine 1100. Logical flow 1100 can represent some or all of the operations executed by one or more embodiments described herein. For example, logical flow 1100 can include some or all of the operations for secure authentication and settlement in a dedicated seller application that uses contactless card 404. The embodiments are not limited to this context.

[0117] As described above, the web browser 444 represents any kind of application. Thus, FIG. 11 reflects an embodiment in which a dedicated application is used for secure authentication and settlement using the contactless card 404. In block 1102, the routine 1100 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 1104, the routine 1100 generates, by the first application, a Uniform Resource Identifier (URI) targeted at a second application, and at least a part of the URI is registered in the second application and the first financial institution in a mobile operating system (OS) executed on the mobile device. The URI can include parameters of the URI 422, for example, a user ID, a session ID, a seller ID, and / or an action ID.

[0118] In block 1106, routine 1100 launches a second application by the mobile OS based on the URI. In block 1108, routine 1100 receives a ciphertext from a contactless card associated with an account by the second application. The second application can send the ciphertext and any URI parameters to a first server associated with the issuer of the contactless card. In block 1110, routine 1100 generates a virtual card number (VCN), the expiration date of the VCN, and the card verification value (CVV) of the VCN by the first server based on the verification of the ciphertext. In block 1112, routine 1100 sends the VCN, expiration date, CVV, and contact information of the account associated with the contactless card by the first server to a second server associated with the vendor providing the first application. The first server can further send the user ID, session ID, vendor ID, and / or action ID to the second server. In block 1114, routine 1100 generates an account with the vendor by the second server based on the VCN, expiration date, CVV, and contact information. By doing so, the second server can store payment information for later use. In block 1116, routine 1100 processes a transaction of the account with the vendor by the second application based at least in part on the stored VCN, expiration date, and CVV. For example, later, the user can log in to the account with the vendor in the first application. The user can specify to purchase a sandwich from the vendor in the first application. Without the need to provide payment information to the first application, the vendor can process the purchase of the sandwich using the stored VCN, expiration date, and CVV associated with the account.

[0119] FIG. 12A is a schematic diagram 1200 showing an exemplary configuration of a contactless card 404 that can include a payment card such as a credit card, debit card, or gift card issued by a service provider and displayed as a service provider seal 1202 on the front or back of the contactless card 404. In some examples, the contactless card 404 is not related to a payment card and can include, without limitation, an identification certificate. In some examples, the transaction card can include a dual interface contactless payment card, a reward card, and the like. The contactless card 404 can include a substrate 1204 that can include a single layer or one or more laminates made of plastic, metal, and other materials. Exemplary base materials include polyvinyl chloride, polyvinyl acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 404 may have physical characteristics compliant with the ID-1 format of the ISO / IEC 7816 standard; otherwise, the transaction card may comply with the ISO / IEC 14443 standard. However, it is understood that the contactless card 404 according to the present disclosure can have different characteristics, and the present disclosure does not require implementing a transaction card on a payment card.

[0120] The contactless card 404 can also include identification information 1206 displayed on the front and / or back of the card and contact pads 1208. The contact pads 1208 may include one or more pads and may be configured to establish contact with another client device such as an ATM, user device, smartphone, laptop, desktop, or tablet computer via a transaction card. The contact pads are designed according to one or more standards such as the ISO / IEC 7816 standard and can enable communication according to the EMV protocol. The contactless card 404 can also include a processing circuit, antenna, and other components as further described in FIG. 12B. These components may be arranged behind the contact pads 1208 or at other locations on the substrate 1204, such as within different layers of the substrate 1204, and may be electrically and physically coupled to the contact pads 1208. The contactless card 404 can also include a magnetic strip or tape that can be disposed on the back of the card (not shown in FIG. 12A). The contactless card 404 can also include a near field communication (NFC) device coupled to an antenna that can communicate via the NFC protocol. Embodiments are not so limited.

[0121] As shown in FIG. 12B, the contact pads 1208 of the contactless card 404 may include a processing circuit 1210 for storing, processing, and communicating information, including a processor 1212, a memory 410, and one or more communication interfaces 428. It is understood that the processing circuit 1210 may include additional components as necessary to perform the functions described herein, including a processor, memory, error and parity / CRC check units, data encoder, anti-collision algorithm, controller, command decoder, security primitive, and anti-counterfeiting hardware.

[0122] Memory 410 may be a read-only memory, a write-once multiple-read memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 404 may include one or more of these memories. The read-only memory may be programmable at the factory as read-only or one-time programmable. The one-time programmable provides opportunities to read multiple times after being written once. The write-once / multiple-read memory can be programmed after the memory chip leaves the factory. 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 leaving the factory. The read / write memory can also be read multiple times after factory shipment. In some cases, the memory 410 may be an encrypted memory that utilizes an encryption algorithm executed by the processor 1212 for encrypted data.

[0123] Memory 410 can be configured to store one or more applets 412, one or more counters 414, customer ID 424, one or more master keys 416, payment information 612, and one or more diversification keys 418. Payment information 612 can include one or more account numbers, such as the account number of the contactless card 404 and / or a plurality of one-time virtual account numbers. Each account number or virtual account number can include its respective expiration date and CVV. Payment information 612 can further include, for example, user attributes such as name, address, etc. The one or more applets 412 may include one or more software applications configured to execute on one or more contactless cards 404, such as Java (registered trademark) card applets. However, it is understood that the applet 412 is not limited to a Java card applet and may instead be any software application operable on a contactless card or other device having limited memory. The one or more counters 414 may include numerical counters sufficient to store integers. Customer ID 424 can include a unique alphanumeric identifier assigned to the user of the contactless card 404, and the identifier can distinguish the user of the contactless card 404 from other users of other contactless cards 404. In some examples, customer ID 424 can identify both the customer and the account assigned to that customer, and can further identify the contactless card 404 associated with the customer's account.

[0124] Although the processor 1212 and memory elements of the foregoing exemplary embodiments have been described with reference to the contact pads 1208, the present disclosure is not limited thereto. It is understood that these elements may be implemented external to the contact pads 1208, or may be completely separated from the contact pads 1208, or may be implemented as additional elements in addition to the processor 1212 and memory 410 elements disposed within the contact pads.

[0125] In some examples, the contactless card 404 can include one or more antennas 1214. The one or more antennas 1214 may be disposed within the contactless card 404 and around the processing circuit 1210 of the contact pad 1208. For example, the one or more antennas 1214 may be integral with the processing circuit 1210, and the one or more antennas 1214 may be used with an external booster coil. As another example, the one or more antennas 1214 may be external to the contact pad 1208 and the processing circuit 1210.

[0126] In one embodiment, the coil of the contactless card 404 can function as the secondary of a air-core transformer. The terminal can communicate with the contactless card 404 by means of interrupted power or amplitude modulation. The contactless card 404 can infer data transmitted from the terminal using the gap in the power connection of the contactless card 404, which can be functionally maintained via one or more capacitors. The contactless card 404 can return communication by switching the load or load modulation to the coil of the contactless card 404. The load modulation can be detected by the coil of the terminal due to interference. More generally, using the antenna 1214, the processor 1212, and / or the memory 410, the contactless card 404 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communication.

[0127] As described above, the contactless card 404 can be built on a software platform that can operate on other devices with limited memory, such as smart cards or JavaCards, and can securely execute one or more applications or applets. To provide one-time passwords (OTPs) for multi-factor authentication (MFA) in various mobile app-based use cases, an applet 412 can be added to the contactless card. The applet 412 can be configured to respond to one or more requests, such as a short-range wireless data exchange request from a reader such as a mobile NFC reader (e.g., mobile computing device 402 or point-of-sale terminal), and generate an NDEF message containing a cryptographically secure OTP encoded as an NDEF text tag. The NDEF message can include a ciphertext 426 and any other data.

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

[0129] In some examples, one or more applets 412 can be configured to emulate an RFID tag. The RFID tag can include one or more polymorphic tags. In some examples, each time the tag is read, different encrypted data can be presented that can indicate the reliability of the contactless card. Based on one or more applets 412, the NFC reading of the tag can be processed, the data can be sent to a server such as a server of a banking system, and the data can be verified at the server.

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

[0131] One or more counters 414 may be configured to prevent replay attacks. For example, if a ciphertext is obtained and replayed, the ciphertext is immediately rejected if the counter 414 has been read, used, or passed. If the counter 414 has not been used, it may be replayed. In some examples, the counter incremented on the contactless card 404 is different from the counter incremented for a transaction. Since there is no communication between the applets 412 on the contactless card 404, the contactless card 404 cannot determine the application transaction counter 414. In some examples, the contactless card 404 may include a first applet 440-1, which may be a transaction applet, and a second applet 440-2. Each applet 440-1 and 440-2 can include its own counter 414.

[0132] In some examples, the counters 414 may become unsynchronized. In some examples, the counter 414 can be incremented to account for accidental reads that start a transaction, such as a read at a certain angle, but the application does not process the counter 414. In some examples, when the mobile device 10 wakes up, NFC may be enabled and the computing device 402 may be configured to read available tags, but no action is taken in response to the read.

[0133] To maintain synchronization of the counter 414, an application (such as a background application) may be executed that is configured to synchronize with a server of a banking system to detect when the computing device 402 wakes up and advance the counter 414 indicating that a read occurred due to the detection. In other examples, a hashed one-time password may be utilized so that a window of mis-synchronization can be tolerated. For example, the counter 414 may be configured to be advanced if it is within a threshold of 10. However, if it is within a different threshold, such as within 10 or 1000, a request to perform re-synchronization may be processed, which is requested via one or more applications that the user taps, gestures, or otherwise indicates one or more times via the user's device. If the counter 414 increments in the appropriate sequence, the user can be made aware of this.

[0134] The key diversification techniques described herein with reference to the counter 414, the master key, and the diversification key are an example of the encryption and / or decryption of key diversification techniques. This exemplary key diversification technique should not be considered as limiting the present disclosure since the present disclosure is equally applicable to other types of key diversification techniques.

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

[0136] In some examples, to overcome the drawbacks of the 3DES algorithm that is vulnerable, a session key (such as a unique key per session) can be derived, but instead of using a master key, a unique card-derived key and a counter can be used as diversified data. For example, each time the contactless card 404 is in operation, different keys may be used for the creation of the message authentication code (MAC) and the execution of encryption. Thereby, three-layer encryption is obtained. The session key can be generated by one or more applets and can be derived by using an application transaction counter having one or more algorithms (as defined in EMV 4.3 Book 2 A1.3.1 Common Session Key Derivation).

[0137] Furthermore, the increment for each card may be unique, may be assigned by personalization, or may be algorithmically assigned by some identification information. For example, the odd-numbered cards may increase by 2 each time, and the even-numbered cards may increase by 5 each time. In some examples, the increment may also vary in successive readings such that one card can increment successively by repeating 1, 3, 5, 2, 2,.... A specific sequence or algorithm sequence can be defined at the time of personalization or from 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.

[0138] The authentication message can 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.

[0139] Figure 13 shows an NDEF Short Record Layout (SR = 1) data structure 1300 according to an exemplary embodiment. One or more applets may be configured to encode the OTP as a well-known type of 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, the following: tag type: well-known type, text, encoded in English (en); applet ID: D2760000850101; function: read-only access; encoding: the authentication message may be encoded as ASCII hex; type-length-value (TLV) data may be provided as a personalization parameter used to generate the NDEF message. In one embodiment, the authentication template can include a first record having a well-known index for providing actual dynamic authentication data. The data structure 1300 can include the ciphertext 426 and any other optional data provided by the applet 412. In some embodiments, the data structure 1300 can include payment information 612.

[0140] Figure 14 shows an embodiment of an exemplary computer architecture 1400 suitable for implementing various embodiments as described above. In one embodiment, the computer architecture 1400 may be included or implemented as part of the computing architecture 100. More generally, the computer architecture 1400 is configured to implement all of the logic, systems, logical flows, methods, apparatuses, and functions described herein with reference to the previous figures.

[0141] As used in this application, the terms "system" and "component" are intended to refer to any computer-related entity, whether hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing computer architecture 1400. For example, a component can be, but is not limited to, a process running on a processor, a processor, a hard disk drive, a plurality of storage drives (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 the server can be components. One or more components can exist within a process and / or an execution thread, and a component can be localized on one computer and / or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communication media for purposes of coordinating operations. The coordination can include the unidirectional or bidirectional exchange of information. For example, components can communicate information in the form of signals communicated through a communication medium. The information can be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments may alternatively use data messages. Such data messages may be transmitted through various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

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

[0143] As shown in FIG. 14, computer architecture 1400 includes a computer 1412 that includes a processor 1402, a system memory 1404, and a system bus 1406. The processor 1402 can be any of a variety of commercially available processors. The computer 1412 can represent a computing device 402 and / or an authentication server 406.

[0144] The system bus 1406 provides an interface for system components, including but not limited to, the system memory 1404, to the processor 1402. The system bus 1406 can be any of several types of bus structures that can further interconnect, with or without a memory controller, a memory bus, a peripheral bus, and a local bus, using any of a variety of commercially available bus architectures. An interface adapter can be connected to the system bus 1406 via a slot architecture. Exemplary slot architectures can include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and the like.

[0145] Computer architecture 1400 can include or implement various products. The products can include a computer-readable storage medium for storing logic. Examples of computer-readable storage media can include any tangible medium 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 can 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 at least partially implemented as instructions included in a non-transitory computer-readable medium readable and executable by one or more processors to enable the execution of the operations described herein or as instructions on a non-transitory computer-readable medium.

[0146] The system memory 1404 can include various types of computer-readable storage media in the form of one or more high-speed memory units, 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, ovonic memory, phase change or ferroelectric memory, silicon oxide nitride oxide silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as redundant arrays of independent disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD), and any other type of storage medium suitable for storing information). In the illustrated embodiment shown in FIG. 14, the system memory 1404 can include non-volatile 1408 and / or volatile 1410. The basic input / output system (BIOS) can be stored in the non-volatile memory 1408.

[0147] The computer 1412 can 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 1414, a magnetic disk drive 1416 that reads from and writes to a removable magnetic disk 1418, and an optical disk drive 1420 that reads from and writes to a removable optical disk 1422 (e.g., CD-ROM or DVD). The hard disk drive 1414, magnetic disk drive 1416, and optical disk drive 1420 can be connected to the system bus 1406 by an HDD interface 1424, an FDD interface 1426, and an optical disk drive interface 1428, respectively. The HDD interface 1424 for external drive implementation can include at least one or both of universal serial bus (USB) and IEEE 1394 interface technologies.

[0148] The drive and associated computer-readable media provide volatile and / or non-volatile storage such as data, data structures, computer-executable instructions, and the like. For example, one or more applications 1432, other program modules 1434, and program data 1436, such as operating system 1430, can be stored in drive and non-volatile 1408, and volatile 1410. In one embodiment, one or more applications 1432, other program modules 1434, and program data 1436 can include, for example, various applications and / or components of system 400 or system 600.

[0149] A user can input commands and information into computer 1412 via one or more wired / wireless input devices, such as a pointing device, e.g., keyboard 1438 and mouse 1440. Other input devices can include a microphone, infrared (IR) remote control, radio frequency (RF) remote control, game pad, stylus pen, card reader, dongle, fingerprint reader, glove, graphic tablet, joystick, keyboard, retina reader, touch screen (e.g., capacitive, resistive, etc.), trackball, track pad, sensor, stylus, and the like. These and other input devices are often connected to processor 1402 via input device interface 1442 coupled to system bus 1406, but can be connected by other interfaces such as a parallel port, IEEE 1394 serial port, game port, USB port, IR interface, and the like.

[0150] Monitor 1444 or other type of display device is also connected to system bus 1406 via an interface such as video adapter 1446. Monitor 1444 can be internal or external to computer 1412. In addition to monitor 1444, a computer typically includes other peripheral output devices such as speakers, printers, and the like.

[0151] Computer 1412 can operate in a network environment using logical connections via wired and / or wireless communication to one or more remote computers, such as remote computer 1448. Remote computer 1448 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer device, or other common network node, and typically includes many or all of the elements described with respect to computer 1412, but for brevity only memory and / or storage device 1450 is shown. The illustrated logical connections include wired / wireless connections to local area network 1452 and / or a larger network, such as wide area network 1454. Such LAN and WAN networking environments are common in offices and enterprises, facilitating enterprise-scale computer networks such as intranets, all of which can be connected to a global communication network such as the Internet.

[0152] When used in a local area network 1452 network environment, computer 1412 is connected to local area network 1452 via a wired and / or wireless communication network interface or network adapter 1456. Network adapter 1456 can facilitate wired and / or wireless communication to local area network 1452, and the local area network can also include a wireless access point disposed thereon to communicate with the wireless capabilities of network adapter 1456.

[0153] When used in a wide area network 1454 network environment, computer 1412 can include a modem 1458, or be connected to a communication server on the wide area network 1454, or have other means for establishing communication on the wide area network 1454 via the Internet or the like. Modem 1458 can be an internal or external, as well as a wired and / or wireless device, and is connected to system bus 1406 via input device interface 1442. In a networked environment, program modules shown with respect to computer 1412 or a portion thereof can be stored in remote memory and / or storage device 1450. The network connections shown are exemplary, and it will be understood that other means of establishing a communication link between computers can be used.

[0154] Computer 1412 is operable to communicate with wired and wireless devices or entities using standards of the IEEE 802 family, such as a wireless device (e.g., IEEE 802.11 wireless modulation technology) operably arranged for wireless communication. This includes, among other things, at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth (trademark) wireless technologies. Thus, communication can be in a pre-defined structure like a conventional network, or simply an ad-hoc communication between at least two devices. A Wi-Fi network uses a wireless technology called IEEE 802.11 (a, b, g, n, ac, ax, etc.) to provide a secure, reliable, and high-speed wireless connection. Computers can be connected to each other, to the Internet, and to a wired network (using media and functions related to IEEE 802.3) using a Wi-Fi network.

[0155] Referring to FIGS. 1-12, the various elements of the device as described above can include various hardware elements, software elements, or combinations of both. Examples of hardware elements can 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 units, logic gates, registers, semiconductor devices, chips, microchips, chip sets, etc. Examples of software elements can include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, the determination of whether an embodiment is implemented using hardware elements and / or software elements can vary according to any number of factors such as the desired computational speed, power level, heat tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints desired for a given embodiment.

[0156] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium that represents various logic within a processor, which, when read by a machine, causes the machine to create the logic for performing the techniques described herein. Such representations, known as “IP cores,” may be stored on a tangible machine-readable medium and provided to various customers or manufacturing facilities for loading into the manufacturing machines that configure the logic or processor. Some embodiments may be implemented, for example, using a machine-readable medium or article that can store instructions or a set of instructions that, when executed by a machine, can cause the machine to perform the methods and / or operations according to the embodiment. Such machines can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and can be implemented using any suitable combination of hardware and / or software. The machine-readable medium or article can 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 disc read-only memory (CD-ROM), recordable compact disc (CD-R), rewritable compact disc (CD-RW), optical disc, magnetic media, magneto-optical media, removable memory card or disk, various types of digital versatile disc (DVD), tape, cassette, etc. The instructions can 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.

[0157] The foregoing description of the exemplary 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. The scope of the disclosure is intended to be limited not by this detailed description, but rather by the appended claims. Future filed applications claiming priority to this application may claim the subject matter disclosed in a different manner and may generally include any set of one or more of the limitations variously disclosed or otherwise demonstrated herein.

Claims

1. A method implemented on a computer, comprising: receiving, by a software development kit (SDK) within an application executing on a processor of a device, an instruction to select a uniform resource locator (URL) in a form for a transaction, wherein the transaction is associated with a seller; presenting, by the SDK, an SDK interface overlaid on an interface of the application; receiving, by the SDK, a selection of an interface element within the SDK interface, wherein the interface element is associated with using payment information associated with a contactless card for the transaction; presenting, by the SDK within the SDK interface based on the selection of the interface element, an orientation instruction indicating an orientation of the contactless card with respect to the device, wherein the orientation is for enabling wireless communication between the contactless card and the device; receiving, by the SDK, the payment information and a ciphertext from the contactless card via wireless communication; transmitting, by the SDK, the ciphertext to an authentication server; receiving, by the SDK, an authentication result indicating that the authentication server has decrypted the ciphertext; presenting, by the SDK within the SDK interface based on the authentication result, a permission element, wherein the permission element is selectable to permit use of the payment information for the transaction; inputting, by the SDK based on the selection of the permission element, the payment information into one or more fields of the form; receiving, by the application, an input specifying to process the transaction using the payment information input into the one or more fields of the form; transmitting, by the application based on the input specifying to process the transaction, the payment information to a server associated with the seller for processing the transaction; A method comprising the above steps.

2. The method according to claim 1, wherein the application includes a web browser or a native application associated with the seller.

3. The method according to claim 1, wherein the SDK is a non-persistent on-demand application associated with the issuer of the contactless card.

4. The method according to claim 2, wherein the non-persistent on-demand application includes one or more of a JavaScript SDK, an Android SDK, an iOS SDK, or an App Clip.

5. The method according to claim 1, wherein the payment information and the ciphertext are received via near field communication (NFC) and in accordance with the data format of the NFC Forum (NDEF).

6. The method according to claim 1, wherein the payment information includes a virtual account number associated with the contactless card, an expiration date associated with the virtual account number, and a card verification value (CVV) associated with the virtual account number.

7. The method according to claim 1, wherein the URL is a deep link URL or a universal link URL.

8. A non-transitory computer-readable storage medium, the computer-readable storage medium including instructions that, when executed by a processor of a device, cause the processor to, receive an instruction to select a uniform resource locator (URL) in a form for a transaction by a software development kit (SDK) within an application executed on the processor, the transaction being associated with a seller, The instructions cause the processor to, present an SDK interface overlaid on the interface of the application by the SDK, receive a selection of an interface element within the SDK interface by the SDK, the interface element being associated with using payment information associated with a contactless card for the transaction, The instructions cause the processor to, present, by the SDK within the SDK interface, an orientation instruction indicating the orientation of the contactless card with respect to the device based on the selection of the interface element, the orientation being for enabling wireless communication between the contactless card and the device, The instructions cause the processor to, The SDK causes the payment information and the ciphertext to be received from the contactless card via wireless communication. The SDK causes the ciphertext to be sent to the authentication server. The SDK causes an authentication result indicating that the authentication server has decrypted the ciphertext to be received. Based on the authentication result, the SDK in the SDK interface presents a permission element, and the permission element can be selected to permit the use of the payment information for the transaction. The instruction causes the processor to Based on the selection of the permission element, the SDK causes the payment information to be input into one or more fields of the form. The application receives an input that designates to process the transaction using the payment information input into the one or more fields of the form. Based on the input that designates to process the transaction, the application causes the payment information to be sent to a server associated with the seller to process the transaction. A computer-readable storage medium. **Claim 9** The computer-readable storage medium according to claim 8, wherein the application includes a web browser or a native application associated with the seller. **Claim 10** The computer-readable storage medium according to claim 8, wherein the SDK is a non-persistent on-demand application associated with the issuer of the contactless card. **Claim 11** The computer-readable storage medium according to claim 9, wherein the non-persistent on-demand application includes one or more of a JavaScript SDK, an Android SDK, an iOS SDK, or an App Clip. **Claim 12** The computer-readable storage medium according to claim 8, wherein the payment information and the ciphertext are received via near field communication (NFC) and in the data format of the NFC Forum (NDEF). **Claim 13** The computer-readable storage medium according to claim 8, wherein the payment information includes a virtual account number associated with the contactless card, an expiration date associated with the virtual account number, and a card verification value (CVV) associated with the virtual account number. **Claim 14** The computer-readable storage medium according to claim 8, wherein the URL is a deep link URL or a universal link URL.

15. A computing device, a processor, and a memory for storing instructions, wherein when the instructions are executed by the processor, the processor is caused to: receive, by a software development kit (SDK) within an application, an instruction to select a uniform resource locator (URL) in a form for a transaction, the transaction being associated with a seller; The instructions cause the processor to: present, by the SDK, an SDK interface overlaid on an interface of the application; receive, by the SDK, a selection of an interface element within the SDK interface, the interface element being associated with using payment information associated with a contactless card for the transaction; The instructions cause the processor to: present, by the SDK within the SDK interface based on the selection of the interface element, an orientation instruction indicating an orientation of the contactless card with respect to the device, the orientation being for enabling wireless communication between the contactless card and the device; The instructions cause the processor to: receive, by the SDK, the payment information and a ciphertext from the contactless card via wireless communication; send, by the SDK, the ciphertext to an authentication server; receive, by the SDK, an authentication result indicating that the authentication server has decrypted the ciphertext; present, by the SDK within the SDK interface based on the authentication result, a permission element, the permission element being selectable to permit use of the payment information for the transaction; The instructions cause the processor to: input, by the SDK based on the selection of the permission element, the payment information into one or more fields of the form; receive, by the application, an input specifying to process the transaction using the payment information input into the one or more fields of the form; send, by the application based on the input specifying to process the transaction, the payment information to a server associated with the seller for processing the transaction. Computing device.

16. The computing device according to claim 15, wherein the application includes a web browser or a native application associated with the seller.

17. The computing device according to claim 15, wherein the SDK is a non-persistent on-demand application associated with the issuer of the contactless card.

18. The computing device according to claim 16, wherein the non-persistent on-demand application includes one or more of a JavaScript SDK, an Android SDK, an iOS SDK, or an App Clip.

19. The computing device according to claim 15, wherein the payment information and the ciphertext are received via near field communication (NFC) and in accordance with the data format of the NFC Forum (NDEF).

20. The computing device according to claim 15, wherein the payment information includes a virtual account number associated with the contactless card, an expiration date associated with the virtual account number, and a card verification value (CVV) associated with the virtual account number.

Images