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

Введение

Payment Page — это предлагаемая Rocketpay платежная форма, которая представляет собой гибко конфигурируемый программный модуль с пользовательским интерфейсом, позволяющий проводить оплату и выполнять другие действия, используя различные платежные методы. Payment Page позволяет вам внедрить платежную форму на свой веб-сайт или в мобильное приложение и принимать платежи, даже если у вас нет сертификата PCI DSS.

Вызов Payment Page осуществляется через API, и со стороны мерчанта может использоваться как сам API, так и специализированные компоненты, облегчающие работу с ним: подключаемая JavaScript-библиотека и подключаемые модули для сайтов на базе ряда распространенных CMS. Такое разнообразие технических решений позволяет оперативно настраивать работу с Payment Page в самых разных проектах.

Открытие Payment Page на пользовательском устройстве может выполняться в отдельной вкладке браузера, в модальном окне и в объекте iframe HTML-страницы с использованием стандартного или индивидуального дизайна. Конкретный способ открытия, а также способы выполнения промежуточных действий и отображения итоговой информации можно задавать при вызове формы. И это разнообразие, в свою очередь, позволяет гибко подстраивать работу Payment Page под самые разные пользовательские сценарии.

Далее в этом разделе представлены основные сведения о схеме работы и возможностях Payment Page с эмулированием ее работы в различных ситуациях.

Схема работы

При работе с Payment Page все взаимодействия с платежной платформой — со стороны пользовательского устройства и серверной части веб-сервиса — выполняются с использованием протоколов HTTP версии не ниже 1.1 и TLS версии не ниже 1.2, а в качестве пользовательского браузера могут использоваться актуальные версии таких браузеров, как Chrome, Safari, Opera, Firefox, Microsoft Edge, Internet Explorer, Yandex Browser, QQ, MIUI, Samsung Internet, 360 и ряда других. Подробную информацию о работе Payment Page в разных средах можно получить у специалистов технической поддержки Rocketpay (support@rocketpay.kz).

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

Рис.: Схема взаимодействия

В общем случае работа с Payment Page строится следующим образом:

  1. Пользователь инициирует вызов платежной формы в пользовательском интерфейсе веб-сервиса, с помощью кнопки оплаты или иным заданным способом.
  2. В клиентской части веб-сервиса формируется набор параметров вызова Payment Page и передается к серверной части.
  3. В серверной части веб-сервиса при необходимости могут выполняться проверка и дополнение параметров и обязательно формируется подпись к итоговому набору, после чего подготовленные данные передаются назад в клиентскую часть. При этом важно, чтобы подписывался именно итоговый набор параметров, с учетом всех требований API и предпочтений по вызову платежной формы: иначе запрос не будет корректным.
  4. На стороне клиентской части веб-сервиса выполняются формирование запроса на открытие Payment Page и отправка этого запроса в платежную платформу.
  5. На стороне платежной платформы выполняются подготовка Payment Page с учетом параметров вызова и передача к пользовательскому устройству данных для отображения формы.
  6. Платежная форма отображается в пользовательском интерфейсе.
  7. Пользователь выполняет необходимые действия в платежной форме: выбирает платежный метод (если он не был задан при вызове), указывает реквизиты и другую информацию и подтверждает готовность провести оплату или выполнить другое целевое действие (например, проверить карту).
  8. От Payment Page к платежной платформе отправляется запрос на выполнение целевого действия с учетом всех данных, введенных пользователем.
  9. На стороне платежной платформы выполняются регистрация платежа и все необходимые технические действия, в том числе передача требуемых данных в платежную среду: к провайдерам и платежным системам.
  10. В платежной среде, на стороне требуемых систем, выполняется обработка платежа, по итогам которой в платежную платформу поступает информация о результате.
  11. В платежной платформе обрабатывается итоговая информация, после чего на заданный URL мерчанта отправляется программное оповещение о результате (как и при работе с другими интерфейсами платежной платформы).
  12. Информация о результате передается из платежной платформы в Payment Page.
  13. Информация о результате отображается в пользовательском интерфейсе в соответствии с заданными настройками: на странице Payment Page или на странице веб-сервиса, к которой выполняется перенаправление.

Эта схема отображает ключевые моменты со стороны мерчанта, но в отдельных случаях может варьироваться в части промежуточных взаимодействий между пользователем, Payment Page, платежной платформой и сервисами платежной среды на шагах 7–10. Так, при проведении платежей возможны дополнительные взаимодействия, например для выполнения аутентификации 3-D Secure или для подтверждения платежа в сервисе альтернативной платежной системы, а при вызове Payment Page для сохранения платежных данных на шаге 9 не регистрируется платеж и опускается шаг 10. Подобные нюансы влияют на пользовательские сценарии, и, с одной стороны, при выполнении промежуточных взаимодействий на шагах 7–10 не требуется никаких дополнительных действий со стороны веб-сервиса, а с другой стороны, за счет подбора параметров вызова Payment Page на шагах 2–3 можно существенно влиять на то, с чем и как сталкивается пользователь. Чтобы конфигурировать работу с платежной формой под потребности конкретного проекта, можно использовать описанные далее возможности и совместно со специалистами технической поддержки Rocketpay настраивать оптимальные сценарии.

Базовый пользовательский сценарий можно представить следующим образом:
  1. Пользователь подтверждает готовность оплатить свой заказ, переходит на Payment Page и выбирает метод оплаты.

    (При этом выполняются шаги 1–6 и частично шаг 7 общей схемы взаимодействия.)

  2. Пользователь указывает необходимые реквизиты платежного инструмента, подтверждает готовность провести оплату выбранным способом и ожидает информацию о результате.

    (При этом выполняются шаги 7–12 общей схемы взаимодействия.)

  3. Пользователь получает информацию о результате оплаты.

    (При этом выполняется шаг 13 общей схемы взаимодействия.)

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

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

Наконец, важным дополнением к приведенной схеме является информация о контроле работы Payment Page со стороны мерчанта. По умолчанию индикация открытия платежной формы и действий с ней не используется, но такую индикацию можно настроить. При использовании JavaScript-библиотеки Rocketpay можно получать и обрабатывать информацию об открытии формы или об ошибке при ее открытии, о подтверждении операции или о закрытии формы, а также о других интерфейсных событиях. А после подтверждения целевого действия в Payment Page и регистрации платежа в платежной платформе для получения информации о состоянии этого платежа можно использовать запросы через Gate и средства интерфейса Dashboard.

Возможности

Доступные действия

С помощью Payment Page можно решать следующие задачи:

  • Оплата Это наиболее распространенный вариант использования платежной формы — с проведением оплат в одну стадию, при которых в рамках одного сеанса работы Payment Page осуществляется разовый перевод денежных средств от пользователя к мерчанту, например за совершаемую покупку.
  • Блокировка средств При таком варианте использования в рамках сеанса работы Payment Page осуществляется блокировка денежных средств на счете пользователя, и мерчант получает возможность уже в дальнейшем (через Gate либо автоматически по истечении заданного периода) списать нужную сумму или вернуть деньги пользователю. Это может быть актуально, например, при бронировании номера в отеле или аренде автомобиля.
  • Регистрация повторяемых списаний При выстраивании долгосрочных отношений с пользователями могут быть удобны неоднократные списания средств без указания платежных реквизитов или вовсе без пользовательского участия (например, при платежах по подписке). В платежной платформе для этого поддерживаются повторяемые оплаты, и с помощью Payment Page можно регистрировать все типы этих оплат — регулярные, автоматические и экспресс (OneClick) — указывая соответствующие параметры при вызове платежной формы.
  • Проверка платежных инструментов Этот вариант позволяет подтвердить возможность работы с конкретным платежным инструментом (как правило, картой), например для последующего проведения выплаты пользователю. В рамках сеанса работы Payment Page при этом осуществляется один условный (нулевой) перевод денежных средств от пользователя к мерчанту или одна реальная (ненулевая) блокировка средств пользователя с последующей отменой.
  • Сохранение платежных данных При таком варианте использования в рамках сеанса работы Payment Page не проводится никаких финансовых операций, даже условных на нулевую сумму, но регистрируется информация о платежном инструменте пользователя и для этой информации создается безопасный идентификатор — токен. Работа с токенами актуальна для платежных карт и позволяет сохранять платежные данные пользователя, например при его регистрации в веб-сервисе, и использовать эти данные в дальнейшем для проведения оплат и выплат с упрощенными пользовательскими сценариями.

Конкретные действия задаются в параметрах вызова Payment Page. В рамках конкретных сценариев допустимы вариации: с указанием и сохранением платежных данных, со сбором дополнительной информации и использованием иных возможностей, представленных далее.

Разные способы указания данных

При использовании Payment Page поддерживаются разные способы выбора платежного метода и указания платежных данных.

Платежный метод выбирается одним из следующих способов:

  • На форме среди доступных методов Это базовый вариант, при котором пользователь выбирает метод из числа всех, подключенных мерчанту в рамках используемого проекта.
  • На форме среди заданных методов В каких-то случаях, например с учетом региональных особенностей, может быть актуально отобразить пользователю не все, а только некоторые из подключенных методов. Тогда нужное подмножество задается в параметрах вызова Payment Page, и пользователь выбирает из этого подмножества.
  • До вызова формы В некоторых ситуациях выбор платежного метода возможен на стороне веб-сервиса до вызова Payment Page (в «корзине», например). Тогда целевой метод задается в параметрах вызова Payment Page и пользователь начинает работу с платежной формой с указания реквизитов, минуя выбор метода.

Платежные данные указываются одним из следующих способов:

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

    В дополнение к выбранным реквизитам для некоторых инструментов требуется подтверждение, такое как ввод проверочного кода (CVC, CVV, CID) при работе с платежными картами.

  • Путем выбора до вызова формы В этом варианте пользователь выбирает в веб-сервисе конкретную карту, в запросе на открытие Payment Page указывается токен этой карты, и платежная форма открывается с указанием всех реквизитов кроме проверочного кода (CVC, CVV, CID), который необходимо указать непосредственно на форме.

Поддержка дополнительных функций

В дополнение к базовым сценариям (в каждом из которых так или иначе присутствуют выбор платежного метода, указание данных и последующие обязательные шаги) при выполнении целевых действий в Payment Page можно использовать следующее:

  • Выбор валюты платежа пользователем. При использовании этой функциональности пользователь может выбрать на форме одну из заданных валют для проведения платежа. И далее, если требуется, на стороне платежной платформы выполняется конвертация по актуальному курсу.
  • Сбор дополнительной информации о пользователе. Эта функциональность позволяет использовать на платежной форме дополнительные поля, например для указания адреса, номера телефона и даты рождения пользователя. Состав таких полей можно выбирать из числа поддерживаемых в платформе, а среди выбранных можно определять обязательные и необязательные к заполнению пользователем.
  • Предоставление повторных попыток ввода данных. При использовании этой функциональности в случае ошибки при выполнении целевого действия пользователю отображается соответствующее сообщение (например, о недостатке средств на балансе указанной карты) и предложение повторить попытку. И далее, если пользователь соглашается попробовать еще раз, он может выбрать тот же или иной платежный метод и не вводить повторно данные, введенные им при предыдущей попытке.
  • Каскадное проведение платежей. Эта функциональность схожа с повторными попытками ввода данных: если что-то пошло не так, то пользователь может попробовать еще раз. Но в этом случае обеспечивается защита не от ошибок со стороны пользователя, а от ошибок и сбоев со стороны провайдеров и платежных систем. Для этого, в соответствии с заданными настройками, последовательно выполняются дополнительные попытки проведения платежа через резервные платежные системы или провайдеров.
  • Отправка уведомлений пользователю. Использование этой функциональности позволяет отправлять уведомления о проведении платежей на электронную почту пользователя. При этом можно настраивать состав и формат отправляемых писем, а также использовать разные шаблоны для разных типов и статусов операций (это, прежде всего, актуально для статусов success и decline).

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

Выполнение вспомогательных процедур

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

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

К поддерживаемым в работе Payment Page вспомогательным процедурам относятся:

  • Аутентификация 3-D Secure. Эта аутентификация (Three-Domain Secure) применяется при работе с платежными картами для защиты от мошенничества. В данное время на смену протоколу 3‑D Secure 1 приходит 3‑D Secure 2, со стороны эмитентов и платежных систем поддерживаются либо один, либо оба протокола и для Payment Page обеспечена работа со всеми переходными ситуациями.

    В пользовательском сценарии при выполнении аутентификации 3‑D Secure либо выполняется перенаправление к сервису эмитента, где необходимо подтвердить свою подлинность кодом из SMS-сообщения или иным способом, либо отображается страница ожидания (в то время, пока эмитент подтверждает подлинность без участия пользователя).

  • Аутентификация по инициативе мерчанта. Эта аутентификация поддерживается со стороны некоторых провайдеров и по желанию мерчанта может использоваться в качестве замены аутентификации 3‑D Secure 1 или для ее дополнения. Такое может быть актуально, когда, например, со стороны эмитента применяются недостаточно надежные методы подтверждения подлинности пользователя.

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

  • Проверка адреса пользователя (Address Verification Service, AVS). Эта проверка призвана обеспечить дополнительный уровень защиты от мошенничества при работе с платежными картами за счет сопоставления адреса, указанного при проведении конкретного платежа, с адресом, зарегистрированным для держателя указанной карты на стороне эмитента. Проверка адреса обязательна для операций, совершаемых на территории Великобритании, и также может применяться в США, Австралии, Канаде и Новой Зеландии.

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

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

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

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

