...

среда, 2 октября 2013 г.

Прием платежей по банковским картам в приложениях — PayOnline Payment SDK

В конце лета PayOnline совместно с Microsoft анонсировали выход нового продукта — PayOnline Payment SDK, позволяющего разработчикам мобильных приложений интегрировать прием безналичных платежей в приложения Windows Store и Windows Phone. 12 сентября мы выступили на Windows Camp с презентацией Payment SDK, встретились с разработчиками приложений лицом к лицу и рассказали о самых интересных аспектах реализации приема платежей в приложениях. О том, что такое интернет-эквайринг, написано много и в Интернете, и, в частности, на Хабре (1,2), поэтому повторяться не хочется, перейдем сразу к делу.

image



Как у любого «взрослого» IPSP (Internet Payment Service Provider) у нас есть свой API, позволяющий проводить платежные операции. Мы передаем разработчикам интерфейс, и из полученного «конструктора» разработчик приложения на своей стороне строит ту часть платежного сервиса, которая будет отвечать за взаимодействие плательщика и банка-эквайера.


Все замечательно и ровно до тех пор, пока разработка касается web-сайтов. Интернет-эквайринг – это прием денег в Интернете, и, соответственно, технологии защиты от мошенничества разработаны с учетом этой специфики.


Один из способов защиты – это протокол 3-D Secure, предложенный мировой платежной системой VISA и принятый за стандарт другими платежными системами.
Что такое 3-D Secure, знает практически каждый, кто совершал покупки в Интернете (сейчас в России очень незначительная доля банков, эмитирующих карты, не поддерживает этот протокол, и их количество уменьшается в связи с требованиями все тех же МПС).

Чаще всего протокол 3-D Secure в работе выглядит так: вы совершаете оплату на сайте интернет-магазина, вводите данные карты, после этого направляетесь на страницу банка-эмитента, где вводите код, полученный в СМС. После этого ваша оплата успешно завершается.


Название 3-D происходит от 3-Domain (три домена), так как в проверке платежа по данному протоколу участвуют организации на трех доменах: домен эмитента (плательщик и банк-эмитент), домен эквайера (банк, обрабатывающий платеж, и интернет-магазин) и домен взаимодействия (МПС). Так выглядит упрощенная схема проверки платежа по протоколу 3-D Secure:

image

Плательщик вводит данные карты в интернет-магазине, они достигают банка-эквайрера (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/


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:



Комментариев нет:

Отправить комментарий