Транзакция отклонена: что делать с несостоявшимися платежами по банковским картам в интернет-магазине Статьи редакции

Бизнес-аналитик, консультант сферы электронных платежей Владимир Долголевец написал для рубрики Growth Hacks колонку о том, что делать с несостоявшимися платежами по банковским картам в интернет-магазине: причины отказов в проведении транзакций, пользовательские сценарии для подобных случаев и типичные ошибки, совершенные при проектировании сервиса.

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

Про конверсию много написано — читателей ЦП не удивит, что это отношение посетителей сайта к пользователям, совершившим покупку (оплату). Если посмотреть чуть глубже (ведь у всех настроены инструменты для этого?), то окажется, что кнопку «Оплатить» нажали 2% пользователей (здесь и далее цифры вымышлены, но близки к реальности), но конверсия составляет 1,5%.

Что же произошло с 0,5% пользователей и какие причины потери целевого трафика, ведь пользователь, который нажал «Оплатить» (прошу не путать с «Купить» и перемещением товара в корзину) — это целевой трафик, который вы привлекли на сайт, заплатили за лид (или какая у вас модель привлечения), но не получили с него денег.

Переходя к ответу на вопрос «Где полпроцента?», посчитаем, сколько стоит это знание, на простом примере.

DAU сайта — 100 000 пользователей.

Средний чек (вариант — сумма ввода денег на пользователя в день) — 100 рублей.

2% от DAU * 100 рублей = 200 000 рублей в день.

Получается, что 0,5% — это 50 тысяч рублей в день или 1,5 млн в месяц (все плюс-минус, естественно, и без учета стоимости привлечения трафика).

Опираясь на свой опыт, могу разделить причины на следующие, наиболее популярные категории:

• Нет денег на карте.
• Транзакции, которые были отклонены антифрод-фильтрами.
• Некорректные настройки Merchant account.
• Работа процессингового центра.
• Ошибки UI, UX, копирайта.

Теперь подробнее про каждый из вариантов.

Очень жизненный сценарий. Из практики около 40% отклоненных транзакций появляются именно по причине отсутствия средств на карте плательщика. Пользователь хочет воспользоваться платной услугой, но у него нет денег — это проблема как ваша, так и пользователя. Сценарии работы с пользователями такие:

• Пользователь известен и уже совершал платежи на сайте или в игре. В данной ситуации мне нравится вариант работы с лояльностью, когда на ответ от процессингового центра с информацией о недостатке средств, вы в явном виде информируете, что N покупка на сайте для пользователя в подарок. «Подарок предоставляется один раз в (период), спасибо, что с нами». Ожидаемый эффект для пользователя — сайт не хочет заработать на мне денег за каждый чих.
• Пользователь неизвестен и никогда не совершал платежи на сайте или в игре. В явном виде проинформировать об отсутствии средств и предложить альтернативный вариант оплаты — платежные системы или популярные сервисы по предоставлению онлайн-кредитования. По кредитованию могу предложить тестировать разные варианты, например, сервисы, предоставляющие онлайн-микрозаймы прямо на карту (к сожалению, такой вариант не успел попробовать).
• Пользователь известен, но никогда не совершал платежи на сайте или в игре. В некоторых процессинговых центрах (ПЦ) существует вариант отложенной покупки, когда ПЦ с заявленной периодичностью пробует тарифицировать пользователя (списать деньги с карты). Таким образом кейс выглядит следующим образом: вы получаете ответ о недостатке средств на карте, выдаете покупку или зачисляете деньги на счет, информируете пользователя о том, что покупка была выдана, но средства с карты списаны не были, «пополните счет в течение (количество дней, которые тарифицирует ПЦ)». В этом же кейсе можно разработать свою систему кредитования, но это чревато накладными расходами на реализацию собственной системы антифрод-фильтров, blacklist-пользователей, а так же системой скоринга. С трафиком «Одноклассников» или «ВКонтакте» должно окупаться, во всех остальных случаях, думаю, не стоит.

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

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

Свои антифрод-системы есть как у ПЦ, так и у банка.

Какие встречал варианты:

• карта эмитирована банком РФ, пользователь совершает платеж за ее пределами — платеж отклонен;
• последняя транзакция в РФ, последующая за ее пределами — платеж отклонен;
• пользователь ранее опротестовывал транзакции и возвращал средства (refund), прошедшие через конкретный процессинг — платеж отклонен;
• пользователь ранее опротестовывал и возвращал средства (refund) при покупках у конкретного мерчанта — платеж отклонен;
• email пользователя не совпадает с тем, который был указан при последней успешной транзакции (в случае, если поле email передается и указано в настройках);
• номер телефона пользователя не совпадает с тем, который был указан при последней успешной транзакции (в случае, если поле «номер телефона» передается и указано в настройках).

Это только те варианты, которые поддаются осмыслению, многие другие, кроме как эвристикой, не назовешь.

Что можно сделать в таких случаях? Опять же несколько вариантов на выбор:

• Если пользователь и его платежная репутация вам известны (это значит, что не было прецедентов возврата средств), вы можете написать письмо в ваш ПЦ с просьбой предоставить данному пользователю возможность оплачивать, несмотря на выявленную с их стороны угрозу. С большой долей вероятности, такой сервис вам афишировать не будут, и информация будет доступна в зависимости от уровня лояльности ПЦ к вам (читай оборотов вашего проекта). В любом случае, ответственность за возможные убытки вы полностью берете на себя и подписываетесь под возможными рисками.
• В остальных случаях рекомендую разделять и считать отдельно каждый из типов ошибок в каждой категории, и уже на основании частоты и сумм отклоненных транзакций принимать решение.

В данную категорию отношу все отклоненные транзакции, которые не прошли потому, что столкнулись с какими-либо ограничениями, которые вы же сами и указали в договоре при подключении к ПЦ.

Какие могут быть варианты:

• минимальная и максимальная сумма транзакций для одной покупки;
• максимальная сумма транзакций в сутки;
• максимальная сумма транзакций в месяц;
• ограничение по географии — перечень стран-эмитентов карты;
• ограничение по типу платежной системы (ПС).

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

Лимиты на минимальную и максимальную сумму одной покупки — ограничение разовой транзакции. Если в настройках стоит минимум 100 рублей, а в вашем платежном интерфейсе (или каком-либо сервисе) есть тариф 80 рублей — вы обманываете пользователя, такая транзакция не пройдет и вы сами этому причина. Справедливо и в большую сторону.

Лимиты на ограничение суммы транзакций в сутки или месяц (max). Простой кейс: пользователь совершает в игре три покупки 500 рублей, 1000 рублей и 3000 рублей. Установленный лимит — 3000 рублей — будет означать, что первые два платежа будут выполнены, но третий будет отклонен, а с ним ARPU, средний чек, доход и лояльность к вам будут не такими, как могли бы.

Ограничение по географии. Тут все просто, если карта выпущена банком Китая, но он отсутствует или выключен в настройках вашего аккаунта — оплатить не получится. Есть тонкий момент, что существуют настройки по умолчанию, в которых исключены страны с высоким уровнем киберпреступности — проверяйте.

Ограничение по типу ПС. В платежных интерфейсах многих сайтов отсутствуют специфичные, но популярные ПС, например, JCB (Japan Credit Bureau), а ведь они эмитируются не только в Японии, но и в 19 странах мира, где так же могут быть ваши пользователи, которых можно огорчить.

Сюда отношу все плановые и внеплановые работы, uptime системы и серверов партнера (кстати, вы знаете, где они хостятся)?

Рекомендация — подписаться на дайджест новостей данного хостинга, информация лишней не будет. Сколько стоит недоступность вашего ПЦ для вас? Фактически, это сумма, которая в среднем проходит через процессинговый центр в минуту (все понимают, что в разное время она будет отличаться), для крупных проектов решением будет включить дублирующего партнера для процессинга. Решение о его необходимости вам помогут принять цифры простоя приема платежей по картам, например, за последний месяц.

Что учесть — ПЦ должны работать, используя шлюзы разных банков.

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

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

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

• Если вы знаете, что платеж отклонен по причине отсутствия денег на карте, текст «Платеж отклонен» смотрится не так дружелюбно, чем «Недостаточная сумма для совершения покупки, выберите другой способ оплаты или пополните счет».
• Кнопка «Оплатить», при клике на которую открывается страница ПЦ в новой вкладке не подразумевает платеж, а предлагает заполнить данные карты для оплаты. Целевое действие — «Перейти к оплате».
• Если я плачу картой постоянно, предложите мне запомнить этот способ оплаты, рекуррентные платежи уже давно ни для кого не секрет, реализуйте их для ваших пользователей.
• Все еще встречаются сайты, в которых вкладка для ввода платежных реквизитов или ввода пароля 3DS блокируется браузером. Моя мама и ее подруги никогда не завершат оплату в таком сценарии, как бы они ни хотели купить ваш товар.
• Cвои примеры можно написать в комментариях.

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

Для всех сценариев, к которым описывал юзкейсы, ошибки предлагается обрабатывать на стороне мерчанта. Все они представлены в документации ПЦ по интеграции, для работы нужно организовать подсчет каждого типа ошибки, спроектировать и «задизайнить» свой вариант отображения сценария для пользователя.

Тезисно основные мысли:

• Конверсией платежей по картам можно и нужно управлять.
• Наибольший эффект от реализации ожидается для проектов с высокой посещаемостью и большой долей платежей по картам. Для интернет-магазинов с объемом 20 заказов в день — эффекта не будет.
• Считайте платежи, которые не дошли до результата (их количество и сумма).
• На основании знания о потенциале платежей по картам можно выстроить систему мотивации или KPI вашего финансового аналитика.

#кейсы #интернетмагазины #банковскиекарты