Сценарії, канали, таймінги й ліміти

14. OTP - підтвердження телефону#

OTP - це одноразовий код, який клієнт отримує на телефон і вводить на сайті.

Збільшити ↗

Як увімкнути OTP#

1. Спочатку перевірте SMS або дзвінок.
2. Відкрийте OTP -> Налаштування OTP.
3. Увімкніть OTP Статус.
4. Увімкніть тільки потрібні сценарії OTP.
5. У полі Канал надсилання OTP виберіть, через що модуль має спробувати відправити OTP-код першим: SMS, Viber або Telegram. Якщо увімкнена Авторизація дзвінком, цей блок показується як Канал OTP без дзвінка: першим буде дзвінок, а вибраний канал працює тільки для OTP без дзвінка.
6. Налаштуйте довжину коду і часи.
7. Перевірте маршрути сторінок, якщо оформлення замовлення нестандартне.
8. Натисніть Зберегти.
9. Протестуйте на сайті як клієнт.

Сценарії OTP#

Як OTP працює для клієнта#

1. Клієнт вводить телефон.
2. Модуль перевіряє формат номера, країну, IP, браузер, сесію і ліміти.
3. Якщо все нормально, модуль вибирає сценарій доставки OTP.
4. Якщо увімкнена авторизація дзвінком і вибраний шлюз її підтримує, модуль спочатку запускає дзвінок.
5. Якщо дзвінок не використовується, модуль створює OTP-код і відправляє його через канал, вибраний у полі Канал надсилання OTP.
6. Якщо дзвінок не вдався і ввімкнене резервне SMS для дзвінка, модуль створює OTP-код і надсилає його саме через SMS.
7. Клієнт вводить код або підтверджує дію через дзвінок.
8. Модуль перевіряє код, результат дзвінка і термін дії підтвердження.
9. Якщо перевірка успішна, номер вважається підтвердженим.

Якщо будь-яка перевірка не пройдена, код або дзвінок не запускається. Це зроблено спеціально, щоб не витрачати баланс на ботів і підозрілі запити.

Логіка вибору каналу OTP#

Для OTP є окреме поле Канал надсилання OTP. Воно не залежить від каналу звичайних повідомлень адміну, статусів замовлення, відкладених подій або масової розсилки.

Якщо ввімкнена Авторизація дзвінком, адмінка одразу змінює цей блок на Канал OTP без дзвінка. Це не декоративна назва, а захист від плутанини: поле не керує першим дзвінком або резервним SMS після його помилки.

Основна логіка така:

1. Дзвінок має пріоритет, якщо ввімкнена Авторизація дзвінком, модуль і OTP увімкнені, а вибраний Call gateway підтримує потрібний сценарій. Це може бути SMS-шлюз із підтримкою дзвінків або окремий Stream Telecom.
2. Резервне SMS після дзвінка спрацьовує, якщо дзвінок не запустився або не підтвердився, поле SMS при помилці дзвінка ввімкнене і налаштований основний SMS-шлюз. У цьому випадку модуль надсилає OTP саме через SMS, а не через канал, вибраний у полі Канал надсилання OTP / Канал OTP без дзвінка.
3. Якщо дзвінок не використовується, перша спроба OTP іде через вибраний канал: SMS, Viber або Telegram.
4. Якщо вибраний канал не спрацював, модуль перевіряє інші доступні й увімкнені канали в порядку Telegram -> Viber -> SMS, пропускаючи вже вибраний канал.
5. Якщо інших доступних каналів немає або резервне надсилання для них вимкнене, додаткової спроби не буде.

Приклади:

Важливо: якщо у списку вибору є тільки SMS, то після невдалого надсилання SMS запасного каналу не буде. Якщо вибрано Без SMS / тільки авторизація дзвінком, а SMS-шлюз не налаштований, резервне SMS для OTP недоступне.

Як працює резервне надсилання для OTP#

Приклад: якщо увімкнений дзвінок, підключений Telegram і налаштований SMS-шлюз, OTP спочатку піде через дзвінок. Якщо дзвінок провалиться і SMS при помилці дзвінка увімкнене, модуль відправить код через SMS, а не через Telegram або Viber. Якщо вибрано Без SMS / тільки авторизація дзвінком, після невдалого дзвінка SMS не піде.

Якщо дзвінок вимкнений і в Канал надсилання OTP вибрано SMS, модуль спочатку відправить SMS. Якщо SMS не спрацює, він не буде повторювати SMS, а перевірить тільки інші доступні канали: Telegram і Viber. Якщо вони не підключені, додаткової спроби не буде.

Які сценарії вмикати#

Код і таймінги#

Ліміти повторного надсилання#

Ліміти помилкових кодів#

Маршрути сторінок#

Стандартні сторінки OpenCart модуль підключає автоматично:

• account/register;
• account/edit;
• checkout/checkout.

Якщо у вас SimpleCheckout, One Page Checkout або інший нестандартний модуль оформлення замовлення, OTP може не з'явитися автоматично. Тоді потрібно додати маршрут сторінки до блоку додаткових сторінок.

Для звичайного користувача правило просте: якщо OTP на оформлення замовлення не з'явився, передайте цей пункт розробнику.

Шаблон для розробника:

У модулі SAP - SMS / OTP Pro увімкнений OTP для оформлення замовлення, але на оформлення замовлення поле підтвердження не з'являється.
Потрібно перевірити маршрут сторінки оформлення замовлення і додати його в "Додаткові сторінки перевірки телефону" або "Сторінки сторонніх модулів".

Ризикові замовлення: OTP лише коли це потрібно#

Збільшити ↗

Функція Ризикові замовлення потрібна, якщо магазин не хоче змушувати кожного покупця вводити OTP. Вона залишає звичайне оформлення швидким для безпечних замовлень і вимагає підтвердження тільки тоді, коли спрацювало активне правило ризику.

Вкладка OTP -> Ризикові замовлення показується одразу після ввімкнення сценарію OTP -> Налаштування OTP -> Оформлення замовлення. Якщо цей сценарій вимкнути, вкладка ховається, а перевірка правил не виконується.

Логіка роботи:

• Оформлення замовлення увімкнено, а Підтвердження ризикових замовлень вимкнено - OTP вимагається для кожного оформлення замовлення;
• обидва перемикачі увімкнено, режим Тестовий - правила перевіряються і пишуться в журнал, але оформлення замовлення не зупиняється через збіг;
• обидва перемикачі увімкнено, режим Робочий - OTP вимагається тільки коли збіглося перше активне правило;
• жодне правило не збіглося - покупець продовжує оформлення без OTP;
• правило збіглося, але номер уже підтверджено для того самого оформлення замовлення і строк підтвердження не минув - повторний код не потрібен.

Безпечне ввімкнення#

1. Переконайтеся, що OTP Статус і Оформлення замовлення увімкнені.
2. Відкрийте OTP -> Ризикові замовлення.
3. Увімкніть перемикач у блоці Підтвердження ризикових замовлень.
4. Залиште Режим роботи = Тестовий - лише журнал.
5. Виберіть поведінку Якщо OTP неможливо надіслати.
6. Задайте строк підтвердження оформлення замовлення.
7. Виберіть статуси замовлень, які магазин вважає успішними.
8. Створіть правила й натисніть Зберегти.
9. Зробіть кілька тестових оформлень: одне має збігтися з правилом, інше - ні.
10. Перевірте блок Останні спрацювання.
11. Лише після перевірки журналу перемкніть режим на Робочий - вимагати OTP.

Основні налаштування#

Як перевіряються правила#

Кожне правило має назву, перемикач Активне правило, пріоритет, логіку умов і одну або кілька умов.

• Менше число в полі Пріоритет перевіряється раніше. Наприклад, 10 має вищий пріоритет за 20.
• Усі умови (AND) означає, що мають виконатися всі умови правила.
• Будь-яка умова (OR) означає, що достатньо хоча б однієї умови.
• Після першого збігу перевірка зупиняється. Саме назва цього правила потрапляє в журнал.
• Неактивне правило не впливає на оформлення замовлення.
• Кнопка копіювання створює копію правила, а червона кнопка видаляє його. Окрема червона кнопка в рядку умови видаляє тільки цю умову.

Показники правил#

Тип покупця читається так:

• Гість - покупець не авторизований;
• Авторизований клієнт - покупець авторизований і має хоча б одне замовлення в обраних успішних статусах;
• Клієнт без успішних замовлень - покупець авторизований, але ще не має замовлень у цих статусах.

Список для показника Спосіб оплати не зашитий у модуль. Він автоматично читає встановлені платіжні розширення та їхні статуси. Для OpenCart/ocStore 2.3 перевіряються старі ключі налаштувань, а для 3.x — нові ключі payment_*, із сумісною перевіркою в обидва боки. Якщо спосіб оплати встановлено, але він не з'явився у правилі, спочатку переконайтеся, що його статус справді Увімкнено, а потім перезбережіть сторінку модуля.

Рекомендований стартовий набір#

Пороги нижче - приклад, а не універсальна істина. Суми треба адаптувати до середнього чека й валюти магазину.

Тримайте правила від вузьких до загальних. Правило масових повторів має бути вище за правило великої суми, інакше журнал показуватиме тільки загальне правило, а причина ризику буде менш зрозумілою.

Останні спрацювання#

Журнал показує дату, назву правила, замаскований телефон, статус рішення та ID створеного замовлення, якщо воно вже існує. Відкритий номер у журналі ризику не зберігається.

Типові статуси журналу: правило збіглося в тестовому режимі, OTP потрібен, OTP підтверджено, оформлення замовлення дозволено або оформлення замовлення пропущено через політику доступності провайдера.

Активні правила кешуються між запитами, а дані оформлення замовлення обчислюються тільки коли вони реально потрібні конкретній умові. Наприклад, для гостя модуль не читає історію успішних замовлень лише заради визначення Тип покупця = Гість; але якщо правило прямо використовує Кількість успішних замовлень, потрібний запит виконується. Це зменшує навантаження без зміни результату правила.

17. OTP - тексти повідомлень#

Збільшити ↗

У цій вкладці налаштовуються тексти OTP-повідомлень.

Як налаштувати#

1. Відкрийте OTP -> Повідомлення OTP.
2. Перевірте текст для входу, реєстрації, профілю і оформлення замовлення.
3. Переконайтеся, що в тексті є {otp}.
4. Натисніть Зберегти.
5. Протестуйте кожний увімкнений сценарій.

Головне правило#

У повідомленні обов'язково має бути шорткод {otp}. Саме він підставляє код.

Нормальні приклади:

Код підтвердження: {otp}

Ваш код для підтвердження телефону: {otp}. Магазин Example.

Не робіть OTP-повідомлення довгим. Клієнт має швидко побачити код.