Система электронных платежей
112,12
рейтинг
2 октября 2013 в 15:05

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

В конце лета 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.

Скачать можно из nuget: https://www.nuget.org/packages/PayOnline_PaymentSDK/
Автор: @PayOnline
PayOnline
рейтинг 112,12
Система электронных платежей

Комментарии (6)

  • 0
    Интересно жизнь развивается. Раньше номер карты фактически и был тем самым «PayID» для банковского счета.
    • 0
      «PayID» — это изобретение процессинга PayOnline. PayID — по своей сути является email'ом, к которому привязаны карты. То есть при оплате через PayID мобильное приложение оперирует не «секьюрными данными» (данные карты), а лишь email'ом пользователя, и уже на стороне процессинга идет работа с картами.
      • 0
        Так я и пытаюсь Вам сказать, что в теории по мере распространения PayID он сам становится «секьюрными данными».
        Придётся вводить PayID level 2. Ведь все эти стандарты для работы с данными карты, тоже не сразу появились. А по мере распространения возможности «получить» деньги со счета пользователя, зная только номер.
        Когда такой возможности не было, номер карта не являлся «секьюрными данными», т.к. требовалась карта физически (точнее то, что записано на магнитной полосе).
        • 0
          Для проведения платежа по PayID необходимо будет знать пароль к личному кабинету payid.ru, а также ввести CVV карты, привязанной к PayID.
  • +3
    Третья версия PCI стандартов выйдет уже вот-вот. Почти нет сомнений что все просчеты относительно мобильных приложений будут закрыты, причем, скорее всего, самым жестоким образом.
  • 0
    У меня маленький глупый вопрос: Вы так хардкодите свой приватный ключ в приложение — не боитесь, что его оттуда вынут?

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

Самое читаемое Разработка