2ds мерчант что это
Полезное Мерч для новичков
Дополнительные параметры
Чтобы определить, какой мерч использует магазин, мы можем воспользоваться сайтом builtwith.com. Вбиваем в поле для ввода URL-адрес сайта и в разделе e-Commerce должен быть мерч, но бывает, что сайт его может не показать, тогда придется смотреть по переадресациям в браузере.
Мерчи, которые чаще всего можно встретить работая по ЮСЕ.
Мерчи по Европе, тут их будет больше.
И это далеко не весь список, лукавить не буду по поводу других и продолжать список не имею права, так как не работал с другими мерчами, если что и забыл, то потом добавлю.
Отдельного внимания заслуживает платёжная система PayPal. Некоторые новички считают, что с ней работать проще, но это далеко не так. Чтобы уметь с ней работать, нужно инвестировать много времени для изучения всех нюансов и тонкостей при работе с этой платёжной системой. Начинающим советую не парится по этому поводу
Бывает так, что вбив зашел на «ура», но трека нет и пак не высылают. Возможно, вы попали под раздачу наших коллег, которые делают такие фейковые страницы для сбора материала. Присмотритесь к ценам на сайте, они зачастую всегда гораздо ниже, чем у других, дабы собирать базу «по-жирнее».
Что такое мерчант
merchant.jpg
Похожие публикации
Покупатели все чаще рассчитываются банковскими карточками за товары и услуги, заказанные в интернет-магазинах. Для проведения этих операций владельцу сайта может понадобиться такой инструмент, как мерчант. Это понятие до недавнего времени было известно только в узких кругах, поэтому у многих людей возникает вопрос при слове «мерчант» – что это такое простыми словами, для чего он используется и как к нему подключиться.
Что такое «мерчант» и для чего он используется в РФ?
Мерчант – это специальная программа, которая дает возможность через интернет получать платежи с банковских карт и банковских счетов. Она эффективна, надежна и полностью безопасна.
Перечисление денежных средств осуществляется в автоматическом, полуавтоматическом и ручном режиме. Когда покупатель принимает решение приобрести через интернет какую-либо вещь – система предлагает ему несколько способов оплаты. И у каждого предложенного способа есть свой мерчант, благодаря которому выполняется прием платежей.
Главное преимущество данного инструмента заключается в том, что он не ограничивает географию сделок и позволяет торговать круглосуточно, 7 дней в неделю. Но он не заменит собой классический банковский счет, к тому же, его не следует использовать для проведения операций, которые не связаны с торговлей.
Мерчант-счет нужен, прежде всего, компаниям, которые осуществляют торговлю товарами и услугами через интернет. К ним относятся:
биржи контента и пр.
Виды мерчант-аккаунтов
Торговые мерчант-аккаунты. Используются в обычных магазинах. Их задачей является прием платежей за совершенные покупки. При этом оплата осуществляется при помощи банковской карты и специального оборудования (POS-терминала, импринтера).
Интернет мерчант-аккаунты. Используются на всех коммерческих сайтах. Оплата проводится без применения специального оборудования, покупателю достаточно ввести в платежную форму данные банковской карты. После этого деньги будут списаны с его счета и зачислены на счет продавца.
Какие преимущества имеет открытие мерчант-счета:
Возможность проводить расчеты разными валютами.
Конфиденциальность и безопасность сделок.
Минимальный риск мошенничества.
Операции обрабатываются за считанные секунды.
Система работает круглосуточно.
Платежный шлюз мерчанта
На сайт владельца мерчант-аккаунта устанавливается специфическое программное обеспечение, которое называется платежным шлюзом мерчанта. Его задача – осуществление контроля за приемом платежей. Механизм работы платежного шлюза следующий:
проверяется активность банковской карты;
кодируются данные о совершенной покупке;
данные перенаправляются в процессинговый центр;
если запрос прошел успешно – данные вновь возвращаются на сайт;
пользователь получает подтверждение в проведении транзакции (или отказ).
В проведении платежа будет отказано, если банковская карта является неактивной, пользователь ввел некорректные данные или системой были обнаружены иные проблемы.
Как открыть Merchant Account
Регистрация мерчанта представляет собой пошаговый процесс, целью которого является интеграция платежной системы для приема платежей на коммерческом сайте. Создать мерчант-аккаунт могут только юридические лица. Но и здесь есть свои ограничения, так как банки предъявляют очень высокие требования к претендентам на получение мерчант-аккаунта.
Для открытия Merchant Account необходимо выполнить следующие условия:
организация должна иметь собственный сайт, через который будут проходить платежи;
интернет-ресурс должен содержать подробное описание товаров и услуг, перечень доступных способов оплаты, описание способа оформления заказа, цены, подробные сведения о компании;
на сайте должен быть специальный раздел для регистрации и авторизации пользователей;
необходимо, чтобы сайт был размещен на платном хостинге;
недопустимо, чтобы реквизиты банковских карт покупателей запрашивались на страницах сайта; запрос должен происходить только после перехода на защищенные страницы процессингового центра.
На главной странице интернет-ресурса желательно расположить логотипы международных платежных систем, с которыми работает данная компания.
После регистрации мерчанта организация получает собственный внутренний код, который будет присутствовать во всех проводимых через ее сайт транзакциях. Данный код будет привязан к расчетному счету организации, и после этого денежные средства с карт клиентов будут перечисляться непосредственно на него.
Для обработки онлайн-платежей владелец коммерческого интернет-ресурса должен заключить договор с банком и центром процессинга платежных карт. Кроме того, в обязательном порядке ему придется открыть расчетный счет. Важно, чтобы у банка имелась процессинговая лицензия.
Для открытия счета банк обычно просит предоставить следующие сведения:
подробное описание товаров и услуг, предоставляемых организацией;
персональные данные руководителей организации;
комплект регистрационных документов (устав, свидетельство о регистрации, лицензию, учредительный договор);
кредитную историю юридического лица;
сведения об объемах продаж и территории, на которую распространяется деятельность компании;
сведения о политике возврата платежей;
адрес сайта, через который будут проходить платежи.
Если заявка на открытие счета будет одобрена – банк пришлет руководителю организации письмо с подготовленным к подписанию договором (в двух экземплярах). Один экземпляр останется в организации, а второй следует отправить в банк. После этого банк выдаст заявителю ID мерчант-аккаунта, инструкцию по системной интеграции и ключи шифрования. После проведения системной интеграции, при покупке товаров на сайте компании можно будет расплачиваться банковской картой.
Сервис Google Merchant Center
Гугл Мерчант Центр – это удобный инструмент для интернет-магазинов и прочих сайтов, работающих на коммерческой основе. После регистрации в этом сервисе владельцы сайтов смогут публиковать информацию о них и своем товарном ассортименте в товарных объявлениях и сервисах Google.
Благодаря сервису Гугл Мерчант пользователи поисковой системы Google видят товарные объявления в результатах поиска. Объявление содержит следующую информацию: название товара с картинкой, его стоимость и название интернет-магазина. Нажав на объявление, пользователи автоматически попадают на страницу товара. При этом оплачиваются именно переходы, а не показы.
Мерчант Центр предлагает очевидные преимущества для интернет-магазинов. Товарное объявление увидят миллионы потенциальных клиентов, а если предложенный товар заинтересует их – уровень продаж интернет-магазина существенно вырастет. Для запуска товарных объявлений необходимо зарегистрироваться в сервисе Google Merchant Center.
Полные тексты нормативных документов в актуальной редакции вы всегда сможете посмотреть в КонсультантПлюс.
Что такое мерчант. Объясняем простыми словами
Мерчант-аккаунты бывают двух видов — торговые и интернет-аккаунты. Торговый мерчант-аккаунт нужен обычному магазину. Когда покупатель расплачивается за товар, информация с его карты считывается на кассе с помощью POS-терминала, после чего деньги поступают на мерчант-счёт.
Интернет-мерчант-аккаунты используются для онлайн-покупок. При оплате клиент вводит данные карты в специальную платёжную форму, деньги списываются с его банковского счёта и перенаправляются на мерчант-счёт.
Мерчант-аккаунт отличается от других счетов тем, что на него можно зачислять средства без полной идентификации клиента — при наличии лишь информации о платёжной карте. Мерчант-аккаунт позволяет принимать платежи через системы Visa, Mastercard, «Мир» и другие.
Помимо открытия мерчант-счёта, торговой организации нужно заключить договор с процессинговым центром, который будет обрабатывать платежи. Также, если речь идёт об онлайн-торговле, на сайт компании устанавливается специальное программное обеспечение — платёжный шлюз мерчанта (для покупателей он будет отображаться как форма для ввода данных карты).
покупатель получает подтверждение о приёме платежа либо отказ в совершении покупки (если ввёл некорректные данные, карта неактивна и т. п.).
Когда платёж прошёл, деньги поступят на мерчант-счёт, и в течение одного-двух дней банк переведёт их на расчётный счёт продавца. Это время нужно на случай, если покупатель решит оформить возврат или если сумму списали в результате мошеннических операций.
Примеры употребления на «Секрете»
«Я занимался маркетингом, продажами, рисовал картинки на сайт. Этот сайт стал одним из первых интернет-магазинов. У нас можно было расплатиться за товар кредитной картой. Мы тогда много чего придумали, перепробовали всё, что сейчас в интернете является большим бизнесом. Например, пришли русские ребята, торгующие адресами девчонок. Мы становимся для них мерчантом, то есть помогаем при расчётах по кредитным картам. Сайт начал приносить нам где-то пару тысяч долларов, и это было уже хорошо».
(Предприниматель Ратмир Тимашев — о первых шагах в интернет-бизнесе.)
«Простота PayPal привлекла продавцов с eBay, многим из которых не хватало оборотов, чтобы завести свой merchant account («торговый счёт») и принимать платежи по кредитным картам. За весну-лето 2000 года PayPal набрал 5 млн новых клиентов».
(Из материала об истории онлайн-платежей — от мафии PayPal до братьев Коллисон.)
Ошибки в употреблении
Мерчант не стоит путать с эквайрингом, то есть вообще обработкой безналичных платежей клиентов. Эквайрингом занимается банк, с которым у торговой компании заключён договор на обслуживание (банк-эквайер). Мерчант-аккаунт — это только отдельное звено эквайринга, промежуточный банковский счёт, на который поступают деньги сразу после оформления покупки.
Нюансы
Система безналичных платежей, привязанная к мерчант-аккаунтам, позволяет проводить расчёты круглосуточно, в том числе в праздничные дни. Также магазин может проводить расчёты разными валютами. За каждую транзакцию владелец аккаунта будет платить комиссию в виде определённого процента от суммы платежа. Этот процент варьируется от 0,5 до 5% в зависимости от типа кредитной карты, вида приобретаемого товара, банка-эмитента (того, который выпустил карту) и других факторов.
3D Secure, или что скрывают механизмы безопасности онлайн-платежей
Электронная коммерция — одна из самых больших и быстро растущих областей, в связи с чем она привлекает внимание как исследователей информационной безопасности, так и злоумышленников. Поэтому хотелось бы разобраться в некоторых аспектах механизмов безопасности, применяемых при проведении онлайн-платежей.
Один из протоколов, используемых для увеличения безопасности онлайн-платежей — 3D Secure. Это протокол, который был разработан на основе XML в качестве дополнительного уровня безопасности платежей, проводящихся без физического участия карты (card not present payment). VISA создала первую версию этого протокола, но вскоре его начали использовать и другие компании (Master Card, JCB International, AmEx, Мир), впоследствии объединившиеся с VISA в содружество EMV. EMV занимается поддержкой и развитием протокола 3DS.
Почему протокол 3D Secure называется именно так?
Полное название этого протокола — Three Domain Secure.
Первый домен — домен эмитента — это банк, выпустивший используемую карту.
Второй домен — домен эквайера — это банк и продавец, которому выплачиваются деньги.
Третий домен — домен совместимости (interoperability domain) — инфраструктура, используемая при оплате картой (кредитной, дебетовой, предоплаченной или другими типами платежных карт) для поддержки протокола 3D Secure. Он включает в себя Интернет, подключаемый модуль продавца (merchant plug-in), сервер контроля доступа (access control server) и других поставщиков программного обеспечения.
Зачем это нужно?
3D Secure обеспечивает новый уровень безопасности путем предоставления дополнительной информации.
Еще одним важным моментом является «перенос ответственности». Это означает, что в случае мошенничества вся ответственность ложится на банк-эмитент. Этот момент является очень важным для продавца (мерчанта), т.к. до появления 3D Secure урегулированием спорных вопросов приходилось заниматься мерчанту.
Также не стоит забывать о двух важных психологических аспектах: повышении доверия к онлайн-платежам и увеличении конверсии.
Конверсия может быть увеличена за счет обновлений протокола 3DS, направленных на сокращение взаимодействия с пользователем.
Версии протокола 3D Secure
В настоящее время большинство платежных сервисов используют версию 1.0.2 при проведении онлайн CNP-платежей, запрашивающих OTP-код.
Версия 1.0.2 была создана в 2001 году и в ней есть некоторые проблемы.
На данный момент актуальной версией является v2.2, и EMV планирует, что к концу 2020-го года она будет использоваться везде.
Как это устроено?
Это основная схема, необходимая для понимания всего процесса платежа с использованием механизма 3DS.
На этом рисунке мы видим все три домена, используемые в протоколе, а также последовательность сообщений между всеми участниками платежной операции.
Как это работает?
Главное, что необходимо понять, — это то, что при использовании своей карты (виртуальной или реальной) для онлайн-оплаты, вы сталкиваетесь именно с протоколом 3DS. Поэтому сейчас мы проиллюстрируем все этапы совершения онлайн-платежа.
1 — Покупатель уже добавил все необходимые ему товары в корзину и нажал кнопку «Оплатить». В этот момент он попадает на страницу MPI-сервиса, где вводит данные своей карты.
После нажатия кнопки оплаты продавец (MPI) инициализирует старт платежного потока и, согласно протоколу, отправляет CRReq-запрос (Card Range Request). Данный запрос необходим, чтобы найти банк-эмитент вашей карты и получить CRR из домена взаимодействия. Этот запрос нас мало интересует.
После этого MPI отправляет VeReq (Verification Request). Этот запрос отправляется банку-эмитенту для проверки того, что 3DS для данной карты включен и карту можно использовать для оплаты.
VeRes (Verification Response) содержит дополнительную информацию для следующего этапа платежа.
Клиенты не могут видеть эти два типа сообщений.
2 — MPI создает PaReq (Payment Request) — запрос на оплату. Этот запрос отправляется через редирект в браузере клиента.
Итогом отправки PaReq становится отображение запроса на ввод OTP-кода.
3 — Клиент вводит OTP-код и возвращается на сайт продавца. Опять же в процессе этого через редирект от банка-эмитента к MPI передается PaRes (Payment Response), который содержит информацию о статусе проверки.
А поподробнее?
CRReq/CRRes для нас не очень важны. А вот VeReq/VeRes рассмотреть нужно.
В VeReq самым важным параметром является идентификатор сообщения, информация о продавце и PAN карты.
VeRes возвращает message id, который необходим, чтобы сопоставить запрос с этим ответом. А status enrolled показывает, что карта поддерживается.
Однако наиболее важным параметром в данном сообщении является URL-адрес. Этот параметр указывает, где находится ACS сервер эквайера и куда нужно отправить PaReq.
Pareq
Браузер клиента, совершающего оплату, может произвести достаточно много редиректов по различным компонентам, участвующим в совершении платежа. Так, в России есть некоторое количество запросов, обрабатывающихся на стороне Национальной Системы Платежных Карт. Но сегодня нас интересует только традиционный этап, описанный в спецификации протокола. А именно этап передачи PaReq.
Платежный запрос, содержащий PaReq (метод POST), имеет три параметра:
1) MD — данные продавца. Он нужен MPI, чтобы сопоставить PaReq и PaRes одной транзакции;
2) PaReq — параметр этого платежного запроса. Он содержит всю важную информацию о платеже;
3) TermUrl — URL-адрес, на который клиент будет возвращен в конце процесса аутентификации 3D Secure.
Параметры TermURL и MD всегда отражаются в ответе на данный запрос. Поэтому могут встречаться имплементации ACS, уязвимые к атакам типа reflected XSS. В процессе аудита различных систем такие сервера были найдены.
Важный момент №1: ACS сервера обрабатывают все входящие PaReq!
Что входит в параметр PaReq?
Вы можете получить его значение, раскодировав PaReq. Это сделать достаточно легко, потому что PaReq — это Xml-> zlib-> base64-> urlencode. Для упрощения работы с этими запросами был написан плагин для burp.
Теперь мы видим, что из себя на самом деле представляет PaReq, а именно сообщение формата xml. Это сообщение содержит информацию о сумме платежа (purchAmount, amount и currency), некоторую информацию о продавце и MessageId (из VeReq).
При отправке правильно сформированного PaReq (в большинстве случаев вам не нужен полный набор запросов на оплату — требуется отправить лишь PaReq, содержащий параметры правильного типа и длины), мы получим PaRes — ответ на платеж, подобный следующему:
Первая мысль, которая может прийти в голову веб-исследователю, который видит XML-запрос — это попробовать выполнить XXE. И это правильный путь!
Но для начала посмотрим на то, что случится, если отправить некорректно сформированный PaReq. Мы получим ошибку! Вот несколько примеров таких ошибок:
Ошибка может помочь получить дополнительную информацию о версии ACS. Некоторые из них могут также оказаться полезными для получения данных из XXE.
Раскрутим XXE
Рассмотрим следующий пример:
acqBIN, merID, xid, date, purchAmount и currency отражаются в PaRes. Однако во всех реализациях ACS, которые мы нашли, удалось использовать только merID. Остальные параметры проверяются на соответствие типам данных.
Еще один интересный параметр (и наиболее полезный для атаки) — это URL. Этот параметр не отражается, но и не проверяется. Поэтому его можно использовать для эксплуатации XXE.
Вернемся к нашему примеру. В одной из реализаций ACS мы обнаружили, что можем читать короткие файлы, а также получать ответ в PaRes error через параметр merID. Таким образом, используя PaReq из примера выше, мы получали следующий ответ:
Тем не менее в большинстве случаев оставалось только использовать параметр URL для получения DNS или HTTP-запроса к нашему сервису. Другой вектор — это выполнить DOS через XXE-атаку «billion laughs» (проверялось на тестовом сервере).
Где это можно найти?
В ходе нашего исследования мы обнаружили несколько распространенных URL-адресов:
И распространенные имена поддоменов:
Впрочем, иногда вы можете найти и другие интересные пути.
Если вы хотите найти что-то новое, используйте proxy interceptor и записывайте процесс совершения платежей для интересующей вас платежной системы.
3D Secure v 2. *
Как мы писали ранее, в 3DS v1.0 есть некоторые проблемы.
Основная проблема в том, что покупатель может использовать множество разных типов устройств. Планшет, мобильный телефон, умные часы, умный чайник и т.д. Но сайт ACS не всегда разработан для взаимодействия со всеми типами устройств.
Для этого в 3DS 2.0 предусмотрели 3DS SDK.
Другая проблема состоит в том, что новый тип защиты требует дополнительного взаимодействия с клиентом. И этот момент влияет на конверсию. Решением проблемы конверсии стала возможность использования механизма управления рисками, который позволяет не заставлять пользователя вводить дополнительные секретные данные, если банк обладает достаточным количеством информации, подтверждающей личность клиента.
Следующий важный момент заключается в том, что технологии аутентификации развиваются. Соответственно, 3DS могла бы использовать не только OTP. Поэтому v2 задумывалась с возможностью расширения поддержки различных механизмов аутентификации.
Интересный факт про v1.0. Люди некоторых стран не доверяли этому протоколу, потому что видели редирект и думали, что это мошенничество!
Этот психологический момент послужил причиной изменения спецификации второй версии протокола для сокрытия момента перенаправления.
Как работает 3D Secure v2?
Начало потока платежей аналогично предыдущей версии. Клиент должен указать данные своей карты.
Первый и самый важный момент — это Risk Engine. В версии 1.0.2 клиенты всегда должны вводить второй фактор, например OTP. Однако в версии 2. * клиент может никогда не увидеть этот дополнительный защищенный запрос.
Особенности работы v2
Если вы посмотрите на схему потока платежей, вы увидите, что она похожа на предыдущую, но во 2-й версии больше этапов. Это происходит за счет добавления дополнительных аутентификационных запросов и механизма Risck Engine, который может совершать как один дополнительный запрос (при платеже через браузер), так и множество (используется 3DS SDK).
Условно, 2-ю версию можно разделить на два блока. Красный, где пользователь непосредственно влияет на передаваемую информацию, и желтый, где система сама собирает и передает информацию о пользователе.
А поподробнее?
AReq (base64url) расскажет все о вас и об устройстве, с которого совершена покупка.
Если вы задумаетесь о том, какой информацией о вас располагают рекламные агентства, то данные AReq вас не удивят. Но если вам кажется, что это плохо, рассмотрите следующий момент: банки знают все о ваших покупках и о вас. С этой точки зрения, некоторая дополнительная информация не так уж и плоха)
Это сообщение необходимо для работы системы управления рисками и упрощения покупок.
Если этой информации оказалось недостаточно, Risk Engine сперва попытается получить дополнительную информацию, и именно в этот момент клиент может получить OTP-запрос.
Что контролирует пользователь?
CReq (base64url json) — challenge request — сообщение, отправляемое браузером пользователя, в случае если ARes вернет сообщение о необходимости провести Challenge Flow.
Если платежный процесс использует 3D Secure SDK, это сообщение будет зашифровано (JWE).
В CReq вы можете увидеть следующие поля:
К сожалению, нам пока не удалось провести достаточно подробное исследование 2-й версии протокола 3DS, поэтому сложно сказать, какие уязвимости встречаются чаще. Вы можете стать первым, кто опубликует исследование на данную тему.
Подведем итоги
Проблемы (найденные и возможные)
На что смотреть в v1
На что смотреть в v2
Тем, кто подумывает обратить свой взгляд на платежные системы, я бы посоветовал остановиться еще и на сервисах, предоставляющих 3DS как SaaS. Там может оказаться еще достаточно много вещей, которые помогут вам понять, как устроен мир онлайн-платежей.