Registering an account using a contactless card

Abstract

Account registration using a contactless card. A payment application executing on a device can receive a request to create a payment account using a contactless card. The payment application can receive encrypted data from the contactless card and send the encrypted data to a server associated with the contactless card. The device can receive a push notification from the server and open an account application associated with the contactless card in response to selecting the push notification. The account application can receive confirmation to create the payment account using the contactless card and send the confirmation to the server. The device can open the payment application in response to receiving validation of the encrypted data from the server. The payment application can enter the account data received from the server into form fields and create the payment account using the account data received from the server and entered into the form fields.

Description

Cross - reference to related applications

[0001] This application claims priority to U.S. Patent Application No. 16 / 726,366, entitled "Account Registration Using a Contactless Card," filed on December 24, 2019. The content of the foregoing application is hereby incorporated by reference in its entirety into this specification.

Technical Field

[0002] Embodiments of this specification generally relate to computing platforms, and more specifically, to using contactless cards to register accounts.

Background Art

[0003] Third - party payment services enable users to make payments using different payment accounts. However, registering an account with a third - party payment service using a payment account may expose users to security risks. For example, malicious users may attempt to generate unauthorized accounts on third - party payment services using information that puts the user and / or the user's payment account at risk. Therefore, third - party payment services and / or institutions associated with payment accounts may not be able to distinguish between legitimate and unauthorized attempts to generate third - party payment accounts.

Summary of the Invention

[0004] The embodiments disclosed herein provide a system, method, product, and computer-readable medium for tapping to automatically input card data into a form on a computer device. According to an example, a payment application running on a device can receive an instruction to generate a payment account in the payment application using a contactless card. The payment application can output an instruction to tap the contactless card on the device. The device can receive encrypted data from a communication interface of the contactless card, and the encrypted data is based on a customer identifier and a private key associated with the contactless card. The device can send the encrypted data to a server associated with the contactless card and receive a push notification from the server. The device can open an account application associated with the contactless card in response to receiving a selection of the push notification. The account application can receive a confirmation input to generate a payment account in the payment application using the contactless card. The account application can send an instruction of the confirmation input to the server. The device can open the payment application in response to the payment application receiving verification of the encrypted data from the server. The payment application can input account data received from the server and account data of an account associated with the contactless card into a plurality of form fields of a form displayed in the payment application. The payment application can generate a payment account using the account data received from the server and input into the plurality of form fields.

Brief Description of the Drawings

[0005]

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 1E

Figure 2A

Figure 2B

Figure 2C

Figure 2D

Figure 2E

Figure 2F

Figure 2G

Figure 3A

Figure 3B

Figure 4

Figure 5

Figure 6

Best Mode for Carrying Out the Invention

[0006] The embodiments disclosed in this specification provide secure techniques for generating an account using a contactless card. The account may be a third-party payment account for a third-party payment service that provides a third-party payment application for use on a computing device. A payment account associated with a contactless card provided by a financial institution may be used to fund transactions using the third-party payment account. When attempting to register an account with a third-party payment application, the user may select an option to securely generate the account using the contactless card. In response, the third-party payment application may output an instruction to tap the contactless card on the device. The user may then tap the contactless card on the device. The device may then instruct the contactless card to generate encrypted data and send it to the device. The data generated by the contactless card may be encrypted using key diversification. The device may send the encrypted data received from the contactless card to a first server associated with the financial institution that provided the contactless card.

[0007] The first server can verify the encrypted data received from the contactless card by decrypting the encrypted data. Then, the first server can send a push notification to the device. The device can output the push notification for display on the display. The account application provided by the financial institution can be opened on the device in response to the user selecting the notification. Then, the account application can request the user to provide authentication credentials for accessing the account associated with the contactless card. Then, the account application can request the user to confirm whether the attempted account generation using the third-party payment application is valid. If the user provides an input indicating that the account generation is not valid, the third-party account generation can be restricted to protect the security of the account associated with the contactless card. Otherwise, the account application can send an instruction to the first server indicating that the user has confirmed the validity of the attempted account generation using the third-party payment application.

[0008] The device can output a third - party payment application for display. The third - party payment application can receive account data of an account associated with a contactless card from a first server. The account data can include one or more of a name, surname, email address, address, account number of the contactless card, expiration date of the contactless card, and card verification value (CVV) of the contactless card. The third - party payment application can automatically input the received account data into corresponding form fields of a form provided by the third - party payment application. In response to receiving user input that explicitly indicates to generate an account, the third - party payment application can generate an account using the data received from the server. The record of the generated account may be stored in a second server associated with the third - party payment application. Then, the user can make purchases using the third - party payment application and the underlying account associated with the contactless card.

[0009] Advantageously, by doing so, the security of all devices and related data is improved. For example, verification of encrypted data by the first server provides an additional safeguard for preventing fraud by confirming that the user attempting to create an account has the contactless card. By doing so, it is likely that a fraudulent card cannot generate encrypted data that can be verified by the server, further confirming that the contactless card is not fraudulent. Furthermore, in conventional methods, the user has to manually enter account data into a form. However, by doing so, it may be possible for other users or devices to capture the card data when the user enters the card data into the form. By eliminating the need for the user to manually enter card data into the form, the security of the account data is enhanced.

[0010] Referring generally to the notations and nomenclatures used in this specification, 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 descriptions and representations 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 herein 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 manipulated. 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 merely convenient labels applied to those quantities.

[0011] Furthermore, these operations are often referred to in 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 computer programs written in accordance with the teachings of this specification, and / or include devices or digital computers specially configured for the required purposes. The various embodiments also relate to devices or systems for performing these operations. These devices may be specially configured for the required purposes. The structures required for the various such machines will become apparent from the given description.

[0012] Reference is now made to the drawings, where like reference numerals are used throughout to refer to like elements. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding. It will be evident, however, that the novel embodiments can 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 within the scope of the claims.

[0013] FIG. 1A shows a schematic diagram of an exemplary system 100 in accordance with the disclosed embodiments. As shown, system 100 includes one or more contactless cards 101, one or more mobile devices 110, a server 120, and a third-party server 140. Contactless card 101 represents any type of payment card such as a credit card, debit card, ATM card, gift card, etc. Contactless card 101 can include one or more chips (not shown), such as a radio frequency identification (RFID) chip, configured to communicate with mobile device 110 via NFC, EMV standards, or other short-range protocols in wireless communication. Although NFC is used as an exemplary communication protocol, the present disclosure is equally applicable to other types of wireless communication such as EMV standards, Bluetooth, and / or Wi-Fi. Mobile device 110 represents any type of network-enabled computing device such as a smartphone, tablet computer, wearable device, laptop, portable gaming device, etc. Servers 120, 140 represent any type of computing device such as a server, workstation, computing cluster, cloud computing platform, virtualized computing system, etc.

[0014] As shown, the memory 111 of the mobile device 110 includes an instance of an operating system (OS) 112. Exemplary operating systems 112 include the Android® OS, iOS®, Linux®, and Windows® operating systems. As shown, the OS 112 includes an account application 113 and one or more third-party applications 115. The account application 113 enables a user to perform various account-related operations such as viewing account balances, purchasing goods, and processing payments. In some embodiments, the user can authenticate using authentication credentials to access the account application 113. For example, the authentication credentials can include a username and password, biometric authentication credentials, and the like.

[0015] The third-party application 115 represents any type of payment application that enables a registered user to process transactions using a payment source added by the user. For example, the user can create an account in the third-party application 115 and register to add the contactless card 101 as a payment source. By doing so, the user can use the contactless card 101 (and / or the account associated with the contactless card 101) as a form of payment to make purchases using the third-party application 115. Examples of the third-party application 115 include, but are not limited to, PayPal (registered trademark), Venmo (registered trademark), Apple (registered trademark) Pay, Samsung (registered trademark) Pay, Google (registered trademark) Pay, etc. Advantageously, the embodiments disclosed herein provide secure techniques for creating an account in a third-party application 115 that has the contactless card 101 as a payment source. The third-party server 140 can be associated with a given third-party application 115. The third-party server 140 can generally include a database of account data 144 for user accounts. The account data 144 can include the user's history information, address information, payment information, account number, account expiration date, CVV, login credentials, and any other type of account and / or personal data of multiple users.

[0016] As shown, the memory 102 of the contactless card 101 includes an applet 103, a counter 104, a master key 105, a dispersion key 106, and a unique customer identifier (ID) 107. The customer ID 107 can uniquely identify the user of the financial institution that provides the contactless card 101 and / or the user's account. The applet 103 can be executed on a processor (not shown) of the contactless card 101 to perform various functions described in more detail herein.

[0017] As shown in the figure, the server 120 includes a data store of account data 124 and a memory 122. The account data 124 includes account-related data of a plurality of users and / or accounts. The account data 124 includes at least a master key 105, a counter 104, a customer ID 107, an associated contactless card 101 (including an account number, an expiration date, and a CVV), an account owner name, an account billing address, one or more delivery addresses, one or more virtual card numbers, and historical information of each account. The memory 122 includes a management application 123 and instances of a counter 104, a master key 105, and a distributed key 106 of one or more accounts from the account data 124.

[0018] As described above, the contactless card 101 can be used at least in part to create an account in the account data 144 of the third-party server 140 using the third-party application 115. Generally, a user of the third-party application 115 can explicitly indicate to use the contactless card 101 to create a new account. By doing so, the third-party application 115 outputs an instruction to explicitly tap the contactless card 101 on the device 110. By doing so, the contactless card 101 enters the communication range of the card reader 118 of the mobile device 110 and causes the applet 103 to generate an encrypted customer ID 109. The applet 103 can use any number of techniques to generate the encrypted customer ID 109 based on the encryption algorithm and the customer ID 107.

[0019] As described above, system 100 is configured to perform key distribution to protect data, which can be referred to as key distribution technology herein. Generally, server 120 (or another computing device) and contactless card 101 can be provisioned with the same master key 105 (also referred to as a master symmetric key). More specifically, each contactless card 101 is programmed with a separate master key 105 that has a corresponding pair within server 120. For example, when contactless card 101 is manufactured, a unique master key 105 can be programmed into the memory 102 of contactless card 101. Similarly, the unique master key 105 can be stored in the customer record associated with contactless card 101 within the account data 124 of server 120 (and / or can be stored in a different secure location such as a hardware security module (HSM) 125). The master key 105 may be kept secret from all parties other than contactless card 101 and server 120, thereby enhancing the security of system 100. In some embodiments, applet 103 of contactless card 101 can encrypt and / or decrypt data (e.g., customer ID 107) using the master key 105 and data as input to the encryption algorithm. For example, by encrypting customer ID 107 with master key 105, an encrypted customer ID 109 can be obtained. Similarly, authentication server 120 can encrypt and / or decrypt data associated with contactless card 101 using the corresponding master key 105.

[0020] In other embodiments, the master key 105 of the contactless card 101 and the server 120 can be used with the counter 104 to enhance security using key distribution. The counter 104 includes a value synchronized between the contactless card 101 and the server 120. The counter value 104 can include a number that changes each time data is exchanged between the contactless card 101 and the server 120 (and / or between the contactless card 101 and the mobile device 110). When preparing to send data (e.g., to the server 120 and / or the mobile device 110), the contactless card 101 can increment the counter value 104. The contactless card 101 can then provide the master key 105 and the counter value 104 as inputs to a cryptographic algorithm, which generates a distributed key 106 as an output. The encryption algorithm can include an encryption algorithm, a hash-based message authentication code (HMAC) algorithm, a cipher-based message authentication code (CMAC) algorithm, etc. Non-limiting examples of cryptographic algorithms can include symmetric encryption algorithms such as 3DES or AES128, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. An example of key distribution technology is 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.

