Биллинговые системы *

Платёжные системы стали активным участником рынка личных и корпоративных счетов. Они предлагают аналогичный банковскому сервис. В некоторых случаях качество обслуживания выше, процессы идут быстрее и стоят дешевле.

Но всё равно счета иногда закрывают. Почему это происходит и как этого избежать?

В этом материале будет:

• Несколько реальных кейсов для понимания ситуации в целом;
• Причины закрытия счетов в платёжных системах;
• Принцип работы с платёжными системами, который позволяет снизить риск заморозки и закрытия счета.

Как и за что закрывают счета в платёжных системах

Рассмотрим три кейса из нашей практики, которые покажут с какой лёгкостью могут закрыть счета некоторые платёжные системы. Для безопасности мы не станем писать названия этих платёжных систем, но скорее всего вы догадаетесь, о каких из них идёт речь – чаще всего на слуху именно популярные платёжные системы.

Эту статью можно рассматривать как один из частных случаев нашего способа принимать решения о разработке и развития продуктов. Если вам интересна тема выбора, какие фичи и в каком приоритете нужно реализовать в своем продукте, то рекомендуем к прочтению «Как мы выбираем идеи для развития своих продуктов: вендор должен уметь слышать…».

Дисковые битвы на светящейся Арене

Я в детстве смотрел Tron и компьютерная сеть была для меня сказкой. Потом были Hackers, которые добавляли романтизма. Были споры с друзьями о том, что Linux круче Windows без понимания, что операционные системы вообще из себя представляют.

Работаем с рисками на глобальном уровне

Мы в прошлой статье про проектные кейсы говорили о проблемах. В одном примере по водопаду пришлось расширять границы проекта, менять БПИ, пересогласовывать бюджеты. Во втором проекте с гибкой методологией вообще никакой пользы заказчик не извлёк. В третьем случае гибридный подход позволил завершить проект успешно и в срок только потому что команда проекта со стороны заказчика была хорошо мотивирована на результат и, осознавая ограниченность ресурсов, внося новые постановки убирала менее приоритетные задачи из спринтов. Мы будем ссылаться на первую статью, поэтому если Вы ее не читали, есть смысл проглядеть ее хотя бы по диагонали – вот ссылка.

Да все уже 100 раз про управление проектами написали

Абсолютно верно, про управление проектами по разным методологиям разве что ленивый еще не написал. Поэтому мы общие ситуации и прелести разных методологий обсуждать не будем. Зато расскажем о нескольких кейсах, когда сработали риски, несмотря на использование какой-то из методологий управления проектами, и как мы из проблемной ситуации выходили.

At The Beginning…

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

Мы хотели быть такими же крутыми и технологичными, как западные вендоры, но более универсальными и доступными по цене среднему бизнесу, так появилась идея создания новой компании, способной справиться с этой задачей. Зарегистрировали её в декабре 2005. Костяк команды сложился из выходцев из компаний-вендоров биллингов и ведущих интеграторов того периода.

В первой команде было всего 6 человек. Жесткой специализации не было, все занимались смежными задачами. Растили команду внедрения, выполняли не более 1-2 проектов одновременно. Один проект на тот момент мог длиться год, приходилось дописывать много функционала.

После долгих лет работы на проектах автоматизации биллинговых систем для крупных компаний мы решили осваивать новый рынок – SMB. Под катом делимся своими первоначальными ожиданиями, пройденным путём и результатами.

Здравствуйте, дорогие друзья.

Сегодня хочу поделиться историей из жизни, как было устроено хранилище DWH в Tele2 до внедрения КХД (EDW).

Поступил я в ИТ подразделение Tele2 в 2012 в отдел по системам отчетности. На тот момент в компании уже было создано хранилище DWH, на котором уже крутилось много процессов по предоставлению отчетности и не только.

Немного по поводу технического стека, который там использовался на тот момент. Для хранилища использовалась Оракловая база объемом 60-100 Тб сервер T4-4 c оперативой под 1 Тб. Туда загружались данные из различных источников. Но основными из них были 4 оракловые биллинговые базы, которые были по сути платформой тарификации. И был отдел, который занимался поддержкой этих баз и предоставлением сервисов. Разделение этих баз было по макрорегионам. Причина: слишком большие объемы. Т.е если абонент звонит, скажем, из Московской сим-карты то и расчет стоимости звонка производится в соответствующем биллинге.

Для тех, кто интересуется темой автоматизации на iOS, у меня две новости — хорошая и плохая. Хорошая: в iOS-приложении для платных сервисов используется только одна точка интеграции — in-app purchases (встроенные в приложение покупки). Плохая: Apple не предоставляет никаких инструментов для автоматизации тестирования покупок.

В этой статье я предлагаю вам вместе со мной поискать универсальный метод автоматизации по ту сторону добра и зла Apple. Статья будет полезна всем, кто интегрирует в свои приложения сторонние сервисы, представляющие собой «чёрный ящик»: рекламу, стриминг, управление локацией и др. Обычно такие интеграции очень сложно тестировать, так как отсутствует возможность гибкой настройки стороннего сервиса для тестирования приложения.

У управленца компании-разработчика биллинга есть два пути построения команды. Первый – набрать уже готовых «сеньоров» и непрерывно создавать такие условия работы, чтобы они использовали навыки и опыт по максимуму, развивались и при этом не передрались. Второй – создать команду из микса новичков, «мидов» и профи, чтобы те общались, влияли друг на друга, учились и росли внутри компании. Я против замкнутого круга а-ля «нет опыта – нет работы – нет опыта» и не вижу проблемы в найме начинающего разраба. В Forward Telecom давно действует стажерская программа, которая стала трамплином карьеры для многих работающих сотрудников.

Сейчас расскажу, как я вижу путь развития разработчика биллинга, и в какой последовательности нужно осваивать профессиональные навыки.

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

Мы разрабатываем автоматизированную систему расчетов (АСР) – биллинг. Срок
жизни нашего продукта 14 лет. За это время система прошла путь от первых версий промышленного тарификатора до модульного комплекса, состоящего из 18 продуктов, дополняющих друг друга. Один из важнейших аспектов долгой жизни для программ – постоянное развитие. А для развития нужны идеи.

Идеи

Источники

Можно выделить 5 источников:

Quorum — блокчейн на базе Ethereum, разработанный JPMorgan и совсем недавно ставший первой платформой распределенного реестра, которую предлагает Microsoft Azure.

Quorum поддерживает приватные и публичные транзакции и имеет много коммерческих сценариев использования.

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

Код, используемый в данном руководстве, лежит в репозитории на GitHub.

Статья покрывает:

• создание смарт-контракта;
• развертывание сети Quorum при помощи Chainstack;
• публичные транзакции Quorum;
• приватные транзакции Quorum.

Для иллюстрации используется сценарий мониторинга температуры в складских помещениях участников сети Quorum в рамках Internet of Things (IoT).

Вся история человечества — это попытки разрушить старый порядок вещей и построить новый, разумеется, лучший. (Анонимный автор)

В прошлой статье «Что нам стоит блокчейн построить?» мы разобрались с технологиями, на которых работают все блокчейны. Пришло время понять какие задачи могут решить современные блокчейны. Для начала давайте посмотрим на аналитику текущего состояния блокчейна и перспективах на будущее. Как техническому специалисту, мне импонирует компания Gartner с ее многочисленными циклами зрелости технологий (Hype Cycles). На графике показан цикл зрелости блокчейна в бизнесе на конец 2018 года. Какие выводы можно сделать?

«Цифра» идет в телеком, а телеком идет в «цифру». Мир стоит на пороге четвертой промышленной революции, а российское правительство проводит масштабную цифровизацию страны. Телеком вынужден выживать в условиях радикальных изменений в работе и интересах клиентов и партнеров. Растет конкуренция со стороны представителей новых технологий. Предлагаем посмотреть на вектор digital-трансформации и обратить внимание на внутренние ресурсы для развития бизнеса операторов связи.

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

Вся история человечества — это непрерывное избавление от цепей и создание новых, еще более крепких. (Анонимный автор)

Анализируя многочисленные blockchain проекты (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin и др.), я понимаю, что с технической точки зрения все они построены по одним принципам. Блокчейны напоминают дома, у которых при всем разнообразии конструкций, декора и назначений имеются фундамент, стены, крыша, окна, двери, которые связаны друг с другом определенными способами. И если понять основные принципы проектирования зданий, знать свойства применяемых материалов, то можно определить целевое назначение конкретного дома. В настоящее время с блокчейном возникла ситуация, что все про него слышали, но мало кто понимает архитектуру и принципы работы. Поэтому возникает непонимание для чего и как имеет смысл использовать технологии блокчейна.

В данной статье мы разберем общие для всех блокчейнов свойства и принципы. Далее посмотрим на задачи, которые можно решать с помощью блокчейна и для закрепления материала построим маленький, но настоящий блокчейн на своем виртуальном участке!

Итак, давайте вспомним какие проблемы изначально решил блокчейн.

«Компания» — оператор связи ПАО «Мегафон»
«Нода» — сервер RabbitMQ.
«Кластер» — совокупность, в нашем случае трех, нод RabbitMQ работающих как единое целое.
«Контур» — совокупность кластеров RabbitMQ, правила работы с которыми определяются на стоящем перед ними балансировщике.
«Балансировщик», «хап» — Haproxy – балансировщик, выполняющий функции переключения нагрузки на кластеры в рамках контура. Для каждого контура используется пара серверов Haproxy, работающих параллельно.
«Подсистема» — публикатор и/или потребитель сообщений, передаваемых через кролика
«СИСТЕМА» — совокупность Подсистем, являющая собой единое программно-аппаратное решение, используемое в Компании, характеризующееся распределённостью по всей территории России, но обладающее несколькими центрами, куда стекается вся информация и где происходят основные расчёты и вычисления.
СИСТЕМА – географически распределённая система – от Хабаровска и Владивостока до Санкт-Петербурга и Краснодара. Архитектурно это несколько центральных Контуров, разделенных по особенностям подсистем, к ним подключённым.

В мои каталоги Поиск VPS и VPS.today попадают не все хостеры, которые присылают заявки на добавление, а некоторые со временем исчезают из них. Происходит это потому, что мы очень дорожим своей репутацией и стараемся максимально точно и полно отображать информацию о представленных услугах, а также обезопасить пользователей от возможных подводных камней при сотрудничестве с хостером. Сегодня я хочу рассказать о правилах и подробно расписать, почему мы используем каждое из них.

На хабре есть скромный юзер TC40, пишущий про реалии эквайринга в России и молчащий о том, что у него вышла книга по электронным платежам, которую я увидел в книжном и не без интереса прочитал. Как я понимаю, это первый учебник в России по электронным платежам. Что бы сэкономить вам время вынесу главное, что понял из книжки. Может и автор подтянется в комментарии.

Больше всего интерес представляют впервые открыто опубликованные внутренние правила платежных систем Visa и Mastercard. Не смотря на то, что формально во всех странах правила одинаковы, в реальности они различаются на западе и в России в маленьких, но принципиальных деталях.