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

В конце лета 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, предложенный мировой платежной системой VISA и принятый за стандарт другими платежными системами.

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

Чаще всего протокол 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/

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:

• Massacres That Matter - Part 1 - 'Responsibility To Protect' In Egypt, Libya And Syria


• Massacres That Matter - Part 2 - The Media Response On Egypt, Libya And Syria


• National demonstration: No attack on Syria - Saturday 31 August, 12 noon, Temple Place, London, UK