Bankir.Ru
8 декабря, четверг 09:04

Объявление

Свернуть
Пока нет объявлений.

ПОС на базе Pc с обработкой ПИН-кода

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • ПОС на базе Pc с обработкой ПИН-кода

    Известно, что построение ПОС-терминала на базе персоналки или даже просто кассового аппарата проблемы большой не составляет, но вот как быть с картами Cirrus/Maestro, которые требуют обязательного ввода ПИН-кода? Возможно кто-то знает как сделать систему с корректной обработкой ПИН-кода? Что-нибудь типа популярного ныне ПОСа на базе ПС Штрих-ФРФ + картридер + ПИН-пад?

  • #2
    А поиском попользоваться?
    Например вот нашлось: http://dom.bankir.ru/showthread.php?s=&threadid=5711
    Verba volant, scripta manent.

    Комментарий


    • #3
      Artem K спасибо за помощь. Я пробовал конечно, но ничего не увидел...

      Комментарий


      • #4
        esperantist

        Ладно. В самом деле, почему бы не высказаться ещё раз.
        Конечно можно. Но!
        1) POS на базе PC, где вся логика и хранение батчей на РС-же и реализована -- сильно не секьюрно. Любой пионер "расковыряет" и выудит треки.
        2) Как быть с сертификацией ПО на PCPOS? У нас оно необходимо для любых ККМ. Проводится оно редко и сессиями. Производители его даже слышать о изменениях не хотят.

        Тем не менее такие решения существуют. Равно как и специализорованные устройства EFTPOS/PINPAD для подключения к кассам.
        <%(

        Комментарий


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

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

          Комментарий


          • #6
            SD В ИНПАС Smart Access конвертор все о чем ты говоришь реализовано еще два года назад - вешается на кассу пин-пад, пинпад ПИН сам закрывает ключами с хоста и еще по триплдезу между кассой это закрывает, так что нигде никаких данных никто не увидит и не подставит. Прошу прощение за популистсткий стиль изложения, но я не программист.

            Комментарий


            • #7
              Smart Всё это клёво. Но номера карт где хранят и как?
              Ростислав.
              Нам и карты в руки!

              Комментарий


              • #8
                Smart
                Я про другое. Организационно сложно доработать кассовый софт на месте. Допустим там, где про Инпас и не слышали. И кардридер не видели. Поэтому должен быть разработан интерфейс для стыковки приложения с дорабатываемой на месте частью. В одном из вариантов - Инпассовским.

                Комментарий


                • #9
                  Проблема еще в следущем - производителей кассового софта много разного. Разработчиков авторизующей части тоже много. Если не выработать единый интерфейс - подобные вопросы адаптации кассы на месте будут чреваты проблемами.

                  Комментарий


                  • #10
                    SD

                    Производители кассового софта не хотят. Совсем не хотят. Даже слышать об этом.
                    Кстати, POS/PINPAD единое устройство и стоит не сильно дороже навороченного пинпада с ридерами.
                    <%(

                    Комментарий


                    • #11
                      ПОС c PinPad (работающий) реализован в Сбербанке. В качестве клавиатур применены Verifone PinPad 1000, но более массово - Verifone SC-552.

                      Комментарий


                      • #12
                        SD Ну благодаря стараниям USC протокол обмена кассы с авторизационной частью (ABG) известен и реализован очень на многих кассах, но принять его стандартом думаю тяжеловато, может еще какие авторские права задеты. Но скажем можно разработать какой-нить протокол обмена кассы с авторизационным сервером и принять его в качестве стандарта, чтоб потом на кассе уже ничего не доделывать (хотя и доделать там это не проблема, потмоу что в фискальную часть это не вмешивается). Разработать протокол обмена кассы с Пин-падом и принять его стандартом будет уже сложнее, я так понимаю у каждого пин-пада уже существуют ньюансы да и потом тоже ведб можно будет пин-пад и для лоялти использовать, шифровать на разных ключах, вобщем там больше операций может быть и спрогнозировать их может быть сложно. Но вообще тема неплохая, постепенно просто посы скорее всего будут отходить, потому как кассовые машины уже достаточно умны, сильны и злопамятны, им может подуматься, что они лучше посов EFT и что нужно гнать из торговли спец устройства, а нужно все унифицировать.
                        aakos Мы за СБЕР всегда очень рады, но только к чему вы тут об этом
                        ?

                        Комментарий


                        • #13
                          Уважаемый Smart!
                          Мы тут к тому об этом, что Сбер кроме СБЕРКАРТ на том ПОсе обслуживает и Цитрус с Маестрой (в т.ч и с вводом ПИН-кода). Т.е. на Ваши теоретические знания есть наши практические.
                          Т.е. ответ на стартовый вопрос - возможно, и давно работает
                          (извините, товарищи, это из другой темы - но Сбербанк не только задницы всем подтирает, но иногда и носы утирает)

                          Комментарий


                          • #14
                            Но вообще тема неплохая, постепенно просто посы скорее всего будут отходить, потому как кассовые машины уже достаточно умны, сильны и злопамятны, им может подуматься, что они лучше посов EFT и что нужно гнать из торговли спец устройства, а нужно все унифицировать
                            ... но пока этого нет, и будет не скоро, и будет ли вообще (?), поэтому используются различные решения, как правило на базе ПИН-падов, желательно программируемых, и желательно с сртифицированными EMV-библиотеками, дабы казусов разных не было.
                            Короче кассы сами по себе смогут выполнять функции ПОСов только тогда, когда разработчики этих самых касс начнут инвестировать в разработку столько же, сколько разработчики ПОСов, а не только укомплектовывать кассы ридерами

                            Комментарий


                            • #15
                              Тут уже была похожая тема. Я там уже говорил, что есть специальный ECR сервис - когда терминал работает, как приставка к ККМ. То есть сумма пересылается на терминал автоматически и т.д.

                              А PINPADов с сертифицированными EMV приложениями я пока не видел.

                              Кроме того, во многих странах в небольших магазинах вообще нет касс...
                              Ростислав.
                              Нам и карты в руки!

                              Комментарий


                              • #16
                                Тут уже была похожая тема. Я там уже говорил, что есть специальный ECR сервис - когда терминал работает, как приставка к ККМ. То есть сумма пересылается на терминал автоматически и т.д.

                                А PINPADов с сертифицированными EMV приложениями я пока не видел

                                Ну вот! да уже бог знает сколько это работает! Например SC 552 - софт ИНПАСа еще год назад сертифицирован, и подобные вещи с ККМ давно делаются

                                Комментарий


                                • #17
                                  VMS
                                  Не понял, чего не хотят производители кассового софта. Когда мы предлагали удобный вариант стыковки - коворили - "замечательно!" Но потом затухало по причине отсутствия здоровой доли энтузиазма - кто платить будет за сделанную работу, тем более в случае, когда клиент сначала купил кассы, а потом пришел с вопросом "можете подключить?" И кто, если не мы убедим в необходимости принятия единого интерфейса стыковки?

                                  Smart
                                  Ну благодаря стараниям USC протокол обмена кассы
                                  Есть мнение, что стандартизировать какой-то конкретный протокол файлового обмена касс с авторизатором есть, хм... не есть рулез. Я, например, хочу ходить к модулю авторизации по ipx. И предлагаемое нами решение позволяет поставить на кассу любой вариант части авторизатора, т.к. предлагаемое нами решение разделяет функции кассы и функции софта конечного разработчика авторизующей кассы. К примеру, для касс под win32 это может быть реализовано в виде dll, с которой ПО кассы работает примерно следущим образом (здоровую критику с предложениями - на мыло, нездоровую - в кранчер)

                                  Есть софт кассы и есть dll ПЦ, с которой софт работает.
                                  У dll есть три функции
                                  - установить параметр с именем long CARD_SETPARM (char *name, char *valueptr);
                                  - запросить параметр с именем long CARD_GETPARM (char *name, char *buffer);
                                  - вызвать функцию с именем long CARD_PROCESS (char *optype);
                                  Все значения и имена параметров и функции имеют asciiz представление во избежание ньюансов выравнивания данных в структурах (через которые также можно реализовать обмен).

                                  Краткий пример запроса на авторизацию карты:
                                  CARD_PROCESS ("BEGIN"); - подготовить dll к новой операции - проинициализировать все, что ей надо.
                                  Если софт кассы умеет читать карту, то касса запрашивает проведение карты и заполняет поле
                                  CARD_SETPARM ("CARDTRACK2", "....."); или иное - для чиповых решений.
                                  Вызывает функцию авторизации
                                  CARD_PROCESS ("PURCHASE");
                                  Dll - если ей не был задан CARDTRACK2, то dll известным ей способом запрашивает данные карты.
                                  Также dll сама осуществляет запрос на ввод дополнительных данных - например, пинблок через
                                  известный dll пинпад. Проводит запрос на авторизацию известным dll способом, заполняет
                                  поля ответа и требуемые данным ПЦ строки чека.
                                  Касса запрашивает результат выполнения запроса
                                  CARD_GETPARM ("RESULT", result) OK, NOK
                                  Касса запрашивает текстовое сообщение результата
                                  CARD_GETPARM ("MESSAGE", result), отображает результат на экран.
                                  В случае RESULT == OK
                                  В цикле запрашивает строки, которые по правилам ПЦ (ПС) необходимо добавить на чек
                                  Завершает работу запроса:
                                  CARD_PROCESS ("COMPLETE");

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

                                  Комментарий


                                  • #18
                                    Сложно. Ни слова не сказано про обработку ошибок. Гораздо проще сформировать пакет
                                    (XML или нет не важно) открыл сокет, отдал авторизатору, считал результат и вперед.
                                    И кстати - писать авторизационный хост под Win32 очень накладно и неудобно.

                                    Комментарий


                                    • #19
                                      yrat
                                      Сложно.
                                      Предложите проще, универсальней, лучше отделяющий то, что должен уметь делать софт кассы и то что умеет делать софт конкретного ПЦ.

                                      Ни слова не сказано про обработку ошибок.
                                      Ключевое слово, специально выделенное жирным шрифтом "ПРИМЕРНЫЙ"

                                      Гораздо проще сформировать пакет (XML или нет не важно) открыл сокет, отдал авторизатору, считал результат и вперед.
                                      И кстати - писать авторизационный хост под Win32 очень накладно и неудобно.

                                      Кто о чем а.... Я говорю про кассы и софт, который стоит на кассах. Обычно это DOS и задачи под DOS, что сильно осложняет жизнь. Также есть кассы под Win32. Главная проблема кассового софта - он как правило не умеет ходить с запросом к авторизатору, или умеет, но недостаточным образом, чтобы его модифицировать - требуется участие разработчиков кассового софта. Мы предлагаем решение, за которое не надо платить, которого можно придерживаться и с помощью которого можно элементарно дорабатывать возможности кассы по процедуре приема (с пинпадом или без), на конкретное взаимодействие с авторизатором в локальной сети на месте. В результате разработчика кассового софта не заботит процедура приема карты и процесс авторизации, а конкретный потребитель может легко поставить свое решение на новые кассы, поддерживающие данный интерфейс. Читая Вас можно подумать, что все кассы умеют формировать XML (или неважно?! - это как) и все авторизаторы умеют это неважно сформированное понимать

                                      И кстати - писать авторизационный хост под Win32 очень накладно и неудобно.
                                      Да-да. Конструкция if-else под win32 более громоздкая и неудобная.

                                      Комментарий


                                      • #20
                                        Предложите проще, универсальней, лучше отделяющий то,
                                        Бывает или проще или универсальнее ;-)) Метод последовательного добавления
                                        атрибутов имеет ряд недостатков: 1) если один из атрибутов добавить не удалось, система попадает в нестабильное состояние 2) Нет глобальной информации о структуре- те нужно синхронизировать количество, вид и порядок параметров на обеих сторонах протокола. Вариант когда касса сложила все что она знает про карточку в пакет и отдала Хосту, а Хост взял оттуда то что ему надо мне кажется надежнее.

                                        Главная проблема кассового софта - он как правило не умеет ходить с запросом к авторизатору, или умеет, но недостаточным образом, чтобы его модифицировать - требуется участие разработчиков кассового софта
                                        Т.е. весь кассовый софт умеет дергать dll c описанными выше функциями?
                                        Мы предлагаем решение, за которое не надо платить,
                                        Чудес не бывает - платить все равно придется - за разработку, тестирование сопровождение.
                                        Да-да. Конструкция if-else под win32 более громоздкая и неудобная.
                                        Конструкция то такая-же . Только вот был тут один проект для буржуев. В итоге 2 (два)
                                        инженера обслуживали 600 авторизационных хостов раскиданных по всей оклахоме.
                                        Обновление софта на всех занимало 36 часов. На Win32 IMHO такое не реально.
                                        Но с этим в мыло - а то начнется флэйм.

                                        Комментарий


                                        • #21
                                          aakos Автор темы в качестве ПОС рассматривал кассовый аппарат, если такой вариант реализован у сбера, то я дико извиняюсь перед Вами, но мне показалось что Вы сказали про EFT POS , так как иначе не понятно куда можно было совать карту с микропроцессором(СБЕР) в реализациии с 1000+ пин-падом, потому я и спросил при чем тут СБЕРовский "универсальный" ПОС. Но в любом случае хамите где-нить в другом месте и свой эпистолярный жанр оттачивайте в специально для этого отведенных темах, типа "Фразы дня".

                                          SD ни слова не понял из того что ты сказал)))))))
                                          Но касса то что напрямую к хосту обращается? или к авторизационному серверочку, который потом уже с хостом болтает?
                                          Alisoman Когда терминал работает как приставка к ККМ - лучшее решение, согласен, но когда стоимость кассы 300 долларов с ПО и ежегодным обслуживанием и касса такая в магазине одна, максимум три. А если касса стоит $4500 ? Если таких касс 48 и каждая из них имеет считыватель магнитных карт? что к каждой из 48 поставить по EFT POS?
                                          Кстати, пин падом уже наверное не совсем правильно называть устройства подобные SC 552, ну может програмируемым пин-падом еще и можно....вобщем не знаю, но это практически самостоятельный POS тока без принтера и модема.

                                          Комментарий


                                          • #22
                                            48Х4500 = 216 000 $ - потратить стоко бабла и не принимать карты- обидно.
                                            Но я всё равно скажу, что проще подцепить к кассам POS терминалы со встроенными PINPADами, чем огород городить. И соединить терминалы по Ethernet с хостом. Это ещё тысяч 30, не больше. Или 14%.
                                            Ростислав.
                                            Нам и карты в руки!

                                            Комментарий


                                            • #23
                                              Smart
                                              ни слова не понял
                                              Дык - для программеров в первую голову инфа

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

                                              Alisoman
                                              POS терминалы со встроенными PINPADами, чем огород городить
                                              имхо в стоимость упирается и в доступность протокола работы с дивайсом.

                                              yrat
                                              имеет ряд недостатков:
                                              Какие именно?
                                              Описан примерный, доступный, общий алгоритм действия кассового софта. Детали здесь приводить не буду.

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

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

                                              Вариант когда касса сложила все что она знает про карточку в пакет и отдала Хосту, а Хост взял оттуда то что ему надо мне кажется надежнее.
                                              Вы не понимаете о чем я говорю. Вы говорите о стыковке кассы с хостом, а я говорю о универсальной стыковке ПО кассы с софтом, которое уже будет стыковаться с софтом. В данном случае то, что Вы пишите - это все можно завернуть в dll. Универсального формата обмена пока - нет. (Не надо говорить "есть", когда его реально нет). Вы, видимо, не имеете дело с российской действительностью. Производителей софта касс - море. 99% - файловый обмен с сервером в локальной сети. Форматы - кто во что горазд. Часта ситуация, когда касса может принимать карту только теоретически. Часто бывает так, что касса не умеет "дать хосту" то, что ему надо. Дорабатывать софт на работу с пинпадом без участия разработчиков по касс - практически невозможно. Плюс те, кто сидят на работающих процессингах вовсе не заинтересованы во внедрении новомодных фишек, когда имеющийся функционал - достаточен.

                                              На Win32 IMHO такое не реально.
                                              dll закачивает (получает) другую dll - какие проблемы?

                                              Комментарий


                                              • #24
                                                Alisoman тысяч тридцать на банк ляжет.

                                                Комментарий


                                                • #25
                                                  Smart Alisoman тысяч тридцать на банк ляжет.
                                                  А PINPADы магазин купит?
                                                  Ростислав.
                                                  Нам и карты в руки!

                                                  Комментарий


                                                  • #26
                                                    Alisoman а что дороже пинпады или терминалы?

                                                    Комментарий


                                                    • #27
                                                      Уважаемый Smart!

                                                      1) извинения по поводу Вашего недопонимания в первой итерации приняты,

                                                      2) пинпады дешевле EFT ПОС, поэтому там, где это возможно пытаемся предложить именно эти решения; вместе с тем, следует обратить внимание коллег на то, что решение "PC-POS+PinPad" получается не всегда или не настолько уж и дешевле варианта автономного POS; решающим фактором является дополнительная функциональность - ускорение за счёт перехода от авторизации по коммутируемым модемным каналам, к увторизации по кусочно-IP каналам, либо (в конце концов, и в идеале) - по "чистому" IP,

                                                      3) решения на базе SC-552 получили более широкое распространение (по отношению к PinPad-1000) по стране (кроме Москвы и Ленинграда) за счёт того, что они хотя и дороги, но универасальны (чип+полоса).

                                                      Комментарий


                                                      • #28
                                                        aakos следует обратить внимание коллег на то, что решение "PC-POS+PinPad" получается не всегда или не настолько уж и дешевле варианта автономного POS - согласен, но дело в том, что в связке PC-POS PC уже как правило есть (компьютерная касса у торговца, операционная касса банка и т.д.) Мы тут к тому об этом, что Сбер кроме СБЕРКАРТ на том ПОсе обслуживает и Цитрус с Маестрой (в т.ч и с вводом ПИН-кода). - вообще только это и послужило поводом для вопроса и мысли о том, что Вы говорите именно об EFT POS, но хамить в любом случае тут не принято)))

                                                        Комментарий


                                                        • #29
                                                          Smart
                                                          ни слова не понял
                                                          Подумав, решил написать суть предлагаемого.
                                                          Есть разные производители софта для разных касс. Ваша же задача - заставить эти кассы савторизовать запросы в вашем процессинге. Задача вашего соседа - аналогичная, но уже в его процессинге.
                                                          Практически сто процентов, что у разных производителей будут разные реализации запросов и вам и вашему соседу придется подстраиваться под них (если, конечно, производитель активно дает информацию) - как правило - делать очередной "авторизационный сервачок" Когда же встает вопрос добавить что-то непредусмотренное производителем - например пинпад - вы оказываетесь в ауте. Вот если бы производитель давал возможность дорабатывать принимающую карту ветку в своем софте - это было бы классно. Тогда вы бы доработали свою ветку, а ваш сосед - свою. Если же разные производители будут придерживаться единого подхода в работе с такой веткой, то поставить свою ветку на кассу другого производителя не составит проблемы, причем без доработки софта. Выигрыш - у вас и у производителя. Вы сами можете сделать свой вариант приема карты, обмена файлами запросов или работой с терминалом, навести своевременный апгрейд своего решения, в любой момент заменить на другое или подключить любой чужой вариант решения на выбор. Производитель же освобождается от необходимости поддерживать зоопарк решений. Вот вариант такой системы взаимодействия ПО кассы с вашей веткой я и предлагаю.

                                                          Комментарий


                                                          • #30
                                                            в связке PC-POS PC уже как правило есть Алексей, поддержу aakos в плане решение "PC-POS+PinPad" получается не всегда или не настолько уж и дешевле варианта автономного POS Вспомни вариат1. Банк в целях безопасности не выпускает трафик в сетку супермаркета, авторизация - Х.25.
                                                            2. Стоимость доработки кассовиками превышает разницу POS- PINpad в 2 раза. Тож поставили POSы.

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X