За что не любят CVV и 3D Secure. И почему разработчик не виноват. Разбор

О неправильном CVV: а был ли код?

Александр, давайте начнём с азов: что такое CVV и зачем нужна его валидация?

Как и в случае с PIN-кодом, предполагается, что CVV/CVC известен только держателю карты. 

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

Валидация CVV/CVC обязательна?

Нет. Наличие этого кода не является обязательным условием для проведения CNP-транзакции.

Как вообще происходит валидация CVV/CVC? От чего она зависит — от разработчика, от банка-эквайера, от платежной системы?

От разработчика необходимость валидировать CVV/CVC вообще никак не зависит: разработчик делает то, что ему говорит заказчик. Валидация CVV/CVC зависит от конкретной ситуации, в которой формируется транзакционный запрос от эквайера к эмитенту.

Международные платёжные системы (МПС), заинтересованные в снижении мошеннических транзакций, настоятельно рекомендуют мерчантам запрашивать CVV/CVC у своих клиентов. И как правило, эквайеры требуют от мерчантов эти рекомендации выполнять.

Вместе с тем бывают ситуации, когда CVV/CVC не запрашивается и не передается — например, при рекуррентных (повторяющихся) платежах. И вообще говоря, если эквайер решит не передавать CVV/CVC в запросе эмитенту, ничто не помешает ему это сделать. Если же CVV/CVC был запрошен и передан, эмитент в своём ответе сообщает эквайеру, совпал ли переданный CVV/CVC с оригинальным кодом или нет. И это исключительное право эмитента решать, одобрять ли платёж, если CVV/CVC не совпадает. 

Почему некоторые сервисы не проверяют CVV? Может, это дорого или сложно в разработке?

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

А как ещё эмитент может убедиться, если не с помощью CVV/CVC и 3D Secure?

Бывают ситуации, когда эквайер и эмитент — это один и тот же банк, который к тому же проводит идентификацию клиента. Например, в О!плати при регистрации кошелька пользователь проходит идентификацию, следовательно, Белинвестбанк знает, что Иван Иванов, зарегистрировавшийся в приложении — это действительно Иван Иванов. Далее, если Иван Иванов пытается пополнить свой счет в О!плати картой Белинвестбанка, последний и без CVV/CVC и 3D Secure может проверить, действительно ли именно эта карта была выдана им Ивану Иванову.

Да, в такой ситуации отсутствие проверки понятно. Но в случае с О!плати платежи проходили без проверки CVV c карт других банков. Как такое может быть? Белорусские банки-эмитенты не запрашивают CVV/CVC?

Сложно сказать, этот вопрос надо адресовать банкам-эмитентам. Я могу сказать только одно: CVV/CVC известен лишь эмитенту, ни эквайер, ни разработчик ничего о нём не знает. Задача разработчика — принять код от клиента и отправить его на шлюз эквайера. Задача эквайера — сформировать запрос по протоколам Visa и Mastercard и передать в сети МПС. А уже эмитент, знающий, какой CVV/CVC на самом деле, даёт ответ: совпали цифры или нет. Почему проходят платежи с неправильными CVV/CVC? У меня две версии. Либо эмитент разрешил транзакции с неправильными CVV/CVC, и тогда это на совести эмитента. Либо эквайер CVV/CVC не отправляет.

А какая выгода эквайеру не передавать CVV?

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

Но тут-то поле есть. И я всё равно ввожу код!

Можно предположить, что в целях упрощения платежей эквайер отказался от CVV/CVC, но разработчики не успели убрать это поле: оно есть, но данные никуда не передаются. Но это всего лишь моё предположение. Точный ответ знает только Белинвестбанк.

А почему эмитенты не отклоняют транзакции без CVV?

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

Принимая решение о том, одобрить или нет платёжную транзакцию, эмитент смотрит не только на наличие-отсутствие CVV/CVC, но и на другие параметры транзакции.

Может, это всё-таки стоит дополнительных денег?

Нет. По крайней мере, здесь нет расходов, которые бы делали экономически целесообразным отказ от CVV/CVC. Это стандартные протоколы, формированием запросов и обработкой ответов занимается специализированное ПО, которое само по себе дорогое, но CVV/CVC входит в его базовый функционал. Для разработчиков добавление поля тоже не представляет никакой сложности.

Давайте резюмируем эту часть: отсутствие валидации CVV/CVC — это нормально?

Это отличается от общепринятых подходов проверки пользователя, которые практикуют другие системы электронных кошельков. Обычно сперва к кошельку привязывается карта с валидацией CVV/CVC и проверкой по 3D Secure, а потом все последующие платежи идут как рекурренты, без каких-либо дополнительных проверок.

Как отсутствие валидации CVV влияет на безопасность платежей? А на риск мошеннических действий с картами?

Конечно же, отсутствие CVV/CVC при CNP-транзакции обычно увеличивает риск того, что кто-то заплатит не своей картой. Номер карты и срок её действия легко подсмотреть, запомнить, украсть. Увидеть CVV/CVC, которые расположены на обратной стороне карты — сложнее. Именно поэтому эмитенты, как правило, отклоняют транзакции, в которых CVV/CVC не совпадает с оригинальным.

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

О валидации имени кардхолдера: не нужна?

Отсутствие валидации имени держателя карты — это нормально?

Да, это нормально.

Имя вообще никто и никогда не проверяет?

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

А зачем тогда это поле?

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

Опять же, как и в случае с CVV/CVC, если эмитент имеет какой-то иной способ убедиться, что транзакция действительно была инициирована его клиентом, то ему всё равно, что написано в поле «имя держателя карты».

О 3D Secure: почему им пренебрегают

О чём свидетельствует отсутствие СМС с динамическим паролем? О том, что карта или сервис не подключены к 3D Secure?

СМС с OTP (one time password), по идее, должен приходить клиенту от эмитента всякий раз, когда тот проходит проверку по 3D Secure. Отсутствие такой СМС не обязательно означает неучастие карты в программе 3D Secure. У эмитента может банально сбоить сервис проверки. Или может глючить оператор мобильной связи.

Проверка карты на участие в 3D Secure происходит в момент совершения платежа путём обращения к специальному серверу платежной системы, под брендом которой выпущена карта. МПС отвечает, участвует карта в программе 3D Secure или нет. Если участвует, в ответе указывается URL ACS (access control server) сервера эмитента, куда плательщик перенаправляется для ввода OTP. Если карта не участвует в программе 3D Secure или ACS-сервер недоступен, запрос на авторизацию передаётся эмитенту. 

Если ACS-сервер доступен, но СМС не приходит из-за проблем с сотовой связи, то через 15 минут сессия закрывается и транзакция автоматически считается неуспешной.

А если карта участвует в 3D Secure, но СМС не приходит и платёж при этом успешен, значит, платёжный сервис не участвует в программе?

Да, бывает и такое. Это значит, что эквайер сервиса позволил мерчанту принимать платежи без проверки транзакций по 3D Secure. Почему он разрешил? Потому что мерчант каким-то образом гарантировал ему возмещение убытков по фрод-транзакциям. Вторая возможная причина — ACS-сервер в момент прохождения платежа был недоступен. В этом случае платёж тоже пропустят.

Почему некоторые сервисы не подключены к 3D Secure? Это сложно, дорого? Как и между кем происходят расчёты за эту услугу?

Трудно сказать почему, в каждом конкретном случае есть своя причина. Использование 3D Secure уже стало стандартом в платёжной индустрии. Международные платёжные системы создали такие условия, когда эмитенты стремятся включить все свои карты в программу 3D Secure. Дело в том, что если карта не участвует в этой программе, то ответственность за мошеннический платеж по такой карте, согласно правилам МПС, возлагается на эмитента. А кому хочется терять деньги?

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

Эквайер как-нибудь экономит, согласившись на отказ от 3D Secure? Кто платит за СМС с подтверждающим кодом?

За СМС платит эмитент, но мне кажется, что расходы там не такие уж большие. Эквайер за счёт отказа от 3D Secure никак не экономит — более того, он рискует.

Это просто, ничего не стоит, убирает риски — в чём тогда смысл отказа от защиты?

В том, чтобы клиентам мерчанта было удобнее и приятнее делать платежи, чтобы они не зависели от СМС. Как правило, отказ разрешается крупным мерчантам — мелким мерчантам такое не позволяется. 

Для эквайера смысл в том, чтобы угодить крупному клиенту. Допустим, есть сервис, который обслуживает крупных мерчантов. Если крупный мерчант убеждается, что без 3D Secure объём платежей увеличивается на 5-10%, то он, конечно, захочет отказаться от защиты. Он подписывает допсоглашение с эквайером о том, что гарантирует покрытие всех убытков банка, связанных с мошенничеством. Если банк-эквайер ему откажет, есть вероятность, что мерчант пойдёт к другим банкам-эквайерам и весь оборот перейдёт к конкуренту. 

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

Это обычная история, мошенники в Беларуси склонны к странным поступкам: они воруют карты, платят ими в кафе и ресторанах, потом попадаются и идут в тюрьму.

В комментарии под материалом dev.by вы выразили мнение, что отсутствие проверки  — зона ответственности банков, а не разработчика. Ответственности разработчика вообще нет?

Мы — сами разработчики и имеем опыт интеграций с сотней разных банков-эквайеров по всему миру. Разработчик делает то, что сказано в API, который он получает от эквайера. Сказано в API передавать значение CVV/CVC — разработчик будет запрашивать его у плательщика и передавать эквайеру. Но валидировать это значение может только эмитент, и никто другой. Соответственно разработчик за валидацию CVV/CVC отвечать никак не может. Решение о том, одобрять ли транзакцию с некорректным CVV/CVC, принимает эмитент. А решение о том, проводить ли такую транзакцию, принимает эквайер на основе ответа по валидации от эмитента. Так же, как и решение о том, передавать ли вообще  CVV/CVC эмитенту. Как видите, разработчик здесь ни на что не влияет.

Приложение от LWO пропускает платежи с липовыми CVV (скоро — в минских маршрутках)

По теме

Приложение от LWO пропускает платежи с липовыми CVV (скоро — в минских маршрутках)

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.