Консорциум W3C постепенно доводит до финальной стадии новый стандарт Payment Request API, который должен упростить пользователям процесс покупок товаров в интернет-магазинах. Больше не придётся вручную вводить платёжные данные при каждой покупке, потому что реквизиты банковских карточек хранятся в браузере и вводятся в форму автоматически (кроме кода CVV).
Это очень удобно: оплата карточкой совершается буквально в несколько нажатий кнопки. Ну и схемы мошенничества изменятся. Если раньше злоумышленники искали базы с кредитками на серверах магазинов, то теперь зловреды будут добывать карточки непосредственно из браузеров на локальных машинах пользователей.
4 октября опубликован черновик Candidate Recommendation, комментарии для которого принимают до 31 октября 2017 года.
Хотя стандарт Payment Request API ещё окончательно не утверждён, он уже включен по умолчанию в следующих браузерах:
- Chrome 61 в десктопной версии
- Chrome для Android с версии 53
- Chrome для iOS с версии 62
- Opera 48
- Opera для Android с версии 48
Новые интерфейсы уже реализованы в браузере Edge, а в Firefox и Safari он находится на стадии разработки. Правда, чтобы использовать автооплату в Edge, нужно зарегистрировать аккаунт Microsoft Wallet, так что в реальности не у многих пользователей она работает. Другое дело — Chrome, который начал хранить реквизиты банковских карт самым первым среди всех браузеров. В версии для Android эта функция активирована в августе 2016 года, а в десктопной версии её включили по умолчанию в сентябре 2017-го, с выходом Chrome 61.
Когда пользователь делает заказ в интернет-магазине (нажимает кнопку «Купить»), магазин отправляет вызов API к браузеру пользователя, сообщая информацию о заказе. Браузер выводит всплывающее окно, в котором уже заполнены все поля с реквизитами платежа и адресом доставки (если они раньше уже вводились и хранятся в браузере). Если пользователь подтверждает информацию, то браузер, а не веб-сайт, связывается с платёжным оператором типа Visa и Mastercard, чтобы провести транзакцию. Когда получено подтверждение, браузер сообщает об успешном проведении платежа веб-сайту магазина, который прислал запрос — и тот может приступать к оформлению заказа, упаковке и отправке товара, зная при этом, что деньги уже перечислены на его банковский счёт.
Поддержку хранения банковских реквизитов в своих реализациях браузеров собираются внедриить Samsung и Facebook, поскольку обе компании крайне заинтересованы в упрощении платежей в интернете.
На GitHub открыт репозиторий с образцами кода, как внедрить на веб-сайте разные виды автоматических платежей через Payment Request API. Есть страница с демками. Там показан реальный процесс оплаты со стороны пользователя, примеры клиентского и серверного кода.
На первый взгляд схема с хранением платёжных реквизитов в браузере кажется опасной. Но она придумана как раз чтобы улучшить защиту конфиденциальных данных. Ведь теперь магазин не получает информации о номерах банковских карт клиентов. Соответственно, эти базы с карточками теперь не будут храниться в каждом магазине, что в прошлом неоднократно приводило к утечкам данных. Сейчас всё в руках пользователя — и он сам несёт за сохранность своих банковских карточек, которые хранятся в его личном браузере.
Исчезает необходимость в платёжных системах вроде PayPal, которые выполняли роль посредника. Теперь таким посредником будет технология Payment Request API и браузер.
Хотя во многих отношениях Payment Request API повышает общую безопасность электронной коммерции, но появляются и новые риски. Получается, что браузер знает слишком много: не только ваши сохранённые пароли, но ещё и финансовую информацию. Получив доступ к браузеру, теперь посторонний человек может совершить покупки в магазинах от вашего имени. Более того, у разработчиков браузеров есть соблазн использовать историю покупок в своих целях. Например, для точного таргетинга интернет-рекламы.
Вопрос в следующем: доверяют ли пользователи браузеру настолько, чтобы хранить в нём информацию о своих банковских карточках?
Комментарии (42)
Andronas
08.10.2017 16:59+1Не понял в чем проблема с безопасностью. Мы ведь доверяем данные своих карт системам Apple Pay или Android pay.
keydon2
08.10.2017 21:31+10Нет, не доверяем.
Protos
09.10.2017 14:49Что значит не доверяем, у меня apple требует ввод карты, без этого не скачивается и не обновляется софт из магазина apple
darthmaul
09.10.2017 21:22+1Виртуальная карта с парой баксов на счету да и всё. Я переживаю не столько за взлом магазина эпл (проще уже слить карты с какого-нибудь инет магазина попроще), а за то, что случайно заплачу за какую-то in-app хрень.
navion
09.10.2017 21:58+1Раньше был вариант «другое» в вариантах оплаты и позволял нормально пользоваться без карты.
read2only
08.10.2017 17:11+4Это очень удобно: оплата карточкой совершается буквально в несколько нажатий кнопки.
Как правило, всё что наиболее удобно — наименее безопасно.
Ну и схемы мошенничества изменятся. Если раньше злоумышленники искали базы с кредитками на серверах магазинов, то теперь зловреды будут добывать карточки непосредственно из браузеров на локальных машинах пользователей.
Вот это верно, будет удобно.cyberly
08.10.2017 17:39+5>>… базы с кредитками на серверах магазинов…
За это разработчику магазина обычно полагается бить по рукам. Магазину эти данные нужны только в момент совершения покупки и то, только для того, чтобы переслать их в платежный шлюз. Хранить их — это подставлять себя и клиентов.
Akuma
08.10.2017 23:23+2Магазин вообще не должен запрашивать данные карты, а клиент не должен их давать магазину. Для этого есть эквайринг и платежные агрегаторы.
Если я в неизвестном интернет-магазине вижу, что именно магазин просит данные карты, я попробую найти другой магазин.
TheDarkKRONOS
09.10.2017 11:20Но если взять тот же Steam или GOG, то у них нет посредников, магазины сами запрашивают данные. Разве не так?
Akuma
09.10.2017 11:24Да, но и тот и другой — сильно известный сервис. А стали бы вы отдавать данные карты какому-нибудь vasya-lavka.ru? Я думаю лучше не стоит.
kissarat
09.10.2017 15:36Даже если магазину нужно хранить всю информацию о пользователе, то можно создать отдельно writeonly сервер, который будет эти данные только принимать. Во время введения данных, они будут отсылатся на этот сервер, но возможности ее читать с production сервера не будет
athacker
10.10.2017 12:55+1Для этого не нужен сервер, по такой схеме надёжнее в /dev/null сразу писать :-) А если где-то что-то сохраняется, то по-любому эту информацию можно прочитать. Так что не вариант.
equand
08.10.2017 17:36-2Пытаются залочить платежи на карты (древнее говно), пока криптовалюты только развиваются.
Втрице вообще конкретненько продается последнее время. Сначала ДРМо, теперь карточки сделали стандартом, скоро сделают стандарт логгинга данных пользователя браузера.
Fagot63
08.10.2017 20:03Банки в большинстве очень закостенелая организация, трудно поддающиеся прогрессу. А если нашли дыру в безопасности, ни в коем случае не писать банку. В крайнем случае из другой страны. Было уже множество печальных случаев.
superyarik
09.10.2017 00:48У ДРМ в браузере есть и другая сторона, сейчас для просмотра сериальчика в какой-нибудь Италии нужно поставить на ПК их приложение, иначе не посмотреть. С дрм в браузере этих проблем уже не должно быть. Те, кто ДРМят контент будут делать это не зависимо от w3c, но степень геморойности для пользователя, вот вопрос.
9uvwyuwo6pqt
10.10.2017 00:46>Сначала ДРМо, теперь карточки сделали стандартом, скоро сделают.
DRM сначала для текста, а потом вообще для всей страницы.
Goodkat
08.10.2017 17:40+1Другое дело — Chrome, который начал хранить реквизиты банковских карт самым первым среди всех браузеров. В версии для Android эта функция активирована в августе 2016 года, а в десктопной версии её включили по умолчанию в сентябре 2017-го, с выходом Chrome 61.
В Сафари данные моей кредитки хранятся уже пару лет.bizonwar
08.10.2017 18:14+1Да и в десктопном хроме уж точно не с сентября 2017.
Prototik
08.10.2017 21:41+1Тут дело не в хранении, а о API для платежей.
Да, браузеры могли хранить данные и раньше, но их функционал был в том, что они заполняли формы на сайтах этими данными.
Теперь же есть api, с помощью которого сайты могут попросить сделать платёж туда-то, и сайты не получают информацию о карте.
alan008
09.10.2017 00:54+1Ниже пишут, что все-таки получают
geektimes.ru/post/294177/#comment_10373003.
LexB
08.10.2017 20:06+1На первый взгляд схема с хранением платёжных реквизитов в браузере кажется опасной. Но она придумана как раз чтобы улучшить защиту конфиденциальных данных. Ведь теперь магазин не получает информации о номерах банковских карт клиентов.
Вот этого не понял, как проходит оплата если магазин не получает данные карты?
Причем на видео на 21й секунде приводят json с данными карты. Если эти данные уходят не в магазин то куда?Akuma
08.10.2017 23:25Скорее всего так же как и оплата через платежного агрегатора. Магазин только получает запросы на «такую-то сумму» и т.п.
Valsha
08.10.2017 20:37+1Немного не понятно одно.
За примеры спасибо, посмотрел первый пример — googlechrome.github.io/samples/paymentrequest/credit-cards
да, все красиво, мои кредитки показывает и дает платить, но не понятно что потом.
Вот сделал я такую оплату у себя на сайте, а КУДА потом деньги приходят от юзеров что делали покупки?
На мою кредитку/счет в банке?
Спасибо.
Akuma
08.10.2017 23:34+1Как верно подметили выше — а куда уходят платежи то? Полюбому ведь есть какой-то агрегатор всего этого добра за некоторый (кстати, какой?) процент от суммы платежа.
Налоги? Онлайн-кассы?
Без третьей стороны невозможно будет «подписать» данные о платеже. Грубо говоря, та же Я.Касса использует секретный ключ для хеширования параметров запроса. Тут как магазин узнает подлинность платежа без «выписки» по счету?Akuma
08.10.2017 23:38+1Плюс без третьей стороны как верить магазину?
Например, когда я вижу известного платежного агрегатора, да тот же банк — я знаю, что мои деньги, как минимум, не пропадут бесследно. А тут… по крайней мере пока непонятно.
mike_y_k
09.10.2017 00:09+1Ну про PayPal они немного зря упомянули — его функция третьей стороны не потеряет актуальности. Даже с приходом криптовалют им останется роль арбитра.
alan008
09.10.2017 00:53-2Да уж забили все на этот PayPal лет 5 назад. Сейчас большинство оплат напрямую с карты.
nidalee
09.10.2017 08:26+1Каждый месяц плачу за VPS через PayPal. Ну и деньги с Upwork тоже на него выводил раньше.
mike_y_k
09.10.2017 18:03И сам PayPal существует вопреки забившим на него клиентам :D
Если Вам лично он не нужен — остальные совсем не при чем…
Кстати при прямом платеже и последующих проблемах — расхлебывать придётся в одиночку.
Это только для соседнего магазина ещё прокатит… ;).
appsforlife
09.10.2017 00:46+3Меня тоже очень заинтересовала тема с оплатой посредством браузера, полез искать детали. Вот статья от гугла: developers.google.com/web/fundamentals/payments, там все куда более прозаично:
After the user authorizes the transaction, all the necessary payment details are sent directly back to the site. For example, for a credit card payment, the site will get back a card number, a cardholder name, an expiration date, and a CVC.
То есть этот новый апи просто заменяет форму оплаты на сайте. Вместо того, чтобы заполнять кучу полей в каждый раз разной форме оплаты на очередном сайте, покупатель просто нажимает «купить», сайт формирует стандартизированный чек на оплату и отдает его браузеру. Браузер показывает пользователю стандартизированную форму оплаты, где уже вбита часть нужной информации, которую браузер знает. Если все ок и пользователь соглашается оплатить, то браузер выдает сайту стандартизированный ответ, содержащий то, что пользователь видел в этой форме.
Вобщем пейпал пока может спать спокойно, карты по прежнему будут процесситься на сайтах магазинов. Смысл нововведения в том, чтобы дать возможность быстро купить что-нибудь с любого девайса, так как заполнять форму оплаты на умном паяльнике довольно сложно, а кликнуть «ну да, я не против» — легко.
А жаль, идея в статье была озвучена интересная…
Sly_tom_cat
09.10.2017 01:04+2Самого главного и не рассказали…
Payment Request API это интерфейс браузера. А вот браузер сам (на мобильном устройстве) лезет за данными карт и токенами в приложение (по другому API).
Да Payment Request API может работать с данными сохраненными в самом браузере, но это только частный случай. На андроиде с установленным приложением AndroidPay карточки или их токены берутся браузером из него. А там вам и шифрование и все дела.
Именно в такой цепочке (Payment Request API — Chrome for Android — AndroidPay App) сейчас работают платежи AndroidPay на сайте HeadHanter (например) и ешё некоторых других (платежи идут через Assist на стороне которого и реализована поддержка платежей AndroinPay и SamsungPay).
andrey_aksamentov
09.10.2017 05:17Почему бы не использовать токены с данными карты для оплаты?
Вставил — оплатил — вынул — закрыл в сейф. Зачем хранить в браузере такую информацию?
mike_y_k
09.10.2017 18:09Как появится окончательная реализация надо будет посмотреть и попробовать.
Заодно разобраться с механизмами и безопасностью.
herrjemand
Нет. W3C внедряет стандарт JS API для процессинга информации для заказа и оплаты продуктов. Хранение информации о кредитных картах уже было в браузерах давно.
Советую посмотреть https://www.youtube.com/watch?v=U0LkQijSeko