# Сбор данных о пользователях {#ru_PP_Gathering_customer_data .concept}

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

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

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

-   обеспечивать дополнительный уровень безопасности за счёт сбора и проверки сведений о пользователях;
-   улучшать пользовательские сценарии за счёт избежания процедуры дополнения информации о платеже \(когда при проведении платежа со стороны платёжныхпровайдеров, системили банков запрашиваются дополнительные данные, [подробнее](ru_pp_clarification.md)\).

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

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

## Пользовательские сценарии {#section_wks_zfs_jsb .section}

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

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

-   `1` — поле отображается с предварительно заполненным значением, указанным в запросе, и пользователь может изменить это значение;
-   `2` — поле отображается без значения, но с его названием;
-   `3` — поле не отображается, значение параметра может быть передано в платёжную платформу только через запрос.

![](images/ecommpay/ru_pp_gathering_customer_data.svg "Варианты отображения дополнительных полей")

Выбор варианта отображения осуществляется следующим образом.

|Обязательность указания данных|+|+|+|+|–|–|–|–|
|Обязательность отображения поля|+|+|–|–|+|+|–|–|
|Передача значения в запросе|+|–|+|–|+|–|+|–|
|**Вариант отображения поля**|**`1`**|**`2`**|**`3`**|**`2`**|**`1`**|**`2`**|**`3`**|**`3`**|

Для сбора дополнительных данных в сторонних сервисах, таких как сервисы Apple Pay и Google Pay, используются интерфейсы этих сервисов. С учётом их специфики при запросе данных от пользователей могут использоваться, например, ранее сохранённые пользователями сведения и другие особенности взаимодействия. При этом запрошенные сведения во всех случаях являются обязательными к заполнению, а для запроса сведений могут использоваться как свойства проекта, так и параметры отдельных запросов. Так, в каких-то случаях можно настроить сбор адресов электронной почты пользователей во всех случаях через свойства проекта и сбор других сведений только при необходимости, через параметры запросов \(подробнее — в статьях о работе с методами [Apple Pay](pm_applepay.md#) и [Google Pay](pm_googlepay.md#)\). Собранные таким образом данные могут передаваться к веб-сервису мерчанта в оповещениях о результатах платежей. Для этого необходимо обратиться в службу технической поддержки Ecommpay.

## Подключение {#section_ts1_3sf_gdb .section}

Чтобы подключить возможность сбора дополнительных данных о пользователях, со стороны мерчанта необходимо:

1.  Определить, для каких проектови каких платёжных методов по этим проектам актуально собирать дополнительные данные. И для каждого такого случая определить набор запрашиваемых данных и свойства соответствующих полей. В состав данных могут включаться различные параметры \(подробнее — [далее](ru_PP_Gathering_customer_data.md#section_jdb_1qx_tdb)\), а к свойствам каждого из требуемых полей относятся:
    -   Обязательность заполнения и отображения.
    -   Способ указания: через ввод с клавиатуры или через выбор из выпадающего списка.

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

    -   Название: по умолчанию используются типовые названия, предоставляемые Ecommpay, но можно задать и индивидуальные.

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

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

## Запрашиваемые данные {#section_jdb_1qx_tdb .section}

Для сбора данных о пользователях могут использоваться следующие параметры.

|Параметр|Описание|
|--------|--------|
|customer\_address  
 string

|Название улицы и номер дома \(с обозначением корпуса или строения, где это актуально\) в адресе проживания пользователя, с использованием разделительной запятой.  
 Представляет собой строку длиной не более 255 символов.  
 Пример: `улица Дукшту, 30`

|
|customer\_birthplace  
 string

|Место рождения пользователя.  
 Представляет собой строку длиной не более 255 символов.  
 Пример: `Рига`

|
|customer\_city  
 string

|Название города проживания пользователя.  
 Представляет собой строку длиной не более 255 символов.  
 Пример: `Вильнюс`

|
|customer\_country  
 string

|Код страны проживания пользователя в формате ISO 3166-1 alpha-2.  
 Пример: `LT`

|
|customer\_day\_of\_birth  
 string

|Дата рождения пользователя в формате `ДД-ММ-ГГГГ`.  
 Пример: `17-04-1989`

|
|customer\_email  
 string

|Адрес электронной почты пользователя.  
 Представляет собой строку длиной не более 255 символов, состоящую из двух частей: имени пользователя и доменного имени, разделённых символом «@».  
 Пример: `sonya@example.com`

|
|customer\_first\_name  
 string

|Имя пользователя.  
 Представляет собой строку не более 255 символов.  
 Пример: `Софья`

|
|customer\_last\_name  
 string

|Фамилия пользователя.  
 Представляет собой строку не более 255 символов.  
 Пример: `Ковалевская`

|
|customer\_middle\_name  
 string

|Отчество пользователя.  
 Представляет собой строку не более 255 символов.  
 Пример: `Васильевна`

|
|customer\_phone  
 string

|Полный номер телефона пользователя, с кодом страны.  
 Должен содержать не менее 4 и не более 24 цифр, при этом, если такое допускается в рамках используемого проекта и платёжного метода, в записи номера могут использоваться знаки пунктуации и специальные символы \(подобные случаи, как правило, оговариваются отдельно\).  
 Пример: `44997654321`

|
|customer\_ssn  
 integer

|Последние 4 цифры номера социального страхования налогоплательщика в США.  
 Пример: `1312`

|
|customer\_state  
 string

|Название региона \(штата\) адреса проживания пользователя.  
 Представляет собой строку длиной не более 255 символов.  
 Пример: `Вильнюсский уезд`

|
|customer\_zip  
 string

|Почтовый индекс адреса проживания пользователя.  
 Представляет собой строку длиной не более 10 символов.  
 Пример: `LT-071171`

|
|billing\_address  
 string

|Название улицы расчётного адреса пользователя.  
 Представляет собой строку длиной не более 255 символов.  
 Пример: `Дукшту`

|
|billing\_city  
 string

|Название города расчётного адреса пользователя.  
 Представляет собой строку  длиной не более 255 символов.  
 Пример: `Вильнюс`

|
|billing\_country  
 string

|Код страны расчётного адреса пользователя в формате ISO 3166-1 alpha-2.  
 Пример: `LT`

|
|billing\_postal  
 string

|Почтовый индекс расчётного адреса пользователя.  
 Представляет собой строку длиной не более 16 символов.  
 Пример: `LT-071171`

|
|billing\_region  
 string

|Название региона расчётного адреса пользователя.  
 Представляет собой строку длиной не более 255 символов.  
 Пример: `Вильнюсский уезд`

|
|billing\_region\_code  
 string

|Код региона расчётного адреса пользователя в формате ISO 3166-2.  
 Пример: `VL`

|

Использование дополнительных параметров, не представленных в таблице, можно согласовывать со специалистами Ecommpay.

**На уровень выше:**[Вспомогательные процедуры и дополнительные возможности](ru_PP_Additional.md)