WooCommerce Customer Email Verification - Плагин WordPress

Руководство по настройке WooCommerce Customer Email Verification для проверки покупателей

WooCommerce Customer Email Verification решает узкую, но болезненную задачу магазина: он заставляет покупателя подтвердить адрес электронной почты до регистрации, оформления заказа, повторного входа или изменения учетных данных, если такой сценарий включен в настройках. В этом руководстве разберем не рекламное описание плагина, а практическую работу с ним: что включать сначала, как не сломать оформление заказа, где проверять отправку кодов, когда использовать всплывающее окно, а когда встроенное поле, и как действовать, если код не приходит или не принимается.

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

Главная мысль: email verification не заменяет антиспам, SMTP, защиту платежей или ручную модерацию спорных заказов. Плагин закрывает конкретную точку риска - неверный или временный адрес покупателя. Если настроить его грубо, можно получить лишние отказы на оформлении заказа. Если настроить его аккуратно, он отсекает часть мусорных регистраций и дает более чистую базу покупателей без лишнего давления на нормальных клиентов.

Что именно защищает проверка email в WooCommerce

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

WooCommerce Customer Email Verification работает через одноразовый код. В зависимости от включенного сценария покупатель получает код по email, вводит его во всплывающем окне или прямо на странице, а плагин отмечает адрес как подтвержденный. Для регистрации это значит, что учетная запись не считается полноценной до успешной проверки. Для оформления заказа это значит, что магазин может попросить гостя или зарегистрированного покупателя подтвердить адрес до завершения покупки.

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

Отдельно стоит различать проверку адреса и доставляемость писем. Если магазин плохо отправляет почту, плагин не исправит это сам. WooCommerce передает письма через механизм WordPress wp_mail(), а дальше результат зависит от сервера, SMTP, DNS-записей отправителя, фильтров получателя и конфликтов с другими расширениями. Поэтому перед включением строгого режима нужно убедиться, что тестовые письма реально доходят.

Где плагин полезен, а где может мешать покупке

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

Подходящие сценарии

WooCommerce Customer Email Verification хорошо подходит магазинам, где важна чистая база клиентов и где неподтвержденный email создает заметную проблему. На практике это такие случаи:

• Магазин получает много регистраций без последующих заказов, а часть адресов выглядит как временные или одноразовые почтовые ящики.
• Покупатели часто ошибаются в email, из-за чего не получают ссылку на скачивание, уведомление о заказе или письмо поддержки.
• Есть бесплатные товары, пробные тарифы, купоны или закрытые материалы, которые не стоит отдавать на неподтвержденный адрес.
• B2B-магазин должен принимать регистрации только с корпоративных доменов и отклонять личные почтовые ящики.
• Команда хочет видеть не только список пользователей, но и статус проверки, повторную отправку кода, аналитику и очистку старых неподтвержденных записей.

Когда лучше включать осторожно

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

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

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

Что проверить перед установкой и первым включением

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

Техническая совместимость

Для бесплатной версии Zorem указывает минимальные требования к WordPress, WooCommerce и PHP в документации. Для коммерческой версии ориентируйтесь на страницу продукта, документацию и changelog, потому что поддерживаемые версии WooCommerce быстро меняются. В самой статье не стоит жестко привязываться к номеру версии, но перед установкой проверьте три вещи:

• WooCommerce активен и страницы My Account, Cart и Checkout открываются без ошибок.
• Тема или конструктор не заменяет регистрацию и оформление заказа так, что стандартные хуки WooCommerce не выполняются.
• На сайте есть резервная копия и возможность быстро отключить плагин через админ-панель или файловый менеджер хостинга.

Почта и доставляемость

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

После этого проверьте базовые DNS-записи отправителя: SPF, DKIM и DMARC. Не нужно превращать установку плагина в сложный проект по почте, но без нормальной отправки OTP-код будет слабым местом. Пользователь не должен угадывать, где письмо: во входящих, спаме, задержанной очереди сервера или вообще не было отправлено.

Checkout и кэширование

Страницы корзины, оформления заказа и личного кабинета нельзя кэшировать как статические страницы. Если кэш-плагин, CDN или оптимизатор скриптов агрессивно объединяет JavaScript, отложенно грузит скрипты WooCommerce или кэширует фрагменты страницы, popup или inline-поле проверки может появляться не там, где ожидается. Перед включением проверьте исключения для /cart/, /checkout/, /my-account/ и AJAX-запросов WooCommerce.

Если магазин использует WooCommerce Cart and Checkout blocks, отдельно проверьте режим inline и popup. Документация Zorem говорит о поддержке блоков, но также отмечает настройку Disable Store API Checkout как средство для ситуации, когда тема или сторонний сценарий позволяет обойти проверку через Store API. Эту настройку не стоит включать вслепую: сначала воспроизведите проблему на тестовом заказе.

Установка и первичная проверка без риска для покупателей

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

Безопасный порядок запуска

1. Сделайте резервную копию сайта или подготовьте быстрый способ отката.
2. Установите плагин через Plugins > Add New или Upload Plugin.
3. Активируйте плагин и перейдите в WooCommerce > Email Verification.
4. Для первого теста включите только проверку регистрации, если магазин позволяет создать учетную запись через My Account.
5. Создайте тестового пользователя на реальный почтовый ящик, к которому у вас есть доступ.
6. Проверьте, что письмо пришло, код вводится, пользователь появляется в списке с правильным статусом.
7. Только после этого переходите к проверке checkout-сценариев.

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

Первый тестовый пользователь

Используйте новый email, который не привязан к существующему аккаунту. Если тестировать на старом пользователе, можно получить смешанную картину: он уже подтвержден, имеет предыдущие сессии, старые метаданные или роль администратора, для которой проверка может быть пропущена. Лучше создать отдельный адрес вида Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. на реальном домене или в тестовом почтовом ящике.

После регистрации проверьте три места: письмо в почте, видимый экран с вводом кода и запись в Users. Если в админке есть колонка статуса проверки, она должна помочь увидеть, прошел ли пользователь подтверждение. Если письмо пришло, но код не принимается, не делайте вывод сразу. Проверьте, не вводится ли старый код после повторной отправки, не истек ли срок действия и не мешает ли кэш.

Настройка регистрации: как не создавать мусорные аккаунты

Проверка регистрации - базовый режим для WooCommerce Customer Email Verification. В актуальной логике Zorem описывает сценарий, где учетная запись создается только после успешного подтверждения кода. Это важно: магазин не должен накапливать пустые аккаунты, если бот или случайный пользователь не завершил проверку. При этом старые установки и разные версии плагина могли работать иначе, поэтому после обновления всегда тестируйте фактическое поведение на своем сайте.

Что включить первым

Начните с переключателя Enable Signup Verification. После сохранения откройте страницу My Account в приватном окне браузера и выполните регистрацию. Покупатель должен увидеть понятный шаг подтверждения, а письмо должно содержать код или проверочную инструкцию, актуальную для вашей версии. Если в старом шаблоне письма осталась ссылка или переменная, которая больше не поддерживается, обновите шаблон через встроенный настройщик, а не копируйте старый текст из предыдущей версии.

Для русского магазина особенно важны тексты popup и письма. Покупатель должен понимать, что код нужен именно для подтверждения email, а не для оплаты, доступа к банковским данным или стороннего сервиса. Хорошая формулировка короткая: "Введите код из письма, чтобы завершить регистрацию". Плохая формулировка - длинный технический текст, где покупатель не видит, что делать дальше.

Статус пользователя и ручное управление

В админ-панели WordPress плагин добавляет инструменты для просмотра статуса проверки: колонку или фильтр по подтвержденным и неподтвержденным пользователям. Это полезно для поддержки: если покупатель пишет, что не может войти, менеджер видит, подтвержден ли email, и может повторно отправить код или вручную подтвердить адрес, если политика магазина это допускает.

Ручная проверка нужна не для массового обхода защиты, а для исключений: корпоративный клиент не получил письмо из-за фильтра компании, менеджер уже подтвердил адрес по другому каналу, или заказ был согласован вручную. Зафиксируйте внутреннее правило: кто имеет право подтверждать пользователя вручную и при каких доказательствах. Иначе проверка email быстро превратится в формальность.

Мини-проверка после настройки

• Новый пользователь не получает полный доступ до ввода корректного кода.
• Повторная отправка кода работает и не создает несколько активных кодов, которые путают покупателя.
• Статус пользователя в админ-панели меняется после успешной проверки.
• Текст письма и popup не содержит устаревших ссылок, неподдерживаемых переменных и англоязычных фраз, если сайт русский.

Проверка перед оформлением заказа: popup, inline и Store API

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

Popup или inline

