Проведение оплаты с автоматическими списаниями

Общая информация

Повторяемая оплата с автоматическими списаниями — это тип платежа, в рамках которого на основании одного исходного запроса осуществляется серия регулярных переводов денежных средств от пользователя к мерчанту с использованием сохранённых платёжных данных и без подтверждения подлинности платёжного инструмента пользователя (такого, как ввод кода проверки подлинности карты).

В рамках платёжной платформы повторяемые оплаты с автоматическими списаниями проводятся в соответствии с моделью проведения платежей (подробнее).

Возможности управления повторными попытками списаний

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

  • целевая оплата проводится с прямым использованием платёжной карты,
  • списание отклонено на стороне платёжной системы или эмитента.

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

При использовании повторных попыток их количество и время на выполнение ограничиваются: для каждого очередного списания допускается не более 7 повторных попыток, которые могут быть выполнены в течение 6 суток. Интервал между первой (исходной) попыткой очередного списания и первой повторной попыткой, а также между первой и второй повторными попытками составляет 12 часов, интервал между остальными попытками — 24 часа. При этом проверяется, что до следующего очередного списания (согласно графику списаний) остаётся не менее 12,5 или 24,5 часов соответственно. Иначе повторные попытки прекращаются. Эти ограничения действуют для всех платежей в рамках любого проекта и не могут быть изменены.

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

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

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

Схемы проведения

Проведение с инициированием списаний при регистрации платежа

В базовом случае, когда при регистрации повторяемой оплаты передаётся параметр scheduled_payment_id, для проведения повторяемой оплаты с автоматическими списаниями необходимо:

  1. Зарегистрировать повторяемую оплату.
  2. Принять от платёжной платформы оповещение о результате списания.
  3. Продолжать принимать оповещения о результате каждого списания в рамках платежа.

Для изменения условий повторяемой оплаты или её отмены, а также для возврата средств после одного или нескольких списаний необходимо передать соответствующие запросы в платёжную платформу (подробнее — в статье Управление списаниями в рамках оплаты).

Рис.: Проведение повторяемой оплаты с инициированием списаний при её регистрации. Описание шагов

  1. В соответствии с графиком, в необходимое время от платёжной платформы к платёжной системе направляется запрос на очередное списание.
  2. В платёжной системе выполняется дальнейшая обработка запроса и его отправка эмитенту.
  3. На стороне эмитента выполняется обработка списания и перевод средств от пользователя к мерчанту.
  4. От эмитента к платёжной системе направляется информация о результате списания.
  5. От платёжной системы к платёжной платформе направляется информация о результате списания.
  6. От платёжной платформы к веб-сервису направляется оповещение о результате списания.
  7. На стороне веб-сервиса обеспечивается информирование пользователя о результате списания.
  8. Далее со стороны платёжной платформы инициируются последующие плановые списания и для каждого из них повторяются шаги 1—7.

Информация о форматах запросов и оповещений приведена далее; общая информация о работе с API — в разделе Организация взаимодействия. Информацию о возможных статусах такой оплаты можно найти в соответствующей статье.

Проведение с отдельным инициированием списаний

В случае, если при регистрации повторяемой оплаты не передаётся параметр scheduled_payment_id, для проведения повторяемой оплаты с автоматическими списаниями необходимо:

  1. Зарегистрировать повторяемую оплату.
  2. Передать запрос на проведение повторяемой оплаты с идентификатором записи о серии списаний.
  3. Принять от платёжной платформы оповещение о результате списания.
  4. Продолжать принимать оповещения о результате каждого списания в рамках платежа.

Рис.: Проведение повторяемой оплаты с отдельным инициированием списаний. Описание шагов

  1. От веб-сервиса на заданный URL ecommpay передаётся запрос на инициирование списаний.
  2. Этот запрос поступает в платёжную платформу.
  3. В платёжной платформе выполняется обработка запроса.
  4. От платёжной платформы к веб-сервису направляется ответ с информацией о получении запроса и его корректности.
  5. От платёжной платформы к платёжной системе направляется запрос на списание.
  6. В платёжной системе выполняется дальнейшая обработка запроса и его отправка эмитенту.
  7. На стороне эмитента выполняется обработка списания и перевод средств от пользователя к мерчанту.
  8. От эмитента к платёжной системе направляется информация о результате списания.
  9. От платёжной системы к платёжной платформе направляется информация о результате списания.
  10. От платёжной платформы к веб-сервису направляется оповещение о результате списания.
  11. На стороне веб-сервиса обеспечивается информирование пользователя о результате списания.
  12. Далее со стороны платёжной платформы инициируются последующие плановые списания и для каждого из них повторяются шаги 5—11.

