Лекция
Привет, Вы узнаете о том , что такое интеграция платёжных систем, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое интеграция платёжных систем , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.
Интеграция платежных систем на веб‑, мобильных и десктопных платформах требует учета разных технических и бизнес‑аспектов: от выбора API и методов оплаты до обеспечения безопасности и удобства для пользователя. На практике ключевые различия связаны с UX, безопасностью (PCI DSS, HTTPS, токенизация) и поддержкой локальных способов оплаты.
Выбор провайдера: комиссия (2.5–4%), поддержка карт/кошельков, география, качество API.
API и SDK: Stripe, PayPal, Adyen, ЮKassa, Robokassa предоставляют готовые библиотеки для популярных языков.
Webhooks/IPN: асинхронные уведомления о статусе транзакций.
Безопасность: HTTPS, токенизация карт, проверка подписи уведомлений, хранение ключей в защищенных хранилищах.
Тестирование: sandbox‑среды, проверка успешных/неуспешных платежей, возвратов.
UX: минимизация шагов до оплаты, поддержка «оплаты в один клик».
Интеграция: RESTful API, редирект на платежную страницу или встроенные формы.
Примеры: Stripe Checkout, PayPal Smart Buttons.
Особенность: важно учитывать кросс‑браузерную совместимость и адаптивность интерфейса.
SDK: готовые библиотеки для iOS/Android (Stripe SDK, PayPal Mobile SDK).
UX: Apple Pay, Google Pay, биометрическая аутентификация.
Особенность: интеграция с системными API для бесшовного опыта (Face ID, Touch ID).
Риски: необходимость строгого контроля хранения токенов и ключей на устройстве.
Интеграция: через встроенные браузерные компоненты (WebView) или прямые API‑вызовы.
Примеры: корпоративные ERP‑системы с модулем оплаты.
Особенность: чаще используется в B2B‑сегменте, где важны отчетность и контроль транзакций.
Риски: обновления SDK и совместимость с ОС.
| Платформа | UX | Интеграция | Особенности |
|---|---|---|---|
| Веб | Оплата в 1 клик, редирект | REST API, webhooks | Кросс‑браузерность |
| Мобильные | Apple Pay, Google Pay, биометрия | SDK для iOS/Android | Интеграция с системными API |
| Десктопные | Менее критично | WebView, API | B2B‑ориентированность, отчетность |
Неоднодимо решить проблемы на уровне архитектуры :
Cart Lockout
Они прямо описывают проблему: пользователь начал checkout, а корзина в это время может измениться или даже могут стартовать два checkout-процесса одновременно. Их решение — комбинация версии корзины (optimistic locking) и перевода корзины в состояние SUBMISSION_IN_PROGRESS.
В процессе оформления заказа в было бы опасно, если бы пользователь мог вносить изменения в свою корзину. Он мог бы изменить цены или другую важную информацию, что позволило бы ему завершить оформление заказа способом, который не должен был быть возможен (например, переплата или недоплата, пропуск проверки и т. д.). Кроме того, для одной корзины можно было бы одновременно запустить несколько процессов оформления заказа, что привело бы к сбою, поскольку они конкурируют за одни и те же ресурсы, или потенциально даже к многократному списанию средств с пользователя.
Чтобы предотвратить это, Broadleaf использует неявный механизм блокировки, при котором пользователи теряют контроль над своей корзиной во время оформления заказа. Это происходит за счет комбинации оптимистической блокировки ( см. Версионирование корзины ) и изменения статуса корзины ( см. Статусы корзины ).
Благодаря оптимистической блокировке мы знаем, что состояние корзины в базе данных никогда не будет перезаписано устаревшей версией. Это помогает гарантировать, что если поступит несколько или дублирующих запросов на изменение корзины, только один из них будет успешным, и состояние корзины останется действительным. Изменение статуса, SUBMISSION_IN_PROGRESSпроисходящее на первом этапе процесса оформления заказа, фактически лишает пользователя контроля над корзиной, и только текущий запущенный процесс оформления заказа должен иметь возможность вносить в нее изменения. Если будет запущено несколько процессов оформления заказа, только одна из операций записи (и процесс оформления заказа) будет успешной благодаря оптимистической блокировке. Сочетание оптимистической блокировки и изменения права собственности гарантирует, что:
Для одной корзины одновременно будет выполняться только один процесс оформления заказа.
Пользователи не могут изменить содержимое корзины во время оформления заказа.
Также полезно:
Stripe — Dynamically update line items
Stripe отдельно пишет про проверку инвентаря и динамическое изменение состава заказа во время Checkout Session. Это показывает, что корзина и платежная сессия рассматриваются как разные сущности.
Для понимания самой проблемы гонок:
Race Condition / TOCTOU
Классическое описание ситуации "проверил данные → данные изменились → использовал устаревший результат". Это ровно то, что может произойти между созданием payment session и финализацией заказа.
Регуляторные требования: PCI DSS, PSD2, GDPR.
Мультивалютность: поддержка локальных способов оплаты.
Безопасность: токенизация, двусторонняя аутентификация API.
Оптимизация конверсии: сокращение шагов, сохранение карт, «оплата в один клик».
Редирект — пользователь перенаправляется на страницу провайдера (PayPal, ЮKassa). Просто и безопасно, но UX хуже.
Встроенные формы — iframe или JS‑виджет на сайте. Удобно, но требует защиты от XSS.
API/SDK — прямое взаимодействие с сервером провайдера. Гибкость, но выше требования к PCI DSS.
Нативные методы — Apple Pay, Google Pay, Samsung Pay. Максимально удобный UX на мобильных.
Инициация платежа — клиент выбирает метод оплаты.
Создание транзакции — сервер генерирует заказ и отправляет запрос в платежный шлюз.
Аутентификация — 3‑D Secure, биометрия, токенизация.
Обработка — шлюз проверяет карту, баланс, лимиты.
Уведомление — через webhook/IPN приходит статус (успех, отказ, возврат).
Обновление заказа — сервер меняет статус и выполняет бизнес‑логику (активация подписки, доставка).
Ложно отрицательные — реальный платеж отклонен. Причины: подозрительные паттерны, лимиты банка, ошибки валидации.
Ложно положительные — мошеннический платеж принят. Причины: слабые правила антифрода, недостаток данных.
Как улучшить:
Использовать антифрод‑системы (Riskified, Sift).
Применять машинное обучение для анализа паттернов.
Настраивать динамические правила: лимиты по странам, IP, устройствам.
Вводить многофакторную аутентификацию (SMS, push, биометрия).
Зачем: чтобы убедиться, что уведомление пришло от платежного провайдера, а не от злоумышленника.
Способы проверки:
Подпись HMAC — провайдер подписывает payload секретным ключом.
Сертификаты — проверка TLS и корневых сертификатов.
Белый список IP — принимать запросы только с доверенных адресов.
Повторная валидация — сервер делает запрос обратно в API провайдера, чтобы подтвердить транзакцию.
При интеграции платежных систем дизайн и брендбук играют ключевую роль: интерфейс оплаты должен быть визуально согласован с фирменным стилем компании, чтобы повысить доверие и конверсию, но при этом соблюдать требования провайдера (например, Яндекс Пэй или Apple Pay) к использованию их логотипов и элементов.
Консистентность бренда: цвета, шрифты, логотипы должны совпадать с основным сайтом или приложением. Об этом говорит сайт https://intellect.icu . Это снижает ощущение «чужого» интерфейса и повышает доверие.
UX и простота: минимизация шагов, понятные кнопки («Оплатить», «Подтвердить»), отсутствие лишних форм.
Локализация: поддержка языков и валют, релевантных целевой аудитории.
Адаптивность: корректное отображение на мобильных, планшетах и десктопах.
Правила использования логотипа: например, Яндекс Пэй требует, чтобы кнопка оплаты имела фирменный бейдж и не изменялась по цвету или форме.
Элементы интерфейса: кнопки, бейджи, попапы должны быть встроены строго по гайдам (размер, отступы, расположение).
Единый опыт: брендбук предписывает, чтобы пользователь видел одинаковый сценарий оплаты на разных сайтах и приложениях, где используется система.
Запрет на модификацию: нельзя менять фирменные цвета, добавлять тени или анимации к логотипам платежных систем.
| Подход | Плюсы | Минусы |
|---|---|---|
| Полная кастомизация (свой шлюз) | Полный контроль над дизайном, UX в стиле компании | Высокие требования к безопасности, PCI DSS |
| BaaS‑платформы | Бесшовная интеграция под брендом компании, готовая инфраструктура | Ограничения по функционалу, зависимость от провайдера |
| Готовые SDK/виджеты | Быстрая интеграция, соблюдение брендбука провайдера | Меньше свободы в дизайне, обязательные элементы |
Несоблюдение брендбука может привести к отказу в сертификации или блокировке интеграции.
Снижение доверия: если дизайн страницы оплаты резко отличается от основного сайта, пользователи могут опасаться мошенничества.
Юридические требования: использование чужих логотипов без согласия нарушает правила и может повлечь штрафы.
Самый распространенный сценарий.
Пользователь:
Примеры:
Особенности:
Продавец инициирует списание без участия пользователя в момент платежа.
Примеры:
Схема:
Особенности:
Самый простой тип интеграции.
Поток:
Приложение
↓
Backend
↓
Payment Provider
↓
Банк
После успешной оплаты:
Критично:
Подписки существенно сложнее разовых платежей.
Основные сущности:
Например:
{
"plan": "Premium",
"period": "monthly",
"nextBillingDate": "2026-07-01"
}
Период списания:
Пробный период:
7 дней бесплатно ↓ автоматическое списание
Когда пользователь оформляет подписку:
Первая оплата ↓ Сохранение платежного метода ↓ Автосписания
Технически обычно сохраняется не карта, а токен.
Например:
card ↓ payment token ↓ merchant
Преимущества:
Очень важная часть подписок.
Причины:
Стандартный сценарий:
День 1: попытка списания ↓ Ошибка ↓ Повтор через 1 день ↓ Ошибка ↓ Повтор через 3 дня ↓ Ошибка ↓ Подписка становится Past Due
Это называется retry logic или dunning management.
Чтобы не отключать пользователя сразу.
Пример:
Подписка закончилась ↓ Списание не удалось ↓ Еще 7 дней доступ сохраняется ↓ Если платеж не восстановлен — доступ отключается
Очень распространено в SaaS.
Для подписок в iOS действует модель Apple.
Пользователь покупает подписку через:
Apple App Store.
Разработчик не получает данные карты.
Apple управляет:
Если продление не удалось:
Подписка истекла ↓ Apple продолжает пытаться списать деньги ↓ Несколько дней или недель ↓ Если получилось — подписка восстанавливается
В этот период пользователь может оставаться в специальном состоянии.
Apple позволяет включить Grace Period.
Пример:
Подписка закончилась ↓ Проблема с картой ↓ Пользователь продолжает пользоваться сервисом ↓ Apple пытается получить оплату
Если деньги спишутся:
Статус подписки снова Active
Apple может автоматически восстановить подписку после успешного повторного списания.
События приходят через:
Для backend это выглядит примерно так:
DID_FAIL_TO_RENEW ↓ GRACE_PERIOD ↓ DID_RENEW
Похожая логика существует в:
Google Google Play.
Состояния:
ACTIVE ↓ IN_GRACE_PERIOD ↓ ON_HOLD ↓ CANCELED
Если пользователь пополняет карту:
ON_HOLD ↓ ACTIVE
без повторного оформления подписки.
Многие делают так:
Клиент сказал: "Оплата успешна" ↓ Открываем доступ
Это небезопасно.
Правильно:
Провайдер ↓ webhook (с проверкой цифровой подписи) Backend ↓ Обновление БД ↓ Клиент получает статус
Источник истины всегда сервер.
ACTIVE ↓ PAST_DUE ↓ GRACE_PERIOD ↓ SUSPENDED ↓ CANCELED
или
TRIAL ↓ ACTIVE ↓ FAILED_PAYMENT ↓ RECOVERED
Такая конечная автоматика обычно лежит в основе любой серьезной интеграции подписок.
User Subscription Payment Method Token Invoice Payment Attempt Webhook Event
Например:
{
"subscriptionId": "sub_123",
"status": "active",
"nextBillingDate": "2026-07-01",
"paymentProvider": "apple"
}
11.1.Сценарий:
Для этого существует механизм восстановления покупок.
Пример:
Пользователь купил Premium за $50.
Через месяц:
Удалил приложение ↓ Установил заново ↓ Вошел в аккаунт
Если восстановление не реализовано, приложение может показать:
Купить Premium
Хотя пользователь уже заплатил.
Это плохой пользовательский опыт и может нарушать требования магазинов приложений.
В экосистеме Apple покупки принадлежат не приложению, а Apple ID пользователя.
Поэтому приложение может запросить у Apple список ранее приобретенных продуктов.
Поток выглядит так:
Пользователь ↓ Нажимает Restore Purchases ↓ App Store ↓ Возвращает историю покупок ↓ Приложение восстанавливает доступ
Обычно:
Примеры:
Premium Unlock No Ads Pro Features Monthly Subscription
Расходуемые товары (consumables):
100 монет 500 кристаллов 1 дополнительная жизнь
После использования они считаются израсходованными.
Apple рекомендует иметь кнопку:
Restore Purchases
особенно если приложение продает:
Приложение запрашивает данные у App Store.
Apple возвращает:
{
"productId": "premium_monthly",
"transactionId": "123456",
"purchaseDate": "...",
"expiresDate": "..."
}
Backend проверяет данные.
Если покупка действительна:
User ↓ Premium = true
Многие приложения дополнительно имеют собственный аккаунт.
Например:
Покупка сделана ↓ Связана с user_id ↓ Сохранена в backend
Тогда восстановление происходит двумя путями:
Если пользователь сменил устройство.
Если пользователь просто снова вошел в свой аккаунт.
Например:
Логин ↓ Backend ↓ У вас уже Premium ↓ Доступ открыт
В Google работает похожая схема.
Покупки привязаны к Google-аккаунту.
После переустановки приложения:
Google Play ↓ Возвращает сведения о покупках ↓ Приложение восстанавливает доступ
Надежная схема обычно выглядит так:
Покупка ↓ Store ↓ Receipt / Purchase Token ↓ Backend ↓ Проверка у Store ↓ Сохранение права доступа
При восстановлении:
Restore Purchases ↓ Store ↓ Receipt ↓ Backend validation ↓ Восстановление entitlement
Ключевое понятие здесь — entitlement (право доступа).
Приложение не должно спрашивать:
Была ли покупка?
Оно должно спрашивать:
Есть ли сейчас право пользоваться функцией?
Например:
{
"userId": "123",
"premium": true,
"expiresAt": "2026-08-01"
}
Хранить информацию только на устройстве.
UserDefaults SharedPreferences
После переустановки все исчезнет.
Давать доступ только по локальному флагу.
isPremium = true
Не поддерживать восстановление для lifetime-покупок.
Пользователь однажды купил:
Premium Forever
После смены телефона снова видит экран покупки.
Это частая причина жалоб и возвратов.
тестирование оплат в платежных системах, то у него есть ряд особенностей.
Для современных мобильных приложений обычно делают так:
Такой подход считается наиболее надежным и соответствует рекомендациям мобильных платформ.
Если смотреть с точки зрения архитектуры мобильного приложения, то сегодня обычно приходится поддерживать три разных класса платежей одновременно:
Именно обработка состояний подписки, повторных попыток списания, grace period и recovery обычно составляет 70–80% сложности платежной интеграции, а не сам первоначальный платеж.
Исследование, описанное в статье про интеграция платёжных систем, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое интеграция платёжных систем и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем
Комментарии