Токенизация карт в E-commerce: что это такое и как работает?

    Всем привет! Недавно мы в Яндекс.Кассе совместно с платежными системами Visa и Mastercard запустили новую технологию токенизации платежей для E-commerce, или, по-другому, онлайн-коммерции. Кто-то может подумать: что тут такого — с токенизацией карт разобрались уже с выходом Apple Pay, Google Pay и других *Pay. Но нет, тут что-то новенькое, а мы еще и первыми эту технологию запустили в России этой весной для магазинов-партнеров, так что почему бы не поделиться.


    В США и Европе эта технология появилась несколько раньше, и пользователи таких сервисов, как Netflix и Amazon, уже платят E-commerce токенами, хотя, возможно, даже не знают об этом. А я сейчас расскажу, как это устроено не только снаружи (для партнеров и держателей карт), но и изнутри, с точки зрения разработчика и тимлида этого проекта. Если интересно — велкам под кат.



    Что общего с Apple Pay и Google Pay


    Те читатели, которые представляют, как работают Apple Pay и Google Pay (а кто не знает — вот наша статья про запуск *Pay), увидят тут знакомые слова.


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


    Пока запомним эти особенности токенизации карт на устройствах пользователей:


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

    Запомнили? А теперь перейдем к токенизации карт для E-commerce, иначе говоря, для онлайн-платежей в интернет-магазинах.


    Итак, что такое токенизация в E-commerce


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


    Конфиденциальные данные карты — это ее номер (PAN — Primary Account Number) и срок действия.
    Если для подключения карты в *Pay инициатором является сам держатель карты, то токенизацию для E-commerce инициирует интернет-магазин. Но зачем (и с какой стати)?

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

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

    1. сохранить их на собственных серверах, если они сертифицированы на соответствие стандарту PCI DSS, что могут себе позволить далеко не все интернет-магазины,
    2. доверить их хранение своему платежному решению, например Яндекс.Кассе, которая сертифицирована PCI DSS по высшему уровню безопасности.

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

    Давайте обо всем по порядку. При токенизации мы обмениваем данные банковской карты на некий токен, но что это такое? Токен предоставляется платежной системой карты — Mastercard или Visa. Он представляет собой уникальный идентификатор, аналогичный номеру учетной записи устройства в Apple Pay или номеру виртуального счета в Google Pay, которые можно найти в приложении на смартфоне (Wallet на устройствах Apple и Google Pay — на Android).

    В отличие от *Pay, в E-commerce токенизации создание токена инициирует интернет-магазин или его платежное решение, а сами токены хранятся на серверах платежных систем.

    Разумеется, кто угодно не может прийти к платежной системе и получить токен чьей-либо карты для оплаты покупок. Во-первых, токенизировать карты могут только те платежные решения, которые пройдут сертификацию и получат одобрение платежных систем. Такое платежное решение называется On-Behalf Token Requestor или Token Service Provider, но для простоты будем впредь оперировать термином Token Requestor. И только Token Requestor может инициировать платежи токеном. Во-вторых, токен всегда выпускается для конкретного магазина, и с помощью токена можно платить только в этом магазине. Очень похоже на то, как токен *Pay связан с устройством, на котором он был создан.

    За счет чего это достигается? Просто перед проведением каждого платежа по токену Token Requestor должен получить одобрение у платежной системы на этот платеж. Факт такого одобрения надо будет предъявить во время фактического проведения платежа, поэтому одобрение это имеет форму одноразовой криптограммы, которую формирует платежная система карты. При проведении платежа эта криптограмма добавляется к параметрам запроса в банк-эквайер и затем передается платежной системе, которая проверяет подлинность этой криптограммы, которую сама ранее выдавала.

    А что там про управление токеном независимо от управления картой? Тут вообще все просто — токен живет своей жизнью, имеет свои статусы жизненного цикла, и о каждом изменении статуса Token Requestor сразу же узнает от платежной системы карты.

    Подведем некоторый итог. Что токенизация дает держателю карты?

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

    Что это дает интернет-магазинам?

    1. То, что хорошо для покупателя, хорошо и для магазина, поэтому использование токенизированных карт может повысить лояльность клиентов.
    2. Возможность перевыпуска банковской карты с сохранением токена важна для магазинов, использующих сценарии платежей по подписке. Магазину больше не нужно будет отключать подписку, если пользователь забыл обновить данные карты, и не придется всячески напоминать ему об этом. Стоит отметить, что у держателя карты все равно остается полный контроль и в любой момент он сможет отключить саму подписку.
    3. Повышение конверсии платежей. Мы исследовали, как использование токенов влияет на конверсию платежей в сравнении с использованием сохраненных данных карт. Выяснилось, что доля успешных платежей без использования токенов была 88,53%, а после включения токенизации выросла до 97,89%*. Получившаяся разница объясняется тем, что если банк-эмитент уже одобрил создание токена, то в дальнейшем платежи этим токеном будут вызывать большее доверие у антифрод-системы банка. На конверсию влияет также возможность оплаты перевыпущенными картами. Если человек не обновит данные карты, которую он привязал к интернет-магазину, то оплата не пройдет, а с токеном такой проблемы не возникнет.

    *Мы сравнивали платежи за этот апрель в крупном онлайн-кинотеатре (MCC 4899) — привязанными картами без 3DS, без учета неуспешных платежей из-за нехватки денег на карте.

    Технические аспекты


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

    Интеграция с платежными системами


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

    Интеграция подразумевает реализацию следующего API (условно) между платежной системой и нами в качестве Token Requestor:

    1. Создание токена.
      Мы передаем платежной системе данные банковской карты и идентификатор интернет-магазина, для которого создается токен. Дополнительно мы проводим скоринг для оценки рисков (risk scoring) токенизации конкретной карты для конкретного магазина и также передаем результат скоринга в запросе. В ответ мы получаем решение, одобрена токенизация карты ее эмитентом или нет, и если одобрена, получаем уникальный идентификатор созданного токена. После этого токен активен, можно проводить платежи с его использованием.
    2. Получение одноразовой криптограммы для платежа токеном.
      Мало обладать токеном, чтобы им платить: для каждого платежа нужно еще получить одобрение от платежной системы — криптограмма, помните? Так вот, чтобы получить эту криптограмму, мы передаем в запросе платежной системе идентификатор токена и некоторые детали платежа. Если токен активен, мы в ответе получаем эту одноразовую криптограмму, которую затем надо будет передать эквайеру при проведении платежа по карте.
    3. Уведомление от платежной системы об изменении состояния токена.
      Это может быть приостановка/возобновление действия токена по инициативе держателя карты, удаление этого токена навсегда, а также обновление данных банковской карты, для которой был выпущен этот токен, в случае ее перевыпуска. Нам нужно уметь обрабатывать определенные запросы от платежных систем и обновлять у себя информацию о токене, проще простого.

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

    Токенизация в Яндекс.Кассе


    Яндекс.Касса представляет из себя большую систему по приему платежей для интернет-магазинов. Она состоит из многих десятков различных сервисов: backend-, frontend-приложения, BI-сервисы. Они обеспечивают прием платежа пользователя различными способами, перевод денежных средств магазину, управление платежами через личный кабинет магазина, аналитические сервисы и тому подобное. И как именно сюда встроилась токенизация карт?

    Главный вопрос: в какой момент создавать токен для банковской карты?
    В API Яндекс.Кассы есть возможность сохранять выбранный способ оплаты для последующих платежей в будущем, мы это называем автоплатежи.

    Это может происходить как при привязке карты к аккаунту пользователя в личном кабинете магазина, так и при подписке на периодической основе, когда платежи с карты будут проводиться автоматически. В обоих сценариях при создании платежа магазин по API передает параметр save_payment_method: true, и после успешного платежа мы выдаем магазину payment_method_id — идентификатор сохраненного способа оплаты, с помощью которого он сможет проводить новые платежи.

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

    Что же сами платежные системы делают в момент токенизации карты?
    Они обращаются в банк-эмитент, с запросом на создание токена (как это происходит и при создании токенов *Pay), и банк выпускает токен для данного магазина. Банк также может уведомить об этом держателя карты и отобразить созданный токен в его личном кабинете.

    Как происходит платеж токеном?


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



    Итак, при платеже ранее сохраненным способом магазин передает только его идентификатор — payment_method_id. По этому идентификатору сервис платежей картами находит данные (PAN и срок действия) карты и передает их одному из банков-эквайеров, который далее общается с платежной системой карты.

    С токенами в этом сценарии добавляется еще один шаг:



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

    А что происходит в сценарии, когда пользователь перевыпускает карту в своем банке?
    Если к карте ранее были выпущены токены, то банк-эмитент сообщает в платежную систему Mastercard/Visa, что карта перевыпущена. В свою очередь, каждый Token Requestor, который выпускал токены к этой карте, получит уведомление от платежной системы. Оно содержит обновленную информацию о карте: последние 4 цифры номера и новый срок действия. Токен при этом остается прежним.

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

    Вместо заключения


    Токенизация в E-commerce — это новый этап развития приема платежей, повышающий удобство для всех участников процесса оплаты. Мы ожидаем, что в ближайшее время технологию поддержат многие российские банки и провайдеры — и она станет новым стандартом платежного рынка.

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

    Я всё, будьте здоровы и не болейте!
    Яндекс.Деньги
    Как мы делаем Деньги

    Комментарии 11

      0
      Вы пишете, что клиенты могут управлять токенами, созданными «на имя» их карт. А кто предоставляет такую услугу? Особо технически продвинутые банки или МПС? Как найти этот секретный сервис?
        0
        Да, такую возможность смогут предоставлять банки-эмитенты — технически для этого все готово, но как скоро это будет появляться в личных кабинетах банков, сказать не могу. Технология новая, и появляется в России постепенно. Думаю, что на первых этапах это будет решаться через тех. поддержку банков, а дальше уже они будут сами смотреть, когда пора выносить это в интерфейсы.
        0
        Интересно, до этого с данным решением не сталкивался. А добавление еще одного элемента в схему взаимодействие систем в рамках проведения оплаты при масштабировании не увеличит время итогового «ок'а» на ту же авторизацию? Были какие-то критичные проблемы или баги с этим связанные?
          0
          Да, есть такой момент — лишний вызов незначительно увеличивает итоговое время обработки платежа. Но надо понимать, что токенизация применима не ко всем платежам, а в основном для сценариев подписок/повторных платежей. Таких платежей меньше, да и пользователь в них обычно не участвует — инициирует их магазин, так что время обработки здесь не так критично.
          Каких-либо проблем с апреля с этим не возникало.
          0
          А перехватывать данные токена нет никакого смысла, потому что токен превращается в тыкву при попытке заплатить в любом другом магазине.


          Интересные у вас оценки рисков. А что, использование токена в том же магазине уже не является вектором атаки?
            0
            Тут на самом деле намного больше препятствий для злоумышленника — данными токена нельзя воспользоваться, как это можно было бы сделать с данными карты для платежа.
            1. Нужно получать одноразовую криптограмму у Visa/MasterCard, что может сделать только Token Requestor.
            2. Нужно иметь интеграцию с реальным банком-эквайером, чтобы иметь возможность сделать платеж с использованием данных токена вместо карты.
              0
              Возможно, в реализации Яндекс.Деньги действительно больше препятствий для злоумышленника и данными токена нельзя воспользоваться, но у других платёжных провайдеров оплата чужим токеном — вполне реальная ситуация.
              Тут "Как ездить на такси за чужой счёт — уязвимости на примере одного сервиса" я пишу, как смог добавить себе токен другого клиента и оплатить им свой заказ (читать со слов «Платёжные карты добавляются в это приложение»).

              Daleko, FYI
            0
            -
              +1
              А почему ничего не рассказали про PAR? Технически, при перевыпуске карты все токены могут и протухнуть, если перегенерируется PAR, например, из-за смены номера карты. Как-то не заметил этого понимания в вашей статье. Почему ничего не сказано про ПС Мир? У них тоже есть технологии токенизации карт или это принципиальное решение не взаимодействовать с ПС Мир? :)

              обновление данных банковской карты, для которой был выпущен этот токен, в случае ее перевыпуска.
              Здесь данные это последние 4 цифры и срок действия?

              Возможность управления токеном.
              А чем управление токеном отличается от управления подписок по CNP для клиента? По факту те же грабли, только в профиль… Что так, что так можно узнать, где и когда была привязана карта. Возможно, насильственное отключение подписки будет проще с токеном, так как ПС или эмитент просто банят авторизацию по конкретному токену, но для пользователя, что управление токеном, что просто CNP подписками будет выглядеть идентично. Если нет, то интересно услышать ваше мнение.

              Насчёт обновления данных карт. Вообще говоря, токенизация карт и получение обновлённых данных карт это 2 разные вещи, которые никак между собой не связаны. Это 2 разных сервиса, что у Visa, что у Mastercard. У вас же в статье пишется будто это один функционал для магазина. Хотелось бы разобраться, поддерживается ли фича для всех магазинов Я.Кассы? По идее нет, так как ни у одного эмитента не видел подобного сервиса в России.

              Когда магазин инициирует очередной платеж с уже просроченной карты, которая на самом деле была перевыпущена, а у нас есть токен к ней для этого магазина
              А может ли вообще возникнуть такая ситуация? Если у вас вместе и сервис токенизации, и сервис автообновления реквизитов карт, то вам при перевыпуске должен сразу прилетать апдейт 4 цифр и срока действия карты (а по идее и токена) через API и такого случая вообще не должно быть. Интересно послушать какой-то кейс, когда это может произойти. Мне видится пример, только если у какого-то магазина упал прод и в личном кабинете отображается старая информация, но де факто, всё обновлённое. И эмитент пришлёт смс для новой карты, естественно.

              Интересно, кто присылает обновления данных карты Я.Кассе, вы напрямую сотрудничаете с Visa & Mastercard как TPP и даёте этот функционал магазинам? Непонятно, является ли это фичей для всех интернет-магазинов с Я.Кассой или только для избранных. Ну и плюс, как уже писал выше, есть ли данные об эмитентах, которые также подключились к этому сервису? :)

              Если же говорить вообще о токенизации карт в e-commerce, то я рад, что наконец-то этот процесс сдвинулся с мёртвой точки. Очень интересно послушать, а будет ли как-то в магазинах обозначаться то, что магазин не хранит данные о карте? Было бы приятно знать, что в магазине поддерживается токенизация.
                0
                Технически, при перевыпуске карты все токены могут и протухнуть, если перегенерируется PAR, например, из-за смены номера карты.

                Да, это верно. Как и то, что не любая просроченная карта вообще будет перевыпущена. Это зависит от банка-эмитента.

                Почему ничего не сказано про ПС Мир?

                Просто у МИР на данный момент нет возможности токенизации карт.

                Здесь данные это последние 4 цифры и срок действия?

                Да, все верно.

                А чем управление токеном отличается от управления подписок по CNP для клиента?

                А какой именно способ управления подписками имеете в виду, можете чуть подробнее пояснить?

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

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

                Хотелось бы разобраться, поддерживается ли фича для всех магазинов Я.Кассы? По идее нет, так как ни у одного эмитента не видел подобного сервиса в России.

                Фича обновления данных токена, как и в целом E-comm токенизация, поддерживается всеми основными банками-эмитентами в РФ. Я сам проверял перевыпуск карты в паре крупных банков-эмитентов, все работает.
                Что касается магазинов Я.Кассы, то мы постепенно включаем поддержку токенизации магазинам, которые используют функциональность сохранения способа оплаты у нас. Сейчас работает для нескольких десятков магазинов. Вот кстати был пресс-релиз, когда на первых магазинах запускали в апреле: retail-loyalty.org/news/mastercard-i-yandeks-kassa-vpervye-v-rossii-zapuskayut-tekhnologiyu-tokenizatsii-dlya-internet-komme

                А может ли вообще возникнуть такая ситуация? Если у вас вместе и сервис токенизации, и сервис автообновления реквизитов карт, то вам при перевыпуске должен сразу прилетать апдейт 4 цифр и срока действия карты (а по идее и токена) через API и такого случая вообще не должно быть.

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

                Интересно, кто присылает обновления данных карты Я.Кассе, вы напрямую сотрудничаете с Visa & Mastercard как TPP и даёте этот функционал магазинам? Непонятно, является ли это фичей для всех интернет-магазинов с Я.Кассой или только для избранных. Ну и плюс, как уже писал выше, есть ли данные об эмитентах, которые также подключились к этому сервису? :)

                Да, мы получаем такие уведомления напрямую от Visa/MasterCard. На данный момент мы обновляем данные в своей системе, а магазин узнает о том, что карта обновилась, только при очередном платеже. API для магазинов, чтобы получать аналогичные уведомления, пока не предусмотрено, если ваш вопрос был об этом.

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

                Пока не знаю, но мысль интересная, думаем над этим :)
                  0
                  Спасибо за столь подробные ответы!

                  А какой именно способ управления подписками имеете в виду, можете чуть подробнее пояснить?
                  Теоретически, при совершении первой транзакции и установки флага на последующие CNP транзакции, ПС или банк-эмитент могут запомнить эту самую транзакцию и показывать в своём приложении информацию о том, что вот в этом-то магазине «привязана» карта и с неё могут списать деньги через CNP. То есть это, можно сказать, «костыльный» метод, когда нет токенизации карт) Он позволяет без сложных словинтеграций сразу предоставлять сервис пользователям (тут есть нюансы, конечно, некая интеграция с ПС будет необходима). Как мне видится, отличий в таком случае нет (если мы говорим про управление подписками). Конечно, с точки зрения банка это может быть гораздо сложнее, так как надо будет проверять транзакции и вести перечень этих самых магазинов. Будут сложности и при удалении карты, но подобный сервис относится к сервису именно для ПС, поэтому решить эти проблемы через API будет просто. И очень было бы интересно услышать, насколько трудозатратно было стать Token Requester с точки зрения разработки, напрашивается ещё одна статья ;)

                  Фича обновления данных токена, как и в целом E-comm токенизация, поддерживается всеми основными банками-эмитентами в РФ. Я сам проверял перевыпуск карты в паре крупных банков-эмитентов, все работает.
                  Здесь, наверное, надо уточнить, что такое перевыпуск карты. Мне сбер как-то перевыпускал карту с заменой PANа, это тоже называется перевыпуск, но, вообще говоря, совершенно другая карта. Очень интересен этот кейс, может, у вас есть какая-то информация по этому поводу, будет ли в таком случае токен работать или протухнет?

                  По токенам действительно нашёл у Мастера в MDES API запрос на обновление данных! Интересная информация на почитать.

                  За новость спасибо, я на самоизоляции как-то её проглядел :) Получается, на текущий момент есть поддержка и Visa, и Mastercard? Или только Mastercard? Не нашёл новости про Visa или это уже не было инфоповодом?

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

              Самое читаемое