Каждый год в мире появляются всё новые и новые способы оплаты. Но универсального, удобного для всех пользователей способа до сих пор нет. В 2008 году, когда мы только создавали систему биллинга для Badoo, нам казалось, что будущее за оплатой через SMS. Но, столкнувшись с реалиями разных стран, мы поняли, что это не так.Предпочтения пользователей меняются в зависимости от страны и устройства, с которого они заходят на сайт. Очень близки к идеалу оказались банковские карты, популярность которых растет из года в год, в том числе и в России. Это не только один из самых распространенных способов оплаты, но и самый прибыльный из всех доступных на сайте Badoo, а их более 20.
Сегодня мы подробней расскажем о том, что осталось за рамками предыдущей статьи о биллинге: об обработке платежей посредством банковских карт; что надо знать и к чему готовиться, если вы только собираетесь их подключать; как увеличить их эффективность, если они у вас уже есть. В целом статья рассчитана на неподготовленных читателей, но и специалисты, возможно, найдут для себя кое-что интересное.
Все началось с того, что четыре года назад мы разместили у себя на сайте форму для ввода деталей кредитных карт и начали принимать платежи. Через несколько месяцев стало понятно, что пользователи с удовольствием платят за наши услуги не только через SMS, но и картами, объем платежей по которым показывал многообещающий рост. Мы стали активно развивать это направление. С тех пор мы рассмотрели десяток платежных шлюзов, предлагающих услуги эквайринга (т. е. приема платежей по банковским картам), и сейчас одновременно работаем с тремя из них. Мы сделали поддержку платежей с 3D Secure, настроили систему, отлавливающую мошеннические транзакции, и многое другое.
Почему принимать оплату пластиковыми картами сложно?
Казалось бы, что тут сложного? Одна простая форма, в которую пользователь вводит данные своей карты и нажимает кнопку оплатить. Мы обрабатываем запрос, посылаем его в банк — и всё, скоро деньги будут у нас на счету. В идеальном мире так и происходит, но в реальном — немного иначе.
Если вы хотите принимать платежи по банковским картам, то в первую очередь должны обеспечить безопасность данных пользователей. Для этого крупные платежные системы, такие как Visa, Master Card, American Express, Diners и др., разработали стандарт безопасности индустрии платежных карт — PCI DSS (Payment Card Industry Data Security Standard). Это большой список требований, которым должна соответствовать компания, а также процесс разработки приложения и конфигурация используемого оборудования.
Вторая проблема — это защита от мошеннических операций, иначе говоря, «фрода» (от англ. fraud). Ведь сайтом могут пользоваться не только добропорядочные пользователи, но и мошенники, использующие при покупках краденные данные кредитных карт. После такой покупки владелец карты получит выписку с непонятными ему транзакциями, пойдет в банк и потребует возврата средств. Через какое-то время ему вернут деньги, а компания получает «минус в карму» и штраф от платежной системы.
И последнее в списке, но не по важности — это доля успешно проведённых транзакций. Даже если на карте достаточно денег и все системы, участвующие в проведении платежа, работают как часы, выпустивший карту банк может просто отклонить транзакцию, если ему что-то не понравится или покажется подозрительным.
Зачем проходить сертификацию PCI DSS?
Основная цель сертификации — удостовериться, что данные карт хранятся безопасно, что злоумышленник не сможет проникнуть в вашу систему, а проникнув, не сможет легко получить приватную информацию. Проходить ее обязаны все компании, которые обрабатывают данные кредитных карт, даже если в процессе обработки эти данные не сохраняются.
В начале прохождение сертификации воспринималось нами как формальность, потому что мы не хранили у себя деталей кредитных карт. Наше приложение занималось только тем, что рисовало красивую формочку, подходящую под дизайн сайта. Но постепенно оно развивалось, обрастало бизнес-логикой и «антифродовыми» проверками. Мы начали сохранять персональные данные пользователей и разрешенную информацию об их кредитных картах. В итоге мы сами стали заинтересованы в том, чтобы наша система была максимально безопасна. Теперь PCI DSS воспринимается не как формальность, а как возможность, пусть и несколько бюрократическая, проверить себя на прочность.
Подтверждать соответствие стандарту необходимо ежегодно. Требования зависят от уровня, присвоенного компании. Их существует всего четыре, и выдаются они в зависимости от количества транзакций, обрабатываемых за год. Недавно Badoo был присвоен первый уровень, который является самым высоким и самым безопасным. У него самые жесткие требования по сертификации, для их подтверждения нужно проходить внешний аудит. Для более низких уровней достаточно заполнения листа самооценки или выполнения внутреннего аудита. Полный список требований можно посмотреть в самом стандарте. Мы же расскажем о том, что может упростить процесс прохождения сертификации для любого из уровней.
Для начала надо запомнить, что номер карты (PAN) и код безопасности находящийся на задней части карты (CVC) запрещено где-либо сохранять. В этом нет ничего страшного, так как для нормальной работы приложения этого и не требуется. При получении запроса от пользователя данные сразу пересылаются агрегатору и могут хранится только в оперативной памяти, что разрешено стандартом. Хранить в постоянном хранилище можно только первые шесть и последние четыре цифры номера карты, имя владельца карты и дату окончания срока ее действия. На высоких уровнях стандарт все-таки позволяет хранить номер карты, но он должен быть зашифрован стойким алгоритмом или необратимой хеш-функцией.
Следующая важная вещь — это уменьшение области, которая подлежит сертификации. Если обработка платежей не является прямым бизнесом компании, то нет особого смысла распространять жесткие правила безопасности PCI DSS на всю инфраструктуру. Достаточно выделить приложению, обрабатывающему карты, отдельные сервера и репозиторий с кодом, доступ к которым будет иметь ограниченный круг людей. Кроме формального уменьшения объема работ это даст и дополнительную безопасность всей системе в целом. Ее компоненты будут слабо связаны, поэтому, взломав основное приложение, злоумышленник не сможет получить доступ к данным кредиток.
Единственный вариант избежать сертификации — не обрабатывать данные пластиковых карт самому. Например, самый простой и распространенный способ — отправить пользователя на страницу платежного шлюза. После оплаты он вернется на сайт, а вам придет уведомление о статусе платежа. Для тех, кто все-таки хочет иметь свою собственную платежную форму, которая органично вписывалась бы в дизайн сайта, есть вариант посложнее. Данные карты можно зашифровать в браузере, используя публичный ключ, и отправить форму напрямую платежному шлюзу, который расшифрует их приватным ключом и обработает платеж.
Чем опасен фрод и как его уменьшить?
Фрод — это вид мошенничества с данными карты, направленный на незаконное использование денег с ее счета. Опасность здесь кроется не только для пользователя, но и для вас как продавца. Пользователь может потребовать у банка вернуть свои средства, и вы не только не получите денег за свой товар или услугу, но еще и заплатите штраф за каждый такой запрос, даже если потом он будет успешно оспорен. Кроме этого, Visa, Master Card и другие платежные системы могут накладывать дополнительные штрафы за высокий уровень возвратов. Если штраф за обычный возврат, как правило, не превышает 10 долларов США, то штраф за большой объем легко может составить сотни тысяч долларов США.
Здесь важно понимать, что существует два вида возвратов: «рефанд» (от англ. refund) и «чарджбек» (от англ. chargeback). Разница в том, что рефанд вы делаете сами при обращении пользователя, а чарджбек вас вынуждает сделать платежная система. Поэтому штрафы и всевозможные санкции накладывают только при чарджбеках.
Способов борьбы с фродом много. Самый простой и эффективный — 3D Secure. По сути, это просто дополнительный шаг при оплате, на котором пользователь должен подтвердить, что платеж выполняется владельцем карты (см. картинку ниже).
Кроме увеличения безопасности, проведение транзакции с 3D Secure перекладывает ответственность за фрод по ней на плечи банка, выпустившего карту. Это происходит потому, что шаг подтверждения находится полностью под его контролем, и транзакция не должна пройти, если у банка возникли какие-либо подозрения. Но, несмотря на все плюсы, у этого способа проверки есть один фатальный недостаток. Как и любой дополнительный шаг, он очень плохо влияет на долю успешных платежей. Чтобы удостовериться в этом, мы провели серию экспериментов в разных странах, результаты которых представлены на графике ниже.
Три стрелки на графике показывают момент, когда мы выключили принудительное использование 3D Secure в стране. К примеру, в России изначально был включен 3D Secure. После его отключения доля успешных платежей выросла на 20%. В Италии, наоборот, мы его включили и увидели падение доли успешных транзакций на 10-15%. И только в Британии поведение пользователей не изменилось.
Мы также проводили подобные эксперименты и в США, где после включения 3D Secure пользователи практически перестали платить, и в странах Южной Африки, которые традиционно считаются оплотом фрода, но где отключение 3D Secure дало положительный эффект.
Посмотрев на получившиеся результаты, мы решили отказаться от принудительного включения 3D Secure для всех транзакций. Но для сохранения чарджбеков на низком уровне нужно было разработать систему, которая сможет определять мошеннические транзакции и блокировать их. Для начала мы решили составить портреты пользователей, которые чаще всего являются источниками фрода у нас на сайте.
Получилось три группы:
- кардеры. Это специалисты по воровству данных банковских карт. Они проверяют работоспособность своей базы и часто используют ботов;
- спамеры. Они покупают данные краденных карт и делают свой профиль популярным. Потом они размещают рекламу или выпрашивают у пользователей деньги (например, на лечение серьезной болезни);
- неудовлетворенные пользователи. Это люди, которые воспользовались платными услугами, но им что-то не понравилось, или они просто забыли, что платили у нас на сайте, или просто хотят получить услуги бесплатно.
Чтобы сделать жизнь таких людей сложнее, мы начали анализировать их поведение на сайте и составлять правила для нашей системы «антифрода» (от англ. anti-fraud). Они основаны на различных параметрах транзакции, которых около 20, например: сумма платежа, IP пользователя и страна выдачи карты, количество использованных этим пользователем карт, количество транзакций и т. п. Каждое сработавшее правило добавляет транзакции «фродовых» очков. После превышения определенного уровня она считается подозрительной, и мы отправляем ее на дополнительную проверку через 3D Secure или просто блокируем.
Если мошеннику удалось пройти через всю нашу защиту и мы получили информацию о чарджбеке, то его можно попытаться оспорить. В этом случае мы все равно платим штраф, но если выиграем спор, то хотя бы не потеряем сумму самого платежа.
Особо продвинутые агрегаторы могут предоставить «инсайдерскую» информацию о полученных банком чарджбеках, которые еще не успели дойти до платежной системы. Такие сообщения мы используем для проактивной защиты от фрода. Они регистрируются в нашей системе, и мы пытаемся сделать рефанд по этим транзакциям. В этом случае мы все равно возвращаем деньги пользователю, но, так как делаем это добровольно, то никаких дополнительных санкций и штрафов на нас не накладывается. Суммарный эффект от подобных мер не очень большой — можно сэкономить всего несколько процентов дохода. Но для Badoo это сотни тысяч долларов в год, что окупает все затраты.
Почему не все платежи проходят успешно?
По пути от покупателя до банка, выпустившего карту, запрос на снятие денег проходит через множество систем. Кроме продавца, в процессе участвуют:
- платежный шлюз или агреатор, который может предоставлять и другие способы оплаты;
- банк-эквайер — банк, который подключен к различным платежным системам и предоставляет услуги по обработке платежей только по пластиковым картам;
- платежные системы (Visa, Master Card и др.);
- банк-эмитент — банк выпустивший карту, которой пользователь пытается оплатить услугу.
- Каждый этап транцзакции содержит свои моменты, которые могут повлиять на ее успешность.
Пользователь — Сайт
На этом этапе код находится под нашим контролем, и если возникают какие-то проблемы, то мы можем их исправить. Здесь самый неприятный вид ошибок — это логические ошибки валидации введенных данных. Если при проверке имени владельца карты очевидно, что оно может быть длинное или очень короткое, с цифрами, дефисом и чем угодно, что показалось родителям уместным, то при проверке номера карты нужно быть внимательным и знать, каким он может и должен быть. Например, его длина может быть от 13 до 19 (в зависимости от типа карты), а не только 16 цифр, как думают многие. Также желательно проверять не только длину, но и весь номер, используя Luhn алгоритм. При проверке даты окончания срока действия карты надо помнить, что она действует до последнего дня указанного месяца, а не до его начала.
Сайт — Платежный шлюз — Банк-эквайер — МПС — Банк-эмитент
Успешность транзакции на этом этапе может зависеть от частоты платежей и их суммы, страны, из которой они поступают; типа карты и многого другого. К сожалению, повлиять на это мы никак не можем, поэтому на этих этапах очень высок процент отказов из-за ложных срабатываний антифродовых систем одного из участников процесса. Но нам удалось найти два параметра, которые мы можем контролировать и которые сильно влияют на долю успешных платежей. Это использование локального процессингового центра и правильного MCC.
MCC (от англ. Merchant Category Code, буквально — код категории продавца) выдается каждому, кто хочет принимать платежи по картам. Он есть у любого сайта и даже магазина за углом. Он используется в интернет-банках, которые дают статистику по вашим расходам с разбивкой на категории, в различных промоакциях, например когда банк возвращает вам часть денег при покупке продуктов или корма для котиков. Но самое интересное для нас то, что он участвует в алгоритмах антифрода банков.
Изначально у нас был код 7273 Dating and Escort Services, и доля успешных платежей при этом составляла около 50%. И если «дейтинг» еще как-то можно отнести к Badoo, то эскорт-услуги — это точно не про нас. Решив, что это не правильно, мы пошли к нашим партнерам и стали настаивать на том, что нам нужен другой, более подходящий код. Наконец наши попытки увенчались успехом, и в одной из стран мы получили код 4814 — Telecoms (телекоммуникационные услуги). В результате доля успешных платежей выросла на 30%. Останавливаться на достигнутом мы не собирались и продолжили искать, какой еще MCC мы можем использовать. Им оказался 8641 — Social, Civic and Fraternity services" (социальные услуги), который повысил долю успешных платежей еще на 10%.
Подобрав подходящий для нас код, мы всё еще не были удовлетворены показателями некоторых стран. Например, во Франции доля успешных платежей никак не хотела подниматься выше 50-60%. Причина оказалась в том, что там очень популярна национальная платежная система Carte Bleue. Чтобы принимать их карты, используемый процессинговый центр (банк-эквайер) должен быть к ней подключен. Как правило, подходящие банки расположены в той же самой стране, где нужно улучшить показатели. Это дает дополнительный бонус в виде уменьшения подозрительности транзакции для антифродовых систем банков-эмитентов этой страны и влечет увеличение доли успешных платежей.
После того как мы стали использовать локальный процессинг, подключенный к Carte Bleue, мы получили прирост доли успешных платежей во Франции на 30%. В США, где нет локальных платежных систем, такой прием дал чуть меньший прирост — около 20%.
За рамками статьи остался рассказ о разработанной нами платформе, которая позволила проводить все вышеописанные эксперименты легко и без дополнительного программирования. Если у вас есть желание прочитать про нее, то пишите в комментариях, и мы подготовим отдельную статью. Возможно, у вас есть свой интересный опыт в индустрии платежных карт — добро пожаловать в комментарии, нам будет очень интересно пообщаться на эту тему.
Анатолий Панов
Ведущий разработчик