Блог

Мультилендинг для саратовского аналога «Убера»: как мы делали сайт службы такси со сложными алгоритмами

 

С чем пришел заказчик

В Саратове Убера нет, но такси есть. И продвинутые пассажиры есть: им удобно вызывать «извозчика» через свой смартфон, пополнять счет в приложении, сразу же оценивать поездку и не задавать вопросов диспетчеру в поисках машины – ее местоположение будет отображаться на карте.

Вот служба такси «Алло Такси» и сделала две версии такого мобильного приложения: отдельно для приема заказов от пассажиров и для распределения их между водителями.

Был у них и старый seo-оптимизированный информационный сайт с перечнем всех услуг и тарифов для клиентов, условий работы и правил подключения к сервису для водителей.

Старый сайт Алло Такси
Приложение для пассажиров в App Store и Google Play
Приложение для водителей в App Store и Google Play

e0b98f64b1
 

Что от нас требовалось

Нужно было запустить промостраницу, чтобы продвигать мобильное приложение для пассажиров. Лендинг должен быть кратким, ёмким, красивым.

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

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

Другое приложение с функционалом для водителей также должно было перекидывать пользователя на страницу сайта для внесения абонентской платы за доступ к сервису. Тут тоже было важно передавать сведения по зашифрованному каналу, чтобы посторонний не смог проникнуть в систему и «подкрутить» цифры. После пополнения баланса водитель получал извещение о продлении периода доступа к заказам в приложении.

В этой схеме лендинг должен был выступать своеобразной «прокладкой» между этими двумя мобильными приложениями и платежной системой. Пользователи же – и пассажиры, и водители – не должны ощущать заминок.

Для подключения эквайринга есть определенное условие платежного провайдера – наличие сайта для мобильного приложения. Еще одно требование – предоставить пользователю доступ к списку тарифов и к оферте. Создание лендинга позволяло решать обе эти задачи.

 

Как мы работали

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

Прототип сайта, его структуру, интерфейс для админки и дизайн с заказчиком утвердили быстро. Также быстро создали лендинг на 1С: Битрикс «Управление сайтом».

Промостраница создавалась динамической – информация на ней заменяется автоматически с учетом геотаргетинга. Такси работало в пяти городах: Саратов, Энгельс, Саранск, Пенза и даже Алматы (сейчас сервис отказался от сотрудничества с Пензой и Казахстаном и остался только в трех городах). В зависимости от местоположения посетителя меняются контактные данные службы такси и тарифы, остальная информация остается неизменной. Между городами пользователь может переключиться и вручную.

 

b04ea0ddd01

 

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

 

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

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

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

Причем все эти алгоритмы были зашифрованы, чтобы никто не мог «врезаться» в схему и внести в нее изменения.

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

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

 

Что получилось

Готовый мультилендинг с серьезной «начинкой» http://alloinfo.info/

За доли секунды информация обо всех денежных потоках обрабатывается «внутри» сайта, безопасно передается из мобильного приложения платежной системе и обратно.

 
screenshot_1
 

По этой схеме происходит оплата пассажиром поездки в такси.

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

screenshot_2

 

По этой схеме происходит оплата водителем всех заказов в такси.

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

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

Комментарии (0)

Добавить комментарий