[0021] Continuing with the example of key distribution, the contactless card 101 can then use the distributed key 106 and the data as inputs to a cryptographic algorithm to encrypt the customer ID 107. For example, by encrypting the customer ID 107 with the distributed key 106, an encrypted customer ID 109 can be obtained.

[0022] Regardless of the encryption technique used to encrypt customer ID 107, the contactless card 101 can send the encrypted customer ID 109 to the mobile device 110 (e.g., via NFC connection, Bluetooth connection, etc.). When received, the mobile device 110 (e.g., the OS 112 and / or third-party application 115) can send the encrypted customer ID 109 to the server 120 via the network 130. In one embodiment, the encrypted customer ID 109 is sent to an API provided by the management application 123 via a Hypertext Transfer Protocol Secure (HTTPS) application programming interface (API) call.

[0023] When received, the management application 123 can authenticate the encrypted customer ID 109. For example, the management application 123 can attempt to decrypt the encrypted customer ID 109 using a copy of the master key 105 stored in the memory 122 of the authentication server 120. In another example, the management application 123 can provide the master key 105 and the counter value 104 as inputs to a cryptographic algorithm, which can generate a derived key 106 as output. The resulting derived key 106 can correspond to the derived key 106 of the contactless card 101 that can be used to decrypt the encrypted customer ID 109.

[0024] Regardless of the decryption technique used, the management application 123 can decrypt the encrypted customer ID 109 and thereby verify the encrypted customer ID 109 (e.g., by comparing the resulting customer ID 107 with the customer ID stored in the account data 124 and / or based on an indication that decryption using keys 105 and / or 106 was successful). Keys 105, 106 are shown as being stored in the memory 122, but keys 105, 106 may be stored in other locations such as a secure element and / or HSM 125. In such embodiments, the secure element and / or HSM 125 can decrypt the encrypted customer ID 109 using keys 105 and / or 106 and an encryption function. Similarly, the secure element and / or HSM 125 can generate the derived key 106 based on the master key 105 and the counter value 104 as described above.

[0025] However, if the management application 123 cannot decrypt the encrypted customer ID 109 to obtain the expected result (e.g., the customer ID 107 of the account associated with the contactless card 101), the management application 123 does not verify the encrypted customer ID 109. In such an example, the management application 123 sends an indication that the verification failed to a third-party application 115. Thus, the third-party application 115 can refrain from generating the requested account to protect the security of the account associated with the contactless card 101. In general, the management application 123 can condition any action on whether the encrypted customer ID 109 was successfully decrypted.

[0026] Figure 1B shows an embodiment in which the management application 123 verifies the encrypted customer ID 109. More specifically, as shown, in response to the verification (e.g., decryption) of the encrypted customer ID 109, the management application 123 sends a push notification 150 to the mobile device 110. The notification 150 can generally indicate that the account generation attempted using the third-party application 115 needs to be verified. The OS 112 can output the notification 150 for display on the display of the mobile device 110. The user can tap or otherwise select the notification 150, whereby the account application 113 is displayed on the mobile device 110. The user can then provide authentication credentials for accessing the account associated with the contactless card 101. Once authenticated, the account application 113 can request user verification (or confirmation) of the requested account generation. If the user rejects the verification of the requested account generation, the account generation is restricted to protect security.

[0027] Figure 1C shows an embodiment in which the user confirms the account generation requested via the account application 113. When the user confirms the requested account generation, the account application 113 can send a confirmation 151 to the server 120. The confirmation 151 may be sent via an HTTPS API call to the API provided by the management application 123.

[0028] FIG. 1D shows an embodiment in which the management application 123 receives a confirmation 151 from the mobile device 110. As shown, the management application 123 transmits a verification 153 including account data 154 to the third-party application 115. The verification 153 can generally instruct the third-party application 115 that the account generation has been securely verified. The management application 123 can generally transmit the verification 153 in response to receiving the confirmation 151 and based on the successful decryption of the encrypted customer ID 109. Although the decryption of the encrypted customer ID 109 has been described with reference to FIGS. 1A / 1B, the management application 123 can attempt to decrypt the encrypted customer ID 109 at any point in time, such as after receiving the confirmation 151.

[0029] The account data 154 provided by the management application 123 generally includes data describing the user and / or account associated with the contactless card 101. For example, the account data 154 can include the user's name, the user's surname, the user's email address, the user's address, the account number of the contactless card 101, the expiration date of the contactless card 101, and the card verification value (CVV) of the contactless card 101. Embodiments are not limited to this context since the account data 154 can include fewer or more data attributes. For example, in some embodiments, to protect security, the account data 154 can include a virtual account number instead of the account number of the contactless card 101. In such embodiments, the management application 123 can transmit the virtual account number if the third-party application 115 and / or the third-party server 140 do not tokenize the account number (e.g., the account number of the contactless card 101). However, if the account number is tokenized by the third-party application 115 and / or the third-party server 140, the management application 123 can include the account number of the contactless card 101.

[0030] Upon being received, third-party application 115 can automatically input (or populate) account data 154 into multiple form fields of a form output by third-party application 115. For example, the first name / last name may be input into the first name / last name field of the form, the email address may be input into the email address field of the form, some parts of the address (e.g., street number, city, state, postal code) may be input into one or more address fields of the form, the account number may be input into the account number field of the form, the expiration date of the account number may be input into the expiration date field of the form, and the CVV may be input into the CVV field of the form. Then, the user can review and submit the form via third-party application 115 to complete the creation of the account. In some embodiments, the user can modify the data within the form before submitting the form. In some embodiments, third-party application 115 can obfuscate or otherwise suppress the display of one or more elements of account data such as the account number.

