Кнопка
Кнопка Лигал Кнопка Кнопка Кнопка Лигал

Подводные камни при разработке кешбека

Денис Гордиенко, генеральный директор Bright Mobile, об особенностях разработки кэшбек-сервисов

Сегодня расскажу о нюансах создания кэшбек-сервисов. Что это такое, вы наверняка знаете: магазин подключается к той или иной системе, при покупке клиент получает себе деньги или баллы на счёт, а потом тратит их при следующей покупке. Это первый вариант агрегаторов магазинов. Но сегодня я буду писать о кэшбеке для отдельных сетей.

Прямо сейчас мы делаем такое приложение для Мегахенда – крупной сети, занимающейся секонд-хэнд вещами в более чем ста городах России (в вашем она, скорее всего, тоже есть). Компания большая, в агрегаторы владельцы не пошли, решили сделать собственное приложение. При покупке начисляется определённый процент возврата, баллы можно тратить – всё по стандарту.

Я буду рассказывать об интересных вещах с точки зрения реализации, поэтому эта статья больше нацелена на архитекторов, которые стоят перед задачей составить проект приложения или веб-версии подобного кэшбека, либо владельцам собственных сетей, которые задумались над внедрением собственного кэшбек-сервиса. Всем остальным – для общего развития.

Что есть в приложении

С точки зрения реализации и интерфейса всё достаточно просто. В первой версии будет только самое основное:

  • экран с балансом;
  • история транзакций (т.е. список операций по начислению и списанию кэшбек-средств);
  • регистрация карты (пока кэшбек осуществляется по старинке: у каждого клиента есть карточка с идентификатором, баланс которой можно узнать на горячей линии или на сайте. Эту карту можно будет авторизовать в приложении);
  • выпуск новой карты для свежих клиентов;
  • экран для считывания на кассе (штрих-код или QR-код).

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

Теперь же нам надо было интегрировать БД огромной сети магазинов. Человеку неподготовленному, который о технических сложностях такой процедуры не имеет ни малейшего представления, может прийти в голову мысль: ну и что с того, что интеграция, интегрируют же платёжные и смс-шлюзы, просто будет на ещё одну больше.

Но дело в том, что выше перечисленные сервисы поработали над публичным API, к которому дают доступ всем, кто подключит с ними договор. Есть программисты поддержки, иногда один, иногда несколько – в зависимости от размеров шлюза, но в любом случае над стабильностью API работают. Когда же мы интегрируемся в ту или иную сеть, которая не давала API публично, встаёт вопрос подготовки программистов со стороны магазина. Подключаться, по сути, не к чему.

О подключении к API речи не идёт: должно быть проведено создание определённого API с нашей стороны и другой части – со стороны магазина. Так оказалось выгоднее и удобнее, получился некий Франкенштейн (в хорошем, впрочем, смысле слова). Конкретного шлюза нет, есть часть модулей у нас и часть со стороны сети.

Для методов работы приложения, магазин подключается к нам, для данных с их стороны – подключаемся мы.

Что внутри?

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

Нам нужно забрать БД себе, при этом так, чтобы не было риска нарушить коммерческую тайну, т.е. БД не могли взломать. Слив клиентской базы для компании – дополнительный риск, поэтому к себе мы забираем только самую простую персоналку. Транзакции, скорее всего, мы хранить на внешнем контуре не станем, а будем запрашивать индивидуально: каждый раз, когда клиент будет заходить в раздел транзакций, во внутренний контур будет направляться соответствующий запрос.

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

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

Мы станем обращаться не в главную БД, чтобы не перегружать её, а в дополнительную. Данные о регистрации затем поступают в общую базу, растекаются по всем 100+ магазинам, подключаются к сайту и пр. Будет интерфейс для кассиров, чтобы забивать все данные, подключение с сайта и пр.

Работа с кассой

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

Регистрация карты в приложении подразумевает добавление функционала в приложение: старая карта уже есть, но теперь клиент хочет пользоваться ею в новом сервисе. Часто бывает так, что указанный при регистрации уже имеющейся карты номер телефона устаревает, и возникает рассинхрон с тем номером, через который человек будет авторизовываться. Т.е. часть данных мы можем автоматически определить и привязать к карте: зарегистрировал номер, вошёл – всё отлично.

Но если номер телефона не актуален, и войти по нему нельзя, клиенту потребуется войти в раздел «Регистрация карты», и привязать себя именно там. Система сравнивает вторичные данные, которые он указывал прежде, например, адрес. А для совсем запущенных случаев, когда другой не только номер, но и адрес или даже фамилия, есть ручной вариант по звонку на горячую линию.

Вместо итога

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

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

0
5 комментариев
Популярные
По порядку
Ivan Struzhkov

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

Ответить
3
Развернуть ветку
Руслан Семагин

Слово "архитектура" в этой простыне выглядит как случайное недоразумение.

А советы "архитектора"..., ну, уволил бы сразу.

Денис, пора таки прекращать срамиться на технические темы, лучше по старинке, про общую водяную воду.

Без обид, ну правда же...

Ответить
1
Развернуть ветку
Денис Гордиенко

Руслан, ты опять выходишь на связь? Смотри, а то потом опять звонить извиняться будешь... Или обиделся, что я твою поделку покупать не стал?

Ответить
0
Развернуть ветку
Руслан Семагин

Родной, ты ничего не перепутал?
О каких обидах речь?
Просто пора остановиться, и не нести эту безудержную дичь которую даже читать как-то неловко.
Ну не идёт у тебя на эту тему, ну не дано может, или курсов мало пока прошёл, ну может чуть позже получится. Честно, ерунду же пишешь.
Но смотри сам конечно, если нравится, никто не запретит.
Не отвечай, пжл.

Ответить
0
Развернуть ветку
Nikolay Kenig

Не посчитайте за рекламу, но я сделал сайт где продавцы выкладывают ссылки на свой товар и предлагают кэшбэк, промокод или что там еще за то что у них его купят.
Сайту 2 месяца. товаров не так много около 200 вроде, да и рекламу я нигде не делал. Создал сайт можно сказать на коленке.
https://sellermall.ru/

Ответить
–6
Развернуть ветку
Читать все 5 комментариев
Хакеры взломали DeFi-платформу Qubit Finance и украли криптовалюту на $80 млн Статьи редакции

Команда проекта предложила вернуть деньги за награду — но им пока не ответили.

Скоро выйдут: сериалы про WeWork, Theranos, Uber и Spotify Статьи редакции

Три из них можно будет посмотреть уже весной 2022 года.

Обман "Озона" с акцией "баллы за отзывы" (заблокировали аккаунт с 3000+ баллами)

Несколько месяцев мной старательно делались видеообзоры на купленные товары. За каждый отзыв с видео и фото начислялись разные деньги (100-150 баллов было обычно). А как захотелось использовать эти баллы и были созданы заказы с ними - "Озон" аккаунт заблокировал (объяснять причины и разблокировать отказывается). 46890080-0775 - один из последних…

Как и почему я переехал в Иннополис: плюсы и минусы

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

Просмотр сетки ордеров
Доходы Yota от роуминга выросли в 1,6 раз

Ковидные ограничения стали испытанием для мобильных операторов, которые недополучили доход от роуминга в 2020 году. В Yota в 2020 году выручка от роуминга сократилась в два раза по сравнению с 2019 годом.

Биржевой стакан в мобильном приложении БКС Мир инвестиций
Что посмотреть про ИТ в TikTok? Рассказываем, как снимаются шутки про работу айтишников

Делимся кейсом: как найти свою аудиторию в TikTok и зачем это нужно крупной ИТ-компании.

От техподдержки через переводчик до главного канала продаж

Как изменился «AliExpress Россия»: рассказывают «старички» маркетплейса.

null