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

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

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

Для таких случаев в платформе 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 поддерживается возможность каскадного проведения платежей, которое включает в себя последовательные дополнительные попытки проведения платежа через резервных провайдеров без изменения платёжного метода. При работе с альтернативными методами эта возможность доступна только для разовых оплат в одну стадию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы наглядно представлять то, как осуществляется каскадное проведение платежа через 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. А также эта информация отображается пользователя на странице о результате платежа.

   
   
   

   {
           "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, а также сумма платежа указывается с учётом двойного списания.

   {
           "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..."
       }