# Общая информация {#ru_PP_general .concept}

статья с вводной информацией о платёжной форме Payment Page, общей схемой её использования и обзором её возможностей

**На уровень выше:**[Payment Page](ru_PP_about.md)

## Введение {#ru_pp_general_introduction}

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

![](images/ru_functional_pp.svg)

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

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

![](images/ecommpay/ru_pp_general_1.svg "Payment Page в объекте iframe HTML-страницы")

![](images/ecommpay/ru_pp_general_2.svg "Payment Page в модальном окне поверх HTML-страницы")

![](images/ecommpay/ru_pp_general_3.svg "Payment Page в виде отдельной HTML-страницы, в текущей или новой вкладке браузера")

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

## Схема работы {#ru_pp_general_interaction}

При работе с Payment Page все взаимодействия с платёжной платформой — со стороны пользовательского устройства и серверной части веб-сервиса — выполняются с использованием протоколов HTTP версии не ниже 1.1 и TLS версии не ниже 1.2, а в качестве пользовательского браузера могут использоваться актуальные версии таких браузеров, как Google Chrome, Safari, Opera, Mozilla Firefox, Microsoft Edge, QQ Browser, Mi Browser, Samsung Internet, 360 Secure Browser и ряда других. Подробную информацию о работе Payment Page в разных средах можно получить у специалистов технической поддержки Ecommpay \([support@ecommpay.com](mailto:support@ecommpay.com)\).

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

![](images/ru_paymentpage_functional.svg "Схема взаимодействия")

В общем случае работа с 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 можно существенно влиять на то, с чем и как сталкивается пользователь. Чтобы конфигурировать работу с платёжной формой под потребности конкретного проекта, можно использовать описанные далее возможности и совместно со специалистами технической поддержки Ecommpay настраивать оптимальные сценарии.

Базовый пользовательский сценарий можно представить следующим образом:

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

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

    ![](images/ecommpay/ru_pp_general_4.svg)

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

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

    ![](images/ecommpay/ru_pp_general_5.svg)

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

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

    ![](images/ecommpay/ru_pp_general_6.svg)


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

-   Подключаемая JavaScript-библиотека. Она подключается к клиентской части веб‑сервиса и поддерживает разные способы вызова платёжной формы \(при выполнении шага 4\)и обработку событий в пользовательском интерфейсе, в том числе для работы со встроенными в интерфейс веб-сервиса кнопками для „быстрых“ платежей с использованием методов Apple Pay и Google Pay.
-   Наборы средств разработки \(SDK\) для веб-сервисов, разработанных на разных языках программирования. Они встраиваются в серверную часть веб-сервиса и позволяют формировать подпись \(при выполнении шага 3\) и обрабатывать оповещения \(передаваемые на шаге 11\).
-   Наборы средств разработки для мобильных приложений, работающих на платформах Android и iOS. Они встраиваются в клиентскую часть приложения и позволяют работать с платёжной формой, адаптированной под мобильные интерфейсы \(с поддержкой шагов 2 и 4 и без необходимости использования браузера на шагах 6–13\).
-   Подключаемые модули для сайтов на базе ряда распространённыхCMS. Они подключаются в административной панели CMS и обеспечивают все необходимые действия как в клиентской, так и в серверной части сайта, без необходимости программирования со стороны мерчанта.

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

## Возможности {#ru_pp_general_capabilities}

### Поддержка разных целевых действий {#section_jzp_qby_mlb .section}

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

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

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

### Поддержка разных способов указания данных {#section_uf5_gwn_nlb .section}

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

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

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

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

-   *Через ввод на форме.* В этом случае пользователь обязательно заполняет на форме все требуемые поля.

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

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

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

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

Помимо этих способов, при которых с платёжной формой взаимодействует пользователь, Payment Page может использоваться *для проведения платежей MO/TO*, при которых *с формой работает сотрудник мерчанта*, принимающий заказ пользователя. Тип такого заказа \(Mail Order или Telephone Order\) указывается при вызове Payment Page и учитывается в сценарии взаимодействия с формой.

### Поддержка дополнительных функций {#section_bh5_hwn_nlb .section}

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

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

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

### Выполнение вспомогательных процедур {#section_v1n_3wn_nlb .section}

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

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

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

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

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

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

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

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

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

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

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


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

### Поддержка разных вариантов отображения итоговой информации {#section_ytj_jwn_nlb .section}

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

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

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

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

### Контроль работы с формой и результатов целевых действий {#section_sdd_kwn_nlb .section}

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

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

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

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

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

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

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

### Поддержка разных вариантов оформления платёжной формы {#section_odv_kwn_nlb .section}

В дополнение к различным функциональным возможностям при работе с 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, так и индивидуальное — в соответствии с предпочтениями мерчанта. Для настройки индивидуального оформления можно использовать соответствующий [конструктор](ru_PP__design_customisation.md#), а с вопросами и предложениями, выходящими за рамки возможностей конструктора, можно обращаться к курирующему менеджеру.
-   *Языковые настройки формы.* В интерфейсе Payment Page поддерживаются различные языки, и при вызове формы можно указывать необходимый или использовать решение по умолчанию, при котором платёжная страница отображается на языке, определённом автоматически \(по языку браузера или по умолчанию\), и пользователю отображается выпадающий список с возможностью изменять этот язык.

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

## Интерфейс {#ru_pp_emulator}

Для предварительного знакомства с пользовательским интерфейсом Payment Page можно использовать демонстрационную версию [на сайте Ecommpay](https://ecommpay.com/core-functionalities/integrations/hosted-payment-page/). Эта версия позволяет эмулировать базовый сценарий разовой оплаты с использованием различных платёжных методов и способов открытия платёжной формы актуального 5-го поколения.

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

|Эмулятор позволяет воспроизводить возможные сценарии работы условного веб-сервиса, Payment Page и сторонних сервисов \(таких, как Access Control Servers\) при выполнении разных целевых действий с применением платёжных карт. При этом можно выбирать и сопоставлять различные сценарии.

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

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

 **Прим.:**

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

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

||