Credit payment with tap

Abstract

Apparatus, methods, and storage media are provided for enhancing a card payment experience with a single tap of a contactless card to a user computing device.SOLUTION: A single tap of the user's contactless card is pre-configured into the API endpoint 504 to cause an automatic payment of a predetermined amount for the card balance, and if the single tap is not pre-set to mean an automatic card payment, the user is presented with a notification and various payment amount options and the user chooses to pay for the card balance.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] Cross-reference to related applications This application claims priority to U.S. Patent Application No. 16 / 863,658, entitled "TAP TO PAY CREDIT BILL," filed April 30, 2020, the contents of which are incorporated herein by reference in their entirety. [Background technology]

[0002] background When a customer uses a credit card or other type of payment card, the customer is required to make payments against the balance on the card at a predetermined time period, e.g., typically the following month. In some examples, the customer may mail in a paper payment to make the monthly credit payment. In other examples, the customer may manually log into the credit card issuer's banking interface and make an online payment each month. In still other examples, the credit card issuer may allow the customer to set up automatic online payments that occur on specified dates. However, in the above examples, the process of making payments and setting up automatic payments is cumbersome, creating friction between the customer and the bill payment experience. Summary of the Invention

[0003] overview Various embodiments relate to enhancing the card payment experience with a single tap of a contactless card to a user computing device. In an example, a single tap of the card may be pre-configured to trigger an automatic payment of a predetermined amount against the card balance. If the single tap is not pre-configured to mean an automatic card payment, the user is presented with a notification and various payment amount options from which the user can choose to pay towards the card balance. [Brief explanation of the drawings]

[0004] [Figure 1A]FIG. 1A illustrates an exemplary data transmission system according to one or more embodiments. [Figure 1B] FIG. 1B is an exemplary sequence diagram for providing authenticated access according to one or more embodiments. [Figure 2] FIG. 2 is a diagram illustrating an exemplary system using contactless cards according to one or more embodiments. [Figure 3A] FIG. 3A illustrates an exemplary contactless card according to one or more embodiments. [Figure 3B] FIG. 3B illustrates an exemplary contact pad of a contactless card according to one or more embodiments. [Figure 4] FIG. 4 is a diagram illustrating an example of reading a URL and authentication payload, according to one or more embodiments. [Figure 5] FIG. 5 illustrates an example of communication between a computing device and an API endpoint, according to one or more embodiments. [Figure 6] FIG. 6 is a diagram illustrating an example of a first message according to one or more embodiments. [Figure 7] FIG. 7 is a diagram illustrating an example of a second message according to one or more embodiments. [Figure 8] FIG. 8 illustrates an example payment experience in a banking app, according to one or more embodiments. [Figure 9] FIG. 9 illustrates an exemplary flow diagram according to one or more embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0005] Detailed Description Various embodiments are generally directed to enhancing the contactless card single-tap or "one-tap" card bill payment experience. This payment experience may alternatively be referred to herein as "one-tap bill pay." It will be understood that the term "card" referred to herein may broadly encompass any type of payment card, e.g., credit card, charge card, virtual card, debit card, etc. It will also be understood that the contactless card may be linked to or otherwise correspond to a card account.

[0006] In an embodiment, a user (e.g., a customer) can make a payment toward at least a portion of a card balance by tapping a contactless card against the user's mobile device (e.g., a smartphone). When the contactless card is placed in the magnetic field of a near-field communication (NFC) reader on the mobile device, the contactless card can generate and send a uniform resource locator (URL) and an authentication payload (e.g., authentication code, encryption) to the mobile device. The URL can be used to communicate with an application programming interface (API) endpoint to authenticate the user based on the received authentication payload. If the user is successfully authenticated, a predetermined payment (e.g., an amount preset by the user) may be applied to the credit balance. If it is determined that the one-tap payment option has not yet been set, the user's contact information may be identified and a message (e.g., email, text) may be sent to the user. In response, the user may send a simple reply message with a payment selection (e.g., minimum monthly payment, fixed amount, full balance payment).

[0007] In a further embodiment, one-tap bill payments can be performed within a banking application (or otherwise referred to as a "banking app"). One advantage of performing one-tap bill payments within a banking app is that it adds an additional layer of security and authentication (e.g., the user must log in to the banking app). Additionally, the banking app allows the user to set and save one or more payment preferences (e.g., pay the minimum, pay half the balance, pay the full balance, pay the previous month's balance). Additionally, the banking app can provide an improved user interactive experience that signals that the transaction is complete and successful.

[0008] With previous solutions, paying off a card balance was an unattractive and burdensome process. Users had to either mail a paper payment or manually log into their electronic account to specify and submit payment information. The embodiments and examples described herein advantageously overcome previous solutions by allowing users to experience card payments in a new, engaging, and exciting way, such as by allowing users to make a given payment with just one tap of their card on their mobile device (sometimes referred to herein as the one-tap bill pay experience). Additionally, in the banking app, users can customize their one-tap bill pay experience.

[0009] Referring now to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It will be apparent, however, that novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate explanation. The intention is to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0010] 1A illustrates an exemplary data transmission system according to one or more embodiments. As discussed further below, system 100 may include contactless card 105, client device 110, network 115, and server 120. While FIG. 1A illustrates a single example of a component, system 100 may include any number of components.

[0011] System 100 may include one or more contactless cards 105, which are further described below with reference to Figures 3A and 3B. In some embodiments, contactless card 105 may communicate wirelessly with client device 110, using, by way of example, NFC.

