вторник, 17 апреля 2018 г.

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

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

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

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

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






  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/

 

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

 

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

 

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




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



Комментариев нет: