Paying with cards using Apple Pay

Paying with cards in stores

If iPhone or Apple Watch is on and detects an NFC field and if Apple Wallet is set as the default Payments and Contactless app, the device presents the user with the requested card (if automatic selection is turned on for that card) or the default card from Apple Wallet (which is managed in Settings). The user can also go to Apple Wallet and choose a card or, when the device is locked, can:

• Double-click the side button on devices with Face ID (if Apple Wallet is the default app)

• Double-click the Home button on devices with Touch ID (if Apple Wallet is the default app)

• Using Accessibility features that allow Apple Pay from the Lock Screen

Next, before information is transmitted, the user must confirm their intent to pay and authenticate themselves using one of the following methods:

• Biometric authentication

• Device passcode or password

• Double-clicking the side button of an unlocked Apple Watch

No payment information is sent without user authentication.

After the user’s identity is verified, the Device Account Number and a unique security code are used to process the payment. Neither Apple nor the user’s device shares full card numbers with merchants. However, Apple may get anonymous data, like the transaction’s time and place. This information helps improve Apple Pay and other Apple services.

Paying with cards within apps

Apple Pay can also be used to make payments in iOS, iPadOS, macOS, watchOS, and visionOS apps. When users pay within apps using Apple Pay, Apple receives the encrypted transaction information to route to the specific developer or merchant to which the user is making a payment. Before that information is sent to the developer or merchant, Apple reencrypts the transaction with a developer-specific key. This is to help ensure that only an authorized developer with the key-pair can decrypt the information. Apple Pay retains anonymous transaction information, such as approximate purchase amount. This information can’t be tied to the user and never includes what the user is buying.

Besides the use of Apple Pay in stores, it also works within iOS, iPadOS, macOS, watchOS, and visionOS apps. When users pay in apps, Apple gets the encrypted transaction data. It then sends this data to the right developer or merchant. Before this, Apple reencrypts the data with a developer-specific key. This ensures that only authorized developers can access it. Apple Pay keeps anonymous data, like the purchase amount. However, this data isn’t linked to users and doesn’t reveal what they buy.

When an app initiates an Apple Pay payment transaction, the Apple Pay servers receive the encrypted transaction from the device prior to the merchant receiving it. The Apple Pay servers then reencrypt the transaction with a merchant-specific key before relaying it to the merchant.

When an app requests a payment, it calls an API to determine whether the device supports Apple Pay and whether the user has credit or debit cards that can make payments on a payment network accepted by the merchant. The app requests information it needs to process and fulfill the transaction, such as the billing and shipping address, and contact information. The app then asks iOS, iPadOS, macOS, watchOS, or visionOS to present the Apple Pay. This sheet then requests information for the app and other necessary information, such as the card to use.

At this time, the app is presented with city, state, and postal code information to calculate the final shipping cost. The full set of requested information isn’t provided to the app until the user authorizes the payment using one of the following methods:

• Biometric authentication

• Device passcode or password

• Double-clicking the side button of an unlocked Apple Watch

After the payment is authorized, the information presented in the Apple Pay sheet is transferred to the merchant.

Paying with cards within App Clips

An App Clip is a small part of an app that allows a user do a task quickly (such as renting a bike or paying for parking) without downloading the full app. If the App Clip supports payments, the user can use Sign in with Apple (if configured by the app developer) and then make a payment using Apple Pay. When a user makes a payment from within an App Clip, all security and privacy measures are the same as when a user pays within an app.

How users authorize, and merchants verify, app payments

Users and merchants ensure secure app payments by passing information to the Apple Pay servers, the Secure Element, the device, and the app’s API. First, the user authorizes an app payment. The app then requests a cryptographic anti-replay value from the Apple Pay servers. The servers send this value and other transaction data to the Secure Element, which creates a payment credential, one that’s encrypted with an Apple key. The Secure Element then returns the payment credential to the Apple Pay servers, so that they can decrypt it, verify its anti-replay value against the anti-replay value that the Apple Pay servers originally sent, and reencrypt it with the merchant’s key. The servers then return the payment to the device, which hands it back to the app API, with the API passing it along to the merchant system for processing. Finally, the merchant verifies the payment credential to confirm the transaction.

