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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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