Руководства
Проверка email при оформлении заказа
Проверьте адрес до оплаты и предложите исправление. Заранее решите, что делать, если email — единственный способ доставить заказ. Не превращайте неопределенность в ложную ошибку адреса.
Что делать с каждым ответом
Каждый раз одни и те же четыре результата. Инструкция меняется вместе с ситуацией, потому что вместе с ней меняется цена ошибки.
| Результат | Что делать здесь |
|---|---|
| Доставляемый | Продолжите оформление. Положительный результат дает основания использовать адрес, но не гарантирует получение чека и не устанавливает, кто управляет ящиком. |
| Рискованный | Прочитайте действие и причины. Ролевой адрес или catch-all домен не говорят о платежном риске. Продолжите, если это допускают правила доставки заказа; отдельно подтвердите контроль над ящиком, когда от него зависит доступ. |
| Недоставляемый | Попросите исправить адрес и объясните ошибку. Если заказ можно безопасно получить без email, ваши правила могут разрешать продолжить после предупреждения. Если email необходим, решите проблему с контактом до оплаты. |
| Неизвестно | Считайте адрес непроверенным. Разрешите оформить заказ, если есть другой безопасный путь его получения, и проверьте контакт позже. Не называйте адрес недействительным и не делайте вывода о мошенничестве. |
Проверяйте адрес до шага оплаты
На адрес из заказа могут прийти чек, лицензия или уведомление о доставке. Проверьте его, пока покупатель еще может изменить поле. Браузер поможет с очевидными ошибками формата, а сервер может вызвать Emvero после завершения ввода или при отправке формы. API-ключ храните на сервере.
Запоздалый ответ должен оставаться связанным с проверенным адресом. Если покупатель изменил поле, отбросьте старый результат и проверьте новое значение. Страница проверки в реальном времени объясняет запрос и ожидание.
Дайте покупателю выбрать исправление
Если ответ содержит LIKELY_DOMAIN_TYPO и подсказку, покажите введенный адрес рядом с предложенным. Покупатель может принять замену или оставить исходный вариант. Не меняйте домен автоматически и не очищайте поле.
Явная ошибка синтаксиса и предполагаемая опечатка требуют разных сообщений. INVALID_SYNTAX может быть основанием попросить исправить формат. SMTP_MAILBOX_NOT_FOUND описывает наблюдение об отказе SMTP-сервера принять получателя. Оно не доказывает отсутствие ящика или опечатку в домене. Текущие правила возвращают unknown с SMTP_RECIPIENT_REJECTED_AMBIGUOUS. Не придумывайте исправление, если API его не вернул.
Решите, зависит ли получение заказа от email
Если покупка уже доступна в аккаунте после входа или через другой безопасный путь, предупреждение об адресе может не останавливать оформление. Если рабочий ящик — единственный способ получить лицензию или доступ к аккаунту, исправьте явную проблему с контактом до оплаты. Объясните это требование рядом с полем.
Рекомендация API — один из сигналов для решения. Действие reject относится к адресу, а не к авторизации платежа. Так же ROLE_ACCOUNT, catch-all и статус risky не доказывают мошенничество. Проверку платежа и личности проводите отдельно от правил приема контактного адреса.
Ограничьте ожидание в форме
Полная проверка может вернуть pending с id и retry_after_ms. После интервала вызовите GET /v1/verifications/{id} с тем же ключом. Повторяйте опрос, только пока проверка выполняется, и прекратите ожидание при достижении предела формы. Emvero не отправляет callback.
Истечение срока или ошибка HTTP не дают отрицательного вердикта об адресе. Используйте выбранный запасной путь получения заказа, не выдавая сбой сервиса за недействительный email. Если оформление разрешено, сохраните идентификатор проверки вместе с соответствующим контактом, чтобы ваш процесс мог получить результат позже. Поля ответа описаны на странице API.
Разрешите безопасно исправить контакт после оплаты
После оплаты покупатель, подтвердивший доступ к аккаунту, может изменить адрес через ваш процесс работы с заказом или поддержку. Проверьте новое значение и обновите нужный заказ без повторного запуска платежа. Не обещайте, что поздняя проверка устранит любую неопределенность.
Emvero не отправляет чеки или письма подтверждения. Если доступ зависит от контроля над ящиком, отправьте собственное подтверждение; руководство по форме регистрации объясняет разницу. Адрес в заказе также не означает согласие на маркетинговые письма.
Reason codes, которые здесь что-то решают
Эти коды входят в словарь API и объясняют результат проверки. В пояснениях также указаны значения, которые текущие правила проверки или SMTP-проба не возвращают.
LIKELY_DOMAIN_TYPO | Домен похож на опечатку |
INVALID_SYNTAX | Адрес составлен неверно |
SMTP_MAILBOX_NOT_FOUND | SMTP-наблюдение об отказе в приеме получателя; текущие правила возвращают unknown с SMTP_RECIPIENT_REJECTED_AMBIGUOUS. |
ROLE_ACCOUNT | Имя адреса обозначает функцию; кто пользуется ящиком, не установлено |
Термины, которые стоит знать заранее
Синтаксис адреса
Правила формата, которые проверяют до сетевых запросов. Корректная запись не подтверждает работу домена или ящика.
Ролевой адрес
Адрес команды или службы, например support@. Он может принимать почту; подходит ли он вам, зависит от задачи.
Жёсткий и мягкий возврат
Постоянный и временный сбои доставки описывают попытку отправки. Узнайте, чем они отличаются от свидетельств проверки.
Выбор, который за этим стоит
Попробуйте на адресе, который вы знаете.
Бесплатная проверка возвращает результат целиком - каждую стадию, каждый reason code, ничего не скрывая.