Работа с оповещениями
Обзор
Введение
Оповещение — это техническое сообщение, отправляемое от платёжной платформы ecommpay к веб-сервису мерчанта и содержащее информацию об определённом событии в платёжной платформе, как правило связанном с проведением платежа или хранением платёжных данных пользователя.
Оповещения позволяют своевременно получать информацию о различных событиях, при этом состав и условия отправки оповещений можно гибко конфигурировать, определяя что именно, в каких случаях, в каком виде и куда отправлять. В этой статье представлена информация об оповещениях, а также о порядке и особенностях работы с ними.
Оповещение — это техническое сообщение, отправляемое от платёжной платформы ecommpay к веб-сервису мерчанта и содержащее заданную информацию об определённом событии. В этой статье представлена информация об оповещениях, а также о порядке и особенностях работы с ними.
Виды оповещений
Оповещения можно условно разделить на предписывающие, требующие каких-либо действий со стороны веб-сервиса, и уведомительные, содержащие информацию к сведению.
Оповещения можно условно разделить на предписывающие и уведомительные.
Предписывающие оповещения направляются в случаях, когда требуется отправить какие-либо сведения в платёжную платформу, предоставить определённую информацию пользователю, перенаправить его к сторонним сервисам или выполнить иные действия. Такие оповещения всегда содержат только промежуточную информацию о платежах и от их получения нельзя отказаться, поскольку своевременное реагирование на эти оповещения необходимо для корректного проведения платежей.
Предписывающие оповещения направляются в случаях, когда требуется отправить какие-либо сведения в платёжную платформу, предоставить определённую информацию пользователю, перенаправить его к сторонним сервисам или выполнить иные действия. Такие оповещения всегда содержат только промежуточную информацию о платежах и от их получения нельзя отказаться.
Уведомительные оповещения направляются в случаях, когда можно принять и использовать определённую информацию, например об изменении статуса платежа или о формировании токена карты. Такие оповещения могут содержать промежуточную или итоговую информацию о платежах и от их получения можно отказываться (выборочно или полностью).
Типовые случаи применения
К типовым случаям применения оповещений можно отнести следующие.
- Изменение статуса платежа.
Это могут быть оповещения как с промежуточной, так и с итоговой информацией о проведении платежа.
- Необходимость действий на стороне веб-сервиса.
Как правило, это оповещения с информацией для перенаправления пользователей, для отображения им определённой информации и для указания дополнительных данных, необходимых для проведения платежа.
- Формирование или удаление токена платёжной карты.
Это оповещения с информацией о событиях, связанных с токенами платёжных карт (таких, как формирование и удаление токенов).
Подключение и настройка
Конфигурирование для проектов
В общем случае отправка оповещений для рабочих проектов мерчанта настраивается при интеграции веб-сервиса с платёжной платформой ecommpay. Вместе с тем, для изменения правил отправки оповещений всегда можно использовать возможности интерфейса Dashboard (подробнее), а также указывать специальные параметры в запросах на проведение платежей (подробнее далее) и при необходимости обращаться к специалистам технической поддержки ecommpay.
Со стороны мерчанта для оповещений можно настраивать следующие свойства:
В общем случае отправка оповещений настраивается при интеграции веб-сервиса с платёжной платформой ecommpay. Вместе с тем, со стороны мерчанта (используя возможности Dashboard и Gate API, а также обращения в техническую поддержку) всегда можно настраивать следующие свойства:
- Обязательность отправки.
Оповещения могут отправляться как для всех событий, так и только для событий, соответствующих заданным условиям: по типам событий, платёжным методам, а также типам и статусам платежей и операций. Так, например, оповещения могут не отправляться для проведённых выплат на платёжные карты и отправляться для отклонённых. Это позволяет оперативно получать только необходимую информацию.
Оповещения могут отправляться как для всех событий, так и только для событий, соответствующих заданным условиям: по типам событий, платёжным методам, а также типам и статусам платежей и операций.
- Адреса доставки.
Оповещения по разным событиям могут отправляться на разные адреса веб-сервиса, с учётом типа события, платёжного метода, типа и статуса платежа и операции. Например, оповещения с итоговой информацией о проведении платежей могут отправляться на один адрес, а об отклонении платежей — на другой.
Оповещения по разным событиям могут отправляться на разные адреса веб-сервиса, с учётом типа события, платёжного метода, типа и статуса платежа и операции.
- Время задержки отправки.
При необходимости оповещения могут отправляться с задержкой до 600 секунд включительно, например для удобства их обработки на стороне веб-сервиса.
При необходимости оповещения могут отправляться с задержкой до 600 секунд включительно.
- Состав параметров.
Для удобства обработки на стороне веб-сервиса состав информации, передаваемой в оповещениях, можно варьировать: добавлять и удалять параметры, а также заменять их названия и определять обязательность включения параметров с пустыми значениями. При этом нельзя менять структуру оповещений и исключать обязательные параметры.
Стоит учитывать, что отдельные параметры могут быть обязательными для всех или только для определённых типов оповещений. Обязательные параметры передаются в оповещениях в любом случае, а необязательные — только в тех случаях, когда была получена соответствующая информация либо когда настроена отправка таких параметров даже с пустыми значениями.
Таким образом, оповещения об одинаковых событиях в разных случаях могут выглядеть по-разному.
Состав информации, передаваемой в оповещениях, можно варьировать: добавлять и удалять параметры, а также заменять их названия и определять обязательность включения параметров с пустыми значениями. При этом нельзя менять структуру оповещений и исключать обязательные параметры.
Управление отправкой для отдельных платежей
При проведении платежей через Gate можно задавать адреса доставки оповещений, их обязательность и время задержки при отправке. Для этого в запросах на проведение платежей могут использоваться следующие параметры:
merchant_callback_url
(в объектеgeneral
) — адрес доставки оповещений по этому запросу;force_disable
(в объектеcallback
) — указатель запрета отправки оповещений (со значениямиtrue
для запрета отправки оповещений с информацией о данном платеже иfalse
для разрешения их отправки);delay
(в объектеcallback
) — задержка отправки оповещений, в секундах (от 0 до 600; например,42
).
Информацию о возможности использования этих параметров при запросах к конкретным конечным точкам можно найти в спецификации Gate API.
Использование
Порядок работы
Технически оповещение представляет собой HTTP-POST-сообщение, отправляемое на предоставленный мерчантом URL. Порядок реагирования на каждое поступающее оповещение со стороны веб-сервиса сводится к следующим шагам:
Порядок реагирования на каждое поступающее оповещение со стороны веб-сервиса сводится к следующим шагам:
- Принять и проверить оповещение.
Принимать оповещения следует только с IP-адресов платёжной платформы, предоставленных специалистами технической поддержки ecommpay. При этом не следует ограничивать время ожидания оповещений, поскольку разные события могут наступать в различное время, а для отправки дополнительно может использоваться задержка.
Чтобы подтверждать достоверность отправителя и целостность данных, необходимо проверять подпись, включаемую в состав каждого оповещения. Подробнее о такой проверке — в разделе Работа с подписью к данным.
Оповещения следует принимать только с IP-адресов платёжной платформы, предоставленных ecommpay, и без ограничения времени ожидания. При этом для подтверждения целостности в каждом полученном оповещении необходимо проверять подпись.
- Подтвердить получение оповещения.
Чтобы подтверждать получение оповещений, необходимо отправлять к платёжной платформе синхронные HTTP-сообщения: при приёме оповещений без ошибок — с кодом ответа
200 ОК
, в остальных случаях — с кодами ответов, соответствующими ошибкам, напримерHTTP 400 Bad Request
, если не удалось преобразовать строку параметров в массив, илиHTTP 500 Internal Server Error
, если оповещение поступило на некорректный URL веб-сервиса.Чтобы подтверждать получение оповещений, необходимо отправлять к платёжной платформе синхронные HTTP-сообщения: при приёме оповещений без ошибок — с кодом ответа
200 ОК
, в остальных случаях — с кодами ответов, соответствующими ошибкам, напримерHTTP 400 Bad Request
.Если от веб-сервиса не поступило сообщение с кодом ответа
200 ОК
, независимо от характера ошибки оповещение отправляется повторно. - Выполнить необходимые действия.
При получении предписывающих оповещений необходимо выполнять действия согласно этим оповещениям, при получении уведомительных — согласно специфике работы веб-сервиса, например с уведомлениями пользователей.
Повторные отправления
Если в платёжной платформе получена информация об ошибке при приёме оповещения или получение оповещения не подтверждено, такое оповещение отправляется повторно. При этом сведения в повторно отправляемых оповещениях могут меняться при изменении соответствующей информации в платёжной платформе: например, при изменении статуса платежа в последующие за этим оповещения включается информация уже о новом статусе.
В общем случае отправка повторных оповещений выполняется в следующем порядке:
Если в платёжной платформе получена информация об ошибке при приёме оповещения или получение оповещения не подтверждено, такое оповещение отправляется повторно. Для повторных отправлений используется следующий порядок:
- 6 попыток с нарастающим интервалом, от 10 до 60 секунд с увеличением на 10 секунд для каждой попытки.
- 58 попыток с нарастающим интервалом, от 84 секунд до 2,5 часов с увеличением по формуле
70 + 10 × 1,12n − 4
(в секундах), где n — порядковый номер попытки. - 56 попыток каждые 4 часа до достижения в общей сложности 120 попыток, после чего отправка оповещений по этому событию прекращается.
Этот порядок может незначительно меняться с учётом загруженности серверов и каналов связи, но в целом автоматические попытки доставить оповещение укладываются в 11 суток. Для изменения этого порядка можно обращаться к специалистам технической поддержки ecommpay.
Для изменения этого порядка можно обращаться к специалистам технической поддержки ecommpay.
Кроме того, помимо автоматической повторной отправки оповещений в необходимых случаях можно инициировать разовые повторные отправки с помощью интерфейса Dashboard и Telegram-бота.
Устранение неисправностей
Оповещения могут не приходить на требуемые адреса по различным причинам. Со стороны мерчанта такие ситуации и способы реагирования на них можно разбить на несколько групп.
- Не приходят оповещения ни по одному из событий.
Это может быть связано с отсутствием в платёжной платформе целевых запросов и событий, с проблемами в каналах связи и недействительностью заданных URL веб-сервиса, а также с отключением отправки оповещений по проекту.
В таких ситуациях рекомендуется:
- Убедиться, что со стороны веб-сервиса отправлялись корректные запросы (без запрета отправки оповещений) и они были приняты со стороны платформы. При необходимости отправить тестовый запрос, например на формирование токена платёжной карты.
- Если запросы принимаются в платформе, но оповещения по-прежнему не приходят — проверить работоспособность URL для приёма оповещений. При обнаружении проблем восстановить работоспособность адресов или изменить их на корректные: самостоятельно, через интерфейс Dashboard, или с помощью специалистов технической поддержки ecommpay.
- Если по итогам предыдущих действий проблему не удалось решить — обратиться к специалистам технической поддержки ecommpay.
- Не приходят оповещения по событиям отдельных типов.
Это может быть связано с отсутствием событий таких типов, с недействительностью URL веб-сервиса или с отключением отправки оповещений для событий этих типов.
В таких ситуациях рекомендуется:
- Убедиться в наличии событий тех типов, по которым не приходят оповещения, используя карточки платежей в интерфейсе Dashboard.
- Если такие события выполнялись, но оповещения по-прежнему не приходят — проверить работоспособность URL для приёма оповещений по событиям соответствующих типов. При обнаружении проблем восстановить работоспособность адресов или изменить их на корректные: самостоятельно, через интерфейс Dashboard, или с помощью специалистов технической поддержки ecommpay.
- Если проблему не удалось решить — обратиться к специалистам технической поддержки ecommpay.
- Не приходит оповещение по конкретной операции.
Это может быть связано с тем, что в объекте
callback
запроса на выполнение операции был передан параметрforce_disable
со значениемtrue
.В такой ситуации уточнять состояние операции можно через Gate, используя запросы на получение соответствующей информации (подробнее), Dashboard и Telegram-бота.
Оповещения могут не приходить на требуемые адреса по различным причинам: например, из-за отсутствия в платёжной платформе целевых запросов и событий, наличия проблем в каналах связи или недействительности заданных URL веб-сервиса. Со стороны мерчанта реагирование на такие ситуации можно свести к следующим действиям:
- Убедиться, что для используемого проекта или для событий отдельных типов по этому проекту не отключена отправка оповещений.
- Убедиться, что со стороны веб-сервиса отправляются корректные запросы (без запрета отправки оповещений) и они принимаются на стороне платформы. При необходимости отправить тестовый запрос.
- Проверить работоспособность URL для приёма оповещений. При обнаружении проблем восстановить работоспособность адресов или изменить их на корректные: самостоятельно, через интерфейс Dashboard, или с помощью специалистов технической поддержки ecommpay.
- Если проблему не удалось решить — обратиться к специалистам технической поддержки ecommpay.
Передаваемые параметры
Параметры оповещений о платежах и операциях
Состав и названия параметров, передаваемых в оповещенияx о платежах и операциях, могут быть базовыми или индивидуально настроенными для отдельных проектов. К базовым относятся следующие параметры.
Параметр | Описание | tree |
---|---|---|
account |
Объект, содержащий информацию о платёжных данных пользователя (например, данных платёжной карты, счёта или электронного кошелька) | 10 |
card_holder |
Имя держателя платёжной карты. Пример: |
10-10 10 |
expiry_month |
Порядковый номер месяца срока действия платёжной карты. Пример: |
10-20 10 |
expiry_year |
Год срока действия платёжной карты. Пример: |
10-30 10 |
id |
Идентификатор сохранённых платёжных данных, используемый в платёжной платформе (подробнее). Пример: |
10-40 10 |
number |
Маскированный номер или иной идентификатор платёжного инструмента пользователя (например, платёжной карты, счёта или электронного кошелька). Пример: |
10-50 10 |
token |
Токен платёжной карты, если он был сформирован при выполнении запроса (подробнее) |
10-60 10 |
type |
Указатель бренда платёжной карты, с использованием которой был проведён платёж: |
10-70 10 |
acs |
Объект, содержащий информацию о результате аутентификации пользователя с применением протокола 3‑D Secure | 20 |
acs_url |
Адрес страницы, на которую перенаправлялся пользователь для его аутентификации с применением протокола 3‑D Secure (ACS-страницы) |
20-10 20 |
md |
Данные о мерчанте, полученные от международной платёжной системы при аутентификации пользователя с применением протокола 3‑D Secure (Merchant Data) |
20-20 20 |
pa_req |
Сообщение PAReq (Payer Authentication Request), полученное при аутентификации пользователя с применением протокола 3‑D Secure | 20-30 20 |
avs_data |
Объект, содержащий информацию о результате проверки Address Verification Service (AVS, подробнее) | 30 |
avs_post_code |
Почтовый индекс пользователя, переданный для выполнения проверки AVS. Пример: |
30-10 30 |
avs_street_address |
Адрес пользователя, переданный для выполнения проверки AVS. Пример: |
30-20 30 |
avs_result |
Код результата проверки AVS (подробнее). Пример: |
40 |
bank |
Объект, содержащий информацию об эмитенте платёжной карты, использованной при проведении платежа | 50 |
name |
Название эмитента в платёжной платформе. Пример: |
50-10 50 |
customer |
Объект, содержащий информацию о пользователе | 70 |
billing |
Объект, содержащий информацию о платёжном адресе пользователя, полученном в платёжной платформе при проведении платежа | 70-10 70 |
address |
Название улицы расчётного адреса пользователя. Пример: |
70-10-10 70-10 |
city |
Название города платёжного адреса пользователя. Пример: |
70-10-20 70-10 |
country |
Код страны платёжного адреса пользователя в формате ISO 3166-1 alpha-2. Пример: |
70-10-30 70-10 |
postal |
Индекс платёжного адреса пользователя. Пример: |
70-10-40 70-10 |
region |
Название региона (района, области, края или республики) платёжного адреса пользователя. Пример: |
70-10-50 70-10 |
city |
Название города пользователя. Пример: |
70-20 70 |
country |
Код страны пользователя в формате ISO 3166-1 alpha-2. Пример: |
70-30 70 |
day_of_birth |
Дата рождения пользователя в формате ДД-ММ-ГГГГ. Пример: |
70-40 70 |
first_name |
Имя пользователя. Пример: |
70-50 70 |
id |
Идентификатор пользователя в рамках проекта мерчанта. Пример: |
70-60 70 |
ip_address |
IP-адрес пользователя, актуальный для данной операции. Пример: |
70-70 70 |
last_name |
Фамилия пользователя. Пример: |
70-80 70 |
middle_name |
Отчество или среднее имя пользователя. Пример: |
70-90 70 |
phone |
Номер телефона пользователя, содержащий от 4 до 24 цифр. Пример: |
70-100 70 |
decision |
Строка, содержащая информацию об оценке допустимости проведения платежа на стороне платёжной платформы | 80 |
decision_message |
Массив записей, содержащий информацию об оценке допустимости проведения платежа на стороне платёжной платформы. Пример: |
90 |
display_data |
Объект, содержащий информацию, необходимую для отображения пользователю. Как правило, в этом объекте передаются сведения, полученные от провайдера или платёжной системы. Специфика для разных платёжных методов обычно указывается в статьях с описанием этих методов. Пример: |
100 |
errors |
Массив с сообщениями об ошибках, полученных при выполнении запроса | 110 |
ErrorItem |
Объект, содержащий информацию об ошибке при выполнении запроса | 110-10 110 |
code |
Код ошибки. Пример: |
110-10-10 110-10 |
description |
Сведения о причине ошибки. Пример: |
110-10-10 110-10 |
field |
Название параметра, при указании которого была допущена ошибка (если такой параметр определён) | 110-10-20 110-10 |
message |
Пояснение к коду ошибки. Пример: |
110-10-30 110-10 |
interface_type |
Объект, содержащий информацию о способе инициирования платежа | 120 |
id |
Индикатор интерфейса, через который поступил исходный запрос:
|
120-10 120 |
user |
Сведения об учётной записи пользователя Dashboard, отправившего исходный запрос. Пример: |
120-20 120 |
operation |
Объект, содержащий информацию об операциях, относящихся к платежу | 130 |
code |
Код состояния операции (подробнее). Пример: |
130-10 130 |
created_date |
Дата и время создания операции. Пример: |
130-20 130 |
date |
Дата и время последнего обновления статуса операции в платёжной платформе. Пример: |
130-30 130 |
eci |
Индикатор результата аутентификации пользователя с применением протокола 3‑D Secure (подробнее). Пример: |
130-40 130 |
id |
Идентификатор операции в платёжной платформе. Пример: |
130-50 130 |
message |
Пояснительное описание к коду состояния операции (подробнее). Пример: |
130-60 130 |
provider |
Объект, содержащий информацию о результате выполнения платежа, полученную от провайдера или платёжной системы | 130-70 130 |
auth_code |
Код авторизации, полученный от провайдера или платёжной системы. Пример: |
130-70-10 130-70 |
date |
Дата и время завершения обработки платежа на стороне провайдера или платёжной системы. Пример: |
130-70-20 130-70 |
endpoint_id |
CRC32-идентификатор провайдера или платёжной системы. Пример: |
130-70-30 130-70 |
id |
Идентификатор провайдера или платёжной системы в платёжной платформе. Пример: |
130-70-40 130-70 |
payment_id |
Идентификатор платежа на стороне провайдера или платёжной системы. Пример: |
130-70-50 130-70 |
recurring_retry |
Объект, содержащий информацию о повторных попытках списаний в рамках регулярных оплат (подробнее) | 130-80 130 |
next_retry_date |
Дата и время следующей попытки списания. Пример: |
130-80-10 130-80 |
next_retry_exists |
Индикатор наличия следующей запланированной попытки списания:
Этот параметр обязателен, если передан объект |
130-80-20 130-80 |
retry_count |
Номер повторной попытки (число от 1 до 7), если такая попытка была выполнена. Пример: |
130-80-30 130-80 |
trigger_operation_id |
Идентификатор очередного списания, для которого была выполнена повторная попытка. Пример: |
130-80-40 130-80 |
request_id |
Идентификатор последнего запроса, относящегося к данной операции, в платёжной платформе |
130-90 130 |
status |
Статус операции (в соответствии с моделью проведения платежей). Пример: |
130-100 130 |
sum_converted |
Объект, содержащий информацию о сумме и валюте операции после конвертации (подробнее о конвертации) | 130-110 130 |
amount |
Сумма операции. В дробных единицах валюты, если они применимы, или в целых единицах. Пример: |
130-110-10 130-110 |
currency |
Код валюты операции в формате ISO 4217 alpha-3. Пример: |
130-110-20 130-110 |
sum_initial |
Объект, содержащий информацию о сумме и валюте операции, переданных в запросе | 130-120 130 |
amount |
Исходная сумма операции в дробных единицах валюты. Пример: |
130-120-10 130-120 |
currency |
Код исходной валюты операции в формате ISO 4217 alpha-3. Пример: |
130-120-20 130-120 |
type |
Тип операции (в соответствии с моделью проведения платежей). Пример: |
130-130 130 |
payment |
Объект, содержащий основные сведения о платеже | 140 |
cascading_with_redirect |
Индикатор необходимости получить подтверждение пользователя на дополнительную попытку проведения оплаты в случае получения отказа при выполнении аутентификации 3‑D Secure (подробнее):
|
140-10 140 |
date |
Дата и время последнего обновления статуса платежа в платёжной платформе. Пример: |
140-20 140 |
description |
Описание платежа, переданное в исходном запросе. Пример: |
140-30 140 |
id |
Идентификатор платежа, переданный в исходном запросе. Пример: |
140-40 140 |
is_new_attempts_available |
Индикатор возможности выполнить повторную попытку оплаты (подробнее):
|
140-50 140 е |
method |
Код платёжного метода (подробнее). Пример: |
140-60 140 |
merchant_refund_id |
Идентификатор, полученный при инициировании возврата со стороны веб-сервиса. Пример: |
140-61 140 |
OperationFee |
Объект, содержащий информацию о сумме комиссии | 140-70 140 |
amount |
Сумма комиссии в дробных единицах валюты, если эта сумма включена в общую сумму операции | 140-70-10 140-70 |
currency |
Код валюты, в которой начислена комиссия, в формате ISO 4217 alpha-3 | 140-70-20 140-70 |
sum_with_surcharge |
Общая сумма операции и надбавленной комиссии в дробных единицах валюты | 140-70-30 140-70 |
surcharge_amount |
Сумма комиссии, надбавленной к сумме платежа, в дробных единицах валюты (применяется для микрофинансовых организаций, МФО) | 140-70-40 140-70 |
surcharge_currency |
Код валюты, в которой начислена сумма комиссии, надбавленная к сумме платежа, в формате ISO 4217 alpha-3 | 140-70-50 140-70 |
region |
Код региона выполнения операции (подробнее). Пример: |
140-80 140 |
status |
Cтатус платежа (в соответствии с моделью проведения платежей). Пример: |
140-90 140 |
sum |
Объект, содержащий информацию о сумме и валюте платежа | 140-100 140 |
amount |
Сумма платежа с учётом всех выполненных операций, в дробных единицах валюты. Пример: |
140-100-10 140-100 |
currency |
Код валюты платежа, переданный в исходном запросе, в формате ISO 4217 alpha-3. Пример: |
140-100-20 140-100 |
timeout_attempts |
Время, в течение которого возможно выполнение повторных попыток оплаты (подробнее), в секундах. Пример: |
140-110 140 |
type |
Тип платежа (в соответствии с моделью проведения платежей). Пример: |
140-120 140 |
scheme_id |
Идентификатор операции, в рамках которой была зарегистрирована повторяемая оплата, на стороне международной платёжной системы (Mastercard или Visa). Может передаваться при регистрации повторяемой оплаты для карты, выпущенной в Европейской экономической зоне. Пример: |
210 |
project_id |
Идентификатор проекта мерчанта в платёжной платформе. Пример: |
150 |
provider_extra_fields |
Объект, содержащий информацию, поступившую от провайдера или платёжной системы | 160 |
recurring |
Объект, содержащий информацию о повторяемой оплате (подробнее) | 170 |
currency |
Код валюты повторяемой оплаты в формате ISO 4217 alpha-3. Пример: |
170-10 170 |
id |
Идентификатор записи о серии списаний, присвоенный на стороне платёжной платформы (подробнее) в платёжной платформе. Пример: |
170-20 170 |
register_payment_id |
Идентификатор записи о серии списаний (подробнее) в веб-сервисе мерчанта. Пример: |
170-30 170 |
status |
Статус записи о серии списаний (подробнее):
|
170-40 170 |
type |
Тип повторяемой оплаты (подробнее):
|
170-50 170 |
valid_thru |
Дата, до наступления которой возможно выполнение списаний (подробнее). Пример: |
170-60 170 |
redirect_data |
Объект, содержащий данные для перенаправления пользователя | 180 |
body |
Данные для перенаправления пользователя | 180-10 180 |
method |
Требуемый HTTP-метод отправки запроса на перенаправление: POST или GET |
180-20 180 |
url |
URL, на который требуется направить пользователя | 180-30 180 |
signature |
Подпись оповещения (подробнее) | 190 |
Параметры оповещений о токенах
Состав и названия параметров, передаваемых в оповещенияx о действиях с токенами, таких как формирование или удаление токенов, могут быть базовыми или индивидуально настроенными для отдельных проектов. К базовым относятся следующие параметры.Параметр | Описание | |
---|---|---|
general |
Объект с основными идентификационными сведениями из исходного запроса на формирование токена | 1 |
project_id |
Идентификатор проекта мерчанта в платёжной платформе. Пример: |
1-11 |
customer_id |
Идентификатор пользователя в проекте мерчанта. Пример: |
1-21 |
signature |
Подпись оповещения | 1-31 |
request |
Объект со сведениями об исходном запросе | 2 |
id |
Идентификатор исходного запроса |
2-12 |
action |
Тип исходного запроса:
Этот параметр может отсутствовать в случае, если токен деактивирован по истечению его срока действия и отправка оповещения инициирована автоматически в связи с этим событием |
2-22 |
status |
Статус запроса:
|
2-32 |
errors |
Массив с информацией об ошибках, возникших при выполнении запроса. Этот массив не передаётся в случаях, когда запрос выполнен без ошибок |
2-42 |
ErrorItem |
Объект с информацией об ошибке, возникшей при выполнении запроса | 2-4-12-4 |
code |
Код ошибки, возникшей при выполнении запроса. Пример: |
2-4-1-12-4-1 |
message |
Поясняющее описание к коду ошибки. Пример: |
2-4-1-22-4-1 |
field |
Название параметра исходного запроса, в котором допущена ошибка, если этот параметр определён | 2-4-1-32-4-1 |
token |
Токен платёжной карты |
3 |
token_created_at |
Дата и время формирования токена карты. Пример: |
4 |
token_status |
Статус токена:
|
5 |
Дополнительные материалы
При работе с оповещениями могут быть полезны:
- Организация взаимодействия — раздел с общей информацией о взаимодействии с платёжной платформой через Gate.
- Работа с подписью к данным — раздел с информацией о работе с подписью к данным.
- Информация об операциях — раздел с информацией о кодах ошибок, используемых в платёжной платформе.
- Контроль и проведение платежей — раздел с информацией о проведении и контроле проведения платежей и операций через Dashboard.
- Работа с Telegram-ботом технической поддержки — раздел с информацией о контроле проведения платежей и операций с помощью Telegram-бота.
- Использование токенов — раздел с информацией о работе с токенами карт.
- API Reference — спецификация интерфейса Gate API.