[0031] Figure 1E shows an embodiment in which a user submits a form via third-party application 115. As shown, third-party application 115 can send an instruction for a new account 155 including account data 154 to third-party server 140. In some embodiments, new account 155 is created by third-party application 115. In other embodiments, third-party application 115 sends a request to third-party server 140 to generate new account 155, and third-party server 140 generates new account 155. Regardless of the entity that generates new account 155, one or more records of new account 155 using account data 154 may be generated in account database 144 of third-party server 140.

[0032] Next, the user can use the new account 155 to perform purchases, fund transfers, execute transactions, and other financial operations via the third-party application 115 using the contactless card 101 (and / or the virtual account number of the contactless card 101). Advantageously, the embodiments disclosed herein enhance security by adjusting account generation via the third-party application 115 using the contactless card 101, based at least in part on verification of the encrypted customer ID 109, authentication of account eligibility information within the account application 113, and secure communication between entities of the system 100.

[0033] FIG. 2A is a schematic diagram 200 showing an exemplary embodiment of account generation using the contactless card 101. The graphical user interface (GUI) of the third-party application 115 on the mobile device 110 provides a GUI element 201 that enables the user to generate an account in the third-party application 115 using the contactless card 101. When the user selects the GUI 201, the third-party application 115 can output an instruction 202 instructing the user to tap the contactless card 101 on the device 110, as shown in the schematic diagram 210 of FIG. 2B.

[0034] As shown in FIG. 2B, the user can tap the contactless card 101 on the device 110. When the user taps the contactless card 101 on the mobile device 110, the applet 103 of the contactless card 101 generates an encrypted customer ID 109. The applet 103 can then transmit the encrypted customer ID 109 to the mobile device 110 via, for example, NFC. Once received, the third-party application 115 can transmit the encrypted customer ID 109 to the management application 123 via, for example, an HTTPS API call.

[0035] The schematic diagram 220 of FIG. 2C shows a push notification 203 that is output for display on the mobile device 110. As described above, the management application 123 can generate a push notification 203 in response to receiving and / or verifying the encrypted customer ID 109. The management application 123 can then send the push notification 203 to the mobile device 110. When the user selects the push notification 203, the account application 113 can be opened on the mobile device 110.

[0036] FIG. 2D is a schematic diagram 230 showing an embodiment in which the user selects the push notification 203. As shown in FIG. 2D, the account application 113 is opened on the mobile device 110. The account application 113 generally notifies the user that an attempt to open an account using a third-party application 115 has been detected. The account application 113 can provide a GUI element 204 for the user to confirm (or verify) that the attempt is valid, for example, initiated by the user associated with the account. As described above, in some embodiments, the user may need to provide authentication credentials to the account application 113 before the GUI shown in FIG. 2D is output. If the user wants to confirm, the user can select the GUI element 204. Otherwise, the user can select a GUI element 224 that restricts the generation of a new account via the third-party application 115. The account application 113 can send instructions of the selected GUI elements 204, 224 to the management application 123.

[0037] FIG. 2E is a schematic diagram 240 showing an embodiment in which a user selects GUI element 204 to confirm the effectiveness of account generation attempted via third-party application 115. As described above, when the user selects GUI element 204, account application 113 can send an indication that the user has selected GUI element 204 to management application 123. By doing so, management application 123 sends verification to third-party application 115 along with account data 154 associated with contactless card 101. As described above, account data 154 can include the user's name, surname, email address, address, account number of contactless card 101, expiration date of contactless card 101, and card verification value (CVV) of contactless card 101. In some embodiments, instead of the account number, expiration date, and CVV of contactless card 101, a virtual account number, expiration date of the virtual account number, and CVV of the virtual account number may be included.

[0038] As shown, third-party application 115 can include form fields 205-209 and 211. Third-party application 115 automatically enters account data 154 received from management application 123 into form fields 205-209 and 211. For example, as shown, the name field 205 has a name entered, the surname field 206 has a surname entered, the email address field 207 has an email address entered, the street address field 208 has a street address entered, and the address information field 209 has additional address information entered. The specific values shown in FIG. 2E are illustrative and should not be considered limiting of the present disclosure. In some embodiments, the user can optionally modify the values entered in form fields 205-209 and 211. The user can then select the Next button 212 to proceed.

[0039] Figure 2F is a schematic diagram 250 showing an embodiment in which the user selects the Next button 212 in Figure 2E. As shown, the third-party application 115 outputs form fields 213 to 215. The third-party application 115 is entering a card number in the card number field 213, an expiration date in the expiration date field 214, and a CVV in the CVV field 215. Although shown as part of a separate form, in one embodiment, form fields 205 to 209, 211, and 213 to 215 may be part of a single form. As described above, the account number may be the basic account number or the virtual account number of the contactless card 101. Next, the user can select the Next button 216 to continue account generation.

[0040] Figure 2G is a schematic diagram 260 showing an embodiment in which the user selects the Next button 216 in Figure 2F to complete account settings using the third-party application 115. As shown, the third-party application 115 indicates that the account has been successfully created. The user can then use the third-party application 115 to make purchases, process payments, etc. using the contactless card 101 (and / or the virtual number generated for the contactless card 101).

[0041] FIG. 3A shows a contactless card 101 that can include a payment card such as a credit card, debit card, and / or gift card. As shown, the contactless card 101 can be issued by a service provider 305 displayed on the front or back of the card 101. In some examples, the contactless card 101 is not related to a payment card and can include, but is not limited to, an identity certificate. In some examples, the payment card can include a dual interface contactless payment card. The contactless card 101 can include a substrate 310 that can include a single layer or one or more laminations composed of plastic, metal, and other materials. Exemplary substrate 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 101 may have physical characteristics compliant with the ID-1 format of the ISO / IEC 7810 standard; otherwise, the contactless card may comply with the ISO / IEC 14443 standard. However, it is understood that the contactless card 101 according to the present disclosure may have different characteristics, and the present disclosure does not require the contactless card to be implemented in a payment card.

[0042] The contactless card 101 can also include identification information 315 displayed on the front and / or back of the card and contact pads 320. The contact pads 320 can be configured to establish contact with another communication device such as a mobile device 30, a user device, a smartphone, a laptop, a desktop, or a tablet computer. The contactless card 101 can also include a processing circuit, an antenna, and other components not shown in FIG. 3A. These components may be disposed behind the contact pads 320 or at other locations on the substrate 310. The contactless card 101 can also include a magnetic strip or tape that can be disposed on the back of the card (not shown in FIG. 3A).

[0043] As shown in FIG. 3B, the contact pad 320 of the contactless card 101 can include a processing circuit 325 for storing and processing information, including a microprocessor 330 and a memory 102. The processing circuit 325 can include additional components such as a processor, a memory, an error and parity / CRC checker, a data encoder, a collision prevention algorithm, a controller, a command decoder, a security primitive, and anti-counterfeiting hardware, as needed to perform the functions described herein.

[0044] The memory 102 may be a read-only memory, a write-once / read-multiple memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 101 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. One-time programmability provides the opportunity to read multiple times after a single write. The write-once / read-multiple memory may 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 may be programmed and reprogrammed multiple times after leaving the factory. The read / write memory may also be read multiple times after leaving the factory.

[0045] Memory 102 can be configured to store one or more applets 103, a counter 104, a master key 105, a distribution key 106, and one or more customer (or user) IDs 107. The one or more applets 103 may include one or more software applications configured to execute on one or more contactless cards such as Java (registered trademark) card applets. However, it is understood that applet 103 is not limited to Java card applets and may instead be any software application operable on a contactless card or other device having limited memory. Customer ID 107 can include a unique alphanumeric identifier assigned to the user of contactless card 101, and the identifier can distinguish the user of the contactless card from other contactless card users. In some examples, customer ID 107 can identify both the customer and the account assigned to that customer, and can further identify the contactless card 101 associated with the customer's account. In some embodiments, applet 103 can use customer ID 107 as input to a cryptographic algorithm having key 105 and / or 106 to generate an encrypted customer ID 109.

[0046] Although the processor and memory elements of the above exemplary embodiments have been described with reference to contact pads, the present disclosure is not limited thereto. It is understood that these elements may be implemented outside of pad 320, or may be completely separated from the pads, or may be implemented as additional elements in addition to processor 330 and memory 102 elements disposed within contact pad 320.

[0047] In some examples, the contactless card 101 may include one or more antennas 355. The one or more antennas 355 may be disposed within the contactless card 101 and around the processing circuit 325 of the contact pad 320. For example, the one or more antennas 355 may be integral with the processing circuit 325, and the one or more antennas 355 may be used with an external booster coil. As another example, the one or more antennas 355 may be external to the contact pad 320 and the processing circuit 325.

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

[0049] As described above, the contactless card 101 can be built on a software platform operable 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 can be added to the contactless card. The applet can respond to one or more requests, such as a short-range wireless data exchange request from a reader, such as a card reader 118 of device 110, and can be configured to generate an NDEF message containing an encrypted and secure OTP encoded as an NDEF text tag.

[0050] The operation of the disclosed embodiments can be further described with reference to the following figures. Some of the drawings can include a logical flow. It will be understood that such figures presented herein can include a particular logical flow, but the logical flow only provides an example of how the general functions described herein can be implemented. Further, unless otherwise indicated, a given logical flow need not necessarily be executed in the order presented. Further, a given logical flow can be implemented by hardware elements, software elements executed by a processor, or any combination thereof. The embodiments are not limited in this context.

[0051] FIG. 4 shows an embodiment of a logical flow 400. The logical flow 400 can represent some or all of the operations performed by one or more of the embodiments described herein. For example, the logical flow 400 can include some or all of the operations for securely generating an account with a third-party application 115 using the contactless card 101. The embodiments are not limited in this context.

[0052] As shown, the logical flow 400 starts at block 405 where the third-party application 115 receives an instruction to create a payment account using the contactless card 101. For example, the user can select the GUI element 201 of FIG. 2A that instructs to generate an account in the third-party application 115 using the contactless card 101. At block 410, the user can tap the contactless card 101 on the device 110 to cause the contactless card 101 to generate and send encrypted data (e.g., encrypted customer ID 109). The user can tap the contactless card 101 in response to a notification output by the third-party application 115 that instructs the user to tap the contactless card 101 on the device 110. At block 415, the applet 103 can generate the encrypted customer ID 109. The applet 103 can send the encrypted customer ID 109 to the mobile device 110 at block 420.

[0053] In block 425, the mobile device 110 (e.g., the OS 112 and / or the third-party application 115) can send the encrypted customer ID 109 to the management application 123 of the server 120. The third-party application 115 can further send an indication specifying that the encrypted customer ID 109 is part of an attempt to create an account in the third-party application 115. In block 430, the mobile device 110 can receive a push notification from the management application 123. As described above, in some embodiments, the management application 123 can decrypt the encrypted customer ID 109 before sending the push notification to the mobile device 110. In block 435, in response to the user selecting the push notification, the account application 113 is opened. As described above, in some embodiments, the user can provide credentials for accessing their account via the account application 113. The account application 113 can then request an input to confirm whether the attempted account creation via the third-party application 115 is valid.

[0054] In block 440, the third-party application 115 can receive an input indicating that the attempted account generation is valid. For example, the user can select the GUI element 204 in FIG. 2D. In block 445, the third-party application 115 can send a confirmation instruction to the management application 123. In block 450, the OS 112, the account application 113, and / or the third-party application 115 can receive an instruction from the management application 123 indicating that the encrypted customer ID 109 has been verified and the account generation has been approved. As described above, the management application 123 can decrypt the encrypted customer ID 109 in response to the first reception of the encrypted customer ID 109 (e.g., in block 425) and / or at a different time. For example, the management application 123 can decrypt the encrypted customer ID 109 in response to the reception of the confirmation in block 450. Further, the verification can include the account data 154 of the user account associated with the contactless card 101.

[0055] In block 455, the third-party application 115 is opened (if not yet presented on the display of the mobile device 110). In block 460, the third-party application 115 inputs the account data 154 received from the management application 123 into a plurality of form fields. The user can optionally edit the information automatically input into the form fields by the third-party application 115. In block 465, the third-party application 115 creates the user's account using the account data 154 received from the management application 123. For example, the third-party application 115 can cause a new account record to be created in the account data 144 of the third-party server 140.

[0056] FIG. 5 shows an embodiment of a logic flow 500. The logic flow 500 can represent some or all of the operations executed by one or more embodiments described herein. For example, the logic flow 500 can include some or all of the operations for securely and automatically entering data associated with the contactless card 101 into a form. Embodiments are not limited in this context.

[0057] As shown, the logic flow 500 starts at block 510, where the third-party application 115 receives account data 154 from the management application 123. At block 520, the third-party application 115 enters the name received in the account data 154 into the name field of the form. At block 530, the third-party application 115 enters the surname in the received account data 154 into the surname field of the form. At block 535, the third-party application 115 enters the email address in the received account data 154 into the email address field of the form. At block 540, the third-party application 115 enters the address in the received account data 154 into the address field of the form.

[0058] At block 550, the third-party application 115 enters the account number in the received account data 154 into the account number field of the form. The account number may be the account number of the contactless card 101 and / or a virtual account number generated by the server 120. At block 560, the third-party application 115 enters the expiration date in the received account data 154 into the expiration date field of the form. The expiration date may be that of the contactless card 101 and / or the virtual account number. At block 570, the third-party application 115 enters the CVV in the received account data 154 into the CVV field of the form. The CVV may be that of the contactless card 101 and / or the virtual account number.

[0059] In some examples, the disclosure refers to tapping a contactless card. However, the disclosure is not limited to tapping, and it is understood that the disclosure may include other gestures (e.g., waving the card or other movements).

[0060] FIG. 6 shows an embodiment of an exemplary computing architecture 600 that includes a computing system 602 that may be suitable for implementing various embodiments as described above. In various embodiments, the computing architecture 600 may include an electronic device or may be implemented as part of an electronic device. In some embodiments, the computing architecture 600 may represent, for example, a system that implements one or more components of system 100. In some embodiments, the computing system 602 may represent, for example, the mobile device 110 and the server 120 of system 100. The embodiments are not limited in this context. More generally, the computing architecture 600 is configured to implement all of the logic, applications, systems, methods, devices, and functions described herein with reference to FIGS. 1-5.

[0061] As used in this application, the terms "system" and "component" and "module" are intended to refer to any computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 600. For example, a component can be, but is not limited to, a process running on a computer processor, a computer processor, a hard disk drive, a plurality of storage drives (of optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer. As an 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 can be distributed between two or more computers. Further, components can 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 the communication media. The information can be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments can alternatively use data messages. Such data messages can be transmitted through various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0062] Computing system 602 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 computing system 602.

[0063] As shown in FIG. 6, computing system 602 includes a processor 604, a system memory 606, and a system bus 608. Processor 604 can be any of various commercially available computer processors including, but not limited to, AMD's Athlon, Duron, and Opteron processors, ARM's application, embedded, and secure processors, IBM's and Motorola's DragonBall and PowerPC processors, IBM's and Sony's Cell processor, Intel's Celeron, Core, Core (2) Duo, Itanium, Pentium, Xeon, and XScale processors, and similar processors. Dual microprocessors, multi-core processors, and other multiprocessor architectures can also be employed as processor 604.

[0064] System bus 608 provides an interface for system components, including but not limited to system memory 606, to processor 604. System bus 608 can be any of several types of bus structures that can further interconnect, using any of a variety of commercially available bus architectures, into a memory bus, a peripheral bus, and a local bus (with or without a memory controller). Interface adapters can be connected to system bus 608 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.

[0065] System memory 606 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 (e.g., one or more flash arrays), 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 exemplary embodiment shown in FIG. 6, system memory 606 can include non-volatile memory 610 and / or volatile memory 612. The basic input / output system (BIOS) can be stored in non-volatile memory 610.

[0066] Computing system 602 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 (HDD) 614, a magnetic floppy disk drive (FDD) 616 that reads and writes removable magnetic disks 618, and an optical disk drive 620 that reads and writes removable optical disks 622 (e.g., CD-ROM or DVD). HDD 614, FDD 616, and optical disk drive 620 can be connected to system bus 608 by HDD interface 624, FDD interface 626, and optical drive interface 628, respectively. HDD interface 624 for external drive implementation can include at least one or both of universal serial bus (USB) and IEEE 1394 interface technologies. Computing system 602 is generally configured to implement all of the logic, systems, methods, apparatuses, and functions described herein with reference to FIGS. 1-5.

