Pull to refresh

Comments 22

По моему очень не удачное оформление статьи. Читать невозможно.
Одни спойлеры, списки, постоянно меняющийся шрифт. Зачем скрывать каждый скрин под спойлер? Если их не открывать, то куски текста просто перестают быть хоть как-то связанными и теряют смысл. У вас идут заголовоки разделов и весь текст в этих разделах находиться под спойлерами. ???

То есть в целом фрейм вместо редиректа отпугивает клиентов? Думаю, разницу в iframe между http и https мало кто заметит.


К советам — у одной платежки столкнулись с тем, что попытка инициации сеанса оплаты или верификации карты их жс-скриптом на странице, который создаёт фрейм по документации и по факту на десктопах и больших планшетах, на мобильных устройствах с относительно небольшим экраном приводит к редиректу с нашей страницы на их с возвратом на ту же нашу страницу где были, причём возврат чисто по referer, а не по истории браузера, узнать что вернулся юзер а не сам дошел, тоже только по referer, и вообще это никак не документировано, редирект или фрейм предлагается на выбор с немного разными параметрами, но ни слова о том, что выбора иногда нет. Как красиво обойти не придумали пока. Наиболее просто выглядит отказ от фрейма и самостоятельном редиректе с явным указанием страницы возврата всегда.

> фрейм вместо редиректа отпугивает клиентов
В той компании, где это делалось — да.
Там есть определенная специфика рынка, которая вызывает недоверие.
О общем случае мне кажется, что будет ли пользоваться народ фреймом зависит от доверия к бренду и бизнесу в целом. Если рынок «спорный», то возникнут сложности.

> Наиболее просто выглядит отказ от фрейма и самостоятельном редиректе с явным указанием страницы возврата всегда.
Тут я точно могу советовать один принцип — действий без ведома клиента (открытия, закрытия, переходы итд) — должно быть как можно меньше и все должно быть как можно проще. Еще при чтении документации сервисов создается впечатление, что части посвященной удобству конечного клиента там уделено гораздо меньше, чем безопасности (логично), и многие «продвинутые» фичи никем не используются и не протестированы.

Конечно можно принимать на своей стороне, но я не знаю сколько точно стоит PCI DSS.

Ссылка на архив
чет не работает :(
Меня бесит, когда некорректно или вообще не используется хранилище кредитных карт от Google Chrome.
image
Согласен, но оно позволяет мимикрировать эффект от PCI DSS
Но мне кажется penetration пользователей такого решения весьма низкий все равно
Еще по поводу интерфейса: сильно мешает разбивка номера карты на 4 поля — в таком варианте очень плохо работает автозаполнение номера карты из хрома.
Да, мы как вы видите, в итоге тоже к этому пришли.
Разделение делается чисто визуально для красоты.
Спасибо за полезный материал! А про PayPal не планируете поделиться опытом?

Для меня настройка подключения PayPal была сродни прохождению аркады: запрятанные кнопочки, секретные ссылки, запутанный классический и неклассический интерфейс. Отличие интерфейса PayPal российского от зарубежного. Удивляет как такая мегакорпорация не может сделать понятным способ настройки.
Идеальный (без всяких почти) UX формы оплаты сделали в Яндекс.Деньгах:
image
Весьма согласен.
Но вот беда — ставка у них не самая привлекательная, особенно для крупной компании.
И почту они собирают у ваших клиентов… =)

Сравните этот дизайн…
image
И этот дизайн…
image
Найдите 5 различий =)

Я показал эту статью коллегам из Яндекса, они попросили поменять всего лишь одну юридическую мелочь про связь их компаний.
Так что все норм =)
У второго тоже есть автоопределение банка и МПС? В вашем варианте много пустого пространства (правда я не видел мобильную вёрстку формы ЯД), слабый контраст между «сторонами карты» и CVC не на своём месте.
1
Автоопределение банка — это скорее визуальный мусор (мое личное мнение).
МПС — конечно — это позитивно влияет на конверсию.

2
Его много, т.к. форма «резиновая». Она подстраивается под размер и разрешение экрана.
Пройдите по ссылкам, скачайте — увидите.

3.
Про контраст и CVC — это было решение дизайна, т.к. когда экран меньшге, выглядит совсем иначе.

По поводу сложностей с PCI DSS — всё немного преувеличено. Если у вас не огромные обороты(уровень сертификации PCI DSS не выше Level 3 — от 20 тыс. до 1 млн. транзакций в год), то сложностей больших нет, но есть затраты — порядка 500 евро в квартал. Вам надо будет заключить договор с QSA аудитором(список QSA можно найти вот — здесь.

Раз в квартал надо будет проходить ASV сканирование сайта, на котором идёт ввод карточных данных и раз в год заполнять опросник SAQ. Первое ASV сканирование будет для вас сюрпризом, скорее всего, так как в отчёте будет много страниц, связанных с уязвимостями и способами их устранения :-) Для подтверждения статуса надо будет их оперативно ликвидировать и пройти повторное сканирование (обычно повторное тоже стоит денег).

Из плюсов — вы сможете кастомизировать форму оплату, как вашей душе угодно + не будет не нужных переходов на сайты агрегаторов/платёжных систем. Но, как справедливо заметил автор, если вы никому неизвестны, то это может снизить конверсию, а если известны — повысить. Люди опасаются вводить карточные данные на сайтах, которые им не известны. Также, благодаря регулярным сканированиям, можно быть уверенным, что ваш сайт соответствует требованиям безопасности и его не так просто сломать :-)
Крутой комментарий. Теперь, если я когда-либо буду опять отвечать за весь эквайринг интернет компании, как раньше, сразу буду планировать и узнавать.
Теперь есть название черного ящика — имея название — можно ковырять.

В любом случае сравнивая уровень бардака и п… а, на который я пришел, PCI DSS все равно не кажется оправданным шагом даже в ретроспективе, особенно с учетом того, что внутри фрейма конверсия таки упала…

Но в мобильных приложениях можно нехило сэкономить имея грамотную форму вписанную во фрейм.

Раз такая пляска — подписывайтесь на наш канал — там много такого же интересного =)
Может тоже напишете нам на сайт что-то =).
Объясните мне почему на многих подобных страничках блокируют ввод CVC через буфер обмена? Обязательно надо вводить циферками с клавиатуры.
Скорее всего потому, что по документации банков там особый тип input-а нужен.
Не уверен, что у нас это было запрещено.
Мол типа «секъюрно».
Самое лучшее решение для интернет-эквайринга видел только у CLoudPayments, никакого редиректа на сторонние сайты, ри этом не надо получать PCI DSS.

А как реализовано? Фрейм?

Там скрипт прописывается через их API. Фрейм не нужен.

В DOM где лежат инпуты, в самом документе? Или всё же фрейм, пускай и динамически формирующийся скриптом?


Мы когда анализировали варианты, пришли к выводу, что в своём документе и(или) пространстве JS нельзя хранить номера и т. д. ни под каким видом без PCI DSS, только если скрипты эквайера либо редирект делают на его сайт, либо открывают фрейм, изолированный (в рамках стандартов на браузеры) от нашего сайта. В иных случаях мы можем получить платежные данные и отправить их к себе или третьим лицам — пускай даже под нашим контролем они будут находиться миллисекунды, но будут.

У них хорошая документация но высокие ставки.
Если не хочется проблем с переводом денег Яндекс лучше имхо.
Sign up to leave a comment.

Articles