Интерфейс WSDL (SOAP)

Введение

Описание (WSDL) сервиса находится на тестовом сервере, который доступен без ограничений.

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

<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-%20wssecurity-utility-1.0.xsd">
    <wsse:UsernameToken wsu:Id="UsernameToken-87">
         <wsse:Username>testuser-api</wsse:Username>
         <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">test_password</wsse:Password>
    </wsse:UsernameToken>
 </wsse:Security>

В зависимости от выбранной схемы системы оплаты (одностадийная или двухстадийная) синтаксис запросов различается. На настоящем портале представлены описания обеих схем оплаты.

Если в ответе на запрос возвращается errorCode=0, запрос был обработан платёжным шлюзом без системных ошибок (при этом параметр errorCode не показывает статус заказа). Для получения статуса заказа следует использовать запрос getOrderStatusExtended.

Никакие передаваемые поля API не могут содержать части html, javascript и другого кода. Поля могут содержать исключительно текст и ссылки.

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

Координаты подключения

Для подключения к тестовой службе (WSDL) используйте следующий адрес:
https://3dsec.sberbank.ru/payment/webservices/merchant-ws?wsdl.

Возможные сценарии взаимодействия

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

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

Обычная оплата

Оплата с указанием карточных данных на платёжной странице

	Одностадийная оплата	Двухстадийная оплата
1	Плательщик выбирает товар или услугу на ресурсе продавца и выбирает способ оплаты банковской картой.
2	Продавец отправляет в платёжный шлюз запрос на регистрацию заказа: registerOrder. В том числе в запросе передаются следующие параметры: `returnUrl` - URL-адрес, на который будет перенаправлен плательщик в случае успешного платежа; `failUrl` - URL-адрес, на который будет перенаправлен плательщик в случае неуспешного платежа.	Продавец отправляет в платёжный шлюз запрос на регистрацию заказа с предавторизацией: registerOrderPreAuth. В том числе в запросе передаются следующие параметры: `amount` - сумма списания; `orderNumber` - номер заказа в системе магазина; `returnUrl` - URL-адрес, на который будет перенаправлен плательщик в случае успешного платежа; `failUrl` - URL-адрес, на который будет перенаправлен плательщик в случае неуспешного платежа.
3	Платёжный шлюз в ответе в числе прочего возвращает параметры: `orderId` - уникальный идентификатор заказа в платёжной системе; `formUrl` - URL-адрес формы ввода данных банковской карты (платёжная форма).
4	Продавец перенаправляет плательщику URL-адрес, указанный в параметре `formUrl` ответа.
5	В браузере плательщика отображается форма ввода данных банковской карты. Плательщик заполняет форму и отправляет данные на сервер платёжного шлюза.
6	Дальнейшие действия зависят от того, поддерживает ли карта покупателя 3-D Secure: поддержка 3-D Secure отсутствует - переход к следующему шагу процедуры; есть поддержка 3-D Secure - платёжный шлюз перенаправляет плательщика на форму аутентификации (чаще всего это проверка с помощью SMS-сообщения), расположенную на сервере контроля доступа, принадлежащего банку-эмитенту - в случае успешной аутентификации выполняется следующий шаг сценария.
7	Платёжный шлюз списывает деньги со счёта плательщика.	Платёжный шлюз производит холдирование (удержание) средств на счёте плательщика.
8	После проведения оплаты платёжный шлюз перенаправляет клиента на URL-адрес возврата (указанный магазином в запросе на регистрацию).
9	Браузер клиента запрашивает страницу с результатами оплаты у магазина.
10	Продавец запрашивает у платёжного шлюза статус оплаты заказа, используя уникальный идентификатор, полученный при регистрации заказа в параметре `orderId`: getOrderStatusExtended.
11	Платёжный шлюз возвращает статус оплаты и продавец передаёт в браузер клиента страницу с результатами оплаты.
12	Не актуально	Для списания средств со счёта клиента продавец должен направить в платёжный шлюз запрос завершения оплаты: depositOrder.
13	Не актуально	Платёжный шлюз возвращает результат обработки запроса. Статус заказа не возвращается. Для получения статуса заказа необходимо отправить в шлюз запрос состояния заказа: getOrderStatusExtended.

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

