Comments 52
Интересно было бы почитать, как именно вы получали PCI DSS. Какого уровня, сколько заплатили, как долго проходила сертификация.
А нет ли возможности сгенерировать картинку о распределении платежей по способам оплаты не для всего мира, а для Евразии (у вас, как я понимаю, велика доля Южной Америки) или даже отдельно — севр. америка, юж. америка, западная европа, снг, восточная европа?
Для СНГ будет не репрезентативно. На карту посмотрите.
Именно по странам не очень просто. Сделал картинку со странами которые используют Евро в качестве валюты
![image](https://habrastorage.org/r/w1560/storage3/fb4/ff7/741/fb4ff77414bb91f009c7e9937ef789f5.png)
![image](https://habrastorage.org/storage3/fb4/ff7/741/fb4ff77414bb91f009c7e9937ef789f5.png)
спасибо за диаграмму! А это за какой период статистика?
Как-то не верится что в европе такие дремучие люди, предпочитающие платить через смс…
Как-то не верится что в европе такие дремучие люди, предпочитающие платить через смс…
За последние сутки. Мне тоже не верилось когда писал, но с цифрами сложно спорить :)
В раздел «SMS & Direct Billing» так же входят платежи которые были сделанны из приложения под Android и c мобильной версии сайта. Я думаю для таких пользователей SMS может быть удобнее и привычнее, поэтому такие цифры.
В раздел «SMS & Direct Billing» так же входят платежи которые были сделанны из приложения под Android и c мобильной версии сайта. Я думаю для таких пользователей SMS может быть удобнее и привычнее, поэтому такие цифры.
А какой возраст у большинства ваших юзеров в евросоюзе? Может у вас большинство это пожилые люди?
а у вас все виды платежей стоят одинаково для пользователя (то есть вы комиссию за платеж платите сами, хотя она для мобильных платежей и для direct debit различается на несколько порядков)?
ИМХО вам стоит подумать чтобы стать платежным шлюзом (принимающим эти 50 видов национальных платежей) — в данный момент эта ниша почти никем не занята.
а у вас все виды платежей стоят одинаково для пользователя (то есть вы комиссию за платеж платите сами, хотя она для мобильных платежей и для direct debit различается на несколько порядков)?
ИМХО вам стоит подумать чтобы стать платежным шлюзом (принимающим эти 50 видов национальных платежей) — в данный момент эта ниша почти никем не занята.
Про возраст не скажу, аналитикой больше продуктовый отдел занимается, а комиссию платим сами. Например в Европе 100 кредитов (внутреняя валюта) на всех способах оплаты стоит 2€, не смотря на то что комиссия везде разная.
Мой опыт показывает что ниша уже давно не свободная. Предложений очень много, на любые вкусы. Мы сами же ими и пользуемся, еще и выбираем у кого комиссия меньше, API удобнее, покрытие выше.
Если и становиться самим платежным шлюзом, то надо какое-то конкуретное преимущество иметь, чтобы выбирали именно нас. Вот пока непонятно какое именно.
ИМХО вам стоит подумать чтобы стать платежным шлюзом (принимающим эти 50 видов национальных платежей) — в данный момент эта ниша почти никем не занята.
Мой опыт показывает что ниша уже давно не свободная. Предложений очень много, на любые вкусы. Мы сами же ими и пользуемся, еще и выбираем у кого комиссия меньше, API удобнее, покрытие выше.
Если и становиться самим платежным шлюзом, то надо какое-то конкуретное преимущество иметь, чтобы выбирали именно нас. Вот пока непонятно какое именно.
> Мой опыт показывает что ниша уже давно не свободная. Предложений очень много, на любые вкусы.
Подскажите какие-нибудь варианты, чтоб поддерживали 50 видов популярных национальных платежей. plimus (bluesnap), share-it и все что от digital river,2checkout, и даже payproglobal (вроде он поддерживает макс. число национальных платежей из всех регистраторов) каждый в сумме 50 видов платежей не поддерживают. Постоянно мониторю этот вопрос ибо это актуально.
Если бы такие всеядные шлюзы уже были, вы бы наверно не стали сами городить весь этот зоопарк из плагинов, а пользовались бы им, верно?
Подскажите какие-нибудь варианты, чтоб поддерживали 50 видов популярных национальных платежей. plimus (bluesnap), share-it и все что от digital river,2checkout, и даже payproglobal (вроде он поддерживает макс. число национальных платежей из всех регистраторов) каждый в сумме 50 видов платежей не поддерживают. Постоянно мониторю этот вопрос ибо это актуально.
Если бы такие всеядные шлюзы уже были, вы бы наверно не стали сами городить весь этот зоопарк из плагинов, а пользовались бы им, верно?
Например Adyen, очень приятные в работе ребята. Вот список того что они поддерживают.
огромное спасибо за 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 для продаж программ, веб-сервисов и т.п.
Сейчас на самых массовых платформах доступно до 20-25 топовых способов платежей (с учетом того, что они cost-effective — т.е. не в виде Premium SMS, где комиссия может быть до 90%...), и это число можно расширить — новые регионы подключаются on-demand + постоянно идет расширение числа платежей, доступных на массовых платформах.
Для справки, а не для SEO: Тарифы и способы платежей флагманской платформы MyCommerce для продаж программ, веб-сервисов и т.п.
мы связались с Adyen.
Открыли у них тестовый акк, они спросили подробности о нас, мы им сказали, они подумали и сказали что с компаниями из РФ они не работают…
Так что если вспомните еще кого-либо не под вашим NDA, дайте знать.
Открыли у них тестовый акк, они спросили подробности о нас, мы им сказали, они подумали и сказали что с компаниями из РФ они не работают…
Так что если вспомните еще кого-либо не под вашим NDA, дайте знать.
Смысл иметь больше одного всеядного платежного шлюза лежит не столько в технической, сколько в бизнес сфере. Например мы хотим через кого-то принимать платежи по банковским картам, но для этого должны проводить не меньше определенного количества транзакций, по картам у нас столько не получается, приходиться добавлять другие платежные методы.
Спасибо, интересная статья.
> Для обработки платежей мы используем два сервера базы данных с MySQL от Percona, работающих в master-master репликации
А чем продиктовано master-master? master-slave судя по пояснениям в скобках тоже бы хватало?
> Для обработки платежей мы используем два сервера базы данных с MySQL от Percona, работающих в master-master репликации
А чем продиктовано master-master? master-slave судя по пояснениям в скобках тоже бы хватало?
Второй сервер становиться основным если например нужно перезагрузить MySQL на первом. Плюс он используется для горячей замены, если вдруг первый выйдет из строя.
Но percona рекомендует минимум 3 узла в кластере (если у вас percona xtradb cluster, конечно)
Для обработки платежей мы используем два сервера базы данных с MySQL от Percona, работающих в master-master репликации. Основная нагрузка идет только на один из них, второй используется для «горячей» замены в случае аварии или для подмены основного
А не страшно? Ну в смысле репликация асинхронная, бинарные логи синкаются иногда не так как ожидается – данные потерять можно запросто.
Здравствуйте! Расскажите пожалуйста подробнее о ядре вашего биллинга? ;]
Пишу свой биллинг для личных нужд, самые простые вещи делать он умеет, но как научить биллинг таким вещам, как промо-акции, механизм бонусов, скидок, Я пока не придумал как это красиво сделать.
Пишу свой биллинг для личных нужд, самые простые вещи делать он умеет, но как научить биллинг таким вещам, как промо-акции, механизм бонусов, скидок, Я пока не придумал как это красиво сделать.
что-то я не совсем понял про сервера которые соответствуют PCI DSS. вы же гетевэями пользуетесь, у себя платёжную инфу не храните, зачем?
Для обработки платежей по картам мы тоже используем больше одного гейтвея, поэтому у нас своя страница ввода деталей карты и правила по которым транзакции отправляются к нужному гейтвею. А раз мы обрабатываем детали карточек, то партнеры требуют чтобы мы были сертифицированы.
т.е. вы не хостинг страницы гетевеев используете, а их API?
я к тому, что если вы посылаете уже данные с карты и получаете ответ платёж принят/платёж отклонён, то странно, что пользователь должен сам выбирать гетевей. а если для осуществления платежа пользователь переходит на страницу гетевея, то для серверов стандарты PCI не категоричны. что-то я упускаю
Для платежных карт пользователь всегда видит одну и ту же форму, которую отдает сам Badoo. Он никогда не выбирает партнера.
Да, для карт мы не используем готовые страницы и используем API.
Пользователь ничего не выбирает, только вводит данные карты. Логика о том куда пойдет платеж находится на сервере и зависит от параметров транзакции, например есть список стран с высоким риском фрода, транзакции из этих стран мы хотим принудительно подтверждать через 3D Secure. Если по BIN карты мы видим что она выдана в стране из этого списка, то отправляем ее на аккаунт где он включен. В зависимости от типа карты, транзакция может уйти в банк который лучше обрабатывает именно этот тип карт.
Пользователь ничего не выбирает, только вводит данные карты. Логика о том куда пойдет платеж находится на сервере и зависит от параметров транзакции, например есть список стран с высоким риском фрода, транзакции из этих стран мы хотим принудительно подтверждать через 3D Secure. Если по BIN карты мы видим что она выдана в стране из этого списка, то отправляем ее на аккаунт где он включен. В зависимости от типа карты, транзакция может уйти в банк который лучше обрабатывает именно этот тип карт.
да да, это всё понятно. меня просто смутил выбор между paypal, creditcard, sofort, paysafecard. которые, кроме прочего, предоставляют услуги гетевеев. теперь всё ясно, спасибо за терпение.
кстати, ради профессионального интереса, если выбраный гетевей недоступен, платёж идёт на другой или отклоняется?
кстати, ради профессионального интереса, если выбраный гетевей недоступен, платёж идёт на другой или отклоняется?
Пока что откланяется, но мы вот-вот добавим функционал делающий несколько попыток, через разные гейтвеи.
здорово. а пока транзакция процессится, данные карточки в базе хранятся или на криптоустройстве?
В памяти. Мы пользуемся чудесной возможностью PHP-FPM fastcgi_finish_request(), которая позволяет завершить HTTP запрос, но продолжить выполнение скрипта.
1. Как Вы делаете заглушки, эмулирующие платежные системы? По документации разбираетесь в протоколе?
2. Как вы поддерживаете зоопарк шаблонов страниц оплаты (в Бельгии есть правило, что короткий номер должен быть написан белым шрифтом на черном фоне). Куча if'ов по стране и типу оплаты?
2. Как вы поддерживаете зоопарк шаблонов страниц оплаты (в Бельгии есть правило, что короткий номер должен быть написан белым шрифтом на черном фоне). Куча if'ов по стране и типу оплаты?
1. Каждый плагин конкретной платежной системы реализует некий абстрактный класс. Когда пишется новый плагин для платежного метода, то он по большей части реализует стандартные методы абстрактного класса, а потому основные методы заглушек реализуются автоматически. Для всего остального по документации протокола дописывается свой код. Сам вызов из заглушки дергает процессор из devel окружения и отрабатывает полный алгоритм.
2. Плагин агрегатора расширяется наследником для страны, если это необходимо. Аналогично для шаблонов — простыми префиксами реализуется выбор нужного шаблона для конкретной страны/агрегатора/оператора.
2. Плагин агрегатора расширяется наследником для страны, если это необходимо. Аналогично для шаблонов — простыми префиксами реализуется выбор нужного шаблона для конкретной страны/агрегатора/оператора.
Как биллинг общается с сервисами? Например когда пользователь хотел купить подарок.
Не понял вопрос. С какими сервисами? С внутренними?
Да, с внутренними.
Никакой особой магии нет. У нас общий репозиторий, просто вызываем методы нужных классов :)
Если чуть подробнее, то во время обработки платежа, в транзакции, мы кладем запись в очередь доставки подарков. От туда ее забирают скрипты и доставлют подарок до пользователя.
Сам биллинг выступает для баду в виде «сервиса» у нас есть внутренее API, используем HTTP + JSON. Но весь остальной функционал просто код, дополнительных абстракций нет.
В виде полноценных сервисов работают только демоны написанные на C.
Если чуть подробнее, то во время обработки платежа, в транзакции, мы кладем запись в очередь доставки подарков. От туда ее забирают скрипты и доставлют подарок до пользователя.
Сам биллинг выступает для баду в виде «сервиса» у нас есть внутренее API, используем HTTP + JSON. Но весь остальной функционал просто код, дополнительных абстракций нет.
В виде полноценных сервисов работают только демоны написанные на C.
Direct billing — вы имеете ввиду прямой биллинг баланса моб телефона?
Вы описываете биллинг, но нигде не говорите о выставлении счетов. Этой задачи у Вас нет? Или у Вас проста и тривиальна?
Sign up to leave a comment.
Биллинг в большом проекте