Как принимать оплату на сайте, и что к этому прилагается по закону

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

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

Второй - платёжный сервис, он же провайдер эквайринга. Это посредник, который даёт вам готовую страницу оплаты, принимает данные карты вместо вас и берёт на себя общение с платёжными системами. Продавцу он выдаёт личный кабинет и программный интерфейс для сайта.

Третий - ваш банк, куда приходят деньги. Между списанием у покупателя и зачислением вам проходит время: сначала сумма замораживается, потом подтверждается, потом переводится. Поэтому деньги на счёте появляются не мгновенно, и это нормальное устройство, а не задержка по чьей-то вине.

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

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

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

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

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

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

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

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

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

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

Проверять эту часть надо до запуска, а не после первых заказов. Переделать техническую сторону приёма оплаты нетрудно, а вот объясняться по поводу невыданных чеков дорого и неприятно.

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

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

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

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

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

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

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

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

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

Деньги списались, а заказ не создался. Классика: покупатель оплатил, страница не дождалась ответа и закрылась, а в системе заказа нет. Лечится тем, что заказ считается оплаченным по уведомлению от платёжного сервиса на сервер, а не по возвращению человека на страницу успеха.

Двойное списание. Человек нажал кнопку дважды или обновил страницу оплаты. Защита простая: у каждой попытки свой идентификатор, повторный запрос с тем же идентификатором не создаёт новый платёж.

Возврат. Покупатель отказался, деньги надо вернуть, а вместе с ними отправить чек возврата. Если сценарий не заложен заранее, каждая такая операция превращается в ручную возню и переписку.

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

Все четыре сценария относятся к разработке, а не к настройкам кабинета. Поэтому приём оплаты закладывают в проект сразу, а не привинчивают к готовому сайту в последний момент. У нас это обычная часть работ по интернет-магазину под ключ.

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

Продаёте разово или подпиской. Регулярные списания устроены сложнее и требуют отдельного согласия покупателя на повторные платежи.

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

Нужен ли личный кабинет с историей заказов. Он заметно упрощает возвраты и споры, но это отдельный объём работ, который стоит закладывать сознательно.

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