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


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

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

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

Снова массовые взломы банкоматов: теперь Бангкок (Таиланд)

Пятница, 26 Августа 2016 г. 10:19 (ссылка)

В январе этого года преступники, которые опустошали банкоматы без использования пластиковой карты, были задержаны в Румынии и Молдове, в мае — в Киеве (фото и видео).

А ещё в мае из 1400 банкоматов в Японии было украдено более 12,7 миллионов долларов, хотя это совсем другая история.



Мошенничество в банкоматах по снятию наличных без использования пластиковых карт набрало серьёзные обороты, задержание части преступников не останавливает взломы по всему миру, и теперь история повторяется. На этот раз в Таиланде.





(источник: Xakep.ru)







Тайвань. В июне этого года глава Bank of Taiwan сообщил, что неизвестные лица атаковали определённые банкоматы, а именно банкоматы Wincor Nixdorf, которых на Тайване около 5 000. Преступники просто подходили к банкоматам, совершали определённые действия, после чего банкоматы выдавали наличные, которые злоумышленники тут же складывали в свои рюкзаки. Всего преступным путём в 34 банкоматах было получено около двух миллионов долларов США.



По подозрению в причастности власти Тайваня арестовали граждан Латвии, Румынии и Молдавии, однако другим подозреваемым (в том числе пяти гражданам России) удалось скрыться. Позже задержанные сообщили, что их группировка состояла из 38 человек.





Теперь о похожем ограблении сообщает и полиция Бангкока (Таиланд). С 1 по 8 августа неизвестные атаковали 21 банкомат Government Savings Bank (GBS) и сняли более 12 млн бат (порядка $346 000). Записи с камер наблюдения указывают на то, что грабители являются иностранцами из Восточной Европы.



Представители банка предупредили, что в этот раз были атакованы банкоматы NCR, и уверены, что злоумышленники используют некий баг или малварь, которая компрометирует банкоматы данного производителя. Всего в стране насчитывается более 10 000 банкоматов NCR, из них около 7 000 принадлежат GBS. В итоге банк, несмотря на то, что взлому подверглись только два десятка устройств, решил перестраховаться, и приостановил работу 3 300 своих банкоматов, оставив работать только те, которые расположены в безопасных охраняемых местах (например, в отделениях банка).



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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308576/

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

Токенизация в России: Как будет работать «безопасная» технология бесконтактных платежей от Visa и Mastercard

Пятница, 12 Августа 2016 г. 14:08 (ссылка)





/ фото Robert Scoble CC



К концу 2016 года в России должны заработать платежные мобильные приложения Apple Pay, Samsung Pay и Android Pay на основе бесконтактной технологии. Это станет возможно, после того, как Visa и Mastercard совместно с Национальной системой платежных карт внедрят в стране сервис токенизации, рассказали «Ведомости». Мы решили чуть подробнее разобраться, что это за система, как она работает и какой от нее, в конечном итоге, прок.



Что это такое



Начнем с терминов. В статье по ссылке суть технологии объяснена не очень доходчиво. Да, есть некий ссылочный номер (токен), по которому сервис продавца идентифицирует клиента и запускает перевод денег. В своей основе токен – это нечто с очень низкой стоимостью, заменяющее нечто с высокой стоимостью. Точно также как фишка в казино обозначает наличность, пишет в блоге The Sequent Каушик Рой.



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



Конечного пользователя волнует, по сути, лишь удобство при проведении расчетов и сохранность средств на банковском счете. Но изначально токенизация была заточена под развивающийся взрывными темпами рынок мобильной коммерции. В 2014 году, когда платежные сервисы начали активно внедрять новую технологию, аналитики из eMarketer предсказывали рост этого сегмента электронной коммерции на треть в 2015 году. Goldman Sachs прогнозировал увеличение его объема до $626 млрд. к 2018 году.



Рост рынка сдерживался лишь недоверием клиентов мобильным платежным системам. В ответ на этот запрос объединение EMV (Europay, Visa и Mastercard) выработало в начале 2014 года свой технический стандарт.



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



Вот как суть токенизации объясняется в блоге API-разработчика Джея Манчиокки на Mashery: «Токенизация включает в себя процесс замены «чувствительных» финансовых элементов данных их цифровыми и «не чувствительными» эквивалентами (токенами), которые сами по себе не имеют никакой ценности и не могут быть использованы злоумышленниками. Токены могут создаваться через математические формулы или через буквенно-цифровые случайные генераторы. Они призваны защитить любую персональную информацию, любые финансовые операции, включая торговлю на бирже».



Вместо того, чтобы передавать финансовые данные напрямую, мобильные платежные платформы будут использовать токены для подтверждения платежа. Поскольку процесс генерации токенов, как и сами они, не содержит никакой актуальной финансовой информации, считается, что такой способ оплаты в m-commerce на настоящий момент самый надежный. Обратный инжиниринг токена, к примеру, в PAN невозможен, утверждает автор блога Securosis.



Как все это работает на самом деле? Когда вы водите информацию о своей банковской карте на сайте продавца, она направляется на защищенный сетевой шлюз и специальное считывающее устройство, которое создает токен, чтобы провести транзакцию. Если сайт продавца взломан, эта информация будет для взломщиков бесполезной: никаких реальных данных о карте на нем нет. Вся оригинальная информация обитает в защищенном хранилище данных. Грубо говоря, в «облаке».



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



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



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



Насколько все эти плюсы новой технологии и уверения ее провайдеров в полной защищенности соответствуют реальности, российские пользователи смогут узнать уже совсем скоро.



Статьи и ссылки от ITinvest по теме:




Original source: habrahabr.ru.

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

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

Бесконтактные платежи – на пути к доверию потребителей и разработчиков

Понедельник, 01 Августа 2016 г. 12:17 (ссылка)

Бесконтактные технологии постепенно становятся важной частью современной жизни – как для компаний, так и для рядовых пользователей. За последние несколько лет, например, мы могли наблюдать, как компании, работающие на рынке пассажирских перевозок, прошли путь от внедрения своих собственных систем на базе бесконтактных платежных карт, до принятия моментальных платежей через банковские карты с поддержкой бесконтактных технологий, а в последнее время – и вовсе стали поддерживать оплату через сотовые телефоны и носимые устройства с поддержкой NFC, такие как Apple Watch. И если раньше бесконтактные терминалы были для нас скорее в диковинку, то сейчас мы видим их практически каждый день. Сегодня и компании из других отраслей начинают изучать, какие возможности открывают им бесконтактные технологии в их секторе.



За последнее время было проведено множество исследований потребительского мнения и уровня проникновения бесконтактных решений, и, хотя изначально уровень доверия к этой технологии был весьма невысоким, по мере того, как пользователи осознали преимущества бесконтактных платежей и доступность этой технологии увеличилась, вырос и уровень доверия к ней. Вырос настолько, что в этом году крупнейшие банки Великобритании увеличили максимальный лимит для бесконтактных транзакций с 20 до 30 фунтов стерлингов (немного, но нам сейчас важна динамика).





Если с точки зрения потребителя картина более или менее понятна, то обсуждения мнения компаний или их опыта работы с бесконтактными технологиями в прессе не так много. Учитывая то, что по прогнозам экспертов, в результате запуска Apple Pay объём бесконтактных платежей, осуществляемых через мобильные цифровые кошельки, к концу 2016 года достигнет 200 млн. фунтов стерлингов, сейчас самое подходящее время обсудить, что вынуждает, или наоборот, сдерживает компании при внедрении этих решений, и каким образом можно преодолеть связанные с этим сложности. Именно такой была цель нашего исследования "Contactless Business: The State of Play" ("Технологии бесконтактных платежей: положение дел"), в котором рассмотрен уровень проникновения бесконтактных платежей, отношение и планы по развёртыванию этих технологий у компаний из Великобритании, Германии и Испании. Россия пока отстает в применении технологии, но опыт лидеров может быть показателен для прогнозирования будущего.



Исследование было проведено в октябре 2015 года среди 240 руководителей компаний в Великобритании (80), Германии (80) и Испании (80). Распределение по отраслям было следующим: банковский сектор (90), розничная торговля (83), телекоммуникации (34) и транспорт (33). Были опрошены как частные, так и государственные компании – авиалинии, службы такси и т.д. – со штатом сотрудников более 250 человек.



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




  • Уровень проникновения бесконтактных технологий весьма высок и в целом картина в Европе весьма единообразна. Лишь очень немногие компании (8%) пока еще не запустили поддержку бесконтактных платежей, и среди респондентов не было ни одной компании, где не планировали бы в ближайшее время реализовывать подобный проект.

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

  • Бесконтактные технологии будут следующим образом распределены по различным группам: наиболее востребованными среди компаний являются бесконтактные платёжные карты (52%), следующими по популярности идут мобильные платежи (50%), платежи с помощью носимых устройств (43%) и бесконтактные карты магазинов/карты лояльности(42%). Новые виды платежей будут активнее всего развиваться в Великобритании, где 61% и 46% компаний ожидают внедрения, соответственно, бесконтактных платежных решений и платежных решений с помощью носимых устройств.

  • Компании Великобритании намерены больше инвестировать в бесконтактные технологии, чем их коллеги из Германии или Испании, при этом в вертикальных рынках лидерами по внедрению бесконтактных технологий являются банки.

  • Основным фактором роста для инвестиций в бесконтактные технологии является увеличение скорости обработки платежей (для 74% компаний). В числе других важных факторов – возможность обрести имидж новатора (43%), повышение эффективности затрат (42%) и возможность дифференцировать своё предложение от конкурентов (33%). Для потребителей наиболее важным фактором является повышение удобства (47%), более высокая степень удовлетворённости (43%) и упрощение процессов оплаты (43%).

  • Более половины компаний, намеревающихся внедрять бесконтактные технологии, предпочтут работать с партнёрами. Среди наиболее востребованных качеств, которые компании хотели бы видеть в своих партнёрах, – наличие решений, обеспечивающих высокий уровень безопасности (59%), хорошая репутация и наличие отраслевых компетенций (53%), а также удобная интеграция с другими решениями (51%).

  • Что касается планов развёртывания, то они различаются: 30% компаний намерены разрабатывать бесконтактные технологии под своим собственным брендом, 33% планируют делать это сотрудничестве с партнером, запускающим сервисы под своим брендом, и 22% планируют сотрудничать сразу с несколькими партнерами.



История успеха: реализация быстрой и безопасной оплаты покупок для болельщиков команды Saracens с помощью браслетов для бесконтактных платежей



Регбийный клуб Saracens, один из наиболее успешных клубов регбийного союза Великобритании, использует браслеты с предварительно внесённой на них суммой для организации более быстрой и удобной продажи снеков и напитков на своём стадионе Allianz Park. В рамках тестовых испытаний перед полномасштабным внедрением этого решения в сезоне 2015/2016, на интеллектуальные браслеты Gemalto было внесено по 5 фунтов стерлингов, поле чего браслеты были выданы болельщикам, чтобы они смогли оплачивать покупку напитков и закусок, просто дотронувшись браслетом до специального платежного терминала. Использование браслетов избавляет от необходимости искать нужные купюры и монеты, заметно ускоряет процедуру оплаты и способствует более оптимальному зрительскому опыту во время большой игры. Баланс браслета с легкостью пополняется в режиме реального времени, для этого достаточно просто привязать браслет к существующей кредитной или дебетовой банковской карте, после чего браслет использовать на всех оставшихся матчах сезона.





Перспективы использования бесконтактных платежей и инвестиции в новые технологии



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



Темпы восприятия бесконтактных технологий будут отличаться в зависимости от их форм-фактора. На графике показано, что в ближайшие три года более всего европейские компании рассчитывают увидеть новые проекты с использованием бесконтактных платежных карт (52% компаний), затем – проекты с применением мобильных платежей (50%), решения для оплаты с использованием носимых устройств (43%) и проекты с бесконтактными картами магазинов / картами лояльности (42%). Бесконтактный доступ с применением брелоков/карт (26%) и бесконтактные проездные билеты (5%) в ближайшие три года не будут столь популярными. Тем не менее, ожидается значительный рост числа проектов с применением новых форм-факторов. В частности, в ближайшие три года количество компаний, решивших реализовать проекты оплаты с помощью мобильных телефонов, увеличится на 28%, а количество тех, кто намерен внедрить решения для оплаты с помощью носимых устройств, вырастет на 39%.



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





История успеха: применение мобильных NFC технологий для продажи билетов на общественном транспорте



В системе общественного транспорта Мадрида был реализован пилотный проект, обеспечивающий удобный и защищенный механизм для проезда в метро и на городских автобусах с помощью NFC технологий. Компания Gemalto предоставила свои решения Allynis Trusted Service Manager (TSM) и UpTeq Multitenant SIM на базе технологии MIFARE DESFire, соответственно, для Консорциума общественного транспорта Мадрида (Consorcio Regional de Transportes de Madrid, CRTM) и для Telefonica, ведущего оператора мобильной связи в Испании. После этого, Муниципальная транспортная компания Мадрида (Empresa Municipal de Transportes de Madrid, EMT), внедрила решение Gemalto TSM в серверные системы CRTM.



Проект был реализован с целью продемонстрировать скорость и удобства новых технологий оплаты для конечных пользователей, а также многочисленные преимущества для поставщиков услуг. Чтобы воспользоваться этим сервисом, потребителям необходимо загрузить приложение, разработанное компанией Samsung, которое позволяет осуществлять покупку цифровых билетов. Новое решение выгодно и для CRTM, которое получило чрезвычайно эффективный канал продажи билетов, доступный для потребителей через их мобильные телефоны в режиме 7 дней в неделю, 24 часа в сутки. При этом уменьшаются задержки на турникетах, у которых часто образуются заторы, когда пассажиры пытаются найти в бумажнике нужную карту, в то время как в новом решении достаточно просто коснуться телефоном бесконтактного считывателя, которыми уже были оснащены турникеты в общественном транспорте Мадрида.