Отмена платежа

Отмена оплаты заказа доступна при наличии соответствующих прав по согласованию со «Сбербанком».

При одностадийных платежах отмена платежа возможна для заказов в состоянии Завершён/Deposited, но только до закрытия дня, т. е. до 24:00 (по московскому времени) того дня, когда была произведена оплата.
При двухстадийных платежах отмену платежа можно выполнить для заказа в состоянии Подтверждён/Approved.

В таблице ниже представлена схема взаимодействий продавца и платёжного шлюза при отмене оплаты.

1	Продавец делает запрос на отмену платежа: reverseOrder.
2	После получения успешного ответа платёжного шлюза продавец делает запрос статуса заказа: getOrderStatusExtended.

Возврат средств плательщику

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

Возврат средств возможен для платежей в состоянии Завершён/Deposited.

В таблице ниже представлена схема взаимодействий продавца и платёжного шлюза при возврате средств покупателю.

1	Продавец делает запрос на возврат средств покупателю: refundOrder.
2	После получения успешного ответа платёжного шлюза продавец делает запрос статуса заказа: getOrderStatusExtended.

При наличии соответствующей пермиссии также доступен Запрос возврата средств по устаревшему заказу сроком более двух лет.

Оплата с регистрацией чеков на контрольно-кассовой технике

Стандартный API

Оплата с передачей корзины и данных для регистрации чека

	Одностадийная оплата	Двухстадийная оплата
1	Плательщик выбирает товар или услугу на ресурсе продавца и выбирает способ оплаты банковской картой.
2	Продавец отправляет в платёжный шлюз запрос на регистрацию заказа: registerOrder. В том числе в запросе передаются следующие параметры: `returnUrl` - URL-адрес, на который будет перенаправлен плательщик в случае успешного платежа; `failUrl` - URL-адрес, на который будет перенаправлен плательщик в случае неуспешного платежа. `orderBundle` - блок, содержащий корзину товаров и данные для регистрации чека; `taxSystem` - идентификатор системы налогообложения.	Продавец отправляет в платёжный шлюз запрос на регистрацию заказа с предавторизацией: registerOrderPreAuth. В том числе в запросе передаются следующие параметры: `amount` - сумма списания; `orderNumber` - номер заказа в системе магазина; `returnUrl` - URL-адрес, на который будет перенаправлен плательщик в случае успешного платежа; `failUrl` - URL-адрес, на который будет перенаправлен плательщик в случае неуспешного платежа. `orderBundle` - блок, содержащий корзину товаров и данные для регистрации чека; `taxSystem` - идентификатор системы налогообложения.
3	Платёжный шлюз в ответе в числе прочего возвращает параметры: `orderId` - уникальный идентификатор заказа в платёжной системе; `formUrl` - URL-адрес формы ввода данных банковской карты (платёжная форма).
4	Продавец перенаправляет плательщику URL-адрес, указанный в параметре `formUrl` ответа.
5	В браузере плательщика отображается форма ввода данных банковской карты. Плательщик заполняет форму и отправляет данные на сервер платёжного шлюза.
6	Дальнейшие действия зависят от того, поддерживает ли карта покупателя 3-D Secure: поддержка 3-D Secure отсутствует - переход к следующему шагу процедуры; есть поддержка 3-D Secure - платёжный шлюз перенаправляет плательщика на форму аутентификации (чаще всего это проверка с помощью SMS-сообщения), расположенную на сервере контроля доступа, принадлежащего банку-эмитенту - в случае успешной аутентификации выполняется следующий шаг сценария.
7	Платёжный шлюз списывает деньги со счёта плательщика.	Платёжный шлюз производит холдирование (удержание) средств на счёте плательщика.
8	После проведения оплаты платёжный шлюз перенаправляет клиента на URL-адрес возврата.
9	Браузер клиента запрашивает страницу с результатами оплаты у магазина.
10	Продавец запрашивает у платёжного шлюза статус оплаты заказа, используя уникальный идентификатор, полученный при регистрации заказа в параметре `orderId`: getOrderStatusExtended;
11	Платёжный шлюз возвращает статус оплаты и продавец передаёт в браузер клиента страницу с результатами оплаты.
12	Не актуально	Для списания средств со счёта клиента продавец должен направить в платёжный шлюз запрос завершения оплаты: завершение с оплатой полной суммой: depositOrder. завершение с оплатой части суммы: depositOrder.
13	Не актуально	Платёжный шлюз возвращает результат обработки запроса. Статус заказа не возвращается. Для получения статуса заказа необходимо отправить в шлюз запрос состояния заказа: getOrderStatusExtended.
14	Если клиент получил товар или услугу не в момент оплаты, необходимо отправить запрос на создание чека закрытия.

Чтобы получить сведения о кассовом чеке (например, чтобы передать эти данные покупателю) используйте запрос getReceiptStatus.do. В настоящее время этот запрос можно выполнить только через интерфейс REST.

Отмена платежа

Отмена оплаты заказа доступна при наличии соответствующих прав по согласованию со «Сбербанком».

При одностадийных платежах отмена платежа возможна для заказов в состоянии Завершён/Deposited, но только до закрытия дня, т. е. до 24:00 (по московскому времени) того дня, когда была произведена оплата.
При двухстадийных платежах отмену платежа можно выполнить для заказа в состоянии Подтверждён/Approved.

В таблице ниже представлена схема взаимодействий продавца и платёжного шлюза при отмене оплаты.

1	Продавец делает запрос на отмену платежа: reverseOrder.
2	После получения успешного ответа платёжного шлюза продавец делает запрос статуса заказа: getOrderStatusExtended.

Возврат средств плательщику

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

Возврат средств возможен для платежей в состоянии Завершён/Deposited.

1	Продавец делает запрос на возврат средств покупателю: возврат полной суммы: refundOrder; частичный возврат: refundOrder.
2	После получения успешного ответа платёжного шлюза продавец делает запрос статуса заказа: getOrderStatusExtended.
3	Если для заказа был осуществлен частичный возврат, то продавец делает запрос закрытия чека: closeOfdReceipt.

Apple Pay

Оплата через Apple Pay (передача корзины)

При оплате с использованием Apple Pay взаимодействие происходит по следующей схеме.

	Одностадийный платёж	Двухстадийный платёж
1	Пользователь в мобильном приложении выбирает вариант оплаты с помощью Apple Pay.
2	Сведения о платеже направляются на обработку в систему Apple Pay.
3	Для обработки данных о платеже в системе Apple Pay создаётся объект `PKPaymentToken Object`, который содержит свойство `paymentData` (здесь и далее см. документацию Apple Pay).
4	Apple Pay направляет продавцу (мобильному приложению) ответ.
5	Продавец извлекает из полученного объекта `PKPaymentToken Object` свойство `paymentData` и кодирует его содержимое в Base64.
6	Продавец создаёт запрос на оплату, содержащий в том числе свойство `paymentData`, полученное из ответа системы Apple Pay и закодированное в Base64, и отправляет его на обработку в платёжный шлюз. Для оплаты через Apple Pay используется следующий запрос: applePay (интерфейс WSDL). При этом параметр `preAuth` либо не передаётся, либо имеет значение `false` (ложь).	Продавец создаёт запрос на оплату, содержащий в том числе свойство `paymentData`, полученное из ответа системы Apple Pay и закодированное в Base64, и отправляет его на обработку в платёжный шлюз. Для оплаты через Apple Pay используется следующий запрос: applePay (интерфейс WSDL). При этом в запросе передаётся параметр `preAuth`, который имеет значение `true` (истина).
7	Платёжный шлюз обрабатывает запрос и возвращает ответ с результатом: интерфейс WSDL.
8	Мобильное приложение отображает пользователю результат оплаты.
9	Продавец запрашивает у платёжного шлюза статус оплаты заказа, используя уникальный идентификатор, полученный при регистрации заказа в параметре `orderId`: getOrderStatusExtended (интерфейс WSDL).
10	Не актуально	Для списания средств со счёта клиента продавец должен направить в платёжный шлюз запрос завершения оплаты: depositOrder (интерфейс WSDL).
11	Не актуально	Платёжный шлюз возвращает результат обработки запроса. Статус заказа не возвращается. Для получения статуса заказа необходимо отправить в шлюз запрос состояния заказа: getOrderStatusExtended (интерфейс WSDL).
12	Если клиент получил товар или услугу не в момент оплаты, необходимо отправить запрос на создание чека закрытия.

