User interface for payment

Abstract

To provide an electronic device for performing a payment transaction.SOLUTION: A mobile device receives and stores information on one or more payment accounts, and is used for performing payment using a payment account. Permission for performing the payment is performed before each purchase performed by a user. A permission process includes receiving verification of a user such as a fingerprint scan or a pass code, and the payment account is selected from available payment accounts. The indication of the digital item related to a purchase item is performed, the payment transaction is started together with a participant during communication, and the application of a retailer is called on the basis of availability of the application.SELECTED DRAWING: Figure 8A

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to the following co-pending provisional applications: U.S. Patent Application No. 62 / 004,886, entitled "USER INTERFACE FOR PAYMENTS," filed May 29, 2014 (Reference No. P22848USP1); U.S. Patent Application No. 62 / 047,545, entitled "USER INTERFACE FOR PAYMENTS," filed September 8, 2014 (Reference No. P22848USP2); U.S. Patent Application No. 62 / 127,790, entitled "USER INTERFACE FOR PAYMENTS," filed March 3, 2015 (Reference No. P22848USP3); and U.S. Patent Application No. 62 / 110,566, entitled "USER INTERFACE FOR PAYMENTS," filed February 1, 2015 (Reference No. P26049USP1), all of which applications are incorporated herein by reference in their entirety.

[0002] This application is related to the following provisional applications: No. 61 / 912,727, filed December 6, 2013, entitled "PROVISIONING AND AUTHENTICATING CREDENTIALS ON AN ELECTRONIC DEVICE" (Reference No. P19543USP1); U.S. Patent Application No. 61 / 909,717, filed November 27, 2013, entitled "PROVISIONING OF CREDENTIALS ON AN ELECTRONIC DEVICE USING PASSWORDS COMMUNICATED OVER VERIFIED CHANNELS" (Reference No. P19950USP1); U.S. Patent Application No. 62 / 004,182, filed May 28, 2014, entitled "ONLINE PAYMENTS USING A SECURE ELEMENT OF AN ELECTRONIC DEVICE" (Reference No. P20450USP4); U.S. Patent Application No. 62 / 004,182, filed May 28, 2014, entitled "DELETION No. 61 / 920,029 (Reference No. P21084USP1), filed December 23, 2013, entitled "USING BIOAUTHENTICATION IN NEAR-FIELD-COMMUNICATION TRANSACTIONS," U.S. Patent Application No. 61 / 899,737 (Reference No. P21646USP1), filed November 4, 2013, entitled "USING BIOAUTHENTICATION IN NEAR-FIELD-COMMUNICATION TRANSACTIONS," U.S. Patent Application No. 61 / 905,035 (Reference No. P21714USP1), filed November 15, 2013, entitled "GENERATING TRANSACTION IDENTIFIERS," and U.S. Patent Application No. 61 / 905,035 (Reference No. P21714USP1), filed November 15, 2013, entitled "ELECTRONIC RECEIPTS FOR NFC-BASED FINANCIAL No. 61 / 905,042 (Reference No. 21734USP1), filed November 15, 2013, entitled "FINANCIAL-TRANSACTION NOTIFICATIONS," and U.S. patent application Ser. No. 62 / 004, filed May 29, 2014, entitled "FINANCIAL-TRANSACTION NOTIFICATIONS."No. 798 (Reference No. P23211USP1), entitled "METHODS FOR MANAGING PAYMENT APPLETS ON A SECURE ELEMENT TO CONDUCT MOBILE PAYMENT TRANSACTIONS," filed May 29, 2014, U.S. Patent Application No. 62 / 004,837 (Reference No. P23215USP1), entitled "METHODS FOR OPERATING A PORTABLE ELECTRONIC DEVICE TO CONDUCT MOBILE PAYMENT TRANSACTIONS," filed May 29, 2014, U.S. Patent Application No. 62 / 004,840 (Reference No. P23223USP1), entitled "METHODS FOR USING A PRIMARY USER DEVICE TO PROVISION CREDENTIALS ONTO A SECONDARY USER DEVICE," filed May 29, 2014. No. 62 / 004,835, filed May 29, 2014 (Reference No. P23224USP1), entitled "A RANDOM AUTHORIZATION NUMBER TO PROVIDE ENHANCED SECURITY FOR A SECURE ELEMENT," U.S. Patent Application No. 62 / 004,832, filed May 29, 2014 (Reference No. P23261USP1), entitled "METHODS FOR USING A RANDOM AUTHORIZATION NUMBER TO PROVIDE ENHANCED SECURITY FOR A SECURE ELEMENT," U.S. Patent Application No. 62 / 004,338, filed May 29, 2014 (Reference No. P22931USP1), entitled "USER DEVICE SECURE PARTICIPATION IN TRANSACTIONS VIA LOCAL SECURE ELEMENT DETECTION OF MECHANICAL INPUT," and U.S. Patent Application No. 62 / 004,338, filed May 29, 2014 (Reference No. P22931USP1), entitled "SECURE PROVISIONING OF CREDENTIALS ON AN ELECTRONIC and U.S. Utility Patent Application No. 14 / 092,205 (Reference No. P19545US1), filed November 27, 2013, entitled "A METHOD FOR IMPROVING A ... [Technical Field]

[0003] It generally relates to electronic devices for conducting payment transactions, including but not limited to electronic devices for use with contactless payment systems and payments over the internet. [Background technology]

[0004] The use of electronic devices at point-of-sale terminals and for making payments over the Internet has increased significantly in recent years. Exemplary point-of-sale terminals include near-field communication (NFC)-enabled terminals, Bluetooth®-enabled terminals, and barcode scanner-enabled terminals. By using an electronic device with these exemplary terminals, a user of the electronic device can, for example, pay for the purchase of goods or services. Similarly, by using an electronic device with an Internet shopping cart, a user of the electronic device can make a payment by entering their credit card information. Summary of the Invention

[0005] Some techniques for making payments using electronic devices, however, are generally cumbersome and inefficient. For example, making a purchase using an NFC-enabled device at a point-of-sale terminal often requires navigating a complex and time-consuming user interface. In another example, a user wishing to purchase an item through a retailer's website or mobile application must manually enter credit card number and shipping address information for the purchase, an inefficient and cumbersome process. In another example, making a purchase using an NFC-enabled device at a point-of-sale terminal often requires navigating a complex and time-consuming user interface to select a payment account to charge. In another example, users purchasing physical goods or services often are not notified of digital items and / or do not have convenient access to digital items, such as software, corresponding to the purchased item. As another example, making a payment requires navigating a complex and time-consuming user interface to select a payment recipient. In another example, navigating a user interface using a retailer's application to make a purchase from the retailer is inefficient. In another example, accessing various applications and navigating their complex user interfaces to repeatedly purchase a product or make purchases related to that product is inefficient. Furthermore, existing techniques take longer than necessary, thereby wasting energy. This latter consideration is particularly important in battery-operated devices.

[0006] Therefore, there is a need for electronic devices with faster and more efficient methods and interfaces for conducting payment transactions. Such methods and interfaces optionally complement or replace traditional methods for conducting payments. Such methods and interfaces reduce the cognitive burden on users and create a more efficient human-machine interface. In the case of battery-operated computing devices, such methods and interfaces conserve power and increase the time between battery charges.

[0007] The above-mentioned deficiencies and other problems associated with user interfaces of computing devices for conducting payment transactions are reduced or eliminated by the devices disclosed herein. In some embodiments, the device is a desktop computer. In some embodiments, the device is portable (e.g., a notebook computer, a tablet computer, or a handheld device). In some embodiments, the device has a touchpad. In some embodiments, the device has a touch-sensitive display (also known as a "touch screen" or "touch screen display"). In some embodiments, the device has a near-field communications radio. In some embodiments, the device has a graphical user interface (GUI), one or more processors, memory, and one or more modules, programs or sets of instructions stored in the memory for performing a plurality of functions. In some embodiments, a user interacts with the GUI primarily through finger contacts and gestures on the touch-sensitive surface. Executable instructions for performing functions may be included on a computer-readable storage medium or other computer program product configured for execution by one or more processors.

[0008] According to some embodiments, a method is performed on an electronic device having a display. The method includes receiving a request to link a payment account associated with a credit card to a corresponding device, the request including information about the credit card. The method includes, in response to receiving the request, determining whether further verification is required to link the payment account to the corresponding device. In accordance with a determination that further verification is not required to link the payment account to the corresponding device, the method includes linking the payment account to the corresponding device and providing an indication that the payment account has been linked to the corresponding device. The method also includes, in accordance with a determination that further verification is required to link the payment account to the corresponding device, providing an indication that further verification is required to link the payment account to the corresponding device.

[0009] According to some embodiments, a method is performed on an electronic device having a display and a near-field communications radio. The method includes detecting, by the near-field communications radio, the presence of a field generated by a contactless payment transaction terminal. The method includes determining, in response to detecting the presence of the field generated by the contactless payment transaction terminal, whether authorization to proceed with the payment transaction is provided. The method proceeds with the payment transaction with the contactless payment transaction terminal in accordance with a determination that authorization to proceed with the payment transaction has been provided. The method also includes providing an indication requesting authorization to proceed with the payment transaction in accordance with a determination that authorization to proceed with the payment transaction has not been provided.

[0010] According to some embodiments, a method is performed on an electronic device having a display. The method includes displaying on the display an electronic wallet including a corresponding representation of a payment account, the corresponding representation of the payment account including first transaction information related to a first payment transaction associated with the payment account. The method includes detecting a second payment transaction using the electronic device associated with the payment account. The method also includes, in response to detecting the second payment transaction, displaying second transaction information related to the second payment transaction before receiving information related to the second payment transaction from a financial institution involved in the second transaction, the second transaction information being based on information locally available on the electronic device.

[0011] According to some embodiments, a method is performed on an electronic device having a display. The method includes displaying a user interface of a first application on the display, the user interface of the first application including a payment affordance associated with the payment transaction. The method includes detecting a selection of the payment affordance. The method also includes, in response to detecting the selection of the payment affordance, transferring first transaction information related to the payment transaction from the first application to a second application and displaying a user interface of the second application on the display, the user interface of the second application including the first transaction information received from the first application and second transaction information provided by the second application, the second transaction information being unavailable to the first application.

[0012] According to some embodiments, a method is executed on an electronic device having a processor and a memory, the method including: linking a plurality of payment accounts to the electronic device, the plurality of payment accounts including a first payment account and a second payment account, the second payment account being different from the first payment account; receiving a payment transaction request for a payment transaction, the first payment account and the second payment account being both available to make payment for the payment transaction; obtaining payment account selection information in response to receiving the payment transaction request; and, in accordance with a determination that criteria for the first payment transaction are met based on the payment account selection information, making the payment in the payment transaction using the first payment account; and, in accordance with a determination that criteria for the second payment transaction are met based on the payment account selection information, making the payment in the payment transaction using the second payment account.

[0013] According to some embodiments, a method is performed on an electronic device having a display, a processor, and a memory. The method includes authorizing a payment transaction for a purchase item using a payment account linked to the electronic device, the purchase item being selected from a set including physical goods and real-world services, determining, after authorizing the payment transaction, that the purchase item is associated with a digital item, the digital item being different from the purchase item, and providing, on a display of the device, an indication of the digital item associated with the purchase item.

[0014] According to some embodiments, a method is performed in an electronic device having a display, a processor, and a memory. The method includes displaying a user interface of a communications application including a user interface indicating an ongoing communication between a user of the device and one or more other participants, the user interface of the communications application including a payment affordance; detecting activation of the payment affordance while displaying the user interface indicating the ongoing communication; and in response to detecting activation of the payment affordance, initiating a payment transaction between the user and one or more other participants in the ongoing communication.

[0015] According to some embodiments, a method is performed on an electronic device having a display, a processor, and a memory, the method including: displaying a user interface of a first application, the user interface of the first application including information identifying a plurality of retailers; receiving a request to initiate a payment transaction with a first retailer of the plurality of retailers; in response to receiving the request to initiate a payment transaction with the first retailer, invoking the first retailer's application in accordance with a determination that the first retailer's application is available on the device, the first retailer's application enabling a user to initiate the payment transaction with the first retailer; and in accordance with a determination that the first retailer's application is not available on the device, providing the user with an option to proceed with the payment transaction without invoking the first retailer's application.

[0016] According to some embodiments, a method is performed on an electronic device having a display, a processor, and a memory, the method including obtaining a history of payment transactions associated with one or more payment accounts linked to the device, determining a current location of the device, determining recommended products to purchase from a retailer based at least in part on the history of payment transactions and the current location of the device, displaying an indication of the recommended products to purchase, displaying affordances associated with the payment transaction for the recommended products, detecting activation of the affordance associated with the payment transaction while displaying the affordances associated with the payment transaction, and in response to detecting activation of the affordance associated with the payment transaction, initiating processing to authorize the payment transaction for the recommended products.

[0017] Thus, a multifunction device is provided with a faster, more efficient method and interface for processing payment transactions, thereby increasing effectiveness, efficiency, and user satisfaction with such a device. Such a method and interface can complement or replace conventional methods for processing payment transactions. [Brief explanation of the drawings]

[0018] For a better understanding of the foregoing embodiments of the present invention, as well as additional embodiments thereof, please refer to the following detailed description in connection with the following drawings, in which like reference numerals refer to corresponding parts throughout:

[0019] [Figure 1A] FIG. 1 is a block diagram illustrating a portable multifunction device with a display in accordance with some embodiments.

[0020] [Figure 1B]FIG. 2 is a block diagram illustrating exemplary components for event processing according to some embodiments.

[0021] [Figure 2] FIG. 1 is a diagram of a portable multifunction device with a touch screen in accordance with some embodiments.

[0022] [Figure 3] FIG. 1 is a block diagram of an exemplary multifunction device with a display in accordance with some embodiments.

[0023] [Figure 4A] 1 is a diagram of an exemplary user interface for a menu of applications on a portable multifunction device in accordance with some embodiments.

[0024] [Figure 4B] 1A-1C are diagrams of exemplary user interfaces of multifunction devices with touch-sensitive surfaces that are separate from the display in accordance with some embodiments.

[0025] [Figure 5A] FIG. 10 is a diagram of an exemplary user interface for linking a payment account to a corresponding device, according to some embodiments. [Figure 5B] FIG. 10 is a diagram of an exemplary user interface for linking a payment account to a corresponding device, according to some embodiments. [Figure 5C] FIG. 10 is a diagram of an exemplary user interface for linking a payment account to a corresponding device, according to some embodiments. [Figure 5D] FIG. 10 is a diagram of an exemplary user interface for linking a payment account to a corresponding device, according to some embodiments. [Figure 5E] FIG. 10 is a diagram of an exemplary user interface for linking a payment account to a corresponding device, according to some embodiments. [Figure 5F]FIG. 10 is a diagram of an exemplary user interface for linking a payment account to a corresponding device, according to some embodiments. [Figure 5G] FIG. 10 is a diagram of an exemplary user interface for linking a payment account to a corresponding device, according to some embodiments. [Figure 5H] FIG. 10 is a diagram of an exemplary user interface for linking a payment account to a corresponding device, according to some embodiments. [Figure 5I] FIG. 10 is a diagram of an exemplary user interface for linking a payment account to a corresponding device, according to some embodiments.

[0026] [Figure 6A] FIG. 1 is a flow diagram illustrating a method for linking a payment account to a corresponding device according to some embodiments. [Figure 6B] FIG. 1 is a flow diagram illustrating a method for linking a payment account to a corresponding device according to some embodiments. [Figure 6C] FIG. 1 is a flow diagram illustrating a method for linking a payment account to a corresponding device according to some embodiments.

[0027] [Figure 7A] FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments. [Figure 7B] FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments. [Figure 7C] FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments. [Figure 7D] FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments. [Figure 7E]FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments. [Figure 7F] FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments. [Figure 7G] FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments. [Figure 7H] FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments. [Figure 7I] FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments. [Figure 7J] FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments. [Figure 7K] FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments. [Figure 7L] FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments. [Figure 7M] FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments. [Figure 7N] FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments. [Figure 7O] FIG. 10 is a diagram of an exemplary user interface for facilitating a payment transaction using a near field communication radio, according to some embodiments.

[0028] [Figure 8A] FIG. 1 is a flow diagram illustrating a method for facilitating a payment transaction using a near-field communication radio, according to some embodiments. [Figure 8B] FIG. 1 is a flow diagram illustrating a method for facilitating a payment transaction using a near-field communication radio, according to some embodiments.

[0029] [Figure 9A] FIG. 10 is a diagram of an exemplary user interface for displaying transaction information for a payment account according to some embodiments. [Figure 9B] FIG. 10 is a diagram of an exemplary user interface for displaying transaction information for a payment account according to some embodiments. [Figure 9C] FIG. 10 is a diagram of an exemplary user interface for displaying transaction information for a payment account according to some embodiments. [Figure 9D] FIG. 10 is a diagram of an exemplary user interface for displaying transaction information for a payment account according to some embodiments. [Figure 9E] FIG. 10 is a diagram of an exemplary user interface for displaying transaction information for a payment account according to some embodiments. [Figure 9F] FIG. 10 is a diagram of an exemplary user interface for displaying transaction information for a payment account according to some embodiments. [Figure 9G] FIG. 10 is a diagram of an exemplary user interface for displaying transaction information for a payment account according to some embodiments. [Figure 9H] FIG. 10 is a diagram of an exemplary user interface for displaying transaction information for a payment account according to some embodiments.

[0030] [Figure 10A] FIG. 1 is a flow diagram illustrating a method for displaying transaction information for a payment account according to some embodiments. [Figure 10B] FIG. 1 is a flow diagram illustrating a method for displaying transaction information for a payment account according to some embodiments.

[0031] [Figure 11A] FIG. 1 is a diagram of an exemplary user interface for conducting a payment transaction, according to some embodiments. [Figure 11B] FIG. 1 is a diagram of an exemplary user interface for conducting a payment transaction, according to some embodiments. [Figure 11C] FIG. 1 is a diagram of an exemplary user interface for conducting a payment transaction, according to some embodiments. [Figure 11D] FIG. 1 is a diagram of an exemplary user interface for conducting a payment transaction, according to some embodiments. [Figure 11E] FIG. 1 is a diagram of an exemplary user interface for conducting a payment transaction, according to some embodiments. [Figure 11F] FIG. 1 is a diagram of an exemplary user interface for conducting a payment transaction, according to some embodiments. [Figure 11G] FIG. 1 is a diagram of an exemplary user interface for conducting a payment transaction, according to some embodiments. [Figure 11H] FIG. 1 is a diagram of an exemplary user interface for conducting a payment transaction, according to some embodiments. [Figure 11I] FIG. 1 is a diagram of an exemplary user interface for conducting a payment transaction, according to some embodiments. [Figure 11J] FIG. 1 is a diagram of an exemplary user interface for conducting a payment transaction, according to some embodiments. [Figure 11K] FIG. 1 is a diagram of an exemplary user interface for conducting a payment transaction, according to some embodiments. [Figure 11L]FIG. 1 is a diagram of an exemplary user interface for conducting a payment transaction, according to some embodiments. [Figure 11M] FIG. 1 is a diagram of an exemplary user interface for conducting a payment transaction, according to some embodiments. [Figure 11N] FIG. 1 is a diagram of an exemplary user interface for conducting a payment transaction, according to some embodiments.

[0032] [Figure 12A] FIG. 1 is a flow diagram illustrating a method for conducting a payment transaction according to some embodiments. [Figure 12B] FIG. 1 is a flow diagram illustrating a method for conducting a payment transaction according to some embodiments. [Figure 12C] FIG. 1 is a flow diagram illustrating a method for conducting a payment transaction according to some embodiments.

[0033] [Figure 13A] FIG. 10 is a diagram of an exemplary user interface for selecting a payment account from among available payment accounts, according to some embodiments. [Figure 13B] FIG. 10 is a diagram of an exemplary user interface for selecting a payment account from among available payment accounts, according to some embodiments. [Figure 13C] FIG. 10 is a diagram of an exemplary user interface for selecting a payment account from among available payment accounts, according to some embodiments. [Figure 13D] FIG. 10 is a diagram of an exemplary user interface for selecting a payment account from among available payment accounts, according to some embodiments.

[0034] [Figure 14] FIG. 1 is a flow diagram illustrating a method for selecting a payment account from among available payment accounts, according to some embodiments.

[0035] [Figure 15] FIG. 10 is a diagram of an exemplary user interface for displaying an indication of digital items related to a purchase item, according to some embodiments.

[0036] [Figure 16] FIG. 1 is a flow diagram illustrating a method for displaying an indication of a digital item related to a purchase item, according to some embodiments.

[0037] [Figure 17A] FIG. 10 is a diagram of an exemplary user interface for initiating a payment transaction with a participant in an ongoing communication, according to some embodiments. [Figure 17B] FIG. 10 is a diagram of an exemplary user interface for initiating a payment transaction with a participant in an ongoing communication, according to some embodiments.

[0038] [Figure 18] FIG. 1 is a flow diagram illustrating a method for initiating a payment transaction with a participant in an ongoing communication, according to some embodiments.

[0039] [Figure 19] FIG. 10 is a diagram of an exemplary user interface for invoking a retailer's application based on application availability, according to some embodiments.

[0040] [Figure 20] FIG. 1 is a flow diagram illustrating a method for invoking a retailer's application based on application availability, according to some embodiments.

[0041] [Figure 21] FIG. 1 is a diagram of an exemplary user interface for providing purchasing recommendations, according to some embodiments.

[0042] [Figure 22]FIG. 1 is a flow diagram illustrating a method for providing purchasing recommendations, according to some embodiments.

[0043] [Figure 23] FIG. 1 is a functional block diagram according to some embodiments. [Figure 24] FIG. 1 is a functional block diagram according to some embodiments. [Figure 25] FIG. 1 is a functional block diagram according to some embodiments. [Figure 26] FIG. 1 is a functional block diagram according to some embodiments. [Figure 27] FIG. 1 is a functional block diagram according to some embodiments. [Figure 28] FIG. 1 is a functional block diagram according to some embodiments. [Figure 29] FIG. 1 is a functional block diagram according to some embodiments. [Figure 30] FIG. 1 is a functional block diagram according to some embodiments. [Figure 31] FIG. 1 is a functional block diagram according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0044] In the following description, example methods, parameters, etc. are set forth. However, it should be understood that the purpose of such description is not to limit the scope of the present disclosure, but rather to provide a description of example embodiments.

[0045] There is a need for electronic devices with faster and more efficient methods and interfaces for conducting payment transactions. Such methods and interfaces optionally complement or replace traditional methods for conducting payments. Such methods and interfaces reduce the cognitive burden on users and create a more efficient human-machine interface. In the case of battery-operated computing devices, such methods and interfaces conserve power and increase the time between battery charges. Furthermore, such techniques can reduce processor and battery power that would otherwise be wasted based on redundant user input.

[0046] Figures 1A-1B, 2, 3, 4A-4B, and 23-31 provide illustrations of exemplary devices for implementing payment-related techniques. Figures 5, 7, 9, 11, 13, 15, 17, 19, and 21 show exemplary user interfaces for payment. The user interfaces in these figures are also used to illustrate the methods described below (including the methods of Figures 6, 8, 10, 12, 14, 16, 18, 20, and 22).

[0047] In the following description, terms such as "first" and "second" are used to describe various elements, but these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first touch can be referred to as a second touch, and similarly, a second touch can be referred to as a first touch, without departing from the scope of the various embodiments described. A first touch and a second touch are both touches, but are not the same touch.

[0048] The terminology used in the description of the various embodiments set forth herein is for the purpose of describing particular embodiments only and is not intended to be limiting. When used in the description of the various embodiments set forth and in the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. As used herein, it should also be understood that the term "and / or" refers to and includes any and all possible combinations of one or more of the associated listed items. It should be further understood that the terms "includes," "including," "comprises," and / or "comprising," when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0049] The term "if" may be interpreted to mean "when," "upon," "in response to determining," or "in response to detecting," depending on the context. Similarly, the phrases "if it is determined" or "if [a stated condition or event] is detected" may be interpreted to mean "upon determining," "in response to determining," "upon detecting [the stated condition or event]," or "in response to detecting [the stated condition or event]," depending on the context.

[0050] Embodiments of electronic devices, user interfaces for such devices, and associated methods for using such devices are described. In some embodiments, the device is a portable communication device, such as a mobile telephone, that also includes other functions, such as PDA and / or music player functionality. Exemplary embodiments of portable multifunction devices include, without limitation, iPhone®, iPod Touch®, and iPad® devices from Apple Inc. of Cupertino, California. Other portable electronic devices, such as laptops or tablet computers with touch-sensitive surfaces (e.g., touchscreen displays and / or touchpads), can also optionally be used. It should also be understood that in some embodiments, the device is not a portable communication device, but rather a desktop computer with a touch-sensitive surface (e.g., touchscreen displays and / or touchpads).

[0051] In the following description, we describe an electronic device with a display and a touch-sensitive surface, but it should be understood that the electronic device optionally includes one or more other physical user interface devices, such as a physical keyboard, a mouse, and / or a joystick.

[0052] The device may support a variety of applications, such as one or more of a drawing application, a presentation application, a word processing application, a website creation application, a disc authoring application, a spreadsheet application, a gaming application, a telephone application, a video conferencing application, an email application, an instant messaging application, a training support application, a photo management application, a digital camera application, a digital video camera application, a web browsing application, a digital music player application, and / or a digital video player application.

[0053] Various applications running on the device optionally use at least one common physical user interface device, such as a touch-sensitive surface. One or more features of the touch-sensitive surface and corresponding information displayed on the device are optionally adjusted and / or changed for each application and / or among corresponding applications. In this way, the common physical architecture (such as the touch-sensitive surface) of the device optionally supports various applications with user interfaces that are intuitive and transparent to the user.

[0054] Attention now turns to embodiments of portable devices with touch-sensitive displays. FIG. 1A is a block diagram illustrating a portable multifunction device 100 with a touch-sensitive display system 112, according to some embodiments. Touch-sensitive display 112 is sometimes conveniently referred to as a "touch screen" and may also be known or referred to as a "touch-sensitive display system." Device 100 includes memory 102 (optionally including one or more computer-readable storage media), a memory controller 122, one or more processing units (CPUs) 120, a peripherals interface 118, RF circuitry 108, audio circuitry 110, a speaker 111, a microphone 113, an input / output (I / O) subsystem 106, other input control devices 116, and an external port 124. Device 100 optionally includes one or more light sensors 164. Device 100 optionally includes one or more intensity sensors 165 (e.g., a touch-sensitive surface such as touch-sensitive display system 112 of device 100) for detecting the intensity of a contact on device 100. Device 100 optionally includes one or more tactile output generators 167 for generating a tactile output on device 100 (e.g., generating a tactile output on a touch-sensitive surface such as touch-sensitive display system 112 of device 100 or touchpad 355 of device 300). These components optionally communicate over one or more communication buses or signal lines 103.

[0055] As used in this specification and claims, the term “intensity” of a contact on a touch-sensitive surface refers to the force or pressure (force per unit area) of a contact (e.g., a finger contact) on the touch-sensitive surface, or a surrogate (proxy) for the force or pressure of a contact on the touch-sensitive surface. The intensity of a contact has a range of values ​​including at least four different values ​​and more typically including hundreds of different values ​​(e.g., at least 256). The intensity of a contact is optionally determined (or measured) using various methods and various sensors or combinations of sensors. For example, one or more force sensors positioned below or adjacent to the touch-sensitive surface are optionally used to measure force at various points on the touch-sensitive surface. In some implementations, the force measurements of multiple force sensors are combined (e.g., weighted average) to determine an estimated force of a contact. Similarly, a pressure-sensitive tip of a stylus is optionally used to determine the pressure of the stylus on the touch-sensitive surface. Alternatively, the size and / or change in the contact area detected on the touch-sensitive surface, the capacitance and / or change in the capacitance of the touch-sensitive surface proximate the contact, and / or the resistance and / or change in the capacitance of the touch-sensitive surface proximate the contact are optionally used as proxies for the force or pressure of the contact on the touch-sensitive surface. In some implementations, the surrogate measure of the force or pressure of the contact is used directly to determine whether an intensity threshold has been exceeded (e.g., the intensity threshold is stated in units corresponding to the surrogate measure). In some implementations, the surrogate measure of the force or pressure of the contact is converted to an estimated force or pressure, and the estimated force or pressure is used to determine whether an intensity threshold has been exceeded (e.g., the intensity threshold is a pressure threshold measured in units of pressure). Using contact intensity as an attribute of user input allows users access to additional device functionality that may not otherwise be accessible to users in reduced-size devices with limited area for displaying affordances (e.g., on a touch-sensitive display) and / or receiving user input (e.g., via a touch-sensitive display, touch-sensitive surface, or physical / mechanical controls such as knobs or buttons).

[0056] As used herein and in the claims, the term “tactile output” refers to a physical displacement of a device relative to a previous position of the device, a physical displacement of a component of the device (e.g., a touch-sensitive surface) relative to another component of the device (e.g., a housing), or a displacement of a component relative to the center of gravity of the device, which is detected by a user with the user's sense of touch. For example, in a situation where a device or a component of the device is in contact with a touch-sensitive surface of a user (e.g., the fingers, palm, or other part of the user's hand), the tactile output produced by the physical displacement is interpreted by the user as a tactile sensation corresponding to a perceived change in a physical property of the device or a component of the device. For example, movement of a touch-sensitive surface (e.g., a touch-sensitive display or trackpad) is optionally interpreted by the user as a “downclick” or “upclick” of a physical actuator button. In some cases, a user feels a tactile sensation such as a “downclick” or “upclick” even when no movement of a physical actuator button associated with the touch-sensitive surface is physically pressed (e.g., displaced) by the user's action. As another example, movement of the touch-sensitive surface is optionally interpreted or felt by a user as "roughness" of the touch-sensitive surface, even when there is no change in the smoothness of the touch-sensitive surface. On the other hand, a user's interpretation of touch will be subject to the user's individualized sensations, although there are many sensations of touch that are common to the majority of users. Thus, when a tactile output is described as corresponding to a particular sensory perception of a user (e.g., "upclick," "downclick," "roughness"), unless otherwise specified, the generated tactile output corresponds to a physical displacement of the device, or a component of the device, that produces the described sensory perception for a typical (or average) user.

[0057] It should be understood that device 100 is only one example of a portable multifunction device, and that device 100 optionally has more or fewer components than those shown, optionally combines two or more components, or optionally has a different configuration or arrangement of components. The various components shown in Figure 1A may be implemented in hardware, software, or a combination of both hardware and software, including one or more signal processing circuits and / or application specific integrated circuits.

[0058] Memory 102 may include one or more computer-readable storage media. The computer-readable storage media may be tangible and non-transitory. Memory 102 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid-state memory devices. Memory controller 122 may control access to memory 102 by other components of device 100.

[0059] A peripheral interface 118 can be used to couple input and output peripherals of the device to the CPU 120 and memory 102. The one or more processors 120 run or execute various software programs and / or instruction sets stored in memory 102 to perform various functions for device 100 and to process data. In some embodiments, the peripheral interface 118, CPU 120, and memory controller 122 may be implemented on a single chip, such as chip 104. In some other embodiments, they may be implemented on separate chips.

[0060] The RF (radio frequency) circuitry 108 transmits and receives RF signals, also called electromagnetic signals. The RF circuitry 108 converts electrical signals to electromagnetic signals and electromagnetic signals to electrical signals and communicates with communication networks and other communication devices via electromagnetic signals. To perform these functions, the RF circuitry 108 optionally includes well-known circuitry, including, but not limited to, an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a CODEC chipset, a subscriber identity module (SIM) card, memory, etc. The RF circuitry 108 optionally communicates via wireless communication with networks, such as the Internet, also called the World Wide Web (WWW), an intranet, and / or a wireless network, such as a cellular telephone network, a wireless local area network (LAN), and / or a metropolitan area network (MAN), and with other devices. The RF circuitry 108 optionally includes well-known circuitry for detecting near field communication (NFC) fields, such as by a near field communication radio. The wireless communication optionally uses any of a number of communication standards, protocols, and technologies, including Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), high-speed downlink packet access (HSDPA), high-speed uplink packet access (HSUPA), Evolution, Data-Only (EV-DO), HSPA, HSPA+, Dual-Cell HSPA (DC-HSPA), long term evolution (LTE), near field communication (NFC), wideband code division multiple access (W-CDMA), code division multiple access (CDMA), and the like.Wireless technologies include, but are not limited to, standard wireless technologies such as code division multiple access (CDMA), time division multiple access (TDMA), Bluetooth, Bluetooth Low Energy (BTLE), Wireless Fidelity (Wi-Fi) (e.g., IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, and / or IEEE 802.11ac), voice over Internet Protocol (VoIP), Wi-MAX, protocols for email (e.g., Internet message access protocol (IMAP) and / or post office protocol (POP)), instant messaging (e.g., extensible messaging and presence protocol (XMPP)), Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE), instant messaging and presence services (e.g., IEEE 802.11b), and protocols for mobile devices (e.g., cellular). The communication protocols include, but are not limited to, the International Mobile Presence Service (IMPS), and / or the Short Message Service (SMS), or any other suitable communication protocol, including communication protocols not yet developed as of the filing date of this document.

[0061] The audio circuit 110, speaker 111, and microphone 113 provide an audio interface between the user and device 100. The audio circuit 110 receives audio data from the peripherals interface 118, converts the audio data into electrical signals, and transmits the electrical signals to the speaker 111. The speaker 111 converts the electrical signals into sound waves audible to humans. The audio circuit 110 also receives electrical signals converted from sound waves by the microphone 113. The audio circuit 110 converts the electrical signals into audio data and transmits the audio data to the peripherals interface 118 for processing. The audio data may be retrieved from and / or transmitted to the memory 102 and / or RF circuit 108 by the peripherals interface 118. In some embodiments, the audio circuit 110 further includes a headset jack (e.g., 212 in FIG. 2 ). The headset jack provides an interface between audio circuitry 110 and a removable audio input / output peripheral, such as an output-only headphone or a headset with both an output (e.g., single or double ear headphones) and an input (e.g., a microphone).

