Open Banking in Germany
Обзор
Введение
Open Banking in Germany — метод интернет-банкинга, базирующийся на применении открытых банковских протоколов и обеспечивающий расширенные возможности для защищённой работы с информацией о пользователях. Этот метод относится к группе Open Banking и позволяет проводить платежи в евро через банки Германии.
В платёжной платформе ecommpay поддерживаются оплаты методом Open Banking in Germany. Для проведения выплат, в том числе в целях возврата средств по проведённым оплатам, при работе с этим методом может использоваться комплементарный метод Выплаты на банковские счета в ЕЗПЕ (SEPA).
В этой статье представлена информация о работе с методом Open Banking in Germany: обзорный раздел с общими сведениями и последующие разделы с информацией о действиях, необходимых со стороны мерчанта для решения разных задач.
Характеристика
Тип платёжного метода | банковские платежи |
---|---|
Платёжные инструменты | банковские счета |
Регионы использования | DE |
Валюты платежей | EUR |
Конвертация валют | на стороне ecommpay |
Разовые оплаты | + |
Повторяемые оплаты | – |
Полные возвраты | – |
Частичные возвраты | – |
Выплаты | – |
Опротестования | – |
Особенности |
|
Организация и стоимость подключения | по согласованию с курирующим менеджером ecommpay; дополнительную информацию можно получить на портале ecommpay shop |
Схема работы
В проведении отдельного платежа с использованием метода Open Banking in Germany задействуются веб-сервис мерчанта, один из интерфейсов и платёжная платформа ecommpay, а также сервисы банка и провайдера, поддерживающих работу с этим методом.
Схематично проведение платежей с использованием метода Open Banking in Germany можно представить следующим образом.
Основные операции
Для проведения оплат с использованием метода Open Banking in Germany могут применяться различные интерфейсы платёжной платформы: Payment Page, Gate и Dashboard (с применением платёжных ссылок на открытие Payment Page). При этом, независимо от используемых интерфейсов, для каждой оплаты применимы ограничения по сумме и времени — с учётом того, через какой банк эта оплата проводится.
Сценарии использования
Оплаты с использованием методов группы Open Banking in Germany проводятся с перенаправлением пользователей к сервису провайдера.
Пользовательский сценарий оплаты через Payment Page (в базовом варианте, с выбором пользователем метода и банка и перенаправлением с итоговой страницы платёжной формы к веб-сервису) выглядит следующим образом.
Базовые сценарии проведения оплат через основные интерфейсы платёжной платформы соответствуют представленным на схемах. В отдельных случаях, например при использовании ряда дополнительных возможностей, эти сценарии могут корректироваться. Вместе с тем, для оплат методом Open Banking in Germany поддерживаются разные варианты выбора банка; они описаны в разделе Оплаты через Payment Page этой статьи. При использовании дополнительных вариантов проведения оплат (например, при оплатах по платёжным ссылкам или при использовании отдельных дополнительных возможностей) эти сценарии корректируются соответствующим образом.
Вместе с тем, к особенностям работы с методом Open Banking in Germany можно отнести то, что для каждого платежа с использованием этого метода должен быть выбран конкретный банк. При работе через Payment Page, как правило, выбор банка осуществляется пользователем уже в платёжной форме, но при вызовах Payment Page с предварительным выбором метода и банка, а также при инициировании оплат через Gate банк должен быть выбран на стороне веб-сервиса и в запросах должен указываться идентификатор этого банка. Возможные варианты выбора банка при работе через Payment Page описаны в разделе Оплаты через Payment Pageэтой статьи, а способы работы с идентификаторами банков — в следующем подразделе, Поддержка со стороны банков.
Поддержка со стороны банков
В проведении платежей с использованием метода Open Banking in Germany могут задействоваться различные банки. В следующей таблице в ознакомительных целях приведены названия и идентификаторы банков, поддерживающих работу с этим методом.
Банк | ID |
---|---|
Deutsche Bank, DB PFB AG | 22731 |
Deutsche Bank, DB PFB AG - Postbank | 22741 |
DKB (Das kann Bank) | 22761 |
HypoVereinsbank eBanking Global | 22701 |
HypoVereinsbank eBanking Global - UK branch | 22711 |
HypoVereinsbank Online Banking | 22691 |
ING-DiBa | 22721 |
Norisbank GmbH | 22751 |
UBS Germany | 22771 |
Поскольку со временем состав доступных банков может меняться, дляДля получения актуальной информации о доступных банках рекомендуется использовать POST-запросы к конечной точке /v2/info/banks/germany/sale/list
, которая относится к группе конечных точек /v2/info/banks/{payment_method}/{operationType}/list
Gate API. В каждом таком запросе должны указываться идентификатор проекта, идентификатор, валюта и сумма платежа и подпись к этим данным; при этом рекомендуется передавать реальные данные о платеже, но допускается и указание произвольных значений.
С вопросами о работе с банками, поддерживающими метод Open Banking in Germany, можно обращаться к курирующему менеджеру ecommpay.
Подтверждение зачисления средств
В некоторых случаях при проведении оплат с использованием метода Open Banking in Germany обработка платежей на стороне провайдера и банка может занимать продолжительное время: вплоть до семи дней и даже больше. В связи с этим возможны ситуации, когда первичная информация о проведении или отклонении платежа не соответствует итоговому результату (например, при получении в платформе информации от провайдера об отклонении платежа позднее средства могут быть всё же зачислены на счёт получателя, и наоборот).
Чтобы обеспечивать в таких случаях корректное уведомление мерчантов о состоянии платежей, в платёжной платформе ecommpay применяется процедура подтверждения зачисления средств получателю. При подключении метода Open Banking in Germany рекомендуется согласовывать с курирующим менеджером применение этой процедуры, а также перевод платежей, по которым получено подтверждение о том, что средства не зачислены, в статус reversed
или decline
(это может быть удобным для контроля и анализа платежей).
Подтверждение зачисления средств выполняется следующим образом:
- После выполнения пользователем всех необходимых действий платёж поступает в обработку на стороне сервиса провайдера, в то время как пользователь возвращается к платёжному интерфейсу (Payment Page или веб-сервиса), где получает информацию о приёме платежа в обработку.
- На стороне платёжной платформы выполняется ряд действий:
- Формируется операция
payment confirmation
. - Платежу присваивается статус
awaiting confirmation
— до получения со стороны провайдера информации о зачислении средств. - К веб-сервису отправляется оповещение об изменении статуса платежа.
- Операции
sale
присваивается статусsuccess
илиdeline
(с учётом специфики работы провайдера) — до получения со стороны провайдера информации о зачислении средств. - К веб-сервису отправляется оповещение об изменении статуса операции.
- Формируется операция
- На стороне провайдера определяется итоговый статус зачисления средств, после чего информация об этом статусе отправляется к платёжной платформе.
- На стороне платёжной платформы обеспечивается обработка полученной информации, в результате чего операции
payment confirmation
и платежу присваиваются итоговые статусы и к веб-сервису отправляются соответствующие оповещения.
Для операции payment confirmation
предусмотрены следующие итоговые статусы:
success
— при получении со стороны провайдера подтверждения того, что средства зачислены. В этом случае платежу присваивается статусsuccess
и к веб-сервису отправляется итоговое оповещение с информацией о результате оплаты.decline
— при получении со стороны провайдера информации о том, что средства не зачислены, либо при отсутствии со стороны провайдера информации о зачислении средств по истечении установленного срока (который по умолчанию составляет 7 дней и может быть изменён через обращение к специалистам технической поддержки ecommpay).В таких случаях, с учётом свойств проекта на стороне платёжной платформы, выполняется один из двух сценариев:
- Формируется операция
reversal
и к веб-сервису последовательно отправляются соответствующие оповещения: промежуточное, с информацией о том, что средства не были зачислены, и итоговое, с информацией о возврате средств и переводе платежа в статусreversed
. - Платёж переводится в статус
decline
и к веб-сервису направляется итоговое оповещение с информацией об отклонении оплаты.
- Формируется операция
Если помимо получения информации, передаваемой в оповещениях, требуется дополнительно отслеживать изменение статусов платежей и операций, это можно делать с использованием Gate API (через ответы на запросы о состоянии платежа), а также через интерфейс Dashboard.
Описания процедуры подтверждения зачисления средств при работе через Payment Page и Gate представлены в соответствующих разделах этой статьи. С вопросами о работе с этой процедурой можно обращаться к специалистам технической поддержки ecommpay.
Оплаты через Payment Page
Общая информация
Для проведения оплаты через Payment Page с использованием метода Open Banking in Germany со стороны веб-сервиса необходимо отправить запрос, содержащий требуемые параметры и подпись, на рабочий URL ecommpay и принять оповещение о результате. При этом следует учитывать, что в процессе проведения платежа пользователь последовательно перенаправляется к сервисам провайдера и банка, для чего от него требуется согласие и в некоторых случаях могут требоваться дополнительные сведения. Для получения такого согласия и сведений (когда они необходимы) в Payment Page отображается соответствующая страница.
Общая схема проведения оплаты выглядит следующим образом.
Как правило, после того как пользователь на стороне веб-сервиса подтверждает готовность перейти к оплате, он перенаправляется к Payment Page, выбирает платёжный метод и, в случае работы с методом Open Banking in Germany, дополнительно выбирает один из доступных банков. Вместе с тем, в некоторых ситуациях могут быть актуальны другие варианты выбора платёжного метода и банка. Например, при открытии Payment Page можно сразу перенаправлять пользователя к выбору банка либо ограничивать список поддерживаемых банков для отдельного платежа и отображать пользователю только кнопки выбора целевых банков. И со стороны веб-сервиса можно управлять применением таких вариантов.
Конкретный вариант выбора платёжного метода и банка определяется через параметры, указанные в запросе на открытие Payment Page (подробнее), при этом допустимы следующие варианты:
- 1 — при открытии платёжной формы в ней последовательно отображаются отдельные страницы для выбора метода и банка, и пользователь выбирает сначала метод, а затем банк (этот вариант используется по умолчанию);
- 2 — при открытии платёжной формы в ней отображается страница с кнопками выбора методов и банков для заданного метода, и пользователь выбирает один из этих банков;
- 3 — при открытии платёжной формы в ней отображается страница с кнопками выбора методов заданной группы и банков для заданного метода, и пользователь выбирает один из этих банков;
- 4 — при открытии платёжной формы в ней отображается страница с кнопками выбора всех доступных банков для заданного метода, и пользователь выбирает один из этих банков;
- 5 — при открытии платёжной формы в ней отображается страница с кнопками выбора заданных банков для заданного метода, и пользователь выбирает один из этих банков;
- 6 — при открытии платёжной формы в ней отображается страница подтверждения для перенаправления к сервису заданного банка, и пользователь соглашается с этим перенаправлением.
При работе с такими оплатами можно использовать следующие варианты выбора метода и банка.
Информация о форматах запросов и оповещений, используемых для проведения оплат методом Open Banking in Germany через Payment Page, приведена далее в этом разделе; общая информация о работе с Payment Page API — в отдельной статье Организация взаимодействия.
Формат запросов
При формировании запросов на открытие платёжной формы с применением метода Open Banking in Germany необходимо учитывать следующее:
- Должен использоваться базовый минимум параметров, обязательный для любого платежа:
project_id
— идентификатор проекта, полученный от ecommpay при интеграции;payment_id
— идентификатор платежа, уникальный в рамках проекта;payment_currency
— буквенный код валюты платежа в формате ISO-4217 alpha-3;payment_amount
— сумма платежа в дробных единицах валюты;customer_id
— идентификатор пользователя в рамках проекта.
- Должен использоваться базовый минимум параметров:
project_id
,payment_id
,payment_currency
,payment_amount
,customer_id
. - Дополнительно рекомендуется указывать имя и фамилию пользователя в параметрах
customer_first_name
иcustomer_last_name
. Если какой-либо или оба из этих параметров отсутствуют в запросе, в платёжной форме могут отображаться соответствующие поля для их указания (подробнее). Подробнее об уточнении параметров — в статье Дополнение информации о платежах.Также в некоторых случаях, с учётом специфики используемого банка, пользователю может требоваться указывать в Payment Page номер счёта (International Bank Account Number, IBAN), в то время как в других случаях этот номер указывается пользователем уже на стороне провайдера или банка. Поскольку этот номер может указываться только пользователем, он не может быть учтён на стороне провайдера или банка даже при его указании в исходном запросе и должен указываться отдельно.
- Поскольку при проведении платежа может требоваться дополнительное согласие пользователя, рекомендуется передавать параметр
merchant_return_url
с указанием адреса для предварительного возвращения пользователя к веб-сервису — чтобы в случае отказа от предоставления согласия пользователь мог вернуться к веб-сервису с помощью соответствующей ссылки в платёжной форме. -
Вариант выбора банка может определяться следующим образом:
- Через выбор в Payment Page метода и банка (1) — как вариант по умолчанию, применяемый, если не указываются параметры
force_payment_method
иpayment_methods_options
, упоминаемые в подпунктах 2–6. - Через выбор в Payment Page банка среди доступных методов (2) — для этого необходимо указывать в значении параметра
payment_methods_options
строковый объект, названием которого выступает указатель метода (online_german_banks
), а содержимым — параметрsplit_banks
со значениемtrue
. При этом в записи такого объекта все вложенные символы"
(U+0022
) должны экранироваться с помощью предшествующих им символов\
(U+005C
)."payment_methods_options": "{\"online_german_banks\": {\"split_banks\": true}}"
В результате использования такого варианта для метода Open Banking in Germany вместо кнопки его выбора отображаются кнопки выбора всех банков, поддерживающих работу с ним.
- Через выбор в Payment Page банка среди методов заданной группы (3) — для этого необходимо:
- Указывать в значении параметра
payment_methods_options
строковый объект, названием которого выступает указатель метода (online_german_banks
), а содержимым — параметрsplit_banks
со значениемtrue
. При этом в записи такого объекта все вложенные символы"
(U+0022
) должны экранироваться с помощью предшествующих им символов\
(U+005C
). - Указывать в значении параметра
force_payment_group
код группыopenbanking
.
"payment_methods_options": "{\"online_german_banks\": {\"split_banks\": true}}", "force_payment_group": "openbanking"
В результате использования такого варианта в платёжной форме отображаются кнопки выбора всех банков, поддерживающих работу с методом Open Banking in Germany, и кнопки выбора других методов группы Open Banking.
- Указывать в значении параметра
- Через выбор в Payment Page банка из числа доступных (4) — для этого необходимо указывать в значении параметра
force_payment_method
код предварительного выбора методаonline-german-banks
."force_payment_method": "online-german-banks"
В результате использования такого варианта в платёжной форме отображаются кнопки выбора всех банков, поддерживающих работу с методом Open Banking in Germany.
- Через выбор в Payment Page банка из числа заданных (5) — для этого необходимо:
- Указывать в значении параметра
payment_methods_options
строковый объект, названием которого выступает указатель метода (online_german_banks
), а содержимым — параметрsplit_banks
со значениемtrue
и массивbanks_id
с идентификаторами целевых банков. При этом в записи такого объекта все вложенные символы"
(U+0022
) должны экранироваться с помощью предшествующих им символов\
(U+005C
). - Указывать в значении параметра
force_payment_method
код предварительного выбора методаonline-german-banks
.
"payment_methods_options": "{\"online_german_banks\": {\"split_banks\": true, \"banks_id\": [54971, 54981]}}", "force_payment_method": "online-german-banks"
В результате использования такого варианта в платёжной форме отображаются кнопки выбора заданных банков, поддерживающих работу с методом Open Banking in Germany.
- Указывать в значении параметра
- Через подтверждение в Payment Page перенаправления к сервису заданного банка (6) — для этого необходимо:
- Указывать в значении параметра
payment_methods_options
строковый объект, названием которого выступает указатель метода (online_german_banks
), а содержимым — параметрsplit_banks
со значениемtrue
и массивbanks_id
с идентификатором целевого банка. При этом в записи такого объекта все вложенные символы"
(U+0022
) должны экранироваться с помощью предшествующих им символов\
(U+005C
). - Указывать в значении параметра
force_payment_method
код предварительного выбора методаonline-german-banks
.
"payment_methods_options": "{\"online_german_banks\": {\"split_banks\": true, \"banks_id\": [54971]}}", "force_payment_method": "online-german-banks"
В результате использования такого варианта при открытии платёжной формы в ней отображается страница подтверждения для перенаправления к сервису заданного банка.
- Указывать в значении параметра
- Через выбор в Payment Page метода и банка (1) — как вариант по умолчанию, применяемый, если не указываются параметры
- Дополнительно могут использоваться любые другие параметры из числа доступных для работы с Payment Page (подробнее).
- После указания всех целевых параметров необходимо составлять подпись (подробнее).
Таким образом, корректный запрос на открытие платёжной формы с применением метода Open Banking in Germany должен содержать идентификатор проекта, базовые сведения о платеже (идентификатор, сумму и код валюты), информацию о пользователе, URL для перенаправления пользователя к веб-сервису и подпись, а также может содержать различные дополнительные параметры.
В случае с выбором из заданных банков (вариант 5), запрос на открытие Payment Page может содержать следующий набор данных.
Формат оповещений
Для оповещений о результатах оплат с применением метода Open Banking in Germany используется типовой формат, описание которого представлено в статье Оповещения(подробнее).
В следующем примере оповещение свидетельствует о том, что в рамках проекта 239
была проведена оплата в размере 10,00 EUR
.
В следующем примере оповещение свидетельствует о том, что оплата была отклонена.
Дополнительные материалы
Для организации работы с оплатами через Payment Page также могут быть полезны следующие материалы:
- Быстрый старт и Организация взаимодействия — о том, как организовать взаимодействие веб-сервиса с платёжной платформой через Payment Page.
- Работа с подписью к данным — о порядке создания и проверки подписи в программных запросах и оповещениях при взаимодействии с платёжной платформой.
- Проведение платежей — о типах, схемах проведения и возможных статусах поддерживаемых платежей и операций.
- Разовая оплата в одну стадию — о том, как проводить разовые оплаты с незамедлительным списанием средств через Payment Page.
- Работа с информацией об операциях — о служебных кодах, которые используются в платёжной платформе, чтобы фиксировать информацию о выполнении операций.
Оплаты через Gate
Общая информация
Для проведения оплаты через Gate с использованием метода Open Banking in Germany со стороны веб-сервиса необходимо:
- Отправить запрос на проведение платежа, содержащий требуемые параметры и подпись, на рабочий URL ecommpay.
- Принять от платёжной платформы промежуточное оповещение о необходимости получить согласие и, если актуально, дополнительные сведения от пользователя.
- Получить от пользователя согласие и дополнительные сведения (если они были запрошены).
- Передать информацию о согласии пользователя и предоставленные им сведения (если они были запрошены) в запросе к платёжной платформе.
- Принять от платёжной платформы промежуточное оповещение с данными для перенаправления пользователя и осуществить перенаправление к сервису провайдера.
- Принять итоговое оповещение от платёжной платформы.
Информация о форматах данных, используемых для получения согласия пользователя и его перенаправления, представлена далее в этом разделе.
Общая схема проведения оплаты выглядит следующим образом.
Информация о форматах запросов и оповещений, используемых для проведения оплат методом Open Banking in Germany через Gate, приведена далее в этом разделе; общая информация о работе с Gate API — в отдельной статье Организация взаимодействия.
Формат запросов
При работе с запросами на оплаты с применением метода Open Banking in Germany необходимо учитывать следующее:
- Для инициирования каждой оплаты должен использоваться отдельный POST-запрос к конечной точке
/v2/payment/banks/germany/sale
, которая относится к группе /v2/payment/banks/{payment_method}/sale. - В каждом запросе должны использоваться следующие объекты и параметры:
general
— объект, содержащий основные идентификационные сведения запроса:project_id
— идентификатор проекта, полученный от ecommpay при интеграции;;payment_id
— идентификатор платежа, уникальный в рамках проекта;;signature
— подпись запроса, составленная после указания всех целевых параметров (подробнее — в статье Работа с подписью к данным); (подробнее);
payment
— объект, содержащий сведения о платеже:amount
— сумма платежа в дробных единицах валюты;currency
— буквенный код валюты платежа в формате ISO-4217 alpha-3;
customer
— объект, содержащий сведения о пользователе:id
— идентификатор пользователя, уникальный в рамках проекта;ip_address
— IP-адрес пользователя, актуальный для инициируемого платежа;
account
— объект, содержащий сведения о банковском счёте пользователя:bank_id
— идентификатор банка;
return_url
— объект, содержащий URL для возвращения пользователя к веб-сервису:return
— URL для возвращения пользователя к веб-сервису при работе с сервисом провайдера или банка в тех случаях, когда пользователь отказывается от проведения платежа.
- Дополнительно рекомендуется указывать в объекте
customer
имя и фамилию пользователя в параметрахfirst_name
иlast_name
соответственно. Если какой-либо или оба из этих параметров отсутствуют в запросе, названия недостающих параметров могут отправляться в оповещении на уточнение.Кроме того, в некоторых случаях, в силу специфики метода, даже если в исходном запросе был указан номер счёта (International Bank Account Number, IBAN), он всё равно запрашивается дополнительно, через указание объекта
account
с параметромnumber
в оповещении на уточнение.Кроме того, в некоторых случаях, с учётом специфики используемого банка, пользователю может требоваться указывать на стороне веб-сервиса номер счёта (International Bank Account Number, IBAN), в то время как в других случаях этот номер указывается пользователем на стороне провайдера или банка. При этом, в силу специфики метода, даже если номер счёта пользователя указывается в исходном запросе, он не учитывается при первичной обработке этого запроса и может быть запрошен отдельно, через указание объекта
account
с параметромnumber
в оповещении на уточнение (вместе с указанием имени и фамилии пользователя, если они не были переданы).Подробнее об уточнении параметров — в статье Дополнение информации о платеже.
- Дополнительно могут использоваться любые другие параметры из числа указанных в спецификации.
Таким образом, корректный запрос на оплату с применением метода Open Banking in Germany должен содержать идентификатор проекта, базовые сведения о платеже (идентификатор, сумму и код валюты), информацию о пользователе, идентификатор банка, URL для перенаправления и подпись, а также может содержать различные дополнительные параметры.
Форматы промежуточных оповещений и запросов для получения согласий и дополнительных сведений
При работе с методом Open Banking in Germany для проведения каждой оплаты требуется получать дополнительное согласие пользователя и, если актуально, дополнительные сведения о нём. Для этого в процессе проведения каждой оплаты от платёжной платформы к веб-сервису направляется промежуточное оповещение с объектом clarification_fields
, во вложенных объектах которого описываются объекты и параметры, необходимые для проведения платежа. в котором указываются:
- параметр
customer.properties.psu_consent_text.default
с текстом, который необходимо отобразить пользователю для получения его согласия на проведение платежа; - параметры, по которым необходимо предоставить дополнительные сведения о пользователе (если это актуально).
Структурно в объект clarification_fields
включаются объекты с заданным набором вложенных элементов (type
, description
, properties
, required
, errors
) для описания каждого запрашиваемого объекта и параметра, при этом объект properties
и массив required
указываются в соответствии со спецификацией JSON Schema.
В структуру каждого объекта, включённого в объект clarification_fields
, входят:
- параметры
type
иdescription
с указанием типа и описания объекта; - объект
properties
с информацией о параметрах, включённых в объект; - массив
required
со списком требуемых параметров; - массив
errors
с информацией о причинах запроса указанных параметров.
В рамках этой структуры объект properties
и массив required
указываются в соответствии со спецификацией JSON Schema, а в объектах массива errors
приводятся параметры property
, message
и constraint
для указания названий запрошенных параметров, поясняющих сообщений и описаний причин.
Текст, который необходимо отобразить пользователю для получения его согласия на проведение платежа, указывается в параметре clarification_fields.customer.properties.psu_consent_text.default
.
В целом, информация о необходимости получения согласия пользователя и дополнительных сведений о нём может выглядеть следующим образом.
После получения на стороне веб-сервиса согласия пользователя и запрошенных сведений каждый раз необходимо отправлять POST-запрос на продолжение платежа —. Такой запрос должен отправляться к конечной точке /v2/payment/clarification методом POST, и в него должны включаться следующие объекты и параметры, с использованием следующих объектов и параметров:
general
— объект, содержащий основные идентификационные сведения запроса:project_id
— идентификатор проекта, к которому относится проводимый платёж.payment_id
— идентификатор платежа, к которому относятся отправляемые данные.signature
— подпись запроса, составленная после указания целевых параметров (подробнее — в статье Работа с подписью к данным).
additional_data
— объект с информацией о согласии пользователя на проведение платежа и дополнительными сведениями (если они необходимы):customer
— объект, содержащий сведения о пользователе:psu_consent
— информация о согласии пользователя на проведение оплаты, со значением1
, если пользователь предоставил такое согласие.Если пользователь не предоставил согласие, то запрос на продолжение платежа можно не отправлять. В таких случаях по истечении 30 минут (или иного времени, если это было настроено для используемого проекта) определённого времени платёж отклоняется. При отправке запросов со значением параметра
psu_consent
, отличным от1
, согласие на проведение платежа запрашивается повторно.psu_consent_text
— текст, который был отображён пользователю для получения согласия. В значении этого параметра должен передаватьсяЭто должен быть именно тот текст, который был получен в оповещении о необходимости получения согласия пользователя. Если текст, указанный в запросе, отличается от текста, отправленного в оповещении, согласие на проведение платежа запрашивается повторно.
<additional_parameters>
— параметры, по которым были запрошены дополнительные сведения о пользователе.
Таким образом, корректный запрос на продолжение платежа должен содержать идентификаторы проекта и платежа, информацию о согласии пользователя, текст, который был отображён пользователю, дополнительные сведения (если они были запрошены) и подпись.
Формат промежуточных оповещений для перенаправления пользователей
Для перенаправления пользователей от веб-сервиса мерчанта к сервису провайдера при проведении каждого платежа с использованием метода Open Banking in Germany необходимо принять промежуточное оповещение от платёжной платформы и использовать информацию из него, включённую в объект redirect_data
. Формат таких оповещений является типовым (подробнее), при этом в состав объекта redirect_data
включаются следующие объекты и параметры:
body
— объект с данными для отправки в теле запроса;method
— параметр с указанием HTTP-метода отправки запроса (GET
илиPOST
);url
— параметр со ссылкой для перенаправления.
Формат итоговых оповещений
Для итоговых оповещений об оплатах с применением метода Open Banking in Germany используется типовой формат, описание которого представлено в статье Оповещения(подробнее).
В следующем примере оповещение свидетельствует о том, что в рамках проекта 239
была проведена оплата в размере 10,00 EUR
.
В следующем примере оповещение свидетельствует о том, что оплата была отклонена.
Дополнительные материалы
Для организации работы с оплатами через Gate также могут быть полезны следующие материалы:
- Быстрый старт и Организация взаимодействия — о том, как организовать взаимодействие с платёжной платформой через Gate.
- Работа с подписью к данным — о порядке создания и проверки подписи в программных запросах и оповещениях при взаимодействии с платёжной платформой.
- Проведение платежей — о типах, схемах проведения и возможных статусах поддерживаемых платежей и операций.
- Разовая оплата в одну стадию — о том, как проводить разовые оплаты с незамедлительным списанием средств через Gate.
- Работа с информацией об операциях — о служебных кодах, используемых в платёжной платформе для фиксации информации о выполнении операций.
Анализ результатов проведения платежей
Для анализа информации о платежах и операциях, как в отдельности по методу Open Banking in Germany, так и в совокупности с другими методами, можно использовать:
- инструментарий интерфейса Dashboard, с различными реестрами и аналитическими панелями;,
- отчёты в формате CSV, выгружаемые (как разово, так и периодически) через раздел Отчёты интерфейса Dashboard;,
- данные в формате JSON, получаемые по программным запросам через интерфейс Data API.
С вопросами по анализу информации о платежах и операциях можно обращаться к разделам документации (Dashboard и Использование Data API) и специалистам ecommpay.