В 2013 году PayOnline при поддержке Microsoft выпустил PayOnline Payment SDK. Это позволило разработчикам мобильных приложений под Windows (на тот момент — под Windows Store и Windows Phone) интегрировать прием платежей в приложения за считанные минуты. В этом посте мы коротко расскажем о Payment SDK, его переходе на Universal Apps и появившейся поддержке рекуррентных (регулярных) платежей в приложениях.
Разобраться, что такое Payment SDK PayOnline, поможет видео с одного из Windows Camp, на котором тим-лид PayOnline продемонстрировал немного «уличной магии»: показал в режиме «реального времени», как происходит интеграция SDK в приложение и провел тестовую транзакцию.
С тех пор у Microsoft появилась возможность создавать Universal Apps – приложения, адаптированные для использования как на смартфоне, так и на стационарном компьютере. Как и обещали гайдлайны от Microsoft, переход оказался простым и быстрым (об этом расскажем далее).
Также в 2014 году у нашего SDK появилась поддержка рекуррентных платежей (регулярных платежей, инициированных плательщиком и списываемых с карты плательщика без его участия). Этот вид платежей категорически рекомендуется использовать сервисам, работающим по модели платной подписки: плательщик сможет один раз завести данные карты и согласиться на автоматические списания один раз, например, в квартал.
Обо всем по порядку.
ЗАЧЕМ РАЗРАБОТЧИКУ ПРИЛОЖЕНИЯ PAYMENT SDK?
PayOnline предоставляет услуги интернет-эквайринга для сайтов и приложений, имеющих коммерческий функционал – то есть продающих за деньги законодательно разрешенные товары и услуги. Для интеграции приема платежей в мобильные приложения еще в начале 2010-х было разработано платежное решение Pay-Mobile. C тех пор мы постоянно занимаемся упрощением процедуры подключения как с технической, так и с операционной точки зрения. Одна из задач, направленных на упрощение технической интеграции, — это реализация Payment SDK для популярных мобильных платформ.
Как у любого «взрослого» платежного сервис-провайдера, у PayOnline есть свой API. Мы передаем его разработчикам, и из полученного «конструктора» они на своей стороне строят ту часть платежного сервиса, которая будет отвечать за взаимодействие плательщика и банка-эквайера.
Интернет-эквайринг – это прием денег в Интернете, и, соответственно, технологии защиты от мошенничества разработаны с учетом интернет специфики. Один из способов защиты – это протокол 3-D Secure, предложенный мировой платежной системой VISA и принятый за стандарт другими платежными системами.
Название 3-D происходит от 3-Domain (три домена), так как в проверке платежа по данному протоколу участвуют организации на трех доменах: домен эмитента (плательщик и банк-эмитент), домен эквайера (банк, обрабатывающий платеж, и интернет-магазин) и домен взаимодействия (МПС). Так выглядит упрощенная схема проверки платежа по протоколу 3-D Secure:
Плательщик вводит данные карты в интернет-магазине, они достигают банка-эквайера (1), отправляются в МПС (2), откуда направляются в банк-эмитент (3). О том, какой банк эмитировал карту, можно узнать по первым шести цифрам номера карты. Банк-эмитент сообщает, что карта подписана на 3-D Secure, формирует уникальный код, а также ссылку на страницу ввода кода (4). Ссылка возвращается в ТСП или IPSP (5), которые делают редирект в браузере держателя карты на эту страницу (6,7). В этот момент эмитент отправляет держателю карты по другому каналу (например, через СМС) код, который он вводит на странице. В случае корректного ввода кода, банк-эмитент сообщает об успешном завершении проверки (8), и средства списываются с карты плательщика (9, 10).
Самая простая форма интеграции приема платежей в мобильных приложениях – это встроенный браузер. Нужно встроить браузер для отображения платежной страницы банка-эквайера или платежного шлюза — и страницу для ввода кода подтверждения проверки 3-D Secure. Но что делать, если вы делаете полноценное нативное приложение и не хотите встраивать поддержку браузера?
В этом случае на помощь приходит API, о котором мы писали выше. Но при использовании API на плечи разработчика приложения ложится значительный объем работ по интеграции приложения с платежным шлюзом, особенно это касается реализации протокола 3-D Secure.
И тут мы подходим к самому интересному — описанию SDK, который позволяет быстро и безболезненно интегрировать в приложения прием платежей по картам.
ПОЛЕВЫЕ ЗАМЕТКИ: ИСПОЛЬЗОВАНИЕ PAYMENT SDK
Пример кода
Рассмотрим пример кода для приложения Windows Store. Его достаточно, чтобы обеспечить прием платежей в приложении.
private void Pay()
{
var conf = new Configuration
{
MerchantId = 1,
Key = "PrivateKey",
};
var request = new PayRequest
{
Amount = 30m,
Currency = Currency.Rub,
OrderId = "335636462808",
CardExpMonth = 1,
CardExpYear = 2018,
CardCvv = 100,
CardHolderName = "CARD HOLDER",
CardNumber = "4111111111111111",
Email = "cardholder@example.com",
};
var po = new Processing(conf);
po.ThreeDs += po_ThreeDs;
po.Success += po_Success;
po.Decline += po_Decline;
po.Error += po_Error;
po.Pay(request);
}
void po_Error(object sender, Exceptions.PaymentSDKException e)
{
}
void po_Decline(object sender, PayResponse e)
{
}
void po_Success(object sender, PayResponse e)
{
}
void po_ThreeDs(object sender, PayResponse e)
{
((Processing)sender).NavigateToAcsUrl(Browser, e);
}
class Configuration : IConfiguration
{
public int MerchantId { get; set; }
public string Key { get; set; }
}
Что здесь происходит
Для проведения платежа необходимо использовать объект Processing — принимающий объект, который должен реализовать интерфейс IConfiguration. Реализация очень простая, два поля: ваш ID и секретный ключ, который выдается при подключении.
class Configuration : IConfiguration
{
public int MerchantId { get; set; }
public string Key { get; set; }
}
Объект Processing предоставляет четыре события:
- Success — возникает в случае успешного проведения платежа.
- Decline — возникает в случае отказа в проведении.
- Error — если в момент проведения платежа возникли какие-то ошибки, например, недоступна сеть.
- ThreeDs — необходимо пройти дополнительную проверку по 3-D Secure.
В последнем случае необходимо показать пользователю страницу банка-эмитента для ввода кода или пароля, и обработать ответ. Можно все сделать вручную, а можно воспользоваться методом NavigateToAcsUrl, принимающим в качестве параметров пользовательский элемент управления — браузер (для каждой платформы он свой) и объект PayResponse.
Наконец, для вызова метода Pay, ему необходимо передать объект PayRequest, содержащий поля:
- Amount — сумма платежа.
- Currency — валюта (поддерживаются рубли, американские доллары и евро).
- OrderId — ID заказа, который вы генерируете в своей системе.
- CardExpMonth — месяц окончания действия карты.
- CardExpYear — год окончания действия карты.
- CardCvv — CVC2 / CVV2.
- CardHolderName — имя держателя карты.
- CardNumber — номер карты.
- Email — e-mail плательщика.
Регулярные платежи и платежи в один клик
В 2014 году в SDK была добавлена поддержка рекуррентных платежей (технология Rebill). Технология Rebill позволяет организовать регулярный прием платежей в вашем приложении: автоматическое списание за услуги, продление подписки и т.д.
Технология может использоваться в двух режимах:
- Пользователь однажды соглашается на условия автоматического списания средств (например: 100 рублей каждые 3 месяца), вводит данные карты и совершает первый платеж. Дальнейшие списания производятся без участия клиента.
- Пользователь вводит данные карты при первой оплате в приложении. Дальнейшие платежи совершаются без ввода данных карты, но с участием плательщика. Может происходить проверка по протоколу 3D Secure или ввод CVV – зависит от настроек.
Интерфейс
void Rebill(RebillRequest request);
Ниже описано, как выглядит запрос на проведение рекуррентного платежа.
Свойство | Тип | Описание |
---|---|---|
RebillAnchor | строка | Ссылка на транзакцию, для проведения повторного платежа |
OrderId | строка | ID заказа в вашей системе |
Amount | decimal | Сумма повторного списания |
Currency | currency | Валюта повторного списания |
Поддержка Universal Apps
C появлением у Microsoft возможности создавать Universal Apps, приложений, одинаково работающих как на платформе Windows 8.1, так и на платформе Windows Phone 8, мы подготовили обновленный SDK с поддержкой Universal Apps.
Вы можете самостоятельно ознакомиться с кодом демонстрационного приложения Windows Universal App, включающего Payment SDK PayOnline.
Переход на технологию Universal Apps
Проблем с переходом на новую технологию не возникло. После того, как мы сделали новую ветку нашего SDK, потребовалось всего лишь три шага:
После загрузки проекта студия предложила добавить поддержку Windows 8.1
В Solution Explorer выбрали Retarget Windows Store projects to Windows 8.1
Затем в свойствах проекта в свойстве Targeting выбрали поддержку Windows 8.1 и Windows Phone 8.1
После пересборки надо было только устранить пару замечаний об устаревших методах.
О планах развития Payment SDK
Сейчас мы активно занимаемся технологией p2p переводов, которая позволяет владельцам приложений и сайтов зарабатывать на платежах, совершаемых между пользователями (переводы средств с карты на карту). Технология может быть полезна для торговых площадок, досок объявлений, бирж труда, краудфандинговых организаций, сервисов микро кредитов и т.д.
Мы планируем интегрировать технологию p2p в Payment SDK PayOnline уже в первой половине 2015 года, о чем незамедлительно известим сообщество разработчиков мобильных приложений.
Автор: PayOnline