Каскадное проведение платежей

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

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

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

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

Оплаты с прямым использованием карт

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

По различным причинам проведение платежей может прерываться. Например, на стороне провайдеров или банков причинами могут служить технические сбои, задержки в обработке платежа или же достижение лимитов, заданных для пользователя на стороне какого-либо провайдера.

Для таких случаев в платформе ecommpay поддерживается возможность каскадного проведения платежей. Каскадное проведение включает в себя последовательные дополнительные попытки проведения платежа через резервных провайдеров без изменения платёжного метода. При работе с прямым использованием карт эта возможность доступна только для разовых оплат в одну или две стадии как с поддержкой, так и без поддержки протокола 3‑D Secure.

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

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

Подключение и настройка

Чтобы подключить каскадное проведение платежей, со стороны мерчанта необходимо согласовать с курирующим менеджером ecommpay подключение этой возможности и протестировать каскадное проведение оплат совместно с сотрудниками технической поддержки ecommpay.

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

Каскадное проведение платежа начинается стандартно: от веб-сервиса к платёжной платформе отправляется запрос на оплату через Payment Page, после приёма и обработки которого пользователю отображается платёжная форма для ввода данных карты, а затем осуществляется первая попытка проведения оплаты через одного из провайдеров, при необходимости включая аутентификацию пользователя по протоколу 3‑D Secure. Если эта попытка завершается списанием средств, то от платёжной платформы к веб-сервису отправляется оповещение с итоговым статусом платежа — success, а иначе продолжается каскадное проведение платежа.

Далее, пока ни одна из выполненных попыток не привела к успешному списанию и дополнительные попытки ещё не исчерпаны, на стороне платёжной платформы инициируется выполнение новой попытки. Если в рамках дополнительной попытки не требуется аутентификация 3‑D Secure, то попытка выполняется без взаимодействия с пользователем. Если требуется аутентификация, то на Payment Page отображаются сообщение об ошибке, введённые ранее данные карты и кнопка Повторить попытку. Затем с согласия пользователя продолжается выполнение этой оплаты с повторной аутентификацией. Статусу платежа присваивается одно из промежуточных значений awaiting_3ds_result, awaiting_redirect_result или processing).

Каскадное проведение платежа заканчивается стандартно: от платёжной платформы к веб-сервису отправляется оповещение с одним из итоговых статусов платежа: success, если одна из выполненных попыток привела к списанию средств, или decline, если ни одна из выполненных попыток не привела к списанию и лимит на дополнительные попытки исчерпан.

Далее представлена схема каскадного проведения оплаты в контексте оплаты в одну стадию с возможной аутентификацией 3‑D Secure.

* В качестве провайдера может выступать ecommpay.

Рис. 1. Каскадное проведение оплаты с поддержкой 3‑D Secure
  1. От платёжной платформы к провайдеру передаётся запрос на проведение платежа.
  2. На стороне провайдера выявляется необходимость в аутентификации пользователя. Если требуется аутентификация, то к платформе отправляются данные для перенаправления пользователя, а иначе отправляется запрос к эмитенту на проведение платежа.
  3. От платёжной платформы к Payment Page направляется оповещение с данными для перенаправления пользователя.
  4. Осуществляется взаимодействие с пользователем:
    • Если аутентификация первичная, то выполняется перенаправление пользователя на страницу аутентификации (ACS URL) эмитента.
    • Если аутентификация повторная, то сначала пользователю отображается страница с ранее введёнными данными карты, сообщением об ошибке и предложением повторить попытку оплаты, и далее с согласия пользователя выполняется перенаправление на страницу аутентификации (ACS URL) эмитента.
  5. Пользователю отображается страница аутентификации, и он осуществляет требуемые действия.
  6. На стороне эмитента выполняется аутентификация пользователя.
  7. От эмитента к платёжной платформе передаются данные о результате аутентификации.
  8. Выполняется перенаправление пользователя к Payment Page.
  9. Пользователю отображается страница ожидания в платёжной форме.
  10. От платёжной платформы к провайдеру отправляется запрос на продолжение проведение платежа.
  11. На стороне провайдера осуществляется обработка запроса на проведение платежа. В результате от сервиса провайдера либо к платформе отправляется уведомление об отказе, и на стороне платформы инициируется дополнительная попытка, либо к эмитенту отправляется запрос на проведение оплаты, и продолжается стандартное проведение платежа.

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

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

Оплаты с использованием альтернативных методов

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

При проведении оплат с использованием альтернативных методов нередко требуется продолжить оплату в сервисе провайдера в отдельном окне. Однако на продолжение оплаты в этом сервисе могут повлиять различные факторы как субъективного (обусловленные влиянием пользователя), так и объективного характера (без влияния пользователя). Так, например, проведение платежа может быть прервано по разным причинам:

  • По инициативе пользователя.

    Как правило, это происходит после перенаправления к сервису провайдера, когда пользователь закрывает окно случайно или исходя из субъективной оценки ситуации. Результатами такой оценки могут быть боязнь вводить данные банковского счёта из-за недоверия к открывшемуся сервису провайдера, желание перезагрузить окно провайдера из-за непрогрузившихся форм для ввода данных, непонимание, что делать дальше в открывшемся окне, или иные причины.

  • По не зависящим от пользователя причинам.

    Как правило, это технические сбои, которые могут возникнуть как на стороне веб-сервиса (не удаётся перенаправить пользователя к сервису провайдера), так и на стороне провайдера, например превышение допустимого количества попыток ввода OTP-кода либо промедление пользователя с вводом кода, недоступность провайдера, отказ в проведении платежа из-за обрыва связи или иные причины.

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

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

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

Подключение и настройка

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

  1. Решить организационные вопросы.
    • Согласовать с курирующим менеджером ecommpay подключение этой возможности и порядок действий при неоднократном списании средств в рамках одной оплаты.
    • Выбрать платёжные методы с поддержкой каскадного проведения платежей.

      Информацию о поддержке этой возможности можно получить в разделе Методы в описании каждого метода и у курирующего менеджера ecommpay.

    • При необходимости согласовать с курирующим менеджером ecommpay текст уведомления с предложением повторить оплату. По умолчанию задан следующий текст: «В случае технических сложностей (не открылось окно, произошла ошибка) повторите попытку оплаты». В уведомлении рекомендуется предупреждать пользователя о возможности неоднократного списания средств в рамках одной оплаты. С примером такого уведомления можно ознакомиться на изображениях платёжных страниц в примере далее.
  2. Доработать веб-сервис для использования каскадного проведения платежей.
    • Поддержать взаимодействие с платёжной платформой на программном уровне.

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

    • Учесть, что логика смены промежуточного статуса платежа на итоговый отличается от стандартной.

      Промежуточный статус платежа processing меняется на итоговый decline или success, когда в платформу поступают результаты выполнения всех операций и присвоены итоговые статусы этим операциям. Такой случай продемонстрирован в примере далее.

    • Рекомендуется обеспечить возможность выплат через Gate для тех методов, при работе с которыми доступно проведение выплат. Эту возможность можно использовать в случае неоднократных списаний в рамках одной оплаты.
  3. Отладить и протестировать возможность каскадного проведения оплат совместно с сотрудниками технической поддержки ecommpay.

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

Каскадное проведение платежа начинается стандартно: от веб-сервиса к платёжной платформе отправляется запрос на оплату через Payment Page. В платформе после приёма и обработки этого запроса пользователю отображается Payment Page для выбора метода и подтверждения оплаты, а затем осуществляется первая попытка проведения платежа через один из провайдеров с возможным перенаправлением пользователя к сервису провайдера. Если в рамках этой попытки выполняется списание средств без ощутимых задержек на стороне провайдера, то проведение платежа завершается стандартно: к веб-сервису отправляется оповещение с итоговым статусом платежа — success, а иначе может продолжаться каскадное проведение платежа.

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

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

Далее представлена схема каскадного проведения оплаты в контексте оплаты в одну стадию с использованием одного из методов интернет-банкинга Юго-Восточной Азии и при условии, что причиной прерывания проведения платежа являются технические сбои на стороне платёжной системы.

Рис. 2. Схема оплаты через Payment Page с перенаправлением в сервис провайдера
  1. Если выполнение текущей попытки не завершается стандартно: информированием всех участников о результате проведения оплаты без ощутимых задержек на стороне провайдера (шаги 17–20* на схеме), пользователь инициирует дополнительную попытку проведения оплаты.
  2. От Payment Page передаётся запрос на дополнительную попытку.
  3. В платёжной платформе проверяется, достигнут ли лимит на дополнительные попытки. В результате проверки к Payment Page направляется ответ, который может содержать:
    • информацию об исчерпанном лимите — в этом случае пользователю предлагается вернуться в веб-сервис, чтобы начать оплату сначала, и взаимодействие с пользователем прекращается;
    • актуальный список банков — в этом случае взаимодействие с пользователем продолжается.
  4. Отображение пользователю списка банков, поддерживающих работу с данным методом и доступных для выбора в рамках новой попытки.
  5. Пользователь выбирает один из банков и вводит требуемые данные.
  6. Отображение пользователю уведомления о необходимости подтвердить оплату.
  7. Пользователь подтверждает проведение оплаты.
  8. От Payment Page передаётся запрос на проведение оплаты.
  9. В платёжной платформе выполняются обработка запроса и его отправка в платёжную систему.
  10. На стороне провайдера выполняется обработка запроса на оплату.
  11. От провайдера к платёжной платформе передаются данные для перенаправления пользователя к сервису провайдера.
  12. К Payment Page направляется оповещение с данными для перенаправления пользователя к сервису провайдера.
  13. Пользователь перенаправляется к сервису провайдера.
  14. Пользователь выполняет необходимые действия для оплаты в сервисе провайдера.
  15. На стороне сервиса провайдера выполняется обработка платежа.
  16. В сервисе провайдера пользователю отображается информация о результате оплаты. При необходимости пользователь может инициировать новую попытку списания, и тогда цикл начинается с шага 1. В случае выполненного списания средств, проведение платежа завершается.
  17. * От провайдеров, участвовавших в проведении платежа, к платёжной платформе направляются уведомления о результатах обработки каждой попытки проведения оплаты (операции в рамках платежа). В зависимости от доступности провайдеров и их скорости обработки запросов возможна задержка (вплоть до нескольких дней) в отправке информации о результатах выполнения операций.
  18. * От платёжной платформы к веб-сервису направляются оповещения о результате проведения платежа, но только для тех попыток (операций), которые завершились списанием средств. В зависимости от доступности провайдеров и их скорости обработки запросов возможна задержка.
  19. * Пользователю отображается результат оплаты.

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

