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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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