Доброе утро, уважаемый посетитель 18-97-9-170.crawl.commoncrawl.org - istcom.spb.ru с IP-адреса 18.97.9.170!
Мы рады приветствовать Вас на нашем сайте и предлагаем Вам посетить его разделы:

Реквизиты компании

ПЛАТЕЖНЫЕ ТЕРМИНАЛЫ САМООБСЛУЖИВАНИЯ.
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ «СОЛО АТМ»®.
ВЫБОР СТАНДАРТА NDC/NDC+®

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

Перспективность и возможность существенного снижения уровня защиты для оборудования продемонстрировало длительное широкое использование торговых автоматов: от всем нам памятных автоматов по продаже газировки по 1 и 3 коп. до современных автоматов по продаже напитков, шоколадных батончиков и прочих штучных товаров. Значительная разница в стоимости терминала самообслуживания и банкомата позволяет поставить десяток терминалов по цене одного банкомата. Такая ситуация не могла не вдохновить предпринимателей на построение сетей по приему и обработке платежей от населения.

Однако ситуация сложилась таким образом, что инициатива пошла не от прямо заинтересованных кредитных организаций и организаций, реализующих услуги населению, имевших на начало этого процесса и так неплохую доходность и не нуждавшихся в дополнительных рисках, а путем создания посреднических структур между банками и предприятиями сферы услуг. Посреднические структуры, в поисках своего «места под солнцем», вынуждены были дублировать функции банковского процессинга по управлению сетью терминалов и обработке принимаемых от терминалов данных для превращения их в понятные для банка проводки. Вдобавок идеология построения таких систем приема платежей шла, скорее всего, от сетей торговых автоматов, а не от банкоматных сетей, что не могло не оставить свой «неизгладимый» след в принципах, структуре функционирования и интерфейсах возникших платежных систем. Разработчики появившихся сетей по приему платежей скорее пользовались своими знаниями в области стандартов электронной коммерции, нежели пытались их соблюдать. Сформировавшиеся и работающие на сегодняшний день платежные системы оказались «закрытыми»: несовместимыми не только по интерфейсам Front <=> BackOffice, но и по внешним интерфейсам. Такие системы работают только «в руках владельца» и для изменения и добавления каких-либо функций требуется участие разработчика.

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

1. погашение банковских кредитов с идентификацией по карте;
2. пополнение карточного счета;
3. карточные платежи в пользу третьих лиц;
4. свободные бескарточные платежи;
5. мониторинг состояния терминалов,

мы внимательно изучили опыт наших предшественников и обнаружили три серьезных препятствия:

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

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

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

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

Пересмотрев множество вариантов, мы выбрали банкоматный стандарт NDC. Протокол NDC/NDC+ одновременно сложен и прост для реализации. Сложен, потому что его описание представляет собой несколько книг в среднем по 800 страниц, которые необходимо реализовать в программном коде, а прост, поскольку не допускает никаких фантазий программиста в правилах функционирования и форматов передачи данных. Что нас привлекло в первую очередь:

1. В стандарте предусмотрено определение полей плательщика и получателя и других возможных дополнительных полей в прогружаемой конфигурации.
2. Предусмотрен и подробно описан мониторинг устройств в сети.
3. Идеология стандарта представляет оконечное устройство как автомат состояний (ATM – Automation Teller Machine), а это означает, что сам терминал практически ничего не может... разве что сказать «я в сети и готов получать задания» и «задание получил – тружусь». На экране терминала можно увидеть только то, что он получил с хост-централа: и картинки работы «неизвестного дизайнера», и порядок смены экранов в зависимости от действий пользователя.

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

• Если в банке есть банкоматный процессинг (хотя бы один банкомат) терминал подключается без каких-либо доработок или изменений в процессинге.
• Конфигурации терминала создаются стандартными «эндисишными» генераторами скриптов, хотя можно и вручную, в соответствии со стандартом, а это позволяет изменять функции терминала быстро и не обращаясь за помощью к тем же разработчикам.
• Терминал с NDC-совместимым ПО обладает существенно большей ликвидностью – он СТАНДАРТНЫЙ и «встанет» в любую банкоматную сеть, он не является «вещью в себе», которая работает только в присутствии разработчика!
• Банк имеет полную свободу при его эксплуатации – всё в РАМКАХ СТАНДАРТА и, в общем случае, при эксплуатации такого терминала помощь разработчика не требуется!

Программное обеспечение написано на Си под Debian GNU/Linux, этот выбор продиктован желанием минимизировать зависимость качества разрабатываемого программного обеспечения от всевозможных ошибок и «дыр» в операционной системе и системных библиотеках. Во всех случаях неадекватного поведения оборудования и ПО наличие исходного кода и «ручная сборка» позволяет найти источник некорректного поведения и предпринять соответствующие меры по исправлению либо обходу ошибки. Мы можем самостоятельно помочь эксплуатирующей организации всегда, не ссылаясь на производителей драйверов, компиляторов, библиотек и операционных систем. Такой подход, безусловно, требует внимательного изучения каждого функционального элемента платежных терминалов и серьезных затрат времени при обновлении комплектации терминала, но с лихвой окупается низкой ценой владения для покупателя – программное обеспечение годами работает без вмешательства сервисной службы.

Наше ПО «СОЛО АТМ» работает в Альянс Банке (Республика Казахстан) на терминалах ОАО СКБ ВТ «ИСКРА» и в МЕТКОМБАНКе (Россия) на терминалах ООО «ТехноПром Групп».

В. А. Родин,
генеральный директор
ООО „ИСТКом“,
Санкт-Петербург