Владельцу магазина сообщают: оплата подключена, бонусная программа подключена. Он открывает сайт и видит кнопки оплаты и блок с бонусами, заходит в кабинет сервиса и видит события с сайта. Всё на месте, проверять как будто нечего.
Так выглядел мультибрендовый магазин одежды на 1С-Битрикс, с которым мы работаем. Сайт переехал на боевой домен и открылся для поисковиков. Программа лояльности в это время общалась с тестовым контуром сервиса, а все три платёжные системы стояли в тестовом режиме. Первая настоящая оплата стала возможна через шесть дней после открытия, программа лояльности вышла из песочницы через двенадцать.
Что было видно и что происходило на деле
| Что видно на сайте и в кабинете | Что происходило на деле |
|---|---|
| Покупателю показываются бонусы | Бонусы считал тестовый контур сервиса, в боевом кабинете их не существовало |
| Кнопки трёх способов оплаты на месте | Все три платёжные системы стояли в тестовом режиме: купить на сайте было нельзя |
| В кабинете сервиса видны события с сайта | События приходили в тестовый кабинет, а менеджер сервиса смотрел в боевой |
Обнаружилось это по чужому вопросу. Менеджер сервиса лояльности написал: "Не вижу, чтобы вам выдавался API-ключ". Он смотрел в боевой кабинет, а сайт к тому времени месяц работал с тестовым.
Из тестового режима интеграции выходили по очереди. Сначала в боевой режим перевели рассрочку, на следующий день - оплату картой и частями и онлайн-кассу, ещё через пять дней - программу лояльности.
Почему тестовый режим не заметен
У большинства сервисов, которые подключают к магазину, два независимых контура. Тестовый, его называют песочницей, нужен для отладки: у него свой адрес, свои ключи доступа и свой кабинет. Боевой устроен так же, только в нём настоящие деньги и настоящие покупатели.
Сайт может работать с одним контуром, пока вы смотрите в другой. Панель управления сайта разницы не показывает: ключ вписан, модуль включён, запросы уходят и получают ответы. Витрина тоже не показывает: песочница отвечает сайту так же, как боевой сервис.
Молчаливые поломки у платёжных интеграций встречаются и в боевом режиме. Мы разбирали случай, когда платёжный виджет показывал баллы и терял рассрочку без единой ошибки в консоли.
Проверка первая: живой запрос к обоим адресам сервиса
Однозначный ответ даёт сам сервис. Мы отправили с сервера сайта запрос с ключом магазина на оба адреса сервиса лояльности - тестовый и боевой.
Двух запросов хватило, чтобы закрыть вопрос, в каком контуре живёт интеграция. Панель управления сайта такого ответа не даёт.
Владельцу для такой проверки доступ к серверу не нужен. Попросите подрядчика показать, что отвечает боевой адрес сервиса на ключ из настроек сайта. С оплатой проще: оформите заказ на небольшую сумму и оплатите его своей картой. В боевом режиме с карты спишутся деньги и на почту придёт кассовый чек. Нет списания или чека - оплата до боевого режима не доведена. Заказ потом верните: заодно проверите возврат.
Дальше мы восстановили хронологию по следам на сервере: когда появился модуль сервиса, когда ушёл первый запрос, менялся ли ключ.
Проверка вторая: довести функцию до суммы в чеке
Программу лояльности мы перевели в боевой контур. Ключ, адрес сервиса и код точки продаж меняли одним движением: если поменять их порознь, заказы и бонусы уезжают в разные точки кабинета. До и после перевода проверили живым запросом: боевой адрес принял ключ, первый расчёт корзины с витрины ушёл туда же.
Расплатиться бонусами после этого всё равно было нельзя. Списание бонусов на сайте применяет правило работы с корзиной внутри самого магазина, модуль сервиса только считает скидку. Правило выключили тремя неделями раньше, и тогда это было разумно: в песочнице бонусы ненастоящие, платить ими незачем.
Снаружи поломки не видно. Блок "Оплатить бонусами" работает, сумма скидки считается, а в итог заказа не попадает.
Отсюда вторая проверка. Сервис может отвечать по-настоящему, а функция до денег в чеке не доходит. Ловит это только сквозной сценарий: положить товар в корзину, применить бонусы, дойти до суммы к оплате и сверить цифру. Мы сверяли цену товара и итог корзины до включения правила и после.
Проверка третья: пройти путь покупателя заново в боевом режиме
Через неделю после перевода клиент прислал снимок экрана из кабинета сервиса: покупатель зарегистрировался на сайте, поле "Карта" пустое, бонусов ноль. За регистрацию на сайте обещана тысяча бонусов.
Сайт отработал штатно: передал сервису имя, телефон и почту, покупатель стал участником программы. Приветственные бонусы в боевом кабинете начисляет автоматическая рассылка сервиса, и доходит она только до тех, у кого есть карта лояльности. В розничном магазине карту выдают на кассе, и через минуту на неё приходит тысяча бонусов. Покупатель с сайта карты не получает. Выдать номер карты сайт не может: при регистрации сервис принимает от сайта только готовый номер.
В тестовом кабинете было иначе: бонусы приходили каждому, кто зарегистрировался на сайте, через минуту и без карты. Перед запуском сценарий проверили, и он прошёл. Настройки тестового кабинета в боевой не переехали.
За неделю без приветственных бонусов остались около десяти покупателей с сайта. Одна покупательница через день пришла в магазин и получила карту на кассе: через минуту ей начислили тысячу бонусов, через две она оплатила ими покупку. Остальным нужна настройка рассылки в кабинете сервиса, а пропущенные бонусы начисляют вручную.
Проверка ключа и адреса сервиса такого не показывает. После перевода в боевой режим каждый обещанный покупателю сценарий проходим заново, как покупатель: регистрируемся, ждём бонусы, оплачиваем ими заказ.
Ключ, который существует в одном экземпляре
Пока восстанавливали хронологию, нашлась ещё одна слабая точка. Ключ доступа к сервису существовал в единственном экземпляре - внутри базы сайта. Кто его выдал, не записано ни в переписке, ни в материалах проекта.
Такой ключ работает, пока сайт никто не переустанавливает. После переезда или смены подрядчика взять его неоткуда, и никто не помнит, кто его выдавал. Лечится это скучно - реестром доступов проекта. Ключи магазина мы туда внесли. По каждому ключу запишите: сервис, контур, кто и когда выдал, к кому идти за новым.
Три проверки одной таблицей
| Что проверяем | Как проверяем | Что нашлось в этом магазине |
|---|---|---|
| Сервис отвечает по-настоящему | Запрос с ключом магазина на тестовый и боевой адрес сервиса | Тестовый адрес ключ принял, боевой отказал |
| Функция доходит до денег | Товар в корзину, применить бонусы, сверить сумму к оплате | Скидка бонусами считалась, но в итог заказа не попадала |
| Сценарий проходит покупатель | Зарегистрироваться на сайте, дождаться бонусов, оплатить ими заказ | Приветственные бонусы приходили только владельцам карты |
Сценарий с приветственными бонусами в этом магазине перед запуском прошёл - в песочнице. Поэтому список проходим дважды: до запуска в тестовом контуре и после перевода в боевой.
Встроенные средства 1С-Битрикс здесь не помогут: три модуля самостоятельной проверки смотрят на сам сайт - систему, безопасность и скорость. С каким контуром внешнего сервиса работает магазин, они не знают.
Цифр о продажах в этой истории нет: работа диагностическая. Её результат - магазин принимает настоящие оплаты, бонусы покупателю считает боевой сервис, а ключи записаны в реестре доступов. Как мы ведём магазины после запуска - на странице сопровождения интернет-магазина.