[0062] I / O subsystem 106 couples input / output peripherals of device 100, such as touchscreen 112 and other input control devices 116, to peripheral interface 118. I / O subsystem 106 optionally includes a display controller 156, a light sensor controller 158, an intensity sensor controller 159, a haptic feedback controller 161, and one or more input controllers 160 for other input or control devices. One or more input controllers 160 receive / send electrical signals from / to other input control devices 116. Other input control devices 116 optionally include physical buttons (e.g., push buttons, rocker buttons, etc.), dials, slider switches, joysticks, click wheels, etc. In some alternative embodiments, input controller(s) 160 are optionally coupled to any (or none) of a keyboard, an infrared port, a USB port, and a pointer device such as a mouse. The one or more buttons (e.g., 208 in FIG. 2) optionally include up / down buttons for adjusting the volume of the speaker 111 and / or microphone 113. The one or more buttons optionally include a push button (e.g., 206 in FIG. 2).

[0063] A quick press of a push button may unlock the touchscreen 112, or a gesture on the touchscreen may be used to initiate the process of unlocking the device, as described in U.S. Patent Application No. 11 / 322,549, "Unlocking a Device by Performing Gestures on an Unlock Image," U.S. Patent No. 7,657,849, filed December 23, 2005, which is incorporated by reference in its entirety. A longer press of a push button (e.g., 206) may power the device 100 on or off. The user may customize the function of one or more buttons. The touchscreen 112 may be used to implement virtual or soft buttons and one or more soft keyboards.

[0064] Touch-sensitive display 112 provides an input and output interface between the device and a user. Display controller 156 receives and / or sends electrical signals to / from touchscreen 112. Touchscreen 112 displays visual output to the user. This visual output may include graphics, text, icons, video, and any combination thereof (collectively referred to as "graphics"). In some embodiments, some or all of these visual outputs may correspond to user interface objects.

[0065] Touchscreen 112 has a touch-sensitive surface, sensor, or set of sensors that receives input from a user based on tactile and / or haptic contact. Touchscreen 112 and display controller 156 (along with any associated modules and / or instruction sets in memory 102) detect contacts (and any movement or cessation of contact) on touchscreen 112 and translate the detected contacts into interactions with user interface objects (e.g., one or more softkeys, icons, web pages, or images) displayed on touchscreen 112. In one exemplary embodiment, contact between touchscreen 112 and a user corresponds to the user's finger.

[0066] Touchscreen 112 may use liquid crystal display (LCD), light emitting polymer display (LPD), or light emitting diode (LED) technology, although other display technologies may be used in other embodiments. Touchscreen 112 and display controller 156 may detect contact and any movement or disruption thereof using any of a number of now-known or later-developed touch-sensing technologies, including, but not limited to, capacitive, resistive, infrared, and surface ultrasonic technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with touchscreen 112. In an exemplary embodiment, projected mutual capacitance sensing technology is used, such as that found in the iPhone® and iPod Touch® from Apple Inc. of Cupertino, California.

[0067] The touch-sensitive display in some embodiments of touchscreen 112 may be similar to the multi-touch-sensing touchpads described in the following U.S. Patents: 6,323,846 (Westerman et al.), 6,570,557 (Westerman et al.), and / or 6,677,932 (Westerman), and / or U.S. Patent Application Publication No. 2002 / 0015024 A1, each of which is incorporated by reference herein in its entirety, except that touchscreen 112 displays visual output from device 100, whereas touch-sensitive touchpads do not provide visual output.

[0068] The touch-sensitive display in some embodiments of touchscreen 112 may be as described in the following applications: (1) U.S. Patent Application No. 11 / 381,313, "Multipoint Touch Surface Controller," filed May 2, 2006; (2) U.S. Patent Application No. 10 / 840,862, "Multipoint Touchscreen," filed May 6, 2004; (3) U.S. Patent Application No. 10 / 903,964, "Gestures For Touch Sensitive Input Devices," filed July 30, 2004; (4) U.S. Patent Application No. 11 / 048,264, "Gestures For Touch Sensitive Input Devices," filed January 31, 2005; (5) U.S. Patent Application No. 11 / 038,590, "Mode-Based Graphical User Interfaces For Touch Sensitive Input Devices," filed January 18, 2005; (6) U.S. Patent Application No. 11 / 228,758, "Virtual Input Device Placement On A Touch Screen User Interface" (7) U.S. Patent Application No. 11 / 228,700, "Operation Of A Computer With A Touch Screen Interface," filed September 16, 2005; (8) U.S. Patent Application No. 11 / 228,737, "Activating Virtual Keys Of A Touch-Screen Virtual Keyboard," filed September 16, 2005; and (9) U.S. Patent Application No. 11 / 367,749, "Multi-Functional Hand-Held Device," filed March 3, 2006. All of these applications are incorporated herein by reference in their entirety.

[0069] The touchscreen 112 may have a video resolution greater than 100 dpi. In some embodiments, the touchscreen has a video resolution of approximately 160 dpi. A user can contact the touchscreen 112 using any suitable object or accessory, such as a stylus, a finger, or the like. In some embodiments, the user interface is designed to function primarily with finger-based contact and gestures, which may be less precise than stylus-based input due to the large contact area of ​​a finger on the touchscreen. In some embodiments, the device translates coarse, finger-based input into precise pointer / cursor position or commands to perform the user's desired action.

[0070] In some embodiments, in addition to the touchscreen, device 100 may include a touchpad (not shown) for activating or deactivating certain functions. In some embodiments, the touchpad is a touch-sensitive area of ​​the device that, unlike the touchscreen, does not display visual output. The touchpad may be a touch-sensitive surface separate from touchscreen 112 or an extension of the touch-sensitive surface formed by the touchscreen.

[0071] Device 100 also includes a power system 162 for providing power to the various components. Power system 162 may include a power management system, one or more power sources (e.g., batteries, alternating current (AC)), a recharging system, power failure detection circuitry, power converters or inverters, power status indicators (e.g., light emitting diodes (LEDs)), and any other components associated with the generation, management, and distribution of power in a portable device.

[0072] Device 100 may also include one or more light sensors 164. FIG. 1A shows a light sensor coupled to light sensor controller 158 of I / O subsystem 106. Light sensor 164 may include a charge-coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS) phototransistor. Light sensor 164 receives light from the environment projected through one or more lenses and converts the light into data representing an image. In conjunction with imaging module 143 (also referred to as a camera module), light sensor 164 may capture still images or video. In some embodiments, a light sensor is located on the back of device 100, opposite touchscreen display 112 on the front of the device, so that the touchscreen display can be used as a viewfinder for still and / or video image acquisition. In some embodiments, a light sensor is located on the front of the device so that an image of the user can be obtained for video conferencing while the user views other video conference participants on the touchscreen display. In some embodiments, the position of the light sensor 164 can be changed by the user (e.g., by rotating the lens and sensor within the device housing), allowing a single light sensor 164 to be used for both video conferencing and still and / or video image capture in conjunction with a touchscreen display.

[0073] Device 100 also optionally includes one or more contact intensity sensors 165. FIG. 1A shows contact intensity sensors coupled to intensity sensor controller 159 in I / O subsystem 106. Contact intensity sensors 165 optionally include one or more piezoresistive strain gauges, capacitive force sensors, electric force sensors, piezoelectric force sensors, optical force sensors, capacitive touch-sensitive surfaces, or other intensity sensors (e.g., sensors used to measure contact force (or pressure) on a touch-sensitive surface). Contact intensity sensors 165 receive contact intensity information (e.g., pressure information or a proxy for pressure information) from the environment. In some embodiments, at least one contact intensity sensor is located on or in proximity to the touch-sensitive surface (e.g., touch-sensitive display system 112). In some embodiments, at least one contact intensity sensor is located on the back of device 100, opposite touchscreen display 112, which is located on the front of device 100.

[0074] Device 100 may also include one or more proximity sensors 166. FIG. 1A shows proximity sensor 166 coupled to peripheral interface 118. Alternatively, proximity sensor 166 may be coupled to input controller 160 within I / O subsystem 106. Proximity sensor 166 may operate as described in U.S. patent application Ser. Nos. 11 / 241,839, "Proximity Detector In Handheld Device," 11 / 240,788, "Proximity Detector In Handheld Device," 11 / 620,702, "Using Ambient Light Sensor To Augment Proximity Sensor Output," 11 / 586,862, "Automated Response To And Sensing Of User Activity In Portable Devices," and 11 / 638,251, "Methods And Systems For Automatic Configuration Of Peripherals," which are incorporated herein by reference in their entireties. In some embodiments, when the multifunction device is placed near the user's ear (eg, when the user is on a phone call), the proximity sensor turns off and disables touchscreen 112.

[0075] Device 100 also optionally includes one or more tactile output generators 167. FIG. 1A shows tactile output generator 167 coupled to haptic feedback controller 161 in I / O subsystem 106. Tactile output generator 167 optionally includes one or more electroacoustic devices, such as speakers or other audio components, and / or electromechanical devices that convert energy into linear motion, such as motors, solenoids, electroactive polymers, piezoelectric actuators, electrostatic actuators, or other tactile output generating components (e.g., components that convert electrical signals into tactile output on the device). Contact intensity sensor 165 receives tactile feedback generation instructions from haptic feedback module 133 and generates a tactile output on device 100 that can be sensed by a user of device 100. In some embodiments, at least one tactile output generator is located on or proximate to a touch-sensitive surface (e.g., touch-sensitive display system 112) and, optionally, generates a tactile output in response to movement of the touch-sensitive surface vertically (e.g., into or out of the surface of device 100) or laterally (e.g., back and forth in the same plane as the surface of device 100). In some embodiments, at least one tactile output generator sensor is located on the back of device 100, opposite touchscreen display 112, which is located on the front of device 100.

[0076] Device 100 may further include one or more accelerometers 168. FIG. 1A shows accelerometer 168 coupled to peripherals interface 118. Alternatively, accelerometer 168 may be coupled to input controller 160 in I / O subsystem 106. Accelerometer 168 may operate as described in U.S. Patent Application Publication No. 20050190059, "Acceleration-Based Theft Detection System for Portable Electronic Devices," and U.S. Patent Application Publication No. 20060017692, "Methods And Apparatuses For Operating A Portable Device Based On An Accelerometer," both of which are incorporated by reference in their entireties. In some embodiments, information is displayed on a touchscreen display in portrait or landscape orientation based on an analysis of data received from one or more accelerometers. In addition to accelerometer(s) 168, device 100 optionally includes a magnetometer (not shown) and a GPS (or GLONASS or other global navigation system) receiver (not shown) for obtaining information regarding the location and orientation (e.g., portrait or landscape) of device 100.

[0077] In some embodiments, the software components stored in memory 102 include an operating system 126, a communications module (or instruction set) 128, a touch / movement module (or instruction set) 130, a graphics module (or instruction set) 132, a text input module (or instruction set) 134, a global positioning system (GPS) module (or instruction set) 135, and applications (or instruction sets) 136. Additionally, in some embodiments, memory 102 (FIG. 1A) or memory 370 (FIG. 3) stores device / global internal state 157, as shown in FIGS. 1A and 3. Device / global internal state 157 includes one or more of: an active application state indicating which applications, if any, are currently active; a display state indicating which applications, views, or other information occupy various regions of touchscreen display 112; a sensor state including information obtained from the device's various sensors and input control devices 116; and location information regarding the device's position and / or orientation.

[0078] Operating system 126 (e.g., an embedded operating system such as Darwin®, RTXC®, LINUX®, UNIX®, OSX®, iOS, WINDOWS®, or VxWorks®) includes various software components and / or drivers for controlling and managing common system tasks (e.g., memory management, storage device control, power management, etc.) and facilitating communication between various hardware and software components.

[0079] Communications module 128 facilitates communication with other devices via one or more external ports 124 and further includes various software components for processing data received by RF circuitry 108 and / or external port 124. External port 124 (e.g., Universal Serial Bus (USB), FIREWIRE®, etc.) is suitable for coupling to other devices directly or indirectly via a network (e.g., the Internet, wireless LAN, etc.). In some embodiments, the external port is a multi-pin (e.g., 30-pin) connector identical to, similar to, and / or compatible with the 30-pin connector used on iPod (trademark of Apple Inc.) devices.

[0080] Contact / movement module 130, optionally in cooperation with display controller 156, detects contact with touch screen 112 and other touch-sensing devices (e.g., a touchpad or physical click wheel). Contact / movement module 130 includes various software components for performing various operations related to detecting contact, such as determining whether contact has occurred (e.g., detecting a finger down event), determining the intensity of the contact (e.g., the force or pressure of the contact, or a surrogate for the force or pressure of the contact), determining whether there is contact movement and tracking of the movement across the touch-sensitive surface (e.g., detecting one or more finger drag events), and determining whether the contact has ceased (e.g., detecting a finger up event or an interruption of contact). Contact / movement module 130 receives contact data from the touch-sensitive surface. Determining the movement of the contact point represented by the series of contact data optionally includes determining the speed (magnitude), velocity (magnitude and direction), and / or acceleration (change in magnitude and / or direction) of the contact point. These actions are optionally applied to a single contact (e.g., one finger contact) or multiple simultaneous contacts (e.g., "multi-touch" / multiple finger contacts). In some embodiments, contact / movement module 130 and display controller 156 detect contacts on the touchpad.

[0081] In some embodiments, contact / movement module 130 uses a set of one or more intensity thresholds for determining whether an action has been performed by the user (e.g., for determining whether the user has “clicked” on an icon). In some embodiments, at least a subset of the intensity thresholds are determined according to software parameters (e.g., the intensity thresholds are not determined by the activation threshold of a particular physical actuator and may be adjusted without modifying the physical hardware of device 100). For example, the mouse “click” threshold of a trackpad or touchscreen display can be set to any of a wide range of predetermined thresholds without modifying the trackpad or touchscreen display hardware. Furthermore, in some implementations, a user of the device is provided with a software setting for adjusting one or more of the set of intensity thresholds (e.g., by adjusting individual intensity thresholds and / or by adjusting multiple intensity thresholds at once via a system-level click “intensity” parameter).

[0082] Contact / movement module 130 optionally detects gesture input by a user. Different gestures on the touch-sensitive surface have different contact patterns (e.g., different movements, timing, and / or intensity of the detected contact). Thus, a gesture is optionally detected by detecting a particular contact pattern. For example, detecting a finger tap gesture includes detecting a finger down event (e.g., at the location of an icon), followed by detecting a finger lift (lift-off) event at the same location (or substantially the same location) as the finger down event. As another example, detecting a finger swipe gesture on the touch-sensitive surface includes detecting a finger down event, followed by detecting one or more finger drag events, followed by detecting a finger up (lift-off) event.

[0083] Graphics module 132 includes various known software components for rendering and displaying graphics on touchscreen 112 or other display, including components for modifying the visual effects (e.g., brightness, transparency, saturation, contrast, or other visual characteristics) of the displayed graphics. As used herein, the term "graphics" includes any object that can be displayed to a user, including, but not limited to, text, web pages, icons (such as user interface objects including soft keys), digital images, video, animation, etc.

[0084] In some embodiments, graphics module 132 stores data representing graphics to be used. Each graphic is optionally assigned a corresponding code. Graphics module 132 receives one or more codes specifying the graphics to be displayed, along with coordinate data and other graphic characteristic data (if necessary), from an application or the like, and then generates screen image data to output to display controller 156.

[0085] The tactile feedback module 133 includes various software components for generating instructions used by the tactile output generator(s) 167 to generate tactile outputs at one or more locations on the device 100 in response to user interaction with the device 100.

[0086] The text input module 134 may be a component of the graphics module 132 and provides a soft keyboard for entering text in various applications (e.g., contacts 137, email 140, IM 141, browser 147, and any other application requiring text input).

[0087] The GPS module 135 determines the location of the device and provides this information for use in various applications (e.g., to the phone 138 for use in location-based dialing, to the camera 143 as image / video metadata, and to applications that provide location-based services such as weather widgets, local yellow pages widgets, and map / navigation widgets).

[0088] The application 136 may include the following modules (or sets of instructions), or a subset or superset thereof: • a contacts module 137 (sometimes called an address book or contact list); ●Telephone module 138, ●Videoconferencing module 139, ● an email client module 140; ● Instant messaging (IM) module 141; ●Training support module 142, a camera module 143 for still and / or video images, ● Image management module 144; ●Video player module, ●Music player module ● Browser module 147, ●Calendar module 148, a widget module 149, which may include one or more of a weather widget 149-1, a stock price widget 149-2, a calculator widget 149-3, an alarm clock widget 149-4, a dictionary widget 149-5, and other widgets obtained by the user, as well as user-created widgets 149-6; a widget creation module 150 for creating user-created widgets 149-6; ● Search module 151, A video and music player module 152 that integrates a video player module and a music player module; ● Memo module 153, Map module 154, and / or ●Online video module 155.

[0089] Examples of other applications 136 that may be stored in memory 102 include other word processing applications, other image editing applications, drawing applications, presentation applications, JAVA®-enabled applications, encryption, digital rights management, voice recognition, and voice duplication.

[0090] The contacts module 137, along with the touch screen 112, the display controller 156, the contact / movement module 130, the graphics module 132, and the text input module 134, may be used to manage an address book or contact list (e.g., stored in the memory 102 or in the application internal state 192 of the contacts module 137 in the memory 370), including adding a name(s) to the address book, removing a name(s) from the address book, associating phone number(s), email address(es), street address(es), or other information with a name, associating an image with a name, categorizing and sorting names, providing phone numbers or email addresses to initiate and / or facilitate communication by phone 138, video conference 139, email 140, or IM 141, etc.

[0091] Telephone module 138, along with RF circuitry 108, audio circuitry 110, speaker 111, microphone 113, touch screen 112, display controller 156, contact / movement module 130, graphics module 132, and text input module 134, may be used to enter a series of characters corresponding to a telephone number, access one or more telephone numbers in contacts module 137, modify the corresponding telephone number, dial the corresponding telephone number, conduct a conversation, and disconnect or hang up when the conversation is completed. As mentioned above, wireless communication can use any of a number of communication standards, protocols, and technologies.

[0092] In conjunction with RF circuitry 108, audio circuitry 110, speaker 111, microphone 113, touch screen 112, display controller 156, light sensor 164, light sensor controller 158, touch / movement module 130, graphics module 132, text input module 134, contact module 137, and telephone module 138, videoconferencing module 139 includes executable instructions to initiate, conduct, and terminate a videoconference between a user and one or more other participants according to the user's instructions.

[0093] In conjunction with RF circuitry 108, touch screen 112, display controller 156, contact / movement module 130, graphics module 132, and text input module 134, email client module 140 contains executable instructions for creating, sending, receiving, and managing emails in accordance with user instructions. In conjunction with image management module 144, email client module 140 makes it very easy to create and email still or video images taken with camera module 143.

[0094] In conjunction with RF circuitry 108, touchscreen 112, display controller 156, contact / movement module 130, graphics module 132, and text input module 134, instant message module 141 includes executable instructions for entering text corresponding to an instant message, modifying previously entered text, sending the corresponding instant message (e.g., using Short Message Service (SMS) or Multimedia Message Service (MMS) protocols for telephone-based instant messaging, or using XMPP, SIMPLE, or IMPS for Internet-based instant messaging), and receiving and displaying the received instant message. In some embodiments, sent and / or received instant messages may include graphics, photos, audio files, video files, and / or other attachments, such as those supported by MMS and / or Enhanced Messaging Service (EMS). As used herein, "instant messaging" refers to both telephone-based messaging (e.g., messages sent using SMS or MMS) and Internet-based messaging (e.g., messages sent using XMPP, SIMPLE, or IMPS).

[0095] In conjunction with the RF circuitry 108, touchscreen 112, display controller 156, contact / movement module 130, graphics module 132, text input module 134, GPS module 135, map module 154, and music player module, the training support module 142 includes executable instructions to generate workouts (e.g., having time, distance, and / or calorie burn goals), communicate with training sensors (sports devices), receive training sensor data, calibrate sensors used to monitor workouts, select and play music for workouts, and display, store, and transmit workout data.

[0096] Camera module 143, in conjunction with touch screen 112, display controller 156, light sensor(s) 164, light sensor controller 158, contact / movement module 130, graphics module 132, and image management module 144, contains executable instructions to capture still images or video (including video streams) and store them in memory 102, change characteristics of still images or video, or delete still images or video from memory 102.

[0097] In conjunction with touch screen 112, display controller 156, contact / movement module 130, graphics module 132, text input module 134, and camera module 143, image management module 144 includes executable instructions for arranging, modifying (e.g., editing) and otherwise manipulating, labeling, deleting, presenting (e.g., in a digital slide show or album), and storing still and / or video images.

[0098] In conjunction with RF circuitry 108, touch screen 112, display controller 156, touch / movement module 130, graphics module 132, and text input module 134, browser module 147 contains executable instructions for browsing the Internet according to user instructions, including retrieving, linking to, receiving, and displaying web pages or portions thereof, as well as attachments and other files linked to web pages.

[0099] Calendar module 148, in conjunction with RF circuitry 108, touch screen 112, display controller 156, contact / movement module 130, graphics module 132, text input module 134, email client module 140, and browser module 147, contains executable instructions to create, display, modify, and store calendars and data associated with calendars (e.g., calendar entries, to-do lists, etc.) in accordance with user instructions.

[0100] In conjunction with RF circuitry 108, touchscreen 112, display controller 156, touch / movement module 130, graphics module 132, text input module 134, and browser module 147, widget module 149 is a mini-application that can be downloaded and used by a user (e.g., weather widget 149-1, stock quotes widget 149-2, calculator widget 149-3, alarm clock widget 149-4, and dictionary widget 149-5), or created by a user (e.g., user-created widget 149-6). In some embodiments, a widget includes an HTML (HyperText Markup Language) file, a CSS (Cascading Style Sheets) file, and a JavaScript file. In some embodiments, a widget includes an XML (Extensible Markup Language) file and a JavaScript file (e.g., Yahoo! Widget).

[0101] In conjunction with RF circuitry 108, touch screen 112, display controller 156, touch / movement module 130, graphics module 132, text input module 134, and browser module 147, widget creation module 150 may be used by a user to create widgets (e.g., turn user-specified portions of a web page into widgets).

[0102] In conjunction with touch screen 112, display controller 156, contact / movement module 130, graphics module 132, and text input module 134, search module 151 contains executable instructions to search memory 102 for text, music, sound, images, video, and / or other files that match one or more search criteria (e.g., one or more user-specified search terms) in accordance with user instructions.

[0103] Video and music player module 152, in conjunction with touchscreen 112, display controller 156, touch / movement module 130, graphics module 132, audio circuitry 110, speaker 111, RF circuitry 108, and browser module 147, includes executable instructions that enable a user to download and play pre-recorded music or other sound files stored in one or more file formats, such as MP3 or AAC files, as well as executable instructions to display, present, or otherwise play videos (e.g., on touchscreen 112 or on an external display connected via external port 124). In some embodiments, device 100 optionally includes the functionality of an MP3 player, such as an iPod (a registered trademark of Apple Inc.).

[0104] In conjunction with touch screen 112, display controller 156, contact / movement module 130, graphics module 132, and text input module 134, notes module 153 contains executable instructions for creating and managing notes, to-do lists, and the like, in accordance with user instructions.

[0105] In conjunction with RF circuitry 108, touch screen 112, display controller 156, touch / movement module 130, graphics module 132, text input module 134, GPS module 135, and browser module 147, map module 154 can be used to receive, display, modify, and store maps and data associated with maps (e.g., driving directions, data about stores and other points of interest at or near a particular location, and other location-based data) in accordance with user instructions.

[0106] Online video module 155, in conjunction with touchscreen 112, display controller 156, contact / movement module 130, graphics module 132, audio circuitry 110, speaker 111, RF circuitry 108, text input module 134, email client module 140, and browser module 147, contains instructions that enable a user to access, browse, receive (e.g., by streaming and / or downloading), and play (e.g., on the touchscreen or on an external display connected via external port 124) online videos in one or more file formats, such as H.264, and send and otherwise manage emails containing links to particular online videos. In some embodiments, instant messaging module 141, rather than email client module 140, is used to send links to particular online videos. Additional description of online video applications can be found in U.S. Provisional Patent Application No. 60 / 936,562, filed June 20, 2007, entitled "Portable Multifunction Device, Method, and Graphical User Interface for Playing Online Videos," and U.S. Patent Application No. 11 / 968,067, filed December 31, 2007, entitled "Portable Multifunction Device, Method, and Graphical User Interface for Playing Online Videos," the contents of which are incorporated herein by reference in their entireties.

[0107] Each of the above-identified modules and applications corresponds to a set of executable instructions and methods described herein (e.g., computer-implemented methods and other information processing methods described herein) that perform one or more of the above functions. These modules (e.g., sets of instructions) need not be implemented as separate software programs, procedures, or modules; thus, various embodiments may combine or otherwise rearrange various subsets of these modules. For example, a video player module may be combined with a music player module into a single module (e.g., video and music player module 152, FIG. 1A ). In some embodiments, memory 102 may store a subset of the above-identified modules and data structures. Additionally, memory 102 may store additional modules and data structures not described above.

[0108] In some embodiments, device 100 is a device in which operation of a predetermined set of functions on the device is performed exclusively via a touchscreen and / or touchpad. By using the touchscreen and / or touchpad as the primary input control device for operation of device 100, the number of physical input control devices (such as pushbuttons, dials, and the like) on device 100 can be reduced.

[0109] The predetermined set of functions performed exclusively via the touchscreen and / or touchpad optionally includes navigation between user interfaces. In some embodiments, the touchpad, when touched by a user, navigates device 100 to a main menu, home menu, or root menu from any user interface displayed on device 100. In such embodiments, a "menu button" is implemented using the touchpad. In some other embodiments, the menu button is a physical push button or other physical input control device rather than a touchpad.

[0110] 1B is a block diagram illustrating exemplary components for event processing, according to some embodiments. In some embodiments, memory 102 (FIG. 1A) or 370 (FIG. 3) includes event sorter 170 (e.g., in operating system 126) and corresponding application 136-1 (e.g., any of applications 137-151, 155, and 380-390 described above).

[0111] Event sorter 170 receives the event information and determines application 136-1 and application view 191 for application 136-1 to distribute the event information to. Event sorter 170 includes event monitor 171 and event dispatcher module 174. In some embodiments, application 136-1 includes application internal state 192 that indicates the current application view(s) that are displayed on touch-sensitive display 112 when the application is active or running. In some embodiments, device / global internal state 157 is used by event sorter 170 to determine which application(s) are currently active, and application internal state 192 is used by event sorter 170 to determine which application(s) are currently active, and application internal state 192 is used by event sorter 170 to determine application view 191 to deliver the event information to.

[0112] In some embodiments, application internal state 192 includes additional information such as one or more of resume information used when application 136-1 resumes execution, user interface state information indicating information being displayed or ready to be displayed by application 136-1, a state queue to allow the user to return to a previous state or view of application 136-1, and a redo / undo queue of actions previously performed by the user.

[0113] Event monitor 171 receives event information from peripherals interface 118. The event information includes information about sub-events (e.g., a user's touch on touch-sensitive display 112 as part of a multi-touch gesture). Peripherals interface 118 transmits information it receives from I / O subsystem 106 or sensors such as proximity sensor 166, accelerometer(s) 168, and / or microphone 113 (via audio circuitry 110). Information that peripherals interface 118 receives from I / O subsystem 106 includes information from touch-sensitive display 112 or a touch-sensitive surface.

[0114] In some embodiments, event monitor 171 sends requests to peripherals interface 118 at predetermined intervals. In response, peripherals interface 118 transmits event information. In other embodiments, peripherals interface 118 transmits event information only when there is a significant event (e.g., exceeding a predetermined noise threshold and / or receiving an input for more than a predetermined time).

[0115] In some embodiments, event sorter 170 also includes a hit view determination module 172 and / or an active event recognizer determination module 173 .

[0116] Hit view determination module 172 provides software procedures for determining where a sub-event occurred within one or more views when touch-sensitive display 112 displays one or more views. A view consists of controls and other elements that a user can see on the display.

[0117] Another aspect of a user interface associated with an application is the set of views, sometimes referred to herein as application views or user interface windows, in which information is displayed and touch-based gestures are performed. The application view (of the corresponding application) in which a touch is detected may correspond to a programmatic level within the application's programmatic or view hierarchy. For example, the lowest-level view in which a touch is detected may be referred to as a hit view, and the set of events that are recognized as appropriate input may be determined, at least in part, based on the hit view of the initial touch that initiates a touch-based gesture.

[0118] Hit view determination module 172 receives information associated with sub-events of a touch-based gesture. If an application has multiple views organized as a hierarchy, hit view determination module 172 identifies the hit view as the lowest view in the hierarchy that should process the sub-events. In most situations, the hit view is the lowest-level view in which the first sub-event occurs (i.e., the first sub-event in the sequence of sub-events that form the event or potential event). Once a hit view is identified by hit view determination module 172, the hit view typically receives all sub-events related to the same touch or input source for which it was identified as the hit view.

[0119] Active event recognizer determination module 173 determines which view(s) in the view hierarchy should receive the particular sequence of sub-events. In some embodiments, active event recognizer determination module 173 determines that only the hit view should receive the particular sequence of sub-events. In other embodiments, active event recognizer determination module 173 determines that all views that contain the physical location of the sub-events are actively participating views, and therefore determines that all actively participating views should receive the particular sequence of sub-events. In other embodiments, even if the touch sub-event is completely confined to the region associated with a particular view, views higher in the hierarchy remain actively participating views.

[0120] Event dispatcher module 174 sends the event information to an event recognizer (e.g., event recognizer 180). In embodiments that include active event recognizer determination module 173, event dispatcher module 174 distributes the event information to the event recognizers determined by active event recognizer determination module 173. In some embodiments, event dispatcher module 174 stores event information retrieved by corresponding event receivers 182 in an event queue.

[0121] In some embodiments, operating system 126 includes event sorter 170. Alternatively, application 136-1 includes event sorter 170. In still other embodiments, event sorter 170 is a stand-alone module or part of another module stored in memory 102, such as contact / movement module 130.

[0122] In some embodiments, application 136-1 includes multiple event handlers 190 and one or more application views 191, each containing instructions for handling touch events that occur within a corresponding view of the application's user interface. Each application view 191 of application 136-1 includes one or more event recognizers 180. Typically, each application view 191 includes multiple event recognizers 180. In other embodiments, one or more of event recognizers 180 are part of a separate module, such as a User Interface Kit (not shown) or a higher-level object from which application 136-1 inherits methods and other properties. In some embodiments, each event handler 190 includes one or more of data updater 176, object updater 177, GUI updater 178, and / or event data 179 received from event sorter 170. Event handler 190 may utilize or call data updater 176, object updater 177, or GUI updater 178 to update application internal state 192. Alternatively, one or more of the application views 191 includes one or more respective event handlers 190. Also, in some embodiments, one or more of a data updater 176, an object updater 177, and a GUI updater 178 are included within each application view 191.

[0123] Each event recognizer 180 receives event information (e.g., event data 179) from event sorter 170 and identifies an event from the event information. Event recognizer 180 includes event receiver 182 and event comparator 184. In some embodiments, event recognizer 180 further includes at least a subset of metadata 183 and event delivery instructions 188 (which may include sub-event delivery instructions).

[0124] Event receiver 182 receives event information from event sorter 170. The event information includes information about a sub-event, such as a touch or a movement of a touch. Depending on the sub-event, the event information also includes additional information, such as the position of the sub-event. If the sub-event involves a movement of a touch, the event information may further include the speed and direction of the sub-event. In some embodiments, the event includes a rotation of the device from one orientation to another (e.g., from portrait to landscape orientation, or vice versa), and the event information includes corresponding information about the device's current orientation (also called the device's attitude).

[0125] The event comparator 184 compares the event information with predefined event or sub-event definitions and determines the event or sub-event, or determines or updates the state of the event or sub-event, based on the comparison. In some embodiments, the event comparator 184 includes an event definition 186. The event definition 186 includes a definition of an event (e.g., a predefined sequence of sub-events), such as, for example, Event 1 (187-1), Event 2 (187-2), etc. In some embodiments, sub-events within an event (187) include, for example, touch start, touch end, touch movement, touch cessation, and multiple touches. In one example, the definition of Event 1 (187-1) is a double tap on a displayed object. The double tap comprises, for example, a first touch (touch start) for a predefined stage on the displayed object, a first lift-off (touch end) for a predefined stage, a second touch (touch start) for a predefined stage on the displayed object, and a second lift-off (touch end) for a predefined stage. In another example, the definition of Event 2 (187-2) is a drag operation on the displayed object. Drag operations include, for example, a touch (or contact) to a predetermined stage on a displayed object, a movement of the touch across the touch-sensitive display 112, and a lift-off of the touch (touch end). In some embodiments, the event also includes information for one or more associated event handlers 190.

[0126] In some embodiments, event definitions 187 include definitions of the event for each user interface object. In some embodiments, event comparator 184 performs a hit test to determine the user interface object associated with the sub-event. For example, in an application view in which three user interface objects are displayed on touch-sensitive display 112, if a touch is detected on touch-sensitive display 112, event comparator 184 performs a hit test to determine which of the three user interface objects is associated with the touch (the sub-event). If each displayed object is associated with a respective event handler 190, event comparator 184 uses the results of the hit test to determine which event handler 190 needs to be activated. For example, event comparator 184 selects the event handler associated with the sub-event and the object that triggered the hit test.

[0127] In some embodiments, the definition for each event (187) also includes a delay action that delays sending the event information until it is determined whether the sequence of sub-events corresponds to the event type of the event recognizer.