[0067] The drives and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer-executable instructions, etc. For example, several program modules, including operating system 630, one or more application programs 632, other program modules 634, and program data 636, can be stored in drives and memory units 610, 612. In one embodiment, one or more application programs 632, other program modules 634, and program data 636 can include, for example, various applications and / or components of system 100, such as operating system 112, account application 113, third-party application 115, third-party server 140, account data 124, account data 144, and management application 123.

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

[0069] A monitor 644 or other type of display device is also connected to the system bus 608 via an interface such as a video adapter 646. The monitor 644 can be inside or outside the computing system 602. In addition to the monitor 644, a computer typically includes other peripheral output devices such as speakers, printers, and the like.

[0070] Computing system 602 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 648. Remote computer 648 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 computing system 602, but for simplicity only memory / storage device 650 is shown. The illustrated logical connections include wired / wireless connections to a local area network (LAN) 652 and / or a larger network, such as a wide area network (WAN) 654. Such LAN and WAN networking environments are common in offices and enterprises, facilitate enterprise-scale computer networks such as intranets, and all of them can be connected to a global communication network such as the Internet. In an embodiment, network 130 of FIG. 1 is one or more of LAN 652 and WAN 654.

[0071] When used in a LAN networking environment, computing system 602 is connected to LAN 652 via a wired and / or wireless communication network interface or adapter 656. Adapter 656 can facilitate wired and / or wireless communication to LAN 652, which can also include a wireless access point disposed thereon to communicate with the wireless function of adapter 656.

[0072] When used in a WAN networking environment, computing system 602 can include a modem 658, or be connected to a communication server on WAN 654, or have other means for establishing communication on WAN 654 via the Internet or the like. Modem 658 can be an internal or external, as well as a wired and / or wireless device, and is connected to system bus 608 via input device interface 642. In a network environment, program modules shown with respect to computing system 602 or a portion thereof can be stored in remote memory / storage device 650. The network connections shown are exemplary, and it will be understood that other means of establishing a communication link between computers can be used.

[0073] Computing system 602 is operable to communicate with wired and wireless devices or entities that use the IEEE 802 standard family, such as a wireless device operably arranged to operate in wireless communication (e.g., IEEE 802.16 wireless modulation technology). This includes, among other things, at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth (trademark) wireless technologies. Thus, the communication can be in a pre-defined structure similar to 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.11x (a, b, g, n, etc.) to provide a secure, reliable, and high-speed wireless connection. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (using media and functions related to IEEE 802.3).

[0074] Various embodiments can be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements can include processors, microprocessors, circuits, circuit elements (such as 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), logic gates, registers, semiconductor devices, chips, microchips, chip sets, and the like. Examples of software can include software components, programs, applications, computer programs, application programs, system 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. The determination as to whether an embodiment is implemented using hardware elements and / or software elements can vary according to any number of factors such as 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.

[0075] 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, and when read by a machine, the machine creates the logic for performing the techniques described herein. Such representations, known as “IP cores,” may be stored on a tangible machine-readable medium and supplied to various customers or manufacturing facilities for loading onto a manufacturing machine that creates 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 embodiments. 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 discs (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.

[0076] 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 exact forms 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 subject matter disclosed in a different manner and can generally include any set of one or more of the limitations variously disclosed herein or otherwise demonstrated.

Claims

1. 1. A method comprising: receiving, by a payment application executing on a processor of the device, instructions indicating to create a payment account with said payment application using a contactless card; receiving, by the processor, encrypted data from the contactless card; transmitting, by the processor, the encrypted data to a server associated with an issuer of the contactless card; opening, by the processor, an account application associated with the issuer of the contactless card; receiving, by the account application, a confirmation input indicating that the contactless card should be used to create the payment account with the payment application; sending, by the account application, an instruction to enter the verification to the server associated with the issuer of the contactless card; opening the payment application in response to receiving, by the processor, verification of the encrypted data from the server associated with the issuer of the contactless card; generating, by the payment application, the payment account using account data generated by the server associated with the issuer of the contactless card.

2. the account data relates to an account associated with the contactless card, and the payment application is distinct from the account application, the method comprising:

2. The method of claim 1, further comprising receiving, by the payment application after opening the payment application and before creating the payment account, the account data from the server associated with the issuer of the contactless card.

3. 3. The method of claim 2, wherein the account data for the account includes: (i) a first name, (ii) a last name, (iii) an email address, (iv) an address, (v) an account number for the contactless card, (vi) an expiration date for the contactless card, and (vii) a card verification value (CVV) for the contactless card.

4. The method includes, after receiving the account data, entering, by the payment application, the name into a name form field of a plurality of form fields of a form in the payment application; entering, via the payment application, the last name into a last name form field of the plurality of form fields; entering, via the payment application, the email address into an email address form field of the plurality of form fields; entering, via the payment application, the address into an address form field of the plurality of form fields; entering, via the payment application, the account number into an account number form field of the plurality of form fields; entering, by the payment application, the expiration date into an expiration date form field of the plurality of form fields; inputting, by the payment application, the CVV into a CVV form field of the plurality of form fields; The method of claim 3 , further comprising receiving, by the payment application, input indicating to submit the form to create the payment account.

5. 2. The method of claim 1, wherein the confirmation input instruction is sent via a HyperText Transfer Protocol Secure (HTTPS) Application Programming Interface (API) call to an API of the server associated with the issuer of the contactless card.

6. After transmitting the encrypted data and before opening the account application, receiving, by the processor, a push notification indicating providing the confirmation input; The method of claim 1 , further comprising receiving, by the processor, an input selecting the push notification, wherein the application is opened based on the input selecting the push notification.

7. wherein the account data for the account includes a virtual account number generated for the account associated with the contactless card, an expiration date for the virtual account number, and a card verification value (CVV) for the virtual account number, and the method further comprises: After opening the payment application and prior to creating the payment account, displaying, by the payment application, the virtual account number in an account number form field of a plurality of form fields of a form in the payment application; displaying, by the payment application, the expiration date in an expiration date form field of the plurality of form fields of the form; displaying, by the payment application, the CVV in a CVV form field of the plurality of form fields of the form; The method of claim 1 , further comprising: receiving, by the payment application, input indicating to submit the form to create the payment account.

8. A non-transitory computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to: receiving, by a payment application, instructions indicating to create a payment account with said payment application using the contactless card; receiving encrypted data from the contactless card; transmitting the encrypted data to a server associated with an issuer of the contactless card; opening an account application associated with the issuer of the contactless card; receiving, by the account application, a confirmation input indicating that the contactless card should be used to create the payment account with the payment application; sending, by the account application associated with the issuer of the contactless card, an instruction to enter the verification to the server; in response to receiving validation of the encrypted data from the server associated with the issuer of the contactless card, opening the payment application; and generating, by the payment application, the payment account using account data generated by the server associated with the issuer of the contactless card.

9. The account data relates to an account associated with the contactless card, and the payment application is different from the account application, and the instructions cause the processor to:

9. The computer-readable storage medium of claim 8, further comprising the step of: after opening the payment application and before creating the payment account, receiving, by the payment application, the account data from the server associated with the issuer of the contactless card.

10. 10. The computer-readable storage medium of claim 9, wherein the account data for the account includes (i) a first name, (ii) a last name, (iii) an email address, (iv) an address, (v) an account number for the contactless card, (vi) an expiration date for the contactless card, and (vii) a card verification value (CVV) for the contactless card.

11. The instructions cause the processor to, after receiving the account data: entering, by the payment application, the name into a name form field of a plurality of form fields of a form in the payment application; entering, via the payment application, the last name into a last name form field of the plurality of form fields; entering, via the payment application, the email address into an email address form field of the plurality of form fields; entering, via the payment application, the address into an address form field of the plurality of form fields; entering, via the payment application, the account number into an account number form field of the plurality of form fields; entering, by the payment application, the expiration date into an expiration date form field of the plurality of form fields; inputting, by the payment application, the CVV into a CVV form field of the plurality of form fields; 11. The computer-readable storage medium of claim 10, further comprising: receiving, by the payment application, input indicating to submit the form to create the payment account.

12. 9. The computer-readable storage medium of claim 8, wherein the confirmation input instruction is sent via a HyperText Transfer Protocol Secure (HTTPS) Application Programming Interface (API) call to an API of the server associated with the issuer of the contactless card.

13. The instructions cause the processor to, after transmitting the encrypted data and prior to opening the account application: receiving a push notification indicating providing said confirmation input; 10. The computer-readable storage medium of claim 8, further comprising: receiving an input selecting the push notification, the application being opened based on the input selecting the push notification.

14. The account data for the account includes a virtual account number generated for the account associated with the contactless card, an expiration date for the virtual account number, and a card verification value (CVV) for the virtual account number, and the instructions cause the processor to, after opening the payment application and prior to creating the payment account: displaying, by the payment application, the virtual account number in an account number form field of a plurality of form fields of a form in the payment application; displaying, by the payment application, the expiration date in an expiration date form field of the plurality of form fields of the form; displaying, by the payment application, the CVV in a CVV form field of the plurality of form fields of the form; 10. The computer-readable storage medium of claim 8, further comprising: receiving, by the payment application, input indicating to submit the form to create the payment account.

15. 1. A computing device comprising: A processor; and a memory storing instructions that, when executed by the processor, cause the processor to: receiving, by a payment application, instructions indicating to create a payment account with said payment application using the contactless card; receiving encrypted data from the contactless card; transmitting the encrypted data to a server associated with an issuer of the contactless card; opening an account application associated with the issuer of the contactless card; receiving, by the account application, a confirmation input indicating that the contactless card should be used to create the payment account with the payment application; sending, by the account application, an instruction to enter the verification to the server associated with the issuer of the contactless card; opening the payment application in response to receiving validation of the encrypted data from the server associated with the issuer of the contactless card; generating, by the payment application, the payment account using account data generated by the server associated with the issuer of the contactless card.

16. the account data relates to an account associated with the contactless card, and the payment application is distinct from the account application; 16. The computing device of claim 15.

17. 17. The computing device of claim 16, wherein the account data for the account includes (i) a first name, (ii) a last name, (iii) an email address, (iv) an address, (v) an account number for the contactless card, (vi) an expiration date for the contactless card, and (vii) a card verification value (CVV) for the contactless card.

18. The instructions cause the processor to, after opening the payment application and prior to creating the payment account: entering, by the payment application, the name into a name form field of a plurality of form fields of a form in the payment application; entering, via the payment application, the last name into a last name form field of the plurality of form fields; entering, via the payment application, the email address into an email address form field of the plurality of form fields; entering, via the payment application, the address into an address form field of the plurality of form fields; entering, via the payment application, the account number into an account number form field of the plurality of form fields; entering, by the payment application, the expiration date into an expiration date form field of the plurality of form fields; inputting, by the payment application, the CVV into a CVV form field of the plurality of form fields; receiving, by the payment application, input indicating to submit the form to create the payment account.

20. The computing device of claim 17.

19. The instruction to enter the verification is sent via a HyperText Transfer Protocol Secure (HTTPS) Application Programming Interface (API) call to an API of the server associated with the contactless card, the instructions instructing the processor to, after opening the payment application and prior to creating the payment account: The computing device of claim 15 , further configured to cause the payment application to receive the account data from the server associated with the issuer of the contactless card.

20. The instructions cause the processor to, after transmitting the encrypted data and prior to opening the account application: receiving a push notification indicating providing said confirmation input; 16. The computing device of claim 15, further comprising: receiving an input selecting the push notification, the application being opened based on the input selecting the push notification.

Images