Каскадное проведение платежей
Общая информация
Для случаев, когда проведение платежа прерывается по различным причинам, в платформе 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.
Формат оповещений
При каскадном проведении оплат с прямым использованием платёжных карт от платёжной платформы к веб-сервису отправляются только итоговые оповещения стандартного формата, описание которого представлено в разделе Оповещения.
Оплаты с использованием альтернативных методов
Общая информация
При проведении оплат с использованием альтернативных методов нередко требуется продолжить оплату в сервисе провайдера в отдельном окне. Однако на продолжение оплаты в этом сервисе могут повлиять различные факторы как субъективного (обусловленные влиянием пользователя), так и объективного характера (без влияния пользователя). Так, например, проведение платежа может быть прервано по разным причинам:
- По инициативе пользователя.
Как правило, это происходит после перенаправления к сервису провайдера, когда пользователь закрывает окно случайно или исходя из субъективной оценки ситуации. Результатами такой оценки могут быть боязнь вводить данные банковского счёта из-за недоверия к открывшемуся сервису провайдера, желание перезагрузить окно провайдера из-за непрогрузившихся форм для ввода данных, непонимание, что делать дальше в открывшемся окне, или иные причины.
- По не зависящим от пользователя причинам.
Как правило, это технические сбои, которые могут возникнуть как на стороне веб-сервиса (не удаётся перенаправить пользователя к сервису провайдера), так и на стороне провайдера, например превышение допустимого количества попыток ввода OTP-кода либо промедление пользователя с вводом кода, недоступность провайдера, отказ в проведении платежа из-за обрыва связи или иные причины.
Для таких случаев в платформе ecommpay поддерживается возможность каскадного проведения платежей, которое включает в себя последовательные дополнительные попытки проведения платежа через резервных провайдеров без изменения платёжного метода. При работе с альтернативными методами эта возможность доступна только для разовых оплат в одну стадию.
- низкое качество интернет-соединения на стороне любого участника проведения платежа,
- некорректную оценку ситуации пользователем,
- отсутствие информирования о списании средств на стороне пользователя либо о результате платежа на стороне провайдера как из-за технических сбоев, так и из-за особенностей реализации, а также иные обстоятельства.
Для поддержки такой возможности на стороне веб-сервиса рекомендуются доработки относительно реализации стандартного проведении разовых оплат. Подробная информация о подключении и схеме каскадного проведения оплат представлена далее.
Подключение и настройка
Чтобы подключить каскадное проведение платежей и настроить взаимодействие с платёжной платформой, со стороны мерчанта необходимо:
- Решить организационные вопросы.
- Согласовать с курирующим менеджером ecommpay подключение этой возможности и порядок действий при неоднократном списании средств в рамках одной оплаты.
- Выбрать платёжные методы с поддержкой каскадного проведения платежей.
Информацию о поддержке этой возможности можно получить в разделе Методы в описании каждого метода и у курирующего менеджера ecommpay.
- При необходимости согласовать с курирующим менеджером ecommpay текст уведомления с предложением повторить оплату. По умолчанию задан следующий текст: «В случае технических сложностей (не открылось окно, произошла ошибка) повторите попытку оплаты». В уведомлении рекомендуется предупреждать пользователя о возможности неоднократного списания средств в рамках одной оплаты. С примером такого уведомления можно ознакомиться на изображениях платёжных страниц в примере далее.
- Доработать веб-сервис для использования каскадного проведения платежей.
- Поддержать взаимодействие с платёжной платформой на программном уровне.
Для этого необходимо учесть, что допускается отправка более одного итогового оповещения — при каждой попытке, выполненной со списанием средств. Оповещения отправляются по мере поступления информации о результатах выполнения операций в платёжную платформу, ожидание может занимать до нескольких дней.
- Учесть, что логика смены промежуточного статуса платежа на итоговый отличается от стандартной.
Промежуточный статус платежа
processing
меняется на итоговыйdecline
илиsuccess
, когда в платформу поступают результаты выполнения всех операций и присвоены итоговые статусы этим операциям. Такой случай продемонстрирован в примере далее. - Рекомендуется обеспечить возможность выплат через Gate для тех методов, при работе с которыми доступно проведение выплат. Эту возможность можно использовать в случае неоднократных списаний в рамках одной оплаты.
- Поддержать взаимодействие с платёжной платформой на программном уровне.
- Отладить и протестировать возможность каскадного проведения оплат совместно с сотрудниками технической поддержки ecommpay.
Схема проведения
Каскадное проведение платежа начинается стандартно: от веб-сервиса к платёжной платформе отправляется запрос на оплату через Payment Page. В платформе после приёма и обработки этого запроса пользователю отображается Payment Page для выбора метода и подтверждения оплаты, а затем осуществляется первая попытка проведения платежа через один из провайдеров с возможным перенаправлением пользователя к сервису провайдера. Если в рамках этой попытки выполняется списание средств без ощутимых задержек на стороне провайдера, то проведение платежа завершается стандартно: к веб-сервису отправляется оповещение с итоговым статусом платежа — success
, а иначе может продолжаться каскадное проведение платежа.
Далее, пока хотя бы одна из выполненных попыток проведения оплаты не привела к списанию и дополнительные попытки ещё не исчерпаны, пользователь может инициировать новую попытку.
Каскадное проведение платежа заканчивается нестандартно: итоговое оповещение о результате платежа отправляется к веб-сервису в рамках каждой операции, выполненной со списанием средств. Такие оповещения отправляются по мере поступления в платёжную платформу информации о результатах выполнения операций, и их ожидание может занять до нескольких дней, поэтому на стороне веб-сервиса не рекомендуется завершать взаимодействие с платформой после приема первого оповещения, а при неоднократном списании средств на усмотрение пользователя рекомендуется осуществить возврат.
Далее представлена схема каскадного проведения оплаты в контексте оплаты в одну стадию с использованием одного из методов интернет-банкинга Юго-Восточной Азии и при условии, что причиной прерывания проведения платежа являются технические сбои на стороне платёжной системы.
Формат оповещений
В платформе ecommpay каждая дополнительная попытка проведения оплаты технически является отдельной операцией со своим идентификатором (operation_id
), при этом идентификатор платежа (payment_id
) является общим для всех таких операций, поэтому в оповещениях может содержаться информация как о самом платеже, так и об отдельной операции — попытке проведения этого платежа.
При каскадном проведении оплат с использованием альтернативных инструментов используются промежуточные и итоговые оповещения стандартного формата, описание которого представлено в разделе Оповещения, а примеры таких оповещений приведены в описаниях платёжных методов в разделе Методы.
- сумма платежа указывается с учётом всех списаний, о которых получена информация на момент отправки этого оповещения;
- статус платежа может быть указан как промежуточный, так и итоговый, даже если статус операции указан итоговый. Статус платежа может оставаться промежуточным до нескольких дней либо так и не поменяться на итоговый, не взирая на то, что хотя бы одна попытка выполнена со списанием и взаимодействие с пользователем завершено. Промежуточный статус платежа (как правило,
processing
) меняется на итоговый, когда в платформу поступают результаты выполнения всех операций, и принимает одно из следующих значений:decline
, если итоговые статусы всех операций —decline
;success
, если статус хотя бы одной из операций —success
.
Примеры итоговых оповещений представлены далее.
Пример каскадного проведения оплаты
Общая информация
Чтобы наглядно представлять то, как осуществляется каскадное проведение платежа через Payment Page, приведён пример, отображающий общую картину проведения оплаты с фокусировкой на действиях со стороны пользователя.
Для этого в примере представлены изображения платёжных страниц, иллюстрирующих взаимодействие с пользователем. А также представлены примеры данных из итоговых оповещений с информацией о результате платежа. Моменты, на которые стоит обратить внимание в этих оповещениях, выделены комментариями.
В рамках данного примера иллюстрируется случай, в котором пользователь выбирает платёжный метод «Банки Малайзии» и делает три попытки проведения оплаты, две из которых завершились списанием средств. В качестве примера может использоваться любой другой платёжный метод.
Первая попытка проведения оплаты
При проведении первой попытки в Payment Page пользователь выбирает банк Hong Leong Bank, перенаправляется к сервису провайдера в отдельном окне, закрывает это окно, не потвердив оплату (например, из-за недоверия к провайдеру), и соглашается на дополнительную попытку проведения оплаты. В рамках первой попытки выполняются следующие действия:
- Инициирование оплаты.
Пользователь подтверждает готовность оплатить свой заказ, и далее от веб-сервиса к платёжной платформе отправляется запрос на открытие Payment Page, где пользователь выбирает метод и банк и подтверждает платёж.
- Перенаправление к сервису провайдера.
Выполняется перенаправление пользователя к сервису провайдера с открытием отдельного окна. Далее в этом примере пользователь закрывает окно, не подтвердив платёж, и возвращается к Payment Page.
- Согласие на выполнение дополнительной попытки проведения оплаты.
В связи с тем, что на стороне платёжной платформы не получено ни одно итоговое оповещение об успешном списании, в Payment Page отображается уведомление с предложением повторить оплату. Далее пользователь соглашается, щёлкнув кнопку Повторить.
Вторая попытка проведения оплаты
В отличие от первой попытки, в данном случае используется другой провайдер, для работы с которым у пользователя запрашиваются дополнительные данные и обновляется список банков, среди которых пользователь выбирает другой банк — Standard Chartered Bank. В сервисе провайдера обработка платежа занимает длительное время, из-за чего пользователь, не дождавшись конца обработки, закрывает окно провайдера, возвращается к Payment Page и соглашается на третью попытку проведения оплаты. При этом результат проведения второй попытки остаётся неизвестным во время проведения третьей. Со стороны пользователя выполнение второй попытки имеет следующий порядок:
- Выбор банка.
Пользователь выбирает банк из обновлённого списка банков.
- Предоставление дополнительных данных.
На странице ввода дополнительной информации пользователь вводит необходимые данные и подтверждает платёж. Подробная информация об этой процедуре представлена в разделе Дополнение информации о платежах.
- Перенаправление к сервису провайдера.
Выполняется перенаправление пользователя к сервису провайдера с открытием отдельного окна. Далее в этом примере пользователь подтверждает платёж, но, не дождавшись завершения обработки платежа, закрывает окно и возвращается к Payment Page.
- Согласие на выполнение дополнительной попытки проведения оплаты.
В связи с тем, что на стороне платёжной платформы не получено ни одно итоговое оповещение об успешном списании, в Payment Page отображается уведомление с предложением повторить оплату. Далее пользователь соглашается, щёлкнув кнопку Повторить.
Третья попытка проведения оплаты
В отличие от предыдущих попыток, в данном случае используется другой провайдер, и для работы с этим провайдером снова необходимо обновляется список банков, среди которых пользователь повторно выбирает банк Hong Leong Bank. В сервисе провайдера пользователь подтверждает платёж, получает информацию о списании средств и возвращается к Payment Page. Со стороны пользователя в рамках третьей попытки выполняются следующие действия:
- Выбор банка.
Пользователь выбирает банк из обновлённого списка банков и подтверждает платёж.
- Перенаправление к сервису провайдера.
Выполняется перенаправление пользователя к сервису провайдера с открытием отдельного окна. Далее в этом примере пользователь подтверждает платёж и, получив информацию о списании средств, возвращается к Payment Page.
Обработка результатов платежа
От платёжной платформы к веб-сервису отправляются оповещения о результате платежа при выполнении каждого списания.
В этом примере в рамках третьей попытки обработка платежа и списание средств выполняются без ощутимых задержек на стороне провайдера, поэтому от платёжной платформы к веб-сервису без задержек отправляется итоговое оповещение и информация о результате отображается пользователю в Payment Page. Затем, например спустя несколько часов, когда обработка второй попытки на стороне другого провайдера завершается списанием, от платёжной платформы к веб-сервису отправляется ещё одно итоговое оповещение. В этом оповещении, в отличие от первого, сумма платежа указывается с учётом обоих списаний. В этом случае на усмотрение пользователя можно провести возврат средств.
На стороне веб-сервиса в контексте данного примера выполняются следущие действия:
- Приём оповещения о результате третьей попытки.
От платёжной платформы к веб-сервису отправляется оповещение об успешном списании средств. Так как на момент отправки этого оповещения результат по крайней мере одной попытки остаётся неизвестным, платёж остаётся в статусе
processing
, однако для текущей попытки (операции) указывается статусsuccess
. А также эта информация отображается пользователя на странице о результате платежа. - Приём итогового оповещения о результате второй попытки.
Спустя продолжительное время с момента начала проведения платежа от платёжной платформы к веб-сервису отправляется ещё одно итоговое оповещение. Так как на момент отправки этого оповещения результаты всех попыток становятся известными и по крайней мере одна из попыток завершилась списанием, статус платежа меняется на итоговый —
success
, а также сумма платежа указывается с учётом двойного списания.