[0128] If the respective event recognizer 180 determines that the sequence of sub-events does not match any of the events in the event definition 186, the respective event recognizer 180 enters an event-disabled, event-failed, or event-ended state, and thereafter ignores subsequent sub-events of the touch-based gesture. In this situation, other event recognizers, if any, that remain active for the hit view continue to track and process sub-events of the ongoing touch-based gesture.

[0129] In some embodiments, each event recognizer 180 includes metadata 183 with configurable properties, flags, and / or lists that indicate how the event delivery system performs sub-event delivery to actively participating event recognizers. In some embodiments, metadata 183 includes configurable properties, flags, and / or lists that indicate how event recognizers may or are enabled to interact with each other. In some embodiments, metadata 183 includes configurable properties, flags, and / or lists that indicate whether sub-events are distributed to various levels in the view or programmatic hierarchy.

[0130] In some embodiments, each event recognizer 180 activates an event handler 190 associated with an event when one or more specific sub-events of the event are recognized. In some embodiments, each event recognizer 180 distributes event information associated with the event to the event handler 190. Activating an event handler 190 and sending (and deferring sending) sub-events to the respective hit view are distinct from each other. In some embodiments, the event recognizer 180 throws a flag associated with the recognized event, and the event handler 190 associated with the flag catches the flag and performs predetermined processing.

[0131] In some embodiments, event delivery instructions 188 include sub-event delivery instructions that deliver event information about a sub-event without activating an event handler. Instead, the sub-event delivery instructions distribute the event information to event handlers associated with a set of sub-events or actively participating views. The event handlers associated with the set of sub-events or actively participating views receive the event information and perform predetermined processing.

[0132] In some embodiments, data updater 176 creates and updates data used by application 136-1. For example, data updater 176 updates phone numbers used in contacts module 137 or stores video files used in a video player module. In some embodiments, object updater 177 creates and updates objects used by application 136-1. For example, object updater 177 creates new user interface objects or updates the positions of user interface objects. GUI updater 178 updates the GUI. For example, GUI updater 178 prepares display information and sends it to graphics module 132 for display on the touch-sensitive display.

[0133] In some embodiments, event handler(s) 190 include or have access to data updater 176, object updater 177, and GUI updater 178. In some embodiments, data updater 176, object updater 177, and GUI updater 178 are included in one module of the respective application 136-1 or application view 191. In other embodiments, they are included in two or more software modules.

[0134] It will be understood that the foregoing description of event processing of a user's touch on a touch-sensitive display also applies to other forms of user input for operating multifunction device 100 using input devices, although not all of them are initiated on the touchscreen. For example, mouse movements and mouse button presses, optionally coupled with one or more keyboard presses or holds, touch movements such as tapping, dragging, scrolling, etc. on a touchpad, pen stylus input, device movement, verbal commands, detected eye movement, biometric input, and / or any combination thereof, are optionally utilized as inputs corresponding to sub-events that define the event to be recognized.

[0135] FIG. 2 illustrates portable multifunction device 100 having touchscreen 112, according to some embodiments. The touchscreen optionally displays one or more graphics within user interface (UI) 200. In this embodiment, as well as embodiments described below, a user can select one or more of the graphics by making a gesture on the graphics, for example, with one or more fingers 202 (not drawn to scale) or one or more styluses 203 (not drawn to scale). In some embodiments, selection of one or more graphics occurs when the user breaks contact with one or more graphics. In some embodiments, the gesture optionally includes one or more taps, one or more swipes (left to right, right to left, upward, and / or downward), and / or rolling of a finger in contact with device 100 (right to left, left to right, upward, and / or downward). In some implementations or situations, accidental contact with a graphic does not result in selection of the graphic. For example, if the gesture corresponding to selection is a tap, a swipe gesture sweeping over an application icon optionally does not select the corresponding application.

[0136] Device 100 may also include one or more physical buttons, such as a "home" or menu button 204. As mentioned above, menu button 204 can be used to navigate to any application 136 within a set of applications that may be running on device 100. Alternatively, in some embodiments, the menu button is implemented as a soft key in a GUI displayed on touch screen 112.

[0137] In some embodiments, device 100 includes touchscreen 112, menu button 204, pushbutton 206 for turning power to the device on / off and locking the device, volume control button(s) 208, Subscriber Identity Module (SIM) card slot 210, headset jack 212, and external docking / charging port 124. Pushbutton 206 is optionally used to turn power on / off on the device by pressing the button and holding it down for a predetermined period of time, and to lock the device and / or unlock the device or start an unlocking process by pressing the button and releasing it before the predetermined period of time has elapsed. In an alternative embodiment, device 100 also accepts verbal input through microphone 113 to activate or deactivate some functions. Device 100 also optionally includes one or more contact intensity sensors 165 for detecting the intensity of a contact on touchscreen 112 and / or one or more tactile output generators 167 for generating a tactile output for a user of device 100.