Плагин предлагает два подхода: всплывающее окно и встроенное поле. Popup заметнее и хорошо подходит, когда нужно остановить покупателя до дальнейшего шага. Inline выглядит спокойнее: поле проверки находится прямо на странице оформления заказа и не выбивает пользователя из контекста. Для блоков оформления заказа, кастомных checkout-страниц и воронок inline-режим часто проще воспринимается, но его нужно тестировать с конкретной темой.

Почему настройка Disable Store API Checkout требует теста

В документации Zorem есть настройка, которая блокирует Store API checkout, чтобы снизить риск обхода проверки. Это полезно, если конкретная тема или сторонняя интеграция позволяет отправить заказ через API без завершения OTP-проверки. Но у Store API есть легитимные задачи, особенно в блоках WooCommerce и интеграциях. Поэтому включайте эту опцию только после теста: сначала воспроизведите обход или конфликт, затем включите настройку, затем повторите тот же сценарий.

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

OTP, письма и тексты: настройки, которые влияют на завершение проверки

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

Длина и срок действия кода

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

Не стоит ставить "never" только ради удобства. Бессрочный код легче использовать повторно, если письмо переслали или почта скомпрометирована. Более практичный подход - разумный срок действия, понятная повторная отправка и сообщение, которое объясняет, что делать при истечении кода.

Повторная отправка и сообщения об ошибках

Resend limit нужен не только для защиты от злоупотребления, но и для UX. Если пользователь нажимает Resend несколько раз подряд, он может получить несколько писем и начать вводить старый код. Ограничение и задержка между отправками помогают снизить хаос. Сообщение должно быть человеческим: "Мы отправили новый код. Используйте последнее письмо".

Для ошибок тоже нужна точность. Фраза "Код неверный" полезнее, чем общее "Ошибка". Если код истек, так и пишите. Если письмо не пришло, укажите проверку папки спама и возможность запросить новый код. Не обещайте мгновенную доставку, если отправка зависит от внешнего почтового сервиса.

Настройка письма и popup

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

Если сайт мультиязычный, проверьте строки через штатный механизм переводов. Документация Zorem отдельно описывает совместимость с WPML для перевода строк плагина. Для простого русскоязычного магазина достаточно настроить тексты в customizer, но для сайта с несколькими языками лучше проверить, что покупатель получает письмо на правильном языке.

Login authentication и 2FA: когда усиливать вход, а не только регистрацию

Проверка email при регистрации защищает входную точку, но не всегда закрывает риск повторного входа. В документации Pro-версии описаны два связанных, но разных слоя: login authentication через OTP для подозрительных входов и двухфакторная аутентификация через приложение-аутентификатор. Эти функции не стоит включать всем пользователям без плана, потому что они меняют привычный вход в личный кабинет.

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

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

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

Двухфакторная аутентификация через приложение-аутентификатор больше подходит для персонала и постоянных B2B-клиентов, чем для случайных розничных покупателей. В документации описаны роли, trust-cookie для запоминания устройства, setup card в личном кабинете, backup codes и reset 2FA со стороны администратора. Это не просто "еще один переключатель". Перед включением нужно решить, кто отвечает за восстановление доступа, где пользователь хранит backup codes и как поддержка проверяет личность владельца аккаунта.

Проверка перед включением 2FA

Сначала включите режим только для тестовой роли или отдельного тестового аккаунта. Пройдите setup: открыть карточку 2FA, отсканировать QR-код, ввести 6-значный код, сохранить backup codes, выйти и войти снова. Затем проверьте сброс: администратор должен понимать, где отключить 2FA пользователю, который потерял телефон и backup codes. Если команда поддержки не готова к таким обращениям, не включайте 2FA для широкой аудитории.

Не смешивайте задачи: email verification нужен для подтверждения адреса, login authentication - для рискованных входов, а authenticator app 2FA - для усиленной защиты аккаунта. Включайте их по уровню риска, а не одним пакетом.

Фильтры спама, B2B-домены и очистка неподтвержденных записей

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

Одноразовые домены и MX-проверка

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

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

Очистка записей и удаление пользователей

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

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

Практический пример: проверка email для бесплатного цифрового товара

Рассмотрим предметный сценарий. Магазин продает платные цифровые товары и периодически раздает бесплатный пробный файл. Проблема: пользователи создают много одноразовых аккаунтов, получают файл и больше не возвращаются. Задача - проверять email для бесплатного заказа, но не добавлять лишний шаг всем покупателям платных товаров.