Проведение с повторными попытками списаний

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

  1. Зарегистрировать повторяемую оплату.
  2. Если при регистрации оплаты не был передан параметр scheduled_payment_id, передать запрос на проведение повторяемой оплаты с идентификатором записи о серии списаний (recurring.id).
  3. Принять от платёжной платформы оповещения о результате списания (одно или несколько, в зависимости от количества выполненных повторных попыток).
  4. Продолжать принимать оповещения о результате каждого планового списания и повторных попытках его выполнения (при их наличии) в рамках платежа. И при необходимости отменять выполнение повторных попыток для конкретных списаний (через Gate или Dashboard).

    Стоит учитывать, что при отменах повторных попыток списаний оповещения о таких отменах не отправляются.

Рис.: Проведение повторяемой оплаты с повторными попытками списаний. Описание шагов

  1. Если попытка проведения списания не завершилось переводом средств, то для этого списания в платёжной платформе проверяется возможность выполнения повторной попытки.
  2. От платёжной платформы к веб-сервису направляется оповещение об отклонении планового списания (со статусом операции decline) с датой и временем выполнения повторной попытки.
  3. От платёжной платформы к платёжной системе в соответствующие дату и время направляется запрос на списание.
  4. В платёжной системе выполняется дальнейшая обработка запроса и его отправка эмитенту.
  5. На стороне эмитента выполняется обработка списания.
  6. От эмитента к платёжной системе направляется информация об отклонении списания.
  7. От платёжной системы к платёжной платформе направляется информация об отклонении списания.
  8. В платёжной платформе проверяется актуальность и доступность выполнить повторную попытку. При необходимости со стороны платёжной платформы инициируются следующие повторные попытки списания и для каждой из них могут повторяться шаги 2 —7.
  9. От платёжной платформы к веб-сервису направляется оповещение о результате со статусом операции decline (если ни одна из попыток не привела к списанию средств) или success (если одна из попыток привела к списанию).
  10. На стороне веб-сервиса обеспечивается информирование пользователя о результате списания.
  11. Далее со стороны платёжной платформы инициируются последующие плановые списания и для каждого из них могут повторяться шаги 1—10.

Чтобы отменить повторные попытки для конкретного списания, следует отправить запрос на отмену повторных попыток, принять ответ и при необходимости уведомить пользователя.

Рис.: Проведение оплаты с отменой выполнения повторных попыток. Описание шагов

  1. От веб-сервиса на заданный URL ecommpay направляется запрос на отмену повторных попыток, запланированных в платформе для отклонённого списания.
  2. Этот запрос поступает в платёжную платформу.
  3. В платёжной платформе выполняется обработка запроса.
  4. От платёжной платформы к веб-сервису направляется ответ с информацией о получении запроса и его корректности. На стороне платёжной платформы прекращаются повторные попытки выполнить это списание.
  5. На стороне веб-сервиса обеспечивается информирование пользователя о результате списания.
  6. Далее со стороны платёжной платформы инициируются последующие плановые списания.

Формат запроса

Запрос на инициирование повторяемой оплаты

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

  1. Для инициирования каждой оплаты должен использоваться отдельный POST-запрос к конечной точке /v2/payment/card/recurring.
  2. В каждом запросе должны использоваться следующие объекты и параметры:
    • general — объект, содержащий основные идентификационные сведения запроса:
      • project_id — идентификатор проекта, полученный от ecommpay при интеграции;,
      • payment_id — идентификатор платежа, уникальный в рамках проекта;,
      • signature — подпись запроса, составленная после указания всех целевых параметров (подробнее — в разделе Работа с подписью к данным); (подробнее),
    • customer — объект, содержащий сведения о пользователе:
      • id — идентификатор пользователя, уникальный в рамках проекта;,
      • ip_address — IP-адрес пользователя, актуальный для инициируемого платежа;,
    • payment — объект, содержащий сведения о платеже:
      • amount — сумма платежа в дробных единицах валюты;,
      • currency — код валюты платежа в формате ISO-4217 alpha-3;,
    • recurring — объект, содержащий сведения повторяемой оплате:
      • id — идентификатор записи о серии списаний, полученный в оповещении после регистрации повторяемой оплаты или заданный при переносе информации об этой оплате от стороннего эквайера.
  3. С учётом региональных особенностей и специфики провайдеров, участвующих в проведении платежей, могут быть обязательны и некоторые другие параметры. Информацию о таких особенностях и требованиях провайдеров можно уточнять у курирующего менеджера ecommpay.
  4. Дополнительно могут использоваться любые другие параметры из числа указанных в спецификации.

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

