Русский
Русский
English
Статистика
Реклама

Платежные системы

B-Money история первой в мире криптовалюты

21.05.2021 16:09:34 | Автор: admin


31 октября 2008 года произошло событие, которое кардинально изменило всю привычную нам картину мира и оказало значительное влияние на экономику, развитие технологий и культуру. Именно в этот день никому не известный человек (или группа людей), скрывающийся под псевдонимом Сатоси Накамото, опубликовал статью Bitcoin: A Peer-to-Peer Electronic Cash System, положив начало истории биткойна. Однако еще за десятилетие до этого, в 1998 году, выпускник Вашингтонского университета Вэй Дай (Wei Dai) создал проект децентрализованной платежной системы, которая должна была использовать в своей работе криптографические алгоритмы. Даже называлась она похоже: B-Money.

Как закалялась сталь


О самом Вэй Дае американце китайского происхождения известно несколько больше, чем о легендарном Сатоси, но тоже немного. Он окончил Вашингтонский университет, получив степень бакалавра по информатике и математике. В профиле Вэй Дая, некогда размещенном на сайте несуществующей ныне компании VoteHere, говорилось, что он работал в составе исследовательской группы на корпорацию Microsoft в Редмонде, Вашингтон, где занимался криптографией. А до того как присоединиться к Microsoft, Вэй Дай трудился программистом в компании TerraSciences в Эктоне, Массачусетс. Это отчасти подтверждается и тем, что человек по имени Вэй Дай заявлен в качестве автора связанных с криптографическими технологиями изобретений согласно американским патентам 5724279 и 6081598, права на которые принадлежат Microsoft.


Вэй Дай получил степень бакалавра в Вашингтонскиом университете это немногое, что о нем известно достоверно.

Именно Вэй Дай является создателем криптографической библиотеки с открытым исходным кодом Crypto ++ (также известной как CryptoPP, libcrypto ++ и libcryptopp). Кроме того, в 2007 году совместно с Тедом Кровецем Вэй Дай разработал алгоритм универсального хеширования, послуживший основой для механизма аутентификации сообщений VMAC. Еще Вэй Дай первым обнаружил критическую уязвимость в криптографическом протоколе TLS (если говорить точнее в используемой TLS реализации режима шифрования Cipher Block Chaining (CBC)). Благодаря именно этой уязвимости стало возможным создание нашумевшего эксплоита BEAST (Browser Exploit Against SSL/TLS).

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

Однако вернемся к истории создания B-Money. Источником вдохновения для Вэй Дая по его собственным словам стала идеология криптоанархизма, которой он проникся благодаря текстам Тимоти Мэя. Криптоанархисты предрекали создание общества, свободного от какого-либо насилия прежде всего потому, что само по себе насилие невозможно, если членов социума нельзя идентифицировать благодаря повсеместному использованию криптографии.


Тимоти Мэй один из самых известных в мире шифропанков.

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

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

Описная Вэй Даем идея в общих чертах сводится к следующему. Субъектами придуманной им платежной системы являются анонимные цифровые псевдонимы, которые никак не связаны с реальными личностями участников. Для поддержки работоспособности системы ее пользователи должны выполнять определенную вычислительную работу, за которую им выплачивается вознаграждение. Эта работа фиксируется в коллективном журнале с тем, чтобы ее могли проверить другие участники. В процессе аутентификации и подтверждения транзакций также применяется коллективный учет, при котором используется шифрование с открытыми ключами. Сам Вэй Дай писал: Протокол B-money был задуман таким образом, чтобы он мог сохранить конфиденциальность всех участников, оставаясь при этом средством обмена и предоставляя исполняемые контракты сообществу. Ничего не напоминает?

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

Концепция A-Money


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

Каждый пользователь системы идентифицируется цифровым псевдонимом. Все сообщения в системе подписываются открытым ключом отправителя и передаются получателю в зашифрованном виде. Любой участник системы может зарабатывать деньги, транслируя решение ранее нерешенной вычислительной задачи, при этом основным критерием оценки работы является объем вычислительных ресурсов, потраченных на решение. Для этого Вэй Дай решил использовать принцип, напоминающий способ вычисления индекса товарных цен (commodity price index). К примеру, если задача может быть решена на компьютере, который тратит на это минимум ресурсов, за 100 часов, а для покупки такого же вычислительного ресурса на открытом рынке потребуется 3 условных индексных единицы, то именно такая сумма в денежном эквиваленте и будет зачислена на счет решившего задачу участника системы, а информация об этом зафиксируется в локальных базах данных всех остальных пользователей.

Транзакции в предложенной Даем системе выполняются следующим образом. Например, Алиса (цифровой псевдоним А) решила передать Бобу (цифровой псевдоним Б) виртуальную валюту на сумму Х единиц. В этом случае она отправляет широковещательное сообщение вида я отправляю Х денежных единиц цифровому псевдониму Б, и подписывает его своим ключом А. После трансляции этого сообщения все участники системы вносят в свою локальную базу соответствующее изменение, а именно, списывают со счета псевдонима А сумму в Х монет и добавляют ее на счет псевдонима Б. Транзакция считается успешной, если эта операция не приводит к возникновению отрицательного баланса на счете А в этом случае сообщение игнорируется.


При выполнении транзакций в системе A-Money участники сделки отправляют всем остальным пользователем широковещательное сообщение, зашифрованное открытым ключом

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

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


Схема исполнения контракта в системе A-Money.

Исходя из описанной выше логики работы системы становится очевидно, что с ростом числа участников будет расти и объем базы, в которую записывается информация обо всех транзакциях. Поскольку точная копия такой базы хранится у каждого участника локально, скорость ее обновления будет крайне невысокой и со временем станет снижаться. Участникам системы необходимо также постоянное подключение к сети для своевременной загрузки непрерывно обновляющихся данных, которые гарантированно создадут значительный трафик. Кроме того, использование такой платежной системы потребует значительных аппаратных ресурсов как минимум, достаточного объема дискового пространства, которое в 1998 году было весьма дефицитным. Нужна была альтернатива.

Концепция B-Money


Именно поэтому Вэй Дай предложил альтернативный протокол для своей платежной системы, который и получил название B-Money. Общий принцип остался тем же самым, только для хранения базы данных о транзакциях в B-Money использовались компьютеры не всех участников сети, а лишь некоторых. Машины таких хранителей Дай условно назвал серверами. В качестве образца для структуры этой сети Вэй Дай взял Usenet самую популярную на тот момент сеть для общения и обмена файлами. Формат широковещательных сообщений о любых операциях в системе B-Money был идентичен описанному выше, но с одним отличием: участники каждой транзакции должны в обязательном порядке убедиться, что сообщение было получено и успешно обработано случайно выбранным подмножеством серверов. Актуальность баз транзакций по задумке Дая должна поддерживаться их постоянной синхронизацией.

Однако в этом случае возникает проблема доверия серверам со стороны других участников системы. Вэй Дай решил ее следующим образом: каждый сервер должен депонировать определенную сумму цифровых денег на специальном счете. Если какой-либо из серверов оказывался замеченным в тех или иных мошеннических действиях, на него налагается штраф, который списывается с этого депозита. А участнику, заметившему мошенничество, с того же счета начисляется вознаграждение. Кроме того, хранящаяся на каждом из серверов база данных транзакций должна быть публичной, чтобы любой участник системы в любой момент времени мог проверить, совпадает ли локальная информация о состоянии его счета с записью в этой базе. Также любой участник по желанию должен иметь возможность убедиться, что общая сумма денег на всех счетах пользователей не превышает общую сумму цифровой валюты, которой оперирует платежная система. Это исключает возможность бесконтрольного наращивания денежной массы даже в случае сговора владельцев всех серверов в сети.


Общая структура B-Money.

Другая серьезная проблема B-Money, на которую обратил внимание Вэй Дай, это процесс эмиссии цифровых денег. В предложенном для A-Money алгоритме подразумевалось, что решение о стоимости конкретных вычислений согласованно принимается всеми держателями учетных записей. В случае архитектуры с серверами сеть имеет меньшую связанность, и это может стать серьезной проблемой. Поэтому для B-Money Дай предложил иной механизм: все серверы в сети B-Money принимают консолидированное решение о том, какой объем цифровой валюты должен быть выпущен в каждый конкретный период времени, а стоимость создания этих денег определяется аукционом. При этом сам процесс он разделил на четыре этапа:

1. Все держатели аккаунтов B-Money определяют по заданным алгоритмам оптимальный объем денежной массы, которую следует выпустить в следующем периоде. Неважно, придут ли участники системы к судьбоносному консенсусу, но каждый из них транслирует в сеть вычисленную им квоту. На основе полученных данных вырабатывается консолидированное решение об объеме цифровой валюты, выпускаемой в следующем периоде.
2. Каждый участник системы, желающий принять участие в эмиссии цифровой валюты, транслирует в сеть ставку в формате <X, Y>, где X сумма в B-Money, которую заявитель рассчитывает получить за решение задачи, а Y сама математическая задача, выбранная из пула ранее нерешенных задач. При этом каждая задача имеет публично согласованную номинальную стоимость в MIPS-годах.
3. Все участники системы выполняют работу согласно своим заявкам и транслируют в сеть полученные решения.
4. Из транслируемых решений принимаются и оплачиваются только имеющие самые выгодные ставки с точки зрения номинальной стоимости решенной задачи за единицу B-Money.

Можно сказать, что в 1998 году Вэй Дай придумал платежную систему, очень напоминающую хорошо знакомые нам современные криптовалюты. По крайней мере, она отвечает сразу нескольким критериям, по которым ее можно отнести к этой категории:
для ее добычи (майнинга) требуется выполнить определенный объем вычислительной работы;
проделанная работа проверяется другими участниками системы, а успешно выполнивший ее участник получает вознаграждение;
ведется коллективный учет транзакций, которые аутентифицируются с использованием криптографии;
контракты исполняются путем отправки широковещательных сообщений и подписания транзакций цифровыми подписями (криптография с открытым ключом).

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



Вместо эпилога


В своей основополагающей публикации Bitcoin: A Peer-to-Peer Electronic Cash System Сатоси Накамото все-таки сослался на проект B-Money это краткое упоминание на второй странице документа удостоилось единственной лаконичной сноски в разделе References. Однако в заметке Decoding the Enigma of Satoshi Nakamoto and the Birth of Bitcoin, опубликованной газетой New York Times 15 мая 2015 года, утверждалось, что Вэй Дай, а также известный британский криптографист и шифропанк Адам Бэк (Adam Back) были первыми людьми, с которыми связался Накомото в ходе работы над биткойном. Правда, сам Вэй Дай прокомментировал этот момент весьма скептически:

я так понимаю, что создатель биткойна [...] даже не прочитал мою статью, прежде чем сам заново изобрел эту идею. Он узнал об этом позже и упомянул меня в своей работе. Так что моя связь с проектом довольно ограничена.

Несмотря на то, что платформа B-Money так навсегда и осталась в истории лишь в виде концепта, создатели других успешных криптовалют не забывают о ней. Например, самая маленькая дробная единица эфира криптовалюты, работающей на платформе Ethereum, названа wei. И теперь вы знаете, в чью именно честь.

Некоторые любители конспирологии всерьез считают, что однажды, когда тайна виртуальной личности Сатоси Накамото будет наконец раскрыта, среди создателей биткойна мы обнаружим немало известных личностей: и уже упомянутого Адама Бэка, и ученого-криптографиста Ника Сабо (Nick Szabo), но в первую очередь Вэй Дая собственной персоной. Кто знает, может, они окажутся правы?


Подробнее..

Мошенники в яндекс-инвестициях

22.04.2021 20:09:52 | Автор: admin

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

Первый звонок.

Несколько дней назад я скачал на свой телефон приложение "ВТБ инвестиции". Да, думал поиграться в акции на брокерском счете. Я не являлся клиентом банка ВТБ, но приложение все равно пообещало, что за 5 минут создаст для меня брокерский счет...

Пройдя несколько простых шагов по заполнению всяких персональных данных, нажал на заветную кнопку чтобы создать счет и... приложение сказало, что-то вроде: "произошла ошибка, возможно вы уже являетесь клиентом банка".

Я конечно искренне удивился, поскольку совершенно точно знал, что клиентом банка ВТБ никогда не был. Пытливый ум предложил мне попробовать стать настоящим клиентом ВТБ, чтобы попробовать открыть брокерский счет уже из нормального онлайн банка.

Второй звонок.

Стать клиентом банка ВТБ оказалось довольно просто: зашел на их сайт, указал свои данные, через два дня курьер принес домой дебетовую карту. Подписали бумаги, курьер ушел, довольный, я скачал и зашел в приложение ВТБ-онлайн. Все замечательно, нахожу в приложении кнопку "создать брокерский счет", нажимаю и... вижу ошибку: "невозможно создать брокерский счет, у нас недостаточно данных, нужно прийти в офис с паспортом".

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

Третий звонок.

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

Сотрудница банка что-то очень быстро поправила и действительно: прежняя ошибка пропала, приложение в офис меня больше не отправляло, прислало мне СМС для подтверждения и... выдало новую ошибку, что-то вроде: "сбой при подключении к внешним данным".

Хорошо, что я не успел далеко отойти от офиса банка, вернулся.

Четвертый звонок.

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

Начинаю что-то подозревать.

Примерно через час случилось нечто странное: я зашел в ВТБ-онлайн, а там в разделе "Инвестиции" уже открыты брокерские счета. Вау, подумал я! Ну и сервис! Наверное паренек из офиса что-то там все таки подкрутил и мне теперь даже не надо открывать счета - они открылись сами!

Ну что же, счета открыты, пробую зайти в приложение с которого все началось: ВТБ инвестиции. Ввожу туда логин.., стойте, а пароль какой? Пробую от интернет-банка - нет. Пробую восстановить пароль одним способом - нет, другим - опять какие-то ошибки... Захожу в интернет банк через браузер, а там вся информация о брокерском счете как на ладони: "дата создания 13.01.2021".

Как интересно подумал я: как это брокерский счет был открыт на четыре месяца раньше, чем я стал клиентом банка???

Служба поддержки банка. Первая серия.

Ну ладно, очередной глюк подумал я с этой датой. Хочется уже войти в приложение ВТБ-Инвестиции, звоню в техподдержку по номеру который дает приложение после неудачного восстановления пароля.

Поддержка берет трубку быстро, я говорю - восстановите пароль, меня отправляют сначала восстанавливать через сайт, потом через приложение ровно так как я уже только что делал... Ну как обычно в любой техподдержке в общем. Когда ничего не помогло и девушка на другом проводе немного приуныла, я ради смеха рассказал про дату открытия счета, а она радостно подхватила: "а давайте я посмотрю как это произошло". Давайте сказал я.

Ну и при чем тут яндекс?

Через полминуты ожидания девушка из техподдержки ВТБ сказала то, что я ну вообще никак не ожидал услышать: "Вы действительно открыли этот счет 13.01.2021 через Яндекс. Можете поинтересоваться у яндекса о подробностях".

Вот это поворот! Я даже на минутку забыл о том, зачем звонил - про пароль от ВТБ-инвестиций. Потом все-таки подумал: ну старый я уже, начало января, может забыл и правда что-то там в яндексе делал? Ладно говорю, пусть так, пароль мне дайте уже от вашего приложения. Девушка перенаправила звонок к другому специалисту...

Служба поддержки банка. Вторая серия.

Второй специалист техподдержки ВТБ трубку не брал заметно дольше, но я сдаваться не собирался. Когда трубку взяли, конечно пришлось объяснять ситуацию с нуля - обычное дело при звонках в техподдержку...

Специалист на проводе оказался грамотным парнем и сразу перешел к делу: вам знаком номер с последними цифрами 6593? Разумеется у меня есть вторая симка номер которой я не знаю и использую только когда где-то балуюсь. Ну, говорю, наверное это мой второй номер. Парень сказал: надо обязательно с этого номера к нам позвонить, тогда пароль поменяем. Ок, говорю. Кладу трубку.

Вот так номер!

Перед тем как звонить в банк со своей второй симки, решил посмотреть все таки сначала ее номер и... номерок-то не тот! WTF?! Начал рыться в контактах - ни у кого нет такого номера!

Паники конечно никакой нет, потому что на всех счетах по нулям. Но ощущение какого-то сюрреализма: получается, что какой-то хмырь через какой-то яндекс умудрился открыть счет на мое имя в банке, клиентом которого я даже не являлся?!

Где счет открывали, туда и идите.

Открываю гугл, ищу "яндекс брокер", нахожу рекламу каких-то яндекс-инвестиций о которых в первый раз слышу. Захожу туда, там действительно предлагают открыть брокерский счет и действительно они партнеры ВТБ. Ситуация начинает для меня вырисовываться все отчетливей, но чтобы подтвердить подозрения связываюсь в чате с поддержкой яндекса, задаю закономерный вопрос: "кто и как мог открыть на мое имя брокерский счет который при этом никак не связан с моим верифицированным яндекс-аккаунтом и номером телефона"? Получаю ответ: "кто-то воспользовался вашими паспортными данными и открыл этот счет. Закрыть вы его можете только походом ногами в банк".

Ну вот как-то так.

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

Что дальше? Могу лишь догадываться: наверное, если бы я подумал что брокерский счет открыл для меня банк, попробовал бы этот счет пополнить, то мошенник получил бы уведомление о пополнении и вывел бы все со счета на свой аккаунт.

Подробнее..

Дыра в безопасности яндекс инвестиций

22.04.2021 22:14:44 | Автор: admin

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

Первый звонок

Несколько дней назад я скачал на свой телефон приложение "ВТБ инвестиции". Да, думал поиграться в акции на брокерском счете. Я не являлся клиентом банка ВТБ, но приложение все равно пообещало, что за 5 минут создаст для меня брокерский счет...

Пройдя несколько простых шагов по заполнению всяких персональных данных, нажал на заветную кнопку чтобы создать счет и... приложение сказало, что-то вроде: "произошла ошибка, возможно вы уже являетесь клиентом банка".

Я конечно искренне удивился, поскольку совершенно точно знал, что клиентом банка ВТБ никогда не был. Пытливый ум предложил мне попробовать стать настоящим клиентом ВТБ, чтобы попробовать открыть брокерский счет уже из нормального онлайн банка.

Второй звонок

Стать клиентом банка ВТБ оказалось довольно просто: зашел на их сайт, указал свои данные, через два дня курьер принес домой дебетовую карту. Подписали бумаги, курьер ушел, довольный, я скачал и зашел в приложение ВТБ-онлайн. Все замечательно, нахожу в приложении кнопку "создать брокерский счет", нажимаю и... вижу ошибку: "невозможно создать брокерский счет, у нас недостаточно данных, нужно прийти в офис с паспортом".

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

Третий звонок

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

Сотрудница банка что-то очень быстро поправила и действительно: прежняя ошибка пропала, приложение в офис меня больше не отправляло, прислало мне СМС для подтверждения и... выдало новую ошибку, что-то вроде: "сбой при подключении к внешним данным".

Хорошо, что я не успел далеко отойти от офиса банка, вернулся.

Четвертый звонок

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

Начинаю что-то подозревать

Примерно через час случилось нечто странное: я зашел в ВТБ-онлайн, а там в разделе "Инвестиции" уже открыты брокерские счета. Вау, подумал я! Ну и сервис! Наверное паренек из офиса что-то там все таки подкрутил и мне теперь даже не надо открывать счета - они открылись сами!

Ну что же, счета открыты, пробую зайти в приложение с которого все началось: ВТБ инвестиции. Ввожу туда логин.., стойте, а пароль какой? Пробую от интернет-банка - нет. Пробую восстановить пароль одним способом - нет, другим - опять какие-то ошибки... Захожу в интернет банк через браузер, а там вся информация о брокерском счете как на ладони: "дата создания 13.01.2021".

Как интересно подумал я: как это брокерский счет был открыт на четыре месяца раньше, чем я стал клиентом банка???

Служба поддержки банка. Первая серия

Ну ладно, очередной глюк подумал я с этой датой. Хочется уже войти в приложение ВТБ-Инвестиции, звоню в техподдержку по номеру который дает приложение после неудачного восстановления пароля.

Поддержка берет трубку быстро, я говорю - восстановите пароль, меня отправляют сначала восстанавливать через сайт, потом через приложение ровно так как я уже только что делал... Ну как обычно в любой техподдержке в общем. Когда ничего не помогло и девушка на другом проводе немного приуныла, я ради смеха рассказал про дату открытия счета, а она радостно подхватила: "а давайте я посмотрю как это произошло". Давайте сказал я.

Ну и при чем тут Яндекс?

Через полминуты ожидания девушка из техподдержки ВТБ сказала то, что я ну вообще никак не ожидал услышать: "Вы действительно открыли этот счет 13.01.2021 через Яндекс. Можете поинтересоваться у яндекса о подробностях".

Вот это поворот! Я даже на минутку забыл о том, зачем звонил - про пароль от ВТБ-инвестиций. Потом все-таки подумал: ну старый я уже, начало января, может забыл и правда что-то там в яндексе делал? Ладно говорю, пусть так, пароль мне дайте уже от вашего приложения. Девушка перенаправила звонок к другому специалисту...

Служба поддержки банка. Вторая серия

Второй специалист техподдержки ВТБ трубку не брал заметно дольше, но я сдаваться не собирался. Когда трубку взяли, конечно пришлось объяснять ситуацию с нуля - обычное дело при звонках в техподдержку...

Специалист на проводе оказался грамотным парнем и сразу перешел к делу: вам знаком номер с последними цифрами 6593? Разумеется у меня есть вторая симка номер которой я не знаю и использую только когда где-то балуюсь. Ну, говорю, наверное это мой второй номер. Парень сказал: надо обязательно с этого номера к нам позвонить, тогда пароль поменяем. Ок, говорю. Кладу трубку.

Вот так номер!

Перед тем как звонить в банк со своей второй симки, решил посмотреть все таки сначала ее номер и... номерок-то не тот! WTF?! Начал рыться в контактах - ни у кого нет такого номера!

Паники конечно никакой нет, потому что на всех счетах по нулям. Но ощущение какого-то сюрреализма: получается, что какой-то хмырь через какой-то яндекс умудрился открыть счет на мое имя в банке, клиентом которого я даже не являлся?!

Где счет открывали, туда и идите

Открываю гугл, ищу "яндекс брокер", нахожу рекламу каких-то яндекс-инвестиций о которых в первый раз слышу. Захожу туда, там действительно предлагают открыть брокерский счет и действительно они партнеры ВТБ. Ситуация начинает для меня вырисовываться все отчетливей, но чтобы подтвердить подозрения связываюсь в чате с поддержкой яндекса, задаю закономерный вопрос: "кто и как мог открыть на мое имя брокерский счет который при этом никак не связан с моим верифицированным яндекс-аккаунтом и номером телефона"? Получаю ответ: "кто-то воспользовался вашими паспортными данными и открыл этот счет. Закрыть вы его можете только походом ногами в банк".

Ну вот как-то так

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

Что дальше? Могу лишь догадываться: наверное, если бы я подумал что брокерский счет открыл для меня банк, попробовал бы этот счет пополнить, то мошенник получил бы уведомление о пополнении и вывел бы все со счета на свой аккаунт.

Подробнее..

Оплата в телеграм боте Платежи 2.0 Сбербанк Telegraf Node.js

02.05.2021 10:10:12 | Автор: admin

Платежи 2.0 В мессенджере Telegram появилась возможность принимать платежи в любом чате, включая группы и каналы. Подключить свой магазин к платформе можно самостоятельно, без согласования с Telegram.



И в этом туториале мы создадим простого бота с Node.js на фреймворке Telegraf.js, который сможет принимать деньги с клиента и отправлять их на ваш счет через Сбербанк.


Платежи 2.0


Платежи 2.0


Платёжные боты существуют в Telegram с 2017 года. С их помощью можно безопасно оплачивать товары и услуги вроде доставки пиццы, не покидая приложения.


С сегодняшнего дня продавцы могут принимать платежи кредитными картами с помощью 8-ми встроенных платёжных систем в любом чате, включая группы и каналы.


На данный момент поддерживаются платежи из более чем 200 стран через следующие платежные системы:


Платежи 2.0


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


Для оплаты можно использовать любое приложение в том числе Telegram для компьютеров. Покупатель также может оставить чаевые, чтобы поддержать любимого автора, кафе или магазин.


Создаём бота в Telegram


Бот в Telegram создается при помощи другого бота под названием @BotFather. Отправляем ему команду /newbot, выбираем имя, которое будет отображаться в списке контактов, и адрес. Например, Оплата в Telegram боте с адресом sber_pay_test_bot.


newbot


Если адрес не занят, а имя введено правильно, BotFather пришлет в ответ сообщение с токеном ключом для доступа к созданному боту.


ВНИМАНИЕ! Его нужно сохранить и никому не показывать.


Создаем проект Node.js


Далее создадим новый проект. Создаем папку.


Вводим в консоле:


mkdir sber_pay_test_bot && cd sber_pay_test_bot

Затем:


npm init 

Программа задаёт вам разные вопросы и создает package.json, который определяет настройки проекта, зависимости, скрипты, название и прочее. Для примера можно везде нажать enter


и добавим файл index.js в котором будет разрабатываться наш бот.


touch index.js    

Telegraf.js


Cтавим telegraf.js это один из популярных фреймворков для создания телеграм бота.


npm install telegraf@3.38 

Ставим библиотеку dotenv это модуль, который загружает переменные среды из файла .env в process.env., а также заодно поставим nodemon инструмент, который помогает разрабатывать приложения на основе node.js путем автоматического перезапуска приложения node при обнаружении изменений файлов в каталоге.


npm install dotenv nodemon

Добавляем скрипт запуска в package.json


"scripts": {    "start": "nodemon index"}

Из документации telegraf.js, копируем в наш проект первоначальную настройку бота.


const { Telegraf } = require('telegraf')require('dotenv').config()const bot = new Telegraf(process.env.BOT_TOKEN) //сюда помещается токен, который дал botFatherbot.start((ctx) => ctx.reply('Welcome')) //ответ бота на команду /startbot.help((ctx) => ctx.reply('Send me a sticker')) //ответ бота на команду /helpbot.on('sticker', (ctx) => ctx.reply('')) //bot.on это обработчик введенного юзером сообщения, в данном случае он отслеживает стикер, можно использовать обработчик текста или голосового сообщенияbot.hears('hi', (ctx) => ctx.reply('Hey there')) // bot.hears это обработчик конкретного текста, данном случае это - "hi"bot.launch() // запуск бота

Создаем файл .env куда в переменную BOT_TOKEN кладем токен, который ранее нам выдал @BotFather


BOT_TOKEN='сюда'

Запускаем бот командой


npm run start

Проверяем работу бота


check bot


Получаем PROVIDER_TOKEN от @SberbankPaymentBot


Для получения PROVIDER_TOKEN вам необходимо получить merchantLogin в Сбербанке. Для этого необходимо подключить услугу интерент-эквайринг в Сбербанке.


После того как вы его получили переходим в @BotFather и вызываем команду /mybots, где выбираем вашего бота.


Далее Payments


Payments


Где выбираем Сбербанк


Payments


Выбираем Connect Сбербанк Live


Payments


После этого вас перекинет на @SberbankPaymentBot, где нужно ввести ваш merchantLogin, который необходимо вводить без всяких префиксов -api или -operator. Например так: P71XXXXXXX21. Из-за того что я этого не знал, у меня ушло на переписку с техподдержкой Сбербанка неделя времени.


SberbankPaymentBot


После @BotFather выдаст вам токен, который нужно вставить в переменную PROVIDER_TOKEN файла .env


PROVIDER_TOKEN='41018XXXX:LIVE:XXXXXXXXXXXXXXXXXXXXXXXXXXXXX'

SberbankPaymentBot


Подключаем оплату в приложении


Пишем в index.js следующий код:


const { Telegraf } = require('telegraf')require('dotenv').config()const bot = new Telegraf(process.env.BOT_TOKEN) //сюда помещается токен, который дал botFatherconst getInvoice = (id) => {  const invoice = {    chat_id: id, // Уникальный идентификатор целевого чата или имя пользователя целевого канала    provider_token: process.env.PROVIDER_TOKEN, // токен выданный через бот @SberbankPaymentBot     start_parameter: 'get_access', //Уникальный параметр глубинных ссылок. Если оставить поле пустым, переадресованные копии отправленного сообщения будут иметь кнопку Оплатить, позволяющую нескольким пользователям производить оплату непосредственно из пересылаемого сообщения, используя один и тот же счет. Если не пусто, перенаправленные копии отправленного сообщения будут иметь кнопку URL с глубокой ссылкой на бота (вместо кнопки оплаты) со значением, используемым в качестве начального параметра.    title: 'InvoiceTitle', // Название продукта, 1-32 символа    description: 'InvoiceDescription', // Описание продукта, 1-255 знаков    currency: 'RUB', // Трехбуквенный код валюты ISO 4217    prices: [{ label: 'Invoice Title', amount: 100 * 100 }], // Разбивка цен, сериализованный список компонентов в формате JSON 100 копеек * 100 = 100 рублей    payload: { // Полезные данные счета-фактуры, определенные ботом, 1128 байт. Это не будет отображаться пользователю, используйте его для своих внутренних процессов.      unique_id: `${id}_${Number(new Date())}`,      provider_token: process.env.PROVIDER_TOKEN     }  }  return invoice}bot.use(Telegraf.log())bot.hears('pay', (ctx) => { . // это обработчик конкретного текста, данном случае это - "pay"  return ctx.replyWithInvoice(getInvoice(ctx.from.id)) //  метод replyWithInvoice для выставления счета  })bot.on('pre_checkout_query', (ctx) => ctx.answerPreCheckoutQuery(true)) // ответ на предварительный запрос по оплатеbot.on('successful_payment', async (ctx, next) => { // ответ в случае положительной оплаты  await ctx.reply('SuccessfulPayment')})bot.launch()

Метод Telegraf replyWithInvoice это метод telegram.sendInvoice.


Используйте этот метод для отправки счетов. В случае успеха отправленное сообщение возвращается.


Запускаем бот командой yarn start и проверяем проходит ли оплата.


Проверить как работает оплата можно в наших телеграм ботах JavaScript Bot это бот с тестовыми вопросами по нашим курсам JavaScript, React Native, TypeScript, а также проверить платежи можно боте по изучению английских слов по эмодзи Englishmoji


Проблемы или вопросы?


Задавайте их в телеграм сообществе Боты на Telegraf


Подписывайтесь на наши новости и социальные сети.


JavaScript Camp

Подробнее..

Создаём королевскую форму для приёма банковских карт

03.06.2021 12:19:11 | Автор: admin


В этой статье я дам рекомендации по созданию платёжных форм, которые будут выгодно отличаться от форм ваших конкурентов. Каждый пункт рекомендаций будет сопровождаться примером кода. Полный пример кода, включающий адаптивную вёрстку, реализацию валидационных тултипов, и прочих мелочей опущенных для краткости в самой статье вы можете посмотреть здесь: http://jsfiddle.net/iserdmi/9sj53x01/


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


Для создания формы мы будем использовать следующие инструменты:


  1. Нативный JS
  2. BinKing вспомогательный сервис для создания платёжных форм: https://binking.io
  3. IMask инструмент для создания масок полей ввода: https://imask.js.org/
  4. Tippy инструмент для создания тултипов: https://atomiks.github.io/tippyjs/



Определение логотипа банка


Вы наверное замечали, что существуют такие формы для приёма банковских карт, в которых, по мере ввода номера карты, появляется логотип банка, которому принадлежит банковская карта? Такое поведение помогает реализовать JS плагин BinKing https://binking.io


      function initBinking () {        binking.setDefaultOptions({          strategy: 'api',          apiKey: 'cbc67c2bdcead308498918a694bb8d77' // Replace it with your API key        })      }      function cardNumberChangeHandler () {        binking($cardNumberField.value, function (result) {          //           if (result.formBankLogoBigSvg) {            $bankLogo.src = result.formBankLogoBigSvg            $bankLogo.classList.remove('binking__hide')          } else {            $bankLogo.classList.add('binking__hide')          }          //         })      }

Определение цветов банка


Для красоты картины предлагаю вам также перекрашивать саму форму в цвета банка. Разумеется важно также не забыть и перекрасить цвет текста. Здесь нам опять же поможет BinKing.


      function cardNumberChangeHandler () {        binking($cardNumberField.value, function (result) {          //           $frontPanel.style.background = result.formBackgroundColor          $frontPanel.style.color = result.formTextColor          //         })      }

Определение логотипа платёжной системы


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


      function cardNumberChangeHandler () {        binking($cardNumberField.value, function (result) {          //           if (result.formBrandLogoSvg) {            $brandLogo.src = result.formBrandLogoSvg            $brandLogo.classList.remove('binking__hide')          } else {            $brandLogo.classList.add('binking__hide')          }          //         })      }

Определение банка привязанных карт


При вводе данных новой карты, записывайте себе в базу данных кроме токена карты ещё и alias банка в системе BinKing. Тогда при выводе привязанных карт вы сможете вывести кроме последних 4 цифр и логотипа платёжной системы ещё и логотип банка, что сильно упростит жизнь пользователю. Причём BinKing выдаёт как полноразмерные логотипы банков, так и эмблемы банков отдельно.


      function showSavedCards () {        if (savedCards.length) {          var banksAliases = savedCards.map(function (card) {            return card.bankAlias          })          binking.getBanks(banksAliases, function (result) {            savedCardsBanks = result            var savedCardsListHtml = savedCards.reduce(function (acc, card, i) {              if (result[i]) {                return acc += '<div class="binking__card" data-index="' + i + '">' +                '<img class="binking__card-bank-logo" src="' + result[i].bankLogoSmallOriginalSvg + '" />' +                '<img class="binking__card-brand-logo" src="' + binking.getBrandLogo(card.brandAlias) + '" />' +                '<div class="binking__card-last4">...' + card.last4 + '</div>' +                '<div class="binking__card-exp">' + card.expMonth + '/' + card.expYear + '</div>' +                '</div>'              }              return acc += '<div class="binking__card" data-index="' + i + '">' +                '<img class="binking__card-brand-logo" src="' + binking.getBrandLogo(card.brandAlias) + '" />' +                '<div class="binking__card-last4">... ' + card.last4 + '</div>' +                '<div class="binking__card-exp">' + card.expMonth + '/' + card.expYear + '</div>' +                '</div>'            }, '') // вывод карты, для которой не был найден банк            $сardsList.innerHTML = savedCardsListHtml + $сardsList.innerHTML          })        }      }

Автоматический фокус первого поля


Удобно, когда курсор уже установлен в первое поле, то есть в поле для ввода банковской карты. Это легко, достаточно пары строк кода:


      var $cardNumberField = document.querySelector('.binking__number-field')      $cardNumberField.focus()

Автоматически перевод курсора


Пользователю удобно, когда курсор автоматически перемещается между полями по мере ввода данных. Самая большая хитрость состоит в том, чтобы своевременно перевести курсор из поля для ввода карты. Беда в том, что не все номера карт состоят из 16 цифр. Переводить курсор следует тогда и только тогда, когда введено символов не меньше минимальной длины карты, и когда в номере карты нету ошибок согласно алгоритму Луна (алгоритм позволяющий определить содержатся ли в номере карты опечатки).


      function cardNumberChangeHandler () {        binking($cardNumberField.value, function (result) {          //           var validationResult = validate()          var isFulfilled = result.cardNumberNormalized.length >= result.cardNumberMinLength          var isChanged = prevNumberValue !== $cardNumberField.value          if (isChanged && isFulfilled) {            if (validationResult.errors.cardNumber) {              cardNumberTouched = true              validate()            } else {              $monthField.focus()            }          }          prevNumberValue = $cardNumberField.value        })      }      function monthChangeHandler () {        var validationResult = validate()        if (prevMonthValue !== $monthField.value && $monthField.value.length >= 2) {          if (validationResult.errors.month) {            monthTouched = true            validate()          } else {            $yearField.focus()          }        }        prevMonthValue = $monthField.value      }      function yearChangeHandler () {        var validationResult = validate()        if (prevYearValue !== $yearField.value && $yearField.value.length >= 2) {          if (validationResult.errors.year) {            yearTouched = true            validate()          } else {            $codeField.focus()          }        }        prevYearValue = $yearField.value      }

Валидация полей формы


Для валидация полей формы мы используем метод validate от BinKing. Валидатор позаботится о том, чтобы в номере карты не было опечаток, чтобы дата срока истечения карты была в будущем, а не в прошлом, проверит заполненность полей и прочее: https://github.com/union-1/binking#%D0%B2%D0%B0%D0%BB%D0%B8%D0%B4%D0%B0%D1%86%D0%B8%D1%8F


      function validate () {        var validationResult = binking.validate($cardNumberField.value, $monthField.value, $yearField.value, $codeField.value)        if (validationResult.errors.cardNumber && cardNumberTouched) {          cardNumberTip.setContent(validationResult.errors.cardNumber.message)          cardNumberTip.show()        } else {          cardNumberTip.hide()        }        var monthHasError = validationResult.errors.month && monthTouched        if (monthHasError) {          monthTip.setContent(validationResult.errors.month.message)          monthTip.show()        } else {          monthTip.hide()        }        if (!monthHasError && validationResult.errors.year && yearTouched) {          yearTip.setContent(validationResult.errors.year.message)          yearTip.show()        } else {          yearTip.hide()        }        if (validationResult.errors.code && codeTouched) {          codeTip.setContent(validationResult.errors.code.message)          codeTip.show()        } else {          codeTip.hide()        }        return validationResult      }

Маски полей формы


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


      function initMasks () {        cardNumberMask = IMask($cardNumberField, {          mask: binking.defaultResult.cardNumberMask        })        monthMask = IMask($monthField, {          mask: IMask.MaskedRange,          from: 1,          to: 12,          maxLength: 2,          autofix: true        })        yearMask = IMask($yearField, {          mask: '00'        })        codeMask = IMask($codeField, {          mask: '0000'        })      }

Показ телефона банка в случае отклонения платежа


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


      function cardNumberChangeHandler () {        binking($cardNumberField.value, function (result) {          newCardInfo = result          //         })      }      function formSubmitHandler (e) {        //         var bankInfo = selectedCardIndex !== null ? savedCardsBanks[selectedCardIndex] : newCardInfo || null        $error.innerHTML = bankInfo && bankInfo.bankPhone          ? 'Ваш банк отклонил операцию по указанной карте. Позвоните в ' + bankInfo.bankLocalName + ' по номеру ' + bankInfo.bankPhone + ', чтобы устранить причину.'          : 'Ваш банк отклонил операцию по указанной карте.'        // 

Логотипы вызывающие доверие


Принято размещать рядом с формой логотипы вызывающие доверия. Чтобы вам самостоятельно не пришлось их искать, вот вам эти логотипы в формате svg.


      <div class="binking__trust-logos">        <img class="binking__trust-logo" src="http://personeltest.ru/aways/static.binking.io/trust-logos/secure-connection.svg" alt="">        <img class="binking__trust-logo" src="http://personeltest.ru/aways/static.binking.io/trust-logos/mastercard.svg" alt="">        <img class="binking__trust-logo" src="http://personeltest.ru/aways/static.binking.io/trust-logos/mir.svg" alt="">        <img class="binking__trust-logo" src="http://personeltest.ru/aways/static.binking.io/trust-logos/visa.svg" alt="">        <img class="binking__trust-logo" src="http://personeltest.ru/aways/static.binking.io/trust-logos/pci-dss.svg" alt="">      </div>

Правильная раскладка клавиатуры


На мобильных телефонах возможно указать то, какой будет отображаемая клавиатура при фокусе на том или ином поле. Давайте сделаем так, чтобы выпадала клавиатура для ввода чисел. Для этого необходимо указать атрибуты inputmode="numeric" pattern="[0-9]*"


Распознавание полей для ввода карты


У некоторых пользователей сохранены данные платёжных карт в браузере. Чтобы в вашей форме работало автоматическое распознавание полей необходимо указать правильные атрибуты name и autocomplete


          <div class="binking__panel binking__front-panel">            <img class="binking__form-bank-logo binking__hide">            <img class="binking__form-brand-logo binking__hide">            <div class="binking__front-fields">              <input name="cardnumber" autocomplete="cc-number" inputmode="numeric" pattern="[0-9 ]*" class="binking__field binking__number-field" type="text" placeholder="0000 0000 0000 0000">              <label class="binking__label binking__date-label">Действует до</label>              <input name="ccmonth" autocomplete="cc-exp-month" inputmode="numeric" pattern="[0-9]*" class="binking__field binking__month-field binking__date-field" type="text" placeholder="MM">              <input name="ccyear" autocomplete="cc-exp-year" inputmode="numeric" pattern="[0-9]*" class="binking__field binking__year-field binking__date-field" type="text" placeholder="YY">            </div>          </div>          <div class="binking__panel binking__back-panel">            <input name="cvc" autocomplete="cc-csc" inputmode="numeric" pattern="[0-9]*" class="binking__field binking__code-field" type="password">            <label class="binking__label binking__code-label">Код<br>на&nbsp;обратной<br>стороне</label>          </div>        </div>

P.S.


Пользуясь случаем, хочу обратиться к читателям:


  1. Я ищу партнёра для развития сервиса BinKing, готов взять в долю. Сейчас планирую перевести весь сервис на английский язык, добавить прочие страны и запуститься за рубежом. От партнёра ожидаю помощи в работе с зарубежными клиентами, попомщи в переводе сайта на английский язык, попомщи в наполнении базы банков других странах. Если интересно сотрудничество, пишите.


  2. Я занимаюсь разработкой многопользовательских веб-сервисов и мобильных приложений на заказ. Веду разработку от проектирования до выхода на рынок. Если кто-то задумал создать свой стартап и сейчас ищет того, кто будет заниматься разработкой буду рад долгосрочному сотрудничеству.


  3. Когда я занимаюсь разработкой веб-сервисов и мобильных приложений на заказ, мне не редко приходится подключать к работе дополнительных разработчиков, и у меня всегда большая сложность в их поиске. По-этому я решил заняться обучением программированию, чтобы сотрудничать с теми, кого я сам обучал разработке. Если у вас есть желание научиться fullstack javascript разработке и освоить Node.js, React, MongoDB, GraphQL и потом работать вместе со мной, прошу обращайтесь, договоримся об индивидуальных занятиях. В ходе занятий разработаем любой веб-сревис, который вы сами захотите.


Подробнее..

Обновление фронтальных систем НСПК без прерывания сервиса

23.12.2020 08:22:02 | Автор: admin

Фронтальные офисные (ФО) системы одни из основных MissionCriticalсистем, эксплуатируемых в НСПК сегодня. Они отвечают за обработку и маршрутизацию авторизационных запросов между Банком-эквайрером и Банком-эмитентом. Именно через них производят обмен данными банки пока вы проводите операцию по карте. Через ФО проходит до 60 миллионов авторизаций в сутки, при этом в пике они обрабатывают 1800TPS(transactionpersecond).

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

ФО обладают достаточно сложной архитектурой и имеют 4-кратное резервирование каждого сервера.

Мы используем 2 ЦОД для георезервирования. В каждом ЦОД расположены ноды, принимающие соединения и обрабатывающие трафик от банков. Каждая нода обслуживает часть банков. Имеются следующие резервирования нода, обслуживающая трафик участников (нода А), имеет копию внутри ЦОД (нода В), а также копии этих двух нод существуют и в другом ЦОД.

Существует 3 типа подключения участников:

  • Участник имеет одно активное соединение к 1 ЦОД (Active-Passive);

  • Участник имеет два активных соединения к 2 ЦОД (Active-Active);

  • Участник имеет четыре активных соединения к 2 ЦОД (4Active).

Как и любые другиеIT-системы, ФО требуют периодических обновлений. Мы разделяем обновления на следующие типы:

  • Релиз;

  • Hotfix.

Релиз рождается в рамках 2-недельных спринтов и может содержать в себе следующие изменения:

  • Businessfeatures внедрение новой бизнес-функциональности в платежную систему. Например, такие сервисы какПокупка с выдачей наличных, возможность использования новыхWalletproviders(MirPay,Samsungpay,etc.);

  • Technicalfeatures внедрение технических изменений, упрощающих сопровождение системы, повышающих ее скорость работы, переход на новые технические решения;

  • Bugfixing устранение багов, не оказывающих влияния на бизнес компании.

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

Как правило, все изменения в виде релиза илиhotfixтребуют полной остановки приложений, отвечающих за обработку трафика на ноде. Это требуется для дистрибуции новых библиотек, перезапуска приложений, а также контроля по логам и через систему мониторинга, что ошибок при старте не образовалось, и модули ФО запущены в полном составе. Но мы не можем останавливать обработку трафика от банков, так как их клиенты не могут ждать у кассы и/или банкоматов, когда мы завершим обновление, и они смогут совершить покупку или снять наличные. Также мы стремимся к доступности нашего сервиса в 99,999%.

Обновление происходит следующим образом:

  1. Остановка приклада на резервных нодах В, где нет трафика от участников.

  2. Обновление ФО на нодах В.

  3. Перевод трафика с активных нод А на обновленные ноды В путем остановки нод А.

  4. Контроль правильности обработки трафика, отсутствия возросших отказов, ошибок в логах.

  5. Обновление нод А.

  6. Ноды В теперь становятся активными, а ноды А резервными.

Участники обмениваются авторизационными сообщениями по прикладному протоколу, основанному на ISO 8583. Он описывает формат финансовых сообщений и процесс передачи системами, обрабатывающими данные банковских платежных карт. Транспортным протоколом выступаетTCP/IP. Участник имеет только дваIPдля подключения (по одному на каждый ЦОД) и не знает, на какую ноду (А или В) уходит его трафик. Раньше мы использовали так называемый балансировщик, который проверял доступность ноды А при установке соединения со стороны банка. В случае ее доступности, устанавливалось соединение с нодой А, при недоступности ноды А, происходило установление соединения с нодой В.

Схема с балансировщиком имела следующий вид:

Использование балансировщиков было удобным и простым для сопровождения, при выключении нод происходило переустановление сессий на резервные ноды, однако опыт эксплуатации выявил следующие недостатки:

  • доступность ноды определяется балансировщиком только во время установления сессии от банка;

  • невозможность проведения обновлений ФО без разрывов соединений. Чтобы перевести трафик на резервные ноды В, происходит разрыв всех соединений, и всему рынку необходимо заново устанавливать свои сессии. Так как после установления сессий на транспортном уровне необходимо также установление прикладного уровня. Большинство банков умеют восстанавливать свои соединения в автоматическом режиме, но разные ПО банков это делают с разной скоростью. Неизбежно происходят потери авторизаций на время переключения. Это негативно влияет на нашу доступность.

  • в случае некорректной обработки трафика на нодах В во время обновления, обратное переключение на ноды А требует времени.

Мы стремимся к доступности 99,999% для наших ФО,поэтомув компании было принято решение и запущен проект разработки нового комплекса по управлению трафиком участника. К нему предъявлялись следующие требования:

  • возможность быстрого ручного или автоматического переключения трафика между нодами А и В;

  • переключение между нодами не должно порождать разрыв существующейTCPсессии с банками;

  • отказоустойчивость. Новый модуль должен быть зарезервирован, его падение также не должно вызывать разрываTCP-сессии с банками;

  • удобный графический web-интерфейс управления с разграничением доступов.

В итоге мы получили новую подсистему управления соединениями с участниками МУПС/ПУПС.

Схема подключения преобразилась следующим образом:

Название система получила от имени двух модулей, из которых она состоит:

  • ПУПС Прокси управления прикладными соединениями;

  • МУПС Модуль управления прикладными соединениями.

Мы вывели точки терминации трафика от банков из ЦОД в точки обмена трафиком М9 и М10, где располагается наше коммуникационное оборудование. Оборудование для реализации нового умного балансировщика мы также расположили на этих площадках.

В каждой точке обмена трафиком М9/М10 мы расположили по активной и резервной паре МУПС/ПУПС. Перейдем к описанию этих компонент и принципа работы нового комплекса. Серверы с этими парами объединены в VRRP-кластер с помощью keepalived и делят между собой один виртуальный IP.

ПУПС отвечает за TCP-взаимодействие узла балансировки с процессинговым ПО банков. Реализует механизм репликации и прозрачного восстановления TCP-соединений с организацией-участником на случай штатного переключения:

  • принимает TCP-соединения;

  • инициирует обмен данными между МУПС, ПУПС и банком;

  • отправляет и получает прикладные сообщения;

  • обрабатывает управляющие соединения между МУПС и ПУПС;

  • восстанавливает TCP-подключения и обеспечивает переключение между основными и резервными МУПС/ПУПС.

МУПС, второй компонент системы, предназначен для:

  • поддержания соединений с нодами ФО;

  • управления соединениями банков (включить/выключить, подключиться к ноде А или ноде B);

  • оборачивания сообщения ISO 8583 (авторизационная информация от банка) в свой протокол взаимодействия МУПС и ноды ФО;

  • получения сообщений от ноды ФО, разворачивания сообщения ISO 8583 и отправка в ПУПС;

  • подачи команды ПУПС о миграции на резервный сервер.

Одна из самых важных функций МУПС, ради чего он создавался, это переключение обработки трафика на резервную ноду ФО и обратно без разрыва соединения с банком-участником. Это работает благодаря тому, что МУПС стоит между ПУПС, который "держит" соединение с банком, и ФО, который обрабатывает трафик. МУПС управляет тем, куда именно этот трафик направляется в данный момент, и по команде от администратора осуществляет незаметное для банка и безопасное для обработки операций переключение между серверами.

Происходит это следующим образом:

  • фронтальные модули по команде от МУПС переходят в состояние синхронизации

  • активный модуль, который в данный момент обрабатывает операции, загружает контексты in-flight операций (для которых он ожидает, но ещё не получил ответных сообщений от банка) из своей памяти в общий in-memory data grid

  • резервный модуль забирает к себе эти контексты

  • по завершении выгрузки МУПС деактивирует активный модуль и передаёт на резервный его новый статус и ряд runtime-параметров, с которым работал прошлый активный модуль

  • с этого момента МУПС начинает направлять трафик от участника на новый активный модуль

Для передачи данных и управления МУПС используется два соединения. Первое это Data-соединение. Используется для передачи данных по авторизациям от банка (ISO8583) в ФО и обратно. Второе соединение это Control-соединение. Используется для обмена управляющими сообщениями между ПУПС и МУПС. В управляющем соединении используются команды для проверки жива ли активная пара МУПС/ПУПС командаheartbeat, а также ряд команд для осуществления переезда соединений на резервную пару МУПС/ПУПС в рамках площадки.

В узле балансировки активный ПУПС взаимодействует только с МУПС, установленном на том же сервере, что и ПУПС.

Если сигналы heartbeat от МУПС отсутствуют в течение заданного времени, ПУПС на активном узле начинает процедуру активации второго узла в кластере (при его доступности), а затем деактивируется.

Процесс миграции с основного сервера на резервный сервер происходит следующим образом:

  • ПУПС на основном сервере устанавливает флаг готовности к миграции;

  • на основном сервере создается дамп процесса, далее ПУПС переносит его образ на резервный сервер, а также устанавливает флаг готовности к миграции и восстановлению на резервном сервере;

  • ПУПС на резервном сервере при обнаружении образа переносит правила iptables и увеличивает приоритет Keepalived на узле, тем самым запускается процедура переноса IP-адреса;

  • после переноса IP-адреса Keepalived на резервном сервере из образа восстанавливается работающий процесс. Также восстанавливается приоритет самого Keepalived.

Таким образом, обеспечивается отказоустойчивость пары МУПС/ПУПС в рамках одной площадки.

Взаимодействие МУПС и ноды ФО происходит по собственному протоколу. В протоколе передается как платежная информация, так и проверяется доступность нод ФО с помощьюheartbeat, а также может передаваться ряд команд, необходимых для переезда трафика на неактивные ноды ФО. Очень важно: при переезде из активной ноды необходимо получить всю платежную информацию и передать ее уже в резервную нодуB. Наличие постоянныхheartbeatмежду МУПС и нодами ФО позволяет в автоматическом режиме диагностировать проблему с нодой и осуществлять мгновенные переводы трафика участника на резервную ноду без разрыва соединения с участником.

В основном работа администраторов системы происходит черезWEB-консоль управления МУПС. В ней отображен список банков, имеющих подключение к нам, статус их коннекции. Мы в удобном интерфейсе можем наблюдать, установлено ли подключение только на транспортном уровне, или имеется подключение на прикладном. Также мы видим, к какой именно ноде (А или В) подключен банк. По клику мыши мы можем переносить соединения выбранного банка или всех сразу между нодами А и В. При этом участник не видит для себя никаких разрывов и пропадания авторизационного трафика.

Заключение

Созданный комплекс МУПС/ПУПС позволил решить ряд существенных вопросов компании по управлению прикладными соединениями банков с компанией:

  • все работы на ФО остаются незамеченными для участников, не происходит разрыва соединений и потери транзакций;

  • при проблеме на ноде ФО, перевод трафика на резерв осуществляется автоматически и мгновенно, банк также не видит разрыва соединения;

  • дежурные службы и администраторы ФО получили удобный и наглядный инструмент для управления соединениями. Вывод ноды из работы для обновления ОС, замены железных компонент также не замечается участником и не приводит к транзакционным потерям.

Подробнее..

Архитектура экосистем

15.12.2020 10:11:51 | Автор: admin

Термин Экосистема появился в бизнес-лексиконе в 1993 году. Американский ученый Джеймс Мур в статье Хищники и жертва: новая экология конкуренции так обозначил модель объединения компаний вокруг решения единой стратегической задачи. Последнее время термин особенно популярен. Упоминаемость экосистемной бизнес-модели на пике в деловых новостях, бизнес-публикациях, финансовых отчетах и программах развития корпораций. Бизнес-экосистемам посвящаются деловые форумы и конференции.

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

Для начала все-таки придется посвятить пару слов лирике - природе и этапам становления экосистем. Это поможет выровняться в понимании самого термина.

В ретроспективе 25-30 лет экосистемная бизнес-модель эволюционировала. На этапе зарождения этого понятия под экосистемой понималось в большей степени объединение вокруг одного продукта конкурирующих между собой поставщиков и производителей. Пример - разработчики клиентского ПО для компьютеров Apple или производители аппаратных компонентов для ПК IBM. Превалировала классическая платформенная модель, которая решала задачу расширения и максимизации ассортиментного состава клиентских продуктов или составных компонентов одного продукта. Сегодня экосистемы приобрели сложный сетевой характер.Бизнес-экосистема выполняет роль источника ресурсов и знаний для развития компаний-участников. Синергетический эффект от участия в экосистеме стал проявляться в намного большем объеме. Продукты и сервисы этой бизнес-модели обогащают друг друга технологиями, функциями и операционными данными.Технологии - главный драйвер эволюции и становления экосистемной бизнес-модели. Тридцать лет назад в розничном бизнесе преобладал Product-centric подход. Главной задачей было грамотно сегментировать клиентскую аудиторию, правильно позиционировать товар, сформировать стратегию продвижения и дистрибуции. С ростом популярности персональных компьютеров, развитием телекоммуникаций, Интернет-технологий и появлением смартфонов возникла ориентация на каналы продаж - WEB-first, Mobile-first, Voice-first. Появилась электронная торговля и продвижение. Золотая полка, статичная и ограниченная в размерах в офлайн-ритейле по причине расположения на уровне глаз покупателя, в электронных каналах продаж стала безграничной и кастомизируемой под каждого клиента. Бизнес представил взору клиента весь товарный ассортимент. Взрывной рост и отрыв от конкурентов получили компании, которые быстро освоили новые каналы продаж и переориентировались на платформенную электронную бизнес-модель. Netflix и Zappos вырвались вперед в конкурентной борьбе, когда предложили клиентам больший ассортимент через онлайн-каналы. Крупнейшим розничным банкам взаимодействие через личные кабинеты клиентов помогло расширить набор финансовых продуктов.

Дальнейший рост вычислительных возможностей, доступности хранилищ данных и их логистики привели к появлению клиенто-центричного подхода в розничном бизнесе. Каждый клиент компании стал отдельным самостоятельным сегментом. Благодаря технологиям регистрации, обработки и анализа неструктурированных операционных данных, бизнес научился предугадывать клиентское поведение и предвосхищать ожидание клиента. Дополнительным катализатором послужило появление CEP (Complex Event Processing) и RTDM (Real-Time Decision Manager) -решений, которые обеспечили анализ информации на лету. Большие данные перестали анализировать по ночам. Интернет-компании за мгновения узнают пользователя и отображают таргетированную рекламу или цену товара уже после обращения к WEB-странице. Благодаря предиктивной аналитике физическое формирование посылки с товарами начинается одновременно с наполнением корзины на сайте - до момента оплаты товара клиентом. А предложение международной страховки направляется клиенту финансовой компании сразу после оплаты покупки в аэропорту.

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

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

Эти профильные бизнес-модели и объединяет понятие Экосистема.

К текущему моменту сложилось две модели появления экосистем Европейская и Американо-Китайская. Первая модель предполагает децентрализованное объединение компаний - чаще стартапов - на основе единых правил, утверждаемых глобальным государственным или межгосударственным регулятором Центральным банком. Вторая модель предполагает объединение вокруг одного глобального финтех или бигтех игрока десятков меньших по объему бизнеса продуктов и сервисов. Примеры таких экосистем - Facebook, Amazon, Microsoft, Google, Apple (FAMGA) и Baidu, Alibaba, Tencent (BAT).

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

Трансформируясь в экосистемную бизнес-модель, корпорации научились зарабатывать на собственной клиентской аудитории. Как говорится, если вы не платите за продукт, значит вы и есть продукт.

Для экосистем характерен ряд свойств, которые отличают их от стратегических альянсов, а также вертикально- и горизонтально-интегрированных компаний:

  • Наличие больших ресурсов для регулярных исследований, опытов и развития решений

  • Использование новых технологий, архитектуры и подходов к разработке ПО

  • Регулярная работа с большими данными

  • Цифровые бизнес-процессы

  • Отсутствие бюрократии в производственном процессе, сокращенный Time-to-market

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

Для клиента такая бесшовная мультисервисная среда включает, например:

  • Возможность использовать единый логин и пароль в разных продуктах

  • Возможность не вводить многократно свои данные в профилях разных сервисов

  • Доступность нужных сервисов в разных интерфейсах (каналах, продуктах) экосистемы

  • Использование единого платежного инструмента, подписки, бонусной программы

  • Просмотр релевантного контента и предложений

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

Без использования кросс-доменных сервисов экосистема не будет таковой, а останется набором разрозненных самостоятельных клиентских продуктов.

Среди таких глобальных технологических сервисов и подходов можно выделить:

  • Сервисы обеспечения омниканальности.

  • Единую учетную запись.

  • Единый ID клиента и клиентский профиль.

  • Доступность основных сервисов и функций через API.

  • Централизованный клиентский биллинг экосистемы.

  • Ориентацию на событийную модель интеграции (Event-Driven Architecture).

  • Единый контакт центр и службу поддержки.

  • Единый аналитический и операционный CRM.

Рассмотрим некоторые из них подробней.

Омниканальность

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

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

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

Единая учетная запись

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

С точки зрения архитектуры важно использовать единый для продуктов экосистемы сервис аутентификации и авторизации. Это условие выглядит очевидным в случае, когда компоненты экосистемы создаются одновременно. Но часто сама экосистема собирается из разрозненных самостоятельных клиентских сервисов, которые уже располагают авторизующими решениями. В этом случае возникает дилемма. C одной стороны в разных сервисах уже зарегистрированы одни и те же клиенты, которые на момент регистрации не давали согласия и не ожидали, что учетная запись в сервисе A в какой-то момент заработает в сервисе B. С другой стороны, новым клиентам должна быть доступна регистрация сразу во всех бизнес-доменах экосистемы. Оптимальный вариант - создание дополнительного глобального универсального для всей экосистемы способа регистрации и аутентификации, доступного клиентам наряду со стандартной регистрацией в отдельных сервисах (продуктах).

Единый ID клиента и клиентский профиль

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

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

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

Единый платежный инструмент и централизованный клиентский биллинг экосистемы

Использование одного продукта экосистемы упрощает клиенту пользование другими продуктами. Это справедливо и для способа финансовых расчетов. Участник экосистемы должен иметь возможность оплатить разные сервисы с помощью одного инструмента и получать финансовую выгоду от одновременного пользования продуктами экосистемы. Легкий способ решения задачи - привязка (токенизация) банковской карты к разным сервисам. В этом случае клиент действительно будет использовать единый платежный инструмент. Но становится практически нереализуемой задача создания механик финансовой мотивации к пользованию разными продуктами экосистемы. Пользователю сложно будет начислить повышенные бонусные баллы за приобретение ряда услуг, оформить единую подписку, показывать в разных сервисах актуальный баланс и единую историю операций, отслеживать пользование услугами, проводить тарификацию в режиме реального времени. Клиент потеряет в бесшовности финансовых выгод, а продукты экосистемы в синергетическом эффекте. Поэтому такие задачи решаются с помощью единого клиентского счета или кошелька, которые обслуживаются в централизованной биллинговой системе. AliPay наиболее яркий пример такого финансового экосистемного сервиса.

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

Событийная интеграция систем (Event-Driven Architecture)

Используя перекрестное обогащение знаниями о клиенте компании создают сложные механики анализа клиентского поведения. Они помогают предвосхищать желания и потребности клиентов и предлагать релевантную продукцию товары, контент, услуги. На таком подходе построены концепции Next Best Offer (NBO) и Next Best Action (NBA). В рамках этих решений определяется, какой товар клиент с высокой вероятностью приобретет в конкретный момент (или период) времени. И, соответственно, какое действие клиент будет готов совершить в следующий момент. Для принятия таких решений компании анализируют в режиме real-time до тысячи триггеров клиентского поведения состав покупок, суммы, тип ТСП, запрашиваемый контент, проставленные в соцсетях лайки, среднее время просмотра роликов, контакты и многое другое. Но главное, решение на основе такого анализа необходимо принимать на лету, так как спустя время готовность клиента к приобретению товара или действию может сильно снизиться и предложение станет не актуальным. Поэтому для такого рода задач важна событийно-ориентированная интеграционная архитектура. Каждый домен экосистемы (как совокупность информационных систем) должен уведомлять другие домены о событиях в жизни клиента. Поэтому необходима организация супермаркета операционных данных - решения, которое позволяет информационной системе в онлайн-режиме получать важные для себя данные (например, на базе брокера сообщений Apache Kafka). Прямая интеграция систем для получения данных по запросу или рассылки сообщений о событиях создаст спагетти-архитектуру и, как следствие: существенный прирост нагрузки на системы, более сложное сопровождение, а также предпосылки для большего количества доработок в случае расширения атрибутного состава клиентских данных.


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

Каждый бизнес-домен экосистемы это канал привлечения клиентской аудитории для других сервисов. И в тоже время элемент, который препятствует выходу клиента из экосистемы.

Поэтому включение нового клиента в экосистему происходит по заранее и детально спроектированному клиентскому пути (Customer Journey). А работа с одним сервисом упрощает клиенту работу с другими сервисами.

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

Подробнее..

HMM ловим мошеннические транзакции

09.04.2021 14:13:02 | Автор: admin

Три года я проработал в Сербии iOS-евангелистом - было два профильный проекта и один Machine Learning-овый.

Если вам стало интересно - добро пожаловать в мир HMM.

Постановка задачи

Австрийский банк. У него много клиентов, у клиентов открыт счет в этом банке. В течении года клиент тратит средства со своего счета. Ходит в магазины, гасит коммунальные платежи и пр. Каждое списание денег со счета назовем транзакцией. Дана последовательность транзакций за определенное время (скажем год). Надо обучить машину, чтобы она начала проверять новые транзакции как достоверные или подозрительные. И выдавала предупреждение в последнем случае. Для решения задачи надо использовать Hidden Markov Model.

Введение в HMM

Я болею коронавирусом каждый год 10 дней подряд. Остальные дни здоров, как бык.

Представим эту последовательность из 365 символов в виде массива. h означает здоров, l - болен.

days{365} = {hhhhhhhhhhllllllllllhhhhhhhhhhhhhhhhhhhhhhhh...hhhhh}

Вопрос - Какова вероятность, что я сегодня болен?

\frac{10}{365}= 3 процента

Если вам понятен ответ, то читайте дальше, через 15 минут вы станете экспертом по HMM. Если нет - ставьте плюс и идите ужинать.

Изменим вопрос - Какова вероятность, что я завтра буду больным?

Вы резонно уточните: -А сегодня я болен или здоров?

Если болен (смотрите на последовательность - таких больных дней всего 10), то с вероятностью \frac{9}{10} = 90 процентов завтра я продолжу болеть и с вероятностью 10 процентов стану здоров.

А если я сегодня здоров? - то с вероятностью

\frac{1}{355}= 0.3 процента я завтра заболею и с вероятностью 99.7% буду здоров.

Если вы сегодня больны, то с вероятностью 10% завтра вы будете здоровы и 90% продолжите болеть.

Получили 4 числа, которые красиво вписываются в матрицу 2 на 2 - вуаля! эта матрица и есть Марковский слой. Уберем проценты, оставим чистые вероятности в диапазоне от 0 до 1, как того требует наука.

здоров

болен

здоров

0.997

0.003

болен

0.10

0.90

Еще раз взглянем на матрицу и прочитаем слева направо, что если ты сегодня здоров, завтра с вероятностью 0.997 ты останешься здоров, а с вероятностью 0.003 заболеешь и так далее.

Формализуем транзакции

Чем отличается последовательность транзакций от череды болен/здоров? Ничем.

Для доказательства этого возьмем список транзакций, который мне предоставил Сбережении по моей просьбе.

27.10.2020 00:00 GAZPROMNEFT AZS 219    2507,43 118 753,95 28.10.2020 / 298380 Автомобиль 26.10.2020 14:45 SPAR 77                319,73 121 261,38 27.10.2020 / 220146 Супермаркеты 26.10.2020 14:38 ATM 60006475           4800,00 121 581,11 26.10.2020 / 213074 Выдача наличных 25.10.2020 17:52 EUROSPAR 18            970,02 126 381,11 26.10.2020 / 259110 Супермаркеты 25.10.2020 00:00 Tinkoff Card2Card      20000,00 127 351,13 26.10.2020 / 253237 Перевод с карты 22.10.2020 14:22 SBOL перевод 4276      7000,00 147 351,13 22.10.2020 / 276951 Перевод с карты 22.10.2020 12:18 STOLOVAYA              185,00 154 351,13 23.10.2020 / 279502 Рестораны и кафе 21.10.2020 16:46 MEGAFON R9290499831    500,00 154 536,13 21.10.2020 / 224592 Комунальные платежи, связь, интернет. 21.10.2020 14:17 SPAR 77                987,03 155 036,13 22.10.2020 / 219015 Супермаркеты 21.10.2020 13:42 PYATEROCHKA 646        289,93 156 023,16 22.10.2020 / 294539 Супермаркеты 21.10.2020 00:00 MEBEL                  75,00 156 313,09 22.10.2020 / 279935 Прочие расходы 19.10.2020 14:54 SPAR 77                552,92 132 044,80 20.10.2020 / 208987 Супермаркеты 19.10.2020 00:00 MOBILE FEE             60,00 132 597,72 20.10.2020 / - Прочие операции 16.10.2020 14:19 SPAR 77                579,39 132 657,72 17.10.2020 / 229627 Супермаркеты 12.10.2020 13:33 STOLOVAYA              185,00 133 237,11 13.10.2020 / 261374 Рестораны и кафе 12.10.2020 00:00 OOO MASTERHOST         1000,00 133 422,11 13.10.2020 / 268065 Прочие расходы 11.10.2020 12:09 SPAR 77                782,87 134 422,11 12.10.2020 / 275816 Супермаркеты 10.10.2020 14:52 SBOL перевод           400,00 135 204,98 10.10.2020 / 276925 Перевод с карты 09.10.2020 13:29 SBOL перевод 5484*     1000,00 135 604,98 09.10.2020 / 229184 Перевод с карты 09.10.2020 11:55 MAGNIT MK KRYUCHYA     274,00 136 604,98 10.10.2020 / 209914 Супермаркеты

Напишем на питоне скрипт, который вытащит последовательность моих транзакций в рублях и нарисует график

def readtrans():    with open ("assets/trans.txt", "r") as file:        grades = file.read()    pattern = '(\d{2,5}),\d\d'    result = re.findall(pattern, grades)    r = list(map(int, result[0::2]))    return rdata = readtrans()t = list(range(len(data)))df = pd.DataFrame({'number':t, 'amount':data})ax1 = df.plot.bar(x='number', y='amount', rot=0, width=1.5)

Упростим картину - дешевые транзакции (менее 10$) обозначим буквой l, дорогие свыше 100$ буквой h, остальные - буквой m.

Наша последовательность стала выглядеть подозрительно знакомо

print(observations[:20])trans[] = ['m', 'm', 'm', 'l', 'm', 'm', 'h', 'm', 'l', 'l', 'm', 'l', 'l', 'l', 'l', 'l', 'l', 'm', 'l', 'l']

Теперь напишем Марковский слой для транзакций. Это будет матрица 3 на 3, поскольку у нас 3 возможных типа транзакций = {l,m,h}

[[0.5 0.3 0.2] [0.6 0.3 0.1] [0.7 0.3 0.0]]

Расшифровываем последнюю строку матрицы - если последняя транзакция была дорогая, то с вероятностью 0.7 последующая операция будет дешевой, с вероятностью 0.3 - средней и никогда снова дорогой.

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

-Так просто?! - воскликнет читатель. Да, но за построение такой простой модели банк много денег не заплатит. Надо ввести еще один Марковский слой (невидимый), и алгоритм сразу станет красивее, сложнее и наукоёмчее. И потянет на кандидатскую диссертацию.

Скрытый Марковский слой

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

То есть существует набор периодических однотипных событий, число которых мы не знаем и Марковский слой для которых невозможно построить. Как построишь, если ничего не знаешь конкретно?! Вот именно. Но мы знаем, что эти события происходят и их примерно 4-6 штук. Поход в магазин. Столовая. Еще что-то. И так далее. И что мы точно знаем, что после похода в столовую мы никогда не опустошаем свой кошелек на сумму более 300 рублей.

Таким образом, мы можем задать матрицу невидимого слоя 5 на 5 (предположим 5 на 5) в которой будет 20 неизвестных чисел.

[[a1 a2 a3 a4 a5] [b1 b2 b3 b4 b5] [c1 c2 c3 c4 c5] [x1 x2 x3 x4 x5] [y1 y2 y3 y4 y5]]

Именно 20, а не 25 (отвечать будет Ягуар). Это точно такой же Марковский слой, что мы строили раньше, но основанный на 5 событиях.

И чтобы связать два слоя (видимый с платежами и невидимый с событиями) мы заведем матрицу перехода размера 5 на 3.

В чем смысл матрицы перехода? В том, что после невидимого события a (поход в столовую)

у нас произойдет с разной степенью вероятности либо l-платеж, либо m-платеж, либо h-платеж. Скорее всего после похода в столовую эта строка будет такая

[0.96 0.04 0.0]

Что означает невозможность потратить более 100 долларов в нашей технопарковской столовой. Даже с приглашенной девушкой.

Таким образом, у нас есть известная матрица вероятностей с явного слоя, неизвестные 20 значений в матрице с невидимого слоя и 10 неизвестных значений из переходной матрицы.

И мы можем найти эти 20+10 неизвестных величин, потому что у нас есть история платежей!

Это прекрасно и это называется обучить систему!

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

Обучение

В питоне есть библиотека hmm, в которой существует метод обучения - ему надо подать ваши три матрицы, и серию последовательностей из транзакций. Алгоритм такой, что вы разбиваете историю ваших транзакций порциями штук по 15-20 и скармливаете ее, пока система не обучится.

Процесс сходимости хорошо виден на графике.

После этого вы обученной системе подаете новую транзакцию и она по выбранному вами критерию отбраковывает ее или одобряет.

Питон против Сишарпа

Работодатель обязал меня использовать библиотек Accord и язык C#

using Accord.MachineLearning;using Accord.Statistics.Models.Markov;using Accord.Statistics.Models.Markov.Learning;using Accord.Statistics.Models.Markov.Topology;using Comtrade.FMS.Common;

Согласно контракту я не могу разглашать код, поэтому написал аналог на Питоне (я не знаю оба языка) и частично смог повторить результат. Но по скорости обучения Питон сильно проигрывает Си-шарпу. Правда, я run-ил программу на разного класса компьютерах)) В Словении это был сервер работодателя. Питон для Хабра пыхтел на 2010 года макбуке.

Приведу одну строку кода, в которой зашифрован метод обучения.

var teacher = new BaumWelchLearning(hmm)

Детали метода Баум-Уэлша вы поймете, прочитав соответствующую литературу и настроив свои мозги на стат. процессы.

Успехов и хорошей карьеры в банковских IT структурах!

Подробнее..

Как мы сделали оплату по QR

25.01.2021 18:10:11 | Автор: admin

Всем привет! Сегодня с вами Владислав Козуля, тимлид команды Розница, и я расскажу, как начать платить по QR и ни в чём себе не отказывать. Моя команда делает продукт Касса МойСклад, которым часто пользуются наши клиенты, у которых есть точки продаж. Речь пойдёт о том, как разработка инструментов для повседневной работы выглядит изнутри.

Что это вообще такое

Для начала немного контекста. Обычно, когда вы оплачиваете покупки на кассе, у вас есть выбор: платить наликом или картой. Технически между ними есть ещё один вариант и тем, и тем, но он встречается гораздо реже. Или бонусной картой, а это вообще отдельная система. Короче, налик или карта.

Теперь к ним добавляется новый способ оплата по QR. Вместо того, чтобы насыпать монет или пикнуть эпплпеем об терминал, можно отсканировать QR-код и оплатить покупку через приложение банка.

Тут возникает резонный вопрос: к чему заморачиваться с камерой на телефоне, если картой проще? Это выгодно магазину. Прикол в том, что для него комиссия с платежа (а магазин с каждой покупки платит комиссию банку) будет ниже. К тому же оплачивать по QR можно без терминала, то есть ещё и экономить на закупке оборудования. Поэтому продавец будет предлагать вам оплатить именно по QR.

Коды бывают двух видов: статические и динамические. Статический код можно распечатать один раз и забыть. Отсканировав код, покупатель должен сам выбрать сумму перевода, поэтому такая схема больше подходит для чаевых или донатов. Чтобы оплачивать покупки, гораздо удобнее использовать динамические коды, которые генерируются на стороне банка. Этот процесс можно автоматизировать через кассовое ПО, что мы и сделали.

Разработчица Екатерина демонстрирует работу функции печати QR-кода на чекеРазработчица Екатерина демонстрирует работу функции печати QR-кода на чеке

У Сбербанка для этого есть своя система Плати по QR, Тинькофф работает по Системе Быстрых Платежей (СБП). При этом они интегрированы друг другом, то есть покупатель разницы не заметит. Обе системы с нашей стороны завёрнуты в единый API, поэтому для клиента тоже нет разницы.

Разберём, как оплата по QR выглядит под капотом с точки зрения Кассы МойСклад.

  1. Пользователь МоегоСклада выбирает в настройках банк, с которым у него есть договор оплаты по QR. Теперь на его кассе появится новый способ оплаты.

  2. Кассир создаёт продажу касса запрашивает у бэкэнда QR-код.

  3. Бэкэнд идёт в API банка, который выбрал пользователь из первого пункта. Получает строку, в которой зашиты данные для формирования платежа.

  4. Полученная строка прилетает на кассу и зашивается в QR-код, который можно отрисовать на UI или распечатать на чеке очень удобно.

  5. Дальше мы опрашиваем банк до тех пор, пока он не скажет, что платеж дошел или был отменён.

  6. Можно печатать фискальный чек, ура!

Вроде, звучит просто, а значит пора ожидать подводных камней.

Подводные камни

Помните, я упоминал, что обычно платят наличными или по карте? Когда проектировали базу, тоже так думали. Добавление нового типа оплаты означает добавление новых полей в базу (у нас PostgreSQL), причём в историю операций, одну из самых больших и популярных таблиц. На её основе формируются отчёты, одна из ключевых функций МоегоСклада. Это раз.

Второй важный момент остановка сервиса для обновления производится только в том случае, когда по-другому просто нельзя. А значит, наше решение должно заехать наживую. Эта часть заслуживает отдельной статьи.

Кроме обычной оплаты также возможны такие экзотические операции, как: предоплата, возврат оплаты и возврат предоплаты. Все они должны корректно учитываться при работе с QR. Смешанную оплату QR + наличными или картой мы просто не стали делать, иначе бы окончательно запутались в стремительно усложняющейся логике.

МойСклад не занимается процессингом платежей, только их учётом. Кассир возвращает вам деньги в руки или на карту своими силами, без участия кассового ПО. С оплатой по QR становится немного сложнее: теперь за отмену транзакции и возврат платежа отвечает бэкэнд. Для этого мы сохраняем её айдишник после инициализации.

В API обе операции сидят на одном эндпоинте (скопировали у Тинькова). До проведения платежа транзакцию можно отменить, и при попытке оплаты покупатель увидит ошибку в приложении банка. Если оплата уже прошла, будет произведён возврат. В случае, когда на кассе что-то пошло не так, возврат всегда может сделать владелец магазина из своего личного кабинета в банке.

Касса МойСклад это не веб-сайт, а десктопное приложение и пара мобильных клиентов под iOS и Android. Они легко могут работать и при отсутствии связи месяцами: для этого там поднимается локальная база, то есть по сути, свой маленький бэкенд. Соответственно, миграцию надо проводить и на сервере, и на клиенте. Сломать локальную базу означает превратить кассу в кирпич или ещё хуже: потерять все данные. Поистине апокалиптический сценарий для техподдержки.

Архитектура Кассы Мойсклад (упрощённая)Архитектура Кассы Мойсклад (упрощённая)

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

Фух.


Мы запустили СБП с Тиньковым 1 октября, а 1 декабря интеграцию со Сбером, Плати по QR. Уже почти февраль, и мы видим с десяток ежедневных платежей. Клиенты пользуются, люди оплачивают свои покупки по QR. А значит, всё было не зря!

В следующем выпуске я подробно расскажу о том, как релиз с оплатой по QR заезжал на бэкенде. Следите за обновлениями!

Подробнее..

Подключение к платежному сервису быстро и удобно. Миф или реальность?

16.12.2020 12:18:50 | Автор: admin
Мы знаем, как важно быстрое подключение онлайн-платежей и для совсем нового бизнеса, и для уже давно работающего. Ведь каждый день простоя это упущенные потенциальные возможности.

Но подключение эквайринга не самый простой процесс. Для этого компании нужно заключить договор с платежным сервисом и добавить на свой сайт формы и кнопки для приема оплаты. В свою очередь, сервис должен проверить компанию на соответствие требованиям регуляторов и настроить ей нужные способы приема платежей. Звучит долго, однако большинство наших клиентов подключают эквайринг через ЮKassa всего за 2-3 дня.

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




Как было раньше

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

Все выглядело примерно так. Клиент оставлял заявку на сайте Кассы с реквизитами компании. Наш менеджер проверял их и отправлял клиенту письмо с условиями подключения, анкетой и списком нужных документов: копии ИНН, ОГРН, устав организации и прочее (всего около 10 штук). После продолжительной переписки (в среднем 5-10 писем) менеджер получал полный пакет документов. Затем он подготавливал файл договора это 21 страница с приложениями. После подписания клиентом договор проходил согласование с нашими юристами, службой безопасности, финансового мониторинга и другими внутренними службами.

В итоге подключение занимало от 7 дней до месяца. Всякий раз этот процесс отнимал много времени и сил с обеих сторон и о массовом подключении магазинов оставалось только мечтать.

Упростить подачу заявки

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

1) Регистрация
Важно, чтобы самый первый шаг регистрации был простым. Поэтому к форме регистрации мы добавили API сервиса DaData, который позволяет найти ИНН организации по ее названию, а ИП по фамилии и имени предпринимателя. Благодаря этому теперь не нужно тратить время, например, на ввод ИНН мы сами покажем подходящие варианты.



2) Анкета для заключения договора с Кассой
После регистрации открывается доступ в Личный кабинет, где можно заполнить и подать анкету для договора. Одновременно с этим появляется доступ к тестовому магазину. На тестовой среде можно получить API-ключ и сразу начать интеграцию, пока идет юридическое оформление. Но об этом мы расскажем позже в другой статье, а сейчас остановимся подробнее на процессе заключения договора

Как уже было сказано, раньше для подписания договора нужно было предоставить массу документов и заполнить анкету. Просто перенести анкету в онлайн не показалось нам оптимальным вариантом. Мы решили автоматизировать сбор информации по контрагентам, чтобы эти данные не нужно было вводить вручную ни нам, ни компаниям. Мы выяснили, что наши юристы и коммерческий департамент используют СПАРК для похожих задач, но просматривают данные вручную на сайте. Мы подумали: почему бы не автоматизировать и этот процесс?

На первый взгляд, рецепт интеграции выглядел просто:
  • берем CRM-систему на платформе 1С (да-да, именно на 1С),
  • добавляем к ней методы получения данных из шлюза обмена СПАРК для ИП и юридических лиц,
  • получаем данные из СПАРК и передаем их в предварительное хранилище данных контрагента.

На деле все оказалось намного запутаннее, ведь в то время (2014-2015) мы были первопроходцами в такой интеграции.

Тем не менее нам удалось реализовать интеграцию. Что нам это дало? После регистрации компании на нашем сайте запрос с ее номером ИНН падает в 1С, где сразу формируется заявка на подключение. Чтобы проверить надежность юрлица, по номеру ИНН через API отправляются запросы в СПАРК. По полученным данным создается карточка клиента в нашей CRM. Эти же данные передаются в личный кабинет клиента. В итоге значительная часть данных для договора заполняется автоматически.



Для работы с компаниями нам нужна и другая важная информация например, на какой счет перечислять им деньги. Для удобства в личном кабинете нужно ввести только БИК банка и номер расчетного счета. По БИК мы определяем остальные банковские реквизиты. А чтобы снизить вероятность ошибки в расчетном счете мы проверяем количество указанных цифр на соотствение номеру счета и подсказываем, если расчетный счет принадлежит другому типу организации (например, ООО вместо ИП).



Еще для подключения нам нужны паспортные данные руководителя компании, которая заключает с нами договор. Стоит отметить, что идентификация клиента по паспортным данным наша обязанность перед регулятором. И здесь тоже не обходится без автоматизации мы используем ПО от компании DBrain. C помощью технологий OCR и AI система за 2-3 секунды с высоким качеством распознает паспорт. Достаточно загрузить скан или фотографию главной страницы паспорта и данные заполнятся автоматически. Если изображение плохого качества, система подскажет об этом.



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

Обработка заявки внутренняя кухня

После заполнения в Личном кабинете анкета уходит в CRM, где ее подхватывает менеджер.

Чтобы подключение происходило максимально быстро, среди всех менеджеров, которые работают с клиентами Кассы, была выделена специальная группа. Она ведет клиентов в течение первых месяцев с момента подачи заявки. Новые заявки равномерным образом автоматически распределяются среди наших сотрудников, чтобы на обработку уходило не больше 24 часов.

Менеджер проверяет анкету и вложенные документы компании, а также ее сайт на соответствие требованиям. Они простые, но соблюдаются не всегда. Для подключения приема платежей нужно, чтобы сайт компании, конечно же, исправно работал, чтобы на нем были размещены товары и услуги, указаны реквизиты и контакты все так, как должно показываться покупателям.

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



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

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

Подписание договора и начало работы

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

Кроме этого можно воспользоваться технологичным и безбумажным способом подписи договора при помощи ЭЦП. Для этого мы используем платформу Диадок одну из самых популярных в России систем документооборота. Чтобы оформить договор с нами достаточно войти в Диадок по своему сертификату КЭП (подойдет любой для сдачи отчетности), подписать и отправить нам оферту. Наша СRM система по API сервиса Диадок проверяет новые поступившие договоры и загружает их в карточку клиента. Работа через систему электронного документооборота позволяет ускорить подключение, особенно для более крупных компаний, где передача бумажных документов между сотрудниками занимает время.

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



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

Как вы видите, мы стараемся делать процесс подключения простым и максимально быстрым. Автоматизация и слаженная работа команды Кассы позволяют бизнесу подключить прием платежей в интернете за 2-3 дня, а некоторые наши клиенты подключаются в течение одного дня. Если готовы так же, welcome.




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

Обзор сервисов для получения актуальных курсов валют

18.01.2021 02:05:59 | Автор: admin

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

Краткий обзор

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

  • cbr.ru - Центральный банк Российской федерации.

    В разделе Технические ресурсы -> Получение данных, используя XML - есть примеры, в формате XML можно получить курсы. Если вам нужны совсем точные курсы, так сказать, от производителя - вам сюда. Но сразу скажу список вас не сильно обрадует, да и XML и возможные перебои в работе сайта, а также выходные дни, когда курсы меняться не будут вам обеспечены.

  • сервисы apilayer.com - самые современные АПИ. Есть бесплатные планы. Куча возможностей. О них мы сегодня поговорим.

  • currate.ru - якобы бесплатный сервис для получения курсов валют.

Почему в этот список вошел никому не известный Currate сервис, потому что по моему мнению, что это некий посредник между apilayer.com, т.к. позиционируется как абсолютно бесплатный, но с ограничением в 1000 запросов в месяц.

Причем, ограничение это появилось сразу после того, как его ввел apilayer.com и его сервисы. Возьмите на заметку, те, кто им пользуется. Возможно, это не лучший вариант.

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

Currency Layer

currencylayer.com - полезнейший сервис для получения в режиме онлайн информации о курсах и стоимости 168 мировых валют. Данные собираются из множества источников, вроде сайтов банков, коммерческих информационных сервисов. Ответ в формате JSON.

Есть бесплатный план - 1000 запросов в месяц, правда с тем ограничением, что все курсы будут по отношению к USD.

Но самое интересное на мой взгляд, - это купить за 10 долларов план Basic, вы получите 10000 запросов в месяц + Source Currency Switching, что вам позволит менять базовую валюту, что очень удобно, если вы как и я, например, пишите свой платежный шлюз.

Лирическое отступление

К тебе обзора это, конечно, не относится, но 10000 запросов в месяц, да, собственно говоря хоть 100 тыс запросов - не резиновые, и поверьте, кончаются они очень быстро.

Поэтому, если вам нужна конвертация и вы используете сервисы Api Layer, то рекомендую поделить N запросов в месяц на 30 дней и по крону забирать курсы с полученным интервалом. У меня получилось раз в 5 минут. Можно сказать, практически онлайн.

  • Во-первых, вы получите бесперебойную работу вашего скрипта по синхронизации курсов, и не получится так, что в один день АПИ вам вместо курсов дает ошибки.

  • Во-вторых, вы выработаете весь лимит по запросам в месяц, что, как минимум, окупит ваши затраты, нет смысла платить за 10к запросов и выработать только 2к.

Coin Layer

Криптовалюты росли с тех пор, как Биткойн начал набирать обороты еще в 2011 году. Сейчас криптовалюты торгуются на мировых биржах, и важность концепции блокчейна резко возросла.

coinlayer.com - предоставляет собой универсальное API-решение для получения данных о курсах обмена криптовалют в реальном времени и за прошлые периоды, которое отличается простотой, надежностью и производительностью.

На данный момент есть поддержка 385 криптовалют с 25 бирж.

Полный список поддерживаемых криптовалют можно найти здесь и целевых валют здесь.

Fixer

fixer.io - если верить описанию, данный сервис поддеживает 170 мировых валют. Данные об обменных курсах 170 мировых валют в режиме реального времени, обновляются каждые 60 секунд.

Данные о валютах, представляемых Fixer, поступают от поставщиков финансовых данных и банков, включая Европейский центральный банк.

Честно говоря, большой разницы Fixer.io от Currency Layer я не увидел.

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

Но все же, на мой взгляд Fixer.io более современный и продвинутый инструмент, т.к. по документации на GitHub, которая чаще обновляется и по описанию на самом сайте, кажется, что Fixer.io инструмент пришедший на смену Currency Layer и в будущем он займет лидирующее место в линейке Api Layer.

Заглянем под капот

За, что я люблю сервисы Api Layer, так это за универсальный подход. Они все работают идентично.

Все что вам нужно это зарегистрироваться и получить токен, и, по желанию, купить тарифный план.

А предоставляемые бесплатные запросы, помогут пощупать данный сервис, прежде чем платить за него. Да и работа с АПИ не вызывает никаких затруднений. Ответы в формате JSON. Есть поддержка JSONP. Очень понятная документация с кучей примеров.

Получаем ключ доступа

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

Чтобы пройти аутентификацию с помощью API, просто прикрепите свой access_key к предпочтительному URL-адресу (в дальнейшем это будут энд-пойнты).

Доступные End-пойнты

  • live - для получения самых свежих данных об обменном курсе

  • historical - для получения исторических ставков за определенный день

  • convert - для конвертации одной валюты в другую

  • timeframe - для запроса курсов обмена на определенный период времени

  • change - для запроса любых параметров изменения валюты (маржа, процент)

Работа с АПИ

https://api.currencylayer.com/live?access_key=YOUR_ACCESS_KEY

В ответ вы получите JSON, примерно с таким содержимым:

Пример ответа в формате JSON
{    "success": true,    "terms": "https://currencylayer.com/terms",    "privacy": "https://currencylayer.com/privacy",    "timestamp": 1430401802,    "source": "USD",    "quotes": {        "USDAED": 3.672982,        "USDAFN": 57.8936,        "USDALL": 126.1652,        "USDAMD": 475.306,        "USDANG": 1.78952,        "USDAOA": 109.216875,        "USDARS": 8.901966,        "USDAUD": 1.269072,        "USDAWG": 1.792375,        "USDAZN": 1.04945,        "USDBAM": 1.757305    }}

Наряду сsource валютой,timestamp и другой мета-информации, API вернетquotes объект, содержащий все доступные или указанные валютные пары с соответствующими значениями обменных курсов (котировками).

Переключение исходной валюты

Данная опция платная и становится доступна, начиная с плана Basic / 10$ в месяц.

Исходная валюта (часто также называемая базовой валютой) - это валюта, относительно которой все значения котировок в наборе результатов API являются относительными (значение по умолчанию:)USD.

Исходную валюту можно найти вsource объектеответа API.Это также первый трехбуквенный код валюты возвращаемой валютной пары.(напримерUSDEUR, гдеUSD находится исходная валюта)

Обратите внимание, что только валюты, которые являются частью соответствующего набора результатов (quotes), могут быть установлены в качестве исходной валюты.

Благодарю за внимание.

Посткриптум

К сожалению, более-менее нормальных клиентов под эти сервисы ApiLayer, для того же PHP на GitHub попросту нет. То, что есть, с этим работать просто невозможно.

Я не рассматривал кустарные либы с кол-вом звезд < 20, без тестов, линтеров и прочего, без поддержки PHP 8 и прочих плюшек вроде Larave / Symfony.

Поэтому для вас мои дорогие читатели свеженький опрос.

Если наберется достаточное кол-во желающих, я напишу удобные клиенты под Laravel / Symfony и выложу на GitHub в своем профиле.

Подробнее..

Особенности национальной интеграции с платёжными системами

24.02.2021 12:05:30 | Автор: admin
Электронная коммерция стала трендом 2020 года. Крупные игроки рынка начали активно развивать сервисы доставки продуктов и готовых блюд. Как грибы после дождя выросли новые маркетплейсы. Даже те, кто был далёк от интернета и технологий, вынужденно погрузились в тему дистанционной торговли. Почему все знают, но сегодня поговорим не об этом. Перейдём сразу к ключевому звену коммерции приёму платежей. В статье поделюсь несколькими рекомендациями о том, как с ним работать.

image

Меня зовут Андрей Шубин, работаю в VK в команде разработки e-commerce в сентябре мы запустили Маркет ВКонтакте. Занимаюсь веб-разработкой десять лет, из них семь работаю с интернет-магазинами, маркетплейсами и другими проектами, продающими через сеть. Последние три года возглавлял разработку для электронной коммерции в компании Siberian Wellness у неё есть представительства в большинстве стран СНГ, ЕС, немного в Юго-Восточной Азии и Северной Америке. Именно из-за такой обширной географии мне довелось познакомиться с локальными платёжными агрегаторами, а также с законодательством некоторых стран.

Эта статья будет полезна разработчикам уровня middle, которые взялись за новое для себя направление ступили на скользкий путь e-commerce. Если вы в этой сфере давно, некоторые кейсы могут показаться очевидными. Буду рад любому фидбэку в комментариях.

Типы данных


Только ленивый не говорил, что вычислительная техника может допускать некоторую погрешность при работе с числами с плавающей точкой. Да-да, попробуйте сложить 0,1 и 0,2, если раньше этого не делали, будете удивлены. Но в работе с финансами точность и однозначность это то, что должно быть на первом месте. Если где-то в расчётах проскользнёт лишняя копейка, последствия могут быть печальными. Конечно, за одну копейку с вами связываться никто не будет хотя известны случаи, когда ФНС таки отправляла налогоплательщику требование уплатить недоимку в 0,01. Но при относительно больших оборотах разница между фактически полученной суммой и той, что отображена в чеках, может принять критическое значение и тогда знакомство с налоговым инспектором вам гарантировано. Особенно если всё происходит в Германии или Чехии.

Кстати, раз уж речь зашла о других странах и типах данных. В мире есть очень дешёвые валюты и с ними обороты компании могут измеряться суммами с целым паровозом нулей. В моей практике это были вьетнамский донг и белорусский рубль до 2017 года. Если вам предстоит работать с одной из таких валют, проверьте своё хранилище на предмет разрядности. Иначе может случиться то же самое, что сделал с ютубом клип Gangnam Style в декабре 2014-го.

Общение с платёжной системой


В общем случае жизненный цикл платёжной транзакции выглядит так:

  1. Принимаем заказ.
  2. Формируем ссылку на платёжный шлюз, в который вшиваем сумму к оплате, номер заказа и что там ещё попросит платёжная система.
  3. Редиректим клиента по этому адресу.
  4. Клиент вводит данные карты и перенаправляется на страницу благодарности (thank you page) магазина.
  5. Банк списывает со счёта клиента деньги и делает callback-запрос на специальный эндпоинт с нашей стороны.
  6. Меняем статус заказа и проводим попутные манипуляции.

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

  • В Казахстане система не признавала редирект методом GET. Она требовала сначала на бэкенде сформировать зашифрованную строку с параметрами платежа, а затем нарисовать в магазине HTML-форму, где единственным параметром должна быть эта строка. И уже форму нужно было отправлять синхронно после этого пользователь попадал на страницу, где мог ввести номер карты. Но просто дождаться callback-запроса недостаточно: необходимо было сделать ещё один запрос с бэкенда, чтобы дать банку понять, что мы готовы принять оплату.
  • В Чехии ввели онлайн-кассы и из-за этого требовалось кроме суммы передать на сторону платёжного шлюза полный список позиций на чешском языке, включая цены и рассчитанные значения НДС. И если вы даёте клиенту скидку, то не можете просто взять и закинуть её в чек отрицательным числом. Так не работает. Нужно пересчитать стоимость всех позиций с учётом этой скидки или распределить её размер по конкретным позициям. И подойти к этому с умом потому что у разных товаров может отличаться ставка НДС, а если вы случайно дадите скидку на товары с большей ставкой, этим может заинтересоваться налоговый инспектор во время камеральной проверки.
  • Нацбанк Молдовы переложил на продавца обязанность отправлять клиенту электронный чек. При этом в нём требуется отображать определённую банковскую информацию. Получать её нужно из callback-запроса от банка либо отдельным методом API. А ещё местные ребята не особо следили за актуальностью документации и не могли ответить на наши вопросы в письмах так что пришлось ехать туда лично и общаться с техдиром.
  • В Узбекистане пошли дальше: решили, что один цикл запрос ответ это слишком просто. Считаем вместе:

    • раз банк узнаёт, готовы ли мы вообще принять платёж;
    • два банк передаёт ID покупателя, который мы ему передали раньше, а мы должны подтвердить, что это действительно наш пользователь;
    • три банк сообщает номер заказа и сумму к оплате, а мы проверяем, что всё ОК, и даём соответствующий ответ;
    • четыре банк подтверждает, что деньги успешно списаны, мы отвечаем, что приняли.

    И только в этот момент мы наконец меняем статус заказа у себя и движемся дальше. Четыре запроса вместо одного!
  • Вьетнамский оператор эквайринга вообще не присылает callback-запрос. Мы должны сами запросить статус транзакции. И при этом использовать ID транзакции, который присваивается оператором и передаётся GET-параметром на thank you page.

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

Не ждите! Пишите первыми


Сделать на своей стороне эндпоинт, на который будет стучаться платёжная система со своими запросами, это очень заманчиво. Но будем честны никто из нас не в состоянии обеспечить 100%-й аптайм: в какой-то момент может отвалиться связь с сервером базы данных или с каким-то другим сервисом, и тогда ваше приложение не сможет отдать ожидаемый ответ. И здесь уже надо смотреть по документации, как поведёт себя конкретная платёжная система (если об этом, конечно, там написано).

Например, в том же Казахстане местный банк делал три запроса с разницей в секунду и после третьего фейла считал транзакцию неуспешной. При этом деньги клиента зависали где-то между счётом клиента и нашим р/с. Сдвинуть их в ту или иную сторону можно было двумя способами: либо делать отдельный API-запрос в течение ограниченного времени, либо идти в отделение банка, с которым заключён договор эквайринга, и писать заявление от руки. Знакомо?

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

Если такой возможности нет, то callback-запросы от банков лучше принимать на отдельный сервер, которому нужно обеспечить максимальный аптайм. В идеале это должен быть простой веб-сервер, который пишет таски в брокер сообщений. Совсем круто, если будет кластер таких серверов. Эх, мечты На самом деле такой монстр, скорее всего, не потребуется, но направление вы поняли.

Откройте глаза! Мониторинг наше всё


В работе с платежами есть скрытые процессы, от которых зависит вся цепочка электронной торговли. Чтобы не быть голословным, приведу пример из практики. У нас был договор интернет-эквайринга со Сбером и договор аренды онлайн-касс с Orange Data. Интеграции из коробки между этими двумя конторами нет, поэтому пришлось делать её на своей стороне. Обработали callback от Сбера, сформировали запрос к оператору фискальных данных, который генерирует чек и отправляет его в налоговую и клиенту на электронную почту. И вот в один не самый прекрасный день Orange Data аннулирует токен авторизации и чеки перестают выписываться и отправляться. Чтобы вы понимали, штраф за невыдачу одного чека 40000 рублей. А узнали мы о сбое в процессе совершенно случайно, спустя два месяца: один дотошный пользователь позвонил в контакт-центр спросить, почему ему не пришёл чек Спасибо, добрый человек! Мы успели всё пофиксить и разослать зависшие чеки до конца отчётного периода. А если бы не сделали этого, размер штрафов не оставил бы компании шансов на выживание.

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

Иногда нужно поработать ручками


E-commerce, как и любой IT-продукт, это не только мы с вами (разработчики), но и целая инфраструктура: с юристами, региональными менеджерами, службой логистики и клиентской поддержки. Вот на последней остановимся подробнее.

Это ребята, которые принимают обращения пользователей через разные каналы. Причём обратная связь, как правило, негативная. И вот они весь день выслушивают претензии к работе вашего интернет-магазина, на них повышают голос в том числе за наши с вами баги.

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

Вместо заключения


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

P. S. Обращаюсь от имени всех разработчиков из e-commerce к финтех-разработчикам. Ребят, ну сядьте вы уже, договоритесь, выработайте единый стандарт взаимодействия с мерчантом. Все же от этого выиграют!
Подробнее..

О фейковых криптовалютах (Ethereum, Tron, Ripple и пр)

01.03.2021 02:23:51 | Автор: admin

В многочисленных популярных роликах и текстах, объясняющих принципы работы криптовалют, это объяснение обычно дается на примере Bitcoin - первой из криптовалют. Биткоин - на самом деле чистая и понятная реализация принципов, необходимых для криптовалюты: открытость истории транзакций, возможность проверки источника денег по цепочке, понятные правила появления денег, понятные правила создания новых транзакций. Новые монеты появляются только в результате майнинга новых блоков, и награда за майнинг постепенно снижается по логарифмическому закону, в результате чего общая сумма выпущеных биткоинов никогда не превысит лимита (21 миллион). Любая трата денег (вход транзакции) должна соответствовать выходу другой транзакции, деньги не могут появиться ниоткуда. Для траты нужно подписать транзакцию приватным ключом. Простой скриптовый язык позволяет делать multisig и всякие другие полезные вещи, в том числе и создавать новые валюты (токены) на базе биткоинового блокчейна (omni layer, так живёт USDT). Центрального узла нет, новый блок определяется консенсусом всех узлов - при наличии нескольких вариантов они принимают ту ветку, в которой сделано максимальное количество вычислений, это формальный критерий, не допускающий разночтений. Собственный узел может запустить любой пользователь, исходный код открыт.

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

Это закономерно привело к появлению муляжей криптовалют, которые якобы используют те же технологии, но при этом дают преференции их создателям, т.е. не такие уж децентрализованные. Для пользователей всё равно, а создателям профит. Самый распространённый из таких муляжей - Ethereum.

В нулевом блоке эфира роздано 72_009_995 Ether на 8903 адреса, это больше, чем всего получено наград за майнинг блоков (сначала было 5 Ether за блок, потом сделали 3 Ether, сейчас 2 Ether) за всё время. Ещё раз: более половины всего эфира, который сейчас есть в наличии, был роздан в нулевом блоке при старте этой криптовалюты, а меньшая часть появилась в результате майнинга блоков. Попробуйте нагуглить этот факт в описании этой криптовалюты - скорее всего ничего не выйдет, он не афишируется, и даже скрывается.
Эфирная нода geth эти стартовые транзакции не показывает, как будто их нет. Говорит, что нулевой блок пустой.
Эксплореры либо показывают их существование, но не дают смотреть подробности (etherscan.io, blockchair.com), либо вообще их не показывают, в результате чего история транзакций по адресу выглядит странно: только траты, без прихода, но положительный или нулевой итоговый баланс. Особую пикантность эта информация приобретает в сочетании с декларируемыми планами перехода с proof-of-work к proof-of-stake, т.е. изменение алгоритма консенсуса с "прав тот, кто проделал больше вычислений" на "прав тот, у кого больше денег".
Наличие такого мухлежа в стартовом блоке привело к тому, что эта криптовалюта в принципе не могла быть столь же открытой и прозрачной, как биткоин, иначе эта история была бы сразу всем видна. И если в биткоине для определения баланса адреса достаточно посчитать сумму utxo (неизрасходованных выходов транзакций), то в эфире это намного сложнее: нужно просматривать все транзакции по адресу (траты и поступления), но и этого недостаточно: баланс может измениться в результате работы смартконтракта ("internal transactions"), а это бинарный код в теле транзакции. В результате, даже запустив собственную ноду, я не могу посмотреть историю операций по какому-то адресу (даже моему собственному), мне для этого нужно обращаться к сторонним сайтам, работающим на собственном софте, т.е. доверять им: "There's not currently any way to do this using the web3 API. [] Blockchain explorers like etherscan obtain internal transactions by running a modified node with an instrumented EVM" (1); "The trouble I see with this is that this centralizes that data. If I create that data, how you know I didn't fake it? I've been trying to figure out a way to both index it and decentralize the 'indexing calculation.' I know how to decentralize the storage (IPFS), but not how to decentralize the indexing calculation. (2) Историю изменений баланса адреса негде запросить, потому что она просто нигде не хранится: нода хранит только состояние (баланс каждого адреса), а в блокчейне сохраняется контрольная сумма (хеш) от этого состояния, ну и сами транзакции, в виде бинарного кода.

Эфирные сматрконтракты - отдельная песня. По сути это ничем не отличается от выполнения какого-то бинарного файла на вашем компьютере, его код не открыт, а логика работы неизвестна. То, что он находится в блокчейне, а не на чьём-то сайте, ни на что принципиально не влияет, кроме психологии пользователей, доверяющих слову "блокчейн". Что, собственно, и требуется. Стандарт ERC20 определяет "узнаваемые" сигнатуры функций, вроде "передать столько-то токенов от такого-то адреса такому-то", но ERC20 не регламентирует, какие ещё функции могут быть у этого смартконтракта (например, "забрать все токены у всех пользователей"). Код смартконтракта, как и код обычной программы, автор может открыть, но это вопрос доброй воли. Смартконтрактам с открытым кодом, конечно, есть больше оснований доверять - в той же степени, что и обычным программам с открытым кодом. Но многим ли пользователям важно, что у Chromium и у Firefox открытый код, а у Chrome и Safari закрытый?

Поскольку чистота и изящество технической реализации не являлись целью при создании эфира, эти качества по сравнению с биткоином в эфире сильно пострадали. Приведу несколько примеров.
У транзации bitcoin может быть несколько входов и несколько выходов. В результате я могу, например, давать каждому своему контрагенту отдельный адрес для перечисления мне денег, смотреть, когда кто-то из них заплатил, а когда мне самому нужно заплатить - я могу платить с нескольких этих адресов одновременно. А для сдачи сгенерировать какой-то новый адрес. В результате получается определённая степень анонимности: тот, кому я заплатил, не знает, сколько у меня всего денег на других адресах, сколько клиентов, которым я плачу и т.п. Прослеживание истории каждого из входов транзакции, в которой он получил от меня деньги, не даст ему никакой интересной информации.
В эфире у транзакции один вход и один выход. Чтобы заплатить кому-то, если я не хочу платить несколькими частями (на то она и транзакция), мне нужно сначала собрать достаточно денег на одном своём адресе, а потом с него выплатить, причём сдача останется там же. История транзакций по адресу, с которого человек получил от меня платёж, даст много информации обо мне.
И дело не только в приватности. Проводя платёж, я помещаю в блокчейн публичный ключ для этого адреса. Получение приватного ключа по публичному в данный момент малореально, но с появлением квантовых компьютеров всё может быть. У биткоина, как я говорил, сдача идёт на новый адрес (именно так рекомендуют делать), и на тех адресах, с которых произошёл платёж, т.е. публичные ключи которых опубликованы в блокчейне, уже ничего нет, взламывать нечего.

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

Комиссия за транзакции (gas) - отдельный адок. Она строится из двух составляющих: цены на "газ", и сколько газа потрачено. Цену на газ устанавливает создатель транзакции исходя из того, насколько быстро он хочет, чтобы его транзакция стала подтверждённой, и текущей "рыночной цены" - это примерно как у биткоина. А вот сколько газа потребуется потратить на транзакцию, заранее неизвестно, отправитель не знает. Даже одна и та же функция одного и того же смартконтракта может потребовать разное количество газа, и не только из-за возможных ветвлений, но и просто в зависимости от amount на адресах в момент её включения в блокчейн. Поэтому отправитель устанавливает максимальное количество газа, которое он готов потратить, а сколько потрачено на самом деле, станет понятно только когда транзакция станет подтверждённой. Соответственно, трудно потратить все деньги, имеющиеся на адресе: комиссия снимается с него же, и если установить большой max_gas, то останется сдача, а если маленький, то его может не хватить.
По той же причине в Ethereum невозможен и "spend unconfirmed", который так удобен и привычен в биткоине. То есть, если есть транзакция получения денег, то я могу создать следующую транзакцию по отправке этих денег куда-то ещё, не дожидаясь, когда первая транзакция станет подтверждённой. Если она отменится - автоматически отменится и вторая. Либо они обе подтвердятся. В эфире так нельзя, потому что пока транзакция не подтверждена, неизвестно, как в её результате изменятся балансы на адресах. Например, если у меня есть адрес с токенами, но без эфира, я не могу потратить эти токены, потому что нужно заплатить комиссию, причём именно с того адреса, с которого отправляются токены. Соответственно, я должен сначала отправить на этот адрес эфир, а потом уже оттуда отправлять токены. И я не могу эти две транзакции отправить подряд - нет, я должен дождаться подтверждения первой транзакции, и только потом отправлять вторую.
Откуда вообще взята идея этого непредсказуемого газа? В биткоине комиссия ставится пропорционально размеру транзакции в байтах. Это логично: размер блока ограничен, и туда можно включить либо одну большую транзакцию, либо на её место десять мелких. В эфире gas определяется количеством и сложностью операций в смартконтракте, и это нелогично: майнящая нода, хоть и должна выполнить этот смартконтракт для включения транзакции в блокчейн, но объём этих вычислений совершенно несравним с вычислениями собственно хеша блока, необходимыми для proof-of-work. Это разные единицы измерения, как метры и килограммы. И майнеру выгоднее включать в блок "дорогие" смартконтрактные транзакции, чем дешёвые простые пересылки, потому что он в таком случае получит больше награду. Вот вам и идея майнера, приносящего большую прибыль. А чтобы простые транзакции всё-таки тоже подтверждались, на них нужно устанавливать больше gas_price - и в итоге придём к тому, что считаем рыночную комиссию за транзакцию (учитывая её размер), потом делим на предполагаемый расходуемый gas, и результат пишем в поле gas_price. Бред ведь?

Но ситуация ещё комичнее. Зачем вообще регистрировать смартконтракт, почему нельзя писать данные в обычную транзакцию? Именно так работает omni layer поверх блокчейна bitcoin, и на нём были запущены USDT. Ведь это лишь вопрос трактовки, и ничто не мешает нам договориться и трактовать определённые данные в eth-транзакциях как пересылку каких-то токенов, оплачивая за это минимальный gas. Есть только одна причина, почему может быть необходима регистрация смартконтракта: если он отправляет кому-то ether, т.е. те самые "internal transactions", от которых столько проблем, и которые разрушают стройность блокчейна. Обычный смартконтракт ERC-20 (которых большинство, это простая реализация другой валюты или токенов) никакой отправки ether средствами смартконтракта не предполагает (хотя и не запрещает), т.е. для них регистрация не нужна, и платить дополнительный gas тоже не нужно. Иными словами, оплатой gas за смартконтрактные транзакции мы оплачиваем не распределённое выполнение этого смартконтракта майнерами и не хранение данных в блокчейне, а лишь используемый алгоритм. Запустим свой, чуть модифицированный алгоритм на том же самом блокчейне эфира - и вуаля, получим токены без дополнительного газа, подобно omni layer в биткоине. Причём нам совершенно не нужно, чтобы этот софт запустили все ноды или даже заметная часть - достаточно чтобы его запустили владельцы токенов, т.е. это может быть просто кошелёк.

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

Ripple, Tron

У них суть похожая. Декларируется децентрализация, распределённость, все дела. Можно ли поднять свою ноду - да, без проблем, вот исходники, любой желающий может поднять.
Но при ближайшем рассмотрении оказывается, что эта нода не участвует в консенсусе, а только получает информацию о транзакциях от других узлов и отправляет другим узлам свои транзакции. Если покопаться глубже, можно найти информацию о том, что поднять майнящую ноду можно, для этого нужно взять другой софт, заплатить кому-то сколько-то денег и подать заявку на рассмотрение. То есть, эти валюты не являются децентрализованными ни административно, ни технически (новый майнящий узел подключается к сети вручную). Вопрос о том, как происходит распределение денег, в такой ситуации уже неважен: понятно, что в любом случае полный контроль за появлением монет, как и за механизмами консенсуса, находится в частных руках.
Такой отказ от децентрализации принципиально упрощает вопросы консенсуса - новый блок можно принимать хоть простым большинством узлов без дорогостоящих вычислений подписи в proof-of-work, а вопрос генерации новых монет и вовсе отпадает - они все изначально принадлежат владельцу валюты и эмитируются только им (или доверенными узлами, что по сути то же самое).

В угоду бизнесу произошёл сдвиг терминологии. Изначально криптовалютами назывались только "настоящие" децентрализованные валюты с полностью открытым и равномерным появлением новых монет, как в Bitcoin, Litecoin и подобных. Потом криптовалютой стали называть Ethereum, который, впрочем, скрывал "особенности" стартовой эмиссии. Дальше - криптовалютой стали смартконтрактные токены, живующие в эфирном блокчейне, даже с закрытым кодом (т.е. с неизвестными правилами). Потом гордое название "криптовалюта" стали носить любые валюты, использующие блокчейн, децентрализация перестала быть обязательной. И, наконец, блокчейн тоже перестал быть необходим: в Ripple его и нет, а просто по сути любые электронные деньги стали называться криптовалютой.

Отдельно стоит упомянуть stablecoins вроде USDT. Они тоже существуют в распределённом блокчейне, как будто настоящие криптовалюты, а отличие их в том, что существует владелец, который может создавать новые монеты в произвольном количестве. Этот владелец декларирует, что выпускает новые монеты ровно в таком количестве, сколько ему заплатили настоящих денег, эти настоящие деньги хранит в сейфе, и таким образом гарантирует, что эти монеты всегда можно будет продать по курсу 1:1 к USD. Пользователям предсказуемость курса удобнее, чем высокая волатильность биткоина, а магические слова "криптовалюта" и "блокчейн" вызывают больше доверия, чем просто чьи-то электронные деньги вроде perfectmoney. Тут достаточно очевидно, что блокчейн в данном случае - не более чем открытый реестр, а владелец имеет полный контроль над валютой. Курс удерживается стабильным постольку, поскольку ему можно не давать расти дополнительной эмиссией, но если он начнёт падать, компенсировать его слишком большими вливаниями владелец вряд ли будет, у него просто закончатся деньги. Ведь вряд ли кто-то на самом деле верит в то, что все полученные деньги они действительно хранят в сейфе и не тратят. Хотя такая декларация, наверное, может быть выгодна в плане уплаты налогов, это ведь получается нулевая прибыль.

Подробнее..

Что было, если бы не было налогов?

22.03.2021 14:08:01 | Автор: admin

Это очень короткий пост об идее, которая у меня родилась очень давно. Лично я вижу в ней огромный потенциал. Особенно, если учесть, что Банк России собирается внедрять крипто-рубль. Суть её в том, что государство могло бы заменить налоги процентами за переводы денег так же, как это происходит во всех платёжных системах.


Примечание: я скорее всего буду здесь мешать в кучу и коней и людей, но у меня нет доступа ко всем цифрам, связанным со сбором налогов. Например, я смог найти сборы по НДФЛ, но не смог найти, сколько человек при этом заплатили НДФЛ.

Первоначально, идея возникла, когда я начал пользоваться PayPal. Главное его отличие от других платёжных систем в том, что комиссию платит получатель платежа, а не отправитель. Это очень похоже на систему, когда человек платит налоги: получил деньги, отдал их часть на поддержание государства. Если государство контролирует свою платёжную систему, то оно может брать деньги за сервис просто по факту использования этого сервиса. Любой денежный перевод облагается комиссией. Получил зарплату заплатил комиссию за перевод. Купил что-то в магазине этот магазин заплатил комиссию за входящий перевод.

Чтобы иметь какую-то точку опоры, я взял сборы по НДФЛ за 2020-й год. За 2020-й год физические лица уплатили НДФЛ в размере 4,25 триллиона рублей. Население России составляет, грубо говоря, 146 миллионов человек (знакомьтесь: сферический конь в вакууме, потому что учитываются всё вообще население, а не количество людей, которые получают деньги и платят налоги). То есть, эти 146 миллионов человек получили совокупный доход в 32,7 триллиона рублей и заплатили с них налог 13%. Если предположить, что в РФ вместо налогов взимается комиссия за перевод в размере 13%, то для обеспечения сопоставимых сумм сборов достаточно, чтобы каждый из этих 146-ти миллионов человек за год получил где-то 224 тысячи рублей, или 18 700 рублей в месяц.

Я считаю, если это стоящая идея, Хабр самое хорошее место, чтобы её озвучить, потому что здесь очень большая аудитория, в том числе, имеющая отношение к государственным структурам. Было бы здорово услышать ваше мнение, особенно если оно будет связано не с критикой власти и соответствующим флеймом, а будет относиться к плюсам и минусам этой конкретной и узко очерченной идеи.

Подробнее..

Проблема доступа к кошельку Ю-мани или рекурсия по-сберовски

05.04.2021 06:20:47 | Автор: admin
Вы не спрашивали, но я всё равно расскажу про свой опыт взаимодействия с этим чудо-сервисом, продуктом любви не менее чудо-яндекса с не более чудо-сбером посредством рук чудо-разработчиков (но только рук!). И почему восстановление вашего кошелька может оказаться невозможным, особенно, если вы не находитесь в РФ.

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

З забота.

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

Сайт юмани обещал безболезненный переход из яндекс-денег, таки ведь сбербанк.
Яндекс аккаунт у меня верифицированный и виртуальная карта тоже была верифицированной, поэтому была надежда получить сразу верифицированный юмани (спойлер нет, юмани переносит только балансы, а верификацию придётся проходить заново в общей очереди).
Ок, дотыкав до подтверждения номера телефона я обнаружил, что номера того давно у меня нет, закрыл страницу без подтверждения и вернулся в почтовый ящик, где заменил номер. Замена заняла месяц.
Кто не знает, в яндексе работает вполне стандартная процедура смена номера, когда нет доступа к предыдущему изменение холдится на 30 дней и в любой момент может быть отменено.
Я уж и забыл про юманю, но они вдруг прислали уведомление что у меня закончилась карта (та самая, которую они же и блоканули ещё в январе) и получите-ка новую.

И тут заве

Перенос кошелька из яндекса в юманю прошёл успешно, ни на каком из этапов никаких предупреждений (например, что он уже был перенесён ранее) не выскакивало. Более того, я потом несколько раз повторял перенос и всегда он проходил успешно.
Но вот незадача юманя уже подсосал старый номер телефона (хотя я месяц назад не завершил перенос кошелька и не подтвердил сам перенос и номер кодом из СМС == не подписал операцию ЭЦП) и принимать новый номер, уже активированный в почтовом ящике, отказывался наотрез.
Ок, некоторое время поиска по FAQ выводит нас на рецепт нужно заполнить форму для привязки нового номера или нажать на карандашик в настройках кошелька:



Насторожило, что обе ссылки ведут на вход в кошелёк:







И не зря насторожило. Чтобы войти в кошелёк и сменить номер, или заполнить анкету на смену номера, нужно получить СМС на старый номер!
Если вы (или вам) заблокировали кошелёк звонком в юмани, вас ждёт то же самое. Если у вас украли телефон только восстановление сим карты.

Способа связаться с человеком или иного сапорта найдено не было. Кроме российских номеров телефонов, по которым надо звонить в рабочее время. Скажу честно не звонил. Возможно там бы меня встретил квалифицированный спрециалист и непременно помог, но верится с трудом
Тем более, что FAQ ненавязчиво предупреждает: скорее всего придётся заполнять заявление в отделении банка.

Я нахожусь не в РФ и стоимость телефонных [цитата Лаврова] звонков в юмани превысила бы остаток на счёте яндекс денег, а желание доверять свои деньги компании, в которой без звонка в их рабочее время можно лишь бесконечно лазить по FAQ отпало напрочь. Равно как и проходить верификацию, т.к. кроме сомнительной надёжности хранения и обработки персональных данных у этих гениев алгоритмизации, есть очевидный риск потери доспупа к кошельку по неочевидным причинам.

К слову, коллега запустил верификацию ещё в январе. До сих пор видит такую картинку:



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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru