Платежные странички и решения (или через тернии к звездам — и через много картинок) +14


image
TLDR для нетерпеливых — в принципе можно закрывать статью

Так уж сложилось, что я принимал участие в создании / управлении / переговорах с большим количеством банков и платежных систем, которые предоставляют услуги онлайн-эквайринга в России. Это происходило на ряде мини-проектов с абсолютно разными провайдерами, но суть не в этом.

Я больше на работаю в этой сфере, но я хочу поделиться тремя аспектами онлайн платежей: i) бизнес и ситуация на рынке на 2016-2017 год (гайд для менеджера) ii) детали технической интеграции (CTO) iii) поведение клиента / дизайн / верстка платежной странички (дизайн, верстка, тестирование).

Весь этот опыт набран не сразу — примерно за 1.5 — 2 года активного ковыряния в этой сфере. Если вас не интересует бизнес опыт, а интересуют только материалы по дизайну — смело пропускайте первые спойлеры.

Список основных разделов


Заголовок спойлера
  1. Чем отличаются эквайеры, как правильно «читать» их маркетинговые материалы;
  2. Какие поведенческие особенности людей нужно учитывать в первую очередь при верстке своих платежных страниц + лог и паноптикум наших усилий в этой сфере;
  3. Насколько нам в итоге удалось увеличить конверсию и снизить ставку за все это время с указанием реальных процентов;
  4. Особенности ведения переговоров с банками и платежными решениями и как отбивать чарджбеки;
  5. Особенности технологической интеграции, плюсы и минусы, наш опыт и набитые шишки;
  6. Основные мифы или просто собранные итоги наших АБ тестов в 1 месте;
  7. Пара слов про мошенников в этой сфере;


Чем отличаются эквайеры, как правильно «читать» их маркетинговые материалы


Заголовок спойлера
Эквайринг это с одной стороны технически сложный бизнес, где нужно иметь АПИ, личный кабинет, интеграцию с банками или сервисами предоставляющими процессинг (я не до конца понимаю весь value chain в этой сфере, но он выглядит примерно так банк — VISA / MASTERCARD — процессинг — сервис онлайн экварийринга, причем возможны любые «сочетания», при которых банк, например Сбербанк, через свой или white-label софт пытается съесть всю цепочку. Чем меньше ртов в цепочке — тем выгоднее ставка.

По ставкам:

  • Сервисы-аггрераторы, которые ориентируются на массового клиента, как правило предлагают ставку 3 — 4%;
  • Эквайринги банков как правило могут играться ставкой, т.к. они могут влиять на свое внутреннее ценообразование. К примеру если ваш оборот — миллионы или десятки миллионов рублей в месяц, то вы можете претендовать на ставку 2 — 2.5%;
  • Если ваши обороты ближе к 100 млн. рублей в месяц — то можно уже говорить о ставке в 1.5 — 2% через банки;
  • Минимально возможная ставка, если вы не продаете авиабилеты или не относитесь к низко-рисковой категории по мнению банков и VISA и MasterCard ~1.5%;
  • Есть пониженные категории с низким риском, там на большом обороте можно получить ближе к 1.1%. Все цифровые услуги сюда как правило НЕ относятся;
  • Если ваши обороты еще на порядок выше, то вам уже скорее нужно проходить сертификацию PCI DSS и принимать платежи на своей стороне, но об этом дальше;
  • Если вам предлагают льготную ставку на первые X оборота или временной период — то это, скорее всего не будет работать и какой-то из сервисов просто пытается изменить свою долю пирога. А не сработает, т.к. такой любой проект интеграции — это длинная игра, и быстро как правило ничего не запускается;

Также если сервис — интегратор, то возможны любые усложнения цепочки, т.к. система становится мгоние-ко-многим). С другой стороны — это бизнес, где очень высокий фрод и ответственность за каждый переведенный рубль. Подумайте, если ваша реальная конечная комиссия в районе 0.1-0.5% максимум, а ваш оборот измеряется миллионами рублей, то потеря или опротестование одной транзакции, в котором обвинят вас — огромная потеря выручки. Примерно по этой причине банки / сервисы (сервисы, которые потеряли долю рынка — не будем называть имен) всегда стараются перевесить опротестования транзакций на мерчанта (пользователя системы, магазина).

