Прием платежей через API: возможности, сценарии, архитектура

Table of contents

• Обзор: что такое прием платежей через API
• Когда выбирать API вместо готового виджета
• Сценарии оплаты и UX‑паттерны
• Архитектура интеграции: client, backend, PSP
• Потоки платежей: authorize/capture и sale
• Методы оплаты: карты, СБП, Apple Pay/Google Pay
• Надежность: идемпотентность, ретраи, таймауты
• Контроль статусов: вебхуки, polling и reconciliation
• Сравнение подходов и чек‑лист внедрения
• Метрики, рост конверсии и A/B‑тесты
• Выводы и следующий шаг

Обзор: что такое прием платежей через API

Прием платежей через API — это прямое взаимодействие вашей системы с платежным провайдером. Вы создаете платеж, управляете жизненным циклом (authorization, capture, refund), получаете статусы через вебхуки и формируете собственный UX. Такой подход идеален для компаний, которым важны гибкость, контроль над воронкой и масштабируемость под высокие нагрузки.

Когда выбирать API вместо готового виджета

• Нужен полностью кастомный UI/UX без ограничений конструктора.
• Требуются нестандартные сценарии: холд средств, частичная оплата, split‑платежи.
• Важно централизованно собирать события и логику в backend (например, для антифрода).
• Вы хотите унифицировать работу разных методов оплаты под единое API.

Если вы запускаете MVP и время критично — начните с базового виджета, а затем перейдите на API‑подход по мере роста требований.

Сценарии оплаты и UX‑паттерны

• Одноразовая оплата (one‑time): быстрый чекаут, минимум шагов.
• Холдинг и последующий капчур (Two‑Step): удобно для доставки/предзаказов.
• Рекуррентные списания: подписки, SaaS, сервисы с автопродлением.
• Оплата в один клик: токенизация + сохраненные карты.
• СБП ссылки/QR: мгновенная оплата со счета клиента без комиссии со стороны банка клиента.

Совет: предлагайте несколько способов оплаты, но не перегружайте интерфейс. Подсвечивайте наиболее конверсионный вариант по умолчанию.

Архитектура интеграции: client, backend, PSP

Базовая схема:

1. Клиент инициирует оплату в вашем интерфейсе.
2. Ваш backend создает платеж через REST API (amount, currency, order_id, customer).
3. Клиент проходит оплату на защищенной платежной странице или встраиваемой форме.
4. PSP отправляет вебхук о результате; вы подтверждаете заказ и обновляете статус.
5. Опционально: создаете capture, refund, receipt и отчеты.

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

Потоки платежей: authorize/capture и sale

• Sale (покупка): мгновенное списание. Простая логика и высокая конверсия.
• Authorize/Capture (двухэтапная): сначала блокировка, потом списание частично или полностью. Удобно для доставки, предзаказов, аренды. Учтите срок жизни холда и автоматическое освобождение.

Таблица выбора:

Сценарий	Рекомендуемый поток	Особенности
Цифровые товары	Sale	Мгновенная выдача доступа
Физические товары	Auth/Capture	Списание после сборки заказа
Предзаказ	Auth/Capture	Капчур при отгрузке
Подписка	Sale + token	Off‑session списания

Методы оплаты: карты, СБП, Apple Pay/Google Pay

• Карты: максимальный охват, 3‑D Secure 2.0, токенизация.
• СБП: быстрый и дешевый перевод; удобен для мобильных сценариев и счетов по ссылке.
• Apple Pay/Google Pay: повышают конверсию на мобильных, минимизируют ввод данных.

Рекомендуем адаптировать выдачу методов оплаты под девайс, локацию и историю конверсий.

Надежность: идемпотентность, ретраи, таймауты

• Для POST используйте заголовок Idempotency‑Key = хеш заказа + попытка.
• Таймауты: 10–30 секунд для платежа, с безопасными повторными запросами.
• Ретраи: выполняйте только для идемпотентных операций; избегайте двойного списания.
• Circuit breaker и backoff‑политики для деградации внешних зависимостей.

Контроль статусов: вебхуки, polling и reconciliation

• Вебхуки — основной канал синхронизации; подписывайте и храните idempotency_key.
• Polling пригодится как резерв, но не должен заменять события.
• Ежедневный reconciliation: сверьте платежи и возвраты с отчетами PSP, кассы и банка.

Сравнение подходов и чек‑лист внедрения

Сравнение:

Подход	Контроль UX	Срок внедрения	Поддержка сценариев	Риски
Готовый виджет	Средний	Очень быстрый	Базовые	Ограниченная кастомизация
API интеграция	Максимальный	Быстрый/Средний	Любые	Требует дисциплины DevOps

Чек‑лист:

• Ключи API и роли доступа
• Идемпотентность и ретраи
• Подпись вебхуков и повторная доставка
• 3‑DS и fallback сценарии
• ККТ/54‑ФЗ и возвратные чеки
• A/B тест UX и методы оплаты
• Monitoring и алерты SLO

Метрики, рост конверсии и A/B‑тесты

Отслеживайте: CTR выбора метода, drop‑off на вводе карты, долю 3‑DS challenge, approve rate, share of SBP, возвраты и chargeback ratio. A/B‑тестируйте упрощенный ввод, автоподстановку BIN‑банк, кнопки Apple/Google Pay.

Выводы и следующий шаг

Интеграция через API позволяет строить конверсионный и надежный платежный поток, который масштабируется с вашим бизнесом. Перейдите к «Быстрому старту», подключите песочницу и создайте первый платеж уже сегодня.