company_banner

Как принимать платежи по кредитным картам — опыт Badoo

    Каждый год в мире появляются всё новые и новые способы оплаты. Но универсального, удобного для всех пользователей способа до сих пор нет. В 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%.



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

    Анатолий Панов
    Ведущий разработчик
    Badoo 405,97
    Big Dating
    Поделиться публикацией
    Похожие публикации
    Комментарии 58
    • +9
      Анатолий, спасибо за отличную статью! Всем ребятам из Badoo огромный привет и респект. Про платформу очень интересно почитать.
      • +2
        А с использованием стороннего мерчанта доля успешных платежей была сильно ниже?
        • +3
          Не понял вопрос. Мы до сих пор пользуемся услугами сторонних процессинговых центров. Просто наша система позволяет гибко перераспределять трафик. Мы можем отправлять французские карты на обработку к тому партнеру у кого есть прямое подключение к французкому банку или американскому, если карты американские.
        • +4
          Да уж. Тема «Как принимать платежи по картам» — полновесная хабровская статья.
          Тему «Как принимать биткойн-платежи» можно в пару абзацев уложить :)
          • 0
            Я думаю там тоже есть что рассказать. Особенно если вдаваться в детали прохождения транзакции по всей системе :)
          • +4
            Спасибо за инсайты! Было бы любопытно почитать про платформу и другие практические решения в этой области.
            • +4
              Неужели те 20%, которые отвалились при включении 3dsecure — это подростки, взявшие мамину карту но спалившиеся по смс на мамин номер?

              Paypal полноценно процессит французские карты?
              • 0
                > Неужели те 20%, которые отвалились при включении 3dsecure — это подростки, взявшие мамину карту но спалившиеся по смс на мамин номер?

                Возможно. Плюс пользователи должны быть подготовленны к 3D Secure, понимать что это такое и что надо делать. В России это распространено, а к примеру в США нет.

                > Paypal полноценно процессит французские карты?

                Мы с ним практически сразу перестали работать, выплаты маленькие. Плюс в то время у них было обязательно заполнять биллинг адрес, а это дополнительный шаг при оплате.
                А если вы про оплату со счета Paypal, то у нас нет информации какая карта привязана к аккаунту пользователя. Можно только по косвенным данным попытаться собрать такую статистику.
                • +1
                  Неужели те 20%, которые отвалились при включении 3dsecure — это подростки, взявшие мамину карту но спалившиеся по смс на мамин номер?

                  Как-то была ситуация с картой Сбера, когда еще не был привязан телефон (тогда 3DSecure только у сбера появился недавно) — как-то не нужна была привязка, Онлайном тогда еще не пользовался… А т.к. телефон не привязан, и одноразовых паролей не получал — пришлось отменять и идти в банкомат.
                  Плюс у того же Сбера бывает что SMS не приходит, хотя для 3D Secure пока не замечал, но для входа/подтверждения операций в ИБ такое случается. Наверняка пользователи забивают, не отправляя SMS повторно
                • +3
                  Во первых, спасибо большое за статью, опыт таких мастодонтов (в хорошем смысле) как Badoo всегда интересен.
                  Тема интересная и достаточно объемная, но один вопрос я задам прямо с телефона :)

                  Для проведения платежа достаточно сообщить процессингу номео карты и дату окончания срока годности.
                  Экспериментировали ли вы с отказом от обязательного введения имени-фамилии владельца?
                  • 0
                    Нет, не экспериментировали. Думали об этом, но решили их оставить. Эти данные мы потом используем для антифродовых правил.
                    • НЛО прилетело и опубликовало эту надпись здесь
                  • +1
                    В Badoo ведь партнерская программа еще есть. Не было случаев недобросовестных «партнеров»-кардеров? С такими, по опыту, сложнее бороться — они в большинстве понимают устройство антифрода и умеют его обходить.
                    • НЛО прилетело и опубликовало эту надпись здесь
                    • +2
                      Спасибо за статью. На наших проектах мы устали от того что платежные агрегаторы косячат (даже Ян*екс), и поэтому анализируем возможность начать принимать оплату заказов картой на нашем сайте. Было много вопросов по поводу PCI DSS и т.д., ваша статья очень вовремя.
                      • 0
                        Вы правда думаете, что обеспечите более стабильный сервис, чем специализированная процессинговая компания? Или дело в UI и/или стоимости услуг процессинга?
                        • +1
                          Ключевой фактор Они косячат, а негатив идет к тебе, а ты ничего не можешь сделать.

                          А так если смотреть:
                          — передав клиента другому сервису мы увеличиваем на несколько шагов путь к оплате
                          — интерфейсы не всегда простые для клиента, да в несколько шагов + отличаются стилем от сайта (кто-то дает допиливать, кто-то нет)
                          — косячат все ) — падает процессинг, подвисают платежи, двойные списания
                          — на различных способах отсутствует механизм возврата, особенно Offline платежи
                          — плохо работает служба поддержки, если клиент все-таки звонит в процессинговую компанию.
                          — часто пинают что проблема у вас или проблема банка, сами общаться с банком отказываются, предлагая это сделать или клиенту или нам вместе с клиентом )
                          • 0
                            Подписываюсь под каждым словом :)
                        • 0
                          О, а расскажите про типичные косяки платежных агрегаторов? Что бесит больше всего?
                          • 0
                            Да, мне тоже интересно, особенно про Ян*екс. Я о них наоборот только позитивные вещи слышал.
                            • +1
                              Сейчас частично работаем с Ян*екс. Такое ощущение что они еще активно пилят систему и обновляют. Подключили три месяца назад, вот проблемы с которыми мы столкнулись:
                              — При проведении они чекают 1 раз. Если наш сервис не принял информацию о платеже (например обновление, баг и т.д.) то Offline платежи подвисают у большого брата, а Online отменяются. Чтобы клиенту вернуть подвисший платеж надо его или хитро проталкивать (есть целый регламент)))) или писать в суппорт — решение рассматривается 30 дней. Автоматически пропихнуть нам они не могу. Вернее могут но говорят что опять же в течение двух — трех недель.
                              — Конфликты с переходом на страницы 3D Secure Банка, видим описание ошибки (присылает клиент) нам СП Ян*екс говорит что у них норм и проблема на стороне банка, и пусть клиент обращается в банк. Понятно что нам приходится помогать клиенту.
                              — Иногда проскакивают ошибки — неделя назад было двойное списание с карт по платежам, ответ от СП один у нас все хорошо — проблемы у банков, пусть клиент обращается в свой банк за возвратом.
                              — Долгое время ответа от СП, некоторые обращения висят до сих пор.
                              — Возвраты по Offline платежи обещали, пили, пили, пили, прошли обещанные сроки, но по моему так не допили )

                              Могу где-то ошибаться, так собирал информацию от коллег. Но картина пока такая
                              • 0
                                Спасибо, понятно. Мы через них карты не процессили. Пользовались только оплатой через их кошелек. Но подобные партнеры тоже попадались, особенно удивляют системы которые посылают запрос о результатах транзакции только один раз, даже не проверяя наш ответ. С теми кто так делает мы стараемся не работать, отклоняя предложения на стадии проверки технической документации.
                          • 0
                            Кстати в плане безопасности интересная тема. Вот мне, как продвинутому интернет-платильщику, гораздо комфортнее вводить свои данные в примелькавшиеся формы и это даже плюс, если платёжная форма будет от стороннего процессингового центра, а не от сайта. Мне так комфортнее. Во первых, я на 90% буду уверен, что самопроизвольно списание не будет произведено, во вторых, не будет лишних подозрений.

                            Мне как-то нужно было воспользоваться услугами на сомнительном сайте, я как знал, специально завёл QVC на qiwi и оплатил услуги. Спустя какое-то время мне начали ломиться смски о недостаточном балансе по этой QVC, где этот сомнительный сайт пытался списать денег за подписку, хотя я не помню, чтоб соглашался на эту подписку.

                            Поэтому вопрос, зачем нужен свой прокси-процессинг? Достаточно по сути определить страну плательщика и работать с правильным процессингом для данной страны.
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • +1
                                Если не ошибаюсь, есть платежные шлюзы, которые испольузуют подход, вроде бы не требующий PCI сертификации, при этом используя форму вашего сайта через iframe.
                                Если не изменяет память — через iframe подставлялась форма с сабмитом данных на шлюз. при сабмите, шлюз возвращал ответ с исковерканным номером кредитки: 128ХХХХХХХХХХ4444, верной датой и своим CVV), после чего модуль передавал именно эти данные на шлюз и тот их сверял со своими сохраненными.
                                Так делал Payone модуль для Magento. Никаких редиректов на внешний сайт не было и данные кредиток не хранились на сервере — сабмит шел напрямую в шлюз. Хотя, возможно, это может нарушать требования PCI, в Payone клялись что нет.
                                • 0
                                  Да, так можно делать. PCI это не нарушает, так как данные карт через вашу систему не проходят. Но это лишает вас возможности как-либо управлять трафиком, все платежи пойдут через один платежный шлюз.
                                  • 0
                                    Ну пусть идут. Имхо, проблема платежных шлюзов в том, что людям надо делать два лишних шага ( Place order > <ввод данных> > Go back to merchant ). Со стороны кода тут тоже проблемка — например в Magento заказ влетает в БД, со статусом pending payment, и потом если клиент закроет браузер этот статус таким и будет висеть, пока через какоето время не придет ответ от шлюза что заказ не оплачен и expired.
                              • +1
                                Чтобы определить страну нужен номер карты как минимум. Либо его первые шесть цифр. Можно определять его на клиенте, но тогда нам всеравно нужна форма «введите первые шесть цифр номера вашей карты». Это добавит один дополнительный шаг в процесс оплаты, которого можно избежать. Плюс сам процесс будет выглядеть очень не привычно для пользователя и будет более подозрительным чем просто форма.
                                Если бы все процессинги давали возможность зашифровать данные формы и отправить на их сервер для обработки, то можно было бы обойтись без нашего прокси-процессинга. Но пока такую возможность почти никто не предлагает.

                                Плюс кроме прокси функций наш сервер занимается многим другим, что делать на клиенте нельзя, хранит токены для рекуринговых платежей и делает антифродовые проверки для платежей.
                                • +1
                                  Так и работает: скрипт шифрует данные в браузере, сервер получает токен и маску карты (первые 6 плюс последние 4 цифры). Далее авторизация через API и управление 3DS
                                  • 0
                                    Зашифрованный данные отправляются на наш сервер и мы их в таком виде пересылаем по API?
                                    • +1
                                      Именно так
                                      • 0
                                        Интересно, о таком варианте я еще не слышал. Но в данном случае всеравно остается проблема с тем что мы привязаны к одному платежному шлюзу.
                              • 0
                                Кстати про 3DSecure, может кто-нибудь ответит на этот вопрос…
                                По крайней мере у MasterCard (даже на скриншоте есть) есть поле «персональное приветствие». Интересно, задумано, что это приветствие может устанавливать клиент, или как? Для двух своих карт (Сбер и Яндекс, который через ТКС) там всегда «None». Интересно, можно ли его установить в наших банках?
                                • 0
                                  ВТБ позволяет. Как раз примерно тогда, когда Вы написали свой комментарий, подключил себе 3D Secure и оно предложило установить персональное приветствие.
                                • +1
                                  Зачем проходить сертификацию PCI DSS?

                                  Я бы изменил заголовок на «Зачем проходить сертификацию PCI DSS, если можно просто перенаправлять пользователя на форму банка».
                                  Правда, тогда статья вышла бы заметно короче.
                                  • 0
                                    И, кстати, при этом можно почти не терять на комиссиях. Если заключить договоры с несколькими крупнейшими банками и направлять на форму по признаку банка карты. Как правило, свои же карты банки процессят со скидками.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                      • 0
                                        Слишком большая нагрузка на юристов, бугалтерию и разработчиков. Сейчас у нас подключено 3 процессинг центра, которые дают нам доступ к 10-12 банкам. Если бы мы делали прямы подключения, то было бы в 4 раза больше работы.
                                        • 0
                                          Абсолютно разумно это аутсорсить. Особенно это касается, к примеру, запуска продаж на несколько стран. Разработчики Интернет-магазинов, работающих на нескольких крупных рынках одновременно, знают, каково это подключать одновременно карты, электронные кошельки и региональные Интернет-банкинги без местного юрлица. Софтверные разработчики, например, начинают думать о «входе в страну» даже не с сотен, с тысяч транзакций в месяц.
                                      • +2
                                        Если у вас 100 платежей в месяц, и вы работаете в одной стране, то это самое правильно решение :)
                                        • +1
                                          Необязательно даже на форму банка. Это в России (конечно, не только в ней) банко-зависимые процессинги карт и ставка на дешевый процессинг с обязательным 3D-Secure. За рубежом и банк-эквайер, и 3DS — необязательные составляющие платежей.

                                          В форме платежных агрегаторов (например, специализированных для мировых продаж digital goods, как MyCommerce) может быть корзина, стилизованная под ваш сайт как минимум по части шапки, а можете и докупить сертификат, встроить форму ввода платежных данных через iFrame, и т.п.
                                        • 0
                                          Отличная статья! Не могли бы вы поделится информацией, платёжные шлюзы каких банков предоставляют возможность реализовать форму оплаты на стороне клиента?
                                          Если форма на стороне клиента, то комиссия ниже или не имеет значения?
                                          • 0
                                            Мы напрямую с банками не работаем, не выгодно поддерживать столько интеграций и конрактов. В любом случае, для реализации своей формы, если не пользоваться техниками шифрования на стороне клиента, вам нужно будет проходить сертификацию PCI DSS. Если трафик у вас маленький, то и требования там не очень страшные будут.
                                          • 0
                                            Может кто знает, несет ли хоть какую-то ответственность перед свои банком клиент, сделавший чарджбек?
                                            • 0
                                              На сколько я знаю нет. В каких-то банках могут брать комиссию с клиента за рассмотрение заявки на чарджбек. Но это все очень индивидуально и зависит от страны и банка.
                                            • 0
                                              Есть способ принимать платежи у себя и управлять авторизацией без полноценного PCI — stripe.com в US, cloudpayments.ru в России и Европе
                                              • 0
                                                Да, в последнее время все больше появляется компаний, которые предлагают встроить виджет оплаты на свой сайт. Это решает кучу проблем со встраиванием платежной формы в свой дизайн, если в дополнение к этому виджет может отправлять данные на наш сервер с маской карты, то о чем вы писали выше, это еще круче. Можно делать многие вещи не заморачиваясь PCI DSS.
                                                Но для нас к сожалению это не подходит, потому что мы остаемся привязанными к одному платежному шлюзу. Даже если он нас сможет обеспечить всем многообразием банков, которые мы хотим, ради уменьшения рисков, нам необходимо будет иметь запасной вариант.
                                              • +1
                                                Там не только виджет, но и скрипт с шифрованием, что выше обсуждали
                                                • 0
                                                  Тогда я что-то не правильно понял из документации у вас на сайте :) Расскажите пожалуйста подробней как оно работает или дайте ссылку где почитать
                                              • +1
                                                За рамками статьи остался рассказ о разработанной нами платформе, которая позволила проводить все вышеописанные эксперименты легко и без дополнительного программирования. Если у вас есть желание прочитать про нее, то пишите в комментариях, и мы подготовим отдельную статью.

                                                Да, было бы очень интересно почитать.
                                                Спасибо за статью!
                                                • +1
                                                  Тоже за статью о платформе! А еще вопрос по процентам деклайнов от банков/шлюзов: вы не пробовали выстраивать каскады, когда если один шлюз отказывает, транзакция идёт на второй, третьий и т.д. пока какой-нибудь не заапрувит?

                                                  Кстати, меня всегда удивляло, почему PCI DSS позволяет хранить 10 цифр (в общем понять можно, чтобы отличать банки и идентифицировать карты), ведь учитывая, что последняя цифра это контрольная сумма, подобрать 6 оставшихся — секундное дело. (был опыт когда отказало 2 криптодевайса и пришлось востанавливать незавершённые транзашки)
                                                  • +1
                                                    А еще вопрос по процентам деклайнов от банков/шлюзов: вы не пробовали выстраивать каскады, когда если один шлюз отказывает, транзакция идёт на второй, третьий и т.д. пока какой-нибудь не заапрувит?

                                                    Пробовали, работает :) Но надо быть очень аккуратным, чтобы не снять с пользователя деньги дважды или трижды.

                                                    Кстати, меня всегда удивляло, почему PCI DSS позволяет хранить 10 цифр (в общем понять можно, чтобы отличать банки и идентифицировать карты), ведь учитывая, что последняя цифра это контрольная сумма, подобрать 6 оставшихся — секундное дело. (был опыт когда отказало 2 криптодевайса и пришлось востанавливать незавершённые транзашки)

                                                    Нас при аудите просили зашифровать этих данных в базе. Чтобы получив к ней доступ нельзя было перебором подобрать номера.
                                                  • +1
                                                    Здесь важно понимать, что существует два вида возвратов


                                                    На самом деле их 3, есть еще «Отмена» (Cancellation), это когда транзакция еще висит в экваере (обычно экваер собирает транзакции за день и процессит их все вместе (предварительно авторизировав средства на карте)). От рефанда отличается тем, что за отмену продавец ничего не платит.
                                                    • +1
                                                      Да, совсем забыл про нее, спасибо за дополнение. Период через которой проводится авторизованная транзакция можно настраивать. Некоторые агрегаторы предлагают делать это в полностью ручном режиме. Тоесть если не послать запрос на отмену или подверждение списания, то через определенный период, транзакция будет автоматически отменена.
                                                      По такому принципу например работает привязка новый карты в PayPal.
                                                    • +1
                                                      Не очень понял, нужно ли проходит сертификацию PCI DSS, если я только хочу показывать свою форму для ввода карточных данных, а сами данные шифровать и передавать процессинговому центру. В начале статьи вы пишите:
                                                      Проходить ее (сертификацию) обязаны все компании, которые обрабатывают данные кредитных карт, даже если в процессе обработки эти данные не сохраняются.

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

                                                      Получается, шифрование не будет являться обработкой карточных данных? А кто гарантирует, что в рамках использования своей кастомной страницы продавец не занимается сохранением карточных данных?
                                                      • 0
                                                        Если данные шифруются после заполнения формы в барузере и отправляются процессинговому центру, то через ваши сервера они не проходят. Значит вы их никак не обрабатываете, сертификацию проходить не надо.
                                                        Пока транзакций мало, за тем что вы делаете с данными карточек никто особо следить не будет. Многое в этом бизнесе основано на доверии. Как только трафик начнет расти, к вам придет ваш собственный процессинговый центр и спросит про сертификат.
                                                        Плюс подобное решение с шифрованием данных, не будут предлагать любому клиенту, толь проверенным компаниям, которым нет нужды заниматься мошейничеством с данными карт.
                                                        И последняя дополнительная защита, это депозит, который процессинговый центр обычно просит внести при заключении контракта. Он должен покрыть все возможные издержки и компенсацию пользователям, если вы вдруг окажетесь не добросовестным клиентом.

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

                                                      Самое читаемое