Comments 42
Нет. W3C внедряет стандарт JS API для процессинга информации для заказа и оплаты продуктов. Хранение информации о кредитных картах уже было в браузерах давно.
Советую посмотреть https://www.youtube.com/watch?v=U0LkQijSeko
Разработчики стиллеров уже потирают руки в предвкушении профита.
Не понял в чем проблема с безопасностью. Мы ведь доверяем данные своих карт системам Apple Pay или Android pay.
Нет, не доверяем.
В смысле не пользуетесь или там принципиально нет данных карты?
Что значит не доверяем, у меня apple требует ввод карты, без этого не скачивается и не обновляется софт из магазина apple
Не повезло Вам. На моем Android нормально все ставится без карт
Виртуальная карта с парой баксов на счету да и всё. Я переживаю не столько за взлом магазина эпл (проще уже слить карты с какого-нибудь инет магазина попроще), а за то, что случайно заплачу за какую-то in-app хрень.
Раньше был вариант «другое» в вариантах оплаты и позволял нормально пользоваться без карты.
Это очень удобно: оплата карточкой совершается буквально в несколько нажатий кнопки.
Как правило, всё что наиболее удобно — наименее безопасно.
Ну и схемы мошенничества изменятся. Если раньше злоумышленники искали базы с кредитками на серверах магазинов, то теперь зловреды будут добывать карточки непосредственно из браузеров на локальных машинах пользователей.
Вот это верно, будет удобно.
>>… базы с кредитками на серверах магазинов…
За это разработчику магазина обычно полагается бить по рукам. Магазину эти данные нужны только в момент совершения покупки и то, только для того, чтобы переслать их в платежный шлюз. Хранить их — это подставлять себя и клиентов.
За это разработчику магазина обычно полагается бить по рукам. Магазину эти данные нужны только в момент совершения покупки и то, только для того, чтобы переслать их в платежный шлюз. Хранить их — это подставлять себя и клиентов.
Магазин вообще не должен запрашивать данные карты, а клиент не должен их давать магазину. Для этого есть эквайринг и платежные агрегаторы.
Если я в неизвестном интернет-магазине вижу, что именно магазин просит данные карты, я попробую найти другой магазин.
Если я в неизвестном интернет-магазине вижу, что именно магазин просит данные карты, я попробую найти другой магазин.
Даже если магазину нужно хранить всю информацию о пользователе, то можно создать отдельно writeonly сервер, который будет эти данные только принимать. Во время введения данных, они будут отсылатся на этот сервер, но возможности ее читать с production сервера не будет
Пытаются залочить платежи на карты (древнее говно), пока криптовалюты только развиваются.
Втрице вообще конкретненько продается последнее время. Сначала ДРМо, теперь карточки сделали стандартом, скоро сделают стандарт логгинга данных пользователя браузера.
Втрице вообще конкретненько продается последнее время. Сначала ДРМо, теперь карточки сделали стандартом, скоро сделают стандарт логгинга данных пользователя браузера.
У ДРМ в браузере есть и другая сторона, сейчас для просмотра сериальчика в какой-нибудь Италии нужно поставить на ПК их приложение, иначе не посмотреть. С дрм в браузере этих проблем уже не должно быть. Те, кто ДРМят контент будут делать это не зависимо от w3c, но степень геморойности для пользователя, вот вопрос.
>Сначала ДРМо, теперь карточки сделали стандартом, скоро сделают.
DRM сначала для текста, а потом вообще для всей страницы.
DRM сначала для текста, а потом вообще для всей страницы.
Другое дело — Chrome, который начал хранить реквизиты банковских карт самым первым среди всех браузеров. В версии для Android эта функция активирована в августе 2016 года, а в десктопной версии её включили по умолчанию в сентябре 2017-го, с выходом Chrome 61.В Сафари данные моей кредитки хранятся уже пару лет.
Да и в десктопном хроме уж точно не с сентября 2017.
Лучше бы внедрили стандартный API для ЭЦП.
На первый взгляд схема с хранением платёжных реквизитов в браузере кажется опасной. Но она придумана как раз чтобы улучшить защиту конфиденциальных данных. Ведь теперь магазин не получает информации о номерах банковских карт клиентов.Вот этого не понял, как проходит оплата если магазин не получает данные карты?
Причем на видео на 21й секунде приводят json с данными карты. Если эти данные уходят не в магазин то куда?
Немного не понятно одно.
За примеры спасибо, посмотрел первый пример — googlechrome.github.io/samples/paymentrequest/credit-cards
да, все красиво, мои кредитки показывает и дает платить, но не понятно что потом.
Вот сделал я такую оплату у себя на сайте, а КУДА потом деньги приходят от юзеров что делали покупки?
На мою кредитку/счет в банке?
Спасибо.
За примеры спасибо, посмотрел первый пример — googlechrome.github.io/samples/paymentrequest/credit-cards
да, все красиво, мои кредитки показывает и дает платить, но не понятно что потом.
Вот сделал я такую оплату у себя на сайте, а КУДА потом деньги приходят от юзеров что делали покупки?
На мою кредитку/счет в банке?
Спасибо.
Тут наверное поможет предпоследнее демо emerald-eon.appspot.com
Звучит как очередная дыра, усложняющая итак перегруженные интерфейсы веба.
Как верно подметили выше — а куда уходят платежи то? Полюбому ведь есть какой-то агрегатор всего этого добра за некоторый (кстати, какой?) процент от суммы платежа.
Налоги? Онлайн-кассы?
Без третьей стороны невозможно будет «подписать» данные о платеже. Грубо говоря, та же Я.Касса использует секретный ключ для хеширования параметров запроса. Тут как магазин узнает подлинность платежа без «выписки» по счету?
Налоги? Онлайн-кассы?
Без третьей стороны невозможно будет «подписать» данные о платеже. Грубо говоря, та же Я.Касса использует секретный ключ для хеширования параметров запроса. Тут как магазин узнает подлинность платежа без «выписки» по счету?
Самого главного и не рассказали…
Payment Request API это интерфейс браузера. А вот браузер сам (на мобильном устройстве) лезет за данными карт и токенами в приложение (по другому API).
Да Payment Request API может работать с данными сохраненными в самом браузере, но это только частный случай. На андроиде с установленным приложением AndroidPay карточки или их токены берутся браузером из него. А там вам и шифрование и все дела.
Именно в такой цепочке (Payment Request API — Chrome for Android — AndroidPay App) сейчас работают платежи AndroidPay на сайте HeadHanter (например) и ешё некоторых других (платежи идут через Assist на стороне которого и реализована поддержка платежей AndroinPay и SamsungPay).
Payment Request API это интерфейс браузера. А вот браузер сам (на мобильном устройстве) лезет за данными карт и токенами в приложение (по другому API).
Да Payment Request API может работать с данными сохраненными в самом браузере, но это только частный случай. На андроиде с установленным приложением AndroidPay карточки или их токены берутся браузером из него. А там вам и шифрование и все дела.
Именно в такой цепочке (Payment Request API — Chrome for Android — AndroidPay App) сейчас работают платежи AndroidPay на сайте HeadHanter (например) и ешё некоторых других (платежи идут через Assist на стороне которого и реализована поддержка платежей AndroinPay и SamsungPay).
Sign up to leave a comment.
W3C внедряет стандарт для хранения реквизитов банковских карт в браузерах (как пароли)