Чеклист для проверки форм оплаты банковскими картами

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

    Впрочем, многие на этих достаточно простых и понятных вещах делают продукты и, следовательно, деньги.

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

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://baymard.com/blog/visually-reinforce-sensitive-fields
• http://gigliwood.com/blog/designing-the-perfect-credi.html
• https://www.lukew.com/ff/entry.asp?1667
• http://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

 

    Автор и эксперт: Борис Богданов.

 

Интересное...

• ...про армию
• ...депутаты запретят лекарства и алкоголь
• ...заблокировали телеграмм

Другие посты по этой теме: