Wallet sdk что это за программа
Зачем и как мы создали мобильный SDK для приёма платежей в приложениях и что в этом хорошего
Менеджер по продуктам «Яндекс.Кассы» Максим Иванов — о том, как обстоят дела с оплатой в мобильных приложениях в России и что его команда сделала для того, чтобы предприниматели могли увеличить конверсию и зарабатывать больше.
Для начала давайте поговорим в цифрах про популярность платежей в мобильных приложениях. По данным Criteo (Европа, 2017 год), в приложениях конверсия продаж в три раза выше, чем в вебе. Проще говоря, в приложениях теряется намного меньше покупателей. Объём покупок в них превышает объём покупок в мобильном вебе — 56% против 44%.
Более того, доля покупок через смартфоны и планшеты — в том числе с мобильных приложений — постоянно растёт. Мы хорошо видим это по метрикам «Яндекс.Кассы». Недавно мы выпустили библиотеку для приёма платежей непосредственно в мобильных приложениях — рассказываем, как к этому пришли и что получилось в итоге.
До недавнего времени с помощью «Яндекс.Кассы» принимать платежи в мобильных приложениях можно было несколькими способами. Самый популярный — через webview, когда пользователь переходит из интерфейса приложения в веб-интерфейс платёжной страницы. Это самый простой в плане интеграции, но не самый эффективный метод.
Тот факт, что покупателям приходится покидать контекст нативного интерфейса приложения, приводит к снижению конверсии. Если человек хочет заплатить из электронного кошелька, тут тоже есть свой нюанс.
Обычно приложения не имеют доступа в мобильных браузерах к авторизации в «Яндексе», поэтому для оплаты из кошелька пользователю придётся авторизоваться в «Яндексе» через веб-интерфейс в приложении. Это ещё сильнее снижает конверсию в платежи.
Ещё один способ приёма оплаты в мобильных приложениях через «Яндекс.Кассу» — с помощью «Сбербанка Онлайн». В этом случае человеку нужно переходить через deep link из приложения магазина в приложение банка. Преимущество этого метода в том, что платёж происходит для покупателя в привычном и безопасном интерфейсе приложения «Сбербанка».
К недостатку можно отнести то, что пользователь покидает приложение магазина и после оплаты может в него уже не вернуться. Магазинам подключить этот способ оплаты не составляет большого труда, но опять же он не идеален с точки зрения пользовательского процесса.
Наконец, компании могут интегрироваться с API «Яндекс.Кассы» и принимать оплату с банковских карт через нативную платёжную форму в своём приложении. Однако для подключения этой возможности партнёру «Кассы» нужно обязательно иметь сертификат PCI DSS. Он есть далеко не у всех крупных компаний, а средним и небольшим получить его зачастую вовсе не по силам.
Таким образом, до сих пор в «Яндекс.Кассе» не было идеального универсального инструмента для приёма платежей в мобильных приложениях. И мы его создали.
Все перечисленные выше сценарии приёма платежей имеют как достоинства, так и недостатки. Мы проанализировали все их сильные и слабые стороны — и создали мобильный SDK «Яндекс.Кассы» для Android и iOS. С помощью нашей новой библиотеки можно принимать платежи из электронных кошельков и с банковских карт.
Мобильный SDK является частью новой технологической платформы «Кассы», то есть работает в связке с её API. На практике это означает, что магазины, которые уже интегрированы с этим API, смогут легко и без особых затрат интегрироваться и с нашим мобильным SDK. Теперь давайте разберём преимущества нашей новой библиотеки.
При использовании SDK оплата происходит полностью в нативном интерфейсе приложения магазина — без каких-либо переходов в веб. То есть процесс платежа становится для покупателя максимально простым и понятным, что положительно сказывается на конверсии.
Кроме того, SDK работает таким образом, что магазину не придётся пропускать данные банковских карт пользователей через свою бэкенд-систему. Это значит, что для приёма платежей с карт компаниям не нужно проходить сертификацию PCI DSS. По сути, мы создали нативный интерфейс, который помогает принимать оплату в мобильных приложениях и который могут подключить любые магазины — от самых крупных до небольших.
Ещё один плюс в пользу мобильного SDK — это заметное упрощение сценария оплаты из электронных кошельков в «Яндекс.Деньгах». Теперь авторизация в «Яндексе» нужна только при первом платеже в приложении. При этом покупателю вовсе не обязательно вручную вводить логин и пароль от аккаунта на «Яндексе».
SDK может получить авторизационные данные из других приложений «Яндекса», установленных на мобильном устройстве пользователя, или из мобильного браузера. И таких устройств в России большинство — на 80% смартфонов и планшетов в России уже пройдена авторизация в «Яндексе». Все последующие платежи «Яндекс.Деньгами» в мобильном приложении можно будет подтверждать одним касанием — так же просто, как через Apple Pay.
Авторизовавшись в «Яндексе», покупатели смогут платить в приложении и с банковских карт, привязанных к электронным кошелькам. По сути, это ещё одно упрощение платёжного сценария, благодаря которому пользователям больше не придётся вводить данные их банковских карт.
Это поможет ещё больше увеличить конверсию платежей. В результате с подключением мобильного SDK «Яндекс.Кассы» компании получат не только простой и эффективный платёжный сценарий в своих приложениях, но и постоянно растущую базу карт, привязанных к кошелькам в «Яндекс.Деньгах».
Поскольку SDK — это программная библиотека, посмотреть на неё в действии без участия разработчика не получится. Это затрудняет продвижение нашего нового решения среди клиентов «Яндекс.Кассы».
В самом деле, как предпринимателю или продакту принять решение об интеграции своего мобильного приложения с «Кассой», если он не может посмотреть, как всё это работает? Для всех сомневающихся мы создали демонстрационное приложение для iOS и Android. Оно наглядно воспроизводит разные сценарии оплаты, встроенные в наш SDK.
Мы наблюдаем тренд увеличения платежей из нативных интерфейсов сайтов и приложений. Это означает, что потребность в сервисах, подобных мобильному SDK «Яндекс.Кассы», будет только расти. Так что мы не собираемся останавливаться на достигнутом. В дальнейшем мы намерены совершенствовать уже существующие в SDK платёжные сценарии, добавить в него возможности кастомизации интерфейса и, конечно, новые способы оплаты.
Что такое Wallet и как им пользоваться в России
Человек постепенно отказывается от большого количества носимых предметов в пользу одного гаджета. Мы уже избавились от пользовательских камер, MP3-плееров и портативных консолей в пользу смартфонов, но функционал телефонов нового поколения на этом не ограничивается.
В мае 2017 в Россию пришел сервис бесконтактных платежей Android Pay, ранее на территории нашей страны запустились главные конкуренты — Apple Pay и Samsung Pay. «Бесполезное» в 2014-2015 годах приложение Wallet уже сейчас может стать полноценной заменой привычному кошельку.
С помощью Wallet можно проходить регистрацию в аэропорту, первым узнавать о новинках любимой кофейни, получать подарки за покупки, расплачиваться накопленными бонусами и, конечно, использовать свою банковскую карту, как способ оплаты. И это не только столичный каприз: стандартные терминалы “Сбербанка” для безналичной оплаты также поддерживают оплату через смартфон, а регистрация на самолет через Wallet работает в екатеринбургском “Кольцово”, новгородском “Стригино” и всех других аэропортах страны.
CARD PR начинает серию публикаций, которая расскажет о том, зачем нужно осваивать мир цифрового кошелька уже сегодня и какие преимущества у этой системы. Разбор будет происходить на примере приложения для iOS — Android версия обладает аналогичным функционалом.
Легкий старт
Программа Wallet является встроенным приложением во всех iPhone и iPad, поэтому не требует установки. Cмартфон не перегружается отдельными приложениями, которые разрабатывают компании, и задействует “родной функционал” системы. Одной карточки достаточно, чтобы клиент мог установить ее в свой Wallet на гаджете любой компании.
Пользователи мобильных устройств оценили удобство подобного общения: по статистике не более 5% представителей целевой аудитории компании устанавливают приложения в свои смартфоны, в то время как до 70% клиентов, ставят электронную карту вместо пластиковой.
Карты разных компаний хранятся в вертикальном ряду, отображая текущий баланс или любую другую информацию. Карточка в Wallet состоит из двух сторон: лицевая, где можно увидеть баланс, название, время следующей тренировки, дату концерта и другие базовые показатели, а также информационная, где начинается диалог пользователя с компанией. Здесь находятся уведомления о новинках компании, подарочные купоны и уникальные предложения. Банки могут показывать сводку: куда ушли последние затраты, кофейни могут рассказывать о новых вкусах, электронные билеты – подсказать путь к своему месту. ХК “Динамо” активно использует такие проходки на своих матчах, упрощая жизнь фанатов.
Если одна компания выпускает не одну карту, а серию, то все они будут сгруппированы в один горизонтальный ряд. Например, карта лояльности Starbucks, купон на бесплатный кофе, подарочный сертификат и другие приятные бонусы будут храниться рядом.
Добавить карту просто: заведения, которые поддерживают карты Wallet, размещают в интерьере QR-код, по которому карта сама появится в электронном кошельке. Также картой можно поделиться с другом, отправив ссылку. При оплате с помощью Apple Pay смартфон покажет, что у заведения есть своя карта Wallet и предложит добавить ее в свой набор.
Некоторые карты могут автоматически открываться в нужное время или в нужном месте, так как они содержат сведения о времени или местонахождении. Например, когда вы приезжаете в аэропорт, на экране должен отобразиться посадочный талон.
Это удобно
Первое преимущество Wallet перед простыми скидочными картами – это безопасно. Электронную карту лояльности невозможно потерять, ведь она привязана к аккаунту. В случае кражи/утери смартфона, ей все равно не смогут воспользоваться – в отличии от потерянного кошелька, современный гаджет можно заблокировать удаленно и в два клика. Также многие пользователи предпочитают пароль на экране блокировки, поэтому у злоумышленника не останется шансов.
Помогает, а не надоедает. В отличии от приложений, которые мозолят глаза на рабочем столе или карты, которая отнимает место в кошельке, электронные карты не мешают повседневной жизни. Они помогают пользователям экономить, напоминая о себе в нужном месте и говорят о необходимых скидках коротким языком уведомлений, а не длинными письмами, которые летят в папку со спамом. Сообщения воспринимаются как приятная форма общения, а не назойливая реклама.
Экономит не только деньги клиента, но и компании. Электронные карты дешевле в изготовлении, рассылке уведомлений и используется чаще, чем пластиковый аналог. При желании, можно без лишних затрат изменить внешний вид каждой выданной карты, если компания совершить внезапный ребрендинг.
Карту невозможно забыть дома, что помогает пользователям экономить каждый раз.
Это больше, чем просто программа лояльности. При желании можно продумать целую игру: пользователь постит в Instagram фотографию с нужным тегом, карта считывает это и выдает подарок от заведения. Мировые и российские бренды уже попробовали различные варианты интеграции соцсетей в карты, о которых мы расскажем в следующих публикациях.
Где взять
Если в Apple-гаджетах Wallet – родное приложение, то для Android-смартфонов рекомендуется использовать WalletPasses.
Каждый, кто хочет создать свою карту Wallet, может написать Telegram-боту по ссылке.
SDK тебе, SDK мне, SDK всем! Как делать SDK и зачем это нужно
Наша компания делает сервис для хранения и обработки данных с промышленных устройств (насосы, буры и прочая промышленная техника). Мы храним данные наших клиентов и предоставляем функционал для их анализа: построение отчетов, графиков и еще много чего.
И в ходе работы мы заметили, что интеграция каждого нового клиента сильно затягивается, а количество различных ошибок постоянно возрастает. Тогда стало понятно, что пора с этим разобраться. Как показал анализ ситуации, IT отдел каждого нашего клиента разрабатывал свое решение для локального сбора данных с устройств и отправки к нам в сервис. Все усложняет то, что с учетом специфики отрасли, не всегда есть доступ к интернету и необходимо хранить данные локально и отправлять при первой возможности. И таких нюансов достаточно большое количество, что и приводит к росту количества ошибок.
И тогда мы поняли, что лучшим решением в данной ситуации будет разработать SDK и предоставлять его клиенту. Сразу же начал искать лучшие практики и рассуждения на тему разработки SDK и сильно удивился — в рунете об этом практически ничего нет, а в басурманских интернетах очень мало информации и она разрознена. Ну что ж, задача понятна, обдумана и реализована.
Пора определяться
Начнем с того, что определим, что такое SDK и зачем он может быть нужен.
SDK (от англ. software development kit) — комплект средств разработки, который позволяет специалистам по программному обеспечению создавать приложения для определённого пакета программ, программного обеспечения базовых средств разработки, аппаратной платформы, компьютерной системы, игровых консолей, операционных систем и прочих платформ. SDK использует преимущества каждой платформы и сокращает время на интеграцию.
…
Инженер-программист обычно получает SDK от разработчика целевой системы.
Что ж, логично. Простыми словами, SDK — это пакет библиотек, для того, чтобы клиент мог легко и быстро начать работать с вашей системой (в данной статье речь пойдет про наш сервис, но всё изложенное в статье применимо и к другим видам SDK) или выполнять однотипные действия.
Но, как и у любого подхода, у «Пути SDK» есть как преимущества, так и недостатки.
Преимущества
Высокая скорость интеграции нового клиента — вашим клиентам нужно писать меньше кода.
Переиспользование кода — один и тот же код используется сразу в нескольких местах. Можно сказать, что это дублирование предыдущего пункта, но речь идет о том, что логика работы везде одинокава, из чего следует
Предсказуемость поведения — использование одних и тех же библиотек приводит поведение систем к определенному стандарту, что сильно облегчает поиск и устранение ошибок и уязвимостей.
Качество кода — много где любят экономить на тестировании (жалко бюджета, горят сроки и прочие причины). Понятно, что в реальном мире покрыть тестами все участки проекта это учень трудоемкая задача. Но качественно протестировать все модули SDK, а затем использовать их — это путь повышения процента покрытия тестами, что приведет вас к снижению количества ошибок.
Документация — тот же сценарий, что и с тестами. Покрыть документацией весь проект достаточно проблематично. Переиспользование модулей SDK повышает процент покрытия документацией, что снижает порог вхождения новых сотрудников в проект и вообще помогает по жизни.
Все преимущества, по сути, это следствия самого главного — мы очень качественно пишем код один раз, а затем его переиспользуем.
Недостатки
Высокие требования к качеству кода SDK — следствие главного преимущества. Ошибка в SDK породит ошибки во всех системах, его использующих.
Установка ограничений — SDK — это набор библиотек для реализации стандартных сценариев. Иногда разработчики SDK полагают, что кроме реализации одного из предусмотренных сценариев клиенту ничего не потребуется, что клиенту проще сделать все с нуля самостоятельно, чем строить пьедестал из костылей для SDK.
Dependency hell и обновления — при расширении функционала (например, кастомизации решения под конкретного клиента), вы выпустите новую версию библиотеки. Но существуют зависимости, различные наборы версий библиотек у разных клиентов, и нужно очень тщательно следить за обратной совместимостью или строгим версионированием.
Когда SDK действительно нужен
У вас есть несколько стандартных сценариев, которые реализуются заново из раза в раз — собственно, наш случай.
Внутренние разработки — в разных проектах вы используете системы логирования, конфигурирования систем, работу с HttpRequest, БД, файлами? Выработайте внутренний SDK — набор библиотек для внутреннего использования. Вы в любой момент можете расширить функционал SDK, но скорость разработки новых проектов, процент покрытия тестами и документацией вырастет, а порог вхождения новых разработчиков снизится.
Когда SDK скорее всего будет лишним
Сценарии использования не определены или постоянно меняются — оставьте реализацию кастомных решений клиентам и помогите им. Не надо городить вундервафлю, которая будет только мешать. Очень актуально для молодых компаний и стартапов.
Вы не умеете делать качественно — у меня для вас плохая новость: пора учиться. Но отдавать кривое решение клиенту это очень, очень неправильно. Клиентов надо уважать, в конце концов.
Итак, мы определились, что такое SDK, с его преимуществами и недостатками и когда он нам нужен. Если после этого вы поняли, что SDK действительно нужен — приглашаю вас встать на «путь SDK» и разобраться, а каким он должен быть и как его, черт подери, делать?
«А вы любите Lego?» — Модульность
Представим все возможные сценарии использования SDK (вы же уже определились, зачем он вам нужен, правда?) и сделаем по библиотеке на сценарий. Чем не выход? Но это плохой подход, и так мы делать не будем. А будем так:
Например, с учетом специфики задачи, нам необходимо, чтобы вся логика задавалась из конфигов. Реализуем модуль работы с конфигами (чтения, записи, обновления, валидации и обработки конфигураций) и будем использовать его во всех остальных модулях.
А для реализации стандартных сценариев мы действительно сделаем модули — этакие «управляющие» модули, каждый из которых реализуют один конкретный сценарий, используя другие модули того же SDK. Таким образом для реализации стандартных сценариев клиент должен лишь подключить управляющий модуль сценария (а он сам подтянет все зависимости), а для реализации нестандартных — используем базовые модули, так же переиспользуя код.
Именно этим обусловлено то, что SDK не должен быть одной библиотекой (хотя очень хочется, понимаю. Ведь когда весь SDK в одной библиотеке, можно забыть о зависимостях и всем, что с ними связано), а быть комплектом библиотек. Дополнительным плюсом данного подхода будет уменьшение «веса» программы клиента — он будет тянуть тяжеловесный SDK, а подтянет только необходимые модули.
Но не стоить плодить модули как попало, ведь чем больше модулей, тем больше головной боли от их зависимостей! Т.е. важно правильно разбить логику на модули, соблюдая баланс между решением «все в одном» и «на каждую функцию свой модуль».
«А что, так можно было?!» — Универсальность
Предоставьте клиенту различные интерфейсы для работы с вашей библиотекой. Приведу пример:
Если предоставить только синхронную версию, то при реализации асинхронного приложения клиент вынужден будет делать асинхронные обертки вашего синхронного метода. Если предоставить только асинхронную версию — ситуация похожа. Дайте клиенту и то и другое и он скажет вам спасибо.
Приятным плюсом будут дженерики. Например, у нас есть класс для работы с конфигурациями, реализующий методы упаковки конфига в строку, загрузки конфига из файла и т.д. Конфигурация конкретного модуля будет наследоваться от нашего базового класса, но для работы с новым классом нам необходимо также предоставить методы распаковки.
Таким образом мы предоставили клиенту аж три реализации, которые он может использовать. Дженерики очень удобны, но при работе с динамическими типами их можно вызывать только через рефлексию, что накладно. Общий принцип универсальности, надеюсь, понятен.
«Родитель 1, Родитель 2, Дети[ ]» — Именование
Что самое трудное в работе программиста? Выдумывать имена для переменных.
И тем не менее… Правильное именование модулей, классов, свойств и методов сильно помогут тем, кто будут с вашим SDK работать. Пример, не требующих комментариев:
Kinect 2.0 SDK example
Всё ясно из названий классов и методов. А если есть автодополнение кода в вашей IDE, то зачастую можно и в документацию не заглядывать, если и так все понятно.
Но даже если у вас очень красиво и актуально названы все модули, классы, методы и свойства, документацию все равно необходимо написать. Во-первых, это очень сильно сбережет вам нервы (количество вопросов клиентов уменьшается на порядок. Все есть в документации), а во-вторых, всегда понятно, почему вы сделали так, а не иначе.
Документация, в SDK, как правило, проста и лаконична. Она обычно делится на две части: Tutorial — пошаговый курс в стиле “Построим город за 10 минут” и раздел Reference — справочник по всему, что можно сделать с помощью данного SDK.
Мы выбрали самый простой путь — summary + articles. Мы добавляем Xml атрибуты для методов и классов, которые светятся в intellisense как подсказки. Используя Docfx мы строим документацию по этим атрибутам и получаем подробную и удобную документацию, которую дополняет статьями, описывающими сценарии использования и примеры.
«— Чтобы чисто было! — Как я буду вилкой-то чистить?» — Тестирование
Что можно сказать про тестирование в рамках обсуждения SDK… Must have! Лучшим решением будет TDD (несмотря на то, что я негативно отношусь к данному подходу, в данном случае я решил использовать именно его). Да, долго. Да, нудно. Но зато в будущем вы не повеситесь от постоянных падений SDK на стороне и следствий этого падения.
Основной сок ситуации заключается в том, что отдавая SDK клиенту вы теряете контроль: вы не можете быстро пофиксить ошибку, сложно эту самую ошибку найти, да и выглядеть в такой ситуации вы будете достаточно глупо. Поэтому — тестируйте. Тестируйте лучше. И еще раз. И, на всякий случай, протестируйте ваши тесты. И тесты тестов. Так, что-то я увлекся, но важность тестирования SDK, надеюсь, понятна.
«Жертва, которая не могла противостоять своему прошлому, была поглощена им» — Логи
Поскольку вы отдаете SDK сторонней компании, в следствие чего теряете контроль над ситуацией, в случае ошибки (на этапе тестирования вы все-так решили «и так сойдёт», да?) вас ждет достаточно долгий и болезненный процесс поиск этой самой ошибки. Именно тут вам на помощь придут логи.
Логируйте все, абсолютно все, а в случае возникновения ошибки запросите у вашего клиента логи. Таким образом вы сэкономите много времени и сможете не потярять лицо перед клиентом.
«Alarm! Achtung! Attention!» — Ошибки
Долго размышляя на тему ошибок я пришел к интересному выводу — ни один метод в вашем SDK не должен отдавать ошибку, не описанную в документации. Согласитесь, очень неприятно, когда вы подключаете стороннюю библиотеку для работы с HttpRequest, а она вываливает на вас какой-нибудь NullPointerException и StackTrace, который уводит в недра библиотеки. И вам приходиться погружаться в эти самые «недра», пытаясь понять, насколько глубока кроличья нора, и в чем, собственно, проблема.
Поэтому я предлагаю следующее решение — декларируйте закрытый список возможных исключений и документируйте их. Но, т.к. нельзя быть увереннным, что вы предусмотрели все, оберните метод в try-catch, а пойманную ошибку — в задекларируему. Например, ConfigurationException, который будет содержать InnerException — пойманную ошибку. Это позволит стороннему разработчику поймать все возможные ошибки, но в случае чего быстро разобраться в чем дело.
Версии или «как не укусить себя за хвост»
Во избежание проблем в будущем крайне рекомендую использовать строгое версионирование. Выберете подходящую вам систему построения версий и используйте ее. Но если новая версия библиотеки не имеет обратной совместимости — это необходимо указать. Как это разруливать — думать вам. Но подумать об этом точно стоит.
«Паровозик, который смог» — Deploy
Необходимость актуальности документации и версий порождают требование к корректности деплоя. В своем решении мы используем следующее решение (костыли, но работают).
Когда надо выпустить нвый релиз, разработчик дергает bat’ник с указанием номера релиза, а затем батник:
На выходе получаем обновленную версию сайта с документацией, откуда можно скачать архив с последней версией SDK.
В планах на будущее — упаковка всего в Nuget пакеты и публикация в локальный Nuget репозиторий.
Рекоммендую обратить внимание на этот пункт, ведь вы можете существенно снизить количество головной боли, вызванной отсутствием актуальной информации о новой версии библиотеки.
«-А так можешь? — Фигня. Смотри как надо!» — Примеры & toolkit
Заключение
Разработка SDK стало для меня интересной новой задачей, поднявшей много важных архитектурных вопросов. Многое описанное в статье является очевидными вещами (для меня), но считаю важным огласить даже очевидные вещи, чтобы получить четкую общую картину.
Спасибо за прочтение, буду рад вашим комментариям. Надеюсь, эта статья будет для вас полезной.