[0012] System 100 may include client device 110, which may be a network-enabled computer. As referred to herein, a network-enabled computer may include, for example, but is not limited to, a computing or communication device, including a server, network appliance, personal computer, workstation, telephone, smartphone, handheld PC, personal digital assistant, thin client, fat client, Internet browser, or other device. Client device 110 may also be, for example, an Apple® iPhone®, iPod®, iPad®, or any other suitable device running Apple's iOS® operating system, any device running Microsoft's Windows® Mobile operating system, any device running Google's Android® operating system, and / or any other suitable mobile computing device, such as a smartphone, tablet, or similar wearable mobile device.

[0013] It is understood that client device 110 may include a processor and memory, and that the processing circuitry may include additional components, including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, necessary to perform the functions described herein. Client device 110 may also include a display and input devices. The display may be any type of device for presenting visual information, such as a computer monitor, flat-panel display, and mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. The input devices may include any device available and supported by the user's device for inputting information into the user's device, such as a touchscreen, keyboard, mouse, cursor control device, touchscreen, microphone, digital camera, video recorder, or camcorder. These devices may be used to input information and interact with the software and other devices described herein.

[0014] In some examples, a client device 110 of system 100 may execute one or more applications, such as software applications, that enable network communication with one or more components of system 100 and transmit and / or receive data.

[0015] The client device 110 may communicate with one or more servers 120 via one or more networks 115 and may act as a respective front-end and back-end pair with the server 120. The client device 110 may send one or more requests to the server 120, for example, from a mobile device application executing on the client device 110. The one or more requests may relate to retrieving data from the server 120. The server 120 may receive one or more requests from the client device 110. Based on the one or more requests from the client device 110, the server 120 may be configured to retrieve the requested data from one or more databases (not shown). Based on receiving the requested data from the one or more databases, the server 120 may be configured to transmit the received data to the client device 110, where the received data is in response to the one or more requests.

[0016] System 100 may include one or more networks 115. In some examples, network 115 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks and may be configured to connect client device 110 to server 120. For example, network 115 may be an optical fiber network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a global system for mobile communications, a personal communication service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced message service, a short message service, a time division multiplexing-based system, a code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi, and / or the like.

[0017] Additionally, network 115 may include, but is not limited to, a telephone line, optical fiber, IEEE Ethernet 802.3, a wide area network, a wireless personal area network, a LAN, or a global network such as the Internet. Furthermore, network 115 may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. Network 115 may further include one network or any number of the exemplary types of networks described above, operating as a standalone network or in cooperation with one another. Network 115 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 115 may translate from other protocols to one or more protocols of network devices, or from other protocols to one or more protocols of network devices. While network 115 is depicted as a single network, it should be understood that, according to one or more examples, network 115 may include multiple interconnected networks, such as the Internet, a service provider network, a cable television network, an enterprise network such as a credit card association network, and a home network.

[0018] The system 100 may include one or more servers 120. In some examples, the server 120 may include one or more processors coupled to a memory. The server 120 may be configured as a central system, server, or platform for controlling and retrieving various data at different times to perform multiple workflow operations. The server 120 may be configured to connect to one or more databases. The server 120 may be connected to at least one client device 110.

[0019] 1B is an exemplary sequence diagram for providing authenticated access according to one or more embodiments. The diagram includes a contactless card 105 and a client device 110, which may include an application 122 and a processor 124. FIG. 1B may reference similar components as shown in FIG. 1A.

[0020] In step 102, application 122 communicates with contactless card 105 (e.g., after being brought close to contactless card 105). Communication between application 122 and contactless card 105 may include bringing contactless card 105 close enough to a card reader (not shown) of client device 110 to enable NFC data transfer between application 122 and contactless card 105.

[0021] In step 104, after communication is established between client device 110 and contactless card 105, contactless card 105 generates a message authentication code (MAC) cryptogram. In some examples, this may occur when contactless card 105 is read by application 122. In particular, this may occur upon reading, such as an NFC read, of a Near Field Data Exchange (NDEF) tag, which may be created according to the NFC data exchange format.

[0022] For example, a reader such as application 122 may send a message such as an applet selection message with the applet ID of the NDEF generation applet. Once the selection is confirmed, a select file message may be sent followed by a sequence of read file messages. For example, the messages may be "select capabilities file," "read capabilities file," and "select NDEF file," in that order. At this point, a counter value maintained by contactless card 105 may be updated or incremented, followed by "read NDEF file." At this point, a message including a header and a shared secret may be generated. A session key may then be generated. A MAC ciphertext may be created from the message including the header and the shared secret. The MAC ciphertext may be combined with one or more blocks of random data, and the MAC ciphertext and random number (RND) may be encrypted with the session key. The ciphertext and header may then be concatenated, ASCII hex-encoded, and returned in the NDEF message format (corresponding to the "read NDEF file" message).

[0023] In some examples, the MAC cryptogram may be transmitted as an NDEF tag, and in other examples, the MAC cryptogram may be included with the uniform resource indicator (eg, as a formatted string).

[0024] In some examples, the application 122 may be configured to send a request to the contactless card 105, where the request includes instructions to generate a MAC cryptogram.

[0025] In step 106, contactless card 105 transmits the MAC cryptogram to application 122. In some examples, transmission of the MAC cryptogram occurs via NFC, although this disclosure is not limited thereto. In other examples, this communication may occur via Bluetooth, Wi-Fi, or other means of wireless data communication.

