В этой статье:
Сегодня обсудим важную для многих индустрий тему Low-value exemption при приеме карт в ЕС. Одно из самых простых на бумаге и одновременно самых неверно понятых на практике исключений из Strong Customer Authentication. Регуляция Евросоюза PSD2 четко требует полноценной проверки личности плательщика и явного подтверждения им платежа через всем известный механизм 3DS. Но и из этого процесса есть практические исключения, призваны упростить платежный поток для низкорисковых и небольших транзакций, чтобы не перегружать плательщиков там, где это не требуется.
Мерчанты чаще всего воспринимают Low-value exemption как простое правило: сумма меньше €30 — значит 3DS не нужен, и на этом все заканчивается. Однако, не все так просто и за этой формулировкой стоит механика с несколькими встроенными ловушками, которые напрямую влияют и на конверсию, и на то, кто в итоге платит за фрод по таким платежам.
Платежный гайд от Monoup раскроет смысл LVE, зачем его придумали и как его правильно использовать.
Low-value exemption (LVE) — одно из пяти оснований для исключения транзакции из обязательной строгой аутентификации, согласно PSD2, наряду с TRA, whitelisting, recurring payments и corporate exemption. Проще говоря, если платеж соответствует критериям «исключения», это позволяет не проводить полную SCA-аутентификацию (3DS) по транзакции путем ввода кода подтверждения, так как он формально считается низкорисковым, в данном случае, в силу небольшой суммы.
Сумма платежа не должна превышать €30, а также соответствовать накопительным порогам: сумма exempted-транзакций с момента последней успешной авторизации не должна превышать €100, либо количество последовательных платежей по этой механике не должно превышать пяти штук. Логика базируется на условии «или», то есть если даже один из факторов выполняется, то платеж уже не может претендовать на исключение. Если платежей прошло более пяти или сумма транзакций по этому потоку превышает €100 или же отдельная транзакция, о которой речь, запрашивается на сумму больше €30 — применить LVE не получится.
Именно здесь мерчанты чаще всего путаются, так как упускают из виду, что этот «счетчик» ведет эмитент карты клиента по всем движениям, а не каждый отдельный мерчант по своему личному сайту. Это значит, что счетчик суммирует exempted-транзакции держателя карты по всем мерчантам, у которых он что-либо покупал с момента последней аутентификации, а не только у вас. Если сегодня утром держатель карты купил кофе на пять евро у совершенно другого мерчанта под LVE, а через час пришел оплатить цифровые товары на двадцать, эта покупка кофе уже частично исчерпала его доступный лимит.
Сложность в том, что каждый отдельный мерчант не может уточнить у клиента детали его предыдущих транзакций, а также не имеет технической возможности видеть транзакции других продавцов. Любой мерчант видит только свой собственный кусок активности карты, тогда как банк эмитент знает про все события по ней целиком. Тем не менее, мерчант все равно может получить выгоду от процесса, предлагая части своей аудитории бесшовный опыт, если понимает роли всех участников. На практике многие мерчанты пытаются создавать математические модели, которые будут вычислять применимость LVE к платежам конкретного клиента, однако в связи с недостатком данных, реализовать этот проект правильно не получится. Задача мерчанта или его платежного провайдера не в том, чтобы точно предсказать решение эмитента, а в том, чтобы корректно запросить исключение на основе того, что вы действительно знаете (то есть суммы конкретной транзакции).
Важно также понимать, что LVE это не бесплатная хитрая опция для мерчантов, продающих недорогие продукты, а осознанный перенос ответственности. Мерчант может создать более удобный платежный процесс, за счет отсутствия челленджа 3DS, однако вся ответственность за это будет на нем. В случае фродовых диспутов именно мерчант отвечает на вопрос: почему платеж не прошел двухфакторную аутентификацию, что, по сути, лишает его главного козыря в спорах с клиентами. Когда мерчант запрашивает Low-Value или TRA, он меняет конверсию на риск: 3DS отключается, но ответственность за фрод полностью ложится на мерчанта.
Однако банк-эмитент может и самостоятельно разрешить Frictionless-оплату на основе собственного анализа рисков. Если банк сам решает не показывать 3DS Challenge честному клиенту, перенос ответственности сохраняется в пользу мерчанта. Для продавца это идеальный сценарий: клиент не вводил SMS (максимальная конверсия), но платеж на 100% защищен от фрод-чарджбэков за счет банка.
Железобетонным доказательством согласия клиента на платеж выступает только 3DS challenge, который включает активное подтверждение платежа путем ввода смс или другой механики. Упрощенные варианты возможны, однако здесь принимается решение: удобство или риск-менеджмент.
В связи с этим, большая часть цифровых мерчантов в принципе не использует LVE в своей работе: поскольку высокий риск чарджбэков и очень разношерстная аудитория превратили бы этот инструмент в прямого врага прибыли. Для многих индустрий первично получить активное подтверждение оплаты от клиента, а эквайеры и платежные системы, в свою очередь, часто вообще не предоставляют опции исключений для высокорисковых мерчантов.
Наряду с LVE, часть мерчантов может использовать еще и TRA (Transaction Risk Analysis) exemption, который дает доступ к куда большему потолку, вплоть до €500, но требует поддержания доказанного низкого fraud rate каждые девяносто дней (по сути, постоянно). Поэтому для мерчанта с невысоким средним чеком и без развитой риск-инфраструктуры LVE остается более простым путем, тогда как для крупного объема и более высоких чеков именно TRA оказывается выгоднее. По оценке Visa Europe, до 40–50% e-commerce транзакций по объему потенциально могут претендовать на то или иное исключение, но на практике LVE применяется не так часто в том числе из-за описанной выше непрозрачности решения эмитента и опасений мошенничества.
Мы уже выяснили, что мерчант не может самостоятельно принять решение об исключении платежа из SCA на базе невысокой суммы, его принимает эмитент карты. И здесь, конечно же, имеют место отказы. Однако, отказ в данном случае не является отказом в платеже, что многие мерчанты понимают не до конца.
Механизм мягкого отказа специально предусмотрен именно для этого сценария: эмитент отклоняет запрос на исключение и возвращает специфический код, который явно означает необходимость полноценной аутентификации, а не отказ в транзакции, как таковой. Мерчант или PSP обязаны распознать этот код и автоматически инициировать новый запрос, но уже полным 3DS challenge с OTP или биометрией. Здесь как раз кроется главная операционная ловушка, из-за которой мерчанты могут терять конверсию: факт отказа эмитента норма, но чекаут мерчанта или PSP может быть попросту не настроена на распознавание мягких отказов, как отдельного случая, и не иметь автоматического механизма повтора. Если этот механизм не реализован, то отказ чаще всего отображается, как финальный статус, держатель карты теряет возможность завершить покупку, хотя формально у него был шанс заплатить.
В связи с этим, главная задача — не в оптимизации самого запроса LVE (как вы будете его передавать, когда, по кому), а правильно выстроить процесс вокруг решения эмитента, которое может быть любым. Необходимо надежно распознавать мягкий отказ, как отдельный, ожидаемый случай, и автоматически разворачивать по нему полноценный 3DS challenge, не теряя держателя карты на этом шаге.
Фактически, судьба конверсии решается именно здесь, а не на этапе настройки запрашивать ли вообще исключение. Из этого же вытекает и то, как стоит измерять эффективность механики на своих данных: не пытаться заранее спрогнозировать долю frictionless-транзакций по части платежей ниже тридцати евро, а смотреть постфактум на фактическую конверсию одобренных запросов и на то, насколько хорошо отрабатывает повторная попытка после мягкого отказа.
Бизнесы, у кого средний платеж существенно ниже 30 евро (а таких в онлайне достаточно) могут серьезно полагаться на LVE, как основной инструмент. Но стоит трезво оценить компромисс применительно к своему профилю риска: для низкорискового бизнеса это почти всегда оправданная сделка, а для пограничных случаев с и так напряженными фрод-метриками — требует отдельного расчета, а не автоматического применения ко всем транзакциям ниже порога. Иначе поток спорных платежей может быстро вырасти, а цифровым продуктам всегда гораздо сложнее доказать свою правоту, чем физическим товарам. Факт предоставления услуги клиенту и ее использования постоянно ставится под сомнение банком-эмитентом и, даже если он сам одобрил LVE, это никак не влияет на потенциал фродовых чарджбэков. Поскольку решение по данному исключению принимается только на основе суммы и обнуления счетчика, а вот другие показатели имеют вторичное значение (хоть и могут быть рассмотрены).
Для high-risk вертикалей доступ к LVE и вообще к упрощенным сценариям зачастую закрыт, как мы уже указывали ранее, и на это есть понятные причины. Крупные объемы, частые транзакции, большой риск отзывов платежей — все это нивелирует позитивный эффект от исключения. Тем не менее, для ряда более привычных индустрий это отличный способ снизить трение, получить больше лояльности и выше конверсию легальным путем.
Эта часть европейской регуляции предоставляет возможность управлять клиентским опытом там, где мерчанты и клиенты видят больше всего трения. Известно, что необходимость двухфакторной аутентификации снижает базовый уровень конверсии платежей за счет ошибок клиентов при вводе кода, неверной загрузки страницы, проблем с 3DS серверами и других нюансов. Многие мерчанты буквально мечтают проводить платежи без дополнительных подтверждений, однако, у всего есть своя цена и цена low value exemption — это полный перенос ответственности за мошенничество. Если его на сайте мало, и оно происходит редко, быстро пресекается, за счет продвинутых антифрод механизмов, в таком случае LVE оправдывает себя как нельзя лучше. В иных случаях риски могут перевешивать пользу и приводить к потоку дружественного или реального фрода.