Поддержка разных вариантов отображения итоговой информации

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

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

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

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

Контроль работы с формой и результатов целевых действий

Процесс работы пользователей с Payment Page контролируется, прежде всего, со стороны Rocketpay, но при этом доступны и возможности для контроля со стороны мерчанта. К таким возможностям относятся:

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

    Это позволяет оперативно реагировать на значимые события, связанные с платежной формой, непосредственно в клиентской части веб-сервиса. Так, можно уточнить у пользователя причину закрытия формы или дополнительно уведомить его о скором завершении времени на ввод данных. И, конечно, за счет такого контроля можно дополнительно анализировать действия пользователей при работе с Payment Page в разных ситуациях.

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

    Это позволяет избежать ситуаций с „подвисанием“ открытых форм на нежелательно долгое или вовсе неопределенное время и контролировать предоставление услуг пользователям (что, например, может быть актуально при продаже билетов, распродаже товаров и иных событиях с привязкой ко времени).

  • Контроль результатов. Для контроля результатов целевых действий, выполняемых через Payment Page, со стороны мерчанта можно использовать разные средства:
    • Во-первых, программные оповещения, которые автоматически отправляются на заданные URL по итогам выполнения целевых действий и содержат детальную информацию о результатах. Через эти оповещения можно обеспечивать оперативный автоматический контроль ситуации на стороне серверной части веб-сервиса.
    • Во-вторых, специальные запросы к Gate и Data API, с помощью которых можно получать детальную информацию об отдельных платежах и группах платежей в тех случаях, когда это необходимо со стороны веб-сервиса.
    • В-третьих, средства интерфейса Dashboard, с помощью которого можно обеспечивать контроль и анализ ситуации сотрудниками, как по отдельным платежам, так и по сводным показателям.

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

Поддержка разных вариантов оформления платежной формы

В дополнение к различным функциональным возможностям при работе с Payment Page можно гибко конфигурировать дизайн формы — в плане аспектов ее «поведения» и оформления. К таким аспектам относятся:

  • Способы вызова формы. Вызов Payment Page из веб-сервиса может быть реализован как через переход по кнопке, так и через другие интерфейсные события. В подключаемой JavaScript-библиотеке Rocketpay для этого доступны соответствующие методы, а если вызов Payment Page осуществляется через API, то со стороны мерчанта можно поддержать необходимую функциональность непосредственно в веб-сервисе.
  • Способы отображения формы. Payment Page поддерживает следующие варианты отображения:
    • в объекте iframe HTML-страницы;
    • в модальном окне поверх HTML-страницы;
    • в виде отдельной HTML-страницы, в текущей или новой вкладке браузера.

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

  • Способы перенаправлений с формы. При выполнении целевых действий через Payment Page порой необходимы перенаправления пользователя к сторонним сервисам — например, для аутентификации 3-D Secure или подтверждения оплаты на стороне платежной системы. Для таких перенаправлений могут использоваться варианты с отдельной HTML-страницей (в текущей или новой вкладке браузера) и с объектом iframe в HTML-странице. Конкретный вариант настраивается специалистами технической поддержки Rocketpay с учетом предпочтений мерчанта.
  • Варианты оформления формы. Для Payment Page можно использовать как типовое оформление от Rocketpay, так и индивидуальное — в соответствии с предпочтениями мерчанта. Во втором случае менять вид формы можно очень существенно: в плане визуальных элементов (логотипов и иконок), шрифтовых гарнитур, текстовых элементов на разных языках. Но за верстку в любом случае отвечает Rocketpay, поэтому для реализации индивидуального оформления следует согласовать возможности с курирующим менеджером, предоставить макет и принять результат.
  • Языковые настройки формы. В интерфейсе Payment Page поддерживаются различные языки, и при вызове формы можно указывать необходимый или использовать решение по умолчанию, при котором в соответствии с IP-адресом пользователя выбирается английский (для всех стран кроме России) либо русский (для России).

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

За счет настройки таких составляющих можно гармонично встраивать Payment Page практически в любой веб-сервис, подчеркивая его специфику и характер.