В платформе ecommpay каждая дополнительная попытка проведения оплаты технически является отдельной операцией со своим идентификатором (operation_id), при этом идентификатор платежа (payment_id) является общим для всех таких операций, поэтому в оповещениях может содержаться информация как о самом платеже, так и об отдельной операции — попытке проведения этого платежа.

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

К особенностям итоговых оповещений в этом случае можно отнести то, что в каждом итоговом оповещении:
  • сумма платежа указывается с учётом всех списаний, о которых получена информация на момент отправки этого оповещения;
  • статус платежа может быть указан как промежуточный, так и итоговый, даже если статус операции указан итоговый. Статус платежа может оставаться промежуточным до нескольких дней либо так и не поменяться на итоговый, не взирая на то, что хотя бы одна попытка выполнена со списанием и взаимодействие с пользователем завершено. Промежуточный статус платежа (как правило, processing) меняется на итоговый, когда в платформу поступают результаты выполнения всех операций, и принимает одно из следующих значений:
    • decline, если итоговые статусы всех операций — decline;
    • success, если статус хотя бы одной из операций — success.

Примеры итоговых оповещений представлены далее.

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

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

Чтобы наглядно представлять то, как осуществляется каскадное проведение платежа через Payment Page, приведён пример, отображающий общую картину проведения оплаты с фокусировкой на действиях со стороны пользователя.

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

В рамках данного примера иллюстрируется случай, в котором пользователь выбирает платёжный метод «Банки Малайзии» и делает три попытки проведения оплаты, две из которых завершились списанием средств. В качестве примера может использоваться любой другой платёжный метод.

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

При проведении первой попытки в Payment Page пользователь выбирает банк Hong Leong Bank, перенаправляется к сервису провайдера в отдельном окне, закрывает это окно, не потвердив оплату (например, из-за недоверия к провайдеру), и соглашается на дополнительную попытку проведения оплаты. В рамках первой попытки выполняются следующие действия:

  1. Инициирование оплаты.

    Пользователь подтверждает готовность оплатить свой заказ, и далее от веб-сервиса к платёжной платформе отправляется запрос на открытие Payment Page, где пользователь выбирает метод и банк и подтверждает платёж.





  2. Перенаправление к сервису провайдера.

    Выполняется перенаправление пользователя к сервису провайдера с открытием отдельного окна. Далее в этом примере пользователь закрывает окно, не подтвердив платёж, и возвращается к Payment Page.



  3. Согласие на выполнение дополнительной попытки проведения оплаты.

    В связи с тем, что на стороне платёжной платформы не получено ни одно итоговое оповещение об успешном списании, в Payment Page отображается уведомление с предложением повторить оплату. Далее пользователь соглашается, щёлкнув кнопку Повторить.



Вторая попытка проведения оплаты

В отличие от первой попытки, в данном случае используется другой провайдер, для работы с которым у пользователя запрашиваются дополнительные данные и обновляется список банков, среди которых пользователь выбирает другой банк — Standard Chartered Bank. В сервисе провайдера обработка платежа занимает длительное время, из-за чего пользователь, не дождавшись конца обработки, закрывает окно провайдера, возвращается к Payment Page и соглашается на третью попытку проведения оплаты. При этом результат проведения второй попытки остаётся неизвестным во время проведения третьей. Со стороны пользователя выполнение второй попытки имеет следующий порядок:

  1. Выбор банка.

    Пользователь выбирает банк из обновлённого списка банков.



  2. Предоставление дополнительных данных.

    На странице ввода дополнительной информации пользователь вводит необходимые данные и подтверждает платёж. Подробная информация об этой процедуре представлена в разделе Дополнение информации о платежах.





  3. Перенаправление к сервису провайдера.

    Выполняется перенаправление пользователя к сервису провайдера с открытием отдельного окна. Далее в этом примере пользователь подтверждает платёж, но, не дождавшись завершения обработки платежа, закрывает окно и возвращается к Payment Page.





  4. Согласие на выполнение дополнительной попытки проведения оплаты.

    В связи с тем, что на стороне платёжной платформы не получено ни одно итоговое оповещение об успешном списании, в Payment Page отображается уведомление с предложением повторить оплату. Далее пользователь соглашается, щёлкнув кнопку Повторить.



Третья попытка проведения оплаты

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

  1. Выбор банка.

    Пользователь выбирает банк из обновлённого списка банков и подтверждает платёж.



  2. Перенаправление к сервису провайдера.

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





Обработка результатов платежа

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

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

На стороне веб-сервиса в контексте данного примера выполняются следущие действия:

  1. Приём оповещения о результате третьей попытки.

    От платёжной платформы к веб-сервису отправляется оповещение об успешном списании средств. Так как на момент отправки этого оповещения результат по крайней мере одной попытки остаётся неизвестным, платёж остаётся в статусе processing, однако для текущей попытки (операции) указывается статус success. А также эта информация отображается пользователя на странице о результате платежа.



    Рис. 3. Пример данных из оповещения об успешном списании средств в рамках третьей попытки
    {
            "customer": {
                "id": "653"
            },
            "project_id": 200,
            "payment": { // информация о платеже (оплате)
                "payment_id": "cosmo_set_4589", // идентификатор платежа, одинаковый для всех попыток,
                "type": "purchase",
                "status": "processing", // статус платежа
                "date": "2020-07-20T04:37:57+0000",
                "method": "Malaysian banks",
                "sum": {
                    "amount": 131970, // сумма платежа с учётом одного списания
                    "currency": "MYR"
                },
                "description": "Gagarin set" 
            },
            "operation": { // информация об операции (попытке проведения оплаты) 
                "id": 003, // идентификатор операциии в платёжной платформе
                "type": "sale",
                "status": "success",
                "date": "2020-07-20T04:37:57+0000",
                "created_date": "2020-07-20T04:36:45+0000",
                "request_id": "cosmo_set_4589_request3", // идентификатор запроса,полученный в ответе
                                                         // на запрос на выполнение третьей попытки проведения оплаты
                "sum_initial": {
                    "amount": 131970, //сумма списания в рамках третьей попытки
                    "currency": "MYR"
                },
                "sum_converted": {
                    "amount": 131970,
                    "currency": "MYR"
                },
                "code": "0",
                "message": "Success",
                "provider": { // информация о провайдере, обработавшем платёж
                    "id": 1256,
                    "payment_id": "064604207", // идентификатор платежа, заданный на стороне провайдера
                    "auth_code": "",
                    "date": "2020-07-20T04:36:51+0000"
                }
            },
            "signature": "n3zmkj5yG..."
        }
  2. Приём итогового оповещения о результате второй попытки.

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

    Рис. 4. Пример данных из оповещения об успешном списании средств в рамках второй попытки
    {
            "customer": {
                "id": "653"
            },
            "project_id": 200,
            "payment": { // информация о платеже (оплате)
                "payment_id": "cosmo_set_4589", // идентификатор платежа, одинаковый для всех попыток,
                "type": "purchase",
                "status": "success",// статус платежа
                "date": "2020-07-20T07:12:04+0000",
                "method": "Malaysian banks",
                "sum": {
                    "amount": 263940, // сумма платежа с учётом двойного списания
                    "currency": "MYR"
                },
                "description": "Gagarin set"
            },
            "operation":{ // информация об операции (попытке проведения оплаты) 
                "id": 002, // идентификатор операциии в платёжной платформе
                "type": "sale",
                "status": "success",
                "date": "2020-07-20T07:12:04+0000",
                "created_date": "2020-07-20T04:33:37+0000",
                "request_id": "cosmo_set_4589_request2", // идентификатор запроса,полученный в ответе
                                                         // на запрос на выполнение третьей попытки проведения оплаты
                "sum_initial": {
                    "amount": 131970, // сумма списания в рамках второй попытки
                    "currency": "MYR"
                },
                "sum_converted": {
                    "amount": 131970,
                    "currency": "MYR"
                },
                "code": "0",
                "message": "Success",
                "provider": { // информация о провайдере, обработавшем платёж
                    "id": 1589,
                    "payment_id": "0757821", // идентификатор платежа, заданный на стороне провайдера
                    "auth_code": "",
                    "date": "2020-07-20T07:11:48+0000"
                }
            },
            "signature": "bYNjg..."
        }