1.20. Payment Cashier

Введение

Интеграция с Платёжной кассой позволяет Плательщику выбрать способ оплаты для транзакции. Платёжную кассу можно настроить на стороне Присоединяющейся стороны или на стороне Платёжного Шлюза (также называемой Параллельной формой), что рассматривается в этом примере использования. Присоединяющаяся сторона перенаправляет Плательщика в Параллельную форму, размещённую на стороне Платёжного Шлюза; Плательщик выбирает один из доступных способов оплаты и пытается выполнить платёж. Параллельная форма может инициировать транзакции sale или preauth для каждого настроенного способа оплаты. После успешной транзакции Плательщик перенаправляется обратно к Присоединяющейся стороне. Подробнее см. Настройка платёжного потока.

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

Значение терминов см. в Глоссарии.

Платёжная касса, настроенная в Платёжном Шлюзе, имеет внутреннюю структуру Главных Эндпоинтов, объединяющих обычные Эндпоинты. Обычные Эндпоинты, подключённые к Главному Эндпоинту, называются Вспомогательными Эндпоинтами. Каждый Вспомогательный Эндпоинт настраивается для конкретного способа оплаты. При выполнении оплаты Плательщик может выбрать способ оплаты в Параллельной форме. Когда Плательщик выбирает способ оплаты, Параллельная форма инициирует вспомогательную транзакцию в соответствующем Вспомогательном Эндпоинте. Если валюта Вспомогательного Эндпоинта отличается от валюты Главного Эндпоинта, сумма главной транзакции будет конвертирована в соответствующую валюту этого способа оплаты. Кроме того, Главные Эндпоинты можно объединить в Группу Эндпоинтов для создания единой логической сущности для мультивалютных интеграций. См. Параметры мультивалютной интеграции и выберите предпочтительный вариант с менеджером службы поддержки SBC.

Payment Cashier Flow

(2) Для реализации запроса sale-form см. /api/v2/sale-form/.

(14) Для реализации финального перенаправления см. Final Redirect.

(16,17) Для реализации запроса статуса заказа см. /api/v2/status/. Статус следует запрашивать несколько раз с интервалами 3–5 секунд, пока в ответе не будет получен окончательный статус.

(18) Сведения о реализации callback с обработкой финального статуса см. в Callbacks Присоединяющейся стороны. Callback отправляется со статусом основной транзакции (транзакции кассира). Чтобы получать дополнительные callback о результате каждой инициированной транзакции, обратитесь к менеджеру поддержки SBC.

Options For Multi-Currency Integration

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

Payment Flow Customization Scenarios

Callback Notification Options

По умолчанию обратные вызовы имеют следующую форму:

Обратный вызов главной конечной точки: client_orderid=A&orderid=B

Обратный вызов вспомогательной конечной точки: client_orderid=A&orderid=C (если он установлен на вспомогательной конечной точке)

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

Существует другая настройка, которая может быть предпочтительнее стандартной (чтобы включить эту функцию, пожалуйста, обратитесь к менеджеру поддержки SBC) :

Обратный вызов главной конечной точки: client_orderid=A&orderid=B

Обратный вызов вспомогательной конечной точки: client_orderid=B&orderid=C (если он установлен на вспомогательной конечной точке)

Обратный вызов на вспомогательной конечной точке может потребоваться в двух случаях:

1. Присоединяющаяся сторона хочет иметь полную информацию обо всех попытках оплаты в Payment Cashier.

2. Присоединяющаяся сторона реализует интеграцию preauth -> capture/cancel в Payment Cashier. Транзакции Capture/cancel могут инициироваться для одобренной транзакции preauth запросом к Master Endpoint ID с использованием orderid вспомогательной транзакции. Этот orderid поступает в callback от Auxiliary Endpoint, когда транзакция preauth получает окончательный статус.

Redirect Payer After Any Decline

По умолчанию Плательщик остаётся в Параллельной форме, если одна из вспомогательных транзакций отклонена, чтобы он мог попытаться оплатить другим доступным способом. Можно перенаправить Плательщика на сайт Присоединяющейся стороны после получения неуспешного статуса (decline, filtered, error и т. д.) на любой вкладке способа оплаты Кассы (отклонение вспомогательной транзакции вызовет отклонение главной транзакции). Для включения этой функции обратитесь к менеджеру службы поддержки SBC.

Keep Payer on Finish Page

Когда одна из вспомогательных транзакций одобрена, Параллельная форма перенаправляет Плательщика обратно на сайт Присоединяющейся стороны (см. Финальное перенаправление). Можно оставить Плательщика на странице завершения вместо перенаправления для одобренной вспомогательной транзакции (это может быть полезно, если Платёжная касса отображается в iframe на сайте Присоединяющейся стороны). Для включения этой функции обратитесь к менеджеру службы поддержки SBC.

Forced Payer Redirect

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

Option 1

Auxiliary Finish Form Template:

<script>
        function backToMerchant() {
            window.parent.postMessage(
                "redirect-to-merchant",
                "https://pay.connectingparty.com"
            );
        }
    </script>
</head>
<body onload="backToMerchant()">
<div class="container">
    <div class="main">
        <h2 class="summary__title">Deposit <span class="status-title">${STATUS}</span></h2>
        <div class="back">
            <a class="link" href="#" onclick="backToMerchant()">Back to merchant website</a>
        </div>
    </div>
</div>

Master Payment Form Template:

<script>
    window.addEventListener("message", function(event) {
        if (event.origin !== "https://pay.connectingparty.com")
            return;
        if (event.data === "redirect-to-merchant") {
            window.location.replace("https://connectingparty.com/result");
        }
    }, false);
</script>

Option 2

Auxiliary Finish Form Template:

<div class="container">
    <div class="main">
        <h2 class="summary__title">Deposit <span class="status-title">${STATUS}</span></h2>
        <div class="back">
            <a class="link" target="_parent" href="${CUSTOMER_REDIRECT_URL}">Back to merchant website</a>
        </div>
    </div>
</div>

Subsequent Transactions on Payment Cashier

Если Присоединяющаяся сторона хочет инициировать транзакции cancel, reversal или capture в Платёжной кассе, ей необходимо отправить запрос на идентификатор Главного Эндпоинта, используя order_id вспомогательной транзакции. Это значение можно получить в callback от Вспомогательного Эндпоинта вместе с другими сведениями об этой транзакции. Подробнее см. в разделе Параметры уведомления callback и ознакомьтесь с приведённым ниже потоком транзакции.

Сценарий отмены

(1) Отмена предавторизации может быть вызвана Присоединяющейся Стороной в соответствии с бизнес-моделью или по запросу Плательщика.

(2) Для имплементации запроса на отмену см. /api/v2/return/.

(5) Обратный вызов по отмене будет отправлен только в случае, если notify_url был предоставлен в инициирующем запросе предавторизации или дополнительный обратный вызов установлен на предоставленный URL для отмен на уровне терминала. Если в запросе предавторизации был предоставлен server_callback_url, обратный вызов по отмене не будет отправлен. Для обработки обратных вызовов см. Обратный вызов Присоединяющейся Стороны.

(7) Для реализации запроса статуса заказа см. /api/v2/status/. Статус следует запрашивать несколько раз с интервалом 3-5 секунд, пока в ответе не будет получен финальный статус.

(9) Конечный статус может быть предоставлен Присоединяющейся Стороной в соответствии с бизнес-моделью или по запросу Плательщика.

Сценарий списания

(1) Списание может быть инициировано Присоединяющейся Стороной в соответствии с бизнес-моделью или по запросу Плательщика.

(2) Для имплементации запроса на списание см. /api/v2/capture/.

(5) Callback для Capture будет отправлен только если notify_url был предоставлен в первоначальном запросе транзакции или дополнительный URL callback для транзакций Capture указан на уровне endpoint. Если server_callback_url был предоставлен в первоначальном запросе транзакции, callback для Capture не отправляется. Для реализации callback с обработкой окончательного статуса см. Connecting Party Callbacks.

(7) Для реализации запроса статуса заказа см. /api/v2/status/. Статус следует запрашивать несколько раз с интервалом 3-5 секунд, пока в ответе не будет получен финальный статус.

(9) Конечный статус может быть предоставлен Присоединяющейся Стороной в соответствии с бизнес-моделью или по запросу Плательщика.

Reversal Flow

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

(2) Для имплементации запроса возврата см. /api/v2/return/.

(5) Callback для Return будет отправлен только если notify_url был предоставлен в первоначальном запросе транзакции или дополнительный URL callback для транзакций Return указан на уровне endpoint. Если server_callback_url был предоставлен в первоначальном запросе транзакции, callback для Return не отправляется. Для реализации callback с обработкой окончательного статуса см. Connecting Party Callbacks.

(7) Для реализации запроса статуса заказа см. /api/v2/status/. Статус следует запрашивать несколько раз с интервалом 3-5 секунд, пока в ответе не будет получен финальный статус.

(9) Финальный статус может быть отправлен Присоединяющейся Стороной, опираясь на внутреннюю политику компании или по запросу Плательщика.