Google Pay

Оплата через Google Pay (передача корзины)

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

При отправке запроса в Google Pay используйте следующие параметры:

gateway: sberbank;
gatewayMerchantId: <наименование вашей организации в системе платёжного шлюза>.

При оплате с использованием Google Pay через мобильное приложение взаимодействие происходит по следующей схеме.

	Одностадийный платёж	Двухстадийный платёж
1	Пользователь выбирает способ оплаты Google Pay.
2	Приложение запрашивает Google Pay маскированные данные платёжной карты.
3	Google Pay возвращает в приложение маскированные данные платёжной карты.
4	Приложение отображает клиенту маскированные данные карты, добавленной в Google Pay.
5	Пользователь подтверждает оплату.
6	Приложение запрашивает Google Pay зашифрованные данные платёжной карты.
7	Google шифрует данные, используя открытый ключ - соответствующий ему закрытый ключ расположен в платёжном шлюзе.
8	Google Pay возвращает в приложение зашифрованные данные о платеже.
9	Приложение отправляет в платёжный шлюз запрос на оплату, указывая полученный от Google Pay токен: интерфейс WSDL (googlePay). При этом параметр `preAuth` либо не передаётся, либо имеет значение `false` (ложь).	Приложение отправляет в платёжный шлюз запрос на оплату, указывая полученный от Google Pay токен: интерфейс WSDL (goooglePay). При этом в запросе передаётся параметр `preAuth`, который имеет значение `true` (истина).
10	Платёжный шлюз расшифровывает полученный токен и производит оплату.
11	Платёжный шлюз возвращает результат оплаты в приложение.
12	Приложение отображает результат покупки плательщику.
13	Продавец запрашивает у платёжного шлюза статус оплаты заказа, используя уникальный идентификатор, полученный при регистрации заказа в параметре `orderId`: интерфейс WSDL (getOrderStatusExtended).
14	Не актуально	Для списания средств со счёта клиента продавец должен направить в платёжный шлюз запрос завершения оплаты: интерфейс WSDL (depositOrder).
15	Не актуально	Платёжный шлюз возвращает результат обработки запроса. Статус заказа не возвращается. Для получения статуса заказа необходимо отправить в шлюз запрос состояния заказа: интерфейс WSDL (getOrderStatusExtended).
16	Если клиент получил товар или услугу не в момент оплаты, необходимо отправить запрос на создание чека закрытия.

Samsung Pay

Оплата через Samsung Pay из мобильного приложения

При оплате с использованием Samsung Pay взаимодействие происходит по следующей схеме.

	Одностадийный платёж	Двухстадийный платёж
1	Пользователь выбирает способ оплаты Samsung Pay.
2	Приложение отправляет сведения о платеже в Samsung.
3	Samsung отправляет в приложение ответ содержащий, среди прочего, парамер `3ds.data` с зашифрованными данными о платеже.
4	Продавец отправляет в платёжный шлюз запрос на оплату: интерфейс WSDL (samsungPay). При этом: параметр `paymentToken` включает содержимое `3ds.data`, полученное от Samsung; параметр `preAuth` либо не передаётся, либо имеет значение `false` (ложь).	Продавец отправляет в платёжный шлюз запрос на оплату: интерфейс WSDL (samsungPay). При этом: параметр `paymentToken` включает содержимое `3ds.data`, полученное от Samsung; в запросе передаётся параметр `preAuth`, который имеет значение `true` (истина).
5	Платёжный шлюз расшифровывает полученный токен и производит оплату.
6	Платёжный шлюз возвращает в приложение результат оплаты, который отображается на экране мобильного устройства.
7	Продавец запрашивает у платёжного шлюза статус оплаты заказа, используя уникальный идентификатор, полученный при регистрации заказа в параметре `orderId`: интерфейс WSDL (getOrderStatusExtended).
8	Не актуально	Для списания средств со счёта клиента продавец должен направить в платёжный шлюз запрос завершения оплаты: интерфейс WSDL (depositOrder).
9	Не актуально	Платёжный шлюз возвращает результат обработки запроса. Статус заказа не возвращается. Для получения статуса заказа необходимо отправить в шлюз запрос состояния заказа: интерфейс WS (getOrderStatusExtended).
10	Если клиент получил товар или услугу не в момент оплаты, необходимо отправить запрос на создание чека закрытия.

Оплата по связкам

Оплата по связке (платёжная форма размещена на сервере платёжного шлюза)

	Одностадийная оплата	Двухстадийная оплата
1	Плательщик выбирает товар или услугу на ресурсе продавца и выбирает способ оплаты банковской картой.
2	Продавец отправляет в платёжный шлюз запрос на регистрацию заказа: registerOrder. В том числе в запросе передаются следующие параметры: `clientId` - идентификатор клиента в системе магазина; `returnUrl` - URL-адрес, на который будет перенаправлен плательщик в случае успешного платежа; `failUrl` - URL-адрес, на который будет перенаправлен плательщик в случае неуспешного платежа. При первичной передаче параметра `clientId` происходит регистрация идентификатора клиента в платёжном шлюзе и сохранение данных его карты (кроме CVC-кода). При последующих передачах этого параметра клиент перенаправляется на страницу, где ему предлагается выбор: использовать ранее сохранённые данные платёжной карты - в этом случае клиенту не нужно повторно заполнять данные платёжной карты для оплаты; ввести данные новой платёжной карты - в этом случае к идентификатору этого клиента будут дополнительно привязаны данные новой платёжной карты.	Продавец отправляет в платёжный шлюз запрос на регистрацию заказа с предавторизацией: registerOrderPreAuth. В том числе в запросе передаются следующие параметры: `clientId` - идентификатор клиента в системе магазина; `amount` - сумма списания; `orderNumber` - номер заказа в системе магазина; `returnUrl` - URL-адрес, на который будет перенаправлен плательщик в случае успешного платежа; `failUrl` - URL-адрес, на который будет перенаправлен плательщик в случае неуспешного платежа. При первичной передаче параметра `clientId` происходит регистрация идентификатора клиента в платёжном шлюзе и сохранение данных его карты (кроме CVC-кода). При последующих передачах этого параметра клиент перенаправляется на страницу, где ему предлагается выбор: использовать ранее сохранённые данные платёжной карты - в этом случае клиенту не нужно повторно заполнять данные платёжной карты для оплаты; ввести данные новой платёжной карты - в этом случае к идентификатору этого клиента будут дополнительно привязаны данные новой платёжной карты.
3	Платёжный шлюз в ответе в числе прочего возвращает параметры: `orderId` - уникальный идентификатор заказа в платёжной системе; `formUrl` - URL-адрес формы ввода данных банковской карты (платёжная форма).
4	Продавец перенаправляет плательщику URL-адрес, указанный в параметре `formUrl` ответа.
5	В браузере плательщика отображается форма ввода данных банковской карты. Плательщик заполняет форму и отправляет данные на сервер платёжного шлюза.
6	Дальнейшие действия зависят от того, поддерживает ли карта покупателя 3-D Secure: поддержка 3-D Secure отсутствует - переход к следующему шагу процедуры; есть поддержка 3-D Secure - платёжный шлюз перенаправляет плательщика на форму аутентификации (чаще всего это проверка с помощью SMS-сообщения), расположенную на сервере контроля доступа, принадлежащего банку-эмитенту - в случае успешной аутентификации выполняется следующий шаг сценария.
7	Платёжный шлюз списывает деньги со счёта плательщика.	Платёжный шлюз производит холдирование (удержание) средств на счёте плательщика.
8	После проведения оплаты платёжный шлюз перенаправляет клиента на URL-адрес возврата (указанный магазином в запросе на регистрацию).
9	Браузер клиента запрашивает страницу с результатами оплаты у магазина.
10	Продавец запрашивает у платёжного шлюза статус оплаты заказа, используя уникальный идентификатор, полученный при регистрации заказа в параметре `orderId`: getOrderStatusExtended.
11	Платёжный шлюз возвращает статус оплаты и продавец передаёт в браузер клиента страницу с результатами оплаты.
12	Не актуально	Для списания средств со счёта клиента продавец должен направить в платёжный шлюз запрос завершения оплаты: depositOrder.
13	Не актуально	Платёжный шлюз возвращает результат обработки запроса. Статус заказа не возвращается. Для получения статуса заказа необходимо отправить в шлюз запрос состояния заказа: getOrderStatusExtended.

