Через интернет-магазин нашего клиента продаются коллекционные растения, поэтому цикл сделки большой, около 6-ти месяцев (заказы делают зимой, а получают весной и летом). Используется оплата с авансом 50% и доплатой остатка при отправке товара. Весь процесс лежал на менеджерах и обрабатывался вручную, что было крайне трудоемко.
Менеджеры работали со счетами в интерфейсе Ю-Кассы: при подтверждении заказа создавался счет, в него переносили список позиций для чека, а ссылка отправлялась в письме клиенту.
При большом количестве позиций в чеке на создание и отправку счетов требовалось много времени, а в интерфейсе Ю-Кассы приходилось вручную поддерживать актуальный список товаров и цен.
Варианты решений
Интернет-магазин работает на платформе InSales, а инструменты ограничены теми, что предоставляет платформа. Заказ всегда имеет 2 разных статуса:
- Статус заказа — отражает движение заказа по процессу сделки. Например, «Новый», «Согласован», «Отгружен», «Доставлен»;
- Статус оплаты — отражает только факт оплаты, оплачен или не оплачен.
![Order.png Order.png](/upload/medialibrary/394/394eb80ea832b3e54531fb774160a968.png)
Мы составили необходимый сценарий для автоматизации:
- После согласования нового заказа менеджер выбирает в административной части способ оплаты (предоплата 50%, оплата 50% или 100%) и изменяет статус заказа на «Согласован»;
- Пользователь получает письмо с ссылкой на страницу своего заказа и кнопкой перейти к оплате;
- На странице заказа кнопка «Перейти к оплате». При клике на кнопку пользователь попадает на страницу оплаты. В кассу передается сумма, описание, признак «Предоплата», и состав заказа;
- После оплаты статус заказа становится «Предоплачено», но статус оплаты всё еще «Не оплачен»;
- После отгрузки товара менеджер меняет статус заказ на «Отгружен», пользователю отправляется ссылка на оплату оставшейся части заказа + стоимость доставки + стоимости тары;
- После оплаты второй части заказа - статус оплаты меняется на «Оплачено».
Для такого процесса был выбор между сценарием «Умный платеж» от Ю-кассы, приложением Ю-кассы и использования интернет-эквайринга и страницы оплаты от Тинькофф (или приложения Тинькофф).
Приложения для CMS были самым быстрым и простым способом реализации оплаты онлайн. Но они не поддерживают внесение предоплаты.
Возможности страниц оплаты у Ю-Кассы и Тинькофф очень близки, поэтому было принято решение использовать Ю-Кассу, т.к. уже существует подключение к физической кассе и заказчику хорошо знаком интерфейс.
Особенности реализации
У заказчика уже существовал специальный сервис интеграций — выделенный сервер, через который мы могли постоянно получать информацию от магазина и от сервера оплаты. Поэтому весь функционал реализовывали на нем.
Часть времени ушла на настройку серверов и статусов заказа, служб доставки, вариантов оплаты в интернет-магазине.
![Variety of payment.png Variety of payment.png](/upload/medialibrary/d04/d04dbd3679186b389901f1d42a53fee5.png)
В административной части, после согласования заказа, менеджер должен выставлять необходимый вариант и способ оплаты.
![Filter.png Filter.png](/upload/medialibrary/e33/e335338fe5829e03b13f478d7ea3ef95.png)
![Options.png Options.png](/upload/medialibrary/176/176693b539fe9e973f3e7398fe2de7ab.png)
Реализовали обмен по API с сервисом приема платежей и обновление заказов в интернет-магазине.
При реализации обмена с сервисом приема платежей настроили передачу ставки НДС, позиций чека, признака расчета (Предоплата или Полный расчет), систему налогообложения.
![Goods1.png Goods1.png](/upload/medialibrary/ced/ced171c010d82caa7db2b38e23bd4a36.png)
![Goods2.png Goods2.png](/upload/medialibrary/efc/efcda89144aa7986d6bba41c68c33692.png)
Страницу оплаты использовали стандартную от Ю-Кассы.
![Ukassa.png Ukassa.png](/upload/medialibrary/496/49629edc17504053948373c8123119b1.png)
После проверки основного сценария решили начать тестирование на реальных заказах.
В этот момент выяснилось, что достаточно часто в список позиций после предоплаты добавляются новые товары. Значит, для предоплаченных товаров в чеке мы должны отображать только половину стоимости, а для добавленных — полную стоимость товара.
Для того, чтобы учитывать все оплаченные ранее товары и не создавать дополнительных заказов для новых позиций мы решили хранить в магазине информацию о полученной сумме предоплаты. После успешной оплаты мы обновляли не только статус заказа, но и записывали сумму оплаты в отдельное поле заказа. Теперь менеджеры точно знали сколько уже предоплаты внес клиент.
![Options2.png Options2.png](/upload/medialibrary/fe8/fe8ce84f1083674b73c285819c286bfd.png)
Также возникла проблема с тарой в заказе. Интернет-магазин заказчика был интегрирован с системой складского учета «Мой склад». В зависимости от количества и состава заказа выбиралась подходящая тара для упаковки — коробки разного размера. Стоимость тары также добавлялась во вторую часть оплаты.
Для того, чтобы можно было гибко добавлять и изменять тару и его цену мы создали специальные товары в интернет-магазине.
![Order positions.png Order positions.png](/upload/medialibrary/fb6/fb6c5b69364de989f8b9fee70c7a0df5.png)
Для таких товаров применялось игнорирование при создании первого чека. Они попадали только во второй чек, и только со 100% стоимостью.
Эффект от проведенных работ
После реализации оплаты онлайн существенно сократилось время на обработку заказа. При этом работа над заказом осуществляется только в интерфейсе интернет-магазина.
Дополнительно для смены статусов заказа мы настроили необходимые уведомления, поэтому клиенты теперь могут оплатить заказ в личном кабинете интернет-магазина.