В общественном транспорте Москвы также реализована подобная схема продажи билетов с помощью мобильных телефонов, при которой пассажиры могут сесть на поезд, в трамвай или в автобус, просто прикоснувшись к терминалу оплаты телефоном, поддерживающим технологию NFC. Российские операторы мобильной связи "Мегафон" и "Вымпелком" сотрудничают с компанией Gemalto, которая предоставила SIM-карты UpTeq Multi-Tenant NFC, необходимые для осуществления этого проекта.



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





Факторы роста и преимущества



Все участники опроса показали четкое понимание того, почему и потребители, и организации готовы вкладывать средства в бесконтактные технологии и активно использовать их.



С точки зрения потребителей основные преимущества:




  1. Удобство

  2. Удовлетворение потребностей

  3. Простота применения



Основные преимущества с точки зрения бизнеса:




  1. Ускорение обработки платежей

  2. Улучшение имиджа (образ технологического лидера)

  3. Повышение эффективности затрат



Среди европейских компаний немецкие наименее оптимистичны и внедряют бесконтактные технологии, чтобы "не отставать от конкурентов".



Преодоление сложностей и сомнений



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



В целом, около четверти компаний (24%) в настоящее время считают, что технология бесконтактных платежей является исключительно защищенной, и ей можно полностью доверять, еще 52% считают технологию в целом безопасной, но при этом допускают, что она может быть защищена еще лучше.





Риски для потребителей



Помимо сложностей с точки зрения бизнеса, бесконтактные технологии несут в себе и определённые потенциальные риски для потребителей. В настоящее время по оценкам компаний примерно четверть их клиентов не доверяет бесконтактным платежным картам (28%), платежам с помощью мобильного телефона (25%) или носимых устройств (28%), несмотря на постоянно растущую прозрачность и популярность этих технологий. Таким образом, здесь действительно есть над чем работать. Статистические данные показывают, что британские потребители менее остальных доверяют платежам, осуществляемым с помощью носимых устройств (29% склонны не доверять такой технологии), тогда как и немцы, и испанцы меньше доверяют платежам с применением бесконтактных карт (им не доверяют, соответственно, 25% и 41% респондентов этих стран).





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



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



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



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





А что вы думаете о перспективах мобильных платежей, в частности, в России? Пользуетесь ли сами и предложили ли бы своим знакомым и партнерам?
















































Проголосовал 1 человек. Воздержавшихся нет.





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


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306844/

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

Почему в Украине всё таки есть белые хакеры

Пятница, 29 Июля 2016 г. 14:49 (ссылка)

Эта статья будет ответом на недавнюю публикацию Владимира Таратушка.

Причин написания статьи у меня было несколько.

Первая — это показать, что белые хакеры в Украине есть. Существуют они благодаря одной из программ поощрения поиска уязвимостей, которую проводит Приватбанк.

Следующая причина — это рассказать свою success story работы с одним из крупнейшим банком Украины в рамках данной программы.

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

Ну и последняя причина — показать будущим и настоящим ресёчерам, что участие в баг-баунти программах интересно, этично и материально выгодно.



Я не считаю себя профессиональным хакером, я не имею профильного образования в области безопасности, у меня нет сертификатов, я не читал талмуд спецификации TCP/IP протокола и я не участвовал в хакатонах и прочих соревнованиях профессиональных хакеров. В то же время у меня есть опыт программирования и написания различных веб-сервисов на PHP, Python, Java. И я примерно понимаю, где обычно программисты допускают ошибки и какие аспекты безопасности игнорируют при разработке веб-приложений. Для меня этого достаточно, что бы успешно находить уязвимости самого критичного уровня.



На данный момент мой опыт как ресёчера составляет 3 года. Именно столько времени я принимаю участие в программе поиска уязвимостей ПриватБанка.

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

И так, на данный момент у меня собрана статистика по 55 заявленным мною уязвимостям, все из которых на данный момент закрыты.

Согласно статистике по статусам заявок, картина следующая:





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

N/A — это значит, что по какой-то причине я не сохранил результатов по данной заявке.

Все заявки со статусом “принята” в итоге были закрыты и за них были выплачены вознаграждения.



Тип уязвимости/атаки по классификации OWASP







По классификации уязвимостей видно, что самый распространнёный тип — это Broken Access Control. Это те уязвимости, которые позволяют получить не авторизованный доступ простым перебором инкерментальных значений, которые задают id пользователя или операции. Причина в том, что такие уязвимости легче всего обнаружить и они являются следствием ошибок в архитектуре приложения. Так как банк — это сложная система многочисленных внутренних взаимодействующих друг с другом подсистем, таких как back-офис, процессинг, антифрод, это накладывает определённые трудности на реализацию взаимодействия веб-приложения с этими системами в рамках прав конечного пользователя сервиса. Это приводит к появлению таких уязвимостей, как доступ к выпискам по картам других пользователей, доступ к приватным данным и в конце концов, к доступу к финансовых средствам пользователей.

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



Тип получаемой информации или доступа в случае эксплуатации уязвимости:



Как видно по статистике, чаще всего удавалось получить доступ к приватным данным (ФИО, паспортные данные, номера карт, телефонов, адресов), финансовым данным (баланс счёта, выписки и тд.), аккаунтам в разных сервисах(как правило благодаря XSS или Open Redirect) и, что не маловажно, в 1 из 5 случаев доступ к финансовым средствам других пользователей.



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



Как видно, чаще всего оповещение приходило в пределах 2-х месяцев, но иногда по некоторым уязвимостям не было ответа по 3-4 месяца.



Ну и естественно, самый интересный момент для исследователей — это средний размер вознаграждения по закрытым заявкам. Сразу предупрежу, сумма вознаграждения не привязывалась к курсу доллара до середины 2015 года, поэтому какое-то время она уменьшалась в долларовом эквиваленте в связи со стремительным ростом курса доллара к гривне.



Как видно, чаще всего сумма вознаграждения попадает в диапазон $50-500



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

Таблица уязвимостей









































































































































































































































































































































































































