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

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

Интересно было бы почитать, как именно вы получали PCI DSS. Какого уровня, сколько заплатили, как долго проходила сертификация.
Есть планы написать отдельную статью о том, как у нас в целом организован прием кредиток. В ней обязательно расскажем.
А нет ли возможности сгенерировать картинку о распределении платежей по способам оплаты не для всего мира, а для Евразии (у вас, как я понимаю, велика доля Южной Америки) или даже отдельно — севр. америка, юж. америка, западная европа, снг, восточная европа?
Для СНГ будет не репрезентативно. На карту посмотрите.
Именно по странам не очень просто. Сделал картинку со странами которые используют Евро в качестве валюты
image
спасибо за диаграмму! А это за какой период статистика?
Как-то не верится что в европе такие дремучие люди, предпочитающие платить через смс…
За последние сутки. Мне тоже не верилось когда писал, но с цифрами сложно спорить :)
В раздел «SMS & Direct Billing» так же входят платежи которые были сделанны из приложения под Android и c мобильной версии сайта. Я думаю для таких пользователей SMS может быть удобнее и привычнее, поэтому такие цифры.
А какой возраст у большинства ваших юзеров в евросоюзе? Может у вас большинство это пожилые люди?

а у вас все виды платежей стоят одинаково для пользователя (то есть вы комиссию за платеж платите сами, хотя она для мобильных платежей и для direct debit различается на несколько порядков)?

ИМХО вам стоит подумать чтобы стать платежным шлюзом (принимающим эти 50 видов национальных платежей) — в данный момент эта ниша почти никем не занята.
Про возраст не скажу, аналитикой больше продуктовый отдел занимается, а комиссию платим сами. Например в Европе 100 кредитов (внутреняя валюта) на всех способах оплаты стоит 2€, не смотря на то что комиссия везде разная.

ИМХО вам стоит подумать чтобы стать платежным шлюзом (принимающим эти 50 видов национальных платежей) — в данный момент эта ниша почти никем не занята.

Мой опыт показывает что ниша уже давно не свободная. Предложений очень много, на любые вкусы. Мы сами же ими и пользуемся, еще и выбираем у кого комиссия меньше, API удобнее, покрытие выше.
Если и становиться самим платежным шлюзом, то надо какое-то конкуретное преимущество иметь, чтобы выбирали именно нас. Вот пока непонятно какое именно.
> Мой опыт показывает что ниша уже давно не свободная. Предложений очень много, на любые вкусы.

Подскажите какие-нибудь варианты, чтоб поддерживали 50 видов популярных национальных платежей. plimus (bluesnap), share-it и все что от digital river,2checkout, и даже payproglobal (вроде он поддерживает макс. число национальных платежей из всех регистраторов) каждый в сумме 50 видов платежей не поддерживают. Постоянно мониторю этот вопрос ибо это актуально.

Если бы такие всеядные шлюзы уже были, вы бы наверно не стали сами городить весь этот зоопарк из плагинов, а пользовались бы им, верно?
огромное спасибо за Adyen!
А можете еще аналоги назвать, на случай если у нас с ними что-то не срастется?
Все остальное увы под NDA. Насколько я помню упомянутый «digital river» тоже имеет внушительный список. На сайте у них не нашел в открытом доступе, думаю высылают по запросу.
Ко мне можно обратиться касательно сервисов Digital River для индивидуальных предпринимателей и СМБ (они, т.е. мы — уже почти год представлены в России целым офисом в Москве — под брендом MyCommerce, это компания группы Digital River, объединяющая платформы MyCommerce-RegNow, ShareIt-Element5, SWREG и eSellerate). По Enterprise-аккаунтам тоже знаю, с кем связать.

Сейчас на самых массовых платформах доступно до 20-25 топовых способов платежей (с учетом того, что они cost-effective — т.е. не в виде Premium SMS, где комиссия может быть до 90%...), и это число можно расширить — новые регионы подключаются on-demand + постоянно идет расширение числа платежей, доступных на массовых платформах.

Для справки, а не для SEO: Тарифы и способы платежей флагманской платформы MyCommerce для продаж программ, веб-сервисов и т.п.
Речь про массовые платформы MyCommerce/Share-It, разумеется.
мы связались с Adyen.
Открыли у них тестовый акк, они спросили подробности о нас, мы им сказали, они подумали и сказали что с компаниями из РФ они не работают…

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

> Для обработки платежей мы используем два сервера базы данных с MySQL от Percona, работающих в master-master репликации

А чем продиктовано master-master? master-slave судя по пояснениям в скобках тоже бы хватало?
Второй сервер становиться основным если например нужно перезагрузить MySQL на первом. Плюс он используется для горячей замены, если вдруг первый выйдет из строя.
Но percona рекомендует минимум 3 узла в кластере (если у вас percona xtradb cluster, конечно)
У нас обычный master-master, без xtradb cluster.
Для обработки платежей мы используем два сервера базы данных с MySQL от Percona, работающих в master-master репликации. Основная нагрузка идет только на один из них, второй используется для «горячей» замены в случае аварии или для подмены основного

А не страшно? Ну в смысле репликация асинхронная, бинарные логи синкаются иногда не так как ожидается – данные потерять можно запросто.
Со Statement-Based репликацей были проблемы, сейчас перешли на Mixed и настроили автоматический check-sum таблиц. Пока все хорошо :)
Здравствуйте! Расскажите пожалуйста подробнее о ядре вашего биллинга? ;]

