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

Поддерживаемые валюты

Код валюты (по ISO 4217)

Название валюты

AED

Дирхам ОАЭ

AZN

Азербайджанский манат

BRL

Бразильский реал

CAD

Канадский доллар

EUR

Евро

GBP

Британский фунт

KGS

Киргизский сом

INR

Индийская рупия

KRW

Южнокорейская вона

PLN

Польский злотый

RUB

Российский рубль

TJS

Таджикский сомони

USD

Доллар США

Особенности отображение сумм в различных валютах

При отправке запроса на осуществление платежа в валюте, не имеющей разменных денежных единиц (копейки, центы и т. п.), сумма операции на платёжной форме Payler всегда отображается в виде целого числа, без десятичного разделителя. Например, при оплате в KRW сумма платежа 250 вон будет отображаться как 250. Тогда как сумма операции в USD отобразится с дробной частью: 250,00.

Способы оплаты

Способ

Описание

Card

Оплата банковской картой

ApplePay

Оплата через ApplePay

GooglePay

Оплата через GooglePay

Статусы операций

Статус

Значение

Created

Платеж зарегистрирован в шлюзе, но его обработка не завершена

PreAuthorized3DS

Пользователь начал аутентификацию по протоколу 3D‑Secure

PreAuthorized3DS2

Пользователь начал аутентификацию по протоколу 3D-Secure (3DS 2.0)

PreAuthorized3DSMethod

Пользователь начал этап проведения 3DS Method (3DS 2.0)

Authorized

Средства заблокированы, но не списаны (двухстадийный платеж)

Reversed

Средства на карте были заблокированы и полностью разблокированы

Charged

Денежные средства списаны с карты пользователя, платёж завершен успешно

Refunded

Успешно произведен полный возврат средств на карту пользователя

Rejected

Последняя операция по платежу отклонена

Pending

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

Credited

Средства зачислены на карту пользователя, перевод завершен успешно

Типы данных

В описаниях методов API используются следующие обозначения типов данных:

Обозначение

Пояснение

A

Строка

A*

Строка с фиксированным количеством символов. Число указывает количество символов

A..*

Строка с ограничением количества символов. Число указывает максимальное допустимое количество символов

Ar

Массив

Ar..*

Массив с ограничением числа элементов. Число указывает максимальное допустимое количество элементов

B

Данные логического типа

D

Словарь

F

Дробное число

N

Целое число

N*

Целое число с фиксированным количеством символов. Число указывает количество символов

Гарантированные уведомления

Гарантированные уведомления (или — callback) служат для информирования мерчанта об успешных или неуспешных платежах и работают следующим образом:

после изменения статуса заказа платежный шлюз посылает POST‑запрос

(Content-type: x‑www‑form‑urlencoded) на заранее заданный URL.

В параметрах запроса передается order_id;

  • если получен успешный код ответа (2xx), то обработка уведомления завершается;

  • если получена ошибка, или сервер недоступен, то попытка повторяется через 10 секунд, 1 минуту, 15 минут, 30 минут, 1 час, 2 часа, 4 часа, 6 часов, 8 часов.

Для получения callback сервис мерчанта должен быть доступен по одному из следующих портов: 80, 433, 8080, 4443, 8443, 9443, 14405, 4405. IP-адрес исходящего соединения: 178.20.235.180.

URL для отправки гарантированных уведомлений указывается мерчантом в Личном кабинете в разделе «Настройки».

Фискальные электронные чеки

Выдача чеков происходит следующим образом:

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

  2. После завершения обработки чека, мерчант получает callback (POST-запрос), на URL, указанный в личном кабинете. В запросе передается параметр order_id.

  3. После получения callback мерчант вызывает метод GetReceiptStatus и получает в ответ информацию по выданному чеку.

В личном кабинете сервиса АТОЛ ОНЛАЙН (а также — в личном кабинете ОФД) доступна статистика и отчетность по выданным чекам. После регистрации чека в ККТ, ОФД самостоятельно проводит рассылку чеков плательщикам по указанным контактным данным (e mail, sms).

Управление учётными записями и картами пользователей

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

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

Сценарии сохранения карточных данных

Привязка карт выглядит следующим образом:

  1. Мерчант создает пользователя в системе Payler метод CustomerRegister.

  2. Мерчант привязывает карты к созданному пользователю одним из способов:

    • Во время проведения платежа; метод StartSession.

    • С проверкой суммы и автоматическим возвратом (разблокировкой) средств; метод StartSaveCardSession (схема Gate) или PaySaveCard (схема Merchant).

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

  4. Удаление карты (RemoveCard) и удаление пользователя (CustomerDelete) необратимы. При удалении пользователя все привязанные к нему карты будут также удалены.3