[0138] FIG. 3 is a block diagram of an exemplary multifunction device with a display and a touch-sensitive surface, according to some embodiments. Device 300 need not be portable. In some embodiments, device 300 is a laptop computer, a desktop computer, a tablet computer, a multimedia player device, a navigation device, an educational device (such as a child's learning toy), a gaming system, or a control device (e.g., a home or commercial controller). Device 300 typically includes one or more processing units (CPUs) 310, one or more network or other communication interfaces 360, memory 370, and one or more communication buses 320 for interconnecting these components. Communication bus 320 optionally includes circuitry (sometimes referred to as a chipset) that interconnects and controls communication between system components. Device 300 includes an input / output (I / O) interface 330 with a display 340, which is typically a touchscreen display. I / O interface 330 also optionally includes a keyboard and / or mouse (or other pointing device) 350, as well as a touchpad 355, a tactile output generator 357 (e.g., similar to tactile output generator(s) 167 described above with reference to FIG. 1A ) for generating tactile output on device 300, sensors 359 (e.g., optical sensors, acceleration sensors, proximity sensors, touch-sensitive sensors, and / or contact intensity sensors similar to contact intensity sensor(s) 165 described above with reference to FIG. 1A ). Memory 370 includes high-speed random-access memory such as DRAM, SRAM, DDR RAM, or other random-access solid-state memory devices, and optionally includes non-volatile memory such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile semiconductor storage devices. Memory 370 optionally includes one or more storage devices located remotely from CPU(s) 310.In some embodiments, memory 370 stores programs, modules, and data structures similar to, or a subset of, the programs, modules, and data structures stored in memory 102 of portable multifunction device 100 (FIG. 1A). Additionally, memory 370 optionally stores additional programs, modules, and data structures not present in memory 102 of portable multifunction device 100. For example, memory 370 of device 300 optionally stores drawing module 380, presentation module 382, ​​word processing module 384, website creation module 386, disk authoring module 388, and / or spreadsheet module 390, while memory 102 of portable multifunction device 100 (FIG. 1A) optionally does not store these modules.

[0139] Each of the above-identified elements of FIG. 3 may be stored in one or more of the memory devices mentioned above. Each of the above-identified modules corresponds to an instruction set that performs the functions described above. The above-identified modules or programs (i.e., instruction sets) need not be implemented as separate software programs, procedures, or modules; thus, various subsets of these modules may be combined or otherwise reconfigured in various embodiments. In some embodiments, memory 370 may store a subset of the above-identified modules and data structures. Additionally, memory 370 may store additional modules and data structures not described above.

[0140] Attention is now directed to embodiments of user interfaces that may be implemented on portable multifunction device 100.

[0141] 4A shows an exemplary user interface for an applications menu on portable multifunction device 100, according to some embodiments. A similar user interface may be implemented on device 300. In some embodiments, user interface 400 includes the following elements, or a subset or superset thereof: signal strength indicator(s) 402 for wireless communications such as cellular and Wi-Fi signals; ●Time 404, ●Bluetooth indicator 405, ● Battery status indicator 406, A tray 408 containing icons for frequently used applications, such as: an icon 416 for the phone module 138, labeled "Phone," optionally including an indicator 414 of the number of missed calls or voicemail messages; an icon 418 for the email client module 140, labeled "Mail," optionally including an indicator 410 of the number of unread emails; ○ An icon 420 for the browser module 147, labeled "Browser"; and ○ An icon 422 labeled "iPod" for the video and music player module 152, also referred to as the iPod (trademark of Apple Inc.) module 152; and ●Icons for other applications, such as: ○ Icon 424 for IM module 141, labeled "Messages"; ○ Icon 426 for the calendar module 148, labeled "Calendar" ○ Icon 428 for the image management module 144, labeled "Photos" ○ An icon 430 for the camera module 143, labeled "camera"; ○ Icon 432 for the online video module 155, labeled "Online Video" Icon 434 for stock price widget 149-2, labeled "Stock Prices" ○ Icon 436 for map module 154, labeled "Map" Icon 438 for weather widget 149-1, labeled "Weather" ○ Icon 440 for alarm clock widget 149-4, labeled "Clock" ○ Icon 442 for Training Support Module 142, labeled "Training Support"; ○ Icon 444 for the Notes module 153, labeled "Notes" o An icon 446 labeled "Settings" for a settings application or module that provides access to settings for the device 100 and its various applications 136.

[0142] 4A are merely exemplary. For example, icon 422 for video and music player module 152 may optionally be labeled "Music" or "Music Player." Other labels are optionally used for various application icons. In some embodiments, the label for each application icon includes the name of the application corresponding to the respective application icon. In some embodiments, the label for a particular application icon is different from the name of the application corresponding to the particular application icon.

[0143] 4B shows an exemplary user interface on a device (e.g., device 300 of FIG. 3) that includes a touch-sensitive surface 451 (e.g., a tablet or touchpad 355 of FIG. 3) that is separate from display 450 (e.g., touchscreen display 112). Device 300 also optionally includes one or more contact intensity sensors (e.g., one or more of sensors 357) for detecting the intensity of a contact on touch-sensitive surface 451 and / or one or more tactile output generators 359 for generating a tactile output for a user of device 300.

[0144] Although some of the following examples are described with reference to input on touchscreen display 112 (when the touch-sensitive surface and display are combined), in some embodiments, the device detects input on a touch-sensitive surface that is separate from the display, as shown in FIG. 4B . In some embodiments, this touch-sensitive surface (e.g., 451 in FIG. 4B ) has a major axis (e.g., 452 in FIG. 4B ) that corresponds to a major axis (e.g., 453 in FIG. 4B ) on the display (e.g., 450). According to these embodiments, the device detects contact with touch-sensitive surface 451 (e.g., 460 and 462 in FIG. 4B ) at locations that correspond to respective locations on the display (e.g., 460 corresponds to 468 and 462 corresponds to 470 in FIG. 4B ). In this manner, when the touch-sensitive surface is separate from the display, user input (e.g., contacts 460 and 462 and their movement) detected by the device on the touch-sensitive surface (e.g., 451 in FIG. 4B ) is used by the device to operate a user interface on the display (e.g., 450 in FIG. 4B ) of the multifunction device. It should be understood that similar methods are optionally used for the other user interfaces described herein.

[0145] Furthermore, while the following examples are described primarily with reference to finger input (e.g., finger touches, finger tap gestures, finger swipe gestures), it should be understood that in some embodiments, one or more of those finger inputs are replaced with input from another input device (e.g., mouse-based input or stylus input). For example, a swipe gesture is optionally replaced with a mouse click (e.g., instead of a touch), followed by cursor movement along the path of the swipe (e.g., instead of moving the contact). As another example, a tap gesture is optionally replaced with a mouse click (e.g., instead of detecting a contact followed by ceasing contact detection) when the cursor is positioned over the location of the tap gesture. Similarly, it will be understood that when multiple user inputs are detected simultaneously, multiple computer mice are optionally used simultaneously, or a mouse and finger contacts are optionally used simultaneously.

[0146] As used herein, the term "affordance" refers to a user-interactive graphical user interface object that may be displayed on the display screen of device 100, 300, and / or 500 (FIGS. 1, 3, and 5). For example, an image (e.g., an icon), a button, and text (e.g., a hyperlink) may each constitute an affordance.

[0147] Attention is now directed to embodiments of user interfaces (“UIs”) and associated methods that may be implemented on a multifunction device with a display, such as device 300 or portable multifunction device 100 .

[0148] 5A-5I illustrate exemplary user interfaces for linking a payment account to a corresponding device, according to some embodiments. The user interfaces in these figures are used to illustrate the methods described below, including the methods of FIGS. 6A-6C.

[0149] 5A-5E show exemplary user interfaces for receiving a request to link a payment account, such as a bank account or revolving credit account, associated with a credit card (e.g., a physical credit card or debit card issued to a user) to a corresponding device (e.g., a mobile phone, laptop, wearable electronic device), according to some embodiments. For example, the request can be to import credit card details from a remote server or account (such as iTunes® or an account associated with iTunes) or to manually enter card details. The request includes information about the credit card (e.g., the credit card primary account number (PAN) or security code).

[0150] For example, FIG. 5A illustrates an electronic wallet. The electronic wallet includes a first stack of card objects 502 and a second stack of card objects 508, 510, and 512. The first stack of card objects 502 is visually separated from the second stack of card objects 508, 510, and 512. In this example, a credit card (e.g., an American Express® credit card) is already linked to the device and is displayed as part of the first stack of card objects 502. In FIG. 5B, user input is received that causes the device to display an add card affordance 520 related to a request to link a payment account (e.g., a revolving credit account held with a financial institution) to the corresponding device. For example, a downward swipe on the display of device 100 is used to display add card affordance 520. The device receives a selection of add card affordance 520 (e.g., activated by a finger tap) and displays the user interface of FIG. 5C.

[0151] Figure 5C illustrates a user interface for selecting between an add payment card affordance 530 for linking a payment account to the device (e.g., making the payment account available in the electronic wallet) and a scan code affordance 532 for linking a pass. If the device determines that it has received a selection of the exit affordance 534, it returns to the electronic wallet display of Figure 5A. If the device determines that it has received a selection of the add payment card affordance 530, it transitions to the display of Figure 5D.

[0152] 5D , the device displays a generic image of a debit or credit card 536 to indicate to the user that they are requesting linking of a payment account to the corresponding device. In one exemplary embodiment, the device displays a credit card import affordance 538 on the display for importing at least partial credit card information (e.g., information for a credit card authorized for use by the current user's account) from a remote server (e.g., an account associated with iTunes or iTunes). The device receives a user selection of the credit card import affordance 538 (e.g., a finger tap on the credit card import affordance 538). Alternatively, the user may manually enter credit card information (e.g., card number, card expiration date, name on the card) by selecting manual input affordance 540 or manually enter credit card information (e.g., card number, card expiration date, name on the card) using the device's camera by selecting camera input affordance 542.

[0153] In response to receiving a user selection of the credit card import affordance 538 to import credit card information (e.g., card number, card expiration date, name on the card) from a remote server, the device displays a credit card details screen, as shown in Figure 5E. The credit card details screen includes an indication 554 of the credit card number (e.g., a truncated credit card primary account number (PAN) displaying the last four digits of the credit card) of the credit card associated with the payment account and includes a security code input field 550 for receiving a security code (e.g., a numeric card security code such as CVD, CVV, CVC, etc.).

[0154] The device receives a corresponding security code via user input (e.g., user input on a displayed keypad 552 or by capturing an image of the credit card) in security code entry field 550. The device determines the validity of the credit card using verification based on the credit card number and the corresponding security code. In some embodiments, after determining that the credit card is valid, the payment account associated with the credit card is linked to the corresponding device.

[0155] In some embodiments, the user requests to manually enter the credit card information (e.g., card number, card expiration date, name on the card) rather than importing it. In FIG. 5D , the user may manually enter the credit card information by selecting manual input affordance 540 or by selecting camera input affordance 542. In response to receiving a user selection of the credit card input affordance for entering the credit card information, the device displays a credit card details screen for manual entry. The credit card details screen for manual entry includes an account input field for receiving a credit card number associated with the payment account (e.g., a credit card primary account number) and a security code input field for receiving a security code (e.g., a numeric card security code such as a CVD, CVV, or CVC). The device receives the corresponding credit card number in the account input field and the corresponding security code in the security code input field via user input (e.g., by user entry on a displayed keypad 552 or by capturing an image of the credit card). The device determines the validity of the credit card using verification based on the corresponding credit card number and the corresponding security code. In some embodiments, after determining that the credit card is valid, the payment account associated with the credit card is linked to the corresponding device.

[0156] Similarly, selection of camera input affordance 542 in FIG. 5D may request that the user input information by using the camera to capture one or more images of the credit card (e.g., the user uses the device to take a picture of the front and / or back of the credit card). The device determines the credit card number and corresponding security code CCV based on the one or more images of the credit card to determine that the credit card is valid. In some embodiments, after determining that the credit card is valid, the payment account associated with the credit card is linked to the corresponding device.

[0157] In response to receiving a request (e.g., a user importing credit card information), the device determines whether further verification is required to link the payment account to the corresponding device (e.g., whether the payment account has already been approved by the bank to be linked to the device, or whether the bank needs to first confirm with the payment account owner). Following a determination that further verification is not required to link the payment account to the corresponding device, the device links the payment account to the corresponding device and provides an indication (e.g., 558 in FIG. 5H) that the payment account has been linked to the corresponding device. Once the payment account is linked to the corresponding device, the corresponding device can be used to facilitate payment transactions (e.g., purchases at a physical store or over the Internet using the corresponding device).

[0158] FIG. 5G illustrates an exemplary user interface including an indication 556 that further verification is required. Following a determination that further verification is required to link the payment account to the corresponding device, the device provides an indication that further verification is required to link the payment account to the corresponding device (e.g., by displaying on a display that approval to link the payment account is pending or by requesting that the user call a verification phone number). In some embodiments, the indication that further verification is required to link the payment account to the corresponding device includes an alphanumeric visual indicator displayed on a display of the electronic device (e.g., an alphanumeric indicator including "Waiting for Approval" indicating that a further verification step has been initiated without further user input). An example visual indication is shown as visual indication 556 "Waiting for Approval" in FIG. 5G. For example, a financial institution (e.g., a bank) associated with the payment account may need to verify the payment account details before the payment account is linked to the corresponding device. The verification may not require further user interaction with the financial institution.

[0159] 5F illustrates an exemplary user interface showing an indication that further verification is required to link a payment account to a corresponding device. In some embodiments, the indication that further verification is required to link a payment account to a corresponding device includes a visual indication of additional steps to take to link the payment account to the corresponding device (e.g., instructions to the user to contact a financial institution associated with the payment account to verify the payment account details before the payment account is linked to the corresponding device).

[0160] In FIG. 5F , the device displays multiple communication method affordances 560 and 562. In some embodiments, pursuant to a determination that further verification is required to link a payment account to a corresponding device, the device displays multiple communication method affordances 560 and 562 on the display. Each communication method affordance is associated with a corresponding communication method (e.g., a phone number for the bank to call, a phone number for the user to call, an email address for the bank to email, or a phone number for the bank to text) for a verification communication (e.g., a call from the bank to the user or a call from the user to the bank, an email providing an identity key, a code or link to a website for entering verification information, or a text message containing verification information). For example, the device may display communication method affordance 560 indicating a phone number for the financial institution to call to further verify the payment account link. In another example, the device may display communication method affordance 562 indicating an email address for the financial institution to email to further verify the payment account link. The multiple communication method affordances 560 and 562 may be based on a communication received from the financial institution. For example, a financial institution may offer a communication method for security purposes rather than using the communication method from the device or entered into the device by the user. Communication method affordances 560 and 562 that indicate a communication method display only part of the communication method contact information (such as the last four digits of a phone number or the domain of an email address). This provides additional security in case a user attempts to link a payment account that does not belong to the user.

[0161] In some embodiments, following a determination that further verification is required to link the payment account to the corresponding device, the device displays multiple communication method affordances 560 and 562 on the display, where each communication method affordance is associated with a corresponding communication method for verification communications (e.g., a phone number for the bank to call, a phone number for the user to call, an email address for the bank to email, a phone number for the bank to text). The display of the multiple communication method affordances 560 and 562 is based on locally stored contact information. For example, the locally stored contact information includes the corresponding communication methods. This allows the user to select a communication method for verification that the financial institution may not know (e.g., the user acquires a new electronic device with a newly assigned phone number and prefers to use the newly assigned phone number for verification communications). The locally stored contact information may be a contact information card associated with the user of the electronic device (e.g., an entry in the device's phone book identified as containing the user's contact information).

[0162] In some embodiments, following a determination that further verification is required to link a payment account to a corresponding device, the device receives a selection of one of a plurality of communication method affordances 560 and 562. In response to receiving the selection of the communication method affordance, the device sends an indication of the communication method corresponding to the selected communication method affordance to the financial institution (e.g., telling the financial institution that the user prefers to be contacted on their desk phone and that the financial institution can contact the user at the selected phone number). A verification communication (e.g., a call from or to the bank to the user, an email providing an identification key or a code or link to a website for entering authorization information, or a text message containing verification information) is based on the communication method affordance. This verification communication thus enables the financial institution to efficiently contact the user to provide specific information or verification for linking the payment account.

[0163] In some embodiments, following a determination that further verification is required to link the payment account to the corresponding device, the device receives a verification communication (e.g., a call, email, or text message) from a financial institution associated with the payment account, the verification communication being for verification (e.g., confirmation of the client's identity) to link the payment account to the corresponding device.

[0164] In some embodiments, following a determination that further verification is required to link the payment account to the corresponding device, the device receives a request from the user to initiate a verification communication with the financial institution (e.g., a call from the bank to the user or from the user to the bank, an email providing a key for identifying information, a code or link to a website for entering the verification information, or a text message containing the verification information). In response to receiving the request to initiate the verification communication, the device initiates a verification communication with the financial institution associated with the payment account. If an application for the financial institution is installed on the device, the device may suggest launching the application to enter identification / authorization information. If the application is downloaded to another device owned by the user, the device may prompt the user to download the application to the device. The verification communication is for verification (e.g., confirmation of the client's identity) to link the payment account to the corresponding device. In some embodiments, the request to initiate the verification communication includes personally identifying information.

[0165] In some embodiments, the device receives a notification on the electronic device (e.g., gets a text message, email message, or push notification sent to the device containing a confirmation code). The notification includes a verification code for linking the payment account to the corresponding device. In response to receiving the notification with the verification code on the electronic device, the device links the payment account to the corresponding device. In some embodiments, the notification is hidden from the user by either deleting the notification or withholding indication of receipt of the notification. For example, receiving a text message on the phone with the verification code and immediately upon receiving the text message, confirming that the user has possession of the phone by sending the verification code by phone to the financial institution, optionally deleting the text message or not displaying the text message notification, but instead removing the "pending approval" indicator to visually indicate that the payment account has been linked to the device.

[0166] In some embodiments, the device displays a confirmation on the display that the payment account has been linked to the corresponding device. This may include displaying a notification (e.g., a pop-up or banner from the electronic wallet application) on the device indicating that the payment account has been linked to the corresponding device (such as the "approved" confirmation 558 illustrated in FIG. 5H). This notification may be displayed while the electronic wallet is being accessed or while a different application (or no application) is being displayed.

[0167] In some embodiments, the device receives user input requesting a secondary verification code (e.g., the user activates an affordance to request verification again) for linking a payment account to the corresponding device. For example, a user may access an electronic wallet and select a "reverify" affordance. In response to receiving the input requesting the secondary verification code, the device sends a request to the financial institution requesting the secondary verification code (e.g., if the first verification code was not received or expired before verification was completed).

[0168] In some embodiments, the device receives a secondary notification (e.g., a text message, email message, or push notification containing a verification code) at the electronic device. The secondary notification includes a secondary verification code for linking the payment account to the corresponding device. In response to receiving the secondary notification including the secondary verification code at the electronic device, the device links the payment account to the corresponding device and displays a confirmation on the device (e.g., "Approved" 558 in FIG. 5H) indicating that the payment account has been linked to the corresponding device.

[0169] In some embodiments, the device receives a primary account number (e.g., a digital PAN, DPAN, 16-digit account number, or other account number that cannot be used to manually complete a transaction solely via a voice call, e.g., instead of completing the payment electronically via the device) from a financial institution for use in authorizing a payment from a payment account using the corresponding device. The received primary account number is different from the account number displayed on a credit card (e.g., a credit card PAN, 16-digit credit card number). In some embodiments, the device assigns the received primary account number (e.g., a digital PAN, DPAN, 16-digit account number, or other account number) to the corresponding device to link the payment account to the corresponding device. This allows, for example, a financial institution to distinguish between payment transactions made using the received primary account number that is assigned to the corresponding device and associated with the payment account and payment transactions made using a credit card that is also associated with the payment account.

[0170] In some embodiments, the credit card details screen of FIG. 5E includes a visually displayed graphical representation 504 of the credit card associated with the payment account. For example, if the user selects to import credit card information, the graphical representation includes a background image of the physical credit card associated with the payment account. By displaying a background image identical to the physical credit card, the user can easily recognize which credit card is being used to link the payment account.

[0171] In some embodiments, the corresponding device is a second electronic device (e.g., a mobile phone, a laptop computer, a wearable electronic device) separate from the electronic device. For example, the electronic device can be used to link a payment account to another mobile phone. This can be done, for example, by sending provisioning information from the electronic device to the corresponding device (e.g., the other device), which provisioning information is used to link the payment account to the corresponding device (e.g., the other device). In some embodiments, a similar method can be repeated (optionally with a different DPAN) to link the payment account to the electronic device. In other embodiments, the corresponding device and the electronic device are the same, and the electronic device is a mobile telecommunications device (e.g., a mobile phone, a laptop computer, a wearable electronic device).

[0172] In some embodiments, the device determines (e.g., before linking a payment account to the corresponding device) whether the corresponding device is configured to require unlock permission (e.g., a passcode) to unlock the corresponding device. Following a determination that the corresponding device is not configured to require unlock permission, the device displays an unlock authentication configurator on its display for configuring the corresponding device to require unlock permission to unlock the corresponding device or to access certain features of the corresponding device. This provides additional security by requiring that the corresponding device, under at least some circumstances, have lock permission to access the device. For example, this authentication configurator can be used to register a fingerprint or passcode that can authorize payment transactions.

[0173] FIG. 5I illustrates an electronic wallet including representations of multiple payment accounts 502 and 504. In some embodiments, the device receives a second request to link a second payment account (e.g., a revolving credit account with a financial institution) associated with a second credit card to a corresponding device. The second request includes information about the second credit card (e.g., selecting a credit card to import and / or enter a card security code). For example, a similar technique as described above can be used to request linking of the second payment account to the corresponding device. The device links the second payment account to the corresponding device and provides an indication that the second payment account has been linked to the corresponding device. The device receives at least a selection from among the first payment account and the second payment account to designate a default payment account to be used for payment transactions.

[0174] 6A-6C are flow diagrams illustrating a method 600 for linking a payment account to a corresponding device, according to some embodiments. Method 600 is performed on a device having a display (e.g., device 300 of FIG. 3 or portable multifunction device 100 of FIG. 1). Some operations of method 600 may be combined, some operations may be reordered, and some operations may be omitted.

[0175] As described below, method 600 provides an intuitive way to link a payment account to a corresponding device. This method reduces the cognitive burden on a user when linking a payment account, thereby creating a more efficient human-machine interface. In the case of battery-operated computing devices, allowing a user to link a payment account to a corresponding device faster and more efficiently conserves power and increases the time between battery charges.

[0176] In block 602, the electronic device receives a request (e.g., a request to import card details from iTunes or to manually enter card details) to link a payment account (e.g., a revolving credit account held with a financial institution) associated with a credit card (e.g., a physical credit card or debit card issued to a user) to a corresponding device (e.g., a mobile phone, a laptop, a wearable electronic device, device 300 of FIG. 3, portable multifunction device 100 of FIG. 1).

[0177] At block 604, in some embodiments, receiving a request to link a payment account includes receiving a request to import credit card information. The device displays a credit card import affordance on a display for importing at least partial credit card information (e.g., information for a credit card authorized for use by the current user's account) from a remote server. The device receives a user selection of the credit card import affordance. In response to receiving a user selection of the credit card import affordance for importing credit card information from the remote server, the device displays a credit card details screen that includes an indication of the credit card number (e.g., a truncated credit card primary account number (PAN) displaying the last four digits of the credit card) of the credit card associated with the payment account and a security code input field for receiving a security code (e.g., a numeric card security code such as a CVD, CVV, or CVC), the device receives the corresponding security code in the security code input field via user input (e.g., user input on a displayed keypad or by capturing an image of the credit card), and the device determines the validity of the credit card using verification based on the credit card number and the corresponding security code. In some embodiments, after determining that the credit card is valid, the payment account associated with the credit card is linked to the corresponding device.

[0178] At block 606, in some embodiments, receiving a request to link a payment account includes receiving a request to manually enter credit card information. The device displays a credit card input affordance on a display for receiving credit card information via user input at the electronic device. The device receives user selection of the credit card input affordance. In response to receiving user selection of the credit card input affordance for entering credit card information, the device displays a credit card details screen, including an account input field for receiving a credit card number (e.g., a credit card primary account number) associated with the payment account and a security code input field for receiving a security code (e.g., a numeric card security code such as a CVD, CVV, or CVC), the device receives the corresponding credit card number in the account input field and the corresponding security code in the security code input field via user input (e.g., by user input on a displayed keypad or by capturing an image of the credit card), and the device determines the validity of the credit card using verification based on the corresponding credit card number and the corresponding security code. In some embodiments, after determining that the credit card is valid, the payment account associated with the credit card is linked to the corresponding device.

[0179] In response to receiving the request to link the payment account at block 608, the device determines whether further verification is required to link the payment account to the corresponding device (e.g., has it already been approved by the bank, or does the bank need to confirm with the user) at block 610. In accordance with a determination that further verification is not required to link the payment account to the corresponding device at block 612, the device links the payment account to the corresponding device and provides an indication that the payment account has been linked to the corresponding device.

[0180] In block 614, in accordance with a determination that further verification is required to link the payment account to the corresponding device, the device provides an indication that further verification is required to link the payment account to the corresponding device (e.g., by displaying on a display that approval to link the payment account is pending).

[0181] In some embodiments, the indication that further verification is required to link the payment account to the corresponding device includes an alphanumeric visual indicator displayed on the display of the electronic device (e.g., an alphanumeric indicator including "Waiting for Approval" (visual indication 556 in FIG. 5G), indicating that a further verification step has begun without further user input). For example, a financial institution associated with the payment account may need to verify the payment account details before the payment account is linked to the corresponding device. The verification may not require further user interaction with the financial institution.

[0182] In some embodiments, the indication that further verification is required to link the payment account to the corresponding device includes a visual indication of additional steps the user must take to link the payment account to the corresponding device (e.g., instructions to the user to contact the financial institution associated with the payment account to verify the payment account details before the payment account is linked to the corresponding device).

[0183] At block 616, in some embodiments, following a determination that further verification is required to link the payment account to the corresponding device, the device displays a plurality of communication method affordances (e.g., 560 and 562 in FIG. 5F ) on the display, each communication method affordance being associated with a corresponding communication method (e.g., a phone number for the bank to call, a phone number for the user to call, an email address for the bank to email, a phone number for the bank to text) for a verification communication (e.g., a call from the bank to the user or a call from the user to the bank, an email providing an identity key, a code or link to a website for entering verification information, or a text message containing verification information).

[0184] In some embodiments, following a determination that further verification is required to link the payment account to the corresponding device, the device displays multiple communication method affordances (560 and 562 in FIG. 5F ) on the display, where each communication method affordance is associated with a corresponding communication method for verification communications (e.g., a phone number for the bank to call, a phone number for the user to call, an email address for the bank to email, and a phone number for the bank to text). The display of the multiple communication method affordances is based on locally stored contact information. For example, the locally stored contact information includes each communication method. This allows the user to select a communication method for verification that the financial institution does not know (e.g., the user obtains a new electronic device with a newly assigned phone number and prefers to use the newly assigned phone number for verification communications). The locally stored contact information may be a contact information card associated with the user of the electronic device (e.g., an entry in the device's phone book identified as containing the user's contact information).

[0185] At block 618, in some embodiments, in accordance with a determination that further verification is required to link the payment account to the corresponding device, the device receives a selection of one of a plurality of communication method affordances (e.g., 560 and 562 in FIG. 5F ). ​​In response to receiving the selection of the communication method affordance, the device sends an indication of the communication method corresponding to the selected communication method affordance to the financial institution (e.g., informing the financial institution that the user prefers to be contacted on their desk phone and that the financial institution can contact the user at the selected phone number). A verification communication (e.g., a call from the bank to the user or from the user to the bank, an email providing an identification key, a code or link to a website for entering verification information, or a text message containing information for verification) is based on the communication method affordance. This verification communication thus enables the financial institution to efficiently contact the user to provide the identification or verification to link the payment account.

[0186] In some embodiments, in accordance with a determination that further verification is required to link the payment account to the corresponding device, the device receives a verification communication (e.g., a call, email, or text message) from a financial institution associated with the payment account at block 620. The verification communication is for verification (e.g., confirmation of the client's identity) to link the payment account to the corresponding device.

[0187] At block 622, in some embodiments, in accordance with a determination that further verification is required to link the payment account to the corresponding device, the device receives a request from the user to initiate a verification communication with a financial institution (e.g., a call from the bank to the user or from the user to the bank, an email providing an identification key, a code or link to a website for entering verification information, or a text message containing information for verification). In response to receiving the request to initiate the verification communication, the device initiates a verification communication with the financial institution associated with the payment account. The verification communication is for verification (e.g., confirmation of the client's identity) to link the payment account to the corresponding device. In some embodiments, the request to initiate the verification communication includes personally identifying information.

[0188] At block 624, in some embodiments, the device receives a notification at the electronic device (e.g., receives a text message, email message, or push notification sent to the device containing a confirmation code). The notification includes a verification code for linking the payment account to the corresponding device. In response to receiving the notification including the verification code at the electronic device, the device links the payment account to the corresponding device. In some embodiments, the notification is hidden from the user by either deleting the notification or by forgoing indication of receipt of the notification. For example, by receiving a text message on the phone with the verification code and immediately transmitting the verification code by phone to the financial institution upon receiving the text message, the user verifies that they own the phone, and optionally deletes the text message or does not display the text message notification, but instead removes the “waiting approval” indicator, visually indicating that the payment account has been linked to the device.

[0189] In block 626, in some embodiments, the device displays a confirmation on the display (e.g., 558 in FIG. 5H) indicating that the payment account has been linked to the corresponding device. This display may include displaying a notification on the device (e.g., a pop-up or banner from the electronic wallet application) indicating that the payment account has been linked to the corresponding device. This notification may be displayed while the electronic wallet is being accessed or while a different application (or no application) is being displayed.

[0190] In some embodiments, the device receives user input requesting a secondary verification code (e.g., the user activates an affordance to request verification again) for linking a payment account to the corresponding device. For example, a user may access an electronic wallet and select a "reverify" affordance. In response to receiving the input requesting the secondary verification code, the device sends a request to the financial institution requesting the secondary verification code (e.g., if the first verification code was not received or expired before verification was completed).

[0191] In some embodiments, the device receives a secondary notification (e.g., a text message, email message, or push notification containing a verification code) at the electronic device. The secondary notification includes a secondary verification code for linking the payment account to the corresponding device. In response to receiving the secondary notification including the secondary verification code at the electronic device, the device links the payment account to the corresponding device and displays a confirmation on the device (e.g., 558 of FIG. 5H) indicating that the payment account has been linked to the corresponding device.

[0192] At block 628, in some embodiments, the device receives from the financial institution a primary account number (e.g., a digital PAN, DPAN, 16-digit account number, or other account number that cannot be used to complete a transaction manually via a voice call only, instead of completing the payment electronically via the device) for use in authorizing a payment from the payment account using the corresponding device. The received primary account number is different from the account number displayed on the credit card (e.g., a credit card PAN, 16-digit credit card number). At block 630, in some embodiments, the device assigns the received primary account number (e.g., a digital PAN, DPAN, 16-digit account number, or other account number) to the corresponding device to link the payment account to the corresponding device. This allows, for example, the financial institution to distinguish between payment transactions made using the received primary account number that is assigned to the corresponding device and associated with the payment account and payment transactions made using a credit card that is also associated with the payment account.

[0193] In some embodiments, the credit card details screen (e.g., of FIG. 5E) includes a displayed visual graphical representation (e.g., 504 of FIG. 5E) of the credit card associated with the payment account. For example, if the user selects to import credit card information, the graphical representation includes a background image of the physical credit card associated with the payment account. By displaying a background image identical to the physical credit card, the user can easily recognize which credit card is being used to link the payment account.

[0194] In some embodiments, the corresponding device is a second electronic device (e.g., a mobile phone, a laptop computer, a wearable electronic device) separate from the electronic device. For example, the electronic device can be used to link a payment account to another mobile phone. This can be done, for example, by sending provisioning information from the electronic device to the corresponding device (e.g., the other device), which provisioning information is used to link the payment account to the corresponding device (e.g., the other device). In some embodiments, a similar method can be repeated to link a payment account to an electronic device (optionally with a different DPAN). In other embodiments, the corresponding device and the electronic device are the same, and the electronic device is a mobile telecommunications device (e.g., a mobile phone, a laptop computer, a wearable electronic device).

[0195] At block 632, in some embodiments, the device determines whether the corresponding device is configured to require unlock permission (e.g., a passcode) to unlock the corresponding device (e.g., before linking a payment account to the corresponding device). Following a determination that the corresponding device is not configured to require unlock permission, the device displays an unlock authentication configurator on its display for configuring the corresponding device to require unlock permission to unlock the corresponding device or to access certain features of the corresponding device. This provides additional security by requiring that the corresponding device, under at least some circumstances, have lock permission to access the device. For example, this authentication configurator can be used to register a fingerprint or passcode that can authorize payment transactions. In some embodiments, the device links the payment account to the corresponding device after processing of the unlock authentication configurator is complete.

[0196] At block 634, in some embodiments, the device receives a second request to link a second payment account (e.g., a revolving credit account at a financial institution) associated with a second credit card to the corresponding device. The second request includes information about the second credit card (e.g., selecting the credit card to import and / or entering a card security code). For example, similar techniques as described above can be used to request linking of the second payment account to the corresponding device. The device links the second payment account to the corresponding device and provides an indication that the second payment account has been linked to the corresponding device. The device receives at least a selection from among the first payment account and the second payment account to designate a default payment account to be used for payment transactions.

[0197] It should be noted that the details of the methods described above with respect to method 600 (e.g., FIGS. 6A-6C and 5A-5I) are also applicable in an analogous manner to the methods described below. For example, methods 800, 1000, 1200, 1400, 1600, 1800, 2000, and 2200 may include one or more of the features of the various methods described above with reference to method 600. For example, the requests, links, payment accounts, credit cards, devices, indications, and other user interface elements described above with reference to method 600 optionally have one or more of the features of the requests, links, payment accounts, credit cards, devices, indications, and other user interface elements described herein with reference to other methods described herein. For brevity, these details will not be repeated below.

[0198] The operations described above with reference to the figures may be performed by the components shown in FIGS. 1A-1B. For example, receiving, displaying, and determining operations may be performed by event sorter 170, event recognizer 180, and event handler 190. Event monitor 171 of event sorter 170 detects contacts on touch-sensitive display 112, and event dispatcher module 174 distributes the event information to application 136-1. Each event recognizer 180 of application 136-1 compares the event information with a respective event definition 186 to determine whether a first contact at a first location on the touch-sensitive surface corresponds to a predetermined event or sub-event, such as the selection of an object on the user interface. When a corresponding predetermined event or sub-event is detected, event recognizer 180 activates event handler 190 associated with the detection of the event or sub-event. Event handler 190 may utilize or invoke data updater 176 or object updater 177 to update application internal state 192. In some embodiments, the event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one skilled in the art how other methods may be implemented based on the components shown in Figures 1A-1B.

[0199] 7A-7O illustrate example techniques and user interfaces for facilitating a payment transaction using a near field communication radio (such as a near field communication (NFC) radio), according to some embodiments. The techniques and user interfaces of these figures are used to illustrate methods described below, including the method of FIGS. 8A-8B.

[0200] 7A-7B illustrate an exemplary approach for facilitating a payment transaction using a near field communication radio, such as an NFC radio. The NFC standard is related to the radio frequency identification (RFID) standard and describes a communication protocol for transferring information, such as payment, between two devices. However, it should be understood that other communication standards and technologies may be used.

[0201] Multifunction device 100 (and device 300) may include near-field communication circuitry, such as a near-field communication radio. Thus, device 100 may use the near-field communication radio to wirelessly communicate with external devices, such as an NFC-enabled contactless payment transaction terminal 2000. For example, the near-field communication circuitry of device 100 may include a near-field radio transmitter and a near-field radio receiver. The near-field communication radio of device 100 may be supported using capacitively coupled near-field communication structures and / or inductively coupled near-field communication structures. In near-field communication technologies, radio signals typically propagate over distances of, for example, 1 meter or less, 100 cm or less, 10 cm or less, or 1 cm or less, and not over longer distances.

[0202] In Figure 7A, an NFC-enabled contactless payment transaction terminal 2000 creates a venue 2002. For example, an NFC-enabled device entering venue 2002 can use NFC to communicate with contactless payment transaction terminal 2000. In Figure 7A, electronic device 100 is not located at venue 2002. Contactless payment transaction terminal 2000 may be part of a payment system (e.g., a cash register) installed in a retail store for processing payment transactions such as purchasing products and services.

[0203] In some embodiments, the electronic device 100 receives authorization (e.g., from a user, as described in more detail below) to proceed with a payment transaction before detecting the presence of a field 2002 (e.g., an NFC-enabled RF field) generated by the contactless payment transaction terminal 2000. This authorization is valid only for a predetermined period of time (e.g., up to 30 seconds). If the user places the device in the field 2002 after receiving the authorization but before the predetermined time has elapsed, the device will proceed with the payment transaction (e.g., payment of money charged by the contactless payment transaction terminal 2000). After the predetermined time has elapsed, the device no longer has authorization to proceed with the payment transaction (unless the user authorizes the device again) and therefore will not proceed with the payment transaction even if the device is located within range of the field 2002. Thus, after receiving authorization to proceed with a payment transaction, the device does not remain authorized indefinitely.

[0204] 7B, the user places the electronic device 100 within a field 2002. The electronic device detects the presence of a field 2002 (e.g., an NFC-enabled RF field) generated by a contactless payment transaction terminal 2000 (e.g., an NFC-enabled payment transaction terminal) via the electronic device's near field communication radio. In some embodiments, the electronic device detects a communication initiation signal from the field and the contactless payment transaction terminal 2000. In response to detecting the presence of the field 2002 generated by the contactless payment transaction terminal 2000, the device determines whether authorization has been provided to proceed with the payment transaction. For example, the device determines whether the device has been pre-authorized by the user to proceed with the payment transaction (e.g., before detecting the field 2002, as described above) or whether the user is currently authorizing the device to proceed with the payment transaction (e.g., the user has placed their finger on the fingerprint sensor for authorization).

[0205] In some embodiments, while the device is within a field generated by a contactless payment transaction terminal, the device detects a corresponding fingerprint with a fingerprint sensor of the electronic device. In response to detecting the corresponding fingerprint with the fingerprint sensor, the device determines whether the fingerprint matches a registered fingerprint, which allows authorization of the payment transaction. In accordance with determining that the corresponding fingerprint matches the registered fingerprint, the device authorizes the payment transaction. For example, a user places their finger on the fingerprint sensor of the device (e.g., without turning on the device's display or without opening a specific application) and then places the device within the field 2002. When the device detects the field 2002, the device reads the fingerprint and determines that the user has granted permission to make a payment using the device. In accordance with determining that the corresponding fingerprint does not match the registered fingerprint, the device withholds authorization of the payment transaction. In other words, the device is not authorized to proceed with the payment transaction, which means that authorization to proceed with the payment transaction is still required.

[0206] In some embodiments, the user interface of the electronic device is locked upon detecting the presence of the generated field, and the display of the electronic device is turned off upon detecting the presence of the generated field. In response to detecting the presence of the generated field 2002 by the contactless payment transaction terminal 2002, the device turns on the display.

[0207] 7C illustrates an exemplary user interface for authorizing a device to proceed with a payment transaction. In some embodiments, in response to detecting the presence of a venue 2002 generated by a contactless payment transaction terminal 2000, the device displays an electronic wallet, as shown in FIG. 7C (e.g., when the device is placed within range of venue 2002 while the device is unlocked). The electronic wallet includes multiple payment card affordances (such as payment card affordances 704 and 708). For example, the user interface of FIG. 7C allows a user to easily determine which payment account to use when the device proceeds with a payment transaction. In this example, a credit card affordance 704 is displayed at the top of the display, indicating that the payment account associated with credit card affordance 704 will be used for the payment.

[0208] Following a determination that permission to proceed with the payment transaction has been provided (e.g., the user provides permission before entering venue 2002 or the user provides permission while the device is at venue 2002), the device proceeds with the payment transaction with the contactless payment transaction terminal 2000 (e.g., sends an identifier such as a PAN to the contactless payment transaction terminal 2000 for use in completing the payment transaction).

[0209] In some embodiments, facilitating a payment transaction with the contactless payment transaction terminal 2002 includes using a linked payment account (e.g., a payment account linked to the electronic device and stored in an electronic wallet) to complete the payment transaction. In some embodiments, facilitating a payment transaction with the contactless payment transaction terminal 2002 includes using a primary account number to use for the payment transaction (e.g., using a credit account to make a purchase), which primary account number is stored on the electronic device, to complete the payment transaction.

[0210] In some embodiments, in response to determining that permission to proceed with the payment transaction has been provided, the device determines whether the payment transaction has been successfully completed. In response to determining that the payment transaction has been successfully completed, the device issues a success audio alert at the electronic device. The success audio alert indicates that the payment transaction has been successfully completed. In some embodiments, the success audio alert is different from the failure audio alert.

[0211] Similarly, providing a non-audible notification to the device user can assist the user in understanding whether additional input is required. In some embodiments, in response to determining that permission to proceed with the payment transaction has been provided (e.g., the device is ready), the device determines whether the payment transaction has been successfully completed. In response to determining that the payment transaction has been successfully completed, the device generates a success haptic alert indicating that the payment transaction has been successfully completed. In one example, the success haptic alert is different from the failure haptic alert. For example, the failure haptic alert is of longer duration and greater intensity than the success haptic alert.

[0212] 7C illustrates an exemplary user interface for authorizing the device to proceed with the payment transaction. Following a determination that authorization to proceed with the payment transaction has not been provided (e.g., the device is not ready), the device provides an indication requesting authorization to proceed with the payment transaction. For example, the indication may be a visual indicator of a fingerprint on the display (e.g., 710A in FIG. 7C), or the indication may be generating a tactile alert (or both a visual indicator and a tactile alert) at the device. These indications requesting authorization to proceed with the payment transaction provide an intuitive user interface that informs the user that the contactless payment transaction terminal 2000 is able (or willing) to process a payment transaction using the device.

[0213] In some embodiments, the indication requesting authorization to proceed with the payment transaction includes detecting, via near field radio, whether the device continues to be in the presence of the field 2002. In response to detecting that the device is not continuing to be in the presence of the field, the device displays a visual indicator on a display indicating that authorization failed or was not provided. A visual indicator is useful because a user may be looking at the device while the device is not within the field 2002. In response to detecting that the device is continuing to be in the presence of the field 2002, a non-visual alert (e.g., a tactile or audio alert) is generated at the electronic device indicating that authorization failed (or was not provided). A non-visual alert is useful because a user may not be looking at the display when the device is within the field 2002. In some embodiments, a similar approach is used to indicate successful authorization. A user can easily see the display when the device is outside the field, but a user cannot easily see the display when the device is within the field; therefore, providing a non-visual alert when the device is within the field results in a more intuitive user interface for the device.

[0214] In some embodiments, providing an indication requesting permission to proceed with the payment transaction includes displaying an instruction on a display regarding permission to proceed with the payment transaction (e.g., prompting the user to provide permission using a fingerprint reader (710A in FIG. 7C)). In some embodiments, providing an indication requesting permission to proceed with the payment transaction includes generating a haptic alert at the electronic device instead of or in addition to the instruction regarding permission to proceed with the payment transaction.

[0215] In some embodiments, providing an indication requesting permission to proceed with the payment transaction includes displaying a permission request screen on a display of the electronic device, as shown in FIG. 7C. The permission request screen includes a graphical representation 704 of a credit card associated with the payment account, where the graphical representation 704 includes a background image of the credit card associated with the payment account. In some embodiments, the graphical representation 704 also includes other information identifying the credit card associated with the payment account, such as the name of the credit card holder, the credit card number of the physical credit card (even if the credit card number of the physical credit card is different from the account number linked to the device), and / or an expiration date.

[0216] In some embodiments, after detecting the presence of a field 2002 generated by a contactless payment transaction terminal when permission to proceed with the payment transaction has not been provided (e.g., a user has not given permission to the device), the device detects via near field communications radio that the device is no longer within range of the field 2002 generated by the contactless payment transaction terminal 2000. In response to detecting that the device is no longer within range of the field 2002 (e.g., a user is not holding the device over the contactless payment transaction terminal 2000), the device displays multiple payment card affordances (e.g., payment card affordances 704 and 708 in FIG. 7C ) associated with different payment accounts. The device receives permission by one of the payment accounts to proceed with the payment transaction for a predetermined time (e.g., in response to detecting user input selecting a “Pay with this payment account” option in a displayed representation of the payment account).

[0217] In FIG. 7C , the device provides an indication that a default payment card affordance 704 of multiple payment card affordances 704 and 708 has been selected as the default payment account. The default primary account number associated with the default payment card affordance is selected for use in the payment transaction (e.g., if the user has not selected another payment account for use in the payment transaction). In some embodiments, a different payment account is assigned as the default payment account based on current environmental factors, such as the current day, time, and / or location. In some embodiments, a different payment account is assigned as the default card based on the quota available on one or more payment accounts. For example, a payment account that has reached its maximum quota (or has reached a threshold based on its maximum quota) will not be used as the default payment account.

[0218] However, the user may select an alternative payment card affordance (such as one of multiple payment card affordances 704 and 708). The device receives a selection (e.g., a finger tap) of an alternative payment card affordance from multiple payment card affordances 704 and 708, where the alternative payment card affordance is associated with a corresponding alternative primary account number. In response to receiving the selection of the alternative payment card affordance, the device selects the corresponding alternative primary account number (rather than the default primary account number) to use for the payment transaction.

[0219] In some embodiments, following a determination that authorization has not been provided, the device receives authorization to proceed with the payment transaction (e.g., receiving a passcode for payment or detecting a fingerprint for payment) for a predetermined time (e.g., up to 30 seconds). For example, a user places the device in venue 2002 and is prompted to provide authorization as described above. The user then removes the device from venue 2002 and provides authorization using the fingerprint sensor or passcode. The authorization is valid for a predetermined time (e.g., 30 seconds). If the user places the device in venue 2002 before the predetermined time has elapsed, the device will proceed with the payment transaction. After the predetermined time has elapsed, the device no longer has authorization to proceed with the payment transaction (unless the user authorizes the device again), and therefore the device will not proceed with the payment transaction. Thus, after receiving authorization to proceed with the payment transaction, the device does not remain authorized indefinitely.

[0220] 7D-7G illustrate various exemplary user interfaces for receiving authorization to proceed with a payment transaction. As described above, in some embodiments, authorization to proceed with the payment transaction can be provided by a fingerprint sensor 702. In FIG. 7D, the device detects a corresponding fingerprint with the fingerprint sensor 702 of the electronic device. In response to detecting the corresponding fingerprint with the fingerprint sensor, the device determines that the fingerprint matches a registered fingerprint, allowing authorization of the payment transaction. The device indicates progress in determining whether the corresponding fingerprint matches the registered fingerprint, as shown in partially filled fingerprint visual indicator 710B, by at least partially filling in fingerprint visual indicator 710A. In response to determining that the corresponding fingerprint matches the registered fingerprint, the device can authorize the payment transaction. The device can also further indicate progress in the payment transaction processing by further filling in fingerprint visual indicator 710B. The device provides an indication (e.g., check mark 730 in FIG. 7K) when the payment transaction is complete.

[0221] 7E illustrates an exemplary user interface for a failed fingerprint sensor authorization attempt. In some embodiments, following a determination that the corresponding fingerprint does not match an enrolled fingerprint, the device displays a visual prompt (712 in FIG. 7E) on the display instructing the user to place a finger on the fingerprint sensor 702.

[0222] 7E-7F show various exemplary user interfaces using a passcode. In some embodiments, following a determination that the corresponding fingerprint does not match the enrolled fingerprint, the device displays an affordance 714 on the display for receiving authorization to proceed with the payment transaction using the payment passcode (rather than the fingerprint sensor). The device also indicates to the user that authorization failed, for example, by providing a visual prompt 712. If the device receives a selection of the affordance 714 for receiving authorization, the device displays a keypad 740, as shown in FIG. 7L, for receiving payment passcode entry. In FIG. 7F, the user attempts to authenticate again using the fingerprint sensor 702. The device indicates progress in determining whether the corresponding fingerprint matches the enrolled fingerprint by at least partially filling in the fingerprint visual indicator, as shown in partially filled fingerprint visual indicator 710B (FIG. 7F). If the device determines that the corresponding fingerprint matches the enrolled fingerprint, the device displays a fully filled fingerprint visual indicator 710C (FIG. 7G).

[0223] In some embodiments, following a determination that the corresponding fingerprint does not match the enrolled fingerprint, the device causes a failure audio alert to be played by a speaker at the electronic device. The failure audio alert indicates that permission to proceed with the payment transaction was not provided. Providing the device user with an audio notification of the status (or condition) of this scheme can assist the user in understanding whether additional input is required.

[0224] In some embodiments, following a determination that the corresponding fingerprint does not match the enrolled fingerprint, the device generates a haptic failure alert indicating that permission to proceed with the payment transaction was not provided. Haptic feedback is particularly useful to the user when the user places the device in venue 2002 and is not looking at the display.

[0225] 7F illustrates an exemplary user interface for authentication using a fingerprint sensor after one or more failed attempts at authentication using the fingerprint sensor. In some embodiments, the electronic device determines whether a predetermined number of attempts to receive authorization to proceed with a payment transaction using the fingerprint sensor has been reached. Following a determination that the predetermined number of attempts to receive authorization has been reached, the device requires authorization to proceed with the payment transaction using a payment passcode, as in the user interface illustrated in FIG. 7L. For example, the predetermined number of attempts is three. Thus, after three failed attempts at authorization using the fingerprint sensor, the device requires authorization to proceed with the payment transaction using a payment passcode.

[0226] 7M-7O illustrate various exemplary user interfaces for receiving authorization to proceed with a payment transaction. As described above, authorization to proceed with a payment transaction may be provided by receiving a payment passcode. In some embodiments, a device receives a payment passcode at an electronic device. The device determines that the payment passcode matches a registered passcode that enables authorization of the payment transaction. In response to determining that the payment passcode matches a registered passcode (e.g., a passcode programmed by a user to unlock the device or make a payment), the device authorizes the payment transaction. For example, if authorization using the fingerprint sensor 702 fails, authorization can be received using the payment passcode. If the electronic device does not support authorization using the fingerprint sensor 702 (e.g., the feature is disabled or the device does not have a fingerprint sensor 702), the user interface of FIG. 7M may be displayed instead of the user interface of FIG. 7C. In FIG. 7N, the device receives selection of a payment passcode affordance 732. In response, the device displays a keypad 740 for receiving payment passcode entry, as shown in FIG. 7O.

[0227] In some embodiments, the predetermined time is based on the current location of the electronic device. For example, if the device determines that the current location is a department store, the predetermined time may be set to 15 seconds. In another example, if the device determines that the current location is a concert or theater location, the predetermined time may be set to 45 seconds. This can help absorb delays, such as standing in line or making a purchase decision. Having a location-based predetermined time helps limit fraud.

[0228] In some embodiments, the predetermined time period is based on a credit score associated with the payment account. For example, the predetermined time period may be based on a credit worthiness. In one example, if the credit score associated with the payment account is greater than a threshold, indicating good credit, the predetermined time period may be set to 30 seconds. In another example, if the credit score associated with the payment account is less than a threshold, indicating poor (e.g., insufficient) credit, the predetermined time period may be set to 15 seconds. For example, a predetermined time period based on a credit score can help limit fraud.

[0229] In some embodiments, the predetermined time is user-configurable. For example, a user may determine that a longer predetermined time may be beneficial for the payment transaction to proceed. Thus, the user may increase the predetermined time to a value higher than the default value, such as 60 seconds. For example, a user-configurable predetermined time may help limit fraud.

[0230] 7H-7J illustrate various exemplary user interfaces for indicating that permission to proceed with a payment transaction has been provided. In some embodiments, in response to receiving permission to proceed with the payment transaction (e.g., via a passcode or fingerprint sensor 702), the device displays a graphical indication 720A-720C that permission has been provided. In some embodiments, the graphical indication includes an indication to place the device in the field (e.g., an animated icon showing the moving device to indicate that the device needs to be moved so that it is positioned within field 2002). For example, graphical indication 720A-720C may be an animation showing an electronic device, such as a mobile phone, starting in a substantially vertical position (720A in FIG. 7H), tilting downward (backward) from the substantially vertical position (720B in FIG. 7I), and then returning to a substantially vertical position (720C in FIG. 7J). This indicates to the user that permission to proceed with the payment transaction has been provided to the electronic device and that the user must place the electronic device in field 2002 to proceed with the payment transaction.

[0231] 7K illustrates an exemplary user interface for indicating that a payment transaction is complete. In some embodiments, upon receiving authorization to proceed with the payment transaction, the device proceeds with the payment transaction (e.g., processes the payment transaction using the NFC-enabled contactless payment transaction terminal 2000 if the device is within range of the venue 2002 and the authorization has not expired). In some examples, the device provides an indication (e.g., check mark 730 in FIG. 7K) when the payment transaction is complete.

[0232] 8A-8B are flow diagrams illustrating a method 800 for facilitating a payment transaction using a near field communication radio (e.g., an NFC radio) according to some embodiments. It should be understood that other communication standards and technologies may be used. Method 800 is performed on a device including a display and a near field communication radio (e.g., device 300 of FIG. 3 or portable multifunction device 100 of FIG. 1). Some operations of method 800 may be combined, some operations may be reordered, and some operations may be omitted.

[0233] As described below, method 800 provides an intuitive way to conduct payment transactions using a near-field communication radio. This method reduces the cognitive burden on a user when conducting a payment transaction, thereby creating a more efficient human-machine interface. In the case of battery-operated computing devices, allowing users to conduct payment transactions faster and more efficiently conserves power and increases the time between battery charges.

[0234] Multifunction device 100 (and device 300) may include near-field communication circuitry. Thus, device 100 can use a near-field communicator to wirelessly communicate with external devices, such as an NFC-enabled contactless payment transaction terminal 2000. The contactless payment transaction terminal 2000 can be part of a payment system (e.g., a cash register) installed in a retail store for processing payment transactions, such as purchasing products and services. For example, the near-field communication circuitry of device 100 can include a near-field radio transmitter and a near-field radio receiver. The near-field communicator of device 100 can be supported using capacitively coupled near-field communication structures and / or inductively coupled near-field communication structures. In near-field communication technologies, radio signals typically propagate over distances of, for example, 1 meter or less, 100 cm or less, 10 cm or less, or 1 cm or less, but not over longer distances.

[0235] At block 802, in some embodiments, the electronic device receives authorization (e.g., from a user, as described in more detail below) to proceed with a payment transaction before detecting the presence of a field (e.g., NFC-enabled RF field 2002 of FIG. 7A ) generated by a contactless payment transaction terminal (e.g., 2000 of FIG. 7A ). The authorization is valid for only a predetermined time (e.g., up to 30 seconds). After receiving the authorization, if the user places the device in the field before the predetermined time has elapsed, the device will proceed with the payment transaction (e.g., payment of money charged by contactless payment transaction terminal 2000 of FIG. 7A ). After the predetermined time has elapsed, the device no longer has authorization to proceed with the payment transaction (unless the user authorizes the device again) and therefore will not proceed with the payment transaction even if the device is located within range of the field. Thus, after receiving authorization to proceed with a payment transaction, the device does not remain authorized indefinitely. In some embodiments, the device cannot receive authorization to proceed with a payment transaction before detecting the presence of a field generated by a contactless payment transaction terminal.

[0236] In block 804, the electronic device detects the presence of a field (e.g., NFC-enabled RF field 2002 of FIG. 7B) generated by a contactless payment transaction terminal (e.g., NFC-enabled payment transaction terminal 2000 of FIG. 7B) using the electronic device's near field communication radio.

[0237] In response to detecting the presence of a venue generated by the contactless payment transaction terminal, the device determines whether authorization to proceed with the payment transaction has been provided at block 806. For example, the device determines whether the device has been pre-authorized by the user to proceed with the payment transaction (e.g., before the device detects the venue) or whether the user is currently authorizing the device to proceed with the payment transaction (e.g., the user has placed a finger on the fingerprint sensor for authorization).

[0238] At block 808, in some embodiments, while the device is within a field generated by the contactless payment transaction terminal, the device detects a corresponding fingerprint on a fingerprint sensor of the electronic device. In response to detecting the corresponding fingerprint on the fingerprint sensor, the device determines whether the fingerprint matches a registered fingerprint, which allows authorization of the payment transaction. In accordance with determining that the corresponding fingerprint matches the registered fingerprint, the device authorizes the payment transaction. For example, a user places their finger on the fingerprint sensor of the device (e.g., without turning on the device's display or without opening a specific application) and then places the device within the field. When the device detects the field, the device reads the fingerprint and determines that the user has granted permission to make a payment using the device. In accordance with determining that the corresponding fingerprint does not match the registered fingerprint, the device withholds authorization of the payment transaction. In other words, the device is not authorized to proceed with the payment transaction, which means that authorization to proceed with the payment transaction is still required.

[0239] In some embodiments, the user interface of the electronic device is locked upon detecting the presence of the generated field, and the display of the electronic device is turned off upon detecting the presence of the generated field. In response to detecting the presence of the generated field by the contactless payment transaction terminal, the device turns on the display.

[0240] At block 810, in some embodiments, in response to detecting the presence of a field generated by the contactless payment transaction terminal, the device displays an electronic wallet (e.g., when the device is placed within range of the field, as shown in FIG. 7C and / or while the device is unlocked). The electronic wallet includes multiple payment card affordances (such as payment card affordances 704 and 708 in FIG. 7C).

[0241] In block 812, pursuant to a determination that permission to proceed with the payment transaction has been provided (e.g., the user provided permission before entering the venue or the user provided permission while the device was at the venue), the device proceeds with the payment transaction with the contactless payment transaction terminal (e.g., sends an identifier such as a PAN to the contactless payment transaction terminal for use in completing the payment transaction).

[0242] In some embodiments, facilitating a payment transaction with the contactless payment transaction terminal 2002 includes using a linked payment account (e.g., a payment account linked to the electronic device and stored in an electronic wallet) to complete the payment transaction. In some embodiments, facilitating a payment transaction with the contactless payment transaction terminal includes using a primary account number to use for the payment transaction (e.g., using a credit account to make a purchase), which primary account number is stored on the electronic device, to complete the payment transaction.

[0243] At block 814, in some embodiments, in accordance with a determination that permission to proceed with the payment transaction was provided, the device determines whether the payment transaction was completed successfully. In response to a determination that the payment transaction was completed successfully, the device causes a success audio alert to be played at the electronic device. The success audio alert indicates that the payment transaction was completed successfully. In some embodiments, the success audio alert is different from the failure audio alert.

[0244] Similarly, providing a non-audible notification to the device user can assist the user in understanding whether additional input is required. At block 814, in some embodiments, in response to determining that permission to proceed with the payment transaction has been provided (e.g., the device is ready), the device determines whether the payment transaction was completed successfully. In response to determining that the payment transaction was completed successfully, the device generates a success haptic alert indicating that the payment transaction was completed successfully. In one example, the success haptic alert is different from the failure haptic alert. For example, the failure haptic alert is longer in duration and greater in intensity than the success haptic alert.

[0245] Pursuant to a determination in block 816 that permission to proceed with the payment transaction has not been provided (e.g., the device is not ready), the device provides an indication requesting permission to proceed with the payment transaction in block 818. For example, the indication may be the display of a visual indicator of the fingerprint on the display (e.g., 710A in FIG. 7C ), or the indication may be the generation of a tactile alert at the device (or both a visual indicator and a tactile alert). These indications requesting permission to proceed with the payment transaction provide an intuitive user interface that informs the user that the contactless payment transaction terminal 2000 is able (or willing) to process a payment transaction using the device.

[0246] In some embodiments, the indication requesting authorization to proceed with the payment transaction includes detecting, via a near-field communication radio, whether the device continues to be in the presence of the field 2002. In response to detecting that the device is not continuing to be in the presence of the field, the device displays a visual indicator on a display indicating that authorization failed or was not provided. A visual indicator is useful because a user may be looking at the device while the device is not within the field 2002. In response to detecting that the device is continuing to be in the presence of a field, the electronic device issues a non-visual alert (e.g., a tactile or audio alert) indicating that authorization failed (or was not provided). A non-visual alert is useful when the device is within the field 2002 because a user may not be looking at the display. In some embodiments, a similar approach is used to indicate successful authorization. When the device is outside the field, a user may likely be able to easily see the display, but when the device is within the field, a user may not be able to easily see the display; therefore, providing a non-visual alert when the device is within the field results in a more intuitive user interface for the device.

[0247] In some embodiments, providing an indication requesting permission to proceed with the payment transaction includes displaying an instruction on a display regarding permission to proceed with the payment transaction (e.g., prompting the user to provide permission using a fingerprint reader (710A in FIG. 7C)). In some embodiments, providing an indication requesting permission to proceed with the payment transaction includes generating a haptic alert at the electronic device instead of or in addition to the instruction regarding permission to proceed with the payment transaction.

[0248] In some embodiments, providing an indication requesting permission to proceed with the payment transaction includes displaying a permission request screen on a display of the electronic device. The permission request screen includes a graphical representation (e.g., 704 in FIG. 7C ) of a credit card associated with the payment account, where the graphical representation (e.g., 704 in FIG. 7C ) includes a background image of the credit card associated with the payment account. In some embodiments, the graphical representation (e.g., 704 in FIG. 7C ) also includes other information identifying the credit card associated with the payment account, such as the credit card holder's name, the credit card number of the physical credit card (even if the credit card number of the physical credit card is different from the account number linked to the device), and / or the expiration date.

[0249] At block 820, in some embodiments, after detecting the presence of a field generated by a contactless payment transaction terminal when permission to proceed with the payment transaction has not been provided (e.g., the user has not given permission to the device), the device detects via a near-field communication radio that the device is no longer within range of the field generated by the contactless payment transaction terminal. In response to detecting that the device is no longer within range of the field (e.g., the user is not holding the device over the contactless payment transaction terminal), the device displays multiple payment card affordances (e.g., payment card affordances 704 and 708 in FIG. 7C ) associated with different payment accounts. The device receives permission by one of the payment accounts to proceed with the payment transaction for a predetermined time (e.g., in response to detecting user input selecting a “Pay with this payment account” option in a displayed representation of the payment account).

[0250] At block 822, in some embodiments, the device provides an indication that a default payment card affordance (e.g., 704 in FIG. 7C ) among multiple payment card affordances (e.g., 704 and 708 in FIG. 7C ) has been selected as the default payment account. A default primary account number associated with the default payment card affordance is selected for use in the payment transaction (e.g., if the user has not selected another payment account for use in the payment transaction). In some embodiments, a different payment account is assigned as the default payment account based on environmental factors such as the current date, time, and / or location. In some embodiments, a different payment account is assigned as the default card based on the available allocation for one or more payment accounts. For example, a payment account that has reached its maximum allocation (or has reached a threshold based on its maximum allocation) will not be used as the default payment account.

[0251] At block 824, in some embodiments, the device receives a selection (e.g., a finger tap) of another payment card affordance from among the plurality of payment card affordances (e.g., 704 and 708 in FIG. 7C ), where the other payment card affordance is associated with a corresponding different primary account number. In response to receiving the selection of the other payment card affordance, the device selects the corresponding different primary account number (rather than the default primary account number) to use for the payment transaction.

[0252] At block 826, in some embodiments, based on a determination that authorization to proceed with the payment transaction has not been provided, the device receives authorization to proceed with the payment transaction (e.g., receiving a passcode for payment or detecting a fingerprint for payment) for a predetermined time (e.g., up to 30 seconds). For example, the user places the device in the venue and is prompted to provide authorization as described above. The user then removes the device from the venue and provides authorization using the fingerprint sensor or passcode. The authorization is valid for a predetermined time (e.g., 30 seconds). If the user places the device in the venue before the predetermined time has elapsed, the device will proceed with the payment transaction. After the predetermined time has elapsed, the device no longer has authorization to proceed with the payment transaction (unless the user authorizes the device again), and therefore the device will not proceed with the payment transaction. Thus, after receiving authorization to proceed with the payment transaction, the device does not remain authorized indefinitely.

[0253] As mentioned above, in some embodiments, authorization to proceed with the payment transaction may be provided by a fingerprint sensor (e.g., 702 of FIG. 7D ). At block 830, the device detects a corresponding fingerprint with the fingerprint sensor of the electronic device. In response to detecting the corresponding fingerprint with the fingerprint sensor, the device determines that the fingerprint matches a registered fingerprint, which allows for authorization of the payment transaction. In accordance with determining that the corresponding fingerprint matches the registered fingerprint, the device authorizes the payment transaction.

[0254] In some embodiments, following a determination that the corresponding fingerprint does not match the enrolled fingerprint (e.g., authentication using the fingerprint sensor failed), the device displays a visual prompt (712 in FIG. 7E) on the display instructing the user to place a finger on the fingerprint sensor 702.

[0255] In some embodiments, following a determination that the corresponding fingerprint does not match the enrolled fingerprint, the device displays an affordance on the display (e.g., 714 in FIG. 7E) for receiving authorization to proceed with the payment transaction using a payment passcode (rather than a fingerprint sensor). The device also indicates to the user that authorization failed, for example, by providing a visual prompt (e.g., 712 in FIG. 7E). If the device receives a selection of the affordance for receiving authorization, the device displays a keypad (e.g., 740 in FIG. 7L) for receiving payment passcode entry.

[0256] In some embodiments, following a determination that the corresponding fingerprint does not match the enrolled fingerprint, the device causes a failure audio alert to be played by a speaker at the electronic device. The failure audio alert indicates that permission to proceed with the payment transaction was not provided. Providing the device user with an audio notification of the status (or state) of this procedure assists the user in understanding whether additional input is required.

[0257] In some embodiments, following a determination that the corresponding fingerprint does not match the enrolled fingerprint, the device generates a tactile failure alert indicating that permission to proceed with the payment transaction was not provided. Haptic feedback is particularly useful to the user when the user places the device within a venue and is not looking at the display.

[0258] In some embodiments, the electronic device determines whether a predetermined number of attempts to receive authorization to proceed with a payment transaction using the fingerprint sensor has occurred. Following a determination that the predetermined number of attempts to receive authorization has occurred, the device requires authorization to proceed with the payment transaction (user interface of FIG. 7L) using a payment passcode. For example, the predetermined number of attempts is three. Thus, after three unsuccessful attempts to authorize using the fingerprint sensor, the device requires authorization to proceed with the payment transaction using the payment passcode.

[0259] As described above, authorization to proceed with a payment transaction can be provided by receiving a payment passcode. In some embodiments, the device receives a payment passcode at the electronic device. The device determines that the payment passcode matches a registered passcode that allows authorization of the payment transaction. In response to determining that the payment passcode matches a registered passcode (e.g., a passcode programmed by a user to unlock the device or make a payment), the device authorizes the payment transaction. For example, if authorization using a fingerprint sensor fails, authorization can be received using the payment passcode.

[0260] In some embodiments, the predetermined time is based on the current location of the electronic device. For example, if the device determines that the current location is a department store, the predetermined time may be set to 15 seconds. In another example, if the device determines that the current location is a concert or theater location, the predetermined time may be set to 45 seconds. This can help absorb delays, such as standing in line or making a purchase decision. Having a location-based predetermined time helps limit fraud.

[0261] In some embodiments, the predetermined time period is based on a credit score associated with the payment account. For example, the predetermined time period may be based on a credit worthiness. In one example, if the credit score associated with the payment account is greater than a threshold, indicating good credit, the predetermined time period may be set to 30 seconds. In another example, if the credit score associated with the payment account is less than a threshold, indicating poor (insufficient) credit, the predetermined time period may be set to 15 seconds. For example, a predetermined time period based on a credit score can help limit fraud.

[0262] In some embodiments, the predetermined time period is user-configurable. For example, a user may determine that a longer predetermined time period would be beneficial for the payment transaction to proceed. Thus, the user may increase the predetermined time period to a value higher than the default value, such as 60 seconds. For example, a user-configurable predetermined time period may help limit fraud.

[0263] At block 832, in some embodiments, in response to receiving authorization to proceed with the payment transaction (e.g., via a passcode or fingerprint sensor), the device displays a graphical indication (e.g., 720A-720C in FIGS. 7H-7J) that authorization has been provided. In some embodiments, the graphical indication includes an indication to place the device in the field (e.g., an animated icon showing the moving device to indicate that the device needs to be moved so that it is placed within the field), indicating to the user that authorization has been provided to the electronic device to proceed with the payment transaction and that the user must place the electronic device in the field to proceed with the payment transaction.

[0264] In block 834, in some embodiments, in response to receiving permission to proceed with the payment transaction, the device proceeds with the payment transaction (e.g., processes the payment transaction using the NFC-enabled contactless payment transaction terminal 2000 if the device is within range of the venue 2002 and the permission has not expired).

[0265] It should be noted that the details of the methods described above with respect to method 800 (e.g., FIGS. 8A-8B and 7A-7O) are also applicable in an analogous manner to the methods described below and above. For example, methods 600, 1000, 1200, 1400, 1600, 1800, 2000, and 2200 may include one or more features of the various methods described above with reference to method 800. For example, the payment transaction, authorization, electronic wallet, device, alert, and user interface element described above with reference to method 800 optionally include one or more features of the payment transaction, authorization, electronic wallet, device, alert, and user interface element described herein with reference to other methods described herein. For the sake of brevity, these details will not be repeated below.

[0266] The operations described above with reference to the figures may be performed by the components shown in FIGS. 1A-1B. For example, display, detection, and determination operations may be performed by event sorter 170, event recognizer 180, and event handler 190. Event monitor 171 of event sorter 170 detects contacts on touch-sensitive display 112, and event dispatcher module 174 distributes the event information to application 136-1. Each event recognizer 180 of application 136-1 compares the event information with a respective event definition 186 to determine whether a first contact at a first location on the touch-sensitive surface corresponds to a predetermined event or sub-event, such as the selection of an object on the user interface. When a corresponding predetermined event or sub-event is detected, event recognizer 180 activates event handler 190 associated with the detection of the event or sub-event. Event handler 190 may utilize or invoke data updater 176 or object updater 177 to update application internal state 192. In some embodiments, the event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one skilled in the art how other methods can be implemented based on the components shown in Figures 1A-1B.

[0267] 9A-9H illustrate exemplary user interfaces for displaying transaction information for a payment account, according to some embodiments. The user interfaces in these figures are used to illustrate the methods described below, including the method of FIGS. 10A-10B.

[0268] 9A-9C illustrate exemplary user interfaces for displaying details of recent payment transactions, according to some embodiments. FIG. 9A illustrates an exemplary user interface of an electronic device 100 including an electronic wallet. The electronic wallet includes a corresponding representation of a payment account (e.g., a revolving credit account held with a financial institution). The corresponding representation of the payment account (e.g., a display representing the front of a credit card associated with the payment account) includes first transaction information 950 (e.g., date, time, location of the transaction, name of the retailer, amount charged) regarding a first payment transaction associated with the payment account. For example, the first payment transaction may be the most recent transaction associated with the payment account. The first transaction information 950 includes, for example, the date 912, time, and / or location of the first payment transaction. The first transaction information 950 may also include the name 910 of the retailer associated with the first payment transaction and the amount charged for the first payment transaction. In some embodiments, the first payment transaction was completed using the electronic device, such as through an NFC payment transaction using the electronic device (e.g., as shown and described in FIGS. 7A-7O and 8A-8B) or through a payment transaction using an application or website accessed on the electronic device (e.g., as shown and described in FIGS. 11A-11N and 12A-12C). In some embodiments, the first payment transaction was completed using a physical credit card associated with the payment account (e.g., by swiping the credit card at a payment terminal at a retail store). Displaying the first transaction information 950 allows a viewer of the electronic wallet to quickly and efficiently understand the details of the most recent transaction associated with the payment account.

[0269] FIG. 9B illustrates an exemplary user interface displaying information about a subsequent payment transaction. The electronic device detects a second payment transaction using the electronic device associated with a payment account. For example, the payment transaction may be an NFC payment transaction using the electronic device (e.g., as shown and described in FIGS. 7A-7O and 8A-8B) or a payment transaction using an application or website accessed on the electronic device (e.g., as shown and described in FIGS. 11A-11N and 12A-12C). In one embodiment, the payment account is linked to the electronic device. In response to detecting the second payment transaction at block 1006, the device displays second transaction information 960 about the second payment transaction (e.g., the date, time, and location of the second payment transaction) at block 1008 before receiving information about the second payment transaction from a financial institution involved in the second transaction (e.g., the merchant or financial institution that processed the payment transaction). The second transaction information 960 is based on information locally available on the electronic device. For example, if a second payment transaction is detected, the information locally available to the electronic device includes one or more of the date of the second payment transaction 922, the time of the second payment transaction 922, or the location of the electronic device 924. In one embodiment, the second transaction information 960 is based solely on information locally available to the electronic device prior to receiving information about the second payment transaction from the financial institution involved in the second transaction.

[0270] In some embodiments, the display of second transaction information 960 regarding the second payment transaction (e.g., date, time, location of the second payment transaction) replaces the display of first transaction information 950 (e.g., date, time, location, retailer name, charge amount of the first payment transaction). In other words, displaying second transaction information 960 regarding the second payment transaction includes replacing the display of first transaction information 950 with the display of second transaction information 960.

[0271] 9C illustrates updating second transaction information 960. In some embodiments, the electronic device receives first additional information 926 about the second payment transaction (e.g., the amount of the second payment transaction) from an intermediary involved in the second transaction. The intermediary may be, for example, an institution that provides the operating system for the electronic device or that provides an electronic wallet software application for the electronic device. In some embodiments, the first additional information 926 includes the amount of the second payment transaction (e.g., $425.00). In response to receiving the first additional information 926 about the second payment transaction from the intermediary involved in the second transaction, the electronic device updates second transaction information 960 about the second payment transaction to include the first additional information 926 about the second payment transaction. Thus, the user interface allows a user to easily and efficiently determine the date, time, location, and / or amount of the most recently detected payment transaction (e.g., the second payment transaction) associated with a payment account.

[0272] 9D illustrates a diagram of further updating the second transaction information 960. In some embodiments, the electronic device receives second additional information about the second payment transaction (e.g., dollar amount, name of merchant 920) from a financial institution (e.g., a bank or merchant) involved in the second transaction. In response to receiving the second additional information about the second payment transaction 920 from the financial institution involved in the second transaction, the device updates the second transaction information about the second payment transaction 920 to include the second additional information about the second payment transaction 920. In some embodiments, the second transaction information is updated when the electronic wallet is refreshed (e.g., by reloading the electronic wallet application or by reopening the electronic wallet application after it has been closed). In some embodiments, the second additional information about the second payment transaction 920 includes the name of the merchant receiving payment as a result of the second payment transaction.

[0273] In some embodiments, the electronic device displays an available credit amount (e.g., how much more can be charged to the account before reaching the account's credit limit, or how much more can be charged to the account before reaching a user-specified quota for the account) above the corresponding representation of the payment account. For example, the available credit amount indicates the amount of credit available to the payment account based on the payment account's credit limit. By displaying the available credit amount, the user can effectively determine how much more money they have left to spend using the payment account.

[0274] FIG. 9E illustrates an exemplary user interface for displaying a message from the financial institution. In some embodiments, the corresponding representation of the payment account includes the message from the financial institution. The electronic device receives a text message 916 from the financial institution and displays the text message from the financial institution on the corresponding representation of the payment account. For example, the message may be an offer to the user or a notification related to the payment account. The electronic device receives a selection of the text message to be displayed (e.g., the user activates the text message by tapping on the message), and in response to receiving the selection of the text message to be displayed, the device displays a particular application associated with the financial institution (e.g., a banking application of the financial institution). For example, when the user taps on the text message 916, the electronic device displays a particular software application associated with the financial institution.

[0275] 9F-9G show an exemplary user interface for displaying transaction details for a payment account. In one embodiment, the electronic device displays an account details affordance 906 over a corresponding representation of the payment account. The electronic device receives a selection of the account details affordance 906 in FIG. 9F, and in response to receiving the selection of the transaction details affordance 906, the electronic device replaces the display of transaction details 930 for the payment account (e.g., the device displays the background of the representation of the payment account to reveal payment history and further details) with the display of the corresponding representation of the payment account, as shown in FIG. 9G. The transaction details 930 include first transaction information 950 and second transaction information 960. For example, when a user taps the transaction details affordance 906, the electronic device displays a list of transaction history for the payment account.

[0276] In some embodiments, transaction details 930 includes a further transaction affordance 954. The electronic device receives a selection of the further transaction affordance 954, and in response to receiving the selection of the further transaction affordance 954, the device displays third transaction information related to a third payment transaction associated with the payment account as part of the displayed transaction details 930 (e.g., the device displays more (or older) transactions related to the payment account).

[0277] In some embodiments, transaction details 930 includes a card removal affordance 958. The electronic device receives a selection of the card removal affordance, and in response to receiving the selection of the card removal affordance 958, the electronic device displays a confirmation request to remove the corresponding representation of the payment account from the electronic wallet. The device receives a confirmation to remove the corresponding representation of the payment account from the electronic wallet (e.g., the user activates the affordance confirming that the payment account should be removed). The electronic device removes the corresponding representation of the payment account from the electronic wallet (e.g., after receiving the confirmation). Thus, the user can initiate the process of removing the link between the electronic device and the payment account by tapping on the card removal affordance 958.

[0278] 9G-9H show exemplary user interfaces for accessing a particular application associated with a payment account. In some embodiments, transaction details 930 include an open application affordance 934 for accessing the particular application or a download application affordance for downloading and installing the particular application. The electronic device determines whether a particular application for accessing details of the associated payment account (e.g., a software application associated with the payment account, such as a banking application) is installed on the electronic device. In accordance with a determination that the particular application is installed, the electronic device displays an open application affordance 934 for accessing (launching or displaying) the particular application. In some embodiments, in accordance with a determination that the particular application is not installed, the electronic device displays a download application affordance (e.g., instead of open application affordance 934) for downloading and installing the particular application on the electronic device. In some embodiments, the electronic device receives a selection of open application affordance 934 (e.g., a finger tap on open application affordance 934), and in response to receiving the selection of open application affordance 934, the electronic device completely replaces the display of transaction details 930 with a display of the particular application, as shown in FIG. 9H. For example, if the user taps the open application affordance 934, the particular application is displayed. If the user taps the download application affordance, the particular application is downloaded or a user interface for downloading the particular application is displayed.

[0279] 9G-9H show exemplary user interfaces for accessing a particular application associated with a payment account to view details of a particular payment transaction. In one embodiment, the electronic device receives a selection of first transaction information 950 of the displayed transaction details 930, and in response to receiving the selection of the first transaction information 950, the electronic device completely replaces the display of transaction details 930 with a display of the particular application 970, as shown in FIG. 9H. The display of the particular application 970 includes details 972 about the first payment transaction associated with the payment account.

[0280] In some embodiments, the displayed electronic wallet includes a representation of a first stack of card objects and a second stack of card objects, the first stack of card objects being visually separated from the second stack of card objects. The first stack of card objects includes a corresponding representation of a payment account and a second corresponding representation of a second payment account. The second stack of card objects includes membership card objects associated with non-financial institutions (e.g., grocery store membership cards, gym membership cards, coffee shop discount cards).

[0281] 10A-10B are flow diagrams illustrating a method 1000 for displaying transaction information for a payment account, according to some embodiments. Method 1000 is performed on a device having a display (e.g., device 300 of FIG. 3 or portable multifunction device 100 of FIG. 1). Some operations of method 1000 may be combined, some operations may be reordered, and some operations may be omitted.

[0282] As described below, method 1000 provides an intuitive way to display payment account transaction information. This method reduces the cognitive burden on a user when accessing transaction information, thereby creating a more efficient human-machine interface. For battery-operated computing devices, allowing users to access transaction information faster and more efficiently conserves power and increases the time between battery charges.

[0283] In block 1002, the electronic device displays an electronic wallet that includes a corresponding representation of a payment account (e.g., a revolving credit account held with a financial institution). The corresponding representation of the payment account (e.g., a display showing the front of a credit card associated with the payment account) includes first transaction information (e.g., transaction date, time, location, retailer name, and charge amount, e.g., 950 of FIG. 9A ) regarding a first payment transaction associated with the payment account. For example, the first payment transaction may be the most recent transaction associated with the payment account. The first transaction information (e.g., 950 of FIG. 9A ) includes, for example, the date (e.g., 912 of FIG. 9A ), time, and / or location of the first payment transaction. The first transaction information may also include the name of the retailer associated with the first payment transaction (e.g., 910 of FIG. 9A ) and the charge amount for the first payment transaction (e.g., 914 of FIG. 9A ). In some embodiments, the first payment transaction was completed using the electronic device, such as through an NFC payment transaction using the electronic device (e.g., as shown and described in FIGS. 7A-7O and 8A-8B) or through a payment transaction using an application or website accessed on the electronic device (e.g., as shown and described in FIGS. 11A-11N and 12A-12C). In some embodiments, the first payment transaction was completed using a physical credit card associated with the payment account (e.g., by swiping the credit card at a payment terminal at a retail store). Displaying the first transaction information allows a viewer of the electronic wallet to quickly and efficiently understand the details of recent transactions associated with the payment account.

[0284] At block 1004, the electronic device detects a second payment transaction using the electronic device that is associated with the payment account. For example, the payment transaction may be an NFC payment transaction using the electronic device (e.g., as shown and described in FIGS. 7A-7O and 8A-8B) or a payment transaction using an application or website accessed on the electronic device (e.g., as shown and described in FIGS. 11A-11N and 12A-12C). In one embodiment, the payment account is linked to the electronic device.

[0285] In block 1006, in response to detecting the second payment transaction, the device displays second transaction information about the second payment transaction (e.g., the date, time, and location of the second payment transaction, 960 of FIG. 9B ) before receiving information about the second payment transaction from a financial institution involved in the second transaction (e.g., the merchant or financial institution processing the payment transaction). The second transaction information is based on information locally available to the electronic device. For example, if the second payment transaction is detected, the information locally available to the electronic device includes one or more of the date of the second payment transaction, the time of the second payment transaction, or the location of the electronic device. In one embodiment, the second transaction information is based solely on information locally available to the electronic device before receiving information about the second payment transaction from a financial institution involved in the second transaction.

[0286] At block 1010, in some embodiments, a display of second transaction information (e.g., date, time, location of the second payment transaction) for the second payment transaction replaces the display of the first transaction information (e.g., date, time, location, retailer name, charge amount of the first payment transaction). In other words, displaying the second transaction information (e.g., 960 of FIG. 9B) for the second payment transaction includes replacing the display of the first transaction information (e.g., 950 of FIG. 9A) with the display of the second transaction information.

[0287] At block 1012, in some embodiments, the electronic device receives first additional information about the second payment transaction (e.g., 926 in FIG. 9C , the amount of the second payment transaction) from an intermediary involved in the second transaction. The intermediary may be, for example, an institution that provides the operating system for the electronic device or that provides an electronic wallet software application for the electronic device. In some embodiments, the first additional information (e.g., 926 in FIG. 9C ) includes the amount of the second payment transaction (e.g., $425.00). In response to receiving the first additional information about the second payment transaction from the intermediary involved in the second transaction, the electronic device updates second transaction information about the second payment transaction (e.g., 960 in FIG. 9C ) to include the first additional information about the second payment transaction. Thus, this user interface allows a user to easily and efficiently determine the date, time, location, and / or amount of the most recently detected payment transaction (e.g., the second payment transaction) associated with a payment account.

[0288] At block 1014, in some embodiments, the electronic device receives second additional information about the second payment transaction (e.g., dollar amount, name of merchant 920 of FIG. 9D ) from a financial institution (e.g., a bank or merchant) involved in the second transaction. In response to receiving the second additional information about the second payment transaction (e.g., 920 of FIG. 9D ) from a financial institution involved in the second transaction, the device updates a display of second transaction information about the second payment transaction to include the second additional information about the second payment transaction. In some embodiments, the second transaction information is updated when the electronic wallet is refreshed (e.g., by reloading the electronic wallet application or by reopening the electronic wallet application after it has been closed). In some embodiments, the second additional information about the second payment transaction (e.g., 920 of FIG. 9D ) includes the name of the merchant receiving payment as a result of the second payment transaction.

[0289] In block 1016, in some embodiments, the electronic device displays an available credit amount (e.g., how much more can be charged to the account before reaching the account's credit limit, or how much more can be charged to the account before reaching a user-specified quota for the account) above the corresponding representation of the payment account. For example, the available credit amount indicates the amount of credit available for the payment account based on the payment account's credit limit. By displaying the available credit amount, the user can effectively determine how much more money they have left to spend using the payment account.

[0290] In some embodiments, the corresponding representation of the payment account includes a message from the financial institution. The electronic device receives a text message from the financial institution (e.g., 916 in FIG. 9E ) and displays the text message from the financial institution on the corresponding representation of the payment account. For example, the message may be an offer to the user or a notification related to the payment account. The electronic device receives a selection of the text message to be displayed (e.g., tapping on the message to activate the text message), and in response to receiving the selection of the text message to be displayed, the device displays a particular application associated with the financial institution (e.g., a banking application of the financial institution). For example, when the user taps on the text message (e.g., 916 in FIG. 9E ), the electronic device displays a particular software application associated with the financial institution.

[0291] In one embodiment, at block 1018, the electronic device displays an account details affordance (e.g., 906 in FIG. 9F ) on a corresponding representation of the payment account. The electronic device receives a selection of the account details affordance (e.g., 906 in FIG. 9F ), and in response to receiving a selection of the transaction details affordance (e.g., 906 in FIG. 9F ), the electronic device replaces a display of the transaction details of the payment account (e.g., at 930 in FIG. 9G , the device displays the background of the representation of the payment account to reveal payment history and further details) with a display of the corresponding representation of the payment account, as shown in illustrative FIG. 9G . The transaction details (e.g., 930 in FIG. 9G ) include first transaction information (e.g., 950 in FIG. 9G ) and second transaction information (e.g., 960 in FIG. 9G ). For example, when a user taps the transaction details affordance 906, the electronic device displays a list of transaction history for the payment account.

[0292] In some embodiments, the transaction details (e.g., 930 in FIG. 9G ) include a further transaction affordance (e.g., 954 in FIG. 9G ). The electronic device receives a selection of the further transaction affordance (e.g., 954 in FIG. 9G ), and in response to receiving the selection of the further transaction affordance, the device displays third transaction information related to a third payment transaction associated with the payment account (e.g., the device displays more (or older) transactions related to the payment account) as part of the displayed transaction details.

[0293] In some embodiments, the transaction details (e.g., 930 in FIG. 9G ) include a card removal affordance (e.g., 958 in FIG. 9G ). The electronic device receives a selection of the card removal affordance, and in response to receiving the selection of the card removal affordance, the electronic device displays a confirmation request to remove the corresponding representation of the payment account from the electronic wallet. The device receives a confirmation to remove the corresponding representation of the payment account from the electronic wallet (e.g., the user activates the affordance confirming that the payment account should be removed). The electronic device removes the corresponding representation of the payment account from the electronic wallet (e.g., after receiving the confirmation). Thus, the user can initiate the process of removing the link between the electronic device and the payment account by tapping on the card removal affordance.

[0294] In some embodiments, the transaction details (e.g., 930 in FIG. 9G ) include an open application affordance (e.g., 934 in FIG. 9G ) to access a particular application or a download application affordance to download and install the particular application. The electronic device determines whether a particular application (e.g., a software application associated with a payment account, such as a banking application) for accessing details of an associated payment account is installed on the electronic device. In accordance with a determination that the particular application is installed, the electronic device displays an open application affordance to access (e.g., launch or display) the particular application. In some embodiments, in accordance with a determination that the particular application is not installed, the electronic device displays a download application affordance (e.g., instead of the open application affordance) to download and install the particular application on the electronic device. In some embodiments, the electronic device receives a selection of the open application affordance (e.g., a finger tap on the open application affordance), and in response to receiving the selection of the open application affordance, the electronic device completely replaces the display of the transaction details with a display of the particular application, as shown in FIG. 9H . For example, when a user taps the open application affordance (e.g., 934 in FIG. 9G ), the particular application is displayed. When a user taps a download application affordance, the particular application is downloaded or a user interface for downloading the particular application is displayed.

[0295] In one embodiment, the electronic device receives a selection of first transaction information (e.g., 950 of FIG. 9G) of the displayed transaction details (e.g., 930 of FIG. 9G), and in response to receiving the selection of the first transaction information (e.g., 950 of FIG. 9G), the electronic device completely replaces the display of the transaction details (e.g., 930 of FIG. 9G) with a display of a particular application (e.g., 970 of FIG. 9H), as shown in FIG. 9H. The display of the particular application (e.g., 970 of FIG. 9H) includes details (e.g., 972 of FIG. 9H) about the first payment transaction associated with the payment account.

[0296] In some embodiments, the displayed electronic wallet includes a representation of a first stack of card objects and a second stack of card objects, the first stack of card objects being visually separated from the second stack of card objects. The first stack of card objects includes a corresponding representation of a payment account and a second corresponding representation of a second payment account. The second stack of card objects includes membership card objects associated with non-financial institutions (e.g., grocery store membership cards, gym membership cards, coffee shop discount cards).

[0297] It should be noted that the details of the methods described above with respect to method 1000 (e.g., FIGS. 10A-10B and 9A-9H) are also applicable in an analogous manner to the methods described below and above. For example, methods 600, 800, 1200, 1400, 1600, 1800, 2000, and 2200 may include one or more of the features of the various methods described above with reference to method 1000. For example, the electronic wallets, payment accounts, transaction information, transactions, devices, institutions, affordances, and other user interface elements described above with reference to method 1000 optionally have one or more of the features of the electronic wallets, payment accounts, transaction information, transactions, devices, institutions, affordances, and other user interface elements described herein with reference to other methods described herein. For the sake of brevity, these details will not be repeated below.

[0298] The operations described above with reference to the figures may be performed by the components shown in FIGS. 1A-1B. For example, displaying, detecting, and receiving operations may be performed by event sorter 170, event recognizer 180, and event handler 190. Event monitor 171 of event sorter 170 detects contacts on touch-sensitive display 112, and event dispatcher module 174 distributes the event information to application 136-1. Each event recognizer 180 of application 136-1 compares the event information with a respective event definition 186 to determine whether a first contact at a first location on the touch-sensitive surface corresponds to a predetermined event or sub-event, such as the selection of an object on a user interface. When a corresponding predetermined event or sub-event is detected, event recognizer 180 activates event handler 190 associated with the detection of the event or sub-event. Event handler 190 may utilize or invoke data updater 176 or object updater 177 to update application internal state 192. In some embodiments, the event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one skilled in the art how other methods may be implemented based on the components shown in Figures 1A-1B.

[0299] 11A-11N illustrate exemplary user interfaces for conducting a payment transaction, according to some embodiments. The user interfaces in these figures are used to illustrate methods described below, including the method of FIGS. 12A-12C.

[0300] 11A-11B illustrate exemplary user interfaces for initiating a payment transaction, according to some embodiments. In FIG. 11A, electronic device 100 displays a user interface for first application 1102 (e.g., a third-party retailer's application or a website accessed in a web browser). The user interface of first application 1102 includes a payment affordance 1110 (e.g., a submit button for purchasing the contents of a shopping cart) associated with the payment transaction (e.g., making a purchase). For example, payment affordance 1110 may be a submit button for initiating the purchase of the contents of electronic shopping cart 1104. In this example, electronic shopping cart 1104 includes multiple clothing items 1106. In some embodiments, the first application is a third-party application installed on the electronic device. In some embodiments, the first application includes a website accessed by a web browser installed on the electronic device.

[0301] The electronic device detects a selection of the payment affordance 1110 (e.g., a user taps on the payment affordance 1110). In response to detecting the selection of the payment affordance 1110, the electronic device transmits first transaction information (e.g., a description of the items in the shopping cart, the item prices, taxes, subtotal amount, shipping details) regarding a payment transaction with a first application 1102 (e.g., a third-party retailer's application or a website accessed with a web browser) to a second application (e.g., an operating system or an electronic wallet application).

[0302] In some embodiments, the second application is an operating system of the electronic device, and the second application can access an electronic wallet (e.g., the electronic wallet illustrated and described in connection with FIGS. 5A-5I, 6A-6C, 9A-9H, and 10A-10B) that includes the second transaction information. In some embodiments, the second application is a first-party application provided by a provider of the operating system of the electronic device, and the second application can access an electronic wallet (e.g., the electronic wallet illustrated and described in connection with FIGS. 5A-5I, 6A-6C, 9A-9H, and 10A-10B) that includes the second transaction information.

[0303] 11B , in response to detecting selection of payment affordance 1110, the electronic device displays a user interface for second application 1120. The user interface for second application 1120 includes first transaction information received from the first application (e.g., a description of the items in the shopping cart, the item price, tax, subtotal 1132, shipping details) and includes second transaction information provided by the second application (e.g., the operating system or an electronic wallet application) (e.g., an indication of payment account 1124, the name associated with the payment account, billing address, shipping address 1126, and contact information 1130). The second transaction information is not available to the first application (e.g., the user has not provided a credit card, billing address, shipping address, or contact information to the third-party application).

[0304] In some embodiments, displaying the user interface of the second application 1120 (e.g., an operating system or an electronic wallet application) partially obscures the user interface of the first application 1102 (e.g., a third-party retailer's application or a website accessed in a web browser), leaving at least a portion of the user interface of the first application 1102 visible. The second application only partially obscures the user interface of the first application to help the user maintain the context of the transaction. For example, in FIG. 11B , the user interface of second application 1120 (e.g., including displayed items 1124, 1126, 1128, 1130, 1124A, 1126A, 1128A, 1130A, 1132, 1134, 1136, 1138, and 1150) covers the bottom of the display of device 100, leaving the top of the user interface of first application 1102, including a portion of electronic shopping cart 1104 and one of clothing items 1106 (e.g., a navy blue shirt for $85.00), visible.

[0305] In some embodiments, displaying the user interface of the second application 1120 (e.g., an operating system or an electronic wallet application) includes sliding the user interface of the second application 1120 (e.g., an operating system or an electronic wallet application) vertically onto the display from the bottom of the display to partially cover the user interface of the first application 1102 while leaving at least a portion of the user interface of the first application 1102 (e.g., a third-party retailer's application or a website accessed in a web browser) visible. The second application only partially covers the user interface of the first application to help the user maintain the context of the transaction. For example, in the transition between Figures 11A and 11B, the user interface of second application 1120 (e.g., including displayed items 1124, 1126, 1128, 1130, 1124A, 1126A, 1128A, 1130A, 1132, 1134, 1136, 1138, and 1150) slides up from the bottom of the display to cover the bottom of device 100's display, leaving the top of the user interface of first application 1102, including part of electronic shopping cart 1104 and one of clothing items 1106 (e.g., a dark blue shirt for $85.00), visible.

[0306] In some embodiments, the first transaction information includes an amount 1108 (e.g., a shopping cart subtotal or a total amount to be paid) and a default shipping method 1128 (e.g., a shipping method selected by the first application, such as 2-day express, express mail, ground shipping, etc.). In some embodiments, the second transaction information includes a primary account number 1124 associated with a payment account (e.g., an account number stored in an electronic wallet). For example, the payment account may be a payment account linked to the electronic device, as described above. In some embodiments, the second transaction information includes a ship-to address 1126 (e.g., a user's home address) obtained from user contact information, which is stored on the electronic device.

[0307] 11C-11D illustrate exemplary user interfaces for changing options for a payment transaction, according to some embodiments. In some embodiments, the electronic device receives a selection (e.g., a user taps) of a first purchase detail affordance (e.g., a caret, shipping address, shipping method, contact information associated with payment account 1124A) displayed on a user interface 1120 of a second application. The first purchase detail affordance 1124A is associated with a first purchase detail (e.g., a selected payment account, shipping address, shipping method, contact information) of the payment transaction. In response to receiving the selection of the first purchase detail affordance 1124A, the device displays one or more affordances (e.g., displaying various options related to the payment account) for selecting another value related to the first purchase detail of the payment transaction. For example, when the user selects caret 1124A in FIG. 11C (related to the payment account for the first purchase detail), the device displays several payment account options 1160 and 1162 related to the first purchase detail, as shown in FIG. 11D. The currently selected payment account option 1160 is identified by a check mark 1164. The device receives a selection of a different value for the first purchase detail of the payment transaction (e.g., the user selects payment account option 1162), and in response to receiving the selection of the different value, the device updates the second transaction information to include this different value as the first purchase detail. In this manner, the user can change the default payment account 1124 that will be used for the payment transaction.

[0308] Similarly, the user can use the caret 1126A associated with the shipping address, the caret 1128A associated with the shipping method, or the caret 1130A associated with the contact information to change the corresponding purchase details. For example, the user can change the default shipping address 1126 to a default shipping address for a work location rather than the default shipping address for a home. In another example, the user can change the default shipping method 1128 to a different shipping method provided by the first application. In another example, the user can change the default contact information 1130 to a different email address.

[0309] In some embodiments, the first purchase details of a payment transaction (e.g., price, default shipping options) are part of the first transaction information by the first application. In some embodiments, the first purchase details (e.g., payment account, shipping address, shipping method, contact information) are part of the second transaction information. In some embodiments, the first purchase detail is a shipping address. In other embodiments, the first purchase detail is a payment account.

[0310] In some embodiments, the electronic device transfers zip code information from the second application to the first application. In some embodiments, the zip code information is transferred before the transaction is authorized so that the device can provide the user with more accurate shipping cost information before the user decides to authorize the transaction. The first transaction information includes an initial shipping cost based on the zip code information. The device (or the second application) receives updated first transaction information, which includes a shipping cost based on the second transaction information (e.g., the shipping cost is updated based on the user's actual shipping destination selection).

[0311] 11E-11L illustrate exemplary user interfaces for receiving authorization to proceed with a payment transaction, according to some embodiments. In some embodiments, the electronic device receives authorization to proceed with the payment transaction (e.g., receives a passcode for payment or detects a fingerprint for payment).

[0312] 11E-11F illustrate exemplary user interfaces for receiving authorization to proceed with a payment transaction using a fingerprint sensor 702 of an electronic device, according to some embodiments. In FIG. 11E, the device displays a visual indicator 1150A that instructs the user to provide authentication using the fingerprint sensor 702. In some embodiments, the fingerprint sensor 702 is used to receive authorization to proceed with the payment transaction. The device detects a corresponding fingerprint on the fingerprint sensor 702 of the electronic device. In response to detecting the corresponding fingerprint on the fingerprint sensor 702, the device determines whether the fingerprint matches a registered fingerprint that allows authorization of the payment transaction. In accordance with determining that the corresponding fingerprint matches the registered fingerprint, the device authorizes the payment transaction. In accordance with determining that the corresponding fingerprint does not match the registered fingerprint, the device withholds authorization of the payment transaction. In other words, the device does not authorize the payment transaction, which means that authorization to proceed with the payment transaction is still required.

[0313] FIG. 11F illustrates the display of a partially filled visual indicator 1150B, indicating the progress of determining whether the fingerprint matches an enrolled fingerprint. FIG. 11G illustrates an exemplary user interface when fingerprint authentication fails. In some embodiments, following a determination that the corresponding fingerprint does not match an enrolled fingerprint, the device displays an affordance 1154 on the display for receiving permission to proceed with the payment transaction using a payment passcode (rather than the fingerprint sensor). In some embodiments, following a determination that the corresponding fingerprint does not match an enrolled fingerprint, the device displays a visual prompt 1150A on the display instructing the user to place a finger on the fingerprint sensor.

[0314] 11H illustrates an exemplary user interface for authentication using a fingerprint sensor after one or more failed attempts at authentication using the fingerprint sensor. In some embodiments, following a determination that the corresponding fingerprint does not match an enrolled fingerprint, the device determines whether a predetermined number of attempts to receive authorization to proceed with the payment transaction using the fingerprint sensor has been reached. Following a determination that the predetermined number of attempts to receive authorization has been reached, the device requires authorization to proceed with the payment transaction using a payment passcode, as shown in FIG. 11L. In some embodiments, the predetermined number of attempts is three.

[0315] 11K-11L illustrate various exemplary user interfaces for entering a payment passcode, according to some embodiments. In some embodiments, receiving authorization to proceed with the payment transaction includes receiving authorization using a payment passcode. The device receives the payment passcode at the electronic device (e.g., using keypad 740 of FIG. 11L). The device determines whether the payment passcode matches a registered passcode that allows authorization for the payment transaction. In response to determining that the payment passcode matches a registered passcode (e.g., a passcode programmed by the user to unlock the device or make a payment), the device authorizes the payment transaction. For example, in FIG. 11K, a passcode payment affordance 1164 is displayed. To provide authorization using a payment passcode, the user selects passcode payment affordance 1164. After receiving selection of passcode payment affordance 1164, the device displays a user interface for receiving a payment passcode (e.g., keypad 740 of FIG. 11L). The user enters the payment passcode to provide authorization.

[0316] FIG. 11I illustrates an exemplary user interface for indicating that permission has been received. The device displays an exit affordance 1156, indicating that permission to proceed with the payment transaction has been received. In some embodiments, in response to receiving permission to proceed with the payment transaction, the electronic device forwards second transaction information to the first application. In some embodiments, the second transaction information is provided to the first application without giving the first application access to other similar information accessible to the second application (such as the user's contact information, payment account information, or shipping information). For example, only the specific payment account information or shipping information that the user selected to provide to the first application is provided to the first application for use in processing the current payment transaction.

[0317] In some embodiments, the electronic device receives authorization to proceed with the payment transaction (e.g., receives a passcode for payment or detects a fingerprint for payment). In response to receiving the authorization to proceed with the payment transaction, the electronic device forwards the first transaction information and the second transaction information to the first application.

[0318] In some embodiments, the electronic device receives authorization to proceed with the payment transaction (e.g., receives a passcode for payment or detects a fingerprint for payment) before transferring the second transaction information to the first application. Prior to receiving authorization to proceed with the application, the second transaction information is not provided to the first application to protect the user's privacy. The user's privacy is protected because the first application (e.g., a third-party application) cannot access sensitive information in the second transaction information without the user's consent (e.g., by authorization to proceed with the payment transaction).

[0319] 11J illustrates an exemplary user interface for a completed payment transaction. In some embodiments, in response to transferring the first transaction information and the second transaction information from the second application to the first application, the device completes the payment transaction. The first application displays a confirmation that the transaction is completed, for example, as shown in FIG. 11J. The confirmation that the transaction is completed may include, for example, the total payment amount and a confirmation number 1162.

[0320] In some embodiments, a financial institution involved in processing a payment transaction treats the payment transaction as a card-present transaction. Even though a physical credit card was not swiped at the time of purchase, the financial institution treats the payment transaction as a card-present transaction compared to a non-card-present transaction. The financial institution treats the payment transaction as a card-present transaction because the payment transaction was completed securely. For example, the payment transaction is completed securely because the payment account is linked to the corresponding device and completion of the payment transaction requires user permission (e.g., via a fingerprint sensor or passcode entry). As a result of these additional layers of security, the financial institution has confidence that the primary account number used in the payment transaction was provided by the device linked to the payment account.

[0321] In some embodiments, a third application can be used to initiate a second payment transaction using the electronic wallet. The device displays a user interface for the third application (e.g., a third-party retailer's application or another website accessed with a web browser). The third application is distinct from the first application and the second application. The user interface for the third application includes a second payment affordance (e.g., a submit button for purchasing the contents of a shopping cart in the third-party retailer's application or a website accessed with a web browser). The second payment affordance is associated with the second payment transaction (e.g., making another purchase made using the second application). The electronic device detects selection (e.g., a user tapping) of the second payment affordance, and in response to detecting selection of the second payment affordance, the electronic device transfers third transaction information regarding the second payment transaction (e.g., a description of the items in the cart, the item prices, tax, subtotal amount, shipping details) from the third application to the second application. The electronic device displays a second user interface for the second application, where the second user interface for the second application includes third transaction information received from the third application and includes fourth transaction information (e.g., payment account information, name on the payment account, billing address, shipping address, and / or contact information) provided by the second application (e.g., an operating system or an electronic wallet application). The fourth transaction information is not available to the third application. For example, the user has not previously provided the payment account information, name on the payment account, billing address, shipping address, and / or contact information to the third application, so the fourth transaction information is not available to the third application.

[0322] 11M-11N show exemplary user interfaces for configuring electronic wallet settings, according to some embodiments. In some embodiments, the electronic device displays a settings menu 1170. The electronic device receives a selection of a default shipping address to be used as a default for second transaction information. For example, the user selects caret 1184 related to the shipping address. The user can then enter (and thus receive by the electronic device) a default shipping address (e.g., default shipping address) for use in payment transactions.

[0323] In some embodiments, the electronic device receives a selection from among at least a payment account 1174 and a second payment account 1176 displayed in a settings menu 1170. The selection specifies a default payment account to be used for payment transactions. The selection determines the default payment account that will be used for payment transactions.

[0324] In some embodiments, the electronic device receives a default contact information input. This input specifies the default contact information to be used for the payment transaction. For example, a user selects the contact information caret 1186. The user can then input (and thus be received by) the preferred contact information. This input determines the default contact information that will be used for the payment transaction.

[0325] 11N illustrates an exemplary user interface for configuring electronic wallet settings, according to some embodiments. In some embodiments, the electronic device receives a selection of a transaction history display preference (e.g., transaction history display preference switch 1192) displayed in settings menu 1170. The electronic device determines whether the transaction history display preference is on, and in accordance with a determination that the transaction history display preference is on, the device displays a history of payment transactions 1194. For example, the history of payment transactions 1194 may include multiple previously completed payment transactions 1196, 1197, and 1198. In another embodiment, when the electronic device receives a selection of more transaction affordance 1199, the device displays additional previously completed payment transactions.

[0326] In some embodiments, the electronic device receives a selection of a transaction history type preference. The transaction history type preference is displayed in a settings menu. The electronic device determines whether the transaction history type preference is a first type, a second type, or a third type. In accordance with a determination that the transaction history type preference is the first type, the electronic device does not display a history of payment transactions for the payment account. In accordance with a determination that the transaction history type preference is the second type, the electronic device displays a history of payment transactions for the payment account completed using only the electronic device. Thus, for example, if the transaction history type preference is the second type, payment transactions associated with the same payment account but completed using a different device or physical credit card are not displayed. In accordance with a determination that the transaction history type preference is the third type, the electronic device displays a history of payment transactions for the payment account completed using the electronic device and a physical credit card.

[0327] 12A-12C are flow diagrams illustrating a method for conducting a payment transaction, according to some embodiments. Method 1200 is performed on a device having a display (e.g., device 300 of FIG. 3 or portable multifunction device 100 of FIG. 1). Some operations of method 1200 may be combined, some operations may be reordered, and some operations may be omitted.

[0328] As described below, method 1200 provides an intuitive way to create a payment account. This method reduces the cognitive burden on a user when conducting a payment transaction, thereby creating a more efficient human-machine interface. For battery-operated computing devices, allowing users to conduct payment transactions faster and more efficiently conserves power and increases the time between battery charges.

[0329] In block 1202, the electronic device displays a user interface for a first application (e.g., a third-party retailer's application or a website accessed in a web browser, 1102 in FIG. 11A ). The user interface for the first application (e.g., 1102 in FIG. 11A ) includes a payment affordance (e.g., a submit button (1110 in FIG. 11A ) for purchasing the contents of a shopping cart) associated with a payment transaction (e.g., making a purchase). For example, the payment affordance (e.g., 1110 in FIG. 11A ) may be a submit button for initiating the purchase of the contents of an electronic shopping cart (e.g., 1104 in FIG. 11A ).

[0330] At block 1204, in some embodiments, the first application is a third-party application installed on the electronic device. At block 1206, in some embodiments, the first application includes a website accessed by a web browser installed on the electronic device.

[0331] In block 1208, the electronic device detects selection of a payment affordance (e.g., the user taps payment affordance 1110 in FIG. 11A).

[0332] In block 1210, the device performs an action in response to detecting selection of a payment affordance (e.g., 1110 in FIG. 11A ). In block 1212, the electronic device transfers first transaction information (e.g., a description of the items in the shopping cart, the item prices, taxes, subtotal amounts, shipping details) related to the payment transaction from a first application (e.g., a third-party retailer's application or a website accessed in a web browser, 1102 in FIG. 11A ) to a second application (e.g., an operating system or an electronic wallet application).

[0333] At block 1214, in some embodiments, the second application is an operating system of the electronic device, and the second application has access to an electronic wallet (e.g., the electronic wallet illustrated and described in connection with Figures 5A-5I, 6A-6C, 9A-9H, and 10A-10B) containing the second transaction information.

[0334] At block 1216, in some embodiments, the second application is a first-party application provided by the operating system provider of the electronic device, and the second application has access to an electronic wallet (e.g., an electronic wallet illustrated and described in connection with Figures 5A-5I, 6A-6C, 9A-9H, and 10A-10B) containing the second transaction information.

[0335] In block 1218, in response to detecting a selection of a payment affordance (e.g., 1110 of FIG. 11A ), the electronic device displays a user interface for a second application (e.g., 1120 of FIG. 11B ). The user interface for the second application (e.g., 1120 of FIG. 11B ) includes first transaction information received from the first application (e.g., a description of the items in the shopping cart, the item price, tax, subtotal, shipping details) and includes second transaction information provided by the second application (e.g., an operating system or electronic wallet application) (e.g., an indication of the payment account, the name associated with the payment account, the billing address, the shipping address, and contact information). The second transaction information is not available to the first application (e.g., the user has not provided a credit card, billing address, shipping address, or contact information to the third-party application).

[0336] In block 1220, in some embodiments, displaying the user interface of the second application (e.g., an operating system or an electronic wallet application, 1120 of FIG. 11B) partially obscures the user interface of the first application (e.g., a third-party retailer's application or a website accessed in a web browser, 1102 of FIG. 11B), leaving at least a portion of the user interface of the first application visible. The second application only partially obscures the user interface of the first application to help the user maintain the context of the transaction.

[0337] In block 1222, in some embodiments, displaying the user interface of the second application (e.g., an operating system or an electronic wallet application, 1120 of FIG. 11B ) includes sliding the user interface of the second application (e.g., an operating system or an electronic wallet application, 1120 of FIG. 11B ) vertically onto the display from the bottom of the display to partially cover the user interface of the first application, while leaving at least a portion of the user interface of the first application (e.g., a third-party retailer's application or a website accessed in a web browser, 1102 of FIG. 11B ) visible. The user interface of the second application only partially covers the user interface of the first application to help the user maintain the context of the transaction.

[0338] In some embodiments, the first transaction information includes an amount (e.g., a shopping cart subtotal or a total payment amount) and a default shipping method (e.g., a shipping method selected by the first application, such as 2-day express, express mail, ground shipping, etc.). In some embodiments, the second transaction information includes a primary account number associated with a payment account (e.g., an account number stored in an electronic wallet). For example, the payment account may be a payment account linked to the electronic device, as described above. In some embodiments, the second transaction information includes a shipping address (e.g., a user's home mailing address) accessed from user contact information, which is stored on the electronic device.

[0339] At block 1224, in some embodiments, the electronic device receives a selection (e.g., a user taps) of a first purchase detail affordance (e.g., a caret associated with a payment account, a shipping address, a shipping method, contact information) displayed on a user interface of a second application (1120 in FIG. 11C ). The first purchase detail affordance (1124A in FIG. 11C ) is associated with a first purchase detail (e.g., a selected payment account, a shipping address, a shipping method, contact information) of the payment transaction. In response to receiving the selection of the first purchase detail affordance (1124A in FIG. 11C ), the device displays one or more affordances for selecting another value for the first purchase detail of the payment transaction (e.g., displays various options related to the payment account). The device receives a selection of another value for the first purchase detail of the payment transaction (e.g., the user selects the payment account option 1162), and in response to receiving the selection of the another value, the device updates the second transaction information to include the another value as the first purchase detail. Thus, a user can change the default payment account that will be used for payment transactions.

[0340] At block 1226, in some embodiments, the first purchase details of the payment transaction (eg, price, default shipping options) are part of the first transaction information by the first application.

[0341] At block 1228, in some embodiments, the first purchase detail (e.g., payment account, shipping address, shipping method, contact information) is part of the second transaction information. In some embodiments, the first purchase detail is a shipping address. In some embodiments, the first purchase detail is a payment account.

[0342] In some embodiments, the electronic device transfers zip code information from the second application to the first application. In some embodiments, the zip code information is transferred before the transaction is authorized so that the device can provide the user with more accurate shipping cost information before the user decides to authorize the transaction. The first transaction information includes a first shipping cost based on the zip code information. The device (or the second application) receives updated first transaction information, which includes a shipping cost based on the second transaction information (e.g., the shipping cost is updated based on the user's actual selected shipping destination).

[0343] At block 1230, in some embodiments, the electronic device receives authorization to proceed with the payment transaction (e.g., receives a passcode for payment or detects a fingerprint for payment).

[0344] At block 1232, in some embodiments, receiving authorization to proceed with the payment transaction uses a fingerprint sensor. The device detects a corresponding fingerprint on the fingerprint sensor of the electronic device. In response to detecting the corresponding fingerprint on the fingerprint sensor, the device determines whether the fingerprint matches a registered fingerprint, which allows authorization of the payment transaction. In accordance with determining that the corresponding fingerprint matches the registered fingerprint, the device authorizes the payment transaction. In accordance with determining that the corresponding fingerprint does not match the registered fingerprint, the device withholds authorization of the payment transaction. In other words, the device does not authorize the payment transaction, which means that authorization to proceed with the payment transaction is still required.

[0345] In some embodiments, following a determination that the corresponding fingerprint does not match the enrolled fingerprint, the device displays an affordance on the display (e.g., 1154 in FIG. 11G) for receiving permission to proceed with the payment transaction using a payment passcode (rather than the fingerprint sensor). In some embodiments, following a determination that the corresponding fingerprint does not match the enrolled fingerprint, the device displays a visual prompt on the display (e.g., 1150A in FIG. 11G) instructing the user to place a finger on the fingerprint sensor.

[0346] In some embodiments, in response to a determination that the corresponding fingerprint does not match the enrolled fingerprint, the device determines whether a predetermined number of attempts have been made to receive authorization to proceed with the payment transaction using the fingerprint sensor. In response to a determination that the predetermined number of attempts has been made, the device requests authorization to proceed with the payment transaction using a payment passcode. In some embodiments, the predetermined number of attempts is three.

[0347] In block 1234, in some embodiments, receiving authorization to proceed with the payment transaction includes receiving authorization using a payment passcode. The device receives the payment passcode at the electronic device (e.g., using keypad 740 of FIG. 11L). The device determines whether the payment passcode matches a registered passcode that allows authorization of the payment transaction. In response to determining that the payment passcode matches a registered passcode (e.g., a passcode programmed by a user to unlock the device or make payments), the device authorizes the payment transaction.

[0348] At block 1236, in some embodiments, the device performs a series of actions in response to receiving authorization to proceed with the payment transaction. At block 1238, in some embodiments, the electronic device forwards second transaction information to the first application. In some embodiments, the second transaction information is provided to the first application without giving the first application access to other similar information accessible to the second application (such as the user's contact information, payment account information, or shipping information). For example, only the specific payment account information or shipping information that the user chose to provide to the first application is provided to the first application for use in processing the current payment transaction.

[0349] At block 1240, in some embodiments, in response to receiving authorization to proceed with the payment transaction, the electronic device forwards the first transaction information and the second transaction information to the first application.

[0350] In some embodiments, the electronic device receives authorization to proceed with the payment transaction (e.g., receives a passcode for payment or detects a fingerprint for payment) before transferring the second transaction information to the first application. Prior to receiving authorization to proceed with the application, the second transaction information is not provided to the first application to protect the user's privacy. The user's privacy is protected because the first application (e.g., a third-party application) cannot access sensitive information in the second transaction information without the user's consent (e.g., by authorization to proceed with the payment transaction).

[0351] In some embodiments, in response to transferring the first transaction information and the second transaction information from the second application to the first application, the device completes the payment transaction.

[0352] At block 1242, in some embodiments, a financial institution associated with processing the payment transaction treats the payment transaction as a card-present transaction. Even though a physical credit card was not swiped at the time of purchase, the financial institution treats the payment transaction as a card-present transaction compared to a card-not-present transaction. The financial institution treats the payment transaction as a card-present transaction because the payment transaction was completed securely. For example, the payment transaction is completed securely because the payment account is linked to the corresponding device and completion of the payment transaction requires user permission (e.g., via a fingerprint sensor or passcode entry). As a result of these additional layers of security, the financial institution has confidence that the primary account number used in the payment transaction was provided by the device linked to the payment account.

[0353] At block 1244, in some embodiments, a third application may be used to initiate a second payment transaction using the electronic wallet. The device displays a user interface for the third application (e.g., a third-party retailer's application or another website accessed with a web browser). The third application is distinct from the first application and the second application. The user interface for the third application includes a second payment affordance (e.g., a submit button for purchasing the contents of a shopping cart in the third-party retailer's application or a website accessed with a web browser). The second payment affordance is associated with a second payment transaction (e.g., making another purchase made using the second application). The electronic device detects selection (e.g., a user tapping) of the second payment affordance, and in response to detecting selection of the second payment affordance, the electronic device transfers third transaction information related to the second payment transaction (e.g., a description of the items in the cart, the item prices, tax, subtotal amount, shipping details) from the third application to the second application. The electronic device displays a second user interface for the second application, where the second user interface for the second application includes third transaction information received from the third application and includes fourth transaction information (e.g., payment account information, name on the payment account, billing address, shipping address, and / or contact information) provided by the second application (e.g., an operating system or an electronic wallet application). The fourth transaction information is not available to the third application. For example, the user has not previously provided the payment account information, name on the payment account, billing address, shipping address, and / or contact information to the third application, so the fourth transaction information is not available to the third application.

[0354] In some embodiments, the electronic device displays a settings menu (e.g., 1170 in FIG. 11M). The electronic device receives a selection of a default shipping address to be used as the default for the second transaction information.

[0355] In some embodiments, the electronic device receives a selection from among at least a payment account (e.g., 1174 of FIG. 11M) and a second payment account (e.g., 1176 of FIG. 11M) displayed in a settings menu (e.g., 1170 of FIG. 11M). The selection specifies a default payment account to be used for payment transactions. The selection determines the default payment account that will be used for payment transactions.

[0356] In some embodiments, the electronic device receives a default contact information input, which specifies the default contact information to be used for payment transactions.

[0357] In some embodiments, the electronic device receives a selection of a transaction history display preference (e.g., transaction history display preference switch 1192 in FIG. 11N ) displayed in a settings menu (e.g., 1170 in FIG. 11N ). The electronic device determines whether the transaction history display preference is on, and in accordance with a determination that the transaction history display preference is on, the device displays a payment transaction history (e.g., 1194 in FIG. 11N ). For example, the payment transaction history (e.g., 1194 in FIG. 11N ) can include multiple already completed payment transactions (e.g., 1196, 1197, and 1198 in FIG. 11N ). In another embodiment, when the electronic device receives a selection of a more transaction affordance (e.g., 1199 in FIG. 11N ), the device displays additional already completed payment transactions.

[0358] In some embodiments, the electronic device receives a selection of a transaction history type preference. The transaction history type preference is displayed in a settings menu. The electronic device determines whether the transaction history type preference is a first type, a second type, or a third type. In accordance with a determination that the transaction history type preference is the first type, the electronic device does not display a history of payment transactions for the payment account. In accordance with a determination that the transaction history type preference is the second type, the electronic device displays a history of payment transactions for the payment account completed using only the electronic device. Thus, for example, if the transaction history type preference is the second type, payment transactions associated with the same payment account but completed using a different device or physical credit card are not displayed. In accordance with a determination that the transaction history type preference is the third type, the electronic device displays a history of payment transactions for the payment account completed using the electronic device and a physical credit card.

[0359] It should be noted that the method details described above with respect to method 1200 (e.g., FIGS. 12A-12C and 11A-11N) are also applicable in an analogous manner to the methods described above. For example, methods 600, 800, 1000, 1400, 1600, 1800, 2000, and 2200 may include one or more of the features of the various methods described above with reference to method 1200. For example, the applications, affordances, transaction information, electronic wallets, transactions, purchase details, permissions, institutions, devices, and user interface elements described above with reference to method 1200 optionally have one or more of the features of the applications, affordances, transaction information, electronic wallets, transactions, purchase details, permissions, institutions, devices, and user interface elements described herein with reference to other methods described herein. For brevity, these details will not be repeated below.

[0360] The operations of the above-described information processing methods can be implemented by executing one or more functional modules of an information processing device, such as a general-purpose processor or an application-specific chip. These modules, combinations of these modules, and / or their combination with general hardware (e.g., as described above with respect to Figures 1A, 1B, and 3) are all included within the scope of protection of the present invention.

[0361] The operations described above with reference to the figures may be performed by the components shown in FIGS. 1A-1B. For example, the detecting, displaying, and determining operations may be performed by event sorter 170, event recognizer 180, and event handler 190. Event monitor 171 of event sorter 170 detects contacts on touch-sensitive display 112, and event dispatcher module 174 distributes the event information to application 136-1. Each event recognizer 180 of application 136-1 compares the event information with a respective event definition 186 to determine whether a first contact at a first location on the touch-sensitive surface corresponds to a predetermined event or sub-event, such as the selection of an object on a user interface. When a corresponding predetermined event or sub-event is detected, event recognizer 180 activates event handler 190 associated with the detection of the event or sub-event. Event handler 190 may utilize or invoke data updater 176 or object updater 177 to update application internal state 192. In some embodiments, the event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one skilled in the art how other processes can be implemented based on the components shown in Figures 1A-1B.

[0362] 13A-13D illustrate exemplary user interfaces for selecting a payment account from among available payment accounts using an electronic device, according to some embodiments. The user interfaces in these figures are used to illustrate methods described below, including the method of FIG. 14.

[0363] 13A-13B illustrate exemplary techniques for making payments for payment transactions. In these examples, payment is provided using a near field communication radio, such as an NFC radio. The NFC standard is related to radio frequency identification (RFID) standards and describes communication protocols for transferring information, such as payments, between two devices. However, it should be understood that other communication standards and technologies can also be used.

[0364] Device 100 (and device 300) may include near-field communication circuitry, such as a near-field communication radio. Thus, device 100 can communicate wirelessly with external devices, such as an NFC-enabled contactless payment transaction terminal 1300, using near-field communication.

[0365] In Figure 13A, an NFC-enabled contactless payment transaction terminal 1300 creates a venue 1302. For example, an NFC-enabled device entering venue 1302 can use NFC to communicate with contactless payment transaction terminal 1300. In Figure 13A, electronic device 100 is not located at venue 1302. Contactless payment transaction terminal 1300 may be part of a payment system (e.g., a cash register) installed in a retail store for processing payment transactions such as purchasing products and services.

[0366] In Figure 13B, a user places electronic device 100 within field 1302. The electronic device detects the presence of field 1302 (e.g., an NFC-enabled RF field) generated by a contactless payment transaction terminal 1300 (e.g., an NFC-enabled payment transaction terminal) via its near field communication radio. In some embodiments, the electronic device detects a communication initiation signal from the field and the contactless payment transaction terminal 1300. The device communicates with the contactless payment transaction terminal 1300 to authorize the payment transaction.

[0367] In some embodiments, a user can make a purchase from anywhere access to a network, such as the Internet, is available. For example, a user can access a software application on electronic device 100 to initiate communication with a remote payment processing terminal using an Internet connection to make a payment transaction.

[0368] In some embodiments, the electronic device is device 100. In some embodiments, the electronic device is device 300. The device has a display (e.g., 112, 340), a processor (e.g., 120, 310), and memory (e.g., 102, 370) that stores one or more programs for execution by the processor.

[0369] 13C illustrates an exemplary user interface including a representation of multiple payment accounts linked to an electronic device (e.g., 100). The multiple payment accounts include a first payment account (e.g., 1304) and a second payment account (e.g., 1306), where the second payment account is different from the first payment account (e.g., 1304).

[0370] The device receives a payment transaction request for a payment transaction, where a first payment account (e.g., 1304) and a second payment account (e.g., 1306) are both available to make payment for the payment transaction. For example, detection of field 1302 and / or a communication initiation signal may be the payment transaction request. In another example, the payment transaction request is for the user to authorize payment. In another example, the payment transaction request is for the user to activate an affordance to review a purchase summary (e.g., a list of purchased items and payment methods) before authorizing payment.

[0371] In response to receiving the payment transaction request, the device obtains payment account selection information (e.g., current location information, current time, current calendar event schedule). In accordance with determining that the criteria for a first payment transaction are met based on the payment account selection information, the device makes payment in the payment transaction using a first payment account (e.g., 1304). For example, the device transmits the primary account number of a first credit card to a contactless payment transaction terminal or an online payment processor. In accordance with determining that the criteria for a second payment transaction are met based on the payment account selection information, the device makes payment in the payment transaction using a second payment account (e.g., 1306). For example, the device transmits the primary account number of a second credit card to a contactless payment transaction terminal or an online payment processor.

[0372] 13D illustrates an exemplary user interface that is displayed after a payment has been made. In this example, the first payment transaction criteria have been met. Thus, the device has made the payment in the payment transaction using the first payment account (e.g., 1304).

[0373] According to some embodiments, the different payment accounts have different primary account numbers. According to some embodiments, a first payment account is associated with a first primary account number and a second payment account is associated with a second primary account number that is different from the first primary account number. Making a payment in a payment transaction includes authorizing the payment using the corresponding primary account number. For example, when using the first payment account (e.g., 1304), the device transmits the first primary account number to the contactless payment transaction terminal (1300) or an online payment processor. In another example, when using the second payment account (e.g., 1306), the device transmits the second primary account number to the contactless payment transaction terminal (1300) or an online payment processor.

[0374] According to some embodiments, the payment account selection information includes the current location of the electronic device. For example, when the device user is in their home country, the device may provide a first payment account (e.g., 1304), and when the device user is traveling to a second country, the device may provide a second payment account (e.g., 1306). In some examples, this allows the device to automatically select the appropriate payment account based on the device's location, thereby reducing the need for the user to navigate a complex user interface to select among various payment accounts.

[0375] According to some embodiments, the payment account selection information includes the types of payment accounts accepted. For example, the device offers a primary American Express account if American Express cards are accepted; if American Express is not accepted, selects a primary MasterCard account if MasterCard is accepted; or if American Express and MasterCard are not accepted, selects a primary Visa account if Visa cards are accepted.

[0376] According to some embodiments, the payment account selection information includes a date or day of the week, for example, which allows the device to use a personal credit card account for work expenses during the day on weekdays and a personal credit card account for personal expenses in the evenings and on weekends.

[0377] According to some embodiments, the payment account selection information includes currently scheduled electronic calendar events, for example, the device uses a corporate credit card account during scheduled business events such as business lunches and business trips, and a personal credit card account at other times.

[0378] According to some embodiments, the payment account selection information includes identification of other devices within a defined proximity of the electronic device. For example, if the user is at a restaurant and the user's spouse's phone is detected within the defined proximity, the device will use the credit card or payment account associated with the joint account. If the user is at a restaurant with a colleague, boss, or subordinate, the device will use the company credit card or payment account. If the user is at a restaurant without anyone they know nearby, the device will use their personal credit card or payment account.

[0379] According to some embodiments, the payment account selection information includes an identification of the retailer (or type of retailer) requesting the payment transaction. For example, the device may use a first payment account (e.g., 1304) at a first retailer and a second payment account (e.g., 1306) at another retailer. In another example, the device may use a credit card or payment account associated with automobile maintenance at a gas station or repair shop and a credit card or payment account associated with purchasing groceries at a grocery store.

[0380] According to some embodiments, the payment account selection information includes one or more items to be purchased as part of the payment transaction. For example, a device uses a first payment account (e.g., 1304) to purchase gasoline at a gas station and a second payment account (e.g., 1306) to purchase food in a different purchase transaction at the same gas station.

[0381] According to some embodiments, the payment account selection information includes one or more promotional materials associated with one or more of the payment accounts. For example, if the device receives information indicating that a promotional discount will be applied to a particular type of purchase or purchase at a particular retailer with an American Express card, a primary American Express account is selected.

[0382] According to some embodiments, the device provides a notification (e.g., audio, tactile, or both) on the electronic device based on the criteria met for the payment transaction. The notification indicates the corresponding payment account to be used to make the payment in the payment transaction. For example, the device provides a custom tactile or audio alert for each different payment account to inform the user which payment account was selected. In some embodiments, each time the device selects a payment account different from the default payment account, the device provides the same tactile and / or audio alert. This notifies the user that a payment account other than the default payment account will be used for the payment transaction.

[0383] According to some embodiments, the first payment account is a default payment account and the second payment account is different from the default payment account, e.g., the criteria for the first payment transaction include one or more criteria that are met if there are no conditions to override the default payment account, and the criteria for the second payment transaction include one or more criteria that are met if there are conditions to override the default payment account in favor of the second payment account.

[0384] According to some embodiments, the device receives an identification of a first payment account as a default payment account from an electronic wallet that includes a representation of multiple payment accounts (e.g., 1304, 1306, 1308). For example, the device includes an electronic wallet application that includes information about the multiple payment accounts and indicates which of the multiple payment accounts is the default payment account.

[0385] According to some embodiments, the first payment account (e.g., 1304) is associated with a first credit card and the second payment account (e.g., 1306) is associated with a second credit card. For example, the first payment account (e.g., 1304) is linked to a credit card at AA Bank, and payments made using the first payment account appear on the same revolving credit account as the first credit card at AA Bank.

[0386] 14 is a flow diagram illustrating a method 1400 for selecting a payment account from among available payment accounts, according to some embodiments. Method 1400 is performed on a device (e.g., 100, 300) having a display (e.g., 112, 340), a processor (e.g., 120, 310), and memory (e.g., 102, 370) storing one or more programs for execution by the processor. Some operations of method 1400 may be combined, some operations may be reordered, and some operations may be omitted.

[0387] As described below, method 1400 provides an intuitive way to select a payment account from among available payment accounts when making a payment. This method reduces the cognitive burden on the user when making a payment, thereby creating a more efficient human-machine interface. For battery-operated computing devices, allowing payments to be made faster and more efficiently conserves power and increases the time between battery charges.

[0388] At block 1402, multiple payment accounts are linked to the electronic device. The multiple payment accounts include a first payment account (e.g., 1304) and a second payment account (e.g., 1306), where the second payment account is different from the first payment account.

[0389] A payment transaction request for a payment transaction is received in block 1404. A first payment account (e.g., 1305) and a second payment account (e.g., 1306) are both available to make payments for the payment transaction.

[0390] In response to receiving a payment transaction request at block 1406, payment account selection information (eg, current location information, current time, current calendar event schedule) is obtained at block 1408.

[0391] In block 1410, based on the payment account selection information, payment in the payment transaction is made using the first payment account in accordance with a determination that the first payment transaction criteria is met (e.g., the device transmits the primary account number of the first credit card to a contactless payment transaction terminal or online payment processor).

[0392] In block 1412, based on the payment account selection information, payment in the payment transaction is made using the second payment account in accordance with a determination that second payment transaction criteria are met (e.g., the device transmits the primary account number of the second credit card to a contactless payment transaction terminal or online payment processor).

[0393] It should be noted that the details of the methods described above with respect to method 1400 (e.g., FIG. 14 and FIGS. 13A-13D) are also applicable in an analogous manner to the methods described below and above. For example, methods 600, 800, 1000, 1200, 1600, 1800, 2000, and 2200 may include one or more of the features of the various methods described above with reference to method 1400. For example, the payment accounts, transactions, information, criteria, devices, and user interface elements described above with reference to method 1400 optionally include one or more of the features of the payment accounts, transactions, information, criteria, devices, and user interface elements described herein with reference to other methods described herein. For the sake of brevity, these details will not be repeated below.

[0394] 15 illustrates exemplary user interfaces for displaying an indication of a digital item associated with a purchase item using an electronic device (e.g., 100, 300), according to some embodiments. The techniques and user interfaces in these figures are used to illustrate methods described below, including the method of FIG. 16.

[0395] FIG. 15 illustrates an exemplary user interface indicating that a payment transaction has been authorized for a purchase item (e.g., a T1000 video game console 1502). A device (e.g., 100) authorizes the payment transaction for the purchase item (e.g., goods or real-world services) using a payment account (e.g., 1504) linked to the electronic device. The purchased item is selected from a set including physical goods and real-world services. For example, a user purchases a product (e.g., a T1000 video game console) at a retail store (e.g., Tim's Toy Store) using a near-field communication radio. After authorizing the payment transaction, the device determines that the purchase item is related to a digital item (e.g., a digital good or service, such as a controller software application for the T1000 video game console), but the digital item differs from the purchase item, and the device displays an indication of the digital item (e.g., affordance 1506) associated with the purchase item. For example, the methods described in connection with FIGS. 14 and 13A-13D can be used to determine the payment account used to purchase the product.

[0396] According to some embodiments, the digital item (controller software application) was not part of the payment transaction (e.g., it was not purchased or licensed as part of the payment transaction).

[0397] According to some embodiments, payment transactions are authorized based on communication (e.g., via NFC technology) with a payment terminal at a physical retail location, such as a brick-and-mortar store, concert venue, or other physical store.

[0398] According to some embodiments, displaying an indication of the digital item includes displaying a prompt to download the digital item (e.g., prompt 1508). For example, the device prompts the user to download an application to control a media playback device purchased by the user. In another example, the device prompts the user to install a concert venue application or download a map of the concert venue to a document reader when a concert ticket is purchased.

[0399] According to some embodiments, while displaying a prompt (e.g., 1508) to download the digital item, the device detects selection of a confirmation affordance (e.g., affordance 1506). In response to detecting selection of the confirmation affordance (e.g., 1506), the device downloads the digital item to the device. Optionally, the device also installs the digital item on the device. For example, the device prompts the user to download an application for controlling a media playback device purchased by the user. In another example, the device prompts the user to install a concert venue application or download a map of the concert venue to a document reader if concert tickets are purchased.

[0400] According to some embodiments, while displaying the prompt, the device detects selection of a cancel affordance (e.g., 1510). In response to detecting selection of the cancel affordance (e.g., 1510), the device refrains from downloading the digital item to the device. For example, the user indicates a desire not to download the digital item.

[0401] According to some embodiments, displaying an indication of the digital item includes downloading the digital item to the device, for example, the device downloads an application for controlling a media playback device purchased by the user using the electronic device, or, if tickets to a concert were purchased using the electronic device, the device downloads a map of the concert venue to a document reader.

[0402] According to some embodiments, the digital item is an advertisement or coupon displayed on the display of the electronic device.

[0403] According to some embodiments, the indication of the digital item is displayed in response to authorization of a payment transaction completed by the device (e.g., not in response to receiving a confirmatory communication from the retailer). For example, the digital item is not a confirmatory email or text message from the retailer. In response to authorization of the payment transaction, the device generates a notification at the device based on the payment transaction. For example, a notification is generated even if the retailer does not have the capability to send a communication to the device (e.g., a retailer that does not have an email address or phone number associated with the device).

[0404] According to some embodiments, the determination of the digital item associated with the purchased item is based on information from a manufacturer of the purchased item, which is different from the sel...

Claims

1. In an electronic device having a display, receiving a request to link a payment account associated with a credit card to a corresponding device, the request including information about the credit card; In response to receiving the request, determining whether further verification is required to link the payment account to the corresponding device; in accordance with a determination that no further verification is required to link the payment account to the corresponding device, linking the payment account to the corresponding device and providing an indication that the payment account has been linked to the corresponding device; In accordance with a determination that further verification is required to link the payment account to the corresponding device, providing an indication that further verification is required to link the payment account to the corresponding device; A method comprising:

2. The method of claim 1 , wherein the indication that further verification is required to link the payment account to the corresponding device comprises an alphanumeric visual indicator displayed on the display of the electronic device.

3. 10. The method of claim 1, wherein the indication that further verification is required to link the payment account to the corresponding device includes a visual indication of additional steps a user must take to link the payment account to the corresponding device.

4. In accordance with the determination that further verification is required to link the payment account to the corresponding device, displaying a plurality of communication method affordances on the display, each communication method affordance being associated with a corresponding communication method for verification communication; The method of claim 1 , wherein the plurality of communication method affordances is based on communications received from the financial institution.

5. In accordance with the determination that further verification is required to link the payment account to the corresponding device, displaying a plurality of communication method affordances on the display, each communication method affordance being associated with a corresponding communication method for verification communication; The method of claim 1 , wherein the display of the plurality of communication method affordances is based on locally stored contact information, the locally stored contact information including the corresponding communication methods.

6. In accordance with the determination that further verification is required to link the payment account to the corresponding device, receiving a selection of a communication method affordance from the plurality of communication method affordances; and in response to receiving the selection of the communication method affordance, sending an indication of the corresponding communication method of the selected communication method affordance to the financial institution; The method of claim 4 or 5, wherein the verification communication is based on the communication method affordance.

7. In accordance with the determination that further verification is required to link the payment account to the corresponding device, receiving a verification communication from a financial institution associated with said payment account; 7. The method of claim 1, further comprising: wherein the verification communication is for verifying linking of the payment account to the corresponding device.

8. In accordance with the determination that further verification is required to link the payment account to the corresponding device, receiving a request from a user to initiate a verification communication with the financial institution; In response to receiving the request, initiating the verification communication with the financial institution associated with the payment account; 7. The method of claim 1, further comprising: wherein the verification communication is for verifying linking of the payment account to the corresponding device.

9. receiving a notification at the electronic device, the notification including a verification code for linking the payment account to the corresponding device; In response to receiving the notification including the verification code at the electronic device, linking the payment account to the corresponding device; The method of claim 1 , further comprising:

10. 10. The method of claim 1, further comprising displaying a notification on the device indicating that the payment account has been linked to the corresponding device, wherein the displaying comprises displaying a confirmation on the device indicating that the payment account has been linked to the corresponding device.

11. receiving a user input requesting a secondary verification code for linking the payment account to the corresponding device; In response to receiving the input requesting the secondary verification code, sending a request to the financial institution requesting the secondary verification code; 10. The method of claim 1, further comprising:

12. receiving a secondary notification at the electronic device that includes the secondary verification code for linking the payment account to the corresponding device; In response to receiving the secondary notification at the electronic device, the secondary notification including the secondary verification code, linking the payment account to the corresponding device and displaying a confirmation on the device indicating that the payment account has been linked to the corresponding device; 11. The method of any one of claims 1 to 8 and 10, further comprising:

13. 13. The method of claim 1, further comprising receiving a primary account number from the financial institution for use in authorizing payments from the payment account using the compatible device, the primary account number being different from the account number displayed on the credit card.

14. 14. The method of claim 13, further comprising assigning the primary account number to the corresponding device, the primary account number being different from the account number displayed on the credit card.

15. receiving the request to link the payment account displaying on the display a credit card import affordance for importing at least partial credit card information from a remote server; receiving a user selection of the credit card import affordance; in response to receiving the user selection of the credit card import affordance to import credit card information from the remote server; displaying a credit card details screen, the credit card details screen including an indication of the credit card number of the credit card associated with the payment account and including a security code entry field for receiving a security code; receiving a corresponding security code in the security code input field through user input; determining the validity of the credit card using verification based on the credit card number and the corresponding security code; 15. The method of any one of claims 1 to 14, comprising:

16. receiving the request to link the payment account displaying, via user input at the electronic device, a credit card input affordance on the display for receiving credit card information; receiving a user selection of the credit card input affordance; in response to receiving the user selection of the credit card input affordance for inputting credit card information; displaying a credit card details screen, the credit card details screen including an account entry field for receiving a credit card number associated with the payment account and a security code entry field for receiving a security code; receiving a corresponding credit card number in the account input field and a corresponding security code in the security code input field according to user input; determining the validity of the credit card using verification based on the corresponding credit card number and the corresponding security code; 16. The method of any one of claims 1 to 15, comprising:

17. 17. The method of claim 16, wherein the credit card detail screen includes a displayed visual graphical representation of the credit card associated with the payment account, the graphical representation including a background image of the credit card associated with the payment account.

18. The method of claim 1 , wherein the corresponding device is a second electronic device separate from the electronic device.

19. The method of claim 1 , wherein the corresponding device is an electronic device, and the electronic device is a mobile communication device.

20. determining whether the corresponding device is configured to require an unlock authorization to unlock the corresponding device; displaying, on the display, an unlock authentication configurator for configuring the corresponding device to require unlock authorization to unlock the corresponding device in accordance with determining that the corresponding device is not configured to require unlock authorization; and 20. The method of any one of claims 1 to 19, further comprising:

21. receiving a second request to link a second payment account associated with a second credit card to the corresponding device, the second request including information about the second credit card; linking the second payment account to the corresponding device and providing an indication that the second payment account has been linked to the corresponding device; receiving a selection from among at least the payment account and the second payment account, the selection specifying the default payment account to be used for payment transactions; 21. The method of any one of claims 1 to 20, further comprising:

22. An electronic device having a display and a short-range communication radio, detecting, by said near field communication radio, the presence of a field created by a contactless payment transaction terminal; determining whether authorization to proceed with a payment transaction is provided in response to detecting the presence of the venue generated by the contactless payment transaction terminal; proceeding with the payment transaction with the contactless payment transaction terminal in accordance with a determination that authorization to proceed with the payment transaction has been provided; and in accordance with a determination that authorization to proceed with the payment transaction has not been provided, providing an indication requesting authorization to proceed with the payment transaction; A method comprising:

23. 23. The method of claim 22, wherein the user interface of the electronic device is locked upon detecting the presence of the generated field and the display of the electronic device is turned off upon detecting the presence of the generated field, the method further comprising turning on the display in response to detecting the presence of the generated field by the contactless payment transaction terminal.

24. if, after detecting the presence of the field generated by the contactless payment transaction terminal, permission to proceed with the payment transaction is not provided; detecting by the near field radio that the device is no longer within range of the field generated by the contactless payment transaction terminal; displaying a plurality of payment card affordances associated with different payment accounts in response to detecting that the device is no longer within range of the venue; receiving authorization to proceed with the payment transaction for a predetermined time using one of the payment accounts; 24. The method of claim 22 or 23, further comprising:

25. providing an indication that a default payment card affordance of the plurality of payment card affordances has been selected as a default payment account; 25. The method of claim 24, wherein the default primary account number associated with the default payment card affordance is selected for use in the payment transaction.

26. receiving a selection of another payment card affordance of the plurality of payment card affordances, the other payment card affordance being associated with a corresponding other primary account number; In response to receiving the selection of the alternative payment card affordance, selecting the corresponding alternative primary account number for use in the payment transaction; 26. The method of claim 24 or 25, further comprising:

27. 27. The method of any one of claims 22 to 26, further comprising receiving permission to proceed with the payment transaction for a predetermined time in accordance with the determination that permission to proceed with the payment transaction has not been provided.

28. 24. The method of claim 22 or 23, further comprising receiving permission to proceed with a payment transaction for a predetermined time before detecting the presence of the field generated by the contactless payment transaction terminal.

29. 29. The method of any one of claims 24 and 27 or 28, wherein the predetermined time is based on a current location of the electronic device.

30. 30. The method of any one of claims 24 and 27-29, wherein the predetermined time is based on a credit score associated with the payment account.

31. 31. The method of any one of claims 24 and 27-30, wherein the predetermined time is user configurable.

32. While the device is within the field generated by the contactless payment transaction terminal, detecting a corresponding fingerprint on a fingerprint sensor of the electronic device; responsive to detecting the corresponding fingerprint on the fingerprint sensor, determining whether the fingerprint matches a registered fingerprint to allow authorization of a payment transaction; authorizing the payment transaction in accordance with a determination that the corresponding fingerprint matches the enrolled fingerprint; withholding authorization of the payment transaction in accordance with a determination that the corresponding fingerprint does not match the enrolled fingerprint; 32. The method of any one of claims 22 to 31, further comprising:

33. in response to a determination that the corresponding fingerprint does not match the enrolled fingerprint; playing a failure audio alert through a speaker on the electronic device indicating that permission to proceed with the payment transaction was not provided.

33. The method of claim 32, further comprising:

34. determining whether the payment transaction was successfully completed in accordance with the determination that authorization to proceed with the payment transaction was provided; and In response to determining that the payment transaction has been successfully completed, playing, at the electronic device, a success audio alert indicating that the payment transaction has been successfully completed; 34. The method of any one of claims 22 to 33, further comprising:

35. 35. The method of claim 33 or 34, wherein the failure audio alert and the success audio alert are different.

36. in response to a determination that the corresponding fingerprint does not match the enrolled fingerprint; generating a tactile failure alert at the electronic device indicating that authorization to proceed with the payment transaction was not provided.

36. The method of any one of claims 22 to 35, further comprising:

37. determining whether the payment transaction was successfully completed in accordance with the determination that authorization to proceed with the payment transaction was provided; and In response to determining that the payment transaction has been successfully completed, generating, at the electronic device, a success tactile alert indicating that the payment transaction has been successfully completed; 35. The method of any one of claims 32 to 34, further comprising:

38. 38. The method of any one of claims 35 to 37, wherein the failure tactile alert and the success tactile alert are different.

39. 39. The method of claim 38, wherein the failure tactile alert is of greater duration and intensity than the success tactile alert.

40. in response to a determination that the corresponding fingerprint does not match the enrolled fingerprint; displaying on the display an affordance for receiving authorization to proceed with the payment transaction using a payment passcode.

39. The method of any one of claims 31 to 38, further comprising:

41. determining whether a predetermined number of attempts have been made to receive authorization to proceed with the payment transaction using a fingerprint sensor; requiring authorization to proceed with the payment transaction using a payment passcode in accordance with a determination that the predetermined number of attempts to receive authorization has been reached; 41. The method of any one of claims 22 to 40, further comprising:

42. 42. The method of claim 32, further comprising: displaying a visual prompt on the display instructing a user to place a finger on the fingerprint sensor in accordance with a determination that the corresponding fingerprint does not match the enrolled fingerprint.

43. receiving authorization to proceed with the payment transaction; receiving a payment passcode at the electronic device; determining that the payment passcode matches a registered passcode that enables authorization of the payment transaction; authorizing the payment transaction in response to determining that the payment passcode matches the registered passcode; 43. The method of any one of claims 22 to 42, comprising:

44. receiving authorization to proceed with the payment transaction; detecting a corresponding fingerprint on a fingerprint sensor of the electronic device; In response to detecting the corresponding fingerprint on the fingerprint sensor, determining that the fingerprint matches a registered fingerprint that allows authorization of a payment transaction, and authorizing the payment transaction in accordance with a determination that the corresponding fingerprint matches the registered fingerprint; 43. The method of any one of claims 22 to 42, comprising:

45. Providing an indication requesting permission to proceed with the payment transaction includes: detecting, via the short-range communications radio, whether the device continues to be in the presence of the field; In response to the device detecting that it is not continuing in the presence of the field, displaying on the display a visual indicator that authentication has failed; generating a non-visual alert at the electronic device indicating authentication has failed in response to the device detecting that the device continues in the presence of the field; 45. The method of any one of claims 22 to 44, comprising:

46. 46. ​​A method according to any one of claims 22 to 45, further comprising, in response to receiving permission to proceed with the payment transaction, providing on the display a graphical indication that permission to proceed has been provided.

47. 47. The method of any one of claims 22 to 46, further comprising, in response to receiving authorization to proceed with the payment transaction, proceeding with the payment transaction.

48. 48. A method according to any one of claims 22 to 47, wherein conducting the payment transaction with the contactless payment transaction terminal comprises completing the payment transaction using a linked payment account.

49. 49. The method of any one of claims 22 to 48, wherein proceeding with the payment transaction with the contactless payment transaction terminal includes completing the payment transaction using a primary account number for use in the payment transaction, the primary account number being stored on the electronic device.

50. 50. A method according to any one of claims 22 to 49, further comprising displaying an electronic wallet on the display in response to detecting the presence of the venue generated by the contactless payment transaction terminal.

51. 51. The method of any one of claims 22 to 50, wherein providing an indication requesting permission to proceed with the payment transaction comprises displaying on the display instructions regarding permission to proceed with the payment transaction.

52. 52. The method of any one of claims 22 to 51, wherein providing the indication requesting permission to proceed with the payment transaction includes displaying a permission request screen on the display of the electronic device, the permission request screen including a graphical representation of the credit card associated with the payment account, the graphical representation including a background image of the credit card associated with the payment account.

53. In an electronic device having a display, displaying on the display an electronic wallet including a corresponding representation of a payment account, the corresponding representation of the payment account including first transaction information regarding a first payment transaction associated with the payment account; detecting a second payment transaction associated with the payment account using the electronic device; In response to detecting the second payment transaction and prior to receiving information regarding the second payment transaction from the financial institution involved in the second transaction, displaying second transaction information regarding the second payment transaction; wherein the second transaction information is based on information locally available to the electronic device.

54. 54. The method of claim 53, wherein displaying the second transaction information regarding the second payment transaction comprises replacing the display of the first transaction information with the display of the second transaction information.

55. 55. The method of claim 53 or 54, wherein if the second payment transaction is detected, the information locally available to the electronic device includes one or more of: a date of the second payment transaction, a time of the second payment transaction, or a location of the electronic device.

56. receiving first additional information regarding the second payment transaction from an intermediary involved in the second transaction; in response to receiving the first additional information about the second payment transaction from the intermediary involved in the second transaction, updating the display of second transaction information about the second payment transaction to include the first additional information about the second payment transaction; 56. The method of any one of claims 53 to 55, further comprising:

57. 57. The method of any one of claims 53 to 56, wherein the first additional information includes an amount of the payment transaction.

58. receiving second additional information; in response to receiving the second additional information related to the second payment transaction from the financial institution involved in the second transaction, updating the second transaction information related to the second payment transaction to include the second additional information related to the second payment transaction; 58. The method of any one of claims 53 to 57, further comprising:

59. 60. The method of claim 58, wherein the second additional information about the second payment transaction includes the name of a retailer that will receive payment as a result of the second payment transaction.

60. 60. The method of any one of claims 53 to 59, wherein the first payment transaction is completed using the electronic device.

61. 61. The method of any one of claims 53 to 60, wherein the first payment transaction is completed using a physical credit card associated with the payment account.

62. receiving a text message from the financial institution; displaying the text message from the financial institution over the corresponding representation of the payment account; receiving a selection of the displayed text message from the financial institution; displaying a particular application associated with the financial institution in response to receiving a selection of the displayed text message from the financial institution; 62. The method of any one of claims 53 to 61, further comprising:

63. 63. The method of any one of claims 53 to 62, further comprising displaying an available credit amount on the corresponding representation of the payment account, the available credit amount representing the amount of available credit for the payment account based on a credit limit for the payment account.

64. displaying an account details affordance over the corresponding representation of the payment account; receiving a selection of the account details affordance; responsive to receiving a selection of the account details affordance, replacing a display of transaction details of the payment account with a display of the corresponding representation of the payment account; 64. The method of any one of claims 53 to 63, further comprising: wherein the transaction details include the first transaction information and the second transaction information.

65. determining whether a specific application for accessing details of the associated payment account is installed on the electronic device; displaying an open application affordance on the transaction details for accessing the particular application in accordance with a determination that the particular application is installed; and 65. The method of claim 64, further comprising:

66. receiving a selection of the open application affordance; In response to receiving a selection of the open application affordance, completely replacing the display of the transaction details with a display of the particular application; 66. The method of claim 65, further comprising:

67. receiving a selection of the first transaction information of the displayed transaction details; In response to receiving a selection of the first transaction information, completely replacing the display of the transaction details with a display of the particular application; 66. The method of any one of claims 53 to 65, further comprising: wherein the display of the particular application includes details regarding the first payment transaction associated with the payment account.

68. the transaction details include further transaction affordances; The method comprises: receiving a selection of the further transaction affordance; and In response to receiving a selection of the further transaction affordance, displaying third transaction information related to a third payment transaction associated with the payment account as part of the displayed transaction details; 68. The method of any one of claims 64 to 67, further comprising:

69. the transaction details include a card removal affordance; The method comprises: receiving a selection of the card removal affordance; and In response to receiving a selection of the card removal affordance, displaying a confirmation request to remove the corresponding representation of the payment account from the electronic wallet; receiving a confirmation from the electronic wallet to remove the corresponding representation of the payment account; removing the corresponding representation of the payment account from the electronic wallet; 69. The method of any one of claims 64 to 68, further comprising:

70. the displayed electronic wallet includes a representation of a first stack of card objects and a second stack of card objects, the first stack of card objects being visually separated from the second stack of card objects; the first stack of card objects includes the corresponding representation of the payment account and a second corresponding representation of a second payment account; 70. The method of any one of claims 64 to 69, wherein the second stack of card objects includes membership card objects associated with non-financial institutions.

71. In an electronic device having a display, displaying a user interface of a first application on the display, the user interface of the first application including a payment affordance associated with a payment transaction; Detecting a selection of the payment affordance; and In response to detecting a selection of the payment affordance, transferring first transaction information relating to the payment transaction from the first application to a second application; displaying a user interface of the second application on the display; wherein the user interface of the second application includes the first transaction information received from the first application and includes second transaction information provided by the second application, and the second transaction information is not available to the first application.

72. receiving a selection of a first purchase details affordance displayed on the user interface of the second application, the first purchase details affordance being associated with first purchase details of the payment transaction; and In response to receiving a selection of the first purchase details affordance, displaying one or more affordances for selecting another value related to the first purchase details of the payment transaction; and receiving a selection of another value for the first purchase detail of the payment transaction; In response to receiving a selection of the alternative value, updating the second transaction information to include the alternative value as the first purchase detail; 72. The method of claim 71, further comprising:

73. 73. The method of claim 72, wherein the first purchase details of the payment transaction are part of the first transaction information from the first application.

74. 73. The method of claim 72, wherein the first purchase details are part of the second transaction information provided by the second application.

75. 74. The method of claim 72 or 73, wherein the first purchase detail is a shipping address.

76. 75. The method of claim 72 or 74, wherein the first purchase details are a payment account.

77. receiving authorization to proceed with the payment transaction; In response to receiving authorization to proceed with the payment transaction, forwarding the second transaction information to the first application; 77. The method of any one of claims 71 to 76, further comprising:

78. receiving authorization to proceed with the payment transaction; In response to receiving authorization to proceed with the payment transaction, forwarding the first transaction information and the second transaction information to the first application; 77. The method of any one of claims 71 to 76, further comprising:

79. 79. The method of any one of claims 71 to 78, wherein the first application is a third-party application installed on the electronic device.

80. 79. The method of any one of claims 71 to 78, wherein the first application comprises a website accessed by a web browser installed on the electronic device.

81. 81. The method of any one of claims 71 to 80, wherein the second application is an operating system of the electronic device, and the second application has access to an electronic wallet containing the second transaction information.

82. 81. The method of any one of claims 71 to 80, wherein the second application is a first-party application provided by an operating system provider of the electronic device, and the second application has access to an electronic wallet containing the second transaction information.

83. 83. The method of any one of claims 71 to 82, wherein the first transaction information includes an amount and a default shipping method.

84. 84. The method of any one of claims 71 to 83, wherein the second transaction information includes a primary account number associated with a payment account.

85. 85. The method of any one of claims 71 to 84, wherein the second transaction information includes a shipping address accessed from user contact information, the user contact information being stored on the electronic device.

86. 86. The method of any one of claims 71 to 85, further comprising receiving the authorization to proceed with the payment transaction before forwarding the second transaction information to the first application.

87. transferring zip code information from the second application to the first application, the first transaction information including an initial shipping cost based on the zip code information; receiving updated first transaction information, the updated first transaction information including a shipping cost based on the second transaction information; 87. The method of any one of claims 71 to 86, further comprising:

88. receiving authorization to proceed with the payment transaction; detecting a corresponding fingerprint on a fingerprint sensor of the electronic device; responsive to detecting the corresponding fingerprint on the fingerprint sensor, determining whether the fingerprint matches a registered fingerprint to allow authorization of a payment transaction; authorizing the payment transaction in accordance with a determination that the corresponding fingerprint matches the enrolled fingerprint; withholding authorization of the payment transaction in accordance with a determination that the corresponding fingerprint does not match the enrolled fingerprint; 88. The method of any one of claims 77 to 87, comprising:

89. in response to a determination that the corresponding fingerprint does not match the enrolled fingerprint; displaying on the display an affordance for receiving authorization to proceed with the payment transaction using a payment passcode.

89. The method of claim 88, further comprising:

90. in response to a determination that the corresponding fingerprint does not match the enrolled fingerprint; determining whether a predetermined number of attempts have been made to receive authorization to proceed with the payment transaction using the fingerprint sensor; requiring authorization to proceed with the payment transaction using a payment passcode in accordance with a determination that the predetermined number of attempts to receive authorization has been reached; 90. The method of claim 88 or 89, further comprising:

91. 91. The method of claim 90, wherein the predetermined number of trials is three.

92. 92. The method of any one of claims 71 to 91, further comprising, pursuant to a determination that the corresponding fingerprint does not match the enrolled fingerprint, displaying a visual prompt on the display instructing a user to place a finger on the fingerprint sensor.

93. receiving authorization to proceed with the payment transaction; receiving a payment passcode at the electronic device; determining whether the payment passcode matches a registered passcode that allows authorization of the payment transaction; authorizing the payment transaction in response to determining that the payment passcode matches the registered passcode; 93. The method of any one of claims 77 to 92, comprising:

94. 94. The method of any one of claims 71 to 93, further comprising completing the payment transaction using the first application in response to transferring the first transaction information and the second transaction information from the second application to the first application.

95. 95. The method of any one of claims 71 to 94, wherein a financial institution associated with processing the payment transaction treats the payment transaction as a card-present transaction.

96. 96. The method of any one of claims 71 to 95, wherein displaying the user interface of the second application partially obscures the user interface of the first application, leaving at least a portion of the user interface of the first application visible.

97. 97. The method of any one of claims 71 to 96, wherein displaying the user interface of the second application comprises sliding the user interface of the second application vertically onto the display from a bottom of the display to partially obscure the user interface of the first application and leave at least a portion of the user interface of the first application visible.

98. displaying, on the display, a user interface of a third application, the user interface of the third application including a second payment affordance associated with a second payment transaction; Detecting a selection of the second payment affordance; and In response to detecting a selection of the second payment affordance, transferring third transaction information relating to the second payment transaction from the third application to the second application; displaying a second user interface of the second application on the display; and 98. The method of any one of claims 71 to 97, further comprising: the second user interface of the second application including the third transaction information received from the third application and including fourth transaction information provided by the second application, and the second transaction information is not available to the third application.

99. Displaying the settings menu; receiving a selection of a default shipping address to be used as a default for the second transaction information; 99. The method of any one of claims 71 to 98, further comprising:

100. 99. The method of claim 71, further comprising receiving a selection from among at least the payment account and a second payment account displayed in the settings menu, the selection specifying the default payment account to be used for payment transactions.

101. receiving a preference for viewing transaction history displayed in a settings menu; determining whether the transaction history display preference is on; displaying a payment transaction history in accordance with a determination that the transaction history display preference is on; and 101. The method of any one of claims 71 to 100, further comprising:

102. receiving a desired selection of the transaction history type to be displayed in a settings menu; determining whether the desired transaction history type is a first type, a second type, or a third type; not displaying a history of payment transactions related to the payment account in response to a determination that the desired transaction history type is the first type; and In accordance with a determination that the transaction history type preference is the second type, displaying a history of payment transactions related to the payment account completed using only the electronic device; and displaying a history of payment transactions completed using the electronic device and a physical credit card for the payment account in accordance with a determination that the transaction history type preference is the third type; and 102. The method of any one of claims 71 to 101, further comprising:

103. A device, The display and one or more processors; Memory and One or more programs; the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs comprising: receiving a request to link a payment account associated with a credit card to a corresponding device, the request including information about the credit card; In response to receiving the request, determining whether further verification is required to link the payment account to the corresponding device; linking the payment account to the corresponding device in accordance with a determination that no further verification is required to link the payment account to the corresponding device and providing an indication that the payment account has been linked to the corresponding device; and providing an indication that further verification is required to link the payment account to the corresponding device in accordance with a determination that further verification is required to link the payment account to the corresponding device. A device containing instructions.

104. 1. A graphical user interface on a device having a display, a memory, and one or more processors executing one or more programs stored in the memory, comprising: a request is received to link a payment account associated with a credit card to a corresponding device, the request including information about the credit card; In response to receiving the request, determining whether further verification is required to link the payment account to the corresponding device; In accordance with a determination that no further verification is required to link the payment account to the corresponding device, the payment account is linked to the corresponding device, and an indication that the payment account has been linked to the corresponding device is provided; In accordance with a determination that further verification is required to link the payment account to the corresponding device, an indication is provided that further verification is required to link the payment account to the corresponding device. Graphical user interface.

105. A non-transitory computer-readable storage medium storing one or more programs, the one or more programs, when executed by a device having a display, causing the device to: receiving a request to link a payment account associated with a credit card to a corresponding device, the request including information about the credit card; In response to receiving the request, determining whether further verification is required to link the payment account to the corresponding device; linking the payment account to the corresponding device in response to a determination that no further verification is required to link the payment account to the corresponding device and providing an indication that the payment account has been linked to the corresponding device; and in response to a determination that further verification is required to link the payment account to the corresponding device, causing an indication that further verification is required to link the payment account to the corresponding device to be provided. A non-transitory computer-readable storage medium containing instructions.

106. A device, The display and means for receiving a request to link a payment account associated with a credit card to a corresponding device, the request including information about the credit card; In response to receiving the request, determining whether further verification is required to link the payment account to the corresponding device; linking the payment account to the corresponding device in accordance with a determination that no further verification is required to link the payment account to the corresponding device and providing an indication that the payment account has been linked to the corresponding device; and providing an indication that further verification is required to link the payment account to the corresponding device in accordance with a determination that further verification is required to link the payment account to the corresponding device. Means and A device comprising:

107. An information processing device used in a device equipped with a display, means for receiving a request to link a payment account associated with a credit card to a corresponding device, the request including information about the credit card; In response to receiving the request, determining whether further verification is required to link the payment account to the corresponding device; linking the payment account to the corresponding device in accordance with a determination that no further verification is required to link the payment account to the corresponding device and providing an indication that the payment account has been linked to the corresponding device; and providing an indication that further verification is required to link the payment account to the corresponding device in accordance with a determination that further verification is required to link the payment account to the corresponding device. Means and An information processing device comprising:

108. A device, The display and one or more processors; Memory and A short-range communication radio One or more programs; the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs comprising: detecting, by said near field communication radio, the presence of a field created by a contactless payment transaction terminal; determining whether authorization to proceed with a payment transaction is provided in response to detecting the presence of the field generated by the contactless payment transaction terminal; proceeding with the payment transaction with the contactless payment transaction terminal in accordance with a determination that authorization to proceed with the payment transaction has been provided; and providing an indication requesting permission to proceed with the payment transaction in accordance with a determination that permission to proceed with the payment transaction has not been provided. A device containing instructions.

109. 1. A graphical user interface on a device having a display, a memory, a near field communication radio, and one or more processors executing one or more programs stored in the memory, comprising: the near field communication radio detects the presence of a field generated by a contactless payment transaction terminal; a determination is provided whether authorization to proceed with a payment transaction is provided in response to detecting the presence of the field generated by the contactless payment transaction terminal; proceeding with the payment transaction with the contactless payment transaction terminal in accordance with a determination that authorization to proceed with the payment transaction has been provided; and providing an indication requesting authorization to proceed with the payment transaction in accordance with a determination that authorization to proceed with the payment transaction has not been provided. Graphical user interface.

110. 1. A non-transitory computer-readable storage medium storing one or more programs, the one or more programs, when executed by a device having a display and a near-field communication radio, causing the device to: causing the near field communication radio to detect the presence of a field created by a contactless payment transaction terminal; determining whether authorization to proceed with a payment transaction is provided in response to detecting the presence of the field generated by the contactless payment transaction terminal; proceeding with the payment transaction with the contactless payment transaction terminal in accordance with a determination that authorization to proceed with the payment transaction has been provided; providing an indication requesting permission to proceed with the payment transaction in accordance with a determination that permission to proceed with the payment transaction has not been provided; A non-transitory computer-readable storage medium containing instructions.

111. A device, The display and A short-range communication radio means for detecting, by said near field communication radio, the presence of a field created by a contactless payment transaction terminal; means for determining whether authorization is provided to proceed with a payment transaction in response to detecting the presence of the field generated by the contactless payment transaction terminal, proceeding with the payment transaction with the contactless payment transaction terminal in accordance with a determination that authorization to proceed with the payment transaction has been provided; providing an indication requesting permission to proceed with the payment transaction in accordance with a determination that permission to proceed with the payment transaction has not been provided; Means and A device comprising:

112. 1. An information processing device for use in a device having a display and a short-range communication radio, comprising: means for detecting, by said near field communication radio, the presence of a field created by a contactless payment transaction terminal; means for determining whether authorization is provided to proceed with a payment transaction in response to detecting the presence of the field generated by the contactless payment transaction terminal, proceeding with the payment transaction with the contactless payment transaction terminal in accordance with a determination that authorization to proceed with the payment transaction has been provided; providing an indication requesting permission to proceed with the payment transaction in accordance with a determination that permission to proceed with the payment transaction has not been provided; Means and An information processing device comprising:

113. A device, The display and one or more processors; Memory and One or more programs; the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs comprising: displaying on the display an electronic wallet including a corresponding representation of a payment account, the corresponding representation of the payment account including first transaction information related to a first payment transaction associated with the payment account; Detecting a second payment transaction associated with the payment account using the electronic device; displaying second transaction information regarding the second payment transaction in response to detecting the second payment transaction and prior to receiving information regarding the second payment transaction from the financial institution involved in the second transaction; 20. A device comprising: instructions for transmitting a transaction to a second electronic device; and wherein the second transaction information is based on information locally available to the electronic device.

114. 1. A graphical user interface on a device having a display, a memory, and one or more processors executing one or more programs stored in the memory, comprising: an electronic wallet including a corresponding representation of a payment account, the corresponding representation of the payment account including first transaction information relating to a first payment transaction associated with the payment account; detecting, with the electronic device, a second payment transaction associated with the payment account; in response to detecting the second payment transaction and prior to receiving information regarding the second payment transaction from the financial institution involved in the second transaction, second transaction information regarding the second payment transaction is displayed, the second transaction information being based on information locally available to the electronic device. Graphical user interface.

115. A non-transitory computer-readable storage medium storing one or more programs, the one or more programs, when executed by a device having a display, causing the device to: causing the display to display an electronic wallet including a corresponding representation of a payment account, the corresponding representation of the payment account including first transaction information regarding a first payment transaction associated with the payment account; detecting, with the electronic device, a second payment transaction associated with the payment account; in response to detecting the second payment transaction and prior to receiving information regarding the second payment transaction from the financial institution involved in the second transaction, displaying second transaction information regarding the second payment transaction. A non-transitory computer-readable storage medium comprising instructions, wherein the second transaction information is based on information locally available to the electronic device.

116. A device, The display and means for displaying on the display an electronic wallet including a corresponding representation of a payment account, the corresponding representation of the payment account including first transaction information regarding a first payment transaction associated with the payment account; means for detecting, with the electronic device, a second payment transaction associated with the payment account; means for displaying second transaction information regarding the second payment transaction in response to detecting the second payment transaction and prior to receiving information regarding the second payment transaction from the financial institution involved in the second transaction; wherein the second transaction information is based on information locally available to the electronic device.

117. An information processing device used in a device equipped with a display, means for displaying on the display an electronic wallet including a corresponding representation of a payment account, the corresponding representation of the payment account including first transaction information regarding a first payment transaction associated with the payment account; means for detecting, with the electronic device, a second payment transaction associated with the payment account; means for displaying second transaction information regarding the second payment transaction in response to detecting the second payment transaction and prior to receiving information regarding the second payment transaction from the financial institution involved in the second transaction; wherein the second transaction information is based on information locally available to the electronic device.

118. A device, The display and one or more processors; Memory and One or more programs; the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs comprising: displaying, on the display, a user interface of a first application, the user interface of the first application including a payment affordance associated with a payment transaction; Detecting a selection of the payment affordance; In response to detecting a selection of the payment affordance, transferring first transaction information relating to the payment transaction from the first application to a second application; displaying a user interface of the second application on the display; a device including instructions, wherein the user interface of the second application includes the first transaction information received from the first application and includes second transaction information provided by the second application, and the second transaction information is not available to the first application.

119. 1. A graphical user interface on a device having a display, a memory, and one or more processors executing one or more programs stored in the memory, comprising: a user interface of a first application, the user interface of the first application including a payment affordance associated with a payment transaction; a selection of the payment affordance is detected; In response to detecting a selection of the payment affordance, first transaction information relating to the payment transaction is transferred from the first application to a second application; a user interface of the second application is displayed, the user interface of the second application including the first transaction information received from the first application and including second transaction information provided by the second application, the second transaction information being unavailable to the first application; Graphical user interface.

120. A non-transitory computer-readable storage medium storing one or more programs, the one or more programs, when executed by a device having a display, causing the device to: Displaying on the display a user interface of a first application, the user interface of the first application including a payment affordance associated with a payment transaction. Detecting a selection of the payment affordance; In response to detecting a selection of the payment affordance, transferring first transaction information relating to the payment transaction from the first application to a second application; displaying a user interface of the second application on the display; A non-transitory computer-readable storage medium comprising instructions, wherein the user interface of the second application includes the first transaction information received from the first application and includes second transaction information provided by the second application, the second transaction information being unavailable to the first application.

121. A device, The display and means for displaying a user interface of a first application on the display, the user interface of the first application including a payment affordance associated with a payment transaction; means for detecting a selection of the payment affordance; In response to detecting a selection of the payment affordance, transferring first transaction information relating to the payment transaction from the first application to a second application; When the user interface of the second application is displayed on the display, Means and wherein the user interface of the second application includes the first transaction information received from the first application and includes second transaction information provided by the second application, and the second transaction information is not available to the first application.

122. An information processing device used in a device equipped with a display, means for displaying a user interface of a first application on the display, the user interface of the first application including a payment affordance associated with a payment transaction; means for detecting a selection of the payment affordance; In response to detecting a selection of the payment affordance, transferring first transaction information relating to the payment transaction from the first application to a second application; displaying a user interface of the second application on the display; Means and wherein the user interface of the second application includes the first transaction information received from the first application and includes second transaction information provided by the second application, and the second transaction information is not available to the first application.

123. 103. A non-transitory computer-readable storage medium comprising instructions for performing the method of any one of claims 1 to 102.

124. A device, 124. A non-transitory computer-readable storage medium according to claim 123; one or more processors capable of executing the instructions of the non-transitory computer-readable storage medium; A device comprising:

125. A device comprising means for carrying out the method of any one of claims 1 to 102.

126. 1. An electronic device comprising: A display unit; a processing unit coupled to the display unit; The processing unit comprises: receiving a request to link a payment account associated with a credit card to a corresponding device, the request including information about the credit card; In response to receiving the request, determining whether further verification is required to link the payment account to the corresponding device; linking the payment account to the corresponding device in accordance with a determination that no further verification is required to link the payment account to the corresponding device and providing an indication that the payment account has been linked to the corresponding device; and providing an indication that further verification is required to link the payment account to the corresponding device in accordance with a determination that further verification is required to link the payment account to the corresponding device.

1. An electronic device configured to:

127. 127. The electronic device of claim 126, wherein the indication that further verification is required to link the payment account to the corresponding device comprises an alphanumeric visual indicator displayed on the display of the electronic device.

128. 127. The electronic device of claim 126, wherein the indication that further verification is required to link the payment account to the corresponding device includes a visual indication of additional steps a user must take to link the payment account to the corresponding device.

129. The processing unit In accordance with the determination that further verification is required to link the payment account to the corresponding device, further configured to enable a plurality of communication method affordances to be displayed on the display, each communication method affordance being associated with a corresponding communication method for verification communication; 129. The electronic device of any one of claims 126 to 128, wherein the plurality of communication method affordances is based on communications received from the financial institution.

130. The processing unit In accordance with the determination that further verification is required to link the payment account to the corresponding device, further configured to enable a plurality of communication method affordances to be displayed on the display, each communication method affordance being associated with a corresponding communication method for verification communication; 129. The electronic device of any one of claims 126 to 128, wherein the display of the plurality of communication method affordances is based on locally stored contact information, the locally stored contact information including each of the communication methods.

131. The processing unit In accordance with the determination that further verification is required to link the payment account to the corresponding device, receiving a selection of a communication method affordance from the plurality of communication method affordances; responsive to receiving the selection of the communication method affordance, enabling an indication of the corresponding communication method of the selected communication method affordance to be sent to the financial institution. further configured as follows:

131. The electronic device of claim 129 or 130, wherein the verification communication is based on the communication method affordance.

132. The processing unit In accordance with the determination that further verification is required to link the payment account to the corresponding device, receive a verification communication from a financial institution associated with said payment account 132. The electronic device of any one of claims 126 to 131, further configured to: wherein the verification communication is for verifying linking of the payment account to the corresponding device.

133. The processing unit In accordance with the determination that further verification is required to link the payment account to the corresponding device, receiving a request from a user to initiate a verification communication with the financial institution; In response to receiving the request, initiate the verification communication with the financial institution associated with the payment account.

132. The electronic device of any one of claims 126 to 131, further configured to: wherein the verification communication is for verifying linking of the payment account to the corresponding device.

134. The processing unit receiving a notification at the electronic device, the notification including a verification code for linking the payment account to the corresponding device; In response to receiving the notification including the verification code on the electronic device, linking the payment account to the corresponding device.

134. The electronic device of any one of claims 126 to 133, further configured to:

135. The processing unit 135. The electronic device of any one of claims 126 to 134, further configured to enable the device to display a confirmation indicating that the payment account has been linked to the corresponding device, including enabling the device to display a notice indicating that the payment account has been linked to the corresponding device.

136. The processing unit receiving a user input requesting a secondary verification code for linking the payment account to the corresponding device; In response to receiving the input requesting the secondary verification code, a request requesting the secondary verification code can be sent to the financial institution.

135. The electronic device of any one of claims 126 to 134, further configured to:

137. The processing unit receiving a secondary notification at the electronic device, the secondary notification including the secondary verification code for linking the payment account to the corresponding device; In response to receiving the secondary notification at the electronic device, the secondary notification including the secondary verification code, linking the payment account to the corresponding device and enabling the device to display a confirmation indicating that the payment account has been linked to the corresponding device.

136. The electronic device of any one of claims 126 to 133 and 135, further configured to:

138. The processing unit 138. The electronic device of any one of claims 126 to 137, further configured to receive a primary account number from the financial institution for use in authorizing payments from the payment account using the corresponding device, the primary account number being different from the account number displayed on the credit card.

139. The processing unit 139. The electronic device of claim 138, further configured to assign the primary account number to the corresponding device, the primary account number being different from the account number displayed on the credit card.

140. receiving the request to link the payment account enabling the display unit to display a credit card import affordance for importing at least partial credit card information from a remote server; receiving a user selection of the credit card import affordance; in response to receiving the user selection of the credit card import affordance to import credit card information from the remote server; enabling a credit card details screen to be displayed, the credit card details screen including an indication of the credit card number of the credit card associated with the payment account and including a security code input field for receiving a security code; receiving a corresponding security code in the security code input field through user input; determining the validity of the credit card using verification based on the credit card number and the corresponding security code; 140. The electronic device of any one of claims 126 to 139, comprising:

141. receiving the request to link the payment account enabling user input at the electronic device to display a credit card input affordance on the display for receiving credit card information; receiving a user selection of the credit card input affordance; in response to receiving the user selection of the credit card input affordance for inputting credit card information; enabling a credit card details screen to be displayed, the credit card details screen including an account input field for receiving a credit card number associated with the payment account and a security code input field for receiving a security code; receiving a corresponding credit card number in the account input field and a corresponding security code in the security code input field according to user input; determining the validity of the credit card using verification based on the corresponding credit card number and the corresponding security code; 141. The electronic device of any one of claims 126 to 140, comprising:

142. 142. The electronic device of claim 141, wherein the credit card detail screen includes a displayed visual graphical representation of the credit card associated with the payment account, the graphical representation including a background image of the credit card associated with the payment account.

143. 143. The electronic device of any one of claims 126 to 142, wherein the corresponding device is a second electronic device separate from the electronic device.

144. 144. An electronic device according to any one of claims 126 to 143, wherein the corresponding device is an electronic device, the electronic device being a mobile communication device.

145. The processing unit determining whether the corresponding device is configured to require an unlock authorization to unlock the corresponding device; enabling the display unit to display an unlock authentication configurator for configuring the corresponding device to require unlock authorization to unlock the corresponding device according to determining that the corresponding device is not configured to require unlock authorization; 145. The electronic device of any one of claims 126 to 144, further configured to:

146. The processing unit receiving a second request to link a second payment account associated with a second credit card to the corresponding device, the second request including information about the second credit card; linking the second payment account to the corresponding device and providing an indication that the second payment account has been linked to the corresponding device; receiving a selection from at least the payment account and the second payment account; 146. The electronic device of any one of claims 126 to 145, further configured so that the selection specifies the default payment account to be used for payment transactions.

147. 1. An electronic device comprising: A display unit; a short-range communication wireless unit; a processing unit coupled to the display unit and the near field communication wireless unit; The processing unit comprises: enabling the near field communication wireless unit to detect the presence of a field generated by a contactless payment transaction terminal; determining whether authorization to proceed with a payment transaction is provided in response to detecting the presence of the field generated by the contactless payment transaction terminal; proceeding with the payment transaction with the contactless payment transaction terminal in accordance with a determination that authorization to proceed with the payment transaction has been provided; and providing an indication requesting permission to proceed with the payment transaction in accordance with a determination that permission to proceed with the payment transaction has not been provided.

1. An electronic device configured to:

148. 148. The electronic device of claim 147, wherein the user interface of the electronic device is locked when the presence of the generated field is detected, and the display of the electronic device is turned off when the presence of the generated field is detected, and the processing unit is configured to turn on the display in response to detecting the presence of the field generated by the contactless payment transaction terminal.

149. The processing unit if, after detecting the presence of the field generated by the contactless payment transaction terminal, permission to proceed with the payment transaction is not provided; detecting by the near field radio that the device is no longer within range of the field generated by the contactless payment transaction terminal; enabling the device to display a plurality of payment card affordances associated with different payment accounts in response to detecting that the device is no longer within range of the venue; receiving authorization to proceed with the payment transaction for a predetermined time using one of the payment accounts; 149. The electronic device of claim 147 or 148, further configured to:

150. The processing unit further configured to provide an indication that a default payment card affordance of the plurality of payment card affordances has been selected as a default payment account; 150. The electronic device of claim 149, wherein the default primary account number associated with the default payment card affordance is selected for use in the payment transaction.

151. The processing unit receiving a selection of another payment card affordance of the plurality of payment card affordances, the other payment card affordance being associated with a corresponding other primary account number; In response to receiving the selection of the alternative payment card affordance, selecting the corresponding alternative primary account number for use in the payment transaction.

151. The electronic device of claim 149 or 150, further configured to:

152. The processing unit 152. The electronic device of any one of claims 147 to 151, further configured to receive permission to proceed with the payment transaction for a predetermined time in accordance with the determination that permission to proceed with the payment transaction has not been provided.

153. The processing unit 149. An electronic device according to claim 147 or 148, further configured to receive permission to proceed with a payment transaction for a predetermined time before detecting the presence of the field generated by the contactless payment transaction terminal.

154. 154. The electronic device of any one of claims 149, 152 or 153, wherein the predetermined time is based on a current location of the electronic device.

155. 155. The electronic device of any one of claims 149 and 152-154, wherein the predetermined time is based on a credit score associated with the payment account.

156. 156. An electronic device according to any one of claims 149 and 152 to 155, wherein the predetermined time is user configurable.

157. The processing unit While the device is within the field generated by the contactless payment transaction terminal, detecting a corresponding fingerprint on a fingerprint sensor unit of the electronic device; responsive to detecting the corresponding fingerprint on the fingerprint sensor unit, determining whether the fingerprint matches a registered fingerprint to allow authorization of a payment transaction; authorizing the payment transaction in accordance with a determination that the corresponding fingerprint matches the enrolled fingerprint; withholding authorization of the payment transaction in accordance with a determination that the corresponding fingerprint does not match the enrolled fingerprint.

157. The electronic device of any one of claims 147 to 156, further configured to:

158. The processing unit in response to a determination that the corresponding fingerprint does not match the enrolled fingerprint; enabling a speaker unit on the electronic device to play a failure audio alert indicating that permission to proceed with the payment transaction was not provided.

158. The electronic device of claim 157, further configured as follows:

159. The processing unit determining whether the payment transaction was successfully completed in accordance with the determination that authorization to proceed with the payment transaction was provided; In response to determining that the payment transaction has been successfully completed, enable the electronic device to play a success audio alert indicating that the payment transaction has been successfully completed.

159. The electronic device of any one of claims 147 to 158, further configured to:

160. 160. The electronic device of claim 158 or 159, wherein the failure audio alert and the success audio alert are different.

161. The processing unit in response to a determination that the corresponding fingerprint does not match the enrolled fingerprint; enabling a tactile failure alert at the electronic device to indicate that authorization to proceed with the payment transaction was not provided; 161. The electronic device of any one of claims 147 to 160, further configured to:

162. The processing unit determining whether the payment transaction was successfully completed in accordance with the determination that authorization to proceed with the payment transaction was provided; In response to determining that the payment transaction has been successfully completed, enabling the electronic device to generate a tactile success alert indicating that the payment transaction has been successfully completed.

160. The electronic device of any one of claims 157 to 159, further configured to:

163. 163. The electronic device of any one of claims 160 to 162, wherein the failure tactile alert and the success tactile alert are different.

164. 164. The electronic device of claim 163, wherein the failure tactile alert is of greater duration and intensity than the success tactile alert.

165. The processing unit in response to a determination that the corresponding fingerprint does not match the enrolled fingerprint; and enabling the display unit to display an affordance for receiving authorization to proceed with the payment transaction using a payment passcode.

164. The electronic device of any one of claims 156 to 163, further configured to:

166. The processing unit determining whether a predetermined number of attempts have been made to receive authorization to proceed with the payment transaction using the fingerprint sensor; requiring authorization to proceed with the payment transaction using a payment passcode pursuant to a determination that the predetermined number of attempts to receive authorization has been reached.

166. The electronic device of any one of claims 147 to 165, further configured to:

167. The processing unit 167. The electronic device of any one of claims 157 to 166, further configured to enable the display unit to display a visual prompt instructing a user to place a finger on the fingerprint sensor unit in accordance with a determination that the corresponding fingerprint does not match the registered fingerprint.

168. receiving authorization to proceed with the payment transaction; receiving a payment passcode at the electronic device; determining that the payment passcode matches a registered passcode that enables authorization of the payment transaction; authorizing the payment transaction in response to determining that the payment passcode matches the registered passcode; 168. The electronic device of any one of claims 147 to 167, comprising:

169. receiving authorization to proceed with the payment transaction; detecting a corresponding fingerprint on a fingerprint sensor unit of the electronic device; In response to detecting the corresponding fingerprint on the fingerprint sensor unit, determining that the fingerprint matches a registered fingerprint that allows authorization of a payment transaction, and authorizing the payment transaction in accordance with a determination that the corresponding fingerprint matches the registered fingerprint; 168. The electronic device of any one of claims 147 to 167, comprising:

170. Providing an indication requesting permission to proceed with the payment transaction includes: detecting, by the short-range communication wireless unit, whether the device continues to be in the presence of the field; In response to the device detecting that it is not continuing in the presence of the field, enabling the display unit to display a visual indicator indicating that authentication has failed; In response to the device detecting that the device continues in the presence of the field, enabling the electronic device to generate a non-visual alert indicating that authentication has failed; 170. The electronic device of any one of claims 147 to 169, comprising:

171. The processing unit 171. The electronic device of any one of claims 147 to 170, further configured to, in response to receiving authorization to proceed with the payment transaction, enable displaying on the display unit a graphical indication that authorization to proceed has been provided.

172. The processing unit 172. The electronic device of any one of claims 147 to 171, further configured to proceed with the payment transaction in response to receiving authorization to proceed with the payment transaction.

173. 173. The electronic device of any one of claims 147 to 172, wherein conducting the payment transaction with the contactless payment transaction terminal comprises completing the payment transaction using a linked payment account.

174. 174. The electronic device of any one of claims 147 to 173, wherein proceeding with the payment transaction with the contactless payment transaction terminal includes completing the payment transaction using a primary account number for use in the payment transaction, the primary account number being stored on the electronic device.

175. The processing unit 175. An electronic device according to any one of claims 147 to 174, further configured to enable an electronic wallet to be displayed on the display unit in response to detecting the presence of the field generated by the contactless payment transaction terminal.

176. 176. The electronic device of any one of claims 147 to 175, wherein providing an indication requesting permission to proceed with the payment transaction comprises enabling the display unit to display instructions regarding permission to proceed with the payment transaction.

177. 177. The electronic device of any one of claims 147 to 176, wherein providing the indication requesting permission to proceed with the payment transaction includes enabling a permission request screen to be displayed on the display of the electronic device, the permission request screen including a graphical representation of the credit card associated with the payment account, the graphical representation including a background image of the credit card associated with the payment account.

178. 1. An electronic device comprising: A display unit; a processing unit coupled to the display unit; The processing unit comprises: enabling the display unit to display an electronic wallet including a corresponding representation of a payment account, the corresponding representation of the payment account including first transaction information regarding a first payment transaction associated with the payment account; Detecting a second payment transaction associated with the payment account using the electronic device; in response to detecting the second payment transaction and prior to receiving information regarding the second payment transaction from the financial institution involved in the second transaction, enabling display of second transaction information regarding the second payment transaction; wherein the second transaction information is based on information locally available to the electronic device.

179. 179. The electronic device of clause 178, wherein displaying the second transaction information regarding the second payment transaction includes replacing the display of the first transaction information with the display of the second transaction information.

180. 180. The electronic device of claim 178 or 179, wherein if the second payment transaction is detected, information locally available to the electronic device includes one or more of the date of the second payment transaction, the time of the second payment transaction, or the location of the electronic device.

181. The processing unit receiving first additional information regarding the second payment transaction from an intermediary involved in the second transaction; and in response to receiving the first additional information about the second payment transaction from the intermediary involved in the second transaction, updating the display of second transaction information about the second payment transaction to include the first additional information about the second payment transaction.

181. The electronic device of any one of claims 178 to 180, further configured to:

182. 182. The electronic device of any one of claims 178 to 181, wherein the first additional information includes an amount of the payment transaction.

183. The processing unit receiving second additional information; in response to receiving the second additional information related to the second payment transaction from the financial institution involved in the second transaction, updating the second transaction information related to the second payment transaction to include the second additional information related to the second payment transaction; 183. The electronic device of any one of claims 178 to 182, further configured to:

184. 184. The electronic device of claim 183, wherein the second additional information about the second payment transaction includes the name of a retailer that will receive payment as a result of the second payment transaction.

185. 185. The electronic device of any one of claims 178 to 184, wherein the first payment transaction was completed using the electronic device.

186. 186. The electronic device of any one of claims 178 to 185, wherein the first payment transaction is completed using a physical credit card associated with the payment account.

187. The processing unit receiving a text message from the financial institution; enabling the text message from the financial institution to be displayed over the corresponding representation of the payment account; receiving a selection of the displayed text message from the financial institution; In response to receiving a selection of the displayed text message from the financial institution, enabling a particular application associated with the financial institution to be displayed.

187. The electronic device of any one of claims 178 to 186, further configured to:

188. The processing unit 188. The electronic device of any one of claims 178 to 187, further configured to enable the corresponding representation of the payment account to display an available credit amount, the available credit amount representing the amount of available credit for the payment account based on the credit limit of the payment account.

189. The processing unit enabling an account details affordance to be displayed over the corresponding representation of the payment account; receiving a selection of the account details affordance; responsive to receiving a selection of the account details affordance, replacing a display of transaction details of the payment account with a display of the corresponding representation of the payment account; 189. The electronic device of any one of claims 178 to 188, further configured to:

190. The processing unit determining whether a specific application for accessing details of the associated payment account is installed on the electronic device; In accordance with a determination that the particular application is installed, making an open application affordance for accessing the particular application displayable on the transaction details.

190. The electronic device of claim 189, further configured as follows:

191. The processing unit receiving a selection of the open application affordance; responsive to receiving a selection of the open application affordance, completely replacing the display of the transaction details with a display of the particular application; 191. The electronic device of claim 190, further configured as follows:

192. The processing unit receiving a selection of the first transaction information of the displayed transaction details; and in response to receiving a selection of the first transaction information, completely replacing the display of the transaction details with a display of the particular application. further configured as follows:

191. The electronic device of any one of claims 178 to 190, wherein the display of the particular application includes details regarding the first payment transaction associated with the payment account.

193. the transaction details include further transaction affordances; The processing unit receiving a selection of the further transaction affordance; In response to receiving a selection of the further transaction affordance, enabling display, as part of the displayed transaction details, third transaction information related to a third payment transaction associated with the payment account.

193. The electronic device of any one of claims 189 to 192, further configured to:

194. the transaction details include a card removal affordance; The processing unit receiving a selection of the card removal affordance; In response to receiving a selection of the card removal affordance, displaying a confirmation request to remove the corresponding representation of the payment account from the electronic wallet; receiving a confirmation from the electronic wallet removing the corresponding representation of the payment account; removing the corresponding representation of the payment account from the electronic wallet; 194. The electronic device of any one of claims 189 to 193, further configured to:

195. the displayed electronic wallet includes a representation of a first stack of card objects and a second stack of card objects, the first stack of card objects being visually separated from the second stack of card objects; the first stack of card objects includes the corresponding representation of the payment account and a second corresponding representation of a second payment account; 195. The electronic device of any one of claims 189 to 194, wherein the second stack of card objects includes membership card objects associated with non-financial institutions.

196. 1. An electronic device comprising: A display unit; a processing unit coupled to the display unit; The processing unit comprises: enabling the display unit to display a user interface of a first application, the user interface of the first application including a payment affordance associated with a payment transaction; Detecting a selection of the payment affordance; In response to detecting a selection of the payment affordance, transferring first transaction information relating to the payment transaction from the first application to a second application; enabling a user interface of the second application to be displayed on the display; wherein the user interface of the second application includes the first transaction information received from the first application and includes second transaction information provided by the second application, and the second transaction information is not available to the first application.

197. The processing unit receiving a selection of a first purchase details affordance displayed on the user interface of the second application, the first purchase details affordance being associated with first purchase details of the payment transaction; In response to receiving a selection of the first purchase details affordance, displaying one or more affordances for selecting another value related to the first purchase details of the payment transaction; receiving a selection of another value for the first purchase detail of the payment transaction; updating the second transaction information to include the alternative value as the first purchase detail in response to receiving the selection of the alternative value; 197. The electronic device of claim 196, further configured as follows:

198. 200. The electronic device of claim 197, wherein the first purchase details of the payment transaction are part of the first transaction information from the first application.

199. 200. The electronic device of claim 197, wherein the first purchase details are part of the second transaction information provided by the second application.

200. 199. The electronic device of claim 197 or 198, wherein the first purchase detail is a shipping address.

201. 200. The electronic device of any one of claims 197 to 199, wherein the first purchase details are a payment account.

202. The processing unit receiving authorization to proceed with the payment transaction; responsive to receiving authorization to proceed with the payment transaction, forwarding the second transaction information to the first application.

202. The electronic device of any one of claims 196 to 201, further configured as follows:

203. The processing unit receiving authorization to proceed with the payment transaction; responsive to receiving authorization to proceed with the payment transaction, forwarding the first transaction information and the second transaction information to the first application.

202. The electronic device of any one of claims 196 to 201, further configured as follows:

204. 204. The electronic device of any one of claims 196 to 203, wherein the first application is a third-party application installed on the electronic device.

205. 204. The electronic device of any one of claims 196 to 203, wherein the first application comprises a website accessed by a web browser installed on the electronic device.

206. 206. The electronic device of any one of claims 196 to 205, wherein the second application is an operating system of the electronic device, and the second application has access to an electronic wallet containing the second transaction information.

207. 206. The electronic device of claim 196, wherein the second application is a first-party application provided by an operating system provider of the electronic device, and the second application has access to an electronic wallet containing the second transaction information.

208. 208. The electronic device of any one of claims 196 to 207, wherein the first transaction information includes an amount and a default shipping method.

209. 209. The electronic device of any one of claims 196 to 208, wherein the second transaction information includes a primary account number associated with a payment account.

210. 210. The electronic device of any one of claims 196 to 209, wherein the second transaction information includes a shipping address accessed from user contact information, the user contact information stored on the electronic device.

211. The processing unit 211. The electronic device of any one of claims 196 to 210, further configured to receive the authorization to proceed with the payment transaction before transferring the second transaction information to the first application.

212. The processing unit transferring zip code information from the second application to the first application, the first transaction information including an initial shipping cost based on the zip code information; receiving updated first transaction information; 212. The electronic device of any one of claims 196 to 211, further configured to: update the updated first transaction information to include a shipping cost based on the second transaction information.

213. receiving authorization to proceed with the payment transaction; detecting a corresponding fingerprint on a fingerprint sensor unit of the electronic device; responsive to detecting the corresponding fingerprint on the fingerprint sensor unit, determining whether the fingerprint matches a registered fingerprint to allow authorization of a payment transaction; authorizing the payment transaction in accordance with a determination that the corresponding fingerprint matches the enrolled fingerprint; withholding authorization of the payment transaction in accordance with a determination that the corresponding fingerprint does not match the enrolled fingerprint; 213. The electronic device of any one of claims 202 to 212, comprising:

214. The processing unit in response to a determination that the corresponding fingerprint does not match the enrolled fingerprint; and enabling the display unit to display an affordance for receiving authorization to proceed with the payment transaction using a payment passcode.

214. The electronic device of claim 213, further configured as follows:

215. The processing unit in response to a determination that the corresponding fingerprint does not match the enrolled fingerprint; determining whether a predetermined number of attempts have been made to receive authorization to proceed with the payment transaction using the fingerprint sensor unit; requiring authorization to proceed with the payment transaction using a payment passcode pursuant to a determination that the predetermined number of attempts to receive authorization has been reached.

215. The electronic device of claim 213 or 214, further configured to:

216. 216. The electronic device of claim 215, wherein the predetermined number of attempts is three.

217. The processing unit 217. The electronic device of any one of claims 196 to 216, further configured to enable the display unit to display a visual prompt instructing a user to place a finger on the fingerprint sensor unit in accordance with a determination that the corresponding fingerprint does not match the registered fingerprint.

218. receiving authorization to proceed with the payment transaction; receiving a payment passcode at the electronic device; determining whether the payment passcode matches a registered passcode that allows authorization of the payment transaction; authorizing the payment transaction in response to determining that the payment passcode matches the registered passcode; 218. The electronic device of any one of claims 202 to 217, comprising:

219. The processing unit 219. The electronic device of any one of claims 196 to 218, further configured to complete the payment transaction using the first application in response to transferring the first transaction information and the second transaction information from the second application to the first application.

220. 220. The electronic device of any one of claims 196 to 219, wherein a financial institution associated with processing the payment transaction treats the payment transaction as a card-present transaction.

221. 221. The electronic device of any one of claims 196 to 220, wherein displaying the user interface of the second application partially obscures the user interface of the first application, leaving at least a portion of the user interface of the first application visible.

222. 222. The electronic device of claim 196, wherein displaying the user interface of the second application comprises sliding the user interface of the second application vertically onto the display from a bottom of the display to partially obscure the user interface of the first application and leave at least a portion of the user interface of the first application visible.

223. The processing unit enabling the display unit to display a user interface of a third application, the user interface of the third application including a second payment affordance associated with a second payment transaction; Detecting a selection of the second payment affordance; In response to detecting a selection of the second payment affordance, transferring third transaction information relating to the second payment transaction from the third application to the second application; enabling a second user interface of the second application to be displayed on the display unit; 223. The electronic device of any one of claims 196 to 222, further configured such that the second user interface of the second application includes the third transaction information received from the third application and includes fourth transaction information provided by the second application, and the second transaction information is not available to the third application.

224. The processing unit Make the settings menu visible, receiving a selection of a default shipping address to be used as a default for the second transaction information; 224. The electronic device of any one of claims 196 to 223, further configured to:

225. The processing unit 225. The electronic device of any one of claims 196 to 224, further configured to receive a selection from among at least the payment account and a second payment account displayed in the settings menu, the selection specifying the default payment account to be used for payment transactions.

226. The processing unit Receive your transaction history display preferences, which will appear in the settings menu. determining whether the transaction history display preference is on; enabling a history of payment transactions to be displayed in accordance with a determination that the transaction history display preference is on; 226. The electronic device of any one of claims 196 to 225, further configured to:

227. The processing unit Receive your desired selection of transaction history types to be displayed in the settings menu, determining whether the desired transaction history type is a first type, a second type, or a third type; pursuant to a determination that the desired transaction history type is the first type, withholding display of a history of payment transactions related to the payment account; responsive to a determination that the desired transaction history type is the second type, enabling a history of payment transactions related to the payment account completed using only the electronic device to be displayed; In accordance with a determination that the transaction history type preference is the third type, enabling a history of payment transactions completed using the electronic device and a physical credit card for the payment account to be displayed.

227. The electronic device of any one of claims 196 to 226, further configured to:

Images