Pull to refresh

Comments 27

Радостно слышать что люди открывают для себя транзакционный бизнес в платёжных системах. Но печально что изобретают велосипеды.
Хм, а что можно было бы использовать вместо велосипедов? Мы же их изобретали не просто так (

Ну и уже давно не открывают, это не первая платежка в моей жизни )
Я занимаюсь платежными системами в Нигерии, где на ИБ кладут здоровый болт, в итоге забавно сравнивать свой опыт с чужим. Например те же ключи шифрования для сетевых запросов по протоколу iso 8583. По правилам их положено разбивать на две части, которые должны знать два разных человека, которые должны вводить их в терминалы каждый свой фрагмент, чтобы никто не знал целый ключ. На практике же нам эти ключи все сразу (обе части + комбинированный итоговый) присылали по простому емейлу.

Вообще очень грустно что все эти нюансы толком нигде не описаны. Нету гайдов «платежные системы для чайников», есть только какие-то совершенно огромные нечитаемые многотомники отдельных стандартов, тех же EMV или PCI DSS в которых без опыта фиг разберешься. И область это довольно узкая и готовых спецов в ней сложно найти. В итоге каждая команда вынуждена снова и снова ходить по тем же граблям.
Насколько я могу видеть, с ИБ вообще все довольно плохо. К нам на собеседования регулярно приходили разработчики из банков или платежных систем — и судя по ответам, далеко не всюду всерьез заботятся о безопасности.
У меня после нескольких сделанных платежных систем развилась легкая личная паранойя на теме доступа к данным и уязвимостям, но в большинстве проектов не готовы увеличивать стоимость разработки и поддержки ради безопасности. Хорошо, если аудитор грамотный и может показать какие-то реальные уязвимые точки, но обычно при PCI DSS аудите проверяются только система, связанная с карточными данными, а это далеко не полный список уязвимостей.
А вместо руководства «платежная система для чайников» — проще найти специалистов для отдельной консультации, все будет дешевле, чем самому грабли собирать. Так, в общем-то, почти в любых сложных проектах.
Так в том и дело что тратить дополнительные деньги (на консультации или аудит) никто не хочет. Типа «у нас пять лет все норм работало значит все в порядке». А то что у них POS-терминалы шлют карточные данные по незашифрованному протоколу (даже банальный TLS они три года настроить не могут), при этом вполне вероятно что часть из них сидит в плохо защищенных wifi сетях — это фигня. Спасает только то, что уровень нигерийских хакеров видимо соответствует уровню их разработчиков.

Были бы какие-то общедоступные гайды — можно было бы хотя бы на них ссылаться.
Ну, в документах по PCI DSS есть выжимки по организации безопасности, их можно использовать для убеждения. И есть же список общих практик по информационной безопаности (вечно забываю, как именно документ называется, но все безопасники на него всегда ссылаются), можно его использовать. Он тоже вполне конкретен.
«Самое идеальное решение было бы, наверное, редактор текстов, встроенный прямо в IntelliJ IDEA, где можно сложность использования Git аккуратненько скрыть. Но, к сожалению, JetBrains такого редактора до сих пор не сделали, хотя я давно их просил.» — не правда, *.md можно успешно редактировать и видеть итог, можно просто текст править и просто складывать его в репозиторий, можно *.html править и в браузере смотреть, вариантов много.
Редактирование html не подходит по условиям задачи (с текстами должны работать люди, не разбирающиеся в верстке). Про плагин работы с Markdown я, конечно, знаю, но это именно плагин, не очень удобный в использовании для «не программиста» и не убирающий всю прочую сложность Idea. Я имел в виду отдельное решение типа WebStorm, но не для языка программирования, а для текстов (сложных текстов). С связями между файлами, возможностью добавить собственные CSS, возможностью добавить метаинформацию и т.п.
Так, что бы этот инструмент можно было дать редактору или маркетологу.
Теоретически, такое можно сделать из Eclipse, но это была бы уже более сложная разработка, нежели мы могли себе позволить.
А что за платежная система? Можно поподробнее про характеристики? Сколько платежей в секунду можете процессить? Какие операторы, типы операторов.
Как я уже говорил, платеж — это довольно сложно.
такие высказывания не придают значимости.
Вы очень еще любите говорить про enterprise. Enterprise — это когда не только вы зависите от систем, но и сторонние системы зависят от вас. А платежная система это не более, чем продукт для небольшой IT компании.
Ну, вообще-то в начале сказано, что это система платежей для легального российского букмекерского бизнеса. Таковых на рынке ровно две и я рассказывал не про Qiwi.
В качестве требований — до 100 платежей в секунду, сквозные платежи, прямые платежи, интеграция с другими агрегаторами, карточными процессингами и другими платежными системами.
Почему платеж — это гораздо сложее, чем кажется, я довольно много рассказывал. Статусы, надежность переходов, юридические ограничения и так далее.
Ну и от этой системы зависит где-то половина российского онлайного букмекерского бизнеса, это не мало. Собственно, потому и на грани энтерпрайза.