Для последующих операций Payment (платеж) требуется хранить и использовать reccurent_template_id. Для последующих операций Credit (перевод) требуется хранить и использовать card_id.

Сохранение карты при оплате

Сценарий выполнения:

  1. Мерчант вызывает метод StartSession с ключевыми параметрами reccurrent=true и customer_id.

  2. Мерчант отправляет пользователя на страницу оплаты (метод PayGate).

  3. Пользователь вводит и отправляет карточные данные.

  4. После завершения оплаты пользователь возвращается на сайт мерчанта, на заранее заданный адрес. Происходит отправка callback (опционально).

  5. При возврате пользователя или получении callback мерчант может вызвать метод GetAdvancedStatus для проверки статуса заказа и получения card_id/reccurent_template_id.

Если по платежу отсутствует 3DS (карта не вовлечена в 3D‑Secure), карта не сохраняется; Если платеж отклоняется по балансу или проходит успешно, то для последующего списания (метод RepeatPay) создается рекуррентный шаблон, и карта сохраняется для операций выдачи средств (метод RepeatCredit). Данные шаблона отправляется исключительно в callback.

Сохранение карты с проверкой суммы и автоматическим возвратом (разблокировкой)

В данном сценарии проводится блокировка или списание денежных средств в размере 1 руб. с последующей автоматической отменой операции. Тип выполняемой операции (блокировка/списание) зависит от настроек процессинга.

Сценарий выполнения для схемы Gate:

  1. Мерчант вызывает метод StartSaveCardSession для создания сессии сохранения карты.

  2. Мерчант отправляет пользователя на страницу сохранения карты (метод Save).

  3. Пользователь вводит и отправляет карточные данные.

  4. После завершения оплаты пользователь возвращается на сайт мерчанта, на заранее заданный адрес. Происходит отправка callback (опционально).

  5. При успешном проведении проверочного списания производится автоматический возврат средств.

  6. При возврате пользователя или получении callback мерчант может вызвать метод GetAdvancedStatus для проверки статуса заказа и получения card_id/reccurent_template_id.

Сценарий выполнения для схемы Merchant:

  1. Мерчант вызывает метод PaySaveCard.

  2. Пользователь вводит и отправляет карточные данные.

  3. При успешном проведении проверочного списания производится автоматический возврат или отмена блокировки средств.

  4. Происходит отправка callback (опционально).

  5. При получении callback мерчант может вызвать метод GetAdvancedStatus для проверки статуса заказа и получения card_id/reccurent_template_id.

Особенности:

  • Если по платежу отсутствует 3DS (карта не вовлечена в 3D‑Secure), карта не сохраняется;

  • Если платеж прошел успешно или отклонился по балансу, то карта сохраняется и пользователю демонстрируется форма с информацией о том, что карта сохранена успешно. Шаблон формы может быть кастомизирован.

  • Если операция завершилась успешно, то автоматически происходит возврат (разблокировка) средств.

  • Если платеж отклоняется по балансу или проходит успешно, то для последующих платежей создается рекуррентный шаблон и карта сохраняется для операций выдачи средств (Credit). Данные шаблона (_template_id) отправляются исключительно в callback.

Примечание

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

В этом случае, и при успешном совершении тестовой оплаты (блокировки), и при отклонении по балансу карточные данные будут сохранены и для пользователя отобразится страница с информацией об успешном сохранении карты.

Рекуррентные платежи

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

Первый платеж выполняется с вводом всех реквизитов карты, включая код подлинности карты (CVV2/CVC2) и прохождение авторизации по протоколу 3D‑Secure. Последующие платежи выполняются без ввода реквизитов карты и без участия владельца карты.

Принципы работы

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

Срок действия шаблона задается равным сроку действия банковской карты, к которой он привязан. Информацию о зарегистрированных шаблонах рекуррентных платежей можно получить в результате выполнения запроса GetTemplate; при этом требуется указать идентификатор шаблона.

Активация или деактивация шаблона выполняется в результате запроса ActivateTemplate; при этом требуется указать идентификатор шаблона.

Автоматическое удаление шаблонов через Payler API недоступно. Удалить шаблон можно по запросу к технической службе Payler.

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

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

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

Сценарии проведения платежа

После успешного проведения платежа мерчант получает идентификатор созданного шаблона рекуррентных платежей (параметр recurrent_template_id) в callback. Обязательным условием является использование протокола HTTPS для callback. Предварительно мерчанту необходимо выполнить настройку callback для триггера charge или block. Настроить callback можно самостоятельно в личном кабинете мерчанта или обратившись в службу поддержки Payler.

Этапы сценария

  1. Выполнение платежа Создать платежную сессию (запрос StartSession) с указанием значения параметра recurrent = true. Перенаправить пользователя на запрос PayGate. Или (только для схемы Merchant) — выполнить запрос PayMerchant или Block c указанием параметра recurrent = true.

  2. Сохранение шаблона рекуррентных платежей После проведения успешного платежа Payler отправляет мерчанту идентификатор созданного шаблона в параметре recurrent_template_id с помощью сallback. После получения callback требуется запросить статус платежа (запрос GetStatus). Это необходимо, чтобы убедиться, что платеж прошел успешно. В случае успешного списания мерчант сохраняет полученный recurrent_template_id. Если статус платежа отличен от charged/authorized, рекуррентный шаблон надо считать недействительным. Требуется обратиться в службу поддержки.

  3. Выполнение повторного платежа Для проведения повторного платежа необходимо выполнить запрос RepeatPay, с указанием полученного параметра recurrent_template_id.

  4. Запрос статуса повторного платежа Необходимо получить статус повторного платежа, используя запрос GetStatus, с указанием параметров key, order_id.

Внимание

Правила МПС ограничивают число попыток рекуррентного списания средств.

  • При получении отказа по рекуррентному платежу по карте VISA повторный запрос на авторизацию можно направлять не более 4 раз в течение 16 календарных дней;

  • При получении отказа по рекуррентному платежу по карте MasterCard повторный запрос на авторизацию можно направлять не чаще 1 раза в день в течение 31 дня.

Нарушение мерчантом правил попыток рекуррентного списания средств может понести за собой оспаривание платежей (chargeback) в пользу плательщика.

В процессе интеграции мерчанту требуется сообщить службе технической поддержки Payler о необходимости подключения и настройки рекуррентных платежей на его аккаунте.

Схема проведения платежа с созданием шаблона рекуррентных платежей

Сплитование платежей

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

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

Принцип работы

  1. Мерчант присылает реквизиты партнеров, на которые будет проводиться сплитование дебетовых операций или дополнительная выплата кредитных операций.

  2. После регистрации реквизитов мерчант получает ID получателей, которые закрепляются за этими реквизитами. Необходимые реквизиты: наименование организации, ИНН, БИК, Р/С.

  3. Для запросов StartSession (при использовании gapi) или PayMerchant, Block (при использовании mapi) необходимо передать дополнительные параметры следующим образом:

    • pay_page_param_addtoreport3 — суммы зачисления частей платежа для каждого получателя через запятую. Например: «30000,50000».

    • pay_page_param_addtoreport4 — ID получателей через запятую. Например: «322_1,322_2».

  4. Для запросов StartCreditSession (при использовании cgapi) или CreditMerchant (при использовании cmapi) необходимо передать дополнительные параметры следующим образом:

    • pay_page_param_addtoreport3 — суммы переводов с р/с мерчанта для каждого получателя через запятую. Например: «3000000,7800».

    • pay_page_param_addtoreport4 — ID получателей через запятую. Например: «322_3, 322_4».

3D-Secure

3D Secure является XML-протоколом, который используется для двухфакторной аутентификации пользователя в качестве дополнительного уровня безопасности для онлайн-кредитных и дебетовых карт. Название 3DS происходит от «3 Domains» (три домена), так как в проверке платежа по данному протоколу участвуют организации на трех доменах:

  1. Домен эмитента (пользователь и банк-эмитент),

  2. Домен эквайера (банк-эквайер и ТСП),

  3. Домен взаимодействия (МПС).

Существует две версии протокола 3D‑Secure — 3DS 1.0 и более современный и внедряемый сейчас банками-эмитентами 3DS 2.0. Переход на использование версии 2.0 осуществляется постепенно, так как часть эмитентов еще не поддерживает 3DS 2.0. При невозможности проведения аутентификации по новому протоколу аутентификация выполняется по 3DS 1.0.

Принципиальное отличие новой версии протокола состоит:

  • в возможности осуществить аутентификацию без непосредственного участия пользователя (frictionless flow),

  • в использовании 3DS Method для проведения аутентификации с проверкой держателя карты. В этом случае эмитент получает доступ к скрытому iframe в браузере пользователя и самостоятельно производит сбор данных о браузере, требуемых для аутентификации.

При поступлении запроса на проведение платежа или сохранение карты, для дальнейшего выполнения операции Payler на своей стороне выполняет проверку вовлеченности карты в 3D-Secure и определение поддерживаемой версии протокола.

3DS 1.0

Краткий сценарий аутентификации по версии 3DS 1.0 (3DS 1.0 Flow):

