Мобильная интеграция: SDK, Apple Pay/Google Pay и безопасность
Table of contents
- Что такое SDK для мобильных платежей
- Архитектура платежного потока в мобильном приложении
- Сценарии и выбор провайдера
- Apple Pay API: ключевые шаги интеграции
- Google Pay API: ключевые шаги интеграции
- Токенизация и безопасность: tokenization mobile, SSL pinning, PCI/3DS
- Deeplink checkout и универсальные ссылки
- Вебхуки, идемпотентность и статусы
- Подписки и сохраненные карты
- Возвраты и отмены
- Тестирование в песочнице: чек-лист запуска
- Аналитика, сверка и мониторинг
- Частые ошибки и рекомендации
- Итоги и следующий шаг
Что такое SDK для мобильных платежей
SDK для мобильных платежей — это библиотека, которую вы встраиваете в iOS/Android‑приложение для приема оплаты картами, Apple Pay и Google Pay. Правильно выбранный мобильные платежи SDK упрощает соответствие PCI DSS, закрывает 3‑D Secure, умеет работать с токенами карт и снижает время вывода на рынок.
Ключевые преимущества:
- Быстрый запуск платежей без самостоятельной реализации криптографии и 3DS.
- Стабильные UI‑компоненты для ввода карты и нативные сценарии Apple Pay/Google Pay.
- Поддержка recurring и сохраненных карт, вебхуков и возвратов на уровне API провайдера.
![Схема: где находится SDK в мобильном платежном стеке — клиент, ваш сервер, провайдер, банк-эмитент]
Архитектура платежного потока в мобильном приложении
Надежный поток строится вокруг нескольких шагов:
- Клиент инициализирует платеж в приложении (некоторые SDK требуют первичный intent от сервера).
- Приложение получает платежный токен (карточный токен, tokenization mobile от Apple/Google, либо одноразовый ключ).
- Ваш бэкенд выполняет авторизацию/капчур через API провайдера.
- Если требуется 3‑D Secure 2.x — SDK открывает нативный challenge/биометрию.
- Итоговый статус фиксируется вебхуком; приложение показывает результат.
Подробнее про базовые схемы см. раздел Базовые принципы интеграции.
Что выбрать: нативная карта, Apple Pay, Google Pay
| Сценарий |
UX/конверсия |
PCI‑область |
Доп. требования |
| Нативная карта (виджет SDK) |
Хорошая при хорошем UI |
От SAQ‑A до SAQ‑D в зависимости от токенизации |
3DS SDK, шифрование ввода |
| Apple Pay |
Очень высокая |
Минимальная, данные карты не касаются приложения |
Merchant ID, сертификаты |
| Google Pay |
Очень высокая |
Минимальная при gateway‑токенизации |
Зарегистрированный merchant, готовый processor |
Сценарии и выбор провайдера
Выбор провайдера зависит от географии, тарифов, методов оплаты и качества мобильного SDK. Посмотрите сравнение подходов в статье Банки против агрегаторов и изучите API конкретных провайдеров:
Рекомендации:
- Проверяйте, есть ли нативные библиотеки для iOS/Android, поддержка 3DS 2.2 и Apple Pay/Google Pay.
- Уточняйте, как реализованы токены карт (network vs gateway), SLA вебхуков и идемпотентность.
Apple Pay API: ключевые шаги интеграции
Интеграция с Apple Pay в приложении iOS опирается на PassKit и настройки аккаунта Apple Developer. Часто провайдер/эквайер упрощает работу, но базовые шаги неизменны.
Основные шаги:
- Merchant ID и сертификаты: создайте Merchant ID и Payment Processing Certificate в Apple Developer.
- Entitlements: включите Apple Pay в проекте (Capabilities), добавьте поддерживаемые платежные сети.
- Настройте список поддерживаемых карт и стран согласно требованиям эквайера.
- Сценарий оплаты: вызов PKPaymentAuthorizationController и получение зашифрованного paymentToken.
- Отправка токена на бэкенд: не расшифровывайте на клиенте; пересылайте провайдеру, который выполнит авторизацию/капчур.
- 3‑D Secure: инициируется по требованию эмитента; современные SDK закрывают UI‑часть.
Подсказки:
- apple pay api может использоваться как на стороне провайдера (gateway‑дешифрация), так и напрямую в банке‑эквайере — уточняйте у партнера.
- Обновляйте сертификаты до истечения срока и проверяйте работу в Sandbox с тестовыми картами.
Google Pay API: ключевые шаги интеграции
Google Pay для Android использует Google Pay API и PaymentDataRequest.
Основные шаги:
- Зарегистрируйте Merchant ID в Google Pay Console и включите production после тестов.
- Определите токенизацию: PAYMENT_GATEWAY (рекомендуется) или DIRECT. В продакшене выберите gateway, предоставленного вашим провайдером.
- Сконфигурируйте допустимые сети и типы карт (PAN_ONLY, CRYPTOGRAM_3DS).
- Вызовите API для отображения UI Google Pay, получите PaymentData и извлеките token.
- Отправьте токен на сервер и завершите авторизацию через процессинг.
Советы:
- Проверьте, что ваш провайдер поддерживает google pay api с gateway‑tokenization.
- Тестируйте на широком спектре устройств и версий Android, учитывая Google Play Services.
Токенизация и безопасность: tokenization mobile, SSL pinning, PCI/3DS
Tokenization mobile снижает риски: вместо PAN вы работаете с одноразовыми или постоянными токенами.
Типы токенов:
- Network tokens (Visa/MC TSP): постоянные токены сети с динамической криптограммой — лучший UX и высокий autorization rate.
- Gateway tokens: токены провайдера/процессинга, выданные на базовые PAN‑данные.
- Apple Pay/Google Pay tokens: шифруются на устройстве и расшифровываются на стороне процессинга.
SSL pinning: когда и как
SSL pinning защищает от MITM‑атак, закрепляя доверие к конкретному сертификату/ключу.
| Тип pinning |
Плюсы |
Минусы |
Рекомендации |
| Сертификат |
Просто внедрить |
Обновление при ротации сертификата |
Обновляйте вместе с релизом приложения |
| Публичный ключ |
Переживает ротацию сертификата |
Сложнее настроить |
Храните 2–3 пина для бесшовной ротации |
Практика:
- Реализуйте «мягкий» fallback для телеметрии, но «жесткий» pinning для платежных вызовов.
- Актуализируйте пины заранее; используйте remote‑конфиг для списка доверенных ключей.
PCI DSS и 3‑D Secure
- Соответствие PCI/3DS: использование нативных кошельков Apple/Google сокращает PCI‑область. Детали — в разделе PCI DSS и 3‑D Secure.
- Хранение: не сохраняйте PAN/CVV в приложении; используйте Keychain/Keystore только для токенов, разрешенных провайдером.
Deeplink checkout и универсальные ссылки
Deeplink checkout — это сценарий, когда вы открываете внешнюю платежную страницу (в вашем домене или домене провайдера) из приложения через универсальные ссылки iOS/Android App Links. Он полезен как fallback или для быстрого запуска.
Преимущества:
- Меньший объем разработки на клиенте, ускоренный go‑live.
- Легче соответствовать PCI: данные карты не попадают в приложение.
Рекомендации:
- Реализуйте возврат в приложение через deeplink с параметрами результата (success, pending, failed).
- подпишите домен для Universal Links/App Links; учитывайте обработку edge‑кейсов при отсутствии приложения.
Вебхуки, идемпотентность и статусы
Платежи могут завершаться асинхронно. Применяйте вебхуки и идемпотентность:
- Настройте вебхуки для окончательного статуса авторизации/капчура/возврата.
- Все операции инициируйте с idempotency‑key на вашем бэкенде.
- Приложение должно быть готово к статусу pending и обновить UI после уведомления сервера.
Подробная схема — в руководстве Вебхуки и идемпотентность.
Подписки и сохраненные карты
Для регулярных списаний используйте токены карт и MIT‑сценарии с согласия клиента:
- Сохранение карты через SDK (карта + 3DS) и дальнейшие списания сервер‑к‑серверу.
- Apple Pay/Google Pay пригодны для первичного связывания, если провайдер возвращает постоянный токен.
Изучите паттерн Рекуррентные подписки.
Возвраты и отмены
Работайте с возвратами и сторнированиями централизованно на сервере, чтобы не зависеть от версии приложения.
- Отложенные платежи: отмена до капчура.
- Полные/частичные возвраты: учитывайте комиссии и сроки зачисления.
Практика и кейсы — в разделе Возвраты и реверсы.
Тестирование в песочнице: чек-лист запуска
Прежде чем включать продакшен, пройдите песочницу провайдера и Apple/Google:
- Карты: успешный платеж, отклонение, 3DS challenge, 3DS frictionless.
- Apple Pay: тестовые карты и регионы, проверка списка сетей, проверка валюты и адресов доставки.
- Google Pay: PaymentDataRequest в режиме TEST, проверка gateway‑настроек, обработка отказов.
- Deeplink checkout: возврат из браузера/кошелька в приложение по универсальной ссылке.
- Слабая сеть/повторные клики/ретраи по таймауту.
Смотрите лучшие практики в Песочнице и тестовых сценариях.
Аналитика, сверка и мониторинг
- Сквозная аналитика: связывайте платеж с сессией пользователя и заказом; логируйте метод оплаты и результат.
- Финансовая сверка: выгружайте отчеты провайдера и сопоставляйте с внутренними транзакциями. Подробно — в разделе Сверка и аналитика.
- Ошибки и алерты: мониторьте spike’и отказов, время ответа, падения SDK. Рекомендации — в Ошибки и мониторинг.
Частые ошибки и рекомендации
- Отсутствие идемпотентности: дублирование платежей при ретраях сети.
- Неправильная работа с сертификатами Apple Pay: просроченные сертификаты, неактивный Merchant ID.
- Неверная конфигурация google pay api: режим PRODUCTION без активации мерчанта или без gateway‑параметров.
- Жесткий SSL pinning для всех доменов: блокирует аналитические/диагностические вызовы; для платежей — да, для остального — опционально.
- Неполные обработки состояний: отсутствует обработка pending/canceled, пользователи застревают.
- Отсутствие fallback: если Apple/Google Pay недоступны, не показывается форма карты.
Итоги и следующий шаг
Интеграция мобильных платежей сегодня — это сочетание удобного UX (Apple Pay/Google Pay), надежного мобильные платежи sdk и строгой безопасности (tokenization mobile, ssl pinning, PCI/3DS). Начните с выбора провайдера и сценария, подготовьте серверную логику для вебхуков и идемпотентности, и тщательно протестируйте песочницу.
Готовы внедрить? Перейдите к базе: Основы интеграции, оцените провайдера (ЮMoney, Сбербанк, T‑Bank, Беларусбанк), проверьте соответствие PCI/3DS и соберите план релиза с чек‑листом Sandbox. Если нужен путь с минимальным временем запуска — начните с deeplink checkout и постепенно переходите к нативному SDK.