Комментарии 31
Это как раз примеры тех случаев, когда магазин берет на себя ответственность за мошеннические операции.А в каком виде это проявляется?
В моём примере ваши деньги попадают на банковский счет AliExpress, Amazon, другой_площадки, а не на счет продавца, зарегистрированного на такой площадке. По этому и возврат денег не является большой проблемой
А в каком виде это проявляется?
Если вы напишете заявление в банк о том, что с вас сняли деньги, банк передаст эту претензию по цепочке до магазина. Дальше чем больше факторов аутентификации использовалось магазином — тем сложнее оспорить. Если использовался 3DS — оспорить практически нереально, а если как в Амазоне, требовался только номер/дата/cvc (не помню, Амазон cvc вообще запрашивает?), то такой платеж возвращают без проблем.
Замечу, что это стандартные требования платежных систем. Банки сейчас впаривают страхование средств, и оно не имеет отношения к стандартным процедурам МПС.
Интересно, это реально так в РФ? Мне недавно сбербанк настойчиво предлагал подключить "страховку", от случайных списаний. Я отказался. В ответ мне было сказано, что если у меня будет несанкционированное списани, чтобы я обращался в полицич, а не к ним.
Но лучше оценить качество претензионной работы по отзывам до открытия счёта — сейчас прошла волна кидалова от авиакомпаний и хорошие банки возвращали деньги клиентам, а плохие (как минимум Альфа и Сбербанк) задним числом ссылались на постановление правильства и также будут придумывать отмазки при оспаривании других.
«Мир» в EMV не входит, если что.
Не нужно ставить эту локальную систему в один ряд с глобальными платёжными системами.
Чем Вас так "прижарило" это упоминание?
Между прочим, НСПК (МИР) фактически первые запустили этот сервис. И разработка началась еще по очень сырой draft спецификации EMVco. И прилизование последующих версий спеки шло по информации от НСПК. Я даже наверное смогу пальцем ткнуть в то место спеки, где разъяснение добавлено скорее всего по моему вопросу в НСПК.
И, к слову, НСПК конечно не member (их немного), но https://www.emvco.com/get-involved/associates/ тут есть.
VISA создала первую версию этого протокола, но вскоре его начали использовать и другие компании (Master Card, JCB International, AmEx, Мир), впоследствии объединившиеся с VISA в содружество EMV. EMV занимается поддержкой и развитием протокола 3DS.
Хотя в таком контексте не правильно сформулировано. НСПК не использовала принадлежащей Visa протокол (Visa 3DS).
Да и построение фразы "говорит" что как бы НСПК организовало EMVco в 1993 году.
И да кстати если кто не в курсе EMV это от Europay/MasterCard/VISA вот только Europay нет уже лет 20 его сожрал MasterCard…
3DS со своими особенностями давно уже был и в MasterCard и VISA.
Естественно, я имел в виду реализацию EMVco спецификации.
Героизма не было.
Остальные не МПС особо торопились ибо у них и так было. Да и спецификация сырая была…
Ну разве что Сhina UP фактически с нуля чиповые и прочие технологии запускало. Но они беззастенчиво на Visa основались (спецификации один к одному цельнотянутые)
А НСПК сделалало предложение вендорам, от которого было сложно отказаться. Первые "реализаторы" 3DS могли "отползти" без сертификации для НСПК своего EMV 3DS решения в EMVco.
Наверное стоило бы отметить что 3DS EMVco это не продолжение 3DS Visa. В принципе не совместимы.
Ну и спецификация Visa это проприетарный протокол Visa.
А 3DS EMVco это открытая спецификация/рекомендация (и, кстати, более "модный" json выбрали).
Я пытался указать на то, что изначальная идея принадлежала Visa, а затем началось «совместное развитие».
Про не совместимость версий. Если я правильно помню то у 2.2 и 2.0 есть проблемы в совместимости.
Да они негодяи даже в рамках под версий несовместимость задавали. По мелочи. Изменить, например название параметра в протоколе.
И корячишься, что бы обеспечить совместимость, порождая залипухи в коде.
По мелочи, у них каждый релиз спецификации с предыдущим несовместим был (в код вносить изменения приходилось).
Немного истории.
Где-то в районе 2007...2008-го года столкнулся с тем, что некоторые компании, принимающие оплату картами онлайн, принимали ее только если эмитент поддерживал 3DSecure. У меня, на тот момент, такой карты не было. Банки на сайтах об этом ничего не писали. Обзвон и личные визиты позволили завести такую карту (сейчас этот банк уже не существует). Каково же было мое удивление, когда выяснилось, что никаких OTP там и в помине нет — оплата проходила в режиме bypass — то есть в момент, когда клиент должен подтвердить свою личность, введя OTP, окно сервера эмитента появлялось с кнопкой OK, которая его просто закрывала. Мне эта карта была нужна только для некоторых покупок, так что меня это не очень пугало, но вообще это был бардак. Первой картой с настоящим 3DS (с чеком, содержащим OTP) у меня стала зарплатная карта Сбербанка, когда они таки внедрили эту технологию.
Звоню в банк, мол, интересно почему не потребовалось смс подтверждение и можно ли его как-то подключить, чтобы с моей карты деньги не списывались сами. В банке мне объяснили, что 1) 3D Secure — супер защищенная технология, нет повода переживать о деньгах 2) Нет, смс подтверждение подключить нельзя, у банка такой возможности нет, и если вы хоть раз сделали оплату по этой технологии, то ваша карта условно больше не принадлежит ни вам, ни банку, кто угодно, когда угодно и какие угодно суммы может с неё списывать.
Да-да-да, конечно, я могу обратиться к продавцу, могу зайти в свой профиль на сайте, настроить параметры подписки и т.п. Но как бы карту мне выдавал банк, счет открыт в банке, финансовые услуги оказывает банк, всяческие комиссии за свои услуги берет банк, рекламный спам мне шлёт банк, донимает звонками тоже банк. Немного странно, что за опцией «смс подтверждение платежей» я должен обращаться к продавцу, а не банку.
Вопрос, для кого это технология безопасная :)
UPDATE: Я кажется понял смысл протокола, не внимательно читал статью:
Конверсия [для продавца] может быть увеличена за счет обновлений протокола 3DS, направленных на сокращение взаимодействия с пользователем.
Вот поэтому терпеть не могу всякие подписки и автоплатежи...
Бесплатная идея для банков. Дайте людям хотя бы выбор. Предложите платную услугу «Подтверждение платежей через смс». В принципе, её даже можно было бы адекватно сделать: настраивать в личном кабинете доверенных получателей, для которых смс не требуется или задавать максимальную сумму, которая может быть списана без подтверждения. Если эта услуга не будет приносить особых денег, то как минимум это отличный повод для пиара, мол, у нас единственный банк в мире, который заботится об удобстве наших клиентов и сохранности их денег, только у нас супер-мега безопасная карта, которой вы можете смело оплачивать покупки в инете.
мой зарубежный банк предлагает услугу виртуальной карты для онлайн покупок. я ее всегда держу выключенной и только включаю на минуту когда хочу совершить покупку. не было еще сюрпризных списаний, зато иногда приходят емейлы типа: не удалось списать деньги за вашу подписку от всяких хитрых сайтов, которые сохраняют данные карты у себя без спроса
Спасибо за статью! Как раз несколько месяцев назад интегрировал этот протокол в процесс оплаты, первую версию полностью, вторую частично, как задел на будущее. То ещё удовольствие, особенно, при (типичном) мнении руководства, что для этого достаточно дня-двух.
Такое вот лицемерие. Защищенную систему можно сделать, но не будут, так как тогда нельзя будет стричь дополнительное бабло с запуганного страшилками пользователя.
Я вот хочу, чтобы всегда любое онлайн списание шло через подтверждение с помощью смс-кода.
Во второй версии, которая, теоретически, в недалёких перспективах должна заменить первую, процесс может быть полностью прозрачен для покупателя — как будто нет никакого 3DS. В статье это упомянуто:
Первый и самый важный момент — это Risk Engine. В версии 1.0.2 клиенты всегда должны вводить второй фактор, например OTP. Однако в версии 2. * клиент может никогда не увидеть этот дополнительный защищенный запрос.
В отдельных банках (не скажу точно в каких), клиент и сейчас может выставить параметр — всегда использовать 3ds. Но учтите, что тогда у вас сломается оплата в тех магазинах где нет 3ds.
Про то, кого же защищает 3ds. Пожалуй основная идея его появления заключается как раз в «переносе ответственности» и только как дополнительный момент — подтверждение, что операцию совершает именно владелец карты.
DonStron говорил не про прозрачность, а про то что сам хотел бы выбирать — использовать 3ds или нет. Это кстати не зависит от версии.
Я не телепат, могу опираться только на текст:
Я вот хочу, чтобы всегда любое онлайн списание шло через подтверждение с помощью смс-кода.
Мне трудно понять, как "хочу всегда через смс-код" может значить "пофиг на смс-код". Впрочем, думаю, DonStron сам нам объяснит, что имел в виду, если захочет.
Про то, кого же защищает 3ds.
В случае нашей фирмы — владельцев терминалов оплаты. 3DS это действительно именно об ответственности. Безопасность самого процесса оплаты для покупателя там побоку. Всё сводится к желанию свести к минимуму потери, наносимые фродом — они могут быть огромны.
На всякий случай подробнее объясню мой предыдущий ответ.
v 1.0.2 — которую сейчас мы везде встречаем — предполагает обязательное введение дополнительного кода (это может быть статический пароль, смс или даже мини пазл). Но если вы не выставили параметр об обязательной верификации платежа (для вашей карточки), то найдутся магазины в которых не будет использоваться 3ds — следовательно вы не получите оповещение (sms или push) о такой оплате.
v 2.* — тут опять всё будет зависеть от банков эмитентов (возможно будет возможность выставить обязательность запроса кода подтверждения) и мерчантов, но скорее всего вы больше ни когда не увидите запрос на ввод OTP кода (или это будет очень редко). Возможно a1111exe подскажет, какова вероятность события получения OTP.
По этому использование 3ds как способ отслеживания платежей — не самый лучший способ.
И как верно отметил a1111exe — мерчант («владелец терминалов оплаты») — заинтересован в использовании данной технологии
Возможно a1111exe подскажет, какова вероятность события получения OTP.
Увы, не могу. Желание мерчанта, разумеется, чтобы эта вероятность стремилась к нулю. Но на момент интеграции в процессы оплаты (где-то в начале июня) вторая версия расценивалась всё ещё как сыроватая для полной имплементации. Плюс, большой клиент, который этого требовал, требовал чтобы оно было готово вчера. Поэтому то, что я реализовал, выглядело, как первый запрос по второй версии — если ответ подразумевал необходимость редиректа, fallback на первую версию, если нет, проводим тразнакцию и сохраняем вместе с параметрами верификации (eci, mid, xid, емнип). Статистику я понаблюдать не успел, т.к. сразу после завершения этого проекта ушёл. :)
3D Secure, или что скрывают механизмы безопасности онлайн-платежей