Как стать автором
Обновить

Комментарии 60

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

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

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

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

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

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

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

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

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

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

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

Плюс кроме прокси функций наш сервер занимается многим другим, что делать на клиенте нельзя, хранит токены для рекуринговых платежей и делает антифродовые проверки для платежей.
Так и работает: скрипт шифрует данные в браузере, сервер получает токен и маску карты (первые 6 плюс последние 4 цифры). Далее авторизация через API и управление 3DS
Зашифрованный данные отправляются на наш сервер и мы их в таком виде пересылаем по API?
Именно так
Интересно, о таком варианте я еще не слышал. Но в данном случае всеравно остается проблема с тем что мы привязаны к одному платежному шлюзу.
Кстати про 3DSecure, может кто-нибудь ответит на этот вопрос…
По крайней мере у MasterCard (даже на скриншоте есть) есть поле «персональное приветствие». Интересно, задумано, что это приветствие может устанавливать клиент, или как? Для двух своих карт (Сбер и Яндекс, который через ТКС) там всегда «None». Интересно, можно ли его установить в наших банках?
ВТБ позволяет. Как раз примерно тогда, когда Вы написали свой комментарий, подключил себе 3D Secure и оно предложило установить персональное приветствие.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Слишком большая нагрузка на юристов, бугалтерию и разработчиков. Сейчас у нас подключено 3 процессинг центра, которые дают нам доступ к 10-12 банкам. Если бы мы делали прямы подключения, то было бы в 4 раза больше работы.
Абсолютно разумно это аутсорсить. Особенно это касается, к примеру, запуска продаж на несколько стран. Разработчики Интернет-магазинов, работающих на нескольких крупных рынках одновременно, знают, каково это подключать одновременно карты, электронные кошельки и региональные Интернет-банкинги без местного юрлица. Софтверные разработчики, например, начинают думать о «входе в страну» даже не с сотен, с тысяч транзакций в месяц.
Если у вас 100 платежей в месяц, и вы работаете в одной стране, то это самое правильно решение :)
Необязательно даже на форму банка. Это в России (конечно, не только в ней) банко-зависимые процессинги карт и ставка на дешевый процессинг с обязательным 3D-Secure. За рубежом и банк-эквайер, и 3DS — необязательные составляющие платежей.

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

Прописывается скрипт, который из указанной формы собирает данные и делает криптограмму. Далее через API идет авторизация cloudpayments.ru/Docs/Api#payWithCrypto
с обработкой 3ds cloudpayments.ru/Docs/Api#3ds

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

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

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

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

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

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


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

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

Получается, шифрование не будет являться обработкой карточных данных? А кто гарантирует, что в рамках использования своей кастомной страницы продавец не занимается сохранением карточных данных?
Если данные шифруются после заполнения формы в барузере и отправляются процессинговому центру, то через ваши сервера они не проходят. Значит вы их никак не обрабатываете, сертификацию проходить не надо.
Пока транзакций мало, за тем что вы делаете с данными карточек никто особо следить не будет. Многое в этом бизнесе основано на доверии. Как только трафик начнет расти, к вам придет ваш собственный процессинговый центр и спросит про сертификат.
Плюс подобное решение с шифрованием данных, не будут предлагать любому клиенту, толь проверенным компаниям, которым нет нужды заниматься мошейничеством с данными карт.
И последняя дополнительная защита, это депозит, который процессинговый центр обычно просит внести при заключении контракта. Он должен покрыть все возможные издержки и компенсацию пользователям, если вы вдруг окажетесь не добросовестным клиентом.
По стандартам PCI DSS Failed to load PDF document. Видимо стандарты по безопасности очень обезопасили.
Наверное всё-таки не спамеры, а скамеры.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий