Comments 27
Существует несколько реализаций XFS-менеджеров (в том числе с открытым исходным кодом), написанных на c++ и теоретически библиотеки сервисных провайдеров, написанные под один менеджер, так же должны подходить ко всем остальным, но по факту иногда библиотека, написанная конкретным вендором под конкретный XFS менеджер, работает только с этим менеджером.
Также существует Java XFS со своими библиотеками, не совместимыми с классическими менеджерами.
Любой крупный производитель банкоматов (Wincor, NCR, Diebold) имеет свою реализацию как XFS, так и банковского приложения.
И как тогда добиваться совместимости?
Однако на рынке есть альтернативный софт, соответствующий всем стандартам и не привязанный к конкретному вендору.
Что за софт — платный или бесплатный? Ссылки, плиз, в студию.
Так что получается, правильно ли я понимаю, что разработчик платёжного приложения для POS-терминала может просто (по идее) взять библиотеку к устройству от вендора, которая отвечает требованиям XFS-менеджера и просто юзать XFS-менеджер? И в дальнейшем при появлении нового оборудования просто подключать новые библиотеки соответствующие требованиям XFS?
Однако на рынке есть альтернативный софт, соответствующий всем стандартам и не привязанный к конкретному вендору.
И вы слетаете с гарантии и суппорта?
Нет, не слетаете.
Сейлзы производителей банкоматов часто стращают банки потерей гарантии на всё устройство если банк отказывается от софта, но на самом деле это не так, поставщики банкоматов продолжают обеспечивать гарантию на железо.
Сейлзы производителей банкоматов часто стращают банки потерей гарантии на всё устройство если банк отказывается от софта, но на самом деле это не так, поставщики банкоматов продолжают обеспечивать гарантию на железо.
А суппорт? А обновления? Драйвера? Если честно не вижe смысла париться с аналогами XFS — проще в веб стэйт отдать управление… и вендорам ок и владельцам меньше проблем.
Водораздел идёт по XFS: вендор банкомата отвечает за работу устройства и работу драйверов до слоя XFS. Выше XFS — ответственность поставщика банкоматного софта.
Это позволяет забыть о NDC/DDC, стэйтах-шмейтах и прочих ограничений эпохи королевы Виктории.
Это позволяет забыть о NDC/DDC, стэйтах-шмейтах и прочих ограничений эпохи королевы Виктории.
Имхо как раз левый софт на банкомате — источник проблем. Это надо мониторить, обновлять и тд и тп. Почему просто не открыть веб вью стэйт и тоже забыть про стэйты?
Вы еще забываете, что сборки ОС у вендоров свои.
Вы еще забываете, что сборки ОС у вендоров свои.
Смотря что называть «левым» софтом.
Практика показывает, что софт компаний специализирующися на банкоматном софте внезапно оказывается лучше дефолтного софта поставляемого вместе с железом.
Особенно это становится явно, когда в банке большая сеть, особенно, когда используются устройства нескольких вендоров.
А если в банке несколько хостов, то дефолтный софт банкоматных вендоров уже совсем не подходит.
Практика показывает, что софт компаний специализирующися на банкоматном софте внезапно оказывается лучше дефолтного софта поставляемого вместе с железом.
Особенно это становится явно, когда в банке большая сеть, особенно, когда используются устройства нескольких вендоров.
А если в банке несколько хостов, то дефолтный софт банкоматных вендоров уже совсем не подходит.
Дак мой вопрос и строится вокруг идеи — зачем менять софт — когда есть браузер на банкомате. Открыли браузер, передали управление и вперед. Зачем ставить кастомный XFS? Не подскажите имена вендоров и софта?
Просто браузер много не даст. Печать на чеке останется проблемой, скажем, в числе многого.
Отдали браузером управление — значит еще один хост должен дублировать функционал АТМ-контроллера: транзакции, реконсиляция, аутентификация, журналирование, все эти прелести.
Специализированный софт (CR2, к примеру) имеет свой АТМ-контроллер, свой АТМ-клиент и общаются они по своему протоколу. Никаких NDC и прочего архаизма. В легаси-схеме устарел сам подход, когда банкомат был тупым терминалом.
Основные банкоматные вендоры идут дорогой замены и хоста и клиента, эмуляцией (и заменой) ISO, NDC. Есть даже инсталляции кое-где, но лет пять готовых продуктов еще не будет.
Радует, что все вендоры идут в одну сторону, но беда в том, что, как обычно, каждый вендор идёт чуть-чуть своей дорогой.
Отдали браузером управление — значит еще один хост должен дублировать функционал АТМ-контроллера: транзакции, реконсиляция, аутентификация, журналирование, все эти прелести.
Специализированный софт (CR2, к примеру) имеет свой АТМ-контроллер, свой АТМ-клиент и общаются они по своему протоколу. Никаких NDC и прочего архаизма. В легаси-схеме устарел сам подход, когда банкомат был тупым терминалом.
Основные банкоматные вендоры идут дорогой замены и хоста и клиента, эмуляцией (и заменой) ISO, NDC. Есть даже инсталляции кое-где, но лет пять готовых продуктов еще не будет.
Радует, что все вендоры идут в одну сторону, но беда в том, что, как обычно, каждый вендор идёт чуть-чуть своей дорогой.
Проблема в том, что опять свой протокол. Как с ними интегрироваться другим вендорам?
Да, в этом беда. Нет ещё единого протокола и, мне кажется, ещё лет десять не будет.
Ну тот же CR2 свой проприетарный протокол открыл, но это ещё не стандарт.
Ну тот же CR2 свой проприетарный протокол открыл, но это ещё не стандарт.
Просто имхо — будущее банкоматов — это веб морда, которая требует минимального железа и обвязка к нативному апи доступному из js. Снимает кучу проблем вроде контроля целостности ПО, обновления софта как примеры.
Это не будущее, это уже почти настоящее) (не сочтите за рекламу).
Мне программирование этих стейтов чем то напомнило создание микропрограммы для ядра микропроцессора, битовые поля, адреса переходов… Я понимаю что такой подход был бы актуален лет 30 назад, когда в банкомате был совсем примитивный процессор. А почему не пришли на какие нибудь более человекопонятные скрипты?
А есть ли какие нибудь среды разработок, которые позволяют создавать конфигурации визуальным способом? Или какие нибудь скриптовые языки которые компилируются в конфигурацию?
А есть ли какие нибудь среды разработок, которые позволяют создавать конфигурации визуальным способом? Или какие нибудь скриптовые языки которые компилируются в конфигурацию?
Для все более или менее развитых хостовых систем, есть и эмуляторы которые позволяют на 80-90% оттестировать логику переходов или что вводит видит пользователь, проверить правильность таймаутов. Есть визуальные средства помогающие увидеть граф переходов по стейтам. Есть относительно примитивные редакторы для графики.
А все остальное от лукавого. Хорошим примером является банкоматы и терминалы сбербанка. На банкоматах все ясно и понятно. А вот на терминалах смены дизайна и расположения элементов достали.
минимализм и жесткость хорошо дисциплинирует и позволяет сосредоточится на сути, а не на дизайнерских глюках.
А все остальное от лукавого. Хорошим примером является банкоматы и терминалы сбербанка. На банкоматах все ясно и понятно. А вот на терминалах смены дизайна и расположения элементов достали.
минимализм и жесткость хорошо дисциплинирует и позволяет сосредоточится на сути, а не на дизайнерских глюках.
Я тут интересный баг/фичу обнаружил: вместо PIN-кода можно ввести любые 8 цифр, даже не придётся нажимать «подтвердить» на клавиатуре — при нажатии последней цифры открывается банкоматное меню.
Деньги снять, конечно, не удалось, но знакомые банковские сотрудники удивляются)
Деньги снять, конечно, не удалось, но знакомые банковские сотрудники удивляются)
Да, ибо максимальная длина пин-кода — именно 8 символов. После ввода 8-го символа автоматически открывается меню, так как далее вводить пин не имеет смысла для любой из ныне существующих карт любого банка. Но, по всей вероятности, в данном конкретном сценарии, проверка правильности пин-кода не происходит, ибо клавиша ввода нажата не была.
Проверка не происходит, скорее всего, из-за настроек конкретного банка/процессинга. Потому как успел попробовать в банкомате другого банка — сработало не на 8-й, а уже на 7-й цифре.
К тому же, читал в одной из статей тут или на Гиктаймс, что есть банкоматы, которые проверяют PIN сразу, а есть — когда только после запроса суммы.
К тому же, читал в одной из статей тут или на Гиктаймс, что есть банкоматы, которые проверяют PIN сразу, а есть — когда только после запроса суммы.
Да, вот та интересная ситуация: http://geektimes.ru/post/258978/#comment_8707976
Скажите, встроенная в банкоматы система видеонаблюдения работает независимо?
Да
Не согласен. Зависит таки от реализации.
Да, на что кто горазд.
Видел банк с 2000+ банкоматами, который внутрь каждого банкомата поставил по еще одному компу с USB-камерой, своей сетью и защищенным питанием. И это не потому что они дураки, а потому что так вышло дешевле, чем покупать софт у винкора.
Бывает ставят софт, который берёт событие с XFS-слоя и таким образом синхронизирует видео с транзакцией.
А бывает так, что видеонаблюдение является частью клиентского приложения и для управления, журналирования, хранения видео используется та же инфраструктура что и для транзакций.
Видел банк с 2000+ банкоматами, который внутрь каждого банкомата поставил по еще одному компу с USB-камерой, своей сетью и защищенным питанием. И это не потому что они дураки, а потому что так вышло дешевле, чем покупать софт у винкора.
Бывает ставят софт, который берёт событие с XFS-слоя и таким образом синхронизирует видео с транзакцией.
А бывает так, что видеонаблюдение является частью клиентского приложения и для управления, журналирования, хранения видео используется та же инфраструктура что и для транзакций.
Sign up to leave a comment.
Под капотом ПО банкомата