Узнайте, что такое Apple Pay в мобильных приложениях, как он работает «за кулисами» и как безопасно интегрировать его, чтобы ускорить оформление заказа и повысить конверсию.
Apple Pay — цифровой кошелёк и платёжный сервис Apple. Он позволяет пользователям безопасно хранить кредитные, дебетовые, а также некоторые предоплаченные и магазинные карты на iPhone, Apple Watch, iPad или Mac и платить единым касанием или взглядом.
Вместо ввода номеров карт и данных для выставления счёта пользователь аутентифицируется через Face ID, Touch ID или код устройства. Apple генерирует уникальный для устройства токен, поэтому реальный номер карты не передаётся продавцу.
Apple Pay работает в трёх основных сценариях:
Этот гид фокусируется на встраивании Apple Pay в приложение, где весь опыт оплаты остаётся внутри приложения.
Ввод данных карты на маленьком экране медленный и склонен к ошибкам. Apple Pay заменяет множество полей формы одним действием, что обычно:
Так как карты и адреса уже хранятся на устройстве, Apple Pay снижает трение и для новых покупателей.
Apple Pay доступен на современных моделях iPhone, iPad, Apple Watch и Mac в поддерживаемых регионах с крупными сетями, такими как Visa, Mastercard, American Express, а также многими локальными схемами в зависимости от банка‑эмитента.
Apple Pay особенно уместен, если:
Он должен существовать рядом с традиционными формами карт и другими кошельками, а не полностью их заменять, чтобы пользователи без Apple Pay могли оплатить покупку.
Apple Pay скрывает много сложности за простым интерфейсом «двойное нажатие для оплаты». Внутри несколько участников и уровней безопасности координируют безопасное перемещение средств.
Типичная транзакция Apple Pay включает:
Когда пользователь добавляет карту в Apple Wallet, реальный номер карты (FPAN, Funding Primary Account Number) передаётся безопасно в платёжную сеть и эмитент. В ответ они выдают DPAN (Device Primary Account Number) и криптографические ключи, уникальные для этого устройства.
DPAN используется Apple Pay при транзакциях. Ваше приложение и бэкенд никогда не видят FPAN. Это суть модели токенизации Apple Pay: устройство использует заместительный номер карты и одноразовые криптограммы вместо раскрытия реального номера.
На поддерживаемых устройствах платёжные реквизиты и ключи хранятся в Secure Element (или защищаются через Secure Enclave). Когда пользователь проходит аутентификацию (Face ID, Touch ID или код устройства), Secure Element:
Приложение получает этот непрозрачный, зашифрованный токен через API Apple Pay и отправляет его на бэкенд, который пересылает его PSP или шлюзу.
PSP расшифровывает токен, извлекает DPAN и криптограмму и отправляет запрос на авторизацию через платёжную сеть в банк‑эмитент. Эмитент проверяет криптограмму и состояние карты, затем одобряет или отклоняет транзакцию.
Позже, при расчёте (settlement), авторизованная сумма захватывается, группируется и переводится от банка‑эмитента к эквайеру продавца. Для вашего приложения это просто завершение оплаты, но за сценой это координация между эквайером, платёжной сетью и эмитентом с использованием DPAN — а не реального номера карты покупателя.
Прежде чем добавить Apple Pay в приложение, нужно выполнить ряд технических, бизнес‑ и региональных условий.
Со стороны продавца требуется:
Многие продавцы также создают Merchant Identity certificate для валидации продавца в веб‑или гибридных сценариях.
Apple Pay в приложениях поддерживается на:
Проверяйте текущую документацию Apple для минимальной поддерживаемой версии OS, особенно если вы используете новые API.
Apple Pay недоступен во всех странах и не у всех банков. Подтвердите:
Apple может ограничивать некоторые категории продавцов и сценарии использования (например, незаконные товары, некоторые цифровые контенты или сферы с повышенным риском). Проверьте:
Наконец, нужен PSP или платёжный шлюз, который поддерживает токенизацию Apple Pay и расшифровку. Убедитесь, что ваш провайдер:
Плавный поток с Apple Pay почти незаметен для пользователя. Вот типичный пошаговый сценарий.
Пользователь обычно начинает на странице товара или в корзине. После выбора опций (размер, цвет, количество) он переходит к оформлению.
На экране оформления или корзины покажите стандартную кнопку Apple Pay, предоставленную Apple. Она должна:
При нажатии кнопки лист Apple Pay выезжает снизу экрана.
В листе обычно отображается:
Пользователь может изменить карту, адрес или контакты прямо в листе перед подтверждением.
Для подтверждения платежа пользователь аутентифицируется через:
Лист подсказывает, например: «Double‑click to pay» на устройствах с Face ID.
После аутентификации лист показывает прогресс и закрывается, возвращая пользователя в приложение.
Приложение должно сразу показать одно из состояний:
Понятные и последовательные состояния успокаивают пользователя и дают ясность по статусу оплаты.
Реализация Apple Pay на iOS сосредоточена вокруг фреймворка PassKit и нескольких ключевых классов. Ниже — порядок действий на уровне приложения.
Это связывает bundle‑идентификатор приложения с вашим Merchant ID, чтобы Apple Pay‑токены могли быть сгенерированы для вашего сервера.
PKPaymentRequestimport PassKit
func createPaymentRequest() -> PKPaymentRequest? {
guard PKPaymentAuthorizationController.canMakePayments() else { return nil }
let request = PKPaymentRequest()
request.merchantIdentifier = "merchant.com.yourcompany.app"
request.countryCode = "US"
request.currencyCode = "USD"
request.supportedNetworks = [.visa, .masterCard, .amex]
request.merchantCapabilities = [.capability3DS]
request.paymentSummaryItems = [
PKPaymentSummaryItem(label: "Pro Subscription", amount: 9.99),
PKPaymentSummaryItem(label: "Your Company", amount: 9.99)
]
return request
}
merchantIdentifier, countryCode и currencyCode должны соответствовать настройкам мерчанта. supportedNetworks отражает схемы карт, которые поддерживаете вы и ваш PSP. По минимуму включите .capability3DS в merchantCapabilities.
PKPaymentButtonИспользуйте PKPaymentButton, а не кастомные кнопки, чтобы соответствовать гайдам Apple:
let payButton = PKPaymentButton(paymentButtonType: .buy, paymentButtonStyle: .black)
Размещайте кнопку там, где сила намерения купить максимальна: страница товара, корзина и финальный экран оформления. Отключайте или скрывайте её, если PKPaymentAuthorizationController.canMakePayments() возвращает false.
PKPaymentAuthorizationController и обработайте колбэкиСоздайте контроллер из запроса и реализуйте PKPaymentAuthorizationControllerDelegate:
func startApplePay() {
guard let request = createPaymentRequest() else { return }
let controller = PKPaymentAuthorizationController(paymentRequest: request)
controller.delegate = self
controller.present(completion: nil)
}
extension CheckoutViewController: PKPaymentAuthorizationControllerDelegate {
func paymentAuthorizationController(_ controller: PKPaymentAuthorizationController,
didAuthorizePayment payment: PKPayment,
handler completion: @escaping (PKPaymentAuthorizationResult) -> Void) {
// Send payment.token to your server for processing
// Then call completion(.init(status: .success, errors: nil)) or .failure
}
func paymentAuthorizationControllerDidFinish(_ controller: PKPaymentAuthorizationController) {
controller.dismiss(completion: nil)
}
}
В didAuthorizePayment вы передаёте payment.token на сервер для фактического списания. После ответа сервера вызовите .success или .failure, затем закройте лист в paymentAuthorizationControllerDidFinish.
Серверная логика превращает лист Apple Pay в реальное движение денег. Приложение собирает авторизацию пользователя; ваш бэкенд валидирует мерчанта, обрабатывает токен и общается с платёжным шлюзом.
Перед показом Apple Pay‑листа приложение должно получить merchant session от Apple:
PKPaymentAuthorizationController.Этот поток доказывает Apple, что приложение связано с вашим мерчант‑идентификатором и доменом.
После авторизации приложение получает зашифрованный платёжный токен (PKPaymentToken) и отправляет его на сервер через HTTPS.
На сервере:
Шлюз расшифровывает токен (с помощью сетевых токенов или DPAN) и выполняет авторизацию карты через платёжные сети.
Шлюзы обычно предоставляют два сценария:
Сервер должен сохранять ID транзакции шлюза, сумму, валюту и статус — но не сырые данные карт или расшифрованные содержимые токена.
Храните только то, что нужно для сверки, возвратов и поддержки:
Никогда не храните полные номера карт, CVV или незашифрованные платёжные токены на своих серверах. Передавайте чувствительную обработку PCI‑соответствующим шлюзам и обеспечьте TLS, строгие логи и контроль доступа.
Apple Pay спроектирован так, чтобы приложение не касалось сырых номеров карт, но вы всё равно несёте ответственность за модель безопасности и свои обязанности.
При добавлении карты в Apple Pay эмитент и сеть заменяют реальный PAN (номер карты) на Device Account Number (DAN).
В платеже:
Ваше приложение и бэкенд видят только токены и метаданные транзакций, а не исходные данные карт.
Чувствительные ключи и платёжные реквизиты хранятся и обрабатываются внутри Secure Enclave — аппаратно изолированного сопроцессора.
Авторизация связана с верификацией пользователя: Face ID / Touch ID или код устройства. Приложение получает лишь сигнал об успехе или неуспехе — ни биометрические данные, ни содержимое Secure Enclave недоступны приложению.
Каждая транзакция Apple Pay использует:
Сети и эмитенты проверяют эти значения, что помогает обнаруживать клонирование, повторное воспроизведение и манипуляции.
Apple Pay может значительно сократить область действия PCI DSS вашего приложения, потому что:
Однако:
За формальными консультациями обращайтесь к эквайеру, PSP и квалифицированному оценщику безопасности.
Apple Pay снижает риск, но небрежная интеграция может вернуть уязвимости.
Практические советы:
Соблюдая эти принципы, вы используете встроенные защиты Apple Pay и одновременно держите свою зону соответствия под контролем.
Тщательное тестирование — единственный путь быть уверенным, что интеграция Apple Pay корректна. Начните с настроек sandbox и плана тестов.
В аккаунте Apple Developer / App Store Connect создайте sandbox‑тестовые аккаунты в разделе Users and Access → Sandbox. Эти Apple ID используются на тестовых устройствах для имитации реальных пользователей без списания реальных денег.
На тестовых устройствах:
Используйте разные sandbox‑аккаунты для различных профилей пользователей (регионы, валюты, схемы карт), чтобы воспроизводить граничные случаи.
iOS Simulator поддерживает базовое тестирование Apple Pay, полезное для быстрой проверки UI и ранней разработки. Можно симулировать авторизацию и проверить, что поток PKPaymentAuthorizationController работает.
Однако всегда проверяйте на реальных устройствах, потому что только они дают:
Рассматривайте симулятор как удобство, но не замену.
Покройте как минимум следующие сквозные сценарии (клиент и сервер):
Используйте тестовые номера карт и триггеры шлюза, чтобы форсировать отказы и коды ошибок.
Логируйте достаточно для трассировки проблем, но никогда не логируйте чувствительные данные. Избегайте:
Логируйте вместо этого:
created → authorized → captured → failed)Коррелируйте клиентские и серверные логи через общий correlation ID, передаваемый из приложения на бэкенд.
Во время тест‑циклов следите за:
Если видите прерывистые ошибки или медленные авторизации, проверьте статус шлюза и Apple, прежде чем искать баги в коде — это экономит время и силы.
Продуманная интеграция Apple Pay может превратить «приятную фичу» в реальный драйвер конверсии. Небольшие решения по размещению и текстам сильно влияют на выбор пользователей.
Используйте Apple Pay там, где намерение купить наиболее высоко:
Не прячьте Apple Pay за дополнительными нажатиями вроде «Другие способы оплаты». Каждый лишний шаг уменьшает использование.
Предлагайте Apple Pay как express‑checkout с:
Когда используете express‑checkout, ясно укажите, что детали доставки и контакты будут обработаны в Apple Pay‑листе.
Следуйте Human Interface Guidelines Apple:
Дайте Apple Pay делать основную работу:
Цель — один решающий тап, а не многоэкранный воронка.
Планируйте понятные состояния ошибок:
Логи ошибок должны быть подробными для инженеров, но пользователю показывайте только необходимую и понятную информацию.
Большинство проблем с Apple Pay вызваны неверной конфигурацией.
Проверьте, что Merchant ID в коде точно совпадает с тем, что в Apple Developer и в настройках платёжного шлюза. Одна лишняя или пропущенная буква (или использование sandbox‑ID в проде) сломает поток.
Проверьте entitlements и capabilities:
Если кнопки Apple Pay не отображаются или лист не появляется, сначала ищите проблемы в конфигурации.
Apple Pay может быть доступен в одних странах/банках, но не в других.
Используйте PKPaymentAuthorizationController.canMakePayments() и canMakePayments(usingNetworks:) перед показом кнопки. Если они возвращают false, скрывайте кнопку и давайте понятное объяснение с альтернативой.
Если пользователи жалуются, что карта «не поддерживается», проверьте:
Ошибки валидации мерчанта проявляются как быстро закрывающийся лист Apple Pay или его неотображение.
Частые причины для нативных приложений:
На сервере логируйте:
Эти логи обычно указывают на конкретный элемент с неправильной настройкой.
Не все отказы технические; многие — отказы эмитентов.
Всегда смотрите ответы шлюза и разделяйте:
Сообщайте пользователям понятные фразы типа:
Не показывайте пользователю сырые коды ошибок шлюза.
Для стабильности Apple Pay в проде инвестируйте в структурированные логи вокруг каждой попытки оплаты:
Настройте дашборды и алерты на всплески отказов, ошибок в валидации мерчанта или таймаутов. Коррелируйте клиентские события и серверные логи, чтобы быстро находить узкие места.
Такой уровень наблюдаемости существенно сокращает время на поиск и исправление проблем в реальном трафике.
После запуска Apple Pay в приложении нужно доказать, что он действительно улучшает оформление, а не только выглядит современно. Отслеживайте нужные события, метрики и проводите контролируемые эксперименты.
Фиксируйте события в каждом шаге воронки:
Коррелируйте эти события с контекстом:
Это показывает, где пользователи отпадают и связаны ли отказы с UX (отмена) или бэкендом (ошибка захвата).
Фокусированный набор метрик упрощает оценку:
Отслеживайте по версиям приложения и во времени, чтобы понять влияние изменений UX и интеграции.
Проводите эксперименты, чтобы оптимизировать эффект Apple Pay:
Измеряйте принятие, успех, время до оплаты и конверсию — даже небольшие изменения макета могут дать значительный эффект.
Интегрируйте аналитику так, чтобы сохранять приватность и гарантии Apple Pay:
Крупные платформы аналитики (Mixpanel, Amplitude, Firebase) подходят для этих событий, если убираются чувствительные поля.
Инсайты из Apple Pay полезны и за его пределами:
Со временем эти метрики помогают улучшить не только Apple Pay, но весь процесс оформления, делая каждый шаг быстрее, понятнее и надёжнее.
Поддержка Apple Pay редко ограничивается одним iOS‑приложением. Пользователи ожидают единый опыт оплаты на разных устройствах и каналах.
Нативные приложения используют PKPaymentAuthorizationController и передают токены напрямую на бэкенд. Это даёт:
Apple Pay в вебе (Safari) использует JavaScript и Payment Request API. Это удобно, если:
Для многих команд оптимальным будет: нативный Apple Pay в приложении, Apple Pay на вебе в Safari и общий бэкенд‑пайтлайн для платежей.
Если вы поддерживаете Google Pay, PayPal и др., согласуйте общий высокий уровень потока:
Так переход между устройствами и методами не будет ощущаться как новый неочевидный процесс.
Для React Native, Flutter и подобных фреймворков обычно используют:
Тестируйте на iPhone, iPad и Apple Watch (если актуально):
Стремитесь к общей системе дизайна и логике оформления, с тонкими платформенными интеграциями вместо разрозненных реализаций.
Поддерживать Apple Pay проще, если делать это через дисциплинированное обслуживание, а не масштабные переписывания.
Apple Pay опирается на Merchant ID и сертификаты для обработки платежей, которые истекают.
Создайте карту владения: кто управляет Apple Developer аккаунтом, где хранятся сертификаты и как их используют в CI/CD и на серверах.
Делайте:
Каждый крупный релиз iOS должен запускать тесты Apple Pay на бета‑ и финальных сборках. Фокусируйтесь на:
Отслеживайте:
Проводите хотя бы годовой дизайн‑ревью, чтобы держать подписи, размещение кнопок и доступность в соответствии с текущими рекомендациями.
Сети, валюты и поддерживаемые регионы со временем меняются. Делайте эти настройки конфигурируемыми:
Согласуйте изменения с вашим платёжным шлюзом и обновляйте PKPaymentRequest по мере добавления новых сетей.
При смене шлюза, реструктуризации приложения или изменении формата токена:
Документируйте эти потоки, чтобы новые участники команды не тратили время на реверс‑инжиниринг.
Ожидайте усиления токенизации со стороны сетей, более детализированных квитанций и уведомлений в Wallet, а также более тесной интеграции между in‑app, web и in‑store Apple Pay. Функции вроде Tap to Pay on iPhone и региональные финансовые опции будут расширяться, поэтому проектируйте интеграцию гибко и конфигурационно, чтобы быстро внедрять новые возможности без переработки основного потока.
Apple Pay — это цифровой кошелёк Apple, который позволяет пользователям оплачивать покупки картами, сохранёнными на iPhone, iPad, Apple Watch или Mac.
В мобильных приложениях он заменяет ручной ввод данных карты системой-диалогом (system sheet), где пользователь подтверждает платёж через Face ID, Touch ID или код устройства. Приложение получает зашифрованный платёжный токен вместо сырых данных карты и пересылает его на бэкенд и платёжный шлюз для завершения списания.
Это ускоряет оформление заказа, уменьшает количество ошибок и защищает номера карт от попадания в инфраструктуру вашего приложения.
Стоит добавить Apple Pay, когда:
Apple Pay лучше предлагать как дополнительный вариант оплаты рядом с картами, PayPal и другими методами. Не убирайте альтернативы — дайте пользователям быстрый путь, если он доступен.
Минимальные требования:
Кратко по шагам на iOS:
Устройство формирует зашифрованный платёжный токен, который содержит:
Токен дополнительно зашифрован под публичный ключ вашего процессора, поэтому приложение и бэкенд обрабатывают его как непрозрачный объект (opaque blob). Бэкенд пересылает токен шлюзу, который дешифрует его, отправляет запрос авторизации в платёжную сеть и эмитент, затем возвращает результат. Вы не видите реальный PAN или криптографические ключи — только метаданные и статус транзакции.
Ваш сервер должен:
Не пытайтесь дешифровать токены сами и не храните их долго. Передавайте чувствительную обработку PCI‑соответствующему шлюзу.
Часто проблемы возникают из‑за конфигурации:
Проверьте настройки в Apple Developer, entitlements в Xcode и конфигурации шлюза, а затем загляните в серверные логи для ошибок валидации и ответов платёжного провайдера.
Чтобы тестировать безопасно:
Симулятор удобен для UI‑проверок, но всегда проверяйте на реальных устройствах для тестирования Wallet, биометрии и сетевого поведения.
Рекомендации по UX для повышения конверсии:
PKPaymentButton с корректным брендингом и подписью рядом (например, «Оплатить мгновенно с Apple Pay»).\n- Позвольте Apple Pay подставлять адрес доставки и контакты; запрашивайте дополнительные данные только если они действительно нужны.\n- В случае ошибки показывайте понятное сообщение и сохраняйте корзину, чтобы пользователь мог легко повторить попытку или сменить метод оплаты.Эти практики снижают трение и делают оплату быстрым и надёжным процессом.
Отслеживайте Apple Pay как отдельную воронку. Полезные метрики:
Проводите A/B‑тесты размещения кнопки, копий и дефолтов, и сравнивайте поведение пользователей Apple Pay с другими методами, чтобы понять реальный эффект на конверсию.
Также убедитесь, что Apple Pay доступен в регионах и у банков, где вы продаёте, и что категория вашего бизнеса и товары соответствуют правилам Apple.
PKPaymentRequest с идентификатором мерчанта, страной, валютой, поддерживаемыми сетями и суммами.PKPaymentButton в месте принятия решения об оплате.PKPaymentAuthorizationController с вашим запросом.didAuthorizePayment отправьте payment.token на сервер для обработки..success или .failure и закройте лист.Биометрия, генерация токена и часть безопасности выполняет система — в приложении остаётся минимум логики.