WWW.BOOK.LIB-I.RU
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - Электронные ресурсы
 

«Merchant Manual (RU) 1 О документе 2 Терминология 3 Подключение 4 Взаимодействие 4.1 Схема работы с использованием 3d secure 4.2 Схема работы ...»

Merchant Manual (RU)

1 О документе

2 Терминология

3 Подключение

4 Взаимодействие

4.1 Схема работы с использованием 3d secure

4.2 Схема работы без использования 3d secure

5 Алгоритм действий для подключения к платежному шлюзу

6 Интерфейс на WebService-ах

6.1 Запросы, используемые при одностадийной оплате

6.1.1 Запрос регистрации заказа

6.1.2 Запрос отмены оплаты заказа

6.1.3 Запрос возврата средств оплаты заказа

6.1.4 Запрос состояния заказа

6.1.5 Расширенный запрос состояния заказа 6.1.6 Запрос проверки вовлечённости карты в 3DS 6.1.7 Запрос добавления дополнительных параметров к заказу

6.2 Запросы, используемые при двухстадийной оплате 6.2.1 Запрос регистрации заказа с предавторизацией 6.2.2 Запрос завершения оплаты заказа 6.2.3 Запрос отмены оплаты заказа 6.2.4 Запрос возврата средств оплаты заказа 6.2.5 Запрос состояния заказа 6.2.6 Расширенный запрос состояния заказа 6.2.7 Запрос проверки вовлечённости карты в 3DS 6.2.8 Запрос добавления дополнительных параметров к заказу 7 Интерфейс REST

7.1 Запросы, используемые при одностадийной оплате 7.1.1 Запрос регистрации заказа 7.1.2 Запрос отмены оплаты заказа 7.1.3 Запрос возврата средств оплаты заказа 7.1.4 Запрос состояния заказа 7.1.5 Расширенный запрос состояния заказа 7.1.6 Запрос проверки вовлечённости карты в 3DS

7.2 Запросы, используемые при двухстадийной оплате 7.2.1 Запрос регистрации заказа c предавторизацией 7.2.2 Запрoс завершения oплаты заказа 7.2.3 Запрос отмены оплаты заказа 7.2.4 Запрос возврата средств оплаты заказа 7.2.5 Запрос состояния заказа 7.2.6 Расширенный запрос состояния заказа 7.2.7 Запрос проверки вовлечённости карты в 3DS 8 Callback-уведомления 9 Оформление платежной страницы

9.1 Требования к странице платёжного интерфейса

9.2 Требования к платёжной странице 9.2.1 Название страницы 9.2.2 Заголовок страницы 9.2.3 Тело страницы 9.2.3.1 Платежная форма

9.3 Требования к странице ошибок 9.3.1 Название страницы 9.3.2 Заголовок страницы 9.3.3 Тело страницы 10 Координаты подключения 11 Тестовые карты 12 Приложение 1. Описание функционала связок

12.1 Общее описание

12.2 Отображение на платёжной странице. Форма выбора связки

12.3 Создание запросов по связкам 12.3.1 Описание запросов, интерфейс на WebService-ах 12.3.1.1 Запрос проведения платежа по связкам 12.3.1.2 Запрос деактивации связки 12.3.1.3 Запрос активации связки 12.3.1.4 Запрос изменения срока действия карты 12.3.1.5 Запрос списка возможных связок для мерчанта 12.3.2 Описание запросов, интерфейс REST 12.3.2.1 Запрос проведения платежа по связкам 12.3.2.2 Запрос деактивации связки 12.3.2.3 Запрос активации связки 12.3.2.4 Запрос изменения срока действия карты 12.3.2.5 Запрос списка возможных связок для мерчанта

12.4 Координаты подключения (функционал связок) 13 Приложение 2. Использование "Альфа- клик"

13.1 Краткое описание

13.2 Ограничения и допущения

13.3 Участники бизнес-процесса

13.4 Основной бизнес-процесс

13.5 Тестирование

13.6 Дополнение к описанию платежной страницы

13.7 Запрос проведения оплаты через «Альфа-Клик»

13.7.1 Интерфейс на WebService 13.7.2 Интерфейс REST 14 Приложение 3. Спецификация дополнительных полей для платежей в авиакомерции

14.1 Описание дополнительных полей

14.2 Пример заполнения дополнительных полей 15 Приложение 4. Коды ответа - расшифровка actionCode (ответ процессинга) О документе Настоящий документ описывает принципы подключения и программные интерфейсы платежного шлюза.





Терминология Магазин – торгово-сервисное предприятие (ТСП), продающее товары или оказывающее услуги через интернет-сайт.

Банковская Карта - карта международных платежных систем VISA и MasterCard.

Банк-эмитент – банк, выпустивший банковскую карту клиента.

МПС – Международная платежная система (например, Visa или MasterCard) Платежный шлюз Банка-экваерера (ПШ) – автоматическая система, предоставляющая магазину принимать, а Клиенту отправлять платежи через Интернет с использованием банковских карт.

Банк-экваерер – банк, который реализует и эксплуатирует платежный шлюз.

3D Secure – технология МПС Visa, позволяющая дополнительно авторизовать пользователя средствами банка-эмитента.

SecureCode – технология МПС MasterCard, позволяющая дополнительно авторизовать пользователя средствами банка-эмитента. Технологически равносильна 3D Secure. В тексте ниже при упоминании 3DSecure будем иметь ввиду и SecureCode.

Merchant Plugin Interface (MPI) – технологический компонент 3D Secure и SecureCode, который может быть размещен на стороне ПС или на стороне магазина ACS – Access Control Server, элемент инфраструктуры 3D Secure, обеспечивающий валидацию плательщика на стороне банка-эмитента.

Платежная форма – HTML-страница, которая используется клиентом для ввода реквизитов платежа.

Платежные реквизиты – реквизиты, используемые пользователем для оплаты заказа. Обычно, это номер карты, expiration date, CVC.

Плательщик - физическое лицо совершающее платеж по своей карте за услуги Мерчанта в интернет магазине Мерчанта.

Связка - соответствие между Плательщиком и платежными реквизитами карты (номер карты, срок действия карты) Заказ – элементарная сущность системы, описывает заказ в некотором интернет-магазине или его аналоге. У любого заказа есть сумма.

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

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