Держатель карты совершает оплату на сайте ТСП, вводит данные карты и направляется на страницу банка-эмитента, для ввода уникального кода. Код отправляется пользователю банком-эмитентом по другому каналу (например, в sms). Если код введен правильно, банк-эмитент сообщает об успешном завершении проверки и операция успешно завершается.

3DS 2.0

3DS 2.0 позволяет эмитенту использовать несколько режимов проверки подлинности клиента, в том числе с вводом одноразового кода, отправляемого эмитентом в sms. Но в отличие от версии 3DS 1.0 ввод пароля не является обязательным. Решение о подтверждении операции принимается на основании данных об устройстве, с которого совершается платеж, настроек браузера, IP-адреса, e-mail и др. Эмитент карты использует эту информацию для оценки уровня риска и необходимости выполнения дополнительной проверки пользователя. В зависимости от результатов анализа степени риска эмитент принимает решение о дальнейшем проведении аутентификации:

  • Frictionless flow — если риск мошенничества ниже заданного порогового значения, то эмитент не запрашивает дополнительную проверку плательщика и считает, что проверка подлинности владельца карты пройдена. В этом случае этап «ручной проверки» с вводом плательщиком дополнительного кода исключается.

  • Challenge flow — если риск мошенничества выше заданного порогового значения, выполняется дополнительная проверка держателя карты аналогично 3DS 1.0.

Сценарии проведения операций с 3DS

Принципиальная схема 3D-Secure
Возможные сценарии аутентификации 3D-Secure 2.0

В настоящий момент поддерживается 3D-Secure version 2.2.0.

Платежи Apple Pay

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

Прием платежей в мобильных приложениях

Регистрация мерчанта

Для использования технологии Apple Pay мерчанту необходимо зарегистрировать Merchant ID и сформировать платежный сертификат:

  1. Payler создает CSR и отправляет его мерчанту.

  2. Мерчант загружает сертификат в свой аккаунт разработчика Apple, как описано в документации Apple.

  3. Мерчант передает в Payler полученный сертификат и Merchant ID.

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

Схема оплаты включает 3 этапа:

  1. Проверку совместимости устройства — если устройство поддерживается, то нужно показать покупателю кнопку Apple Pay.

  2. Подтверждение платежа — подтверждение покупателем оплаты отпечатком пальца.

  3. Обработку платежа — после подтверждения Apple формирует зашифрованный токен, который необходимо передать в API Payler. Для этого требуется:

    • вызвать метод StartSession для инициализации сессии платежа.

    • после подтверждения платежа пользователем параметр paymentData из объекта PKPaymentToken передать в Payler с помощью метода ApplePay; в ответ придет информация о статусе платежа.

    • вызвать в приложении completion, передав в него статус платежа.

Интеграция ApplePay в мобильных приложениях описана в документации Apple.

Прием платежей на сайте мерчанта

Страница с кнопкой Apple Pay должна отдаваться с через HTTPS с использованием валидного SSL‑сертификата и протокола TLS 1.2.

Необходимо:

  1. Получить от Payler файл apple-developer-merchantid-domain-association,

  2. Разместить полученный файл на сервере мерчанта по адресу: https://адрес.сайта/.well-known/apple-developer-merchantid-domain-association.

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

Схема оплаты включает 4 этапа:

  1. Проверку совместимости устройства — если устройство поддерживается, нужно показать покупателю кнопку Apple Pay.

  2. Валидацию мерчанта — необходимо выполнить запрос AppleValidateMerchant для валидации мерчанта в Apple.

  3. Подтверждение платежа — подтверждение покупателем оплаты отпечатком пальца.

  4. Обработку платежа — после подтверждение Apple формирует зашифрованный токен, который необходимо передать в API Payler c использованием метода ApplePay.

Отображение кнопки ApplePay

Пример CSS и HTML для добавления кнопки Apple Pay на странице приведен в документации Apple. Изначально кнопка Apple Pay должна быть невидима (display: none), a отображаться, только если есть возможность оплатить с помощью Apple Pay с данного устройства.

Обработка оплаты в JavaScript

Сначала требуется проверить возможность оплаты через Apple Pay на данном устройстве:

var promise = ApplePaySession.canMakePaymentsWithActiveCard(merchantIdentifier);
promise.then(function (canMakePayments) {
  if (canMakePayments) {
    // если возможно — отобразить кнопку
    document.getElementById("apple-pay-button").style.display = "block";
  }
});

При нажатии на кнопку создать сессию на оплату:

document.getElementById("apple-pay-button").onclick = function(evt) {
  var paymentRequest = {
    currencyCode: 'RUB',
    countryCode: 'RU',
    total: {
      label: 'Описание продукта',
      amount: 100.00 // цена в рублях
    },
    supportedNetworks: ['masterCard', 'visa', 'mir'],
    merchantCapabilities: [ 'supports3DS', 'supportsCredit', 'supportsDebit']
  };
  var session = new ApplePaySession(2, paymentRequest);

Далее необходимо добавить обработчики событий в объект session: Валидация мерчанта:

session.onvalidatemerchant = function (event) {
  // Нужно отправить event.validationURL на свой сервер, откуда вызвать
  // метод Payler AppleValidateMerchant, а полученный ответ передать в
  // метод session.completeMerchantValidation

  session.completeMerchantValidation(JSON.parse(response.validation_object));
}

Обработка платежа:

session.onpaymentauthorized = function (event) {
  // необходимо отправить event.payment.token.paymentData на свой сервер, откуда
  // вызвать метод Payler StartSession, а затем ApplePay.
  // Результат проведения платежа нужно вернуть обратно на клиент.
 
  // Если платёж успешен, вызываем:
  session.completePayment(ApplePaySession.STATUS_SUCCESS);
 
  // Если платёж неуспешен, вызываем:
  session.completePayment(ApplePaySession.STATUS_FAILURE);
}

Отображение формы Apple Pay:

session.begin();

Более подробно методы и события ApplePaySession описаны в документации Apple.

Платежи GooglePay

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

В случае использования Google Pay мерчант обязан соблюдать положения следующих правил: https://payments.developers.google.com/terms/sellertos

Документация к API: https://developers.google.com/pay/api/web

Правила использования бренда: https://developers.google.com/pay/api/web/guides/brand-guidelines

Контрольный список интеграции: https://developers.google.com/pay/api/web/guides/test-and-deploy/integration-checklist

Мерчант может самостоятельно выбрать типы карт (методов аутентификации), по которым возможна оплата в Google Pay.

Доступны два метода аутентификации:

  1. CRYPTOGRAM 3DS — для токенизированных карт, данные которых хранятся в виде токенов на устройстве клиента и доступных только на том устройстве, на котором карта была добавлена в приложение Google Pay.

  2. PAN ONLY — для нетокенизированных карт, данные которых хранятся в аккаунте Google и доступных на любом устройстве клиента.

Тип аутентификации указывается в настройках при интеграции с Google Pay в свойстве allowedAuthMethods.

Внимание

Метод PAN ONLY доступен не для всех мерчантов. Возможность подключения метода необходимо уточнять индивидуально

Прием платежей в мобильных приложениях

Настройка Google Pay API

Заполнение файла Constants.java
package com.google.android.gms.samples.wallet;

import com.google.android.gms.wallet.WalletConstants;
import java.util.Arrays;
import java.util.HashMap;
import java.util.List;

public class Constants {

public static final int PAYMENTS_ENVIRONMENT =  WalletConstants.ENVIRONMENT_TEST; // WalletConstants.ENVIRONMENT_PRODUCTION для production среды.

public static final List<String> SUPPORTED_NETWORKS = Arrays.asList(
"MASTERCARD",
"VISA");
 
public static final List<String> SUPPORTED_METHODS =
Arrays.asList("PAN_ONLY",        //Оплата по карточным данным из аккаунта Google.
"CRYPTOGRAM_3DS"); //Оплата только при наличии на устройстве Google Pay. Является более безопасным способом. Можно использовать как оба способа, так и любой один из них

public static final String CURRENCY_CODE = "RUB"; // Или USD, EUR. Должна совпадать с валютой в StartSession

public static final String PAYMENT_GATEWAY_TOKENIZATION_NAME = "payler";

public static final HashMap<String, String> PAYMENT_GATEWAY_TOKENIZATION_PARAMETERS =
  new HashMap<String, String>() {
      {
          put("gateway", PAYMENT_GATEWAY_TOKENIZATION_NAME);
          put("gatewayMerchantId", "Ваш идентификатор в системе Payler");
      }
  }
  private Constants() {}
}

В файле PaymentsUtil.java должен быть установлен тип токенизации “PAYMENT_GATEWAY”.

Проведение платежа

  1. Вызвать метод StartSession для инициализации сессии платежа.

  2. В обработчике нажатия кнопки Google Pay в случае успеха вызывать метод GooglePay, передав:

    • session_id из ответа StartSession,

    • строку "tokenizationData.token" из полученного от Google объекта PaymentData (google_pay_token),

    • почтовый адрес покупателя (email).

Пример токена:

{
    "signature": "MEYCIQCkSQPbDN5lKh1Y+l6W3A5fdW3Patf0hoBrXmTudQZSSQIhAMX8G54mswpbw07t1adHhNfZAkWUvQ6YyQP8Zzhc68pR",
    "intermediateSigningKey": {
        "signedKey": "{\"keyValue\":\"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEzHwfz1Vq1ZIf9fiZVyBI33CnXRwBP2hJ1CYvzx5x6adfBXfYv0krbQU1bEv9DNKwStIlRKhzQhIdeJZBGFl96w\\u003d\\u003d\",\"keyExpiration\":\"1551450347229\"}",
        "signatures": [
            "MEYCIQC6Cws1WByrGnoijw0MWcjvq16aYCL+JH/+5Y3DAMbJiwIhAL6+RWUJo+j9cqaP71UsZs18GPVU0kq/CLOB0Qb8rBgr"
            ]
        },
    "protocolVersion": "ECv2",
    "signedMessage": "{\"encryptedMessage\":\"WBGMAnIuhwyGROX6c4q/Ux6Gupm/US2FVnq7wKZEp7C6E5OkiHqv/2vd+PW4/XVY1VlKhh+POt6RY66Q3OX/Q2apalv+4OCxWJhlsP4sZ0NZCCiJEfWY5P9ayjNbzJJnoJerfwykn2cDItHHjerHtNObMUkqCFkW7Yj0X5uZTfx1Alr2k4knLWtMrlfHuh9RHiAei/pcppWerYmNPrLzU615ypqinwtifq+iVldnz2oYJpDzQyZukFU51Xu5BQhzHUtqly9Y1Lt1hCfCeLY4fqrz/V10oiXmgeY9gUrJOy6zzSdAq5VsdiZlUJCbspK2lThXG9Hg/ZPQ7o0fxdSnLI3BvkjFLvFtLgDtnk9o8Di9kx2intm/5YJS0RB1wOfjicn5JzwuDiur/RXYMPjhAh0L+ZUts3knWMNlgiVXAuEPwRm5oU/2RiThV3du3BNJSQbybflvSIhH12Pwua1tFLRKzESBnhfrP/OFN52PaazQQ4Jv7PG+tpVuvWEErdifoGuVXQw89vloCYKYBBEdlNG85DSkMYq/hAfmsgFrDrs7spA1Sb26s5oJRomL76x90X8\\u003d\",\"ephemeralPublicKey\":\"BLVkBHOrk1we3aAqbHeMfnL3dfGUmM9MQJ8CJtLwQn6KUnpySSSY0os+PHDbqfIHVVa8jqzgx1gynofubTsqgTA\\u003d\",\"tag\":\"5lc6cXbwEd9obykJ+qbAj+O6fHFwP85LGnihp4//zDg\\u003d\"}"
}

Прием платежей на сайте мерчанта

Cайт мерчанта должен работать по HTTPS и поддерживать протокол TLS версии 1.2. Домен сайта необходимо предварительно зарегистрировать и подтвердить в Google, заполнив форму регистрации. После отправки формы представитель Google связывается с мерчантом для консультации по дальнейшим действиям.

Интеграция включает использование серверной и клиентской (javascript) части. На клиенте выполняется проверка совместимости устройства и получение платежных данных, на сервере отправляется запрос на проведение платежа.

Настройки

Пример js кода:

  • Параметр gateway в скрипте имеет постоянное значение "payler";

  • Значение параметра gatewayMerchantId мерчант получает от Payler;

  • Значение параметра merchantId мерчант получает от Google,

  • Значение параметра merchantName соответствует названию интернет-магазина, указанному при регистрации в Google.

Пример
// /**
 * Define the version of the Google Pay API referenced when creating your
 * configuration
 *
 * @see {@link https://developers.google.com/pay/api/web/reference/object#PaymentDataRequest|apiVersion in PaymentDataRequest}
 */
var baseRequest = {
  apiVersion: 2,
  apiVersionMinor: 0,
};
 
var allowedCardNetworks = ['MASTERCARD', 'VISA'];
// CRYPTOGRAM_3DS - Оплата только при наличии на устройстве Google Pay. Является более безопасным способом. На текущий момент работает только в браузере Chrome на Android.
// PAN_ONLY - Оплата по карточным данным из аккаунта Google. Доступен в большинстве современных браузеров.
// Можно использовать как оба способа, так и любой один из них.
var allowedCardAuthMethods = ["PAN_ONLY",'CRYPTOGRAM_3DS'];
var tokenizationSpecification = {
  type: 'PAYMENT_GATEWAY',
  parameters: {
    gateway: 'payler',
    gatewayMerchantId: 'ваш Id в системе Payler',
  },
};
 
/**
 * Describe your site's support for the CARD payment method and its required
 * fields
 *
 * @see {@link https://developers.google.com/pay/api/web/reference/object#CardParameters|CardParameters}
 */
var baseCardPaymentMethod = {
  type: 'CARD',
  parameters: {
    allowedAuthMethods: allowedCardAuthMethods,
    allowedCardNetworks: allowedCardNetworks,
  },
};
 
/**
 * Describe your site's support for the CARD payment method including optional
 * fields
 *
 * @see {@link https://developers.google.com/pay/api/web/reference/object#CardParameters|CardParameters}
 */
var cardPaymentMethod = Object.assign({}, baseCardPaymentMethod, {
  tokenizationSpecification: tokenizationSpecification,
});
 
var paymentsClient = null;
 
/**
 * Configure your site's support for payment methods supported by the Google Pay
 * API.
 *
 * Each member of allowedPaymentMethods should contain only the required fields,
 * allowing reuse of this base request when determining a viewer's ability
 * to pay and later requesting a supported payment method
 *
 * @returns {object} Google Pay API version, payment methods supported by the site
 */
function getGoogleIsReadyToPayRequest() {
  return Object.assign({}, baseRequest, {
    allowedPaymentMethods: [baseCardPaymentMethod],
  });
}
/**
 * Configure support for the Google Pay API
 *
 * @see {@link https://developers.google.com/pay/api/web/reference/object#PaymentDataRequest|PaymentDataRequest}
 * @returns {object} PaymentDataRequest fields
 */
function getGooglePaymentDataRequest() {
  var paymentDataRequest = Object.assign({}, baseRequest);
  paymentDataRequest.allowedPaymentMethods = [cardPaymentMethod];
  paymentDataRequest.transactionInfo = getGoogleTransactionInfo();
  paymentDataRequest.merchantInfo = {
    // @todo a merchant ID is available for a production environment after approval by Google
    // See {@link https://developers.google.com/pay/api/web/guides/test-and-deploy/integration-checklist|Integration checklist}
    merchantId: 'Ваш Id GooglePay',
    merchantName: 'Ваше наименование,
  };
  return paymentDataRequest;
}
 
/**
 * Return an active PaymentsClient or initialize
 *
 * @see {@link https://developers.google.com/pay/api/web/reference/client#PaymentsClient|PaymentsClient constructor}
 * @returns {google.payments.api.PaymentsClient} Google Pay API client
 */
function getGooglePaymentsClient() {
  if (paymentsClient === null) {
    paymentsClient = new google.payments.api.PaymentsClient({
      environment: 'TEST', // Для продуктовой среды д.б. PRODUCTION
    });
  }
  return paymentsClient;
}
 
/**
 * Initialize Google PaymentsClient after Google-hosted JavaScript has loaded
 *
 * Display a Google Pay payment button after confirmation of the viewer's
 * ability to pay.
 */
function onGooglePayLoaded() {
   {
    var paymentsClient = getGooglePaymentsClient();
 
    paymentsClient
      .isReadyToPay(getGoogleIsReadyToPayRequest())
      .then(function(response) {
        if (response.result) {
          addGooglePayButton();
          // @todo prefetch payment data to improve performance after confirming site functionality
          // prefetchGooglePaymentData();
        }
      })
      .catch(function(err) {
        // show error in developer console for debugging
        console.error(err);
      });
  }
}
 
/**
 * Add a Google Pay purchase button alongside an existing checkout button
 *
 * @see {@link https://developers.google.com/pay/api/web/reference/object#ButtonOptions|Button options}
 * @see {@link https://developers.google.com/pay/api/web/guides/brand-guidelines|Google Pay brand guidelines}
 */
function addGooglePayButton() {
  var paymentsClient = getGooglePaymentsClient();
  var button = paymentsClient.createButton({onClick: onGooglePaymentButtonClicked});
  var changeBlock = document.querySelector('.change-js');
  document.getElementById('container').appendChild(button);
  changeBlock.style.display = 'block';
}
 
/**
 * Provide Google Pay API with a payment amount, currency, and amount status
 *
 * @see {@link https://developers.google.com/pay/api/web/reference/object#TransactionInfo|TransactionInfo}
 * @returns {object} transaction info, suitable for use as transactionInfo property of PaymentDataRequest
 */
function getGoogleTransactionInfo() {
  return {
    currencyCode: 'RUB', //Валюта платежа
    totalPriceStatus: 'FINAL',
    // set to cart total
    totalPrice: '11.20', //Сумма платежа
  };
}
 
/**
 * Prefetch payment data to improve performance
 *
 * @see {@link https://developers.google.com/pay/api/web/reference/client#prefetchPaymentData|prefetchPaymentData()}
 */
function prefetchGooglePaymentData() {
  var paymentDataRequest = getGooglePaymentDataRequest();
  // transactionInfo must be set but does not affect cache
  paymentDataRequest.transactionInfo = {
    totalPriceStatus: 'NOT_CURRENTLY_KNOWN',
    currencyCode: 'RUB',
  };
  var paymentsClient = getGooglePaymentsClient();
  paymentsClient.prefetchPaymentData(paymentDataRequest);
}
 
/**
 * Show Google Pay payment sheet when Google Pay payment button is clicked
 */
function onGooglePaymentButtonClicked() {
  var paymentDataRequest = getGooglePaymentDataRequest();
  paymentDataRequest.transactionInfo = getGoogleTransactionInfo();
 
  var paymentsClient = getGooglePaymentsClient();
  paymentsClient
    .loadPaymentData(paymentDataRequest)
    .then(function(paymentData) {
      // handle the response
      processPayment(paymentData);
    })
    .catch(function(err) {
      // show error in developer console for debugging
      console.error(err);
    });
}
 
function sendPaymentData(paymentToken) {
  return new Promise(function(resolve, reject) {
    var xhr = new XMLHttpRequest();
    xhr.onload = function() {
      var data = JSON.parse(this.responseText);
      resolve(data);
    };
    xhr.onerror = reject;
    xhr.open(
      'POST',
      'https:/secure.payler.com/gapi/GooglePay?session_id=' + // https:/secure.payler.com для тестовой среды
        encodeURIComponent(window.params_payler.session_id) +
        '&google_pay_token=' +
        encodeURIComponent(paymentToken)
    );
    xhr.send();
  });
}
 
/**
 * Process payment data returned by the Google Pay API
 *
 * @param {object} paymentData response from Google Pay API after user approves payment
 * @see {@link https://developers.google.com/pay/api/web/reference/object#PaymentData|PaymentData object reference}
 */
function processPayment(paymentData) {
  // show returned data in developer console for debugging
  //  console.log(paymentData);
  // @todo pass payment token to your gateway to process payment
  paymentToken = paymentData.paymentMethodData.tokenizationData.token;
 
  var promise = sendPaymentData(paymentToken);
  promise.then(function(response) {
    if (response.error) {
      //  console.log(response.error);
    } else {
      );
    }
  });
}

В ответ Google должен вернуть элемент PaymentData, а поле paymentMethodData.tokenizationData.token должно содержать надежно зашифрованный токен Google Pay (строка символов). Пример Google Pay Token:

{
    "signature": "MEUCIQDY3wBQyHB4sZcktRoJXKxm+OLcjHzCvdDeGn23oX0kkwIgKznRFZZL+sDMv1b5cuD+YurXMZraYBsr9hbravVY5Ro\u003d",
    "protocolVersion": "ECv2",
    "signedMessage": "{\"encryptedMessage\":\"cI87tLqzqTGyCFnMMCVWcTHw3xhYIK+CEnuQ74K+nlLpCgOlfpScib9jds4sxDtN6CunCqCSMfd/3yHeeRy6aCx1yyqcT4ey6NueeBznprJpkmVVgI1JHWLQt4hzAXMUAcYASYLOabKP9fUZvHkOBDytD531jpzNXa+Spc/zrpGzFKx2C4VU9sC95q9i+ey+kr7ZMNVCOFJPWXu7lKZ105IOOqozJ6/70MKmxP3jM89eeq+/19QnyHjQLXfnQPvQjiUJKGCcRKDLlrb3XoY5ZUUzGfN5eZCLzCVg0hWEbwU+6J7KWYJyW+Wr1r8bagN9zWsrMKhDpsQbHfyzb+yBzFUoxeUgL4a7FeVvEllIcHtqsvTCf6FENV20aF5VLDv5qzUkV+PzTAIbFEuabA0God9UbVCVVv7nM8QFzvRPhzYYFVFTn4JHvL2qZ4pAR9lE+w\\u003d\\u003d\",\"ephemeralPublicKey\":\"BPHLC4sBHpenY1M0ixmiDMuWJTaTJOqggRUwtgBJMcBp28VsxHD7zPI7985x4F5EjMP5y8j/cuUzbe/cGPjOKGk\\u003d\",\"tag\":\"RaXrPOUuc5iw3oxDa0C2MOjaKxgxIRQvwOspmtFV0zU\\u003d\"}"
}

Проведение платежа

Процедура аналогична проведению платежа при совершении оплаты из мобильного приложения (см. выше).

PreviousВведениеNextИстория изменений

Last updated