Pay with credit and debit cards within apps using Apple Pay
Apple Pay can also be used to make payments within iOS, iPadOS, and Apple Watch apps. When users pay within apps using Apple Pay, Apple receives the encrypted transaction information. 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 if the device supports Apple Pay and if 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, or watchOS to present the Apple Pay sheet, which requests information for the app, as well as 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 Touch ID, Face ID, or the device passcode. After the payment is authorized, the information presented in the Apple Pay sheet is transferred to the merchant.
App payment authorization
When the user authorizes the payment, a call is made to the Apple Pay servers to obtain a cryptographic nonce, which is similar to the value returned by the NFC terminal used for in-store transactions. The nonce, along with other transaction data, is passed to the Secure Element to generate a payment credential that is encrypted with an Apple key. When the encrypted payment credential comes out of the Secure Element, it’s passed to the Apple Pay servers, which decrypt the credential, verify the nonce in the credential against the nonce originally sent by the Apple Pay servers, and reencrypt the payment credential with the merchant key associated with the Merchant ID. The payment is then returned to the device, which hands it back to the app through the API. The app then passes it along to the merchant system for processing. The merchant can then decrypt the payment credential with its private key for processing. This, together with the signature from Apple’s servers, allows the merchant to verify that the transaction was intended for this particular merchant.
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.