Подумайте о переходе с обработки единичных платежей на обработку пачек платежей, естественно, асинхронно. Так вы решите вопрос производительности радикально.

Увы, это имело бы смысл, если бы контрагенты поддерживали бы пакетную обработку и если бы у всех платежей был бы одинаковый процесс прохождения.
Но это не так, контрагенты не поддерживают пакетной обработки и каждый платеж достаточно индивидуален.
А все, что можно сделать пачкой мы, конечно, сделали, но таких операций очень и очень мало. Да и логика обработки сильно усложняется.

А вам нужно проще или быстрее?
Да, контрагенты есть разные, и да, процессы прохождения платежей различаются. Но процентов на 90 платежи имеют одинаковую обработку и их можно автоматически, на стороне АБС организовать в пакеты, и обрабатывать пакет за раз.
Просто как пример способа объединения — одной из "тяжёлых" операций является изменение остатка/ликвидности на счетах при исполнении платежа. Типично в АБС остаток меняется каждой проводкой отдельно. Если вы сгруппируете проводки по задействованным счетам и отложите апдейт остатка на обработку пакета проводок, вы сразу получите прирост производительности.

А откуда взялась такая статистика «90 процентов имеют одинаковую обработку»? У нас категорически не так.
Впрочем, подозреваю, вы путаете процессинг (проведение онлайн платежа) и банковский учет (оформление проводок в АБСке). Я рассказываю в основном про процессинг, где задержки пользователя недопустимы, а проводок вообще нет (платеж, представляет собой первичный документ в терминах бухучета и в АБСку поступает только при удачном завершении).
Разумеется, интеграция с АБСкой делается пакетно, уже после завершения платежа. Проблемы возникают, скорее, из-за неторопливости нашей АБСки (впрочем, насколько я знаю, это проблема не столько нашей конкретной системы, сколько всех АБСок — они в основном сделаны по технологиям прошлого века), ну для этого мы и переводим потихоньку бухучет в процессинг (где он занимает, впрочем, совершенно незначительное время по сравнению с прочими этапами платежа).
Ну а изменение остатка и ликвидности в процессинге — совершенно не значимая операция, что там может быть сложного и тяжелого…
Например, если мы выложили не те комиссии, которые мы реально взимаем, пользователи потом могут очень сильно на нас обидеться, а, главное, на нас могут обидеться контролирующие органы, что гораздо хуже. Поэтому тексты для нас — это тоже код: нужно проверять его перед публикацией, в его подготовке задействовано много людей, ошибки дорого стоят.

Только что пришла смс от МТС о грядущем изменении тарифа. Перехожу в подробности и что вижу — если сейчас я плачу 8 руб. в сутки, то буду платить 820, или около того, в чём я нисколько не сомневаюсь :)
Новые тарифы

О да, давно ли я приходил к тебе и смотрел на большие машины )
Ну, примерно так, подозреваю.

Такие проблемы которые вы описали прошли многие процессинги платежей


  • Стейт машин для платежа не подходит на практике лучше себя показало использование шагов, каждый платеж набирает пройденные шаги и в зависимости от набранного множества принимается решение.
  • Долгая транзакция это действительно проблема, и ваше решение выглядит, как пришли через боль, написание шлюзов становится не тривиальной задачей.
  • То что для анализа финансовой системы выгружаете данные о платежах в клауд это просто капец. Говорит о вашей не состоятельности, Вы не понимаете что у вас творится в системе с деньгами? С НКО у вас наверно беда.
  • Для очередей в бд, ребята из яндекс денег выложили отличный проект db-queue
  • Очень понравилось что вы сделали с безопасностью, это действительно последняя тема которой уделяют внимание(но примеры с qiwi, Rapida и д.р. дали талчек, но пока гром...)
  • Еще порадовало архитектура динамическая ;-(
    Спасибо отличная статья, я бы хотел добавить что мир платежных систем держится на идемпотентности, так что платим не боимся. :-)
О, содержательный комментарий, ура. По пунктам:
1) Если посмотришь на статью, то именно это мы и сделали. Только шаги набираются не заранее, а в процессе прохождения платежа. От чистого STM мы отказались вообще сразу, а дальше был длинный путь до осознания, что наша модель работы с платежами — это просто персистентные акторы.
2) Как раз с шлюзами у нас проблем нет, они на акторной модели пишутся просто и там легко можно вместо длинных транзакций внутри одного шага сделать несколько шагов, базы данных у шлюзов независимые, в производительность не упремся. Тут главное — в продуманном внутреннем API для шлюзов, если оно асинхронное, то все пишется достаточно просто.
3) Э, не надо путать учет в НКО и бизнес-аналитику. Учет в НКО — это управленческий и бухгалтерский, ведется в АБСке, и там все достаточно хорошо (по крайней мере и бизнес и аудит ЦБ довольны). А бизнес-аналитика нужна для ответов на вопросы вида «после обновления API у такого-то контрагента как изменилось распределение ошибок по соответствующему шлюзу» или «мы изменили дизайн формы оплаты через мобильных операторов, что стало с конверсией» или «один из клиентов начал рекламную акцию на Дальнем Востоке, как это изменило поток платежей по региону сравнительно с предыдущими подобными акциями». Это очень разные инструменты. Одним из требований к бизнес-аналитике, кстати, является интеграция с Google Analitics.
4) Как ты думаешь, кто проектировал самую первую очередь (еще на Oracle) на БД в Яндекс.Деньгах? И переписывал ее потом на skip locked? Да и появилась db-queue уже после того, как мы сделали свое собственное решение. И в нашем решении некоторые вещи сделаны заметно гибче и (для нас) удобнее. Например, возможность задавать свои стратегии повтора (произвольные) или добавлять действия на коммит транзакции обработки (для инвалидации или заполнения кэшей, например).
Собственно, то, что я делал в текущем проекте — это как раз попытка не наступить на те грабли, что были в Яндекс.Деньгах.
5) Сейчас у меня есть понимание, как это можно сделать еще проще, но пока не реализовано, так что доклада пока не будет )
6) Спасибо. Но идемпотемптность идет по одной операции, а не по цепочке. И не все контрагенты (почти никто, если честно) вообще не поддерживают идемпотемптность в платежах, так что все не так хорошо. Ну и пособеседовав кучу разработчиков и архитекторов из маленьких платежных систем — я понял, что спокойно готов пользоваться только теми, что сам писал (так что Яндекс.Деньгами я спокойно пользуюсь).
С аналитикой мы пошли другим путем :)
Долгое время внедрял системы интеграции, АБС банков с процесингами платежей и везде были одни и те же проблемы не сходится день, откаты в закрытом дне, расчеты на счетчиках, нет стабильности в отчетах, нет понимания у каких поставщиков какие деньги.
На рынке мы так и не нашли, что смогло бы удовлетворить нас.
Написали свой ;-) но пошли от схемы проводок, запихали часть абс в процесинг и получили банковский учет внутри. Получили учет по банковским правилам, получили аналитику в обортно сальдовой ведомости.
Ну, у нас, вроде бы, проблем с АБСкой нет. Там есть ограничения по производительности (слишком дорого получается масштабировать), так что мы тоже переносим банковский учет внутрь процессинга. И, конечно, внутри процессинга приходится делать проводки, счета и т.п, но это как раз относительно просто, хотя и муторно. Сложности там скорее в прекрасных отчетах из 255 полей для Финмониторинга и прочих вещах, связанных с персональными данными.
Кстати, а ты (или лучше на Вы) где работаешь?
На будущее заметка — у нас Firebird3 держит сотни соединений в варианте суперсервера без проблем. Может много больше. Не постгресом единым.
Сотни (и тысячи) и PostgreSQL держит. Но в Firebird нет skip locked (и вообще, насколько я помню, там очень ограничено управление блокировками и транзакциями).
С трудом себе представляю сценарий, в котором мне мог бы понадобиться Firebird.
Sign up to leave a comment.