[0026] In step 108, application 122 communicates the MAC ciphertext to processor 124. In step 112, processor 124 verifies the MAC ciphertext according to instructions from application 122. For example, the MAC ciphertext may be verified as described below.

[0027] In some examples, verifying the MAC ciphertext may be performed by a device other than client device 110, such as a server 120 in data communication with client device 110 (as shown in FIG. 1A). For example, processor 124 may output the MAC ciphertext for transmission to server 120, and server 120 may verify the MAC ciphertext.

[0028] In some instances, the MAC ciphertext may serve as a digital signature for purposes of verification. Other digital signature algorithms, such as public key asymmetric algorithms, such as the Digital Signature Algorithm and the RSA algorithm, or zero-knowledge protocols, may be used to perform this verification.

[0029] It will be appreciated that in some examples, contactless card 105 may initiate communication after the contactless card is brought close to client device 110. By way of example, contactless card 105 may send a message to client device 110 indicating that the contactless card has established communication. Application 122 on client device 110 may then proceed with communication with the contactless card in step 102, as described above.

[0030] 2 illustrates an exemplary system 200 that uses a contactless card. System 200 may include a contactless card 205, one or more client devices 210, a network 215, servers 220, 225, one or more hardware security modules 230, and a database 235. Although FIG. 2 illustrates a single example of a component, system 200 may include any number of components.

[0031] 3A and 3B below. In some examples, the contactless card 205 may communicate wirelessly, e.g., NFC, with the client device 210. For example, the contactless card 205 may include one or more chips, such as a radio frequency identification chip, configured to communicate via NFC or other short-range protocols. In other embodiments, the contactless card 205 may communicate with the client device 210 through other means, including, but not limited to, Bluetooth, satellite, Wi-Fi, wired communication, and / or any combination of wireless and wired connections. According to some embodiments, the contactless card 205 may be configured to communicate with the card reader 213 (which may otherwise be referred to herein as an NFC reader, NFC card reader, or reader) of the client device 210 via NFC when the contactless card 205 is within range of the card reader 213. In other examples, communication with the contactless card 205 may be achieved through a physical interface, such as a Universal Serial Bus interface or a card swipe interface.

[0032] System 200 may include client device(s) 210, which may be a network-enabled computer. As referred to herein, a network-enabled computer may include, for example, but is not limited to, a computing device such as a server, a network appliance, a personal computer, a workstation, a mobile device, a telephone, a handheld PC, a personal digital assistant, a thin client, a fat client, an Internet browser, or a communication device. One or more client devices 210 may also be mobile devices, for example, a mobile device may include an iPhone®, an iPod®, an iPad®, or any other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® mobile operating system, any device running Google's Android® operating system, and / or other smartphones or similar wearable mobile devices. In some examples, client device 210 may be the same as or similar to client device 110 as described with reference to FIG. 1A or FIG. 1B.

[0033] The client device 210 may be in communication with one or more servers 220 and 225 over one or more networks 215. The client device 210 may send one or more requests to the one or more servers 220 and 225, for example, from an application 211 executing on the client device 210. The one or more requests may relate to retrieving data from the one or more servers 220 and 225. The servers 220 and 225 may receive one or more requests from the client device 210. Based on the one or more requests from the client device 210, the one or more servers 220 and 225 may be configured to retrieve the requested data from one or more databases 235. Based on receiving the requested data from the one or more databases 235, the one or more servers 220 and 225 may be configured to send the received data to the client device 210, where the received data is in response to the one or more requests.

[0034] System 200 may include one or more hardware security modules (HSMs) 230. For example, one or more HSMs 230 may be configured to perform one or more cryptographic operations as disclosed herein. In some examples, one or more HSMs 230 may be configured as special-purpose security devices configured to perform one or more cryptographic operations. HSMs 230 may be configured such that keys are never revealed outside of HSM 230 but instead are maintained within HSM 230. For example, one or more HSMs 230 may be configured to perform at least one of key derivation, decryption, and MAC operations. One or more HSMs 230 may be included within servers 220 and 225 or may be in data communication with servers 220 and 225.

[0035] System 200 may include one or more networks 215. In some examples, network 215 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks and may be configured to connect client device 210 to server 220 and / or 225. For example, network 215 may include an optical fiber network, a passive optical network, a cable network, a cellular network, an Internet network, a satellite network, a wireless local area network, a global system for mobile communications, a personal communication service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced message service, a short message service, a time division multiplexing-based system, a code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, RFID, Wi-Fi, and / or any combination of these networks. As non-limiting examples, communications from the contactless card 205 and the client device 210 may include NFC communications, a cellular network between the client device 210 and the carrier, and the Internet between the carrier and a backend.

[0036] Additionally, network 215 may include, but is not limited to, telephone lines, optical fiber, IEEE Ethernet 802.3, wide area networks, wireless personal area networks, local area networks, or global networks such as the Internet. Furthermore, network 215 may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. Network 215 may also include one network or any number of the exemplary types of networks described above, operating as a standalone network or in cooperation with one another. Network 215 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 215 may translate from other protocols to one or more protocols of network devices, or from other protocols to one or more protocols of network devices. While network 215 is depicted as a single network, according to one or more examples, it should be understood that network 215 may include multiple interconnected networks, such as, for example, the Internet, a service provider network, a cable television network, an enterprise network such as a credit card association network, and a home network.

[0037] In various examples according to the present disclosure, client device 210 of system 200 may execute one or more applications 211 and include one or more processors 212 and one or more card readers 213. The one or more applications 211, e.g., software applications, may be configured to, for example, enable network communication with one or more components of system 200, to transmit and / or receive data. While FIG. 2 illustrates only a single example of components of client device 210, it will be understood that any number of devices 210 may be used. Card reader 213 may be configured to read from and / or communicate with contactless card 205. In conjunction with one or more applications 211, card reader 213 may communicate with contactless card 205. In an example, card reader 213 may include circuitry or circuit components, e.g., an NFC reader coil, that generate a magnetic field to enable communication between client device 210 and contactless card 205.

[0038] An application 211 on any of the client devices 210 may communicate with the contactless card 205 using short-range wireless communication (e.g., NFC). The application 211 may be configured to interface with a card reader 213 on the client device 210 configured to communicate with the contactless card 205. It should be noted that those skilled in the art will understand that a distance of less than 20 centimeters corresponds to an NFC range.

[0039] In some embodiments, the application 211 communicates with the contactless card 205 via an associated reader (eg, card reader 213).

[0040] In some embodiments, card activation can occur without user authentication. For example, contactless card 205 may communicate with application 211 through card reader 213 of client device 210 through NFC. Communication (e.g., tapping the card in proximity to card reader 213 of client device 210) can cause application 211 to read data associated with the card and perform activation. In some cases, the tap can activate or launch application 211, which can then initiate one or more operations or communications with account server 225 to activate the card for subsequent use. In some cases, if application 211 is not installed on client device 210, tapping the card against card reader 213 can initiate download of application 211 (e.g., navigation to an application download page). Following installation, tapping the card can activate or launch application 211, which can then initiate card activation (e.g., via application or other back-end communication). After activation, the card can be used in various transactions, including commercial transactions.

[0041] According to some embodiments, contactless card 205 may include a virtual payment card. In those embodiments, application 211 may obtain information related to contactless card 205 by accessing a digital wallet implemented on client device 210, the digital wallet including the virtual payment card. In some examples, the virtual payment card data may include one or more statically or dynamically generated virtual card numbers.

[0042] Server 220 may include a web server in communication with database 235. Server 225 may include an account server. In some examples, server 220 may be configured to verify one or more credentials from contactless card 205 and / or client device 210 by comparing them with one or more credentials in database 235. Server 225 may be configured to approve one or more requests, such as payments and transactions, from contactless card 205 and / or client device 210.

[0043] FIG. 3A illustrates one or more contactless cards 300, which may include a payment card such as a credit card, debit card, or gift card issued by a service provider 305 displayed on the front or back of the card 300. In some examples, the contactless card 300 is unrelated to a payment card and may include, but is not limited to, an identification card. In some examples, the payment card may include a dual-interface contactless payment card. The contactless card 300 may include a substrate 310, which may include a single layer or one or more laminates of plastic, metal, and other materials. Exemplary substrates include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium oxide, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 300 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7810 standard; the contactless card may otherwise conform to the ISO / IEC 14443 standard. However, it is understood that contactless cards 300 according to the present disclosure may have different characteristics, and the present disclosure does not require that the contactless card be implemented as a payment card.

[0044] Contactless card 300 may also include identification information 315 displayed on the front and / or back of the card, as well as a contact pad 320. Contact pad 320 may be configured to establish contact with another communication device, such as a user device, smartphone, laptop, desktop, or tablet computer. Contactless card 300 may also include processing circuitry, an antenna, and other components not shown in FIG. 3A . These components may be located behind contact pad 320 or elsewhere on substrate 310. Contactless card 300 may also include a magnetic strip or tape, which may be located on the back of the card (not shown in FIG. 3A ).

[0045] As shown in Figure 3B, the contact pad 320 of Figure 3A may include processing circuitry 325 for storing and processing information, including a microprocessor 330 and memory 335. It will be understood that processing circuitry 325 may include additional components such as processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tamper hardware necessary to perform the functions described herein.

[0046] The memory 335 may be read-only memory, write-once read-multiple memory, or read / write memory, such as RAM, ROM, or EEPROM, and the contactless card 300 may include one or more of these memories. Read-only memory may be factory programmable as read-only or one-time programmable. One-time programmable memory provides the opportunity to write once and read multiple times. Write-once read-multiple memory can be programmed at any time after the memory chip leaves the factory. Once programmed, the memory cannot be rewritten, but can be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory, and can also be read multiple times.

[0047] The memory 335 may be configured to store one or more applets 340, one or more counters 345, one or more diversification keys 347, one or more customer identifiers 350, and one or more uniform resource locators (URLs). The one or more applets 340 may include one or more software applications configured to run on one or more contactless cards, such as a Java Card applet. However, it is understood that the applet 340 is not limited to a Java Card applet and may instead be any software application capable of operating on a contactless card or other device having limited memory. The one or more counters 345 may include a numeric counter sufficient to store integers. As described further below, the one or more diversification keys 347 may be used to encrypt various information, such as information about a user or customer (e.g., a customer identifier 450), to generate a cipher(s) that can be transmitted to a mobile device, for example, at least for authentication purposes. Customer identifier 350 may include a unique alphanumeric identifier assigned to a user of contactless card 300, which identifier can distinguish a contactless card user from other contactless card users. In some examples, customer identifier 350 may identify both a customer and an account assigned to the customer, and may further identify a contactless card associated with the customer's account. One or more URLs 355 may include unique addresses associated with World Wide Web pages or the like, and in some examples can be generated by processing circuitry 325 based on a URL-generating event (e.g., tapping card 300 to a computing device).

[0048] While the processor and memory elements of the foregoing exemplary embodiments have been described with reference to contact pads, the present disclosure is not limited thereto, and it will be appreciated that these elements may be implemented outside of or entirely separate from the pads 320, or as additional elements in addition to the processor 330 and memory 335 elements located within the contact pads 320.

[0049] In some examples, the contactless card 300 may include one or more antennas 355. The one or more antennas 355 may be disposed within the contactless card 300 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, or the one or more antennas 355 may be used in conjunction 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.

[0050] In one embodiment, the coil of the contactless card 300 may act as the secondary of an air-core transformer. The terminal may communicate with the contactless card 300 by cutting power or performing amplitude modulation. The contactless card 300 may infer data transmitted from the terminal using gaps in the contactless card's power connection, which may be maintained functionally through one or more capacitors. The contactless card 300 may also return communication by switching the load on the contactless card's coil or by load modulation. Load modulation may be detected by interference in the terminal's coil.

[0051] As described above, contactless card 300 may be built on a software platform operable on a smart card or other device with limited memory, such as JavaCard, on which one or more applications or applets may be securely executed. An applet may be added to the contactless card to provide one-time passwords (OTPs) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet may be configured to respond to one or more requests, such as a near-field data exchange request, from a reader, such as a mobile NFC reader, and generate an NDEF message containing the cryptographically secure OTP encoded as an NDEF text tag.

[0052] In an embodiment, when preparing to transmit data (e.g., to a mobile device, to a server, etc.), contactless card 300 may increment the counter values ​​of one or more counters 345. Contactless card 300 may then provide a master key, which may be a separate key stored on card 300, and the counter value as input to a cryptographic algorithm that generates a diversified key as output, which may be one of diversified keys 347. It is understood that the master key and counter value are also stored in the memory of a device or component that receives data from contactless card 300 so as to decrypt the data using the diversified key used by the card to encrypt the transmitted data. Cryptographic algorithms may include encryption algorithms, hash-based message authentication code (HMAC) algorithms, cipher-based message authentication code (CMAC) algorithms, etc. Non-limiting examples of cryptographic algorithms may 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. The contactless card 300 may then encrypt data (e.g., customer identifier 350 and any other data) using the diversification key in the form of one or more ciphers that may be transmitted to the mobile device, for example, as an NDEF (NFC Data Exchange Format) message. The contactless card 300 may then transmit the encrypted data (e.g., ciphertext) to the mobile device, which may then decrypt the ciphertext using the diversification key (e.g., a diversification key generated by the mobile device using a counter value and a master key stored in its memory).

[0053] 4 is a diagram illustrating an example reading 400 of a URL and authentication payload by a mobile device in accordance with one or more embodiments. As shown, a contactless card 404 (which may be similar or identical to the contactless card 300 described above) may be tapped or held near a mobile device 406. This action of tapping or holding the contactless card 404 near the mobile device 406 may cause the contactless card 404 to enter or be within a magnetic field generated by an NFC reader coil of the mobile device 406, which may cause the card 404 to perform an action or send a signal.

[0054] In response, the contactless card 404 may, for example, generate and transmit a URL 401 and an authentication payload 402 (e.g., a cipher including the customer identifier 350) to the mobile device 406. In some examples, the contactless card 404 need only transmit the URL (e.g., URL 355 may already be stored on the contactless card 300) and authentication payload if they have already been generated and stored on the card 404. It will be appreciated that the authentication payload 402 may be ciphertext and transmitted by the contactless card as an NFC Data Exchange Format (NDEF) message. It will further be appreciated that ciphertext may broadly refer to any encrypted text, data, or information.

[0055] As described further below, upon reading URL 401 and authentication 402, mobile device 406 can be configured to communicate with one or more APIs (e.g., authentication APIs) or one or more servers (e.g., backend authentication servers) via URL 401 to authenticate the user based on the retrieved authentication payload 402. URL 401 may be a web address that specifies the location of one or more API endpoints or one or more servers.

[0056] Additionally, it may be understood that the contactless card 404 does not need to be tapped or brought near a particular area on the mobile device 406 for the mobile device 406 to accurately read the URL and authentication payload from the contactless card 404, but may be tapped or brought near any physical area or portion of the mobile device 406. Additionally, it may be understood that the above reading 400 does not require that a banking app be already installed on the mobile device 406 for the mobile device 406 to receive the URL 401 and authentication code 402.

[0057] 5 illustrates exemplary communications 500 between a computing device 502 and an API endpoint 504 according to one or more embodiments. The computing device 502 may be a user mobile device, such as the mobile device 406, or any other suitable device (e.g., a smartphone, a laptop, a tablet computer, a wearable computer, etc.). The API endpoint 504 may be an authentication API that may be run, executed, or supported by one or more backend servers 506.

[0058] As described and shown, the computing device 502 can use the URL read from the contactless card to locate the API endpoint 504 and establish communication. Upon establishing communication, the computing device 502 may provide the API endpoint 504 with an authentication payload, also read from the contactless card. In an example, the authentication payload may be ciphertext (e.g., the authentication payload is encrypted) and may include at least customer information, such as a customer identifier (e.g., the customer identifier 350 stored on the contactless card 300). The customer identifier may be a unique identifier (e.g., an alphanumeric string, personal identification information, etc.) that associates an authorized user with the contactless card, and this association may be verifiable at least by the API endpoint 504.

[0059] By way of example, the API endpoint 504 may be configured to receive and decrypt an authentication payload using at least one key (e.g., a private key, a decryption key, a key corresponding to a particular encryption-decryption scheme). Information included in the authentication payload, such as a customer identifier, may be compared or matched with user credentials maintained at a backend. For example, the credentials may be any type of data or information (e.g., ID number, customer number, personal identification information, etc.) used to properly identify and authenticate a user at the backend of the authentication process. Thus, if the decrypted customer identifier and the user credentials match, the user may be successfully authenticated.

[0060] As further shown in FIG. 5, upon successful authentication or verification of the user, the API endpoint 504 may perform (or cause another API or server to perform) one of at least two actions based on the user's card tap configuration. In one example, the API endpoint 504 may determine whether a single tap of the user's card is pre-configured (e.g., pre-configured to perform one-tap bill pay) and may determine whether a single tap event has occurred (e.g., which the API endpoint 504 receiving the authentication payload indicates or qualifies as a single tap event). If the user has pre-configured the single tap of the card to operate or function as a card payment of a predetermined value (e.g., a minimum payment amount, half of the balance payment, the full balance payment, a percentage of the balance payment, etc.), the API endpoint 504 may cause the predetermined payment to be automatically processed. The user may then be notified that the predetermined payment was successfully made and applied to the card balance. As described further below, a card tap may be configured by the user to mean or function in a variety of ways in a banking app, one of which may be a one-tap bill pay experience.

[0061] In another example, if the user has not pre-configured a card tap, the API endpoint 504 may (or may have another API or another server do so) look up the user's contact information (e.g., mobile phone number, email, social media account, etc.) and send the user (e.g., text, email, app notification, etc.) a notification asking if a payment will be made to the card and how much (e.g., a payment amount prompt). The user can simply reply (as indicated by the dashed arrow) with simple payment instructions (e.g., pay the minimum amount, pay half the balance, pay the full balance, pay a percentage of the balance) using the message itself, as described below.

[0062] One of the many advantages of the one-tap bill pay experience described above is that the URL and authentication payload mechanism allows the entire authentication and payment process to be completed automatically with a single tap of the card, without first opening or directly engaging with the banking app, making it much easier, more convenient, and more practical for the user compared to payment experiences that include multi-factor authentication.

[0063] 6 is a diagram illustrating an exemplary message 600 displayed on a user mobile device 602, according to one or more embodiments. In an example, a user may have already pre-configured a single tap of their card to act as a payment of a specific amount or value, e.g., $200, toward their card balance. Thus, when the user taps their card on the user mobile device 602, the $200 payment may be automatically processed (via the URL and authentication payload mechanisms described above). Upon successful payment, message 600 may be sent and displayed on the user mobile device 602.

[0064] As shown, message 600 may display a simple message such as, "Yay! Your $200 payment has been applied to your previous card balance of $1,213.45. Your new balance is $1,013.45." Message 600 may be any form of notification, such as an email, text message, app notification, etc. Other notification methods are possible, such as an automated phone call.

[0065] Additionally, at least two icons 604 and 606 are shown at the bottom of message 600. In the example, icon 604 may be selected by the user if the user wishes to change any aspect of the One Tap Bill Pay experience, such as the predetermined payment amount. If icon 604 is selected, the user may be prompted to a banking app where changes to the One Tap Bill Pay functionality may be made in the banking app.

[0066] In a further example, icon 606 may be selected by a user if the user has a question or concern about the content displayed in message 600 or anything related to the one-tap bill pay experience. By selecting icon 606, the user may be automatically connected to the appropriate banking representative via a messaging app (of the banking app), phone call, etc.

[0067] 7 is a diagram illustrating an example message 700 displayed on a user mobile device 702, according to one or more embodiments. In an example, message 700 may be the type of message a user receives during a one-tap bill pay experience if the user has not already pre-set a single tap of their card to mean payment of a specific monetary value.

[0068] When a user taps a card on a user mobile device 702, a payment message 700 may be generated on the backend side of the system (e.g., via one or more API endpoints that handle authentication) and sent to the user mobile device 702. The message 700 may be any type of notification, such as an email, a text message, an app notification, etc.

[0069] As shown, message 700 may be titled, "How much would you like to pay against your credit card balance?" This inquiry or other similar examples may otherwise be referred to as a payment prompt. Under that portion of the message, one or more payment amount options may be presented to the user. For example, the user may pay the full balance, half the balance, one-quarter the balance, or the minimum payment. In some examples, the user may enter a custom amount to be paid against the card balance in response to message 700, such as a specific amount or a specific percentage of the balance, or type it directly into the message. For simplicity, typically, only a few options may be presented to the user in message 700.

[0070] Upon responding to message 700 with a payment option (e.g., a payment amount entered by the user), the user may receive a subsequent message (not shown) indicating that the payment was successfully applied to the balance. In an example, the subsequent message may be similar to message 600 in that it displays information related to at least the current balance of the card, along with options for setting or changing card tap settings in a banking app or for communicating with a representative.

[0071] FIG. 8 illustrates a payment experience 800 with a banking app 802 according to one or more embodiments. The card payment experience 800 via the banking app 802 may differ from the one-tap bill pay experience described above in that the user may be required to first log in to the banking app 802 before initiating a card payment. In an example, the user may log in to the app 802 via one-tap sign-in (e.g., the user taps their contactless card to their mobile device, and the banking app automatically authenticates and logs them in). The user's card may then be tapped again to their mobile device to make the card payment. While the payment experience 800 can include multiple card taps, the banking app 802 offers greater user flexibility and customization during the experience, as described below. Additionally, requiring the user to log in to the banking app 802 adds a layer of security to the payment process.

