Wallet sdk что это за программа

Возможности Wallet в Xamarin.iOS

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

Разработчики могут работать с Wallet различными способами:

• Для создания карты необязательно создавать приложение. Файл Passfile является zip-архивом, содержащим несколько файлов JSON и необязательно файлы метаданных. Для его подготовки необходимы ИД типа карты и Сертификат карты. Эта информация затем объявляется в файле JSON. Дополнительные сведения о подготовке файла Passfile см. в руководстве Введение в PassKit.
• Для распространения карт разрабатываются дополнительные приложения. Они также обладают возможностью создавать, изменять и обновлять карты и затем добавлять их в приложение Wallet. Типичным примером такого приложения является приложение кинотеатра — после покупки билета через приложение этот билет можно напрямую добавить в приложение Wallet. Для использования дополнительного приложения подготовленный вами файл должен содержать ИД приложения с поддержкой функций Wallet, настройка которого описана ниже. Это приложение должно также включать необходимые назначения.
• Приложения-проводники — приложения, которые напрямую не управляют картами. Они минимально взаимодействуют с картами, за исключением получения и предоставления пользователю возможности добавления карт в Wallet. Такие приложения не требуют никакой дополнительной подготовки или назначений, но они используют некоторые методы из среды PassKit.

Центр разработчика

Чтобы создать новый профиль подготовки для использования с Wallet, выполните следующее:

1. Перейдите к разделу Сертификаты, идентификаторы и профили на портале разработчика Apple.
2. В Идентификаторах перейдите к ИД приложений:
3. Нажмите значок + в правом верхнем углу страницы.
4. Зарегистрируйте новый ИД приложения, введя его Имя и идентификатор пакета. (Примечание. Этот идентификатор пакета должен совпадать с ИД пакета в вашем проекте):
5. Выберите службу приложения Wallet из списка служб:
6. Нажмите кнопку Продолжить, затем Регистрация для создания ИД приложения.

При необходимости можно изменить существующий ИД приложения для добавления возможностей Wallet.

Этот ИД приложения можно использовать для создания или повторного создания профиля подготовки, как это описано в руководстве Работа с возможностями:

Дополнительные сведения об использовании приложения Wallet см. в следующем руководстве:

Следующие шаги

Ниже перечислены дополнительные действия, которые необходимо выполнить:

• Используйте в приложении пространство имен платформы.
• Добавьте необходимые назначения к вашему приложению. Подробные сведения о необходимых назначениях и об их добавлении см. в руководстве Работа с назначениями.
• Убедитесь, что в Подписывании пакета iOS приложения параметр Настраиваемые назначения установлен в Entitlements.plist. Эта настройка не устанавливается по умолчанию для сборок отладки и симулятора iOS.

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

Apple Wallet. Что это такое и как интегрировать в него свою карту

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

Что такое Wallet? Он позволяет держать в телефоне различного вида карты (билеты, скидочные карты и т.п.), облегчая жизнь пользователям продукта. Более того, есть возможность актуализировать информацию о карте посредством push-уведомлений, но это тема для отдельной статьи. Но если у вас есть карта/билет/абонемент, которые можно интегрировать в телефон, то для этого есть решение! Как это сделать – читайте ниже.

Как правило, за создание карты отвечает ваш сервер. Приложение получает карту в виде .pkpass файла и уже через приложение пользователь может добавить карту в Wallet.

Структура карты

Что же представляет собой карта с точки зрения разработчика? Карта – это архив с расширением .pkpass. Он содержит в себе все данные, необходиимые для отображения и работы карты. Содержимое архива – в таблице ниже.

Файл	Назначение
background.png	Фоновая картинка для карты.
footer.png	Картинка рядом со штрихкодом
icon.png	Иконка для уведомлений и писем
logo.png	Логотип карточки. Отображается слева сверху
manifest.json	Реестр всех включанымх файлов
signature	PKCS7 подпись
pass.json	Внешний вид и информация на карте
strip.png	Картинка, находящаяся сзади основного описания карточки
thumbnail.png	Дополнительная картинка (уточнить)

Существуют следующие типы карт:

• Посадочный билет: на самолет или поезд. Обычно купон работает на одну поездку;
• Купон: для купонов и специальных предложений;
• Билет на событие: может работать как для одного события, так и для целого сезона;
• Скидочная карта: карты лояльности, скидочные или подарочные карты;
• Карта общего вида: если ничего из вышеперечисленного не подходит под ваш случай: например, карта для поездок на метро или пропуск в спортзал.

Рассмотрим схематично внешний вид разных карт. Картинки лучше называть так, как это указано в таблице выше.

Посадочный билет

Купон

Билет на событие

Общая карта

Скидочная карта

Структура pass.json

Обязательные поля. Содержат Pass Type ID, Team ID, название организации и т.п.
Ключи для связанных приложений. Нужны для отображения приложений, которые нужно «ассоциировать» с картой.
Ключи «срока годности» карточки.
Ключи актуальности. Например, координаты местности, где карта может быть использована, или начало события, для которого она предназначена.
Ключ стиля. В начале статьи были перечислены 5 видов карт для Wallet. Каждому из них соответствует свой стиль. Такой ключ должен быть строго один.
Ключи визуального оформления карты. Помимо очевидного, содержат в себе информацию о штрихкоде, отображаемом на карте.
Ключи web-сервисов. Вы можете использовать web-сервисы для взаимодействия с картой, например, автоматически ее обновлять.
NFC-ключи. Содержат дополнительную информацию для Apple Pay транзакции.

Теперь обо всем подробнее.

Обязательные поля

description	String. Локализуемое	Краткое описание карты. Локализуемое.
formatVersion	Int	Версия формата файла. Значение должно быть 1.
String. Локализуемое	Название организации, которая выдает карты.
String	Pass Type ID и кабинете разработчика.
String	Серийный номер отдельной карты
String	Team ID команды разработчика

Ключи для связанных приложений

[Int]	Опционально. ID приложений, ассоциированных с картой. Берется всегда первое, совместимое с текущим устройством.
String	URL, который передается в приложение при открытии

Ключи стиля

[JSON]	Основная информация о карте.
[JSON]	Второстепенная информация.
[JSON]	Поля для дополнительной информации. Опциональное
[JSON]	Заголовок карты. Отображается даже в том случае, когда карты видны списком.
[JSON]	Основная информация о карте.
String	Тип транспорта для карт-билетов. Может принимать следующие значения: PKTransitTypeAir, PKTransitTypeBoat, PKTransitTypeBu`, PKTransitTypeGeneric, `PKTransitTypeTrain`.
[JSON]	Массив полей, отвечающий за обратную сторону карты

JSON в данном случае имеет следующий вид:

 "key" : "value1", "label" : "value2", "value" : "value3"

Значение по ключу value может быть как числовым, так и строковым. Однако currencyCode вместе со строковым значением использовать не получится. Что касается auxiliaryFields и secondaryFields, их может быть несколько, и стоит следить за длиной строк, которые в них используются.

Ключи визуального оформления

[JSON]	Информация для баркода (см. ниже).
color as string	Цвет фона.(#fa32e4)
color as string	Цвет лейблов со значениями
String	Опционально для билетов на события и билетов на транспорт. Карты с одинаковым стилем ― passTypeIdentifier и groupingIdentifier ― будут группироваться
color as string	Текст лейблов с названиями полей
Localizable string	Текст, отображаемый рядом с логотипом

Баркод

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

String	Опциональный текст, отображаемый рядом с баркодом в том случае, если баркод не считывается.
String	Формат баркода. Может принимать значения: PKBarcodeFormatQR, PKBarcodeFormatPDF417, PKBarcodeFormatAztec, PKBarcodeFormatCode128
String	Код или номер карты, зашифрованный в баркод.
String	Кодировка сообщения. Обычно iso-8859-1

Локация

Эти ключи отвечают за локацию, в пределах которой карта может быть использована.

String	Опциональный текст, отображаемый рядом с баркодом в том случае, если баркод не считывается.
Долгота	Широта
Double	Широта
String	Опциональный текст, который отображается на экране блокировки в тот момент, когда пользователь входит в радиус действия карты.

Оборотная сторона

На оборотной информационной части можно разместить дополнительную информацию: условия использования, политику автообновления, контактные данные и ссылку на приложение, к которому относится карта. На рисунке представлено соответствие полей в pass.json и внешнего вида обратной стороны карты. Если в value-поле есть ссылки, номера телефона и т.п., они подсветятся автоматически.

Создание карты. Часть 2

Итак, картинки готовы, pass.json сформирован, осталось собрать все это вместе. Для этого заполним manifest.json (см. таблицу 1), куда необходимо включить все картинки и pass.json. Получается примерно так:

. . . . . . "pass.json" = 303c753abc39aa732ec74643d6db28348fe8a823; "strip.png" = 736d01f84cb73d06e8a9932e43076d68f19461ff; "strip@2x.png" = 468fa7bc93e6b55342b56fda09bdce7c829d7d46; . . . . . .

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

Далее нужно создать Pass Type ID в кабинете разработчика и сделать для него сертификат. Процедура должна быть более-менее знакомая, если ранее вы создавали, например, Provisioning профили.

Далее заходим в ключницу (Keychain) и экспортируем оттуда Apple Worldwide Developer Relation Certificate (WWDR) как .pem.

Оттуда же экспортируем созданный Pass Type ID как .p12. На этом этапе ключница попросит вас ввести пароль для сертификата. При этом пароль вводить необязательно.
Обратите внимание, что все дальнейшие действия надо производить в одной папке, где уже должны лежать manifest.json, pass.json и картинки.

Теперь необходимо сгенерировать подпись, которой будем подписывать архив. Для начала экспортируем Pass Type ID и ключ к нему как .pem.

openssl pkcs12 -in certificate.p12 -clcerts -nokeys -out passcertificate.pem -passin pass: your_password

openssl pkcs12 -in certificates.p12 -nocerts -out passkey.pem -passin pass: -passout pass:new_password

Теперь мы готовы к генерации подписи. Сделаем это командой:

openssl smime -binary -sign -certfile WWDR.pem -signer passcertificate.pem -inkey passkey.pem -in manifest.json -out signature -outform DER -passin pass:пароль_из_предыдущей_команды

Итак, у нас все готово, осталось только собрать архив, делаем это командой:

zip -r nameOfPass.pkpass manifest.json pass.json signature logo.png logo@2x.png logo@3x.png icon.png icon@2x.png icon@3x.png

Обращаю внимание, что тут должны быть перечислены все файлы, в которые вы хотите включить архив данных для карты(.pkpass).
В итоге мы получим .pkpass файл, который можно открывать на компьютере. Мы увидим превью карты, внешний вид которой может отличаться от вида на телефоне.
Все это можно сделать чуть проще. Apple предоставляет утилиту signpass (Apple Wallet sample meterials), которая берет на себя все подсчеты SHA (файл manifest.json можно не делать самостоятельно) и работу по созданию подписей. Чтобы ей воспользоваться, нужно собрать проект и поместить файл signpass в папку со всеми необходимыми ресурсами.

В целом структура должна выглядеть примерно так:

Далее выполняем команду:

./signpass -p wallet

Wallet — это название папки, в которой лежат все ресурсы. На выходе получаем файл wallet.pkpass. Его содержимое можно посмотреть, разархивировав wallet.pkpass.

unzip wallet.pkpass

Не исключено, что создание pkpass будет вынесено на бэкенд, в таком случае надо будет передать разработчикам WWDR, сертификат для Pass Type ID в виде .p12 и пароль от него.

Интеграция с приложением

Для того чтобы приложение имело возможность добавлять карты в Wallet, необходимо включить эту возможность в App ID и также включить эту возможность в Capabilities в проекте.

Это необходимо для полноценной корректной работы с Wallet. В противном случае не получится считывать карты с Wallet и, например, не будет возможности понять, добавлена наша карта или нет. Также важно отметить, что team id в pass.json должен совпадать c team id, либо придется добавлять их вручную в entitlements и это может исправить ситуацию, но это я не проверял.

Добавление карты

Добавлять карты очень просто:

guard let passPath = Bundle.main.path(forResource: "wallet", ofType: "pkpass") else < return >let error: ErrorPointer = ErrorPointer(nilLiteral: ()) guard let passData = NSData(contentsOfFile: passPath) else < return >let pass = PKPass(data: passData as Data, error: error) let passLibrary = PKPassLibrary() passLibrary.addPasses([pass])

Однако, опять же, чаще .pkpass файл надо будет скачивать с вашего сервера.
Стоит отметить, что PassKit выдает довольно читаемые ошибки, поэтому можно легко понять, что именно было сделано не так.

Получение информации о добавленных картах

Чтобы получить информацию о картах, имеющихся в Wallet и относящихся к вашему приложению, необходимо обратиться к объекту PKPassLibrary.

let passLibrary = PKPassLibrary() let passes = passLibrary.passes()

Таким образом, можно понять, добавлена карта или нет, а также обновить интерфейс. Кроме того, через PKPassLibrary карты можно обновлять и удалять. Обновлять карты можно и через веб-сервисы, но в этой статье мы не будем рассматривать такой вариант.

Проверка на уникальность

Поскольку в вашем сервисе, как правило карта привязана к аккаунту, в приложении скорее всего придется как-то определять принадлежность карты к текущему пользователю. Предлагаю делать это через serialNumber . Например, задавать в качестве serialNumber id пользователя или номер карты.

Тестирование

Apple предоставляет примеры pkpass для разных типов, можно ориентироваться на них.
Apple Wallet samples
Чтобы увидеть то, как выглядит карта, можно, добавить pkpass в проект (см. «Добавление карты»). Процесс добавления/удаления уже рассмотрен выше, осталось только напомнить, что приложение не будет видеть уже добавленные карты, если карта для Wallet создавалась на одном аккаунте разработчика, а сама разработка велась с другого аккаунта (актуально для аутсорс-компаний). При этом добавлять карты можно без проблем.
Проверить, корректно ли закодирована информация в штрихкоде, можно с помощью любого сканера QR-кодов. И точно необходимо проверить корректность работы с настоящим сканером.

Заключение

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

Используемые материалы:

Отдельное спасибо mehdzor за аккаунт разработчика для тестов.

Почему Wallet «вытесняет» мобильные приложения?

Written by admin on 30.01.2019 . Posted in Без категории,Новости.

Сегодня многие бизнесы, работающие в сегменте B2C предлагают клиентам участие в программе лояльности с выдачей пластиковых карт. Но сегодняшнему потребителю зачастую очень сложно хранить все пластиковые карты в одном месте, и часть из них или «забывается» дома или теряется. Помимо этого, есть ещё одна немаловажная проблема, чтобы выжить на высококонкурентном рынке, компаниям нужно «идти в ногу со временем». И осваивать новые технологии, позволяющие бизнесу «проникать» в смартфоны своих клиентов. Как правило, решением данной проблемы могут быть два варианта. Создание собственного мобильного приложения с электронной картой лояльности или внедрение электронной карты в приложения мобильных кошельков Apple Wallet и Wallet Union для Android.

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

Сроки

Мобильное приложение

Первое, из чего складывается стоимость и время разработки — это сложность приложения. Второе — количество платформ (iPhone iOS, iPad iOS, Android phone, Android tablet, Windows Phone), на которых оно будет работать. Нередко смартфоны и планшеты считаются отдельно.

Приложение на Android создается на 20-30% дольше чем на iOS и стоимость приложения будет дороже. Это обусловлено тем, что тестировать приложение для Android необходимо на большем количестве девайсов, и в следствие чего находится больше багов. Тем самым приходится вносить больше правок.

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

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

Среднее приложение (300-1000 часов) – они могут включать создание API и панели администратора. В них могут быть, например, чаты, функции оплаты и т.д. На стоимость здесь влияет не только сложность компонента, но и их количество.

Сложное приложение (1000 – 3000 часов) – данное приложение синхронизируется в режиме реального времени, содержит большое количество интерактивов и анимаций, включает интеграцию с большим количеством сторонних сервисов, разработку бэкенда и функцию оплаты через приложение. Сверх этого — в нем большое количество контента и экранов.

Wallet

С каждым днем технология Wallet набирает свою популярность, это объясняется тем, что все больше компаний стремятся идти в ногу со временем, а значит — внедрять инновационные цифровые решения. Играют свою роль и международные тренды: многие крупные западные торговые сети уже подключены к сервису, а новые компании с самого старта отказываются от пластика в пользу электронных карт.

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

В среднем срок реализации проекта для бизнеса составляет около 7 дней.

Стоимость

Мобильное приложение

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

Чтобы обозначить примерную стоимость приложения, вернемся к нашим условным группам, основанным на количестве часов, необходимых на их разработку. Мы рассчитали примерную стоимость проекта для каждой группы. За стоимость часа мы взяли средний показатель по России согласно данным аналитического агентства Тэглайн. На момент публикации этой статьи средняя стоимость часа разработчика равна 1920 рублей.

Если вернуться к предыдущему критерию сравнения – сроки, то мы получим:

Простое приложение (100-300 часов) – 192 000 руб. – 576 000 руб.

Среднее приложение (300-1000 часов) – 576 000 руб. – 1 920 000 руб.

Сложное приложение (1000 – 3000 часов) – 1 920 000 руб. – 5 760 000 руб.

*Стоимость указана на создание приложения для оной платформы.

Релиз приложения в AppStore или Google Play — это только начало большого пути проекта. В дальнейшем ему скорее всего понадобится квалифицированная техническая поддержка, включающая в себя отслеживание и устранение проблем, оптимизацию функционала приложения, защиту от атак и т.д.

Wallet

Для бизнеса иметь свои электронные карты в приложениях Wallet (для iOS) и Wallet Union (для Android) гораздо удобнее и экономнее, чем создавать отдельное приложение.

В среднем внедрение электронных карт лояльности составляет 15 000 – 20 000 рублей в месяц.

В данную стоимость входит интеграция с большинством распространенных CRM и ERP систем, безлимитное количество электронных карт покупателей, безлимитное количество push-уведомлений, техническая поддержка личного аккаунт-менеджера на каждом этапе работы. А также возможность неограниченного обновления карт. На наш взгляд – это очень удобно!

Функционал

В чем же отличие технологии Wallet от других мобильных карточных приложений? В первую очередь они различаются реализацией. Если в Wallet у пользователя есть возможность получить мгновенный доступ к любой из своих карт лояльности, к любому билету или купону на скидку даже при отсутствии интернет-соединения, то функциональность карточных приложений не так проста в использовании. Как минимум необходимо себе в смартфон установить еще одно приложение из App Store или Google Play, хотя намного удобнее иметь под рукой встроенное, «родное» решение. Помимо этого, каждый раз, когда клиенту нужно предъявить карту лояльности в магазине или билет на стадионе, приложение будет запрашивать соединение с интернетом и будет обновляться от нескольких секунд до нескольких минут. Тем самым создавая очередь на кассе.

Давайте рассмотрим функционал сервиса электронных карт и мобильных приложений по основным критериям, таким как:

• Установка
• Аналитика
• Возможности коммуникации
• Вариативность

Установка

Надо быть готовым к тому, что немалая часть пользователей все-таки не захочет устанавливать приложение. От установки приложения отказываются по нескольким причинам: хлопотно (надо искать в онлайн-магазине, скачивать, предоставлять какие-то разрешения), долго, занимает место в памяти устройства и замедляет его работу. Все это привело к тому, что популярность мобильных приложений постепенно стала угасать: если еще пять лет назад только около 30% пользователей устанавливали приложение раз в месяц, то сегодня более 60% пользователей в мире устанавливает приложения реже, чем раз в месяц.

Технология Wallet поддерживается как на iOS, так и на Android устройствах. В случае с iOS приложение Wallet уже встроено во все устройства Apple, также как приложения «Почта», «Календарь», «Заметки» и другие. В случае с Android, пользователям нужно скачать бесплатное приложение WalletUnion в Google Play. Данные приложения позволяют хранить электронные карты, визитки, билеты, страховые полисы и многое другое в одном приложении, за счет чего они приобретают все большую популярность. Это доказывают данные из исследования компании Loup Ventures, которое показало, что 31% владельцев Iphone используют Apple Pay, которое функционирует через приложение Wallet.

Аналитика

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

В большинстве случаев мобильные приложения не предусматривают в себе наличия систем аналитики. Что сказывается на дальнейшей работе с электронными картами неблагоприятно.

Возможности коммуникации

Как в собственных мобильных приложениях, так и в Wallet приложениях встроена возможность отправки push-уведомлений. Push-уведомления – это эффективный канал коммуникации между бизнесом и клиентом. Это короткие сообщения, которые приходят прямо на cмартфон клиента даже при заблокированном экране.

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

Вариативность

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

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

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

Подводя итоги:

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

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

Решение этой проблемы нашлось в новых технологиях – универсальных хранилищах Wallet для iOS и WaletUnion для Android. Они позволяют хранить электронные карт лояльности, а также кредитные карты, посадочные талоны, билеты в кино, купоны и многое другое в одном месте.

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

SDK для Android (legacy)

SDK для Android — это набор средств разработки для подключения мобильных приложений, работающих на платформе Android, к платёжной платформе ecommpay . В этом разделе представлена информация о работе с SDK для Android с примерами кода на языках программирования Java и Kotlin.

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

SDK для Android может встраиваться в мобильные приложения, работающие на платформе Android версии 4.4 (уровень API — 19) или выше и поддерживающие AndroidX. Для корректного отображения платёжной формы разрешение экрана мобильного устройства должно быть не менее 480×800 пикселей.

• Библиотеки для Android: https://github.com/ITECOMMPAY/paymentpage-sdk-android/releases/
• Примеры кода: https://github.com/ITECOMMPAY/paymentpage-sdk-android/

Общая информация

Возможности

• Google Pay — оплаты с использованием платёжных карт. Информация об особенностях проведения оплат с использованием метода Google Pay через SDK для Android представлена в разделе Оплата с использованием альтернативных платёжных методов.
• Skrill Wallet — оплаты с использованием электронных кошельков во всех странах.
• DOKU Wallet — оплаты с использованием электронных кошельков в Индонезии.
• Malaysian Online Banking — оплаты с использованием интернет-банкинга через банки Малайзии.
• Thai Online Banking — оплаты с использованием интернет-банкинга через банки Таиланда.
• Alipay — оплаты с использованием электронных кошельков в Китае.
• Neteller — оплаты с использованием электронных кошельков.
• Open banking в странах Европы — оплаты с использованием интернет-банкинга в следующих странах: Австрия, Бельгия, Великобритания, Венгрия, Германия, Греция, Италия, Латвия, Литва, Нидерланды, Румыния, Франция, Эстония.

Также поддерживается проведение платежей с использованием методов, информация о которых представлена в разделе Методы. По вопросам, связанным с подключением этих платёжных методов, следует обращаться к курирующему менеджеру ecommpay .

• Поддержка русского, английского, испанского, итальянского, немецкого и французского языков. Платёжная форма может отображаться на языке интерфейса мобильного устройства пользователя или на том языке, который для платёжной формы указывается со стороны мерчанта. При этом необходимо учитывать следующее:
  • Если со стороны мерчанта указывается поддерживаемый SDK для Android язык, платёжная форма отображается на указанном языке.
  • Если со стороны мерчанта указывается не поддерживаемый SDK для Android язык, платёжная форма отображается на английском языке.
  • Если со стороны мерчанта язык не указывается, платёжная форма отображается на языке интерфейса мобильного устройства, если этот язык поддерживается SDK для Android , или на английском языке, если язык интерфейса мобильного устройства не поддерживается SDK для Android .
  • вручную,
  • сканируя карту,
  • выбирая сохранённую карту,
  • используя предварительно выбранную карту.

  Состав

  SDK для Android содержит файл с библиотеками ecommpaySDK.aar и примеры работы на языках программирования Java и Kotlin.

  Схема работы

  Проведение платежей с использованием SDK для Android выполняется следующим образом:

  1. В клиентской части мобильного приложения формируется объект с необходимыми параметрами для проведения платежа.
  2. В серверной части мобильного приложения вычисляется подпись на основании параметров платежа.
  3. В клиентской части формируется итоговый запрос на проведение платежа и с помощью библиотеки отправляется в платёжную платформу ecommpay .
  4. В платёжной платформе выполняется обработка платежа.
  5. От платёжной платформы к клиентской части отправляется результат выполнения платежа.
  6. От платёжной платформы на заданный URL отправляется оповещение.

  Подключение и использование

  Для использования SDK для Android необходимо:

  1. Решить организационные вопросы, касающиеся взаимодействия с ecommpay :
     • Если у компании нет идентификатора и ключа для взаимодействия с ecommpay — отправить заявку на подключение.
     • Если у компании есть идентификатор и ключ для взаимодействия с ecommpay — сообщить специалистам технической поддержки о намерении интеграции с использованием SDK для Android и согласовать с ними порядок тестирования и запуска.
  2. Выполнить подготовительные технические работы:
     1. Обеспечить подписывание данных на стороне серверной части мобильного приложения.
     2. Скачать и подключить SDK для Android .
     3. Доработать клиентскую часть мобильного приложения для инициирования платежей необходимых типов и обработки результатов этих платежей.
     1. Для тестирования следует использовать тестовый идентификатор проекта и данные тестовых карт, предоставленные специалистами технической поддержки ecommpay .
     2. Для перевода в рабочий режим следует изменить тестовое значение идентификатора проекта на рабочее значение, полученное от ecommpay .

     При возникновении вопросов о работе с SDK для Android следует обращаться в службу технической поддержки ecommpay support@ecommpay.com .

     Интерфейс платёжной формы

     

     Обеспечение работы с подписью

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

     1. Вычислить код HMAC для полученной строки на основе алгоритма SHA-512 и секретного ключа.
     2. Выполнить кодировку результата по алгоритму Base64.
     • Строка для подписывания.

     customer_id:5;payment_amount:30;payment_currency:EUR;payment_id:payment1;project_id:115

     RTUC1Awbk1Wgc6ddAeVsxLxHfhM3T9X79SBwiWXSWiWMyUSAobIxLQTdiRWvdtMQOY6VdjRAVTj6L3zIH6iwLQ==

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

     Подключение библиотек

     Подключение библиотек к проекту

     1. Загрузить файл ecommpaySDK.aar .
     2. Добавить в проект библиотеки из загруженного файла. В Android Studio 3.0 для этого необходимо перейти в раздел File > New > New Module , выбрать Import .JAR/.AAR Package и указать расположение файла ecommpaySDK.aar .
     3. Открыть файл модуля приложения ( build.gradle ).
     4. Добавить параметры компиляции в секцию android <> :

     compileOptions < sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 >

     implementation project(path: ':ecommpaySDK') implementation 'io.card:android-sdk:5.5.1' implementation 'com.squareup.retrofit2:retrofit:2.3.0' implementation 'com.squareup.okhttp3:logging-interceptor:3.10.0' implementation 'androidx.appcompat:appcompat:1.0.0' implementation 'androidx.legacy:legacy-support-v4:1.0.0' implementation 'androidx.recyclerview:recyclerview:1.0.0' implementation 'com.squareup.retrofit2:converter-gson:2.3.0' implementation 'com.google.code.gson:gson:2.8.4' implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version" implementation 'androidx.lifecycle:lifecycle-viewmodel:2.0.0' implementation 'androidx.lifecycle:lifecycle-extensions:2.0.0' annotationProcessor 'androidx.lifecycle:lifecycle-compiler:2.0.0'

     "android.permission.INTERNET" /> "android.permission.ACCESS_NETWORK_STATE" /> "android.permission.ACCESS_FINE_LOCATION" /> "android.permission.ACCESS_COARSE_LOCATION" /> "android.permission.WRITE_EXTERNAL_STORAGE" />

     Подключение библиотек через MavenCentral

     Для SDK для Android версии 1.10.0 и выше поддерживается подключение библиотек через MavenCentral. Для подключения библиотек через MavenCentral необходимо:

     1. Открыть файл модуля приложения ( build.gradle ).
     2. Указать в секции repositories <> репозиторий mavenCentral :

     allprojects < repositories < google() jcenter() mavenCentral() >>

     Вызов платёжной формы

     Вызов в Java

     Для вызова платёжной формы необходимо выполнить следующие действия:

     1. Создать объект ECMPPaymentInfo . Этот объект должен содержать обязательные параметры для открытия платёжной формы:
        • projectID — идентификатор проекта, полученный от ecommpay при интеграции;
        • paymentID — идентификатор платежа, уникальный в рамках проекта;
        • paymentAmount — сумма платежа в дробных единицах;
        • paymentCurrency — валюта платежа в формате ISO-4217 alpha-3.

     Пример объекта ECMPPaymentInfo , который содержит только обязательные параметры:

     ECMPPaymentInfo paymentInfo = new ECMPPaymentInfo( 115, // идентификатор проекта, полученный от ecommpay при интеграции "internal_payment_id_1", // идентификатор платежа, уникальный в рамках проекта 1999, // сумма платежа в дробных единицах "USD" // валюта платежа в формате ISO-4217 alpha-3 );

     Дополнительно могут использоваться следующие объекты и параметры:

     • recurrentInfo — объект с информацией о повторяемой оплате (подробнее).
     • paymentDescription — описание платежа (данный параметр доступен не только мерчанту, но и пользователю; если параметр paymentDescription передан в запросе, он отображается в платёжной форме в диалоговом окне с информацией о платеже; если параметр не передан в запросе, пользователю он не виден).
     • customerID — идентификатор пользователя, уникальный в рамках проекта.
     • regionCode — код страны пользователя в формате ISO 3166 alpha-2.
     • ActionType — тип действия. Допустимые значения: Sale (по умолчанию), Auth , Verify и Tokenize .
     • token — токен карты.
     • forcePaymentMethod — идентификатор платежного метода, который откроется в платёжной форме по умолчанию без возможности выбора пользователем другого платёжного метода. Список идентификаторов приведен в разделе Коды платёжных методов.
     • hideSavedWallets — параметр, позволяющий управлять отображением сохранённых ранее платёжных инструментов и при необходимости скрывать сохранённые платёжные инструменты в платёжной форме. Возможные значения:
       • true — сохранённые ранее платёжные инструменты скрыты, они не отображаются при открытии платёжной формы.
       • false — сохранённые ранее платёжные инструменты отображаются при открытии платёжной формы.
       • hide_success_final_page — финальная страница с сообщением о совершённом платеже не отображается в платёжной форме,
       • hide_decline_final_page — финальная страница с сообщением об отклонённом платеже не отображается в платёжной форме.

       Пример передачи в запросе параметров hide_success_final_page и hide_decline_final_page :

       // Init ECMPPaymentInfo paymentInfo.addEcmpScreenDisplayMode("hide_success_final_page") .addEcmpScreenDisplayMode("hide_decline_final_page");

       Пример объекта ECMPPaymentInfo , который содержит необязательные параметры (описание платежа, идентификатор и страну пользователя):

       ECMPPaymentInfo paymentInfo = new ECMPPaymentInfo( 115, // идентификатор проекта, полученный от ecommpay при интеграции "internal_payment_id_1", // идентификатор платежа, уникальный в рамках проекта 1999, // сумма платежа в дробных единицах "USD", // валюта платежа в формате ISO-4217 alpha-3 "T-shirt with dog print", // описание платежа "10", // идентификатор пользователя, уникальный в рамках проекта "US" // код страны в формате ISO 3166 alpha-2 );

       paymentInfo.getParamsForSignature();

       paymentInfo.setSignature(signature);

       startActivityForResult(ECMPActivity.buildIntent(this, paymentInfo), PAY_ACTIVITY_REQUEST);

       Вызов в Kotlin

       Для вызова платёжной формы необходимо выполнить следующие действия:

       1. Создать объект ECMPPaymentInfo . Этот объект должен содержать обязательные параметры для открытия платёжной формы:
          • projectID — идентификатор проекта, полученный от ecommpay при интеграции;
          • paymentID — идентификатор платежа, уникальный в рамках проекта;
          • paymentAmount — сумма платежа в дробных единицах;
          • paymentCurrency — валюта платежа в формате ISO-4217 alpha-3.

       Пример объекта ECMPPaymentInfo , который содержит только обязательные параметры:

       val paymentInfo = ECMPPaymentInfo( 115, // идентификатор проекта, полученный от ecommpay при интеграции "internal_payment_id", // идентификатор платежа, уникальный в рамках проекта 1999, // сумма платежа в дробных единицах "USD") // валюта платежа в формате ISO-4217 alpha-3

       Дополнительно могут использоваться следующие объекты и параметры:

       • recurrentInfo — объект с информацией о повторяемой оплате (подробнее).
       • paymentDescription — описание платежа (данный параметр доступен не только мерчанту, но и пользователю; если параметр paymentDescription передан в запросе, он отображается в платёжной форме в диалоговом окне с информацией о платеже; если параметр не передан в запросе, пользователю он не виден).
       • customerID — идентификатор пользователя, уникальный в рамках проекта.
       • regionCode — код страны пользователя в формате ISO 3166 alpha-2.
       • ActionType — тип действия. Допустимые значения: Sale (по умолчанию), Auth , Verify и Tokenize .
       • token — токен карты.
       • forcePaymentMethod — идентификатор платежного метода, который откроется в платёжной форме по умолчанию без возможности выбора пользователем другого платёжного метода. Список идентификаторов приведен в разделе Коды платёжных методов.
       • hideSavedWallets — параметр, позволяющий управлять отображением сохранённых ранее платёжных инструментов и при необходимости скрывать сохранённые платёжные инструменты в платёжной форме. Возможные значения:
         • true — сохранённые ранее платёжные инструменты скрыты, они не отображаются при открытии платёжной формы.
         • false — сохранённые ранее платёжные инструменты отображаются при открытии платёжной формы.
         • hide_success_final_page — финальная страница с сообщением о совершённом платеже не отображается в платёжной форме,
         • hide_decline_final_page — финальная страница с сообщением об отклонённом платеже не отображается в платёжной форме.

         Пример передачи в запросе параметров hide_success_final_page и hide_decline_final_page :

         // Init ECMPPaymentInfo paymentInfo.addEcmpScreenDisplayMode("hide_success_final_page") .addEcmpScreenDisplayMode("hide_decline_final_page");

         Пример объекта ECMPPaymentInfo , который содержит необязательные параметры (описание платежа, идентификатор и страну пользователя):

         val paymentInfo = ECMPPaymentInfo( 115, // идентификатор проекта, полученный от ecommpay при интеграции "internal_payment_id", // идентификатор платежа, уникальный в рамках проекта 1999, // сумма платежа в дробных единицах "USD", // валюта платежа в формате ISO-4217 alpha-3 "T-shirt with dog print", // описание платежа "10", // идентификатор пользователя, уникальный в рамках проекта "US") // код страны в формате ISO 3166 alpha-2

         paymentInfo.getParamsForSignature();

         paymentInfo.signature = signature

         startActivityForResult( ECMPActivity.buildIntent(this, paymentInfo), PAY_ACTIVITY_REQUEST)

         Приём результатов

         Для получения кода ответа о проведении платежа необходимо переопределить метод onActivityResult в том окне (activity), где вызывается ECMPActivity.

         Для проведения платежей с использованием альтернативных платёжных методов требуется связаться со специалистами службы технической поддержки ecommpay для включения данной возможности в рамках проекта. Также можно настроить передачу данных о пользователе (подробнее).

         Google Pay

         1. Зарегистрироваться в сервисе Google Pay Business Console и получить идентификатор мерчанта в сервисе Google Pay (Google merchant ID).
         2. Принять и соблюдать Правила допустимого использования Google Pay API, а также принять условия, приведённые в Пользовательском соглашении Google Pay API.
         3. Связаться со специалистами технической поддержки ecommpay для подключения метода Google Pay в рамках требуемых проектов.

         После этого можно проводить оплаты с использованием Google Pay. Все основные процедуры — вызов платёжной формы, приём результатов и обработка оповещений — выполняются при этом так же, как и при работе с другими методами, а при формировании запросов необходимо учитывать следующее:

         • В запросах на открытие платёжной формы необходимо указывать идентификатор мерчанта в сервисе Google Pay ( merchantId ) и объект PaymentDataRequest , который используется для подключения приложения мерчанта к Google Pay API и описан в документации Google Pay API.
         • настраивать оформление отдельных элементов.

         Использование темы

         SDK для Android позволяет использовать две темы платёжной формы: светлую (по умолчанию) и тёмную. Для смены темы необходимо установить:

         ECMPTheme theme = ECMPTheme.getDarkTheme(); startActivityForResult(ECMPActivity.buildIntent(this, paymentInfo, theme), PAY_ACTIVITY_REQUEST);

         val theme = ECMPTheme.getDarkTheme() startActivityForResult( ECMPActivity.buildIntent( this, paymentInfo, theme ), PAY_ACTIVITY_REQUEST )

         Настройка оформления отдельных элементов

         Также можно настраивать цветовое оформление отдельных элементов. Например:

         theme.fullScreenBackgroundColor = Color.GREEN; theme.showShadow = false;

         theme.fullScreenBackgroundColor = Color.GREEN theme.showShadow = false

         • overlayColor — цвет затемнения открытой области платёжной формы,
         • statusBarColor — цвет строки состояния,
         • modalBackgroundColor — цвет фона модального окна,
         • fullScreenBackgroundColor — цвет фона платёжной формы в полноэкранном режиме,
         • headingTextColor — цвет текста заголовка,
         • menuTextColor — цвет текста кнопок в заголовке модального окна,
         • fieldTextColor — цвет текста дополнительных полей, названий платёжных методов, данных на странице с информацией о результате проведения платежа,
         • fieldPlaceholderTextColor — цвет заполнителей полей,
         • fieldImageTintColor — цвет иконок в полях ввода при оплате новой картой и в поле CVV,
         • fieldBackgroundColor — цвет кнопок платёжных систем и поля CVV,
         • fieldUnderlineSelectedColor — цвет нижней линии полей ввода при выборе поля в фокус,
         • fieldUnderlineDefaultColor — цвет нижней линии полей ввода по умолчанию,
         • fieldUnderlineErrorColor — цвет нижней линии полей ввода при неуспешной проверке заполненного поля,
         • navigationBarItemsColor — цвет кнопок панели навигации,
         • navigationBarColor — цвет панели навигации,
         • primaryTintColor — основной цвет кнопок и иконок платёжной формы,
         • secondaryTintColor — вспомогательный цвет платёжной формы,
         • actionButtonDisableBackgroundColor — цвет заблокированной кнопки,
         • actionButtonDisableTextColor — цвет текста на заблокированной кнопке,
         • actionButtonTextColor — цвет текста на активной кнопке,
         • supportiveTextColor — цвет вспомогательного текста,
         • secureKeyboardTextColor — цвет цифр экранной клавиатуры,
         • showShadow — включение тени кнопок платежных методов и сохранённых карт на странице выбора платёжных методов,
         • showLightLogo — включение светлых логотипов при использовании тёмной темы.