Отмена операции оплаты (Reversal) - снятие блокировки с денежных средств на карте покупателя. Данная функция доступна ограниченное время, точные сроки необходимо уточнять в банке.

Возврат средств (Refund) - частичный или полный возврат денежных средств на карту покупателя в случае его отказа от получения товара(услуги) или его возврата. Операция возврата денежных средств выполняется после списания денежных средств со счета покупателя.

Подключение

Для подключения к системе магазин предоставляет:

1. HTML-страницу, с графикой и CSS и прочими подключаемыми объектами, которая показывает платежную форму. Требования к этой странице описаны в отдельном документе "Оформление платежной страницы".

В результате подключения магазин получает:

1. Логин – имя магазина в рамках платежного шлюза. Оно используется только для произведения операций посредством API.

2. Пароль – пароль магазина в рамках платежного шлюза. Используется только для произведения операций посредством API Взаимодействие Работа платежного шлюза различается для случаев использование и неиспользования технологии 3d secure.

Схема работы с использованием 3d secure

Описание:

1. Клиент взаимодействует с магазином для создания заказа в магазине.

2. После подтверждения заказа клиентом, система магазина регистрирует заказ в платежном шлюзе. Для регистрации используются такие параметры как сумма списания, валюта списание, номер заказа в системе магазина, а также URL возврата клиента.

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

4. Система магазина передает браузеру клиента redirect на URL, полученный на шаге 3.

5.

5. Браузер клиента открывает URL

6. В качестве страницы по указанному URL браузер клиента получает платежную форму

7. Пользователь заполняет полученную форму и отправляет данные на сервер платежного шлюза

8. Система проверяет вовлеченности карты в 3DSecure (SecureCode).

9. Шлюз отправляет браузеру клиента redirect на страницу ACS банка эмитента (этот шаг является необходимым для реализации 3DS)

10. Браузер клиента запрашивает у ACS форму авторизации пользователя (у каждого эмитента это делается по-своему)

11. ACS отправляет в браузер клиента эту форму, клиент ее видит

12. Клиент заполняет форму и отправляет ее в ACS

13. ACS обрабатывает заполненную форму и (в не зависимости от результата) передает браузеру redirect на URL страницы платежного шлюза. Вместе с этим URL передаются зашифрованные параметры результата авторизации

14. Браузер клиента запрашивает страницу платежного шлюза, передавая зашифрованные параметры результата авторизации

15. Платежный шлюз производит оплату (списание)

16. После проведения оплаты, платежный шлюз передает браузеру клиента URL возврата (указанный ранее при регистрации заказа магазином)

17. Браузер клиента запрашивает страницу с результатами оплаты у магазина.

18. Система магазина запрашивает платежный шлюз о статусе оплаты заказа (по внутреннему номеру в платежной системе)

19. Платежный шлюз возвращает статус оплаты

20. Система магазина передает в браузер клиента страницу с результатами оплаты.

В этой схеме шаги 18 и 19 не являются обязательными, магазин может не использовать их в работе.

Схема работы без использования 3d secure

Описание:

1. Клиент взаимодействует с магазином для создания заказа в магазине.

2. После подтверждения заказа клиентом, система магазина регистрирует заказ в платежном шлюзе. Для регистрации используются такие параметры как сумма списания, валюта списание, номер заказа в системе магазина, а также URL возврата клиента.

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

4. Система магазина передает браузеру клиента redirect на URL, полученный на шаге 3.

5. Браузер клиента открывает URL

6. В качестве страницы по указанному URL браузер клиента получает платежную форму

7. Пользователь заполняет полученную форму и отправляет данные на сервер платежного шлюза

8. Получив платежные реквизиты (номер карты и т.п.) система производит списание со счета клиента

9. После проведения оплаты, платежный шлюз передает браузеру клиента URL возврата (указанный ранее при регистрации заказа магазином)

10. Браузер клиента запрашивает страницу с результатами оплаты у магазина.

11. Система магазина запрашивает платежный шлюз о статусе оплаты заказа (по внутреннему номеру в платежной системе)

12. Платежный шлюз возвращает статус оплаты

13. Система магазина передает в браузер клиента страницу с результатами оплаты Если по истечении отведенных на оплату 20 минут клиент не вернулся с платежного шлюза на страницу результатов оплаты магазина (на URL возврата клиента), то оплата считается неудачной.

Изменение статуса оплаты заказа может быть выполнено по запросу магазина вручную сотрудниками Банка после проверки состояния транзакции в банковских системах. В этом случае после подтверждения изменения статуса заказа магазин может выполнить повторный запрос о статусе оплаты заказа (шаги 18-19).

По завершении п.20 заканчивается взаимодействие между магазином и платежным шлюзом в on-line режиме. Дальнейшие операции по завершению платежа (в случае двухстадийных платежей), отмене платежа и возврату денежных средств проводятся в off-line режиме.

Жизненный цикл заказа приводится в документе Работа с заказом (AF) Реализация схем на стороне магазина

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

–  –  –

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

Чтобы разработчик системы магазина мог реализовать эти взаимодествия, система платежного шлюза представляет API из 2х запросов:

1. Зарегистрировать заказ

2. Получить информацию по состоянию заказа

Система предоставляет 2 реализации API:

Реализация на WebService-ах (SOAP) Реализация на REST Примечание: С момента регистрации заказа у покупателя есть 20 минут для его оплаты. При попытке его оплаты по истечении этого срока будет выдаваться страница с ошибками.

Алгоритм действий для подключения к платежному шлюзу

1. Получение логинов и паролей на тестовый сервер.

2. Верстка платежной страницы.

3. Загрузка архива с платежной страницы на тестовый сервер.

4. Тестирование работоспособности платежной страницы:

с использованием интерфейса REST \ интерфейса на web- сервисах с использованием формы для регистрации заказа с использованием личного кабинета и консоли

5. Свяжитесь с банком, чтобы вашу платежную страницу проверили. Если проверка прошла успешно, сотрудники банка перенесут Вашу платежную страницу на боевой сервер.

6. Получение логинов и паролей на боевой сервер.

7. Переключение вашего магазина на использование промышленной системы.

8. Произведение тестовой оплаты настоящей картой (рекомендуется провести оплату по 3DS-карте, а также выполнить SSL-платеж).

9. Выполнить отмену и возврат платежа через личный кабинет платежа.

10. Подписание акта о готовности интернет-магазина.

Интерфейс на WebService-ах Описание (WSDL) сервиса находится на тестовом сервере, который доступен без ограничений. Адреса см. "Координаты подключения" ниже.

Для авторизации обращения магазина к системе платежного шлюза, в любом запросе со стороны магазина должны быть приведены имя и пароль магазина, которые представитель магазина ввел при регистрации магазина в системе. Значения имени и пароля передаются в формате, описанном в рамках спецификации WS-Security, тип авторизации userName token.

Заголовок при такой авторизации будет выглядеть примерно так:

wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu=" http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-%20wssecurity-utility-1.0.xsd" wsse:UsernameToken wsu:Id="UsernameToken-87" wsse:Usernameaa/wsse:Username wsse:Password Type=" http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText"123456/wsse:Password /wsse:UsernameToken /wsse:Security В зависимости от выбранной схемы системы оплаты (одностадийная или двухстадийная) синтаксис запросов различается. Ниже описаны запросы для каждой из них.

Если Error code (Код ошибки) = 0, запрос был обработан Платежным шлюзом без системных ошибок (при этом error code не показывает статус заказа).

Для получения статуса заказа следует использовать запрос getOrderStatus или getOrderStatusExtended.

Запросы, используемые при одностадийной оплате Запрос регистрации заказа Запрос регистрации заказа называется registerOrder, он описан в WSDL сервиса.

Параметры запроса:

–  –  –

* Поля дополнительной информации для последующего хранения. Данные поля могут быть переданы в процессинг банка для последующего отображения в реестрах.** Включение данного функционала возможно по согласованию с банком в период интеграции. Для передачи N параметров, в запросе должно находиться N тэгов Params, где атрибут name содержит название, а атрибут value содержит значение:

–  –  –

** По умолчанию в процессинг банка передаются поля номер заказа orderNumber и его описание description (не более 99 символов, запрещены к использованию %, +, конец строки \r и перенос строки \n) errorMessage AN..512 нет Описание ошибки на языке, переданном в параметре Language в запросе.

Коды ошибок:

Значение Описание 0 Обработка запроса прошла без системных ошибок

–  –  –

Пример запроса:

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mer=" http://engine.paymentgate.ru/webservices/merchant" soapenv:Header/ soapenv:Body mer:registerOrder order merchantOrderNumber="78ds901234567890" description=" " amount="15000" currency=" " language=" " pageView="MOBILE" sessionTimeoutSecs=" " expirationDate="2014-09-08T14:14:14" returnUrl http://example.ru?page=result /returnUrl failUrlhttp://example.ru?page2=result/failUrl params name=" " value=" "/ clientId666/clientId /order /mer:registerOrder /soapenv:Body /soapenv:Envelope

Пример ответа:

soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:Body ns1:registerOrderResponse xmlns:ns1="http://engine.paymentgate.ru/webservices/merchant" return orderId="05fcbc62-7ee6-4f1a-b3d5-6ca41a982283" errorCode="0" errorMessage="Успешно" Все указанные выше hidden-поля обязательны. Значение поля language должно содержать двухбуквенное обозначение локали страницы.

Форма также должна содержать поля для ввода информации для проведения платежа:

input name="$PAN" id="iPAN" maxlength="19" type="text" autocomplete="off" / Поле для ввода номера кредитной карты select name="MM" id="month" option value="01" selected 1 - январь/option option value="02" 2 - февраль/option option value="03" 3 - март/option option value="04" 4 - апрель/option option value="05" 5 - май/option option value="06" 6 - июнь/option option value="07" 7 - июль/option option value="08" 8 - август/option option value="09" 9 - сентябрь/option option value="10"10 - октябрь/option option value="11"11 - ноябрь/option option value="12"12 - декабрь/option /select / select name="YYYY" id="year" option value='2012' selected2012/option option value='2013'2013/option option value='2014'2014/option option value='2015'2015/option option value='2016'2016/option option value='2017'2017/option option value='2018'2018/option option value='2019'2019/option option value='2020'2020/option option value='2021'2021/option option value='2022'2022/option /select Селектор месяца и селектор года (заполняется автоматически при загрузке страницы) истечения срока действия кредитной карты input name="TEXT" id="iTEXT" maxlength="90" type="text" autocomplete="off" / Поле ввода имени владельца карты (Cardholder name) input name="$CVC" id="iCVC" maxlength="3" type="password" autocomplete="off" / поле ввода cvc/cvv/cid -кода input value="Оплатить" type="button" id="buttonPayment" кнопка подтверждения оплаты.

После формы оплаты, ниже должен быть размещён следующий код:

На странице оплаты должны быть также размещены следующие объекты:

div id="errorBlock" style="color:red;"/div блок, где отображаются ошибки (например, неверные данные по карте) div id="numberCountdown"/div блок, где отображается сообщение о том, сколько ещё времени до конца сессии оплаты.

div id="infoBlock"/div блок, где отображается информационное сообщение при переходе со страницы оплаты на итоговую страницу.

div id="indicator" style="display:none;"img src="../img/ajax-loader.gif" height="19" width="220" alt="indicator"/div блок, где отображается индикатор прогресса выполнения запроса к серверу (при подтверждении оплаты и последующему обращению к серверу)

При выполнении всех требований на платежной странице при оплате заказа будут отображаться:

- сумма заказа

- номер заказа в системе магазина

- описание заказа (отображается только при заполнении поля description) Требования к странице ошибок Страница должна содержать ряд необходимых объектов.

Название страницы Название обычной страницы – errors_ln.html, Название страницы для мобильного устройства – mobile_errors_ln.html, где ln - двухбуквенное обозначение локали страницы (например, ru – русский, en - английский, ISO 639-1).

Заголовок страницы

В заголовке страницы должны подключаться следующие скрипты:

где ln - двухбуквенное обозначение локали страницы (например, ru – русский, en - английский, ISO 639-1).

Тело страницы Все блоки и элементы, описанные ниже в данном параграфе, обязательно должны быть размещены в теле страницы.

Форма:

где ln - двухбуквенное обозначение локали страницы (например, ru – русский, en - английский, ISO 639-1).

Форма также должна содержать блок, где отображаются ошибки (например, об окончании сессии или сообщение о том, что оплата уже была совершена).

