Comments 22
Это актуально банкам, а бизнес просто редиректит на страницу банка для оплаты. И это дико странно просить пользователя ввести данные карты у себя. Это нужно брать на себя ненужную ответственность.
Гитхаб и им подобные монстры могут это делать. Им пользователи доверяют. И есть причина - эквайрить пользователей разных стран через разные банки. Бывает даже в ресторанах терминалы разных банков. А у нас единая комиссия на интернет-эквайринг. Интересно что таи за мутки у ресторанов, что разные терминалы. Может тупо уход от налогов.
Если приносят два счёта и два разных терминала, то вероятнее всего здесь два юр лица — ООО с лицензией на алкоголь и какой-нибудь ИП на упрощёнке для всего остального. Да, это схема оптимизации налогов.
Или ресторан имеет эквайринг с разными банками для отказоустойчивости. Если один банк упал и не принимает платежи через свой терминал, то второй банк позволит не останавливать обслуживание.
Ну вообще на многих популярных веб-сервисах ввод данных карты идёт прямо на странице сайта.
Это не значит, что так должно быть, и что это лучшая практика.
Возвращаясь к заголовку — королевская форма для приёма банковских карт та, которая не требует ввода карты. Да, я лучше буду доверять большим мастодонтам банковские данные, чем каждому третьему сайту обещающему не хранить данные карты (что, емнип, незаконно, лень искать, первый попавшийся результат тут же, на qna: https://qna.habr.com/q/76658), но сохраняющему у себя не только номер в открытом виде, но и CVV.
Нет, это определённо, не королевская форма.
Я бы даже сказал больше, ввод платежных данных на стороне мерчанта - это обязанность прохождения сертификации на соответствие pci dss. Поэтому да, для обычного небольшого магазина решение явно излишнее.
Но тем не менее, мы для использования платежных систем типа Stripe создаем такую форму у себя на сайте. Данные по API передаются в Stripe, мы храним у себя только Customer ID и Customer Card ID, они имеют вид типа cus_1q2w3e4r5t6y7u8i9o. Как для разовых платежей, так и для подписок.
Никаких других данных у себя хранить не нужно, никакой ответственности.
Так что подобные формы у себя на сайте актуальны и для мелких сайтов. Пользователи используют, но это США, не бСССР.
P.S. К автору не имею никакого отношения.
Не статья, а реклама.
Эта форма отсылает все данные в какой-то левый никому не известный сервис binking (само название которого напоминает логин с хакерского форума), где с ними неизвестно что произойдет. Подумайте сами, нормально ли отсылать все данные карт пользователей на какой-то анонимный российский сайт?
Основная проблема. Это сертификация. Если хочешь не редиректить, а вводить у себя то это от 500 000₽.
Кто готов столько заплатить те без проблем сами сделают. И еще крупные компании, большие деньги. Зачем им рисковать и брать чужую библиотеку. Здесь нужна максимальная безопасность.
В общем, я понимаю, что Вы хотите упростить текущие проблемы с парсингом номеров и вынести их в отдельный сервис, но, к сожалению, данные карт — это, пожалуй, последнее что хочется отправлять на внешний сервис, даже если сейчас он вызывает доверие. Любой дополнительный встраиваемый скрипт, npm пакет или АПИ куда мы отправляем номера карт в открытом виде — это потенциальная брешь на будущее, ни один нормальный отдел безопасности этого не разрешит.
Моё мнение — если хотите идти в этом направлении — лучше всего делать это исключительно на стороне клиента, с минимумом кода (опен сорс, конечно же) который взаимодействует непосредственно с данными карты. Продать это будет крайне сложно, но как портфолио сойдёт. Скорее даже как ответ на SO к похожим вопросам, там часто бывает "я посмотрел на вопрос, и решил написать свою библиотеку для его решения". А так — удачи Вам, конечно, но на многое я бы не рассчитывал.
Последнее время все чаще встречаю формы, где автоматически только CVV код заполняется…
Мне как пользователю удобнее платить через ApplePay или Google Pay, чем вводить данные карты.
Создаём королевскую форму для приёма банковских карт