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

Поддержка разных целевых действий

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

• Проведение оплат. Это наиболее распространённый вариант использования платёжной формы — с проведением оплат в одну стадию, при которых в рамках одного сеанса работы Payment Page осуществляется разовый перевод денежных средств от пользователя к мерчанту, например за совершаемую покупку.
• Блокировка средств. При таком варианте использования в рамках сеанса работы Payment Page осуществляется блокировка денежных средств на счёте пользователя, и мерчант получает возможность уже в дальнейшем (через Gate или Dashboard либо автоматически по истечении заданного периода) списать нужную сумму или вернуть деньги пользователю. Это может быть актуально, например, при бронировании номера в отеле или аренде автомобиля.
• Регистрация повторяемых списаний. При выстраивании долгосрочных отношений с пользователями могут быть удобны неоднократные списания средств без указания платёжных реквизитов или вовсе без пользовательского участия (например, при платежах по подписке). В платёжной платформе для этого поддерживаются повторяемые оплаты, и с помощью 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 может использоваться для проведения платежей MO/TO, при которых с формой работает сотрудник мерчанта, принимающий заказ пользователя. Тип такого заказа (Mail Order или Telephone Order) указывается при вызове Payment Page и учитывается в сценарии взаимодействия с формой.

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

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

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

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

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

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

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

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

• Аутентификация 3‑D Secure. Эта аутентификация (Three-Domain Secure) применяется при работе с платёжными картами для защиты от мошенничества.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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