На днях сугубо по работе попытался формализировать набор требований по тестированию платежных форм. Речь в данном случае о банковских картах, но принципы общие для всего. За исключением некоторой узкотематической специфики, правила применимы почти везде. Впрочем, многие на этих достаточно простых и понятных вещах делают продукты и, следовательно, деньги.

Совсем общие принципы:

1. Мы не пугаем пользователя. Ему в каждый момент должно быть понятно, что происходит и зачем.
2. Достичь результата, т.е. заплатить должно быть максимально просто. Мы не должны спрашивать у пользователя то, что можем узнать сами.
3. Мы делаем вещи, затрагивающие платежи, т.е. мы должны заботиться о безопасности и соблюдении формальных требований (законодательство, требования МПС и т.д.).

А теперь ближе к делу:

1. Общее
   1. Только https, только PCI DSS
   2. Поддерживаем все типы карт. Не забываем, что есть карты с длинной номера отличной от 16.
   3. На странице есть все необходимые по стандартам элементы (логотипы Visa/MasterCard, если требуется – оферта с условиями проведения платежа)
   4. На странице есть информация о заказе. Сразу понятно, что оплачивает человек.
   5. Не спрашиваем то, что и так можем узнать (например, тип карты мы можем определять по БИНу)
   6. Страница корректно ведет себя в iframe и в полноэкранном режиме
   7. Форма нормально работает на мобильных.
      • “Складывается” под размер экрана
      • fat-finger-friendly
      • Клавиатуру показываем по типу содержимого. Например, для номера карты – цифровая клавиатура.
   8. Понятно, как выводить доп. поля, иногда необходимые для проведения платежа (доп. поля для фрод-мониторинга, хайриск и т.д.)
   9. Понятно, как делать рекурренты
   10. Форма в полном размере максимально повторяет внешний вид карты (вкусовщина, по хорошему надо ставить эксперименты)
   11. CVC корректно/понятно подписан
   12. Есть контактные данные саппорта
2. Валидация
   1. expiry date не в прошлом
   2. Номер карты проходит валидацию по Luhn (https://ru.wikipedia.org/wiki/Алгоритм_Луна)
   3. Пропускаются короткие имена/фамилии (1-2 буквы) и составные фамилии (содержат дефис)
3. Поведение
   1. Номер карты можно скопировать и вставить в форму. Более того, форма должна быть дружественна к приложениям, сохраняющим и заполняющим данные карты (1password, iCloud keychain и т.д.)
   2. Цифры в номере карты форматируются по группам
   3. Между полями можно переходить по табуляции. Последовательность перехода соответствует визуальному расположению полей на форме.
   4. Вбиваемая кирилица приводится к латинице. Все буквы приводятся к верхнему регистру
4. Доп. функционал (специфично для интеграторов, но… мало ли)
   1. Кастомизируется под мерчанта – фоны-логотипы
   2. Максимально много информации для предзаполнения можно передать со стороны мерчанта
   3. Понятно, как делать рекурренты – https://www.chargify.com/, https://recurly.com/

Ссылки в порядке занимательного чтения:

• https://jessepollak.github.io/card/
• https://creditcardjs.com/
• https://kenkeiter.com/2013/07/21/redesigning-credit-card-inputs/ -- https://news.layervault.com/stories/6355-beautifully-designed-credit-card-form
• https://baymard.com/blog/visually-reinforce-sensitive-fields
• https://gigliwood.com/blog/designing-the-perfect-credi.html
• https://zoliang.com/post/37178942744/making-beautiful-forms-square-and-recurly
• https://www.lukew.com/ff/entry.asp?1667
• https://bradfrost.com/blog/post/single-field-credit-card-input-pattern/
• https://designmodo.com/ux-credit-card/
• https://designmodo.com/ux-credit-card-payment-form/
• https://dribbble.com/shots/797913-Credit-Card-input

Запись добавлена 31.12.2014 в 1:02. Автор Boris Bogdanov. Категории: Без рубрики. Комментарии к этой записии можно отслеживать по RSS 2.0. Комментарии и пинги запрещены.