Что такое white label приложение
White-label банкинг: готовые банковские продукты под собственным брендом
Запуск решения цифрового банкинга и других приложений обычно требует значительных временных и финансовых ресурсов. Вместо создания банковских решений с нуля, финтех-компании могут запускать свои проекты, используя решения White-label, тем самым минимизируя время выхода на рынок и экономя ресурсы.
В этой статье мы расскажем, что такое решение цифрового банкинга по моделе White-label и какие его основные преимущества.
Что такое White-label цифровой банкинг?
White-label банкинг включает в себя бэк-офис и готовые к использованию банковские и платежные продукты, включая API-интерфейсы для подключения к разным поставщикам BaaS услуг. Решение также позволяет разрабатывать новые продукты, не создавая их с нуля или подключать новые интеграции.
Продукты цифрового банкинга по модели White-label
Решение цифрового банкинга по моделе White-label предоставляет следующую функциональность:
Онбординг клиентов, AML / KYC
Чтобы создать учетную запись и открыть расчетный счет, новые клиенты должны зарегистрироваться, пройти процесс верификации и предоставить соответствующую информацию. Функциональность KYC / AML поможет гарантировать, что этапы регистрации будут безопасными, быстрыми и беспроблемными.
Платежи и обмен валюты
Создание платежной инфраструктуры – одно из самых сложных, но с готовыми white-label услугами для платежей и обмена валют вы сможете подключиться к различным провайдерам и предоставить своим клиентам разные способы оплаты и доступные валюты.
Лицензия как услуга
Финтех-компании могут работать под сторонними лицензиями учреждений электронных денег, платежных учреждений или банков.
Выпуск карт
Используя интеграцию с поставщиком решения по выпуску карт, вы можете выдавать своим клиентам дебетовые карты под своим брендом.
Спонсорство IBAN
Существуют десятки регулируемых компаний, которые предлагают возможность генерировать IBAN без необходимости в индивидуальной лицензии на электронные деньги или платежной лицензии, а также подключаться к SEPA через них. Такие компании позволяют автоматически выдавать IBAN и управлять ими через свой API. Эти IBAN-номера создаются на имя партнера – клиент получает IBAN-номера с реквизитами партнера (например, банка, платежной системы).
Можно, но очень сложно интегрировать различные решения white-label от разных поставщиков самостоятельно. С помощью платформы цифрового банкинга Macrobank, вы сможете упростить этот процесс, так как получите не только платформу с уже готовыми интегрированными решениями и интеграциями, но и архитектуру, которая позволит вам запускать новые продукты.
White-label приложения для конечных пользователей и white-label цифровой банкинг
Цифровой банкинг по моделе white-label связан с операциями бэк-офиса, тогда как приложения по моделе white-label, такие как интернет-банк и мобильное приложение, обеспечивают операции для конечных пользователей. Они также могут хорошо дополнять решение цифрового банкинга и работать как единое целое.
Финтех-компании могут в кратчайшие сроки создавать приложения для конечных пользователей под своим брендом в кратчайшие сроки.
Преимущества white-label цифрового банкинга
Многие финтех-компании предпочитают сотрудничать с поставщиками white-label платформ цифрового банкинга. Создание продуктов при помощи таких платформ и с использованием API-интерфейсов, дает множество преимуществ:
Экономия ресурсов
Конечно, вы можете разработать свое решение с нуля. Однако, для разработки вам потребуется опытная ИТ команда, вам будет также необходимо тестировать решение и исправлять ошибки. Но кроме человеческих ресурсов, вам придется вложить немало денежных средств. Вместо этого вы можете купить готовую платформу, чтобы сократить свои расходы и сроки.
Созданы экспертами индустрии
Готовые решения по модели white-label разрабатываются специалистами с большим опытом в индустрии при использовании новейших технологий, тщательно протестированы, а также соответствуют регулятивным требованиям.
Быстрый выход на рынок
Почему бы не пропустить трудоемкий этап разработки и тестирования приложений? С решениями white-label вы сможете быстрее выходить на рынок и добавлять новые функции, не тратя много времени на их создание с нуля. Затем вам остается только настроить решения и начать их предлагать своим клиентам.
Знайте свой продукт с самого начала
Ознакомьтесь со своим продуктом – попробуйте, протестируйте и только тогда начните использовать. Если вы создаете приложения самостоятельно, То, скорее всего, будет много неожиданных моментов. Индустрия финтех быстро меняется, а процесс разработки продукта может длиться 1-2 года. По этой причине, на момент запуска решения, ваша новая версия может быть устаревшей и не соответствовать ожиданиям клиентов.
Знайте свой бюджет со старта
Поставщики готовых white-label решений, такие как Advapay, предлагают пакеты решений в зависимости от выбранного модуля, количества интеграций или бюджета. Таким образом, вы сможете точно рассчитать свои расходы со старта. В сравнении, разработка собственного решения может превысить первоначальный бюджет, так как точно рассчитать все расходы перед началом разработки невозможно – очень часто, проекты затягиваются, что и влечет повышение расходов.
Запускайте свой цифровой банк с помощью нашего white-label решения – создавайте новые продукты, разработанные нашими экспертами и подключайтесь к нашему хабу готовых интеграций.
Остались вопросы о нашем решении? Свяжитесь с нами чтобы узнать больше.
Системный гайд по созданию White Label android-приложений
Как написать код один раз, а продать 20 мобильных приложений? Мы нашли ответ путём проб и факапов и разложили опыт по пунктам: из статьи вы узнаете, как безболезненно реализовать White Label android-проект.
Greetings and salutations! Меня зовут Кирилл, по работе я однажды получил крутую задачу по разработке White Label android-приложения. Изучил достижения коллег в этой области и нашёл только:
входные гайды (раз, два, три, etc) о механизмах, но без промышленного дизайна;
статьи, в которых освещены узкие аспекты задачи (раз, два, etc).
На мой взгляд, теме не хватает цельного гайда, который проведёт от потребностей к требованиям, от требований к архитектуре и вооружит best practices. Поэтому я решил сделать его сам.
1 Ставим задачу
Мы в «Лайв Тайпинге» уже 10 лет делаем приложения для сегмента eCommerce и retail. За это время мы поняли, что и малый, и средний бизнес нуждается в дешёвых приложениях для систем лояльности: крупные ретейлеры уже обзавелись такими продуктами и приучили пользователей к мобильным приложениям.
Работает система просто (покупатели показывают приложение на кассе вместо пластиковой карты и получают скидки и бонусы), а для её реализации нужны типовые фичи: регистрация, виртуальная дисконтная карта и прочие.
Бюджет ограничен. фичи типовые. да здравствует конструктор приложений! Или White Label продукт? Пока отложим термины и опишем задачу: генерировать приложения из единой кодовой базы, каждое – с дизайном под бренд клиента и только нужными ему фичами.
Задача: создавать приложения для разных клиентов из единой кодовой базы
1.1 Визуализируем решение
Посмотрим, как это должно работать на примере экрана дисконтной карты. В магазине карту можно использовать двумя способами: чтобы узнать баланс и чтобы получить тот или иной бонус.
У каждого бренда своя программа лояльности, например в SEPHORA накапливаются бонусные баллы и процент скидки, а в «Пятёрочке» только баллы. В приложениях это выглядит так:
Мы хотим поддерживать как можно больше программ лояльности, при этом интерфейс оставить общим. Предусмотрим вариативность, получим возможный вид экрана карты для разных клиентов:
Как реализовать такой проект без боли? Прочитайте статью и найдёте ответ.
Мы знаем, о чём говорим, ведь уже создали «Лояку» — White Label продукт, который помогает быстро собирать крутые мобильные приложения с программой лояльности. Рост выручки, клиенты в курсе всех акций — вот это вот всё 🙂
1.2 Детализируем требования
Разложим видение по полочкам: как в ТЗ, но проще.
Функциональные требования
Реализовать общие модули фичей:
новости – клиент узнаёт об акциях и жизни сети магазинов;
лояльность – получает дисконтную карту, узнаёт баланс, пробивает на кассе;
Задавать отдельно для каждого приложения:
наборы фичей, чтобы выбирать сами модули и настраивать их параметры;
бренд, чтобы настраивать цвета и менять ресурсы: шрифты, картинки, зашитый контент.
Нефункциональные
у приложений должен быть общий код;
настройка нового приложения – меньше четырёх часов разработчика;
архитектура должна упрощать расширение модулей и поддержку от 10 до 100 приложений.
1.3 Что пилим то? Конструктор? White Label?
Требования ясны – разберёмся с терминами. На старте проекта я думал, что мы делаем «конструктор приложений». Искал статьи с опытом создания, а находил рекламу готовых продуктов. Потратил пару часов на гугл и с радостью сэкономлю время вам:
универсальный сервис сборки приложений из готовых компонентов;
например, AppGyver – drag’n’drop вёрстка, программирование на низкоуровневых фичах (открыть экран, сделать фото);
творим что угодно – от приложений по покупке золота до приёмки грузов.
конструктор для конкретного типа приложений, например для такси;
ребрендинг под клиента и настройка высокоуровневых фич (новости, профиль)
Наш фокус на системах лояльности. Значит, делаем White Label. Гуглим «white label android development» и находим то, что нужно.
2 Проектируем и воплощаем
Строим системную схему White Label приложения
Для успешной реализации проекта нам нужно создать «понятную» и «расширяемую» архитектуру (раскрывать термины не буду, здесь хватит интуитивного понимания). Для этого заглянем вглубь системы, выделим подзадачи по слоям Clean Architecture…
… и получим четыре жирные проблемы:
Как шарить кодовую базу между приложениями?
Как сделать ребрендинг?
Как задавать конфиги?
Как отключать ненужные модули и настраивать необходимые?
В очередь, проблемы, в очередь!
2.1 Шарим код
Задача – одна кодовая база, до 100 приложений. Решение – Gradle Product Flavors.
Если вы ещё не знакомы с Gradle Product Flavors, советую почитать документацию или общие статьи. А можно и сразу в контексте White Label: кратко или в формате инструкции
Главное преимущество. Относительная простота переиспользования кода и ресурсов, удобство сборки.
Главный недостаток. Если вариантов больше 100, то в проекте и конфигах будет тяжело ориентироваться. Но у нас меньше, поэтому ок.
Альтернативы, на мой взгляд, рассматривать нет смысла: решение надёжное, из коробки.
Пример flavors. Допустим, на старте делаем два приложения:
«Лояка» — абстрактная компания;
«Ювелирия» — сеть ювелирных магазинов.
Здесь и далее привожу сокращённые примеры из тестового проекта к статье.
Наконец, задействуем flavors — в build.gradle уровня app :
2.2 Перекрашиваем
2.2.1 Концепт
У каждого приложения свой бренд, который складывается из:
шрифтов, картинок, строк;
зашитого контента (соглашений, ссылок в соц. сети).
Благодаря flavors тоже решим задачу просто. Загрузим в голову 3 факта:
общие код и ресурсы проекта лежат в папке main ;
для gradle main это как дефолтный flavor;
Слева — ресурсы по flavor; справа — итоговый APK.
2.2.2 Best practices
Крайне важно заранее договориться с дизайнерами:
ресурсы в приложениях называем одинаково — вставляем в проект прямиком из дизайна;
тему задаём чётким набором цветов — для перекрашивания копируем colors.xml в новый flavor и просто меняем значения.
Проблема в том, что костыли масштабируются на 100 приложений! Представьте, что дизайн оставили, а для решения проблемы ввели новый цвет в общей теме. Приходит новое приложение, а там опять несоответствие: вводим очередной цвет, итог — тема на сотни значений и проект, который тяжело поддерживать.
Создать и поддерживать чёткую схему для всех приложений на порядок дешевле, чем расширять код, состоящий из «уникальных» косяков.
2.2.3 Пример схемы цветов
Задаём цвета бренда в файле project_styleguide.xml :
2.3 Задаём конфиг
2.3.1 Концепт
Фичи настраиваем на двух уровнях:
отключаем ненужные модули;
меняем параметры внутри самих модулей.
Начнём с того, что зафиксируем правила в типовой форме и пошарим на команду. Настройка нового приложения упрощена: аналитик собирает с клиента требования и присылает форму. Разработчику остаётся механически перевести её в конфиг.
Упрощённый пример дока в формат «модуль-фича-параметры»:
Подключаемые модули:
Аутентификация:
логин пользователя: телефон или email;
Карта лояльности:
тип штрих-кода: EAN-8, EAN-13, CODE-128.
2.3.2 Пути решения
Как сделать качественный конфиг? Само качество определим так:
удобство работы – «простота» чтения, «простота» заполнения (в идеале, хотим DSL);
Скорость обработки – важно, чтобы чтение конфига не тормозило приложение.
Выделим основные пути:
задаём переменные в gradle скрипте;
json объект в файле;
зашит локально, либо получаем с сервера.
Кратко оценим пути по критериям.
2.3.3 Путь №1. Gradle buildConfigField
удобство создания — делаем DSL на минималках: выносим типы и возможные значения параметров в переменные; выявляем синтаксические ошибки на компиляции;
простота — большинству уже знаком;
скорость — обращаемся к классу BuildConfig в памяти.
Главный минус — отвратительная читаемость: переменная состоит из четырёх блоков, подсветки синтаксиса нет.
Пример переменной на условном DSL:
buildConfigField MAIN_SCREEN_TYPE, MAIN_SCREEN_VAR, MS_SHOPS
2.3.4 Путь №2. JSON
удобство чтения — особенно в формате HOCON;
удобство создания — делаем DSL через JSON Schema, проверяем на ошибки по мере написания;
переиспользование — шарим между iOS и Android.
скорость — придётся перед запуском считать из файла или получать с сервера;
время на освоение — по сравнению с первым вариантом JSON Schema наверняка менее популярна.
2.3.5 Так что же лучше?
Когда делали проект, даже не изучали альтернативы. Сразу сделали через Gradle. На мой взгляд, JSON + Schema его побеждает. Удобство чтения — приоритет, при этом удобство создания остаётся на том же уровне, если не лучше. Дополнительная секунда для загрузки файла на общем фоне незначительна.
Сделали конфиг через Gradle, не изучая альтернатив. Но оказалось, что JSON Schema удобнее для чтения – и это её главное преимущество.
2.3.6 Best practices для buildConfigField
при изменение имени или типа переменной придётся делать Find & Replace по всем конфигам.
Дальше настраиваем приложения в скриптах flavor, которые на первом шаге заботливо вытащили по файлам.
2.3.7 Получаем доступ к конфигу
Спроектируем решение в контексте Clean Architecture.
Как сгруппировать параметры по классам? Мы на проекте за группу взяли экран, а зря. С одной стороны, компактные классы, а с другой — возникли коллизии, например на экранах ввода номера телефона и подтверждения кода нужна маска номера. Пришлось реализовать считывание из конфига 2 раза.
С BuildConfig это легко, но с JSON будет грязно. Считаю, что оптимально группировать по процессу (флоу). Под процессом здесь понимаю целевой use case и вторичные по отношению к нему. Обычно это группа экранов, например в модуле лояльности два целевых процесса:
аутентификация — чтобы авторизоваться, придётся ввести логин, а затем код подтверждения;
просмотр дисконтной карты — чтобы получить доступ, нужно сначала её привязать, либо сгенерировать.
Пример реализации конфига для второго процесса: фрагмент BuildCardConfig.kt:
В итоге получим архитектуру работы с конфигом (диаграмма классов UML; в ui MVVM):
UseCase работает только с одним конфигом, ибо в этом классе есть все параметры целевого процесса. Если требуется больше одного — звоночек, похоже UseCase делает много вещей.
2.3.8 Валидируем конфиг
Возникает проблема: если создавать UseCase на каждый параметр, то будет много пустых классов. Ведь правила есть не везде.
Впрочем, если правил у вас субъективно мало и коллизии очевидные, такая валидация не нужна. Мы обошлись без неё и багов из-за этого пока не ловили.
2.4 Настраиваем фичи
2.4.1 Выбираем модули
Мы должны отключать модули, которые не нужны клиенту. Под модулем здесь пониманием связный и независимый кусок функциональности, обычно крупный. Например, модуль «лояльность»: в него входит работа с дисконтной картой и аутентификация.
Модуль здесь – крупный связный и независимый кусок функциональности.
В идеале хочется выпиливать код и ресурсы выключенных модулей из APK. Но на мой взгляд, это оверкилл, поэтому ограничимся функциональным отключением.
Рассмотрим главные точки связи модуля с приложением:
Переходы из ui — боттом навигация, рандомная кнопка, etc;
Реакция на события — кастомные (выбран город), платформы (найдена сеть), etc.
По опыту, обычно хватит убрать пункт модуля из меню, например, для лояльности — это таб из боттом навигации. Я реализовал пример в MainViewModel и MainActivity тестового проекта.
Но бывает, что есть межмодульные переходы, например когда по кнопке из акции попадаем на экран карты – такое придётся обработать отдельно для каждого кейса.
На события в «Лояке» реагирует только модуль пушей. Когда юзер выбирает свой город – подписываемся на соответствующий новостной канал. Опять же обрабатываем каждый кейс.
2.4.2 Настраиваем экраны и бизнес-правила
Настройка конкретных фичей основана на уже спроектированной архитектуре. Например, при отсутствии сети мы хотим показывать карту лояльности из кэша. Однако хотим это настраивать, чтобы отключать кэш для кейсов, когда критична свежесть данных.
Например, получаем карту двумя способами: привязываем физическую или генерируем виртуальную. Не у всех клиентов доступны оба способа, но один гарантирован.
2.4.3 Ещё один трюк
Иногда вариативную вёрстку целесообразнее сделать без конфига.
Вспомним начало поста, хотим показать дисконтную карту – номер, статус, размер скидки и баланс бонусов. Однако процессинг лояльности у клиентов разный, поэтому не все поля гарантированы:
Аналитик собрал наиболее вероятные поля, дизайнер продумал кейсы и переиспользовал вьюхи. Получилось так, что обошлись даже без конфига — смотрим на то, какие данные приходят с бэкенда и показываем необходимое состояние. В тестовом проекте реализован пример — CardInfoFragment.
3 Подведём итог
Мы успешно спроектировали архитектуру White Label android-проекта, которая соответствует поставленным требованиям, а именно позволяет:
✅ развивать общую кодовую базу – расширять модули фичей и собирать из одного кода разные приложения, от 10 до 100;
✅ создавать приложения под клиента – настраивать набор модулей и параметры фичей, менять бренд, делать это относительно быстро (до четырёх часов, по моей оценке).
Горькими уроками поделились, best practices передали. Надеюсь, наш опыт создал цельное представление о создании White Label android-приложений и комфортную отправную точку для вашего проекта.
Напомню, что полный код примера доступен на гитхабе — можно изучить реализацию подробнее, поиграть с настройками. Пример полноценного приложения есть в сторе.
Если возникли вопросы — пишите в комменты, буду рад ответить! А если заинтересовала «Лояка» как продукт, то мы с удовольствием расскажем больше 🙂
4 Куда развить решение?
Мы продаём целую систему, а что если продавать модули в другие приложения? Тот же White Label, но на системный уровень ниже. Мы такую задачу решали, если интересно – напишите в комментах, расскажем.
Когда количество приложений растёт, хочется CI и CD. В этом репозитории есть подробный гайд по настройке Azure Devops.
Если не нужна детальная настройка фичей, а писать flavors руками надоело – сделайте автогенерацию flavors по json конфигу.
Бизнес бьёт ключом, клиентов больше сотни? Пора автоматизировать создание приложений.
Если знаете кейсы, на которые нет ссылок в нашей статье, то обязательно скиньте их в комменты – вместе мы точно соберём крутую библиографию!
Что такое White Label, как это работает и для кого подходит
White Label сводит крупные и мелкие компании на рынке, обеспечивая им равные условия — доступ к клиентской базе, рекламу на популярных ресурсах, гарантированный доход. В статье расскажем, как это работает и для кого подходит.
Что такое White Label
White Label — это партнерское взаимодействие, при котором одна компания выпускает продукт, а другая продает его под своим брендом. Каждый участник сделки исполняет свои обязательства. Такой формат налаживает массовый выпуск потребительских товаров. Главное преимущество — продукт попадает на рынок под разными брендами и с разными ценами.
Впервые термин «White Label» появился в США. Звукозаписывающие студии выпускали виниловые пластинки с белым чистым лейблом, на который продавец мог нанести собственный логотип.
Со временем WL перешел в сегмент финансовых и IT услуг. Например, в США и Австралии крупные банки делают кредитные карты для небольших банков, чтобы они могли снизить расходы на производство.
Как работает White Label
Партнерская программа объединяет производителя и продавца. Наиболее популярный формат взаимодействия — продавец и производитель. Производитель передает продукт продавцу. А продавец предоставляет финансовые и маркетинговые ресурсы для продвижения и продажи товаров/услуг. Так на рынке появляется два одинаковых товара.
Такое сотрудничество полезно для обеих сторон сделки. Продавец наращивает клиентскую аудиторию и получает дополнительную прибыль. Производитель создает продукт с низкой себестоимостью, минимизирует издержки на маркетинг и рекламу, оплату услуг сопутствующих специалистов.
Кому подходит
Партнерская программа White Label — вариант пассивного дохода для форумов, информационных порталов, СМИ. Единственное условие — наличие аудитории, высокая посещаемость ресурса. Верхние позиции в поисковой выдаче занимают проекты с численностью аудитории более 5 млн. уникальных посетителей в сутки. Витрина, размещенная на таком сайте, привлечет, конечно же, больше внимания.
Помимо крупных порталов, WL характерен для таких обстоятельств:
Чтобы это сработало, нужно корректно расположить страницы на сайте. Если рекламная вывеска спрятана в футере, не выводится ссылками на главную страницу, клиенты не увидят предложение и не смогут им воспользоваться. Витрину лучше сделать отдельным разделом информационного портала. Это позволит посетителям увидеть предложение.
Текст витрины должен соответствовать содержанию сайта. Если содержание сайта и рекламное объявление не будут соответствовать друг другу, аудитория воспримет информацию как навязчивую рекламу. Доверие к интернет-проекту снизится. И рейтинг в выдаче будет понижен, т.к. поисковые системы анализируют содержание порталов. В отдельных ситуациях проект могут убрать из поисковой выдачи.
Кто этим занимается и сколько это стоит
Популяризацией решений White Label занимаются преимущественно компании с успешным опытом.
Воспользовавшись решением White Label, владелец информационного ресурса отдает в аренду часть разделов за долю дохода вебмастера. Подрядчик самостоятельно заполняет страницу контентом, формирует рекламные предложения и поддерживает работоспособность сайта. Второй участник сделки получает готовое решение, за которое придется платить процент с суммы заработка. 5% — владельцу площадки, где размещена витрина, и 5% — разработчику партнерской программы.
Плюсы и минусы
White Label зарекомендовала себя как успешная партнерская программа. Она активно используется в различных сферах бизнеса, приносит хороший результат за короткий промежуток времени. Чтобы не столкнуться с проблемами после запуска партнерской программы, следует заблаговременно анализировать сильные и слабые стороны.
Преимущества для продавца:
Преимущества для производителя:
Формат сотрудничества WL имеет и недостатки. Производитель сталкивается с такими сложностями как:
Минусы сотрудничества WL для продавца:
Перспективы White Label
WL получил широкое распространение в странах Западной Европы и США. Там работает множество порталов, занимающихся продвижением партнерских товаров. Один из примеров — разработчик ПО ShieldApps, реализующий свои разработки по партнерским программам. Компания предоставляет партнерам право распространять софт из портфеля ShieldApps под другими брендами.
На территории бывшего СССР партнерская программа WL появилась недавно. Она сосредоточена в сегменте интернет-шопинга. Это агрегаторы, осуществляющие поиски скидок и промокодов, информацию о стоимости товара в разных магазинах.
Специалисты в сфере маркетинга утверждают, что скоро около 70% рынка интернет-рекламы перейдет на формат WL. Это позволит снизить себестоимость продукта и предоставить клиентам товар по выгодной цене.
Сфера развития White Label — стартапы и мелкий бизнес. Они не борются с крупными игроками на рынке. Партнерская программа дает шанс выйти на широкую аудиторию, быстро реализовать проекты, разработать и внедрить новые технологии. Затраты на продвижение минимальные, что позволит новому бизнес-проекту стать популярным.
Заключение
Как показывает опыт российских и иностранных компаний, White Label гарантирует одинаковые возможности для крупных и начинающих бизнес-проектов. Чтобы внедрить новые возможности, нужно сопоставить тонкости партнерской программы с конкретной бизнес-деятельностью. При правильном подходе можно добиться многократного увеличения продаж и стремительного роста аудитории.