Комментарии 19
«В новой упрощенной форме остались только самые важные поля: номер карты, срок действия, CVV, имя и фамилия держателя карты, email, наименование банка.»
Зачем вам наименование банка?
И еще вопрос. Нажал кнопку «Купить», увидел иконку Альфабанка, в подсказке написано «Оплата через альфа-клик», ткнул, перебросило на вебмани почему-то. Это что за прикол такой? Я думал мне инвойс выставят, который я со счета заплатить смогу, при чем тут вебмани?
И еще момент. Нашел я книгу, хочу посмотреть качество перевода, жму «Читать отрывок», и тут мне предлагают регистрироваться/логиниться. Оно мне надо?
Зачем вам наименование банка?
И еще вопрос. Нажал кнопку «Купить», увидел иконку Альфабанка, в подсказке написано «Оплата через альфа-клик», ткнул, перебросило на вебмани почему-то. Это что за прикол такой? Я думал мне инвойс выставят, который я со счета заплатить смогу, при чем тут вебмани?
И еще момент. Нашел я книгу, хочу посмотреть качество перевода, жму «Читать отрывок», и тут мне предлагают регистрироваться/логиниться. Оно мне надо?
Мне кажется, что наименование банка лишнее.
Вбивать наименование «Объединенный Офигенный Великодержавный Банк Всея Руси Вообще и Москвы В Частности», а они очень любят себя именовать подобным образом, не сильно удобно.
Номера карты, CV2, Expires и Holder — достаточно
Вбивать наименование «Объединенный Офигенный Великодержавный Банк Всея Руси Вообще и Москвы В Частности», а они очень любят себя именовать подобным образом, не сильно удобно.
Номера карты, CV2, Expires и Holder — достаточно
и поле «Email» кстати тоже лишний для оплаты картой
C Email еще можно смириться. На него параметры заказа придут. Если делать его опциональным, обязательно найдется уникум, который его не укажет, номер заказа не запомнит и будет потом долго любить мозг техподдержке.
Ну судя по заголовку окна «Пополнение кредитной картой» я предполагаю что пользователь уже зарегистрирован в системе (так как пополнять несуществующий счет, наверное, смысла нет), так что email пользователя уже есть. Если же происходит покупка новым пользователем, то поле e-mail можно сделать опциональным и в случае его отсутствия показывать по завершении покупки параметры заказа и персональную ссылку на скачивание книжки. Еще можно кнопку сделать «Отправить параметры заказа на EMail».
Как-то так.
Как-то так.
Вы правы, наименование банка для совершения платежа не нужно, как и Holder (нигде в техническом взаимодействие с VI/MC не использует это поле). Но для антифрода наименование банка полезно, как и cardholder.
Чтобы не вводить названия банков, достаточно ввести 4 символа, после чего будет предложены выбрать из списка.
Чтобы не вводить названия банков, достаточно ввести 4 символа, после чего будет предложены выбрать из списка.
Хм… ajax работает только в веб-форме.
Вы представляете размер списка наименований банков содержащих эти 4 символа при всем их (банков) многообразии? ))))
Я так думаю что на телефоне придется скролить оченно долго.
Я так думаю что на телефоне придется скролить оченно долго.
«Чтобы не вводить названия банков, достаточно ввести 4 символа, после чего будет предложены выбрать из списка.»
Достаточно ввести номер карты. По номеру карты можно однозначно идентифицировать банк-эмитент. Так что требование вводить название банка или от лени или от дури.
Достаточно ввести номер карты. По номеру карты можно однозначно идентифицировать банк-эмитент. Так что требование вводить название банка или от лени или от дури.
Я же объяснил выше, что нужно для антифрода.
Поле cardholdername можно всегда считать равным CARDHOLDER NAME и платежи будут проходить. В принципе, платежи без cvc2/cvv2 тоже можно проводить. Не означает же это, что не нужно требовать эти данные.
Поле cardholdername можно всегда считать равным CARDHOLDER NAME и платежи будут проходить. В принципе, платежи без cvc2/cvv2 тоже можно проводить. Не означает же это, что не нужно требовать эти данные.
Если данные по карте куплены, выяснить банк по BIN-у не такая уж большая проблема, особенно тому, кто такими делами промышляет профессионально (если не экзотика какая-нибудь). С CARDHOLDER NAME тяжелее. Если реквизиты карты переписал злоумышленник (официант, например), то название банка он также успешно перепишет, уверяю вас. Так что доп защиты по сути никакой, а геморроя пользователю добавили.
Хотите защиты от фрода, надо юзать Verified by Visa или MasterCard SecureCode.
Хотите защиты от фрода, надо юзать Verified by Visa или MasterCard SecureCode.
3-D Secure (Verified By Visa И MasterCard SecureCode) позволяет переместить отвественность на держателя карты, но от фрода защищают не шибко. Карту, подписанную на 3-DS можно легко авторизовать по обычному e-commerce, и тогда 3-ds код запрашиваться даже не будет (т.е. можно и без 3-ds кода провести операцию).
В антифроде, чем больше данных тебе известно о плательщике, об устройстве, с которого проихзводится оплата, тем более точный скоринговый rate можно присвоить операции.
В антифроде, чем больше данных тебе известно о плательщике, об устройстве, с которого проихзводится оплата, тем более точный скоринговый rate можно присвоить операции.
«Карту, подписанную на 3-DS можно легко авторизовать по обычному e-commerce»
Не понял, это как? Если не трудно, объясните в 2-х словах.
Не понял, это как? Если не трудно, объясните в 2-х словах.
Сначала 2 момента ввода в тему:
1. Если эмитент поддерживает 3-DS эмиссию, то его карты бывают подписаны на 3-DS в эмитенте (enrolled), и бывают не подписаны. А бывает так, что эмитент не поддерживает 3-DS эмиссию.
2. Есть различные режимы авторизации транзакции эквайером
ECI5: 3-DS acquirer only, т.е. эквайер поддерживает 3-DS, а эмитент нет
ECI6: Full 3DS, т.е. и эквайер поддерживает 3-DS и карта была подписана на 3-DS
ECI7: Secured e-Commerce, т.е. эквайер направил авторизационный запрос с указанием что 3-DS не нужен
Теперь про авторизацию.
В последнем случае (ECI7), как раз и возможен сценарий, когда 3-DS enrolled карты пройдет по e-Commerce, т.е. код не затребуют, это правда регулируется банками-эмитентами, они могут дать отказ. НО, эмитенту в этом случае даже более интересно провести авторизацию, поскольку ответственность (liability shift) не нем, а на эквайере.
1. Если эмитент поддерживает 3-DS эмиссию, то его карты бывают подписаны на 3-DS в эмитенте (enrolled), и бывают не подписаны. А бывает так, что эмитент не поддерживает 3-DS эмиссию.
2. Есть различные режимы авторизации транзакции эквайером
ECI5: 3-DS acquirer only, т.е. эквайер поддерживает 3-DS, а эмитент нет
ECI6: Full 3DS, т.е. и эквайер поддерживает 3-DS и карта была подписана на 3-DS
ECI7: Secured e-Commerce, т.е. эквайер направил авторизационный запрос с указанием что 3-DS не нужен
Теперь про авторизацию.
В последнем случае (ECI7), как раз и возможен сценарий, когда 3-DS enrolled карты пройдет по e-Commerce, т.е. код не затребуют, это правда регулируется банками-эмитентами, они могут дать отказ. НО, эмитенту в этом случае даже более интересно провести авторизацию, поскольку ответственность (liability shift) не нем, а на эквайере.
Спасибо. Я так понимаю, работать только по ECI6 эквайеру не выгодно из-за большого количества карт не поддерживающих 3-DS?
Эквайеру всегда выгодно работать по ECI5 или ECI6, эквайеров в первую очередь заботит безопасность (при ECI5 и ECI6 ответственность на эмитенте), во вторую обороты. Мы у себя в PayOnline разработали 2-х стадийную авторизацию: сначала пустим по ECI5/ECI6, а потом, если не удалось из-за отказа эмитента — по ECI7. И трафик в норме, и с безопасностью все ок.
Блин, iOS TabBar в Android-приложении. Жуть! Разработчики читали вообще Android Design Guidelines?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Все книги в одном мобильном приложении