Цель

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

Подготовка

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

Шаги настройки

1. Откройте WooCommerce > Email Verification и включите проверку на оформлении заказа.
2. Выберите режим проверки, который подходит вашей теме: сначала протестируйте inline, затем popup, если popup лучше объясняет пользователю действие.
3. Если в вашей версии есть параметр Free orders only, включите его для проверки только бесплатных заказов.
4. Настройте срок действия OTP и лимит повторной отправки так, чтобы покупатель успевал получить письмо, но не мог бесконечно запрашивать коды.
5. В тексте popup напишите коротко: "Введите код из письма, чтобы получить бесплатный файл".
6. Сохраните настройки и откройте магазин в приватном окне.

Проверка результата

Сначала добавьте бесплатный товар в корзину и перейдите к оформлению заказа. Введите новый email. Магазин должен отправить код и не завершать заказ до подтверждения. После ввода кода заказ должен создаться, а покупатель должен получить обычные письма WooCommerce и доступ к файлу.

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

Нюанс, который часто пропускают

Если покупатель меняет состав корзины после получения кода, магазин должен не позволять использовать старую проверку для другого состояния заказа. В changelog Zorem есть исправления, связанные со снимком суммы корзины на момент отправки OTP. Это хороший пример того, почему тест должен включать не только "код пришел", но и "что будет, если покупатель поменяет корзину".

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

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

Мини-набор тестов

• Регистрация нового пользователя через My Account: письмо пришло, код работает, статус подтверждения меняется.
• Повторная отправка кода: пользователь получает новый код и не может успешно ввести старый, если он уже заменен или истек.
• Гостевой checkout: заказ не завершается до проверки, но после проверки идет дальше без зацикливания.
• Зарегистрированный пользователь с неподтвержденным email: магазин не дает обойти проверку через вход или checkout, если такой режим включен.
• Смена email в личном кабинете: адрес требует повторной проверки, если функция доступна и включена.
• Кэш и приватное окно: поведение одинаковое в обычном и приватном браузере, на мобильной и настольной ширине.

Аналитика и журнал событий

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

Если отправленных кодов много, а подтверждений мало, проверьте письмо, срок действия, доставляемость и понятность popup. Если много блокировок по allowlist, убедитесь, что список доменов не слишком узкий. Если много ошибок OTP, проверьте срок действия, повторную отправку и тексты, которые объясняют пользователю, какой код актуален.

Что считать хорошим результатом

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

Как передать процесс команде поддержки и не потерять контроль

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

Мини-регламент для менеджера

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

1. Попросить покупателя проверить папку спама и убедиться, что он смотрит последний код, если запрашивал письмо несколько раз.
2. Открыть Users и найти пользователя по email.
3. Проверить статус email verification и время последней попытки, если такие данные видны в вашей версии.
4. Отправить код повторно из админ-панели, если адрес выглядит корректным и нет признаков злоупотребления.
5. Подтвердить вручную только после дополнительной проверки личности или связи с реальным заказом.
6. Передать задачу администратору сайта, если письмо не отправляется вообще или похожая жалоба повторяется у разных покупателей.

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

Что фиксировать в первые дни после запуска

Первые несколько дней после включения checkout verification полезно вести короткий журнал: сколько обращений было из-за неполученного кода, сколько из-за неверного кода, сколько покупателей успешно завершили заказ после повторной отправки, были ли жалобы от корпоративных доменов. Если есть Analytics tab, часть этих данных видна внутри плагина, но живые обращения поддержки дают контекст, которого нет на графике.

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

Разделение прав

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

Безопасная адаптация под магазин: тексты, роли и небольшой snippet

В большинстве случаев WooCommerce Customer Email Verification лучше настраивать через интерфейс плагина: тексты popup, email, лимиты, роли, блокировки и режимы проверки. Код нужен только для маленьких точечных изменений, если они подтверждены документацией. Не правьте файлы плагина напрямую: обновление перезапишет изменения, а ошибка в коде может сломать checkout.

Когда достаточно настроек

Если нужно изменить цвет popup, заголовок письма, текст кнопки внутри настройщика, лимит повторной отправки или список доменов, используйте админку. Это безопаснее, чем snippet. Для мультиязычного сайта сначала проверьте WPML или другой механизм перевода строк, потому что ручное изменение одной фразы не решит проблему нескольких языков.

Пример безопасного изменения текста кнопки OTP

Документация разработчика показывает фильтр cev_checkout_send_otp_button_text для изменения текста кнопки отправки OTP на checkout. Такой snippet можно добавить через плагин Code Snippets или файл дочерней темы functions.php. Используйте его только если этот текст нельзя удобнее изменить через настройки или перевод.

add_filter( 'cev_checkout_send_otp_button_text', function( $text ) {
    return 'Получить код';
} );

После добавления откройте страницу оформления заказа в приватном окне и проверьте, что кнопка действительно изменилась, а отправка кода работает. Если появляется ошибка PHP, белый экран или кнопка пропала, отключите snippet через Code Snippets или удалите код из дочерней темы. Не меняйте название фильтра и не придумывайте дополнительные параметры, если они не описаны разработчиком.

Роли и исключения

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

Почему проверка может не сработать и как диагностировать проблему

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

Код не приходит на почту

Симптом: пользователь видит форму ввода кода, но письмо не появляется. Сначала проверьте, ушло ли письмо вообще. Отправьте тестовое письмо WooCommerce, проверьте SMTP-лог, папку спама и адрес отправителя. Если обычные письма WooCommerce тоже не доходят, проблема не в конкретном OTP-сценарии, а в доставке почты.

Что исправить: настройте SMTP, проверьте SPF/DKIM/DMARC, убедитесь, что адрес отправителя относится к домену магазина, отключите на время плагины, которые меняют почтовые заголовки. После изменения отправки повторите тест новым кодом, а не старым письмом.

Код приходит, но считается неверным

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

Что исправить: очистите сессию тестового браузера, запросите новый код, используйте последнее письмо, временно увеличьте срок действия и проверьте без кэша. Если проблема началась после обновления, посмотрите changelog и support-темы: у плагина уже были исправления, связанные с неверным PIN, ссылками проверки и повторным появлением popup.

Checkout verification выключен, но письмо все равно отправляется

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

Что исправить: сохраните настройки повторно, проверьте только один активный email-verification плагин, выполните тест на новом email и новой сессии. Если поведение сохраняется, временно отключите сторонние checkout-расширения и повторите проверку на стандартной теме.

Popup долго открывается или не появляется

Симптом: пользователь нажимает кнопку, страница зависает, popup не появляется или появляется без стилей. Обычно это связано с JavaScript, кэшем, объединением скриптов, несовместимой темой или ошибкой на странице checkout.

Что исправить: исключите страницы checkout и my-account из кэша, отключите отложенную загрузку скриптов WooCommerce, проверьте консоль браузера, временно выключите оптимизацию JavaScript. Если используется блоковое оформление заказа, сравните inline и popup-режимы.

Покупатель смог оформить заказ без подтверждения

Симптом: заказ создан, хотя email не подтвержден. Проверьте, какой checkout используется: классический, блоковый, кастомная воронка, REST API или интеграция стороннего сервиса. В документации Zorem есть отдельные заметки про WooCommerce Checkout Blocks, REST API customer creation и настройку Disable Store API Checkout.

Что исправить: воспроизведите обход на тестовом товаре, включите нужный режим проверки, проверьте Store API-сценарий, отключите конфликтующую checkout-интеграцию для теста. Если обход связан с кастомной разработкой, не пытайтесь исправлять его случайным snippet: проверьте документацию расширения и логику хуков WooCommerce.

Удаление неподтвержденных пользователей выглядит опасным

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

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

Когда WooCommerce Customer Email Verification будет удачным выбором

WooCommerce Customer Email Verification стоит использовать, если главная проблема магазина связана с неподтвержденными email: мусорные регистрации, бесплатные заказы на временные адреса, ошибки покупателей в почте, необходимость проверять корпоративные домены или желание видеть понятную аналитику по воронке подтверждения. Плагин особенно полезен, когда вы готовы настроить не только переключатель, но и весь путь: письмо, текст popup, срок действия OTP, повторную отправку, checkout-сценарий, список неподтвержденных пользователей и диагностику.

Если вы уже проверили отправку писем, сделали тестовую регистрацию, прогнали бесплатный или гостевой заказ и убедились, что реальные покупатели не застревают на вводе кода, можно скачать установочный файл и внедрять его поэтапно. Начните с минимального режима, соберите первые данные, затем расширяйте проверку на checkout, B2B allowlist, напоминания и очистку только там, где они действительно улучшают работу магазина.

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