[0072] As shown, in addition to tapping the card to make a payment, the user may be able to customize all kinds of features related to the payment experience 800 on the banking app 802 interface. For example, first, the user may configure a single tap of the card (for use and detection outside of the banking app) to mean one-tap bill pay. It will be appreciated that in other examples, the user may configure a single tap of the card to mean other actions. However, in this example, the user may set it to function as one-tap bill pay. The user may also be able to set a predetermined amount for the one-tap bill pay experience. Additionally, the user may be able to customize or configure how notifications are delivered.

[0073] 9 illustrates an example flow diagram 900 according to one or more embodiments. Flow diagram 900 relates to the one-tap bill pay experience described above. It may be understood that the blocks of flow diagram 900 and the functions described therein are not required to be performed in any particular order. Furthermore, it may be understood that flow diagram 900 and the features described therein may be performed or supported by one or more processors. In an example, flow diagram 900 may be implemented at least on the API endpoint or backend server side of the one-tap bill pay process.

[0074] In block 902, it may be determined whether the user has pre-configured a single tap of the contactless card to perform card payments. As described above, whether the user has pre-configured the single tap of the card to function as a one-tap bill pay determines whether a predetermined payment is automatically applied to the card balance or whether payment input is required from the user. In embodiments, user configurations and settings related to the single tap or one-tap of the contactless card may be saved or stored on the back-end side of the system. Thus, when an authentication payload containing a customer identifier is received and decoded, the identifier may be matched against customer information, including the single tap or one-tap settings.

[0075] At block 904, it may be determined whether a single tap event has occurred. As described above, when a user taps a contactless card to the user's mobile device, a URL and an authentication payload may be sent to the device. The device then communicates with one or more API endpoints via the URL and provides the authentication payload to the API endpoint(s). To at least that end, in one example, receipt of the authentication payload by the API endpoint(s) may indicate, at least, that a single tap event has occurred (e.g., a user tapped a contactless card to a mobile device).

[0076] In response to the occurrence of the single tap event, one of at least two events may occur in block 906. In one example, based on a determination that the user has pre-configured a single tap of the contactless card to perform a card payment, the card payment may be automatically processed without further action from the user. The user may receive notification that the user's predetermined payment has been successfully applied to the card balance.

[0077] In another example, based on a determination that the user has not pre-configured a single tap of the contactless card to perform a card payment, a notification may be sent to the user requesting input regarding the payment amount. As described above, the notification may include payment options (e.g., pay the full balance, pay half the balance, pay the minimum amount, pay a percentage) readily selectable by the user on the right side of the notification. The payment amount may then be input, and the card payment corresponding to the specified payment amount may be processed. Another notification may also be sent to the user indicating that the payment has been successfully applied to the card balance. Furthermore, in some examples, the subsequent notification may inquire whether the user would like to configure the single tap or one tap to function as one-tap bill pay for the banking app.

[0078] As discussed above, a one-tap bill pay experience is advantageous at least because a payment of a predetermined amount can be automatically processed with a single tap of a contactless card to a user's computing device. At least in that respect, the payment experience is easy and engaging for the user. Another advantage of the present disclosure is that the user can also make card payments with a card tap within a banking app, which adds an additional layer of security, flexibility, and customizability as discussed above.

[0079] The components and features of the devices described above may be implemented using any combination of discrete circuits, application specific integrated circuits (ASICs), logic gates, and / or single-chip architectures. Furthermore, the features of the devices may preferably be implemented using a microcontroller, a programmable logic array, and / or a microprocessor, or any combination of the foregoing. It should be noted that hardware, firmware, and / or software elements may be collectively or individually referred to herein as "logic circuitry" or "circuitry."

[0080] At least one computer-readable storage medium may contain instructions that, when executed, cause the system to perform any of the computer-implemented methods described herein.

[0081] Some embodiments, along with variations thereof, may be described using the phrase "one embodiment" or "an embodiment." These terms mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places throughout this specification do not necessarily all refer to the same embodiment. Furthermore, unless otherwise specified, it is recognized that the features described above can be used together in any combination. Thus, features discussed separately can be employed in combination with each other unless it is indicated that the features are incompatible with each other.

[0082] To generally refer to the notation and nomenclature used herein, the detailed descriptions herein may be presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art.

[0083] A procedure is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0084] Further, the manipulations performed are often referred to in terms, such as adding or comparing, that are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of one or more embodiments. Rather, the operations are machine operations.

[0085] Some embodiments may be described using the terms "coupled" and "connected," along with derivatives thereof. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms "connected" and / or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but yet still cooperate or interact with each other.

[0086] Various embodiments also relate to apparatus or systems for performing these operations. This apparatus may be specially constructed for the required purposes, or it may be selectively activated or reconfigured by a computer program stored in a computer. The procedures presented herein are not inherently related to any particular computer or other apparatus. The required structure for a variety of these machines will appear from the description given.

[0087] It is emphasized that the Summary of the Disclosure is provided to enable the reader to quickly grasp the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Moreover, in the foregoing Detailed Description, various features may be grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in fewer than all features of a single disclosed embodiment. Accordingly, the following claims are incorporated herein, with each claim standing on its own as an independent embodiment. In the appended claims, the terms "comprising" and "wherein" are used as the plain-English equivalents of the terms "consisting of" and "wherein," respectively. Furthermore, the terms "first," "second," "third," etc. are used merely as labels and are not intended to impose numerical requirements on their subject matter.

[0088] What has been described above includes examples of the disclosed architecture. Of course, it is not possible to describe every conceivable combination of components and / or methodologies, but one of ordinary skill in the art will recognize that many further combinations and permutations are possible. Accordingly, the novel architecture is intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.

Claims

1. a memory for storing instructions; one or more processors, coupled to the memory, operable to execute the instructions; An apparatus comprising: The instructions, when executed, cause the one or more processors to: receiving a URL and an authentication payload from a contactless card possessed by a user when the contactless card enters a magnetic field generated by an NFC reader coil; establishing communication with one or more API endpoints via said URLs; providing the authentication payload to the one or more API endpoints to perform authentication of the user based on the authentication payload; in response to successful authentication of the user; receiving, from the one or more API endpoints, a notification of a successful payment applied to the card balance, the payment being a predetermined amount set by a user; and displaying a notification of successful payment of said predetermined amount; Or, receiving notification of a payment request from the one or more API endpoints to the user; displaying the payment amount input request; receiving a payment amount input from the user; sending the payment input to the one or more API endpoints; receiving notification of a successful payment applied to the card balance from the one or more API endpoints; and displaying a notification of said successful payment; and to carry out Device.

2. the authentication payload is a cryptogram containing a customer identifier corresponding to the user, the customer identifier associating the contactless card with the user; 10. The apparatus of claim 1.

3. The authentication of the user includes: the one or more API endpoints for decrypting the encryption, comparing the customer identifier with customer authentication information, and confirming that the authentication of the user is successful if the customer identifier and the customer authentication information match; 3. The apparatus of claim 2.

4. In response to the successful authentication of the user, the one or more API endpoints automatically process the payment of the predetermined amount.

4. The apparatus of claim 3.

5. 2. The apparatus of claim 1, wherein the payment input request includes a plurality of payment options, and the payment input from the user is one of the plurality of payment options selected by the user.

6. 6. The device of claim 5, wherein the plurality of payment options include paying off the entire card balance, paying half the card balance, paying a percentage of the card balance, or paying a minimum payment on the card balance.

7. the notification of the successful payment is an email, a text message, or an application notification; 10. The apparatus of claim 1.

8. A non-transitory computer-readable storage medium storing computer-readable program code executable by at least one processor, comprising: The computer readable program code, when executed by the processor, determining whether the user has pre-configured a single tap of the contactless card to make a card payment; determining the occurrence of a single tap event; and In response to the occurrence of the single tap event, (i) based on determining that the user has pre-configured a single tap of the contactless card to make a card payment, processing the card payment and sending a notification to the user computing device of a successful payment applied to the card balance, the payment being a predetermined amount configured by the user; Or, (ii) based on determining that the user has not pre-configured a single tap of the contactless card to make a card payment, sending a notification to the user computing device requesting input of a payment amount, receiving a payment amount input from the user, processing the card payment, and sending a notification to the user computing device of a successful payment applied to the card balance; Execute the A non-transitory computer-readable storage medium.

9. At a minimum, determining whether a single tap event has occurred is performed via one or more API endpoints. The non-transitory computer-readable storage medium of claim 8.

10. determining the occurrence of the single tap event includes receiving an authentication payload from a user computing device; 10. The non-transitory computer-readable storage medium of claim 9.

11. The computer readable program code further comprises: decrypting and comparing the customer identifier to the customer authentication information; if the customer identifier and the customer authentication information match, confirming that the user has been successfully authenticated; causing at least one of the processors to perform The non-transitory computer-readable storage medium of claim 10.

12. In response to the user being successfully authenticated, the one or more API endpoints automatically process the payment of the predetermined amount. The non-transitory computer-readable storage medium of claim 11.

13. the payment amount input request includes a plurality of payment amount options, and the payment amount input from the user is one of the plurality of payment amount options selected by the user. The non-transitory computer-readable storage medium of claim 8.

14. The plurality of payment options include paying the entire card balance, paying half the card balance, paying a percentage of the card balance, or paying a minimum payment on the card balance.

14. The non-transitory computer-readable storage medium of claim 13.

15. It is a method determining whether the user has pre-configured a single tap of the contactless card to make a card payment; determining the occurrence of a single tap event; and In response to the occurrence of the single tap event, (i) based on determining that the user has pre-configured a single tap of the contactless card to make a card payment, processing the card payment and sending a notification to the user computing device of a successful payment applied to the card balance, the payment being a predetermined amount configured by the user; Or, (ii) based on determining that the user has not pre-configured a single tap of the contactless card to make a card payment, sending a notification to the user computing device requesting input of a payment amount, receiving a payment amount input from the user, processing the card payment, and sending a notification to the user computing device of a successful payment applied to the card balance; A method comprising:

16. At least, determining the occurrence of the single tap event is performed via one or more API endpoints.

16. The method of claim 15.

17. determining the occurrence of the single tap event includes receiving an authentication payload from the user computing device; 17. The method of claim 16.

18. Furthermore, decrypting and comparing the customer identifier to the customer authentication information; if the customer identifier and the customer authentication information match, confirming that the user has been successfully authenticated; 18. The method of claim 17, comprising:

19. In response to the user being successfully authenticated, the one or more API endpoints automatically process the payment of the predetermined amount.

20. The method of claim 18.

20. the payment amount input request includes a plurality of payment amount options, and the payment amount input from the user is one of the plurality of payment amount options selected by the user.

16. The method of claim 15.

Images