Paying with cards using Apple Pay
Apple Pay can be used to pay for purchases in stores, within apps, and at websites.
Paying with cards in stores
If iPhone or Apple Watch is on and detects an NFC field, it presents the user with the requested card (if automatic selection is turned on for that card) or the default card, 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
Double-click the Home button on devices with Touch ID
Using Accessibility features that allow Apple Pay from the Lock Screen
Next, before information is transmitted, the user must authenticate using Face ID, Touch ID, or their passcode. When Apple Watch is unlocked, double-clicking the side button activates the default card for payment. No payment information is sent without user authentication.
After the user authenticates, the Device Account Number and a transaction-specific dynamic security code are used when processing the payment. Neither Apple nor a user’s device sends the full credit or debit card numbers to merchants. Apple may receive anonymous transaction information such as the approximate time and location of the transaction, which helps improve Apple Pay and other Apple products and services.
Paying with cards within apps
Apple Paycan also be used to make payments in iOS, iPadOS, macOS, and watchOS apps. When users pay within apps using Apple Pay, Apple receives the encrypted transaction information to route to the developer or merchant. Before that information is sent to the developer or merchant, Apple reencrypts the transaction with a developer-specific key. 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.
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 any pieces of 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, or watchOS to present the Apple Pay sheet, which 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 zip 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 with Face ID, Touch ID, or the device passcode. 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 an App Clip supports payments, the user can use Sign in with Apple, 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 servers, the Secure Element, the device, and the app’s API. First, when the user authorizes an app payment, the app obtains a cryptographic anti-relay value by calling the Apple Pay servers. The servers send this value and other transaction data to the Secure Element, to compute 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 ID’s associated merchant key. The Apple 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. The merchant decrypts the payment credential to verify that it’s the correct recipient of the transaction.
The APIs require an 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 applicationData on the PKPaymentRequest. 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 on iPhone, iPad, Apple Watch, and Mac computers 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.
Apple Pay on the web 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. For each payment transaction, websites need to obtain a secure and unique merchant session 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.
After a merchant session is validated, all privacy and security measures are the same as when a user pays within an app.
If the user is transmitting payment-related information from a Mac to an iPhone or Apple Watch, 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, and the 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 using Face ID, Touch ID, a passcode, or double-clicking the side button on Apple Watch, 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.
Only devices in proximity to each other may request and complete payment. Proximity is determined through Bluetooth Low Energy (BLE) advertisements.
Automatic payments and Merchant Tokens
In iOS 16 or later, apps and websites that offer Apple Pay can take advantage of Apple Pay merchant tokens that enable secure payments consistently across a user’s devices. The updated Apple Pay payment sheet in iOS 16 also optimizes preauthorized payment experiences. New transaction types in the Apple Pay API allow app and website developers to fine-tune the payment sheet experience for subscriptions, recurring bills, installment payments, and automatic reloads of card balances.
Merchant tokens are not 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.