В связи с затронутой недавно темой устройства банкоматов, желании хабра узнать о них побольше, а также просто зашкаливающему количеству домыслов от такой, казалось бы, технически подкованной аудитории, я решил написать этот пост. В отличии от UserSide, который в основном занимался физическим обслуживанием банкоматов, и как мне кажется, весьма далек от тех, кто собственно пишет софт для его управления хостом, я расскажу о «той стороне». Естественно, в меру своих познаний, пока еще слишком скромных.
Так как это моя первая статья на хабре, прошу прощения за, возможно, излишнюю сумбурность.
Первое что хочу отметить — все, сказанное в статье и практически все в комментариях — правда, но правда однобокая — она описывает частные случаи. И хотя это частные случаи, в той манере, как подана информация, у неподготовленного читателя может возникнуть впечатление, что бывает только так, как было рассказано. И хотя в комментариях успело появиться несколько противоположных описаний ситуаций, никто так и не озвучил главного — все это частные случаи.
Один из форумчан, ссылаясь на свой опыт, настаивал, что к карте можно привязать любой счет (причем в любой валюте) за 5 минут, кто-то другой сомневался. Это действительно так. Возможность этой процедуры определяется только возможностями программного обеспечения самой процессинговой системы, поддержкой ее со стороны интернет/мобильного банка, желанием банка предоставлять населению такие услуги и его желанием заплатить за это дополнительную денежку разработчику системы. В системе, к разработке которой я имею отношение, карта и счет — это две разные сущности.
Карта в нашей терминологии является токеном — точно также, как токеном является, например, пароль, сертификат, документ, удостоверяющий личность и некоторые другие, сходу не вспомню. Токен служит лишь для доступа к счету. Причем, как к счету можно получить доступ через несколько токенов, так и токен может обслуживать несколько счетов. Например, в одном банке, где работает наша система, во время карточной операции вас могут попросить указать конкретный счет — если к карте их привязано несколько.
Эта фича называется «Ложный ПИН» (iPIN). То, что какой-то банк предлагает по умолчанию делать его, как основной ПИН, записанный наоборот, служит только цели более легкого его запоминания. Судя по комментариям, у меня сложилось впечатление, что не все это понимают.
Насколько я слышал от коллег, эта фича не очень востребована, т.к. имеет свои негативные стороны (не знаю, какие). Факт в том, что используется она крайне редко.
Опять же, это не непреложное правило, это сделано просто для удобства обслуживания. В нашей системе оно сделано таким образом, подозреваю, что во всех остальных так же:
При вставке такой карточки хост, вместо выполнения транзакции, запрашивает у банкомата текущие счетчики (либо приложение банкомата само может определить такую карту и самостоятельно сразу послать счетчики — о приложениях дальше). Далее происходит физическая инкассация терминала с занесением в него новых счетчиков (это делается вручную, но я краем уха слышал, что возможно и автоматическое занесение по опросу кассет… но мне кажется, сейчас это редко где есть). После закрытия банкомата дверца придавливает специальную кнопку, называемой кнопкой супервизора, и банкомат рапортует в сеть как минимум, что изменилось состояние сенсора «режим супервизора», как максимум — свое полное состояние, в том числе и новые счетчики (а может еще и старые — см. в главе про приложения). Если рапорт содержит информацию только о сенсоре, то хост самостоятельно запрашивает счетчики. В этот момент хост может сравнить новые счетчики со старыми и создать транзакцию инкассации. Опять же, повторюсь, так это работает у нас, но это не значит, что так работает везде. Но так как схема очень гибкая и автономная, то используется наверняка почти в любом программном продукте такого рода.
Вместо карточки команду на начальный опрос счетчиков (перед переводом банкомата в режим супервизора для инкассации) могут дать и из хоста. Инкассация в таком случае может выглядеть так: инкассаторы прибывают на место, звонят в процессинговый центр, оператор выполняет команду через систему, далее все как в первом сценарии.
Тут надо отметить, что все приложения можно разделить на 2 вида:
Самое же главное, что отличает эти схемы взаимодействия хоста с банкоматом является то, какая сторона хранит промежуточные данные до тех пор, пока не сможет сформироваться полноценная транзакция. Это может произойти, например, в том случае, когда к карте привязано 2 и более счетов — т.к. сценарий взаимодействия не знает количество счетов заранее, он просто формирует запрос транзакции и отсылает ее на хост. Хост ее отклоняет с причиной «Необходимо уточнение» и присылает список параметров, которые необходимо уточнить. И тут возможно два варианта:
Поведение при обнаружении не забранной карты полностью настраивается — банкомат может как захватить ее, так и оставить в тракте. Тоже самое относится к выдаче карты до/после денег, в начале/конце работы, при отключении электричества (если банк не совсем бедный, в банкомате должен быть ИБП). Что делать, если введен неверный ПИН-код, введен ложный ПИН (если есть), когда обнуляется счетчик неверных ПИН, нужен ли захват карты — все решает хост. Если хост не проинструктирует банкомат захватить карту, он ее не захватит, будь она хоть десять раз фальшивая, украденная и потерянная.
Что делать с чиповыми картами, если не удалось прочитать чип — зависит от настроек сценария. Может предлагаться более узкий круг услуг, а может просто отказать обслуживать. Тоже самое касается карт других банков.
Какой алгоритм выдачи использовать и откуда банкомат его узнает — опять же, полностью зависит от настройки. Конечно, сейчас, в эпоху повального интернета, хосту выгоднее самому выполнять все расчеты, а банкомату только выдавать команды. Однако, например, Kaliginte-объект для управления CashDispenser-ом (устройством выдачи наличных) также умеет рассчитывать покупюрную сумму выдачи по разным алгоритмам. В нашей системе мы не используем эту возможность. Опять же, позволять пользователю выбрать алгоритм выдачи, или, как кто-то говорил в комментариях, даже конкретные номиналы купюр — целиком и полностью зависит от желания банка создать такой сценарий (ну и от возможностей ПО, конечно же).
Ограничение в 40 купюр действительно идет от физических ограничений — пачка из 40 банкнот почти в сантиметр толщиной. Про то, что банкомат просто откажет выдавать сумму, которая не сможет быть физически выдана за раз, с невразумительной ошибкой — вина разработчика сценария — что не предусмотрел внятного сообщения о причине. С Kalignite-ом все вообще просто, это обычный HTML, как я уже выше говорил, фактически локальный сайт, а для NDC/DDC банкоматов ответ хоста может содержать обновленные экраны, текст на которых, опять же, определяет хост… Протокол Triton-а победнее, да и кодов ошибок у него мало, но Triton-ы в России, кажется, не очень распространены.
На тех, на которых мне доводилось тестироваться, стоит Windows XP. А тестировался я с Kalignite-овским сценарием, с NDC и DDC банкоматами.
Ну вот. Надеюсь, было интересно и хаоса в головах поубавилось. Основная мысль, которую я хотел донести — настраивается абсолютно ВСЕ. Естественно, где-то меньше, где-то больше, но это больше касается уже более глубоких нюансов, чем те, что видны с первого взгляда.
Так как это моя первая статья на хабре, прошу прощения за, возможно, излишнюю сумбурность.
Первое что хочу отметить — все, сказанное в статье и практически все в комментариях — правда, но правда однобокая — она описывает частные случаи. И хотя это частные случаи, в той манере, как подана информация, у неподготовленного читателя может возникнуть впечатление, что бывает только так, как было рассказано. И хотя в комментариях успело появиться несколько противоположных описаний ситуаций, никто так и не озвучил главного — все это частные случаи.
1. Карты и счета
Один из форумчан, ссылаясь на свой опыт, настаивал, что к карте можно привязать любой счет (причем в любой валюте) за 5 минут, кто-то другой сомневался. Это действительно так. Возможность этой процедуры определяется только возможностями программного обеспечения самой процессинговой системы, поддержкой ее со стороны интернет/мобильного банка, желанием банка предоставлять населению такие услуги и его желанием заплатить за это дополнительную денежку разработчику системы. В системе, к разработке которой я имею отношение, карта и счет — это две разные сущности.
Карта в нашей терминологии является токеном — точно также, как токеном является, например, пароль, сертификат, документ, удостоверяющий личность и некоторые другие, сходу не вспомню. Токен служит лишь для доступа к счету. Причем, как к счету можно получить доступ через несколько токенов, так и токен может обслуживать несколько счетов. Например, в одном банке, где работает наша система, во время карточной операции вас могут попросить указать конкретный счет — если к карте их привязано несколько.
2. ПИН наоборот для мошенников
Эта фича называется «Ложный ПИН» (iPIN). То, что какой-то банк предлагает по умолчанию делать его, как основной ПИН, записанный наоборот, служит только цели более легкого его запоминания. Судя по комментариям, у меня сложилось впечатление, что не все это понимают.
Насколько я слышал от коллег, эта фича не очень востребована, т.к. имеет свои негативные стороны (не знаю, какие). Факт в том, что используется она крайне редко.
3. Карточки инкассаторов/супервизоров
Опять же, это не непреложное правило, это сделано просто для удобства обслуживания. В нашей системе оно сделано таким образом, подозреваю, что во всех остальных так же:
При вставке такой карточки хост, вместо выполнения транзакции, запрашивает у банкомата текущие счетчики (либо приложение банкомата само может определить такую карту и самостоятельно сразу послать счетчики — о приложениях дальше). Далее происходит физическая инкассация терминала с занесением в него новых счетчиков (это делается вручную, но я краем уха слышал, что возможно и автоматическое занесение по опросу кассет… но мне кажется, сейчас это редко где есть). После закрытия банкомата дверца придавливает специальную кнопку, называемой кнопкой супервизора, и банкомат рапортует в сеть как минимум, что изменилось состояние сенсора «режим супервизора», как максимум — свое полное состояние, в том числе и новые счетчики (а может еще и старые — см. в главе про приложения). Если рапорт содержит информацию только о сенсоре, то хост самостоятельно запрашивает счетчики. В этот момент хост может сравнить новые счетчики со старыми и создать транзакцию инкассации. Опять же, повторюсь, так это работает у нас, но это не значит, что так работает везде. Но так как схема очень гибкая и автономная, то используется наверняка почти в любом программном продукте такого рода.
Вместо карточки команду на начальный опрос счетчиков (перед переводом банкомата в режим супервизора для инкассации) могут дать и из хоста. Инкассация в таком случае может выглядеть так: инкассаторы прибывают на место, звонят в процессинговый центр, оператор выполняет команду через систему, далее все как в первом сценарии.
4. Приложение на банкомате
Тут надо отметить, что все приложения можно разделить на 2 вида:
- протокол обмена жестко определен, на стороне банкомата выполняется программа, работающая по этому протоколу и расширить ее никак нельзя. Это, например, NDC, DDC и Triton.
- протокол обмена не только жестко не закреплен, но наоборот, приложение на банкомате является расширяемым плагином для поддержки общения с конкретным хостом. Так устроены банкоматы Kalignite — кстати, наиболее гибкие из тех, с которыми мне довелось работать. Приложение Kalignite — это обычное .Net приложение, показываемые на экране банкомата экраны — обычные HTML-странички, отображаемые через стандартный .Net компонент браузера (который, в свою очередь, основан на ядре IE, т.е. имеет все его уязвимости. Однако сам компонент сильно урезан). Благодаря этому разработкой визуальной части сценария могут заниматься веб-дизайнеры и пользоваться всеми благами — например, jQuery, виртуальной клавиатурой и всем, чего душа пожелает.
Так как на банкомате работает код, который пишется самим разработчиком системы, то выполнение всяких сервисных функций может заметно упроститься — например, транзакцию инкассации можно сформировать на самом банкомате, и переслать ее на хост, как обычный запрос транзакции (только это будет административная транзакция).
Самое же главное, что отличает эти схемы взаимодействия хоста с банкоматом является то, какая сторона хранит промежуточные данные до тех пор, пока не сможет сформироваться полноценная транзакция. Это может произойти, например, в том случае, когда к карте привязано 2 и более счетов — т.к. сценарий взаимодействия не знает количество счетов заранее, он просто формирует запрос транзакции и отсылает ее на хост. Хост ее отклоняет с причиной «Необходимо уточнение» и присылает список параметров, которые необходимо уточнить. И тут возможно два варианта:
- терминал присылает только уточненные параметры — в таком случае, хост должен где-то хранить информацию, которую банкомат прислал в предыдущем запросе — банкомат stateless, хост statefull — так ведут себя все банкоматные программы с жестко закрепленным протоколом (NDC/DDC, Triton и другие), т.к. протокол не предусматривает места для хранения этих данных;
- терминал присылает все прошлые данные плюс уточненные параметры — банкомат statefull, хост stateless. Так лучше делать при работе с Kalignite, т.к. все равно нужно (желательно) написать свое расширение для взаимодействия по удобному хосту протоколу.
5. Изъятие карт и неверные ПИНы
Поведение при обнаружении не забранной карты полностью настраивается — банкомат может как захватить ее, так и оставить в тракте. Тоже самое относится к выдаче карты до/после денег, в начале/конце работы, при отключении электричества (если банк не совсем бедный, в банкомате должен быть ИБП). Что делать, если введен неверный ПИН-код, введен ложный ПИН (если есть), когда обнуляется счетчик неверных ПИН, нужен ли захват карты — все решает хост. Если хост не проинструктирует банкомат захватить карту, он ее не захватит, будь она хоть десять раз фальшивая, украденная и потерянная.
6. Чиповые карты
Что делать с чиповыми картами, если не удалось прочитать чип — зависит от настроек сценария. Может предлагаться более узкий круг услуг, а может просто отказать обслуживать. Тоже самое касается карт других банков.
7. Максимум в 40 купюр для выдачи и алгоритм выдачи
Какой алгоритм выдачи использовать и откуда банкомат его узнает — опять же, полностью зависит от настройки. Конечно, сейчас, в эпоху повального интернета, хосту выгоднее самому выполнять все расчеты, а банкомату только выдавать команды. Однако, например, Kaliginte-объект для управления CashDispenser-ом (устройством выдачи наличных) также умеет рассчитывать покупюрную сумму выдачи по разным алгоритмам. В нашей системе мы не используем эту возможность. Опять же, позволять пользователю выбрать алгоритм выдачи, или, как кто-то говорил в комментариях, даже конкретные номиналы купюр — целиком и полностью зависит от желания банка создать такой сценарий (ну и от возможностей ПО, конечно же).
Ограничение в 40 купюр действительно идет от физических ограничений — пачка из 40 банкнот почти в сантиметр толщиной. Про то, что банкомат просто откажет выдавать сумму, которая не сможет быть физически выдана за раз, с невразумительной ошибкой — вина разработчика сценария — что не предусмотрел внятного сообщения о причине. С Kalignite-ом все вообще просто, это обычный HTML, как я уже выше говорил, фактически локальный сайт, а для NDC/DDC банкоматов ответ хоста может содержать обновленные экраны, текст на которых, опять же, определяет хост… Протокол Triton-а победнее, да и кодов ошибок у него мало, но Triton-ы в России, кажется, не очень распространены.
8. Операционная система
На тех, на которых мне доводилось тестироваться, стоит Windows XP. А тестировался я с Kalignite-овским сценарием, с NDC и DDC банкоматами.
Ну вот. Надеюсь, было интересно и хаоса в головах поубавилось. Основная мысль, которую я хотел донести — настраивается абсолютно ВСЕ. Естественно, где-то меньше, где-то больше, но это больше касается уже более глубоких нюансов, чем те, что видны с первого взгляда.