Домен Тип уязвимости/атаки (OWASP) Тип доступа Краткое описание
1 privat24.privatbank.ua Broken Access Control Приватные данные Получение критичных данных любой карты
2 privat24.privatbank.ua Broken Access Control Приватные данные Доступ к архиву платежей пользователей
3 privat24.privatbank.ua Broken Access Control Приватные данные Доступ к приватным данным пользователей (ФИО, паспортные данные, сумма остатка и задолженности)
4 privat24.privatbank.ua Broken Access Control Приватные данные Доступ к приватным данным пользователей (ФИО, паспортные данные, девичья фамилия матери)
5 privat24.privatbank.ua Broken Access Control Финансовые данные Просмотр выписок по номеру карты
6 privat24.privatbank.ua Broken Access Control Финансовые операции Оплата sms рассылки с чужой карты
7 liqpay.com Broken Access Control Финансовые данные Данные по платежам клиентов
8 napi.privatbank.ua Broken Access Control Приватные данные Получение критичных данных чужой интернет карты
9 napi.privatbank.ua Broken Access Control Финансовые данные Покупка авто/жд билетов по чужой карте
10 privat24.privatbank.ua Broken Access Control Финансовые операции Создание регулярного платежа по чужой карте
11 pcalendar.privatbank.ua Broken Access Control Финансовые операции Изменение статуса любого регулярного платежа, пересоздание, даже если он был удален, просмотр данных по нему
12 siteheart.com Session Variable Overloading Доступ к аккаунту Полный доступ к любому аккаунту siteheart.com
13 privat24.privatbank.ua CSRF Приватные данные Подключение своего телефона к смс-информированию об операциях по чужой карте
14 privat24.privatbank.ua Broken Access Control Финансовые операции Создание регулярного платежа по чужой карте
15 cards.privatbank.ua XSS Доступ к аккаунту Кража куки авторизованного пользователя
16 privat24.privatbank.ua Broken Access Control Финансовые операции Массовое пополнение мобильных телефонов с чужой карты
17 ecommerce.liqpay.com Broken Access Control Финансовые операции Платеж с чужой карты при оплате услуг на сайте мерчанта, подключенного к ПриватБанку
18 privat24.privatbank.ua Broken Access Control Приватные данные Получение номеров телефонов, подключенных к услуге SMS-уведомления для любой карты ПриватБанка
19 privat24.privatbank.ua Broken Access Control Приватные данные Просмотр информации по коммунальным платежам клиентов приват24 (ФИО, адрес проживания, моб. телефон, задолженность)
20 pcalendar.privatbank.ua Broken Access Control Финансовые данные Баланс по любой карте ПриватБанка
21 pcalendar.privatbank.ua Broken Access Control Финансовые операции Создание регулярного платежа по чужой карте
22 pcalendar.privatbank.ua Broken Access Control Финансовые операции Создание регулярного платежа по чужой карте
23 privat24.privatbank.ua Insecure Configuration Серверные данные Открыта структура каталогов
24 privat24.privatbank.ua Broken Access Control Операция модификации Получение и изменение интернет-лимита по любой карте ПриватБанка
25 privat24.privatbank.ua Broken Access Control Финансовые данные Просмотр выписок по номеру карты, присутствуют адреса и gps координаты банкоматов и терминалов самообслуживания, которыми пользуется клиент
26 privat24.privatbank.ua Insecure Configuration Финансовые данные Доступны Google чеки
27 transfers.privatbank.ua Broken Access Control Финансовые данные Информация по переводам в приват24 (PrivatMoney, Золотая корона, Unistream, Western Union, Contact, Coinstar и Swift)
28 privat24.privatbank.ua Broken Access Control Финансовые операции Создание регулярного платежа по чужой карте
29 privat24.privatbank.ua Broken Access Control Приватные данные Просмотр информации по коммунальным платежам клиентов приват24 (ФИО, адрес проживания, моб. телефон, задолженность)
30 privat24.privatbank.ua Broken Access Control Финансовые данные Информация по заявкам на кредитный рейтинг в УБКИ (ФИО, ИНН, дата рождения, кредитный рейтинг и пр.)
31 client-bank.privatbank.ua Broken Access Control Финансовые данные Получение выписки по эквайрингу по любому мерчанту ПриватБанка
32 client-bank.privatbank.ua Broken Access Control Пароли Получение пароля любого мерчанта, зарегистрированного в приват24 в эквайринге. Помимо пароля доступен номер карты для приёма платежей, название клиента, адрес сайта клиента, ip адрес и пр.
33 limit.pb.ua Broken Authentication and Session Management Приватные данные Подробная информация по клиенту (ФИО, номера карт, телефонов, дата рождения, адреса проживания и т.д.)
34 privat24.privatbank.ua Broken Access Control Приватные данные Получение по номеру карты ФИО владельца, номера телефона, срока действия карты
35 socauth.privatbank.ua Insecure Configuration Приватные данные Подробная информация по клиенту (ФИО, номера карт, телефонов, дата рождения, адреса проживания и т.д.)
36 privat24.privatbank.ua Broken Authentication and Session Management Доступ к аккаунту Многократно вход в приват24 по сформированной ссылке без ввода статического и отп пароля даже после окончания действия сессии ользователя
37 chat.sender.mobi XSS Доступ к аккаунту Кража куки авторизованного пользователя
38 msb.privatbank.ua XSS Доступ к аккаунту Кража куки авторизованного пользователя
39 mypayments.privatbank.ua Broken Authentication and Session Management Приватные данные Подробная информация по клиенту (ФИО, номера карт, телефонов, дата рождения, адреса проживания и т.д.)
40 privat24.privatbank.ua Broken Authentication and Session Management Финансовые данные Выписки по картам пользователей.
41 liqpay.com Broken Authentication and Session Management Доступ к аккаунту Cлабая защита сессии пользователя при авторизации через звонок на мобильный телефон
42 client-bank.privatbank.ua Broken Access Control Финансовые данные Выписки по любому терминалу, подключенному к эквайрингу.
43 client-bank.privatbank.ua Broken Access Control Финансовые данные Просмотр документов юр. лиц, созданных при помощи конструктора документов
44 chat.sender.mobi XSS Доступ к аккаунту Кража куки авторизованного пользователя
45 bank24.privatbank.ua XSS Доступ к аккаунту Кража куки авторизованного пользователя
46 blago.privatbank.ua Broken Access Control Финансовые операции Уязвимость позволяет любому зарегистрированному пользователю подменить карту любого другого пользователя на свою для получения пожертвований
47 client-bank.privatbank.ua Broken Access Control Финансовые данные Информация по чужим договорам с зарубежными партнерами
48 client-bank.privatbank.ua Broken Access Control Приватные данные Информация о пользователях, имеющих доступ к указанному счёту, а именно логин(иногда это номер телефона), ФИО, email.
49 privat24.privatbank.ua Broken Access Control Операция модификации Массовое измение (как минимум уменьшение) кредитных лимитов по картам клиентов ПриватБанка
50 nkk.privatbank.ua Broken Access Control Приватные данные Доступ к информации, которую клиент заполняет при оформлении заявки на кредит
51 privat24.privatbank.ua Redirects and forwards Доступ к аккаунту Доступ к аккаунту пользователя через токен, полученный через Open Redirect
52 client-bank.privatbank.ua Broken Authentication and Session Management Доступ к аккаунту Доступ к аккаунту пользователя через токен, полученный через referer на сайте статистики
53 client-bank.privatbank.ua Redirects and forwards Доступ к аккаунту Доступ к аккаунту пользователя через фишинг, используя Open Redirect
54 client-bank.privatbank.ua Broken Authentication and Session Management Доступ к аккаунту Доступ к аккаунту пользователя через токен, полученный через referer на сайте статистики
55 client-bank.privatbank.ua Broken Access Control Финансовые данные Доступ к к договорам с зарубежными партнерами клиентов




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



Ну и напоследок, я хотел бы развеять стойкое, но ошибочное мнение многих, что с ПриватБанком лучше не работать, так как они могут обвинить в взломе, как это было описано в истории с Алексеем Моховым.

Главный принцип белого хакера — это этичность. Поиск уязвимостей должен проводиться исключительно на аккаунтах и счетах самих “взломщиков” либо их родственников/друзей/знакомых с их личного разрешения. Так же, если поиск уязвимости осуществлялся в рамках баг-баунти программы, раскрывать информацию о ней стоит только после её закрытия и только с разрешения владельца ресурса, на котором она была найдена. Тогда все ваши действия не будут осуществлять в ущерб компании и не будут нарушать закон, а поэтому претензий к вам, как к исследователю, не будет.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306694/

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

