Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1496 сообщений
Cообщения с меткой

платежные системы - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

9 секретов онлайн-платежей. Часть 7: система Fraud-мониторинга

Четверг, 23 Июня 2016 г. 20:40 (ссылка)

imageПочему отклоняются платежи? Как интернет-магазины защищаются от мошенников? Как определить, настоящей картой вам платят или ворованной? Что обеспечивает защиту e-commerce от фрода? Ответы на эти вопросы вы найдете в седьмой части серии авторских статей «9 секретов онлайн-платежей» от PayOnline.



От карточного фрода может пострадать и интернет-магазин, и банк, и непосредственно сам держатель карты. В случае утечки данных карт, злоумышленники стараются снять максимальную сумму денег и не оставить следов, чтобы интернет-магазины разбирались с банками, кто же всё-таки должен возместить утраченную сумму. За владельцами карт уследить невозможно — интернет-магазин не может знать, кто находится по ту сторону экрана: злоумышленник или добропорядочный клиент. Риск есть всегда, но чтобы приблизить его значение к нулю существует множество инструментов проверки платежей и верификации плательщиков. Об одной из них, системе мониторинга мошеннических операций, или «системе антифрод», пойдет речь далее.



Часть 1. Настройка 3D Secure

Часть 2. Регулярные платежи

Часть 3. Страница выбора способа оплаты

Часть 4. Платежная форма

Часть 5. Мобильные платежи

Часть 6. Оплата в один клик

Часть 7. Система fraud-мониторинга

Часть 8. Возвраты и как их избежать

Часть 9. Настройки платежного сервиса под тип бизнеса



Что такое антифрод и как он работает



Общая схема работы практически любого механизма фрод-мониторинга выглядит следующим образом: в момент совершения оплаты с помощью банковской карты собирается несколько показателей (у каждой антифрод системы они разные) – начиная от IP адреса компьютера и заканчивая статистикой оплат по этой карте. Количество фильтров может превышать сотню (например, у системы электронных платежей PayOnline их более 120). Система имеет набор правил, то есть лимитов фильтров безопасности. Каждый из фильтров проверяет пользователя — его персональные и карточные данные. Цель системы — убедиться в том, что пользователь является реальным владельцем карты, совершающим покупку на сайте. В случае выявления подозрительной активности, то есть превышения какого-либо значения параметра, фильтр автоматически блокирует возможность совершения платежа по этой карте. Рассмотрим процесс работы антифрод системы пошагово.



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




  • Страна, из которой совершается платеж.

  • Страна банка, выпустившего карту.

  • Размер платежа.

  • Количество платежей с карты.

  • Платежная история банковской карты.

  • Профиль среднестатистического плательщика магазина.



Транзакция проходит первичный анализ на основании этих и других факторов. На основании анализа ей присваивается «метка», которая характеризует способ обработки транзакции. Существуют три типа меток. «Зеленая» отмечает транзакции с низкой вероятностью возникновения мошеннической операции. «Желтой» меткой отмечаются транзакции, в которых шанс возникновения мошеннической операции выше среднего, и для проведения платежа потребуются дополнительного внимания. «Красной» отмечаются транзакции, которые с наибольшей вероятностью могут оказаться мошенническими, и при их проведении потребуется документальное подтверждение аутентичности владельца карты.



«Судьба» каждой метки индивидуальна. В графическом виде мы представили жизненный цикл транзакций всех трех типов на Рисунке 1. Далее на нескольких простых примерах мы рассмотрим типовые транзакции всех «цветов» и расскажем, какие проверки определяет транзакциям система fraud-мониторинга в зависимости от уровня риска возникновения фрода.



image

Рисунке 1. «Жизненный цикл» транзакций с разными уровнями риска возникновения мошеннической операции



С «зелеными» транзакциями все максимально просто: например, плательщик осуществляет оплату из России, картой, выпущенной российским банком. Сумма платежа не превышает среднего чека магазина.



Система мониторинга присваивает транзакции «зеленую» метку. Далее транзакция отправляется на авторизацию с помощью 3-D Secure. А если карта не подписана на сервис одноразовых паролей или банк-эмитент еще не поддерживает данный сервис, запрос на авторизацию этой транзакции будет направлен в процессинговый центр банка-плательщика обычным способом — напрямую.



Средний уровень риска возникновения fraud-а определяет иной путь проверки оплаты на легитимность. Метка «желтого» цвета присваивается транзакциям со средним и выше среднего уровнями риска возникновения мошеннических операций. Например, в российском интернет-магазине покупка оплачивается банковской картой, выпущенной в России, но размер среднего чека заметно превышает средний «по больнице».



Система помечает данную транзакцию «желтой» меткой, и для ее авторизации могут потребоваться дополнительные действия плательщика. Если карта подписана на 3-D Secure, то транзакция (как и в случае с «зеленой» меткой), будет авторизована с использованием одноразового пароля. Однако если плательщик не может воспользоваться этим способом авторизации платежа, то его банковская карта будет автоматически направлена на онлайн-валидацию или ручную проверку.



«Красную» метку система фрод-мониторинга автоматически присваивает транзакциям с высоким уровень риска совершения мошеннических операций. Например, оплата в российском интернет-магазине осуществляется картой, выпущенной в США, а плательщик находится в Испании.



Если платежи с помощью данной банковской карты ранее не совершались через PayOnline, система fraud-мониторинга пометит транзакцию «красной меткой» и переведет ее из автоматического режима авторизации в ручной. Такой платеж будет отправлен на ручную модерацию специалистам департамента рисков. Для аутентификации владельца банковской карты потребуется документальное подтверждение — отсканированное изображение банковской карты и документа, удостоверяющего личность владельца. После предоставления корректных сканов документов операция переводится из «красного» в «зеленый» цвет и направляется на авторизацию в процессинговый центр банка. Сомнительные операции, не прошедшие ручную модерацию, отклоняются во избежание риска возникновения мошеннических операций.



