When you tap “Pay with Apple Pay,” what happens behind the scenes to keep your transaction secure?
From session validation to token decryption, Apple Pay follows a multi-layered security process that protects your payment details without exposing sensitive card information.
But how exactly does it work, and why is it considered one of the safest payment methods available?
This article breaks down Apple Pay’s payment flow step by step, explaining each security measure in detail. Whether you’re a developer integrating Apple Pay, a merchant ensuring secure transactions, or a security enthusiast curious about encryption, this guide will walk you through everything from session validation to token decryption — so you can understand what makes Apple Pay both seamless and secure.
The Apple Pay payment flow involves four key players:
- 🧑 User (Customer making the payment)
- 🏪 Merchant (Website or app accepting the payment)
- 🍏 Apple (Handles Apple Pay session validation & token encryption)
- 💳 Payment Processor (Decrypts the token and completes the transaction)
1. User Initiates Payment
The user selects Apple Pay as the payment method on the merchant’s website or app and clicks the “Pay with Apple Pay” button.
2. Merchant Requests Apple Pay Session Validation
Before displaying the Apple Pay payment sheet, the merchant must validate its session with Apple. This process ensures that only authorized merchants can initiate Apple Pay transactions.
To do this, the merchant’s server (not the client) sends a validation request to Apple’s Payment Session endpoint. This request must be secured using mutual TLS (mTLS) — a protocol where both the client and server authenticate each other to establish a trusted connection. Unlike standard TLS, which only verifies the server, mTLS adds an extra layer of security by requiring both parties to prove their identities, preventing unauthorized access.
The validation request includes key details such as:
- Merchant identifier (to verify the business)
- Store name (displayName) (to display on the Apple Pay sheet)
- Domain or app context (initiativeContext) (to confirm the transaction source)
Apple provides a dynamically generated validation URL for each session, and the request must be sent to this specific endpoint. Once verified, Apple responds with a merchant session object, allowing the transaction to proceed.
3. Apple Returns Merchant Session Object
Apple verifies the request, ensuring that the merchant’s identity certificate is valid. If successful, Apple responds with a merchant session object, which:
- Authorizes the merchant to proceed with the payment.
- Expires after five minutes, requiring a new request if not used in time.
3.5 Merchant Passes Session to Apple Pay UI
To finalize the validation, the merchant:
- Calls the completeMerchantValidation(merchantSession) method in JavaScript.
- Passes the session object received from Apple.
- Enables the Apple Pay payment sheet to appear on the user’s screen.
4. User Authorizes Payment on Apple Pay Sheet
With the session validated, the Apple Pay payment sheet appears. The user selects a card and confirms the payment using Face ID, Touch ID, or Passcode.
5. Apple Generates Encrypted Payment Token
Once the user authorizes the transaction, Apple generates a payment token containing the transaction details. This token is encrypted for security and then sent to the merchant.
6. Merchant Sends Token for Decryption
Once the merchant receives the encrypted Apple Pay token, it forwards the token to a PCI-compliant payment processor or payment gateway for secure decryption and transaction processing. The merchant itself does not decrypt the token.
7. Payment Processor Decrypts Token and Processes Payment
Before decrypting the Apple Pay token, the payment processor performs multiple security checks to ensure the transaction’s authenticity and integrity:
- Signature Verification — The processor validates the Apple Pay token by checking the certificate chain and verifying its digital signature using ECDSA (Elliptic Curve Digital Signature Algorithm) or RSA (Rivest–Shamir–Adleman). Both cryptographic algorithms create digital signatures to ensure data integrity and authenticity. While RSA relies on integer factorization, ECDSA is based on elliptic curve cryptography, allowing for shorter key lengths with comparable security.
- Replay Attack Prevention — The processor compares the transaction timestamp with the signing time, rejecting any tokens older than five minutes to prevent replay attacks.
- Symmetric Key Decryption — To decrypt the token, the processor uses the merchant’s private key along with Apple’s encryption scheme: AES-256-GCM for ECC-based transactions and AES-128-GCM for RSA-based transactions. Encryption schemes like these protect sensitive data by transforming it into ciphertext, ensuring only authorized parties can decode it.
- Transaction Integrity Check — Finally, the processor verifies that the decrypted payment details — including the amount, currency, and application data — match the original request, preventing tampering or unauthorized modifications.
Once these security measures are completed, the processor extracts the necessary card details and securely forwards the transaction request to the appropriate card network (Visa, Mastercard, etc.) for approval.
8. Payment Confirmation Sent Back to Merchant and User
If the transaction is approved, the payment processor notifies the merchant, who then confirms the successful payment to the user (9). The purchase is now complete. ✅
Apple Pay’s security measures — spanning session validation, encryption, and decryption — demonstrate how modern payment systems protect sensitive data while maintaining a seamless user experience.
But security doesn’t stop here.
In our next articles, we’ll explore how tokenization enhances security beyond Apple Pay, the role of PCI compliance in safeguarding transactions, and how emerging threats like quantum computing might challenge existing encryption methods.
Stay tuned as we continue to break down the evolving landscape of digital payments and cybersecurity.