Технически, при перевыпуске карты все токены могут и протухнуть, если перегенерируется 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 для магазинов, чтобы получать аналогичные уведомления, пока не предусмотрено, если ваш вопрос был об этом.
Очень интересно послушать, а будет ли как-то в магазинах обозначаться то, что магазин не хранит данные о карте? Было бы приятно знать, что в магазине поддерживается токенизация.
Пока не знаю, но мысль интересная, думаем над этим :)
Тут на самом деле намного больше препятствий для злоумышленника — данными токена нельзя воспользоваться, как это можно было бы сделать с данными карты для платежа.
1. Нужно получать одноразовую криптограмму у Visa/MasterCard, что может сделать только Token Requestor.
2. Нужно иметь интеграцию с реальным банком-эквайером, чтобы иметь возможность сделать платеж с использованием данных токена вместо карты.
Да, есть такой момент — лишний вызов незначительно увеличивает итоговое время обработки платежа. Но надо понимать, что токенизация применима не ко всем платежам, а в основном для сценариев подписок/повторных платежей. Таких платежей меньше, да и пользователь в них обычно не участвует — инициирует их магазин, так что время обработки здесь не так критично.
Каких-либо проблем с апреля с этим не возникало.
Да, такую возможность смогут предоставлять банки-эмитенты — технически для этого все готово, но как скоро это будет появляться в личных кабинетах банков, сказать не могу. Технология новая, и появляется в России постепенно. Думаю, что на первых этапах это будет решаться через тех. поддержку банков, а дальше уже они будут сами смотреть, когда пора выносить это в интерфейсы.
Если автор имеет хорошую карму, выборочно просматриваю самые интересные файлы.
Такого конечно хотелось бы избегать — все-таки мы код в первую очередь ревьюим, а не автора кода.
А что касается чек-листа — это больше похоже на конвенции, например: сборка должна быть «зеленой», должно быть верхнеуровневое описание задачи, форматирование кода отдельным коммитом и тд. Да, у нас тоже есть аналогичные конвенции, и кстати проверка многих из них довольно легко автоматизируется.
Из того, что не вошло в статью, следим еще за долго-живущими PR, то есть за аномалиями: если видим, что PR не вмержен после N дней, то информируем об этом участников PR, а также видим это в статистике.
Но в первую очередь это всегда вопрос к автору PR — именно он больше всех заинтересован в том, чтобы довести свою доработку до production. К ревьюерам у нас обычно вопросов не возникает.
Просто ранее не было более гибкого инструмента для подбора ревьюеров, да и не осознавали потребности в таковом, пока не ощущали проблем.
В целом всегда достаточно было бы иметь одного (или N экспертов), и теперь мы начали автоматически находить этих экспертов и более адекватно подбирать ревьюеров.
Ранее ревьюерами добавлялись одни и те же разработчики-эксперты, которые были закреплены за репозиториями. Теперь же не добавляются в ревью каждый раз все эксперты, а только кто-то один из них, таким образом нагрузка размазывается.
Если есть спрос, будет и предложение :) Да, многие функции, не завязанные на наши внутренние инструменты (получение составов команд, отсутствий ревьюеров), вполне можно выделить в отдельный плагин и опубликовать.
Проблемы обычно решаются по мере их появления и обнаружения. При взгляде извне проблем не наблюдалось — время жизни PR было приемлемым (а это была по сути единственная метрика), а значит все ОК. За нагруженностью ревьюеров просто никто не следил, а качество код-ревью оценить тем более очень сложно.
А стоило всплыть проблеме излишней загрузки ревьюеров «изнутри», и когда стало ясно, что это не случайный всплеск, а закономерность, тогда и начали ее решать, а заодно пересмотрели весь процесс код-ревью и опыт других компаний учли. Не думаю, что это странность.
Вот то что не было нормальных метрик код-ревью раньше — это скорее было ошибкой на мой взгляд, теперь исправились.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Да, это верно. Как и то, что не любая просроченная карта вообще будет перевыпущена. Это зависит от банка-эмитента.
Просто у МИР на данный момент нет возможности токенизации карт.
Да, все верно.
А какой именно способ управления подписками имеете в виду, можете чуть подробнее пояснить?
Отчасти так. Платежные системы и правда предоставляют отдельную возможность узнавать обновления данных карт. В Яндекс.Кассе мы эту отдельную фичу не используем.
Если же говорить о токенах, то по ним платежные системы дают аналогичную возможность, но она работает немного по-другому (мы не получаем полные данные карт — лишь last4 и expiry), и является неотъемлемой частью жизненного цикла токена, которую обязан поддерживать любой Token Requestor.
Фича обновления данных токена, как и в целом E-comm токенизация, поддерживается всеми основными банками-эмитентами в РФ. Я сам проверял перевыпуск карты в паре крупных банков-эмитентов, все работает.
Что касается магазинов Я.Кассы, то мы постепенно включаем поддержку токенизации магазинам, которые используют функциональность сохранения способа оплаты у нас. Сейчас работает для нескольких десятков магазинов. Вот кстати был пресс-релиз, когда на первых магазинах запускали в апреле: retail-loyalty.org/news/mastercard-i-yandeks-kassa-vpervye-v-rossii-zapuskayut-tekhnologiyu-tokenizatsii-dlya-internet-komme
Тут как раз и имелось в виду, что если бы не было автообновления реквизитов карт, то карта была бы уже просрочена и платеж бы не прошел.
Да, мы получаем такие уведомления напрямую от Visa/MasterCard. На данный момент мы обновляем данные в своей системе, а магазин узнает о том, что карта обновилась, только при очередном платеже. API для магазинов, чтобы получать аналогичные уведомления, пока не предусмотрено, если ваш вопрос был об этом.
Пока не знаю, но мысль интересная, думаем над этим :)
1. Нужно получать одноразовую криптограмму у Visa/MasterCard, что может сделать только Token Requestor.
2. Нужно иметь интеграцию с реальным банком-эквайером, чтобы иметь возможность сделать платеж с использованием данных токена вместо карты.
Каких-либо проблем с апреля с этим не возникало.
Такого конечно хотелось бы избегать — все-таки мы код в первую очередь ревьюим, а не автора кода.
А что касается чек-листа — это больше похоже на конвенции, например: сборка должна быть «зеленой», должно быть верхнеуровневое описание задачи, форматирование кода отдельным коммитом и тд. Да, у нас тоже есть аналогичные конвенции, и кстати проверка многих из них довольно легко автоматизируется.
Но в первую очередь это всегда вопрос к автору PR — именно он больше всех заинтересован в том, чтобы довести свою доработку до production. К ревьюерам у нас обычно вопросов не возникает.
В целом всегда достаточно было бы иметь одного (или N экспертов), и теперь мы начали автоматически находить этих экспертов и более адекватно подбирать ревьюеров.
Ранее ревьюерами добавлялись одни и те же разработчики-эксперты, которые были закреплены за репозиториями. Теперь же не добавляются в ревью каждый раз все эксперты, а только кто-то один из них, таким образом нагрузка размазывается.
А вам какие фичи были бы наиболее полезны?
А стоило всплыть проблеме излишней загрузки ревьюеров «изнутри», и когда стало ясно, что это не случайный всплеск, а закономерность, тогда и начали ее решать, а заодно пересмотрели весь процесс код-ревью и опыт других компаний учли. Не думаю, что это странность.
Вот то что не было нормальных метрик код-ревью раньше — это скорее было ошибкой на мой взгляд, теперь исправились.