Подключение эквайринга: порядок действий и документы
Подключение эквайринга состоит из двух параллельных линий: документальной и технической. Документальная идёт на стороне владельца бизнеса и банка, техническая — на стороне разработки, и она короче. Общий срок определяется первой линией, поэтому заявку подают в первый день проекта.
Ниже — порядок действий, перечень документов, требования к сайту и типовые причины отказа.
1. Что нужно определить до подачи заявки
1.1. Юридическое лицо или индивидуальный предприниматель, от чьего имени принимаются платежи.
1.2. Расчётный счёт, на который зачисляются средства.
1.3. Перечень того, что продаётся, с указанием категорий товаров или услуг.
1.4. Способы оплаты: банковские карты, СБП, оплата частями — по каждому способу условия отдельные.
1.5. Наличие обязанности применять кассу и выбранный кассовый сервис.
Пункт 1.5 согласуется с бухгалтером. Ряд банков подключает фискализацию совместно с эквайрингом, ряд требует отдельный кассовый сервис.
2. Перечень документов
Состав различается по банкам; типовой перечень таков.
2.1. Свидетельство о регистрации или лист записи государственного реестра.
2.2. Свидетельство о постановке на налоговый учёт.
2.3. Документ, удостоверяющий личность руководителя или предпринимателя.
2.4. Реквизиты расчётного счёта.
2.5. Устав и решение о назначении руководителя — для юридического лица.
2.6. Заявление на подключение по форме банка.
2.7. Адрес сайта, на котором будет приниматься оплата.
Документы по пунктам 2.1–2.6 готовит владелец. Пункт 2.7 предоставляет разработчик или владелец, в зависимости от того, у кого на момент подачи находится рабочая версия.
3. Требования к сайту на момент проверки
Банк проверяет сайт до подписания договора. К этому моменту на сайте должны присутствовать:
3.1. Сведения о продавце: наименование, ИНН, ОГРН или ОГРНИП, фактический адрес.
3.2. Контакты: телефон и адрес электронной почты.
3.3. Описание товаров или услуг с ценами.
3.4. Условия оплаты с перечнем принимаемых способов.
3.5. Условия и сроки доставки.
3.6. Порядок возврата товара и возврата денежных средств.
3.7. Политика обработки персональных данных.
3.8. Пользовательское соглашение или оферта.
3.9. Работающий протокол защищённого соединения на всех страницах.
Пункты 3.1–3.8 — тексты, и готовит их владелец бизнеса, при необходимости с юристом. Разработчик размещает их и обеспечивает пункт 3.9.
4. Порядок действий по шагам
4.1. Владелец выбирает банк или платёжного провайдера и подаёт заявку.
4.2. Разработчик размещает рабочую версию сайта с заполненными разделами по пункту 3.
4.3. Банк проводит проверку сайта и документов.
4.4. Банк направляет замечания. Замечания устраняются: текстовые — владельцем, технические — разработчиком.
4.5. Подписывается договор, владелец получает доступ к личному кабинету.
4.6. Владелец передаёт разработчику технические ключи доступа для подключения. Логин и пароль от кабинета не передаются.
4.7. Разработчик подключает создание платежа и приём уведомления о результате.
4.8. Проводятся тестовые операции по пункту 5.
4.9. Подключение переводится в рабочий режим.
4.10. После сдачи проекта ключи доступа остаются у владельца; при необходимости они перевыпускаются.
5. Тестовые операции до запуска
5.1. Успешная оплата картой. Статус заказа изменился автоматически.
5.2. Успешная оплата по СБП. Статус заказа изменился автоматически.
5.3. Отклонённый платёж. Заказ остался в ожидании оплаты, покупателю предложена повторная попытка.
5.4. Закрытие вкладки до подтверждения. Заказ не помечен оплаченным.
5.5. Повторное уведомление по тому же платежу. Заказ обработан один раз.
5.6. Возврат средств из кабинета банка. Статус заказа отражает возврат.
5.7. Сумма списания совпадает с суммой заказа, включая доставку.
Пункт 5.4 проверяет главное правило: заказ считается оплаченным по уведомлению провайдера, а не по возвращению покупателя на страницу подтверждения.
6. Типовые причины отказа или замечаний
6.1. На сайте отсутствуют реквизиты продавца.
6.2. Отсутствует или не соответствует товару порядок возврата.
6.3. Не размещена политика обработки персональных данных.
6.4. Сайт не заполнен: шаблонные тексты, пустой каталог, страницы-заглушки.
6.5. Категория товара не соответствует заявленной в анкете.
6.6. Отсутствует защищённое соединение на части страниц.
6.7. Данные в заявке расходятся со сведениями в реестре.
Замечания по пунктам 6.1–6.4 закрываются за день, если тексты подготовлены заранее. Именно поэтому их пишут параллельно с разработкой, а не в неделю запуска.
7. Разграничение ответственности
| Работа | Сторона |
|---|---|
| Выбор банка и подача заявки | Владелец |
| Документы по пунктам 2.1–2.6 | Владелец |
| Юридические тексты по пунктам 3.1–3.8 | Владелец, при необходимости юрист |
| Размещение текстов, защищённое соединение | Разработчик |
| Подключение платежей и уведомлений | Разработчик |
| Тестовые операции | Совместно |
| Хранение доступов после сдачи | Владелец |
8. Когда эквайринг не подключается
8.1. Расчёты ведутся только с юридическими лицами по счетам.
8.2. Сайт принимает заявки, оплата производится на месте.
8.3. Оборот несколько заказов в месяц и оплата выставляется вручную ссылкой.
В третьем случае интеграция не окупается: ручное выставление ссылки на оплату обходится дешевле подключения и его обслуживания. Порог, после которого подключение оправдано, каждый определяет по числу заказов и по времени, которое уходит на сверку. Типы проектов и порядок цен приведены на странице услуг.
9. Что фиксируется при приёмке
9.1. Наименование банка или платёжного провайдера и номер договора.
9.2. Подтверждение, что доступ к личному кабинету находится у владельца.
9.3. Перечень подключённых способов оплаты.
9.4. Результаты тестовых операций по пункту 5 с датой проведения.
9.5. Порядок действий при сбое приёма платежей: к кому обращаться и в какой срок.
10. Эксплуатация после запуска
10.1. Сверка. Сумма поступлений на счёт сверяется с суммой оплаченных заказов. При корректно работающих уведомлениях расхождений быть не должно; расхождение является поводом для проверки.
10.2. Смена расчётного счёта или реквизитов. Оформляется на стороне банка, работ на сайте не требует.
10.3. Добавление способа оплаты. Выполняется как отдельная работа с повторным проведением проверок по пункту 5.
10.4. Смена провайдера. Выполняется как отдельная работа; прежнее подключение отключается после подтверждения работы нового.
10.5. Изменение требований провайдера. Приведение интеграции в соответствие относится к дополнительным работам.
11. Частая последовательность ошибок
11.1. Заявку подают после сдачи сайта — проект простаивает в ожидании проверки.
11.2. Юридические тексты пишут в неделю запуска — банк присылает замечания, срок сдвигается ещё раз.
11.3. Тестируют только успешную оплату — отклонённый платёж и повторное уведомление обнаруживаются на реальных покупателях.
11.4. Доступы к кабинету оставляют у разработчика — при смене подрядчика владелец не может управлять приёмом платежей.
Последовательность 11.1–11.2 даёт основную часть задержек запуска и устраняется одним решением: заявка подаётся в первый день.
Коротко
Подключение эквайринга идёт двумя линиями: документы и проверка сайта на стороне владельца и банка, техническая часть на стороне разработки. Общий срок задаёт первая линия, поэтому заявка подаётся в первый день проекта, а юридические тексты пишутся параллельно с разработкой. Сайт к моменту проверки должен содержать реквизиты, контакты, условия оплаты, доставки и возврата, политику обработки данных и защищённое соединение. Перед запуском выполняются семь тестовых операций, включая отклонённый платёж и повторное уведомление; доступы к кабинету банка после сдачи остаются у владельца.
Первый разговор — разбор задачи: нужна ли вам система или хватит одной страницы. Без обязательств и без счёта.
Частые вопросы
Когда начинать подключение — до разработки или после?
В первый день проекта. Техническая часть занимает малую долю работ, а рассмотрение заявки и проверка сайта банком идут своим темпом и от вас не зависят. Проекты чаще ждут эквайринг, чем эквайринг ждёт проект.
Можно ли подать заявку сразу в несколько банков?
Да, и на первом проекте это разумно: условия и требования к сайту различаются, а отказ одного банка не означает отказа другого. Договор подписывается с тем, чьи условия и требования вам подошли.
Что делать, если сайт ещё не готов, а банк требует его посмотреть?
Открыть банку рабочую версию с реальной структурой и заполненными юридическими страницами. Пустой шаблон проверку не проходит: банк смотрит не дизайн, а наличие сведений о продавце, условий возврата и понятного описания того, что продаётся.
Те, что не помогают, мы переписываем — по этой кнопке и решаем, какие именно.
Ещё по теме
Справка о составе чека, разграничении зон ответственности между сайтом, кассой и бухгалтерией и порядке проверки перед запуском.
тем, кто заказывает «Жук и Плут»: детский бренд ушёл с маркетплейсов на свой сайтИстория магазина детских товаров — что мы построили, что пошло не так и почему бренд встал первым в Яндексе на третий день.
тем, кто заказывает «С этим покупают»: где ставить блоки допродажКарта мест на сайте, где допродажа работает, и что показывать в каждом — от карточки товара до письма после доставки.
тем, кто заказывает