Мобильная интеграция: SDK, Apple Pay/Google Pay и безопасность

Мобильная интеграция: SDK, Apple Pay/Google Pay и безопасность

---

Что такое SDK для мобильных платежей

SDK для мобильных платежей — это библиотека, которую вы встраиваете в iOS/Android‑приложение для приема оплаты картами, Apple Pay и Google Pay. Правильно выбранный мобильные платежи SDK упрощает соответствие PCI DSS, закрывает 3‑D Secure, умеет работать с токенами карт и снижает время вывода на рынок.

Ключевые преимущества:

• Быстрый запуск платежей без самостоятельной реализации криптографии и 3DS.
• Стабильные UI‑компоненты для ввода карты и нативные сценарии Apple Pay/Google Pay.
• Поддержка recurring и сохраненных карт, вебхуков и возвратов на уровне API провайдера.

![Схема: где находится SDK в мобильном платежном стеке — клиент, ваш сервер, провайдер, банк-эмитент]

Архитектура платежного потока в мобильном приложении

Надежный поток строится вокруг нескольких шагов:

1. Клиент инициализирует платеж в приложении (некоторые SDK требуют первичный intent от сервера).
2. Приложение получает платежный токен (карточный токен, tokenization mobile от Apple/Google, либо одноразовый ключ).
3. Ваш бэкенд выполняет авторизацию/капчур через API провайдера.
4. Если требуется 3‑D Secure 2.x — SDK открывает нативный challenge/биометрию.
5. Итоговый статус фиксируется вебхуком; приложение показывает результат.

Подробнее про базовые схемы см. раздел Базовые принципы интеграции.

Что выбрать: нативная карта, 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 конкретных провайдеров:

• ЮMoney API
• СберБанк Эквайринг API
• T‑Bank API
• Беларусбанк API

Рекомендации:

• Проверяйте, есть ли нативные библиотеки для iOS/Android, поддержка 3DS 2.2 и Apple Pay/Google Pay.
• Уточняйте, как реализованы токены карт (network vs gateway), SLA вебхуков и идемпотентность.

Apple Pay API: ключевые шаги интеграции

Интеграция с Apple Pay в приложении iOS опирается на PassKit и настройки аккаунта Apple Developer. Часто провайдер/эквайер упрощает работу, но базовые шаги неизменны.

Основные шаги:

1. Merchant ID и сертификаты: создайте Merchant ID и Payment Processing Certificate в Apple Developer.
2. Entitlements: включите Apple Pay в проекте (Capabilities), добавьте поддерживаемые платежные сети.
3. Настройте список поддерживаемых карт и стран согласно требованиям эквайера.
4. Сценарий оплаты: вызов PKPaymentAuthorizationController и получение зашифрованного paymentToken.
5. Отправка токена на бэкенд: не расшифровывайте на клиенте; пересылайте провайдеру, который выполнит авторизацию/капчур.
6. 3‑D Secure: инициируется по требованию эмитента; современные SDK закрывают UI‑часть.

Подсказки:

• apple pay api может использоваться как на стороне провайдера (gateway‑дешифрация), так и напрямую в банке‑эквайере — уточняйте у партнера.
• Обновляйте сертификаты до истечения срока и проверяйте работу в Sandbox с тестовыми картами.

Google Pay API: ключевые шаги интеграции

Google Pay для Android использует Google Pay API и PaymentDataRequest.

Основные шаги:

1. Зарегистрируйте Merchant ID в Google Pay Console и включите production после тестов.
2. Определите токенизацию: PAYMENT_GATEWAY (рекомендуется) или DIRECT. В продакшене выберите gateway, предоставленного вашим провайдером.
3. Сконфигурируйте допустимые сети и типы карт (PAN_ONLY, CRYPTOGRAM_3DS).
4. Вызовите API для отображения UI Google Pay, получите PaymentData и извлеките token.
5. Отправьте токен на сервер и завершите авторизацию через процессинг.

Советы:

• Проверьте, что ваш провайдер поддерживает 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.