The APIs require a Merchant ID Entitlement that specifies the supported Merchant IDs. An app can also include additional data (such as an order number or customer identity) to send to the Secure Element to be signed, ensuring that the transaction can’t be diverted to a different customer. This is accomplished by the app developer, who can specify application-specific data (applicationData) on the request for payment. A hash of this data is included in the encrypted payment data. The merchant is then responsible for verifying that their applicationData hash matches what’s included in the payment data.

Paying with cards at websites

Apple Pay can be used to make payments at websites with the following:

• Devices that use biometric authentication

• Apple Watch

• Mac computers with Apple silicon that use the Magic Keyboard with Touch ID

Apple Pay transactions can also start on a Mac and be completed on an Apple Pay–enabled iPhone or Apple Watch using the same iCloud account. If the user is transmitting payment-related information this way, Apple Pay Handoff uses the end-to-end encrypted Apple Identity Service (IDS) protocol to transmit payment-related information between the user’s Mac and the authorizing device. The IDS client on Mac uses the user’s device keys to perform encryption so no other device can decrypt this information. These keys aren’t available to Apple.

Device discovery for Apple Pay Handoff contains the type and unique identifier of the user’s credit cards along with some metadata. The Device Account Number of the user’s card isn’t shared, and it continues to remain stored securely on the user’s iPhone or Apple Watch. Apple also securely transfers the user’s recently used contact, shipping, and billing addresses over iCloud Keychain.

After the user authorizes a payment, a payment token—uniquely encrypted to each website’s merchant certificate—is securely transmitted from the user’s iPhone or Apple Watch to their Mac and then delivered to the merchant’s website.

Apple Pay on the web also requires that all participating websites register with Apple. After the domain is registered, domain name validation is performed only after Apple issues a TLS client certificate. Websites supporting Apple Pay are required to:

• Serve their content over HTTPS

• Obtain a secure and unique merchant session (for each payment transaction) with an Apple server using the Apple-issued TLS client certificate

Merchant session data is signed by Apple. After a merchant session signature is verified, a website may query whether the user has an Apple Pay–capable device and whether they have a credit, debit, or prepaid card activated on the device. No other details are shared. If the user doesn’t want to share this information, they can disable Apple Pay queries in Safari privacy settings on iPhone, iPad, and Mac devices.

If the website is using the latest version of the Apple Pay JS SDK, then Apple Pay transactions can also be started using any third-party web browser on any operating system, and be completed on an Apple Pay-enabled iPhone or iPad with iOS 18, iPadOS 18, or later. For this to occur, a code must be scanned using the device’s camera to establish a connection with the website. When the website presents this code, a secure WebSocket connection is made between the website and Apple’s servers. Upon scanning this code, an additional separate secure WebSocket connection is made between the Apple Pay-enabled device and Apple’s servers. This completes the bidirectional connection required between the website and Apple Pay-enabled device, using Apple’s servers as a relay. Any communication made between these two parties then follows the usual process for Apple Pay web transactions.

After a merchant session is validated, all privacy and security measures are the same as when a user pays within an app.

Automatic payments and Merchant Tokens

Devices with iOS 16, iPadOS 16, macOS 13, or later, can use Apple Pay merchant tokens, which ensure secure payments across a user’s devices. The updated Apple Pay payment sheet optimizes preauthorized payments. The Apple Pay API also supports new transaction types, allowing developers to customize the payment sheet for specific uses, such as subscriptions, recurring bills, installment payments, and automatic reloading of card balances.

Merchant tokens aren’t device specific, and therefore allow for continuity of recurring payments if the user removes a payment card from the device.

Payments to multiple merchants

In iOS 16 or later, Apple Pay includes the ability to specify purchase amounts for multiple merchants within a single Apple Pay payment sheet. This allows the flexibility to let customers make a bundled purchase, such as a travel package with flight, rental car, and hotel, then send payments to individual merchants.