В работе с фродом и диспутами мерчанты сталкиваются с различными типами платежей и ситуаций. Согласно построенной Visa и Mastercard системе, владелец карты не может просто решить, что хочет получить средства обратно за свою покупку или, что он передумал пользоваться услугой, которую купил. Ему придется подкрепить свое желание вернуть средства реальными причинами, которые строго регламентируются. Здесь есть как возможности, так и ограничения.
Платежные системы создали четкий алгоритм, как клиенты могут защитить свои права, и также, как мерчанты могут сделать то же самое. И ключом к эффективному использованию этой системы становится понимание ее правил и причинно-следственных связей.
Итак, сегодня мы разберем основные коды чарджбэк операций, с которыми сталкиваются цифровые мерчанты — какие они бывают, что за ними стоит и как оспаривать каждый из них (и нужно ли это делать).
Один из самых частых кодов чарджбэка в электронной коммерции и цифровых продуктах, когда держатель карты заявляет, что оплатил, но товар или доступ к сервису не получил. Под этот код попадают принципиально разные ситуации: физический товар, который потерялся при доставке, цифровой продукт, который не был активирован из-за технического сбоя, и случаи, когда клиент все получил, но предпочел пойти в банк, а не в поддержку мерчанта в попытке «обмануть систему».
Чтобы уверенно представлять интересы мерчанта в таких ситуациях, необходимо обеспечить доказательную базу факта предоставления услуги клиенту. Поскольку на слово в этом процессе никто не поверит — логи, отслеживание действий клиентов на платформе можно считать мастхэвом. Вы должны иметь железные доказательства того, как и когда вы представили сервис клиенту. Для физических товаров это трекинг с отметкой о получении, для цифровых — история сессий, IP входов, дата и время активации, вид браузера, контактные детали клиента, история использования. Чем детальнее можно показать, что клиент реально взаимодействовал с продуктом после оплаты, тем убедительнее ваша позиция при оспаривании. Письмо с подтверждением доставки или активации сразу после транзакции работает и превентивно, так как позволяет усилить коммуникацию и избежать ошибочных споров.
Этот код описывает ситуацию, когда клиент товар или услугу получил, но остался недоволен тем, что именно получил: характеристики оказались другими, качество не совпало с ожиданиями, физический товар пришел поврежденным или не работающим (если это техника). На практике его нередко используют и как удобный инструмент обхода — вместо того чтобы разбираться с поддержкой и ждать возврата, часть клиентов просто открывает диспут, потому что это быстрее, но товар не всегда действительно дефектный.
Здесь принципиально важно то, что именно было обещано на момент покупки. Описание продукта, фотографии, технические характеристики, условия предоставления услуги — все это становится отправной точкой для оспаривания. Если страница продукта была точной и актуальной, а клиент получил именно то, что там описано, это нужно показать документально: скриншоты с датой, спецификации, версия страницы на момент транзакции. Дополнительно усиливают позицию любые следы коммуникации с клиентом, в которых он не поднимал вопрос несоответствия.
Для физических товаров полезны фото фиксация при упаковке и документы, подтверждающие комплектацию. Точные описания и актуальные фото работают и на опережение — они снижают не только количество диспутов, но и число клиентов, которые чувствуют себя обманутыми. Для цифровых товаров здесь может быть сложнее, однако, такие товары не могут быть повреждены при доставке (чаще всего) и поэтому главным для мерчанта будет наличие четкого описания цифрового товара, которую получит клиент.
Один из самых болезненных кодов для мерчанта — и один из самых размытых по своей природе. Держатель карты заявляет, что не совершал транзакцию и не давал на нее согласия. За этим может стоять, как реальный несанкционированный доступ к карточным данным, так и, так называемый friendly fraud, — когда клиент покупку совершил сам, получил что хотел, а потом решил оспорить списание по «удобному» коду.
Разграничить одно от другого на практике бывает непросто, и именно в этом основная сложность работы с данными чарджбэками. Для оспаривания необходимо собирать косвенные доказательства того, что плательщик и держатель карты — одно лицо: совпадение адресов доставки и оплаты, история покупок с того же устройства и карты, подтвержденный адрес электронной почты, IP-адрес в той же стране, что и эмитент карты, история использования сервиса после оплаты. Чем больше точек совпадения удается показать, тем убедительнее позиция.
Если транзакция прошла через 3DS-аутентификацию, это существенно помогает оспаривании в сторону мерчанта, поскольку банк клиента проводил аутентификацию в момент оплаты — а значит подтвердил личность плательщика. Карточные данные довольно часто утекают в сеть или их целенаправленно крадут, "пакетные кражи" сразу всех данных (доступа в онлайн банкинг, телефона, адреса, почты) происходят значительно реже.
Этот код возникает, когда карта клиента была списана дважды за одну и ту же покупку. Причины бывают разные: технический сбой на стороне мерчанта или процессора, двойная отправка формы оплаты, ошибка при повторной попытке транзакции. Иногда клиент сам нажимает «оплатить» несколько раз, не дождавшись ответа системы, и получает два успешных списания.
Это один из немногих кодов, где оспаривание имеет смысл только в том случае, если дублирования на самом деле не было. И такие случаи бывают довольно часто, когда плательщик пытается сэкономить постфактум и отозвать часть своих одинаковых платежей, если он покупал цифровые товары в короткий промежуток времени за одну и ту же стоимость или пополнял баланс своего аккаунта. Если две транзакции действительно разные — по сумме, дате, товару — это нужно четко показать в документах: выписка по обеим операциям, описание того, что именно было оплачено в каждом случае. Если же дубль реальный, гораздо разумнее сделать рефанд самостоятельно до того, как ситуация эскалируется — это дешевле и не повлияет на показатели чарджбэк рейтов. Превентивно вопрос решается на уровне платежной логики: проверка на дубли и блокировка повторной отправки формы оплаты убирают большинство таких случаев еще до их появления.
Один из самых распространенных кодов в подписочном бизнесе. Клиент отменил подписку — или считает, что отменил — а списание продолжилось. Он может обратиться в банк, и мерчант получает диспут, который при определенном масштабе бизнеса превращается в системную проблему.
Для оспаривания здесь нужно показать одно из двух: либо что отмена в систему мерчанта не поступала и задокументированных подтверждений этого нет, либо что списание произошло до момента отмены в соответствии с условиями подписки, с которыми клиент соглашался при регистрации.
Логи системы, скриншоты личного кабинета, история коммуникаций — все это работает в пользу мерчанта. Если же клиент отменил корректно, оспаривание не имеет смысла: рефанд в таких случаях выгоднее проигранного диспута и сохраняет уровень чарджбэков в норме. Превентивно этот код лучше всего закрывается операционно — уведомление перед каждым списанием, простая и понятная процедура отмены и письмо с подтверждением отмены на электронный адрес убирают большую часть таких диспутов еще на стадии недовольства клиента.
Этот код возникает на стыке клиентского сервиса и операционного процесса: клиент вернул товар или отменил услугу, мерчант обещал рефанд, но деньги на карту так и не вернулись. Иногда возврат был инициирован, но клиент его не увидел или не дождался и открыл диспут раньше, чем средства появились на счету.
Основа оспаривания здесь — подтверждение того, что рефанд был инициирован: дата, сумма и номер транзакции возврата. Если возврат все еще в обработке, это тоже можно показать с детализацией по времени. Нередко такие ситуации решаются через прямую коммуникацию без полноценного разбирательства — особенно если мерчант может оперативно предоставить доказательства. Превентивно этот код закрывается проще всего: четкие сроки возврата в политике и автоматическое уведомление клиента о статусе рефанда снимают большинство подобных кейсов до того, как клиент успевает задаться вопросом, где его деньги.
Существуют и другие возможности отозвать платеж, однако, описанные нами выше являются самыми популярными, так как покрывают основные клиентские кейсы. При настраивании работы с фродом важно понимать, что сам по себе чарджбэк не является абсолютным злом системы, однако, есть много плательщиков, которые находят способы использовать этот процесс для нечестных целей. Несмотря на это, часть чарджбэков может быть полноценно легитимной.
В данном случае задача мерчанта — минимизировать случаи, когда клиент действительно может столкнуться с необходимостью оспорить платеж, представляя качественный сервис и поддержку. А для борьбы с абьюзерами системы придется построить качественную техническую базу и процедуры защиты в рамках правил Visa и Mastercard.