div id="errorBlock" style="color:red;"/div Координаты подключения При регистрации мерчанта, представителю предоставляется логин и пароль, который можно использовать в личном кабинете, а также нужно использовать в протоколах.

Описание тестового сервиса (WSDL) находится по адресу https://test.paymentgate.ru/testpayment/webservices/merchant-ws?wsdl.

URL для доступа к методам REST:

–  –  –

Регистрация заказа с предавторизацией https://test.paymentgate.ru/testpayment/rest/registerPreAuth.do Запрос завершения оплаты заказа https://test.paymentgate.ru/testpayment/rest/deposit.do Запрос отмены оплаты заказа https://test.paymentgate.ru/testpayment/rest/reverse.do Запрос возврата средств оплаты заказа https://test.paymentgate.ru/testpayment/rest/refund.do Получение статуса заказа https://test.paymentgate.ru/testpayment/rest/getOrderStatus.do Получение расширенного статуса заказа https://test.paymentgate.ru/testpayment/rest/getOrderStatusExtended.do Запрос проверки вовлеченности карты в 3DS https://test.paymentgate.ru/testpayment/rest/verifyEnrollment.do Тестовые карты В качестве Cardholder name указывать от 2 слов в английской раскладке. Для всех карт, вовлеченных в 3d Secure (veres=y, pares=y или a ) код на ACS 12345678. / Use two or more words in Roman letters as the name of the cardholder.

For cards involeved into 3d Secure (veres=y, pares=y or a) ACS code is 12345678:

pan: 4111 1111 1111 1111 exp date: 2015/12 cvv2: 123 3dsecure: veres=y, pares=y pan: 5100 0000 0000 0008 exp date: 2015/08 cvv2: 123 3dsecure: veres=y, pares=y pan: 6011 0000 0000 0004 exp date: 2015/12 cvv2: 123 3dsecure: veres=y, pares=y pan: 6390 0200 0000 000003 exp date: 2015/12 cvv2: 123(необязательный параметр) 3dsecure: veres=y, pares=a pan: 5555 5555 5555 5599 exp date: 2015/12 cvv2: 123 3dsecure: veres=n pan: 4444 0000 0000 1111 exp date: 2015/12 cvv2: 123 3dsecure: veres=n Карты, возвращающие ошибки /

Cards returning errors:

pan: 5555 5555 5555 5557 exp date: 2015/12 cvv2: 123 3dsecure: veres=y, pares=u pan: 4444 3333 2222 1111 exp date: 2015/12 cvv2: 123 3dsecure: veres=y, pares=u Declined. PaRes status is U (-2011) pan: 4000 0000 0000 0002 exp date: 2015/12 cvv2: 123 3dsecure: veres=u pan: 5555 5555 4444 4442 exp date: 2015/12 cvv2: 123 3dsecure: veres=u Declined. VeRes status is U (-2016) pan: 4444 4444 4444 4422 exp date: 2015/12 cvv2: 123 Invalid message format (913) pan: 4444 4444 4444 4455 exp date: 2015/12 cvv2: 123 Card limitations exceeded (902) pan: 4444 4444 4444 3333 exp date: 2015/12 cvv2: 123 Limit exceeded (123) pan: 4444 4444 4444 6666 exp date: 2015/12 cvv2: 123 BLOCKED_BY_LIMIT (-20010) pan: 4444 4444 1111 1111 exp date: 2015/12 cvv2: 123 Network refused transaction (5) pan: 4444 4444 9999 9999 exp date: 2015/12 cvv2: 123 TDSEC_COMM_ERROR (151017) pan: 5432 5432 5432 5430 exp date: 2018/08 cvv2: 521 INSUFFICIENT_FUNDS (116) Приложение 1. Описание функционала связок 1 Общее описание 2 Отображение на платёжной странице. Форма выбора связки 3 Создание запросов по связкам

3.1 Описание запросов, интерфейс на WebService-ах 3.1.1 Запрос проведения платежа по связкам 3.1.2 Запрос деактивации связки 3.1.3 Запрос активации связки 3.1.4 Запрос изменения срока действия карты 3.1.5 Запрос списка возможных связок для мерчанта

3.2 Описание запросов, интерфейс REST 3.2.1 Запрос проведения платежа по связкам 3.2.2 Запрос деактивации связки 3.2.3 Запрос активации связки 3.2.4 Запрос изменения срока действия карты 3.2.5 Запрос списка возможных связок для мерчанта 4 Координаты подключения (функционал связок) Общее описание Данный функционал используется для привязки номера карты к id покупателя в системе магазина (например, к логину). Существует 2 способа использования связок: отображение на платежной странице и создание запроса оплаты по связкам.

В первом варианте, если после авторизации на сайте магазина и успешной оплаты заказа по карте, пользователь повторно на данном сайте оформит заказ под тем же id, то при перенаправлении на платежную страницу ему будет предложено автозаполнение всех данных по карте, исключая CVC/ CVV.

Во втором варианте (создание запроса оплаты) при оплате заказа картой, для которой существует связка, передаётся только id связки карточные данные не указываются.

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

Отображение на платёжной странице. Форма выбора связки Если для мерчанта предполагается использование функционала связок, платежная страница может содержать форму выбора связки для оплаты заказа.

Оформление формы должно удовлетворять следующим условиям:

Форма должна иметь идентификатор id="formBinding".

Форма должна быть скрыта по-умолчанию при помощи CSS свойства "display: none;".

Форма должна содержать выпадающий список выбора связки с именем name="bindingId".

Выпадающий список должен содержать один вариант выбора: option value="" selected="selected"другая/option, при выборе которого пользователь осуществляет обычную оплату по карте, без использования функционала связок.

Форма должна содержать поле ввода СVC/CVV с именем name="cvc".

Форма должна содержать кнопку "Оплатить": input value="Оплатить" type="button" id="buttonBindingPayment" с идентификатором id="buttonBindingPayment".

Поле ввода CVC/CVV и кнопка "Оплатить" должны быть обрамлены элементами с классом class="rbs_hidden".

При выборе варианта оплаты без использования функционала связок, эти элементы будут скрыты путем установки свойства CSS "display:

none;".

Пример формы:

Создание запросов по связкам Описание запросов, интерфейс на WebService-ах Запрос проведения платежа по связкам Для проведения платежа по связкам используется запрос paymentOrderBinding.

Параметры запроса:

–  –  –

* Поля дополнительной информации для последующего хранения. Данные поля могут быть переданы в процессинг банка для последующего отображения в реестрах.** Включение данного функционала возможно по согласованию с банком в период интеграции. Для передачи N параметров, в запросе должно находиться N тэгов Params, где атрибут name содержит название, а атрибут value содержит значение:

–  –  –

** По умолчанию в процессинг банка передаются поля номер заказа orderNumber и его описание description (не более 99 символов, запрещены к использованию %, +, конец строки \r и перенос строки \n)

Коды ошибок (поле errorCode):

Значение Описание 0 Обработка запроса прошла без системных ошибок 1 Необходимо указать CVC2/CVV2 код, поскольку у мерчанта нет разрешения на проведение платежа без CVC

–  –  –

Пример запроса:

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mer=" http://engine.paymentgate.ru/webservices/merchant" soapenv:Header/ soapenv:Body mer:paymentOrderBinding order mdOrder="9213bc5f-5d5b-43d6-a408-b6b93cdde992" bindingId="ca91a4ab-b6d4-495d-b606-8fb0114e679e" language="ru" ip="127.0.0.1" cvc="123" email=" " !-Zero or more repetitions:params name=" " value=" "/ /order /mer:paymentOrderBinding /soapenv:Body /soapenv:Envelope

Пример ответа:

soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:Body ns1:paymentOrderBindingResponse xmlns:ns1="http://engine.paymentgate.ru/webservices/merchant" return errorCode="0" info="Ваш платёж обработан, происходит переадресация..." redirect=" http://example.ru?orderId=9213bc5f-5d5b-43d6-a408-b6b93cdde992"/"/ /ns1:paymentOrderBindingResponse /soap:Body /soap:Envelope Запрос деактивации связки Для того, чтобы сделать существующую связку неактивной, используется запрос unBindCard.

Параметры запроса:

–  –  –

errorMessage ANS..* (при ошибке) Сообщение об ошибке

Коды ошибок (поле errorCode):

Значение Описание 0 Обработка запроса прошла без системных ошибок 2 Неверное состояние связки (при попытке деактивировать неактивную связку)

–  –  –

Пример запроса:

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mer="http://engine.paymentgate.ru/webservices/merchant" soapenv:Header/ soapenv:Body mer:unBindCard bindingIdfd3afc57-c6d0-4e08-aaef-1b7cfeb093dc/bindingId /mer:unBindCard /soapenv:Body /soapenv:Envelope

Пример ответа:

soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:Body ns1:unBindCardResponse xmlns:ns1="http://engine.paymentgate.ru/webservices/merchant" return errorCode="0" errorMessage="Успешно"/ /ns1:unBindCardResponse /soap:Body /soap:Envelope Запрос активации связки Для активации деактивированной ранее связки используется запрос bindCard.

Параметры запроса:

–  –  –

errorMessage ANS..* (при ошибке) Сообщение об ошибке

Коды ошибок (поле errorCode):

Значение Описание 0 Обработка запроса прошла без системных ошибок 2 Неверное состояние связки (при попытке деактивировать неактивную связку)

–  –  –

Пример запроса:

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mer="http://engine.paymentgate.ru/webservices/merchant" soapenv:Header/ soapenv:Body mer:bindCard bindingIdfd3afc57-c6d0-4e08-aaef-1b7cfeb093dc/bindingId /mer:bindCard /soapenv:Body /soapenv:Envelope

Пример ответа:

soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:Body ns1:bindCardResponse xmlns:ns1="http://engine.paymentgate.ru/webservices/merchant" return errorCode="5" errorMessage="Пользователь должен сменить свой пароль"/ /ns1:bindCardResponse /soap:Body /soap:Envelope Запрос изменения срока действия карты Для изменения срока действия карты используйте метод extendBinding.

Параметры запроса:

–  –  –

Пример запроса:

Пример ответа:

Запрос списка возможных связок для мерчанта Для получения списка связок по идентификатору клиента используется запрос getBindings.

Параметры запроса:

–  –  –

Пример запроса:

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mer="http://engine.paymentgate.ru/webservices/merchant" soapenv:Header/ soapenv:Body mer:getBindings request clientId="client"/ /mer:getBindings /soapenv:Body /soapenv:Envelope

Пример ответа:

soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:Body ns1:getBindingsResponse xmlns:ns1="http://engine.paymentgate.ru/webservices/merchant" return errorCode="0" errorMessage="Успешно" bindings binding bindingId="fd3afc57-c6d0-4e08-aaef-1b7cfeb093dc" maskedPan="4000 00** **** **02" expiryDate="201512"/ /bindings /return /ns1:getBindingsResponse /soap:Body /soap:Envelope Описание запросов, интерфейс REST Запрос проведения платежа по связкам Для проведения платежа по связкам используется запрос paymentOrderBinding.do (см. раздел "Координаты подключения (функционал связок)").

Параметры запроса:

–  –  –

paReq ANS..* (при 3DS платеже) Payment Authentication Request termUrl ANS..* (при 3DS платеже) URL для возврата с ACS

Коды ошибок (поле success):

Значение Описание 0 Обработка запроса прошла без системных ошибок 1 Необходимо указать CVC2/CVV2, поскольку у мерчатна нет разрешения на проведение оплаты без CVC

–  –  –

Пример запроса POST:

mdOrder=65401edc-3fa1-4112-87fd-a569ca69fb6a& bindingId=41954212-70a7-4eae-8430-90c1a87beda7

Пример ответа:

{"info":"Ваш платёж обработан, происходит переадресация...","redirect":"finish.html?login=username& password=testPwd&orderId=65401edc-3fa1-4112-87fd-a569ca69fb6a","errorCode":0} Запрос деактивации связки Для того, чтобы сделать существующую связку неактивной, используется запрос unBindCard.do (см. раздел "Координаты подключения (функционал связок)").

Параметры запроса:

–  –  –

Коды ошибок (поле errorCode):

Значение Описание 0 Обработка запроса прошла без системных ошибок 2 Неверное состояние связки (при попытке деактивировать неактивную связку

–  –  –

Пример запроса GET:

https://test.paymentgate.ru/testpayment/rest/unBindCard.do?

userName=binding_api&password=testPwd&bindingId=fd3afc57-c6d0-4e08-aaef-1b7cfeb093dc

Пример запроса POST:

bindingId=fd3afc57-c6d0-4e08-aaef-1b7cfeb093dc

Пример ответа:

{"errorCode":"2","errorMessage":"Binging isn't active"} Запрос активации связки Для активации деактивированной ранее связки используется запрос bindCard.do (см. раздел "Координаты подключения (функционал связок)").

Параметры запроса:

–  –  –

Коды ошибок (поле errorCode):

Значение Описание 0 Обработка запроса прошла без системных ошибок 2 Неверное состояние связки (при попытке активировать активную связку)

–  –  –

Пример запроса GET:

https://test.paymentgate.ru/testpayment/rest/bindCard.do?

userName=binding_api&password=testPwd&bindingId=fd3afc57-c6d0-4e08-aaef-1b7cfeb093dc

Пример запроса POST:

bindingId=fd3afc57-c6d0-4e08-aaef-1b7cfeb093dc

Пример ответа:

{"errorCode":"2","errorMessage":"Binding is active"} Запрос изменения срока действия карты Для получения списка связок по идентификатору клиента используется запрос extendBinding.do (см. раздел "Координаты подключения (функционал связок)").

Параметры запроса:

–  –  –

errorMessage ANS..* (при ошибке) Сообщение об ошибке

Коды ошибок (поле errorCode):

Значение Описание 0 Обработка запроса прошла без системных ошибок 1 Не указан или неверно указан один или несколько обязательных параметров

–  –  –

Пример запроса GET:

Пример запроса POST:

Пример ответа:

Запрос списка возможных связок для мерчанта Для получения списка связок по идентификатору клиента используется запрос getBindings.do (см. раздел "Координаты подключения (функционал связок)").

Параметры запроса:

–  –  –

Пример запроса GET:

https://test.paymentgate.ru/testpayment/rest/getBindings.do?

userName=binding_api&password=testPwd&clientId=client

Пример запроса POST:

clientId=client

Пример ответа:

{"bindings":[{"bindingId":"fd3afc57-c6d0-4e08-aaef-1b7cfeb093dc", "maskedPan":"4000 00** **** **02","expiryDate":"201512"}],"errorCode":"0", "errorMessage":"Успешно"} Координаты подключения (функционал связок) При регистрации мерчанта, представителю предоставляется логин и пароль, который можно использовать в личном кабинете, а также нужно использовать в протоколах.

Описание тестового сервиса (WSDL) находится по адресу https://test.paymentgate.ru/testpayment/webservices/merchant-ws?wsdl.

URL для доступа к методам REST:

–  –  –

Запрос проведения оплаты по связкам https://test.paymentgate.ru/testpayment/rest/paymentOrderBinding.do Запрос деактивации связки https://test.paymentgate.ru/testpayment/rest/unBindCard.do Запрос активации связки https://test.paymentgate.ru/testpayment/rest/bindCard.do Запрос изменения срока действия карты https://test.paymentgate.ru/testpayment/rest/extendBinding.do Запрос списка возможных связок для мерчанта https://test.paymentgate.ru/testpayment/rest/getBindings.do Приложение 2. Использование "Альфа- клик" 1 Краткое описание 2 Ограничения и допущения 3 Участники бизнес-процесса 4 Основной бизнес-процесс 5 Тестирование 6 Дополнение к описанию платежной страницы 7 Запрос проведения оплаты через «Альфа-Клик»

7.1 Интерфейс на WebService

7.2 Интерфейс REST Краткое описание Система PayByClick является еще одним платежным средством платежного шлюза наравне с оплатой банковскими картами. При этом схема взаимодействия интернет-магазина и платежного шлюза остается неизменной.

Существует 2 способа использования платёжного средства «Альфа-Клик»: отображение на платёжной странице и создание запроса оплаты.

Оплата через PayByClick предназначена для клиентов интернет-банка «Альфа-Клик».

Ограничения и допущения Не меняется протокол связи Магазина с системой РБС.

Оплата только в рублях.

Оплата только для валидных клиентов Клика.

Отсутствует возможность размещения страницы ввода данных для платежа на стороне сайта магазина.

Отсутствует возможность частичного списания предавторизованного заказа (при двухфазном процессе).

Отсутствует возможность частичной оплаты, частичного или полного возврата средств (reversal или refund).

Для сверки используются существующие реестры платежей e-invoicing.

Участники бизнес-процесса «Клиент» (клиент и его интернет-браузер) «Магазин» (сайт онлайн-магазина) «РБС» (существующая и дорабатываемая система интернет-эквайринга РБС) «PayByClick» (разрабатываемое Альфа-Банком приложение PayByClick) Back-end: сервисы Gemini, сервисы E-Invoicing, сервис списка счетов.

Основной бизнес-процесс

Основной процесс:

описывает основной способ оплаты (через Клик), не учитывает негативные сценарии (обработку ошибок).

1. Клиент формирует корзину заказа на сайте Магазина.

2. После подтверждения заказа клиентом, Магазин регистрирует заказ в РБС.

3. РБС возвращает ID заказа в РБС и URL перенаправления клиента на платежную форму. В случае реализации выбора способа оплаты на стороне платежной страницы, выполняются шаги 4-5. В случае выбора оплаты на стороне магазина, на данном шаге передается URL для продолжения на шаге 7.

4. Магазин передает Клиенту redirect на URL, полученный на шаге 3.

5. Клиент открывает полученный URL, запрашивая платежную форму.

6. Клиенту отображается форма выбора типа оплаты: при выборе «по карте» продолжается существующий процесс РБС, при выборе «через Клик» происходит редирект клиента на PayByClick.

7. Клиент запрашивает форму авторизации с передачей параметров: ID заказа, URL для возврата на страницу запроса статуса заказа РБС (BackURL).

8. PayByClick запрашивает данные заказа по его ID (вызов WS на стороне РБС).

9. РБС возвращает данные заказа.

10-29. Операции аутентификации клиента Клика и авторизации оплаты через Клик.

30. PayByClick вызывает процесс подтверждения созданного инвойса (вызов WSInvoiceConfirm).

31. e-invoicing стартует асинхронный процесс подтверждения инвойса (см. описание ниже).

32. WSInvoiceConfirm возвращает «ОК».

33. PayByClick передает Клиенту редирект на URL РБС, полученный на шаге 6 и завершает работу.

34. Браузер клиента открывает полученный BackURL страницы запроса статуса оплаты.

35. На странице java-скриптом проверяется статус оплаты заказа (должен быть DEPOSITED для одностадийных платежей, APPROVED для двустадийных платежей или DECLINED)

36. Когда статус заказа получит необходимый статус, происходит редирект на страницу магазина для отображения статуса оплаты заказа

37. Пользователь получает страницу со статусом Тестирование

1. Зарегистрировать заказ. Это можно сделать либо посредством REST/ SOAP, либо перейдя по адресу https://test.paymentgate.ru/testpayment/merchants/alfa-test/test.html

Во 2 случае Вы увидите страницу:

На странице регистрации заказа необходимо указать: логин, пароль, номер заказа в системе магазина и адрес возврата.

Примечание: адрес возврата должен быть абсолютным, например http://bpc.ru

2. После заполнения необходимых данных и нажатия кнопки "списание" или "предавторизация" (в зависимости от схемы работы магазина- одно или двух стадийная) произойдет перенаправление на платежную страницу по адресу

https://test.paymentgate.ru/testpayment/merchants/alfa-test/payment_ru.html?mdOrder= :

3. Не заполняя данные по карте, нажимаем кнопку "Оплатить через АльфаКлик" и переходим на страницу авторизации в системе АльфаКлик по адресу

https://testjmb.alfabank.ru/PayByClick/login.jsp :

4. Вводим логин/пароль : 1821363/000000, авторизуемся:

5. Вводим одноразовый код 00000000:

Примечание: для оплаты нужно выбрать счет, оканчивающийся на 987.

После выбора счёта, с которого будут списаны средства и нажатия кнопки оплатить, происходит перенаправление обратно на страницу магазина (указанную при регистрации заказа в параметре returnUrl (если регистрация делалась посредством REST/ SOAP), либо в параметре адрес возврата (при регистрации через форму)) Оплата считается формально завершённой. Для уточнения статуса оплаты, магазину необходимо опрашивать систему РБС через стандартный запрос состояния заказа (getOrderStatus) и ожидать, когда заказ перейдёт в состояние APPROVED (средства захолдированы) для двухфазного процесса оплаты заказа или DEPOSITED (средства списаны) - для однофазного процесса.

Дополнение к описанию платежной страницы Помимо стандартных требований к платежной странице, описанных в документе "Оформление платежной страницы", необходимо на платёжной странице разместить элемент-кнопку input type="button" class="alfaclick" id="buttonPaymentAlfa" value="Оплатить через АльфаКлик" /" Также существует возможность загрузки магазину стандартной платежной страницы с уже размещенной кнопкой.

Запрос проведения оплаты через «Альфа-Клик»

Интерфейс на WebService Для оплаты заказа через внешнюю платежную систему используется запрос paymentOrderOtherWay со специальными параметрами.

Данную операцию можно осуществлять, если есть соответствующие права в системе.

Параметры запроса:

–  –  –

Пример запроса:

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mer=" http://engine.paymentgate.ru/webservices/merchant" soapenv:Header/ soapenv:Body mer:paymentOrderOtherWay order language="ru" orderId="8232a33f-c44f-48ec-b52f-0d63a88c50ae" paymentWay="ALFA_ALFACLICK" ip=" "/ /mer:paymentOrderOtherWay /soapenv:Body /soapenv:Envelope

Пример ответа:

soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:Body ns1:paymentOrderOtherWayResponse xmlns:ns1="http://engine.paymentgate.ru/webservices/merchant" return errorCode="0" errorMessage="Успешно" info="Ваш платёж обработан, происходит переадресация..." redirect=" https://testjmb.alfabank.ru/ALFAIBSR_FT4/?orderId=8232a33f-c44f-48ec-b52f-0d63a88c50ae&backUrl=http%3A%2F%2Fya.ru"/ /ns1:paymentOrderOtherWayResponse /soap:Body /soap:Envelope Интерфейс REST Для оплаты заказа через внешнюю платежную систему используется запрос paymentotherway.do со специальными параметрами.

Возможен только запрос POST.

URL для доступа к методу:

https://test.paymentgate.ru/testpayment/rest/paymentotherway.do Данную операцию можно осуществлять, если есть соответствующие права в системе.

Параметры запроса:

–  –  –

Пример запроса POST:

password=111111&userName=987&language=ru&MDORDER=c96a734c-e2c9-429c-8fda-aaa0030c8a92&paymentWay=ALFA_ALFACLICK

Пример ответа:

{"redirect":"http://testjmb.alfabank.ru/PayByClick/login.jsp?orderId=b37da970-e2b8-4729-a196-b4c2ab5bb401&backUrl=+","info":"Your order is proceeded, redirecting...","errorCode":0} Приложение 3. Спецификация дополнительных полей для платежей в авиакомерции Описание дополнительных полей Для улучшения контроля и качества в сфере борьбы с мошенничеством при предоставлении услуг Интернет Коммерции при продаже авиабилетов, необходимо при регистрации платежа в платежном шлюзе передавать дополнительную информацию о составе пассажиров и параметрах перелета.

Ниже приведена таблица, в которой указано название дополнительных полей, а так же их описание.

–  –  –

Дополнительные пояснения:

S{N}- указание на номер сегмента перелета. Под Сегментом в данном случае подразумевается перелет из одного аэропорта в другой без совершения авиатранспортом посадок. Параметр {N} может быть равен от 1 до 99, т.е. общее название будет изменяться от S1 до S99.

P{N}- указание на номер пассажира. Параметр {N} может изменяться в диапазоне от 1 до 99, т.е. общее название будет изменяться от P1 до P99 Пример заполнения дополнительных полей

Ниже приведена таблица с примером заполнения параметров:

–  –  –

Приложение 4. Коды ответа - расшифровка actionCode (ответ процессинга) Код ответа – это цифровое обозначение результата, к которому привело обращение к системе со стороны пользователя.

В системе определены следующие коды:

Action code - digital code of a result received after a client addressed to the system. The following codes exist in the system:

–  –  –

110 110 Decline. Invalid amount Неверно указана сумма транзакции. / Transaction amount is incorrect.

111 111 Decline. No card record Неверный номер карты. / Card number is incorrect.

–  –  –

209 209 Decline. Card limitations Превышены ограничения по карте. / Card limitations exceeded.

exceeded 400 400 Реверсал обработан. Реверсал обработан. / Reversal is processed.

–  –  –

903 903 Decline. Re-enter trans. Предпринята попытка выполнить транзакцию на сумму, превышающую лимит, заданный банком-эмитентом. / Attempt to perform a transaction of amount exceeding Issuing bank limit.

–  –  –

1004 1004 Стадия авторизации 1 Стадия авторизации 1. / Authorization phase 1.

1005 1005 Стадия авторизации 2 Стадия авторизации 2. / Authorization phase 2.

–  –  –

9001 9001 RBS internal error Внутренний код отказа РБС. / RBS internal error.

71015 1015 Decline. Input error Введены неправильные параметры карты. / Entered card details are incorrect.

–  –  –

151018 018 Decline. Processing Таймаут в процессинге. Не удалось отправить. / Processing timeout. Sending is failed.

timeout 151019 1019 Decline. Processing Таймаут в процессинге. Удалось отправить, но не получен ответ от банка. / Processing timeout timeout. Sending is success, response from the bank was not received.




Похожие работы:

«Федеральное государственное бюджетное образовательное учреждение высшего образования "Белгородский государственный технологический университет им. В.Г. Шухова" ПОЛОЖЕНИЕ О РЕАЛИЗАЦИИ ПРОЦЕССА Порядок применен...»

«2 Содержание Раздел 1. Перечень планируемых результатов обучения по дисциплине, соотнесенных с планируемыми результатами освоения образовательной программы.. 4 1.1.Перечень планируемых результатов обучения по дисциплине. 4 1.2. Планируемые результаты освоения образовательной программы.. 4...»

«УТВЕРЖДЕНО Председателем Правления И.А. Спиридоновым 09.04.2015 Введено в действие Приказом № 121-С от 09.04.2015 Изменение № 3 к Общим условиям создания и доверительного управления имуществом общего фонда банковского управления "Партнер"1. Изменить Приложение № 2, Приложение № 3, Пр...»

«Автоматизированная копия 461_450387 ВЫСШИЙ АРБИТРАЖНЫЙ СУД РОССИЙСКОЙ ФЕДЕРАЦИИ ПОСТАНОВЛЕНИЕ Президиума Высшего Арбитражного Суда Российской Федерации № 15792/12 Москва 9 апреля 2013 г. Президиум...»

«ПРОИЗВЕДЕНО ООО НПП ОРИОН СПБ г. Санкт-Петербург Загребский бульвар, д. 33 Вымпел-37 ООО НПП ОРИОН СПБ АВТОМАТИЧЕСКОЕ ЗАРЯДНО-ПРЕДПУСКОВОЕ УСТРОЙСТВО С СЕГМЕНТНЫМ ЖК ИНДИКАТОРОМ ДЛЯ АВТОМОБИЛЬНЫХ КИСЛОТНЫХ АККУМУЛЯТОРНЫХ БАТАРЕЙ, АКБ ТИПА AGM, EFB, АКБ С ГЕЛЕВЫМ ЭЛЕКТРОЛИТОМ: LONG LIFE, DEEP-CYCLE И АКБ ТИПА VARTA ВНИМАНИЕ! Соблюдай...»

«2 Copyright © 2008. Asay cybersystems Ltd. Все права сохранены. Краткое руководство компьютера AsayCyber A120 Информация в настоящем издании может периодически меняться, никаких обязательств об уведомлении кого бы то ни было, о таких изменениях компания не несет. Такие изменения будут включены в новые издания настоящего...»

«Предварительно утвержден Утвержден решением Совета директоров Решением единственного акционера ОАО "Росэлектроника" Распоряжение Росимущества от "9 " июня 2006 г. № 2874-р от "30" июня 2006 г. ГОДОВОЙ ОТЧЕТ Открытого акционерного общества РОССИЙСКАЯ ЭЛЕКТРОНИКА за 2005 ГОД г. Москва 2...»

«УДК 666.762 Т.Б. ГОНТАР, асистент, УИПА, Харьков, С.М. ВИЛКОВ, канд. техн. наук, приват-проф., УИПА, Харьков, О.Б. СКОРОДУМОВА, докт. техн. наук, проф., УИПА, Харьков РАЗРАБОТКА ОПТИМАЛЬНОГО ГРАНУЛОМЕТРИЧЕСКОГО СОСТАВА ЭКЗОТЕРМИЧЕСКИХ ГРАНУЛИРОВАННЫХ СМЕСЕЙ У роботі досліджений вплив розміру гранул на структурно-механіч...»

«Acta Slavica Iaponica, Tomus 23, pp. 1-36 Articles Последние русско-японские переговоры перед войной 1904-1905 гг. (взгляд из России) Игорь Лукоянов Ход русско-японских переговоров 1903 г. не раз был предметом изучения. Впервые это сделал П.Н. Симан...»

«особенностей. Общими способами образования кличек собак всех пород являются онимизация апеллятивов (Набат, Скрипка, Сокол) и трансонимизация на базе антропонимов и топонимов (Лель, Том, Арагва). Однако трансонимизация на базе антропонимов для кличек легавых является основным способо...»

«Приложение № 1 УТВЕРЖДАЮ: /Локтионов М.В./ Председатель Закупочной комиссии " 15 " марта 2013 года Согласовано на заседании Закупочной комиссии Протокол № 2-1 от " 15 " марта 2013 года Конкурсная документация Открытый одноэтапный конкурс без п...»

«Приложение № 4 к Условиям открытия и обслуживания расчетного счета Перечень тарифов и услуг, оказываемых клиентам подразделений Северного банка ПАО Сбербанк на территории Ярославской области (действуют с 30.11.2015) Стоимость услуги1 Наименование услуги...»

«Содержание Введение Предварительные условия Требования Используемые компоненты Условные обозначения Системное время, пользовательское время, IOWait, мягкий IRQ и IRQ Предупреждения привязки ЦП Идентификация Процесса, который Использование Большая часть ЦП Высокий IOWait Высокий IOWait из-за Общего Разделения Идентификация пр...»








 
2017 www.book.lib-i.ru - «Бесплатная электронная библиотека - электронные ресурсы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.