Пишу свой биллинг для личных нужд, самые простые вещи делать он умеет, но как научить биллинг таким вещам, как промо-акции, механизм бонусов, скидок, Я пока не придумал как это красиво сделать.
делайте некрасиво, походу подгоните
Наша текущая схема промо, скидок и т.п. нас тоже полностью не устраивает. Думаем над ее развитием и улучшением. Как реализуем, поделимся опытом :)
что-то я не совсем понял про сервера которые соответствуют PCI DSS. вы же гетевэями пользуетесь, у себя платёжную инфу не храните, зачем?
Для обработки платежей по картам мы тоже используем больше одного гейтвея, поэтому у нас своя страница ввода деталей карты и правила по которым транзакции отправляются к нужному гейтвею. А раз мы обрабатываем детали карточек, то партнеры требуют чтобы мы были сертифицированы.
т.е. вы не хостинг страницы гетевеев используете, а их API?
я к тому, что если вы посылаете уже данные с карты и получаете ответ платёж принят/платёж отклонён, то странно, что пользователь должен сам выбирать гетевей. а если для осуществления платежа пользователь переходит на страницу гетевея, то для серверов стандарты PCI не категоричны. что-то я упускаю
Для платежных карт пользователь всегда видит одну и ту же форму, которую отдает сам Badoo. Он никогда не выбирает партнера.
а вот тут вроде как выбирает,

image

или это вроде с кошелька на кошелёк?
Что выбирает? :) Это оплата через SMS на скриншоте он может выбрать только количество кредитов которое хочет купить. Либо сменить тип оплаты.
Форма оплаты кредиткой выглядит вот так
image
Да, для карт мы не используем готовые страницы и используем API.
Пользователь ничего не выбирает, только вводит данные карты. Логика о том куда пойдет платеж находится на сервере и зависит от параметров транзакции, например есть список стран с высоким риском фрода, транзакции из этих стран мы хотим принудительно подтверждать через 3D Secure. Если по BIN карты мы видим что она выдана в стране из этого списка, то отправляем ее на аккаунт где он включен. В зависимости от типа карты, транзакция может уйти в банк который лучше обрабатывает именно этот тип карт.
да да, это всё понятно. меня просто смутил выбор между paypal, creditcard, sofort, paysafecard. которые, кроме прочего, предоставляют услуги гетевеев. теперь всё ясно, спасибо за терпение.

кстати, ради профессионального интереса, если выбраный гетевей недоступен, платёж идёт на другой или отклоняется?
Пока что откланяется, но мы вот-вот добавим функционал делающий несколько попыток, через разные гейтвеи.
здорово. а пока транзакция процессится, данные карточки в базе хранятся или на криптоустройстве?
В памяти. Мы пользуемся чудесной возможностью PHP-FPM fastcgi_finish_request(), которая позволяет завершить HTTP запрос, но продолжить выполнение скрипта.
хорошо. а если с сервером что-то случилось до получения ответа, вы потом пробегаетесь по незавершённым транзакциям, запрашиваете статус платежа у гетевея и проставляете транзакции статус?
По разному. У кого-то есть push нотификации, если что-то сломается в процессе обработки запроса мы узнаем об этом когда статус транзакции измениться у агрегатора. А для кого-то приходиться опрашивать статус.
теперь вроде как сложилось. спасибо
1. Как Вы делаете заглушки, эмулирующие платежные системы? По документации разбираетесь в протоколе?

2. Как вы поддерживаете зоопарк шаблонов страниц оплаты (в Бельгии есть правило, что короткий номер должен быть написан белым шрифтом на черном фоне). Куча if'ов по стране и типу оплаты?
1. Каждый плагин конкретной платежной системы реализует некий абстрактный класс. Когда пишется новый плагин для платежного метода, то он по большей части реализует стандартные методы абстрактного класса, а потому основные методы заглушек реализуются автоматически. Для всего остального по документации протокола дописывается свой код. Сам вызов из заглушки дергает процессор из devel окружения и отрабатывает полный алгоритм.

2. Плагин агрегатора расширяется наследником для страны, если это необходимо. Аналогично для шаблонов — простыми префиксами реализуется выбор нужного шаблона для конкретной страны/агрегатора/оператора.
Как биллинг общается с сервисами? Например когда пользователь хотел купить подарок.
Не понял вопрос. С какими сервисами? С внутренними?
Да, с внутренними.
Никакой особой магии нет. У нас общий репозиторий, просто вызываем методы нужных классов :)
Если чуть подробнее, то во время обработки платежа, в транзакции, мы кладем запись в очередь доставки подарков. От туда ее забирают скрипты и доставлют подарок до пользователя.
Сам биллинг выступает для баду в виде «сервиса» у нас есть внутренее API, используем HTTP + JSON. Но весь остальной функционал просто код, дополнительных абстракций нет.
В виде полноценных сервисов работают только демоны написанные на C.
Direct billing — вы имеете ввиду прямой биллинг баланса моб телефона?
Да
НЛО прилетело и опубликовало эту надпись здесь
Вы описываете биллинг, но нигде не говорите о выставлении счетов. Этой задачи у Вас нет? Или у Вас проста и тривиальна​?
Если вопрос о бухгалтерской части и выставлении/сверке счетов, то этим занимается Лондонский офис. Мы только обеспечиваем их исходными данными и поддерживаем интерфейс позволяющий проставлять процент комиссий.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий