Банк или агрегатор: что выбрать для приема платежей по API

![Схема: банк против агрегатора — архитектура интеграции]

Table of contents

• В чем разница между банковским эквайрингом и агрегатором
• Ключевые критерии выбора: тарифы, SLA, методы оплаты
• Техническая интеграция: API, SDK, песочница, вебхуки
• Безопасность: PCI DSS, 3‑D Secure и KYC
• Экономика эквайринга: комиссии, удержания, скрытые издержки
• Методы оплаты и география
• SLA, поддержка и риск-менеджмент
• Когда выбирать банк
• Когда выбирать агрегатор
• Сравнительная таблица: банк vs агрегатор
• Чеклист выбора и шаги интеграции
• Примеры провайдеров API
• Вывод и следующий шаг

В чем разница между банковским эквайрингом и агрегатором

Вопрос «банк или агрегатор» возникает у любого бизнеса, который планирует прием платежей по API. Оба варианта решают задачу онлайн-оплаты, но делают это по‑разному:

• Банковский эквайринг — вы заключаете договор напрямую с банком. Платеж обрабатывается банком-эквайером, деньги зачисляются с минимальным числом посредников.
• Платежный агрегатор — платформа, которая объединяет несколько методов оплаты и банков. Агрегатор берет на себя маршрутизацию, риск‑менеджмент, дополнительные сервисы (повторные списания, токенизация, антифрод) и часто проще в запуске.

Итог: банковский эквайринг обычно даёт более предсказуемые тарифы и прямые расчеты, а агрегатор — больше гибкости, конверсию и скорость запуска. Ниже — подробное сравнение эквайринга по ключевым критериям.

Ключевые критерии выбора: тарифы, SLA, методы оплаты

Прием платежей API — выбор, в котором важно оценить не только цену за транзакцию, но и совокупную стоимость владения (TCO) и влияние на конверсию.

• Тарифы эквайринга. Ставки могут различаться по МСС, обороту, картам (дебет/кредит), P2P, иностранным картам. Уточняйте комиссии за возвраты, чарджбэки, 3‑D Secure, конвертацию, вывод средств.
• SLA платежи. Смотрите на «SLA по платежам» (доступность API, время авторизации/капчура, время выплат), приоритет в очередях поддержки, каналы эскалации.
• Методы оплаты. Карты, SBP/ФПС, Apple Pay/Google Pay, кошельки, BNPL, подписки, инвойсы, split‑платежи, payouts. Чем шире пул методов, тем выше конверсия в разных сегментах.
• География и валюты. Если вы растете в другие страны, агрегаторы чаще дают мультивалютность и локальные методы.
• Скорость онбординга. У агрегаторов KYC/KYB часто быстрее; банки могут дольше согласовывать рисковые модели.
• Развитость API. Версионирование, идемпотентность, вебхуки, SDK, песочница, отчётность — всё влияет на сроки разработки и устойчивость.

Техническая интеграция: API, SDK, песочница, вебхуки

Качество API определяет стабильность платежей и скорость релиза. Рекомендуем начать с базового плана интеграции по шагам из руководства Основы интеграции.

Ключевые технические аспекты:

• Песочница (sandbox). Наличие полноценного стенда и тестовых карт сокращает время запуска и количество регрессий. См. Песочница и тестовые сценарии.
• SDK и мобильные платежи. Готовые SDK для iOS/Android ускоряют встраивание Apple Pay/Google Pay и снижают затраты на сертификации. См. Интеграция SDK.
• Вебхуки и идемпотентность. Корректная обработка уведомлений о статусах, повторная доставка, подпись сообщений и идемпотентные ключи критичны для устойчивости. См. Вебхуки и идемпотентность.
• Повторные списания и токены. Для подписок проверьте поддержку payment tokens и сценариев dunning. См. Рекуррентные подписки.
• Возвраты и отмены. API для partial refunds, reversals до клиринга — основа корректной послеплатежной логики. См. Возвраты и отмены.
• Финансовая сверка. Отчётность, выгрузка актов, reconciliation-API. См. Сверка и аналитика.
• Мониторинг. Метрики 2xx/5xx, задержки в вебхуках, алерты по падению конверсии. См. Ошибки и мониторинг.

![Схема потока: клиент —> API —> 3DS —> вебхуки —> ERP]

Безопасность: PCI DSS, 3‑D Secure и KYC

Безопасность и комплаенс — обязательный слой любой платежной архитектуры:

• PCI DSS. При прямом эквайринге банк может потребовать соблюдение PCI DSS SAQ‑A/SAQ‑A‑EP в зависимости от способа интеграции. Агрегаторы часто берут токенизацию и хостед‑формы на себя, упрощая аудит. Подробнее в разделе PCI DSS и 3‑D Secure.
• 3‑D Secure 2.x. Влияние на конверсию зависит от флоу (Frictionless/Challenge). Агрегаторы иногда предоставляют «смарт‑маршрутизацию» 3DS для повышения аппрува.
• KYC/KYB и антифрод. Банки более консервативны к категориям риска; агрегаторы предлагают дополнительные антифрод‑правила и скоринг в API.

Экономика эквайринга: комиссии, удержания, скрытые издержки

Сравнение эквайринга нельзя сводить к «X% за транзакцию». Проверьте полный прайс:

• Комиссия за приём (MDR): фикс/процент, различается по MCC и оборотам.
• 3DS‑fee, cross‑border fee: отдельные сборы за аутентификацию и иностранные BIN.
• Возвраты и чарджбэки: стоимость chargeback, representment, arbitration.
• Сроки выплат и холды: D+1/D+3/еженедельно, rolling reserve 5–10% — влияет на оборотный капитал.
• Валютная конверсия: курс и комиссии при мультивалютной обработке.
• Комиссия за вывод на юрлицо/самозанятых (payouts).
• Стоимость разработки и поддержки интеграции: время команды, SLA, тестирование.

Совет: моделируйте три сценария — «низкий средний чек, высокий объём», «средний чек, смешанные BIN», «высокий чек, высокий риск возвратов» — и сравните TCO для банка и агрегатора.

Методы оплаты и география

Чем шире набор методов, тем выше доля успешных оплат:

• Карты: Visa, Mastercard, МИР — базовый минимум.
• SBP/ФПС: значительно снижает комиссию, растёт в B2C и сервисах.
• Apple Pay / Google Pay: конверсия в мобильных сценариях.
• Кошельки и BNPL: важны для маркетплейсов и цифровых товаров.
• Инвойсы и pay‑by‑link: вне сайта/приложения, для B2B.
• Локальные методы и кросс‑бордер: критично при выходе за пределы страны.

Агрегаторы обычно покрывают больше методов «из коробки». Банки — надёжны в базовых методах и могут предлагать индивидуальные условия под крупный оборот.

SLA, поддержка и риск-менеджмент

SLA платежи — это не только аптайм API. Важно:

• Аптайм: 99.9%+ для критичных окон, прозрачные статус‑страницы.
• Время авторизации/капчура: влияет на UX и блокировки по карте.
• Ретрай‑политики и очереди: повторная отправка вебхуков, идемпотентность.
• Поддержка: 24/7, приоритеты, чат/телефон, регламент эскалации.
• Риск и антифрод: правила, чёрные/белые списки, машинное обучение.
• Оспаривание платежей: процессинг chargeback, сроки и документы.

Банки держат высокий стандарт безопасности, но поддержка может быть менее гибкой. Агрегаторы, как правило, быстрее эволюционируют и дают больше инструментов мерчанту.

Когда выбирать банк

Банковский эквайринг часто выигрывает, если:

• У вас предсказуемый поток платежей и крупный оборот, есть потенциал индивидуальных ставок.
• Нужны прямые расчёты и минимальное число посредников.
• Достаточна базовая корзина методов (карты, SBP) и один рынок.
• Важна консервативная комплаенс‑модель и прямой договор с банком.

Когда выбирать агрегатор

Агрегатор чаще предпочтителен, если:

• Нужны широкие методы оплаты, быстрая «витрина» и мобильные SDK.
• Стартовать нужно быстро, KYC/онбординг — за дни, а не недели.
• Важны подписки, сохраненные карты, ретраи, смарт‑маршрутизация, A/B по 3DS.
• Вы выходите на новые рынки и хотите мультивалютность без множества договоров.
• Нужна централизованная отчётность, гибкие вебхуки и богатая аналитика.

Сравнительная таблица: банк vs агрегатор

Критерий	Банк	Агрегатор
Тарифы эквайринга	Часто ниже при крупном обороте; индивидуальные соглашения	Выше базовая ставка, но оптимизация за счёт маршрутизации
Онбординг	Дольше, более строгий KYC	Быстрее, гибкий риск‑профиль
Методы оплаты	Базовые (карты, SBP), иногда Apple/Google Pay	Широкий спектр: кошельки, BNPL, payouts, pay‑by‑link
География	Обычно один рынок	Мультивалютность и локальные методы
API/SDK	Базовый функционал, бывает консервативным	Богатый API, SDK, webhooks, песочница
Безопасность	Сильный комплаенс, строгие политики	Комплаенс + антифрод‑инструменты для мерчанта
SLA платежи	Высокий аптайм, но менее гибкая поддержка	Гибкий SLA, 24/7 поддержка и статус‑страницы
Подписки/токены	Может быть ограничено	Развито «из коробки»
Отчётность/сверка	Классические отчёты	Расширенные API для reconciliation

Чеклист выбора и шаги интеграции

1. Сформулируйте требования:

• Методы оплаты, рынки, устройства (web/mobile), подписки/возвраты.
• Целевые метрики: аппрув‑рейт, время платежа, SLA, сроки выплат.

1. Запросите офферы у 1–2 банков и 1–2 агрегаторов:

• Тарифы, комиссии на возвраты/чарджбэки, холды, конвертация.
• SLA, поддержка, дорожная карта API.

1. Проведите техоценку:

• Песочница, документация, SDK, вебхуки, идемпотентность.
• PCI‑периметр, 3DS‑флоу, антифрод‑правила.

1. Запустите пилот на тестовом сегменте:

• A/B маршрутизация (если доступна), сбор метрик и логов.
• Сверка отчётов и корректность финансовой сверки.

1. Настройте эксплуатацию:

• Мониторинг ошибок и задержек вебхуков — см. Ошибки и мониторинг.
• Процедуры возвратов — см. Возвраты и отмены.
• Подписки и токены — см. Рекуррентные подписки.

Примеры провайдеров API

Чтобы углубиться в специфику конкретных интеграций, изучите профильные страницы провайдеров:

• Сбербанк: Sberbank Acquiring API — прямой банковский эквайринг с поддержкой МИР и SBP.
• Тинькофф: T‑Bank API — современный API, SDK, удобная песочница.
• YooMoney: YooMoney API — агрегатор с широким набором методов и быстрым онбордингом.
• Беларусьбанк: Belarusbank API — для локального рынка и карт БЕЛКАРТ.

Дополнительно начните с раздела Основы интеграции и требований по PCI DSS и 3‑D Secure.

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

Сравнение эквайринга «банк или агрегатор» сводится к приоритетам вашего бизнеса: если у вас крупный, предсказуемый оборот и достаточно базовых методов, прямой банк даст лучшую экономику и простые расчёты. Если важны скорость запуска, конверсия, мультивалютность и богатая функциональность API, агрегатор упростит старт и масштабирование.

Готовы принять решение и перейти к интеграции? Откройте чеклист в разделе Основы интеграции, проверьте настройки вебхуков и идемпотентности по best‑practice, и запустите пилот в песочнице. Если нужны рекомендации по выбору провайдера под ваш стек и рынки — свяжитесь с нами через форму на сайте api-platezhi.online.