Таким образом, анализ транзакций автоматически проводится системой fraud-мониторинга сразу на трех уровнях: единичная банковская карта; профиль предприятия электронной коммерции; общий поток транзакций, обрабатываемых IPSP. Вкупе с постоянно совершенствующимися алгоритмами автоматического сбора, обработки и анализа данных о совершенных платежах многоуровневый анализ транзакций позволяет системе fraud-мониторинга своевременно изменяться, повышая уровень безопасности совершения оплат на сайтах клиентов и снижая риски по всем видам фрода, свойственным интернет-коммерции.



Что настораживает систему фрод-мониторинга?



Что может вызвать подозрение у антифрод системы? Вот некоторые параметры, которые, скорее всего, заставят систему мониторинга мошеннических операций.




  • Оплата по одной карте происходит с различных устройств, идентифицированных различными IP адресами.

  • Обратная ситуация — с одного и того же устройства (IP адреса) производятся операции с помощью большого количества карт.

  • С одной карты совершается несколько неудачных попыток оплаты (вероятно, пользователь не имеет возможности пройти процедуру подтверждения).

  • Один клиент регистрируется под несколькими аккаунтами, используя разные адреса электронной почты, и платит с одной карты

  • Имя плательщика, указанное на платежной форме, отличается от имени владельца карты.

  • Разные страны регистрации интернет-магазина, банка-эмитента карты и покупателя.



Этот перечень «спорных ситуаций» может дать вам общее представление о логике работы системы. Специалисты по рискам и бизнес-аналитики стараются учесть все нюансы, добавляя новые фильтры, защищающие бизнес интернет-компаний от злоумышленников. Стоит отметить, что в зависимости от платежного сервис-провайдера логика работы системы фрод-мониторинга и ее параметры изменяются.



Ручная настройка: зачем и кому она нужна



Настройки системы фрод-мониторинга различаются в зависимости от типов бизнеса. Необходимо учитывать целый список параметров:




  • среднестатистический профиль плательщика,

  • размер среднего чека,

  • уровень рисков в сегменте,

  • особенности реализуемых товаров и услуг (цифровые они или физические).



Иногда бизнес имеет очень узкую специфику, и без индивидуальной настройки некоторые платежи просто не смогут пройти стандартные настройки антифрода, хотя и не будут являться мошенническими.



Например, ограничения по географии платежей критичны для сферы онлайн туризма: клиенту может понадобиться приобрести билет на самолет, находясь в командировке за границей, а система заблокирует такой платеж, так как он совершается не из той страны, где выпущена карта плательщика.



В этом случае применяется тонкая настройка фильтров: можно задать условия, согласно которым платеж будет пропускаться, даже если не выполняется условие, географии платежа. Подобные изменения вносятся в систему только после анализа возможных рисков, под контролем специалистов и после согласования изменений с представителем интернет-магазина.



Собственноручное вмешательство в работу системы может привести к большим потерям — при одобрении мошеннических операций интернет-магазин будет обязан вернуть деньги на карту владельца, даже если товар уже был отгружен мнимому покупателю. Более того, на магазин может быть наложен штраф в зависимости от объемов мошенничества, а при повторении подобных ситуаций — особые санкции от международных платежных систем (МПС).



Плюсы и минусы системы антифрод



Плюсы системы мониторинга мошеннических операций очевидны — автоматическое отклонение сомнительных транзакций, защита интернет-магазина от последующих разбирательств с банками, платежными системами и реальными владельцами карт. И, конечно же, минимизация репутационных и финансовых рисков. Репутация магазина не пострадает, и пользователи будут доверять такому ресурсу, а значит, их лояльность будет расти.



Но, как и у любого сервиса, у системы фрод-мониторинга есть свои «издержки производства». Отклонение платежей может привести к потере клиентов, а значит, прибыли. Без должной настройки фильтры могут не пропускать значимые для интернет-магазина транзакции, что точно не понравится покупателям.



При выборе платежного сервис-провайдера стоит обратить внимание на заявленную конверсию в успешные платежи: сервисы, гарантирующие «100% успешных оплат», скорее всего, либо намеренно переоценивают свой функционал, либо подвергают клиентов риску стать жертвой злоумышленников. Например, уровень конверсии в успешные платежи после «ручной» настройки (или у стандартных интернет-магазинов со стандартной клиентской аудиторией) системы электронных платежей PayOnline варьируется в рамках 93-96% — и это очень хороший показатель для рынка.



Еще одним неприятным, но важным моментом, с которым придется столкнуться при разработке системы фрод-мониторинга на стороне интернет-магазина, станет защита данных пользователей, как персональных, так и платежных. Необходимо будет пройти сертификацию соответствия требованием стандарта PCI DSS, а также учесть ограничения на хранение и обработку данных, регулируемые законом. Это относится скорее к тем, кто всё-таки берется за самостоятельную разработку антифрода, поэтому подробно вдаваться в детали в данной статье мы не будем.



Кто предоставляет услуги антифрод и почему лишь единицам стоит вкладываться в собственные разработки



Мониторинг мошеннических операций — необходимость в современных реалиях электронной коммерции. Для банка затраты на поддержку и развитие антифрод-системы — это более чем приемлемая сумма, которая многократно окупится в процессе использования.



Для платежного сервис-провайдера система фрод-мониторинга является одним из ключевых сервисов, который она предоставляет компаниям-клиентам.



Для малого и среднего бизнеса разработка собственного антифрода — это неподъемный и не окупающийся проект. Требования к подобным механизмам растут с каждым годом, они учатся более тонко обрабатывать получаемую информацию, учитывая статистику и поведенческие факторы. Чтобы система работала эффективно и соответствовала современным требованиям, необходим штат квалифицированных специалистов и значительные технические мощности. В подавляющем большинстве случаев игрокам электронной коммерции «не по карману» такие постоянные затраты — и мониторинг мошеннических операций делегируются платежным сервис-провайдерам, специализирующимся на анализе и обработке платежных операций. Так, к примеру, деятельность по мониторингу мошеннических платежных операций в PayOnline осуществляет система Fraud Management System (FMS), разработанная нашими специалистами. Она позволяет произвести тонкую настройку безопасности по 140 фильтрам. Если вы заинтересованы в приеме платежей на сайте или в мобильном приложении, защищенных антифрод-системой, смело обращайтесь, проконсультируем и подключим.



В следующей части «9 секретов онлайн-платежей» обсудим еще одну очень важную для любого продавца тему — чардж-бэк: Что делать, если услуга оказана или товар отгружен, а клиент или банк требуют вернуть деньги обратно на карту плательщика? Как можно избежать возвратов? Какие требования обычно предъявляются к сайту интернет-магазина? Скоро в нашем блоге.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303204/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как не дать частым релизам поломать ваше API, или пишем авто-тесты для открытого API и шлем результат в Telegram бот

Среда, 08 Июня 2016 г. 13:54 (ссылка)

image

Предисловие



Наша команда разрабатывает финансовые инструменты, в том числе открытые платежные API, и как многие проекты, работающие по практике continuous integration мы одновременно с созданием проекта 3 года назад начали думать над тем, как улучшить покрытие проекта тестами и добиться максимальной стабильности нашего кода при довольно частых изменениях (мы иногда устанавливаем обновления на продуктовую среду несколько раз в день). Особенно это важно в трех аспектах:




  • мы предоставляем наши API интерфейсы в открытый доступ клиентам и важно, чтобы все взаимодействие четко соответствовало описаниям спецификаций

  • мы интегрируемся с большим количеством других финансовых сервисов и банков, и помимо покрытия тестами своего кода мы вынуждены также покрывать интеграционными тестами взаимодействие с test (а иногда и prod) средой сторонних систем


  • наша внутренняя архитектура включает в себя большое количество микросервисов, которые общаются между собой по HTTP API






В этой статье я хотел бы поделиться опытом и показать пример, как мы разрабатываем тесты для API интерфейсов включающих в себя как сервер-сервер взаимодействие, так и работу через браузер.  Для демонстрации я приведу простой пример тестирования процесса оплаты банковской картой через наш платежный шлюз с отправкой результата тестов в Telegram.



Проект с примерами тестов вы можете скачать в GitHub: https://github.com/cloudipsp/auto_tests.git



Документация по нашему тестируемому платежному API: https://www.fondy.eu/info/api/



Подготавливаем среду



Для разработки тестов мы используем Robot Framework, и хотя у этого фреймворка есть собственная среда разработки RIDE, но она существенно уступает PyCharm по удобству и возможностям



RIDE

image



Для начала разработки установим 




  1. virtualenv



    pip install virtualenv setuptools

  2. бесплатную версию PyCharm Edu

    https://www.jetbrains.com/pycharm-edu/download/

  3. для PyCharm ставим плагины

    intellibot: 

    http://plugins.jetbrains.com/plugin/7386?pr=pycharm111



    Robot Framework Support:

    http://plugins.jetbrains.com/plugin/7415?pr=pycharm99



    при этом для актуальной версии PyCharm Edu 2.0.4 мне пришлось ставить версию robot framework 0.14.2, так как последняя 0.15 оказалась не совместимой

  4. клонируем проект с github — этот пункт можно пропустить, если есть желание проделать все с нуля:



    git clone https://github.com/cloudipsp/auto_tests.git



  5. устанавливаем зависимости:



    для начала нам достаточно таких библиотек:



    robotframework==2.9a1

    selenium

    robotframework-selenium2library

    requests





    Создаем файл pip-requires.txt с этим содержимым, активируем virtualenv и устанавливаем



    cd auto_tests
    pip install -r pip-requires.txt





Разработка: автотесты без браузера





Для примера возьмем тип покупки по 3DSecure карте, когда карта вводится на стороне торговца (раздел API https://www.fondy.eu/ru/info/api/v1.0/4).







Для простоты исключим Шаг 2. — редирект в браузере (мы его протестируем в следующем примере). Для тестовой карты этот редирект происходит на страницу — эмулятор банковской, которая всегда возвращает один и тот же результат — пароль введен верно.



В этом случае у нас будет 2 шага:


  • шаг 1 — отправка на API https://api.fondy.eu/api/3dsecure_step1/ тестовых данных платежа и реквизитов карты и получение в ответе адреса URL страницы, куда необходимо перенаправить клиента (параметры response_status, acs_url, pareq, md ) для ввода 3DSecure пароля (в случае тестовых данных никакой пароль запрашиваться не будет, вместо страницы эмитента будет страница-заглушка)


  • шаг 3 — отправляем данные order_id, merchant_id, pares, md, version, signature на API https://api.fondy.eu/api/3dsecure_step2/ , получаем финальный ответ и сравниваем его со спецификациями






Первоначальные файлы настроек





В документации по ссылке https://www.fondy.eu/ru/info/api/v1.0/2 возьмем тестовые карты на которых и будем тестировать. Кстати все тестовые платежи можно будет увидеть в демо-кабинете торговца: https://www.fondy.eu/mportal/#/account/demo





Теперь создадим файлы робота:



cards.robot

*** Settings ***
Documentation A resource file with test credit cards. Imported once in resource.robot

*** Variables ***
#Name Card Number Exp Month Exp Year Cvv2
@{3dsApproved} 4444555566661111 01 24 238
@{no3dsApproved} 4444555511116666 01 24 238
@{3dsDeclined} 4444111166665555 01 24 238
@{no3dsDeclined} 4444111155556666 01 24 238




merchant.robot



*** Settings ***
Documentation A resource file with test merchants. Imported once in resource.robot

*** Variables ***
${TestMerchant} 1397120 #(Test merchant)





variables.robot



*** Settings ***
Documentation Variables used in all tests. Imported one time in resource.robot

*** Variables ***
${API SERVER} api.fondy.eu
${JSON} application/json
${XML} application/xml
${FORM} application/x-www-form-urlencoded




resource.robot



*** Settings ***
Documentation A resource file with reusable keywords.

Resource variables.robot
Resource cards.robot
Resource merchants.robot
Library helper/utils.py
Library requester.py




Спецификации протоколов





Для того, чтобы быть уверенным, что запрос к API и ответ от него соответствует спецификациям, создадим файл specifications_settings.py, который будет содержать структуру параметров, описанных в документации. Например параметры в документации





будут соответствовать структуре



PAY_SERVER2SERVER_3DS = {
'request_step1': {
"order_id": {
"required": True,
"type": "string",
"size": 1024
},
"merchant_id": {
"required": True,
"type": "int",
"size": 12
},
"order_desc": {
"required": True,
"type": "string",
"size": 1024
},



полный specifications_settings.py
PAY_SERVER2SERVER_3DS = {
'request_step1': {
"order_id": {
"required": True,
"type": "string",
"size": 1024
},
"merchant_id": {
"required": True,
"type": "int",
"size": 12
},
"order_desc": {
"required": True,
"type": "string",
"size": 1024
},
"signature": {
"required": True,
"type": "string",
"size": 40
},
"amount": {
"required": True,
"type": "amount",
"size": 12
},
"currency": {
"required": True,
"type": "string",
"size": 3
},
"version": {
"default": "1.0",
"required": False,
"type": "string",
"size": 10
},
"server_callback_url": {
"required": False,
"type": "url",
"size": 2048
},
"lifetime": {
"required": False,
"type": "int",
"size": 6
},
"merchant_data": {
"required": False,
"type": "string",
"size": 2048
},
"preauth": {
"default": False,
"type": "boolean",
"required": False
},
"sender_email": {
"required": False,
"type": "email",
"size": 50
},
"lang": {
"required": False,
"type": "string",
"size": 2
},
"product_id": {
"required": False,
"type": "string",
"size": 1024
},
"verification": {
"default": False,
"type": "boolean",
"required": False
},
"card_number": {
"required": True,
"type": "string",
"size": 19
},
"cvv2": {
"required": True,
"type": "string",
"size": 3
},
"expiry_date": {
"required": True,
"type": "date",
"size": 4,
"important": False,
},
},
'request_step2': {
"order_id": {
"required": True,
"type": "string",
"size": 1024
},
"merchant_id": {
"required": True,
"type": "int",
"size": 12
},
"pares": {
"required": True,
"type": "string",
"size": 20480
},
"md": {
"required": True,
"type": "string",
"size": 1024
},
"version": {
"default": "1.0",
"required": False,
"type": "string",
"size": 10
},
"signature": {
"required": True,
"type": "string",
"size": 40
},
},
'response_3ds': {
"response_status": {
"type": "string",
"required": True,
"size": 50
},
"acs_url": {
"type": "string",
"required": True,
"size": 2048
},
"pareq": {
"type": "string",
"required": True,
"size": 20480
},
"md": {
"default": "",
"type": "string",
"required": True,
"description_en": "",
"description_ru": "",
"size": 1024
},
},
'response_final': {
"order_id": {
"type": "string",
"size": 1024
},
"merchant_id": {
"type": "int",
"size": 12
},
"amount": {
"type": "amount",
"size": 12
},
"currency": {
"type": "string",
"size": 3
},
"order_status": {
"type": "string",
"size": 50
},
"response_status": {
"type": "string",
"size": 50
},
"signature": {
"type": "string",
"size": 40
},
"tran_type": {
"type": "string",
"size": 50
},
"sender_cell_phone": {
"type": "string",
"size": 20
},
"sender_account": {
"type": "string",
"size": 50
},
"masked_card": {
"type": "string",
"size": 19
},
"card_bin": {
"type": "int",
"size": 6
},
"card_type": {
"type": "string",
"size": 50
},
"rrn": {
"type": "string",
"size": 50
},
"approval_code": {
"type": "string",
"size": 6
},
"response_code": {
"type": "int",
"size": 4
},
"response_description": {
"type": "string",
"size": 1024
},
"reversal_amount": {
"type": "amount",
"size": 12
},
"settlement_amount": {
"type": "amount",
"size": 12
},
"settlement_currency": {
"type": "string",
"size": 3
},
"order_time": {
"type": "time",
"size": 19
},
"settlement_date": {
"type": "time",
"size": 10
},
"eci": {
"type": "string",
"size": 2
},
"fee": {
"type": "amount",
"size": 12
},
"payment_system": {
"type": "string",
"size": 50
},
"sender_email": {
"type": "email",
"size": 254
},
"payment_id": {
"type": "int",
"size": 19
},
"actual_amount": {
"type": "amount",
"size": 12
},
"actual_currency": {
"type": "string",
"size": 3
},
"product_id": {
"type": "string",
"size": 1024
},
"merchant_data": {
"type": "string",
"size": 2048,
},
"verification_status": {
"type": "string",
"size": 48,
},
"rectoken": {
"type": "string",
"size": 48,
},
"rectoken_lifetime": {
"type": "time",
"size": 19,
},
},
}





Далее создаем функции



функция, которая будет пробегать по файлу спецификаций specifications_settings.py и создавать запрос в формате JSON, XML, FORM из набор всех данных разных типов, добивая их до максимальной длины.



Build required parameters dict
   def build_required_parameters_dict(self, merchant_id, currency, spec, spec_dict, response_url=None, *args,
**kwargs):
self.merchant_id = merchant_id
request_params_specs = getattr(
specifications_settings, spec)[spec_dict]
# for requests with cards
if args:
kwargs['card_number'] = args[0]
kwargs['expiry_date'] = int(str(args[1]) + str(args[2]))
kwargs['cvv2'] = args[3]
request_params = {}
for param in request_params_specs:
if param in kwargs.iterkeys():
request_params[param] = kwargs[param]
elif param == "signature":
request_params[param] = ''
elif param == "currency":
request_params[param] = currency
elif param == "payment_systems":
request_params[param] = 'card'
elif param == "response_url":
request_params[param] = response_url
elif param == "merchant_id":
request_params[param] = merchant_id
elif param == "delayed":
request_params[param] = "n"
elif param == "order_desc":
request_params[param] = 'test' + randomStr(size=7, chars=string.digits)
elif param == "order_id":
request_params[param] = self.order_id
# for 3ds requests
elif param == "pares":
request_params[param] = TEST_PARES
elif param == "md":
request_params[param] = self.md
# any other parameters
elif request_params_specs[param]["type"] == "email":
request_params[param] = "test@fondy.eu"
elif request_params_specs[param]["type"] == "string":
request_params[param] = randomStr(
request_params_specs[param]["size"], param).encode('utf-8')
elif request_params_specs[param]["type"] == "url":
request_params[param] = "https://" + randomStr(
request_params_specs[param]["size"] - 12, param).encode('utf-8') + ".com"
elif request_params_specs[param]["type"] == "int":
request_params[param] = randomStr(request_params_specs[param]["size"], "",
string.digits)
elif request_params_specs[param]["type"] == "amount":
request_params[param] = randomStr(
5, "", string.digits)
elif request_params_specs[param]["type"] == "boolean":
request_params[param] = randomStr(
1, "", "YN")

self.request_params = request_params





функцию непосредственной HTTPS POST отправки данных на API:

Send request
    def send_request(self, content_type, url=None, data=None, protocol=False, **kwargs):
requests.packages.urllib3.disable_warnings()
print "*HTML* sending request"
print "*HTML* content_type=%r, url=%r, data=%r, kwargs=%r" % (content_type, url, data, kwargs)
if data is None:
data = self.request_params
if self.order_id == '':
data['order_id'] = 'test' + randomStr(
10, "", string.ascii_letters)
else:
data['order_id'] = self.order_id

data['signature'] = ""
data['signature'] = build_signature(self.request_params)
self.save_order_id_from_server(data['order_id'])
post_data = self.build_request(content_type, data)
print "*HTML* POSTREQUEST %s" % (post_data)
self.response = requests.post(
url, headers={'Content-Type': content_type}, data=post_data, verify=False).text
print "*HTML* POSTRESPONSE %s" % (self.response)
return self.response




также нам нужна функция для проверки ответа от API, которая сверит все полученные параметры с файлом спецификаций specifications_settings.py:



Verify response status
    def verify_response_status(self, spec, spec_dict, content_type, response=None, request_params=None,
status='approved'):
try:
if response == None:
response = self.response
print "*HTML* response %s" % (response)
if request_params == None:
if self.request_params:
request_params = self.request_params
print "*HTML* REq_par %s" % (request_params)
response_params_specs = getattr(
specifications_settings, spec)[spec_dict]
print "*HTML* REsponse_par_spec %s" % (response_params_specs)
errors_list = []
error = False
response_params = parse_response(self.response, content_type)
print "*HTML* REsp_par %s" % (response_params)
for param in response_params_specs:
if response_params[param] is not None:
if response_params_specs[param]["type"] == "string":
if len(response_params[param]) > response_params_specs[param]["size"]:
errors_list.append('Error: size of param ' + param + ' is ' + str(
len(response_params[param])) + ' but max is ' + str(
response_params_specs[param]["size"]))
error = True
elif response_params_specs[param]["type"] == "int":
if len(str(response_params[param])) > response_params_specs[param]["size"]:
errors_list.append('Error: size of param ' + param + ' is ' + str(
len(str(response_params[param]))) + ' but max is ' + str(
response_params_specs[param]["size"]))
error = True
if response_params[param] != "" and not str(response_params[param]).isdigit():
errors_list.append(
'Error: param ' + param + ' is not integer')
error = True
else:
errors_list.append('Error: param ' + param + ' is missing')
error = True
if request_params.get(param) is not None and request_params.get(
param) != "" and param != 'signature' and response_params.get(param) is not None:
if (response_params_specs[param]["type"] == "string" and request_params.get(
param) != response_params.get(
param)) or (
response_params_specs[param]["type"] == "amount" and int(
request_params.get(param)) != int(
response_params.get(param))):
request = 'request:' + str(request_params.get(param))
response = 'response:' + str(response_params.get(param))
order_id = 'order_id:' + \
str(response_params.get('order_id'))
errors_list.append(
'Error: param ' + param + ' is not equal in request and '
'response\n request=%s\n response=%s order_id=%s' % (
request, response, order_id))
error = True

if response_params_specs.get('signature') is not None:
params_sign = {param: response_params.get(param, "") for param in response_params_specs if
param != 'signature'}
params = collections.OrderedDict(sorted(response_params.items()))
params_sign['signature'] = build_signature(params_sign)
if params_sign['signature'] != params["signature"]:
errors_list.append('Error: signature invalid in response ')
error = True

if response_params.get('order_status') and response_params.get('order_status') != status:
errors_list.append('Error: invalid status in response ')
error = True
except Exception as e:
errors_list.append("final %s" % e.message)
error = True
finally:
if error:
raise Exception("*HTML* Errors:\n %s" % errors_list)
else:
print "*HTML* test passed OK"






и последнюю функцию сохранения ответа от API на шаге 1 для передачи параметров на шаг 2



Save md pareq and acs url for 3ds
    def save_order_id_from_server(self, order_id):
self.order_id = order_id
print "*HTML* Order_id %s" % (self.order_id)






Теперь на базе этих функций мы можем построить тестовый сценарий pay_with_3ds_card.robot



*** Settings ***
Documentation A test suite containing tests related to server-server complete purchase with 3ds card.

Test Template Server-server full purchase with 3ds card Should Pass
Test Timeout 15 seconds
Default Tags smoke 3ds
Library DebugLibrary
Resource ../resource.robot

*** Variables ***
${specificatons} PAY_SERVER2SERVER_3DS
${req_dict_step1} request_step1
${resp_dict_step1} response_3ds
${url_step1} https://${API SERVER}/api/3dsecure_step1/
${req_dict_step2} request_step2
${resp_dict_step2} response_final
${url_step2} https://${API SERVER}/api/3dsecure_step2/

***Test Cases *** merchant_id currency content_type credit_card
USD_JSON_Approved ${TestMerchant} USD ${JSON} @{3dsApproved}
USD_XML_Approved ${TestMerchant} USD ${XML} @{3dsApproved}
USD_FORM_Approved ${TestMerchant} USD ${FORM} @{3dsApproved}
UAH_JSON_Approved ${TestMerchant} UAH ${JSON} @{3dsApproved}
UAH_XML_Approved ${TestMerchant} UAH ${XML} @{3dsApproved}
UAH_FORM_Approved ${TestMerchant} UAH ${FORM} @{3dsApproved}
EUR_JSON_Approved ${TestMerchant} EUR ${JSON} @{3dsApproved}
EUR_XML_Approved ${TestMerchant} EUR ${XML} @{3dsApproved}
EUR_FORM_Approved ${TestMerchant} EUR ${FORM} @{3dsApproved}
RUB_JSON_Approved ${TestMerchant} RUB ${JSON} @{3dsApproved}
RUB_XML_Approved ${TestMerchant} RUB ${XML} @{3dsApproved}
RUB_FORM_Approved ${TestMerchant} RUB ${FORM} @{3dsApproved}
GBP_JSON_Approved ${TestMerchant} GBP ${JSON} @{3dsApproved}
GBP_XML_Approved ${TestMerchant} GBP ${XML} @{3dsApproved}
GBP_FORM_Approved ${TestMerchant} GBP ${FORM} @{3dsApproved}

*** Keywords ***
Server-server full purchase with 3ds card Should Pass
[Arguments] ${merchant_id} ${currency} ${content_type} @{credit_card}
Build required parameters dict ${merchant_id} ${currency} ${specificatons} ${req_dict_step1} @{credit_card}
Send request ${content_type} ${url_step1}
Verify response status ${specificatons} ${resp_dict_step1} ${content_type}
Save md pareq and acs url for 3ds ${content_type}
Build required parameters dict ${merchant_id} ${currency} ${specificatons} ${req_dict_step2}
Send request ${content_type} ${url_step2}
Verify response status ${specificatons} ${resp_dict_step2} ${content_type}




Данный человекочитаемый сценарий будет тестировать все 3 поддерживаемые форматы запросов JSON, XML, FORM для 5-ти разных валют: USD, UAH, EUR, RUB, GBP



Запускаем тесты в virtualenv:

(tests) E:\work\fondy\auto_tests>pybot  server-server-tests






Разработка: автотесты c браузером и Telegram





Теперь добавим файл робота, в котором пропишем все HTML элементы, с которыми мы будем работать: заполнять или анализировать

ui_repository.robot

*** Settings ***
Documentation Variables used in all tests. Imported one time in resource.txt

*** Variables ***
# Checkout page
${CHECKOUT_BUTTON} css=.btn-lime
${CVV2} id=cvv2
${EXPIRE_YEAR} id=expire_year
${EXPIRE_MONTH} id=expire_month
${CARD_NUMBER} name=card_number
${CARD_NUMBER_FIELD} id=credit_card_number
${3DS_SUBMIT_BUTTON} xpath=//button[@type='submit']

#Response page
${ORDER_STATUS} css=.field_order_status .value
${TABLE_RESPONSE} id=table_response





в файл resource.robot у нас добавится библиотека Selenium2Library и функция открытия браузера

*** Settings ***
Documentation A resource file with reusable keywords.

Resource variables.robot
Resource cards.robot
Resource merchants.robot
Resource ui_repository.robot
Library Selenium2Library
Library helper/utils.py
Library requester.py

*** Keywords ***
Open Browser For Empty Page
[Arguments]
Open Browser about :blank
Maximize Browser Window




В файл variables.robot добавим название браузера: FireFox



*** Settings ***
Documentation Variables used in all tests. Imported one time in resource.robot

*** Variables ***
${API SERVER} api.fondy.eu
${RESP_URL} https://${API SERVER}/test/responsepage/
${SERVER} fondy.eu
${BROWSER} FireFox
${JSON} application/json
${XML} application/xml
${FORM} application/x-www-form-urlencoded




Файл спецификаций теперь пополнился новым набором параметров из документации https://www.fondy.eu/ru/info/api/v1.0/3

Эти спецификации отличаются тем, что реквизиты карты передает не торговец, а они вводятся на стороне платежного шлюза, после редиректа с сайта торговца:

specifications_settings.py
# -*- coding: utf-8 -*-

PURCHASE_FIELDS_REDIRECT = {
"request": {
"order_id": {
"type": "string",
"required": True,
"size": 1024
},
"merchant_id": {
"type": "int",
"required": True,
"size": 12
},
"order_desc": {
"type": "string",
"required": True,
"size": 1024
},
"signature": {
"type": "string",
"required": True,
"size": 40
},
"amount": {
"type": "amount",
"required": True,
"size": 12
},
"currency": {
"type": "string",
"required": True,
"size": 3
},
"version": {
"default": "1.0",
"type": "string",
"required": False,
"size": 10
},
"response_url": {
"type": "url",
"required": False,
"size": 2048
},
"server_callback_url": {
"type": "url",
"required": False,
"size": 2048
},
"payment_systems": {
"type": "string",
"required": False,
"size": 1024
},
"default_payment_system": {
"type": "string",
"required": False,
"size": 25
},
"lifetime": {
"default": "36000",
"type": "int",
"required": False,
"size": 6
},
"merchant_data": {
"type": "string",
"required": False,
"size": 2048
},
"preauth": {
"default": False,
"type": "boolean",
"required": False
},
"sender_email": {
"type": "string",
"required": False,
"size": 50
},
"delayed": {
"default": True,
"type": "boolean",
"required": False
},
"lang": {
"type": "string",
"required": False,
"size": 2
},
"product_id": {
"type": "string",
"required": False,
"size": 1024
},
"required_rectoken": {
"default": False,
"type": "boolean",
"required": False
},
"verification": {
"default": False,
"type": "boolean",
"required": False
},
"verification_type": {
"default": "amount",
"type": "string",
"required": False,
"size": 25
},
"rectoken": {
"type": "string",
"required": False,
"size": 40
},
"receiver_rectoken": {
"type": "string",
"required": False,
"size": 40
},
"design_id": {
"type": "string",
"required": False,
"size": 6
},
"subscription": {
"default": False,
"type": "boolean",
"required": False
},
"subscription_callback_url": {
"type": "url",
"required": False,
"size": 2048
}
},
"response": PAY_SERVER2SERVER_3DS['response_final'],
}






Детально описывать все файлы тестовых сценариев не буду, в них довольно легко разобраться, приведу только один

pay_with_checkout_url_3ds_approved.robot

pay_with_checkout_url_3ds_approved.robot
*** Settings ***
Documentation A test suite containing tests related to recurring api transactions with token.
... Card with 3ds.

Suite Setup Open Browser For Empty Page
Suite Teardown Close Browser
Default Tags 3ds approved
Test Template Checkout With 3ds Should Pass
Resource checkout_resources.robot



*** Variables ***
${specificatons} PURCHASE_FIELDS_REDIRECT
${req_dict_step1} request
${resp_dict_step1} response
${url} https://${API SERVER}/api/checkout/url/
${checkout_url} ${EMPTY}

***Test Cases*** currency merchant_id message content_type credit_card
USD_JSON_Approved USD ${TestMerchant} approved ${JSON} @{3dsApproved}
USD_XML_Approved USD ${TestMerchant} approved ${XML} @{3dsApproved}
USD_FORM_Approved USD ${TestMerchant} approved ${FORM} @{3dsApproved}
UAH_JSON_Approved UAH ${TestMerchant} approved ${JSON} @{3dsApproved}
UAH_XML_Approved UAH ${TestMerchant} approved ${XML} @{3dsApproved}
UAH_FORM_Approved UAH ${TestMerchant} approved ${FORM} @{3dsApproved}
EUR_JSON_Approved EUR ${TestMerchant} approved ${JSON} @{3dsApproved}
EUR_XML_Approved EUR ${TestMerchant} approved ${XML} @{3dsApproved}
EUR_FORM_Approved EUR ${TestMerchant} approved ${FORM} @{3dsApproved}
RUB_JSON_Approved RUB ${TestMerchant} approved ${JSON} @{3dsApproved}
RUB_XML_Approved RUB ${TestMerchant} approved ${XML} @{3dsApproved}
RUB_FORM_Approved RUB ${TestMerchant} approved ${FORM} @{3dsApproved}
GBP_JSON_Approved GBP ${TestMerchant} approved ${JSON} @{3dsApproved}
GBP_XML_Approved GBP ${TestMerchant} approved ${XML} @{3dsApproved}
GBP_FORM_Approved GBP ${TestMerchant} approved ${FORM} @{3dsApproved}
*** Keywords ***
Checkout With 3ds Should Pass
[Arguments] ${currency} ${merchant_id} ${message} ${content_type} @{credit_card}
Get and set checkout url ${merchant_id} ${currency} ${specificatons} ${req_dict_step1} ${RESP_URL} ${content_type} ${url} @{credit_card}
Go to ${checkout_url}
Input and submit checkout ${merchant_id} @{credit_card}
Confirm 3ds ${merchant_id}
Response page should be displayed
Check transaction status ${message}







Для отправки результатов в Telegram нам понадобятся 2 файла: listener и sender

PythonListener.py
from telegram_sender import *


class PythonListener(object):
ROBOT_LIBRARY_SCOPE = "GLOBAL"
ROBOT_LISTENER_API_VERSION = 2

def __init__(self, count=0):
self.ROBOT_LIBRARY_LISTENER = self
self.count = count
self.stat = None

def end_suite(self, name, attrs):
self.stat = attrs['statistics']
return self.stat

def log_file(self, path):
print self.stat
test = Telegram()
test.telegram_article(self.stat)







telegram_sender.py
import telegram
from helper._settings import *
from telegram.ext import Updater


class Telegram(object):
def __init__(self, token=None):
self.token = token or default_token
self.updater = None
self.bot = None

def update_bot(self):
self.updater = Updater(token=self.token)
self.bot = telegram.Bot(token=self.token)
self.updater.start_polling()
self.bot.getMe()
self.bot.getUpdates()

def telegram_article(self, status):
self.update_bot()
# chat_id = bot.getUpdates()[-1].message.chat_id # add this string to update all telegram users
chat_id = default_user
self.bot.sendMessage(chat_id=chat_id, text=status)
self.updater.stop()





Также пропишем в _settings.py параметры для Telegram бота

default_token = None # Put Your bot token to this variable
default_user = None # Add user chat id


как получить токен и id чата можно прочитать например тут и тут:



Теперь собственно запускаем браузерные тесты. Результат должен прийти в телеграм:



(tests) E:\work\fondy\auto_tests>pybot --listener PythonListener.py checkout-tests






Послесловие





Надеюсь эта статья будет полезна как автотестеровщикам, так и разработчикам. В следующей статье я постараюсь рассказать о том, что делать если тестов уже несколько тысяч — как их расспараллелить, как собрать метрики о скорости работы тестов, как разработать тесты, взаимодействующие с базой данных
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/302736/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Очередное крупное мошенничество с использованием платежных карт

Вторник, 07 Июня 2016 г. 18:16 (ссылка)

В статье ноября 2015-го была описана ситуация с относительно новым видом мошенничества, с помощью которого преступники похищали деньги с банковских счетов: Хакеры изобрели новую схему воровства денег, украв 250 млн. рублей. Как именно происходило мошенничество, кратко:



Преступник получал платёжную карту, пополнял её и тут же снимал внесённые деньги в банкомате, запрашивая чек. Далее данные о транзакциях отправлялись сообщнику, который имел доступ к зараженным POS-терминалам. Через терминалы, по коду операции, формировалась отмена снятия наличных. В результате баланс карты мгновенно восстанавливался и у злоумышленника появлялись «отменённые» деньги на счету. Преступники повторяли эти действия многократно, пока в банкоматах не заканчивалась наличка, модифицируя свою схему после исправления банками ошибки. Тогда было открыто несколько судебных дел в отношении виновных, «денежные мулы» были из Лондона, Украины, Латвии и Литвы.



Однако сейчас появилась новость об очень похожей ситуации, включающая и названия пострадавших компаний. Сумма ущерба на этот раз почти в два раза больше — около полумиллиарда рублей.



image





ПАО «Банк «Кузнецкий»
ПАО «Банк «Кузнецкий» — небольшой по размеру активов региональный банк, единственная кредитная организация, зарегистрированная в Пензенской области. Ключевые направления деятельности — обслуживание и кредитование корпоративных клиентов, привлечение средств населения во вклады и кредитование частных лиц. Основной источник финансирования деятельности банка — вклады физических лиц (55,7%). Сеть банка представлена головным офисом в Пензе, 20 дополнительными офисами, четырьмя операционными кассами вне кассового узла и тремя операционными офисами. Вся сеть банка, кроме двух операционных офисов в Самаре и Республике Чувашия, расположена и действует в Пензенской области. Численность персонала банка на 1 апреля 2016 года составляла 350 человек. Сеть собственных устройств насчитывает 45 банкоматов и 114 терминалов. Информация с Banki.ru.





В августе 2015-го мошенники или их сообщники, используя карты MasterCard, которые были выпущены банком «Кузнецкий», сняли из банкоматов других банков 470 млн руб. Мошенники использовали платежную систему ОРС, в которую тогда входило более 200 банков и которая позволяла снимать наличные по более низким тарифам. UCS же является операционным и платежным клиринговым центром ОРС.



Обычно мошенники делают по 5-10 подходов к банкомату, каждый раз снимая максимально возможную сумму (200 000 руб., 40 купюр номиналом 5000 руб.). Особенность данного случая в том, что за сутки было сделано более 3 000 таких операций, а общая сумма достигла почти 470 млн руб. Судя по сумме и количеству операций, мошенникам пришлось за короткий срок опустошить более 200 банкоматов, принадлежащих разным банкам. Вручную выполнить такое количество операций отмены платежа невозможно даже физически, так что можно уверенно утверждать, что действовал не сотрудник, а хакеры, которые предварительно получили доступ к инфраструктуре банка.



Ситуация очень похожа с описанной ранее, это атака «отмена транзакции»: мошенник, используя карту банка-эмитента, снимает наличные в банкомате. Сразу после этого сообщник мошенника направляет в платежную систему требование об отмене операции. «Из-за отмены операции сумма на карточном счете не изменяется, так что мошенники могут повторять эту двухходовку снова и снова, пока не надоест», – говорит директор по методологии и стандартизации Positive Technologies Дмитрий Кузнецов – При этом у эмитента возникнет долг перед эквайером на сумму, равную сумме снятой наличности».



Когда мошенники сняли первую сотню тысяч рублей, остаток, имеющийся на корсчете эмитента, уменьшился на эту сумму, а после отмены операции восстановился, хотя у эмитента возникла фактическая задолженность перед эквайером на сотню тысяч. С каждой следующей мошеннической операцией остаток на корреспондентском счете то уменьшался, то восстанавливался.



Суд указал, что транзакции в платежной системе ОРС осуществляются в соответствии с правилами MasterCard, а, согласно им, право на отмену операции в режиме реального времени имеет только банк-эквайер (т. е. владелец банкомата), а банк-эмитент (в нашем случае «Кузнецкий») мог отменить операцию только по истечении семи календарных дней. Но ответчик UCS, несмотря на это, провел операцию отмены от имени «Кузнецкого».



«По нашим сведениям, по возбужденным уголовным делам проводятся следственные действия, которые еще не завершены», – говорит представитель НКО «ОРС».

По неподтверждённой информации, первые задержания по этому делу прошли еще осенью.



Из материалов следует, что ОРС сразу после инцидента заплатила банкам, из чьих банкоматов украли деньги, 470 млн руб., а иск к UCS был подан 2 ноября 2015 г. По словам человека, близкого к одной из сторон, «Кузнецкий» не мог компенсировать банкам ущерб, поскольку у него не было таких средств, для ОРС это был больше вопрос репутации.



Компенсировать причиненный вред должен преступник. Если хакеров не поймают, то компенсировать вред некому. Если их поймают, то таких денег у них все равно уже нет, — рассуждает Дмитрий Кузнецов — Ущерб возмещает тот, кто по итогам судебных разбирательств оказался «сильнее неправ».



Итого: суд Москвы взыскал с процессинговой компании UCS 470 млн руб., посчитав, что по её вине мошенники похитили у банка «Кузнецкий» данные средства, потому как UCS нарушила условия договора.



По материалам Habrahabr, Ведомости.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/302836/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Хаордическая организация Visa (Часть 3)

Четверг, 02 Июня 2016 г. 12:28 (ссылка)





В какой бы стране ни оказался сегодня, перед какой бы аудиторией ни выступал, если я покажу кредитную карту NBA и спрошу: «Кто из вас знает, что это такое?» — в ответ поднимется лес рук. Но стоит мне спросить: «А скажите-ка мне, кто владеет NBA, кто ею управляет и где можно купить ее акции?» — как в зале наступит гробовая тишина. Все чувствуют, что речь идет о чем-то необычном, да только не могут выразить словами, что и как. В этом нет ничего удивительного. Результаты деятельности хаордической организации всегда на виду, а вот ее структура, управление и процессы скрыты



Ди Хок




Уважаемые читатели, мы продолжаем цикл статей об истории зарождения самой крупной финансовой организации в мире — Visa. Как и в предыдущей части, цитаты из книги Ди Хока “One from Many: VISA and the Rise of Chaordic Organization” выделены курсивом. Важные цитаты выделены жирным шрифтом. Эти моменты мы и обсудим в 4-ой заключительной части.



<<Хаордическая организация Visa (Часть 2)

Читать дальше →

https://habrahabr.ru/post/302456/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Первые слова крупных проектов

Вторник, 24 Мая 2016 г. 10:11 (ссылка)






Большое дело начинается с малого шага. Какой-то студент из Питера смастерил веб-сайт на коленке. Никому не известный энтузиаст из Финляндии прислал анонс в тематическую эхо-конференцию по Minix. Кто может предположить, к чему это приведёт?



Спустя много лет интересно взглянуть, как начинались некоторые популярные ИТ-проекты.

Читать дальше →

https://habrahabr.ru/post/301496/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Преступники, заражавшие банкоматы вирусом, пойманы на горячем

Четверг, 19 Мая 2016 г. 13:30 (ссылка)


В Киеве обезврежена преступная группировка, которая специализировалось на тайном проникновении в сервисные части банкоматов и дальнейшего заражения вредоносным программным кодом операционной системы банкоматов, что приводило к несанкционированной выдачи средств. Украинским банкам был нанесён ущерб в размере более 5 миллионов гривен, а аналогичные случаи заражения банкоматов имели место на территории Львовской и других областей Украины.





Читать дальше →

https://habrahabr.ru/post/301196/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<платежные системы - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda