Работа с повторными попытками автоматических списаний

Технически повторные попытки списаний выполняются следующим образом:

1. При отклонении со стороны платёжной системы или эмитента исходной попытки очередного списания в платёжной платформе Flashpay очередного списания проверяется возможность повторить попытку, и если эта возможность подтверждается, то к веб-сервису направляется оповещение об отклонении списания со статусом операции decline и с плановыми датой и временем повторной попытки.
2. В заданное время автоматически выполняется повторная попытка списания.
3. Исходя из результата повторной попытки выполняются последующие действия:
   • Если попытка приводит к переводу необходимых средств от пользователя к мерчанту, то к веб-сервису направляется оповещение о результате списания (со статусом операции success) и оплата проводится дальше согласно графику.
   • Если попытка отклоняется и в платёжной платформе подтверждается возможность выполнить следующую попытку, то к веб-сервису направляется повторное оповещение об отклонении списания (со статусом операции decline и с плановыми датой и временем следующей попытки) и шаг 2 повторяется.
   • Если попытка отклоняется и в платёжной платформе не подтверждается возможность выполнить следующую попытку, то к веб-сервису направляется итоговое оповещение об отклонении списания (со статусом операции decline и без информации о следующей попытке) и оплата проводится дальше согласно графику. В таком случае решения относительно необходимости дополнительных списаний или завершения серии списаний и оплаты в целом должны приниматься на стороне мерчанта.

Общая схема этого процесса выглядит следующим образом.

Формат оповещений, используемых в рамках этого процесса, описан далее.

Чтобы подключить возможность работы с повторными попытками автоматических списаний, со стороны мерчанта необходимо:

1. Согласовать подключение с курирующим менеджером Flashpay подключение этой возможности и необходимость её тестирования.
2. Если была согласована необходимость тестирования, получить от специалистов Flashpay уведомление о готовности к тестированию, проверить корректность работы с использованием этой возможности и сообщить о готовности к запуску.
3. Получить от специалистов Flashpay уведомление о подключении возможности.

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

Для получения информации о планировании и выполнении каждой повторной попытки списания можно использовать оповещения от платформы. Общая информация о работе с такими оповещениями представлена в отдельной статье. В случаях, когда для автоматических списаний по проекту используются повторные попытки, в оповещения включается дополнительный объект recurring_retry, в структуре которого, в зависимости от ситуации, могут использоваться следующие параметры со следующими параметрами:

• trigger_operation_id — идентификатор очередного списания, для которого была выполнена повторная попытка. Указывается в тех случаях, когда была выполнена по крайней мере одна повторная попытка.
• retry_count — число использованных повторных попыток (в виде числа от 1 до 7). Указывается в тех случаях, когда была выполнена по крайней мере одна повторная попытка.
• next_retry_exists — индикатор наличия следующей запланированной попытки (со значением true, если перевод средств не был выполнен и в платформе подтверждена возможность повторить попытку списания, и со значением или false в остальных случаях). Указывается во всех случаях.
• next_retry_date — дата и время следующей запланированной попытки. Указывается в тех случаях, когда была запланирована очередная повторная попытка.

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

"recurring_retry": {   
            "next_retry_exists": false 
            }

В следующем примере содержится информация о том, что вслед за отклонённой исходной попыткой очередного списания запланирована первая повторная попытка ("next_retry_exists": true). В этом случае не указываются идентификатор целевого списания и идентификатор повторной попытки, поскольку ни одна повторная попытка ещё не выполнялась.

"recurring_retry": {   
            "next_retry_exists": true,
            "next_retry_date": "2026-01-21T16:58:02+0000"  
            }

В следующем примере содержится информация о том, что первая повторная попытка ("retry_count": 1) списания 344589675 была отклонена и для этого списания запланирована вторая повторная попытка ("next_retry_exists" : true) на 2026-01-25T16:58:02+0000.

"recurring_retry": {   
            "trigger_operation_id": 344589675,
            "retry_count": 1,
            "next_retry_exists": true,
            "next_retry_date": "2026-01-25T16:58:02+0000"  
            }

В следующем примере содержится информация о том, что для списания 344589675 была выполнена вторая повторная попытка ("retry_count": 2) и последующих попыток не планируется ("next_retry_exists" : false). Это может быть связано с тем, что вторая повторная попытка привела к переводу средств от пользователя к мерчанту (об этом должен свидетельствовать статус операции success), либо с тем, что повторные попытки исчерпаны, не приведя к переводу средств (об этом должен свидетельствовать статус операции decline).

"recurring_retry": {     
            "trigger_operation_id": 344589675,
            "next_retry_exists": false,
            "retry_count": 2
            }

Чтобы отменить через Gate API выполнение дальнейших повторных попыток для конкретного списания, следует:

1. Отправить POST-запрос к конечной точке .
2. Принять синхронный ответ о прекращении повторных попыток для указанного списания.

Следует учитывать, что для выполнения таких запросов используется синхронная схема взаимодействия между веб-сервисом и платёжной платформой, когда каждый запрос полностью выполняется на стороне платёжной платформы в течение одного HTTP-сеанса с предоставлением актуального ответа (подробнее). Описание типового формата синхронного ответа представлено в отдельной статье.

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

При работе с запросами на отмену дальнейших повторных попыток конкретного списания каждый раз должны использоваться следующие объекты и параметры:

• general — объект, содержащий основные идентификационные сведения запроса:
  • project_id — идентификатор проекта, полученный от Flashpay при интеграции;,
  • signature — подпись запроса, составленная после указания всех целевых параметров (подробнее — в статье Работа с подписью к данным); (подробнее),
• recurring — объект, содержащий сведения о повторяемой оплате:
  • id — идентификатор записи о целевой серии списаний, полученный при регистрации повторяемой оплаты или заданный при переносе информации об этой оплате от стороннего эквайера;,
• trigger_operation_id — идентификатор списания, для которого необходимо прекратить выполнение повторных попыток.

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

{ 
  "general":{ 
    "project_id":42,
    "signature":"K5D/anjn7fv+YyilUwS=="
  },
  "recurring":{
    "id":1079
   },
  "trigger_operation_id":092384
}

{ 
  "general":{ 
    "project_id":42,
    "signature":"K5D/anjn7fv+YyilUwS=="
  },
  "recurring":{
    "id":1079
   },
  "trigger_operation_id":092384
}

При выполнении такого запроса на отмену дальнейших попыток списания от платёжной платформы к веб-сервису передаётся ответ с кодом 200 OK, а при отклонении — с указанием статуса обработки запроса error и поясняющего описания.

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

• Контроль и проведение платежей — статья с информацией о работе с платежами через интерфейс Dashboard, включая работу с регулярными оплатами и управление повторными попытками списаний в рамках таких оплат.
• Проведение оплаты с автоматическими списаниями — статья о проведении повторяемых оплат с автоматическими списаниями через Gate, включая общую информацию о таких оплатах и описания схем их проведения и форматов данных при работе с классическими карточными платежами.
• Организация взаимодействия — статья о порядке работы с платёжной платформой через Gate API, включая описание применяемых схем взаимодействия и общих требований к форматам данных.
• Работа с оповещениями — статья о работе с программными оповещениями, позволяющими максимально оперативно получать значимую информацию о проведении каждого платежа, с описанием применяемых типов оповещений и структуры используемых данных.
• Работа с подписью к данным — статья о порядке создания и проверки подписи в программных запросах и оповещениях при взаимодействии с платёжной платформой.