Отмена платежа

Отмена оплаты заказа доступна при наличии соответствующих прав по согласованию со «Сбербанком».

При одностадийных платежах отмена платежа возможна для заказов в состоянии Завершён/Deposited, но только до закрытия дня, т. е. до 24:00 (по московскому времени) того дня, когда была произведена оплата.
При двухстадийных платежах отмену платежа можно выполнить для заказа в состоянии Подтверждён/Approved.

В таблице ниже представлена схема взаимодействий продавца и платёжного шлюза при отмене оплаты.

1	Продавец делает запрос на отмену платежа: reverseOrder.
2	После получения успешного ответа платёжного шлюза продавец делает запрос статуса заказа: getOrderStatusExtended.

Возврат средств плательщику

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

Возврат средств возможен для платежей в состоянии Завершён/Deposited.

1	Продавец делает запрос на возврат средств покупателю: возврат полной суммы: refundOrder; частичный возврат: refundOrder.
2	После получения успешного ответа платёжного шлюза продавец делает запрос статуса заказа: getOrderStatusExtended.
3	Если для заказа был осуществлен частичный возврат, то продавец делает запрос закрытия чека: closeOfdReceipt.

Операции со связками

{(rater>id=rater8_2|name=Была ли статья полезна?|type=vote)}

Инструменты страницы

Интерфейс WSDL (SOAP)

Введение

Координаты подключения

Возможные сценарии взаимодействия

Обычная оплата

Оплата с указанием карточных данных на платёжной странице

Отмена платежа

Возврат средств плательщику

Оплата с регистрацией чеков на контрольно-кассовой технике

Стандартный API

Оплата с передачей корзины и данных для регистрации чека

Отмена платежа

Возврат средств плательщику

Apple Pay

Оплата через Apple Pay (передача корзины)

Google Pay

Оплата через Google Pay (передача корзины)

Samsung Pay

Оплата через Samsung Pay из мобильного приложения

Оплата по связкам

Оплата по связке (платёжная форма размещена на сервере платёжного шлюза)

Отмена платежа

Возврат средств плательщику

Операции со связками