Мобильные платежи и SDK: iOS/Android, Apple/Google/Mir Pay и СБП

Table of contents

• Что такое мобильные SDK оплаты
• Способы оплаты: Apple Pay, Google Pay, Mir Pay, СБП
• Архитектура интеграции и поток платежа
• SDK CloudPayments и Тинькофф: практическое сравнение
• UX мобильной оплаты: лучшие практики
• 3DS2 в приложении и безопасность
• СБП в приложении: deeplink, возврат и статусы
• Юридические и фискальные требования
• Тестирование, sandbox и мониторинг
• Стоимость и комиссии
• Чек-лист запуска
• Итоги и следующий шаг

Что такое мобильные SDK оплаты

Мобильные SDK оплаты — это библиотеки для iOS и Android, позволяющие встроить в приложение быстрые и безопасные сценарии платежей: карты, Apple Pay/Google Pay, Mir Pay и СБП. Правильно настроенный SDK повышает конверсию «оплата в iOS/Android», снижает UX-трение и закрывает требования 3DS2, PCI DSS и фискализации. Обычно SDK берут у платежного провайдера (например, "sdk CloudPayments" или "Tinkoff Acquiring SDK") и подключают к своему бэкенду через API.

Если вы только оцениваете варианты, начните с обзора по выбору провайдера и методам оплаты: Сравнение провайдеров и Карты, Apple Pay, Google Pay.

Способы оплаты: Apple Pay, Google Pay, Mir Pay, СБП

Ниже — краткая матрица методов в мобильных SDK с основными требованиями и сценариями.

Метод	Платформы	Ключевые требования	Где работает	Подходит для
Apple Pay (Apple Pay SDK)	iOS	Merchant ID, Apple Pay Entitlements, домен в Apple	iOS, регионы поддержки	Быстрые платежи, высокий UX, токенизация карт
Google Pay (Google Pay SDK)	Android	Google Play Services, GPay API, merchantId	Android	«Один тап», массовые платежи
Mir Pay (mir pay интеграция)	Android	Поддерживаемый провайдер/банк, приложение Mir Pay у пользователя	РФ	Владельцы карт «Мир», офлайн/онлайн кейсы
СБП (deeplink SBP mobile)	iOS/Android	Подключение СБП у провайдера, deeplink/intent, хэндлинг возврата	РФ	Низкая комиссия, P2B-платежи

Подробнее о СБП и сценариях QR/ссылок — в материале СБП: подключение и UX.

Архитектура интеграции и поток платежа

Классическая схема интеграции мобильного SDK такова:

1. Пользователь выбирает метод (Apple Pay, Google Pay, Mir Pay, карта, СБП).
2. SDK инициирует токенизацию/вызывает нативный платежный лист (Apple Pay/Google Pay SDK) или открывает нативную форму карты.
3. Приложение получает paymentToken и отправляет его на ваш сервер.
4. Ваш сервер создаёт платеж через API провайдера и возвращает статус/redirect/challenge-инструкции (3DS2).
5. При необходимости запускается 3DS2 в приложении (challenge flow), после чего провайдер подтверждает платеж.
6. Вы слушаете вебхуки провайдера, обновляете заказ и отправляете push уведомления статусов (успех/ожидание/отмена).
7. Параллельно происходит фискализация (54‑ФЗ) и отправка чека.

Полезно к внедрению:

• Серверные коллбеки и финализация статуса — см. API и вебхуки.
• Тестовый полигон — см. Sandbox и запуск.

SDK CloudPayments и Тинькофф: практическое сравнение

Рынок РФ чаще всего сравнивает «sdk cloudpayments tinkoff». Обе экосистемы зрелые, с хорошим покрытием карт и локальных методов. Конкретные возможности зависят от версии SDK и подключённых модулей у вашего провайдера — проверяйте актуальную документацию.

Критерий	CloudPayments SDK	Tinkoff Acquiring SDK
Платформы	iOS/Android	iOS/Android
Методы	Карты, Apple Pay, Google Pay, СБП (через провайдера)	Карты, Apple Pay, Google Pay, СБП (через провайдера)
Mir Pay интеграция	Опционально/через провайдера	Опционально/через провайдера
3DS2 в приложении	Да (device fingerprint, challenge)	Да (challenge flow, встроенные экраны)
Рекуррентные/токены	Да (rebills, one‑click)	Да (autopay, one‑click)
UI-компоненты	Готовые формы + кастомизация	Готовые экраны + кастомизация
Чеки 54‑ФЗ	Через API провайдера	Через API провайдера
Документация	Подробная, примеры	Подробная, примеры

Советы по выбору: оценивайте не только «галочки», но и SLA, откат на веб-форму, стабильность 3DS2, SBP deeplink, качество SDK-обновлений и саппорта. Сравнение провайдеров — в разделе Как выбрать провайдера. Для стоимости и расчёта ROI см. Тарифы и комиссии.

UX мобильной оплаты: лучшие практики

Сильный мобильный UX оплаты повышает конверсию на 10–30% относительно веб-чекаута.

• Используйте нативные листы Apple Pay/Google Pay SDK там, где это возможно; показывайте их первыми.
• Держите запасной вариант: форма карты в SDK, Mir Pay (для Android), СБП из одного экрана.
• Для СБП помещайте кнопку с логотипом и рядом — ссылку «Оплатить через банк» с открытием deeplink.
• Минимизируйте ввод: автоподстановка email/телефона из профиля, сохранение карт и «1‑клик» (см. Рекуррентные и подписки).
• Покрывайте отказоустойчивость: чёткие ошибки, повторная отправка, офлайн-очередь.
• Информируйте: push уведомления статусов («ожидает подтверждения», «успешно», «отклонено»).
• Измеряйте: conversion to pay, drop на каждом шаге, время до оплаты — подробнее в Checkout UX и конверсия.

3DS2 в приложении и безопасность

3DS2 в приложении — обязательный компонент для картовых платежей. Современные SDK:

• Снимают device fingerprint (без участия пользователя) — попытка «frictionless».
• Автоматически запускают challenge (SCA) если банк требует подтверждение.
• Возвращают результат в приложение без перехода в браузер/WebView.

Рекомендации безопасности:

• Не обрабатывайте PAN на устройстве — получайте токены через SDK и завершайте оплату на сервере.
• Используйте вебхуки для финального статуса, а не только клиентский коллбек.
• Включите антифрод инструменты провайдера и мониторинг аномалий.

Больше про безопасность, PCI DSS и антифрод — в материале Безопасность платежей, 3DS, антифрод.

СБП в приложении: deeplink, возврат и статусы

СБП в мобильном — это либо:

• Deeplink/intent в банковское приложение клиента (deeplink SBP mobile), либо
• Встроенный провайдерский экран с каталогом банков и автоматическим возвратом после оплаты.

Практические советы:

• Генерируйте платёжную ссылку/счёт СБП на сервере, открывайте deeplink из приложения.
• Обязательно предусмотрите обработку возврата в ваше приложение через custom URL scheme/App Links/Universal Links.
• Если пользователь «завис» в чужом приложении, показывайте ему в своём «ожидаем оплату…» и статус через вебхуки или периодический опрос API.
• Делайте таймауты и сценарий отмены/смены метода оплаты.

Подключение и сценарии — в разборе СБП: QR и мобильные сценарии.

Юридические и фискальные требования

Для «оплата в iOS/Android» действуют те же правила, что и для веба:

• 54‑ФЗ и онлайн‑касса: нужно формировать чек на каждый расчёт и отправлять его клиенту. Смотрите Онлайн‑касса и фискализация.
• KYC/KYB у провайдера: подготовьте документы ИП/ООО, проверьте, можно ли принимать платежи как самозанятый. Подробности — в Юридические требования.

Если вы строите маркетплейс или SaaS, обратите внимание на раздельные платежи и сплит — см. Маркетплейсы и white‑label.

Тестирование, sandbox и мониторинг

Критические сценарии для QA перед релизом:

• Apple Pay SDK и Google Pay SDK: успешный платёж, отмена пользователем, недоступность сервиса.
• Mir Pay интеграция: наличие приложения, отсутствие приложения, отмена, успех.
• СБП: deeplink в банк, возврат в приложение, таймаут, повтор.
• Карта + 3DS2: frictionless и challenge, ошибка аутентификации.
• Поведение сети: медленный интернет, потеря соединения, повторный запрос.
• Вебхуки и push уведомления статусов: единообразие статусов и идемпотентность.

Подготовка sandbox-окружения и скрипты тестов — в руководстве Sandbox и запуск. Реализация серверной части — см. API и вебхуки.

Стоимость и комиссии

• Карты, Apple Pay, Google Pay: как правило тарифицируются как эквайринг по ставке провайдера.
• СБП: в РФ обычно дешевле картового эквайринга, привлекательна для среднего чека и частых покупок.
• Mir Pay: тарификация сопоставима с картами «Мир» через эквайринг.

Итоговая экономика зависит от вашего провайдера, оборота и MCC. Подобрать оптимальную схему помогает наш калькулятор — см. Тарифы и комиссии и гайд Как выбрать провайдера.

Чек-лист запуска

• Определите платежные методы по платформам (iOS/Android) и аудитории.
• Выберите провайдера и SDK, подтвердите поддержку 3DS2, Mir Pay и СБП.
• Настройте серверную часть: создание платежей, вебхуки, фискализация.
• Реализуйте UX потоки: Apple Pay/Google Pay первым шагом, fallback на карту/СБП.
• Подключите push уведомления статусов и экран «ожидаем оплату» для СБП.
• Пройдите регламенты KYC/договора у провайдера.
• Проведите тесты в sandbox и на бою с малыми лимитами.
• Подготовьте аналитику: конверсия, отказоустойчивость, A/B UX.

Если вы впервые подключаете эквайринг, загляните в общий гид Как подключить платёжную систему.

Итоги и следующий шаг

Мобильные SDK оплаты — быстрый способ дать пользователю «один тап» через Apple Pay/Google Pay, закрыть локальные потребности (Mir Pay, СБП) и защитить платеж с 3DS2 в приложении. Успех интеграции — это не только галочки в чек-листе, но и продуманный мобильный UX, корректная архитектура серверной части, вебхуки и мониторинг.

Готовы спроектировать надёжную «оплата в iOS/Android»? Изучите сравнение провайдеров и API-паттерны, а мы поможем собрать оптимальный стек: Сравнение провайдеров, API и вебхуки. Напишите нам, чтобы подобрать SDK и запустить релиз без просадок конверсии.