Mobile Development 16 min read

Integrating Apple Pay in iOS Apps: Process, Security, and Practical Considerations

This article provides a comprehensive overview of Apple Pay integration on iOS, covering the end‑to‑end payment flow, Apple’s security mechanisms, certificate preparation, differences between domestic and international implementations, and practical tips for developers to avoid common pitfalls.

Ctrip Technology
Ctrip Technology
Ctrip Technology
Integrating Apple Pay in iOS Apps: Process, Security, and Practical Considerations

Apple Pay, launched by Apple in 2014 and supported on iOS 8, added UnionPay support in iOS 9, quickly gaining traction in the Chinese market due to its security, simplicity, and easy integration.

Ctrip was among the first Chinese merchants to adopt Apple Pay, and its international app now also supports the service, continuously expanding supported countries, currencies, and payment channels.

1. Apple Pay Overall Process

The diagram below shows a typical domestic Apple Pay flow (UnionPay API mode). The steps are:

Client displays the Apple Pay payment button using Apple’s API.

User authenticates via Touch ID, Face ID, or device passcode.

After successful authentication, Apple generates an encrypted PaymentToken containing the selected card information; this requires network connectivity and Apple’s public key.

Client sends the PaymentToken to the backend.

Backend decrypts the token, extracts key fields, adds order details, and forwards the request to the payment provider (e.g., UnionPay) for charging.

Backend receives the charge result and returns the payment outcome to the client.

2. Apple’s Security Guarantees

During card binding in the iOS Wallet app, the user’s real card number is replaced by a device‑specific virtual card number, which appears in the decrypted PaymentToken . This virtual number changes each time the card is re‑bound, ensuring that the real PAN never traverses the network.

Apple also provides special APIs that allow certain bank apps to bind cards directly within the Wallet, but these require separate authorization from Apple.

2.1 Apple Pay Card Binding

The virtual card number (device card number) is the identifier sent to the payment provider for settlement.

2.2 Data Encryption

Payment tokens are encrypted JSON objects. Outside China, Apple uses ECC encryption; in China, RSA encryption is employed. The token consists of data , header , signature , and version fields.

Example of an ECC‑encrypted token:

{
  "data":"H22hDxsaFP8JZCuLf6AYu99IB2rLvRbQaZ/...",
  "header":{
    "ephemeralPublicKey":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEBZITXjr/...",
    "publicKeyHash":"KjwaMOiXIeoSDyLEz5TDPl3uXAVcwZ2f5/...",
    "transactionId":"2e9d75661d1641d188d4e646901fe708836b5a5ac7c705c15915b27e23786488"
  },
  "signature":"MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEF...",
  "version":"EC_v1"
}

After decrypting the ECC data field, the payload contains fields such as applicationPrimaryAccountNumber , currencyCode , transactionAmount , and an emvData block.

In China, the token uses RSA + AES. The data field is AES‑encrypted, while the AES key is wrapped in the header.wrappedKey and protected with RSA.

Example of a RSA‑encrypted token:

{
  "data":"juTLgE+0gQPg3RSe5DdJj1/...",
  "header":{
    "publicKeyHash":"YcmdtTV209LCGVZV99T0lNab3yo0KnudAyBKQPo+5e8=",
    "transactionId":"41a6eb8dd8602def5f41463ad314e484289258df71ab17b50204ea4795a3db52",
    "wrappedKey":"l6w4oBmvLF/f/6Gj7idhO5aIFlwZ5qZrqSLxR+mLqsjJqHLf2OUTObn+UOO/..."
  },
  "signature":"MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEF...",
  "version":"RSA_v1"
}

Decrypted Chinese token data reveals the deviceManufacturerIdentifier , which corresponds to the virtual card number needed by the payment provider.

3. Payment Providers

Payment providers (e.g., UnionPay in China, Adyen or SoftBank internationally) handle the actual charge by communicating with issuing banks. They receive the virtual card number and other transaction details from the backend.

4. Client‑Side Development of Apple Pay

Key tasks for iOS developers include:

Preparing the Apple Pay certificate (CSR generation, upload to Apple Developer portal).

Configuring the Xcode project (enabling the Apple Pay capability and selecting the correct Merchant ID).

Calling the Apple Pay APIs (requesting payment, handling callbacks).

4.1 Certificate Preparation

Developers generate a Certificate Signing Request (CSR) using the macOS Keychain app, then upload it to Apple’s developer site to obtain the Apple Pay certificate. For China, the CSR must use RSA; for other regions, ECC is required.

4.2 Project Configuration and Certificate Usage

Each Apple Pay certificate is linked to a Merchant ID. The Merchant ID must be supplied when invoking the Apple Pay API; it is recommended to deliver it from the backend rather than hard‑coding it in the app.

In Xcode, enable the Apple Pay capability under the target’s Capabilities tab and select the appropriate Merchant ID; otherwise the built IPA cannot launch the Apple Pay sheet.

Certificates expire after about two years; renewal involves uploading a new CSR, activating the new certificate, and optionally revoking the old one. During renewal, the backend should temporarily disable Apple Pay to avoid payment failures.

5. Differences Between Domestic and International Apple Pay Integration

Initially Ctrip used UnionPay’s SDK, which simplified client integration but added significant binary size, limited flexibility, and required the SDK’s CSR‑generated certificates.

Later Ctrip switched to an API‑based integration, giving the merchant full control over certificates, keys, and UI, and allowing support for multiple currencies and providers (e.g., Adyen, SoftBank). International integrations use ECC certificates, while the Chinese UnionPay integration uses RSA.

In the international version, the app receives the appropriate MerchantId from the backend based on currency and payment channel, enabling dynamic selection of Visa, MasterCard, etc.

6. Summary

Integrating Apple Pay on iOS is more than a simple API call; developers must consider user interactions, error handling, certificate management, and security. A robust design that anticipates cancellations, duplicate submissions, and amount verification is essential for a safe and seamless payment experience.

Apple’s tightly coupled ecosystem—client, server, issuing banks, payment providers, and Apple itself—demonstrates a strong emphasis on security and user experience, offering valuable lessons for any mobile payment implementation.

iOSsecurityCertificatePayment IntegrationApple Paymobile payments
Ctrip Technology
Written by

Ctrip Technology

Official Ctrip Technology account, sharing and discussing growth.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.