Все разделы про бизнес нужно читать только тем, чья маржинальность составляет сильно ниже 10% — в такой ситуации разница между 4% и 2% весьма ощутима.

Также обратите внимание, что российский рынок весьма изолирован от мирового по причине изолированности банковской системы. По этой причине тут гораздо более продвинутые сервисы и гораздо больше свободы и меньше монополии. Вопреки. Частично это следствие огромного рынка обналички, который начали подрезать только в 2014-2015 годах. Как обналичка, эквайринг и электронные деньги связаны — это все альтернативные методы платежей. Когда я читаю про mPesa в Африке, на ум сразу приходит бум электронных денег в России в середине 2000-х.

Основные кластеры платежных сервисов


Заголовок спойлера
  1. While-label сервисы банков, как правило работающие на системе RBS. Отличаются медленностью изменений, более низкой ставкой, наличием технической поддержки RBS, весьма кондовым базовым сервисом (надо извращаться, чтобы сделать конфетку). Документация читабельная, но кондовая. Принимают только карты. Как правило новые попытки внедрять новое у таких сочетаний не получаются. Также отделение банка, который отвечает за сервис и сервиса означает, что по опротестованию вы будете общаться с банком;
  2. Uniteller. Еще один сервис, предоставляет аггрегатор, умеренные ставки. Позиционирует себя как более продвинутая версия RBS + ряд технологических фич + аггрегатор. На практике они предоставляют опции кастомизации, которые устарели на 3-5 лет от state-of-the-art (который уже устарел на момент написания статьи). Ну и там менеджерами работают симпатичные девочки (кому плюс, а кому нет);
  3. Новые сервисы или аггрегаторы, которые осваивают деньги инвесторов. Классное АПИ и документация, высокая ставка и ноль гарантий, что завтра к вам придут деньги. Я бы не советовал;
  4. Яндекс.Касса (сервис компании Яндекс.Деньги — совместного предприятия Яндекса и Сбербанка), их кажется Яндекс продал Сбербанку, но бренд остался). Очень адекватные люди, качественные менеджеры (как ни странно). Их существование это причина, по которой я бы не советовал использовать пункт 3. Ставки — умеренно высокие, можно немного поторговаться, если у вас большой объем, но за счет большого числа ртов ставка никогда не станет ниже 2% скорее всего. У Яндекса также есть сестринские сервисы — яндекс деньги, массовый сбор пожертвований итд. Все развивается и документация даже читабельна;
  5. Робокасса — были де-факто лидером, до того как Яндекс-деньги за год полностью заняли эту нишу (2016). Публично — из-за непоняток с их банком и поблажек по KYC процедурам. На практике в 2015 — 2016 они начали политику перекладывания всех штрафов на мерчанта. Также имеет непонятные амбиции по сбору данных ваших клиентов. По этой причине работа с ними не рекоммендуется;
  6. Пейпал — высокая ставка, хотят войти на рынок, очень устаревшее АПИ, нужно заполнять тонну полей для клиента, итд итп. С ними хорошо делать совместный маркетинг, или иметь их как запасной эквайринг и / или международное решение. В качестве основного метода — вряд ли;
  7. Все остальные более менее крупные сервисы, как мне показалось, или резко теряют свою долю, или не развиваются или не имеют реальных преимуществ перед описанными выше;
  8. У банков, RBS и Юнителлера есть опции настройки приема платежей из-за границы, но они как правило ориентированы на минимизацию рисков, а не максимизацию выручки;

Какие поведенческие особенности людей нужно учитывать в первую очередь при верстке своих платежных страниц? Летопись наших стараний


Человек, особенно в онлайне, где уже почти все население, (!!!) существо пугливое, опасливое и ничего не понимающее (!!!) (люди деньги пришли у вас оставлять). Поэтому, если вы хотите построить ментальную модель его поведения, следуйте таким принципам:

  1. Думайте про то, что непонятно типичному пользователю на платежной странице или форме заказа;
  2. Представьте, что вы продавщица магазина, которая в первый раз пользуется интернетом и хочет воспользоваться вашим сервисом;
  3. Каждая не максимально логично или просто работающая кнопка — минус 50% к конверсии;
  4. Любое подвисание или JS, который не работает как каком-то типе дивайсов — минус 50%-100% к конверсии на таком типе дивайсов;
  5. Любой дополнительный неавтоматический переход на другую страницу из формы заказа — минус 90% к конверсии;
  6. Пользователи больше доверяют переходу на сайт банка, чем вводу карточных данных на сайте без HTTPS и с низким трастом ДЛЯ ВСЕГО НАСЕЛЕНИЯ в среднем. Это значит, что если ваш бизнес белый и пушистый, но про него знает менее 1-5% населения, то люди не захотят (статистически конечно) вводить данные на вашей стороне;
  7. Удобство, адаптивность, читабельность на всех устройствах в удобном виде, правильно сделанные inputs в форме заполнения для любого типа дивайсов (если вы заморачиваетесь настолько, то эти детали я опишу дальше в пунтке 5);
  8. Правильный и красивый flow с вашего сайта (приложения) на платежную страницу, примерно похожий дизайн, отсутствие визуального мусора;
  9. Следуйте принципу снижения «трения» — простым языком — чем меньше геморроя клиенту нужно претерпеть — тем лучше (детали также в разделе 5);
  10. По секрету, забегая вперед, ПОЛЕ ВЛАДЕЛЕЦ КАРТЫ НЕ НУЖНО ДЛЯ ПРОВЕДЕНИЯ ПЛАТЕЖА;

Эти принципы звучат довольно сухо, но давайте я проиллюстрирую из на примере собственно платежных страниц. Если вам также нужно, то тут:

  1. Ссылка на папку на гугл-диске с макетами и логами тестирования (видео);
  2. Ссылка на архив на гугл-диске со всеми описанными ниже платежными страницами в HTML (там есть заморочки с настройкой скриптов для каждого эквайера, но все должно открываться или в браузере или на простейшем веб-сервере);

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

Картиночка
image

Письмо вело на такую форму, которая тоже не фонтан. Она огромная, не адаптивная, ее нельзя встроить в i-frame итд итп. Как вы понимаете — форма стоковая от Альфа банка. Она ужасна.

Картиночка
image

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

Картиночка
image

После ряда усилий, форма стала выглядеть вот так. Ясное дело, мы сменили эквайера на того, кто позволял нам играться с формой. Пока на форме очень много мусора, плюс пара клиентов позвонила в колл-центр, подумав что платеж принимает Сбербанк а не мы. Ну вы поняли.

Картиночка
image

Чуть менее убогая вариация прошлой формы. Я тут не могу передать этого, но была проделана огромная работа, чтобы поля было проще вводить, чтобы «курсор лишний раз не перескакивал», чтобы поля отображались на всех типах дивайсов корректно и удобно. Чтобы на всех типах дивайсов формы ввода отображались нативно.

Картиночка
image

Адаптивное отображение прошлой формы. Обратите внимание, что все еще присутствует большое количество визуального мусора.

Картиночка
image

Следующая итерация формы — обратите внимание, что тут уже нет «визуального мусора», лишних слов, палитра в стиле компании. Меньше — больше.

Картиночка
image

Естественно эта итерация тоже мобильная и адаптивная. Также много работы на формами.

Картиночка
image

А так выглядит финальная версия формы.

Картиночка
image

Естественно она полностью мобильная и адаптивная.

Картиночка
image

Такая же форма, но для другого эквайера (сколько боли стоило) и с опцией сохранения карты.

Картиночка
image

Важная информация для тех, у кого не очень большой бюджет на мобильное приложение

  • Если ваша платежная форма адаптивна и подстраивается по фрейм, то вы можете открывать ее в web-view в вашем мобильном приложении;
  • Это позволяет сэкономить денег на 3DS и сделать как будто не нужно переходить по ссылке из приложение в браузер в телефоне;

Особенности технологической интеграции, плюсы и минусы, наш опыт и набитые шишки


Если вы не собираетесь проходить сертификацию по PCI-DSS (это может стоить относительно много денег), то высока вероятность, что форма оплаты будет открываться на стороне банка или платежного сервиса (на его домене). Что это означает с прикладной точки зрения?

  • В совсем печальном случае, если у вас нет никакой технической возможности влиять на поведение фронтенда вашего сайта или вы продаете монопродукт, форма оплаты будет в виде ссылки в email. Ссылка будет вести на страницу банка / платежного сервиса. Открываемость / теряемость электронной почты умноженная на невнимательность клиентов (если клиенту пришло две ссылки) и ваши «кривые руки» и моменты связанные с тем, что переход не всегда отрабатывает, приводят к тому, что такое решение имеет конверсию платежей в 50%. Понятное дело, что те, кто реально хотят что-то купить попробуют снова, но это неправильно;
  • В более продвинутом случае оплата будет работать как редирект в вебе с невозможностью иметь счетчик, куку или JS скрипт на стороне платежной страницы;
  • Как правильно продвинутые JS скрипты и media запросы могут быть запрещены на стороне банка. Все нужно решать только через HTML и CSS;
  • Если вы сделаете кастомную платежную страницу и попробуете согласовать ее с платежным сервисом, то:
  • Скорее всего будут ограничения на скрипты валидации на клиенте (формула Луна);
  • Ограничение на визуальную составляющую HTML input-ов;
  • Вам придется доказывать банку, что новые HTML-теги, которые нужны для того, чтобы поля хорошо выглядели на сотовом телефоне, вам реально нужны;
  • Единственная информация, которую вы сможете получить о поведении клиента на стороне банка — это ответ АПИ платежного сервиса / банка;
  • У сбербанка периодически падает эмиссия карт и платежи перестают работать в онлайне и оффлайне. Это происходит в среднем раз в месяц;
  • На мобильных фронтендах нужно обращать пристальное внимание как страница ведет себя и отображается на основных типах дивайсов (iPhone, Android);
  • Нужно протестировать страницу 1 раз хотя бы на каждом типе устройств, популярных у клиентов вашей компании;
  • Если вы достаточно продвинуты, чтобы открывать страницу в i-frame или web-view, то пристально следите за конверсией, она может не вырасти от введения iframe — клиенты могут испугаться;
  • Внимательно прочитайте список полей, которые хочет ваш эквайринг сервис, реально нужны для проведения платежа картой ТОЛЬКО (все остальное или legacy или они собирают информацию о ваших клиентах):
  • Реально нужен — номер карты (на момент написания статьи уже может поменялось, но вследствие введения новых карт поле было 4+4+4+4-7 символов — банки не очень качественно уведомляют о таких изменениях);
  • Реально нужен — срок действия (смотрите внимательно документацию, настроить надо макимально просто для клиента);
  • Реально нужен — код безопасности (CVV / CVC 3-5 символов);
  • Платежный сервис сам откроет фрейм / сделает редирект на страницу с 3DS если он включен;

Выключение 3DS

Как правило не рекомендуется, т.к.:

Заголовок спойлера
  1. Банк / сервис переложит ответственность на вас;
  2. В интернете высокий уровень фрода;
  3. Наличие мошенников и клиентов, которые играют в «двойной» чарджбек — обращаются и к вам и в банк за опротестованием транзакции;
  4. Для некоторых типов карт российских эмитентов в принципе нельзя платить в интернете без 3DS. В частности для карт Сбербанка. А это значит, что если вы его отключите транзакция будет по умолчанию отклонена;


Еще есть один очень тонкий и важный момент, связанный с отслеживанием времени «протухания» формы:

Заголовок спойлера
  1. Большая часть платежных сервисов имеет таймаут в 20 минут (настраивается при запросе по АПИ) на оплату, который начинает идти… в момент ПЕРЕХОДА на сторону банка / сервиса, а НЕ в МОМЕНТ отправки запроса к АПИ сервиса;
  2. Если у вас есть так называемый time-to-live вашего товара или услуги, то он скорее всего от 5 минут до суток (кто-то называет это временем резервирования, кто-то как-то иначе);
  3. На практике это означает, что если у вас хотя бы 1000 заказов в месяц и / или вы отправляете дубли ссылок на электронную почту, то обязательно найдется клиент, который или:
  4. Оплатит после того, как истечет ваш time-to-live;
  5. Попытается оплатить со второй попытки;
  6. Все такие случае — по сути это геморрой для вашего сервиса поддержки клиентов (если его нет, то лично для вас);
  7. Реальное решение такой проблемы я видел только у Uniteller. Есть конечно еще более простое решение — настроить time-to-live в вашей системе примерно в 20 минут, но если ваш заказ можно забрать также оффлайн, это может быть невозможно;


Пример почти идеального UX от банка tinkoff. Не до конца понимаю, зачем тут нужен «барабан» для CVV кода (он бесит) — возможно для защиты от такого мошенничества.

image

На всякий случай еще раз приведу ссылки:

  1. Ссылка на папку на гугл-диске с макетами и логами тестирования (видео);
  2. Ссылка на архив на гугл-диске со всеми описанными ниже платежными страницами в HTML (там есть заморочки с настройкой скриптов для каждого эквайера, но все должно открываться или в браузере или на простейшем веб-сервере);

Насколько нам в итоге удалось увеличить конверсию и снизить ставку за все это время с указанием реальных процентов


Цифры ориентировочные, потому что реально отслеживать полную воронку конверсий довольно сложно. Но легко смотреть какая доля инвойсов на оплату оплачивается, а какая — нет.

Читая эту таблицу, знайте, чем отличается процент от процентного пункта. Если конверсия была 50%, а стала 55%, то она изменилась на 5 п.п.

Используемая платежная страница Примерная наблюдаемая конверсия платежного шлюза
1. Письмо на email + ссылка на сайт Альфа-Банка ~50% + было много проблем на нашей стороне
2. Редирект на сайт RBS (white-label от Сбербанка) и письмо на email для подстраховки ~60%-65% (подняли на 10-15 п.п.)
3. Редирект на сайт RBS (white-label от Сбербанка) с новой платежной страницей ~65%-70% (подняли еще на 5 п.п.)
4. Редирект на сайт RBS (white-label от Сбербанка) с финальной версией платежной страницы ~75% (подняли еще на 5-10 п.п.)
5. Редирект на сайт Uniteller (white-label от Сбербанка) с финальной версией платежной страницы ~70% — конверсия ниже чем у Сбербанка + RBS
6. Пункт 5 + открытие в iframe без HTTPS ~70% (минус 5 п.п. против пункта 5)
7. Пункт 5 + открытие в iframe с HTTPS не успел протестировать
8. Открытие в web-view в мобильных платформах примерно такая же как на десктопе

Основные влияющие факторы, которые мы выявили в итоге AB тестов (условно):

  1. Чем меньше полей и шума — тем лучше. Считайте, что каждое поле — минус 5пп к конверсии;
  2. Каждый блок, который привлекает внимание клиента — минус 5пп конверсии;
  3. Каждый логотип, картинка или надпись, которая не логично связана с вашим бизнесом — минус 5-10 пп к конверсии;
  4. Технологическая продвинутость нужна и важна, но только если КЛИЕНТ доверяет такой технологии или вашему бренду;

По идее еще есть бейджики, замочки и прочая атрибутика — но ее слава богу я не успел протестировать, ибо сначала надо решать технологические проблемы ).

Особенности ведения переговоров с банками и платежными решениями и как отбивать чарджбеки


Заголовок спойлера
  1. Банки не будут менять свои процессы под вас;
  2. KYC процессы с закручиванием гаек в экономике все более и более анальные — некоторые сервисы просят все ВПЛОТЬ до бенефициаров;
  3. Банк / сервис в худшем случае просто спишет с вас деньги (привет Пейпал, но я лично отбил эти чарджбеки на много денег) без права оспаривания в случае чарджбека;
  4. Если банк / сервис имеет процесс опротестования, то как правило если вы предоставите доказательства того, что услуга предоставлена в виде записки с подписью руководителя, которая покажет факт оказания услуги — вы можете отбить чарджбек;


Пара слов про мошенников в этой сфере


Сейчас, когда страна в рецессии — я начал замечать, что мошенники активизировались до такого уровня, что я стал сталкиваться с ними даже несмотря на фаервол в восприятии говно-сайтов, рекламы и тизеров.

Заголовок спойлера
  1. Эта схема просто гениальна. Нет слов. По сути автоподстановка с поддельного сервера по покупке билетов в форму card-2-card. PHP скрипт занимает страничку;
  2. Мошенники банальные — купили цифровой продукт, попросили вернуть деньги сразу и вас и банк. Сам цифровой продукт попытались сразу перепродать пока банк думает;
  3. Гениальный мошенники с авито — мы очень хотим купить ваш диван, только скажите нам номер вашей карты. И код из СМС. Знают как работает веб-банкинг ряда крупных банков и пытаются сыграть на этом. Если сказать им, что их телефон внесен в списки спамеров и написано заявление в полицию — обижаются и больше не берут трубку;
  4. У западных банков, которые более отсталые, случается и такое;

-->


К сожалению, не доступен сервер mySQL