19 октября, пятница 02:21
Bankir.Ru

Объявление

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

Работа процессингового центра и..

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

  • Работа процессингового центра и..

    Добрый день,Уважаемые!
    Меня интересует такой вопрос как происходят расчеты по "пластикам".С того момента как картой расплатились.Что происходит тогда....какая просходит цепочка. Если возможно ссылками или авторами книг.
    Юлия.

  • #2
    Мерчант - Эквайер - ПС - Банк Эмитент - ПС - Эквайер - Мерчант.
    Наша жизнь состоит из цитат. Лишь немногим удается написать что-то своё. (с)

    Комментарий


    • #3
      Вот модель для интернет платежей.

      3D - THREE DOMAIN MODEL (МОДЕЛЬ “ТРЕХ ДОМЕНОВ”)

      Сразу же следует заметить, что модель “трех доменов” содержит в себе два частных случая: т. е. модель 3D SET и модель 3D SSL. В начале будет рассмотрена общая концепция данной модели, после чего будут коротко описаны две вышеупомянутых модели 3D SET и 3D SSL.

      Итак, в конце лета 2000 года, крупнейшая компания VISA объявила о своей поддержке модели «трех доменов» (Three Domain Model), далее 3D, мы не будем останавливаться на каких-либо исторических и т. п. моментах, а перейдем сразу же к сути.

      Главная идея в том, что весь процесс аутентификации, обеспечивающий безопасность транзакций, разбивается на три домена (или другими словами области):

      - Issuer Domain;

      - Acquirer Domain;

      - Interoperability Domain;



      Рассмотрим назначение каждого выше упомянутого домена:

      Issuer Domain – его назначение заключается в том, что обслуживающий банк производит аутентификацию своей торговой точки на основе правил и методов, установленных самим обслуживающим банком (т. е. в этом случае вся ответственность за аутентификацию ложиться на обслуживающий банк торговой точки);

      Acquirer Domain – его назначение в том, чтобы определить правила и процедуры обмена информацией между доменами Issuer Domain и Acquirer Domain, гарантирующие этим доменам взаимную аутентификацию друг друга (как видим, идея состоит в том, чтобы сделать систему самодостаточной);

      Владелец карты находится в домене Issuer, а торговое предприятие находится в домене Acquirer, которые в свою очередь взаимодействуют между собой (клиент -> торговая точка) через домен Interoperability.

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

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

      Отсюда вытекает следующий вывод, что главным и очевидным преимуществом рассматриваемой нами модели, является, то, что эмитент получает возможность производить аутентификацию своего клиента любым удобным ему способом (могут применяться методы, которые уже применяются банком в электронном бэнкинге) или, например, с помощью PKI-приложения на смарт-картах, кстати давайте ненадолго отвлечемся от модели трех доменов и рассмотрим, кое-что из ноу-хау в электронном бизнесе, а именно: «недавно компания Europay предложила новую оригинальную технологию аутентификации владельца карты, внедрив приложение Wireless Public Key Infrastructure (WPKI) в SIM-карте мобильного телефона. Суть идеи состоит в том, что после того как клиент обратился к серверу своего эмитента для инициализации SET-транзакции, последний организует передачу на мобильный телефон владельца карты SMS-сообщение, содержащее описание товаров, заказанных клиентом. Если клиент согласен с содержимым перечня товаров, он его подтверждает. В результате полученное SMS-сообщение подписывается ключом владельца карты и возвращается на сервер эмитента, т. е. как видим процесс аутентификации производится посредством мобильного телефона, сегодня такая тенденция развивается и вливается в новое направление электронного бизнеса – мобильная коммерция – m-commerce».

      Вернемся к модели трех доменов, далее будут рассмотрены два частных случая модели трех доменов: 3D SET и 3D SSL.



      - 3D SET

      Суть модели 3D SET состоит в том, что взаимодействие между доменами эмитента и обслуживающего банка, осуществляется через протокол SET. На практике, это означает, что в Issuer Domain реализуется концепция «тонкого кошелька» с использованием Issuer Server Wallet, главной задачей которого является, осуществление аутентификации клиента по некоторому своему алгоритму и далее направляет в Acquirer Domain сообщения, подтверждающие аутентификацию клиента в формате сообщений протокола SET. Т.е. в данном случае отпадает необходимость передачи сертификатов ключей клиентов самим клиентам, что в свою очередь повышает производительность системы в целом.

      С точки зрения торговой точки, модель 3D SET позволяет ей выполнить транзакцию с использованием независимого платежного сервера (POS-сервер).



      - 3D SSL

      Эта модель отличается от 3D SET тем, что в области Interoperability Domain вместо протокола SET используется обычный SSL протокол, что на практике выражается в следующем, после завершения банком эмитентом процедуры аутентификации своего клиента банк-эмитент подписывает запрос клиента своим секретным ключом и передает в Acquirer Domain тем самым эмитент подтверждает результат аутентификации клиента.

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

      Так как используется протокол SSL (обладающий более быстрыми операционными показателями нежели SET) преимущества 3D SSL очевидны. Клиенту достаточно использовать обычный браузер для реализации транзакции, при этом на сервере эмитента Issuer Server не требуется хранение (и тем более распространение) сертификатов ключей клиентов банка. В связи с этим внедрение подобной модели является чрезвычайно простым в сравнении с процедурой внедрения модели 3D SET. В то же время, модель 3D SSL имеет и очевидные недостатки – не обеспечивается конфиденциальность данных о реквизитах карты клиента по отношению к торговой точке, т. е. главный аспект безопасности транзакций, что в свою очередь должно оказывать (негативное) воздействие на любую платежную систему, выбирающую модель безопасности для обеспечения надежности и конфиденциальности транзакций. Очевидно, что компании сами должны решить для себя - выбор: безопасность или хорошие операционные показатели.



      МОДЕЛЬ 3D SECURE

      В мае 2001 года были опубликованы спецификации стандарта 3D Secure, исторически (и политически) сложилось так, что данный стандарт претендует на роль глобального стандарта аутентификации в платежной системе VISA. Нужно заметить, что данный стандарт базируется на концепции трех доменов (см. выше), но во всем остальном, это две разные модели.

      Рассмотрим схему транзакции по данной модели. После того, как владелец карты подтвердил торговой точке свою готовность произвести покупку и посредством SSL-сессии передал торговой точке реквизиты карты, приложение торговой точки инициирует специальное ПО, устанавливаемое на сервере торговой точки и называемое Merchant Plug-In.

      ПО Merchant Plug-In обращается к серверу платежной системы (Directory) с запросом на проверку поддержки владельцем карты протокола 3D Secure. Данный запрос содержит номер карты, идентификатор торговой точки ее пароль. Сервер Directory по идентификатору торговой точки проверяет наличие данной торговой точки в базе данных интернет-магазинов, поддерживающих протокол 3D Secure. Кроме того, в случае использования пароля торговой точки, производится ее идентификация. После этого сервер Directory по номеру карты покупателя определяет ее принадлежность к диапазону карт, поддерживающих протокол 3D Secure, а также URL сервера эмитента карты, называемого Aсcess Control Server (ACS), и передает по этому адресу запрос на поддержку данной конкретной картой протокола 3D Secure. Сервер ACS проверяет поддержку владельцем карты протокола 3D Secure и результат проверки через Directory сообщает ПО Merchant Plug-In.

      Взаимодействие Merchant Plug-In – Directory и Directory – ACS происходит по защищенным ssl-сессиям с использованием ssl-сертификатов, выданных Root Certificate Authority, что в свою очередь обеспечивает не только конфиденциальность передаваемых данных, но и что крайне важно – взаимную аутентификацию участников транзакции.

      Если в результате проверки на ACS карта покупателя поддерживает 3D Secure, то Merchant Plug-In формирует запрос на аутентификацию владельца карты. Данный запрос содержит информацию о сумме покупки, торговой точке, специальный идентификатор владельца каты (Account ID), поддерживаемый на сервере ACS, URL торговой точки и передается на сервер ACS, через браузер покупателя с одновременной переадресацией владельца карты на сервер ACS.

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

      После успешного завершения аутентификации клиента, сервер ACS подготавливает ответ, подписанный на ключе эмитента. Подпись эмитента используется для решения проблемы потенциального отказа владельца карты от результатов транзакции. Ответ передается на сервер обслуживающего банка с одновременным переключением клиента на этот же сервер. Результат аутентификации передается ACS также на сервер Directory, который выступает в роли третейского судьи в случае возникновения диспута по поводу транзакции. Merchant Plug-In проверяет подпись эмитента и формирует стандартный авторизационный запрос для передачи его в платежную сеть.

      Из всего выше сказанного по данной модели следует, что модель 3D Secure удовлетворяет основным требованиям безопасности, предъявляемым к электронной коммерции. В частности, решается проблема аутентификации участника транзакции, отказа от транзакции и т. п. И в тоже время, говорить о модели 3D Secure как об устойчивой невозможно, поскольку он определяет только часть процесса обработки транзакции (Interoperability Domain), оставляя протоколы в доменах Issuer и Acquirer на выбор соответственно эмитента и обслуживающего банка.

      У модели 3D Secure имеются следующие очевидные достоинства:

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

      2. Резко упрощается процедура сертификации, так как используется одноуровневая система центров сертификации.

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

      4. ПО устанавливаемое на стороне обслуживающего банка и банка-эмитента, гораздо проще по своей функциональности и поэтому существенно дешевле, нежели ПО реализующее протокол SET.



      Используемый материал:

      1. Visa Security Standards for e-Commerce Payments

      2. И. Голдовский «Безопасность платежей в Интернете»

      3. Дэвид Козье «Электронная коммерция»
      Наша жизнь состоит из цитат. Лишь немногим удается написать что-то своё. (с)

      Комментарий


      • #4
        Юля Кремлевская.
        полистай историю на страницах форума

        Комментарий


        • #5
          ValentineS
          спасибо))
          а где бы это поподробней почитать,?

          Комментарий


          • #6
            LIBORDCN
            хм.....))
            не нашла,честно говоря

            Комментарий


            • #7
              Юлия_кремлин

              http://dit.perm.ru/articles/management/tmp/01/index.htm

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

              А вот что интересует Вас.

              Создание и функционирование системы взаимообмена.

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

              Важной компонентой взаимообмена является установление величины платы за него. Ставку обмена устанавливает платежная ассоциация. Движение платы взаимообмена показано на рисунке. Агентом платежной ассоциации на рисунке выступает расчетный банк, обмен информацией организует процессинговая компания (процессор), которая тоже является частью платежной системы.

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

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

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

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

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

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

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

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

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

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

              Собственно, как конкретно в платежной системе разрешаются отношения "должник-кредитор" торгово-сервисной организации не важно. Ее проблема - во время и в полном объеме получить от эквайрера все суммы по авторизованным сделкам. За обслуживание эквайрер берет с торгово-сервисной организации комиссию. Обычно величины комиссий и сроки возврата денег
              Наша жизнь состоит из цитат. Лишь немногим удается написать что-то своё. (с)

              Комментарий


              • #8
                Спасибо всем,хочется сказать.
                процесс понятен, да и диплом на данную тему защитила на "Отлично".
                Юлия

                Комментарий


                • #9
                  Юлия_кремлин

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

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

                  С уважением.

                  Комментарий


                  • #10
                    Здравствуйте
                    Подскажите пожалуйста какой информацией обменивается банк acquirer c торговым предприятием при проведении покупки по интернету (Без 3D secure)

                    И как создать систему электронного магазина (e-commerce) ?
                    Какое оборудование для этого нужно устанавливать между Банком и Торговым предприятием ?
                    Какие программы требуются?

                    Буду благодарен за любую информацию
                    С уважением

                    Комментарий

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

                    Свернуть

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

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