Система приема платежей: из чего складывается и почему это не только эквайринг

Половина брошенных корзин в интернет-магазинах — это не плохой товар и не высокая цена. Это момент оплаты, где что-то пошло не так: форма не открылась, метод не тот, страница зависла.

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

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

Ниже разберём, из каких элементов состоит инфраструктура приёма платежей, чем отличаются модели подключения и что влияет на конверсию в оплату — а не только на размер комиссии. Отдельно — про то, почему ИП и самозанятые попадают в ловушку «универсальных» решений, заточенных под средний e-commerce.

Эквайринг — это один слой, а не вся система

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

Эквайринг закрывает один сценарий: карта, POS-терминал или карточная форма на сайте. Если клиент хочет заплатить через СБП, отсканировать QR-код или получить ссылку в мессенджере — это другие механизмы, каждый из которых требует отдельного подключения, договора и интеграции.

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

СБП — не альтернатива эквайрингу, а отдельный канал с другой логикой

Система быстрых платежей работает иначе. Деньги идут напрямую со счёта на счёт через Банк России, без карточных сетей. Комиссия для бизнеса ниже, зачисление — секунды. В 2025 году через СБП прошло более 65% всех онлайн-переводов физлиц в России.

Если принимать платежи только картой, часть аудитории уходит к конкурентам. Особенно это заметно в b2c с чеком до 5 000 рублей — там покупатели чаще выбирают СБП.

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

QR-оплата — это не то же самое, что СБП

Путаница здесь частая. QR-код — способ передачи платёжных данных, а не отдельная платёжная система. За QR-кодом может стоять СБП, карточная транзакция или проприетарный кошелёк. Конкретный механизм зависит от настройки кода и приложения, которое его считывает.

В офлайне QR заменяет терминал. В онлайне — удобен для мобильных пользователей: навести камеру проще, чем вводить 16 цифр карты. Конверсия на шаге оплаты через QR на мобильных устройствах выше, чем при ручном вводе карточных данных, в среднем на 12–18%.

Чтобы QR-оплата работала, нужна инфраструктура: генерация кодов, контроль статусов, обработка вебхуков при успешной транзакции. Это отдельный технический компонент системы приёма платежей, а не картинка на странице.

Платёжная ссылка закрывает сценарии без сайта и без кассы

Есть класс бизнесов, которым сайт не нужен или ещё не готов: консультанты, мастера, магазины в Telegram. Для них полноценный интернет-эквайринг избыточен, а наличный расчёт неудобен обеим сторонам.

Платёжная ссылка решает задачу иначе. Продавец формирует ссылку с суммой и описанием, отправляет её в мессенджере — покупатель переходит и платит. Никакого кода, никакого сайта, никакой встречи.

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

Вебхуки и API — нервная система всей инфраструктуры

Платёж прошёл. Что дальше? Система должна об этом узнать автоматически, без ручной проверки. Именно это делает вебхук: платёжный сервис отправляет уведомление на сервер продавца в момент изменения статуса транзакции.

Без вебхуков система работает вслепую. Продавец не знает, оплачен ли заказ, пока не проверит вручную. В Telegram-ботах и SaaS-сервисах это критично: доступ должен открываться сразу после подтверждения оплаты, иначе пользователь уходит.

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

Антифрод — компонент, который невидим, пока не сломается

Фрод в онлайн-платежах — не абстрактная угроза. По оценкам Центробанка, в 2025 году объём мошеннических операций с платёжными картами в России превысил 15 млрд рублей. Каждый успешный chargeback для продавца — потеря товара, потеря денег и удар по репутации у платёжной системы.

Антифрод-мониторинг работает на нескольких уровнях. Первый — правила на основе паттернов: много попыток с одного IP, нетипичная сумма, карта из страны с высоким риском. Второй — машинное обучение, которое учитывает историю транзакций мерчанта и выявляет аномалии. Третий — 3-D Secure и токенизация, которые защищают данные карты на стороне покупателя.

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

Массовые выплаты — отдельный компонент, который часто забывают при проектировании

Маркетплейсы, агрегаторы, сервисы для фрилансеров должны не только принимать деньги, но и распределять их. Выплата исполнителям, роялти авторам, комиссии партнёрам — всё это массовые выплаты, и они требуют отдельной инфраструктуры.

Делать это вручную через банк — значит тратить часы на каждую итерацию, ошибаться в реквизитах и не иметь истории транзакций в системе. Автоматизированные массовые выплаты через API позволяют отправить сотни платежей одним запросом, получить статусы по каждому и зафиксировать всё в аналитике.

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

Онбординг мерчанта — часть инфраструктуры, про которую забывают до момента отказа

Технически сильная платёжная платформа бесполезна, если к ней нельзя подключиться за разумное время. Классический банковский эквайринг требует пакета документов, андеррайтинга, иногда визита в офис. Для ИП это занимает от недели до месяца. Для самозанятых чаще заканчивается отказом без объяснений.

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

Система приёма платежей — это маршрутизация, антифрод, резервные сценарии, управление выплатами и логика работы с разными категориями пользователей. Чем раньше владелец проекта понимает это, тем дешевле обходится переделка.

Если вы выбираете инфраструктуру или текущее решение не закрывает всё нужное, посмотрите на URLPAY. Одна интеграция через API подключает карты, включая зарубежные, СБП, QR-код и платёжные ссылки — без необходимости собирать это из трёх разных сервисов. Работает для ИП, ООО и самозанятых.

Подключение занимает от одного дня. Документация, песочница и примеры запросов — в открытом доступе на urlpay.io. Если нужен живой ответ, пишите в бот поддержки @url_pay_help_bot — там не автоответчик.