[Перевод] Последние тенденции в онлайн платежах

Вторник, 26 Июля 2016 г. 13:35 (ссылка)

image



В этой статье представлены последние тенденции в онлайн платежах, с точки зрения покупателя и продавца.



С точки зрения продавца



Рост доли альтернативных способов оплаты


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

Чаще всего эти альтернативные способы оплаты были разработаны местными игроками отрасли, которые учитывают местные условия рынка, а так же потребности покупателей. Эти методы часто основаны на уже существующей платежной инфраструктуре конкретной страны, на учете доступности банков и на платежной культуре( привычках). Например, бразильцы, которым не доступны услуги банков и которые не имеют доступа к онлайн-банку или кредитной карте, могут оплатить заказ через Интернет с помощью местного альтернативного метода Boleto.

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

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



Популярность электронных кошельков растет


Помимо альтернативных способов оплаты, все больший и больший оборот по всему миру набирают электронные кошельки. Часто они разрабатываются с ориентиром на мобильные устройства. Как растет популярность использования смартфонов и планшетов, с такой же прогрессией растет популярность электронных кошельков. Многие электронные кошельки (MasterPass, V.me от Visa, PayPal), были разработаны для более простого, быстрого и легкого выполнения платежей, сделанных через мобильные устройства.



Оптимизация конверсии


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

Кроме того, предлагая правильный набор методов оплаты, все больше и больше поставщиков услуг оплаты предоставляют платежные инструменты аналитики, которые позволяют интернетчикам усовершенствовать свои предложения по оплате или улучшить проверочные критерии. Например, продавцы могут принять решение затребовать 3D-secure аутентификацию, основанную на подтверждении личности держателя карты или транзакционных критериев (например, страна покупателя или стоимость заказа). Будучи в состоянии согласовывать способ оплаты заказа с покупателем и выполняя проверку рисков, продавцы смогут переложить бОльшую часть ответственности за оплату на покупателя.



Межбанковские комиссии снижаются


В США и в Европе взаимные комиссии для четвертой стороны при оплате, например, для MasterCard и Visa, были вытеснены регуляторами. Взаимные комиссии относятся к тем сборам, которые должны быть оплачены владельцем карты эмитенту для каждой обрабатываемой сделки. Эти сборы представляют собой значительную долю сборов за использование торговых точек, принимающих банковские карты, или торговую комиссию. Из-за возросшей конкуренции ожидается, что продавцы выиграют в результате более низких комиссионных ставок.

Усиление конкуренции между провайдерами платежных услуг и банками — эквайрерами

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



Универсальные магазины


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

Для многих продавцов это даже проще, поскольку они имеют дело только с агрегаторами. Нет необходимости контактировать с провайдерами платежных услуг и эквайерами.



С точки зрения покупателя



Восприятие покупателями процесса совершения покупок в цифровой реальности


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

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



Покупки и платежи при помощи мобильных устройств


Во всем мире доля смартфонов среди обычных мобильных телефонов стремительно растет. 9 миллиардов устройств по всему миру в настоящее время подключены к сети Интернет, в том числе компьютеры и смартфоны. И как ожидается, это число резко возрастет в течение следующего десятилетия от 50 млрд устройств до 1 трлн. Мобильные устройства все чаще используются в различных целей:




  • В магазине: поиск информации о продукте и сравнение цен в интернет-магазинах конкурентов




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




  • Мобильные устройства требуют различного взаимодействия с пользователями из-за меньшего экрана и иного способа ввода данных по сравнению со стационарным компьютером




  • Пользователи хотят использовать привычные им онлайн методы оплаты, адаптированные для мобильного устройства




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




  • Мобильные устройства обеспечат PoS терминалы более дешёвыми технологиями для принятия онлайн и офлайн платежей.





Электронные кошельки и приложения для телефона


Электронные кошельки предлагают услуги по оплате, хранение данных по оплате и личных данных пользователя. Цель электронных кошельков:




  • увеличение скорости оплаты и удобство для покупателей;




  • обеспечение продавцов конверсией и клиентами



В настоящее время существует огромное количество сервисов с электронными кошельками, предлагающих свои услуги для продавцов и покупателей, что привело к «войне электронных кошельков». В настоящее время рынок демонстрирует разнообразный охват, прием и поддержку каналов. Сузествуют интернет- и PoS-кошельки, а так же омниканальные кошельки. Электронные кошельки могут быть использованы в различных целях и с помощью множества устройств (стационарные ПК, планшеты, мобильные телефоны). Ожидается, что в будущем появятся многие дополнительные и усовершенствованные услуги. Примерами могут служить: MasterPass, V.me от Visa, PayPal



Процесс сближения каналов продаж


Поскольку опыт использования Интернета у населения продолжает расти, потребители по умолчанию при совершении покупки учитывают оба канала, как офлайн, так и онлайн. Помимо этого, у продавцов существует растущая возможность использовать эти же два канала, создавая омниканальный опыт продаж для покупателя. Нормой считается осуществить покупку онлайн, а затем забрать товар в офлайн магазине или пункте самовывоза. Так же покупатели очень ценят и довольно часто пользуются возможностью вернуть товар назад при заказе онлайн. Или же, например, покупатель мерил в магазине понравившуюся модель джинсов, а его размер закончился – тогда он может заказать нужный размер в интернет-магазине и получить товар уже у себя дома. Для потребителя эта тенденция означает, что нет больше различий между обычной покупкой, покупкой через интернет или покупкой с помощью мобильного телефона. Есть просто покупка. Платежи же индивидуальны для каждого отдельного заказа, в офлайне и онлайне они отличаются друг от друга.

Электронные кошельки пытаются предоставить возможность оплаты для потребителя, используя любые каналы и адаптируясь к ним.



Контроль личных данных покупателем


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



В качестве реакции на вышеперечисленные недостатки, возникла интересная тенденция превращения общедоступных данных в закрытые. Платформы Life Management и Personal Data Ecosystems предоставляют пользователям возможность сохранять полный контроль над своими личными данными и позволяют определить, какие данные с какой компанией совместимы. Особенно это важно для платежей, которые включают в себя конфиденциальные данные, и для них существует растущая потребность в безопасности. В свете этой тенденции мы видим как развиваются такие способы оплаты, как, например, Bitcoin.



С уважением команда фулфилмент-оператора «Ямбокс»

(мы занимаемся логистикой для e-commerce)






image
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306418/

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

Stripe: сервис вашей мечты для автоматизации денежных переводов

Понедельник, 25 Июля 2016 г. 15:05 (ссылка)

Имевшие дело с сервисом электронных платежей Stripe знают, что он отлично заточен под разработчиков. Его документация написана людьми для людей; есть хороший тестовый режим — полная копия реального, и для перехода на live-режим нужно только заменить ключи, не трогая API и не получая никаких сюрпризов; админка тестового режима — тоже полная копия боевого. В общем, Stripe — это хорошо, и я хочу посвятить эту статью базовым вопросам интеграции сервиса в e-Commerce-проект, объяснив процессы на конкретных и абстрактных примерах. Надеюсь, что мой опыт поможет всем, кто хочет попробовать Stripe на своём проекте.



Однако перед тем, как использовать Stripe, задайте вопрос: «А где находится бизнес, который мы будем обслуживать?». Например, если бизнес российский, Stripe для нас бесполезен: принимать платежи можно из любой страны, но бизнес владельца аккаунта на Stripe должен быть юридически зарегистрирован в одной из доступных стран. Иначе создать и авторизовать аккаунт невозможно. Список стран можно посмотреть здесь. Если вы хотите выводить деньги на другие счета, например, поставщикам (как это делать, я расскажу ниже), то юридически поставщики тоже должны находиться в странах, с которыми работает Stripe. Бизнес клиента, с которым работала я, зарегистрирован в Америке, что позволяло проводить платежи через Stripe.



Также нужно быть готовым, что Stripe не поддерживает xml-протокол 3-D-secure, который требует от клиента вводить код подтверждения, полученный в SMS-сообщении. Stripe просто пытается провести платеж без этой опции, и если банк принимает платежи без 3-D Secure — хорошо, если нет — всё закончится отказом, и с этой карты платить не получится.



Проведение платежа



Чтобы перевести деньги с карточки клиента на наш Stripe-аккаунт, нам нужно сделать следующее. С помощью скрипта Stripe.js получим на фронтенде Stripe token. Дальше мы будем использовать token с серверной стороны, чтобы провести сам платёж.



Подключаем Stripe.js и указываем публичный ключ:






Делаем обычную HTML-форму, на input указываем атрибуты data-stripe для работы скрипта. Нам будет нужен номер карты клиента, год и месяц валидности карты и CVC. Имя и фамилию владельца Stripe не требует.















Теперь получим token:



$(function() {
var $form = $('#payment-form');
$form.submit(function(event) {
// Отключим кнопку, чтобы предотвратить повторные клики
$form.find('.submit').prop('disabled', true);

// Запрашиваем token у Stripe
Stripe.card.createToken($form, stripeResponseHandler);

// Запретим форме submit
return false;
});
});

function stripeResponseHandler(status, response) {
// Grab the form:
var $form = $('#payment-form');

if (response.error) { // Problem!

// Показываем ошибки в форме:
$form.find('.payment-errors').text(response.error.message);
$form.find('.submit').prop('disabled', false); // Re-enable submission

} else { // Token был создан

// Получаем token id:
var token = response.id;

// Вставим token в форму, чтобы при submit он пришел на сервер:
$form.append($('').val(token));

// Сабмитим форму:
$form.get(0).submit();
}
};


На всякий случай: этот шаг описан в официальной документации.



Теперь мы можем списать деньги с клиента через сервер. Примеры кода на PHP.



// Устанавливаем секретный ключ 
\Stripe\Stripe::setApiKey("your_secret_key");

// Забираем token из формы
$token = $_POST['stripeToken'];

// Создаём оплату
try {
$charge = \Stripe\Charge::create(array(
"amount" => 1000, // сумма в центах
"currency" => "usd",
"source" => $token,
"description" => "Example charge"
));
} catch(\Stripe\Error\Card $e) {
// Платёж не прошёл
}


Это всё, что нужно сделать, чтобы перевести деньги с карты клиента на ваш Stripe счет.



Автоматические переводы денег вашим поставщикам



Теперь рассмотрим перевод на рабочем примере. Представим, что вы пишете платформу, которая продаёт редкие книги из маленьких издательств по всему миру. Вам нужно переводить деньги вашим поставщикам-издательствам, чтобы они выслали книгу клиенту, и брать себе комиссию 10$ c каждой продажи. Вы не хотите париться с ежемесячными отчётами и выплатами, вы хотите просто переводить деньги каждый раз, когда платит клиент. Stripe это позволяет.



Как и прежде, обязательное условие для настройки автоматических переводов — это нахождение поставщика в одной из стран, поддерживаемых Stripe.



У Stripe есть замечательная штука Managed Acсounts. С помощью этой опции мы как бы создаем Stripe-аккаунт для нашего поставщика, но берём на себя все заботы по управлению аккаунтом, так что самому издательству не нужно будет регистрироваться в Stripe.



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



Stripe.bankAccount.createToken({
country: $('.country').val(), // 2-хсимвольный код страны (US)
currency: $('.currency').val(), // 3-хсимвольный код валюты (USD)
routing_number: $('.routing-number').val(), // идентификационый номер банка
account_number: $('.account-number').val(), // номер банковского счёта
account_holder_name: $('.name').val(), // имя владельца бизнеса (в нашем примере — издательства)
account_holder_type: $('.account_holder_type').val() // тип аккаунта — идивидуальный предприниматель или компания (individual, company)
}, stripeResponseHandler);


Это тоже описано в документации.



Ремарка. Имейте в виду, что для каждой страны банковские данные (routing_number, account_number ) заполняются по-разному. Например, для европейских стран нужно получать IBAN-номер. Он кладётся в поле account_number, а routing_number не отпраляется вообще. Также для некоторых стран внутренние номера счетов склеиваются в одну строку и записываются в поля. Например, чтобы получить корректный идентификационный номер банка routing_number для Канады, надо склеить transit number и institution number (transit number + institution number). Если transit number: 02345, а institution number: 987, то routing_number будет ‘02345987’. Account number варьируется в зависимости от банка. А для Германии нужен будет только IBAN номер, он заполняется в поле routing_number. Например, IBAN: DE89370400440532013000 (22 символа). Как заполнять эти поля для остальных стран, можно посмотреть тут.



Итак, теперь у нас есть token банковского счёта, куда мы можем выводить деньги поставщикам. Давайте создадим Managed Account. Пусть наше издательство находится в Америке, является компанией, а не ИП, и мы платим ему в американских долларах.



\Stripe\Stripe::setApiKey("your_secret_key");
$account = Account::create([
"country" => 'US',
"managed" => true,
]);
if (isset($account->id)) {
try {
$account->external_accounts->create(
["external_account" => $token] // наш token банковского счета
);
} catch (InvalidRequest $error) {
// произошла ошибка создания
}
}


Казалось бы, теперь у нас есть Managed Account, и можно переводить деньги, но нет: аккаунт нужно верифицировать. Для этого нужно предоставить Stripe определённую юридическую информацию о компании. Какая именно информация нужна и в каких странах, описано здесь.



Итак, для издательства в Америке нам нужно предоставить:




































































legal_entity.address.city Город, в котором расположена компания
legal_entity.address.line1 Адрес компании
legal_entity.address.postal_code Почтовый индекс
legal_entity.address.state Штат
legal_entity.business_name Название компании
legal_entity.business_tax_id Налоговый идентификационный номер
legal_entity.dob.day День рождения владельца компании
legal_entity.dob.month Месяц рождения владельца компании
legal_entity.dob.year Год рождения владельца компании
legal_entity.first_name Имя владельца компании
legal_entity.last_name Фамилия владельца компании
legal_entity.ssn_last_4 Четыре последние цифры номера социального страхования владельца компании
legal_entity.type individual/company
tos_acceptance.date Дата принятия условий использования Stripe
tos_acceptance.ip IP-адрес, с которого происходило принятие условий использования Stripe


Условия использования Stripe здесь. Человек, от чьего имени будет создаваться Managed Account, должен их принять.



Также Stripe может потребовать дополнительную информацию. Для Америки это:
















legal_entity.personal_id_number Личный идентификационный номер
legal_entity.verification.document Скан документа, подтверждающего личность


Собираем необходимую информацию и редактируем аккаунт.



\Stripe\Stripe::setApiKey("your_secret_key");
$account = Account::retrieve($accountId);
$account->legal_entity->address->city = 'New-York';
$account->legal_entity->address->state = 'New-York';
$account->legal_entity->address->postal_code = '00501';
$account->legal_entity->address->line1 = 'Some address';
$account->legal_entity->business_name = 'US TEST';
$account->legal_entity->business_tax_id = '00000001';
$account->legal_entity->dob->day = 1;
$account->legal_entity->dob->month = 1;
$account->legal_entity->dob->year = 1980;
$account->legal_entity->first_name = 'Bob';
$account->legal_entity->last_name = 'Smith';
$account->legal_entity->type = 'company';
$account->legal_entity->ssn_last_4 = '0000';
$account->tos_acceptance->date = 1466074123; // timestamp
$account->tos_acceptance->ip = 123.123.123.123;
try {
$account->save();
} catch (InvalidRequest $error) {
// ошибка во время сохранения
}


Теперь команда Stripe всё проверит, и в админке мы увидим статус Verified.

https://dashboard.stripe.com/test/applications/users/overview



![image]()



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



image



Когда команда проверит данные, аккаунт будет обновлён. На это событие можно настроить webhook.



image



Необходимые поля будут описаны в объекте аккаунта:



$account->verification->fields_needed


Также Stripe может выставить дедлайн для предоставления данных. Если дата есть, она будет в свойстве $account->verification->due_by.



Для тестирования верификации Stripe предоставляет хорошую тестовую среду. С помощью переводов с определённых тестовых карт мы можем симулировать разные сценарии поведения верификации аккуантов. Примеры таких сценариев:




  • данные не заполнены, и мы вообще не можем совершать переводы;

  • сработал лимит на размер платежа. Это происходит, если Stripe считает, что перевод слишком большой, и предоставленной информации ему недостаточно. В этом случае он отключает Managed Account;

  • отключение аккаунта с требованием ввести данные к определенной дате;

  • загрузка скана документа, подтверждающего личность владельца аккаунта.

  • принятие и отклонение этого скана.



Как конкретно симулировать эти случаи, описано здесь.



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



Когда все окей, и Stripe верифицировал ваш Managed Account, нужно включить переводы (transfers) с помощью API или отключить автоматические — это одно и то же.

https://dashboard.stripe.com/account/transfers



Как конкретно симулировать эти случаи, описано здесь.



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



Когда все окей, и Stripe верифицировал ваш Managed Account, нужно включить переводы (transfers) с помощью API или отключить автоматические — это одно и то же.

https://dashboard.stripe.com/account/transfers



image



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



Предположим, у нас есть книга. Поставщик хочет за неё 50$, мы хотим 10$ долларов комиссии себе, плюс нам надо заложить в цену комиссию Stripe на перевод. Сейчас Stripe берёт за каждый перевод 2,9% + 30c. Мы решили, что оплатим комиссию из своей части. Тогда пользователю надо заплатить за книгу 60$. Из своей части мы отдадим 2,04$ комиссии Stripe.



Получаем token с помощью Stripe.js и проводим платёж со стороны сервера.



$charge = Charge::create([
"amount" => 6000, // в центах
"currency" => 'USD',
"source" => $token,
"application_fee" => 1000,
"destination" => $managedAccountId
]);


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



На банковский счёт поставщика деньги сразу не придут, они выводятся раз в семь дней. Т.е. мы переводим деньги на Stripe-аккаунт нашего поставщика, и по истечении семи дней они переводятся аккаунту на привязанный банковский счёт.



Дополнительные фичи



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



Желаю вам удачи в интеграции Stripe! Я буду рада вашим комментариям, вопросам и уточнениям, которые помогут дополнить статью.



Полезные ссылки:



Страны, которые поддерживают Stripe

Custom HTML form для получения token

Managed Acсounts

Получение token для банковского аккаунта

Необходимая банковская информация по странам

Необходимая юридическая информация для Managed Accounts по странам

Условия использования Stripe

Тестирование верификации аккуанта

Webhooks

Stripe Pricing

Stripe API Reference


Original source: habrahabr.ru.

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

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

[Перевод] Интервью с мамой, банковским программистом на COBOL'е

Среда, 20 Июля 2016 г. 16:09 (ссылка)



Фото из Гугла, это не мама автора



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



Объясню немного



Мир банковского программного обеспечения — это другая вселенная. Она сильно отличается от той, к которой привыкло большинство из нас. Я публикую этот пост на HN и на Reddit. Публикую интервью не в виде вопросов-ответов, а в виде рассказа. Я добавил некоторые вопросы и ответы в нижнюю часть поста.



1991



Год, когда она начала внутреннее обучение в банке Nordea, который тогда назывался Nordbanken (Северный банк). В 2001 году его переименовали в Nordea. Во время обучения она должна была проходить различные тесты, в первую очередь тест IQ, чтобы показать, что она обладает интеллектом, достаточным для работы в этой области. Тест на психологическую устойчивость — что у неё достаточно нервов для этой специфической работы и тест на многозадачность, который она завалила с оценкой 22/100. Остальные тесты она прошла успешно и заняла одну из 16 доступных позиций.



Должность звучала «как программист мэйнфреймов IBM на языке COBOL», и до сих пор, уже 25 лет, моя мама работает на этой должности в том же банке.



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





Мой брат (ему 1 год, он слева), моя мама и я (справа)



COBOL...



… это не такой крутой язык программирования как функциональный Haskell или Golang для параллельных вычислений. COBOL — это императивный, процедурный язык, а с 2002 года — объектно-ориентированный. В самом языке ничего плохого нет, проблема в том, что его почти никто не знает, как минимум в контексте программирования мэйнфреймов. Моя мать — вторая из самых молодых членов команды, а она родилась в 1964 году. У самого молодого из персонала разница с ней в два года. Это глобальная проблема, поскольку почти все крупнейшие банки в мире работают с мэйнфреймами IBM и COBOL у них — основной язык программирования. У банков помельче ситуация лучше, они обычно работают, например, на Java, без мэйнфреймов.



Мама раньше спрашивала меня, не хочу ли я изучить этот язык, но я тогда уже работал с более продвинутыми технологиями вроде Postgres, Redis, Node, Crystal, PHP и всегда отвечал «Да ни за что!». Мне до сих пор интересно то, что она делает, но такие типы систем вызывают, кажется, самое плохое ощущение корпоративщины, которое только можно представить и которого мне хотелось бы избежать.



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



Базы данных



Их основная база данных называется IMS. Это иерархическая база данных, созданная IBM для программы Apollo. Между собой они называют её DL/1, Язык Базы данных 1 (Database Language One). Они пытаются мигрировать на DB2, реляционную базу данных, которая понимает нормальный SQL. Но, учитывая огромный объем данных, которые хранит банк Nordea, такая задача займёт несколько лет. Нужно не просто переместить данные из IMS в DB2, в дополнение надо обновить модули для загрузки и сохранения данных из DB2 вместо IMS, а модулей тысячи, многие из них были разработаны программистами, которые либо умерли, либо вышли на пенсию.



Каждая транзакция хранится в DB2. Они избегают записей в IMS насколько это возможно, и только считывают из неё данные, пока их новая купленная система не интегрируется полностью, и они не смогут хранить данные там.



IMS — чрезвычайно старая и очень медленная (для некоторых задач).

Поиск данных может занять несколько часов. Ха, а мы тут спорим о том, что у MySQL скорость выполнения запросов на две миллисекунды выше, чем у Postgres. Немного иронично.



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



Давайте поговорим о размере их баз данных. DB2 хранит данные только о транзакциях, и транзакции отличаются по размеру, в зависимости от типа счетов, между которыми протекает транзакция. Частные счета, как мой личный банковский счет, на порядок проще, чем корпоративные счета. Каждая транзакция весит где-то от 500б до 2Кб, в среднем примерно 1Кб.



Сейчас их база данных DB2 хранит 11 миллиардов транзакций, а закон требует хранить каждую транзакцию в течение 10 лет, а по факту — 11 лет. На данный момент транзакциям только 7 лет, а их количество, предположительно, растёт на 5-8% каждый год, и так, пока они не дождутся 11 лет, когда можно будет уничтожить записи старше 11 лет.



Получается, сегодня DB2 хранит около 10Тб данных, и это только транзакции. Через четыре года это превратится приблизительно в 13-14Тб.



Большая часть оставшейся информации хранится в IMS. Эти данные сильно отличаются по объёму, так что трудно оценить размер, но я предполагаю, что их намного больше, чем в DB2.



Ещё они хранят некоторые данные на лентах, а их программы указывают машине загрузить или сохранить данные с конкретной ленты. Это довольно круто!



IDE



У всех есть что-то вроде IDE или текстового редактора, правда? У них, вот, есть. Их IDE называется ISPF и напоминает операционную систему. ISPF можно расширять, и часть, которую можно назвать IDE — это расширение ISPF под названием Endevor.



ISPF напрямую связана с мэйнфреймом, и у них нет такого понятия, как локальная среда разработки.





Интерфейс ISPF, найденный в интернете



Пакетная обработка



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



Пакетные задания работают с гигабайтами, иногда терабайтами данных, и в некоторых случаях могут занять несколько часов. Хотелось бы посмотреть, как мэйнфреймы IBM внезапно переходят на полную мощность в их датацентрах в ту секунду, когда на часах 00:00. Это было бы офигенно!



Проблемы, с которыми сталкиваются банки



У банков, которые работают на мэйнфреймах, множество проблем, которые они должны решать, но времени на это, к сожалению, не хватает.



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



Есть программы, которым десятки лет: никто не понимает, как они работают, а человека, который их писал, уже давно нет.



Многие банки хотят приобрести новые крутые системы, чтобы заменить старые, а все их программисты в один голос заявляют: «это не сработает, нашего монстра нельзя ничем заменить».



Отчасти, причина огромного размера их систем в том, что они изначально допустили ошибку и начали подстраивать свою систему под другие системы. Хороший пример: мы создаём RESTful-сервисы, в которых программы, которым нужно получить от нас данные, подстраивают свои системы под нашу. В некоторых банках всё не так, и они посылают данные другим системам, например, налоговым службам, а налоговые службы могут в любой момент обновить свои системы, которые, в свою очередь, сломают те, что банки используют для отправки данных.



Банковские системы также чрезвычайно продвинутые. Личный банковский счет сильно отличается от корпоративного банковского счета. В дополнение существует как минимум 50 различных видов банковских счетов для каждого из типов. А в случае с Nordea, есть ещё и шведские правительственные счета, которые отличаются от личных и корпоративных. Думаю, что существуют финские правительственные счета и, возможно, часть датских, которые тоже чем-то отличаются.



В заключение



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



Q&A



Почему ты решила программировать на мэйнфрейме IBM на COBOL?

— Я всегда хотела «работать с компьютерами», но не искала эту конкретную работу. Я увидела объявление в газете, подала резюме и получила работу. Правда, на тот момент у меня уже было немного опыта в сфере компьютерных систем.



Что тебя больше всего шокировало?

— Мой коллега однажды забыл добавить точку в конце инструкции для программного модуля в самой важной части нашей системы, которую мы называем «кассой». Она отвечает за обработку всех денег. В результате на 16 часов остановилась работа всего банка, исключительно из-за модуля, который продолжал выполняться, хотя должен был остановиться после той инструкции. Это буквально повесило нашу систему, устроив, можно сказать, DoS-атаку самой себя.



Как ты думаешь, какое будущее ждёт банки, работающие в той же инфраструктуре, как Nordea?

— Большинство банков признало, что нужно заменить старые мэйнфреймы на более современные. Nordea купил новую систему, которой обещал заменить текущую в течение 4-х лет, но банк обслуживает несколько стран, и в реальности 4 года уйдёт только на одну страну, так что в общей сложности — 16 лет.



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



С какими проблемами тебе пришлось столкнуться как женщине-программисту, которая начала работать в 90-х?

— Совершенно никаких проблем не было. В моём коллективе есть несколько женщин, но мужчин больше. Меня это не особо беспокоит.



Ты работаешь над одним модулем и, возможно, над одной кодовой базой больше 20 лет. Это вообще надоедает?

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



Насколько страшно писать код для банка?

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



Ты когда-нибудь допускала серьёзные ошибки в работе?

— Определенно, одну довольно серьёзную ошибку я сделала еще в 1997 году, когда мой младший сын (это я, автор) только пошёл в детский сад и кончился мой декретный отпуск. У нас есть накопительная пенсионная система. Этот тип банковских счетов в то время был не закрытым, а по закону нельзя было снимать деньги с этого счета пока не исполнится 55 лет. Поскольку счета не были закрытыми, при наличии номера банковского счета деньги можно было снимать. Поэтому решение было простым — не давать клиентам номера их банковских счетов.



Я ухитрилась облажаться и изменила модуль, который стал добавлять номер счета в письмо, отсылаемое клиенту по почте. Клиенты начали снимать деньги (с которых еще не списали налоги!) со своих пенсионных счетов раньше, чем им полагалось по закону.



Это повлекло за собой огромное внутреннее расследование. Вмешалось шведское правительство, нас атаковали финансовая инспекция и СМИ. Это всё — я.



Какая у тебя рабочая атмосфера?

— Мы недавно переехали в более «модное» место. Раньше у нас были личные столы, а теперь «выбирай любое доступное место» — открытое пространство. Мне это совсем не нравится.



(Перевод Наталии Басс)


Original source: habrahabr.ru.

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

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

Следующие 30  »

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

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

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