Мельников Д. А. - Организация и обеспечение безопасности информационно-технологических сетей и систем - 2012

ждый из последних может взаимодействовать с несколькими платежными ЮТР-мостами;

•каждый программный модуль соответствующей платежной системы может управлять несколькими платежными схемами (например, «SET»), а каждая из последних может обеспечи­ ваться несколькими программными модулями различных пла­ тежных систем;

окаждая платежная схема может поддерживать несколько видов платежных средств (например, соответствующая КК или смарткарта) или способов (например, «Visa» с использованием « SET»), а каждый из последних может использоваться несколькими про­ граммными компонентами различных платежных схем.

PAPI-интерфейс предусматривает следующие типы электрон­

ных операций ЮТР-протокола:

•PURCHASE;

•REFUND;

•VALUE EXCHANGE;

•WITHDRAWAL;

•INQUIRY (Payment).

Очевидно, что PAPI-интерфейс:

•с одной стороны, должен быть в целом полнофункциональ­ ным и адаптивным для одновременного обеспечения большо­ го количества соединений с общими и специфическими про­ граммными компонентами;

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

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

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

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

оуправляет зарегистрированными платежными IOTP-мостами и реализует способ их регистрации (здесь эта функция не рас­ сматривается);

•предполагает, что любой платежный IOTP-мост является пас­ сивным компонентом, т.е. последний функционирует в режи­ ме ожидания входных данных и формирует один ответ на ка­ ждый запрос;

•поддерживает процесс обсуждения условий электронного пла­ тежа (покупатель: выбирает разрешенное платежное средство (или способ); продавец: выбирает способы платежа, которые предлагает покупателю), который предшествует запросу на непосредственное проведение платежной процедуры;

•запрашивает дополнительные специфические данные пла­ тежного протокола у ПО платежной системы через выбранный и зарегистрированный ЮТР-мост;

винициализирует и завершает работу ПО платежной системы через ЮТР-мост;

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

оконтролирует процесс обработки электронных торговых про­ цедур в режиме реального времени («on-line») и следит за их развитием;

осохраняет данные электронных торговых процедур, которые циркулируют по «IOTP-соединению» (т.е. те специфические данные платежного протокола, которые «прозрачно» транс­ портируют ЮТР-сообщения);

©«маркирует» каждую электронную платежную операцию с помощью нескольких платежных параметров (идентификатор электронной торговой операции ЮТР-протокола, дополни­ тельные функции торгового протокола, платежное средство/способ, коммерческое предложение продавца, платежный ЮТР-мост, идентификатор ПО платежной системы, взаимо­ действующие между собой удаленные участники электронной коммерческой сделки). Такая «маркировка» может быть более простой, т.е. использовать только идентификатор платежной системы, участвующей в операции, платежный ЮТР-мост, идентификатор ПО платежной системы и наименования уда­ ленных участников сделки, но только тогда, когда платежная операция «стартовала» успешно;

восуществляет контроль за развитием электронных платежных операций;

опредоставляет возможность для запроса на начало и заверше­ ние электронных платежных операций;

•реализует общие диалоговые процедуры (т.е., выбор торговой марки платежной организации, подтверждение платежа, пре­ кращение (аннулирование) платежа; визуализация электрон­ ной платежной квитанции; запрос базовой электронной опе­ рации IOTP-протокола; запрос платежного баланса; подтвер­ ждение электронной платежной квитанции);

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

вобеспечивает обращение к программному модулю любой пла­ тежной системы в интерактивном режиме. Такое обращение может использоваться для:

-определения специфики платежного протокола с целью по­ следующей корректной обработки платежных операций (или выбора необходимой платежной операции;

-анализа платежного средства;

-регистрации нового платежного средства/способа;

-перенастройки платежного средства/способа;

°передает функции обратного вызова («call back») для исполь­ зования платежным IOTP-мостом или ПО (программным мо­ дулем) платежной системы в целях указания необходимости применения этих компонентов.

Кроме указанных функций, программный ЮТР-модуль:

•управляет информационным обменом (отправкой, приемом и обработкой блоков и компонентов IOTP-сообщений) в течение электронной торговой операции, так как блоки и компоненты IOTP-сообщений могут содержать ссылки и могут понадобить­ ся в период обработки последующих сообщений (например, для проверки и вычисления электронной цифровой подписи - ЭЦП). В частности, ЮТР-модуль хранит транспортируемые в IOTP-сообщениях данные (элементы «Packaged Content»), ко­ торыми обмениваются между собой участники электронной торговой сделки;

вуправляет несколькими типами идентификаторами (т.е. иден­ тификаторами торговых операций, IOTP-сообщений, блоков и компонентов);

вреализует способ выделения оперативной памяти для хране­ ния ЮТР-сообщений;

•выявляет режим «тайм-аута» («time-out») при функциониро­ вании протокола и PAPI-интерфейса, отображая наличие свя­ зи с удаленным программным IOTP-модулем и локальным оконечным программным модулем платежной системы (на­ пример, смарт-карта («считыватель») может запросить режим «тайм-аута»).

Однако программные модули IOTP-моста и платежной системы не способны «полагаться» на все эти свойства (функции) программно­ го IOTP-модуля. Например, ПО платежной системы у некоторого по­ купателя (клиентский модуль) может «отвергнуть» скомпрометиро­ ванное специфическое платежное средство на этапе выбора торговой марки платежной организации и может прервать этот этап выбора, используя для этого запрос «Check Payment Possibility» («проверка плате­ жеспособности») и свой «собственный» интерфейс пользователя.

Функциональные возможности программного модуля ЮТР-мос- та, помимо распределения текущих платежных процессов между покупателем и платежной системой, также включают:

отрансляцию и сборку/разборку сообщений из одного форма­ та в другой и наоборот при информационном обмене между PAPI-интерфейсом и соответствующим программным моду­ лем платежной системы. Запросы PAPI-интерфейса и ответы на них имеют строгую «парную» структуру, т.е. на один за­ прос должен поступить только один ответ («1-to-l related»);

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

озапрос состояния платежной операции, причем такой, что за­ прашивающая сторона (программный ЮТР-модуль или ПО пользователя) может определить следующую необходимую итерацию;

•запрос платежного баланса или «истории» платежной проце­ дуры. Например, покупатели могут с помощью собственной смарт-карты (которая является определенным платежным средством) запросить справку-счет еще до успешного завер­ шения платежной процедуры;

•запрос информации о состоянии платежных процедур, кото­ рые интерпретируются как не корректные. Эта информация может использоваться программным IOTP-модулем для при­ нятия решения о запуске приостановленных процедур (после возможного сбоя);

•индикацию «прохождения» платежной процедуры. Эта функ­ ция может быть использована клиентом для определения де­ талей «прохождения» платежной процедуры;

•специфические способы аутентификации в рамках соответст­

вующих платежных протоколов.

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

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

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

©дополнительное информирование программного ЮТРмодуля об обнаруженной ошибке, так как штатные средства выявления ошибок (и информировании о них) ПО различных платежных систем для него не доступны;

•возможность использования способов управления передачей данных и запроса состояния при проведении определенных процедур, за исключением способов регистрации платежных процедур и функциональных особенностей последних;

•применение платежным протоколом специфического про­ граммного интерфейса для проведения диалогового режима информационного обмена.

33.4. Функции PAPI-интерфейса

PAPI-интерфейс в рамках IOTP-протокола реализует следую­ щие наборы функций:

Компиляция т орговы х марок платежных систем

•«поиск общедоступной торговой марки платежной системы» (Find Accepted Payment Brand) - используется для определения из­ вестных торговых марок платежных систем для обслуживания любой указанной валюты;

в«поиск общедоступного платежного протокола» (Find Accepted Payment Protocol) - используется для определения известных платежных протоколов для обслуживания любой указанной валюты (и торговой марки платежной системы) и доставки от­ ветной специфической информации о платежных протоколах с целью выбора наиболее приемлемого (Примечание. Эта функция может быть использована совместно с предыдущей функцией или вызвана без указания какого-либо идентифика­ тора торговой марки платежной системы.);

о«получение данных о начале платежной процедуры» (Get Payment In­ itialization Data) - используется для доставки ответной специфи­ ческой информации о платежных протоколах с целью коррект­ ной обработки протокольных сообщений системой платежей;

•«запрос процедуры аутентификации» (Inquire Authentication Challenge) - используется для доставки специфической ин­ формации, необходимой для осуществления процедуры ау­ тентификации;

в«проверка ответа с аутентификационными данными» (Check Au­ thentication Response) - используется для проверки специфиче­ ских данных аутентификации, полученных платежной схемой в ответ на их запрос;

о«изменение текущего состояния процесса» (Change Process State) - используется (и только в этом наборе функций) для не штат­ ного завершения процедуры;

Выбор т орговых марок платежных систем:

о«поиск платежного средства» (Find Payment Instrument) - ис­ пользуется для определения некоторого варианта платежного средства специфической платежной системы с данной торго­ вой маркой, которое является разрешенным для использова­ ния в определенной платежной процедуре;

•«проверка платежеспособности» (Check Payment Possibility) - ис­ пользуется для проверки специфического платежного средства на предмет его способности осуществить платежную процедуру;

•«аутентификация» (Authenticate) - используется для доставки программному модулю IOTP-моста на обработку специфиче­ ских аутентификационных данных от какой-либо платежной схемы;

•«изменение текущего состояния процесса» (Change Process State) - используется (и только в этом наборе функций) для не штат­ ного завершения процедуры;

Обработка данных платежной процедуры:

•«инициализация или завершение работы ПО покупателя/платежной системы» (Start or Resume Payment Consumer/Payment Handler) - используется для запуска или завершения платежной процеду­ ры. Данные функции предназначены только лишь для двух уча­ стников торговой электронной сделки - покупателя и платежной системы;

о«обеспечение текущего процесса обработки данных платежной про­ цедуры» (Continue Process) - используется для доставки ПО со­ ответствующей платежной системы на обработку специфиче­ ских данных и приема от него для передачи противоположной стороне (участнику торговой электронной сделки) ответных специфических данных платежной схемы;

о«изменение текущего состояния процесса» (Change Process State) - используется для изменения текущего состояния платежной процедуры. Обычно эта функция используется для успешно­ го/безуспешного завершения или приостановки платежной процедуры;

Запросы общего характера

о«удаленная регистрация платежной процедуры» (Remove Payment Log) - используется для уведомления программного модуля IOTP-моста о том, что имеет место соответствующий зарегист­ рированный удаленный доступ к программному ЮТР-модулю для проведения платежной процедуры;

•«запрос свойств платежного средства» (Payment Instrument In­ quiry) - используется для ответных данных о свойствах пла­ тежного средства;

в«запрос данных о незавершенной платежной процедуре» (Inquire Pending Payment) - используется для информирования о не­ штатном прерывании любой платежной процедуры, которое известно программному модулю ЮТР-моста;

Запросы состояния процесса обработки данных платежной процедуры

о«проверка электронной платежной квитанции» (Check Payment Re­ ceipt) - используется для проверки логики и правильности со­ держания электронной платежной IOTP-квитанции, полученной от платежной системы или возвращаемой РАР1-интерфейсом при запросе функции «запрос текущего состояния процесса».

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

•«перекодирование электронной платежной квитанции» (Expand Pay­ ment Receipt) - используется для преобразования данных элек­

тронных платежных IOTP-квитанций («Packaged Content»),

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

о«запрос текущего состояния процесса» (Inquire Process State) - ис­ пользуется для доставки ответных данных о состоянии платеж­ ной процедуры и электронных платежных ЮТР-квитанций. Обычно, эта функция используется платежной системой в пе­ риод завершения платежной процедуры;

в«инициализация запроса текущего состояния платежной процеду­ ры» (Start Payment Inquiry) - используется для предваритель­ ной подготовки к запросу состояния платежной процедуры и доставки ответных специфических данных о платежной схеме (протоколе), которые могут понадобиться платежной системе для обработки запроса, поступившего от покупателя;

в«запрос состояния платежной процедуры» (Inquire Payment Status) - используется платежной системой для ответов на запросы по­ купателя. Данная функция обеспечивает доставку специфиче­ ской информации платежной схемы (протокола) в информа­ ционном IOTP-блоке «Inquiry Response»;

•«обеспечение текущего процесса обработки данных платежной про­ цедуры» (Continue Process) и «изменение текущего состояния про­