В конце лета PayOnline совместно с Microsoft анонсировали выход нового продукта — PayOnline Payment SDK, позволяющего разработчикам мобильных приложений интегрировать прием безналичных платежей в приложения Windows Store и Windows Phone. 12 сентября мы выступили на Windows Camp с презентацией Payment SDK, встретились с разработчиками приложений лицом к лицу и рассказали о самых интересных аспектах реализации приема платежей в приложениях. О том, что такое интернет-эквайринг, написано много и в Интернете, и, в частности, на Хабре (1,2), поэтому повторяться не хочется, перейдем сразу к делу.
Как у любого «взрослого» IPSP (Internet Payment Service Provider) у нас есть свой API, позволяющий проводить платежные операции. Мы передаем разработчикам интерфейс, и из полученного «конструктора» разработчик приложения на своей стороне строит ту часть платежного сервиса, которая будет отвечать за взаимодействие плательщика и банка-эквайера.
Все замечательно и ровно до тех пор, пока разработка касается web-сайтов. Интернет-эквайринг – это прием денег в Интернете, и, соответственно, технологии защиты от мошенничества разработаны с учетом этой специфики.
Чаще всего протокол 3-D Secure в работе выглядит так: вы совершаете оплату на сайте интернет-магазина, вводите данные карты, после этого направляетесь на страницу банка-эмитента, где вводите код, полученный в СМС. После этого ваша оплата успешно завершается.
Название 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, который позволяет быстро и безболезненно, и «без особого геморроя» интегрировать в приложение прием платежей по картам.
Пример кода
Рассмотрим пример кода для приложения 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 плательщика.
Про PCI PA-DSS
Подкованный читатель, разумеется, заметит, что в нашем SDK мы оперируем номерами карт, и спросит как же PCI DSS? Да, действительно, приложения, в которых вводятся данные банковских карт в ходе оплаты, формально попадают под действие стандарта PCI DSS, а точнее PCI PA-DSS.
Что такое PCI DSS мы подробно писали в своем посте. PCI PA-DSS это родственный PCI DSS стандарт безопасности платежных приложений (Payment Card Industry Payment Application).
- Область применения: приложение, которое хранит, обрабатывает или передает данные о держателях карт.
- Критерий применимости: хранение, обработка или передача хотя бы одного номера карты (PAN).
- Критерий соответствия: выполнение 100% требований.
- Способ подтверждения: проверка безопасности приложения аудиторской организацией.
- Регулярность подтверждения: ежегодно.
Как несложно понять из области применения стандарта, если в приложении вводятся данные банковских карт, оно попадает под зону действия стандарта. И задуматься о получении сертификата, казалось бы, должны владельцы приложений, использующих как API, так и SDK.
Однако, стоит отметить, что, во-первых, для мобильных приложений еще просто не существует четких требований (как, например, для интернет-магазинов), а во-вторых, для малых форм бизнеса прохождение сертификации является строго обязательным только формально. Например, все интернет-магазины, предоставляющие клиентам возможность оплатить заказ банковской картой, должны обладать сертификатом PCI DSS Level 4, даже если сама оплата производится на защищенной платежной странице сервис-провайдера. Однако, всем понятно, что интернет-магазин с оборотом по картам в 20 000 рублей в месяц никто не обяжет проходить ежегодную сертификацию — и та же ситуация наблюдается с сертификацией по PA-DSS для мобильных приложений.
Про возможность замены платежных данных на платежный идентификатор payID
Требования стандарта распространяется на приложения, в которые вводятся данные банковских карт. Если же в приложении вводятся не платежные данные, а некий идентификатор – приложение перестает обрабатывать данные карт и необходимость в сертификации отпадает.
В начале 2013 года мы запустили проект payID, позволяющий принимать оплаты без ввода платежных данных. Владелец банковской карты создает аккаунт в payID, привязывает к нему банковскую карту и при совершении оплат на сайтах, принимающих платежи через PayOnline, вводит не полные данные карты, а свой идентификатор payID и CVC CVV код. Это позволяет снять с интернет-магазина или приложения ответственность за обработку данных банковских карт, а плательщику – обеспечить 100% безопасность данных своей карты и, соответственно, денег на счете.
Если встроить в приложение прием оплат по payID – можно принимать платежи по картам без встроенных платежных форм, прохождения сертификации PA-DSS, страха и упрека.
Про будущее Payment SDK
Как мы уже писали выше, SDK под Windows мы запустили в конце этого лета, продукт еще свеж и находится в стадии активного развития. Вообще, сфера приема платежей по картам в мобильных приложениях сама по себе очень молода. Вплоть до того, что стандарты безопасности в ней еще формируются, контролируется она отнюдь не так жестко, как стандартная электронная коммерция.
Но динамика роста популярности мобильного Интернета в России, повальный переход с телефонов на смартфоны, рост количества русскоязычных приложений – все это говорит о перспективности работы в мобильном сегменте электронной коммерции, его потенциале и возможностях монетизации.
Посему, мы продолжим развивать Payment SDK, и планируем двигаться в нескольких направлениях:
- Расширение возможностей для разработчиков: списка платформ (Android, iOS) и списка поддерживаемых языков программирования – здесь все понятно и без комментариев.
- Перевод с карты на карту: у нас есть реализованный сервис перевода с карты на карту, о нем на Хабре уже писали. Мы думаем о реализации возможности интеграции данного сервиса в приложения, работающие по Donation схеме. Владелец приложения сможет избежать необходимости регистрации ИП, создания сайта визитки и заключения договора с платежным шлюзом. Ему потребуется только банковская карта для получения переводов.
- Удобный прием платежей через payID в приложениях: почему использовать payID удобно и выгодно понятно из части поста «Про PCI PA-DSS». Это позволяет избежать затрат на сертификацию, снять с себя ответственность за данные карт и привлечь новых покупателей.
Сейчас мы размышляем о том, как безболезненно превратить владельца карты во владельца идентификатора, если он уже находится в вашем приложении.
Тем для размышления много, работы не меньше – будем признательны хабражителям за конструктивную критику, интересные идеи и предложения по развитию PayOnline Payment SDK.
Скачать можно из nugget: https://www.nuget.org/packages/PayOnline_PaymentSDK/
Автор: PayOnline