Рис.: Пример набора данных в запросе на проведение повторяемой оплаты

{  
  "general":{  
    "project_id":42,
    "payment_id":"456789",
    "signature":"K5D/aZAMdeR+YyilUwS=="
  },
  "customer":{  
    "ip_address":"202.144.196.0",
    "id":"customer_12"
  },
  "payment":{
    "amount":400,
    "currency":"USD"
  },
  "recurring":{
    "id":1079
  }
}

Запрос на отмену повторных попыток списания

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

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

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

Рис.: Пример набора данных в запросе на отмену повторных попыток списания

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

Формат оповещений

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

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

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

    Этот параметр принимает значение true, если списание средств не было выполнено и возможность повторить попытку списания доступна (количество попыток и время на их выполнение не исчерпаны), и значение false во всех остальных случаях.

  • next_retry_date — дата и время следующей запланированной попытки.

В следующем примере оповещение свидетельствует о том, что в рамках проекта 42 для пользователя customer_12 было выполнено списание в размере 4,00 USD с платёжной карты № 424242******4243 и ожидаются последующие списания. Возможность повторных попыток списаний не подключена.

Рис.: Пример данных из оповещения о списании средств в базовом случае

{  
  "customer":{  
    "id":"customer_12"
  },
  "account":{  
    "number":"431422******0056",
    "type":"visa",
    "card_holder":"JOHN SMITH",
    "id":45678,
    "expiry_month":"08",
    "expiry_year":"2026"
  },
  "payment":{  
    "sum":{  
      "amount":400,
      "currency":"USD"
    },
    "method":"card",
    "date":"2023-06-07T06:18:02+0000",
    "status":"scheduled recurring processing",    // Статус платежа
    "type":"recurring",    // Тип платежа
    "id":"456789",
    "description":""
  },
  "project_id":42,
  "recurring":{  
    "valid_thru":"2023-07-31T00:00:00+0000",
    "currency":"USD",
    "id":1079    // Идентификатор серии списаний
  },
  "operation":{  
    "id":39690002636,
    "type":"recurring",    // Тип операции
    "status":"success",    // Статус операции
    "date":"2023-06-07T06:18:02+0000",
    "created_date":"2023-06-07T06:18:02+0000",
    "request_id":"5cfa0199c33071",
    "sum_initial":{  
      "amount":400,
      "currency":"USD"
    },
    "sum_converted":{  
      "amount":400,
      "currency":"USD"
    },
    "provider":{  
      "id":6,
      "payment_id":"1192",
      "date":"2023-02-07T08:34:24+0000",
      "auth_code":"5253",
      "endpoint_id":6
    },
    "code":"0",
    "message":"Success"
  },
  "signature":"v7KNMpfZZ5D/aZMdeR+YyilUwSm...=="
}

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

Рис.: Пример данных из оповещения об отклонении списания с планированием первой повторной попытки

"recurring_retry": {   
            "next_retry_exists": true,
            "next_retry_date": "2023-05-24T16:58:02+0000"  
            }

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

Рис.: Пример данных из оповещения об отклонении списания с планированием второй повторной попытки

"recurring_retry": {   
            "trigger_operation_id": 344589675,
            "retry_count": 1,
            "next_retry_exists": true,
            "next_retry_date": "2023-05-24T16:58:02+0000"  
            }

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

Рис.: Пример данных из оповещения о списании средств в результате выполнения второй повторной попытки

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

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

Рис.: Пример данных из оповещения об отсутствии запланированных повторных попыток

"recurring_retry": {   
            "next_retry_exists": false 
            }