Как принять сайт у разработчика: формы, документы и оплата

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

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

Что подготовить перед проверкой сайта?

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

Подготовьте условное имя, отдельную тестовую почту и товар или услугу для пробного заказа. Если проверка отправляет SMS или вызывает звонок, используйте номер, который контролирует команда, либо согласованный тестовый режим. Не используйте данные клиентов. Если проверка отправляет письма, создаёт заявки в CRM или резервирует остатки, заранее договоритесь, кто очистит тестовые записи.

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

Как проверить каждую форму?

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

Для одной формы пройдите весь сценарий, затем повторите его для остальных:

1. Отправьте пустую форму. Ошибка должна объяснять, какое поле исправить, и не перекрывать кнопку на телефоне.
2. Введите тестовые данные. Проверьте сообщение на сайте, письмо и запись в системе, куда должна поступить заявка.
3. Если в форме есть флажок, нажмите на текст рядом с ним. Выбор должен меняться именно у этой формы.
4. Если есть необязательная рекламная рассылка, оставьте её выключенной. Проверьте, что заявка обрабатывается по своему назначению, а адрес не попадает в рекламный список.
5. Повторите отправку после ошибки. Уже введённые данные не должны пропадать без причины. Одно действие не должно создавать несколько одинаковых заявок.

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

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

Какие документы должны открываться посетителю?

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

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

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

Для продаж потребителям проверьте доступность сведений о продавце, товаре или услуге, цене и условиях приобретения. Набор сведений зависит от статуса продавца и вида деятельности; он не одинаков для всех сайтов. Для магазина есть отдельный список реквизитов и способов связи.

Как проверить аналитику после отказа?

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

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

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

В Chrome вкладку Network открывают до перезагрузки страницы. Она позволяет увидеть запросы и их адресатов; Preserve log сохраняет журнал при переходах. В Application → Storage → Cookies выберите адрес проверяемого сайта и посмотрите сохранённые cookies. Их отсутствие не доказывает, что данные никуда не отправляются: нужны также проверка запросов и пояснение разработчика о серверной обработке.

Зафиксируйте результат словами: «после отказа запрос к указанному сервису продолжает отправляться» - и приложите подтверждение. Перед передачей журналов уберите тестовые контакты и другие чувствительные сведения. После удаления чувствительных заголовков в HAR (файле сетевого журнала) всё ещё могут оставаться данные в адресах и телах запросов.

Что проверить в корзине и перед оплатой?

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

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

Уберите необязательную платную позицию и проверьте, что основную покупку можно продолжить, а итоговая сумма пересчитана.

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

Как убедиться, что оплата подтверждается правильно?

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

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

Разработчик должен показать, как сервер проверяет сообщение провайдера, связывает его с заказом и суммой и учитывает нужный статус платежа. При двухстадийной оплате авторизация и списание - разные события. Например, в схеме мобильной интеграции Т-Банка возврат на страницу успеха возможен после авторизации, а статус и сумму дополнительно проверяют через API. В документации Т-Банка отдельно описаны проверка уведомлений и повторная доставка.

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

Если к продавцу и расчёту применяются требования 54-ФЗ о кассовом чеке, отдельно проверьте его формирование и передачу покупателю. Попросите ответственного показать чек, сверить продавца, позиции и сумму с заказом, а также проверить получение чека на указанный тестовый контакт. Успешный статус платежа сам по себе не подтверждает, что чек сформирован и отправлен. Режим этой проверки согласуйте с ответственным за кассу; реальные расчёты проводите только по отдельной договорённости.

Что проверить на телефоне и при ошибке?

Пройдите основные сценарии на настоящем телефоне. Экранная клавиатура не должна закрывать ошибку или кнопку. Длинный текст документа не должен мешать вернуться к форме. Проверьте открытие платёжной страницы и возврат к заказу.

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

Если настроены цели аналитики, разделите нажатие кнопки, завершение операции и ошибку. Событие «заявка отправлена» должно соответствовать успешной отправке, а не первому клику. Сбой аналитики не должен мешать самой заявке или заказу.

Какие доступы и сведения получить от разработчика?

Составьте реестр доступов к домену, хостингу, почте, аналитике и платёжному кабинету. Включите в него репозиторий - хранилище исходного кода, CMS - систему управления сайтом, CRM - систему учёта клиентов и заявок. Для каждого сервиса укажите владельца учётной записи, ответственного, способ восстановления доступа и место хранения инструкции. Пароли и ключи не вставляйте в общую таблицу замечаний: передавайте доступы через предусмотренные сервисом роли или согласованный защищённый способ.

Попросите показать создание резервной копии и согласованную проверку восстановления на тестовой площадке. Наличие файла с названием backup ещё не подтверждает, что из него можно восстановить сайт.

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

Как оформить замечания и повторную проверку?

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

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

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