money. web viewПРИЛОЖЕНИЕ № 5. Протокол обмена информацией...

ПРИЛОЖЕНИЕ № 5.

Протокол обмена информацией при осуществлении

переводов: HTTP- и email-уведомления

3.0.1, Протокол редакция от 03.02.2015ОГЛАВЛЕНИЕ1. General information.......................................................................................................................2

1.1. The purpose of this document.............................................................................................2

1.2. The Counterparty’s integration...........................................................................................3

2. Interaction: a general overview..................................................................................................4

3. The payment form......................................................................................................................5

4. HTTP-notifications about payments........................................................................................10

4.1. Format for interaction........................................................................................................10

4.2. Checking orders (сheckOrder)..........................................................................................11

4.2.1. Format of the Operator’s request...............................................124.2.2. Format of the Counterparty’s response......................................15

4.3. Notification of payment (paymentAviso)..........................................................................17

4.3.1. Format of the Operator’s request...............................................174.3.2. Format of the Counterparty’s response......................................19

4.4. Rules for the Counterparty when processing HTTP-notifications....................................20

5. Email-notifications about payments.........................................................................................21

6. Appendices...............................................................................................................................23

6.1. The Counterparty’s integration parameters.......................................................................23

6.2. Particulars of interaction when payment method is cash via payment kiosks..................27

6.3. Particulars of interaction when payment is made through third-party payment systems..29

ANNEX #5.

Yandex.Money to Merchant Integration Protocol: HTTP and

Email Notifications.

Protocol 3.0.1, revised on February 3, 2015

TABLE OF CONTENTS1. General information..........................................................................................................................................

1.1. The purpose of this document.....................................................................................................................

1.2. The Counterparty’s integration...................................................................................................................

2. Interaction: a general overview.........................................................................................................................

3. The payment form.............................................................................................................................................

4. HTTP-notifications about payments...............................................................................................................

4.1. Format for interaction...............................................................................................................................

4.2. Checking orders (сheckOrder)..................................................................................................................

4.2.1. Format of the Operator’s request.................................................................4.2.2. Format of the Counterparty’s response........................................................

4.3. Notification of payment (paymentAviso).................................................................................................

4.3.1. Format of the Operator’s request.................................................................4.3.2. Format of the Counterparty’s response........................................................

4.4. Rules for the Counterparty when processing HTTP-notifications............................................................

5. Email-notifications about payments................................................................................................................

6. Appendices......................................................................................................................................................

6.1. The Counterparty’s integration parameters..............................................................................................

6.2. Particulars of interaction when payment method is cash via payment kiosks..........................................

6.4. Particulars of interaction when payment method is bank card via mPOS........................31

6.5. Daily payment reports.......................................................................................................31

6.6. Payment methods..............................................................................................................35

6.7. Types of data.....................................................................................................................36

1. Общие сведения1.1. Назначение документа

Данный документ описывает взаимодействие ОООНКО« . » ( – , . ) ЯндексДеньги далее Оператор ЯндексДеньги с

( – ) , информационной системой далее ИС Контрагента необходимое для уведомления Контрагента о совершенном в его пользу переводе

( – ) .далее также платеж в режиме реального времени

, Оператор обеспечивает прием платежей осуществляемых : , различными способами с банковских карт из электронных

( . ), кошельков в том числе со счетов ЯндексДенег наличными через, . , терминалы со счетов мобильных телефонов Перечень способов , доступный конкретному Контрагенту зависит от условий договора

и дополнительно контролируется настройками на стороне.Оператора

Упрощенно процесс взаимодействия можно представить в виде :нескольких последовательных действий

1. Передача Оператору данных о заказе и способе его оплаты ( ).осуществляется с помощью браузера плательщика

2. (Уведомление Контрагента о платеже осуществляется , HTTP- Оператором возможна отправка или email- ).уведомлений

3. Формирование реестра принятых в пользу Контрагента ( ).переводов пересылается Оператором по электронной почте

4. Перечисление денежных средств на банковский счет

6.3. Particulars of interaction when payment is made through third-party payment systems.........................

6.4. Particulars of interaction when payment method is bank card via mPOS................................................

6.5. Daily payment reports...............................................................................................................................

6.6. Payment methods......................................................................................................................................

6.7. Types of data.............................................................................................................................................

1. General information1.1. The purpose of this document

This document describes the protocol by which Yandex.Money (hereinafter ‘Operator’) will interact with the information system (IS) of the Counterparty to notify the Counterparty in real time about complete transactions (hereinafter ‘payments’) made in the interest of the Counterparty.

The Operator shall ensure receipt of payments made by various methods: bank cards, electronic wallets (including Yandex.Money e-wallets), cash via payment kiosks, and mobile phone balances. The payment methods that are available to a particular Counterparty will depend on the provisions of the agreement and are further controlled by the Operator’s settings.

If simplified, the interaction process can be presented as a few successive steps:

1. The Operator transmits information about the order and the payment method (performed using the payer’s browser).

2. The Counterparty receives notification about the payment (performed by the Operator either by HTTP or email notification).

3. A report of the payments accepted in the interest of the Counterparty is generated (sent by the Operator via email).

4. Funds are transferred to the Counterparty’s bank account.5. If necessary, refunds of successful payments are made to payers as initiated by

the Counterparty.

.Контрагента5. – При необходимости возврат успешных платежей

.плательщикам по инициативе Контрагента

. 1–3 , . 4–5 Пп описаны далее по тексту пп выходят за рамки данного. документа Для работы с возвратами Контрагенту дополнительно

Merchantпотребуется выпустить сертификат и реализовать протокол Web Services (MWS). Процедура обмена сертификатами и протоколMWS .описаны в отдельных документах

1.2. Подключение Контрагента . :Контрагенту доступны две схемы подключения кЯндексДеньгам

схема с отправкой уведомлений о платежах в адрес HTTP ( –Контрагента посредством вызовов по протоколу далее

HTTP- , схема подробное описание взаимодействия представлено в разделе 4 «HTTP-notifications about »);

схема с отправкой уведомлений о платежах в адрес ( – email- ,Контрагента по электронной почте далее схема

подробное описание представлено в разделе 5 «Email-notificationsabout »).

, Принципиальное различие в том что email- схема не предполагает , HTTP- обратной связи а схема позволяет Контрагенту производить

- . онлайн проверку параметров заказа при оплате Если Контрагенту необходимо в режиме реального времени демонстрировать

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

. . . ЯндексДеньгам Схемы не могут использоваться одновременно Количество доступных способов оплаты от выбранной схемы не

.зависит

В зависимости от схемыКонтрагент должен сообщить Оператору : URL' ( ) параметры подключения ы адрес электронной почты для

, URL' отправки уведомлений ы для редиректа плательщика после, оплаты адрес электронной почты для отправки реестров принятых

Steps 1-3 are described below. Steps 4-5 are beyond the scope of this document. To work with refunds, the Counterparty will also need to issue a certificate and implement the Merchant Web Services (MWS) protocol. The procedure for exchanging MWS certificates and the MWS protocol are described in separate documents.

1.2. The Counterparty’s integrationThe Counterparty has the option of integrating with Yandex.Money according to one of two integration schemes:

the scheme wherein the Operator sends payment notifications to the Counterparty via the HTTP protocol (hereinafter - HTTP-scheme, a detailed description of interactions is presented in Section 4 ‘HTTP-notifications about payments’);

the scheme wherein the Operator sends payment notifications to the Counterparty via email (hereinafter – email scheme, a detailed description is presented in Section 5 ‘Email-notifications about payments’).

The main difference between the two schemes is that the email scheme does not allow for feedback, whereas the HTTP scheme allows the Counterparty to perform online review of order parameters during the payment process. If the Counterparty needs to show the payer on its website and in real time that the goods or services have been paid for, the Counterparty must use the HTTP-scheme to integrate with Yandex.Money. Both schemes cannot be used simultaneously. The number of available payment methods does not depend on the scheme.

Depending on the scheme, the Counterparty must inform the Operator of the integration parameters: URLs (email address) for delivery of notifications, URLs for redirecting payers after completion of payment, email address for delivery of daily payment reports, etc. (detailed information can be found in section 6.1 ‘The Counterparty’s integration parameters’).

In response, the Operator will provide the settings for accessing Yandex.Money’s testing environment. After the testing procedure is complete, the Operator will provide the Counterparty with settings for information exchange in the production

. . ( – переводов и т д подробная информация в разделе 6.1 «The Counterparty’s integration parameters»).

Оператор в ответ предоставляет настройки для доступа к тестовой . , – среде ЯндексДенег а после завершения процедуры отладки

« » . MWS настройки для боевого взаимодействия Подключение к .производится отдельно

2. Обобщенное описание взаимодействия0. « Контрагент размещает на странице оплаты заказа платежную

» ( форму с данными заказа и указанием способов оплаты в ряде « » случаев возможно размещение платежнойформы на сайте

: Оператора https://money.yandex.ru/shops.xml).

При HTTP-схеме email-При схеме

environment. Integration to MWS is performed separately.

2. Interaction: a general overview0. The Counterparty places a ‘payment form’ on the order payment page with the order information and payment method options (in some cases the ‘payment form’ may be placed on the Operator’s site: https://money.yandex.ru/shops.xml).

HTTP integration scheme Email integration scheme

1-2. The payer’s browser transmits the completed form to the Operator IS.

3. The Operator uses the data received to determine the payment method and displays the payment confirmation page to the payer.

4. The payer enters additional information (e.g. bank card details) and confirms the payment.

https://money.yandex.ru/shops.xml

подключения подключения

1-2. Браузер плательщика передает заполненнуюформу вИС.Оператора

3. На основании полученных данныхОператор определяет способ оплаты и отображает для плательщика страницу подтверждения

.платежа

4. ( , Плательщик вводит дополнительные данные например ) .реквизиты банковской карты и подтверждает платеж

5. Перед тем как провести, платеж Оператор отправляет в

ИСКонтрагента запрос« ( heckOrder)».Проверка заказа с

5. .Шаг пропускается

6. Контрагент подтверждает корректность заказа либо отказывается от проведения

.платежа

6. .Шаг пропускается

7-8. ЕслиИСКонтрагента « ответила на запрос Проверка

» , заказа положительно то Оператор списывает деньги с

плательщика и отображает для него результат проведения

.платежа

7-8. Оператор списывает деньги с плательщика и отображает

для него результат проведения.платежа

9. « На странице результата отображается ссылка Вернуться в».магазин

URL, , на который будет перенаправлен плательщик определяется.Контрагентом

10-11. Пофакту успешного прохождения платежа

Оператор отправляет ИС Контрагента запрос

10. Пофакту успешного прохождения платежа

Оператор отправляет ИС email- Контрагента уведомление

5. Before the payment is completed, the Operator sends the Counterparty IS a request to review the order (‘сheckOrder’).

5. This step is skipped.

6. The Counterparty confirms the accuracy of the order or declines the payment.

6. This step is skipped.

7-8. If the Counterparty IS gives an affirmative response to the ‘Check order’ request, the Operator debits money from the payer and displays the payment result to the payer.

7-8. The Operator debits money from the payer and displays the payment result to the payer.

9. On the payment result page the link ‘Return to store’ is displayed.

The Counterparty determines the URL where the payer will be redirected.

10-11. If the payment is completed successfully, the Operator will send the Counterparty IS a ‘Notification of payment’ (paymentAviso) request.

10. If the payment is completed successfully, the Operator will send the Counterparty IS an email-notification about the payment.

Please note: if the payment method is anything other than a Yandex.Money e-wallet or a bank card, interaction between the Operator and Counterparty involve a few special differences. A description of these scenarios can be found in section 6 ‘Appendices’.

Once a day, the Operator sends the Counterparty a daily payment report via email. The Counterparty should check that the list of successful payments in its IS’ data matches the list of operations in the payment report and inform the Operator of any discrepancies. The format of the payment report is described in section 6.3 ‘Daily payment reports’.

« Уведомление о переводе(paymentAviso)».

.о переводе

:Обратите внимание взаимодействие Оператора и Контрагента в , случае оплаты заказа способом отличным от платежа из кошелька. , ЯндексДенег и оплаты с произвольной банковской карты имеет

. ряд особенностей Описания таких сценариев приведены в разделе 6 «Приложения».

2.1. Раз в суткиОператор отправляет Контрагенту по электронной почте реестр принятых переводов. Контрагент должен

сверять список успешных платежей по данным своейИС со списком операций из реестра и сообщать Оператору о

. расхождениях Формат реестра описан в разделе 6.35 «

3. The payment formThe Counterparty places the payment form on the payment page. It determines the order parameters and the payment method. The act of sending via the payer’s browser the payment form at the standard address (http://money.yandex.ru/eshop.xml) initiates the creation and processing of an order for transfer on the side of the Operator.

Sample payment form:

http://money.yandex.ru/eshop.xml

2.2.

Особенности взаимодействия при оплате через внешние платежные системы».

3. Платежная форма , Платежная форма размещается Контрагентом на странице оплаты . определяет параметры заказа и способ платежа Отправка через

браузер плательщика платежнойформы по стандартному адресу(http://money.yandex.ru/eshop.xml) инициирует на стороне Оператора

.формирование и обработку распоряжения на перевод

Пример :платежной формы

When transmitting information about the order and payment method, the Counterparty should use the parameters from the table below. All parameters are case sensitive.

Table 3.1. Payment form parameters

Parameter Type Description

<!—Values for all fields are arbitrary and provided only as examples -->

<form action="https://money.yandex.ru/eshop.xml" method="post">

<!—Required fields -->

<input name="shopId" value="1234" type="hidden"/>

<input name="scid" value="4321" type="hidden"/>

<input name="sum" value="100.50" type="hidden">

<input name="customerNumber" value="abc000" type="hidden"/>

<!—Optional fields -->

<input name="shopArticleId" value="567890" type="hidden"/>

<input name="paymentType" value="AC" type="hidden"/>

<input name="orderNumber" value="abc1111111" type="hidden"/>

<input name="cps_phone" value="79110000000" type="hidden"/>

<input name="cps_email" value="[email protected]" type="hidden"/>

<input type="submit" value="Pay"/>

</form>

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

регистрозависимые.

3.1.Таблица Параметры платежнойформы

Параметр Тип Описание

Reserved parameters:

shopId xs:long, required field

Counterparty’s ID. Issued by the Operator.

shopArticleId xs:long, optional field

Article ID. Issued by the Operator. Applies if the Counterparty uses various payment forms for different articles (goods).

scid xs:long, required field

Counterparty's payment form ID. Issued by the Operator.

sum CurrencyAmount, required field

Order total.

customerNumber

xs:normalizedString, up to 64 characters, required field

Payer ID in the Counterparty IS. The ID can be the payer’s contract number, login, etc.

Multiple payments may be applied for a single customerNumber.

orderNumber xs:normalizedString, up to 64 characters, optional field

Unique order number in the Counterparty IS. The uniqueness is verified by the Operator in combination with the parameter shopId.

If a payment with the same order number has been successfully completed already, repeated attempts to pay will be rejected by the Operator.

shopSuccessURL xs:string, up to 250 characters, optional field

URL for payer redirection when payment is successful. Applies only if the corresponding Counterparty integration option is selected (see section 6.1Counterparty’s integration parameters’).

shopFailURL xs:string, up to 250 characters, optional field

URL for payer redirection if an error occurs. Applies only if the corresponding Counterparty integration option is selected.

cps_email xs:string, up to 100 Payer’s email address. If it is present, the



<form action="https://money.yandex.ru/eshop.xml" method="post">



<input name="shopId" value="1234" type="hidden"/>

<input name="scid" value="4321" type="hidden"/>

<input name="sum" value="100.50" type="hidden">

<input name="customerNumber" value="abc000" type="hidden"/>



<input name="shopArticleId" value="567890" type="hidden"/>

<input name="paymentType" value="AC" type="hidden"/>

<input name="orderNumber" value="abc1111111" type="hidden"/>

<input name="cps_phone" value="79110000000" type="hidden"/>

<input name="cps_email" value="[email protected]" type="hidden"/>

<input type="submit" value="Заплатить"/>

</form>

characters, optional field

corresponding field on the payment confirmation page will be filled in automatically (step 3 on the flow chart above).

cps_phone xs:string, up to 15 characters, numbers only, optional field

Payer’s phone number. If it is present, the corresponding field on the payment confirmation page will be filled in automatically (step 3 on the flow chart above). The phone number is used for cash payments via payment kiosks.

paymentType xs:normalizedString,

up to 5 characters, optional field

Payment method. Example:

РС – payment from a Yandex.Money wallet; АС – payment by any bank card.

For the full list of values, see Table 6.6.1.

Please note:

The absence of the paymentType parameter is interpreted as payment from a Yandex.Money wallet;

If the payment form contains a payment method that the Counterparty is not authorized to accept, the payer won’t be able to make the payment.

Parameters added by the Counterparty:

Any names other than listed above

xs:string Parameters added by the Counterparty to the payment form will be saved and transmitted to the Counterparty IS with the ‘Check order’ (checkOrder) and ‘Notification of payment’ (paymentAviso) requests.

The total length of all parameters added by the Counterparty shall not exceed 4,096 characters.

Please note: email notifications about payments do not feature parameters added by the Counterparty. To transmit additional payment details, the Counterparty can use the standard parameters listed below.

Reserved parameters used in email notifications about payments:

:Служебные параметры ustNameс xs:string, optional field

Payer’s full name.

сustAddr xs:string, optional field

Delivery address or payer’s residential address.

ustEMailс xs:string, optional field

Payer’s email address, for email notifications only.

orderDetails xs:string, optional field

Order details: the list of purchased goods, their quantity, purpose of payment, etc.

4. HTTP-notifications about payments4.1. Format for interactionWhen integrating according to the HTTP-scheme, the Counterparty should determine the address where it will receive HTTP-notifications from the Operator.

Information from the Operator is transmitted to the Counterparty IS via HTTP/1.1 protocol using POST request method. The message’s parameters are packed as a set of POST-request parameters in the form of the pairs ‘name=value’. Content-Type: application/x-www-form-urlencoded, charset – UTF-8.

The ‘md5’ request parameter contains the result of the hash function from the concatenation of the message parameters with a secret word, which the Counterparty will specify during the integration process. The Counterparty should check the result of the ‘md5’ parameter (the algorithm can be found in section 4.4 ‘Rules for the Counterparty when processing HTTP-notifications’) and decline to process the request if the check is unsuccessful. A successful hash check will confirm:

• that the request was sent by the Operator;• the information in the request is authentic.

We also recommend checking the IP-addresses from which the Counterparty IS receives requests (a list of the Operator’s IP-addresses can be provided during the

shopId xs:long, обязательный

, Идентификатор Контрагента выдается.Оператором

shopArticleId xs:long, необязательный

, Идентификатор товара выдается. , Оператором Применяется если Контрагент

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

scid xs:long, обязательный

, Номер витриныКонтрагента выдается.Оператором

sum CurrencyAmount, обязательный

.Стоимость заказа

customerNumber

xs:normalizedString,

64 , до символовобязательный

Идентификатор плательщика вИС. Контрагента В качестве идентификатора

может использоваться номер договора, . .плательщика логин плательщика и т п

Возможна повторная оплата по одному и .томуже идентификатору плательщика

orderNumber xs:normalizedString,

64 , до символовнеобязательный

Уникальный номер заказа в ИС .Контрагента Уникальность контролируется Оператором в

сочетании с параметром shopId.

Если платеж с таким номером заказа уже , был успешно проведен то повторные

попытки оплаты будут отвергнуты.Оператором

shopSuccessURL xs:string, 250 до, символов

необязательный

URL, на который нужно отправить . плательщика в случае успеха перевода Используется при выборе соответствующей

( . опции подключения Контрагента см раздел 6.1 «The Counterparty’s integration parameters

shopFailURL xs:string, 250 до, символов

необязательны

URL, на который нужно отправить . плательщика в случае ошибки оплаты Используется при выборе соответствующей

integration process).

In order to ensure the security of payment information during the interaction between the Operator and Counterparty IS, one of the conditions listed below must be met:

3. the transmission of information takes place via a secure channel (the Counterparty uses the HTTPS protocol for receiving messages from the Operator);

4. the Operator’s messages are encrypted prior to being sent(*).* This requires that the Counterparty integrate according to the scheme XML/PKSC#7. In this case messages are transmitted by the Operator in the form of XML-documents embedded in PKCS#7 cryptographic message containers. Data are signed by the Operator’s SSL-certificate. Contact your account manager for detailed information about the XML/PKCS#7 integration scheme.

The Counterparty should return the result of processing the Operator’s request in the form of an XML-document in the body of the response to the HTTP-request. A document is created according to the standard XML 1.0 (Fifth Edition), which can be found at the following address: http://www.w3.org/TR/xml/. Names of elements and attributes are case sensitive. Content-Type: application/xml, charset – UTF-8.

4.2. Checking orders (сheckOrder)This section covers the request for validation of the order parameters. This step will help the Counterparty prevent errors that can occur when the payment form is being sent through the payer’s browser.

If the response from the Counterparty is successful, the Operator will invite the payer to pay for the order. If the payment is successful, the Operator will send the Counterparty a ‘Notification of payment’.

Please note:

http://www.w3.org/TR/xml/

й .опции подключения Контрагента

cps_email xs:string, 100 до, символов

необязательный

. Адрес электронной почты плательщика , Если он передан то соответствующее поле

на странице подтверждения платежа будет ( 3 ).предзаполнено шаг на схеме выше

cps_phone xs:string, 15 до, символов

, только цифрынеобязательный

. Номермобильного телефона плательщика , Если он передан то соответствующее поле

на странице подтверждения платежа будет ( 3 ). предзаполнено шаг на схеме выше

Номер телефона используется при оплате .наличными через терминалы

paymentType xs:normalizedString,

5 , до символовнеобязательный

. :Способ оплаты Например

PC – . ;оплата из кошелька в ЯндексДеньгах AC – оплата с произвольной банковской

.карты . 6.6.1.Полный список значений см в таблице

Обратите внимание:

отсутствие paymentType интерпретируется . ;как оплата из кошелька в ЯндексДеньгах

если в платежной форме указан способ , оплаты который не разрешен для

, Контрагента плательщик не сможет .совершить платеж

, :Параметры добавляемые Контрагентом

Любые, названия отличные от

перечисленн ых выше

xs:string , Параметры добавленные Контрагентом в , платежнуюформу будут сохранены и

переданыИСКонтрагента в запросах« » « Проверка заказа и Уведомление о

».переводе

Суммарная длина всех добавленных Контрагентом параметров не должна

4096 .превышать символов

4. A ‘Check order’ request is usually created before money is debited from the payer’s account. During this step, the Counterparty can refuse to accept the payment.

5. When the payment method is a bank card, payment authorization occurs before the ‘Check order’ request is created. If the Counterparty refuses the payment, money will automatically be returned to the card.

6. When the payment method is anything other than a Yandex.Money e-wallet, third-party systems may charge additional commission. In that case, if the Counterparty refuses the payment, funds will be returned to the payer less the third-party’s commission.

4.2.1. Format of the Operator’s requestTable 4.2.1.1. checkOrder request parameters


requestDatetime xs:dateTime The time when the request is generated in the Operator IS.

action xs:normalizedString, up to 16 characters

Request type. Value: ‘checkOrder’ (without quotation marks).

md5 xs:normalizedString, exactly 32 hexadecimal characters, all caps.

MD5 hash of the payment form parameters. Rules for generating it are described in section 4.4 ‘Rules for the Counterparty when processing HTTP-notifications’.

shopId xs:long Counterparty’s ID assigned by the Operator.

shopArticleId xs:long Article ID assigned by the Operator.

invoiceId xs:long Unique transaction number in the Operator IS.

orderNumber xs:normalizedString, Order number in the

Обратите внимание: email- в уведомлениях произвольные параметрыКонтрагента не

. передаются Для передачи дополнительных данных о платеже Контрагент может

воспользоваться стандартными, .параметрами перечисленными ниже

, email- :Служебные параметры используемые в уведомлениях о переводе

custName xs:string, необязательный

.ФИОплательщика

custAddr xs:string, необязательный

Адрес доставки товара или адрес .проживания плательщика

custEMail xs:string, необязательный

, Адрес электронной почты плательщика email- .только для отправки в уведомлениях

orderDetails xs:string, необязательный

: Детали заказа список приобретенных, , товаров их количество назначение платежа

. .и т п

4. HTTP-уведомления о переводах4.1. Формат взаимодействия

При подключении по HTTP- , схеме Контрагент определяет адрес по которому он будет принимать HTTP- .уведомления от Оператора

Данные от Оператора передаются вИСКонтрагента посредством HTTP/1.1, POST. вызова по протоколу методом Параметры сообщения

POST- упаковываются как набор параметров запроса в виде пар« = ». MIME- : application/x-www-form-urlencoded, имя значение тип

– UTF-8.кодировка символов

up to 64 characters Counterparty IS. Present only if specified on the payment form.

customerNumber xs:normalizedString, up to 64 characters

Payer ID (sent in the payment form) with the Counterparty: contract number, mobile phone number, etc.

orderCreatedDatetime xs:dateTime The time when the order is registered in the Operator IS.

orderSumAmount CurrencyAmount Order total. Can differ from the payment amount if the user paid in a currency other than the one specified on the payment form. In this case, the Operator assumes all conversion transactions.

orderSumCurrencyPaycash CurrencyCode Currency code for the order total.

orderSumBankPaycash CurrencyBank The Operator's processing center code for the order total.

shopSumAmount CurrencyAmount Amount to be received on the Counterparty's bank account: the order total less the Operator's commission.

shopSumCurrencyPaycash CurrencyCode Currency code for shopSumAmount.

shopSumBankPaycash CurrencyBank The Operator's processing center code for shopSumAmount.

paymentPayerCode YMAccount Number of the account in the

«md5» - Параметр запроса содержит значение хэш функции от , свертки параметров сообщения совместно с секретным словом

. указаннымКонтрагентом при подключении Контрагенту следует «md5» ( проверять значение параметра алгоритм приведен в разделе

4.4 « HTTP- Правила обработки уведомленийКонтрагентом») и . отказывать в обработке запроса при неуспехе проверки Успех

:проверки хэша удостоверяет

• , ;факт того что запрос отправленОператором• .факт целостности данных запроса

IP- , Дополнительно рекомендуется проверять адреса с которыхИС ( IP Контрагента принимает запросы список Оператора можно

).получить при подключении

При взаимодействииИСОператора и Контрагента для защиты информации о платежах обязательно соблюдение одного из

:условий ниже

1. передача информации происходит по защищенному каналу ( HTTPS Контрагент использует протокол для приема сообщений

);от Оператора2. (*).сообщения Операторашифруются перед отправкой

* XML/PKCS#7.Требуется подключение Контрагента по схеме В этом случае сообщения передаютсяОператором в виде

XML- , PKCS#7. документа вложенного в криптоконтейнер SSL- . Данные подписываются сертификатомОператора Для

получения подробной информации о схеме подключенияXML/PKCS#7 .обратитесь к своемуменеджеру

Результат выполнения запроса Оператора должен быть возвращен XML- HTTP- . Контрагентом в виде документа в теле ответа на запрос

XML 1.0 (Fifth Edition), Документ формируется согласно стандарту : опубликованному по адресу http://www.w3.org/TR/xml/. Имена

. MIME- : элементов и атрибутов чувствительны к регистру типapplication/xml, – UTF-8.кодировка символов

Operator IS where the payment is made from.

paymentType xs:normalizedString Payment method used. The list of possible values can be found in Table 6.6.1.

Any names other than listed above

xs:string Parameters added to the payment form by the Counterparty.

Please note: the Operator’s requests may contain parameters that are not described in this document. The Counterparty should ignore such parameters.

Sample ‘сheckOrder’ request parameters:

requestDatetime 2011-05-04T20:38:00.000+0

action checkOrder

md5 8256D2A032A35709EAF156270C9EFE2E

shopId

shopArticleId

13

456

invoiceId 1234567

customerNumber 8123294469

orderCreatedDatetime 2011-05-04T20:38:00.000+0

orderSumAmount 87.10

orderSumCurrencyPaycash 643

orderSumBankPaycash 1001

shopSumAmount 86.23

shopSumCurrencyPaycash 643

4.2. Проверка заказа (checkOrder) . Запрос проверки корректности параметров заказа Этотшаг

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

В случае успешного ответа Контрагента Оператор предлагает плательщику оплатить заказ и при успехе отправляет Контрагенту

« ».Уведомление о переводе

:Обратите внимание

1. « » Формирование запроса Проверка заказа чаще всего . происходит до списания денег со счета плательщика На этом

шаге Контрагент может отказаться .от приема перевода2. При оплате с банковской карты авторизация платежа

« ». производится до формирования запроса Проверка заказа В случае отказа Контрагента деньги будут автоматически

.возращены на карту3. , При оплате способами отличными от платежа из кошелька в

. , ЯндексДеньгах внешние системы могут брать . дополнительную комиссию Тогда при отказе Контрагента от

приема перевода средства возвращаются плательщику за .вычетом такой комиссии

4.2.1. Формат запроса Оператора 4.2.1.1.Таблица checkOrderПараметры запроса операции


requestDatetime xs:dateTime Момент формирования запроса в ИС

.Оператора

action xs:normalizedString, до 16 символов

. : Тип запроса Значение«checkOrder» ( без

).кавычек

md5 xs:normalizedString, MD5- хэш параметров

shopSumBankPaycash 1001

paymentPayerCode 42007148320

paymentType AC

MyField Field added by the Counterparty

4.2.2. Format of the Counterparty’s responseTable 4.2.2.1. checkOrder response parameters


performedDatetime xs:dateTime The time the request is processed according to the time of the Counterparty IS.

code xs:int Processing result code. The list of possible values can be found in the table below.

shopId xs:long Counterparty ID. Should be identical to the request's ‘shopId’ field.

invoiceId xs:long Transaction ID in the Operator IS. Should be identical to the request's ‘invoiceId’ field.

orderSumAmount CurrencyAmount

Order total in the currency determined by the ‘orderSumCurrencyPaycash’ request parameter.

message xs:string, up to 255 characters

Message if the payment is declined.

techMessage xs:string, up to 64 characters

Additional comment to the Counterparty’s response. Generally used as extra information about errors. Optional field.

Table 4.2.2.2. checkOrder request processing result codes

32 ровношестнадцатерич

, ных символа в верхнем регистре

, платежной формы правила формирования описаны в разделе 4.4

« Правила обработкиHTTP- уведомленийКонтрагентом».

shopId xs:long Идентификатор, Контрагента

присваиваемый.Оператором

shopArticleId xs:long , Идентификатор товара присваиваемый

.Оператором

invoiceId xs:long Уникальный номер транзакции вИС

.Оператора

orderNumber xs:normalizedString, до 64 символов

Номер заказа в ИС. Контрагента

, Передается только если был указан в

.платежной форме

customerNumber xs:normalizedString, 64 до символов

Идентификатор плательщика

( присланный в ) платежной форме на

: стороне Контрагента , номер договора

мобильного телефона и. .т п

orderCreatedDatetime xs:dateTime Момент регистрации .заказа в ИСОператора

orderSumAmount CurrencyAmount . Стоимость заказа

Code Value Description

0 Successful The Counterparty has given its permission and is ready to accept the payment.

1 Authorization error

md5 parameter value does not match the hash function calculation result. The Operator considers the error final and will not perform the payment.

100 Payment declined

The payment with the given parameters cannot be accepted. The Operator considers the error final and will not perform the payment.

200 Bad Request The Counterparty IS is unable to process the request. The Operator considers the error final and will not perform the payment.

Sample response to checkOrder request when the processing is successful:

<?xml version="1.0" encoding="UTF-8"?>

<checkOrderResponse performedDatetime="2011-05-04T20:38:01.000+04:00"

code="0" invoiceId="1234567"

shopId="13"/>

Sample response to checkOrder request when an error occurs: the IS rejected the payment at the order review stage:


<checkOrderResponse performedDatetime="2011-05-04T20:38:01.000+04:00"


shopId="13"

message="The phone number specified does

Может отличаться от , суммы платежа если

пользователь платил в, валюте которая

отличается от указанной в платежной

. форме В этом случае Оператор берет на себя

.все конвертации

orderSumCurrencyPaycash CurrencyCode Код валюты для суммы.заказа

orderSumBankPaycash CurrencyBank Код процессингового центра Оператора для .суммы заказа

shopSumAmount CurrencyAmount Сумма к выплате / Контрагенту на р с

( стоимость заказа минус комиссия

).Оператора

shopSumCurrencyPaycash CurrencyCode Код валюты дляshopSumAmount.

shopSumBankPaycash CurrencyBank Код процессингового центра Оператора для

shopSumAmount.

paymentPayerCode YMAccount Номер счета в ИС, Оператора с которого

.производится оплата

paymentType xs:normalizedString . Способ оплаты заказа Список значений

6.6.1.приведен в таблице

, Любые названия xs:string , Параметры

not exist"

techMessage="Invalid phone number"/>

4.3. Notification of payment (paymentAviso)This section covers how the Counterparty is notified that a payment has been performed. This request confirms that the funds transfer between the payer and the Counterparty was successfully completed and that the Counterparty is now obligated to issue the payer the goods he or she ordered.

Please note: during this step the Counterparty cannot refuse to accept the payment.

4.3.1. Format of the Operator’s requestThe parameters of the ‘Notification of payment’ request match the parameters in the ‘Check order’ request (see the description in section 4.2.1). The parameters specific to the operation paymentAviso are outlined in the table below:

Table 4.3.1.1. paymentAviso request parameters


action xs:normalizedString, up to 16 characters

Request type, value: paymentAviso.

paymentDatetime xs:dateTime The time the payment for an order is registered with the Operator IS.

cps_user_country_code xs:string, 2 characters

Two-letter country code of the payer in accordance with ISO 3166-1 alpha-2.

Please note:

The payer’s country code (cps_user_country_code) is determined from data that the Operator receives from certain technical sources associated with the chosen payment method. The payer does not confirm these data. The

отличные от перечисленных

выше

добавленные Контрагентом в

.платежнуюформу

:Обратите внимание запросыОператора могут содержать, . параметры не описанные в этом документе Контрагенту следует их

.игнорировать

checkOrderПример параметров запроса :

существует"

techMessage="Неверный номер телефона"/>

4.3. Уведомление о переводе (paymentAviso) . Уведомление Контрагента о принятом переводе Этот запрос

обозначает факт успешного перевода денежных средств плательщика в адрес Контрагента и обязанность Контрагента

.выдать товар плательщику

:Обратите внимание на этомшаге Контрагент не может .отказаться от приема перевода

4.3.1. Формат запроса Оператора « » Параметры запроса Уведомление о переводе совпадают с

« » ( . параметрами для запроса Проверка заказа см описание в разделе 4.2.1). Специфичные для операции paymentAviso параметры

:приведены в таблице ниже

4.3.1.1.Таблица Параметры запроса операции paymentAviso


action xs:normalizedString, 16 до символов

, : Тип запроса значениеpaymentAviso.

paymentDatetime xs:dateTime Момент регистрации оплаты заказа в ИС

.Оператора

cps_user_country_code xs:string, 2 символа

Двухбуквенный код страны плательщика в соответствии с ISO 3166-1

alpha-2.


Operator shall not be held liable for their accuracy. The Operator’s requests may contain parameters that are not described in

this document. The Counterparty should ignore such parameters.

Sample paymentAviso request parameters:


action paymentAviso

md5 45125C95A20A7F25B63D58EA304AFED2

shopId

shopArticleId

13

456

invoiceId 1234567






shopSumAmount 86.23



paymentDatetime 2011-05-04T20:38:10.000+0

paymentPayerCode

paymentType

42007148320

AC

cps_user_country_code RU

MyField Field added by the Counterparty

(Код страны плательщика cps_user_country_code) определяется , из данных которые Оператор получает из технических

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

.несет ответственности за их достоверность , Запросы Оператора могут содержать параметры не

. описанные в данном документе Контрагенту следует их .игнорировать

Пример параметров запроса paymentAviso:


action paymentAviso

md5 45125C95A20A7F25B63D58EA304AFED2

shopId

shopArticleId

13

456

invoiceId 1234567






shopSumAmount 86.23



paymentDatetime 2011-05-04T20:38:10.000+0

paymentPayerCode

paymentType

42007148320

AC

4.3.2. Format of the Counterparty’s responseThe parameters for the Counterparty’s response to the ‘Notification of payment’ request match the parameters for the ‘Check order’ operation (see the description in section 4.2.2).

Possible codes for the results of processing the ‘Notification of payment’ request are outlined in the table below:

Table 4.3.2.1. paymentAviso request processing result codes

Code Value Description

0 Successful Success, even when the Operator has sent the given request multiple times.

1 Authorization error

md5 parameter value doesn’t match the hash function calculation result. The Operator will not repeat the request and will mark the order as ‘Notification not delivered to the Counterparty’.

200 Bad Request The Counterpartys IS is unable to process the request. The Operator will not repeat the request and will mark the order as ‘Notification not delivered to the Counterparty’.

Sample response to paymentAviso request when the processing is successful:


<paymentAvisoResponse

performedDatetime ="2011-05-04T20:38:11.000+04:00"


shopId="13"/>

4.4. Rules for the Counterparty when processing HTTP-notifications1. The Counterparty should review the value for the md5 parameter in order

to verify the completeness and authenticity of the requests. If the value for

cps_user_country_code RU

MyField Добавленное Контрагентом поле

4.3.2. Формат ответа Контрагента « Параметры ответа Контрагента на запрос Уведомление о

» « переводе совпадают с параметрами для операции Проверка» ( . заказа см описание в разделе 4.2.2).

« Возможные коды результата обработки запроса Уведомление о» :переводе приведены в таблице ниже

4.3.2.1.Таблица Коды результата обработки запроса paymentAviso

Код

Значение Описание ситуации

0 Успешно — Успешно даже еслиОператор прислал данный запрос.повторно

1 Ошибкаавторизации

Значение параметра md5 не совпадает с результатом - . расчета хэш функции Оператор не будет повторять

« запрос и пометит заказ как Уведомление Контрагенту ».не доставлено

200 Ошибка разбора

запроса

. ИСКонтрагента не в состоянии разобрать запрос Оператор не будет повторять запрос и пометит заказ как

« ».Уведомление Контрагенту не доставлено

Пример ответа на paymentAviso :при успехе обработки


<paymentAvisoResponse

performedDatetime ="2011-05-04T20:38:11.000+04:00"


shopId="13"/>

4.4. Правила обработки HTTP-уведомлений Контрагентом1. md5 Контрагенту следует проверять значение параметра для

. проверки целостности и подлинности запросов Если значение md5 - не совпадает с результатом расчета хэш функции MD5,

.нужно отказывать в обработке запросаMD5- , хэширование применяется к тексту формируемому как

, последовательность значений ряда параметров запроса « » — «;». разделенных символом точка с запятой Порядок

:следования параметров следующий

action;orderSumAmount;orderSumCurrencyPaycash;orderSumBankPaycash;shopId;invoiceId;customerNumber;shopPassword

md5 does not match the result of the calculated MD5 hash function, the Counterparty must refuse to process the request.

MD5 hashing is applied to the text assembled as a sequence of the values for several request parameters, which are delimited by semicolons - ‘;’. The parameters will appear in the following order:

action;orderSumAmount;orderSumCurrencyPaycash;orderSumBankPaycash;shopId;invoiceId;customerNumber;shopPassword

Sample:

Original line (without breaks) Hashing result

checkOrder;87.10;643;1001;13;55;8123294469;s<kY23653f,{9fcnshwq

1B35ABE38AA54F2931B0C58646FD1321

2. The Counterparty IS should respond to the Operator’s requests within 10 seconds.

3. If there is no response from the Counterparty to the ‘Check order’ request or if the response is anything besides ‘successful’, the Operator will inform the payer that he or she may not pay.

4. If, for a long period, there are no responses from the Counterparty to repeated ‘Notification of payment’ requests (or technical errors are returned repeatedly), the Operator IS will repeat attempts to deliver the notification within a 24-hour period: the first repeat attempt will be sent one minute after the initial request, the next five in intervals from 5-30 minutes. After that the payment will be given a final status. Whether the status is ‘successful’ or ‘unsuccessful’ depends on the Counterparty’s integration parameters (more detailed information can be found in the section 6.1 ‘The Counterparty’s integration parameters’).

5. The Operator assigns a unique number to each payment (invoiceId). The Counterparty should be prepared for the case that several ‘Notification of payment’ requests may be delivered for the same invoiceId (due to problems with the connection or an error in the Counterparty’s response to the request). The Counterparty IS should respond ‘successful’ (code=”0”) to duplicate notifications.

5. Email-notifications about payments

:Пример

Исходная строка ( )без переносов Результатхеширования

checkOrder;87.10;643;1001;13;55;8123294469;s<kY23653f,{9fcnshwq

1B35ABE38AA54F2931FD1321

2. ИС Контрагента должна отвечать на запросы Оператора в 10 .течение секунд

3. «При отсутствии ответа от Контрагента на запрос Проверка » « » заказа или при любом ответе кроме Успешно Оператор

.сообщит плательщику о невозможности заплатить4. При длительном многократном отсутствии ответа Контрагента

« » ( на запросы Уведомление о переводе либо при многократных ) технических ошибках ИС Оператора будет повторять попытки

: – доставки уведомления в течение суток первый раз через , 5–30 . минуту потом еще до пяти раз с интервалом минут После

.этого платеж будет переведен в окончательный статус – Успешный или неуспешный зависит от параметров

( подключения Контрагента подробная информация приведена в разделе 6.1 «The Counterparty’s integration parameters»).

5. Оператор присваивает каждому переводу уникальный номер (invoiceId). , Контрагент должен быть готов к тому что запрос « » invoiceId Уведомление о переводе для одного и того же может

( - приходить неоднократно из за проблем со связью или ошибок в ). ответе ИС Контрагента на этот запрос На повторные

уведомления ИС Контрагента должна отвечать успехом (code="0").

5. Email-уведомления о переводах email- При подключении по схеме Контрагент определяет адрес

, email-электронной почты на который он будет принимать .уведомления от Оператора

(email) Уведомления отправляются в теле электронного сообщения и (подписываются сертификатомОператора S/MIME ).подпись

If the Counterparty selects the email scheme for integration, it should provide the Operator with the email address where it will receive email notifications from the Operator.

Notifications are sent in the body of an email message and are signed with the Operator’s certificate (S/MIME signature).

The Operator generates a separate notification for every successful payment to the Counterparty. The format for notifications is outlined below:

Table 5.1. Fields for email notifications about payments

Field Value

№Извещение (Notification #)

Number of the email notification about the payment made to the Counterparty. Numbering is continuous.

Получатель

(Recipient)

Legal name of the Counterparty specified at the integration stage.

Время перевода

(Date and time of payment)

Date and time of payment in the format dd.mm.yyyy hh:mm:ss according to the time of the Operator IS.

Сумма

(Payment amount)

Amount of payment. Decimal delimiter — a decimal point, always exactly two characters after the decimal point, thousands place delimiter is absent.

Номертранзакции (Payment number)

Unique transaction ID in the Operator IS.

Идентификаторплательщика

(Customer ID)

Payer ID in the Operator IS. ‘customerNumber’ parameter value on the payment form (for here and below, see Section 3 ‘Payment form’).

Номер у Unique order ID in the Counterparty IS. ‘orderNumber’ parameter value

Оператор формирует отдельное уведомление по итогам каждого . успешного платежа в пользу Контрагента Формат уведомления

:представлен ниже

5.1. Таблица Поля email- уведомления о переводе

Поле Значение

№Извещение Номер email- уведомления о переводе в адрес. .Контрагента Нумерация сквозная

Получатель , Юридическое наименование Контрагента .указанное при подключении

Времяперевода

«dd.mm.yyyy Дата и время перевода в форматеhh:mm:ss», .по часамИСОператора

Сумма . – Сумма перевода Разделитель дробной части, , точка всегда ровно два знака после точки

.разделитель тысяч отсутствует

Номертранзакции

.Уникальный номер транзакции в ИСОператора

Идентификат ор

плательщика

. Идентификатор плательщика вИСКонтрагента customerNumber Значение параметра платежной

( . формы здесь и ниже см раздел 3 « Платежнаяформа»).

Номер уконтрагента

Уникальный номер заказа в ИС . Контрагента orderNumber Значение параметра платежной

. , формы Если поле не заполнено подставляется « ».значение из Номер транзакции

ФИО . custName ФИОплательщика Значение параметра .платежной формы

Адресдоставки

Адрес доставки товара или адрес проживания. custплательщика Значение параметра Addr

контрагента

(Counterparty’s order number)

on the payment form. If the field is not filled out, the value from ‘Transaction number’ field is inserted.

ФИО (Full name) First name, last name, and patronymic of the payer. ‘custName’ parameter value on the payment form.

Адрес доставки

(Address for delivery)

Delivery address or the payer’s residential address. ‘custAddr’ parameter value on the payment form.

Email Email address of the payer. ‘custEMail’ parameter value on the payment form.

Содержаниезаказа (Contents of order)

Order details: the list of purchased goods, their quantity, purpose of payment destination, etc. ‘orderDetails’ parameter value on the payment form.

Please note: some fields may be empty if the Counterparty has not included the corresponding parameter in the payment form or the payer did not fill in the field.

Sample email notification:

Subject: Yandex.Dengi payment for Наименование_Контрагента #87

Извещение № 87

Получатель: ООО «Наименование_Контрагента»

Время перевода: 18.01.2008 16:32:37

.платежной формы

Email . Адрес электронной почты плательщика Значение custпараметра EMail .платежной формы

Содержаниезаказа

: , Детали заказа список приобретенных товаров их, . . количество назначение платежа и т п Значение

параметра orderDetails .платежной формы

:Обратите внимание некоторые поля могут прийти с пустыми, значениями если соответствующий параметр не был включен

Контрагентом в платежнуюформу или не был заполнен.плательщиком

email- :Образец уведомления

Subject: Yandex.Dengi payment for Наименование_Контрагента #87

Извещение № 87

Получатель: ООО «Наименование_Контрагента»

Время перевода: 18.01.2008 16:32:37

Сумма: 12.00 RUB

Номер транзакции: 1099511628638

Идентификатор плательщика: 4637937

Номер у Контрагента: 1099511628638

Сумма: 12.00 RUB

Номер транзакции: 1099511628638

Идентификатор плательщика: 4637937

Номер у Контрагента: 1099511628638

Заполнено плательщиком в платежной форме Контрагента:

ФИО: Ivanov Iva Ivanovich

Адрес доставки: Moscow, ul. Moskovskaya 3-45

Email: [email protected]

Содержание заказа: some description of the order

6. Appendices6.1. The Counterparty’s integration parametersTo complete integration with the Operator IS, the Counterparty must inform the Operator of its selections for the following settings (parameters 3-6 are only required if the HTTP-scheme for integration is selected, parameter 9 is only required for the email-scheme for integration):

Table 6.1.1. Counterparty integration parameters

Parameter Value Comments

1. Name of the Counterparty

From 3 to 128 characters Name of the Counterparty’s store, which should be visible to the payer during the payment process.

2. URL of Counterparty’s website

Заполнено плательщиком в платежной форме Контрагента:

ФИО: Иванов Иван Иванович

Адрес доставки: г.Москва, ул. Московская 3-45

Email: [email protected]

Содержание заказа: какое-то описание заказа

6. Приложения6.1. Параметры подключения Контрагента

Для подключения кИСОператора Контрагент должен сообщить ( . 3-6 HTTP- следующие настройки пп требуются только при схеме

, . 9 – email- ):подключения п только при схеме

6.1.1.Таблица Параметры подключения Контрагента

Параметр Значение Комментарий

1. Наименование Контрагента

3 128 От до символов Название магазина, Контрагента которое

плательщик должен видеть в .процессе платежа

2. Адрес сайтаКонтрагента

3. checkURL o Для тестированияo Для продакшн

* 200 до символов

URL, по которомуИС Контрагента будет доступна для

« запросов Оператора Проверка». заказа Для взаимодействия

необходимо использовать HTTPS.протокол

4. o Для тестирования URL, по которомуИС

3. checkURL o For testingo For production

* up to 200 characters

URL where the Counterparty IS will be available for the Operator’s ‘Check order’ requests. For interaction, the HTTPS protocol must be used.

4. paymentAvisoURL

o For testingo For production

* up to 200 characters

URL where the Counterparty IS will be available for the Operator’s ‘Notification of payment’ requests. For interaction, the HTTPS protocol must be used.

5. Counterparty's secret word

We suggest you use a randomly generated set of symbols with a length of no more than 20 characters.

Used to create the md5 hash transmitted in the ‘Check order’ and ‘Notification of payment’ requests.

6. Status of payments when notification of payment cannot be delivered

o 6.1 Consider unsuccessfulo 6.2 Consider successful

These settings account for the mutual behavior of the Counterparty and the Operator when the ‘Notification of payment’ cannot be delivered (if the Counterparty does not respond to repeated requests from the Operator over a long period of time or the Counterparty IS returns multiple technical errors).

For description of options, see Table 6.1.2 below.

7. Procedure for redirecting payers after payment is complete

o 7.1 To static URLs of the Counterparty:articleId successURL (*)

failURL (*)

articleId

successURL (*)

failURL (*)

These settings determine where the payer will be redirected after the payment is completed. The payer is redirected from the payment result page by clicking the ‘Return to store’ link.

For a description of redirect options, see Table 6.1.3 below.

paymentAvisoURL o Для продакшн* 200 до символов

Контрагента будет доступна для запросов Оператора

« ». Уведомление о переводе Для взаимодействия необходимо

HTTPS.использовать протокол

5. Секретное слово

Контрагента

Рекомендуется использовать случайно

сгенерированный набор символов длиной не более

20 .символов

Необходимо для формированияmd5 , хэша передаваемого в

« » запросах Проверка заказа и« » Уведомление о переводе в

.адрес Контрагента

6. Учет переводов при

недоставке уведомления о

переводе

o 6.1 Считать неуспешнымo 6.2 Считать успешным

Настройка определяет взаимное поведение

Контрагента и Оператора при невозможности доставки

« » Уведомления о переводе( длительное многократное

отсутствие ответа Контрагента на запросыОператора либо

многократные технические ).ошибкиИСКонтрагента

. Описание вариантов см в 6.1.2 .таблице ниже

7. Порядокперенаправле

ния плательщика

после завершения

перевода

o 7.1 На статические :адреса Контрагента

articleId successURL (*)

failURL (*)

articleId successURL

(*)

failURL (*)

* 200 ; до символов адреса

Настройка определяет порядок перенаправления плательщика

на сайт Контрагента после . завершения оплаты Переход

происходит со страницы — результата платежа по клику

« на ссылку Вернуться в».магазин

Описание вариантов . перенаправления см в таблице

6.1.3 .ниже

* up to 200 characters; addresses for testing and for production

o 7.2 To URLs transmitted by the Counterparty on the payment form

8. Email address for payment reports

Email address for delivery of daily payment reports of accepted by the Operator in the interest of the Counterparty.

9. Email address for notifications about payments

Email address for delivery of notifications.

Table 6.1.2. Status of payments when ‘Notification of payment’ cannot be delivered

Option Comments

‘Consider unsuccessful’ (by default)

The Operator ceases all attempts to deliver the notification, marks the payment as not delivered to the Counterparty and does not include it in the daily payment report. The amount of the unsuccessful payment will be automatically returned to the payer. The Counterparty can find the ‘lost notifications’ by reviewing the list on Merchant Web Services (MWS).

‘Consider unsuccessful’

The Operator ceases all attempts to deliver the notification and marks the payment as successful. The payment will be included in the daily payment report as of the time of the last attempt to deliver the ‘Notification of payment’. The Counterparty can find the ‘lost notifications’ by reviewing the list on MWS (*).

* To view the list of operations through the web interface MWS, the Counterparty just needs to issue a certificate. No programming is necessary.

The Counterparty will need to implement the MWS protocol if it needs the ability to

для тестирования и дляпродакшн

o 7.2 , На адреса передаваемые Контрагентом в

платежной форме8. Email дляреестров

Адрес электронной почты для , отправки реестров переводов принятых Оператором в пользу

.Контрагента

9. Email для уведомлений о

переводах

Адрес электронной почты для .отправки уведомлений

6.1.2.Таблица Варианты учета переводов при недоставке « »Уведомления о переводе

Вариант Комментарий

« Считатьнеуспешным» ( по

)умолчанию

Оператор прекращает попытки доставки, уведомления помечает перевод как

недоставленный Контрагенту и не помещает его в . реестр принятых переводов Сумма неуспешного

перевода будет автоматически возвращена. плательщику Контрагент может обнаружить

« » потерянные уведомления путем сверки с использованием сервиса Merchant Web Services (MWS).

« Считать»успешным

Оператор прекращает попытки доставки . уведомления и помечает перевод как успешный

Перевод будет включен в реестр принятых переводов согласно времени последней попытки

« ». доставки Уведомления о переводе Контрагент « » может обнаружить потерянные уведомления

путем сверки с реестром или с использованием

issue refunds. Contact your account manager for the necessary documentation.

Table 6.1.3. Options for redirecting the payer after completion of the payment

Option Comments

‘To static URLs of the Counterparty’ (by default)

The addresses used for redirect are fixed ones and are determined by the following settings (individually for each good):

successURL failURL

‘To URLs transmitted by the Counterparty on the payment form’

The addresses used for redirect are transmitted by the Counterparty with the payment form parameters (individually for each good):

shopSuccessURL shopFailURL

Please note:

1. During a redirect to a URL, the parameter “?action=PaymentSuccess” (“?action=PaymentFail”) is added, as well as the request parameters from the Operator to the Counterparty IS (payment form parameters). Redirects are performed via the GET method (an exception is unsuccessful payment from a Yandex.Money e-wallet, in which case a redirect will be performed via the POST method).

2. If the payment status cannot be determined, the payer will be redirected to the Counterparty’s homepage (the URL specified during integration: ‘2. URL of Counterparty’s website’), additional parameters will not be added to the URL.

3. If the Counterparty plans on displaying personal information intended for a specific payer, then it should authorize that payer using its own resources. This may be a standard authorization on the Counterparty’s website (e.g. via cookies) or through use of the Counterparty’s session keys placed on the payment form.

4. When the payment method is cash at a payment kiosk or payment from a mobile phone balance, the payer will be redirected to the homepage of the

сервиса MWS (*).

* -Для доступа к просмотру списка операций через веб MWS интерфейс Контрагенту потребуется выпуститьтолько

, .сертификат программировать ничего не нужно

MWS , Реализация протокола требуется если Контрагенту . нужен функционал возвратов За документацией обратитесь к .своемуменеджеру

6.1.3.Таблица Варианты перенаправления плательщика после завершения перевода

Вариант Комментарий

« На статические

адреса товара

Контрагента»

( по)умолчанию

Для перехода используются фиксированные, адреса определенные в следующих настройках

( ):отдельно по каждому товару

successURL failURL

« , На адресапередаваемы

еКонтрагенто

м в платежной

»форме

, Для перехода используются адреса которые Контрагент должен передавать в параметрах

( платежной формы отдельно по каждому):платежу

shopSuccessURL shopFailURL


1. При редиректе к URL' «?у для перехода добавляютсяaction=PaymentSuccess» («?action=PaymentFail»), а также все

Counterparty’s website and additional parameters will not be added to the URL.

5. When the payment method is a WebMoney e-wallet, the payer will be redirected straight from the WebMoney system to the Counterparty’s site. In this case, WebMoney may add its own additional parameters to the URL for redirect.

6. When the payment is made via Sberbank: payment by text messages or Sberbank Online, via Alfa-Click, or via Promsvyazbank, then the payer is not redirected to the Counterparty’s site after payment.

6.2. Particulars of interaction when payment method is cash via payment kiosks

The interaction between the Operator and the Counterparty when the payment method is cash at a payment kiosk differs from the basic scenario (as described in section 2 ‘Interaction: a general overview’). These particulars must be taken into consideration:

параметры запроса от Оператора к ИС Контрагента ( ). параметры платежной формы Переход осуществляется при

GET (помощи метода исключение – неуспех оплаты из . , кошелька в ЯндексДеньгах в этом случае переход

осуществляется методом POST).2. При неопределенном статусе платежа редирект производится

(URL, на главную страницу сайта Контрагента указанный при : «2. »), подключении Адрес сайта Контрагента дополнительные

URL' .параметры к у при этом не подклеиваются3. Если Контрагент собирается отображать персональную

, информацию предназначенную для конкретного , плательщика то он должен авторизовать такого плательщика

. собственными средствами Это могут быть стандартная ( авторизация на сайте Контрагента через cookies . .) и т п или

, через сессионные ключи Контрагента помещенные им в .платежнуюформу

4. При оплате наличными через терминалы и при платеже со счета мобильного телефона редирект осуществляется на

, главную страницу сайта Контрагента дополнительные URL' .параметры к у не подклеиваются

5. При оплате из кошелька в WebMoneyсистеме редирект плательщика на сайт Контрагента производится напрямую из

WebMoney. WebMoney системы При этом могут подклеивать к URL' у для перехода свои собственные дополнительные

.параметры6. При оплате через : Сбербанк SMS оплата по или Сбербанк

, Онлайн через -Альфа Клик и Промсвязьбанк редирект .плательщика на сайт Контрагента не выполняется

6.2. Особенности взаимодействия при оплате наличными через терминалы

Взаимодействие Оператора и Контрагента в случае оплаты заказа наличными через терминалы имеет ряд особенностей по

( сравнению с базовым сценарием описан в разделе 2 «Interaction: a general overview»). :Эти особенности необходимо учитывать

3-4. After payment form parameters are received and the payment method is determined, the payer is additionally asked to provide a phone number and email address.

If the Counterparty transmitted the payer’s phone number (cps_phone) and/or email address (cps_email) among the payment form parameters, the payment confirmation form will be pre-filled with these data.

5. The payer is issued a special code and instructions for paying at a payment kiosk or retailer. The Operator sends this code, as well as the payment total, via SMS to the phone number specified by the payer.

When the payer clicks on the link ‘Return to store’, found on the page where the code is displayed, the payer will be redirected to the webpage the Counterparty specified during the integration process (‘2. URL of Counterparty’s website’). The

3-4. После получения параметров платежнойформыи определения способа платежа у плательщика дополнительно запрашиваются .телефон и адрес электронной почты

Если Контрагент передал среди параметров платежной формы (cps_phone) / email (cps_email), телефон плательщика и или форма

.подтверждения платежа будет предзаполнена этими данными

5. Плательщику выдается специальный код и инструкция по оплате . , , через терминалы и кассы Этотже код а также сумма к оплате

SMS .высылаются Оператором в на указанный телефон

« », При клике по ссылке Вернуться в магазин размещенной на , странице выдачи кода плательщик перенаправляется на адрес

, («2. Контрагента указанный при подключении Адрес сайта

parameters (shop)successURL, (shop)failURL are not used in this case.

6. The payer can use the payment code received in step 5 to indicate the order he or she wants to pay for at any payment kiosk or ATM where users can add money to their Yandex.Money e-wallets.

Please note: if the payment kiosk is able to inform the Operator in real time that money was inserted in the kiosk, then an additional ‘Check order’ (checkOrder) request will be performed at this step. In that case, if the Counterparty declines the payment, the payer’s money will not be accepted by the kiosk.

7-11. After the payment kiosk network transmits confirmation that the payer inserted the full payment amount, the Operator sends the successive requests ‘Check order’ (checkOrder) and ‘Notification of payment’ (paymentAviso).

Please note:

If the Counterparty refuses to accept the payment, the Operator will return money to the payer independent of the Counterparty;

If the amount of money the payer inserts into the payment kiosk exceeds the order amount, the change will be automatically credited to the balance of the mobile phone specified by the payer during the order process;

If the amount of money the payer inserts into the payment kiosk is less than the order amount, the Operator will send him or her an SMS with information about the insufficient amount. To complete the payment, the payer must insert the insufficient amount.

11. After the Counterparty IS responds to the ‘Notification of payment’ request, the Operator sends a message to the payer about the payment result to the email address indicated by the payer earlier.

6.3. Particulars of interaction when payment is made through third-party payment systems

When the payment of an order is made via Sberbank: payment by text messages or Sberbank Online, via Alfa-Click, via Promsvyazbank, via MasterPass, or from a WebMoney e-wallet (hereinafter—‘third-party payment system’, ‘TPS’), then interaction between the Operator and the Counterparty involves several particulars as compared to the basic scenario (as described in section 2 ‘Interaction: a general overview’). It is necessary to take these particulars into account:

»). (shop)successURL, (Контрагента Параметры shop)failURL в данной .ситуации не используются

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

. .принимаются деньги для пополнения кошельков в ЯндексДеньгах

: Обратите внимание если терминал имеет техническую возможность сообщить Оператору о внесении денег в режиме реального времени, на этом шаге будет выполнен дополнительный запрос «Проверка заказа» (checkOrder). Тогда в случае, если Контрагент откажется от приема перевода, деньги от плательщика не будут приняты терминалом.

7-11. , После получения от терминальной сети информации о том что , плательщик внес деньги Оператор выполняет последовательные

« » (checkOrder) « » запросы Проверка заказа и Уведомление о переводе(paymentAviso).


, если Контрагент откажется принимать перевод Оператор ;самостоятельно вернет деньги плательщику

, если плательщик внесет в терминал сумму которая больше , стоимости заказа сдача будет автоматически перечислена на

;счет указанного при платежемобильного телефона , если плательщик внесет в терминал сумму которая меньше

, стоимости заказа Оператор пришлет ему SMS с информацией о . недостающей сумме Для проведения платежа плательщик

.должен будет довнести недостающую сумму11. « » После ответа от ИСКонтрагента на Уведомление о переводе

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

6.3. Особенности взаимодействия при оплате через внешние платежные системы

Взаимодействие Оператора и Контрагента в случае оплаты заказа черезСбербанк: SMS , оплата по или Сбербанк Онлайн -Альфа

Клик, Промсвязьбанк, MasterPass, а также из кошелька в системе

3-4. After the payment form parameters are received and the payment method has been determined, on the Operator’s page, the payer will be asked for data for payment through TPS (optional).

Please note: when paying from a WebMoney e-wallet, entry of extra data is not requested, and the payer will visually be redirected immediately to WebMoney’s portal.

5-7. The Operator informs the TPS of the sum to be paid and the optional set of information about the good and the payer.

8. The Operator redirects the payer to the TPS’s portal for completing the payment.

9-11. The subsequent display of information about the good, payment confirmation method, notification of the payer about the operation’s result, as well as the payer’s option of being redirected to the Counterparty’s site after completing payment will be determined by the particulars of operating each specific TPS.

12-17. After receiving information from the TPS about the successful debiting of funds from the payer, the Operator fulfills the ‘Check order’ (checkOrder) and ‘Notification of payment’ (paymentAviso) requests in sequence.

Please note: when payment is made via MasterPass, the payment type AC (payment

WebMoney ( – , ) далее внешняя платежная система ВПС имеет ряд ( особенностей по сравнению с базовым сценарием описан в разделе

2 «Interaction: a general overview»). Эти особенности необходимо:учитывать

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

Обратите внимание: при оплате из кошелька в системе WebMoney ввод дополнительных данных не производится, и плательщик визуально сразу же перенаправляется на сторону WebMoney.

5-7. Оператор сообщает ВПС сумму к оплате и опциональный набор сведений о товаре и плательщике.

8. Оператор перенаправляет плательщика на сторону ВПС для проведения оплаты.

9-11. Дальнейшие отображение сведений о товаре, способ подтверждения оплаты, информирование плательщика о результате операции, а также возможность перенаправления плательщика на сайт Контрагента после завершения оплаты определяются особенностями функционирования конкретной ВПС.

from any bank card) will be specified in the Operator’s requests and the payment report.

6.4. Particulars of interaction when payment method is bank card via mPOSAccepting payments by bank card via a mobile point of sale (mPOS) is achieved with the help of a special reader connected to a smartphone with the 2Can for Yandex.Money application installed on it.

Notification of the Counterparty about such a payment contains additional information about the payment purpose, which is entered in the corresponding field on the app. If the Counterparty is operating on the HTTP-scheme, this information will be transmitted in the parameter orderDetails of ‘Check order’ (checkOrder) and ‘Notification of payment’ (paymentAviso) requests. If the Counterparty is operating on the email-scheme, the information is transmitted in the field ‘Contents of order’ of email notifications.

6.5. Daily payment reportsOnce a day, the Operator generates a report of payments accepted in the interest of the Counterparty. The payment report is sent in the body of an email message to the email address (*) the Counterparty indicates during the integration process. (‘8. Email address for payment reports’). The payment report is signed with the Operator’s certificate (S/MIME signature). The daily payment report contains all payments made on the date indicated in the report.

* Payment reports can also be sent using (s)ftp. Contact your account manager for more details.

Subject lines of email messages are generated by the following model (continuous numbering):

YANDEX.MONEY DAILY PAYMENT REPORT FOR <Name_of_Counterparty>. № <number>

12-17. После получения от ВПС информации об успешном списании средств с плательщика Оператор выполняет последовательные запросы «Проверка заказа» (checkOrder) и «Уведомление о переводе» (paymentAviso).

Обратите внимание: MasterPass при оплате через в запросах Оператора и в реестре принятых переводов будет указан тип

платежа AC ( ).оплата с произвольной банковской карты

6.4. Особенности взаимодействия при оплате через мобильный терминал

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

«2can подключенного к смартфону с установленным приложениемfor Yandex.Money».

Уведомление Контрагента о таком платеже дополнительно , содержит информацию о назначении платежа введенном в

. соответствующее поле приложения При подключении Контрагента по HTTP- orderDetails схеме данные передаются в параметре запросов

« » (checkOrder) « » Проверка заказа и Уведомление о переводе(paymentAviso). email- – При подключении по схеме в поле« » email- .Содержание заказа уведомлений

6.5. Реестры принятых переводов Раз в суткиОператор формирует реестр принятых в пользу

. Контрагента переводов Реестр отправляется в теле электронного сообщения на email (*), указанныйКонтрагентом при подключении

(«8. Email »). для реестров Реестр подписывается сертификатом (Оператора S/MIME ). подпись В реестре содержатся все переводы за .указанную в реестре дату

* Также в (s)ftp. озможна отправка реестров по За подробной .информацией обратитесь к своемуменеджеру

(subject) Тема электронного сообщенияформируется по следующему

The body of email messages are generated as follows:

YANDEX.MONEY DAILY PAYMENT REPORT FOR <Name_of_Counterparty>. № <number>

Date of payments: <dd.mm.yyyy>

Transaction number; Customer ID; Gross payment amount; Payment currency; Payment amount less fee; Date and time of payment; E-wallet number; Description; Payment type

<Payment details>

Total gross amount of payments accepted of type <Payment type>: <gross amount of payments accepted of given type on the given date>

Total amount of payments less fees of type <Payment type>: <total amount of payments accepted less Operator’s fees of given type>

Number of payments of type <Payment type>: <quantity of payments of the given type>

Total gross amount of payments accepted: <gross amount of payments accepted on the given date>

Total amount of payments less fees: <total amount of payments accepted less Operator’s fees>

Number of payments: <quantity of payments>

To: < Name_of_Counterparty >

( ):шаблону нумерация сквозная

РЕЕСТР ПЛАТЕЖЕЙ В <Наименование_Контрагента>. № <номер>

:Тело электронного сообщенияформируется как

РЕЕСТР ПЛАТЕЖЕЙ В <Наименование Контрагента>. № <номер>

Дата платежей: <dd.mm.yyyy>

Номер транзакции; Идентификатор клиента; Сумма платежа; Валюта платежа; Сумма за вычетом комиссии; Время платежа; Номер кошелька плательщика; Краткое описание; Тип платежа

<Данные платежей>

Сумма принятых платежей типа <Тип операции>: <общая сумма принятых переводов данного типа за сутки>

Сумма принятых платежей за вычетом комиссии типа <Тип операции>: <сумма принятых переводов данного типа за вычетом комиссии Оператора>

Число платежей типа <Тип операции>: <количество переводов данного типа>

Сумма принятых платежей: <общая сумма принятых переводов за сутки>

Сумма принятых платежей за вычетом комиссии: <сумма принятых переводов за вычетом комиссии Оператора>

Число платежей: <количество переводов>

(Under Agent agreement <number of agreement between Counterparty and Operator>)

A description of the fields with the payment information is outlined in the table below.

Table 6.5.1. Fields in a standard payment report

Field Value

Transaction number

Unique transaction number in the Operator IS (string, up to 32 characters). Operator’s notification ‘invoiceId’ parameter value.

Customer ID Payer ID in the Counterparty IS (string, up to 64 characters). ‘customerNumber’ parameter value on the payment form.

Gross payment amount

Amount of transaction. Decimal delimiter — a decimal point, always exactly two characters after the decimal point. There is no thousands place delimiter.

Payment currency Three-letter currency code (RUB – Russian Federation ruble).

Payment amount less fee

Amount to be transferred to the Counterparty's bank account. Decimal delimiter — a decimal point, always exactly two characters after the decimal point, thousands place delimiter is absent.

Date and time of payment

The time when the ‘Notification of payment’ is delivered to the Counterparty (for email-scheme for integration – the time when the payment for an order is registered with the Operator IS). Date and time of payment is displayed in the format dd.mm.yyyy hh:mm:ss according to the time of the Operator IS.

E-wallet number Number of the account in the Operator IS where the payment was made from.

Description Written name of the purchased good in the Operator IS.

Payment type The method that was used to complete the payment. Values correspond to the ‘paymentType’ parameter values (see Table 6.6.1). Optional field.

Кому: <Наименование Контрагента>

(По договору <номер договора между Контрагентом и Оператором>)

.Описание полей с данными платежей приведено в таблице ниже

6.5.1. Таблица Поля стандартного реестра принятых переводов

Поле Значение

Номертранзакции

(Уникальный номер транзакции в ИСОператора string). символов Значение параметра invoiceId уведомлений

.Оператора

Идентификато р клиента

(Идентификатор плательщика вИСКонтрагента string). customerNumber символов Значение параметра платежной

.формы

Суммаплатежа

. – , Сумма транзакции Разделитель дробной части точка , всегда ровно два знака после точки разделитель тысяч

.отсутствует

Валютаплатежа

Трехбуквенный к (RUB – ).од валюты Рубль РФ

Сумма за вычетом

комиссии

/ . Сумма к выплате Контрагенту на р с Разделитель дробной – , , части точка всегда ровно два знака после точки

.разделитель тысяч отсутствует

Времяплатежа

« » Момент доставки Уведомления о переводе Контрагенту( email- – при работе по схеме момент регистрации оплаты

). «dd.mm.yyyy заказа в ИСОператора Дата и время в форматеhh:mm:ss», .по часамОператора

Номер кошелька

плательщика

, .Номер счета в ИСОператора с которого произведена оплата

Sample payment report:

Subject: YANDEX.MONEY DAILY PAYMENT REPORT FOR Name_of_Counterparty. № 3355

YANDEX.MONEY DAILY PAYMENT REPORT FOR “Name_of_Counterparty”. № 3355

Date of payments: 14.03.2014

Transaction number; Customer ID; Gross payment amount; Payment currency; Payment amount less fee; Date and time of payment; E-wallet number; Description; Payment type

549755819524; 4956; 10.00; RUB; 9.50; 18.12.2007 17:46:58; 410038366898; online store payment of services; GP

549755819525; 4957; 15.00; RUB; 14.25; 18.12.2007 17:47:32; 410038366898; online store payment of services; PC

Total gross amount of payments accepted of type PC: 15.00 RUB

Total amount of payments less fees of type PC: 14.25 RUB

Number of payments of type PC: 1

Total gross amount of payments accepted of type GP: 10.00 RUB

Total amount of payments less fees of type GP: 9.50 RUB

Number of payments of type GP: 1

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

Текстовое наименование оплаченного товара в ИС.Оператора

Тип платежа , . Способ которым был совершен платеж Значения paymentType ( . соответствуют значениям параметра см таблицу

6.6.1). .Необязательное поле

:Образец реестра

Subject: РЕЕСТР ПЛАТЕЖЕЙ В Наименование_Контрагента. № 3355

РЕЕСТР ПЛАТЕЖЕЙ В ООО «Наименование_Контрагента». № 3355

Дата платежей: 14.03.2014

Номер транзакции; Идентификатор клиента; Сумма платежа; Валюта платежа; Сумма за вычетом комиссии; Время платежа; Номер кошелька плательщика; Краткое описание; Тип платежа

549755819524; 4956; 10.00; RUB; 9.50; 18.12.2007 17:46:58; 410038366898; оплата услуг Интернет Магазин; GP

549755819525; 4957; 15.00; RUB; 14.25; 18.12.2007 17:47:32; 410038366898; оплата услуг Интернет Магазин; PC

Сумма принятых платежей типа PC: 15.00 RUB

Сумма принятых платежей за вычетом комиссии типа PC: 14.25 RUB

Число платежей типа PC: 1

Сумма принятых платежей типа GP: 10.00 RUB

Total gross amount of payments accepted: 25.00 RUB

Total amount of payments less fees: 23.75 RUB

Number of payments: 2

To: Name of Counterparty

(Under Agent agreement 111.1111.11)

6.6. Payment methodsTable 6.6.1. ‘paymentType’ parameter values

Value Comments

PC Payment from a Yandex.Money e-wallet.

АС Payment by any bank card.

MC Payment from a mobile phone balance.

GP Payment in cash via retailers and payment kiosks.

WM Payment from a WebMoney e-wallet.

SB Payment via Sberbank: payment by text messages or Sberbank Online.

MP Payment via mobile point of sale (mPOS).

AB Payment via Alfa-Click.

MA Payment via MasterPass.

PB Payment via Promsvyazbank.

Сумма принятых платежей за вычетом комиссии типа GP: 9.50 RUB

Число платежей типа GP: 1

Сумма принятых платежей: 25.00 RUB

Сумма принятых платежей за вычетом комиссии: 23.75 RUB

Число платежей: 2

Кому: ООО «Наименование_Контрагента»

(По договору 111.1111.11)

6.6. Способы оплаты 6.6.1.Таблица paymentTypeЗначения параметра

Значение Пояснение

PC . .Оплата из кошелька в Яндекс Деньгах

AC .Оплата с произвольной банковской карты

MC .Платеж со счета мобильного телефона

GP .Оплата наличными через кассы и терминалы

WM WebMoney.Оплата из кошелька в системе

SB : SMS .Оплата через Сбербанк оплата по или Сбербанк Онлайн

MP (Оплата через мобильный терминал mPOS).

6.7. Types of dataTable 6.7.1. Definitions of protocol data types

Type Description

xs:int 32-bit integer. Int32, as defined in the standard: http://www.w3.org/TR/xmlschema-2/#int

xs:long 64-bit integer. Int64, as defined in the standard: http://www.w3.org/TR/xmlschema-2/#long

xs:decimal Fixed-point decimal, as defined in the standard: http://www.w3.org/TR/xmlschema-2/#decimal

xs:boolean Logical value (true/false), as defined in the standard:

http://www.w3.org/TR/xmlschema-2/#boolean

xs:string Text string, as defined in the standard:

http://www.w3.org/TR/xmlschema-2/#string

xs:normalizedString

Text string, as defined in the standard:

http://www.w3.org/TR/xmlschema-2/#normalizedString

xs:dateTime Time stamp of the format according to recommendations of:

http://www.w3.org/TR/xmlschema-2/#dateTime ISO8601:2004

The format is defined as:

YYYY-MM-DDThh:mm:ss.fZZZZZ

Format breakdown:

YYYY year, precisely 4 digits

MM month, precisely 2 digits (01=January, etc.)

http://www.w3.org/TR/xmlschema-2/#dateTime

http://www.w3.org/TR/xmlschema-2/#normalizedString

http://www.w3.org/TR/xmlschema-2/#string

http://www.w3.org/TR/xmlschema-2/#boolean

http://www.w3.org/TR/xmlschema-2/#decimal

http://www.w3.org/TR/xmlschema-2/#long

http://www.w3.org/TR/xmlschema-2/#int

AB Оплата через - .Альфа Клик

МА MasterPass.Оплата через

PB Оплата через .Промсвязьбанк

6.7. Типы данных 6.7.1. Таблица Определения типов данных протокола

Тип Описание

xs:int 32-bit . целое знаковое число Int32, : определенный в стандартеhttp://www.w3.org/TR/xmlschema-2/# int

xs:long 64-bit . целое знаковое число Int64, : определенный в стандартеhttp :// www . w 3. org / TR / xmlschema -2/# long

xs:decimal , Десятичное число с фиксированной точкой определенное в: стандарте http://www.w3.org/TR/xmlschema-2/#decimal

xs:boolean (Логическое значение true/false), : определенное в стандартеhttp://www.w3.org/TR/xmlschema-2/#boolean

xs:string , : Текстовая строка определенная в стандартеhttp://www.w3.org/TR/xmlschema-2/#string

xs:normalizedString

, : Текстовая строка определенная в стандартеhttp://www.w3.org/TR/xmlschema-2/#normalizedString

xs:dateTime :Временная метка в формате согласно рекомендациям

http://www.w3.org/TR/xmlschema-2/#dateTime ISO8601:2004

:Формат определяется как

YYYY-MM-DDThh:mm:ss.fZZZZZ

DD day of the month, precisely 2 digits (from 01 to 31)

T Latin letter ‘T’, must be upper case

hh hours, precisely two digits (24hrs format, from 00 to 23)

mm minutes, precisely two digits (from 00 to 59)

ss seconds, precisely two digits (from 00 to 59)

f fraction of a second (1 to 6 digits) can be omitted; in such cases the ‘.’ delimiter should be omitted as well.

ZZZZZ Time Zone descriptor, a universal parameter, can have values:

Z – UTC, the ‘Z’ symbol must be in upper case;

+hh:mm or -hh:mm – deviation from UTC (shows that the time is displayed, which is the given number of hours and minutes ahead of or behind UTC).

All the above elements are required; the only element that can be omitted is the fraction of a second (in such cases the ‘.’ delimiter should be omitted as well). If only the date is to be specified, the time of 00:00:00 needs to be entered.

Examples:

2011-07-24T19:00:00+04:00 – 19 hours 00 minutes 24 July 2011, the time zone is UTC + 4 hrs.;

2004-07-24T15:00:00Z – the same moment of time on the canonic format;

2004-07-24T15:00:00.666Z – the same moment of time plus 666 milliseconds.

YMAccount Virtual account number in the Operator IS, a string of decimal digits from 11 to 33 symbols long.

:Расшифровка формата

YYYY , 4 год точно цифры

MM , 2 (01= . .)месяц точно цифры январь и т д

DD , 2 ( 01 31)день месяца точно цифры от до

T латинский «символ T», должен быть в верхнем регистре

hh , 2 (24- , часы точно цифры часовой формат 00 23)от до

mm , 2 ( 00 59)минуты точно цифры от до

ss , 2 ( 00 59)секунды точно цифры от до

f ( 1 6 ),дробная часть секунды от до цифр

, может отсутствовать в этом случае «.»следует опускать и разделитель

ZZZZZ , Описатель временной зоны может :принимать значения

Z – UTC, «символ Z» должен быть в верхнем.регистре

+hh:mm -или hh:mm – смещение относительно UTC (GMT) ( , показывает что

указано локальное время, которое на данное число часов и минут опережает

или отстает от UTC).

Обязательно должны присутствовать все указанные, ( элементы можно опускать только дробную часть секунд в

«.»). этом случае следует опускать и разделитель Если нужно , задать только дату то время все равно следует указать как

00:00:00.

CurrencyAmount Amount. Positive decimal fixed-point number with precisely two digits after the decimal point.

CurrencyCode Currency code. Possible values:

643 — Russian Federation ruble; 10643 — test currency (demo-rubles of the Yandex.Money demo-

system).

<xs:simpleType name="YMAccount">

<xs:restriction base="xs:normalizedString">

<xs:minLength value="11"/>

<xs:maxLength value="33"/>

<xs:pattern value="[0-9]+"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="CurrencyAmount">

<xs:restriction base="xs:decimal">

<xs:minExclusive value="0"/>

<xs:maxInclusive value="9999999999999"/>

<xs:fractionDigits value="2"/>

</xs:restriction>

</xs:simpleType>

:Примеры

2011-07-24T19:00:00+04:00 – 19 00 24 2011часов минут июля , – UTC + 4 ;года часовой пояс часа

2004-07-24T15:00:00Z – тот же момент времени в ;каноническом представлении

2004-07-24T15:00:00.666Z – 666тот же момент времени плюс .миллисекунд

YMAccount , Номер виртуального счета в ИСОператора строка 11 33 .десятичных цифр длиной от до символов

CurrencyAmount . Сумма Положительное десятичное число с фиксированной, – .точкой после точки две цифры

<xs:simpleType name="YMAccount">

<xs:restriction base="xs:normalizedString">

<xs:minLength value="11"/>

<xs:maxLength value="33"/>

<xs:pattern value="[0-9]+"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="CurrencyAmount">

<xs:restriction base="xs:decimal">

<xs:minExclusive value="0"/>

<xs:maxInclusive value="9999999999999"/>

<xs:fractionDigits value="2"/>

</xs:restriction>

</xs:simpleType>

CurrencyCode . :Код валюты Возможные значения

643 — ;рубль РоссийскойФедерации 10643 — ( - - тестовая валюта демо рублики демо системы

« . »).ЯндексДеньги

CurrencyBank . Код процессингового центра Оператора Возможные:значения

1001 – ;ЭкомБанк 1003 – - « . ».ДемоБанк демо системы ЯндексДеньги

CurrencyBank Operator’s processing center code. Possible values:

1001 – EcomBank; 1003 – DemoBank of the Yandex.Money demo-system.

<xs:simpleType name="CurrencyCode">

<xs:restriction base="xs:int">

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="CurrencyBank">


</xs:restriction>

</xs:simpleType>

<xs:simpleType name="CurrencyCode">


</xs:restriction>

</xs:simpleType>

<xs:simpleType name="CurrencyBank">


</xs:restriction>

</xs:simpleType>

money. web viewПРИЛОЖЕНИЕ № 5. Протокол обмена информацией...

Documents