# Начало работы

Добро пожаловать в документацию платформы НПЦК. Здесь вы найдёте всё необходимое для успешной интеграции — от первого запроса до production.

{% hint style="info" %}
**Оперативные уведомления** — плановые работы и обновления API публикуются в Telegram: [t.me/npckconnect](https://t.me/npckconnect)
{% endhint %}

### Сервисы платформы

<table data-view="cards"><thead><tr><th>Title</th><th data-card-target data-type="content-ref">Target</th></tr></thead><tbody><tr><td>🔐 FinID / ЦОИД</td><td><a href="/pages/w4FDlX1gIPbxPHrCEwvS">/pages/w4FDlX1gIPbxPHrCEwvS</a></td></tr><tr><td>✍️ Облачная ЭЦП</td><td><a href="/pages/TYW0Zxm048bKbalASDeP">/pages/TYW0Zxm048bKbalASDeP</a></td></tr><tr><td>💳 Платежи (МСМП)</td><td><a href="/pages/isK9xWVzWsEOvDgSuoOz">/pages/isK9xWVzWsEOvDgSuoOz</a></td></tr><tr><td>🏦 Open API (пилот)</td><td><a href="/pages/alTcvJWOJeft3Lp2krrS">/pages/alTcvJWOJeft3Lp2krrS</a></td></tr><tr><td>✍️Сервис управления согласиями (СУС)</td><td><a href="/pages/5WX8NA3JncNA0kjJYW0o">/pages/5WX8NA3JncNA0kjJYW0o</a></td></tr></tbody></table>

### Быстрый старт

### Сервисы ЦОИД

{% tabs %}
{% tab title="🧪 Тестовая среда" %}
{% stepper %}
{% step %}
**Шаг 1 - Предоставление данных ЮЛ/ФЛ**

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

Направьте письмо на соответствующий адрес:

| Проект                                           | Email          |
| ------------------------------------------------ | -------------- |
| ЦОИД, Облачная ЭЦП и агрегация счетов (Open API) | <coid@npck.kz> |

В письме укажите для каждого сотрудника:

1. Фотографию (формат как на удостоверение личности)
2. ФИО
3. ИИН
4. Номер телефона
5. БИН и наименование организации
6. Кто будет выступать руководителем на тестовом стенде
7. Систему, к которой планируете подключиться (ЦОИД, Open Banking/Open API)

{% hint style="warning" %}
В тестовой среде регистрация **первого руководителя организации не требуется** - руководителем может быть любой уполномоченный сотрудник.
{% endhint %}
{% endstep %}

{% step %}
**Шаг 2 - Регистрация и авторизация в Портале НПК**

Портал НПК (тестовая среда): [cabinet.stage.npck.kz](https://cabinet.stage.npck.kz)

Регистрацию выполняет сотрудник, назначенный руководителем на тесте:

1. Заполните форму авторизации и нажмите **Войти**
2. На форме подтверждения ИИН убедитесь, что введён корректный ИИН, и нажмите **Продолжить**
3. При положительном ответе от ГБД ФЛ проводится биометрическая верификация физического лица с использованием цифрового сканирования лица

{% hint style="warning" %}
Перед прохождением биометрической верификации убедитесь, что лицо полностью в кадре, взгляд направлен в камеру, глаза открыты, фон однородный, освещение равномерное без теней. При превышении количества неуспешных попыток система временно блокирует пользователя.
{% endhint %}

4. Введите одноразовый SMS-код

{% hint style="info" %}
На тестовом стенде SMS не отправляется - вводите код **`0000`**. Если код не пришёл - нажмите **Отправить код повторно**.
{% endhint %}

5. Введите **БИН** организации
6. Нажмите **Разрешить**

{% hint style="success" %}
Регистрация завершена! Руководителю открывается Личный кабинет участника.
{% endhint %}
{% endstep %}

{% step %}
**Шаг 3 - Добавление сотрудников**

**Сотрудники → Добавить сотрудника**:

1. Введите ИИН, ФИО и должность сотрудника
2. Выберите доступы по роли:
   * Менеджеры / аналитики - все функции
   * Технические специалисты - «Управление услугами» и «Управление заявками»
3. При необходимости - установите галочку «Право подписания юридических документов»
4. Нажмите **Добавить**

{% hint style="info" %}
Можно загрузить список сотрудников в формате CSV. Шаблон: [employees\_example.csv](https://cabinet.stage.npck.kz/assets/documents/employees_example.csv)
{% endhint %}
{% endstep %}

{% step %}
**Шаг 4 - Подача заявки на подключение к сервису**

{% tabs %}
{% tab title="🔐 FinID / ЦОИД и ✍️ Облачная ЭЦП" %}

1. Перейдите в раздел **Подключиться к ЦОИД**
2. Нажмите **Подать заявку**
3. Выберите тип сервиса
4. Прикрепите необходимые документы (перечень - в правилах функционирования ЦОИД на [npck.kz](https://npck.kz))
5. Нажмите **Отправить**

Статусы заявки: `черновик` → `в работе` → `одобрена` / `отказ`

{% hint style="info" %}
Если заявка отклонена - причина указана в деталях. Подайте новую заявку с исправлениями.
{% endhint %}
{% endtab %}

{% tab title="🏦 Open API" %}

1. Перейдите в раздел **Подключиться к Open Banking**
2. Нажмите **Подать заявку**
3. Выберите роль:
   * **Поставщик API** - для обмена информацией по счетам
   * **Пользователь API (чтение и запись)** - для агрегации счетов
4. Прикрепите документы (для тестовой среды достаточно лицензии на проведение банковских операций)
5. Нажмите **Отправить**

Статусы заявки: `черновик` → `в работе` → `одобрена` / `отказ`
{% endtab %}
{% endtabs %}
{% endstep %}

{% step %}
**Шаг 5 - Регистрация приложения**

После одобрения заявки: **Услуги → Мои приложения → Добавить приложение**

* **Название** - наименование приложения
* **Redirect URL** - адрес для перенаправления после аутентификации (можно несколько)
* **Логотип** - PNG, 100×100 px (необязательно)

Нажмите **Сохранить**. Система сгенерирует `client_id` и `client_secret`.

{% hint style="danger" %}
`client_secret` - строго конфиденциально. Сохраните сразу - повторно просмотреть нельзя. При необходимости можно сгенерировать новый через **Сгенерировать новый client secret**.
{% endhint %}
{% endstep %}

{% step %}
**Шаг 6 - Настройка и тестирование API**

{% hint style="info" %}
Сервис сопоставления фотоизображений (IDEC/Photomatch) подключается отдельно от остальных сервисов ЦОИД - не через Портал НПК (cabinet.npck.kz), а через собственный контур регистрации Удостоверяющего центра. См. вкладку **«📷 Сопоставление фотоизображений»**.
{% endhint %}

{% tabs %}
{% tab title="🔐 FinID / ЦОИД" %}
**Реализуйте на своей стороне:**

1. Получение URL для перенаправления клиента - `POST /v1/auth/generate-user-url`
2. Перенаправление клиента на полученный URL через SafariWebView (iOS) или WebView (Android)
3. Перехват редиректа с кодом авторизации `code` на `redirectUri`
4. Обмен `code` на `access_token` - `POST /oauth2/token`
5. Проверка и анализ токена - `POST /oauth2/introspect`

{% hint style="warning" %}
**iOS:** только `SafariWebView`, `WKWebView` не поддерживается. Редирект перехватывать через deeplink.

**Android WebView:** если не отображается изображение с камеры при прохождении биометрической верификации:

```kotlin
webView.settings.allowContentAccess = true
webView.settings.mediaPlaybackRequiresUserGesture = false
webView.settings.domStorageEnabled = true
```

{% endhint %}

{% hint style="info" %}
На тестовом стенде SMS не отправляется - клиент вводит код **`0000`**.

Срок жизни URL - **15 минут**, кода авторизации - **300 секунд** (одноразовый).

Срок жизни `access_token` - **12 часов** для FinID scopes.
{% endhint %}

→ Спецификация: [auth-openapi.npck.kz](https://auth-openapi.npck.kz/#tag/Auth/operation/generateUserUrl)

→ Клиентский сценарий: [Описание клиентского пути FinID](https://docs.npck.kz/servisy-coid/servis-autentifikacii-lichnosti-klienta-finid/opisanie-klientskogo-puti)
{% endtab %}

{% tab title="✍️ Облачная ЭЦП" %}
**Реализуйте на своей стороне:**

1. Загрузите документы для подписания через API Esign до начала сессии
2. Получите URL для перенаправления клиента со scope `esign` (физлица) или `organization_esign` (юрлица)
3. Перенаправьте клиента через SafariWebView / WebView
4. Перехватите редирект с `code` и обменяйте на `access_token`
5. Получите подписанные документы

{% hint style="info" %}
Срок жизни `access_token` для scope `esign` / `organization_esign` - **5 минут**.

Если у клиента нет облачной ЭЦП - система предложит выпустить её прямо в flow. ЭЦП выпускается на **1 год**.

На тестовом стенде SMS - код **`0000`**.
{% endhint %}

{% hint style="warning" %}
Пароль от ЭЦП не хранится в системах ЦОИД - только его хэш в HSM. Клиент может сбросить пароль через «Не помню пароль» - при этом выпускается новая ЭЦП.
{% endhint %}

→ Спецификация: [esign-openapi.npck.kz](https://esign-openapi.npck.kz)

→ Клиентский сценарий: [Описание клиентского пути Esign](/servisy-coid/servis-upravleniya-oblachnoi-ecp-esign/opisanie-klientskogo-puti)
{% endtab %}

{% tab title="🏦 Open API" %}
**1. Настройка API (для Поставщика API)**

**Услуги → Мои API → Настройки API:**

* Введите URL-адрес, по которому будут доступны ваши API
* Заполните основную информацию о поставщике
* Нажмите **Перейти к публикации API**

{% hint style="warning" %}
Токен доступа (JWT) действует **1 год**. Хранить только на серверной стороне.
{% endhint %}

**2. Публикация API**

В разделе **Мои API** выберите нужный API из списка и нажмите **Активировать услугу**.

**3. Запуск автотестов**

После публикации API нажмите **Запустить проверку** рядом с нужным API.

Система запустит автоматические тесты и отобразит результат. Если выявлены ошибки - они будут показаны с описанием, исправьте согласно технической документации и запустите проверку повторно.

{% hint style="success" %}
Кнопка **Опубликовать** становится доступна только после успешного прохождения всех проверок.
{% endhint %}

**4. Тестирование (для Пользователя API)**

Реализуйте на своей стороне полный OAuth2 flow:

1. `POST /v1/auth/generate-user-url` со scopes `accounts`, `account_balance`, `account_transactions`
2. Перенаправление клиента → аутентификация (подтверждение ИИН + биометрическая верификация + SMS-код `0000`) → согласие
3. Получение `code` → обмен на `access_token` (срок жизни **30 дней**)
4. Запрос данных счетов: `GET /accounts`, `GET /accounts/{id}/balance`, `GET /accounts/{id}/transactions`

{% hint style="info" %}
API v2 устарел - используйте **API v3**.
{% endhint %}

→ Спецификация: [accounts-openapi.npck.kz](https://accounts-openapi.npck.kz)

→ [Рекомендации для Пользователя API](https://docs.npck.kz/open-banking/poluchenie-informacii-o-bankovskikh-schetakh-klienta-pilotnyi-proekt/rekomendacii-po-realizacii-integracii-dlya-polzovatelya-api)

→ [Рекомендации для Поставщика API](https://docs.npck.kz/open-banking/poluchenie-informacii-o-bankovskikh-schetakh-klienta-pilotnyi-proekt/rekomendacii-po-realizacii-integracii-dlya-postavshika-api)
{% endtab %}
{% endtabs %}
{% endstep %}
{% endstepper %}
{% endtab %}

{% tab title="🚀 Промышленная среда" %}
{% hint style="info" %}
Переходите в промышленную среду только после успешного тестирования и подписания протокола с АО «НПК».
{% endhint %}

{% stepper %}
{% step %}
**Шаг 1 - Регистрация и авторизация в Портале НПК**

Портал НПК (промышленная среда): [cabinet.npck.kz](https://cabinet.npck.kz)

В промышленной среде **предоставление данных сотрудников заранее не требуется** - верификация через ГБД ФЛ и ГБД ЮЛ автоматическая.

Регистрацию выполняет **первый руководитель** организации:

1. Откройте форму авторизации и нажмите **Войти**
2. Введите ИИН и нажмите **Продолжить**
3. Пройдите биометрическую верификацию
4. Введите SMS-код (отправляется реально на телефон)
5. Введите **БИН** организации
6. Нажмите **Разрешить**

{% hint style="success" %}
Регистрация завершена!
{% endhint %}
{% endstep %}

{% step %}
**Шаг 2 - Добавление сотрудников**

**Сотрудники → Добавить сотрудника** - те же шаги, что и в тестовой среде.

{% hint style="warning" %}
В промышленной среде один сотрудник может быть добавлен в личный кабинет только **одного** участника.
{% endhint %}
{% endstep %}

{% step %}
**Шаг 3 - Подача заявки на подключение**

{% tabs %}
{% tab title="🔐 FinID / ЦОИД и ✍️ Облачная ЭЦП" %}

1. **Подключиться к ЦОИД** → **Подать заявку**
2. Выберите тип сервиса, прикрепите документы, нажмите **Отправить**

{% hint style="warning" %}
`client_id` и `client_secret` в промышленной среде **отличаются** от тестовых.
{% endhint %}
{% endtab %}

{% tab title="🏦 Open API" %}

1. **Подключиться к Open Banking** → **Подать заявку**
2. Выберите роль, прикрепите документы, нажмите **Отправить**

{% hint style="warning" %}
`client_id` и `client_secret` в промышленной среде **отличаются** от тестовых.
{% endhint %}
{% endtab %}
{% endtabs %}
{% endstep %}

{% step %}
**Шаг 4 - Регистрация приложения**

**Услуги → Мои приложения → Добавить приложение**

* **Название**, **Redirect URL** (production-домен), **Логотип** (необязательно)
* Нажмите **Сохранить** → получите промышленные `client_id` и `client_secret`

{% hint style="danger" %}
`client_secret` отображается только один раз. Сохраните сразу.
{% endhint %}
{% endstep %}

{% step %}
**Шаг 5 - Настройка подключения и публикация API**

{% tabs %}
{% tab title="🔐 FinID / ЦОИД и ✍️ Облачная ЭЦП" %}
Клиентский сценарий идентичен тестовому - SMS отправляется реально.

1. Выполните smoke-тест с промышленными `client_id` / `client_secret`
2. Проверьте логирование и мониторинг на своей стороне

{% hint style="warning" %}
**Альтернативный путь обслуживания**

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

В случае неуспешной верификации запрос может быть передан разработчику биометрического решения на дополнительный анализ. До получения результатов анализа рекомендуется обслуживать клиента альтернативным методом в соответствии с внутренними процедурами Участника.
{% endhint %}

→ [Результаты биометрической аутентификации](https://docs.npck.kz/servisy-coid/rezultaty-biometricheskoi-autentifikacii)

→ [Матрица полномочий (для юрлиц, Esign)](https://docs.npck.kz/servisy-coid/servis-upravleniya-oblachnoi-ecp-esign/dlya-podpisaniya-dokumentov-yuridicheskimi-licami/matrica-polnomochii)
{% endtab %}

{% tab title="🏦 Open API" %}
**1. Настройка и публикация API**

**Услуги → Мои API → Настройки API** → укажите production endpoint → **Перейти к публикации API**.

Подайте заявку на публикацию - требуется **подписанный протокол тестирования**. Срок рассмотрения - **3 рабочих дня**.

**2. Smoke-тест**

Выполните smoke-тест с промышленными ключами, проверьте логирование и мониторинг.

→ [Статус API участников](https://docs.npck.kz/open-banking/poluchenie-informacii-o-bankovskikh-schetakh-klienta-pilotnyi-proekt/servis-polucheniya-statusa-api-uchastnikov)
{% endtab %}
{% endtabs %}
{% endstep %}
{% endstepper %}
{% endtab %}
{% endtabs %}

***

### Сервис сопоставления фотоизображений

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

{% hint style="warning" %}
Аутентификацию могут пройти люди, у которых имеется как минимум один из следующих документов:

* удостоверение личности гражданина РК
* паспорт гражданина РК
* вид на жительство иностранца в РК
* удостоверение лица без гражданства (казахстанского образца)
  {% endhint %}

{% hint style="info" %}
Для использования сервиса Участник должен:

1. Пройти процедуру регистрации на Портале АО «НПК» (см. [Регистрация и авторизация в Портале НПК](https://docs.npck.kz/rabota-s-testovym-okruzheniem-is-npk/rabota-s-testovym-portalom-npk/registraciya-i-avtorizaciya-v-portale-npk))
2. Подать заявку на подключение к ЦОИД (см. 5.1 Подключение к ЦОИД)
3. Зарегистрировать приложение Участника (см. [Пользователям API (добавление и использование приложения)](https://docs.npck.kz/rabota-s-testovym-okruzheniem-is-npk/rabota-s-testovymi-servisami/polzovatelyam-api-dobavlenie-i-ispolzovanie-prilozheniya))
   {% endhint %}

***

{% tabs %}
{% tab title="🧪 Тестовая среда" %}
{% stepper %}
{% step %}
**Шаг 1 - Получение криптографических ключей**

Перейдите на портал УЦ: [betacms.npck.kz/info](https://betacms.npck.kz/info), скачайте [шаблон заявки](https://betacms.npck.kz/downloads/res-open/primer.zip) и направьте заполненную заявку согласно инструкции на портале.

→ Подробнее: [Выпуск ключей ГОСТ 2015](https://docs.npck.kz/servisy-coid/servis-sopostavleniya-fotoizobrazhenii/vypusk-klyuchei-gost-2015)

{% hint style="info" %}
По вопросам получения ключей: [**supportca@npck.kz**](mailto:supportca@npck.kz) или **+7 (727) 250-66-75**
{% endhint %}
{% endstep %}

{% step %}
**Шаг 2 - Выполните первый запрос**

Авторизация по схеме Basic Auth:

```
Authorization: Basic <Base64(ClientID:ClientSecret)>
```

{% tabs %}
{% tab title="Синхронный метод" %}
Используется для моментальной верификации личности с заранее определённым типом согласия. Согласие **собирается Участником** перед началом процедуры идентификации и **подписывается ЭЦП организации** (JWS, алгоритм ГОСТ 34.10-2012/2015).

→ Подробнее о формировании подписи: [Формирование ЭЦП JWS](https://docs.npck.kz/servisy-coid/servis-sopostavleniya-fotoizobrazhenii/formirovanie-ecp-jws)

```bash
curl -X POST https://api.stage.npck.kz/v2/identity/sync/verify \
  -H "Authorization: Basic <base64(ClientID:ClientSecret)>" \
  -H "Content-Type: application/json" \
  -H "x-jws-signature: <jws-signature>" \
  -d '{
    "iin": "123456789012",
    "photo": "<base64_фото_клиента>",
    "vendor": "VISIONLABS",
    "consentType": "BIOMETRY",
    "serviceCode": "ACCOUNT_OPEN",
    "dataScope": ["iin"],
    "consentTypes": ["CT_01"],
    "consentGivenAt": "2019-08-24T14:15:22Z",
    "consentExpiresAt": "2019-08-24T14:15:22Z",
    "dataRetentionPeriod": 1
  }'
```

В ответ возвращается результат сопоставления в процентах (%).

**Получение электронного документа по результатам:**

```bash
curl -X GET https://api.stage.npck.kz/v1/identity/report/{verificationId}/download \
  -H "Authorization: Basic <base64(ClientID:ClientSecret)>"
```

→ Спецификация: [identity-openapi.npck.kz](https://identity-openapi.npck.kz/#tag/Identity/operation/syncVerifyV2)
{% endtab %}

{% tab title="Асинхронный метод" %}
Используется для запуска процесса верификации, который требует подтверждения от физического лица посредством **SMS с номера 1414**. Номер телефона берётся из базы мобильных граждан (БМГ).

{% hint style="info" %}
В тестовой среде SMS не отправляется - согласие имитируется через Telegram-бот [@NPCK\_TestControl\_bot](https://t.me/NPCK_TestControl_bot): нажмите **/start**, введите ИИН.
{% endhint %}

```bash
curl -X POST https://api.stage.npck.kz/v1/identity/async/verify \
  -H "Authorization: Basic <base64(ClientID:ClientSecret)>" \
  -H "Content-Type: application/json" \
  -H "x-jws-signature: " \
  -d '{
    "iin": "123456789012",
    "photo": "<base64_фото_клиента>",
    "vendor": "VISIONLABS"
  }'
```

{% hint style="danger" %}
Если клиент отклонил согласие - сопоставление не производится. Участник получает соответствующий статус в ответе.
{% endhint %}

→ Спецификация: [identity-openapi.npck.kz](https://identity-openapi.npck.kz/#tag/Identity/operation/asyncVerify)
{% endtab %}
{% endtabs %}
{% endstep %}
{% endstepper %}
{% endtab %}

{% tab title="🚀 Промышленная среда" %}
{% hint style="info" %}
Переходите в промышленную среду только после успешного тестирования.
{% endhint %}

{% stepper %}
{% step %}
**Шаг 1 - Заключение договора**

Заключите «Договор с Участником (сопоставление фотоизображений)».

Шаблон: [npck.kz - Типовые договора](https://npck.kz/tipovye-dogovory-coid/) - вкладка «Типовые договора» - «Договор с Участником (сопоставление фотоизображений)»

{% hint style="success" %}
Регистрация участника в ИС ЦОИД произойдёт **автоматически** после заключения договора.
{% endhint %}

По вопросам заключения договора: [**coid@npck.kz**](mailto:coid@npck.kz) или **+7 (727) 297-91-44**
{% endstep %}

{% step %}
**Шаг 2 - Получение криптографических ключей**

Заполните Приложение №1 к Заявлению/Соглашению к Договору о предоставлении услуг УЦ и направьте в Удостоверяющий центр.

Портал УЦ: [cms.npck.kz/auth](https://cms.npck.kz/auth)

{% hint style="warning" %}
Первичные ключи действуют **14 дней** и требуют ежегодного переоформления.
{% endhint %}

По вопросам: [**supportca@npck.kz**](mailto:supportca@npck.kz) или **+7 (727) 250-66-75**
{% endstep %}

{% step %}
**Шаг 3 - Настройка сетевого доступа. &#x20;**<mark style="color:$danger;">**При необходимости**</mark>**.**&#x20;

Доступ к промышленной среде осуществляется через выделенный канал **IP VPN** или **IPSec**.

Сканированный вариант заполненного шаблона необходимо направить на [**info@npck.kz**](mailto:info@npck.kz):

* IP VPN - [шаблон письма](https://npck.kz/wp-content/uploads/2025/06/shablon-dlya-podcluc-kanala-ip-vpn-rus-1.docx)
* IPSec - [шаблон письма](https://npck.kz/wp-content/uploads/2025/06/shablon-ipsec-rus-1.docx)
  {% endstep %}

{% step %}
**Шаг 4 - Выполните первый запрос**

Используйте те же методы, что и в тестовой среде, с промышленными ключами:

* **Sync V2:** `https://api.npck.kz/v2/identity/sync/verify`
* **Async V1:** `https://api.npck.kz/v1/identity/async/verify`

{% hint style="success" %}
Интеграция завершена! По вопросам: [**coid@npck.kz**](mailto:coid@npck.kz) или **+7 (727) 297-91-44**
{% endhint %}
{% endstep %}
{% endstepper %}
{% endtab %}
{% endtabs %}

### Спецификации

| Сервис                      | Ссылка                                                                     |
| --------------------------- | -------------------------------------------------------------------------- |
| Auth (FinID, OAuth2, Esign) | [auth-openapi.npck.kz](https://auth-openapi.npck.kz/)                      |
| Esign                       | [esign-openapi.npck.kz](https://esign-openapi.npck.kz/)                    |
| Open Banking ID             | [obid-openapi.npck.kz](https://obid-openapi.npck.kz/)                      |
| Accounts                    | [accounts-openapi.npck.kz](https://accounts-openapi.npck.kz/)              |
| Identity                    | [identity-openapi.npck.kz](https://identity-openapi.npck.kz/#tag/Identity) |


# Технические требования к клиентским устройствам

## Требования к клиентским устройствам

В качестве клиентского устройства могут использоваться:&#x20;

* компьютеры (персональные компьютеры, ноутбуки и т.п.)
* мобильные устройства (смартфоны, планшеты и т.п.)

> Для мобильных устройств поддерживаются следующие операционные системы:
>
> * Android версии 8 и выше&#x20;
> * IOS версии 16.5 и выше

{% hint style="warning" %}
*Для проведения биометрической верификации личности на клиентском устройстве должна быть работающая камера, доступ к камере должен быть разрешен*
{% endhint %}

## Поддерживаемые браузеры

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

> * Chrome
> * Firefox
> * Safari
> * Microsoft Edge

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

> * в IOS - Safari, Chrome
> * в Android - Chrome

{% hint style="warning" %}
В IOS необходимо использовать SafariWebView. WKWebView не поддерживается.
{% endhint %}

{% hint style="warning" %}
Если в ОС Android при проведении liveness-сессии не отображается изображение клиента (см. пример на рисунке ниже), то потенциальным решением проблемы может являться применение следующих параметров:

*webView\.settings.allowContentAccess = true; webView\.settings.mediaPlaybackRequiresUserGesture = false; webView\.settings.domStorageEnabled = true*

WebKit в Android, позволяет видео компонентам запускаться только по действию пользователя, при этом для корректной работы сервисов ЦОИД камера запускается программными средствами (autoplay), WebKit блокирует данное действие и выдает ошибку. Чтобы избежать этого, необходимо в компоненте webView указать данную настройку.
{% endhint %}

<figure><img src="/files/oLiWIMREOpKd8CbybRhA" alt="" width="143"><figcaption><p>Пример отсутствия доступа к контенту для WebView</p></figcaption></figure>


# 1. Портал НПК

**Портал НПК** — это информационная система, предназначенная для централизованного взаимодействия участников с АО «НПК».

Портал позволяет:

* подавать заявки на подключение к сервисам НПК
* подключать услуги
* добавлять сотрудников
* назначать сотрудникам роли и права доступа
* просматривать информацию по биллингу ЦОИД.

Через Портал НПК осуществляется работа с основными разделами, необходимыми для подключения и дальнейшего использования сервисов НПК, включая ЦОИД, Open Banking и МСМП.

### Среды Портала НПК

Работа с Порталом НПК доступна в двух средах:

| Среда              | Назначение                                                                                                                                                            | Адрес                           |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------- |
| Тестовая среда     | Используется для предварительного ознакомления, тестирования процессов подключения, подачи заявок и проверки работы сервисов до перехода в промышленную эксплуатацию. | <https://cabinet.stage.npck.kz> |
| Промышленная среда | Используется для работы с действующими сервисами НПК в рамках промышленной эксплуатации.                                                                              | <https://cabinet.npck.kz>       |


# 2. Предоставление данных ЮЛ/ФЛ для тестовой среды

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

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

* <Support-OAPI@npck.kz> — по проектам, связанным с платежами и переводами;
* <coid@npck.kz> — по проектам ЦОИД и агрегации счетов.

{% hint style="warning" %} <mark style="color:red;">**Для работы на тестовом стенде регистрация первого руководителя организации не требуется.**</mark>**&#x20;В качестве руководителя в тестовой среде может быть указан любой уполномоченный сотрудник организации.**&#x20;
{% endhint %}

> 1. Фотографии сотрудников (в формате <как на удостоверение>)
> 2. ФИО сотрудников
> 3. ИИН сотрудников
> 4. Номер телефона сотрудников
> 5. БИН и наименование организации
> 6. Отметка кто из сотрудников будет выступать в качестве руководителя организации на тестовом стенде: должен будет зарегистрировать организацию и добавить остальных сотрудников
> 7. Система, к которой планирует подключиться сотрудник (Open Banking/Open API, ЦОИД)

{% hint style="warning" %} <mark style="color:green;">**В промышленной среде предоставление информации пользователей не требуется, т.к. верификация сотрудников производится на основании данных из ГБД ФЛ, ГБД ЮЛ.**</mark>

Первый руководитель проходит процедуру [регистрации и авторизации](/registraciya-i-avtorizaciya/3.-registraciya-i-avtorizaciya-v-portale-npk) и [добавляет своих сотрудников в Портал НПК](/registraciya-i-avtorizaciya/4.-dobavlenie-novykh-sotrudnikov) для делегирования работ в Портале НПК.
{% endhint %}


# 3. Регистрация и авторизация в Портале НПК

{% hint style="info" %}
Если Вы авторизуетесь на **тестовом** Портале НПК убедитесь, что сведения по Вам были предоставлены согласно разделу [2. Предоставление данных ЮЛ/ФЛ для тестовой среды](/registraciya-i-avtorizaciya/2.-predostavlenie-dannykh-yul-fl-dlya-testovoi-sredy)
{% endhint %}

Для доступа к личному кабинету в Портале НПК Участник должен зарегистрироваться в Портале НПК.&#x20;

Регистрация Участника производится физическим лицом, который является первым руководителем организации.

Последовательность действий для регистрации и авторизации Участника едины и включают в себя следующие действия:

1. Первый руководитель юридического лица заполняет форму авторизации и нажимает кнопку *<Войти>*.

<figure><img src="/files/VU2jyghcupFAdgr4lUA6" alt=""><figcaption><p>Форма авторизации</p></figcaption></figure>

2\.    На форме подтверждения ИИН необходимо убедиться, что введен корректный ИИН, после чего нажать кнопку *<Продолжить>.*

<figure><img src="/files/WhF7pFAKvvelwda7gpXk" alt=""><figcaption><p>Форма подтверждения ИИН</p></figcaption></figure>

3. Если по введенному ИИН получен положительный ответ от ГБД ФЛ, то проводится биометрическая верификация физического лица с использованием цифрового сканирования лица. Необходимо следовать инструкциям, которые будут показаны на экране.

{% hint style="warning" %}
При прохождении биометрической верификации необходимо убедиться в хорошем освещений и следовать следующим рекомендациям:

* лицо полностью должно быть в кадре и помещаться в овал;
* смотреть прямо в камеру;
* яркость/контраст должны быть умеренными;
* глаза должны быть открыты и видны, а волосы не должны закрывать лицо;
* лицо - строго анфас «портретный стиль»;
* фон однородный, светлый свет при съемке равномерный, без теней на лице.
  {% endhint %}

{% hint style="danger" %}
В случае, если пользователь осуществляет множественные неуспешные попытки пройти регистрацию, то Система блокирует пользователя и отображает сообщение с указанием времени блокировки.
{% endhint %}

<figure><img src="/files/tGbjHcmuL8uACHf1D7mj" alt=""><figcaption><p>Сообщение о блокировке</p></figcaption></figure>

4. После успешного прохождения биометрической верификации на указанный номер телефона отправляется СМС с одноразовым кодом. Необходимо ввести полученный код в форму ввода кода.

<figure><img src="/files/teWq6kt815dLStfxMzbL" alt=""><figcaption><p>Форма ввода одноразового кода</p></figcaption></figure>

{% hint style="warning" %}
**На тестовом стенде отправка СМС не производится, необходимо ввести код «**<mark style="color:red;">**0000**</mark>**»**
{% endhint %}

{% hint style="danger" %}
Если СМС с кодом не получено, то необходимо нажать кнопку <*Отправить код повторно*> для повторной отправки кода
{% endhint %}

<figure><img src="/files/7kd14rADx99KjFaqgESy" alt=""><figcaption><p>Форма ввода одноразового кода с кнопкой &#x3C;Отправить код повторно></p></figcaption></figure>

5. После положительного завершения проверки личности пользователю отображается форма для ввода БИН организации.

<figure><img src="/files/9J5RTrgPxUJVEFfHf6aA" alt=""><figcaption><p>Форма ввода БИН организации</p></figcaption></figure>

6. После ввода БИН отобразится окно для разрешения передачи данных.&#x20;

<figure><img src="/files/skrvYt9N1VLZ4RQttGvr" alt=""><figcaption><p>Форма разрешения доступа</p></figcaption></figure>

7. Для того чтобы продолжить регистрацию необходимо нажать на кнопку <Разрешить>.

Если нажать кнопку <*Запретить*>, процесс прекращается.

{% hint style="success" %}
Регистрация завершена!&#x20;

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

·       добавления пользователей в список сотрудников организации, чтобы они получили доступ к личному кабинету Участника. Описание см в [4. Добавление новых сотрудников](/registraciya-i-avtorizaciya/4.-dobavlenie-novykh-sotrudnikov);

·       подачи заявки на подключение к другим ИС НПК;

·       и другое.
{% endhint %}


# 4. Добавление новых сотрудников

<figure><img src="/files/RQ5IcIu7xwJYKyy8ylf8" alt=""><figcaption></figcaption></figure>

Раздел <Сотрудники> предназначен для управления сотрудниками, которым будет доступна работа в личном кабинете Участника в Портале НПК.

Необходимо добавить сотрудников в список  сотрудников организации, чтобы они получили доступ к личному кабинету Участника и могли в нем работать.

<figure><img src="/files/PFdcw9nITJtZ60WOOT8h" alt=""><figcaption></figcaption></figure>

## Главная страница раздела <Сотрудники> содержит:

* &#x20;*список пользователей, которым доступен вход в личный кабинет Участника.*

ФИО пользователя отображается после того, как он в первый раз авторизуется в личном кабинете, т.к. он должен дать согласие на получение его данных из ГБД ФЛ.

* &#x20;*кнопку <Добавить сотрудника> – при нажатии на которую открывается форма для добавления пользователей в список сотрудников Участника.*

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

> 1\) Нажать на кнопку <Добавить сотрудника> - откроется форма добавления сотрудников

<figure><img src="/files/hbKbTchNlHYPRbLEoSjp" alt=""><figcaption></figcaption></figure>

> 2\) Ввести ИИН сотрудника.
>
> 3\) Ввести ФИО ИО сотрудника.
>
> 4\) Ввести должность сотрудника.
>
> 5\) Выбрать доступы в зависимости от их роли в проекте. Для менеджеров или аналитиков проектов допустимо выбрать все функции. Для технических специалистов достаточно выбора "Управление услугами" и "Управление заявками на подключение к сервисам".
>
> 6\) Можно установить галочку в поле для наделения сотрудника правом подписания юридических документов. При отсутствии галочки право подписи не предоставляется
>
> <p align="center"><img src="/files/mh42cfudh1UVMB7PJsCr" alt="" data-size="original"></p>
>
> 7\) Можно добавить нескольких сотрудников. Для этого нужно нажать кнопку <Добавить еще сотрудника>. \
> Можно загрузить списком сотрудников по формату который можно скачать по ссылке <https://cabinet.stage.npck.kz/assets/documents/employees_example.csv>
>
> 8\) Нажать кнопку <Добавить> – введенные данные сохраняются и добавленные ИИН отображаются в списке сотрудников Участника, им предоставляется доступ в личный кабинет Участника.
>
> Пользователь может иметь доступ только в личный кабинет одного Участника, т.е. нельзя добавить один и тот же ИИН в качестве сотрудника нескольких Участников.

* *кнопки <Закрыть доступ> – при нажатии на которые блокируется доступ в личный кабинет для соответствующего пользователя.*

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

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


# 5. Подача заявки на подключение к сервисам


# 5.1 Подключение к ЦОИД

Доступно после регистрации на Портале НПК

Раздел "Подключиться к ЦОИД"предназначен для подачи заявки на подключение к сервисам ЦОИД и просмотра статуса поданной заявки.

<figure><img src="/files/HwGOZwfdaQjGfZMLBZQW" alt=""><figcaption></figcaption></figure>

Главная страница раздела "Подключиться к ЦОИД" содержит:

1. Список заявок – при нажатии на заявку открывается форма просмотра данных заявки.&#x20;

> Заявки могут быть в статусе:
>
> * <mark style="color:orange;">черновик</mark> – заявка не была подана, доступно ее редактирование и отправка;
> * <mark style="color:orange;">в работе</mark> – заявка находится на рассмотрении в АО "НПК";
> * <mark style="color:orange;">одобрена</mark> – заявка успешно  одобрена;
> * <mark style="color:orange;">отказ</mark> – заявка отклонена, причина отказа указывается в данных заявки. Необходимо подать новую заявку, внеся необходимые корректировки.

2. Кнопку <*Подать заявку*> - при нажатии на которую открывается форма подачи заявки.

{% hint style="success" %}
Если была подана и успешно одобрена заявка на  подключение к ЦОИД, то кнопка <Подать заявку> не отображается.
{% endhint %}

<details>

<summary>Подача заявки на подключение к ЦОИД</summary>

Для того, чтобы подать заявку необходимо выполнить следующие действия:

1. Нажать на кнопку <*Подать заявку*> или выбрать заявку в статусе «*черновик*», откроется форма подачи заявки.
2. Выбрать тип сервиса
3. Прикрепить необходимые документы, нажав кнопку <Нажмите или перетащите сюда> или перенося файлы в выделенную область на форме. Перечень документов приведен в правилах функционирования ЦОИД, опубликованных на сайте <https://npck.kz/>
4. Завершив заполнение формы, нажать кнопку <*Отправить*>.

После отправки заявка отображается в списке заявок участника с указанием ее текущего статуса. Если не нажать кнопку <*Отправить*>, то заявка сохраняется в статусе «*черновик*»..

</details>


# 5.2 Подключение к Open Banking/Open API

Доступно после регистрации на Портале НПК

<details>

<summary>Подключение к Open API (МСМП)</summary>

Для подключения к Open API пользователю, [авторизованному в Портале НПК](/registraciya-i-avtorizaciya/1.-portal-npk) необходимо перейти в раздел <Подключиться к Open Banking>

<figure><img src="/files/CIaZM3PTzz3jOAL8HFio" alt=""><figcaption><p>Главная страница Портала НПК</p></figcaption></figure>

Раздел <Подключиться к Open Banking> предназначен для подачи заявки на подключение к Open API и просмотра статуса поданной заявки.

<figure><img src="/files/JTb41C5s2N04Lh7NcDmk" alt=""><figcaption><p>Страница для подачи заявки на подключение к Open Banking</p></figcaption></figure>

Главная страница раздела <Подключиться к Open Banking> содержит:

* Список заявок – при нажатии на заявку открывается форма просмотра данных заявки.

> Заявки могут быть в статусе:
>
> * <mark style="color:orange;">черновик</mark> – заявка не была подана, доступно ее редактирование и отправка;
> * <mark style="color:orange;">в работе</mark> – заявка находится на рассмотрении в АО <НПК<;
> * <mark style="color:orange;">одобрена</mark> – заявка успешно одобрена;
> * <mark style="color:orange;">отказ</mark> – заявка отклонена, причина отказа указывается в данных заявки. Необходимо подать новую заявку, внеся необходимые корректировки.

* Кнопку <Подать заявку> - при нажатии на которую открывается форма подачи заявки.

Если заявки были поданы и успешно одобрены по всем доступным ролям, то кнопка <Подать заявку> не отображается.&#x20;

Для того, чтобы подать заявку необходимо выполнить следующие действия:

1\.      Нажать на кнопку <Подать заявку> или выбрать заявку в статусе <черновик>, откроется форма подачи заявки.

<figure><img src="/files/5tIF7lGbM7uE7YglPRFv" alt=""><figcaption></figcaption></figure>

2\.      Выбрать роль для участия.

Выберите ***роль <Поставщик API>*** для подключения к сервисам по переводам и платежам и/или обмену информацией по банковским счетам.

3\.      Прикрепить необходимые документы, нажав кнопку <Нажмите или перетащите сюда> или перенося файлы в выделенную область на форме. *Для тестовой среды достаточно прикрепить лицензию на проведение банковских операций.*

После отправки, заявка отображается в списке заявок Участника с указанием ее текущего статуса.&#x20;

Если не нажать кнопку <Отправить>, то заявка сохраняется в статусе <черновик>. После отправки заявки ожидайте подтверждения Оператором.

</details>

<details>

<summary>Подключение к Open Banking</summary>

Для подключения к Open API пользователю, [авторизованному в Портале НПК](/registraciya-i-avtorizaciya/1.-portal-npk) необходимо перейти в раздел <Подключиться к Open Banking>

<figure><img src="/files/CIaZM3PTzz3jOAL8HFio" alt=""><figcaption><p>Главная страница Портала НПК</p></figcaption></figure>

Раздел <Подключиться к Open Banking> предназначен для подачи заявки на подключение к Open API и просмотра статуса поданной заявки.

<figure><img src="/files/JTb41C5s2N04Lh7NcDmk" alt=""><figcaption><p>Страница для подачи заявки на подключение к Open Banking</p></figcaption></figure>

Главная страница раздела <Подключиться к Open Banking> содержит:

* Список заявок – при нажатии на заявку открывается форма просмотра данных заявки.

> Заявки могут быть в статусе:
>
> * <mark style="color:orange;">черновик</mark> – заявка не была подана, доступно ее редактирование и отправка;
> * <mark style="color:orange;">в работе</mark> – заявка находится на рассмотрении в АО <НПК<;
> * <mark style="color:orange;">одобрена</mark> – заявка успешно одобрена;
> * <mark style="color:orange;">отказ</mark> – заявка отклонена, причина отказа указывается в данных заявки. Необходимо подать новую заявку, внеся необходимые корректировки.

* Кнопку <Подать заявку> - при нажатии на которую открывается форма подачи заявки.

Если заявки были поданы и успешно одобрены по всем доступным ролям, то кнопка <Подать заявку> не отображается.&#x20;

Для того, чтобы подать заявку необходимо выполнить следующие действия:

1\.      Нажать на кнопку <Подать заявку> или выбрать заявку в статусе <черновик>, откроется форма подачи заявки.

<figure><img src="/files/SxA2CRK8ICNln0RThpKV" alt=""><figcaption><p>Форма подачи заявки</p></figcaption></figure>

2\.      Выбрать роль для участия.

Выберите ***роль <Пользователь API (чтение и запись)>*** для подключения к сервисам по переводам (M2M) и обмену информацией по банковским счетам.

3\.      Прикрепить необходимые документы, нажав кнопку <Нажмите или перетащите сюда> или перенося файлы в выделенную область на форме. *Для тестовой среды достаточно прикрепить лицензию на проведение банковских операций.*

После отправки, заявка отображается в списке заявок Участника с указанием ее текущего статуса.&#x20;

Если не нажать кнопку <Отправить>, то заявка сохраняется в статусе <черновик>. После отправки заявки ожидайте подтверждения Оператором.

</details>


# 6. Добавление и использование приложения

Доступно после регистрации на Портале НПК

{% hint style="info" %}
Доступ к данному разделу доступ после подключения к [Open Banking/Open API](/registraciya-i-avtorizaciya/5.-podacha-zayavki-na-podklyuchenie-k-servisam/5.2-podklyuchenie-k-open-banking-open-api) или [ЦОИД](/registraciya-i-avtorizaciya/5.-podacha-zayavki-na-podklyuchenie-k-servisam/5.1-podklyuchenie-k-coid)
{% endhint %}

<details>

<summary>Добавление приложения</summary>

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

<img src="/files/YzDaYoyyO7FxdrDejpfO" alt="Главная страница Портала НПК" data-size="original">

Для добавления приложения авторизованному пользователю, подключившемуся к Open Banking необходимо с главного рабочего окна перейти в раздел <Услуги>,

<img src="/files/M6aXbpLOCmrP18u5nTX4" alt="Раздел &#x22;Услуги&#x22;" data-size="original">

затем во вкладку <Мои приложения> и выполнить следующие действия:

Нажать на кнопку <Добавить приложение>.

<img src="/files/mjYrTagiF7S5PIcrLwOj" alt="Форма добавления приложения" data-size="original">

Заполнить форму регистрации приложения, содержащие данные:

* кнопка <Логотип> – при нажатии на которую открывается окно для выбора файла с изображением логотипа для приложения. Формата изображения должен быть png, размером 100\*100 px.
* поле <Название> – для ввода наименования приложения.
* поле \<Client ID> – уникальный идентификатор приложения, генерируется автоматически, недоступно для редактирования.
* поле \<Client secret> – пароль для приложения (строго конфиденциальная информация), генерируется автоматически, недоступно для редактирования. Связка Client ID и Client secert представляют собой специальные учетные данные (credentials), которые используется для подключения к сервисам API.
* кнопка <Сгенерировать новый client secret> – при нажатии на которую производится генерация нового значения в поле \<Client secret>.
* поле \<Redirect URL> – для ввода URL-адреса, на который осуществляется перенаправление в процессе аутентификации клиента. Допускается использование нескольких Redirect URL, для добавления еще одного нужно нажать кнопку <Добавить Redirect URL> – при нажатии на которую добавляется еще одно поле \<Redirect URL>.
* кнопка <Сохранить> – при нажатии на которую выполняется сохранение введенных данных и регистрация приложения на Платформе.

Заполнив форму регистрации приложения, нажать кнопку <Сохранить>. После сохранения данных приложение отображается в списке во кладку <Мои приложения>.

**После успешной регистрации для приложения генерируются учетные данные (client id и client secret).** Поэтому регистрация приложения необходима для реализации сценариев, в которых вызываются API, в которых авторизация производится по client id и client secret.

В частности, на данном этапе реализации проекта регистрация приложения необходима для сценария **перевода денег между собственными счетами клиента - M2M2** (перевод денег клиентом со своего счета в одном БВУ на свой же счет в другой БВУ).

</details>

<details>

<summary>Работа с добавленным приложением</summary>

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

Во вкладке <Мои приложения> выбрать необходимое приложение.

Откроется форма с данными приложения.

<img src="/files/XdL7WhEIFvbFaBYKaQ9P" alt="Просмотр данных приложения" data-size="original">

При необходимости, можно отредактировать данные приложения и нажать кнопку <Сохранить> или деактивировать нажав кнопку <Деактивировать приложение>.&#x20;

При нажатии на <Деактировать> откроется форма подтверждения деактивации приложения, на которой нажать кнопку <Деактивировать>. Приложение будет деактивировано.

Если приложение деактивировано, то выполнять информационный обмен, используя его учетные данные (client id, client secret) будет невозможно.

</details>


# 1. Настройка подключения к Межбанковской системе мобильных платежей

Доступно для участников, зарегистрированных на Портале НПК и подключенных к Open Banking/Open API

{% hint style="info" %}
Подключение к Межбанковской системе переводов и платежей состоит из следующих шагов

1. [Подача заявки на получение ключей в Удостоверяющем центре НПК](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei/1.1-podacha-zayavki-na-poluchenie-klyuchei-v-uc-npk).
2. [Проведение работ по полученному ключу](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei/1.2-provedenie-rabot-po-poluchennomu-klyuchu).
3. [Передача информации в НПК](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei/1.4-dobavlenie-korrespondentskogo-scheta).
   {% endhint %}


# 1.1 Подача заявки на получение ключей в УЦ НПК

Подача заявки на получение ключей в Удостоверяющем центре НПК

Для выпуска ключей необходимо заполнить шаблон заявки с OID'ом для <Межбанковской системы платежей и переводов> (приложен ниже). После заполнения необходимо отправить текст с заявкой на <supportca@npck.kz>

Ключи будут отправлены архивом на указанную в заявке почту.

{% hint style="danger" %}
Обязательно необходимо выбирать в заявке **"Межбанковская система платежей и переводов".**
{% endhint %}

<figure><img src="/files/ozDfa9n2NYHgIx20QopY" alt=""><figcaption></figcaption></figure>

{% file src="/files/t1nSgsCxxMzJ6BLwRMKY" %}
Шаблон заявки для выпуска тестовых ЭЦП
{% endfile %}


# 1.2 Проведение работ по полученному ключу

Для работы с личным кабинетом УЦ необходимо установить Тумар Конфигуратор с поддержкой ГОСТ 2015, который доступен по адресу [https://betacms.npck.kz](https://betacms.npck.kz/) в разделе:

<Инфо> → <Программное обеспечение, документация, примеры разработчикам> → \<Tumar CSP для пользователя> (или по прямой ссылке: <https://betacms.npck.kz/downloads/res-open/client/TumarCSP.zip>).

{% hint style="danger" %}
Важно:

Вы получите КЛЮЧИ ПЕРВИЧНОЙ ИНИЦИАЛИЗАЦИИ СРОКОМ ДЕЙСТВИЯ 14 ДНЕЙ.

ВАМ НЕОБХОДИМО ВЫПУСТИТЬ ДЕЙСТВУЮЩИЕ КЛЮЧИ И СЕРТИФИКАТЫ СРОКОМ ДЕЙСТВИЯ 1 ГОД.

Ключи первичной инициализации можно использовать только один раз.

После выпуска действующих ключей сроком действия 1 год, ключи первичной инициализации невозможно использовать повторно.
{% endhint %}

Инструкция по выпуску действующих ключей расположена по адресу <https://betacms.npck.kz/downloads/res-open/manuals/manual.pdf>.

**Адрес тестового кабинета УЦ НПК:** [**https://betacms.npck.kz/auth**](https://betacms.npck.kz/auth)

**Адрес промышленного кабинета УЦ НПК:** [**https://ca.kisc.kz/auth**](https://ca.kisc.kz/auth)

Вместе с ключами первичной информации вы получаете документ readme\_beta1.txt, который содержит важную информацию для дальнейшей работы с ключом.

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

По всем дополнительным вопросам касательно получения ключей и работы с ними можно обращаться по номерам телефонов: (727) 297-91-38, 297-91-39


# 1.3 Настройка API

Доступно после подключения к Open Banking/Open API или ЦОИД

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

<figure><img src="/files/lorVoSIwYUp78nb7Xqlq" alt=""><figcaption><p>Главная страница Портала НПК</p></figcaption></figure>

Для настройки API авторизованному пользователю, подключившемуся к Open Banking необходимо перейти в раздел <Услуги>, во вкладку <Мои API>, кнопка <Настройки API>.

<figure><img src="/files/Zurer2fsktWudGSNpg3u" alt=""><figcaption><p>Мои API</p></figcaption></figure>

Для того, чтобы заполнить информацию об API необходимо заполнить данные:

<figure><img src="/files/7A2qDcAtYJQrtmJw1nlt" alt=""><figcaption><p>Данные для песочницы</p></figcaption></figure>

{% hint style="info" %}
Срок действия токена — **1 год.**
{% endhint %}

Ввести URL-адрес, по которому будут доступны публикуемые API.

<figure><img src="/files/DKGTTuG0YMC0DXjlbVx9" alt=""><figcaption><p>Основная информация о поставщике</p></figcaption></figure>

Затем заполнить основную информацию о поставщике, после чего необходимо нажать на кнопку <Перейти к публикации API>.

{% hint style="info" %}
Для взаимодействия с Межбанковской системой мобильных платежей необходимо при настройке API импортировать публичную часть ключа  (как получить - см подраздел[ ](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei/1.2-provedenie-rabot-po-poluchennomu-klyuchu)[1.2 Проведение работ по полученному ключу](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei/1.2-provedenie-rabot-po-poluchennomu-klyuchu)).
{% endhint %}

В данной вкладке отображается токен доступа, который используется для доступа к служебным сервисам Open API.

Если необходимо перегенерировать токен доступа (JWT), то необходимо нажать кнопку <Сгенерировать новый токен> - новый токен будет сохранен автоматический (без необходимости нажатия кнопки <Сохранить>)

{% hint style="warning" %}
**Токен доступа (JWT) должен сохраняться в тайне и не передаваться в публичный доступ, должен храниться на серверной стороне приложения, и вся обработка, связанная с ним, должна производиться на серверной стороне приложения.**
{% endhint %}


# 1.4 Добавление корреспондентского счета

Для добавления банку – участнику возможности работы с сервисами платежей и Переводов нужно перейти во вкладку <Платежи и переводы> в разделе <Услуги>.

<figure><img src="/files/7MTqyFvz747nWqr13fcK" alt=""><figcaption></figcaption></figure>

> Требуется заполнить номер корреспондентского счета (для выписок) и нажать на кнопку <Сохранить>.

{% hint style="info" %}
Тестовый стенд опубликован в сети Интернет
{% endhint %}


# 1.5 Реализация API

Для интеграции с другими Участниками посредством Open API необходимо реализовать соответствующие API по переводам / платежам. Спецификация методов по переводам / платежам описана по ссылке <https://transfers-openapi.npck.kz/>, описание процессов приведено в разделе[Межбанковская система мобильных платежей (МСМП)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp).


# 1.6 Публикация API

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

Участники разрабатывают свои API (согласно опубликованных технических спецификации) и публикуют их на Платформе для взаимодействия с другими Участниками.&#x20;

{% hint style="info" %}
Тестовый стенд опубликован в сети Интернет. Перед публикацией API необходимо предоставить в АО <НПК> URL-адрес API, чтобы к нему был организован доступ.
{% endhint %}

После публикации API становится доступным для вызова другим Участникам. При этом, Платформа обеспечивает маршрутизацию запросов между Участниками.

Для публикации API необходимо перейти в раздел <Услуги> и во вкладке Услуги выбрать сервисы, которые были реализованы и планируется опубликовать (см. список [услуг](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei/1.6-publikaciya-api/dostupnye-k-podklyucheniyu-api))  и нажать на кнопку <Активировать услугу>.

### Сервисы по переводам и платежам

<figure><img src="/files/GOig30HANkcuEnoASfTt" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
После нажатия на кнопку <Активировать услугу> в *сервисах, **которые относятся к переводам и платежам*** *статус услуги будет изменён на <в процессе интеграции> и требует обработки Оператора. Требуется обратиться к Оператору и ожидать результата обработки.*
{% endhint %}


# Доступные к подключению API

Список и описание доступных к подключению API сервисов в личном кабинете Участника:

* **Переводы**

<details>

<summary>Получение/отправка переводов (C2C2)</summary>

*Процесс перевода денег C2C2 предназначен для инициализации перевода денег от клиента (Отправитель денег) из одного БВУ (Банк отправителя денег) другому физическому лицу (Бенефициар) в другой БВУ (Банк бенефициара).*

*Перевод инициируется в приложении Банка отправителя денег.*

*Перевод денег осуществляется со счета Отправителя денег в Банке отправителя денег на счет Бенефициара в Банке бенефициара.*

&#x20;

**Услуга «Отправка переводов (C2C2)»** – участник готов к инициализации перевода денег между физическими лицами, т.е. будет выступать в роли Банка отправителя денег в данном процессе (подробнее см. в [Инициализация перевода денег другому ФЛ (C2C2)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-perevodov-deneg/inicializaciya-perevoda-deneg-drugomu-fl-c2c2)).

&#x20;

**Услуга «Получение переводов (C2C2)»** – участник готов к приему переводов денег между физическими лицами, т.е. будет выступать в роли Банка бенефициара в данном процессе (подробнее см. в [Инициализация перевода денег другому ФЛ (C2C2)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-perevodov-deneg/inicializaciya-perevoda-deneg-drugomu-fl-c2c2)).

</details>

<details>

<summary>Получение/отправка переводов (M2M2) между своими счетами</summary>

*Процесс перевода денег M2M2 предназначен для инициализации перевода денег клиентом (Отправитель денег) со своего счета в одном БВУ (Банк отправителя денег) на свой же счет в другой БВУ (Банк бенефициара, т.е. банк, обслуживающий счет клиента, на который переводятся деньги).*&#x20;

&#x20;

**Услуга «Отправка переводов (M2M2)»** – участник готов к инициализации перевода денег между собственными счетами клиента в разных банках, т.е. будет выступать в роли Банка отправителя денег в данном процессе (подробнее см. [Инициализация перевода денег между своими счетами (M2M2)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-perevodov-deneg/inicializaciya-perevoda-deneg-mezhdu-svoimi-schetami-m2m2).

&#x20;

**Услуга «Получение переводов (M2M2)»** – участник готов к приему переводов денег между собственными счетами клиента в разных банках, т.е. будет выступать в роли Банка бенефициара в данном процессе (подробнее см. [Инициализация перевода денег между своими счетами (M2M2)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-perevodov-deneg/inicializaciya-perevoda-deneg-mezhdu-svoimi-schetami-m2m2).

</details>

<details>

<summary>Получение/отправка возвратов переводов (C2CR)</summary>

*Процесс возврата перевода C2CR предназначен для инициализации возврата денег по ранее полученному переводу.*

*Инициатором возврата перевода выступает его получатель, и тем самым он выступает в качестве отправителя денег в рамках данного процесса.*

*Бенефициаром является клиент, которому возвращаются деньги (т.е. изначальный отправитель перевода).*

&#x20;

**Услуга «Отправка возвратов переводов (C2CR)»** – участник готов к инициализации возврата перевода денег, т.е. будет выступать в роли Банка отправителя денег в данном процессе (подробнее см. [Возврат полученного перевода (C2CR)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-perevodov-deneg/vozvrat-poluchennogo-perevoda-c2cr).

&#x20;

**Услуга «Получение возвратов переводов (C2CR)»** – участник готов к приему возвратов переводов, т.е. будет выступать в роли Банка бенефициара в данном процессе (подробнее см. [Возврат полученного перевода (C2CR)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-perevodov-deneg/vozvrat-poluchennogo-perevoda-c2cr).

</details>

* **Платежи**

<details>

<summary>Получение/отправка платежей (C2B2)</summary>

*Процесс осуществления платежей C2B2 предназначен для инициализации проведения оплаты за товар/услугу посредством сканирования QR-кода в POS-терминале или посредством статического QR-кода.*

*В рамках данного сценария клиенту предоставляется возможность QR-оплаты из приложения одного банка (Банка отправителя денег) через POS-терминал или статический QR-код другого банка (Банка бенефициара).*

&#x20;

**Услуга «Отправка платежей (C2B2)»** – участник готов к инициализации осуществления платежа, т.е. будет выступать в роли Банка отправителя денег в данном процессе (подробнее см. [Инициализация оплаты по QR-коду (C2B2\_V2)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-provedeniya-platezhei-po-qr-kodu-v-ramkakh-celevoi-modeli/inicializaciya-oplaty-po-qr-kodu-c2b2_v2)).

&#x20;

**Услуга «Получение платежей (C2B2)»** – участник готов к приему платежа, т.е. будет выступать в роли Банка бенефициара в данном процессе (подробнее см. [Инициализация оплаты по QR-коду (C2B2\_V2)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-provedeniya-platezhei-po-qr-kodu-v-ramkakh-celevoi-modeli/inicializaciya-oplaty-po-qr-kodu-c2b2_v2)).

</details>

<details>

<summary>Получение/отправка платежей в рамках электронной коммерции (C2B2E)</summary>

*Процесс осуществления платежей C2B2E предназначен для инициализации проведения оплаты за товар/услугу посредством сканирования QR-кода в рамках электронной коммерции.*

&#x20;

**Услуга «Отправка платежей в рамках электронной коммерции (C2B2E)»** – участник готов к инициализации осуществления платежа в рамках электронной коммерции, т.е. будет выступать в роли Банка отправителя денег в данном процессе (подробнее см. [Инициализация оплаты в рамках электронной коммерции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-oplaty-v-ramkakh-elektronnoi-kommercii/inicializaciya-oplaty-v-ramkakh-elektronnoi-kommercii)).

&#x20;

**Услуга «Получение платежей в рамках электронной коммерции (C2B2E)»** – участник готов к приему платежа в рамках электронной коммерции, т.е. будет выступать в роли Банка бенефициара в данном процессе (подробнее см. [Инициализация оплаты в рамках электронной коммерции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-oplaty-v-ramkakh-elektronnoi-kommercii/inicializaciya-oplaty-v-ramkakh-elektronnoi-kommercii)).

</details>

<details>

<summary>Получение/отправка возвратов платежей (C2BR)</summary>

*Процесс возвратов платежей C2BR предназначен для инициализации возврата денег по проведенной ранее оплате за товар/услугу.*

*Поставщик/продавец (т.е. изначальный получатель денег за товар/услугу) выступает в качестве отправителя денег в рамках данного сценария.*

*Бенефициаром является клиент, которому возвращаются деньги (т.е. изначальный плательщик).*

&#x20;

**Услуга «Отправка возвратов платежей (C2BR)»** – участник готов к инициализации возврата денег в рамках ранее совершенного платежа, т.е. будет выступать в роли Банка отправителя денег в данном процессе (подробнее см. [Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-provedeniya-platezhei-po-qr-kodu-v-ramkakh-adaptacionnoi-modeli/vozvrat-deneg-po-provedennoi-ranee-oplate-za-tovar-uslugu-c2br)).

&#x20;

**Услуга «Получение возвратов платежей (C2BR)»** – участник готов к приему возврата денег в рамках ранее совершенного платежа, т.е. будет выступать в роли Банка бенефициара в данном процессе  (подробнее см. [Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-provedeniya-platezhei-po-qr-kodu-v-ramkakh-adaptacionnoi-modeli/vozvrat-deneg-po-provedennoi-ranee-oplate-za-tovar-uslugu-c2br)).

</details>

* **Обмен информацией о банковских счетах клиента**

<details>

<summary>Получение/предоставление списка счетов</summary>

**Услуга «Предоставление списка счетов»** – для активации, необходимо реализовать и успешно опубликовать API по предоставлению списка счетов клиента.

**Услуга «**&#x41F;олучение списка счето&#x432;**»** – при активированной услуге, участнику доступно подключение к опубликованным API по предоставлению списка счетов клиента.

</details>

<details>

<summary>Получение/предоставление информации о балансе счета</summary>

**Услуга «**&#x41F;редоставление информации о балансе счет&#x430;**»** – для активации, необходимо реализовать и успешно опубликовать API по предоставлению информации о балансе счета.

**Услуга «**&#x41F;олучение информации о балансе счет&#x430;**»** – при активированной услуге, участнику доступно подключение к опубликованным API по предоставлению информации о балансе счета.

</details>

<details>

<summary>Получение/предоставление списка транзакций счета</summary>

**Услуга «Предоставление списка транзакций счета»** – для активации, необходимо реализовать и успешно опубликовать API по предоставлению списка транзакций счета.

**Услуга «Получение списка транзакций счета»** – при активированной услуге, участнику доступно подключение к опубликованным API по предоставлению списка транзакций счета.

</details>

* **Верификация личности клиента**

<details>

<summary>Идентификация без данных</summary>

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

</details>

<details>

<summary>Идентификация с данными</summary>

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

</details>

* **Облачная ЭЦП**

<details>

<summary>Подписание облачной ЭЦП</summary>

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

</details>


# 1.7 Эмуляторы банков для платежей и переводов

Используется только для Подсистемы платежей и переводов Open API

Участник может протестировать реализацию API по платежам и переводам используя эмуляторы банков. Эмуляторы банков позволяют:&#x20;

* моделировать поведение отправляющей стороны при переводе/платеже;
* моделировать поведение стороны, получающей деньги при переводе/платеже;
* моделировать возвраты переводов/платежей.

{% hint style="warning" %}
Для работы с сервисами по платежам необходимо передать в АО НПК URL для QR-платежей (будет 2 URL для тестового сервиса и промышленного сервиса соответственно) по примерному шаблону:

[https://links.bankname.kz/](https://links.bvuname.kz/).
{% endhint %}

{% hint style="success" %}
Доступно два эмулятора банков:&#x20;

* <https://mock-bank-1.stage.npck.kz&#x20>;
* <https://mock-bank-2.stage.npck.kz>

Функциональность у них идентична (каждый может как отправлять платежи/переводы, так и получать)
{% endhint %}

## Моделирование действий Клиента (физического лица)

Для входа в качестве Клиента (физического лица) необходимо на форме входа во вкладке <**Пользователь**> указать любой номер телефона (кроме указанных в [#dannye-dlya-modelirovaniya-oshibok](#dannye-dlya-modelirovaniya-oshibok "mention")) и нажать кнопку <*Вход*>.

<figure><img src="/files/VZHQKRL3Vh7uA4nZYfDY" alt=""><figcaption></figcaption></figure>

ФИО клиента генерируется автоматически. Есть возможность отправить перевод, произвести платежи, выполнить возвраты, просмотреть список транзакций по данному клиенту.

В списке транзакции отображается подробная информация по каждой проведенной транзакции (исходящей и входящей).

<figure><img src="/files/papGZ1JX2qZLol48sM3U" alt=""><figcaption><p>Список транзакций клиента</p></figcaption></figure>

<details>

<summary>Отправка перевода</summary>

Для отправки перевода необходимо выполнить следующие действия:

1. Нажать на кнопку ![](/files/aey4cGSczYYBbnpENkyO)
2. Ввести номер телефона получателя, выбрать банк и нажать <*Проверить счет*>.&#x20;
3. Ввести сумму и нажать <*Перевести*>. Будет эмулирован поток сообщений в указанный банк-получатель (подробнее поток сообщений описан в [Инициализация переводов денег](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-perevodov-deneg)).

![](/files/StpdvO1Tvv7FYr8YFner)

</details>

<details>

<summary>Возврат полученного перевода</summary>

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

1. В списке транзакции выбрать полученный перевод и нажать кнопку <*Возврат*>.

![](/files/i0IzMLO9Z5sb6HPjcPlN)

2. Нажать кнопку <*Выполнить возврат*>. Будет смоделирован поток сообщений по возврату перевода его отправителю (подробнее поток сообщений описан в [Возврат полученного перевода (C2CR)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-perevodov-deneg/vozvrat-poluchennogo-perevoda-c2cr)).

![](/files/r5yn04sMpGFZrbX76wze)

*Примечание: Выполняется возврат всей суммы полученного перевода*

</details>

<details>

<summary>Оплатить платеж</summary>

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

1. Нажать на кнопку ![](/files/3gNj08Irp3N1EcY0DvGZ)
2. Ввести данные платежа и нажать <*Получить информацию*>.

![](/files/V8q1p6DpmgCtLyVaPWtI)

3. Нажать <*Оплатить*>.

Если введены данные для платежа по статическому QR-коду, то дополнительно необходимо указать сумму платежа. Будет эмулирован поток сообщений в банк-получателя (подробнее поток сообщений описан в [Инициализация проведения платежей (по QR-коду) в рамках адаптационной модели](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-provedeniya-platezhei-po-qr-kodu-v-ramkakh-adaptacionnoi-modeli)).

![](/files/A41tdVe4Ay9sLu53n7kx)

</details>

<details>

<summary>Инициализация возврата платежа</summary>

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

1. Нажать на кнопку ![](/files/ycrfeVlUcl8VdRZdwfZp)
2. Ввести данные из QR-кода для возврата и нажать кнопку <*Получить информацию*>. Будет смоделирован поток сообщений по возврату денег отправителю (подробнее в [Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-provedeniya-platezhei-po-qr-kodu-v-ramkakh-adaptacionnoi-modeli/vozvrat-deneg-po-provedennoi-ranee-oplate-za-tovar-uslugu-c2br))

![](/files/tG2T0Hi0yhYWHI2rBmaA)

</details>

## Моделирование действий Поставщика товаров/ работ/ услуг (мерчанта)

Для входа в качестве Поставщика товаров/ работ/ услуг (мерчанта) необходимо на форме входа во вкладке <**Организация**>   указать любой БИН (кроме указанных в [#dannye-dlya-modelirovaniya-oshibok](#dannye-dlya-modelirovaniya-oshibok "mention")) и нажать кнопку <*Вход*>.

<figure><img src="/files/YafzPU8tZjtMCpGrwpKN" alt=""><figcaption></figcaption></figure>

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

В списке транзакции отображается подробная информация по каждой проведенной транзакции (исходящей и входящей).

<figure><img src="/files/aI7LQQCaJI2bP65V0EKc" alt=""><figcaption><p>Список транзакций мерчанта</p></figcaption></figure>

<details>

<summary>Генерация данных для проведения платежа</summary>

Для генерации данных для проведения платежа необходимо выполнить следующие действия:

1. Нажать кнопку ![](/files/R0d3eS9QvlXGpYbvrnKF)
2. Ввести данные для формирования данных для проведения платежа.&#x20;

Для динамического QR-кода указывается сумма платежа при его генерации.&#x20;

Для статического QR-кода сумма платежа указывается клиентом при его оплате.

![](/files/SnvlijbBZLeIWzE4r6Wy)

3. Нажать кнопку <*Сформировать*>  (вы получите QR в виде ссылке) и скопировать полученные данные, которые должны быть использованы для последующего моделирования оплаты данного платежа клиентом (см. [Инициализация проведения платежей (по QR-коду) в рамках адаптационной модели](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-provedeniya-platezhei-po-qr-kodu-v-ramkakh-adaptacionnoi-modeli)).

Для генерации QR-кода в виде изображения перейдите во вкладку "QR"

<figure><img src="/files/AtYSeCc17OemIgk8c7vi" alt=""><figcaption></figcaption></figure>

1\) Введите любой БИН.

2\) Нажмите на кнопку <Войти>.

3\) Укажите сумму оплаты в тенге.

4\) Нажмите кнопку <Сформировать QR>.

</details>

<details>

<summary>Возврат денег по полученному платежу</summary>

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

1. В списке транзакции выбрать платеж и нажать кнопку <*Возврат*>.

![](/files/ohlzs1ue2vpf92kXfXln)

2. Скопировать полученные данные для инициирования возврата платежа, используя которые необходимо направить сообщение admi.009 с данными клиента для возврата (подробнее в [Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-provedeniya-platezhei-po-qr-kodu-v-ramkakh-adaptacionnoi-modeli/vozvrat-deneg-po-provedennoi-ranee-oplate-za-tovar-uslugu-c2br))

![](/files/GhOcwz9cbGOXzHu5ytHi)

3. Ввести сумму возврата и нажать кнопку <*Выполнить возврат*>. Будет смоделирован поток сообщений по возврату денег отправителю (подробнее в [Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-provedeniya-platezhei-po-qr-kodu-v-ramkakh-adaptacionnoi-modeli/vozvrat-deneg-po-provedennoi-ranee-oplate-za-tovar-uslugu-c2br)).

![](/files/tJEdRKQMpQlhvU0l4V2u)

</details>

## Данные тестового банка

На форме входа во вкладке <**Банк**> можно посмотреть данные тестового банка. Используя эти данные можно отправлять сообщения тестовому банку для отладки исходящих платежей / переводов.

<figure><img src="/files/vHltkSUFV7YCb4PqT2MW" alt=""><figcaption></figcaption></figure>

При нажатии на кнопку <*Получить выписку*> отображается выписка по тестовому банку.

<figure><img src="/files/oPiiUhwoohRvXkzJCnLO" alt=""><figcaption><p>Просмотр  выписки</p></figcaption></figure>

### Данные для моделирования ошибок

Во вкладке <**Банк**>  при нажатии на кнопку <*Список ошибок*> доступен список номеров телефонов и БИН, используя которые можно моделировать ошибки.&#x20;

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

<figure><img src="/files/wDXNCzi25Sa1slLT3ax9" alt=""><figcaption><p>Данные для моделирования ошибок</p></figcaption></figure>

> *В "Списке ошибок" по каждой ошибки приводится:*&#x20;
>
> * *код ошибки*
> * *номер телефона / БИН, который нужно указать в качестве получателя платежа/перевода*
> * *краткое описание*


# 1.8 Тестирование API

Используется только для Подсистемы платежей и переводов Open API

### 1. Тест кейсы

В данном разделе представлены тест кейсы, которые помогут вам провести тестирование. &#x20;

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

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

{% hint style="info" %}
Данный файл заполняется Оператором после успешного тестирования вместе с Протоколом тестирования (см. [Подписание Протокола тестирования](broken://pages/BWLznJ6HGIyKUWh7RRRY)).
{% endhint %}

{% file src="/files/BGiPtxBc7wvCaOKmWaLX" %}
Тест кейсы по переводам денег
{% endfile %}

{% file src="/files/AIy2cEZZ5posw5RvIsDf" %}
Тест кейсы по платежам
{% endfile %}

### 2. Подписание Протокола тестирования

После успешного выполнения всех тестовых сценариев (в соответствии с выбранной ролью) Участник сообщает Оператору о пройденном тестировании. Запрос направляется в рабочем порядке через электронную почту.

В тексте сообщения Участник в произвольной форме сообщает об успешном тестировании и запрашивает Протокол тестирования. Протокол тестирования разрабатывается Оператором согласно и подписывается обеими сторонами.

{% hint style="warning" %}
*Внимание!* Успешно выполненные тестовые сценарии не являются гарантией успешной работы систем Участника в режиме промышленной эксплуатации, но являются обязательным условием для подключения к промышленной среде.
{% endhint %}


# Работа с промышленным окружением МСМП

Для работы с промышленной средой Порталом НПК перейдите по адресу [https://cabinet.npck.kz](https://cabinet.npck.kz/).

Первый руководитель проходит процедуру [регистрации и авторизации](/registraciya-i-avtorizaciya/3.-registraciya-i-avtorizaciya-v-portale-npk) и [добавляет своих сотрудников в Портал НПК](/registraciya-i-avtorizaciya/4.-dobavlenie-novykh-sotrudnikov) для делегирования работ в Портале НПК.


# Подключение к  сервисами Межбанковской системы мобильных платежей

{% hint style="success" %}
Подключение к  **промышленным сервисам Межбанковской системы мобильных платежей,** состоит из следующих шагов:

1. [Заявка на подключение к Межбанковской системе переводов и платежей, Open Banking/Open API](/promyshlennoe-okruzhenie-msmp/rabota-s-promyshlennym-okruzheniem-msmp/podklyuchenie-k-servisami-mezhbankovskoi-sistemy-mobilnykh-platezhei/zayavka-na-podklyuchenie-k-mezhbankovskoi-sisteme-perevodov-i-platezhei-open-banking-open-api).
2. [Настройка подключения](/promyshlennoe-okruzhenie-msmp/rabota-s-promyshlennym-okruzheniem-msmp/podklyuchenie-k-servisami-mezhbankovskoi-sistemy-mobilnykh-platezhei/nastroika-podklyucheniya).
3. [Публикация API](/promyshlennoe-okruzhenie-msmp/rabota-s-promyshlennym-okruzheniem-msmp/podklyuchenie-k-servisami-mezhbankovskoi-sistemy-mobilnykh-platezhei/publikaciya-api).
   {% endhint %}

{% hint style="info" %}
Для полного подключения к промышленным сервисам Межбанковской системы переводов и платежей необходимо успешно провести тестирование с подписанием итогового протокола тестирования (см. [Тестирование API](broken://pages/1L4mVdFZjr65WTTkLC3H) и [Подписание Протокола тестирования](broken://pages/BWLznJ6HGIyKUWh7RRRY)).
{% endhint %}


# Заявка на подключение к Межбанковской системе переводов и платежей, Open Banking/Open API

Данный раздел доступен участникам, которые прошли регистрацию

1. Для подключения к Межбанковской системе переводов и платежей и/или Open Banking/Open API требуется подать заявку на подключение согласно разделу [5.2 Подключение к Open Banking/Open API](/registraciya-i-avtorizaciya/5.-podacha-zayavki-na-podklyuchenie-k-servisam/5.2-podklyuchenie-k-open-banking-open-api).
2. Должен быть подготовлен список из следующих документов:

<table data-full-width="false"><thead><tr><th width="78" data-type="number">№</th><th valign="top">Документ</th><th width="210" valign="top">Комментарий</th><th>Куда направляется документ</th></tr></thead><tbody><tr><td>1</td><td valign="top">Заявление о присоединении к Договору присоединения о предоставлении услуг в Межбанковской системе обмена информацией по открытым программным интерфейсам (Open API) - (далее - Договор)</td><td valign="top"><p>Приложение № 1 к Договору:</p><p>Оригинал - 2 экземпляра</p><p> </p></td><td>НПК</td></tr><tr><td>2</td><td valign="top">Заявление на подключение к API сервисам</td><td valign="top"><p>Приложение № 2 к Договору:</p><p>Оригинал - 1 экземпляр. Выбрать галкой все сервисы, к которым подключаетесь</p></td><td>НПК</td></tr><tr><td>3</td><td valign="top">Электронная копия Устава</td><td valign="top"> </td><td>НПК</td></tr><tr><td>4</td><td valign="top">Электронная копия свидетельства / справки о государственной регистрации (перерегистрации) юридического лица</td><td valign="top">С информацией о юридическом и фактическом адресах Участника, его контактных телефонах и электронной почте (справка с e-gov)</td><td>НПК</td></tr><tr><td>5</td><td valign="top">Электронная копия свидетельства о постановке на учет по налогу на добавленную стоимость</td><td valign="top"> </td><td>НПК</td></tr><tr><td>6</td><td valign="top">Электронная копия приказа о назначении первого руководителя</td><td valign="top"> </td><td>НПК</td></tr><tr><td>7</td><td valign="top">Электронная копия лицензии на проведение банковских операций и / или отдельных видов банковских операций</td><td valign="top"> </td><td>НПК</td></tr><tr><td>8</td><td valign="top">Информация о работниках Участника, уполномоченных от его имени решать технические, финансовые и другие вопросы, связанные с взаимодействием с Системой</td><td valign="top">Информация с ФИО, рабочим и сотовым телефоном, адресом эл. почты сотрудников. В случае изменения данных Участник обязуется в течение 7 (семи) рабочих дней с момента изменения данной информации уведомить в письменном виде Оператора</td><td>НПК</td></tr><tr><td>9</td><td valign="top">Доверенность на представителя, если договор с Оператором подписывается не первым руководителем</td><td valign="top">Оригинал - 1 экземпляр</td><td>НПК</td></tr><tr><td>10</td><td valign="top">Заявление об ознакомлении и соблюдений порядка проведения платежей и переводов денег и иной документации Межбанковской системы обмена информацией по открытым программным интерфейсам (Open API);</td><td valign="top"><p>Оригинал - 1 экземпляр</p><p>Приложение № 4 из документа &#x3C;Межбанковская система по открытым программным интерфейсам (Open API). Подсистема платежей и переводов Open API. Порядок проведения платежей и переводов денег> (далее - Порядок)</p></td><td>НПК</td></tr><tr><td>11</td><td valign="top">Гарантийное обязательство</td><td valign="top"><p>Приложение №1 Порядка.</p><p>Оригинал -  1 экземпляр в фирменном бланке</p></td><td>Оригинал в НБРК, электронная копия в НПК</td></tr><tr><td>12</td><td valign="top">Электронная копия договора о предоставлении дневного займа &#x3C;овердрафт> (при наличии)</td><td valign="top"></td><td>Оригинал в НБРК, электронная копия в НПК</td></tr><tr><td>13</td><td valign="top">Согласие на дебетование и кредитование счета в МСПД (после регистрации договора)</td><td valign="top">Приложение № 5 к Договору, заполненное и подписанное на фирменном бланке Банка. Оригинал - 1 экземпляр.</td><td>НПК</td></tr></tbody></table>

{% hint style="warning" %}
**Разъяснения по некоторым документам**

1. Сбор и отправка документов в НПК и НБРК может происходить параллельно.
2. **Согласие на дебетование и кредитование счета в МСПД** (далее - Согласие).  Данный документ предоставляется после того, как все документы согласно пунктам 1-10 были отправлены Оператору и договор с Участником был зарегистрирован.&#x20;

После регистрации договора Участник уведомляется о регистрации, получает номер и дату регистрации, которую указывает в Согласии и направляет Оператору.&#x20;

Требуется заполнить и распечатать Согласие на фирменном бланке банка. Здесь Участник дает Оператору разрешение на списывание и зачисление средств со своего корреспондентского счета, открытого в НБРК.

3. **Гарантийное обязательство** для расчета суммы максимально допустимого значения дебетовой чистой позиции участника предоставляется в Национальный банк самостоятельно. Указать в нем сумму в рамках которой будут проводиться в течение операционного дня операции (переводы и платежи).&#x20;

&#x20;**Важно:**

В связи с тем, что при отправке гарантийного обязательства оно сразу берется в работу и на следующий день средства блокируются на корреспондентском счете банка, просим к гарантийному обязательству написать сопроводительное письмо в произвольной форме.&#x20;

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

4. Для заключения **Договора овердрафта** (на усмотрение банка), каждому Банку необходимо самостоятельно написать письмо по электронной почте в Национальный банк с запросом на заключение договора в рамках подключения к Межбанковской системе обмена информацией по открытым программным интерфейсам (Open API).
   {% endhint %}

Собранные документы должны быть направлены получателям согласно указаниям в таблице:

1. Оригиналы документов, которые должны быть направлены в НПК - направляются по адресу г. Алматы, Коктем-3, д 21
2. Электронные копии, которые должны быть направлены в НПК - направляются на электронные почты [Aitkazy.Z@npck.kz](mailto:Aitkazy.Z@kisc.kz) и [Dikhanchinova.M@npck.kz](mailto:Dikhanchinova.M@kisc.kz) или прикрепляются к заявке на подключение согласно разделу [5.2 Подключение к Open Banking/Open API](/registraciya-i-avtorizaciya/5.-podacha-zayavki-na-podklyuchenie-k-servisam/5.2-podklyuchenie-k-open-banking-open-api)
3. Документы, которые должны быть направлены в НБРК - направляются по адресу Z05T8F6, Астана, проспект Мәңгілік Ел, 57«А». Кому: канцелярия и Департамент операционного учета.

   <hq@nationalbank.kz>  - канцелярия

   в копию необходимо поставить:

   <zhuldyz@nationalbank.kz>  - Жулдыз Юсупжанова – Начальник управления обслуживания банковских счетов Департамента операционного учета.


# Настройка подключения

Для настройки приложений и API на промышленных серверах необходимо провести следующие шаги:

1. **Организация сетевого доступа**

В промышленной среде используется существующий выделенный канал между банками и НПК. При необходимости настройки - доступ дополнительно настраивается совместно, при этом обеспечивается консультация со стороны сетевых специалистов НПК. В случае необходимости требуется обратиться с заявкой на электронную почту <Support-OAPI@npck.kz>&#x20;

&#x20; 2\. **Открытые ключи для подключения к Межбанковской системе переводов и платежей**

* Необходимо подать «Заявление о присоединении, а также на изготовление ключей и регистрационного свидетельства и/или регистрацию регистрационного свидетельства» к Договору о предоставлении услуг удостоверяющего центра в системах АО «НПК» в Удостоверяющий центр УЦ (<https://npck.kz/dogovory-uuc/> ([Приложение №1 к Договору о предоставлении услуг удостоверяющего центра в системах AO «НПК»](https://npck.kz/wp-content/uploads/2025/06/991-1.docx)).&#x20;

В заявлении требуется указать необходимость регистрационного свидетельства для использования в системе «Межбанковская система обмена информацией по открытым программным интерфейсам Open API».

{% hint style="info" %}
Для получения имени субъекта, CN name - нужно обратиться на почту <Support-OAPI@npck.kz>.&#x20;

По вопросам заполнения заявления и **обязательной проверки перед подписанием и отправкой** в НПК следует обратиться в [supportca@npck.kz](mailto:supportca@kisc.kz).
{% endhint %}

* После получения ключей требуется провести работы согласно [1.2 Проведение работ по полученному ключу](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei/1.2-provedenie-rabot-po-poluchennomu-klyuchu)и [1.4 Добавление корреспондентского счета](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei/1.4-dobavlenie-korrespondentskogo-scheta).

&#x20;3\. **Настройки API**

&#x20;Настройки API в промышленной среде осуществляются согласно разделу [Настройка API](/open-banking/poluchenie-informacii-o-bankovskikh-schetakh-klienta-pilotnyi-proekt/rekomendacii-po-realizacii-integracii-dlya-postavshika-api/nastroika-api).

&#x20; 4\. **Опционально для сервиса получения информации о счетах: Настройки приложений** **участников**

Управление приложениями описано в разделе [6. Добавление и использование приложения](/registraciya-i-avtorizaciya/6.-dobavlenie-i-ispolzovanie-prilozheniya).


# Публикация API

Публикация API в промышленной среде осуществляется согласно разделу [1.6 Публикация API](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei/1.6-publikaciya-api)[.](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei/1.6-publikaciya-api)

Для подтверждения Оператором заявки на публикацию API Участник должен предоставить Протокол тестирования, согласно разделу [Подписание Протокола тестирования](https://docs.npck.kz/promyshlennoe-okruzhenie-msmp/rabota-s-promyshlennym-okruzheniem-msmp/podklyuchenie-k-servisami-mezhbankovskoi-sistemy-mobilnykh-platezhei/pages/vtBowvZhN444ImaVVjbW#id-2.-podpisanie-protokola-testirovaniya), подписанный ранее Участником и Оператором.

Срок рассмотрения заявки - 3 рабочих дня.


# Диспуты

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

Для регистрации диспута или обращения необходимо пройти авторизацию в кабинете [https://cabinet.npck.kz/](https://cabinet.npck.kz/organization) согласно [3. Регистрация и авторизация в Портале НПК](/registraciya-i-avtorizaciya/3.-registraciya-i-avtorizaciya-v-portale-npk).

В главном меню рабочей области необходимо нажать на раздел <Диспуты>.

<figure><img src="/files/wrUnvj2wWMAGlxo0NJrH" alt=""><figcaption></figcaption></figure>

Раздел <Диспуты> включает функциональность со списком созданных диспутов, фильтрации по дате, статусу и наличию новых уведомлений, а также возможность добавления новых диспутов.

<figure><img src="/files/2knsFcR7NclrV52nOyEG" alt=""><figcaption></figcaption></figure>

### Входящие и исходящие диспуты

<details>

<summary>&#x3C;Исходящие> — содержит диспуты, зарегистрированные другим участникам системы.</summary>

{% hint style="warning" %}
&#x20;В списке диспутов отображаются номер обращения и его текущий статус. Возможные статусы включают:

* Новый – диспут только создан, рассмотрение ещё не начато.
* Открыт – диспут принят в работу.
* На рассмотрении – проводится анализ представленных материалов.
* Одобрен – требования Инициатора признаны обоснованными.
* Отклонён – претензия отклонена.
* Решён – диспут урегулирован сторонами.
* На арбитражном рассмотрении – спор передан на рассмотрение арбитражной комиссии.
* Решён арбитражной комиссией – вынесено решение в рамках арбитража.
* Просрочен – превышен установленный срок рассмотрения.
  {% endhint %}

При нажатии на запись с диспутом отображается карточка Диспута:

<figure><img src="/files/vYAy5PFJ2oVD5UoXCi4K" alt=""><figcaption></figcaption></figure>

{% hint style="success" %}
Информация отображаемая в карточке диспута включает следующие сведения:

* Номер – уникальный идентификатор обращения.
* Статус – текущий этап обработки.
* Отправитель претензии – участник инициировавший диспут.
* Получатель претензии – участник, к которому направлена претензия.
* Тип диспута – категория спорной ситуации (переводы/платежи).
* Причина диспута – основание, по которому подана претензия.
* End To End ID Транзакции – идентификатор платежной операции.
* Краткое описание диспута – сжатое изложение сути по спорной ситуации **в 120 символах**.
* Суть претензии – развернутое описание требований инициатора диспута - **до 400 символов.**
* Дата проведения спорного платежа – календарная дата проведения платежа/перевода.
* Сумма транзакции – сумма, проведенная по спорной операции.
* Сумма диспута – сумма, которая оспаривается.
* Дополнительные документы – прикрепленные файлы, подтверждающие позицию стороны.&#x20;
* Дата создания диспута – дата регистрации обращения.
* История обращений – хронология действий.
  {% endhint %}

Для создания нового обращения нужно нажать кнопку <Новый диспут>. Откроется карточка  диспута с предупреждением:&#x20;

<figure><img src="/files/Z4QMtjsp1iQSppWwFln0" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
Требуется заполнить следующие поля в карточке диспута:

* Получатель претензии – участник, к которому направлена претензия.
* End To End ID Транзакции – идентификатор платежной операции.
* Дата проведения спорного платежа – календарная дата проведения платежа/перевода.
* Сумма транзакции – сумма, проведенная по спорной операции.
* Тип диспута – категория спорной ситуации (переводы/платежи).
* Причина диспута – основание, по которому подана претензия.
* Сумма диспута – сумма, которая оспаривается.
* Краткое описание диспута – сжатое изложение сути по спорной ситуации.
* Суть претензии – развернутое описание требований инициатора диспута.
* Дополнительные документы – прикрепленные файлы, подтверждающие позицию стороны.&#x20;
  {% endhint %}

После заполнения всех обязательных полей и прикрепления файлов нажмите <Сохранить>, чтобы сохранить обращение, либо <Отмена>, чтобы выйти без сохранения.

{% hint style="success" %}
После сохранения обращению автоматически присваивается статус «Новый». В дальнейшем, по мере обработки, статус диспута может изменяться на:

* Открыт — диспут принят в работу.
* На рассмотрении — проводится проверка и анализ информации.
* Одобрен — претензия признана обоснованной.
* Отклонён — претензия не подтверждена.
* Решён — диспут урегулирован.
* На арбитражном рассмотрении — передан на рассмотрение арбитражной комиссии.
* Решён арбитражной комиссией — принято окончательное решение.
* Просрочен — сроки рассмотрения обращения нарушены.
  {% endhint %}

</details>

<details>

<summary>&#x3C;Входящие> — содержит диспуты, полученные от других участников системы.</summary>

<figure><img src="/files/m9VgtgIm7SKHyMUSzIPd" alt=""><figcaption></figcaption></figure>

В списке входящих диспутов отображается следующая информация:

{% hint style="warning" %}

* Период - имеется возможность указать: сегодня, текущая неделя, текущий месяц, прошлый месяц, а также указать период.
* Статусы - по умолчанию выбраны все статусы, имеется возможность указать: новый, открыт, на рассмотрении, одобрен.
* Новые уведомления - галочка для фильтра.
* Краткая информация о диспуте в списке: номер диспута, описание, статус, срок исполнения диспута, дата создания, кому назначен.
  {% endhint %}

При нажатии на диспут открывается карточка диспута:

<figure><img src="/files/iCP9U0kiSnP1SHAJ6VOz" alt=""><figcaption></figcaption></figure>

Для рассмотрения диспута необходимо нажать на кнопку <Взять на рассмотрение>.

Статус диспута меняется на <На рассмотрении>:

<figure><img src="/files/ICsh70QRozlegzKC68Wi" alt=""><figcaption></figcaption></figure>

При необходимости запроса дополнительных документов имеется возможность запросить данные в АО НПК или в организацию, которая зарегистрировала диспут, для этого необходимо нажать на кнопку <Запрос в NPCK> или <Запрос в Организацию> соответственно. Далее в появившемся окне необходимо заполнить описание запроса и направить запрос.

<figure><img src="/files/BnOfJYlxBVRPPvBTNXum" alt=""><figcaption></figcaption></figure>

Для того, чтобы завершить работу над диспутом необходимо нажать на кнопку <Отклонить>, чтобы отклонить диспут или <Принять>, чтобы принять диспут.&#x20;

{% hint style="danger" %}
При нажатии на <Отклонить> откроется форма отклонения, со следующими полями:

* Решение по диспуту.
* Причина отклонения.
* Описание решения.
* Дополнительные документы.

![](/files/PIccbQR1wpm3QmXx3VFC)
{% endhint %}

{% hint style="success" %}
При нажатии на <Принять> откроется форма согласия с диспутом  со следующими полями:

* Решение по диспуту.
* Сведения о способе возмещения.
* Описание решения.
* Дополнительные документы.

<img src="/files/mQ2F87OjcMJJ4KieGIk3" alt="" data-size="original">
{% endhint %}

</details>


# Межбанковская система мобильных платежей (МСМП)

Техническая спецификация по платежам и переводам Open API

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

{% hint style="success" %}
Для подключения к тестовому окружению Межбанковской системы переводов и платежей нужно выполнить шаги из разделов:

1. [3. Регистрация и авторизация в Портале НПК](/registraciya-i-avtorizaciya/3.-registraciya-i-avtorizaciya-v-portale-npk)
2. [5.2 Подключение к Open Banking/Open API](/registraciya-i-avtorizaciya/5.-podacha-zayavki-na-podklyuchenie-k-servisam/5.2-podklyuchenie-k-open-banking-open-api).
3. [1. Настройка подключения к Межбанковской системе мобильных платежей](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei)&#x20;
   {% endhint %}

{% hint style="info" %}
После настройки API каждому участнику присваивается уникальный идентификатор (provider id), который используется в потоках информационного взаимодействия для идентификации участника.&#x20;
{% endhint %}


# Рекомендации для мобильного приложения

Разработка дизайна мобильного приложения требует тщательного подхода, чтобы обеспечить интуитивно понятный и привлекательный интерфейс для пользователей.&#x20;

> В этом разделе представлены рекомендации, которые помогут дизайнерам создать удобный и эстетически приятный пользовательский опыт.&#x20;
>
> Эти советы охватывают все ключевые аспекты дизайна, включая визуальную структуру, навигацию, взаимодействие с пользователем.

{% file src="/files/LgsMSXuJmEIRDgNEbAiY" %}
Рекомендации для процессов платежей и переводов
{% endfile %}


# Описание структуры запросов

## Структура запроса

Реализация процессов инициализации переводов денежных средств и платежей основана на методах API, описанных в электронном формате в <https://transfers-openapi.npck.kz/>.&#x20;

{% hint style="warning" %}
Во всех запросах должен быть указан **HTTP заголовок end-to-end-id**, в котором должен указываться сквозной идентификатор для всей цепочки сообщений, использующийся в рамках данной операции *(должен совпадать с соответствующим значением, передаваемым в теле сообщения)*
{% endhint %}

В запросах в методах API, передаются бизнес-сообщения, основанные на соответствующих сообщениях стандарта ISO20022.&#x20;

{% hint style="info" %}
Используются следующие сообщения стандарта ISO20022:

\-     acmt.023.001.03;

\-     acmt.024.001.03;

\-     camt.053.001.11;

\-     camt.060.001.06;

\-     pacs.002.001.13;

\-     pacs.004.001.12;

\-     pacs.008.001.11;

\-     pacs.028.001.05;

\-     admi.009.001.02;

\-     admi.010.001.02
{% endhint %}

Бизнес‑сообщения должны быть представлены в виде XML‑документов и должны соответствовать XSD‑схемам и правилам заполнения документов (см. [Форматы сообщений](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/opisanie-struktury-zaprosov/formaty-soobshenii)).

{% hint style="info" %}
XSD‑схемы сообщений доступны для скачивания по ссылке: [https://www.iso20022.org/catalogue-messages/iso-20022-messages-archive](https://www.google.com/url?q=https://www.iso20022.org/catalogue-messages/iso-20022-messages-archive\&sa=D\&source=docs\&ust=1716958801626628\&usg=AOvVaw3Ynu37Xj9GSDrJtNPQDNU_)  или <https://www.iso20022.org/iso-20022-message-definitions>
{% endhint %}

Структура бизнес-сообщения:

```xml
<?xml version="1.0" encoding="utf-8"?>
<ns0:Document xmlns:ns0="urn:iso:std:iso:20022:tech:xsd:xxx.nnn.nnn.nn">
  
   <!-- Содержимое сообщения -->    
  
   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
       <!— Подпись сообщения -->
   </ds:Signature>

</ns0:Document>

```

Корневым тегом бизнес-сообщения является тег «Document», который должен содержать:

* Содержимое сообщения  (бизнес часть) – содержит смысловую информацию сообщения, например, информацию о переводе денежных средств или информацию о движении денежных средств по счетам. Формат данного блока индивидуален для каждого метода (описание методов приведено в электронном формате в <https://transfers-openapi.npck.kz/>) и основан на соответствующих сообщениях  стандарта ISO20022.
* Вложенный тег «Signature» – содержит подпись передаваемого сообщения в формате XMLDSIG (см. [Подписание и проверка электронной цифровой подписи бизнес-сообщений](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/podpisanie-i-proverka-elektronnoi-cifrovoi-podpisi-biznes-soobshenii)).

{% hint style="info" %}
Для корневого элемента «Document» и вложенных в него элементов используется  префикс пространства имен **ns0**, кроме подписи сообщения, передаваемой в элементе «Signature», для которой используется пространство имен **ds**
{% endhint %}


# Форматы сообщений

В данном разделе приведено описание полей сообщений, используемых в рамках процессов переводов и платежей. Сообщения основаны на стандарте ISO20022 и адаптированы в соответствии с правилами ISO20022 (соблюдены правила обеспечения соответствия стандарту).&#x20;

{% hint style="danger" %}
**Важно!** Поля, которые присутствуют в XSD-схемах сообщений стандарта ISO20022, но не прописаны в таблицах в данном приложении, Платформа никак не обрабатывает на своей стороне, соответственно не нужно их заполнять при формировании сообщений.
{% endhint %}

Матрица данных по целевой модели C2B2\_V2 представлена ниже для скачивания:

{% file src="/files/o2ApclakSbfuQfnwII7Q" %}


# Сообщение acmt.023

Сообщение acmt.023 должно соответствовать XSD-схеме acmt.023.001.03 стандарта ISO 20022. Если поле не отмечено как опциональное, оно является обязательным.

### Что передаёт сообщение

Сообщение используется для запроса верификации наличия счета клиента.

{% hint style="info" %}
Для полей идентификаторов и даты используйте единые правила:

* [Генерация уникальных идентификаторов для сообщений](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/generaciya-unikalnykh-identifikatorov-dlya-soobshenii)
* [Формат даты и времени в бизнес сообщении (ISODateTime и ISODate)](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/format-daty-i-vremeni-v-biznes-soobshenii-isodatetime-i-isodate)
  {% endhint %}

### Структура сообщения

<table><thead><tr><th>№</th><th>Наименование</th><th>XML-тег</th><th width="109">Опциональность</th><th>Описание</th></tr></thead><tbody><tr><td>0</td><td>IdentificationVerificationRequest</td><td>IdVrfctnReq</td><td>—</td><td>Запрос на верификацию наличия счета клиента.</td></tr><tr><td>1</td><td>Assignment</td><td>Assgnmt</td><td>—</td><td>Информация о сообщении.</td></tr><tr><td>1.1</td><td>MessageIdentification</td><td>MsgId</td><td>—</td><td>Идентификатор сообщения. Формат должен соответствовать странице <a href="/spaces/oKJIIe9wXRYlANVFHqJE/pages/s5MxzFtnHpHNgStDruwy">Генерация уникальных идентификаторов для сообщений</a>.</td></tr><tr><td>1.2</td><td>CreationDateTime</td><td>CreDtTm</td><td>—</td><td>Дата и время создания сообщения. Указывается в формате UTC. См. <a href="/spaces/oKJIIe9wXRYlANVFHqJE/pages/nA5tJTQBCyaP9kOrHlzb">Формат даты и времени в бизнес сообщении (ISODateTime и ISODate)</a>.</td></tr><tr><td>1.3</td><td>Assigner</td><td>Assgnr</td><td>—</td><td>Отправитель сообщения. Сторона, которая направляет сообщение.</td></tr><tr><td>1.3.1</td><td>Agent</td><td>Agt</td><td>—</td><td>Идентификация банка или финансовой организации.</td></tr><tr><td>1.3.1.1</td><td>FinancialInstitutionIdentification</td><td>FinInstnId</td><td>—</td><td>—</td></tr><tr><td>1.3.1.1.1</td><td>Name</td><td>Nm</td><td>—</td><td>Идентификатор, присвоенный банку или финансовой организации Платформой. См. <a href="/spaces/oKJIIe9wXRYlANVFHqJE/pages/WHfFTzuxkpXfyHNbawjC">страницу с идентификаторами участников Платформы</a>.</td></tr><tr><td>1.4</td><td>Assignee</td><td>Assgne</td><td>—</td><td>Получатель сообщения. Сторона, которой направляется сообщение.</td></tr><tr><td>1.4.1</td><td>Agent</td><td>Agt</td><td>—</td><td>Идентификация банка или финансовой организации.</td></tr><tr><td>1.4.1.1</td><td>FinancialInstitutionIdentification</td><td>FinInstnId</td><td>—</td><td>—</td></tr><tr><td>1.4.1.1.1</td><td>Name</td><td>Nm</td><td>—</td><td>Идентификатор, присвоенный банку или финансовой организации Платформой. См. <a href="/spaces/oKJIIe9wXRYlANVFHqJE/pages/WHfFTzuxkpXfyHNbawjC">страницу с идентификаторами участников Платформы</a>.</td></tr><tr><td>1.5</td><td>Creator</td><td>Cretr</td><td>—</td><td>Данные ФЛ, по инициативе которого выполняется запрос верификации счета.</td></tr><tr><td>1.5.1</td><td>Party</td><td>Pty</td><td>—</td><td>Данные ФЛ.</td></tr><tr><td>1.5.1.1</td><td>Name</td><td>Nm</td><td>—</td><td>ФИО ФЛ, по инициативе которого выполняется запрос верификации счета. Максимальная длина — 140 символов.</td></tr><tr><td>1.5.1.2</td><td>CountryOfResidence</td><td>CtryOfRes</td><td>—</td><td>Страна резидентства. Код страны по ISO 3166 Alpha-2.</td></tr><tr><td>1.5.1.3</td><td>Identification</td><td>Id</td><td>—</td><td>Идентификационные данные.</td></tr><tr><td>1.5.1.3.1</td><td>PrivateIdentification</td><td>PrvtId</td><td>—</td><td>Идентификационные данные ФЛ.</td></tr><tr><td>1.5.1.3.1.1</td><td>Other</td><td>Oth</td><td>—</td><td>Массив из трёх элементов. Пример приведён ниже.</td></tr><tr><td>1.5.1.3.1.1.1</td><td>Identification</td><td>Id</td><td>—</td><td>Идентификатор, соответствующий схеме идентификации в теге <code>&#x3C;SchmeNm></code>. Максимальная длина — 35 символов.</td></tr><tr><td>1.5.1.3.1.1.2</td><td>SchemeName</td><td>SchmeNm</td><td>—</td><td>Может содержать только один из тегов <code>&#x3C;Cd></code> или <code>&#x3C;Prtry></code>.</td></tr><tr><td>1.5.1.3.1.1.2.1</td><td>Code</td><td>Cd</td><td>Тег используется для указания кода типа документа.</td><td>Код типа документа: <strong>NIDN</strong> — ИИН, <strong>CCPT</strong> — документ, удостоверяющий личность, для нерезидентов без ИИН.</td></tr><tr><td>1.5.1.3.1.1.2.2</td><td>Proprietary</td><td>Prtry</td><td>Тег используется для передачи дополнительных атрибутов идентификации ФЛ.</td><td><p>Дополнительные атрибуты: </p><p><strong>IRS</strong> — признак резидентства, <strong>SECO</strong> — сектор экономики.</p></td></tr><tr><td>2</td><td>Verification</td><td>Vrfctn</td><td>—</td><td>Данные, на основе которых выполняется верификация наличия счета клиента. Заполняется один элемент массива.</td></tr><tr><td>2.1</td><td>Identification</td><td>Id</td><td>—</td><td>Сквозной идентификатор для всей цепочки сообщений в рамках операции. Используется как EndToEndId в последующей цепочке сообщений. Формат должен соответствовать странице <a href="/spaces/oKJIIe9wXRYlANVFHqJE/pages/s5MxzFtnHpHNgStDruwy">Генерация уникальных идентификаторов для сообщений</a>. Соответствует значению HTTP-заголовка <code>end-to-end-id</code>.</td></tr><tr><td>2.2</td><td>PartyAndAccountIdentification</td><td>PtyAndAcctId</td><td>—</td><td>Информация для верификации.</td></tr><tr><td>2.2.1</td><td>Account</td><td>Acct</td><td>—</td><td>—</td></tr><tr><td>2.2.1.1</td><td>Identification</td><td>Id</td><td>—</td><td>—</td></tr><tr><td>2.2.1.1.1</td><td>Other</td><td>Othr</td><td>—</td><td>—</td></tr><tr><td>2.2.1.1.1.1</td><td>Identification</td><td>Id</td><td>—</td><td>Номер мобильного телефона клиента, по которому выполняется верификация наличия счета. Шаблон: <code>^\+\d{10,14}$</code>. Пример: <code>+77071234567</code>.</td></tr><tr><td>3</td><td>SupplementaryData</td><td>SplmtryData</td><td>—</td><td><p>Массив.</p><p>Параметры запроса в виде «ключ-значение»:</p><p>·          в теге &#x3C;PlcAndNm> - передается ключ;</p><p>·          в теге &#x3C;Envlp> - передается соответствующее указанному ключу значение.</p><p>Не допускается указывать один и тот же ключ дважды.</p><p>Список используемых ключей:</p><ul><li><strong>OPERATION_TYPE</strong> – код типа операции, обязательный. Принимает значения:</li></ul><ul class="contains-task-list"><li><input type="checkbox" checked><strong>C2C2</strong> – для перевода денег от отправителя денег к другому ФЛ в приложении Банка отправителя денег</li><li><input type="checkbox" checked><strong>C2B2_RTP</strong> - для инициализации выставления счета на оплату ФЛ от ЮЛ. <mark style="color:orange;">Для данного типа транзакции в блоке <strong>IdVrfctnReq → SplmtryData</strong> передается расширенный состав данных согласно таблице ниже.</mark></li><li><input type="checkbox" checked>M2M - для инициализация перевода денег клиента между своими счетами в разных БВУ</li></ul><p>Пример:</p><p><em>&#x3C;ns0:SplmtryData>  &#x3C;ns0:PlcAndNm>OPERATION_TYPE&#x3C;/ns0:PlcAndNm></em></p><p> <em>&#x3C;ns0:Envlp></em></p><p>  <em>&#x3C;EnvlpValue>C2C2&#x3C;/EnvlpValue></em></p><p>    <em>&#x3C;/ns0:Envlp></em></p><p><em>&#x3C;/ns0:SplmtryData></em></p></td></tr><tr><td>3.1</td><td>PlaceAndName</td><td>PlcAndNm</td><td>—</td><td>Ключ в формате Upper Camel Case.</td></tr><tr><td>3.2</td><td>Envelope</td><td>Envlp</td><td>—</td><td>—</td></tr><tr><td>3.2.1</td><td>EnvelopeValue</td><td>EnvlpValue</td><td>—</td><td>Значение. Префикс пространства имён <code>ns0</code> не указывается.</td></tr></tbody></table>

<mark style="background-color:$primary;">Расширенный состав данных для сообщения acmt.023 для типа транзакции</mark> <mark style="background-color:$primary;"></mark><mark style="background-color:$primary;">**C2B2\_RTP**</mark><mark style="background-color:$primary;">:</mark>&#x20;

<table><thead><tr><th width="149.75">Наименование</th><th width="289.5">Описание</th><th width="166.5277099609375">Опциональность</th><th width="173">Описание</th></tr></thead><tbody><tr><td>IIN</td><td><p>ИИН клиента.</p><p>Длина: 12 символов.</p></td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>BANK_NAME  </td><td>Наименование БВУ</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>BANK_BIN</td><td>БИН БВУ</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>DEVICE_ID</td><td>ID устройства</td><td></td><td><i class="fa-download">:download:</i><br></td></tr><tr><td>DEVICE_IP</td><td>IP устройства</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>CLIENT_REGISTRATION_DATE</td><td><p>Дата регистрации клиента в приложении.</p><p>Указывается в формате UTC (см. <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/format-daty-i-vremeni-v-biznes-soobshenii-isodatetime-i-isodate">Формат даты и времени в бизнес сообщении (ISODateTime и ISODate)</a>)</p></td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_DAYS_SINCE_FIRST_DEVICE_LOGIN</td><td>Скор балл для параметра «Кол-во дней с первого входа на девайс текущего пользователя»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_CURRENT_DAY</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за текущий день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_ONE_DAY</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за 1 день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_SEVEN_DAYS</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за 7 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_FOURTEEN_DAYS</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за 14 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_ONE_MONTH</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за 1 месяц»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_THREE_MONTHS</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за 3 месяца»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_SIX_MONTHS</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за 6 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_TWELVE_MONTHS</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за 12 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_CURRENT_DAY</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за текущий день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_ONE_DAY</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за 1 день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_SEVEN_DAYS</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за 7 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_FOURTEEN_DAYS</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за 14 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_ONE_MONTH</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за 1 месяц»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_THREE_MONTHS</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за 3 месяца»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_SIX_MONTHS</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за 6 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_TWELVE_MONTHS</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за 12 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_DAYS_SINCE_LAST_SESSION</td><td>Скор балл для параметра «Количество дней с последней сессии в приложении по клиенту»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_CURRENT_DAY</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за текущий день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_ONE_DAY</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за 1 день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_SEVEN_DAYS</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за 7 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_FOURTEEN_DAYS</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за 14 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_ONE_MONTH</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за 1 месяц»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_THREE_MONTHS</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за 3 месяца»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_SIX_MONTHS</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за 6 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_TWELVE_MONTHS</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за 12 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_CURRENT_DAY</td><td>Скор балл для параметра «Кол-во сессий со звонком за текущий день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_ONE_DAY</td><td>Скор балл для параметра «Кол-во сессий со звонком за 1 день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_SEVEN_DAYS</td><td>Скор балл для параметра «Кол-во сессий со звонком за 7 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_FOURTEEN_DAYS</td><td>Скор балл для параметра «Кол-во сессий со звонком за 14 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_ONE_MONTH</td><td>Скор балл для параметра «Кол-во сессий со звонком за 1 месяц»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_THREE_MONTHS</td><td>Скор балл для параметра «Кол-во сессий со звонком за 3 месяца»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_SIX_MONTHS</td><td>Скор балл для параметра «Кол-во сессий со звонком за 6 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_TWELVE_MONTHS</td><td>Скор балл для параметра «Кол-во сессий со звонком за 12 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_CURRENT_DAY</td><td>Скор балл для параметра «Среднее кол-во сессий в день за текущий день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_ONE_DAY</td><td>Скор балл для параметра «Среднее кол-во сессий в день за 1 день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_SEVEN_DAYS</td><td>Скор балл для параметра «Среднее кол-во сессий в день за 7 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_FOURTEEN_DAYS</td><td>Скор балл для параметра «Среднее кол-во сессий в день за 14 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_ONE_MONTH</td><td>Скор балл для параметра «Среднее кол-во сессий в день за 1 месяц»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_THREE_MONTHS</td><td>Скор балл для параметра «Среднее кол-во сессий в день за 3 месяца»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_SIX_MONTHS</td><td>Скор балл для параметра «Среднее кол-во сессий в день за 6 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_TWELVE_MONTHS</td><td>Скор балл для параметра «Среднее кол-во сессий в день за 12 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_YESTERDAY</td><td>Скор балл для параметра «Кол-во сессий за предыдущий день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>DEVICE_OS</td><td>Операционная система устройства (IOS|Android)</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>DEVICE_MODEL</td><td>Модель устройства</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>GEOLOCATION</td><td>Геолокация</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_DAYS_SINCE_NEW_DEVICE_LOGIN</td><td>Скор балл для параметра «Кол-во дней со входа с нового устройства»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MINUTES_SINCE_SESSION_START</td><td>Скор балл для параметра «Кол-во минут с открытия сессии»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_REMOTE_ASSIST_SESSION_AGE</td><td>Скор балл для параметра «Давность сессии с наличием программ удаленного помощника»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>APP_LANGUAGE</td><td>Язык приложение</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_PASSWORD_RESTORE_AGE</td><td>Скор балл для параметра «Давность восстановления пароля»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_PASSWORD_CHANGE_AGE</td><td>Скор балл для параметра «Давность смены пароля»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_LAST_IAD_AGE</td><td>Скор балл для параметра «Давность последнего ИАД»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_USERS_PER_DEVICE</td><td>Скор балл для параметра «Кол-во пользователей на девайс»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_UNIQUE_DEVICES_PER_CLIENT</td><td>Скор балл для параметра «Количество уникальных девайсов на клиента»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>CALL_FLAG</td><td>Признак звонка</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>CALL_SESSION_AGE</td><td>Давность сессии с признаком звонка</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_FIRST_SESSION_AGE_NEW_DEVICE</td><td>Скор балл для параметра «Давность первой сессии с входа с нового устройства»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>REMOTE_ASSIST_ENABLED_SESSION_AGE</td><td>Давность сессии с включенной программой удаленного помощника</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_CURRENT_SESSION_DURATION</td><td>Скор балл для параметра «Длительность текущей сессий»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_PHONE_CHANGE_AGE  </td><td>Скор балл для параметра «Давность изменение номера телефона»</td><td></td><td><i class="fa-download">:download:</i></td></tr></tbody></table>

#### Пример заполнения блока PrivateIdentification

```xml
<ns0:PrvtId>
    <ns0:Othr>
        <ns0:Id>856728615445</ns0:Id>
        <ns0:SchmeNm>
            <ns0:Cd>NIDN</ns0:Cd>
        </ns0:SchmeNm>
    </ns0:Othr>
    <ns0:Othr>
        <ns0:Id>1</ns0:Id>
        <ns0:SchmeNm>
            <ns0:Prtry>IRS</ns0:Prtry>
        </ns0:SchmeNm>
    </ns0:Othr>
    <ns0:Othr>
        <ns0:Id>9</ns0:Id>
        <ns0:SchmeNm>
            <ns0:Prtry>SECO</ns0:Prtry>
        </ns0:SchmeNm>
    </ns0:Othr>
</ns0:PrvtId>
```

#### Значения для Code и Proprietary

* **NIDN** — ИИН. Обязателен для резидентов и нерезидентов при наличии ИИН.
* **CCPT** — документ, удостоверяющий личность, для нерезидентов при отсутствии ИИН.
* **IRS** — признак резидентства. В теге `<Id>` указывается `1` для резидента и `2` для нерезидента.
* **SECO** — сектор экономики. В теге `<Id>` указывается значение от `1` до `9`, например `9` — домашние хозяйства.

{% hint style="info" %}
Если используется **NIDN**, поле **CCPT** не заполняется.
{% endhint %}

#### Значения для OPERATION\_TYPE

* **C2C2** — перевод денег другому ФЛ в приложении банка отправителя.
* **C2B2\_RTP** — инициализация выставления счёта на оплату ФЛ от ЮЛ.
* **M2M** — для инициализация перевода денег клиента между своими счетами в разных БВУ.

#### Пример заполнения блока SupplementaryData

```xml
<ns0:SplmtryData>
    <ns0:PlcAndNm>OPERATION_TYPE</ns0:PlcAndNm>
    <ns0:Envlp>
        <EnvlpValue>C2C2</EnvlpValue>
    </ns0:Envlp>
</ns0:SplmtryData>
```


# Сообщение acmt.024

Сообщение acmt.024 должно соответствовать XSD-схеме сообщения acmt.024.001.03 стандарта ISO20022 и правилам заполнения документа, указанным в таблице ниже. Если поле не отмечено как опциональное, то оно является обязательным.

<table><thead><tr><th>№</th><th>Наименование</th><th>XML-тег</th><th width="135.25">ООпциональность</th><th>Описание</th></tr></thead><tbody><tr><td>0</td><td>IdentificationVerificationReport</td><td>IdVrfctnRpt</td><td><br></td><td>Результат верификации наличия счета клиента</td></tr><tr><td>1</td><td>Assignment</td><td>Assgnmt</td><td><br></td><td>Информация о сообщении</td></tr><tr><td>1.1.</td><td>MessageIdentification </td><td>MsgId </td><td><br></td><td>Идентификатор сообщения (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>)</td></tr><tr><td>1.2.</td><td>CreationDateTime</td><td>CreDtTm</td><td><br></td><td><p>Дата и время создания сообщения.</p><p>Указывается в формате UTC (см. <a data-mention href="/pages/nA5tJTQBCyaP9kOrHlzb">/pages/nA5tJTQBCyaP9kOrHlzb</a>)</p></td></tr><tr><td>1.3.</td><td>Assigner</td><td>Assgnr</td><td><br></td><td>Отправитель сообщения. Сторона, которая направляет данное сообщение</td></tr><tr><td>1.3.1</td><td>Agent</td><td>Agt</td><td><br></td><td>Идентификация Банка или финансовой организации</td></tr><tr><td>1.3.1.1</td><td>FinancialInstitutionIdentification</td><td>FinInstnId</td><td><br></td><td><br></td></tr><tr><td>1.3.1.1.1</td><td>Name</td><td>Nm</td><td><br></td><td><p>Идентификатор, присвоенный Банку или финансовой организации Платформой (см. <a data-mention href="/pages/WHfFTzuxkpXfyHNbawjC">/pages/WHfFTzuxkpXfyHNbawjC</a>). </p><p>В сообщениях, сформированных Платформой, будет передаваться в качестве идентификатора Платформы значение - <strong>00000000-0000-0000-0000-000000000000</strong></p></td></tr><tr><td>1.4</td><td>Assignee</td><td>Assgne</td><td><br></td><td>Получатель сообщения. Сторона, которой направляется сообщение</td></tr><tr><td>1.4.1</td><td>Agent</td><td>Agt</td><td><br></td><td>Идентификация Банка или финансовой организации</td></tr><tr><td>1.4.1.1</td><td>FinancialInstitutionIdentification</td><td>FinInstnId</td><td><br></td><td><br></td></tr><tr><td>1.4.1.1.1</td><td>Name</td><td>Nm</td><td><br></td><td>Идентификатор, присвоенный Банку или финансовой организации Платформой (см. <a data-mention href="/pages/WHfFTzuxkpXfyHNbawjC">/pages/WHfFTzuxkpXfyHNbawjC</a>).</td></tr><tr><td>2</td><td>Report</td><td>Rpt</td><td><br></td><td><p>Результат верификации наличия счета клиента.</p><p>Массив, содержит один элемент</p></td></tr><tr><td>2.1.</td><td>OriginalIdentification</td><td>OrgnlId</td><td><br></td><td><p>Сквозной идентификатор для всей цепочки сообщений в рамках данной операции (формат должен соответствовать описанному в <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>).</p><p>Соответствует значению HTTP заголовка end-to-end-id</p></td></tr><tr><td>2.2.</td><td>Verification</td><td>Vrfctn</td><td><br></td><td>Результат верификации наличия счета клиента (<strong>true/false</strong>)</td></tr><tr><td>2.3</td><td>Reason</td><td>Rsn </td><td>Опционально</td><td>Причина неуспешности верификации. Используется при коде верификации «<strong>false</strong>»</td></tr><tr><td>2.3.1</td><td>Proprietary</td><td>Prtry</td><td><br></td><td><p>Код причины неуспешности верификации.</p><p>Возможные значения приведены в <a data-mention href="/pages/GNLjZsETLk55q8e2bQPE">/pages/GNLjZsETLk55q8e2bQPE</a></p></td></tr><tr><td>2.4.</td><td>UpdatedPartyAndAccountIdentification</td><td>UpdtdPtyAndAcctId</td><td>Опционально</td><td>Информация о счете клиента. Используется при коде верификации «<strong>true</strong>»</td></tr><tr><td>2.4.1.</td><td>Party</td><td>Pty</td><td><br></td><td><br></td></tr><tr><td>2.4.1.1</td><td>Name</td><td>Nm</td><td><br></td><td><p>ФИО клиента. </p><p>Поле заполняется в обязательной последовательности: <em><mark style="color:$danger;">Фамилия, Имя, Отчество</mark></em> (при наличии).</p><p></p><p><em><strong>*Отображение в МП сохраняется в формате «Имя Ф.».</strong></em></p><p></p><p>Максимальная длина: 140 символов</p></td></tr><tr><td>2.4.1.2</td><td>Identification </td><td>Id </td><td><br></td><td><br></td></tr><tr><td>2.4.1.2.1 </td><td>PrivateIdentification</td><td>PrvtId</td><td><br></td><td>Идентификационные данные клиента</td></tr><tr><td>2.4.1.2.1.1</td><td>Other</td><td>Othr</td><td><br></td><td><p>Массив, в массиве заполняются три элемента.</p><p></p><p><em>Пример:</em></p><pre class="language-xml" data-overflow="wrap"><code class="lang-xml">&#x3C;ns0:PrvtId>
							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>313407829711&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Cd>NIDN&#x3C;/ns0:Cd>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>1&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Prtry>IRS&#x3C;/ns0:Prtry>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>9&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Prtry>SECO&#x3C;/ns0:Prtry>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
						&#x3C;/ns0:PrvtId>
</code></pre></td></tr><tr><td>2.4.1.2.1.1.1</td><td>Identification</td><td>Id</td><td><br></td><td><p>Идентификатор, соответствующий схеме идентификации, указанной в теге &#x3C;SchmeNm>.</p><p><strong>Максимальная длина: 35 символов</strong></p></td></tr><tr><td>2.4.1.2.1.1.2</td><td>SchemeName</td><td>SchmeNm</td><td><br></td><td>Может содержать только один из тегов &#x3C;Cd> или &#x3C;Prtry></td></tr><tr><td>2.4.1.2.1.1.2.1</td><td>Code</td><td>Cd</td><td>Тег используется для указания кода типа документа</td><td><p>Код типа документа </p><ul><li><strong>NIDN</strong> – ИИН (обязателен для резидентов и нерезидентов при наличии ИИН; <em>при указании ИИН поле CCPT не заполняется);</em></li><li><strong>CCPT</strong> – документ, удостоверяющий личность для нерезидентов в случае отсутствия ИИН.</li></ul><p></p><p>Примечание: В теге &#x3C;Id> указывается соответственно ИИН <em>(длина - 12 символов)</em> либо номер документа, удостоверяющего личность</p></td></tr><tr><td>2.4.1.2.1.1.2.2</td><td>Proprietary</td><td>Prtry</td><td>Тег используется для передачи дополнительных атрибутов идентификации ФЛ</td><td><p>Дополнительные атрибуты идентификации для физического лица:</p><ul><li><strong>IRS</strong> – признак резидентства </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение: 1 – резидент, 2 – нерезидент;</em></p><ul><li><strong>SECO</strong> – сектор экономики </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение сектора экономики (цифра от 1 до 9), например: 9 – домашние хозяйства</em></p></td></tr><tr><td>2.4.1.3 </td><td>CountryOfResidence </td><td>CtryOfRes </td><td><br></td><td>Страна резидентства. <strong>Код страны по ISO 3166 (Alpha-2 code)</strong></td></tr><tr><td>2.4.2</td><td>Account</td><td>Acct</td><td><br></td><td><br></td></tr><tr><td>2.4.2.1</td><td>Name</td><td>Nm</td><td><br></td><td>IBAN счета клиента. <strong>Шаблон:^[0-9A-Z]{20}$</strong></td></tr><tr><td>3</td><td>SupplementaryData</td><td>SplmtryData</td><td><br></td><td><p>Массив.</p><p>Параметры запроса в виде «ключ-значение»:</p><ul><li><strong>в теге &#x3C;PlcAndNm></strong> - передается ключ;</li><li><strong>в теге &#x3C;Envlp></strong> - передается соответствующее указанному ключу значение.</li></ul><p>Не допускается указывать один и тот же ключ дважды.</p><p></p><p>Список используемых ключей:</p><ul><li><strong>OPERATION_TYPE</strong> – код типа операции, обязательный. <em>Принимает значения:</em></li></ul><ul class="contains-task-list"><li><input type="checkbox" checked><em>C2C2 – для перевода денег от отправителя денег к другому ФЛ в приложении Банка отправителя денег</em></li><li><input type="checkbox" checked><em>C2B2_RTP - для инициализации выставления счета на оплату ФЛ от ЮЛ.</em> <mark style="color:orange;">Для данного типа транзакции в блоке <strong>IdVrfctnRpt→ SplmtryData</strong> передается расширенный состав данных согласно таблице ниже.</mark></li><li><input type="checkbox" checked>M2M - для инициализация перевода денег клиента между своими счетами в разных БВУ</li></ul><ul><li><strong>ERROR_DESCRIPTION</strong> - описание ошибки, максимальная длина: 105 символов, опциональное, применяется в случае ошибок<br></li></ul><p></p><p><em>Пример:</em></p><pre class="language-xml" data-overflow="wrap"><code class="lang-xml">&#x3C;ns0:SplmtryData>
    &#x3C;ns0:PlcAndNm>OPERATION_TYPE&#x3C;/ns0:PlcAndNm>
    &#x3C;ns0:Envlp>
        &#x3C;EnvlpValue>C2C2&#x3C;/EnvlpValue>
    &#x3C;/ns0:Envlp>
&#x3C;/ns0:SplmtryData>
</code></pre></td></tr><tr><td>3.1</td><td>PlaceAndName</td><td>PlcAndNm</td><td><br></td><td>Ключ (Upper Camel Case)</td></tr><tr><td>3.2</td><td>Envelope</td><td>Envlp</td><td><br></td><td></td></tr><tr><td>3.2.1</td><td>EnvelopeValue</td><td>EnvlpValue</td><td></td><td>Значение. Префикс пространства имен ns0 не указывается </td></tr><tr><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

<mark style="background-color:$primary;">Расширенный состав данных для сообщения acmt.024 для типа транзакции C2B2\_RTP:</mark>&#x20;

<table><thead><tr><th valign="top">Наименование</th><th width="246.97216796875" valign="top">Описание</th><th width="135.5" valign="top">Опциональность</th><th width="155.75" valign="top">Примечание</th></tr></thead><tbody><tr><td valign="top">COMPANY_ID</td><td valign="top">ИИН/БИН поставщика товара, работы или услуги </td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">COMPANY_FULL_NAME</td><td valign="top">Полное наименование мерчанта</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">PARTNER_BANK </td><td valign="top">Банк партнера</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">BUSINESS_LEGAL_FORM </td><td valign="top">Организационно правовая форма бизнеса(ИП/ТОО)</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">MERCHANT_ID </td><td valign="top">Идентификатор мерчанта (ТСП) в системе банка-эквайера. Используется для идентификации получателя платежа.</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">TERMINAL_ID </td><td valign="top">Идентификатор терминала в системе банка-эквайера. Используется для идентификации терминала, через который выполняется платеж.</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">DEVICE_IP </td><td valign="top">IP устройства для динамичного/статичного</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SALES_POINT_ADDRESS </td><td valign="top">Адрес точки продаж</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">PARTNER_CONNECTION_DATE </td><td valign="top">Дата подключение партнера</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">QR_GENERATION_DATETIME </td><td valign="top"><p>Дата и время формирования QR.</p><p>Указывается в формате UTC (см.  параграф 2 главы 2)</p></td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">CEO_IIN </td><td valign="top">ИИН первого руководителя</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_COUNT_ONE_DAY</td><td valign="top">Скор балл для параметра «кол-во дней с продажами за 1 день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_COUNT_SEVEN_DAYS</td><td valign="top">Скор балл для параметра «кол-во дней с продажами за 7 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_COUNT_FOURTEEN_DAYS</td><td valign="top">Скор балл для параметра «кол-во дней с продажами за 14 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_COUNT_ONE_MONTH</td><td valign="top">Скор балл для параметра «кол-во дней с продажами за 1 месяц»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_COUNT_THREE_MONTHS</td><td valign="top">Скор балл для параметра «кол-во дней с продажами за 3 месяца»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_COUNT_SIX_MONTHS</td><td valign="top">Скор балл для параметра «кол-во дней с продажами за 6 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_COUNT_TWELVE_MONTHS</td><td valign="top">Скор балл для параметра «кол-во дней с продажами за 12 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_CURRENT_DAY</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за текущий день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_ONE_DAY</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за 1 день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_SEVEN_DAYS</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за 7 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_FOURTEEN_DAYS</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за 14 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_ONE_MONTH</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за 1 месяц»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_THREE_MONTHS</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за 3 месяца»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_SIX_MONTHS</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за 6 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_TWELVE_MONTHS</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за 12 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_CURRENT_DAY</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за текущий день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_ONE_DAY</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за 1 день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_SEVEN_DAYS</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за 7 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_FOURTEEN_DAYS</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за 14 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_ONE_MONTH</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за 1 месяц»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_THREE_MONTHS</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за 3 месяца»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_SIX_MONTHS</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за 6 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_TWELVE_MONTHS</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за 12 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_RATIO_2Y </td><td valign="top">Скор балл для параметра «соотношение дней с продажами к кол-ву дней с первой продажи за 2 года»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_CURRENT_DAY</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за текущий день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_ONE_DAY</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за 1 день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_SEVEN_DAY</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за 7 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_FOURTEEN_DAY</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за 14 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_ONE_MONTH</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за 1 месяц»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_THREE_MONTHS</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за 3 месяца»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_SIX_MONTHS</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за 6 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_TWELVE_MONTHS</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за 12 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_DAYS_SINCE_FIRST_SALE </td><td valign="top">Скор балл для параметра «кол-во дней с первой продажи»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_CURRENT_DAY</td><td valign="top">Скор балл для параметра «средний чек на покупку за текущий день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_ONE_DAY</td><td valign="top">Скор балл для параметра «средний чек на покупку за 1 день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_SEVEN_DAYS</td><td valign="top">Скор балл для параметра «средний чек на покупку за 7 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_FOURTEEN_DAYS</td><td valign="top">Скор балл для параметра «средний чек на покупку за 14 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_ONE_MONTH</td><td valign="top">Скор балл для параметра «средний чек на покупку за 1 месяц»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_THREE_MONTHS</td><td valign="top">Скор балл для параметра «средний чек на покупку за 3 месяца»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_SIX_MONTHS</td><td valign="top">Скор балл для параметра «средний чек на покупку за 6 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_TWELVE_MONTHS</td><td valign="top">Скор балл для параметра «средний чек на покупку за 12 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_CURRENT_DAY</td><td valign="top">Скор балл для параметра «кол-во транзакции за текущий день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_ONE_DAY</td><td valign="top">Скор балл для параметра «кол-во транзакции за 1 день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_SEVEN_DAYS</td><td valign="top">Скор балл для параметра «кол-во транзакции за 7 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_FOURTEEN_DAYS</td><td valign="top">Скор балл для параметра «кол-во транзакции за 14 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_ONE_MONTH</td><td valign="top">Скор балл для параметра «кол-во транзакции за 1 месяц»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_THREE_MONTHS</td><td valign="top">Скор балл для параметра «кол-во транзакции за 3 месяца»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_SIX_MONTHS</td><td valign="top">Скор балл для параметра «кол-во транзакции за 6 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_TWELVE_MONTHS</td><td valign="top">Скор балл для параметра «кол-во транзакции за 12 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">DEVICE_TYPE </td><td valign="top">Тип устройства (POS терминал, мобильное приложение)</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">OS_TYPE </td><td valign="top">Операционная система (IOS/Android)</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">APP_LANGUAGE </td><td valign="top">Язык приложение\устройства</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">GEOLOCATION </td><td valign="top">Геолокация</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_DAYS_SINCE_LAST_PASSWORD_CHANGE </td><td valign="top">Скор балл для параметра «Кол-во дней с последней смены пароля »</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_DAYS_SINCE_NEW_DEVICE_LOGIN </td><td valign="top">Скор балл для параметра «Кол-во дней со входа с нового устройства»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">DEVICE_SESSION_START_DATETIME </td><td valign="top"><p>Дата и время открытия текущей сессии устройства.</p><p>Указывается в формате UTC (см.  параграф 2 главы 2)</p></td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_COUNT_SINCE_SESSION_START </td><td valign="top">Скор балл для параметра «Кол-во продаж с начала сессии»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_SINCE_SESSION_START </td><td valign="top">Скор балл для параметра «Средний чек на покупку с начала сессии»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">USER_ROLE </td><td valign="top">Роль пользователя приложения/устройства</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_USER_ADDED_DAYS_AGO </td><td valign="top">Скор балл для параметра «Давность добавления пользователя»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_USER_AUTHORIZATIONS_TODAY </td><td valign="top">Скор балл для параметра «Кол-во авторизаций пользователя за текущий день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CALL_IN_SESSION_FLAG </td><td valign="top">Скор балл для параметра «Признак звонка в сессии»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr></tbody></table>


# Сообщение admi.009

Сообщение admi.009 должно соответствовать XSD‑схеме сообщения admi.009.001.02 стандарта ISO20022 и правилам заполнения документа, указанным в таблице ниже. Если поле не отмечено как опциональное, то оно является обязательным.

<table><thead><tr><th width="116.5">№</th><th width="154.5">Наименование</th><th width="132.75">XML-тег</th><th width="89">Опциональность</th><th>Описание</th></tr></thead><tbody><tr><td>0 </td><td>StaticDataRequest</td><td>StatcDataReq</td><td><br></td><td>Запрос данных</td></tr><tr><td>1</td><td>MessageIdentification </td><td>MsgId </td><td><br></td><td>Идентификатор сообщения (формат должен соответствовать описанному в <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>)</td></tr><tr><td>2</td><td>DataRequestDetails</td><td>DataReqDtls</td><td><br></td><td><br></td></tr><tr><td>2.1</td><td>Type</td><td>Tp</td><td><br></td><td><p>Тип запрашиваемых данных.</p><p>Может принимать значения:</p><ul><li><em>QR - для адаптационной модели;</em></li><li><em>QR_V2 - для целевой модели.</em></li></ul></td></tr><tr><td>3</td><td>SupplementaryData</td><td>SplmtryData</td><td><br></td><td><p>Массив.</p><p>Параметры запроса в виде «ключ-значение»:</p><ul><li><strong>в теге &#x3C;PlcAndNm></strong> - передается ключ;</li><li><strong>в теге &#x3C;Envlp></strong> - передается соответствующее указанному ключу значение.</li></ul><p>Не допускается указывать один и тот же ключ дважды.</p><p>Список используемых ключей:</p><ul><li><strong>MSG_CREATION_TIME</strong> – дата и время создания сообщения, обязательный. Указывается в формате UTC (см. <a data-mention href="/pages/nA5tJTQBCyaP9kOrHlzb">/pages/nA5tJTQBCyaP9kOrHlzb</a>).</li><li><strong>END_TO_END_ID</strong> – сквозной идентификатор для всей цепочки сообщений в рамках данной операции (формат должен соответствовать описанному в <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>), обязательный. Соответствует значению HTTP заголовка end-to-end-id</li><li><strong>SENDER_PROVIDER_ID</strong> – идентификатор банка отправителя запроса, обязательный. Идентификатор, присвоенный банку Платформой (provider  id) (см. <a data-mention href="/pages/WHfFTzuxkpXfyHNbawjC">/pages/WHfFTzuxkpXfyHNbawjC</a>).</li></ul><p></p><ul><li><strong>RECEIVER_PROVIDER_ID</strong> – идентификатор банка получателя запроса, обязательный. Идентификатор, присвоенный банку Платформой (provider  id) Определяется на основе {BANK_BASE_DOMAIN} из QR-кода (см. <a data-mention href="/pages/WHfFTzuxkpXfyHNbawjC">/pages/WHfFTzuxkpXfyHNbawjC</a>).</li><li><strong>QR_ID</strong> – идентификатор QR-кода, указанный в ссылке в QR-коде (см. <a data-mention href="/pages/ZL8xpXIOxuLDnXDp5jc2">/pages/ZL8xpXIOxuLDnXDp5jc2</a>), шаблон: [0-9A-Za-z_=-]{8,50}, обязательный. </li><li><strong>IIN</strong> - ИИН клиента, обязательное. Длина: 12 символов.</li></ul></td></tr><tr><td>3.1</td><td>PlaceAndName</td><td>PlcAndNm</td><td><br></td><td>Ключ (Upper Camel Case)</td></tr><tr><td>3.2</td><td>Envelope</td><td>Envlp</td><td><br></td><td></td></tr><tr><td>3.2.1</td><td>EnvlpValue</td><td>EnvlpValue</td><td></td><td>Значение. Префикс пространства имен ns0 не указывается </td></tr></tbody></table>


# Сообщение admi.009

Сообщение admi.009 должно соответствовать XSD‑схеме сообщения admi.009.001.02 стандарта ISO20022 и правилам заполнения документа, указанным в таблице ниже. Если поле не отмечено как опциональное, то оно является обязательным.

{% hint style="info" %}
В рамках целевой модели для передачи дополнительных данных о владельце счета (от эмитента к эквайеру) расширен состав сведений в теге ***StatcDataReq-> SplmtryData***.&#x20;
{% endhint %}

{% columns %}
{% column width="58.333333333333336%" valign="bottom" %} <i class="fa-download">:download:</i> Нижеперечисленные параметры добавляются  в рамках расширения состава данных:&#x20;

{% file src="/files/3zdcwkAC0jhbFzdou99j" %}
{% endcolumn %}

{% column width="41.666666666666664%" %}

<p align="center"><i class="fa-download">:download:</i> Скор. балл определяется согласно документу «Параметры Единый QR (n)_V3.xlsx»:</p>

{% file src="/files/GygqgHmUR57OUqhtODZf" %}
{% endcolumn %}
{% endcolumns %}

<mark style="background-color:green;">Состав элементов сообщения admi.009:</mark>&#x20;

<table><thead><tr><th width="116.5">№</th><th width="154.5">Наименование</th><th width="132.75">XML-тег</th><th width="89">Опциональность</th><th>Описание</th></tr></thead><tbody><tr><td>0 </td><td>StaticDataRequest</td><td>StatcDataReq</td><td><br></td><td>Запрос данных</td></tr><tr><td>1</td><td>MessageIdentification </td><td>MsgId </td><td><br></td><td>Идентификатор сообщения (формат должен соответствовать описанному в <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>)</td></tr><tr><td>2</td><td>DataRequestDetails</td><td>DataReqDtls</td><td><br></td><td><br></td></tr><tr><td>2.1</td><td>Type</td><td>Tp</td><td><br></td><td><p>Тип запрашиваемых данных.</p><p>Может принимать значения:</p><ul><li><em>QR - для адаптационной модели;</em></li><li><em>QR_V2 - для целевой модели.</em></li></ul></td></tr><tr><td>3</td><td>SupplementaryData</td><td>SplmtryData</td><td><br></td><td><p>Массив.</p><p>Параметры запроса в виде «ключ-значение»:</p><ul><li><strong>в теге &#x3C;PlcAndNm></strong> - передается ключ;</li><li><strong>в теге &#x3C;Envlp></strong> - передается соответствующее указанному ключу значение.</li></ul><p>Не допускается указывать один и тот же ключ дважды.</p><p>Список используемых ключей приведен в таблице ниже.</p></td></tr><tr><td>3.1</td><td>PlaceAndName</td><td>PlcAndNm</td><td><br></td><td>Ключ (Upper Camel Case)</td></tr><tr><td>3.2</td><td>Envelope</td><td>Envlp</td><td><br></td><td></td></tr><tr><td>3.2.1</td><td>EnvlpValue</td><td>EnvlpValue</td><td></td><td>Значение. Префикс пространства имен ns0 не указывается </td></tr></tbody></table>

<mark style="background-color:$primary;">Список используемых ключей для сообщений admi.009:</mark>&#x20;

<table><thead><tr><th width="149.75">Наименование</th><th width="289.5">Описание</th><th width="166.5277099609375">Опциональность</th><th width="173">Описание</th></tr></thead><tbody><tr><td>MSG_CREATION_TIME</td><td>Дата и время создания сообщения, обязательный. Указывается в формате UTC (см. <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/format-daty-i-vremeni-v-biznes-soobshenii-isodatetime-i-isodate">Формат даты и времени в бизнес сообщении (ISODateTime и ISODate)</a>)</td><td></td><td></td></tr><tr><td>END_TO_END_ID</td><td>Сквозной идентификатор для всей цепочки сообщений в рамках данной операции (формат должен соответствовать описанному в (<a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/generaciya-unikalnykh-identifikatorov-dlya-soobshenii">Генерация уникальных идентификаторов для сообщений</a> ), обязательный. Соответствует значению HTTP заголовка end-to-end-id</td><td></td><td></td></tr><tr><td>SENDER_PROVIDER_ID</td><td>Идентификатор банка отправителя запроса, обязательный. Идентификатор, присвоенный банку Системой (provider id) (см.<a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/poluchenie-informacii-o-bankakh-i-statuse-api">Получение информации о банках и статусе API</a>).</td><td></td><td></td></tr><tr><td>RECEIVER_PROVIDER_ID</td><td><p>Идентификатор банка получателя запроса, обязательный. Идентификатор, присвоенный банку Системой (provider id).</p><p>Определяется на основе {BANK_BASE_DOMAIN} из QR-кода (см.<a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/poluchenie-informacii-o-bankakh-i-statuse-api">Получение информации о банках и статусе API</a>).</p></td><td></td><td></td></tr><tr><td>QR_ID</td><td>Идентификатор QR-кода, указанный в ссылке в QR-коде (см.<a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/ispolzovanie-qr-koda-dlya-soversheniya-platezhei">Использование QR-кода для совершения платежей</a>)</td><td></td><td></td></tr><tr><td>IIN</td><td><p>ИИН клиента.</p><p>Длина: 12 символов.</p></td><td></td><td></td></tr><tr><td>BANK_NAME  </td><td>Наименование БВУ</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>BANK_BIN</td><td>БИН БВУ</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>DEVICE_ID</td><td>ID устройства</td><td></td><td><i class="fa-download">:download:</i><br></td></tr><tr><td>DEVICE_IP</td><td>IP устройства</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>CLIENT_REGISTRATION_DATE</td><td><p>Дата регистрации клиента в приложении.</p><p>Указывается в формате UTC (см. <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/format-daty-i-vremeni-v-biznes-soobshenii-isodatetime-i-isodate">Формат даты и времени в бизнес сообщении (ISODateTime и ISODate)</a>)</p></td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_DAYS_SINCE_FIRST_DEVICE_LOGIN</td><td>Скор балл для параметра «Кол-во дней с первого входа на девайс текущего пользователя»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_CURRENT_DAY</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за текущий день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_ONE_DAY</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за 1 день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_SEVEN_DAYS</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за 7 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_FOURTEEN_DAYS</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за 14 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_ONE_MONTH</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за 1 месяц»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_THREE_MONTHS</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за 3 месяца»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_SIX_MONTHS</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за 6 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSIONS_PER_DAY_TWELVE_MONTHS</td><td>Скор балл для параметра «Максимальное количество сессий в день по клиенту за 12 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_CURRENT_DAY</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за текущий день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_ONE_DAY</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за 1 день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_SEVEN_DAYS</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за 7 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_FOURTEEN_DAYS</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за 14 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_ONE_MONTH</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за 1 месяц»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_THREE_MONTHS</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за 3 месяца»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_SIX_MONTHS</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за 6 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MAX_SESSION_DURATION_TWELVE_MONTHS</td><td>Скор балл для параметра «Максимальная продолжительность сессии по клиенту за 12 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_DAYS_SINCE_LAST_SESSION</td><td>Скор балл для параметра «Количество дней с последней сессии в приложении по клиенту»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_CURRENT_DAY</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за текущий день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_ONE_DAY</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за 1 день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_SEVEN_DAYS</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за 7 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_FOURTEEN_DAYS</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за 14 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_ONE_MONTH</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за 1 месяц»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_THREE_MONTHS</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за 3 месяца»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_SIX_MONTHS</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за 6 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSION_DURATION_TWELVE_MONTHS</td><td>Скор балл для параметра «Средняя продолжительность сессии по клиенту за 12 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_CURRENT_DAY</td><td>Скор балл для параметра «Кол-во сессий со звонком за текущий день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_ONE_DAY</td><td>Скор балл для параметра «Кол-во сессий со звонком за 1 день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_SEVEN_DAYS</td><td>Скор балл для параметра «Кол-во сессий со звонком за 7 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_FOURTEEN_DAYS</td><td>Скор балл для параметра «Кол-во сессий со звонком за 14 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_ONE_MONTH</td><td>Скор балл для параметра «Кол-во сессий со звонком за 1 месяц»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_THREE_MONTHS</td><td>Скор балл для параметра «Кол-во сессий со звонком за 3 месяца»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_SIX_MONTHS</td><td>Скор балл для параметра «Кол-во сессий со звонком за 6 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_WITH_CALL_COUNT_TWELVE_MONTHS</td><td>Скор балл для параметра «Кол-во сессий со звонком за 12 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_CURRENT_DAY</td><td>Скор балл для параметра «Среднее кол-во сессий в день за текущий день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_ONE_DAY</td><td>Скор балл для параметра «Среднее кол-во сессий в день за 1 день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_SEVEN_DAYS</td><td>Скор балл для параметра «Среднее кол-во сессий в день за 7 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_FOURTEEN_DAYS</td><td>Скор балл для параметра «Среднее кол-во сессий в день за 14 дней»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_ONE_MONTH</td><td>Скор балл для параметра «Среднее кол-во сессий в день за 1 месяц»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_THREE_MONTHS</td><td>Скор балл для параметра «Среднее кол-во сессий в день за 3 месяца»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_SIX_MONTHS</td><td>Скор балл для параметра «Среднее кол-во сессий в день за 6 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_AVG_SESSIONS_PER_DAY_TWELVE_MONTHS</td><td>Скор балл для параметра «Среднее кол-во сессий в день за 12 месяцев»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_SESSIONS_YESTERDAY</td><td>Скор балл для параметра «Кол-во сессий за предыдущий день»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>DEVICE_OS</td><td>Операционная система устройства (IOS|Android)</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>DEVICE_MODEL</td><td>Модель устройства</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>GEOLOCATION</td><td>Геолокация</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_DAYS_SINCE_NEW_DEVICE_LOGIN</td><td>Скор балл для параметра «Кол-во дней со входа с нового устройства»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_MINUTES_SINCE_SESSION_START</td><td>Скор балл для параметра «Кол-во минут с открытия сессии»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_REMOTE_ASSIST_SESSION_AGE</td><td>Скор балл для параметра «Давность сессии с наличием программ удаленного помощника»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>APP_LANGUAGE</td><td>Язык приложение</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_PASSWORD_RESTORE_AGE</td><td>Скор балл для параметра «Давность восстановления пароля»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_PASSWORD_CHANGE_AGE</td><td>Скор балл для параметра «Давность смены пароля»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_LAST_IAD_AGE</td><td>Скор балл для параметра «Давность последнего ИАД»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_USERS_PER_DEVICE</td><td>Скор балл для параметра «Кол-во пользователей на девайс»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_UNIQUE_DEVICES_PER_CLIENT</td><td>Скор балл для параметра «Количество уникальных девайсов на клиента»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>CALL_FLAG</td><td>Признак звонка</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>CALL_SESSION_AGE</td><td>Давность сессии с признаком звонка</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_FIRST_SESSION_AGE_NEW_DEVICE</td><td>Скор балл для параметра «Давность первой сессии с входа с нового устройства»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>REMOTE_ASSIST_ENABLED_SESSION_AGE</td><td>Давность сессии с включенной программой удаленного помощника</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_CURRENT_SESSION_DURATION</td><td>Скор балл для параметра «Длительность текущей сессий»</td><td></td><td><i class="fa-download">:download:</i></td></tr><tr><td>SCORE_PHONE_CHANGE_AGE  </td><td>Скор балл для параметра «Давность изменение номера телефона»</td><td></td><td><i class="fa-download">:download:</i></td></tr></tbody></table>


# Сообщение admi.010

Сообщение admi.010 должно соответствовать XSD схеме сообщения admi.010.001.02 стандарта ISO20022 и правилам заполнения документа, указанным в таблице ниже. Если поле не отмечено как опциональное, то оно является обязательным.

<table data-full-width="false"><thead><tr><th width="103.25">№</th><th width="151.5">Наименование</th><th width="136.75">XML-тег</th><th width="111.5">Опциональность</th><th>Описание</th></tr></thead><tbody><tr><td>0</td><td>StaticDataReport</td><td>StatcDataRpt</td><td> </td><td>Результат запроса данных</td></tr><tr><td>1</td><td>MessageIdentification</td><td>MsgId</td><td> </td><td>Идентификатор сообщения (формат должен соответствовать описанному в <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>)</td></tr><tr><td>2</td><td>ReportDetails</td><td>RptDtls</td><td> </td><td> </td></tr><tr><td>2.1</td><td>Type</td><td>Tp</td><td> </td><td><p>Тип получаемых данных.</p><p>Должно принимать значение: </p><ul><li><em>QR - для адаптационной модели;</em></li><li><em>QR_V2 - для целевой модели.</em></li></ul></td></tr><tr><td>2.2</td><td>RequestReference</td><td>ReqRef</td><td> </td><td>Сквозной идентификатор из запроса данных admi.009, указанный с ключом END_TO_END_ID (формат должен соответствовать описанному в <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>) . Соответствует значению HTTP заголовка end-to-end-id</td></tr><tr><td>2.3</td><td>ReportKey</td><td>RptKey</td><td> </td><td>Массив</td></tr><tr><td>2.3.1</td><td>Key</td><td>Key</td><td> </td><td><p>Может принимать значения: </p><ul><li>QR</li></ul></td></tr><tr><td>2.3.2</td><td>ReportData</td><td>RptData</td><td> </td><td><p>Массив.</p><p>Информация в виде «ключ-значение»:</p><ul><li><strong>в теге</strong> <strong>&#x3C;Nm></strong> - передается ключ;</li><li><strong>в теге &#x3C;Val></strong> - передается соответствующее указанному ключу значение.</li></ul><p>Не допускается указывать один и тот же ключ дважды.</p><p>Список используемых ключей:</p><ul><li><strong>MSG_CREATION_TIME</strong> – дата и время создания сообщения, обязательный. Указывается в формате UTC (см. <a data-mention href="/pages/nA5tJTQBCyaP9kOrHlzb">/pages/nA5tJTQBCyaP9kOrHlzb</a>).</li><li><strong>SENDER_PROVIDER_ID</strong> - идентификатор банка отправителя запроса, обязательный. Идентификатор, присвоенный банку Платформой (provider  id). (см. <a data-mention href="/pages/WHfFTzuxkpXfyHNbawjC">/pages/WHfFTzuxkpXfyHNbawjC</a>). В сообщениях, сформированных Платформой, будет передаваться в качестве идентификатора Платформы значение - 00000000-0000-0000-0000-000000000000</li><li><strong>RECEIVER_PROVIDER_ID</strong> - идентификатор банка получателя запроса, обязательный. Идентификатор, присвоенный банку Платформой (provider  id). (см. <a data-mention href="/pages/WHfFTzuxkpXfyHNbawjC">/pages/WHfFTzuxkpXfyHNbawjC</a>).</li><li><strong>ERROR_CODE</strong> – информация об ошибке, условно обязательный (обязательный в случае ошибки). Возможные значения см. в <a data-mention href="/pages/GNLjZsETLk55q8e2bQPE">/pages/GNLjZsETLk55q8e2bQPE</a></li><li><strong>ERROR_DESCRIPTION</strong> - описание ошибки, максимальная длина: 105 символов, условно обязательный (обязательный в случае ошибки).</li><li><strong>QR_DATA_TYPE</strong> - тип запрашиваемых данных,  обязательное, если данные по QR_ID найдены успешно. Может принимать значения: </li></ul><p><em>-    001 (оплата по QR-коду, используется для операций типа C2B2);</em></p><p><em>-    002 (оплата в рамках электронной коммерции, используется для операций типа C2B2E);</em></p><p><em>-    003 (возврат по проведенной оплате, используется для операций типа C2BR);</em></p><p><em>-    004 (оплата по QR-коду, используется для операций типа C2B2_V2 в рамках целевой модели);</em> </p><p><em>-    005 (возврат по проведенной оплате, используется для операций типа C2BR_V2 в рамках целевой модели)</em></p><p></p><ul><li><strong>QR_TYPE</strong> -     тип QR кода, обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004. Принимает значения:</li></ul><p><em>-       STATIC - для статического QR-кода</em></p><p><em>-       DYNAMIC - для динамического QR-кода</em></p><p></p><ul><li><strong>POS_ID</strong> – идентификатор торговой точки (point of sale identification),  максимальная длина: 35 символов, обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004.</li><li><strong>BIC</strong> – БИК банка поставщика товара, работы или услуги (бенефициара), 8 символов (латинский алфавит и цифры), обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004.</li><li><strong>ACCOUNT_NUMBER</strong> – IBAN счета поставщика товара, работы или услуги (бенефициара), обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004. <strong>Шаблон:^[0-9A-Z]{20}$</strong></li><li><strong>MCC</strong> – 4-значный код категории продавца, обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004.</li><li><strong>COMPANY_ID</strong> – ИИН/БИН поставщика товара, работы или услуги, обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004.</li><li><strong>COMPANY_NAME</strong> – наименование поставщика товара, работы или услуги,  максимальная длина: 140 символов, обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004.</li><li><strong>COUNTRY_OF_RESIDENCE</strong> – код страны резидентства поставщика товара, работы или услуги, обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004. Значение в соответствии с ISO 3166-1 alpha 2, для Казахстана - «KZ».</li><li><strong>CITY</strong> – город физического местонахождения поставщика товара, работы или услуги,  максимальная длина: 35 символов, обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004.</li><li><strong>CURRENCY</strong> – код валюты (буквенный), принимает значение KZT, обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004.</li><li> <strong>AMOUNT</strong> – сумма платежа, обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004 для динамических QR-кодов и статических QR-кодов с фиксированной суммой, не используется для  статических QR-кодов по операциям с вводом суммы на стороне клиента. Не должно превышать 100 000 000 000 00, должна передаваться в тиын (см. <a data-mention href="/pages/yJXdUQKQdG0AMs3xdPlW">/pages/yJXdUQKQdG0AMs3xdPlW</a>).</li><li><strong>KNP</strong> – код назначения платежа,  3 символа (цифры), обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004.</li><li><strong>KNP_MESSAGE</strong> - описание КНП, обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004. Длина: до  140 символов.</li><li><strong>BENEFICIARY_CODE</strong> – код бенефициара, обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004. Значение этого поля состоит из двух цифр: первая цифра указывает признак резидентства (1 или 2), вторая сектор экономики <em>(принимает значение от 1 до 9)</em>.</li><li><strong>SME</strong> - признак того, что  поставщика товара, работы или услуги является представителем малого или среднего бизнеса, обязательный в случае успешного ответа при QR_DATA_TYPE=001, 002,004. Принимает значения: <em>значение: 0 – не является МСБ, 1 – является МСБ</em>. </li><li><strong>MERCHANT_CHANNEL</strong> - канал транзакции, необязательное. Трехзначная цифра. Значения каналов транзакции приведены в таблице ниже.</li><li><strong>QR_ID</strong> - идентификатор QR-кода, должен соответствовать значению, указанному в admi.009 с ключом QR_ID,  шаблон: [0-9A-Za-z_=-]{8,50}, обязательный </li></ul></td></tr><tr><td>2.3.2.1</td><td>Name</td><td>Nm</td><td> </td><td>Ключ (Upper Camel Case)</td></tr><tr><td>2.3.2.2</td><td>Value</td><td>Val</td><td> </td><td>Значение</td></tr><tr><td>3</td><td>SupplementaryData</td><td>SplmtryData</td><td>Обязательный в случае успешного ответа (при QR_DATA_TYPE=004)</td><td>Дополнительные данные о мерчанте. Массив. Параметры запроса в виде «ключ-значение»: - в теге - передается ключ; - в теге - передается соответствующее указанному ключу значение. Не допускается указывать один и тот же ключ дважды. Список используемых ключей приведен в <a href="https://app.gitbook.com/o/u7C7n84gFFfiAp8eDPnO/s/oKJIIe9wXRYlANVFHqJE/~/edit/~/changes/103/mezhbankovskaya-sistema-perevodov-i-platezhei/opisanie-struktury-zaprosov/formaty-soobshenii/soobshenie-admi.010-dlya-celevoi-modeli-c2b2_v2">Сообщение admi.010 (для целевой модели C2B2_V2)</a></td></tr><tr><td>3.1</td><td>PlaceAndName</td><td>PlcAndNm</td><td></td><td>Ключ</td></tr><tr><td>3.2</td><td>Envelope</td><td>Envlp</td><td></td><td></td></tr><tr><td>3.2.1</td><td>EnvlpValue</td><td>EnvlpValue</td><td></td><td>Значение</td></tr></tbody></table>

*Значения каналов транзакции:*

<table data-full-width="false"><thead><tr><th>Значение (цифра) 1 - средство предъявления QR-кода</th><th>Значение (цифра) 2 - место транзакции</th><th>Значение (цифра) 3 - присутствие поставщика товара, работы или услуги</th></tr></thead><tbody><tr><td>«0» – печатное (стикер со штриховым кодом поставщика товара, работы или услуги)</td><td>«0» – в месторасположении поставщика товара, работы или услуги/зарегистрированного адреса</td><td><p>«0» – необходимо присутствие поставщика товара, работы или услуги</p><p> </p></td></tr><tr><td>«1» – печатное (квитанция, счет на оплату)</td><td>«1» – не в месторасположении поставщика товара, работы или услуги/зарегистрированного адреса</td><td>«1» – отсутствие поставщика товара, работы или услуги</td></tr><tr><td>«2» – печатное (журнал)</td><td><p>«2» – электронная коммерция</p><p> </p></td><td>«2» – кассы самообслуживания</td></tr><tr><td>«3» – печатное (другое)</td><td><p>«3» – другое</p><p> </p></td><td><p>«3» – другое</p><p> </p></td></tr><tr><td>«4» – электронное (пункт продажи)</td><td>-</td><td>-</td></tr><tr><td>«5» - электронное (вебсайт)</td><td>-</td><td>-</td></tr><tr><td>«6» - электронное (приложение)</td><td>-</td><td>-</td></tr><tr><td>«7» - электронное (другое);</td><td>-</td><td>-</td></tr></tbody></table>


# Сообщение admi.010

Сообщение admi.010 должно соответствовать XSD схеме сообщения admi.010.001.02 стандарта ISO20022 и правилам заполнения документа, указанным в таблице ниже. Если поле не отмечено как опциональное, то оно является обязательным.

{% hint style="info" %}
В рамках целевой модели для передачи дополнительных данных о мерчанте расширен состав сведений в теге **StatcDataRpt*****-> SplmtryData***.
{% endhint %}

{% columns %}
{% column width="58.333333333333336%" %} <i class="fa-download">:download:</i> Нижеперечисленные параметры добавляются  в рамках расширения состава данных:&#x20;

{% file src="/files/xEhbTmLXubPCq50liJZV" %}
{% endcolumn %}

{% column width="41.666666666666664%" %} <i class="fa-download">:download:</i> Скор. балл определяется согласно документу «Параметры Единый QR (n)\_V3.xlsx»:

{% file src="/files/GygqgHmUR57OUqhtODZf" %}
{% endcolumn %}
{% endcolumns %}

<mark style="background-color:green;">Состав элементов сообщения admi.010:</mark>&#x20;

<table data-full-width="false"><thead><tr><th width="103.25">№</th><th width="151.5">Наименование</th><th width="136.75">XML-тег</th><th width="111.5">Опциональность</th><th>Описание</th></tr></thead><tbody><tr><td>0</td><td>StaticDataReport</td><td>StatcDataRpt</td><td> </td><td>Результат запроса данных</td></tr><tr><td>1</td><td>MessageIdentification</td><td>MsgId</td><td> </td><td>Идентификатор сообщения (формат должен соответствовать описанному в <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>)</td></tr><tr><td>2</td><td>ReportDetails</td><td>RptDtls</td><td> </td><td> </td></tr><tr><td>2.1</td><td>Type</td><td>Tp</td><td> </td><td><p>Тип получаемых данных.</p><p>Должно принимать значение: </p><ul><li><em>QR - для адаптационной модели;</em></li><li><em>QR_V2 - для целевой модели.</em></li></ul></td></tr><tr><td>2.2</td><td>RequestReference</td><td>ReqRef</td><td> </td><td>Сквозной идентификатор из запроса данных admi.009, указанный с ключом END_TO_END_ID (формат должен соответствовать описанному в <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>) . Соответствует значению HTTP заголовка end-to-end-id</td></tr><tr><td>2.3</td><td>ReportKey</td><td>RptKey</td><td> </td><td>Массив</td></tr><tr><td>2.3.1</td><td>Key</td><td>Key</td><td> </td><td><p>Может принимать значения: </p><ul><li>QR</li></ul></td></tr><tr><td>2.3.2</td><td>ReportData</td><td>RptData</td><td> </td><td><p>Массив.</p><p>Информация в виде «ключ-значение»:</p><ul><li><strong>в теге</strong> <strong>&#x3C;Nm></strong> - передается ключ;</li><li><strong>в теге &#x3C;Val></strong> - передается соответствующее указанному ключу значение.</li></ul><p>Не допускается указывать один и тот же ключ дважды.</p><p>Список используемых ключей приведено в таблице ниже.</p></td></tr><tr><td>2.3.2.1</td><td>Name</td><td>Nm</td><td> </td><td>Ключ (Upper Camel Case)</td></tr><tr><td>2.3.2.2</td><td>Value</td><td>Val</td><td> </td><td>Значение</td></tr><tr><td>3</td><td>SupplementaryData</td><td>SplmtryData</td><td>Обязательный в случае успешного ответа (при QR_DATA_TYPE=002,004)</td><td><p>Дополнительные данные о мерчанте. Массив. Параметры запроса в виде «ключ-значение»: </p><p>- в теге <strong>&#x3C;PlcAndNm></strong> - передается ключ; </p><p>- в теге <strong>&#x3C;Envlp></strong> - передается соответствующее указанному ключу значение. Не допускается указывать один и тот же ключ дважды. Список используемых ключей приведен в таблице ниже.</p></td></tr><tr><td>3.1</td><td>PlaceAndName</td><td>PlcAndNm</td><td></td><td>Ключ</td></tr><tr><td>3.2</td><td>Envelope</td><td>Envlp</td><td></td><td></td></tr><tr><td>3.2.1</td><td>EnvlpValue</td><td>EnvlpValue</td><td></td><td>Значение</td></tr></tbody></table>

<mark style="background-color:$primary;">Список используемых ключей для сообщений admi.010:</mark>&#x20;

<table><thead><tr><th valign="top">Наименование</th><th width="246.97216796875" valign="top">Описание</th><th width="135.5" valign="top">Опциональность</th><th width="155.75" valign="top">Примечание</th></tr></thead><tbody><tr><td valign="top">MSG_CREATION_TIME</td><td valign="top">Дата и время создания сообщения, обязательный. Указывается в формате UTC (см. <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/format-daty-i-vremeni-v-biznes-soobshenii-isodatetime-i-isodate">Формат даты и времени в бизнес сообщении (ISODateTime и ISODate)</a>).</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">SENDER_PROVIDER_ID</td><td valign="top">Идентификатор банка отправителя запроса, обязательный. Идентификатор, присвоенный банку Системой (provider id) (см.<a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/poluchenie-informacii-o-bankakh-i-statuse-api">Получение информации о банках и статусе API</a>).</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">RECEIVER_PROVIDER_ID</td><td valign="top"><p>Идентификатор банка получателя запроса, обязательный. Идентификатор, присвоенный банку Системой (provider id).</p><p>Определяется на основе {BANK_BASE_DOMAIN} из QR-кода (см.<a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/poluchenie-informacii-o-bankakh-i-statuse-api">Получение информации о банках и статусе API</a>).</p></td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">ERROR_CODE</td><td valign="top">Информация об ошибке, <em>(обязательный в случае ошибки).</em> Возможные значения см. в <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/kody-oshibok">Коды ошибок</a></td><td valign="top">условно обязательный</td><td valign="top"></td></tr><tr><td valign="top">ERROR_DESCRIPTION</td><td valign="top">Описание ошибки, максимальная длина: 105 символов<em>(обязательный в случае ошибки).</em></td><td valign="top"> условно обязательный </td><td valign="top"></td></tr><tr><td valign="top">QR_DATA_TYPE</td><td valign="top"><p>Тип запрашиваемых данных, обязательное, если данные по QR_ID найдены успешно. Может принимать значения:</p><p><em>-    002 (оплата в рамках электронной коммерции, используется для операций типа C2B2E);</em></p><p><em>-    003 (возврат по проведенной оплате, используется для операций типа C2BR);</em></p><p><em>-    004 (оплата по QR-коду, используется для операций типа C2B2_V2 в рамках целевой модели);</em> </p><p><em>-    005 (возврат по проведенной оплате, используется для операций типа C2BR_V2 в рамках целевой модели)</em></p></td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">QR_TYPE</td><td valign="top"><p>Тип QR кода, обязательный в случае успешного ответа при QR_DATA_TYPE=002, 004. Принимает значения:</p><p><em>- STATIC - для статического QR-кода</em></p><p><em>- DYNAMIC - для динамического QR-кода</em></p></td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">POS_ID</td><td valign="top">Идентификатор торговой точки в системе банка-эквайера. Используется для идентификации торговой точки, к которой относится платеж, максимальная длина: 35 символов, обязательный в случае успешного ответа при QR_DATA_TYPE=002, 004.</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">BIC</td><td valign="top">БИК банка поставщика товара, работы или услуги (бенефициара), 8 символов (латинский алфавит и цифры), обязательный в случае успешного ответа при QR_DATA_TYPE=002,004.</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">ACCOUNT_NUMBER</td><td valign="top">IBAN счета поставщика товара, работы или услуги (бенефициара), обязательный в случае успешного ответа при QR_DATA_TYPE=002,004. Шаблон:^[0-9A-Z]{20}$</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">MCC</td><td valign="top">4-значный код категории продавца, обязательный в случае успешного ответа при QR_DATA_TYPE=002,004.</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">COMPANY_NAME</td><td valign="top">Наименование поставщика товара, работы или услуги, максимальная длина: 140 символов, обязательный в случае успешного ответа при QR_DATA_TYPE=002,004</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">COUNTRY_OF_RESIDENCE</td><td valign="top">Код страны резидентства поставщика товара, работы или услуги, обязательный в случае успешного ответа при QR_DATA_TYPE=002,004. Значение в соответствии с ISO 3166-1 alpha 2, для Казахстана - «KZ».</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">CITY</td><td valign="top">Город физического местонахождения поставщика товара, работы или услуги, максимальная длина: 35 символов, обязательный в случае успешного ответа при QR_DATA_TYPE=002,004</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">CURRENCY</td><td valign="top">Код валюты (буквенный), принимает значение KZT, обязательный в случае успешного ответа при QR_DATA_TYPE=002,004.</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">AMOUNT</td><td valign="top">Сумма платежа, обязательный в случае успешного ответа при QR_DATA_TYPE=002,004 для динамических QR-кодов и статических QR-кодов с фиксированной суммой, не используется для  статических QR-кодов по операциям с вводом суммы на стороне клиента. Не должно превышать 100 000 000 000 00, должна передаваться в тиын (см. <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/pravilo-peredachi-znachenii-denezhnykh-summ">Правило передачи значений денежных сумм</a>).</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">KNP</td><td valign="top">Код назначения платежа, 3 символа (цифры), обязательный в случае успешного ответа при QR_DATA_TYPE=002,004.</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">KNP_MESSAGE</td><td valign="top">Описание КНП, обязательный в случае успешного ответа при QR_DATA_TYPE=002,004. Длина: до 140 символов.</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">BENEFICIARY_CODE</td><td valign="top">Код бенефициара, обязательный в случае успешного ответа при QR_DATA_TYPE=002,004. Значение этого поля состоит из двух цифр: первая цифра указывает признак резидентства (1 или 2), вторая сектор экономики <em>(принимает значение от 1 до 9)</em>.</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">SME</td><td valign="top">Признак того, что поставщика товара, работы или услуги является представителем малого или среднего бизнеса, обязательный в случае успешного ответа при QR_DATA_TYPE=002,004. <em>Принимает значения: значение: 0 – не является МСБ, 1 – является МСБ.</em></td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">MERCHANT_CHANNEL</td><td valign="top">Канал транзакции. Трехзначная цифра. Значения каналов транзакции приведены в таблице ниже.</td><td valign="top">Опционально</td><td valign="top"></td></tr><tr><td valign="top">QR_ID</td><td valign="top">Идентификатор QR-кода, должен соответствовать значению, указанному в admi.009 с ключом QR_ID, <strong>шаблон: [0-9A-Za-z_=-]{8,50}.</strong></td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">COMPANY_ID</td><td valign="top">ИИН/БИН поставщика товара, работы или услуги , обязательный в случае успешного ответа при QR_DATA_TYPE=002,004.</td><td valign="top"></td><td valign="top"></td></tr><tr><td valign="top">COMPANY_FULL_NAME</td><td valign="top">Полное наименование мерчанта</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">PARTNER_BANK </td><td valign="top">Банк партнера</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">BUSINESS_LEGAL_FORM </td><td valign="top">Организационно правовая форма бизнеса(ИП/ТОО)</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">MERCHANT_ID </td><td valign="top">Идентификатор мерчанта (ТСП) в системе банка-эквайера. Используется для идентификации получателя платежа.</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">TERMINAL_ID </td><td valign="top">Идентификатор терминала в системе банка-эквайера. Используется для идентификации терминала, через который выполняется платеж.</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">DEVICE_IP </td><td valign="top">IP устройства для динамичного/статичного</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SALES_POINT_ADDRESS </td><td valign="top">Адрес точки продаж</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">PARTNER_CONNECTION_DATE </td><td valign="top">Дата подключение партнера</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">QR_GENERATION_DATETIME </td><td valign="top"><p>Дата и время формирования QR.</p><p>Указывается в формате UTC (см.  параграф 2 главы 2)</p></td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">CEO_IIN </td><td valign="top">ИИН первого руководителя</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_COUNT_ONE_DAY</td><td valign="top">Скор балл для параметра «кол-во дней с продажами за 1 день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_COUNT_SEVEN_DAYS</td><td valign="top">Скор балл для параметра «кол-во дней с продажами за 7 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_COUNT_FOURTEEN_DAYS</td><td valign="top">Скор балл для параметра «кол-во дней с продажами за 14 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_COUNT_ONE_MONTH</td><td valign="top">Скор балл для параметра «кол-во дней с продажами за 1 месяц»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_COUNT_THREE_MONTHS</td><td valign="top">Скор балл для параметра «кол-во дней с продажами за 3 месяца»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_COUNT_SIX_MONTHS</td><td valign="top">Скор балл для параметра «кол-во дней с продажами за 6 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_COUNT_TWELVE_MONTHS</td><td valign="top">Скор балл для параметра «кол-во дней с продажами за 12 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_CURRENT_DAY</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за текущий день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_ONE_DAY</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за 1 день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_SEVEN_DAYS</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за 7 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_FOURTEEN_DAYS</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за 14 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_ONE_MONTH</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за 1 месяц»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_THREE_MONTHS</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за 3 месяца»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_SIX_MONTHS</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за 6 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CARD_SALES_SHARE_TWELVE_MONTHS</td><td valign="top">Скор балл для параметра «доля продаж в сумме картой за 12 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_CURRENT_DAY</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за текущий день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_ONE_DAY</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за 1 день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_SEVEN_DAYS</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за 7 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_FOURTEEN_DAYS</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за 14 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_ONE_MONTH</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за 1 месяц»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_THREE_MONTHS</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за 3 месяца»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_SIX_MONTHS</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за 6 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_QR_SALES_SHARE_TWELVE_MONTHS</td><td valign="top">Скор балл для параметра «доля продаж в сумме QR за 12 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_DAYS_RATIO_2Y </td><td valign="top">Скор балл для параметра «соотношение дней с продажами к кол-ву дней с первой продажи за 2 года»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_CURRENT_DAY</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за текущий день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_ONE_DAY</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за 1 день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_SEVEN_DAY</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за 7 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_FOURTEEN_DAY</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за 14 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_ONE_MONTH</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за 1 месяц»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_THREE_MONTHS</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за 3 месяца»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_SIX_MONTHS</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за 6 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_PURCHASES_TWELVE_MONTHS</td><td valign="top">Скор балл для параметра «среднее кол-во покупок за 12 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_DAYS_SINCE_FIRST_SALE </td><td valign="top">Скор балл для параметра «кол-во дней с первой продажи»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_CURRENT_DAY</td><td valign="top">Скор балл для параметра «средний чек на покупку за текущий день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_ONE_DAY</td><td valign="top">Скор балл для параметра «средний чек на покупку за 1 день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_SEVEN_DAYS</td><td valign="top">Скор балл для параметра «средний чек на покупку за 7 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_FOURTEEN_DAYS</td><td valign="top">Скор балл для параметра «средний чек на покупку за 14 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_ONE_MONTH</td><td valign="top">Скор балл для параметра «средний чек на покупку за 1 месяц»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_THREE_MONTHS</td><td valign="top">Скор балл для параметра «средний чек на покупку за 3 месяца»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_SIX_MONTHS</td><td valign="top">Скор балл для параметра «средний чек на покупку за 6 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_TWELVE_MONTHS</td><td valign="top">Скор балл для параметра «средний чек на покупку за 12 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_CURRENT_DAY</td><td valign="top">Скор балл для параметра «кол-во транзакции за текущий день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_ONE_DAY</td><td valign="top">Скор балл для параметра «кол-во транзакции за 1 день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_SEVEN_DAYS</td><td valign="top">Скор балл для параметра «кол-во транзакции за 7 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_FOURTEEN_DAYS</td><td valign="top">Скор балл для параметра «кол-во транзакции за 14 дней»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_ONE_MONTH</td><td valign="top">Скор балл для параметра «кол-во транзакции за 1 месяц»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_THREE_MONTHS</td><td valign="top">Скор балл для параметра «кол-во транзакции за 3 месяца»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_SIX_MONTHS</td><td valign="top">Скор балл для параметра «кол-во транзакции за 6 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_TRANSACTIONS_COUNT_TWELVE_MONTHS</td><td valign="top">Скор балл для параметра «кол-во транзакции за 12 месяцев»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">DEVICE_TYPE </td><td valign="top">Тип устройства (POS терминал, мобильное приложение)</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">OS_TYPE </td><td valign="top">Операционная система (IOS/Android)</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">APP_LANGUAGE </td><td valign="top">Язык приложение\устройства</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">GEOLOCATION </td><td valign="top">Геолокация</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_DAYS_SINCE_LAST_PASSWORD_CHANGE </td><td valign="top">Скор балл для параметра «Кол-во дней с последней смены пароля »</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_DAYS_SINCE_NEW_DEVICE_LOGIN </td><td valign="top">Скор балл для параметра «Кол-во дней со входа с нового устройства»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">DEVICE_SESSION_START_DATETIME </td><td valign="top"><p>Дата и время открытия текущей сессии устройства.</p><p>Указывается в формате UTC (см.  параграф 2 главы 2)</p></td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_SALES_COUNT_SINCE_SESSION_START </td><td valign="top">Скор балл для параметра «Кол-во продаж с начала сессии»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_AVG_RECEIPT_SINCE_SESSION_START </td><td valign="top">Скор балл для параметра «Средний чек на покупку с начала сессии»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">USER_ROLE </td><td valign="top">Роль пользователя приложения/устройства</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_USER_ADDED_DAYS_AGO </td><td valign="top">Скор балл для параметра «Давность добавления пользователя»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_USER_AUTHORIZATIONS_TODAY </td><td valign="top">Скор балл для параметра «Кол-во авторизаций пользователя за текущий день»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr><tr><td valign="top">SCORE_CALL_IN_SESSION_FLAG </td><td valign="top">Скор балл для параметра «Признак звонка в сессии»</td><td valign="top"></td><td valign="top"><i class="fa-download">:download:</i></td></tr></tbody></table>

*Значения каналов транзакции:*

<table data-full-width="false"><thead><tr><th>Значение (цифра) 1 - средство предъявления QR-кода</th><th>Значение (цифра) 2 - место транзакции</th><th>Значение (цифра) 3 - присутствие поставщика товара, работы или услуги</th></tr></thead><tbody><tr><td>«0» – печатное (стикер со штриховым кодом поставщика товара, работы или услуги)</td><td>«0» – в месторасположении поставщика товара, работы или услуги/зарегистрированного адреса</td><td><p>«0» – необходимо присутствие поставщика товара, работы или услуги</p><p> </p></td></tr><tr><td>«1» – печатное (квитанция, счет на оплату)</td><td>«1» – не в месторасположении поставщика товара, работы или услуги/зарегистрированного адреса</td><td>«1» – отсутствие поставщика товара, работы или услуги</td></tr><tr><td>«2» – печатное (журнал)</td><td><p>«2» – электронная коммерция</p><p> </p></td><td>«2» – кассы самообслуживания</td></tr><tr><td>«3» – печатное (другое)</td><td><p>«3» – другое</p><p> </p></td><td><p>«3» – другое</p><p> </p></td></tr><tr><td>«4» – электронное (пункт продажи)</td><td>-</td><td>-</td></tr><tr><td>«5» - электронное (вебсайт)</td><td>-</td><td>-</td></tr><tr><td>«6» - электронное (приложение)</td><td>-</td><td>-</td></tr><tr><td>«7» - электронное (другое);</td><td>-</td><td>-</td></tr></tbody></table>


# Сообщение camt.053

Сообщение camt.053 должно соответствовать XSD-схеме сообщения camt.053.001.11 стандарта ISO20022 и правилам заполнения документа, указанным в таблице ниже. Если поле не отмечено как опциональное, то оно является обязательным.

<table><thead><tr><th>№</th><th width="160">Наименование</th><th width="183.7777099609375">XML-тег</th><th width="98.888916015625">Опциональность</th><th width="183.5555419921875">Описание</th></tr></thead><tbody><tr><td>0 </td><td>BankToCustomerStatement</td><td>BkToCstmrStmt </td><td><br></td><td>Выписка по счету</td></tr><tr><td>1 </td><td>GroupHeader </td><td>GrpHdr</td><td><br></td><td>Заголовок сообщения</td></tr><tr><td>1.1 </td><td>MessageIdentification </td><td>MsgId</td><td><br></td><td>Идентификатор сообщения (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>)</td></tr><tr><td>1.2 </td><td>CreationDateTime </td><td>CreDtTm</td><td><br></td><td><p>Дата и время создания сообщения.</p><p>Указывается в формате UTC (см. <a data-mention href="/pages/nA5tJTQBCyaP9kOrHlzb">/pages/nA5tJTQBCyaP9kOrHlzb</a>)</p></td></tr><tr><td>1.3 </td><td>MessagePagination </td><td>MsgPgntn </td><td><br></td><td>Пагинация</td></tr><tr><td>1.3.1 </td><td>PageNumber </td><td>PgNb</td><td><br></td><td>Номер страницы</td></tr><tr><td>1.3.2 </td><td>LastPageIndicator </td><td>LastPgInd </td><td><br></td><td>Признак последней страницы</td></tr><tr><td>1.4 </td><td>OriginalBusinessQuery </td><td>OrgnlBizQry </td><td>Опционально</td><td>Опционально, заполняется только в случае, если camt.053 генерируется в ответ на camt.060</td></tr><tr><td>1.4.1 </td><td>MessageIdentification </td><td>MsgId </td><td><br></td><td>Идентификатор исходного сообщения camt.060 (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>)</td></tr><tr><td>2 </td><td>Statement </td><td>Stmt </td><td><br></td><td><p>Выписка по счету.</p><p>Массив</p></td></tr><tr><td>2.1 </td><td>Identification </td><td>Id </td><td><br></td><td><p>Идентификатор выписки (формируется по алгоритму из  (формат должен соответствовать описанному в   <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>), сквозной идентификатор.</p><p>Соответствует значению из тега &#x3C;RptgReq> -> &#x3C;Id> исходного запроса camt.060. </p><p>Соответствует значению HTTP заголовка end-to-end-id</p></td></tr><tr><td>2.2</td><td>Account </td><td>Acct </td><td><br></td><td>Счет</td></tr><tr><td>2.2.1 </td><td>Name </td><td>Nm</td><td><br></td><td>Корпоративный счет банка, по которому делается выписка</td></tr><tr><td>2.3</td><td>Balance </td><td>Bal </td><td><br></td><td><p>Информация о балансе.</p><p>Массив</p></td></tr><tr><td>2.3.1</td><td>Type</td><td>Tp</td><td><br></td><td><br></td></tr><tr><td>2.3.1.1</td><td>CodeOrProprietary</td><td>CdOrPrtry</td><td><br></td><td><br></td></tr><tr><td>2.3.1.1.1</td><td>Code</td><td>Cd</td><td><br></td><td><p>Принимает значения:</p><ul><li><strong>CLAV</strong> - по закрытию опер дня</li><li><strong>OPAV</strong> - на начало опер дня</li><li><strong>INFO</strong> - на момент запроса</li></ul></td></tr><tr><td>2.3.2</td><td>Amount</td><td>Amt</td><td><br></td><td><p>Сумма, должна передаваться в тиын (см. <a data-mention href="/pages/yJXdUQKQdG0AMs3xdPlW">/pages/yJXdUQKQdG0AMs3xdPlW</a>).</p><p>Сумма указывается в теге &#x3C;Amt>, валюта указывается в атрибуте «Ccy».</p><p><em>Пример: &#x3C;</em>ns0:<em>Amt Ccy="KZT">138640&#x3C;/</em>ns0:<em>Amt></em></p></td></tr><tr><td><p>2.3.2.1</p><p>(атрибут)</p></td><td>CurrencyCode</td><td><p>Ccy</p><p>(атрибут)</p></td><td><br></td><td>Код валюты (буквенный), принимает значение KZT</td></tr><tr><td>2.3.3</td><td>CreditDebitIndicator</td><td>CdtDbtInd</td><td><br></td><td><p>Указывает, является ли остаток кредитовым или дебетовым.</p><p>Примечание: нулевой баланс считается кредитовый.</p><p>Принимает значения:</p><ul><li><strong>CRDT</strong> - кредит</li><li><strong>DBIT</strong> - дебет</li></ul></td></tr><tr><td>2.3.4</td><td>Date</td><td>Dt</td><td><br></td><td><br></td></tr><tr><td>2.3.4.1</td><td>Date</td><td>Dt</td><td><br></td><td>Дата операционного дня</td></tr><tr><td>2.4 </td><td>Entry </td><td>Ntry </td><td><br></td><td><p>Информация о транзакции.</p><p>Массив</p></td></tr><tr><td>2.4.1</td><td>Amount</td><td>Amt</td><td><br></td><td><p>Сумма транзакции, должна передаваться в тиын (см. <a data-mention href="/pages/yJXdUQKQdG0AMs3xdPlW">/pages/yJXdUQKQdG0AMs3xdPlW</a>).</p><p>Сумма указывается в теге &#x3C;Amt>, валюта указывается в атрибуте «Ccy».</p><p>Не должно превышать 100 000 000 000 00</p><p><em>Пример: &#x3C;</em>ns0:<em>Amt Ccy="KZT">138640&#x3C;/</em>ns0:<em>Amt></em></p></td></tr><tr><td><p>2.4.1.1</p><p>(атрибут)</p></td><td>CurrencyCode</td><td><p>Ccy</p><p>(атрибут)</p></td><td><br></td><td>Код валюты (буквенный), принимает значение KZT</td></tr><tr><td>2.4.2</td><td>CreditDebitIndicator</td><td>CdtDbtInd</td><td><br></td><td><p>Признак кредита или дебита транзакции:</p><ul><li><strong>CRDT</strong> - кредит</li><li><strong>DBIT</strong> - дебет</li></ul></td></tr><tr><td>2.4.3</td><td>Status</td><td>Sts</td><td><br></td><td><br></td></tr><tr><td>2.4.3.1</td><td>Code</td><td>Cd</td><td><br></td><td><p>Код статуса транзакции. Принимает значения:</p><ul><li><strong>BOOK</strong> – платеж завершен;</li><li><strong>INFO</strong> – платеж не завершен (ошибка при платеже, списание средств не производилось)</li></ul></td></tr><tr><td>2.4.4</td><td>BookingDate</td><td>BookgDt</td><td><br></td><td><br></td></tr><tr><td>2.4.4.1</td><td>DateTime</td><td>DtTm</td><td><br></td><td><p>Если транзакция завершена успешно, то указывается дата принятия банком-получателем (AccptncDtTm (acceptance date time) из pacs.002).</p><p>В случае, если транзакция отклонена, содержит дату создания транзакции на стороне Платформы.</p></td></tr><tr><td>2.4.5</td><td>BankTransactionCode</td><td>BkTxCd</td><td><br></td><td>Тип операции</td></tr><tr><td>2.4.5.1</td><td>Proprietary</td><td>Prtry</td><td><br></td><td><br></td></tr><tr><td>2.4.5.1.1</td><td>Code</td><td>Cd</td><td><br></td><td><p>Код типа операции. Принимает значения:</p><ul><li><strong>C2C2</strong> – для перевода денег от отправителя денег к другому ФЛ в приложении Банка отправителя денег</li><li><strong>M2M</strong> – для перевода денег между своими счетами</li><li><strong>B2C2U</strong> – для перевода денег от ЮЛ на счет ФЛ</li><li><strong>B2C2I</strong> – для перевода денег от ЮЛ на счет ФЛ с проведением идентификации бенефициара</li><li><strong>C2CR</strong> – возврат полученного перевода денег</li><li><strong>C2CR_RTP</strong> – возврат перевода по инициативе отправителя</li><li><strong>C2B2_V2</strong> – оплата по QR-коду </li><li><strong>C2B2E</strong> – оплата по QR-коду в рамках электронной коммерции</li><li><strong>C2B2_RTP</strong> – для выставления счета на оплату ФЛ от ЮЛ</li><li><strong>C2BR_V2</strong> – возврат денег по проведенной ранее оплате за товар/услугу </li><li><strong>C2BRM_V2</strong> – возврат денег по инициативе продавца без участия покупателя</li><li><strong>C2BRE</strong> – возврат денег по проведенной ранее оплате за товар/услугу в рамках электронной коммерции</li></ul></td></tr><tr><td>2.4.6</td><td>EntryReference</td><td>NtryRef</td><td></td><td>Идентификатор транзакции (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>)</td></tr><tr><td>2.4.7</td><td>Charges</td><td>Chrgs</td><td>Опционально</td><td><p>Комиссии. </p><p>Если сведения о комиссии не указаны, это равнозначно тому, что она равна 0. </p></td></tr><tr><td>2.4.7.1</td><td>Record</td><td>Rcrd</td><td></td><td>Информация о комиссии. Массив</td></tr><tr><td>2.4.7.1.1</td><td>Amount</td><td>Amt</td><td></td><td><p>Сумма комиссии, должна передаваться в тиын (см. <a data-mention href="/pages/yJXdUQKQdG0AMs3xdPlW">/pages/yJXdUQKQdG0AMs3xdPlW</a>).</p><p>Сумма указывается в теге &#x3C;Amt>, валюта указывается в атрибуте «Ccy».</p><p><em>Пример: &#x3C;</em>ns0:<em>Amt Ccy="KZT">138640&#x3C;/</em>ns0:<em>Amt></em></p></td></tr><tr><td><p>2.4.7.1.1.1 </p><p>(атрибут)</p></td><td>CurrencyCode</td><td><p>Ccy</p><p>(атрибут)</p></td><td></td><td>Код валюты (буквенный), принимает значение KZT</td></tr><tr><td>2.4.7.1.2</td><td>Type</td><td>Tp</td><td></td><td>Тип комиссии</td></tr><tr><td>2.4.7.1.2.1</td><td>Proprietary</td><td>Prtry</td><td></td><td></td></tr><tr><td>2.4.7.1.2.1.1</td><td>Identification </td><td>Id</td><td></td><td><p>Код типа комиссии. Принимает значения: </p><ul><li><strong>INTERCHANGE_FEE</strong> - интерчейндж</li><li><strong>PROCESSING_FEE</strong> - комиссия за процессинг</li></ul><p>Если сведения о комиссии не указаны, это равнозначно тому, что она равна 0. </p></td></tr><tr><td>2.4.7.1.3</td><td>Agent</td><td>Agt</td><td></td><td>Получатель комиссии</td></tr><tr><td>2.4.7.1.3.1</td><td>FinancialInstitutionIdentification</td><td>FinInstnId</td><td></td><td></td></tr><tr><td>2.4.7.1.3.1.1</td><td>BICFI</td><td>BICFI</td><td>Опционально</td><td><p>БИК банка-получателя комиссии. </p><p>Если получатель комиссии БВУ, то указывается его БИК</p></td></tr><tr><td>2.4.7.1.3.1.2</td><td>Name</td><td>Nm</td><td></td><td>Наименование получателя комиссии</td></tr><tr><td>2.4.7.1.3.1.3</td><td>Other</td><td>Othr</td><td>Опционально</td><td>Если получатель комиссии не БВУ, то указывается БИН организации-получателя комиссии</td></tr><tr><td>2.4.7.1.3.1.3.1</td><td>Identification</td><td>Id</td><td></td><td>БИН получателя комиссии</td></tr><tr><td>2.4.7.1.3.1.3.2</td><td>SchemeName</td><td>SchmeNm</td><td></td><td></td></tr><tr><td>2.4.7.1.3.1.3.2.1</td><td>Code</td><td>Cd</td><td></td><td><p>Принимает значение: </p><ul><li>COID - БИН организации</li></ul></td></tr><tr><td>2.4.8</td><td>EntryDetails</td><td>NtryDtls</td><td></td><td><p>Детализированная информацию о транзакции. </p><p>Массив, заполняется один элемент массива</p></td></tr><tr><td>2.4.8.1</td><td>TransactionDetails</td><td>TxDtls</td><td></td><td>Массив, заполняется один элемент массива</td></tr><tr><td>2.4.8.1.1</td><td>References</td><td>Refs</td><td></td><td>Сведения об идентификаторах для транзакции</td></tr><tr><td>2.4.8.1.1.1</td><td>EndToEndIdentification</td><td>EndToEndId</td><td></td><td>Сквозной идентификатор операции</td></tr><tr><td>2.4.8.1.1.2</td><td>TransactionIdentification</td><td>TxId</td><td></td><td>Идентификатор транзакции </td></tr><tr><td>2.4.8.1.2</td><td>RelatedParties</td><td>RltdPties</td><td></td><td></td></tr><tr><td>2.4.8.1.2.1</td><td>Debitor</td><td>Dbtr</td><td>Условно обязательное</td><td>Используется для передачи MCC-кода. Значение передается в блоке <code>Cdtr</code> либо <code>Dbtr</code> в зависимости от стороны операции, являющейся юридическим лицом.</td></tr><tr><td>2.4.8.1.2.1.1</td><td>Party</td><td>Pty</td><td></td><td></td></tr><tr><td>2.4.8.1.2.1.1.1</td><td>Identification</td><td>Id</td><td></td><td>Идентификационные данные. Для ЮЛ и ИП – заполняется тег &#x3C;OrgId>.</td></tr><tr><td>2.4.8.1.2.1.1.1.1</td><td>OrganisationIdentification</td><td>OrgId</td><td></td><td>Идентификационные данные ЮЛ или ИП</td></tr><tr><td>2.4.8.1.2.1.1.1.1.1</td><td>Other</td><td>Othr</td><td></td><td>Массив, в массиве заполняется 1 элемент.</td></tr><tr><td>2.4.8.1.2.1.1.1.1.1.1</td><td>Identification</td><td>Id</td><td></td><td><p>Идентификатор, соответствующий схеме идентификации, указанной в теге &#x3C;SchmeNm>.</p><p><strong>4-значный код категории продавца</strong></p></td></tr><tr><td>2.4.8.1.2.1.1.1.1.1.2</td><td>SchemeName</td><td>SchmeNm</td><td></td><td>Может содержать &#x3C;Prtry></td></tr><tr><td>2.4.8.1.2.1.1.1.1.1.2.1</td><td>Proprietary</td><td>Prtry</td><td></td><td><p>Атрибут идентификации для ЮЛ или ИП: Передается ключ-значение: <strong>MCC.</strong> Пример: <em><code>&#x3C;ns0:</code></em><a data-footnote-ref href="#user-content-fn-1"><em><code>RltdPties</code></em></a><em><code>></code></em></p><p><em><code>&#x3C;ns0:Dbtr></code></em></p><p><em><code>&#x3C;ns0:Pty></code></em></p><p><em><code>&#x3C;ns0:Id></code></em></p><p><em><code>&#x3C;ns0:OrgId></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>3617&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Prtry>MCC&#x3C;/ns0:Prtry></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;/ns0:OrgId></code></em></p><p><em><code>&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;/ns0:Pty></code></em></p><p><em><code>&#x3C;/ns0:Dbtr></code></em></p><p><em><code>&#x3C;ns0:DbtrAcct></code></em></p><p><em><code>&#x3C;ns0:Nm>IBAN счета отправителя&#x3C;/ns0:Nm></code></em></p><p><em><code>&#x3C;/ns0:DbtrAcct></code></em></p><p><em><code>&#x3C;ns0:CdtrAcct></code></em></p><p><em><code>&#x3C;ns0:Nm>IBAN счета бенефициара&#x3C;/ns0:Nm></code></em></p><p><em><code>&#x3C;/ns0:CdtrAcct></code></em></p><p><em><code>&#x3C;/ns0:RltdPties></code></em>         </p></td></tr><tr><td>2.4.8.1.2.2</td><td>DebtorAccount</td><td>DbtrAcct</td><td></td><td>Счет отправителя денег </td></tr><tr><td>2.4.8.1.2.2.1</td><td>Name</td><td>Nm</td><td></td><td>IBAN счета отправителя денег. <strong>Шаблон:^[0-9A-Z]{20}$</strong></td></tr><tr><td>2.4.8.1.2.3</td><td>Creditor</td><td>Cdtr</td><td>Условно обязательно</td><td>Используется для передачи MCC-кода. Значение передается в блоке <code>Cdtr</code> либо <code>Dbtr</code> в зависимости от стороны операции, являющейся юридическим лицом.</td></tr><tr><td>2.4.8.1.2.3.1</td><td>Party</td><td>Pty</td><td></td><td></td></tr><tr><td>2.4.8.1.2.3.1.1</td><td>Identification</td><td>Id</td><td></td><td>Для ЮЛ и ИП – заполняется тег  .</td></tr><tr><td>2.4.8.1.2.3.1.1.1</td><td>OrganisationIdentification</td><td>OrgId</td><td></td><td>Идентификационные данные ЮЛ или ИП</td></tr><tr><td>2.4.8.1.2.3.1.1.1.1</td><td>Other</td><td>Othr</td><td></td><td>Массив, в массиве заполняется 1 элемент.</td></tr><tr><td>2.4.8.1.2.3.1.1.1.1.1</td><td>Identification</td><td>Id</td><td></td><td><p>Идентификатор, соответствующий схеме идентификации, указанной в теге &#x3C;SchmeNm>.</p><p><strong>4-значный код категории продавца</strong></p></td></tr><tr><td>2.4.8.1.2.3.1.1.1.1.2</td><td>SchemeName</td><td>SchmeNm</td><td></td><td>Может содержать &#x3C;Prtry></td></tr><tr><td>2.4.8.1.2.3.1.1.1.1.2.1</td><td>Proprietary</td><td>Prtry</td><td></td><td><p>Атрибут идентификации для ЮЛ или ИП: Передается ключ-значение: <strong>MCC.</strong> Пример: <em><code>&#x3C;ns0:RltdPties></code></em></p><p><em><code>&#x3C;ns0:DbtrAcct></code></em></p><p><em><code>&#x3C;ns0:Nm>IBAN счет отправителя&#x3C;/ns0:Nm></code></em></p><p><em><code>&#x3C;/ns0:DbtrAcct></code></em></p><p><em><code>&#x3C;ns0:Cdtr></code></em></p><p><em><code>&#x3C;ns0:Pty></code></em></p><p><em><code>&#x3C;ns0:Id></code></em></p><p><em><code>&#x3C;ns0:OrgId></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>3617&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Prtry>MCC&#x3C;/ns0:Prtry></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;/ns0:OrgId></code></em></p><p><em><code>&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;/ns0:Pty></code></em></p><p><em><code>&#x3C;/ns0:Cdtr></code></em></p><p><em><code>&#x3C;ns0:CdtrAcct></code></em></p><p><em><code>&#x3C;ns0:Nm>IBAN счет бенефициара&#x3C;/ns0:Nm></code></em></p><p><em><code>&#x3C;/ns0:CdtrAcct></code></em></p><p><em><code>&#x3C;/ns0:RltdPties></code></em></p></td></tr><tr><td>2.4.8.1.2.4</td><td>CreditorAccount</td><td>CdtrAcct</td><td></td><td>Счет бенефициара</td></tr><tr><td>2.4.8.1.2.4.1</td><td>Name</td><td>Nm</td><td></td><td><p>Номер счета бенефициара:</p><ul><li>для операций C2C2, C2B2, C2B2E - IBAN счета бенефициара. <strong>Шаблон:^[0-9A-Z]{20}$</strong></li></ul></td></tr><tr><td>2.4.8.1.3</td><td>RelatedAgents</td><td>RltdAgts</td><td></td><td></td></tr><tr><td>2.4.8.1.3.1</td><td>DebtorAgent</td><td>DbtrAgt</td><td></td><td>Банк отправителя денег</td></tr><tr><td>2.4.8.1.3.1.1</td><td>FinancialInstitutionIdentification</td><td>FinInstnId </td><td></td><td></td></tr><tr><td>2.4.8.1.3.1.1.1</td><td>BICFI</td><td>BICFI</td><td></td><td>БИК банка отправителя денег</td></tr><tr><td>2.4.8.1.3.1.1.2</td><td>Name</td><td>Nm</td><td></td><td>Наименование банка отправителя денег</td></tr><tr><td>2.4.8.1.3.2</td><td>CreditorAgent</td><td>CdtrAgt</td><td></td><td>Банк бенефициара</td></tr><tr><td>2.4.8.1.3.2.1</td><td>FinancialInstitutionIdentification</td><td>FinInstnId </td><td></td><td></td></tr><tr><td>2.4.8.1.3.2.1.1</td><td>BICFI</td><td>BICFI</td><td></td><td>БИК банка бенефициара</td></tr><tr><td>2.4.8.1.3.2.1.2</td><td>Name</td><td>Nm</td><td></td><td>Наименование банка бенефициара</td></tr></tbody></table>

<br>

[^1]:


# Сообщение camt.060

Сообщение camt.060 должно соответствовать XSD-схеме сообщения camt.060.001.06 стандарта ISO20022 и правилам заполнения документа, указанным в таблице ниже. Если поле не отмечено как опциональное, то оно является обязательным.

| №         | Наименование                       | XML-тег     | Опциональность | Описание                                                                                                                                                                                                                                                                                                   |
| --------- | ---------------------------------- | ----------- | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 0         | AccountReportingRequest            | AcctRptgReq | <p><br></p>    | Запрос выписки по счету                                                                                                                                                                                                                                                                                    |
| 1         | GroupHeader                        | GrpHdr      | <p><br></p>    | Заголовок сообщения                                                                                                                                                                                                                                                                                        |
| 1.1       | MessageIdentification              | MsgId       | <p><br></p>    | Идентификатор сообщения (формат должен соответствовать описанному в  [Генерация уникальных идентификаторов для сообщений](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/generaciya-unikalnykh-identifikatorov-dlya-soobshenii))                       |
| 1.2       | CreationDateTime                   | CreDtTm     | <p><br></p>    | <p>Дата и время создания сообщения.</p><p>Указывается в формате UTC (см. <a data-mention href="/pages/nA5tJTQBCyaP9kOrHlzb">/pages/nA5tJTQBCyaP9kOrHlzb</a>)</p>                                                                                                                                           |
| 1.3       | MessageSender                      | MsgSndr     | <p><br></p>    | Отправитель запроса                                                                                                                                                                                                                                                                                        |
| 1.3.1     | Agent                              | Agt         | <p><br></p>    | <p><br></p>                                                                                                                                                                                                                                                                                                |
| 1.3.1.1   | FinancialInstitutionIdentification | FinInstnId  | <p><br></p>    | <p><br></p>                                                                                                                                                                                                                                                                                                |
| 1.3.1.1.1 | Name                               | Nm          | <p><br></p>    | Идентификатор, присвоенный Банку или финансовой организации Платформой (см. [Получение информации о банках и статусе API](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/poluchenie-informacii-o-bankakh-i-statuse-api)).                              |
| 2         | ReportingRequest                   | RptgReq     | <p><br></p>    | <p>Запрос выписки.</p><p>Массив, заполняется один элемент массива</p>                                                                                                                                                                                                                                      |
| 2.1       | Identification                     | Id          | <p><br></p>    | <p>Идентификатор выписки (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>), сквозной идентификатор. </p><p>Соответствует значению HTTP заголовка end-to-end-id</p>                                                          |
| 2.2       | RequestedMessageNameIdentification | ReqdMsgNmId | <p><br></p>    | Принимает значение **camt.053.001.11**                                                                                                                                                                                                                                                                     |
| 2.3       | AccountOwner                       | AcctOwnr    | <p><br></p>    | БВУ-владелец счета                                                                                                                                                                                                                                                                                         |
| 2.3.1     | Agent                              | Agt         | <p><br></p>    | <p><br></p>                                                                                                                                                                                                                                                                                                |
| 2.3.1.1   | FinancialInstitutionIdentification | FinInstnId  | <p><br></p>    | <p><br></p>                                                                                                                                                                                                                                                                                                |
| 2.3.1.1.1 | Name                               | Nm          | <p><br></p>    | Идентификатор, присвоенный Банку или финансовой организации, должно совпадать со значением в MsgSndr (см. [Получение информации о банках и статусе API](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/poluchenie-informacii-o-bankakh-i-statuse-api)) |
| 2.4       | ReportingPeriod                    | RptgPrd     | <p><br></p>    | <p><br></p>                                                                                                                                                                                                                                                                                                |
| 2.4.1     | FromToDate                         | FrToDt      | <p><br></p>    | <p><br></p>                                                                                                                                                                                                                                                                                                |
| 2.4.1.1   | FromDate                           | FrDt        | <p><br></p>    | Дата операционного дня. Предоставляются данные только за один операционный день                                                                                                                                                                                                                            |
| 2.4.2     | Type                               | Tp          | <p><br></p>    | Принимает значение **ALLL**                                                                                                                                                                                                                                                                                |


# Сообщение pacs.002

Сообщение pacs.002 должно соответствовать XSD-схеме сообщения pacs.002.001.13 стандарта ISO20022 и правилам заполнения документа, указанным в таблице ниже. Если поле не отмечено как опциональное, то оно является обязательным.

<table><thead><tr><th>№</th><th>Наименование </th><th>XML-тег</th><th width="149">Опциональность</th><th>Описание</th></tr></thead><tbody><tr><td>0</td><td><p>FIToFIPaymentStatus</p><p>Report </p></td><td><p>FIToFIPmt</p><p>StsRpt </p></td><td><br></td><td>Статус обработки финансовой операции</td></tr><tr><td>1 </td><td>GroupHeader </td><td>GrpHdr </td><td><br></td><td>Заголовок сообщения</td></tr><tr><td>1.1 </td><td>MessageIdentification </td><td>MsgId </td><td><br></td><td>Идентификатор сообщения (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>)</td></tr><tr><td>1.2 </td><td>CreationDateTime </td><td>CreDtTm </td><td><br></td><td><p>Дата и время создания сообщения.</p><p>Указывается в формате UTC (см. <a data-mention href="/pages/nA5tJTQBCyaP9kOrHlzb">/pages/nA5tJTQBCyaP9kOrHlzb</a>)</p></td></tr><tr><td>1.3</td><td>InstructingAgent</td><td>InstgAgt</td><td></td><td>Банк-отправитель данного сообщения</td></tr><tr><td>1.3.1 </td><td>FinancialInstitutionIdentification </td><td>FinInstnId </td><td><br></td><td><br></td></tr><tr><td>1.3.1.1</td><td>Name</td><td>Nm</td><td><br></td><td><p>Идентификатор, присвоенный Банку или финансовой организации Платформой (см. <a data-mention href="/pages/WHfFTzuxkpXfyHNbawjC">/pages/WHfFTzuxkpXfyHNbawjC</a>). </p><p>В сообщениях, сформированных Платформой, будет передаваться в качестве идентификатора Платформы значение - 00000000-0000-0000-0000-000000000000</p></td></tr><tr><td>1.4 </td><td>InstructedAgent </td><td>InstdAgt </td><td><br></td><td>Банк-получатель данного сообщения</td></tr><tr><td>1.4.1 </td><td>FinancialInstitutionIdentification </td><td>FinInstnId </td><td><br></td><td><br></td></tr><tr><td>1.4.1.1</td><td>Name</td><td>Nm</td><td><br></td><td>Идентификатор, присвоенный Банку или финансовой организации Платформой (см. <a data-mention href="/pages/WHfFTzuxkpXfyHNbawjC">/pages/WHfFTzuxkpXfyHNbawjC</a>)</td></tr><tr><td>2 </td><td>TransactionInformationAndStatus </td><td>TxInfAndSts </td><td><br></td><td><p>Статус обработки транзакции.</p><p>Массив, заполняется один элемент массива</p></td></tr><tr><td>2.1</td><td>OriginalEndToEndIdentification </td><td>OrgnlEndToEndId </td><td><br></td><td><p>Сквозной идентификатор для всей цепочки сообщений в рамках данной операции (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>).</p><p>Соответствует сквозному идентификатору из исходного запроса. </p><p>Соответствует значению HTTP заголовка end-to-end-id</p></td></tr><tr><td>2.2 </td><td>OriginalTransactionIdentification </td><td>OrgnlTxId </td><td><p><br>Условно обязательный </p><p>(в ответе от Платформы тег может отсутствовать в случае, если сообщение отправлено в ответ на <code>pacs.028</code> до <code>pacs.008/004</code>)</p></td><td><p>Идентификатор транзакции (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>).</p><p>Соответствует идентификатору транзакции из исходного запроса. </p><p>Примечание: В ответе от Платформы тег может отсутствовать в случае, если сообщение отправляется по операции, в рамках которой еще не направлялось сообщение  <code>pacs.008/004</code> </p></td></tr><tr><td>2.3 </td><td>TransactionStatus </td><td>TxSts </td><td><br></td><td><p>Статус обработки транзакции. Принимает значения:</p><ul><li><strong>PDNG</strong> – в обработке</li><li><strong>RJCT</strong> – отклонена</li><li><strong>ACSC</strong> – успешно завершена</li></ul></td></tr><tr><td>2.4 </td><td>StatusReasonInformation </td><td>StsRsnInf </td><td>Опционально</td><td><p>Опционально, обязательно заполняется в случае TxSts=RJCT (транзакция отклонена).</p><p><strong>Используется только для TxSts=RJCT (отклоненных транзакций)</strong>.</p><p>Массив, заполняется только один элемент массива</p></td></tr><tr><td>2.4.1 </td><td>Reason </td><td>Rsn </td><td><br></td><td>Причина отклонения транзакции</td></tr><tr><td>2.4.1.1 </td><td>Proprietary </td><td>Prtry </td><td><br></td><td><p>Код причины отклонения транзакции.</p><p>Возможные значения см. в  <a data-mention href="/pages/GNLjZsETLk55q8e2bQPE">/pages/GNLjZsETLk55q8e2bQPE</a></p></td></tr><tr><td>2.4.2</td><td>AdditionalInformation</td><td>AddtlInf</td><td></td><td><p>Описание ошибки. Массив, заполняется один элемент массива. </p><p>Максимальная длина: 105 символов</p></td></tr><tr><td>2.5</td><td>ChargesInformation</td><td>ChrgsInf</td><td>Опционально</td><td><p>Комиссии. </p><p>Массив</p></td></tr><tr><td>2.5.1</td><td>Amount</td><td>Amt</td><td></td><td><p>Сумма комиссии, должна передаваться в тиын (см. <a data-mention href="/pages/yJXdUQKQdG0AMs3xdPlW">/pages/yJXdUQKQdG0AMs3xdPlW</a>).</p><p>Сумма указывается в теге &#x3C;Amt>, валюта указывается в атрибуте «Ccy».</p><p><em>Пример: &#x3C;ns0:Amt Ccy="KZT">12342&#x3C;/ns0:Amt></em></p></td></tr><tr><td><p>2.5.1.1 </p><p>(атрибут)</p></td><td>CurrencyCode</td><td><p>Ccy</p><p>(атрибут)</p></td><td></td><td>Код валюты (буквенный), принимает значение KZT</td></tr><tr><td>2.5.2</td><td>Agent</td><td>Agt</td><td></td><td>Получатель комиссии</td></tr><tr><td>2.5.2.1</td><td>FinancialInstitutionIdentification</td><td>FinInstnId</td><td></td><td></td></tr><tr><td>2.5.2.1.1</td><td>BICFI</td><td>BICFI</td><td>Опционально</td><td><p>БИК банка-получателя комиссии. </p><p>Если получатель комиссии БВУ, то указывается его БИК</p></td></tr><tr><td>2.5.2.1.2</td><td>Name</td><td>Nm</td><td></td><td>Наименование получателя комиссии</td></tr><tr><td>2.5.2.1.3</td><td>Other</td><td>Othr</td><td>Опционально</td><td>Если получатель комиссии не БВУ, то указывается БИН организации-получателя комиссии</td></tr><tr><td>2.5.2.1.3.1</td><td>Identification</td><td>Id</td><td></td><td>БИН получателя комиссии</td></tr><tr><td>2.5.2.1.3.2</td><td>SchemeName</td><td>SchmeNm</td><td></td><td></td></tr><tr><td>2.5.2.1.3.2.1</td><td>Code</td><td>Cd</td><td></td><td><p></p><p>Принимает значение: </p><ul><li>COID - БИН организации</li></ul></td></tr><tr><td>2.5.3</td><td>Type</td><td>Tp</td><td></td><td>Тип комиссии</td></tr><tr><td>2.5.3.1</td><td>Proprietary</td><td>Prtry</td><td></td><td></td></tr><tr><td>2.5.3.1.1</td><td>Identification </td><td>Id</td><td></td><td><p>Код типа комиссии. Принимает значения: </p><ul><li><strong>INTERCHANGE_FEE</strong> - интерчейндж</li><li><strong>PROCESSING_FEE</strong> - комиссия за процессинг</li></ul><p>Если сведения о комиссии не указаны, это равнозначно тому, что она равна 0. </p></td></tr><tr><td>2.6</td><td>AcceptanceDateTime</td><td>AccptncDtTm</td><td>Опционально</td><td><p>Дата и время принятия. Опционально, заполняется только если pacs.002 отправляется в ответ на pacs.008/pacs.004.</p><p></p><p>Не заполняется, если:</p><ul><li>не доставлен pacs.008/pacs.004 до банка бенефициара,</li><li>Платформа возвращает: <code>PACS_002_NET_POSITION_LIMIT_REACHED</code> / <code>PACS_002_SENDING_TO_CREDITOR_ERROR</code> </li><li>Платформа отправляет pacs.002 в ответ на pacs.028.</li></ul><p>Заполняется, если:</p><ul><li>возвращен pacs.002 со статусом PDNG/ACSC,</li><li>банк бенефициар возвращает pacs.002 со статусом RJCT.</li></ul><p>Указывается в формате UTC (см. <a data-mention href="/pages/nA5tJTQBCyaP9kOrHlzb">/pages/nA5tJTQBCyaP9kOrHlzb</a>)</p></td></tr><tr><td>2.7</td><td>ProcessingDate </td><td>PrcgDt</td><td>Опционально</td><td><p>Дата опер. дня, в который вошла исходная транзакция </p><p>Заполняется только Платформой (<em>поле банки заполнять не должны</em>) в случае, когда она отправляет финальное сообщение PACS.002 со статусом <strong>ACSC</strong></p></td></tr><tr><td>2.7.1</td><td>Date</td><td>Dt</td><td></td><td>Дата опер. дня</td></tr><tr><td>2.8</td><td>OriginalTransactionReference</td><td>OrgnlTxRef</td><td>Опционально</td><td>Заполняется   только Платформой.  Значения, отправленные в этом поле БВУ, Платформой будут игнорироваться</td></tr><tr><td>2.8.1</td><td>PaymentTypeInformation</td><td>PmtTpInf</td><td></td><td></td></tr><tr><td>2.8.1.1</td><td>CategoryPurpose</td><td>CtgyPurp</td><td></td><td><p>Тип операции. </p><p>Заполняется   только Платформой.  Значения, отправленные в этом поле БВУ, Платформой будут игнорироваться. </p><p></p><p><em>*В случае отправки сообщения pacs.028 до pacs.004/008 значение типа операции в сообщении pacs.002 в поле "CtgyPurp.Prtry" может отсутствовать, так как на данном этапе тип операции еще не определен.</em></p></td></tr><tr><td>2.8.1.1.1</td><td>Proprietary</td><td>Prtry</td><td></td><td><p>Код типа операции. Принимает значения:</p><ul><li><strong>C2C2</strong> – для перевода денег от отправителя денег к другому ФЛ в приложении Банка отправителя денег</li><li><strong>M2M</strong> – для перевода денег между своими счетами</li><li><strong>B2C2U</strong> – для перевода денег от ЮЛ на счет ФЛ</li><li><strong>B2C2I</strong> – для перевода денег от ЮЛ на счет ФЛ с проведением идентификации бенефициара</li><li><strong>C2CR</strong> – возврат полученного перевода денег</li><li><strong>C2CR_RTP</strong> – возврат перевода по инициативе отправителя</li><li><strong>C2B2_V2</strong> – оплата по QR-коду </li><li><strong>C2B2E</strong> – оплата по QR-коду в рамках электронной коммерции</li><li><strong>C2B2_RTP</strong> – для выставления счета на оплату ФЛ от ЮЛ</li><li><strong>C2BR_V2</strong> – возврат денег по проведенной ранее оплате за товар/услугу </li><li><strong>C2BRM_V2</strong> – возврат денег по инициативе продавца без участия покупателя</li><li><strong>C2BRE</strong> – возврат денег по проведенной ранее оплате за товар/услугу в рамках электронной коммерции</li></ul></td></tr></tbody></table>


# Сообщение pacs.004

4 должно соответствовать XSD-схеме сообщения pacs.004.001.12 стандарта ISO20022 и правилам заполнения документа, указанным в таблице ниже. Если поле не отмечено как опциональное, то оно является обязательным.

<table><thead><tr><th width="149">№ </th><th>Наименование</th><th>XML-тег</th><th>Опциональность</th><th>Описание</th></tr></thead><tbody><tr><td>0 </td><td>PaymentReturn</td><td>PmtRtr</td><td><br></td><td>Запрос возврата денежных средств</td></tr><tr><td>1 </td><td>GroupHeader </td><td>GrpHdr </td><td><br></td><td>Заголовок сообщения</td></tr><tr><td>1.1 </td><td>MessageIdentification </td><td>MsgId </td><td><br></td><td>Идентификатор сообщения (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>)</td></tr><tr><td>1.2</td><td>CreationDateTime </td><td>CreDtTm </td><td><br></td><td><p>Дата и время создания сообщения.</p><p>Указывается в формате UTC (см. <a data-mention href="/pages/nA5tJTQBCyaP9kOrHlzb">/pages/nA5tJTQBCyaP9kOrHlzb</a>)</p></td></tr><tr><td>1.3</td><td>NumberOfTransactions </td><td>NbOfTxs </td><td><br></td><td>Принимает значение <strong>1</strong> </td></tr><tr><td>1.4</td><td>SettlementInformation </td><td>SttlmInf </td><td><br></td><td>Информация о переводе/платеже</td></tr><tr><td>1.4.1 </td><td>SettlementMethod </td><td>SttlmMtd </td><td><br></td><td>Принимает значение <strong>CLRG</strong></td></tr><tr><td>1.4.2</td><td>ClearingSystem</td><td>ClrSys</td><td><br></td><td>Платежная система</td></tr><tr><td>1.4.2.1</td><td>Proprietary</td><td>Prtry</td><td><br></td><td>Должен содержать значение: <strong>KZOBG</strong></td></tr><tr><td>1.5</td><td>InstructingAgent</td><td>InstgAgt</td><td><br></td><td>Банк-отправитель данного сообщения</td></tr><tr><td>1.5.1 </td><td>FinancialInstitutionIdentification</td><td>FinInstnId </td><td><br></td><td><br></td></tr><tr><td>1.5.1.1</td><td>Name</td><td>Nm</td><td><br></td><td>Идентификатор, присвоенный Банку или финансовой организации Платформой (см. <a data-mention href="/pages/WHfFTzuxkpXfyHNbawjC">/pages/WHfFTzuxkpXfyHNbawjC</a>)</td></tr><tr><td>1.6</td><td>InstructedAgent </td><td>InstdAgt </td><td><br></td><td><br></td></tr><tr><td>1.6.1 </td><td>FinancialInstitutionIdentification</td><td>FinInstnId </td><td><br></td><td>Банк-получатель данного сообщения</td></tr><tr><td>1.6.1.1</td><td>Name</td><td>Nm</td><td><br></td><td>Идентификатор, присвоенный Банку или финансовой организации Платформой (см. <a data-mention href="/pages/WHfFTzuxkpXfyHNbawjC">/pages/WHfFTzuxkpXfyHNbawjC</a>)</td></tr><tr><td>2</td><td>TransactionInformation</td><td>TxInf</td><td><br></td><td><p>Информация о транзакции.</p><p>Массив, заполняется один элемент массива</p></td></tr><tr><td>2.1</td><td>ReturnIdentification</td><td>RtrId</td><td><br></td><td>Идентификатор транзакции на возврат денег (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>)</td></tr><tr><td>2.2</td><td>OriginalInstructionIdentification</td><td>OrgnlInstrId</td><td><br></td><td><p>Сквозной идентификатор для всей цепочки сообщений в рамках данной операции возврата денег (используется в качестве EndToEndId в последующей цепочке сообщений)  (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>). </p><p>Соответствует значению HTTP заголовка end-to-end-id</p></td></tr><tr><td>2.3</td><td>OriginalEndToEndIdentification </td><td>OrgnlEndToEndId</td><td><br></td><td>Соответствует  сквозному идентификатору из исходного запроса  (pacs.008) Формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a></td></tr><tr><td>2.4</td><td>OriginalTransactionIdentification </td><td>OrgnlTxId</td><td><br></td><td><p>Соответствует  идентификатору транзакции из исходного запроса (pacs.008). </p><p>Формат должен соответствовать описанному в   <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a></p></td></tr><tr><td>2.5</td><td>OriginalInterbankSettlementDate</td><td>OrgnlIntrBkSttlmDt</td><td>Опционально</td><td>Дата операционного дня обработки исходной транзакции. Указывается в формате ISODate (см. <a href="https://docs.npck.kz/mezhbankovskaya-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/format-daty-i-vremeni-v-biznes-soobshenii-isodatetime-i-isodate">Формат даты и времени в бизнес сообщении (ISODateTime и ISODate)</a>).</td></tr><tr><td>2.6</td><td>PaymentTypeInformation </td><td>PmtTpInf </td><td><br></td><td>Тип операции</td></tr><tr><td>2.6.1</td><td>CategoryPurpose </td><td>CtgyPurp </td><td><br></td><td><br></td></tr><tr><td>2.6.1.1</td><td>Proprietary </td><td>Prtry </td><td><br></td><td><p>Код типа операции. Принимает значения:</p><ul><li><strong>C2CR</strong> – возврат полученного перевода денег</li><li><strong>C2CR_RTP</strong> – возврат перевода по инициативе отправителя</li><li><strong>C2BR_V2</strong> – возврат денег по проведенной ранее оплате за товар/услугу </li><li><strong>C2BRM_V2</strong> – возврат денег по инициативе продавца без участия покупателя</li><li><strong>C2BRE</strong> – возврат денег по проведенной ранее оплате за товар/услугу в рамках электронной коммерции</li></ul></td></tr><tr><td>2.7</td><td>ReturnedInterbankSettlementAmount</td><td>RtrdIntrBkSttlmAmt</td><td><br></td><td><p>Сумма возврата, должна передаваться в тиын (см. <a data-mention href="/pages/yJXdUQKQdG0AMs3xdPlW">/pages/yJXdUQKQdG0AMs3xdPlW</a>).</p><p>Сумма указывается в теге &#x3C;RtrdIntrBkSttlmAmt>, валюта перевода указывается в атрибуте «Ccy».</p><p>Не должно превышать 100 000 000 000 00.</p><p><em>Пример: &#x3C;ns0:RtrdIntrBkSttlmAmt Ccy="KZT">138640&#x3C;/ns0:RtrdIntrBkSttlmAmt></em></p></td></tr><tr><td><p>2.7.1</p><p>(атрибут)</p></td><td>CurrencyOfTransfer</td><td><p>Ccy</p><p>(атрибут)</p></td><td><br></td><td>Код валюты (буквенный), принимает значение <strong>KZT</strong></td></tr><tr><td>2.8</td><td>ChargeBearer </td><td>ChrgBr </td><td><br></td><td>Плательщик комиссии. Принимает значение <strong>SLEV</strong></td></tr><tr><td>2.9</td><td>ReturnChain</td><td>RtrChain</td><td><br></td><td><br></td></tr><tr><td>2.9.1</td><td>Debtor </td><td>Dbtr </td><td><br></td><td><p>Отправитель денег.</p><p>В зависимости от типа операции может содержать данные ФЛ, ЮЛ, ИП (см. тег &#x3C;PmtTpInf> -> &#x3C;CtgyPurp> -> &#x3C;Prtry>):</p><ul><li>для C2CR – <strong>содержит данные ФЛ</strong>, осуществляющего возврат перевода</li><li>для C2BR, C2BR_V2 – <strong>содержит данные ЮЛ или ИП</strong>, осуществляющего возврат  денег по совершенной покупке/ оплате</li></ul></td></tr><tr><td>2.9.1.1</td><td>Party</td><td>Pty</td><td><br></td><td><br></td></tr><tr><td>2.9.1.1.1 </td><td>Name </td><td>Nm </td><td><br></td><td><p>Может указываться:</p><ul><li><strong>ФИО отправителя денег</strong> – для ФЛ</li><li><strong>Наименование</strong> – для ЮЛ и ИП</li></ul><p>Максимальная длина: 140 символов</p></td></tr><tr><td>2.9.1.1.2</td><td>Identification </td><td>Id </td><td><br></td><td><p>Идентификационные данные отправителя денег.</p><p>Заполняется только один из тегов &#x3C;PrvtId> или &#x3C;OrgId>:</p><ul><li>Для ФЛ – заполняется тег &#x3C;PrvtId>.</li><li>Для ЮЛ и ИП – заполняется тег &#x3C;OrgId>.</li></ul></td></tr><tr><td>2.9.1.1.2.1 </td><td>PrivateIdentification</td><td>PrvtId</td><td>Условно обязательно</td><td>Идентификационные данные ФЛ</td></tr><tr><td>2.9.1.1.2.1.1</td><td>Other</td><td>Othr</td><td><br></td><td><p>Массив, в массиве заполняются три элемента.</p><p></p><p><em>Пример:</em></p><pre class="language-xml" data-overflow="wrap"><code class="lang-xml">&#x3C;ns0:PrvtId>
							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>313407829711&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Cd>NIDN&#x3C;/ns0:Cd>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>1&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Prtry>IRS&#x3C;/ns0:Prtry>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>9&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Prtry>SECO&#x3C;/ns0:Prtry>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
						&#x3C;/ns0:PrvtId>
</code></pre></td></tr><tr><td>2.9.1.1.2.1.1.1</td><td>Identification</td><td>Id</td><td><br></td><td><p>Идентификатор, соответствующий схеме идентификации, указанной в теге &#x3C;SchmeNm>.</p><p>Максимальная длина: 35 символов</p></td></tr><tr><td>2.9.1.1.2.1.1.2</td><td>SchemeName</td><td>SchmeNm</td><td><br></td><td>Может содержать только один из тегов &#x3C;Cd> или &#x3C;Prtry></td></tr><tr><td>2.9.1.1.2.1.1.2.1</td><td>Code</td><td>Cd</td><td>Тег используется для указания кода типа документа</td><td><p>Код типа документа </p><ul><li><strong>NIDN</strong> – ИИН (обязателен для резидентов и нерезидентов при наличии ИИН; <em>при указании ИИН поле CCPT не заполняется);</em></li><li><strong>CCPT</strong> – документ, удостоверяющий личность для нерезидентов в случае отсутствия ИИН.</li></ul><p><br><em>Примечание: В теге &#x3C;Id> указывается соответственно ИИН  (длина - 12 символов) либо номер документа, удостоверяющего личность</em></p></td></tr><tr><td>2.9.1.1.2.1.1.2.2</td><td>Proprietary</td><td>Prtry</td><td>Тег используется для передачи дополнительных атрибутов идентификации ФЛ</td><td><p>Дополнительные атрибуты идентификации для физического лица:</p><ul><li><strong>IRS</strong> – признак резидентства </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение: 1 – резидент, 2 – нерезидент</em></p><ul><li><strong>SECO</strong> – сектор экономики </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение сектора экономики (</em>принимает значение от 1 до 9)<em>, например: 9 – домашние хозяйства</em></p></td></tr><tr><td>2.9.1.1.2.2</td><td>OrganisationIdentification  </td><td>OrgId </td><td>Условно обязательно</td><td>Идентификационные данные ЮЛ или ИП</td></tr><tr><td>2.9.1.1.2.2.1</td><td>Other</td><td>Othr</td><td><br></td><td><p>Массив, в массиве заполняются шесть элементов.</p><p><em>Пример заполнения:</em></p><p><em><code>&#x3C;ns0:OrgId></code></em></p><p>   <em><code>&#x3C;ns0:Othr></code></em></p><p>      <em><code>&#x3C;ns0:Id>600100277300&#x3C;/ns0:Id></code></em></p><p>      <em><code>&#x3C;ns0:SchmeNm></code></em></p><p>         <em><code>&#x3C;ns0:Prtry>COID&#x3C;/ns0:Prtry></code></em></p><p>      <em><code>&#x3C;/ns0:SchmeNm></code></em></p><p>   <em><code>&#x3C;/ns0:Othr></code></em></p><p>   <em><code>&#x3C;ns0:Othr></code></em></p><p>      <em><code>&#x3C;ns0:Id>1&#x3C;/ns0:Id></code></em></p><p>      <em><code>&#x3C;ns0:SchmeNm></code></em></p><p>         <em><code>&#x3C;ns0:Prtry>IRS&#x3C;/ns0:Prtry></code></em></p><p>      <em><code>&#x3C;/ns0:SchmeNm></code></em></p><p>   <em><code>&#x3C;/ns0:Othr></code></em></p><p>   <em><code>&#x3C;ns0:Othr></code></em></p><p>      <em><code>&#x3C;ns0:Id>7&#x3C;/ns0:Id></code></em></p><p>      <em><code>&#x3C;ns0:SchmeNm></code></em></p><p>         <em><code>&#x3C;ns0:Prtry>SECO&#x3C;/ns0:Prtry></code></em></p><p>      <em><code>&#x3C;/ns0:SchmeNm></code></em></p><p>   <em><code>&#x3C;/ns0:Othr></code></em></p><p>   <em><code>&#x3C;ns0:Othr></code></em></p><p>      <em><code>&#x3C;ns0:Id>f810639431e4423f982737abaffb03c5&#x3C;/ns0:Id></code></em></p><p>      <em><code>&#x3C;ns0:SchmeNm></code></em></p><p>         <em><code>&#x3C;ns0:Prtry>POSID&#x3C;/ns0:Prtry></code></em></p><p>      <em><code>&#x3C;/ns0:SchmeNm></code></em></p><p>   <em><code>&#x3C;/ns0:Othr></code></em></p><p>   <em><code>&#x3C;ns0:Othr></code></em></p><p>      <em><code>&#x3C;ns0:Id>5814&#x3C;/ns0:Id></code></em></p><p>      <em><code>&#x3C;ns0:SchmeNm></code></em></p><p>         <em><code>&#x3C;ns0:Prtry>MCC&#x3C;/ns0:Prtry></code></em></p><p>      <em><code>&#x3C;/ns0:SchmeNm></code></em></p><p>   <em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p> <em>     <code>&#x3C;ns0:Id>1&#x3C;/ns0:Id></code></em></p><p>      <em><code>&#x3C;ns0:SchmeNm></code></em></p><p>         <em><code>&#x3C;ns0:Prtry>SME&#x3C;/ns0:Prtry></code></em></p><p>      <em><code>&#x3C;/ns0:SchmeNm></code></em></p><p>   <em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;/ns0:OrgId></code></em></p></td></tr><tr><td>2.9.1.1.2.2.1.1</td><td>Identification</td><td>Id</td><td><br></td><td><p>Идентификатор, соответствующий схеме идентификации, указанной в теге &#x3C;SchmeNm>.</p><p>Максимальная длина: 35 символов</p></td></tr><tr><td>2.9.1.1.2.2.1.2</td><td>SchemeName</td><td>SchmeNm</td><td><br></td><td>Может содержать только один из тегов &#x3C;Cd> или &#x3C;Prtry></td></tr><tr><td>2.9.1.1.2.2.1.2.1</td><td>Proprietary</td><td>Prtry</td><td>Тег используется для передачи дополнительных атрибутов идентификации ЮЛ или ИП</td><td><p>Дополнительные атрибуты идентификации для ЮЛ или ИП:</p><ul><li><p><strong>COID</strong> – идентификатор компании</p><p></p></li></ul><p><em>Примечание: В теге &#x3C;Id> указывается соответственно БИН для ФЛ  (длина - 12 символов) или ИИН  (длина - 12 символов) для ИП</em></p><ul><li><strong>IRS</strong> – признак резидентства </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение: 1 – резидент, 2 – нерезидент</em></p><ul><li><strong>SECO</strong> – сектор экономики </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение сектора экономики (принимает значение от 1 до 9)</em></p><ul><li><strong>POSID</strong> – уникальный идентификатор торговой точки (point of sale identification) </li><li><strong>MCC</strong> – 4-значный код категории продавца</li><li><strong>SME</strong> - признак МСБ</li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение: 0 – не является МСБ, 1 – является МСБ</em></p></td></tr><tr><td>2.9.1.1.2 </td><td>CountryOfResidence </td><td>CtryOfRes </td><td><br></td><td>Страна резидентства. Код страны по ISO 3166 (Alpha-2 code)</td></tr><tr><td>2.9.2</td><td>DebtorAccount </td><td>DbtrAcct </td><td><br></td><td>Счет отправителя денег </td></tr><tr><td>2.9.2.1</td><td>Name</td><td>Nm</td><td><br></td><td>IBAN счета отправителя денег. <strong>Шаблон:^[0-9A-Z]{20}$</strong></td></tr><tr><td>2.9.3</td><td>DebtorAgent </td><td>DbtrAgt </td><td><br></td><td>Банк отправителя денег</td></tr><tr><td>2.9.3.1 </td><td>FinancialInstitutionIdentification</td><td>FinInstnId </td><td><br></td><td><br></td></tr><tr><td>2.9.3.1.1</td><td>BICFI</td><td>BICFI</td><td><br></td><td>БИК банка отправителя денег</td></tr><tr><td>2.9.3.1.2</td><td>Name</td><td>Nm</td><td><br></td><td><p>Полное наименование, включая организационно-правовую форму, банка отправителя денег.</p><p>Максимальная длина: 140 символов</p></td></tr><tr><td>2.9.4</td><td>CreditorAgent </td><td>CdtrAgt </td><td><br></td><td>Банк бенефициара</td></tr><tr><td>2.9.4.1 </td><td>FinancialInstitutionIdentification</td><td>FinInstnId </td><td><br></td><td><br></td></tr><tr><td>2.9.4.1.1</td><td>BICFI</td><td>BICFI</td><td><br></td><td>БИК банка бенефициара</td></tr><tr><td>2.9.4.1.2</td><td>Name</td><td>Nm</td><td><br></td><td><p>Полное наименование, включая организационно-правовую форму, банка бенефициара.</p><p>Максимальная длина: 140 символов</p></td></tr><tr><td>2.9.5</td><td>Creditor </td><td>Cdtr </td><td><br></td><td><p>Бенефициар.</p><p>Содержит данные ФЛ, которому выполняется возврат</p></td></tr><tr><td>2.9.5.1</td><td>Party</td><td>Pty</td><td><br></td><td><br></td></tr><tr><td>2.9.5.1.1 </td><td>Name </td><td>Nm </td><td><br></td><td><p>Имя клиента.</p><p>Максимальная длина: 140 символов. </p><p>Примечание: должно соответствовать значению, указанному для отправителя денег в исходном  pacs.008, по которому был платеж</p></td></tr><tr><td>2.9.5.1.2</td><td>Identification </td><td>Id </td><td><br></td><td>Идентификационные данные бенефициара</td></tr><tr><td>2.9.5.1.2.1 </td><td>PrivateIdentification</td><td>PrvtId</td><td><br></td><td>Идентификационные данные ФЛ</td></tr><tr><td>2.9.5.1.2.1.1</td><td>Other</td><td>Othr</td><td><br></td><td><p>Массив, в массиве заполняются три элемента.</p><p></p><p><em>Пример:</em></p><pre class="language-xml" data-overflow="wrap"><code class="lang-xml">&#x3C;ns0:PrvtId>
							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>313407829781&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Cd>NIDN&#x3C;/ns0:Cd>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>1&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Prtry>IRS&#x3C;/ns0:Prtry>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>9&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Prtry>SECO&#x3C;/ns0:Prtry>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
						&#x3C;/ns0:PrvtId>
</code></pre></td></tr><tr><td>2.9.5.1.2.1.1.1</td><td>Identification</td><td>Id</td><td><br></td><td><p>Идентификатор, соответствующий схеме идентификации, указанной в теге &#x3C;SchmeNm>.</p><p>Максимальная длина: 35 символов</p></td></tr><tr><td>2.9.5.1.2.1.1.2</td><td>SchemeName</td><td>SchmeNm</td><td><br></td><td>Может содержать только один из тегов &#x3C;Cd> или &#x3C;Prtry></td></tr><tr><td>2.9.5.1.2.1.1.2.1</td><td>Code</td><td>Cd</td><td>Тег используется для указания кода типа документа</td><td><p>Код типа документа: </p><ul><li><strong>NIDN</strong> – ИИН (обязателен для резидентов и нерезидентов при наличии ИИН; <em>при указании ИИН поле CCPT не заполняется);</em></li><li><strong>CCPT</strong> – документ, удостоверяющий личность для нерезидентов в случае отсутствия ИИН.</li></ul><p><br><em>Примечание: В теге &#x3C;Id> указывается соответственно ИИН  (длина - 12 символов) либо номер документа, удостоверяющего личность</em></p></td></tr><tr><td>2.9.5.1.2.1.1.2.2</td><td>Proprietary</td><td>Prtry</td><td>Тег используется для передачи дополнительных атрибутов идентификации ФЛ</td><td><p>Дополнительные атрибуты идентификации для физического лица:</p><ul><li><strong>IRS</strong> – признак резидентства </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение: 1 – резидент, 2 – нерезидент;</em></p><ul><li><strong>SECO</strong> – сектор экономики </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение сектора экономики, например (</em>принимает значение от 1 до 9)<em>: 9 – домашние хозяйства</em></p></td></tr><tr><td>2.9.5.1.3</td><td>CountryOfResidence </td><td>CtryOfRes </td><td><br></td><td>Страна резидентства. Код страны по ISO 3166 (Alpha-2 code)</td></tr><tr><td>2.9.6</td><td>CreditorAccount </td><td>CdtrAcct </td><td><br></td><td>Счет бенефициара</td></tr><tr><td>2.9.6.1</td><td>Name</td><td>Nm</td><td><br></td><td>IBAN счета бенефициара. <strong>Шаблон:^[0-9A-Z]{20}$</strong></td></tr><tr><td>2.10</td><td>ReturnReasonInformation</td><td>RtrRsnInf</td><td><br></td><td><p>Информация о причине возврата.</p><p>Массив, заполняется один элемент массива</p></td></tr><tr><td>2.10.1 </td><td>Reason</td><td>Rsn</td><td><br></td><td>Причина возврата</td></tr><tr><td>2.10.1.1</td><td>Code</td><td>Cd</td><td><br></td><td><p>Код причины возврата.</p><p>Возможные значения:</p><ul><li><strong>CUST</strong> – запрос возврата по инициативе клиента.</li><li><strong>DS28</strong> – возврат по техническим причинам.</li><li><strong>FR01</strong> – подозрительная операция, вероятная попытка мошеннических действий (Fraud).</li><li><strong>DUPL</strong> – дублирование платежа.</li><li><strong>FOCR</strong> – иная причина, используется в случае, если другая причина из указанных не применима.</li></ul></td></tr><tr><td>2.11</td><td>OriginalTransactionReference</td><td>OrgnlTxRef</td><td><br></td><td><br></td></tr><tr><td>2.11.1</td><td>RemittanceInformation</td><td>RmtInf </td><td></td><td></td></tr><tr><td>2.11.1.1</td><td>Unstructured</td><td>Ustrd</td><td></td><td><p>Описание цели платежа/перевода для транзакции возврата денежных средств.</p><p>Массив, заполняется один элемент массива.</p><p>Ограничение: не больше 140 символов</p><p><em>По умолчанию: Указывается наименование назначения платежа, соответствующее коду в теге &#x3C;Prtry></em></p></td></tr><tr><td>2.11.2</td><td>Purpose </td><td>Purp </td><td><br></td><td><br></td></tr><tr><td>2.11.2.1</td><td>Proprietary </td><td>Prtry </td><td><br></td><td><p>Код назначения платежа для транзакции возврата денежных средств.</p><p>Значение должно соответствовать правилам, утвержденным Постановлением Правления Национального Банка Республики Казахстан от 31 августа 2016 года № 203 «Об утверждении Правил применения кодов секторов экономики и назначения платежей»</p></td></tr></tbody></table>


# Сообщение pacs.008

Сообщение pacs.008 должно соответствовать XSD-схеме сообщения pacs.008.001.11 стандарта ISO20022 и правилам заполнения документа, указанным в таблице ниже. Если поле не отмечено как опциональное, то оно является обязательным.

<table><thead><tr><th width="149">№ </th><th>Наименование</th><th>XML-тег</th><th>Опциональность</th><th width="152">Описание</th></tr></thead><tbody><tr><td>0 </td><td>FIToFICustomerCredit Transfer </td><td>FIToFICstmrCdtTrf </td><td><br></td><td>Запрос на проведение финансовой операции</td></tr><tr><td>1 </td><td>GroupHeader </td><td>GrpHdr </td><td><br></td><td>Заголовок сообщения</td></tr><tr><td>1.1 </td><td>MessageIdentification </td><td>MsgId </td><td><br></td><td>Идентификатор сообщения (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>)</td></tr><tr><td>1.2</td><td>CreationDateTime </td><td>CreDtTm </td><td><br></td><td><p>Дата и время создания сообщения.</p><p>Указывается в формате UTC (см. <a data-mention href="/pages/nA5tJTQBCyaP9kOrHlzb">/pages/nA5tJTQBCyaP9kOrHlzb</a>)</p></td></tr><tr><td>1.3</td><td>NumberOfTransactions </td><td>NbOfTxs </td><td><br></td><td>Принимает значение: <strong>1</strong> </td></tr><tr><td>1.4</td><td>SettlementInformation </td><td>SttlmInf </td><td><br></td><td>Информация о переводе/платеже</td></tr><tr><td>1.4.1 </td><td>SettlementMethod </td><td>SttlmMtd </td><td><br></td><td>Принимает значение: <strong>CLRG</strong></td></tr><tr><td>1.4.2</td><td>ClearingSystem</td><td>ClrSys</td><td><br></td><td>Платежная система</td></tr><tr><td>1.4.2.1</td><td>Proprietary</td><td>Prtry</td><td><br></td><td>Должен содержать значение: <strong>KZOBG</strong></td></tr><tr><td>1.5</td><td>InstructingAgent</td><td>InstgAgt</td><td><br></td><td>Банк-отправитель данного сообщения</td></tr><tr><td>1.5.1 </td><td>FinancialInstitutionIdentification</td><td>FinInstnId </td><td><br></td><td><br></td></tr><tr><td>1.5.1.1</td><td>Name</td><td>Nm</td><td><br></td><td>Идентификатор, присвоенный Банку или финансовой организации Платформой (см. <a data-mention href="/pages/WHfFTzuxkpXfyHNbawjC">/pages/WHfFTzuxkpXfyHNbawjC</a>)</td></tr><tr><td>1.6 </td><td>InstructedAgent </td><td>InstdAgt </td><td><br></td><td><br></td></tr><tr><td>1.6.1 </td><td>FinancialInstitutionIdentification</td><td>FinInstnId </td><td><br></td><td>Банк-получатель данного сообщения</td></tr><tr><td>1.6.1.1</td><td>Name</td><td>Nm</td><td><br></td><td>Идентификатор, присвоенный Банку или финансовой организации Платформой (см. <a data-mention href="/pages/WHfFTzuxkpXfyHNbawjC">/pages/WHfFTzuxkpXfyHNbawjC</a>)</td></tr><tr><td>2</td><td>CreditTransferTransac tionInformation </td><td>CdtTrfTxInf </td><td><br></td><td><p>Запрос на перевод денег/платеж.</p><p>Массив, заполняется один элемент массива</p></td></tr><tr><td>2.1 </td><td>PaymentIdentification </td><td>PmtId </td><td><br></td><td><br></td></tr><tr><td>2.1.1</td><td>EndToEndIdentification </td><td>EndToEndId </td><td><br></td><td><p>Сквозной идентификатор для всей цепочки сообщений в рамках данной операции (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>). </p><p>Соответствует значению HTTP заголовка end-to-end-id</p></td></tr><tr><td>2.1.2 </td><td>TransactionIdentification </td><td>TxId </td><td><br></td><td>Идентификатор транзакции (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>)</td></tr><tr><td>2.2 </td><td>PaymentTypeInformation </td><td>PmtTpInf </td><td><br></td><td>Тип операции</td></tr><tr><td>2.2.1</td><td>CategoryPurpose </td><td>CtgyPurp </td><td><br></td><td><br></td></tr><tr><td>2.2.1.1</td><td>Proprietary </td><td>Prtry </td><td><br></td><td><p>Код типа операции. Принимает значения:</p><ul><li></li><li><strong>C2C2</strong> – для перевода денег от отправителя денег к другому ФЛ в приложении Банка отправителя денег</li><li><strong>M2M</strong> – для перевода денег между своими счетами</li><li><strong>B2C2U</strong> – для перевода денег от ЮЛ на счет ФЛ</li><li><strong>B2C2I</strong> – для перевода денег от ЮЛ на счет ФЛ с проведением идентификации бенефициара</li><li><strong>C2B2_V2</strong> – оплата по QR-коду </li><li><strong>C2B2E</strong> – оплата по QR-коду в рамках электронной коммерции</li><li><strong>C2BR_RTP</strong> – для выставления счета на оплату ФЛ от ЮЛ</li></ul></td></tr><tr><td>2.3</td><td>InterbankSettlementAmount </td><td>IntrBkSttlmAmt </td><td><br></td><td><p>Сумма перевода/платежа, должна передаваться в тиын (см. <a data-mention href="/pages/yJXdUQKQdG0AMs3xdPlW">/pages/yJXdUQKQdG0AMs3xdPlW</a>).</p><p>Сумма указывается непосредственно в теге, валюта перевода указывается в атрибуте «Ccy».</p><p>Не должно превышать 100 000 000 000 00.</p><p><em>Пример: &#x3C;ns0:IntrBkSttlmAmt Ccy="KZT">138640&#x3C;/ns0:IntrBkSttlmAmt></em></p></td></tr><tr><td><p>2.3.1</p><p>(атрибут)</p></td><td>CurrencyOfTransfer</td><td><p>Ccy</p><p>(атрибут)</p></td><td><br></td><td>Код валюты (буквенный) перевода, принимает значение <em>KZT</em></td></tr><tr><td>2.4 </td><td>ChargeBearer </td><td>ChrgBr </td><td><br></td><td>Плательщик комиссии. Принимает значение <em>SLEV</em></td></tr><tr><td>2.5 </td><td>Debtor </td><td>Dbtr </td><td><br></td><td><p>Отправитель денег.</p><p>Содержит данные ФЛ</p></td></tr><tr><td>2.5.1 </td><td>Name </td><td>Nm </td><td><br></td><td><p>Может указываться:</p><ul><li>ФИО отправителя денег – для ФЛ.</li></ul><p>Максимальная длина: 140 символов</p></td></tr><tr><td>2.5.2</td><td>Identification </td><td>Id </td><td><br></td><td>Идентификационные данные отправителя денег.</td></tr><tr><td>2.5.2.1 </td><td>PrivateIdentification</td><td>PrvtId</td><td><br></td><td>Идентификационные данные ФЛ</td></tr><tr><td>2.5.2.1.1</td><td>Other</td><td>Othr</td><td><br></td><td><p>Массив, в массиве заполняются три элемента.</p><p></p><p><em>Пример:</em></p><pre class="language-xml" data-overflow="wrap"><code class="lang-xml"><strong>&#x3C;ns0:PrvtId>
</strong>							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>313407829711&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Cd>NIDN&#x3C;/ns0:Cd>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>1&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Prtry>IRS&#x3C;/ns0:Prtry>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>9&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Prtry>SECO&#x3C;/ns0:Prtry>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
						&#x3C;/ns0:PrvtId>
</code></pre></td></tr><tr><td>2.5.2.1.1.1</td><td>Identification</td><td>Id</td><td><br></td><td><p>Идентификатор, соответствующий схеме идентификации, указанной в теге &#x3C;SchmeNm>.</p><p>Максимальная длина: 35 символов</p></td></tr><tr><td>2.5.2.1.1.2</td><td>SchemeName</td><td>SchmeNm</td><td><br></td><td>Может содержать только один из тегов &#x3C;Cd> или &#x3C;Prtry></td></tr><tr><td>2.5.2.1.1.2.1</td><td>Code</td><td>Cd</td><td>Тег используется для указания кода типа документа</td><td><p>Код типа документа: </p><ul><li><strong>NIDN</strong> – ИИН (обязателен для резидентов и нерезидентов при наличии ИИН; <em>при указании ИИН поле CCPT не заполняется);</em></li><li><strong>CCPT</strong> – документ, удостоверяющий личность для нерезидентов в случае отсутствия ИИН.</li></ul><p></p><p><em>Примечание:  В теге &#x3C;Id> указывается соответственно ИИН  (длина - 12 символов) либо номер документа, удостоверяющего личность.</em> </p></td></tr><tr><td>2.5.2.1.1.2.2</td><td>Proprietary</td><td>Prtry</td><td>Тег используется для передачи дополнительных атрибутов идентификации ФЛ</td><td><p>Дополнительные атрибуты идентификации для физического лица:</p><ul><li><strong>IRS</strong> – признак резидентства </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение: 1 – резидент, 2 – нерезидент;</em></p><ul><li><strong>SECO</strong> – сектор экономики </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение сектора экономики (принимает значение от 1 до 9), например: 9 – домашние хозяйства</em></p></td></tr><tr><td>2.5.3</td><td>CountryOfResidence </td><td>CtryOfRes </td><td><br></td><td>Страна резидентства. Код страны по ISO 3166 (Alpha-2 code)</td></tr><tr><td>2.6 </td><td>DebtorAccount </td><td>DbtrAcct </td><td><br></td><td>Счет отправителя денег </td></tr><tr><td>2.6.1</td><td>Name</td><td>Nm</td><td><br></td><td>IBAN счета отправителя денег. <strong>Шаблон:^[0-9A-Z]{20}$</strong></td></tr><tr><td>2.7 </td><td>DebtorAgent </td><td>DbtrAgt </td><td><br></td><td>Банк отправителя денег</td></tr><tr><td>2.7.1 </td><td>FinancialInstitutionIdentification</td><td>FinInstnId </td><td><br></td><td><br></td></tr><tr><td>2.7.1.1</td><td>BICFI</td><td>BICFI</td><td><br></td><td>БИК банка отправителя денег</td></tr><tr><td>2.7.1.2</td><td>Name</td><td>Nm</td><td><br></td><td><p>Полное наименование, включая организационно-правовую форму, банка отправителя денег.</p><p>Максимальная длина: 140 символов</p></td></tr><tr><td>2.8 </td><td>CreditorAgent </td><td>CdtrAgt </td><td><br></td><td>Банк бенефициара</td></tr><tr><td>2.8.1 </td><td>FinancialInstitutionIdentification</td><td>FinInstnId </td><td><br></td><td><br></td></tr><tr><td>2.8.1.1</td><td>BICFI</td><td>BICFI</td><td><br></td><td>БИК банка бенефициара</td></tr><tr><td>2.8.1.2</td><td>Name</td><td>Nm</td><td><br></td><td><p>Полное наименование, включая организационно-правовую форму, банка бенефициара.</p><p>Максимальная длина: 140 символов</p></td></tr><tr><td>2.9 </td><td>Creditor </td><td>Cdtr </td><td><br></td><td><p>Бенефициар.</p><p>В зависимости от типа операции может содержать данные ФЛ, ЮЛ, ИП (см. тег &#x3C;PmtTpInf> -> &#x3C;CtgyPurp> -> &#x3C;Prtry>):</p><ul><li>для C2C2, M2M – содержит данные ФЛ</li><li>для C2B2, C2B2E, C2B2_V2 – содержит данные ЮЛ или ИП</li></ul></td></tr><tr><td>2.9.1 </td><td>Name </td><td>Nm </td><td><br></td><td><p>Может указываться:</p><ul><li><strong>ФИО</strong> – для ФЛ</li><li><strong>Наименование</strong> – для ЮЛ и ИП.</li></ul><p>Максимальная длина: 140 символов</p></td></tr><tr><td>2.9.2</td><td>Identification </td><td>Id </td><td><br></td><td><p>Идентификационные данные бенефициара.</p><p>Заполняется только один из тегов &#x3C;PrvtId> или &#x3C;OrgId>.</p><p>Для ФЛ – заполняется тег &#x3C;PrvtId>.</p><p>Для ЮЛ и ИП – заполняется тег &#x3C;OrgId>.</p></td></tr><tr><td>2.9.2.1 </td><td>PrivateIdentification</td><td>PrvtId</td><td>Условно обязательно</td><td>Идентификационные данные ФЛ</td></tr><tr><td>2.9.2.1.1</td><td>Other</td><td>Othr</td><td><br></td><td><p>Массив, в массиве заполняются три элемента.</p><p></p><p><em>Пример:</em></p><pre class="language-xml" data-overflow="wrap"><code class="lang-xml">&#x3C;ns0:PrvtId>
							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>313407829711&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Cd>NIDN&#x3C;/ns0:Cd>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>1&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Prtry>IRS&#x3C;/ns0:Prtry>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
							&#x3C;ns0:Othr>
								&#x3C;ns0:Id>9&#x3C;/ns0:Id>
								&#x3C;ns0:SchmeNm>
									&#x3C;ns0:Prtry>SECO&#x3C;/ns0:Prtry>
								&#x3C;/ns0:SchmeNm>
							&#x3C;/ns0:Othr>
						&#x3C;/ns0:PrvtId>
</code></pre></td></tr><tr><td>2.9.2.1.1.1</td><td>Identification</td><td>Id</td><td><br></td><td>Идентификатор, соответствующий схеме идентификации, указанной в теге &#x3C;SchmeNm>. Максимальная длина: 35 символов</td></tr><tr><td>2.9.2.1.1.2</td><td>SchemeName</td><td>SchmeNm</td><td><br></td><td>Может содержать только один из тегов &#x3C;Cd> или &#x3C;Prtry></td></tr><tr><td>2.9.2.1.1.2.1</td><td>Code</td><td>Cd</td><td>Тег используется для указания кода типа документа</td><td><p>Код типа документа: </p><ul><li><strong>NIDN</strong> – ИИН (обязателен для резидентов и нерезидентов при наличии ИИН; <em>при указании ИИН поле CCPT не заполняется);</em></li><li><strong>CCPT</strong> – документ, удостоверяющий личность для нерезидентов в случае отсутствия ИИН.</li></ul><p><br><em>Примечание:  В теге &#x3C;Id> указывается соответственно ИИН  (длина - 12 символов) либо номер документа, удостоверяющего личность.</em> </p></td></tr><tr><td>2.9.2.1.1.2.2</td><td>Proprietary</td><td>Prtry</td><td>Тег используется для передачи дополнительных атрибутов идентификации ФЛ</td><td><p>Дополнительные атрибуты идентификации для физического лица:</p><ul><li><strong>IRS</strong> – признак резидентства </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение: 1 – резидент, 2 – нерезидент</em></p><ul><li><strong>SECO</strong> – сектор экономики </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение сектора экономики (принимает значение от 1 до 9), например: 9 – домашние хозяйства</em></p></td></tr><tr><td>2.9.2.2</td><td>OrganisationIdentification</td><td>OrgId </td><td>Условно обязательно</td><td>Идентификационные данные ЮЛ или ИП</td></tr><tr><td>2.9.2.2.1</td><td>Other</td><td>Othr</td><td><br></td><td><p>Массив, в массиве заполняются шесть элементов.</p><p><em>Пример заполнения:</em></p><p><em><code>&#x3C;ns0:OrgId></code></em></p><p>   <em><code>&#x3C;ns0:Othr></code></em></p><p>      <em><code>&#x3C;ns0:Id>600100277300&#x3C;/ns0:Id></code></em></p><p>      <em><code>&#x3C;ns0:SchmeNm></code></em></p><p>         <em><code>&#x3C;ns0:Prtry>COID&#x3C;/ns0:Prtry></code></em></p><p>      <em><code>&#x3C;/ns0:SchmeNm></code></em></p><p>   <em><code>&#x3C;/ns0:Othr></code></em></p><p>   <em><code>&#x3C;ns0:Othr></code></em></p><p>      <em><code>&#x3C;ns0:Id>1&#x3C;/ns0:Id></code></em></p><p>      <em><code>&#x3C;ns0:SchmeNm></code></em></p><p>         <em><code>&#x3C;ns0:Prtry>IRS&#x3C;/ns0:Prtry></code></em></p><p>      <em><code>&#x3C;/ns0:SchmeNm></code></em></p><p>   <em><code>&#x3C;/ns0:Othr></code></em></p><p>   <em><code>&#x3C;ns0:Othr></code></em></p><p> <em>     <code>&#x3C;ns0:Id>7&#x3C;/ns0:Id></code></em></p><p>      <em><code>&#x3C;ns0:SchmeNm></code></em></p><p>         <em><code>&#x3C;ns0:Prtry>SECO&#x3C;/ns0:Prtry></code></em></p><p>      <em><code>&#x3C;/ns0:SchmeNm></code></em></p><p>   <em><code>&#x3C;/ns0:Othr></code></em></p><p>   <em><code>&#x3C;ns0:Othr></code></em></p><p>      <em><code>&#x3C;ns0:Id>f810639431e4423f982737abaffb03c5&#x3C;/ns0:Id></code></em></p><p>      <em><code>&#x3C;ns0:SchmeNm></code></em></p><p>         <em><code>&#x3C;ns0:Prtry>POSID&#x3C;/ns0:Prtry></code></em></p><p>      <em><code>&#x3C;/ns0:SchmeNm></code></em></p><p>   <em><code>&#x3C;/ns0:Othr></code></em></p><p>   <em><code>&#x3C;ns0:Othr></code></em></p><p> <em>     <code>&#x3C;ns0:Id>5814&#x3C;/ns0:Id></code></em></p><p>      <em><code>&#x3C;ns0:SchmeNm></code></em></p><p>         <em><code>&#x3C;ns0:Prtry>MCC&#x3C;/ns0:Prtry></code></em></p><p>      <em><code>&#x3C;/ns0:SchmeNm></code></em></p><p>   <em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p> <em>     <code>&#x3C;ns0:Id>1&#x3C;/ns0:Id></code></em></p><p>      <em><code>&#x3C;ns0:SchmeNm></code></em></p><p>         <em><code>&#x3C;ns0:Prtry>SME&#x3C;/ns0:Prtry></code></em></p><p>      <em><code>&#x3C;/ns0:SchmeNm></code></em></p><p>   <em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;/ns0:OrgId></code></em></p></td></tr><tr><td>2.9.2.2.1.1</td><td>Identification</td><td>Id</td><td><br></td><td><p>Идентификатор, соответствующий схеме идентификации, указанной в теге &#x3C;SchmeNm>. </p><p>Максимальная длина: 35 символов</p></td></tr><tr><td>2.9.2.2.1.2</td><td>SchemeName</td><td>SchmeNm</td><td><br></td><td>Может содержать только один из тегов &#x3C;Cd> или &#x3C;Prtry></td></tr><tr><td>2.9.2.2.1.2.1</td><td>Proprietary</td><td>Prtry</td><td>Тег используется для передачи дополнительных атрибутов идентификации ЮЛ или ИП</td><td><p>Дополнительные атрибуты идентификации для ЮЛ или ИП:</p><ul><li><strong>COID</strong> – идентификатор компании</li></ul><p><em>Примечание: В теге &#x3C;Id> указывается соответственно БИН для ФЛ  (длина - 12 символов) или ИИН  (длина - 12 символов) для ИП</em></p><ul><li><strong>IRS</strong> – признак резидентства </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение: 1 – резидент, 2 – нерезидент</em></p><ul><li><strong>SECO</strong> – сектор экономики </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение сектора экономики (принимает значение от 1 до 9)</em></p><ul><li><strong>POSID</strong> – уникальный идентификатор торговой точки (point of sale identification). </li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается соответствующее значение из admi.010 из элемента &#x3C;</em>RptDat<em>a> с ключом &#x3C;POS_ID></em></p><ul><li><strong>MCC</strong> – 4-значный код категории продавца. Указывается на основе соответствующего значения из admi.010 из элемента &#x3C;RptData> с ключом &#x3C;MCC></li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается соответствующее значение из admi.010 из элемента &#x3C;RptData> с ключом &#x3C;MCC></em></p><ul><li><strong>SME</strong> - признак МСБ.</li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение: 0 – не является МСБ, 1 – является МСБ</em>. </p></td></tr><tr><td>2.9.3 </td><td>CountryOfResidence </td><td>CtryOfRes </td><td><br></td><td>Страна резидентства. Код страны по ISO 3166 (Alpha-2 code)</td></tr><tr><td>2.10</td><td>CreditorAccount </td><td>CdtrAcct </td><td><br></td><td>Счет бенефициара</td></tr><tr><td>2.10.1</td><td>Name</td><td>Nm</td><td><br></td><td><p>Указывается идентификатор для счета бенефициара:</p><ul><li>для операций C2C2, M2M, C2B2, C2B2_V2, C2B2E - IBAN счета бенефициара. <strong>Шаблон:^[0-9A-Z]{20}$</strong></li></ul></td></tr><tr><td>2.11</td><td>Purpose </td><td>Purp </td><td><br></td><td><br></td></tr><tr><td>2.11.1 </td><td>Proprietary </td><td>Prtry </td><td><br></td><td><p>Код назначения платежа.</p><p>Значение должно соответствовать правилам, утвержденным Постановлением Правления Национального Банка Республики Казахстан от 31 августа 2016 года № 203 «Об утверждении Правил применения кодов секторов экономики и назначения платежей»</p></td></tr><tr><td>2.12</td><td>RemittanceInformation</td><td>RmtInf  </td><td><br></td><td><br></td></tr><tr><td>2.12.1 </td><td>Unstructured </td><td>Ustrd </td><td><br></td><td><p>Описание цели платежа/перевода денег.</p><p>Массив, заполняется один элемент массива. </p><p>Ограничение: не больше 140 символов</p><p>По умолчанию: Указывается наименование назначения платежа, соответствующее коду в теге &#x3C;Prtry></p></td></tr><tr><td>2.12.2</td><td>Structured</td><td>Strd</td><td>Опционально</td><td><p>Канал транзакции.</p><p>Заполняется, если в admi.010 в элементе &#x3C;RptData> указано значение с ключом &#x3C;MERCHANT_CHANNEL>(Канал транзакции).</p><p>Массив, заполняется один элемент массива</p></td></tr><tr><td>2.12.2.1</td><td>AdditionalRemittanceInformation</td><td>AddtlRmtInf</td><td></td><td><p>Содержит значение, указанное в admi.010 в элементе &#x3C;RptData> с ключом &#x3C;MERCHANT_CHANNEL>(Канал транзакции).</p><p>Массив, заполняется один элемент массива</p></td></tr></tbody></table>


# Сообщение pacs.028

Сообщение pacs.028 должно соответствовать XSD-схеме сообщения pacs.028.001.05 стандарта ISO20022 и правилам заполнения документа, указанным в таблице ниже. Если поле не отмечено как опциональное, то оно является обязательным.

| №       | Наименование                                                          | XML-тег         | Опциональность                                                                                                                                            | Описание                                                                                                                                                                                                                                                                                                                                                            |
| ------- | --------------------------------------------------------------------- | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 0       | Financial Institution to Financial Institution Payment Status Request | FIToFIPmtStsReq | <p><br></p>                                                                                                                                               | Запрос статуса обработки операции                                                                                                                                                                                                                                                                                                                                   |
| 1       | GroupHeader                                                           | GrpHdr          | <p><br></p>                                                                                                                                               | Заголовок сообщения                                                                                                                                                                                                                                                                                                                                                 |
| 1.1     | MessageIdentification                                                 | MsgId           | <p><br></p>                                                                                                                                               | Идентификатор сообщения (формат должен соответствовать описанному в   [Генерация уникальных идентификаторов для сообщений](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/generaciya-unikalnykh-identifikatorov-dlya-soobshenii))                                                                               |
| 1.2     | CreationDateTime                                                      | CreDtTm         | <p><br></p>                                                                                                                                               | <p>Дата и время создания сообщения.</p><p>Указывается в формате UTC (см. <a data-mention href="/pages/nA5tJTQBCyaP9kOrHlzb">/pages/nA5tJTQBCyaP9kOrHlzb</a>)</p>                                                                                                                                                                                                    |
| 1.3     | InstructingAgent                                                      | InstgAgt        | <p><br></p>                                                                                                                                               | Банк-отправитель данного сообщения                                                                                                                                                                                                                                                                                                                                  |
| 1.3.1   | FinancialInstitutionIdentification                                    | FinInstnId      | <p><br></p>                                                                                                                                               | <p><br></p>                                                                                                                                                                                                                                                                                                                                                         |
| 1.3.1.1 | Name                                                                  | Nm              | <p><br></p>                                                                                                                                               | Идентификатор, присвоенный Банку или финансовой организации Платформой (см. [Получение информации о банках и статусе API](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/poluchenie-informacii-o-bankakh-i-statuse-api))                                                                                        |
| 2       | TransactionInformation                                                | TxInf           | <p><br></p>                                                                                                                                               | <p>Данные запрашиваемой операции.</p><p>Массив, заполняется один элемент массива</p>                                                                                                                                                                                                                                                                                |
| 2.1     | OriginalEndToEndIdentification                                        | OrgnlEndToEndId |                                                                                                                                                           | <p>Сквозной идентификатор для всей цепочки сообщений(формат должен соответствовать описанному в <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/generaciya-unikalnykh-identifikatorov-dlya-soobshenii">Генерация уникальных идентификаторов для сообщений</a>).</p><p>Соответствует значению HTTP заголовка end-to-end-id</p>           |
| 2.2     | OriginalTransactionIdentification                                     | OrgnlTxId       | <p><br>Условно обязательный</p><p>(Если сообщение отправляется до <code>pacs.008/004</code> то тег необязательный к заполнению, иначе - обязательный)</p> | <p>Идентификатор транзакции (формат должен соответствовать описанному в  <a data-mention href="/pages/s5MxzFtnHpHNgStDruwy">/pages/s5MxzFtnHpHNgStDruwy</a>).  </p><p>Примечание: Если сообщение отправляется по операции, в рамках которой еще не направлялось сообщение  <code>pacs.008/004</code> , то тег необязательный к заполнению, иначе - обязательный</p> |

<br>


# Сообщение pain.013

Сообщение pain.013 «Запрос на проведение финансовой операции» должно соответствовать XSD-схеме сообщения pain.013.001.11 стандарта ISO20022 и правилам заполнения документа, указанным в таблице ниже. Если поле не отмечено как опциональное, то оно является обязательным.

<table data-header-hidden><thead><tr><th width="126.4444580078125" valign="top"></th><th width="167.7777099609375" valign="top"></th><th width="87.9720458984375" valign="top"></th><th width="161.361083984375" valign="top"></th><th valign="top"></th></tr></thead><tbody><tr><td valign="top"><strong>№</strong></td><td valign="top"><strong>Наименование</strong></td><td valign="top"><strong>XML-тег</strong></td><td valign="top"><strong>Опциональность</strong></td><td valign="top"><strong>Описание</strong></td></tr><tr><td valign="top">0</td><td valign="top">CreditorPaymentActiv ationRequest</td><td valign="top">CdtrPmtActvtnReq</td><td valign="top"> </td><td valign="top">Запрос на проведение финансовой операции.</td></tr><tr><td valign="top">1</td><td valign="top">GroupHeader</td><td valign="top">GrpHdr</td><td valign="top"> </td><td valign="top">Заголовок сообщения</td></tr><tr><td valign="top">1.1</td><td valign="top">MessageIdentification</td><td valign="top">MsgId</td><td valign="top"> </td><td valign="top">Идентификатор сообщения (формат должен соответствовать описанному в <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/generaciya-unikalnykh-identifikatorov-dlya-soobshenii">Генерация уникальных идентификаторов для сообщений</a>)</td></tr><tr><td valign="top">1.2</td><td valign="top">CreationDateTime</td><td valign="top">CreDtTm</td><td valign="top"> </td><td valign="top"><p>Дата и время создания сообщения.</p><p>Указывается в формате UTC (см. <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/format-daty-i-vremeni-v-biznes-soobshenii-isodatetime-i-isodate">Формат даты и времени в бизнес сообщении (ISODateTime и ISODate)</a>)</p></td></tr><tr><td valign="top">1.3</td><td valign="top">NumberOfTransactions</td><td valign="top">NbOfTxs</td><td valign="top"> </td><td valign="top">Принимает значение: 1</td></tr><tr><td valign="top">1.4</td><td valign="top">InitiatingParty</td><td valign="top">InitgPty</td><td valign="top"> </td><td valign="top">Банк-отправитель данного сообщения</td></tr><tr><td valign="top">1.4.1</td><td valign="top">Name</td><td valign="top">Nm</td><td valign="top"> </td><td valign="top">Идентификатор присвоенный банку или финансовой организации Платформой (см. <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/poluchenie-informacii-o-bankakh-i-statuse-api">Получение информации о банках и статусе API</a>)</td></tr><tr><td valign="top">1.5</td><td valign="top">Forwarding Agent</td><td valign="top">FwdgAgt</td><td valign="top"> </td><td valign="top"> </td></tr><tr><td valign="top">1.5.1</td><td valign="top">FinancialInstitutionIdentification</td><td valign="top">FinInstnId</td><td valign="top"> </td><td valign="top">Банк-получатель данного сообщения</td></tr><tr><td valign="top">1.5.1.1</td><td valign="top">Name</td><td valign="top">Nm</td><td valign="top"> </td><td valign="top">Идентификатор присвоенный банку или финансовой организации Платформой (см. <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/poluchenie-informacii-o-bankakh-i-statuse-api">Получение информации о банках и статусе API</a>)</td></tr><tr><td valign="top">2</td><td valign="top">PaymentInformation</td><td valign="top">PmtInf</td><td valign="top"> </td><td valign="top">Массив, заполняется один элемент массива</td></tr><tr><td valign="top">2.1</td><td valign="top">PaymentMethod</td><td valign="top">PmtMtd</td><td valign="top"> </td><td valign="top">Принимает значение: <strong>TRF</strong></td></tr><tr><td valign="top">2.2</td><td valign="top">PaymentTypeInformation</td><td valign="top">PmtTpInf</td><td valign="top"> </td><td valign="top">Тип операции</td></tr><tr><td valign="top">2.2.1</td><td valign="top">CategoryPurpose</td><td valign="top">CtgyPurp</td><td valign="top"> </td><td valign="top"> </td></tr><tr><td valign="top">2.2.1.1</td><td valign="top">Proprietary</td><td valign="top">Prtry</td><td valign="top"> </td><td valign="top"><p>Код типа операции. Принимает значения:</p><ul><li><strong>C2B2_RTP</strong>– Инициализация выставления счета на оплату от ЮЛ к ФЛ</li><li><strong>C2CR_RTP</strong> - Возврат перевода по инициативе Отправителя</li></ul></td></tr><tr><td valign="top">2.3</td><td valign="top">Debtor</td><td valign="top">Dbtr</td><td valign="top"> </td><td valign="top"><ul><li>Отправитель денег.</li><li>Содержит данные ФЛ.</li></ul></td></tr><tr><td valign="top">2.3.1</td><td valign="top">Name</td><td valign="top">Nm</td><td valign="top"> </td><td valign="top"><p>Может указываться:</p><ul><li><strong>ФИО клиента</strong> – для ФЛ.</li></ul><p>Максимальная длина: 140 символов</p></td></tr><tr><td valign="top">2.3.2</td><td valign="top">Identification</td><td valign="top">Id</td><td valign="top"> </td><td valign="top">Идентификационные данные отправителя денег.</td></tr><tr><td valign="top">2.3.2.1</td><td valign="top">PrivateIdentification</td><td valign="top">PrvtId</td><td valign="top"> </td><td valign="top">Идентификационные данные ФЛ</td></tr><tr><td valign="top">2.3.2.1.1</td><td valign="top">Other</td><td valign="top">Othr</td><td valign="top"> </td><td valign="top"><p>Массив, в массиве заполняются три элементов.</p><p><em>Пример заполнения:</em></p><p><em><code>&#x3C;ns0:PrvtId></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>313407829711&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Cd>NIDN&#x3C;/ns0:Cd></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>1&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Prtry>IRS&#x3C;/ns0:Prtry></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>9&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Prtry>SECO&#x3C;/ns0:Prtry></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;/ns0:PrvtId></code></em></p></td></tr><tr><td valign="top">2.3.2.1.1.1</td><td valign="top">Identification</td><td valign="top">Id</td><td valign="top"> </td><td valign="top"><p>Идентификатор, соответствующий схеме идентификации, указанной в теге &#x3C;SchmeNm>.</p><p>Максимальная длина: 35 символов</p></td></tr><tr><td valign="top">2.3.2.1.1.2</td><td valign="top">SchemeName</td><td valign="top">SchmeNm</td><td valign="top"> </td><td valign="top">Может содержать только один из тегов &#x3C;Cd> или &#x3C;Prtry></td></tr><tr><td valign="top">2.3.2.1.1.2.1</td><td valign="top">Code</td><td valign="top">Cd</td><td valign="top">Тег используется для указания кода типа документа</td><td valign="top"><p>Код типа документа:</p><ul><li><strong>NIDN</strong> – ИИН (обязателен для резидентов и нерезидентов при наличии ИИН; <em>при указании ИИН поле CCPT не заполняется);</em></li><li><strong>CCPT</strong> – документ, удостоверяющий личность для нерезидентов в случае отсутствия ИИН.</li></ul><p><em>Примечание: В теге &#x3C;Id> указывается соответственно ИИН (длина - 12 символов) либо номер документа, удостоверяющего личность.</em></p></td></tr><tr><td valign="top">2.3.2.1.1.2.2</td><td valign="top">Proprietary</td><td valign="top">Prtry</td><td valign="top">Тег используется для передачи дополнительных атрибутов идентификации ФЛ</td><td valign="top"><p>Дополнительные атрибуты идентификации для физического лица:</p><ul><li><strong>IRS</strong> – признак резидентства</li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение: 1 – резидент, 2 – нерезидент.</em></p><ul><li><strong>SECO</strong> – сектор экономики</li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение сектора экономики (принимает значение от 1 до 9), например: 9 – домашние хозяйства.</em></p></td></tr><tr><td valign="top">2.3.3</td><td valign="top">CountryOfResidence</td><td valign="top">CtryOfRes</td><td valign="top"> </td><td valign="top">Страна резидентства. Код страны по ISO 3166 (Alpha-2 code)</td></tr><tr><td valign="top">2.4</td><td valign="top">DebtorAccount</td><td valign="top">DbtrAcct</td><td valign="top"> </td><td valign="top">Счет отправителя денег</td></tr><tr><td valign="top">2.4.1</td><td valign="top">Name</td><td valign="top">Nm</td><td valign="top"> </td><td valign="top"><p>IBAN счета отправителя денег. </p><p><em>Шаблон:^[0-9A-Z]{20}$</em></p></td></tr><tr><td valign="top">2.5</td><td valign="top">DebtorAgent</td><td valign="top">DbtrAgt</td><td valign="top"> </td><td valign="top">Банк отправителя денег</td></tr><tr><td valign="top">2.5.1</td><td valign="top">FinancialInstitutionIdentification</td><td valign="top">FinInstnId</td><td valign="top"> </td><td valign="top"> </td></tr><tr><td valign="top">2.5.1.1</td><td valign="top">BICFI</td><td valign="top">BICFI</td><td valign="top"> </td><td valign="top">БИК банка отправителя денег</td></tr><tr><td valign="top">2.5.1.2</td><td valign="top">Name</td><td valign="top">Nm</td><td valign="top"> </td><td valign="top"><p>Полное наименование, включая организационно-правовую форму, банка отправителя денег.</p><p>Максимальная длина: 140 символов</p></td></tr><tr><td valign="top">2.6</td><td valign="top">CreditTransferTransaction</td><td valign="top">CdtTrfTx</td><td valign="top"> </td><td valign="top"><p>Данные запроса.</p><p> </p><p>Массив, заполняется один элемент массива</p></td></tr><tr><td valign="top">2.6.1</td><td valign="top">PaymentIdentification</td><td valign="top">PmtId</td><td valign="top"> </td><td valign="top"> </td></tr><tr><td valign="top">2.6.1.1</td><td valign="top">EndToEndIdentification</td><td valign="top">EndToEndId</td><td valign="top"> </td><td valign="top"><p>Сквозной идентификатор для всей цепочки сообщений в рамках данной операции (формат должен соответствовать описанному в <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/generaciya-unikalnykh-identifikatorov-dlya-soobshenii">Генерация уникальных идентификаторов для сообщений</a>).</p><p>Соответствует значению HTTP заголовка end-to-end-id</p></td></tr><tr><td valign="top">2.6.2</td><td valign="top">Amount</td><td valign="top">Amt</td><td valign="top"> </td><td valign="top"> </td></tr><tr><td valign="top">2.6.2.1</td><td valign="top">InstructedAmount</td><td valign="top">InstdAmt</td><td valign="top"> </td><td valign="top"><p>Сумма запроса, должна передаваться в тиын (см. <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/pravilo-peredachi-znachenii-denezhnykh-summ">Правило передачи значений денежных сумм</a>).</p><p>Сумма указывается непосредственно в теге, валюта перевода указывается в атрибуте «Ccy».</p><p> </p><p>Не должно превышать 100 000 000 000 00.</p><p> </p><p><em>Пример: &#x3C;ns0:InstdAmt Ccy=”KZT”>138640&#x3C;/ns0:InstdAmt ></em></p></td></tr><tr><td valign="top"><p>2.6.2.1.1</p><p>(атрибут)</p></td><td valign="top">CurrencyOfTransfer</td><td valign="top">Ccy (атрибут)</td><td valign="top"> </td><td valign="top">Код валюты (буквенный) запроса, принимает значение KZT</td></tr><tr><td valign="top">2.6.3</td><td valign="top">CreditorAgent</td><td valign="top">CdtrAgt</td><td valign="top"> </td><td valign="top">Банк бенефициара</td></tr><tr><td valign="top">2.6.3.1</td><td valign="top">FinancialInstitutionIdentification</td><td valign="top">FinInstnId</td><td valign="top"> </td><td valign="top"> </td></tr><tr><td valign="top">2.6.3.1.1</td><td valign="top">BICFI</td><td valign="top">BICFI</td><td valign="top"> </td><td valign="top">БИК банка бенефициара</td></tr><tr><td valign="top">2.6.3.1.2</td><td valign="top">Name</td><td valign="top">Nm</td><td valign="top"> </td><td valign="top"><p>Полное наименование, включая организационно-правовую форму, банка бенефициара.</p><p>Максимальная длина: 140 символов</p></td></tr><tr><td valign="top">2.6.4</td><td valign="top">Creditor</td><td valign="top">Cdtr</td><td valign="top"> </td><td valign="top"><p>Бенефициар.</p><p>В зависимости от типа операции может содержать данные ФЛ, ЮЛ, ИП (см. тег &#x3C;PmtTpInf> -> &#x3C;CtgyPurp> -> &#x3C;Prtry>):</p><ul><li>для <strong>C2CR_RTP</strong> – содержит данные ФЛ</li><li>для <strong>C2B2_RTP</strong> – содержит данные ЮЛ или ИП</li></ul></td></tr><tr><td valign="top">2.6.4.1</td><td valign="top">Name</td><td valign="top">Nm</td><td valign="top"> </td><td valign="top"><p>Может указываться:</p><ul><li><strong>ФИО клиента</strong> – для ФЛ.</li><li><strong>Наименование</strong> – для ЮЛ и ИП.</li></ul><p>Максимальная длина: 140 символов</p></td></tr><tr><td valign="top">2.6.4.3</td><td valign="top">Identification</td><td valign="top">Id</td><td valign="top"> </td><td valign="top"><p>Идентификационные данные бенефициара.</p><p>Заполняется только один из тегов &#x3C;PrvtId> или &#x3C;OrgId>.</p><ul><li><strong>Для ФЛ</strong> – заполняется тег &#x3C;PrvtId>.</li><li><strong>Для ЮЛ и ИП</strong> – заполняется тег &#x3C;OrgId>.</li></ul></td></tr><tr><td valign="top">2.6.4.3.1</td><td valign="top">PrivateIdentification</td><td valign="top">PrvtId</td><td valign="top">Условно обязательно</td><td valign="top">Идентификационные данные ФЛ</td></tr><tr><td valign="top">2.6.4.3.1.1</td><td valign="top">Other</td><td valign="top">Othr</td><td valign="top"> </td><td valign="top"><p>Массив, в массиве заполняются три элементов.</p><p><em>Пример заполнения:</em></p><p><em><code>&#x3C;ns0:PrvtId></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>313407829711&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Cd>NIDN&#x3C;/ns0:Cd></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>1&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Prtry>IRS&#x3C;/ns0:Prtry></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>9&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Prtry>SECO&#x3C;/ns0:Prtry></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;/ns0:PrvtId></code></em></p></td></tr><tr><td valign="top">2.6.4.3.1.1</td><td valign="top">Identification</td><td valign="top">Id</td><td valign="top"> </td><td valign="top"><p>Идентификатор, соответствующий схеме идентификации, указанной в теге &#x3C;SchmeNm>.</p><p>Максимальная длина: 35 символов</p></td></tr><tr><td valign="top">2.6.4.3.1.2</td><td valign="top">SchemeName</td><td valign="top">SchmeNm</td><td valign="top"> </td><td valign="top">Может содержать только один из тегов &#x3C;Cd> или &#x3C;Prtry></td></tr><tr><td valign="top">2.6.4.3.1.2.1</td><td valign="top">Code</td><td valign="top">Cd</td><td valign="top">Тег используется для указания кода типа документа</td><td valign="top"><p>Код типа документа:</p><ul><li><strong>NIDN</strong> – ИИН (обязателен для резидентов и нерезидентов при наличии ИИН; <em>при указании ИИН поле CCPT не заполняется);</em></li><li><strong>CCPT</strong> – документ, удостоверяющий личность для нерезидентов в случае отсутствия ИИН.</li></ul><p><em>Примечание: В теге &#x3C;Id> указывается соответственно ИИН (длина - 12 символов) либо номер документа, удостоверяющего личность.</em></p></td></tr><tr><td valign="top">2.6.4.3.1.2.2</td><td valign="top">Proprietary</td><td valign="top">Prtry</td><td valign="top">Тег используется для передачи дополнительных атрибутов идентификации ФЛ</td><td valign="top"><p>Дополнительные атрибуты идентификации для физического лица:</p><ul><li><strong>IRS</strong> – признак резидентства</li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение: 1 – резидент, 2 – нерезидент.</em></p><ul><li><strong>SECO</strong> – сектор экономики</li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение сектора экономики (принимает значение от 1 до 9), например: 9 – домашние хозяйства</em></p></td></tr><tr><td valign="top">2.6.4.3.2</td><td valign="top">OrganisationIdentification</td><td valign="top">OrgId</td><td valign="top">Условно обязательно</td><td valign="top">Идентификационные данные ЮЛ или ИП</td></tr><tr><td valign="top">2.6.4.3.2.1</td><td valign="top">Other</td><td valign="top">Othr</td><td valign="top"> </td><td valign="top"><p>Массив, в массиве заполняются восемь элементов.</p><p><em>Пример заполнения:</em></p><p><em><code>&#x3C;ns0:OrgId></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>600100277300&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Prtry>COID&#x3C;/ns0:Prtry></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>1&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Prtry>IRS&#x3C;/ns0:Prtry></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>7&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Prtry>SECO&#x3C;/ns0:Prtry></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>f810639431e4423f982737abaffb03c5&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Prtry>POSID&#x3C;/ns0:Prtry></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>5814&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Prtry>MCC&#x3C;/ns0:Prtry></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>1&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Prtry>SME&#x3C;/ns0:Prtry></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>Алматы&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Prtry>CITY&#x3C;/ns0:Prtry></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Othr></code></em></p><p><em><code>&#x3C;ns0:Id>ул. Сатпаева, 52&#x3C;/ns0:Id></code></em></p><p><em><code>&#x3C;ns0:SchmeNm></code></em></p><p><em><code>&#x3C;ns0:Prtry>ADDRESS&#x3C;/ns0:Prtry></code></em></p><p><em><code>&#x3C;/ns0:SchmeNm></code></em></p><p><em><code>&#x3C;/ns0:Othr></code></em></p><p><em><code>&#x3C;/ns0:OrgId></code></em></p></td></tr><tr><td valign="top">2.6.4.3.2.1.1</td><td valign="top">Identification</td><td valign="top">Id</td><td valign="top"> </td><td valign="top">Идентификатор, соответствующий схеме идентификации, указанной в теге &#x3C;SchmeNm>.</td></tr><tr><td valign="top">2.6.4.3.2.1.2</td><td valign="top">SchemeName</td><td valign="top">SchmeNm</td><td valign="top"> </td><td valign="top">Может содержать только один из тегов &#x3C;Cd> или &#x3C;Prtry></td></tr><tr><td valign="top">2.6.4.3.2.1.2.1</td><td valign="top">Proprietary</td><td valign="top"><br>Prtry</td><td valign="top"> </td><td valign="top"><p>Дополнительные атрибуты идентификации для ЮЛ или ИП:</p><ul><li><strong>COID</strong> – идентификатор компании</li></ul><p><em>Примечание: В теге &#x3C;Id> указывается соответственно БИН для ФЛ (длина - 12 символов) или ИИН (длина - 12 символов) для ИП.</em></p><ul><li><strong>IRS</strong> – признак резидентства</li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение: 1 – резидент, 2 – нерезидент.</em></p><ul><li><strong>SECO</strong> – сектор экономики</li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение сектора экономики (принимает значение от 1 до 9).</em></p><ul><li><strong>POSID</strong> – уникальный идентификатор торговой точки (point of sale identification). Максимальная длина: 35 символов.</li><li><strong>MCC</strong> – 4-значный код категории продавца.</li><li><strong>SME</strong> - признак МСБ.</li></ul><p><em>Примечание: Для данного кода в теге &#x3C;Id> указывается значение: 0 – не является МСБ, 1 – является МСБ.</em></p><ul><li><strong>CITY</strong> – Город регистрации компании.</li></ul><p>Максимальная длина: 256 символов.</p><ul><li><strong>ADDRESS</strong> – юридический адрес компании.</li></ul><p>Максимальная длина: 256 символов.</p></td></tr><tr><td valign="top">2.6.4.4</td><td valign="top">CountryOfResidence</td><td valign="top">CtryOfRes</td><td valign="top"> </td><td valign="top">Страна резидентства. Код страны по ISO 3166 (Alpha-2 code)</td></tr><tr><td valign="top">2.6.5</td><td valign="top">CreditorAccount</td><td valign="top">CdtrAcct</td><td valign="top"> </td><td valign="top">Счет бенефициара</td></tr><tr><td valign="top">2.6.5.1</td><td valign="top">Name</td><td valign="top">Nm</td><td valign="top"> </td><td valign="top">IBAN счета бенефициара. <em>Шаблон:^[0-9A-Z]{20}$</em></td></tr><tr><td valign="top">2.6.6</td><td valign="top">Purpose</td><td valign="top">Purp</td><td valign="top"> </td><td valign="top"> </td></tr><tr><td valign="top">2.6.6.1</td><td valign="top">Proprietary</td><td valign="top">Prtry</td><td valign="top"> </td><td valign="top"><p>Код назначения запроса.</p><p>Значение должно соответствовать правилам, утвержденным Постановлением Правления Национального Банка Республики Казахстан от 31 августа 2016 года № 203 «Об утверждении Правил применения кодов секторов экономики и назначения платежей»</p></td></tr><tr><td valign="top">2.6.7</td><td valign="top">RemittanceInformation</td><td valign="top">RmtInf</td><td valign="top"> </td><td valign="top"> </td></tr><tr><td valign="top">2.6.7.1</td><td valign="top">Unstructured</td><td valign="top">Ustrd</td><td valign="top"> </td><td valign="top"><p>Описание цели платежа/перевода денег.</p><p>Массив, заполняется один элемент массива.</p><p>Ограничение: не больше 140 символов</p><p><em>По умолчанию: Указывается наименование назначения платежа, соответствующее коду в теге &#x3C;Prtry></em></p></td></tr><tr><td valign="top">2.6.7.2</td><td valign="top">Structured</td><td valign="top">Strd</td><td valign="top">Опциональн</td><td valign="top"><p>Обязательное для заполнения при<a href="https://app.gitbook.com/o/u7C7n84gFFfiAp8eDPnO/s/oKJIIe9wXRYlANVFHqJE/~/edit/~/changes/108/mezhbankovskaya-sistema-perevodov-i-platezhei/vozvraty/vozvrat-perevoda-po-iniciative-otpravitelya-c2cr_rtp#vozmozhnye-neuspeshnye-scenarii-14"> Возврат перевода по инициативе отправителя (C2CR_RTP)</a>.</p><p>Детали транзакции в структурированном формате</p><p>Массив, заполняется один элемент массива</p></td></tr><tr><td valign="top">2.6.7.2.1</td><td valign="top">ReferredDocumentInfor mation</td><td valign="top">RfrdDocInf</td><td valign="top"> </td><td valign="top"> </td></tr><tr><td valign="top">2.6.7.2.1.1</td><td valign="top">Number</td><td valign="top">Nb</td><td valign="top"> </td><td valign="top"><p>Сквозной идентификатор для всей цепочки сообщений в рамках данной операции (формат должен соответствовать описанному в <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/generaciya-unikalnykh-identifikatorov-dlya-soobshenii">Генерация уникальных идентификаторов для сообщений</a>).</p><p> </p><p>Соответствует  сквозному идентификатору из исходного запроса  (pacs.008).</p></td></tr><tr><td valign="top">2.6.7.2.1.2</td><td valign="top">RelatedDate</td><td valign="top">RltdDt</td><td valign="top"> </td><td valign="top">Дата оригинальной транзакции.</td></tr><tr><td valign="top">2.6.7.2.1.2.1</td><td valign="top">Type</td><td valign="top">Tp</td><td valign="top"> </td><td valign="top">Тип даты</td></tr><tr><td valign="top">2.6.7.2.1.2.1.1</td><td valign="top">Proprietary</td><td valign="top">Prtry</td><td valign="top"> </td><td valign="top">Должен содержать значение: <strong>ORIGINAL_TX_PROCESSING_DATE</strong></td></tr><tr><td valign="top">2.6.7.2.1.2.2</td><td valign="top">Date</td><td valign="top">Dt</td><td valign="top"> </td><td valign="top"><p>Содержит значение, указанное в сообщении pacs.002 в элементе &#x3C;PrcgDt>.</p><p>Указывается в формате UTC (см. <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/format-daty-i-vremeni-v-biznes-soobshenii-isodatetime-i-isodate">Формат даты и времени в бизнес сообщении (ISODateTime и ISODate)</a>)</p></td></tr></tbody></table>

<br>


# Сообщение pain.014

Сообщение pain.014 «Отчет о статусе запроса на проведение финансовой операции» должно соответствовать XSD-схеме сообщения pain.014.001.11 стандарта ISO20022 и правилам заполнения документа, указанным в таблице ниже. Если поле не отмечено как опциональное, то оно является обязательным.

<table data-header-hidden><thead><tr><th width="100.1112060546875" valign="top"></th><th width="138.7777099609375" valign="top"></th><th width="151.22216796875" valign="top"></th><th width="148" valign="top"></th><th valign="top"></th></tr></thead><tbody><tr><td valign="top"><strong>№</strong></td><td valign="top"><strong>Наименование</strong></td><td valign="top"><strong>XML-тег</strong></td><td valign="top"><strong>Опциональность</strong></td><td valign="top"><strong>Описание</strong></td></tr><tr><td valign="top">0</td><td valign="top">CreditorPaymentActivationRequestStatusReport</td><td valign="top">CdtrPmtActvtnReqStsRpt</td><td valign="top"> </td><td valign="top">Статус обработки</td></tr><tr><td valign="top">1</td><td valign="top">GroupHeader</td><td valign="top">GrpHdr</td><td valign="top"> </td><td valign="top">Заголовок сообщения</td></tr><tr><td valign="top">1.1</td><td valign="top">MessageIdentification</td><td valign="top">MsgId</td><td valign="top"> </td><td valign="top">Идентификатор сообщения (формат должен соответствовать описанному в <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/generaciya-unikalnykh-identifikatorov-dlya-soobshenii">Генерация уникальных идентификаторов для сообщений</a>)</td></tr><tr><td valign="top">1.2</td><td valign="top">CreationDateTime</td><td valign="top">CreDtTm</td><td valign="top"> </td><td valign="top"><p>Дата и время создания сообщения.</p><p>Указывается в формате UTC (см. <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/format-daty-i-vremeni-v-biznes-soobshenii-isodatetime-i-isodate">Формат даты и времени в бизнес сообщении (ISODateTime и ISODate)</a>)</p></td></tr><tr><td valign="top">1.3</td><td valign="top">InitiatingParty</td><td valign="top">InitgPty</td><td valign="top"> </td><td valign="top">Банк-отправитель данного сообщения</td></tr><tr><td valign="top">1.3.1</td><td valign="top">Name</td><td valign="top">Nm</td><td valign="top"> </td><td valign="top"><p>Идентификатор присвоенный банку или финансовой организации Платформой (см. <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/poluchenie-informacii-o-bankakh-i-statuse-api">Получение информации о банках и статусе API</a>)</p><p> </p><p>В сообщениях, сформированных Платформой, будет передаваться в качестве идентификатора Платформы значение - 00000000-0000-0000-0000-000000000000</p></td></tr><tr><td valign="top">1.4</td><td valign="top">Forwarding Agent</td><td valign="top">FwdgAgt</td><td valign="top"> </td><td valign="top"> </td></tr><tr><td valign="top">1.4.1</td><td valign="top">FinancialInstitutionIdentification</td><td valign="top">FinInstnId</td><td valign="top"> </td><td valign="top">Банк-получатель данного сообщения</td></tr><tr><td valign="top">1.4.1.1</td><td valign="top">Name</td><td valign="top">Nm</td><td valign="top"> </td><td valign="top">Идентификатор присвоенный банку или финансовой организации Платформой (см. <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/poluchenie-informacii-o-bankakh-i-statuse-api">Получение информации о банках и статусе API</a>)</td></tr><tr><td valign="top">2</td><td valign="top">OriginalGroupInforma tionAndStatus</td><td valign="top">OrgnlGrpInfAndSts</td><td valign="top"> </td><td valign="top"><p>Данные статуса обработки запроса.</p><p> </p><p>Массив, заполняется один элемент массива</p></td></tr><tr><td valign="top">2.1</td><td valign="top">OriginalMessageIdentification</td><td valign="top">OrgnlMsgId</td><td valign="top"> </td><td valign="top"><p>Сквозной идентификатор для всей цепочки сообщений в рамках данной операции (формат должен соответствовать описанному в <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/generaciya-unikalnykh-identifikatorov-dlya-soobshenii">Генерация уникальных идентификаторов для сообщений</a>).</p><p> </p><p>Соответствует значению HTTP заголовка end-to-end-id</p></td></tr><tr><td valign="top">2.2</td><td valign="top">OriginalMessageNameIdentification</td><td valign="top">OrgnlMsgNmId</td><td valign="top"> </td><td valign="top"><p>Код типа операции. Принимает значения:</p><ul><li><strong>C2CR_RTP</strong> – Возврат перевода по инициативе Отправителя. </li><li><strong>C2B2_RTP</strong> – Выставление счета на оплату  ФЛ от ЮЛ.</li></ul></td></tr><tr><td valign="top">2.3</td><td valign="top">GroupStatus</td><td valign="top">GrpSts</td><td valign="top"> </td><td valign="top"><p>Статус обработки транзакции. Принимает значения:</p><p><strong>RJCT</strong> – отклонена</p></td></tr><tr><td valign="top">2.4</td><td valign="top">StatusReasonInformation</td><td valign="top">StsRsnInf</td><td valign="top">Опционально</td><td valign="top"><p>Используется только для <strong>GrpSts=RJCT</strong> (отклоненных транзакций).</p><p>Массив, заполняется только один элемент массива</p></td></tr><tr><td valign="top">2.4.1</td><td valign="top">Reason</td><td valign="top">Rsn</td><td valign="top"> </td><td valign="top">Причина отклонения транзакции</td></tr><tr><td valign="top">2.4.1.1</td><td valign="top">Proprietary</td><td valign="top">Prtry</td><td valign="top"> </td><td valign="top">Код причины отклонения транзакции.</td></tr><tr><td valign="top">2.4.2</td><td valign="top">AdditionalInformation</td><td valign="top">AddtlInf</td><td valign="top"> </td><td valign="top">Описание ошибки. Массив, заполняется один элемент массива</td></tr></tbody></table>

<br>


# Формат даты и времени в бизнес сообщении (ISODateTime и ISODate)

По умолчанию (если иного явно не указано в описании) при передаче даты и времени в бизнес-сообщении они должны быть представлены в формате dateTime стандарта ISO 8601 (ISODateTime) с буквой "Z", т.е. время указывается в формате UTC (Coordinated Universal Time).

<figure><img src="/files/5mzpQdCJyHY6IpbyBIYu" alt=""><figcaption><p>Формат даты и времени (ISODateTime)</p></figcaption></figure>

По умолчанию (если иного явно не указано в описании) при передаче даты в бизнес-сообщении она должна быть представлены в формате dateTime стандарта ISO 8601 (ISODate).

<figure><img src="/files/jSmbN2YbPh17KjUHZATp" alt=""><figcaption><p>Формат даты (ISODate)</p></figcaption></figure>

{% hint style="info" %}
*Для минимизации рисков и предотвращения ошибок при подключении к Системе рекомендуется убедиться, что серверное время банковских серверов синхронизировано с эталонным источником. Допустимое отклонение не должно превышать **0,5 секунды.***
{% endhint %}


# Правило передачи значений денежных сумм

{% hint style="warning" %}
*По умолчанию (если иного явно не указано в описании) денежные суммы должны передаваться в тиын.*&#x20;
{% endhint %}

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

<figure><img src="/files/mW4NOPZNKxCzia08NSHH" alt=""><figcaption><p>Пример передачи значений денежных сумм</p></figcaption></figure>


# Генерация уникальных идентификаторов для сообщений

В сообщениях ISO20022 используются уникальные идентификаторы. Например, идентификатор сообщения, сквозной идентификатор цепочки транзакций, идентификатор транзакции и т.д. (MsgId, EndToEndId, TxId и т.д.).

> Идентификатор должен генерироваться криптографически стойким генератором в виде случайной строки длиной 24 символа, состоящей из символов 0-9, A-Z, a-z, "\_", "-".
>
> *Шаблон идентификатора: \[0-9A-Za-z\_-]{24}*

{% hint style="info" %}
Рекомендуется в качестве первых трех символов использовать идентификатор банка, присвоенный АО "НПК" (предоставляется представителем АО "НПК"), а в качестве последующих восьми символов использовать дату операции.

*Например: BNK20241001-62141673\_aA5*
{% endhint %}


# Подписание и проверка электронной цифровой подписи бизнес-сообщений

Формирование и проверка ЭЦП осуществляется в порядке, установленном законодательством Республики Казахстан.

{% hint style="info" %}
&#x20;Для формирования ЭЦП БВУ-участники должны использовать регистрационные свидетельства, выпускаемые УЦ АО «НПК». Подробная информация по выпуску регистрационных свидетельств, описания технических аспектов алгоритмов подписания, а также корневые сертификаты УЦ АО «НПК» доступны по ссылке <https://npck.kz/udostoveryayushhij-tsentr/>
{% endhint %}

Для работы с регистрационными свидетельствами УЦ АО «НПК» БВУ-участнику необходимо использовать программное средство криптографической защиты информации «ТУМАР-CSP». При необходимости, сотрудниками АО «НПК» обеспечивается консультационная поддержка по вопросам выпуска и применения регистрационных свидетельств, а также инструкции по установке и настройке ПО «ТУМАР-CSP».

{% hint style="info" %}
По запросу может быть предоставлен проект (пример) подписания и проверки подписи на Kotlin, а также docker-контейнер с реализованным подписанием и проверкой подписи для запуска, что позволит упростить процесс реализации работы с ЭЦП.

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

*<mark style="color:red;">**Важно:**</mark>*

* *<mark style="color:red;">**Предоставляемые примеры кода и сервисы (в Docker-контейнере) являются вспомогательными (необязательными к использованию). Они предназначены для ознакомления и упрощения начала работы с ЭЦП, АО «НПК» не несет ответственности за их корректную работу, эффективность и производительность. Не рекомендуем использовать данный сервис в production среде.**</mark>*
  \
  *<mark style="color:red;">**Рекомендуется самостоятельно реализовать полноценную работу с ЭЦП на стороне банка.**</mark>*
* ***При сборке и запуске проекта npck-transfers-adapter необходимо учитывать архитектуру системы.***
  \
  ***На устройствах с процессорами Apple Silicon (ARM, macOS) возможны ошибки при подписании или несовместимости зависимостей.***
  \
  ***Рекомендуется выполнять сборку и запуск на системах x86\_64 (Intel / AMD) либо использовать контейнер с образом, собранным под x86.***
  \
  ***Если работа ведётся на macOS с архитектурой ARM, убедитесь, что контейнер запускается с правильной архитектурой.***
  {% endhint %}

## Подписание сообщения

{% hint style="warning" %}
Бизнес-часть всех сообщений подписывается в обязательном порядке.&#x20;

Данные подписываются, применяя алгоритм подписания СТ РК ГОСТ Р 34.10-2015 (512).
{% endhint %}

{% hint style="warning" %}
После выполнения подписи xml файла - его **НЕЛЬЗЯ** форматировать, нужно отправлять неизмененным.&#x20;

Иначе подпись будет невалидна и будет возвращен HTTP-статус 401&#x20;
{% endhint %}

Подписание бизнес части сообщения осуществляется посредством XML-подписи (XML-Signature) по спецификации консорциума W3C XMLDSIG (XML-Signature Syntax and Processing). Полученный результат помещается в теге \<Document> → \<Signature>.&#x20;

Структуру подписи сообщения описывает таблица ниже.

<table><thead><tr><th width="330">Поле</th><th>Описание</th></tr></thead><tbody><tr><td>Signature</td><td>Подпись сообщения</td></tr><tr><td><br>   SignedInfo</td><td>Сведения о подписи: включает в себя алгоритм канонизации, алгоритм подписи и один или несколько элементов Reference</td></tr><tr><td><br>         CanonicalizationMethod</td><td>Метод канонизации (определяет конкретный набор правил для упрощения и структурирования экземпляра XML до подписания)</td></tr><tr><td>         SignatureMethod<br></td><td><p>Алгоритм, используемый для создания подписи.</p><p>Данные подписываются, применяя алгоритм подписания СТ РК ГОСТ Р 34.10-2015 (512)</p></td></tr><tr><td>         Reference<br></td><td><p>Определяет данные, которые подписываются, и содержит информацию о них, такую как URI (или хэш) подписываемых данных и информацию о применяемом алгоритме хэширования </p><p>Содержит алгоритм формирования цифровой подписи, список преобразований, может содержать идентификатор подписываемого объект</p></td></tr><tr><td><br>               Transforms</td><td>Представляет список элементов преобразования</td></tr><tr><td>               DigestMethod<br></td><td>Определяет алгоритм хэширования, который используется для создания хэш-значения для данных, подлежащих подписи</td></tr><tr><td><br>               DigestValue</td><td>Элемент содержит само значение хэша, которое было вычислено для данных, указанных в элементе Reference. Значение хэша представляет собой результат применения алгоритма хэширования (определенного в элементе DigestMethod) к подписываемым данным</td></tr><tr><td><br>   SignatureValue</td><td>Это значение, полученное путем применения алгоритма подписи к канонизированным данным, подписанным закрытым ключом. Это элемент, содержащий фактическое значение подписи</td></tr><tr><td><br>   KeyInfo</td><td>Этот элемент содержит информацию о ключе, используемом для создания подписи. </td></tr><tr><td>         X509Data<br></td><td>Идентификатор ключа или сертификат X509 (идентификатор сертификата или список отозванных сертификатов)</td></tr><tr><td>               X509Certificate<br></td><td>Сертификат, закодированный в base64.</td></tr></tbody></table>

Пример подписи:

```xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Document
	xmlns:ns0="urn:iso:std:iso:20022:tech:xsd:xxx.nnn.nnn.nn">
	<!-- Содержимое сообщения -->
	<ds:Signature
		xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
		<ds:SignedInfo>
			<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
			<ds:SignatureMethod Algorithm="urn:ietf:params:xml:ns:pkigovkz:xmlsec:algorithms:gostr34102015-gostr34112015-512"/>
			<ds:Reference URI="">
				<ds:Transforms>
					<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
					<ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/>
				</ds:Transforms>
				<ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:pkigovkz:xmlsec:algorithms:gostr34112015-512"/>
				<ds:DigestValue>5Db4igpZm5S0qUWJIta7W6T8YBOa8r...
</ds:DigestValue>
			</ds:Reference>
		</ds:SignedInfo>
		<ds:SignatureValue>ZvbD3pMlj9H2RXCxcV9/pcQ7Iayxgmz...
        </ds:SignatureValue>
		<ds:KeyInfo>
			<ds:X509Data>
				<ds:X509Certificate>MIIEtjCCBB6gAwIBAgIUYEeZfcJ...
</ds:X509Certificate>
			</ds:X509Data>
		</ds:KeyInfo>
	</ds:Signature>
</Document>
```

## Проверка ЭЦП сообщений

Проверка подлинности ЭЦП сообщения осуществляется следующим образом:&#x20;

1. Извлекается регистрационное свидетельство из структуры заголовка бизнес-сообщения (из тега \<Document> → \<Signature> → \<KeyInfo> → \<X509Data> → \<X509Certificate>).
2. Извлеченное регистрационное свидетельство проверяется на то, что оно действительно выпущено промышленным УЦ АО «НПК».&#x20;

{% hint style="info" %}
Корневые регистрационные свидетельства УЦ доступны по ссылке <https://npck.kz/registratsionnye-svidetelstva-uts-i-spiski-otozvannyh-sertifikatov/> (Алгоритм ГОСТ 34.310-2015)
{% endhint %}

3. Проверяется срок действия регистрационного свидетельства.&#x20;
4. Проверяется отозванность регистрационного свидетельства – должно быть не отозвано на момент подписи.

{% hint style="warning" %}

Важно:
\
В качестве альтернативного механизма, при недоступности сервиса OCSP (порт 62255), проверка статуса сертификата (отозван/не отозван) может выполняться с использованием списка отозванных сертификатов (CRL, Certificate Revocation List).

CRL периодически загружается из удостоверяющего центра по адресу <http://ca.kisc.kz/cgi/RevListGOST.crl> и хранится локально.
{% endhint %}

5. Проверяются области использования ключа.

{% hint style="info" %}
Для ЭЦП должны присутствовать области использования ключа Digital Signature, Non-Repudiation
{% endhint %}

6. Проверяются политики применения ключа OID policy. OID policy=1.2.398.3.5.2.23.1
7. Проверяется алгоритм формирования подписи (подпись сформирована с применением алгоритма СТ РК ГОСТ Р 34.10-2015 (512), OID алгоритма = `1.2.398.3.10.1.1.2.3.2`).
8. Проверяется корректность электронной подписи.

{% hint style="info" %}
Используемый для подписания сертификат должен быть выдан той организации, которая подписывает сообщения (проверка по полю subject (по БИН)).&#x20;

В сообщениях, полученных от Платформы, должен быть указан БИН АО «НПК» (960440000151).
{% endhint %}


# Использование QR-кода для совершения платежей

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

<figure><img src="/files/xul1L7aKL8UiGVGoonjR" alt=""><figcaption><p>Концептуальная схема использования QR-кода</p></figcaption></figure>

Концептуальная схема использования QR-кода приведена на рисунке ниже и включает в себя следующие основные шаги:

* Генерация QR-кода производится Банком бенефициара.

*Примечание: Банк бенефициара должен реализовать и опубликовать на Платформе сервис по предоставлению информации о QR-коде POST /v1/transfers/iso20022/admi.009.001.02, описанный в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*

{% hint style="warning" %}
Если отсканированный QR-код выпущен самим Банком плательщика, то его оплата производится внутри Банка плательщика без взаимодействия с Платформой.&#x20;

Т.е. если счет получателя, указанный в QR-коде, также обслуживается в данном банке, то производится внутрибанковская операция
{% endhint %}

* Клиент сканирует QR-код \[1].
* Приложение Банка отправителя денег распознает QR-код \[2].
* Банк отправителя денег посредством Платформы получает от Банка бенефициара данные для оплаты по отсканированному QR-коду \[3-4].
* Банк отправителя денег посредством Платформы проводит платеж в Банк бенефициара \[5-6].
* Банк бенефициара уведомляет бенефициара о поступлении оплаты \[7].
* Банк отправителя денег уведомляет клиента об успешной оплате \[8].

<figure><img src="/files/wpN8wdOtezIDcPrmHJNc" alt=""><figcaption><p>Структура данных в QR-коде</p></figcaption></figure>


# Тайм-ауты и логика повторных запросов

## Ограничения по времени обработки (тайм-ауты)

{% file src="/files/Rf3q5S1nMqktYDpD9xES" %}
Схематичное отображение тайм-аутов
{% endfile %}

### На стороне Банка отправителя денег

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

> * Для процесса “Инициализация перевода денег от отправителя денег к другому ФЛ в приложении Банка отправителя денег (C2C2)” - 30 секунд на получение acmt.024 после успешной отправки сообщения acmt.023, 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.008.
> * Для процесса “Инициализация перевода денег между своими счетами (M2M)” - 30 секунд на получение acmt.024 после успешной отправки сообщения acmt.023, 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.008.
> * Для процесса “Возврат полученного перевода (C2CR)” - 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.004.
> * Для процесса “Инициализация оплаты по QR-коду (C2B2\_V2)” - 30 секунд на получение admi.010 после успешной отправки сообщения admi.009 , 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.008.
> * Для процесса “Инициализация оплаты по QR-коду в рамках электронной коммерции (C2B2E)” - 30 секунд на получение admi.010 после успешной отправки сообщения admi.009, 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.008.
> * Для процесса “Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR\_V2)” - 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.004.
> * Для процесса “Возврат денег по проведенной ранее оплате за товар/услугу по инициативе продавца без участия покупателя (C2BRM\_V2)“  - 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.004.

***! Применимо к следующим процессам: С2С2, С2CR, M2M, C2BRE:*** Если Банк отправителя денег получает сообщение о статусе платежа/перевода pacs.002 со статусом PDNG (т.е. транзакция была успешно начата и находится в обработке) – он не должен разблокировать средства самостоятельно до получения от Платформы сообщения pacs.002 с финальным статусом транзакции (RJCT или ACSC).

***! Применимо к следующим процессам: С2С2, С2CR, M2M, C2BRE:*** Если, Банк отправителя денег не получает сообщение о статусе платежа/перевода pacs.002 с финальным статусом транзакции (RJCT или ACSC) в течение 30 секунд после получения pacs.002 со статусом PDNG, то он должен направить запрос статуса транзакции pacs.028 Платформе.

{% hint style="warning" %}
Банк отправителя денег должен соблюдать следующие временные ограничения обработки сообщений:

* обработка полученного сообщения и формирование ответа c HTTP кодом 200 в случае успеха или HTTP кодом 400 в случае ошибки - не более 10 секунд;
* обработка полученного сообщения admi.010 и формирование сообщения pacs.008 - не более 60 секунд;
* обработка полученного сообщения acmt.024 и формирование сообщения pacs.008 - не более 180 секунд;
* формирование сообщения pacs.004 с момента успешной отправки admi.010 - не более 120 секунд;
* обработка полученного сообщения admi.009 и формирование ответного сообщения admi.010 - не более 10 секунд;
* обработка полученного сообщения pacs.002 (PDNG) и формирование сообщения pacs.002 (ACSC) - не более 10 секунд.
  {% endhint %}

{% hint style="info" %}
***Примечание:*** *Для процесса “ Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR\_\_V2)” и* “Возврат денег по проведенной ранее оплате за товар/услугу по инициативе продавца без участия покупателя (C2BRM\_V2)“ *-  Если, Банк отправителя денег не получает сообщение о статусе платежа/перевода pacs.002 PDNG в течение 30 секунд после успешной отправки pacs.004, то банк завершает процесс по таймауту и направляет в Платформу  сообщение pacs.002 (RJCT) до тех пор пока не будет получен  ответ HTTP 200.*
{% endhint %}

### На стороне Банка бенефициара

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

> * Для процесса “Инициализация перевода денег от отправителя денег к другому ФЛ в приложении Банка отправителя денег (C2C2)” - 200 секунд на получение pacs.008 после успешной отправки сообщения acmt.024.
> * Для процесса “Инициализация перевода денег между своими счетами (M2M)” - 200 секунд на получение pacs.008 после успешной отправки сообщения acmt.024.
> * Для процесса “Инициализация оплаты по QR-коду (C2B2\_V2)” – 60 секунд на получение pacs.008 после успешной отправки сообщения admi.010.
> * Для процесса “Инициализация оплаты по QR-коду в рамках электронной коммерции (C2B2E)” - 60 секунд на получение pacs.008 после успешной отправки сообщения admi.010.
> * Для процесса “ Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR\_\_V2) ” - 30 секунд на получение admi.010 после успешной отправки сообщения admi.009 и 120 секунд на получение pacs.004 с момента получения admi.010.

&#x20;Если Банк бенефициара не получает  сообщение о статусе платежа/перевода pacs.002 с финальным статусом транзакции (RJCT или ACSC) в течение 30 сек после успешной отправки pacs.002 со статусом PDNG, то он завершает транзакцию неуспешно (RJCT) по тайм-ауту, начисление денег бенефициару не производится.

{% hint style="danger" %}
Если Банк бенефициара завершает транзакцию по тайм-ауту и после этого получает запрос с  pacs.002 с финальным статусом ACSC, то он **должен ответить на этот запрос HTTP кодом 400 с ошибкой INVALID\_TRANSACTION\_STATUS**
{% endhint %}

{% hint style="warning" %}
Банку бенефициар должен соблюдать следующие временные ограничения обработки сообщений:

* обработка полученного сообщения и формирование ответа c HTTP кодом 200 в случае успеха или HTTP кодом 400 в случае ошибки - не более 10 секунд;
* обработка полученного сообщения admi.009 и формирование ответного сообщения admi.010 - не более 10 секунд;
* обработка полученного сообщения acmt.023 и формирование ответного сообщения acmt.024 - не более 10 секунд;
* обработка полученного сообщения pacs.008 и формирование ответного сообщения pacs.002 - не более 10 секунд;
* обработка полученного сообщения pacs.004 и формирование ответного сообщения pacs.002 - не более 10 секунд.
  {% endhint %}

{% hint style="info" %}
***Примечание:*** *Для процесса “Инициализация оплаты по QR-коду (C2B2\_V2)” и* Возврат денег по проведенной ранее оплате за товар/услугу по инициативе продавца без участия покупателя (C2BRM\_V2)“ *-  Если, Банк бенефициара не получает сообщение о статусе платежа/перевода pacs.002 с финальным статусом транзакции (RJCT или ACSC) в течение 30 секунд после отправки pacs.002 PDNG, то банк завершает процесс по таймауту и направляет в Платформу  сообщение pacs.002 (RJCT) до тех пор пока не будет получен  ответ HTTP 200.*
{% endhint %}

## Отправка повторных запросов

**Для всех запросов, кроме запроса статуса транзакции pacs.028, запроса выписки camt.053 (см.** [#poluchenie-vypiski](#poluchenie-vypiski "mention")**):**

* Если получатель сообщения возвращает следующие HTTP-статусы - 500, 502, 503, 504 или при разрыве TCP-соединения по независящим от клиента причинам, отправитель сообщения должен повторно отправить запрос через 3 секунды.&#x20;
* Общее количество повторных попыток отправки запроса может быть не более 2, после чего операция завершается неуспешно.

{% hint style="info" %}
При подсчете попыток повторной отправки сообщения используется комбинация следующих полей:  тип сообщения, сквозной идентификатор, идентификатор банка отправителя сообщения (идентификатор Платформы).
{% endhint %}

{% hint style="danger" %}
При превышении количества повторных попыток отправки сообщения будет возвращен HTTP-статус 429
{% endhint %}

**Для запроса статуса транзакции pacs.028:**

Повторные запросы pacs.028 направляются по следующим правилам:&#x20;

* первые две попытки – интервал 3 секунды;
* третья и последующие попытки – интервал определяется отправителем сообщения, но не менее 10 секунд.&#x20;

{% hint style="warning" %}
Повторные попытки отправки запроса необходимо направлять не более чем в течении суток, до получения информации о состоянии транзакции из выписки, направляемой при смене операционного дня
{% endhint %}

{% hint style="info" %}
pacs.028 направляется в случаях, когда:

* Платформа не отвечает
* Платформа отвечает следующими HTTP статусами - 500, 502, 503, 504, при разрыве TCP-соединения по независящим от клиента причинам
* Не получено сообщение о статусе платежа/перевода pacs.002 с финальным статусом транзакции (RJCT или ACSC) согласно установленных временных регламентов
  {% endhint %}

## Логика повторной отправки pacs.002 со статусом ACSC Платформой&#x20;

{% hint style="danger" %}
***Применимо к следующим процессам: С2С2, С2CR, M2M, C2BRE***
{% endhint %}

В случае, если при отправке платформой pacs.002 со статусом ACSC в банк бенефициара возникают ошибки соединения или серверные ошибки, применяется следующая логика:

* Если банк бенефициар возвращает HTTP-статусы 500, 502, 503, 504 либо происходит разрыв TCP-соединения по причинам, не зависящим от платформы - платформа выполняет две повторные попытки отправки через 3 и 6 секунд.
* Если платформа не получила однозначного ответа от банка бенефициара (HTTP-статус 200 или 400) - выполняются дополнительные три повторные попытки через 60, 90 и 120 секунд.
* При отсутствии успешного ответа после всех повторных попыток - транзакция фиксируется в системе со статусом COMMITTED, в банк отправителя направляется сообщение pacs.002 со статусом ACSC.
* Дальнейшее получение статуса обработки транзакции банком бенефициаром осуществляется посредством - запроса статуса обработки транзакции (pacs.028) или получением информации о статусе транзакции из выписки (camt.053).

## Получение выписки

В случае неполучения выписки по счету camt.053 по запросу camt.060, повторный запрос выписки camt.060 Платформе можно направлять не ранее, чем через 2 минуты после предыдущей попытки.

## Информирование об ошибках

Ошибка направляется в ответе на запрос (синхронно), если она возникает при валидации запроса/

В случае возникновения ошибок при обработке сообщения, связанных с бизнес-процессом (контроль лимитов, антифрод и т.д.) на стороне Платформы, Платформа направляет соответствующие ответные сообщения (acmt.024, pacs.002, admi.010), в которых указывается информация о возникшей ошибке (причина неуспешности запроса).

В случае возникновения ошибок при обработке сообщения, связанных с бизнес-процессом (контроль лимитов, антифрод и т.д.) на стороне БВУ, БВУ направляет соответствующие ответные сообщения (acmt.024, pacs.002, admi.010), в которых указывается информация о возникшей ошибке (причина неуспешности запроса).


# Инициализация переводов денег

{% hint style="info" %}
Реализация процессов инициализации платежей и переводов денег средств основана на методах API, описанных в электронном формате в <https://transfers-openapi.npck.kz/>
{% endhint %}

{% hint style="warning" %}
Во всех запросах должен быть указан **HTTP заголовок end-to-end-id**, в котором должен указываться сквозной идентификатор для всей цепочки сообщений, использующийся в рамках данной операции *(должен совпадать с соответствующим значением, передаваемым в теле сообщения)*
{% endhint %}

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


# Инициализация перевода денег другому ФЛ (C2C2)

Данный сценарий описывает инициализацию перевода денег от клиента (Отправитель денег) из одного БВУ (Банк отправителя денег) иному физическому лицу (Бенефициар) в другой БВУ (Банк бенефициара).&#x20;

Перевод инициируется в приложении Банка отправителя денег.&#x20;

Перевод денег осуществляется со счета Отправителя денег в Банке отправителя денег на счет Бенефициара в Банке бенефициара.

Отправитель денег для осуществления перевода указывает номер мобильного телефона бенефициара и Банк бенефициара.

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Инициализация перевода денег другому ФЛ (C2C2)» отображает рисунок ниже.

<figure><img src="/files/2qhX092Np38SLXd3ZvkR" alt=""><figcaption><p>Схема процесса «Инициализация перевода денег другому ФЛ (C2C2)»</p></figcaption></figure>

{% hint style="info" %}
*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Инициализация перевода денег другому ФЛ (C2C2)», приведены в таблице ниже.

| Метод API (endpoint)                                                                                     | Банк отправителя денег | Банк бенефициара |
| -------------------------------------------------------------------------------------------------------- | ---------------------- | ---------------- |
| <p>Запрос верификации наличия счета клиента </p><p>(POST /v1/transfers/iso20022/acmt.023.001.03)</p>     | <p><br></p>            | +                |
| <p>Результат верификации наличия счета клиента  </p><p>(POST /v1/transfers/iso20022/acmt.024.001.03)</p> | +                      | <p><br></p>      |
| <p>Запрос на перевод денег </p><p> (POST /v1/transfers/iso20022/pacs.008.001.11)</p>                     | <p><br></p>            | +                |
| <p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p>      | +                      | +                |

## Взаимосвязь идентификаторов сообщений

Процесс «Инициализация перевода денег другому ФЛ (C2C2)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/6wUfAGwvRwmtCK3nxwtk" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

Описание успешного сценария процесса «Инициализация перевода денег другому ФЛ (C2C2)»:

***Верификация наличия счета клиента***

1. Отправитель денег в приложении Банка отправителя денег инициирует перевод денег бенефициару по номеру телефона.
2. Банк отправителя денег направляет Платформе запрос верификации наличия счета клиента по номеру телефона (сообщение acmt.023), подписывая его своим ЭЦП.

> В сообщении передается:
>
> * в теге \<Document::Assgnmt:MsgId> – сгенерированный уникальный идентификатор сообщения
> * в теге \<Document::Vrfctn:Id> – сгенерированный уникальный идентификатор запроса верификации, который будет выступать в качестве сквозного идентификатора для всей цепочки сообщений в рамках данной операции перевода

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.
2. Процесс завершается неуспешно.

</details>

2.1. Платформа, получив запрос, проводит его обработку и валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей
* проверяет, что сквозной идентификатор \<Document::Vrfctn:Id> не использовался

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

3. Платформа направляет в Банк бенефициара запрос верификации наличия счета клиента по номеру телефона (сообщение acmt.023), подписывая его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::Assgnmt:MsgId> – сгенерированный уникальный идентификатор сообщения
> * в теге \<Document::Vrfctn:Id> – сквозной идентификатор для всей цепочки сообщений в рамках данной операции перевода, полученный на шаге 2

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Платформа направляет в Банк отправителя сообщение acmt.024 с ошибкой.
3. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
4. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа завершает процесс, получив сообщение с информацией об ошибке.
3. Платформа направляет в Банк отправителя сообщение acmt.024 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.
5. Процесс завершается неуспешно.

</details>

3.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

4. Банк бенефициара проверяет наличие счета по указанному в запросе номеру телефона.
5. Банк бенефициара направляет результат верификации наличия счета клиента Платформе (сообщение acmt.024), подписав его своим ЭЦП.

> В сообщении передается:
>
> * в теге \<Document::Rpt:OrgnlId> – сквозной идентификатор из тега \<Vrfctn:Id> исходного запроса (из acmt.023)
> * При наличии счета бенефициара передается его ФИО и IBAN для счета бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом.&#x20;
2. Банк отправителя денег завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Процесс завершается неуспешно.

* **Сведения о счете клиента не найдены:**

1. Банк бенефициара направляет негативный результат верификации наличия счета клиента Платформе (сообщение acmt.024).
2. Платформа направляет негативный результат верификации наличия счета клиента Банку отправителя денег (сообщение acmt.024).&#x20;
3. Процесс завершается неуспешно.

</details>

5.1. Платформа, получив запрос (сообщение acmt.024), проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

6. Платформа направляет результат верификации наличия счета клиента в Банк отправителя денег (сообщение acmt.024), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::Rpt:OrgnlId> – сквозной идентификатор из тега \<Vrfctn:Id> исходного запроса (из acmt.023)
> * При наличии счета бенефициара передается его ФИО и IBAN для счета бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

6.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

7. Банк отправителя денег отображает информацию о бенефициаре (имя и первая буква фамилии, например, «Имя Ф.»), чтобы Отправитель денег мог удостовериться в корректности получателя.
8. Отправитель денег подтверждает перевод в приложении Банка отправителя денег.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Отправитель денег не подтверждает перевод в приложении Банка отправителя денег:**

1. Процесс завершается неуспешно.

</details>

***Транзакция по переводу денег***

9. Банк отправителя денег проводит проверку счета клиента на:&#x20;
   * валидность статуса для его дебетования&#x20;
   * отсутствие наложенного ПТП/ РПРО/ ареста и т.п.&#x20;
   * достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Проверка счета не прошла успешно:**

1. Банк отправителя денег уведомляет клиента о невозможности проведения операции.&#x20;
2. Процесс завершается неуспешно.

</details>

10. Банк отправителя денег блокирует сумму операции по счету клиента и формирует платежное поручение (pacs.008).
11. Банк отправителя денег направляет Платформе запрос на перевод денег (сообщение pacs.008), подписав его своим ЭЦП.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::PmtId:EndToEndId> – сквозной идентификатор из тега \<OrgnlId> из сообщения acmt.024&#x20;
> * в поле \<Document::PmtId:TxId> – сгенерированный уникальный идентификатор новой транзакции
> * указывается  IBAN для счета Отправителя денег
> * указывается  IBAN для счета Бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

11.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

12. Платформа обрабатывает  запрос на перевод денег (сообщение pacs.008), в том числе:&#x20;
    * выполняет проверку позиций участников и лимитов;
    * выполняет блокирование средств для проведения транзакции;
    * выполняет поиск результата верификации наличия счета клиента по \<EndToEndId> (acmt.024).

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса на перевод денег pacs.008 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
2. Процесс завершается неуспешно.

</details>

13. Платформа направляет в Банк бенефициара запрос на перевод денег (сообщение pacs.008), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::PmtId:EndToEndId> – сквозной идентификатор из тега \<OrgnlId> из сообщения acmt.024, соответствует \<EndToEndId> из сообщения pacs.008 Банка отправителя денег
> * в поле \<Document::PmtId:TxId> – идентификатор транзакции из тега \<TxId> из сообщения pacs.008 Банка отправителя денег
> * указывается  IBAN для счета Отправителя денег
> * указывается  IBAN для счета Бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
4. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
5. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
6. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

13.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

14. Банк бенефициара проверяет счет бенефициара на возможность зачисления денег.
15. Банк бенефициара направляет статус обработки запроса перевода денег Платформе (сообщение pacs.002), подписав его своим ЭЦП.

> В сообщении передается:
>
> * \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<EndToEndId> исходного запроса (pacs.008)
> * \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<TxId> исходного запроса (из pacs.008)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции статусом RJCT (отклонена).&#x20;
3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса перевода денег (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

15.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара&#x20;
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

16. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<EndToEndId> исходного запроса (pacs.008)
> * в теге \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<TxId> исходного запроса (из pacs.008)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* &#x20;**Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

16.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

17. Платформа успешно завершает транзакцию (commit transaction).
18. Платформа направляет в качестве уведомления об успешной транзакции в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

18.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк бенефициара не производит (не производит повторное зачисление денег на счет бенефициара и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк бенефициара ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк бенефициара в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)) завершает транзакцию неуспешно (RJCT) по тайм-ауту, зачисление средств бенефициару не производится.&#x20;
3. Платформа производит откат транзакции, устанавливает статус транзакции - RJCT (неуспешно). Банк отправителя денег, получив статус транзакции RJCT (неуспешно), разблокирует средства Отправителя денег, списание средств не производится.

*Примечание: перед завершением транзакции Банк бенефициара может проверить статус транзакции на Платформе, отравив сообщение pacs.028 (см.* [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)*)*

</details>

18.2. Банк бенефициара производит зачисление денег на счет бенефициара и уведомляет об этом бенефициара.

19. Платформа направляет в качестве уведомления об успешной транзакции в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

19.1. Банк отправителя денег, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк отправителя денег ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк отправителя денег  направляет запрос статуса транзакции Платформе (сообщение pacs.028, см. [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)), подписав его своим ЭЦП.&#x20;
3. Платформа, успешно выполнив обработку запроса, направляет ответ с HTTP статусом 200.
4. Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции, подписав его ЭЦП Платформы.

</details>

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк отправителя денег не производит (не производит повторное списание денег со счета отправителя денег и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

19.2. Банк отправителя денег производит списание денег со счета отправителя денег и уведомляет его о завершении операции.


# Инициализация перевода денег между своими счетами (M2M)

Данный сценарий описывает инициализацию перевода денег клиентом со своего счета в одном БВУ на свой счет в другой БВУ.  Перевод осуществляется по номеру мобильного телефона.

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

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Инициализация перевода денег между своими счетами (M2M)» отображает рисунок ниже.

<figure><img src="/files/v1rfeuoZuDgc0ko9NQRB" alt=""><figcaption><p>Схема процесса «Инициализация перевода денег между своими счетами (M2M)»</p></figcaption></figure>

{% hint style="info" %}
*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Инициализация перевода денег между своими счетами (M2M)», приведены в таблице ниже.

| Метод API (endpoint)                                                                                     | Банк отправителя денег | Банк бенефициара |
| -------------------------------------------------------------------------------------------------------- | ---------------------- | ---------------- |
| <p>Запрос верификации наличия счета клиента </p><p>(POST /v1/transfers/iso20022/acmt.023.001.03)</p>     | <p><br></p>            | +                |
| <p>Результат верификации наличия счета клиента  </p><p>(POST /v1/transfers/iso20022/acmt.024.001.03)</p> | +                      | <p><br></p>      |
| <p>Запрос на перевод денег </p><p> (POST /v1/transfers/iso20022/pacs.008.001.11)</p>                     | <p><br></p>            | +                |
| <p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p>      | +                      | +                |

## Взаимосвязь идентификаторов сообщений

Процесс «Инициализация перевода денег между своими счетами (M2M)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/6wUfAGwvRwmtCK3nxwtk" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

Описание успешного сценария процесса «Инициализация перевода денег между своими счетами (M2M)»:

***Верификация наличия счета клиента***

1. Отправитель денег в приложении Банка отправителя денег инициирует перевод денег на свой счет в другой БВУ по номеру телефона.
2. Банк отправителя денег направляет Платформе запрос верификации наличия счета клиента по номеру телефона (сообщение acmt.023), подписывая его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.
2. Процесс завершается неуспешно.

</details>

2.1. Платформа, получив запрос, проводит его обработку и валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей
* проверяет, что сквозной идентификатор \<Document::Vrfctn:Id> не использовался

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

3. Платформа направляет в Банк бенефициара запрос верификации наличия счета клиента по номеру телефона (сообщение acmt.023), подписывая его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Платформа направляет в Банк отправителя сообщение acmt.024 с ошибкой.
3. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
4. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа завершает процесс, получив сообщение с информацией об ошибке.
3. Платформа направляет в Банк отправителя сообщение acmt.024 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.
5. Процесс завершается неуспешно.

</details>

3.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

4. Банк бенефициара проверяет наличие счета по указанному в запросе номеру телефона и проверяет соответствие идентификационных данных отправителя (из acmt.023) идентификационным данным получателя.&#x20;
5. Банк бенефициара направляет результат верификации наличия счета клиента Платформе (сообщение acmt.024), подписав его своим ЭЦП. При этом идентификационные данные получателя (в acmt.024 - значение и тип для **NIDN/CCPT из тега** Rpt.UpdtdPtyAndAcctId.Pty.Id.PrvtId) должны в точности совпадать с данными отправителя (из acmt.023 - значение и тип для **NIDN/CCPT из тега** Assgnmt.Cretr.Pty.Id.PrvtId) для успешного перевода денег.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом.&#x20;
2. Банк отправителя денег завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Процесс завершается неуспешно.

* **Сведения о счете клиента не найдены или не прошла** проверка  соответствия идентификационных данных отправителя идентификационным данным получател&#x44F;**:**

1. Банк бенефициара направляет негативный результат верификации наличия счета клиента Платформе (сообщение acmt.024): ошибка `ACMT_024_ACCOUNT_NOT_FOUND`
2. Платформа направляет негативный результат верификации наличия счета клиента Банку отправителя денег (сообщение acmt.024).&#x20;
3. Процесс завершается неуспешно.

</details>

5.1. Платформа, получив запрос (сообщение acmt.024), проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

6. Платформа направляет результат верификации наличия счета клиента в Банк отправителя денег (сообщение acmt.024), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

6.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

7. Отправитель денег подтверждает перевод в приложении Банка отправителя денег.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Отправитель денег не подтверждает перевод в приложении Банка отправителя денег:**

1. Процесс завершается неуспешно.

</details>

***Транзакция по переводу денег***

9. Банк отправителя денег проводит проверку счета клиента на:&#x20;
   * валидность статуса для его дебетования&#x20;
   * отсутствие наложенного ПТП/ РПРО/ ареста и т.п.&#x20;
   * достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Проверка счета не прошла успешно:**

1. Банк отправителя денег уведомляет клиента о невозможности проведения операции.&#x20;
2. Процесс завершается неуспешно.

</details>

10. Банк отправителя денег блокирует сумму операции по счету клиента и формирует платежное поручение (pacs.008).
11. Банк отправителя денег направляет Платформе запрос на перевод денег (сообщение pacs.008), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

11.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

12. Платформа обрабатывает  запрос на перевод денег (сообщение pacs.008), в том числе:&#x20;
    * выполняет проверку позиций участников и лимитов;
    * выполняет блокирование средств для проведения транзакции;
    * выполняет поиск результата верификации наличия счета клиента по \<EndToEndId> (acmt.024).

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса на перевод денег pacs.008 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
2. Процесс завершается неуспешно.

</details>

13. Платформа направляет в Банк бенефициара запрос на перевод денег (сообщение pacs.008), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
4. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
5. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
6. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

13.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

14. Банк бенефициара проверяет счет бенефициара на возможность зачисления денег.
15. Банк бенефициара направляет статус обработки запроса перевода денег Платформе (сообщение pacs.002), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции статусом RJCT (отклонена).&#x20;
3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса перевода денег (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

15.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара&#x20;
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

16. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* &#x20;**Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

16.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

17. Платформа успешно завершает транзакцию (commit transaction).
18. Платформа направляет в качестве уведомления об успешной транзакции в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

18.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк бенефициара не производит (не производит повторное зачисление денег на счет бенефициара и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк бенефициара ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк бенефициара в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)) завершает транзакцию неуспешно (RJCT) по тайм-ауту, зачисление средств бенефициару не производится.&#x20;
3. Платформа производит откат транзакции, устанавливает статус транзакции - RJCT (неуспешно). Банк отправителя денег, получив статус транзакции RJCT (неуспешно), разблокирует средства Отправителя денег, списание средств не производится.

*Примечание: перед завершением транзакции Банк бенефициара может проверить статус транзакции на Платформе, отравив сообщение pacs.028 (см.* [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)*)*

</details>

18.2. Банк бенефициара производит зачисление денег на счет бенефициара и уведомляет об этом бенефициара.

19. Платформа направляет в качестве уведомления об успешной транзакции в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

19.1. Банк отправителя денег, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк отправителя денег ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк отправителя денег  направляет запрос статуса транзакции Платформе (сообщение pacs.028, см. [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)), подписав его своим ЭЦП.&#x20;
3. Платформа, успешно выполнив обработку запроса, направляет ответ с HTTP статусом 200.
4. Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции, подписав его ЭЦП Платформы.

</details>

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк отправителя денег не производит (не производит повторное списание денег со счета отправителя денег и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

19.2. Банк отправителя денег производит списание денег со счета отправителя денег и уведомляет его о завершении операции.


# Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2U)

Данный сценарий описывает инициализацию перевода денег юридическим лицом (Отправитель денег) на счет физического лица (Бенефициар).

Перевод денег осуществляется со счета Отправителя денег в Банке отправителя денег на счет Бенефициара в Банке бенефициара.

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2U)»отображает рисунок ниже.

<figure><img src="/files/2qhX092Np38SLXd3ZvkR" alt=""><figcaption><p>Схема процесса «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2U)»</p></figcaption></figure>

{% hint style="info" %}
*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2U)», приведены в таблице ниже.

| Метод API (endpoint)                                                                                     | Банк отправителя денег | Банк бенефициара |
| -------------------------------------------------------------------------------------------------------- | ---------------------- | ---------------- |
| <p>Запрос верификации наличия счета клиента </p><p>(POST /v1/transfers/iso20022/acmt.023.001.03)</p>     | <p><br></p>            | +                |
| <p>Результат верификации наличия счета клиента  </p><p>(POST /v1/transfers/iso20022/acmt.024.001.03)</p> | +                      | <p><br></p>      |
| <p>Запрос на перевод денег </p><p> (POST /v1/transfers/iso20022/pacs.008.001.11)</p>                     | <p><br></p>            | +                |
| <p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p>      | +                      | +                |

## Взаимосвязь идентификаторов сообщений

Процесс «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2U)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/6wUfAGwvRwmtCK3nxwtk" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

Описание успешного сценария процесса «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2U)»:

***Верификация наличия счета клиента***

1. Отправитель денег инициирует перевод денег из Банка отправителя денег Бенефициару по номеру телефона.
2. Банк отправителя денег направляет Платформе запрос верификации наличия счета клиента по номеру телефона (сообщение acmt.023), подписывая его своим ЭЦП.

> В сообщении передается:
>
> * в теге \<Document::Assgnmt:MsgId> – сгенерированный уникальный идентификатор сообщения
> * в теге \<Document::Vrfctn:Id> – сгенерированный уникальный идентификатор запроса верификации, который будет выступать в качестве сквозного идентификатора для всей цепочки сообщений в рамках данной операции перевода

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.
2. Процесс завершается неуспешно.

</details>

2.1. Платформа, получив запрос, проводит его обработку и валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей
* проверяет, что сквозной идентификатор \<Document::Vrfctn:Id> не использовался

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

3. Платформа направляет в Банк бенефициара запрос верификации наличия счета клиента по номеру телефона (сообщение acmt.023), подписывая его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::Assgnmt:MsgId> – сгенерированный уникальный идентификатор сообщения
> * в теге \<Document::Vrfctn:Id> – сквозной идентификатор для всей цепочки сообщений в рамках данной операции перевода, полученный на шаге 2

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Платформа направляет в Банк отправителя сообщение acmt.024 с ошибкой.
3. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
4. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа завершает процесс, получив сообщение с информацией об ошибке.
3. Платформа направляет в Банк отправителя сообщение acmt.024 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.
5. Процесс завершается неуспешно.

</details>

3.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

4. Банк бенефициара проверяет наличие счета по указанному в запросе номеру телефона.
5. Банк бенефициара направляет результат верификации наличия счета клиента Платформе (сообщение acmt.024), подписав его своим ЭЦП.

> В сообщении передается:
>
> * в теге \<Document::Rpt:OrgnlId> – сквозной идентификатор из тега \<Vrfctn:Id> исходного запроса (из acmt.023)
> * При наличии счета бенефициара передается его ФИО и IBAN для счета бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом.&#x20;
2. Банк отправителя денег завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Процесс завершается неуспешно.

* **Сведения о счете клиента не найдены:**

1. Банк бенефициара направляет негативный результат верификации наличия счета клиента Платформе (сообщение acmt.024).
2. Платформа направляет негативный результат верификации наличия счета клиента Банку отправителя денег (сообщение acmt.024).&#x20;
3. Процесс завершается неуспешно.

</details>

5.1. Платформа, получив запрос (сообщение acmt.024), проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

6. Платформа направляет результат верификации наличия счета клиента в Банк отправителя денег (сообщение acmt.024), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::Rpt:OrgnlId> – сквозной идентификатор из тега \<Vrfctn:Id> исходного запроса (из acmt.023)
> * При наличии счета бенефициара передается его ФИО и IBAN для счета бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

6.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

7. Банк отправителя денег отображает информацию о бенефициаре (имя и первая буква фамилии, например, «Имя Ф.»), чтобы Отправитель денег мог удостовериться в корректности получателя.
8. Отправитель денег подтверждает перевод в приложении Банка отправителя денег.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Отправитель денег не подтверждает перевод в приложении Банка отправителя денег:**

1. Процесс завершается неуспешно.

</details>

***Транзакция по переводу денег***

9. Банк отправителя денег проводит проверку счета клиента на:&#x20;
   * валидность статуса для его дебетования&#x20;
   * отсутствие наложенного ПТП/ РПРО/ ареста и т.п.&#x20;
   * достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Проверка счета не прошла успешно:**

1. Банк отправителя денег уведомляет клиента о невозможности проведения операции.&#x20;
2. Процесс завершается неуспешно.

</details>

10. Банк отправителя денег блокирует сумму операции по счету клиента и формирует платежное поручение (pacs.008).
11. Банк отправителя денег направляет Платформе запрос на перевод денег (сообщение pacs.008), подписав его своим ЭЦП.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::PmtId:EndToEndId> – сквозной идентификатор из тега \<OrgnlId> из сообщения acmt.024&#x20;
> * в поле \<Document::PmtId:TxId> – сгенерированный уникальный идентификатор новой транзакции
> * указывается  IBAN для счета Отправителя денег
> * указывается  IBAN для счета Бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

11.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

12. Платформа обрабатывает  запрос на перевод денег (сообщение pacs.008), в том числе:&#x20;
    * выполняет проверку позиций участников и лимитов;
    * выполняет блокирование средств для проведения транзакции;
    * выполняет поиск результата верификации наличия счета клиента по \<EndToEndId> (acmt.024).

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса на перевод денег pacs.008 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
2. Процесс завершается неуспешно.

</details>

13. Платформа направляет в Банк бенефициара запрос на перевод денег (сообщение pacs.008), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::PmtId:EndToEndId> – сквозной идентификатор из тега \<OrgnlId> из сообщения acmt.024, соответствует \<EndToEndId> из сообщения pacs.008 Банка отправителя денег
> * в поле \<Document::PmtId:TxId> – идентификатор транзакции из тега \<TxId> из сообщения pacs.008 Банка отправителя денег
> * указывается  IBAN для счета Отправителя денег
> * указывается  IBAN для счета Бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
4. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
5. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
6. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

13.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

14. Банк бенефициара проверяет счет бенефициара на возможность зачисления денег.
15. Банк бенефициара направляет статус обработки запроса перевода денег Платформе (сообщение pacs.002), подписав его своим ЭЦП.

> В сообщении передается:
>
> * \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<EndToEndId> исходного запроса (pacs.008)
> * \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<TxId> исходного запроса (из pacs.008)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции статусом RJCT (отклонена).&#x20;
3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса перевода денег (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

15.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара&#x20;
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

16. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<EndToEndId> исходного запроса (pacs.008)
> * в теге \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<TxId> исходного запроса (из pacs.008)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* &#x20;**Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

16.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

17. Платформа успешно завершает транзакцию (commit transaction).
18. Платформа направляет в качестве уведомления об успешной транзакции в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

18.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк бенефициара не производит (не производит повторное зачисление денег на счет бенефициара и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк бенефициара ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк бенефициара в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)) завершает транзакцию неуспешно (RJCT) по тайм-ауту, зачисление средств бенефициару не производится.&#x20;
3. Платформа производит откат транзакции, устанавливает статус транзакции - RJCT (неуспешно). Банк отправителя денег, получив статус транзакции RJCT (неуспешно), разблокирует средства Отправителя денег, списание средств не производится.

*Примечание: перед завершением транзакции Банк бенефициара может проверить статус транзакции на Платформе, отравив сообщение pacs.028 (см.* [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)*)*

</details>

18.2. Банк бенефициара производит зачисление денег на счет бенефициара и уведомляет об этом бенефициара.

19. Платформа направляет в качестве уведомления об успешной транзакции в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

19.1. Банк отправителя денег, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк отправителя денег ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк отправителя денег  направляет запрос статуса транзакции Платформе (сообщение pacs.028, см. [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)), подписав его своим ЭЦП.&#x20;
3. Платформа, успешно выполнив обработку запроса, направляет ответ с HTTP статусом 200.
4. Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции, подписав его ЭЦП Платформы.

</details>

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк отправителя денег не производит (не производит повторное списание денег со счета отправителя денег и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

19.2. Банк отправителя денег производит списание денег со счета отправителя денег и уведомляет его о завершении операции.


# Инициализация перевода денег между своими счетами (M2M2)

Данный сценарий описывает инициализацию перевода денег клиентом (Отправитель денег) со своего счета в одном БВУ (Банк отправителя денег) на свой счет в другой БВУ (Банк бенефициара, т.е. банк, обслуживающий счет клиента, на который переводятся деньги). Причем, перевод инициируется в приложении Банка отправителя денег.

Для реализации данного сценария в приложении Банка отправителя денег должно быть реализовано получение информации о счетах клиента (Отправителя денег), чтобы была возможность выбора счета клиента, на который переводятся деньги в другом банке. Подробное описание того, как получить информацию о счетах клиента из других банков приведено в документе «Руководство разработчика. Получение информации о счетах клиента».

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Инициализация перевода денег между своими счетами (M2M2)» отображает рисунок ниже.

<figure><img src="/files/JPlAFZN0JfTtVIij5Yxi" alt=""><figcaption><p>Схема процесса «Инициализация перевода денег между своими счетами (M2M2)»</p></figcaption></figure>

{% hint style="info" %}
*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Инициализация перевода денег между своими счетами (M2M2)», приведены в таблице ниже.

| Метод API (endpoint)                                                                                | Банк отправителя денег | Банк бенефициара |
| --------------------------------------------------------------------------------------------------- | ---------------------- | ---------------- |
| <p>Запрос на перевод денег </p><p> (POST /v1/transfers/iso20022/pacs.008.001.11)</p>                | <p><br></p>            | +                |
| <p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p> | +                      | +                |

## Взаимосвязь идентификаторов сообщений

Процесс «Инициализация перевода денег между своими счетами (M2M2)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/EW5EB1dR6YNhZ5T3Qnuw" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

{% hint style="warning" %}
***Обязательное предусловие:***

*Для реализации данного сценария в приложении Банка отправителя денег должно быть реализовано получение информации о счетах клиента (Отправителя денег), чтобы была возможность выбора счета клиента, на который переводятся деньги в другом банке. Подробное описание того, как получить информацию о счетах клиента из других банков приведено в документе «Руководство разработчика. Получение информации о счетах клиента».*
{% endhint %}

Описание успешного сценария процесса «Инициализация перевода денег между своими счетами (M2M2)»:

1. Банк отправителя денег проводит проверку счета клиента на:

* валидность статуса для его дебетования&#x20;
* отсутствие наложенного ПТП/ РПРО/ ареста и т.п.&#x20;
* достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Проверка счета не прошла успешно:**

1. Банк отправителя денег уведомляет клиента о невозможности проведения операции.&#x20;
2. Процесс завершается неуспешно.

</details>

2. Банк отправителя денег блокирует сумму операции по счету клиента и формирует платежное поручение (pacs.008).
3. Банк отправителя денег направляет Платформе запрос на перевод денег (сообщение pacs.008), подписав его своим ЭЦП.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::PmtId:EndToEndId> – сгенерированный уникальный идентификатор, который будет выступать в качестве сквозного идентификатора для всей цепочки сообщений в рамках данной операции перевода
> * в поле \<Document::PmtId:TxId> – сгенерированный уникальный идентификатор новой транзакции
> * указывается  IBAN для счета Отправителя денег
> * указывается  идентификатор Платформы (OBID) для счета Бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

3.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.&#x20;

4. Платформа обрабатывает  запрос на перевод денег (сообщение pacs.008), в том числе:&#x20;
   * выполняет проверку позиций участников и лимитов;
   * выполняет блокирование средств для проведения транзакции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса на перевод денег pacs.008 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
2. Процесс завершается неуспешно.

</details>

5. Платформа направляет в Банк бенефициара запрос на перевод денег (сообщение pacs.008), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::PmtId:EndToEndId> – сквозной идентификатор из тега \<EndToEndId> сообщения pacs.008 Банка отправителя денег
> * в поле \<Document::PmtId:TxId> – идентификатор транзакции из тега \<TxId> из сообщения pacs.008 Банка отправителя денег
> * указывается  IBAN для счета Отправителя денег
> * указывается  идентификатор Платформы (OBID) для счета Бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
4. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
5. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
6. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

5.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

6. Банк бенефициара проверяет счет бенефициара на возможность зачисления денег.
7. Банк бенефициара направляет статус обработки запроса перевода денег Платформе (сообщение pacs.002), подписав его своим ЭЦП.

> В сообщении передается:
>
> * \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<EndToEndId> исходного запроса (pacs.008)
> * \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<TxId> исходного запроса (из pacs.008)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Банк отправителя денег,  не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса перевода денег (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

7.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара&#x20;
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

8. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<EndToEndId> исходного запроса (pacs.008)
> * в теге \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<TxId> исходного запроса (из pacs.008)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

8.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

9. Платформа успешно завершает транзакцию (commit transaction).
10. Платформа направляет в качестве уведомления об успешной транзакции в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

10.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк бенефициара не производит (не производит повторное зачисление денег на счет бенефициара и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк бенефициара ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк бенефициара в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)) завершает транзакцию неуспешно (RJCT) по тайм-ауту, зачисление средств бенефициару не производится. Платформа производит откат транзакции, устанавливает статус транзакции - RJCT (неуспешно). Банк отправителя денег, получив статус транзакции RJCT (неуспешно), разблокирует средства Отправителя денег, списание средств не производится.

*Примечание: перед завершением транзакции Банк бенефициара может проверить статус транзакции на Платформе, отравив сообщение pacs.028 (см.* [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)*)*

</details>

10.2. Банк бенефициара производит зачисление денег на счет бенефициара и уведомляет об этом бенефициара.

11. Платформа направляет в качестве уведомления об успешной транзакции в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

11.1. Банк отправителя денег, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк отправителя денег не производит (не производит повторное списание денег со счета отправителя денег и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк отправителя денег ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк отправителя денег  направляет запрос статуса транзакции Платформе (сообщение pacs.028, см. [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)), подписав его своим ЭЦП.&#x20;
3. Платформа, успешно выполнив обработку запроса, направляет ответ с HTTP статусом 200.
4. Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции, подписав его ЭЦП Платформы.

</details>

11.2. Банк отправителя денег производит списание денег со счета отправителя денег и уведомляет его о завершении операции.


# Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2I) с проведением идентификации бенефициара

Данный сценарий описывает инициализацию перевода денег юридическим лицом (Отправитель денег) на счет физического лица (Бенефициар).

Перевод денег осуществляется со счета Отправителя денег в Банке отправителя денег на счет Бенефициара в Банке бенефициара. Перед проведением перевода денег выполняется верификация принадлежности банковского счета бенефициару по номеру телефона бенефициара.

Для обеспечения возможности проверки принадлежности счета бенефициар предоставляет согласие на доступ к данным о его номере счета по номеру телефона. В случае невозможности проверки принадлежности банковского счета перевод денег не осуществляется.

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2I) с проведением идентификации бенефициара» отображает рисунок ниже.

<figure><img src="/files/JYgr17LyB9qQRPDIdybz" alt=""><figcaption><p align="center">Схема процесса «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2I) с проведением идентификации бенефициара»</p></figcaption></figure>

{% hint style="info" %}
*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

Для обеспечения возможности проверки принадлежности счета бенефициар предоставляет согласие на доступ к данным о его номере счета по номеру телефона. Описание подпроцесса «Регистрация согласия на проверку принадлежности счета» приведено ниже в разделе «Описание процесса»

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2I) с проведением идентификации бенефициара», приведены в таблице ниже.

| Метод API (endpoint)                                                                                     | Банк отправителя денег | Банк бенефициара |
| -------------------------------------------------------------------------------------------------------- | ---------------------- | ---------------- |
| <p>Запрос верификации наличия счета клиента </p><p>(POST /v1/transfers/iso20022/acmt.023.001.03)</p>     | <p><br></p>            | +                |
| <p>Результат верификации наличия счета клиента  </p><p>(POST /v1/transfers/iso20022/acmt.024.001.03)</p> | +                      | <p><br></p>      |
| <p>Запрос на перевод денег </p><p> (POST /v1/transfers/iso20022/pacs.008.001.11)</p>                     | <p><br></p>            | +                |
| <p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p>      | +                      | +                |

## Взаимосвязь идентификаторов сообщений

Процесс «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2I) с верификацией номера счета» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/6wUfAGwvRwmtCK3nxwtk" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

Описание успешного сценария процесса «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2I) с проведением идентификации бенефициара»:

**Регистрация согласия на проверку принадлежности счета**

1. Для того, чтобы перед отправкой денег Отправитель денег (ЮЛ) мог выполнить проверку принадлежности счета Бенефициару (ФЛ) необходимо получение согласия на это от Бенефициара. Регистрация согласия на проверку принадлежности счета производится посредством сервисов Центра обмена идентификационными данными (ЦОИД).

При успешном предоставлении согласия Бенефициаром (ФЛ) Отправителю денег будет предоставлен подтверждающий это токен, который используется при верификации наличия счета клиента.

<figure><img src="/files/RylBqVR0mfUPpB5gt7h4" alt=""><figcaption></figcaption></figure>

**Подпроцесс «Регистрация согласия на проверку принадлежности счета»**

1. Система отправителя денег получает URL-адрес для перенаправления бенефициара на сервис ЦОИД. Описание метода «Получить URL-адрес для перенаправления клиента» (POST /v1/auth/generate-user-url) приведено в  <https://auth-openapi.npck.kz/#tag/Auth/operation/generateUserUrl>

{% hint style="info" %}
То какая услуга ЦОИД должна быть предоставлена определяется значениями, указанными в параметре scoped при запросе URL-адреса для перенаправления клиента в ЦОИД.

Для регистрации согласия на проверку принадлежности счета используется значение b2c2i.

Значение b2с2i, может использоваться совместно со значениями scopes для персональных данным и верификации физического лица (см. [Сервисы ЦОИД](https://docs.npck.kz/servisy-coid))&#x20;
{% endhint %}

2. Для проведения двухфакторной аутентификации Система отправителя денег перенаправляет бенефициара на полученный URL-адрес.

{% hint style="warning" %}
Время действия URL-адреса для перенаправления (время «жизни») составляет 15 минут
{% endhint %}

{% hint style="warning" %}
Если в ОС Android при проведении liveness-сессии не отображается изображение клиента, то потенциальным решением проблемы может являться применение следующих параметров:

*webView\.settings.allowContentAccess = true;*

*webView\.settings.mediaPlaybackRequiresUserGesture = false;*&#x20;

*webView\.settings.domStorageEnabled = true*

WebKit в Android, позволяет видео компонентам запускаться только по действию пользователя, при этом для корректной работы сервисов ЦОИД камера запускается программными средствами (autoplay), WebKit блокирует данное действие и выдает ошибку. Чтобы избежать этого, необходимо в компоненте webView указать данную настройку.
{% endhint %}

{% hint style="warning" %}
В IOS необходимо использовать SafariWebView. WKWebView не поддерживается.
{% endhint %}

3. Бенефициару отображается форма аутентификации ЦОИД. Пользователь проходит двухфакторную аутентификацию личности.
4. Бенефициар должен дать согласие на проверку принадлежности счета Отправителем денег.

{% hint style="info" %}
Бенефициар может отклонить согласие на доступ к его данным.

Если Бенефициар отклоняет согласие на доступ к его данным или происходит ошибка, то клиент будет перенаправлен на указанный на шаге 1 **redirectUri**, с указанием кода ошибки, по следующему шаблону:

`[redirectUri]?errorCode=[error code]&state=[state]`

В таком случае процесс завершается, код авторизации не предоставляется.
{% endhint %}

5. После того, как Бенефициар выполнит все действия на стороне ЦОИД, осуществляется его возврат в приложение отправителя денег.

{% hint style="info" %}
Если аутентификация Бенефициара проходит успешно и он дает согласие на доступ к его данным, то Бенефициар перенаправляется обратно в приложение Отправителя денег (на указанный в запросе *redirectUri*) с одноразовым кодом авторизации (code), по следующему шаблону:

`[redirectUri]?code=[authorization code]&state=[state]`
{% endhint %}

{% hint style="warning" %}
Код авторизации является одноразовым.

Время действия кода авторизации (время «жизни») составляет 300 секунд
{% endhint %}

{% hint style="warning" %}
Редирект из webview в случае SafariWebView нужно перехватывать через диплинк (deeplink)
{% endhint %}

6. Система Отправителя денег получает токен доступа (в формате JWT), который необходим для верификации наличия счета клиента, используя полученный на предыдущем шаге код авторизации. Описание используемого для этого метода приведено в <https://auth-openapi.npck.kz/#tag/Auth/operation/getOauthToken>

{% hint style="info" %}
Срок действия токена составляет 3 часа
{% endhint %}

**Верификация наличия счета клиента**

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

{% hint style="info" %}
Срок действия токена составляет 3 часа
{% endhint %}

{% hint style="warning" %}
Информационное взаимодействие между Отправителем денег и Банком отправителя денег выходит за рамки данной спецификации.

Должно быть обеспечена безопасная передача токена доступа из системы Отправителя денег в Банк отправителя денег для инициализации перевода.&#x20;
{% endhint %}

3. Банк отправителя денег направляет Платформе запрос верификации наличия счета клиента по номеру телефона (сообщение acmt.023), подписывая его своим ЭЦП.

В HTTP-заголовке запроса в параметре Authorization передается токен доступа из шага 1.

При отсутствии токена, передачи некорректного или недействительного токена будет возвращена ошибка с HTTP-статусом 401.

> В сообщении передается:
>
> * в теге \<Document::Assgnmt:MsgId> – сгенерированный уникальный идентификатор сообщения
> * в теге \<Document::Vrfctn:Id> – сгенерированный уникальный идентификатор запроса верификации, который будет выступать в качестве сквозного идентификатора для всей цепочки сообщений в рамках данной операции перевода

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.
2. Процесс завершается неуспешно.

</details>

3.1. Платформа, получив запрос, проводит его обработку и валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей
* проверяет, что сквозной идентификатор \<Document::Vrfctn:Id> не использовался
* проверяет срок действия токена доступа и область действия токена (scope)

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

4. Платформа направляет в Банк бенефициара запрос верификации наличия счета клиента по номеру телефона (сообщение acmt.023), подписывая его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::Assgnmt:MsgId> – сгенерированный уникальный идентификатор сообщения
> * в теге \<Document::Vrfctn:Id> – сквозной идентификатор для всей цепочки сообщений в рамках данной операции перевода, полученный на шаге 2

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Платформа направляет в Банк отправителя сообщение acmt.024 с ошибкой.
3. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
4. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа завершает процесс, получив сообщение с информацией об ошибке.
3. Платформа направляет в Банк отправителя сообщение acmt.024 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.
5. Процесс завершается неуспешно.

</details>

4.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

5. Банк бенефициара проверяет наличие счета по указанному в запросе номеру телефона.
6. Банк бенефициара направляет результат верификации наличия счета клиента Платформе (сообщение acmt.024), подписав его своим ЭЦП.

> В сообщении передается:
>
> * в теге \<Document::Rpt:OrgnlId> – сквозной идентификатор из тега \<Vrfctn:Id> исходного запроса (из acmt.023)
> * При наличии счета бенефициара передается его ФИО и IBAN для счета бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом.&#x20;
2. Банк отправителя денег завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Процесс завершается неуспешно.

* **Сведения о счете клиента не найдены:**

1. Банк бенефициара направляет негативный результат верификации наличия счета клиента Платформе (сообщение acmt.024).
2. Платформа направляет негативный результат верификации наличия счета клиента Банку отправителя денег (сообщение acmt.024).&#x20;
3. Процесс завершается неуспешно.

</details>

6.1. Платформа, получив запрос (сообщение acmt.024), проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

7. Платформа направляет результат верификации наличия счета клиента в Банк отправителя денег (сообщение acmt.024), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::Rpt:OrgnlId> – сквозной идентификатор из тега \<Vrfctn:Id> исходного запроса (из acmt.023)
> * При наличии счета бенефициара передается его ФИО и IBAN для счета бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

7.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

8. Банк отправителя денег предоставляет Отправителю денег информацию о бенефициаре, чтобы Отправитель денег мог удостовериться в корректности получателя.
9. Отправитель денег подтверждает перевод.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Отправитель денег не подтверждает перевод в приложении Банка отправителя денег:**

1. Процесс завершается неуспешно.

</details>

***Транзакция по переводу денег***

10. Банк отправителя денег проводит проверку счета клиента на:&#x20;

* валидность статуса для его дебетования&#x20;
* отсутствие наложенного ПТП/ РПРО/ ареста и т.п.&#x20;
* достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Проверка счета не прошла успешно:**

1. Банк отправителя денег уведомляет клиента о невозможности проведения операции.
2. Процесс завершается неуспешно.

</details>

11. Банк отправителя денег блокирует сумму операции по счету клиента и формирует платежное поручение (pacs.008).
12. Банк отправителя денег направляет Платформе запрос на перевод денег (сообщение pacs.008), подписав его своим ЭЦП.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::PmtId:EndToEndId> – сквозной идентификатор из тега \<OrgnlId> из сообщения acmt.024&#x20;
> * в поле \<Document::PmtId:TxId> – сгенерированный уникальный идентификатор новой транзакции
> * указывается  IBAN для счета Отправителя денег
> * указывается  IBAN для счета Бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

12.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

13. Платформа обрабатывает  запрос на перевод денег (сообщение pacs.008), в том числе:&#x20;

* выполняет проверку позиций участников и лимитов;
* выполняет блокирование средств для проведения транзакции;
* выполняет поиск результата верификации наличия счета клиента по \<EndToEndId> (acmt.024).

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса на перевод денег pacs.008 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
2. Процесс завершается неуспешно.

</details>

14. Платформа направляет в Банк бенефициара запрос на перевод денег (сообщение pacs.008), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::PmtId:EndToEndId> – сквозной идентификатор из тега \<OrgnlId> из сообщения acmt.024, соответствует \<EndToEndId> из сообщения pacs.008 Банка отправителя денег
> * в поле \<Document::PmtId:TxId> – идентификатор транзакции из тега \<TxId> из сообщения pacs.008 Банка отправителя денег
> * указывается  IBAN для счета Отправителя денег
> * указывается  IBAN для счета Бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
4. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
5. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
6. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

14.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

15. Банк бенефициара проверяет счет бенефициара на возможность зачисления денег.
16. Банк бенефициара направляет статус обработки запроса перевода денег Платформе (сообщение pacs.002), подписав его своим ЭЦП.

> В сообщении передается:
>
> * \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<EndToEndId> исходного запроса (pacs.008)
> * \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<TxId> исходного запроса (из pacs.008)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции статусом RJCT (отклонена).&#x20;
3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса перевода денег (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

16.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара&#x20;
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

17. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<EndToEndId> исходного запроса (pacs.008)
> * в теге \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<TxId> исходного запроса (из pacs.008)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* &#x20;**Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

17.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

18. Платформа успешно завершает транзакцию (commit transaction).
19. Платформа направляет в качестве уведомления об успешной транзакции в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

19.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк бенефициара не производит (не производит повторное зачисление денег на счет бенефициара и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк бенефициара ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк бенефициара в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)) завершает транзакцию неуспешно (RJCT) по тайм-ауту, зачисление средств бенефициару не производится.&#x20;
3. Платформа производит откат транзакции, устанавливает статус транзакции - RJCT (неуспешно). Банк отправителя денег, получив статус транзакции RJCT (неуспешно), разблокирует средства Отправителя денег, списание средств не производится.

*Примечание: перед завершением транзакции Банк бенефициара может проверить статус транзакции на Платформе, отравив сообщение pacs.028 (см.* [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)*)*

</details>

19.2. Банк бенефициара производит зачисление денег на счет бенефициара и уведомляет об этом бенефициара.

20. Платформа направляет в качестве уведомления об успешной транзакции в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

20.1. Банк отправителя денег, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк отправителя денег ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк отправителя денег  направляет запрос статуса транзакции Платформе (сообщение pacs.028, см. [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)), подписав его своим ЭЦП.&#x20;
3. Платформа, успешно выполнив обработку запроса, направляет ответ с HTTP статусом 200.
4. Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции, подписав его ЭЦП Платформы.

</details>

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк отправителя денег не производит (не производит повторное списание денег со счета отправителя денег и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

20.2. Банк отправителя денег производит списание денег со счета отправителя денег и уведомляет его о завершении операции.


# Возврат полученного перевода (C2CR)

Данный сценарий описывает возврат денег по ранее полученному переводу.

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

Бенефициаром является клиент, которому возвращаются деньги (т.е. изначальный отправитель перевода).

Запрос возврата денег (pacs.004) формируется на основе исходного платежного поручения (pacs.008), по которому был ранее выполнен перевод денег.&#x20;

{% hint style="warning" %}
*Важно! Допускается возврат только полной суммы полученного ранее перевода. Возврат по ранее полученному переводу может быть выполнен только один раз. Если запрос возврата денег по переводу находится в обработке, то повторный запрос возврата денег по данному переводу не должен отправляться до ее завершения.*
{% endhint %}

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Возврат полученного перевода (C2CR)» отображает рисунок ниже.

<figure><img src="/files/mlALXJkgPFtDnjiBfs4s" alt=""><figcaption><p>Схема процесса «Возврат полученного перевода (C2CR)»</p></figcaption></figure>

{% hint style="info" %}
*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Возврат полученного перевода (C2CR)», приведены в таблице ниже.

участника

| Метод API (endpoint)                                                                                | Банк отправителя денег | Банк бенефициара |
| --------------------------------------------------------------------------------------------------- | ---------------------- | ---------------- |
| <p>Запрос возврата денег </p><p> (POST /v1/transfers/iso20022/pacs.004.001.12)</p>                  | <p><br></p>            | +                |
| <p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p> | +                      | +                |

## Взаимосвязь идентификаторов сообщений

Процесс «Возврат полученного перевода (C2CR)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/AMGLNiY5dQ7dxf2rBcDO" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

Описание успешного сценария процесса «Возврат полученного перевода (C2CR)»:

1. Отправитель денег (бенефициар из оригинальной транзакции) в приложении Банка отправителя денег инициализирует возврат денег по ранее полученному переводу.

{% hint style="warning" %}
Допускается возврат только полной суммы полученного ранее перевода
{% endhint %}

**Транзакция по проведению возврата денег**

2. Банк отправителя денег производит проверку, что сумма возврата соответствует исходной транзакции, и по данному переводу возврат не производился (выполненный или находящийся в обработке).

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Запрошена некорректная сумма возврата или отсутствуют данные о полученном ранее переводе, по которому запрошен возврат:**

1. Банк отправителя денег отклоняет запрос возврата полученного перевода.
2. Процесс завершается неуспешно.

</details>

3. Банк отправителя денег проводит проверку счета клиента на:&#x20;
   * валидность статуса для его дебетования&#x20;
   * отсутствие наложенного ПТП/ РПРО/ ареста и т.п.&#x20;
   * достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Проверка счета не прошла успешно:**

1. Банк отправителя денег уведомляет клиента о невозможности проведения операции.&#x20;
2. Процесс завершается неуспешно.

</details>

4. Банк отправителя денег блокирует сумму операции по счету клиента и формирует запрос возврата денег (pacs.004) на основе исходного сообщения pacs.008, по которому был проведен перевод.
5. Банк отправителя денег направляет Платформе запрос на проведение возврата денег (сообщение pacs.004), подписав его своим ЭЦП.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::TxInf:RtrId> – сгенерированный уникальный идентификатор транзакции на возврат денег
> * в теге \<Document::TxInf:OrgnlInstrId > – сгенерированный уникальный сквозной идентификатор для всей цепочки сообщений в рамках данной операции возврата денег
> * в теге \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<EndToEndId> исходного сообщения pacs.008, по которому был проведен перевод
> * в теге \<Document::OrgnlTxId> – идентификатор транзакции из тега \<TxId> исходного сообщения pacs.008, по которому был проведен перевод
> * указывается  IBAN для счета Отправителя денег (бенефициар из оригинальной транзакции)
> * указывается  IBAN для счета Бенефициара (отправителя денег из оригинальной транзакции)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

5.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

6. Платформа обрабатывает  запрос на проведение возврата денег (сообщение pacs.004), в том числе:&#x20;
   * производит проверку, что сумма возврата соответствует исходной транзакции, и по данному переводу возврат не производился (выполненный или находящийся в обработке);
   * выполняет проверку позиций участников и лимитов;
   * выполняет блокирование средств для проведения транзакции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса возврата денег pacs.004 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса на проведение возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
2. Процесс завершается неуспешно.

</details>

7. Платформа направляет в Банк бенефициара запрос на проведение возврата денег (сообщение pacs.004), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::RtrId> – идентификатор транзакции из тега \<RtrId> сообщения pacs.004 Банка отправителя денег
> * в теге \<Document::OrgnlInstrId> – сквозной идентификатор из тега \<OrgnlInstrId> сообщения pacs.004 Банка отправителя денег
> * в теге \<Document::OrgnlEndToEndId> – сквозной идентификатор исходной операции оплаты из тега \<OrgnlEndToEndId> сообщения pacs.004 Банка отправителя денег
> * в теге \<Document::OrgnlTxId> – идентификатор транзакции исходной операции оплаты из тега \<OrgnlTxId> из сообщения pacs.004 Банка отправителя денег
> * указывается  IBAN для счета Отправителя денег (бенефициара из оригинальной транзакции) из сообщения pacs.004 Банка отправителя денег
> * указывается  IBAN для счета Бенефициара (отправителя денег из оригинальной транзакции)из сообщения pacs.004 Банка отправителя денег

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
4. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
5. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
6. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

7.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

8. Банк бенефициара проверяет счет бенефициара (отправителя денег из оригинальной транзакции) на возможность зачисления денег.
9. Банк бенефициара направляет статус обработки запроса проведения возврата денег Платформе (сообщение pacs.002), подписав его своим ЭЦП.

> В сообщении передается:
>
> * \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<OrgnlInstrId> исходного запроса (pacs.004)
> * \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<RtrId> исходного запроса (из pacs.004)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса проведения возврата денег (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса проведения возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

9.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара&#x20;
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

10. Платформа направляет статус обработки запроса проведения возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<OrgnlInstrId> исходного запроса (pacs.004)
> * в теге \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<RtrId> исходного запроса (из pacs.004)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

10.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

11. Платформа успешно завершает транзакцию (commit transaction).
12. Платформа направляет в качестве уведомления об успешной транзакции в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

12.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание:*&#x20;

*Если Платформа направляет в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк бенефициара не производит (не производит повторное зачисление денег на счет бенефициара и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк бенефициара ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк бенефициара в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)) завершает транзакцию неуспешно (RJCT) по тайм-ауту, зачисление средств бенефициару не производится. Платформа производит откат транзакции, устанавливает статус транзакции - RJCT (неуспешно). Банк отправителя денег, получив статус транзакции RJCT (неуспешно), разблокирует средства Отправителя денег, списание средств не производится.

*Примечание: перед завершением транзакции Банк бенефициара может проверить статус транзакции на Платформе, отравив сообщение pacs.028 (см.* [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)*)*

</details>

12.2. Банк бенефициара производит зачисление денег на счет бенефициара (отправителя денег из оригинальной транзакции) и уведомляет об этом бенефициара (отправителя денег из оригинальной транзакции).

13. Платформа направляет в качестве уведомления об успешной транзакции в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

13.1. Банк отправителя денег, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк отправителя денег не производит (не производит повторное списание денег со счета отправителя денег и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк отправителя денег ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк отправителя денег  направляет запрос статуса транзакции Платформе (сообщение pacs.028, см. [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)), подписав его своим ЭЦП.&#x20;
3. Платформа, успешно выполнив обработку запроса, направляет ответ с HTTP статусом 200.
4. Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции, подписав его ЭЦП Платформы.

</details>

13.2. Банк отправителя денег производит списание денег со счета Отправителя денег (бенефициара из оригинальной транзакции) и уведомляет его о завершении операции.


# Инициализация проведения платежей (по QR-коду) в рамках адаптационной модели

{% hint style="info" %}
Реализация процессов инициализации платежей и переводов денежных средств основана на методах API, описанных в электронном формате в <https://transfers-openapi.npck.kz/>
{% endhint %}

{% hint style="warning" %}
Во всех запросах должен быть указан **HTTP заголовок end-to-end-id**, в котором должен указываться сквозной идентификатор для всей цепочки сообщений, использующийся в рамках данной операции *(должен совпадать с соответствующим значением, передаваемым в теле сообщения)*
{% endhint %}

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


# Инициализация оплаты по QR-коду (C2B2)

Данный сценарий описывает инициализацию проведения оплаты за товар/услугу посредством сканирования QR-кода в POS-терминале или посредством статического QR-кода.

В рамках данного сценария клиенту предоставляется возможность QR-оплаты из приложения одного банка (банка отправителя денег) через POS-терминал или статический QR-код другого банка (банка бенефициара).

{% hint style="warning" %}
*Важно! Если отсканированный QR-код выпущен самим Банком отправителя денег, то оплата производится внутри Банка отправителя денег без взаимодействия с Платформой. Т.е. если счет бенефициара, указанный в QR-коде, также обслуживается в данном банке, то производится внутрибанковская операция.*
{% endhint %}

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Инициализация оплаты по QR-коду (C2B2)» отображает рисунок ниже.

<figure><img src="/files/R7xBHqbpwPMYfpIYIRcX" alt=""><figcaption><p>Схема процесса «Инициализация оплаты по QR-коду (C2B2)»</p></figcaption></figure>

*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Инициализация оплаты по QR-коду (C2B2)», приведены в таблице ниже.

<table><thead><tr><th width="388">Метод API (endpoint)</th><th width="170">Банк отправителя денег</th><th>Банк бенефициара</th></tr></thead><tbody><tr><td><p>Запрос данных по QR-коду для оплаты</p><p>(POST /v1/transfers/iso20022/admi.009.001.02)</p></td><td><br></td><td>+</td></tr><tr><td><p>Данные для оплаты</p><p>(POST /v1/transfers/iso20022/admi.010.001.02)</p></td><td>+</td><td></td></tr><tr><td><p>Запрос на перевод денег </p><p> (POST /v1/transfers/iso20022/pacs.008.001.11)</p></td><td></td><td>+</td></tr><tr><td><p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p></td><td>+</td><td>+</td></tr></tbody></table>

## Взаимосвязь идентификаторов сообщений

Процесс «Инициализация оплаты по QR-коду (C2B2)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/V7lxDStfkLh8xuG5WOSG" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

Описание успешного сценария процесса «Инициализация оплаты по QR-коду (C2B2)»:

***Генерация и считывание QR-кода для оплаты***

1. POS-терминал направляет данные о платеже в Банк бенефициара

> Для статического QR-кода данный шаг не применяется

2. Банк бенефициара формирует данные для QR-кода для оплаты
3. Отправитель денег в приложении Банка отправителя денег сканирует QR-код в POS-терминале или статический QR-код

{% hint style="warning" %}
*Важно! Если отсканированный QR-код выпущен самим Банком отправителя денег, то оплата производится внутри Банка отправителя денег без взаимодействия с Платформой. Т.е. если счет бенефициара, указанный в QR-коде, также обслуживается в данном банке, то производится внутрибанковская операция.*
{% endhint %}

4. Банк отправителя денег направляет Платформе запрос данных для оплаты (сообщение admi.009), по ссылке из QR-кода, подписав его своим ЭЦП

> В сообщении передается:
>
> * в теге \<Document:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document:SplmtryData:PlcAndNm> с ключом END\_TO\_END\_ID – сгенерированный уникальный идентификатор, который будет выступать в качестве сквозного идентификатора для всей цепочки сообщений в рамках данной операции оплаты

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Банк отправителя денег завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).&#x20;
2. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

4.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

5. Платформа направляет в Банк бенефициара запрос данных для оплаты (сообщение admi.009), подписав его ЭЦП Платформы

> В сообщении передается:
>
> * в теге \<Document:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document:SplmtryData:PlcAndNm> с ключом END\_TO\_END\_ID –
>
> сквозной идентификатор из сообщения admi.009 Банка отправителя денег

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа направляет в Банк отправителя сообщение admi.010 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
5. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа завершает процесс, получив сообщение с информацией об ошибке.
3. Платформа направляет в Банк отправителя сообщение admi.010 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.
5. Процесс завершается неуспешно.

</details>

5.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей
* выполняет поиск данных по идентификатору QR-кода

6. Банк бенефициара направляет данные для оплаты Платформе (сообщение admi.010), подписав его своим ЭЦП

> В сообщении передается:
>
> * в теге \<Document:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document:RptDtls:ReqRef> – сквозной идентификатор из тега \<Document::SplmtryData:PlcAndNm> с ключом END\_TO\_END\_ID исходного запроса (admi.009)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку бенефициара ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Банк бенефициара завершается процесс с ошибкой.
3. Банк отправителя денег завершает процесс по тайм-ауту (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).&#x20;
4. Процесс завершается неуспешно.

</details>

6.1. Платформа, получив ответ, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей

7. Платформа направляет данные для оплаты в Банк отправителя денег (сообщение admi.010), подписав его ЭЦП Платформы

> В сообщении передается:
>
> * в теге \<Document:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document:RptDtls:ReqRef> – сквозной идентификатор из тега \<Document::SplmtryData:PlcAndNm> с ключом END\_TO\_END\_ID исходного запроса (admi.009)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

7.1. Банк отправителя денег, получив ответ, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

8. Отправителю денег в приложении Банка отправителя денег отображается информация о платеже, он выбирает счет для оплаты и подтверждает проведение оплаты.

***Транзакция по проведению платежа***

9. Банк отправителя денег проводит проверку счета клиента на:&#x20;

* валидность статуса для его дебетования&#x20;
* отсутствие наложенного ПТП/ РПРО/ ареста и т.п.&#x20;
* достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Проверка счета не прошла успешно:**

1. Банк отправителя денег уведомляет клиента о невозможности проведения операции.&#x20;
2. Процесс завершается неуспешно

</details>

10. Банк отправителя денег блокирует сумму операции по счету клиента и формирует платежное поручение (pacs.008).
11. Банк отправителя денег направляет Платформе запрос на проведение оплаты (сообщение pacs.008), подписав его своим ЭЦП.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::PmtId:EndToEndId> – сгенерированный уникальный сквозной идентификатор&#x20;
> * в поле \<Document::PmtId:TxId> – сгенерированный уникальный идентификатор новой транзакции
> * указывается  IBAN для счета Отправителя денег
> * указывается  IBAN для счета Бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ, то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).&#x20;

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

11.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

12. Платформа обрабатывает  запрос на проведение оплаты (сообщение pacs.008), в том числе:&#x20;

* выполняет проверку лимитов;
* выполняет блокирование средств для проведения транзакции.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса на перевод денег pacs.008 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса на проведение оплаты в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
2. Процесс завершается неуспешно.

</details>

13. Платформа направляет в Банк бенефициара запрос на проведение оплаты (сообщение pacs.008), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::PmtId:EndToEndId> – сквозной идентификатор из тега \<EndToEndId> сообщения pacs.008 Банка отправителя денег
> * в поле \<Document::PmtId:TxId> – идентификатор транзакции из тега \<TxId> из сообщения pacs.008 Банка отправителя денег
> * указывается  IBAN для счета Отправителя денег из сообщения pacs.008 Банка отправителя денег
> * указывается  IBAN для счета Бенефициара из сообщения pacs.008 Банка отправителя денег

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
4. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
5. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
6. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

13.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

14. Банк бенефициара направляет информацию о том, что qr-код считан на POS-терминал
15. Банк бенефициара проверяет счет бенефициара на возможность зачисления денег
16. Банк бенефициара направляет статус обработки запроса проведения оплаты Платформе (сообщение pacs.002), подписав его своим ЭЦП.

> В сообщении передается:
>
> * \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<EndToEndId> исходного запроса (pacs.008)
> * \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<TxId> исходного запроса (из pacs.008)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса проведения оплаты (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса проведения оплаты в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

16.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара;&#x20;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

17. Платформа направляет статус обработки запроса проведения оплаты в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<EndToEndId> исходного запроса (pacs.008)
> * в теге \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<TxId> исходного запроса (из pacs.008)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

17.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

17.2. Платформа производит проверку чистой позиции. При достижении лимита чистой позиции Платформа направляет в Банк отправителя денег и в Банк бенефициара сообщение pacs.002 со статусом RJCT и кодом ошибки `PACS_002_NET_POSITION_LIMIT_REACHED` .

18. Платформа успешно завершает транзакцию (commit transaction).
19. Платформа направляет в качестве уведомления об успешной транзакции в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

19.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк бенефициара не производит (не производит повторное зачисление денег на счет бенефициара и т.д.), а лишь отправляет ответ  с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк бенефициара ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк бенефициара в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)) завершает транзакцию неуспешно (RJCT) по тайм-ауту, зачисление средств бенефициару не производится. Платформа производит откат транзакции, устанавливает статус транзакции - RJCT (неуспешно). Банк отправителя денег, получив статус транзакции RJCT (неуспешно), разблокирует средства Отправителя денег, списание средств не производится.

*Примечание: перед завершением транзакции Банк бенефициара может проверить статус транзакции на Платформе, отравив сообщение pacs.028 (см.* [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)*)*

* **Банк бенефициара отклонил pacs.002:**

1. Если банк-бенефициар отклонил pacs.002 со статусом ACSC, то Платформа должна отправить банку отправителю денег pacs.002 со статусом RJCT и кодом ошибки `PACS_002_SENDING_TO_CREDITOR_ERROR` .

</details>

19.2. Банк бенефициара производит зачисление денег на счет бенефициара и направляет информацию об этом на POS-терминал.

20. Платформа направляет в качестве уведомления об успешной транзакции в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

**Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

20.1. Банк отправителя денег, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк отправителя денег не производит (не производит повторное списание денег со счета отправителя денег и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк отправителя денег ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом(см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк отправителя денег  направляет запрос статуса транзакции Платформе (сообщение pacs.028, см. [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)), подписав его своим ЭЦП.
3. Платформа, успешно выполнив обработку запроса, направляет ответ с HTTP статусом 200.
4. Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции, подписав его ЭЦП Платформы.

</details>

20.2. Банк отправителя денег производит списание денег со счета отправителя денег и уведомляет его о завершении операции.<br>


# Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)

Данный сценарий описывает возврат денег по проведенной ранее оплате за товар/услугу.

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

Бенефициаром является клиент, которому возвращаются деньги (т.е. изначальный плательщик, отправитель денег из оригинальной транзакции).

Запрос возврата денег (pacs.004) формируется на основе исходного платежного поручения (pacs.008), по которому была ранее выполнена оплате за товар/услугу.

{% hint style="warning" %}
*Важно! Допускается возврат части суммы или полной суммы по проведенной ранее оплате за товар/услугу. Общая сумма возврата не должна превышать суммы исходной транзакции с учетом возвратов по ней (в том числе выполненных и находящихся в обработке).*
{% endhint %}

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)» отображает рисунок ниже.

<figure><img src="/files/o7moIY0t6Ae5T5k09OVB" alt=""><figcaption><p>Схема процесса «Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)</p></figcaption></figure>

{% hint style="info" %}
*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)», приведены в таблице ниже.

| Метод API (endpoint)                                                                                | Банк отправителя денег | Банк бенефициара |
| --------------------------------------------------------------------------------------------------- | ---------------------- | ---------------- |
| <p>Запрос данных по QR-коду</p><p> (POST /v1/transfers/iso20022/admi.009.001.02)</p>                | <p><br>+</p>           |                  |
| <p>Данные по QR-коду</p><p> (POST /v1/transfers/iso20022/admi.010.001.02)</p>                       |                        | +                |
| <p>Запрос возврата денег </p><p> (POST /v1/transfers/iso20022/pacs.004.001.12)</p>                  | <p><br></p>            | +                |
| <p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p> | +                      | +                |

## Взаимосвязь идентификаторов сообщений

Процесс «Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/FgTl6LEkXnpq6PSmxQh3" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

Описание успешного сценария процесса «Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)»:

1. Сотрудник мерчанта инициирует отображение QR-кода для возврата. На POS-терминале отображается QR-код для возврата.
2. Клиент (отправитель денег из оригинальной транзакции) в приложении Банка бенефициара сканирует QR-код для возврата в POS-терминале.
3. Банк бенефициара направляет Платформе запрос данных по QR-коду (сообщение admi.009), подписав его своим ЭЦП.

> В сообщении передается:
>
> * в теге \<Document:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document:SplmtryData:PlaceAndName> с ключом END\_TO\_END\_ID – сгенерированный уникальный идентификатор, который будет выступать в качестве сквозного идентификатора для всей цепочки сообщений в рамках данной операции оплаты

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Банк бенефициара завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку бенефициара ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

3.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей

4. Платформа направляет в Банк отправителя денег запрос данных по QR-коду (сообщение admi.009), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document:SplmtryData:PlaceAndName> с ключом END\_TO\_END\_ID –
>
> сквозной идентификатор из сообщения admi.009 Банка бенефициара

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Платформа направляет в Банк бенефициара сообщение admi.010 с ошибкой.
3. Банк бенефициара завершает процесс, получив сообщение с информацией об ошибке.&#x20;
4. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк отправителя денег направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа завершает процесс, получив сообщение с информацией об ошибке.
3. Платформа направляет в Банк бенефициара сообщение admi.010 с ошибкой.
4. Банк бенефициара завершает процесс, получив сообщение с информацией об ошибке.&#x20;
5. Процесс завершается неуспешно.

</details>

4.1. Банк отправителя денег, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей&#x20;
* выполняет поиск данных по идентификатору QR-кода

5. Банк отправителя денег направляет на POS-терминал информацию о платежах клиента, совершенных с данного терминала и доступных для возврата.
6. Сотрудник мерчанта инициирует возврат денег по проведенной ранее оплате за товар/услугу с указанием суммы возврата.

{% hint style="warning" %}
*Допускается возврат части суммы или полной суммы по проведенной ранее оплате за товар/услугу*
{% endhint %}

7. Банк отправителя денег направляет данные по QR-коду Платформе (сообщение admi.010), подписав его своим ЭЦП

> В сообщении передается:
>
> * в теге \<Document:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document:RptDtls:ReqRef> – сквозной идентификатор из тега \<Document::SplmtryData:PlcAndNm> с ключом END\_TO\_END\_ID исходного запроса (admi.009)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Банк отправителя денег завершает процесс с ошибкой.
3. Банк бенефициара завершает процесс по тайм-ауту (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).&#x20;
4. Процесс завершается неуспешно.

</details>

7.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

8. Платформа направляет данные по QR-коду  в Банк бенефициара (сообщение admi.010), подписав его ЭЦП Платформы

> В сообщении передается:
>
> * в теге \<Document:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document:RptDtls:ReqRef> – сквозной идентификатор из тега \<Document::SplmtryData:PlcAndNm> с ключом END\_TO\_END\_ID исходного запроса (admi.009)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

8.1. Банк бенефициара, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

9. Банк бенефициара обрабатывает полученные данные по QR-коду  (получает информацию, что QR-код для возврата)&#x20;

**Транзакция по проведению возврата денег**

10. Банк отправителя денег производит проверку, что сумма возврата не превышает суммы исходной транзакции с учетом возвратов по ней (выполненных и находящихся в обработке).

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Запрошена некорректная сумма возврата или отсутствуют данные о совершенной ранее оплате, по которой запрошен возврат:**

1. Банк отправителя денег отклоняет запрос возврата по проведенной ранее оплате за товар/услугу.
2. Процесс завершается неуспешно.

</details>

11. Банк отправителя денег проводит проверку счета клиента на:&#x20;

* валидность статуса для его дебетования&#x20;
* отсутствие наложенного ПТП/ РПРО/ ареста и т.п.&#x20;
* достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Проверка счета клиента не прошла успешно:**

1. Банк отправителя денег отклоняет запрос возврата по проведенной ранее оплате за товар/услугу.
2. Процесс завершается неуспешно.

</details>

12. Банк отправителя денег блокирует сумму операции по счету клиента и формирует запрос возврата денег (pacs.004) на основе исходного сообщения pacs.008, по которому была проведена оплата.
13. Банк отправителя денег направляет Платформе запрос на проведение возврата денег (сообщение pacs.004), подписав его своим ЭЦП.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::TxInf:RtrId> – сгенерированный уникальный идентификатор транзакции на возврат денег
> * в теге \<Document::TxInf:OrgnlInstrId > –сквозной идентификатор для всей цепочки сообщений в рамках данной операции возврата денег
> * в теге \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<EndToEndId> исходного сообщения pacs.008, по которому была проведена оплата
> * в теге \<Document::OrgnlTxId> –идентификатор транзакции из тега \<TxId> исходного сообщения pacs.008, по которому была проведена оплата
> * указывается  IBAN для счета Отправителя денег (бенефициара из оригинальной транзакции)
> * указывается  IBAN для счета Бенефициара (отправителя денег из оригинальной транзакции)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

{% hint style="info" %}
Ошибка INVALID\_TRANSACTION\_STATUS, полученная на данном шаге, означает, что на шаге 8 не удалось доставить сообщение admi.010  в Банк бенефициара
{% endhint %}

13.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

14. Платформа обрабатывает  запрос на проведение возврата денег (сообщение pacs.004), в том числе:&#x20;

* производит проверку, что сумма возврата не превышает суммы исходной транзакции с учетом возвратов по ней (выполненных и находящихся в обработке);
* выполняет проверку позиций участников и лимитов;
* выполняет блокирование средств для проведения транзакции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса возврата денег pacs.004 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса на проведение возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
2. Процесс завершается неуспешно.

</details>

15. Платформа направляет в Банк бенефициара запрос на проведение возврата денег (сообщение pacs.004), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::RtrId> – идентификатор транзакции из тега \<RtrId> сообщения pacs.004 Банка отправителя денег
> * в теге \<Document::OrgnlInstrId> – сквозной идентификатор из тега \<OrgnlInstrId> сообщения pacs.004 Банка отправителя денег
> * в теге \<Document::OrgnlEndToEndId> – сквозной идентификатор исходной операции оплаты из тега \<OrgnlEndToEndId> сообщения pacs.004 Банка отправителя денег
> * в теге \<Document::OrgnlTxId> – идентификатор транзакции исходной операции оплаты из тега \<OrgnlTxId> из сообщения pacs.004 Банка отправителя денег
> * указывается  IBAN для счета Отправителя денег (бенефициар из оригинальной транзакции) из сообщения pacs.004 Банка отправителя денег
> * указывается  IBAN для счета Бенефициара (отправителя денег из оригинальной транзакции) из сообщения pacs.004 Банка отправителя денег

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
5. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

15.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

16. Банк бенефициара проверяет счет бенефициара на возможность зачисления денег.
17. Банк бенефициара направляет статус обработки запроса проведения возврата денег Платформе (сообщение pacs.002), подписав его своим ЭЦП.

> В сообщении передается:
>
> * \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<OrgnlInstrId> исходного запроса (pacs.004)
> * \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<RtrId> исходного запроса (из pacs.004)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции статусом RJCT (отклонена).&#x20;
3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса проведения возврата денег (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса проведения возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

17.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара&#x20;
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

18. Платформа направляет статус обработки запроса проведения возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<OrgnlInstrId> исходного запроса (pacs.004)
> * в теге \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<RtrId> исходного запроса (из pacs.004)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

18.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

19. Платформа успешно завершает транзакцию (commit transaction).
20. Платформа направляет в качестве уведомления об успешной транзакции в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

20.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание:*&#x20;

*Если Платформа направляет в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк бенефициара не производит (не производит повторное зачисление денег на счет бенефициара и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**&#x20;

1. Банк бенефициара ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк бенефициара в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)) завершает транзакцию неуспешно (RJCT) по тайм-ауту, зачисление средств бенефициару не производится. Платформа производит откат транзакции, устанавливает статус транзакции - RJCT (неуспешно). Банк отправителя денег, получив статус транзакции RJCT (неуспешно), разблокирует средства Отправителя денег, списание средств не производится.

*Примечание: перед завершением транзакции Банк бенефициара может проверить статус транзакции на Платформе, отравив сообщение pacs.028 (см.* [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)*)*

</details>

20.2. Банк бенефициара производит зачисление денег на счет бенефициара (отправителя денег из оригинальной транзакции) и уведомляет об этом бенефициара.

21. Платформа направляет в качестве уведомления об успешной транзакции в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

21.1. Банк отправителя денег, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание:*&#x20;

*Если Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк отправителя денег не производит (не производит повторное списание денег со счета отправителя денег и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк отправителя денег ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк отправителя денег  направляет запрос статуса транзакции Платформе (сообщение pacs.028, см. [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)), подписав его своим ЭЦП.&#x20;
3. Платформа, успешно выполнив обработку запроса, направляет ответ с HTTP статусом 200.
4. Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции, подписав его ЭЦП Платформы.

</details>

21.2. Банк отправителя денег производит списание денег со счета Отправителя денег (бенефициара из оригинальной транзакции)и уведомляет его о завершении операции.


# Инициализация проведения платежей (по QR-коду) в рамках целевой модели

{% hint style="info" %}
Реализация процессов инициализации платежей и переводов денежных средств основана на методах API, описанных в электронном формате в <https://transfers-openapi.npck.kz/>
{% endhint %}

{% hint style="warning" %}
Во всех запросах должен быть указан **HTTP заголовок end-to-end-id**, в котором должен указываться сквозной идентификатор для всей цепочки сообщений, использующийся в рамках данной операции *(должен совпадать с соответствующим значением, передаваемым в теле сообщения)*
{% endhint %}

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


# Инициализация оплаты по QR-коду (C2B2\_V2)

Данный сценарий описывает инициализацию проведения оплаты за товар/услугу посредством сканирования QR-кода в POS-терминале или посредством статического QR-кода.

В рамках данного сценария клиенту предоставляется возможность QR-оплаты из приложения одного банка (банка отправителя денег) через POS-терминал или статический QR-код другого банка (банка бенефициара).

{% hint style="warning" %}
*Важно! Если отсканированный QR-код выпущен самим Банком отправителя денег, то оплата производится внутри Банка отправителя денег без взаимодействия с Платформой. Т.е. если счет бенефициара, указанный в QR-коде, также обслуживается в данном банке, то производится внутрибанковская операция.*
{% endhint %}

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Инициализация оплаты по QR-коду (C2B2\_V2)» отображает рисунок ниже.

<figure><img src="/files/5PmwbxLdrcKLbhdRFYWt" alt=""><figcaption><p>Схема процесса «Инициализация оплаты по QR-коду (C2B2_V2)»</p></figcaption></figure>

{% file src="/files/ZfTraUQ9krLdX7uoN44G" %}
Схематичное отображение процесса
{% endfile %}

*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Инициализация оплаты по QR-коду (C2B2\_V2)», приведены в таблице ниже.

<table><thead><tr><th width="388">Метод API (endpoint)</th><th width="170">Банк отправителя денег</th><th>Банк бенефициара</th></tr></thead><tbody><tr><td><p>Запрос данных по QR-коду для оплаты</p><p>(POST /v1/transfers/iso20022/admi.009.001.02)</p></td><td><br></td><td>+</td></tr><tr><td><p>Данные для оплаты</p><p>(POST /v1/transfers/iso20022/admi.010.001.02)</p></td><td>+</td><td>+</td></tr><tr><td><p>Запрос на перевод денег </p><p> (POST /v1/transfers/iso20022/pacs.008.001.11)</p></td><td></td><td>+</td></tr><tr><td><p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p></td><td>+</td><td>+</td></tr></tbody></table>

## Взаимосвязь идентификаторов сообщений

Процесс «Инициализация оплаты по QR-коду (C2B2\_V2)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/V7lxDStfkLh8xuG5WOSG" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

Описание успешного сценария процесса «Инициализация оплаты по QR-коду (C2B2\_V2)»:

***Генерация и считывание QR-кода для оплаты***

1. POS-терминал направляет данные о платеже в Банк бенефициара

> Для статического QR-кода данный шаг не применяется

2. Банк бенефициара формирует данные для QR-кода для оплаты
3. Отправитель денег в приложении Банка отправителя денег сканирует QR-код в POS-терминале или статический QR-код

{% hint style="warning" %}
*Важно! Если отсканированный QR-код выпущен самим Банком отправителя денег, то оплата производится внутри Банка отправителя денег без взаимодействия с Платформой. Т.е. если счет бенефициара, указанный в QR-коде, также обслуживается в данном банке, то производится внутрибанковская операция.*
{% endhint %}

4. Банк отправителя денег направляет Платформе запрос данных для оплаты (сообщение admi.009), на основе данных из QR-кода, подписав его своим ЭЦП

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Банк отправителя денег завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).&#x20;
2. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

4.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

5. Платформа направляет в Банк бенефициара запрос данных для оплаты (сообщение admi.009), подписав его ЭЦП Платформы

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа направляет в Банк отправителя сообщение admi.010 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
5. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа завершает процесс, получив сообщение с информацией об ошибке.
3. Платформа направляет в Банк отправителя сообщение admi.010 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.
5. Процесс завершается неуспешно.

</details>

5.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей
* выполняет поиск данных по идентификатору QR-кода

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

6. Банк бенефициара направляет данные для оплаты Платформе (сообщение admi.010), подписав его своим ЭЦП

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку бенефициара ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Банк бенефициара завершается процесс с ошибкой.
3. Банк отправителя денег завершает процесс по тайм-ауту (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).&#x20;
4. Процесс завершается неуспешно.

</details>

6.1. Платформа, получив ответ, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

7. Платформа направляет данные для оплаты в Банк отправителя денег (сообщение admi.010), подписав его ЭЦП Платформы

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

7.1. Банк отправителя денег, получив ответ, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

8. Отправителю денег в приложении Банка отправителя денег отображается информация о платеже, он выбирает счет для оплаты и подтверждает проведение оплаты.

<details>

<summary><strong>Возможные неуспешные сценарии</strong></summary>

1. *Клиент отменил операцию или операция отменена по иной причине на стороне Банка отправителя денег*:

* Банк отправителя денег направляет Платформе уведомление об отмене операции (сообщение admi.010), подписав его своим ЭЦП.

1.1. Платформа, получив запрос, проводит его валидацию, в том числе

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

***

<mark style="color:$info;">**• Возможные неуспешные сценарии**</mark>

<mark style="color:$info;">**• Платформа не отвечает**</mark>

1. <mark style="color:$info;">Если Платформа не направляет ответ, то Банк отправителя денег должен считать, что запрос не доставлен.</mark>
2. <mark style="color:$info;">Банк отправителя денег выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см.</mark>

   &#x20;[<mark style="color:$info;">Тайм-ау ты и логика повторных запросов</mark>](https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/taim-auty-i-logika-povtornykh-zaprosov)<mark style="color:$info;">).</mark>

<mark style="color:$info;">**•    Валидация сообщения не прошла успешно:**</mark>

1. <mark style="color:$info;">Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.</mark>
2. <mark style="color:$info;">Банк отправителя денег завершается процесс с ошибкой.</mark>
3. <mark style="color:$info;">Банк бенефициара завершает процесс по тайм-ауту (см.</mark> [ <mark style="color:$info;">Тайм-ау ты и логика повторных запросов</mark>](https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/taim-auty-i-logika-povtornykh-zaprosov)<mark style="color:$info;">).</mark>
4. <mark style="color:$info;">Процесс завершается неуспешно</mark>

***

1.2. Платформа направляет в Банк бенефициара уведомление об отмене операции (сообщение admi.010), подписав его ЭЦП Платформы.&#x20;

***

<mark style="color:$info;">**• Возможные неуспешные сценарии**</mark>

<mark style="color:$info;">**• Банк бенефициара не отвечает**</mark>

1. <mark style="color:$info;">Если Банк бенефициара не направляет ответ, то Платформа должна считать, что запрос не доставлен.</mark>
2. <mark style="color:$info;">Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см.</mark> [<mark style="color:$info;">Тайм-ауты и логика повторных запросов</mark>](https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/taim-auty-i-logika-povtornykh-zaprosov)<mark style="color:$info;">).</mark>

<mark style="color:$info;">**•    Валидация сообщения не прошла успешно:**</mark>

1. <mark style="color:$info;">Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.</mark>
2. <mark style="color:$info;">Платформа завершает процесс, получив сообщение с информацией об ошибке.</mark>
3. <mark style="color:$info;">Процесс завершается неуспешно.</mark>

***

1.3. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

1.4. На POS-терминале выводится информация о том, что операция отменена клиентом, и процесс завершается.

</details>

***

***Транзакция по проведению платежа***

9. Банк отправителя денег проводит проверку счета клиента на:&#x20;

* валидность статуса для его дебетования&#x20;
* отсутствие наложенного ПТП/ РПРО/ ареста и т.п.&#x20;
* достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Проверка счета не прошла успешно:**

1. Банк отправителя денег уведомляет клиента о невозможности проведения операции.&#x20;
2. Процесс завершается неуспешно

</details>

10. Банк отправителя денег проверяет возможность транзакции по счету клиента и формирует платежное поручение (pacs.008), предварительно блокирует сумму операции по счету клиента.
11. Банк отправителя денег направляет Платформе запрос на проведение оплаты (сообщение pacs.008), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ, то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).&#x20;

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

11.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

12. Платформа обрабатывает  запрос на проведение оплаты (сообщение pacs.008), в том числе:&#x20;

* выполняет проверку лимитов;
* выполняет блокирование средств для проведения транзакции;
* осуществляет проверку чистой позиции - при достижении лимита чистой позиции направляет в Банк отправителя и Банк бенефициара сообщение pacs.002 со статусом RJCT и кодом ошибки `PACS_002_NET_POSITION_LIMIT_REACHED.`

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса на перевод денег pacs.008 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса на проведение оплаты в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
2. Процесс завершается неуспешно.

</details>

13. Платформа направляет в Банк бенефициара запрос на проведение оплаты (сообщение pacs.008), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
4. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
5. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
6. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

13.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

14. Банк бенефициара проверяет счет бенефициара на возможность зачисления денег.
15. Банк бенефициара направляет статус обработки запроса проведения оплаты Платформе (сообщение pacs.002), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса проведения оплаты (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса проведения оплаты в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

15.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара;&#x20;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

16. Платформа направляет статус обработки запроса проведения оплаты в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

16.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

17. Банк отправителя денег направляет в качестве уведомления об успешной транзакции в Платформу сообщение pacs.002 со статусом транзакции ACSC, подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. При отсутствии ответа от Платформы, Банк отправителя денег осуществляет повторную отправку запроса с интервалом 3 секунды до тех пор, пока не будет получен ответ HTTP 200.

</details>

17.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Не получен pacs.002 ACSC от Банка отправителя денег:**

1. Если Платформа в течение 30 секунд не получает сообщение pacs.002 (ACSC) от Банка отправителя денег, то транзакция завершается со статусом RJCT и при получении pacs.002 ACSC от Банка отправителя денег будет возвращен HTTP 408.

</details>

18. Платформа направляет в качестве уведомления сообщение pacs.002 со статусом ACSC в Банк бенефициара, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Если Банк бенефициара не направляет ответ, то Платформа считает запрос не доставленным, при этом транзакция не отклоняется и остается в состоянии ожидания сообщения pacs.002 с финальным статусом от Банка бенефициара.
3. Банк бенефициара не получив ответ от платформы в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), завершает транзакцию с ошибкой и направляет в Платформу pacs.002 со статусом RJCT с интервалом 3 секунды до тех пор, пока не будет получен ответ HTTP 200.

</details>

18.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

19. Банк бенефициара производит зачисление денег на счет бенефициара и направляет информацию об этом на POS-терминал.
20. Банк бенефициара направляет в качестве уведомления об успешной транзакции в Платформу сообщение pacs.002 со статусом транзакции ACSC, подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. При отсутствии ответа от Платформы, Банк отправителя денег осуществляет повторную отправку запроса с интервалом 3 секунды до тех пор, пока не будет получен ответ HTTP 200.

</details>

20.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

21. Платформа успешно завершает транзакцию (commit transaction).
22. Платформа направляет уведомление pacs.002 со статусом ACSC до Банка отправителя денег с информацией о дате обработки транзакции (Processing Date) и информацией о размерах комиссий, подписав его ЭЦП Платформы.
23. Банк отправителя завершает транзакцию и уведомляет клиента о завершении операции.

<details>

<summary>Возможные неуспешные сценарии</summary>

1. Банк отправителя денег не получил финальное уведомление от платформы pacs.002 со статусом ACSC с информацией о дате обработки транзакции (Processing Date) и информацией о размерах комиссий.
2. Банк отправителя денег отправляет запрос на получение статуса обработки транзакции (pacs.028) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

{% hint style="info" %}
*Рекомендуется: Банку отправителя денег начинать направлять запрос статуса обработки транзакции (pacs.028) через 5 секунд после успешной отправки pacs.002.*
{% endhint %}


# Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR\_V2)

Данный сценарий описывает возврат денег по проведенной ранее оплате за товар/услугу.

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

Бенефициаром является клиент, которому возвращаются деньги (т.е. изначальный плательщик, отправитель денег из оригинальной транзакции).

Запрос возврата денег (pacs.004) формируется на основе исходного платежного поручения (pacs.008), по которому была ранее выполнена оплате за товар/услугу.

{% hint style="warning" %}
*Важно! Допускается возврат части суммы или полной суммы по проведенной ранее оплате за товар/услугу. Общая сумма возврата не должна превышать суммы исходной транзакции с учетом возвратов по ней (в том числе выполненных и находящихся в обработке).*
{% endhint %}

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR\_V2)» отображает рисунок ниже.

<figure><img src="/files/WoCZg9OgBnWaeUNy0da3" alt=""><figcaption><p>Схема процесса «Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR_V2)</p></figcaption></figure>

{% file src="/files/kf32SyPm03nn1mc2ZrSo" %}
Схематичное отображение процесса
{% endfile %}

{% hint style="info" %}
*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR\_V2)», приведены в таблице ниже.

| Метод API (endpoint)                                                                                | Банк отправителя денег | Банк бенефициара |
| --------------------------------------------------------------------------------------------------- | ---------------------- | ---------------- |
| <p>Запрос данных по QR-коду</p><p> (POST /v1/transfers/iso20022/admi.009.001.02)</p>                | <p><br>+</p>           |                  |
| <p>Данные по QR-коду</p><p> (POST /v1/transfers/iso20022/admi.010.001.02)</p>                       |                        | +                |
| <p>Запрос возврата денег </p><p> (POST /v1/transfers/iso20022/pacs.004.001.12)</p>                  | <p><br></p>            | +                |
| <p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p> | +                      | +                |

## Взаимосвязь идентификаторов сообщений

Процесс «Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR\_V2)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/FgTl6LEkXnpq6PSmxQh3" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

Описание успешного сценария процесса «Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR\_V2)»:

1. Сотрудник мерчанта инициирует отображение QR-кода для возврата. На POS-терминале отображается QR-код для возврата.
2. Клиент (отправитель денег из оригинальной транзакции) в приложении Банка бенефициара сканирует QR-код для возврата в POS-терминале.
3. Банк бенефициара направляет Платформе запрос данных по QR-коду (сообщение admi.009), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Банк бенефициара завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку бенефициара ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

3.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей

4. Платформа направляет в Банк отправителя денег запрос данных по QR-коду (сообщение admi.009), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Платформа направляет в Банк бенефициара сообщение admi.010 с ошибкой.
3. Банк бенефициара завершает процесс, получив сообщение с информацией об ошибке.&#x20;
4. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк отправителя денег направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа завершает процесс, получив сообщение с информацией об ошибке.
3. Платформа направляет в Банк бенефициара сообщение admi.010 с ошибкой.
4. Банк бенефициара завершает процесс, получив сообщение с информацией об ошибке.&#x20;
5. Процесс завершается неуспешно.

</details>

4.1. Банк отправителя денег, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей&#x20;
* выполняет поиск данных по идентификатору QR-кода

5. Банк отправителя денег направляет на POS-терминал информацию о платежах клиента, совершенных с данного терминала и доступных для возврата.
6. Сотрудник мерчанта инициирует возврат денег по проведенной ранее оплате за товар/услугу с указанием суммы возврата.

{% hint style="warning" %}
*Допускается возврат части суммы или полной суммы по проведенной ранее оплате за товар/услугу*
{% endhint %}

7. Банк отправителя денег направляет данные по QR-коду Платформе (сообщение admi.010), подписав его своим ЭЦП

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Банк отправителя денег завершает процесс с ошибкой.
3. Банк бенефициара завершает процесс по тайм-ауту (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).&#x20;
4. Процесс завершается неуспешно.

</details>

7.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

8. Платформа направляет данные по QR-коду  в Банк бенефициара (сообщение admi.010), подписав его ЭЦП Платформы

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

8.1. Банк бенефициара, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

9. Банк бенефициара обрабатывает полученные данные по QR-коду  (получает информацию, что QR-код для возврата)&#x20;

**Транзакция по проведению возврата денег**

10. Банк отправителя денег производит проверку, что сумма возврата не превышает суммы исходной транзакции с учетом возвратов по ней (выполненных и находящихся в обработке).

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Запрошена некорректная сумма возврата или отсутствуют данные о совершенной ранее оплате, по которой запрошен возврат:**

1. Банк отправителя денег отклоняет запрос возврата по проведенной ранее оплате за товар/услугу.
2. Процесс завершается неуспешно.

</details>

11. Банк отправителя денег проводит проверку счета клиента на:&#x20;

* валидность статуса для его дебетования&#x20;
* отсутствие наложенного ПТП/ РПРО/ ареста и т.п.&#x20;
* достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Проверка счета клиента не прошла успешно:**

1. Банк отправителя денег отклоняет запрос возврата по проведенной ранее оплате за товар/услугу.
2. Процесс завершается неуспешно.

</details>

12. Банк отправителя денег блокирует сумму операции по счету клиента и формирует запрос возврата денег (pacs.004) на основе исходного сообщения pacs.008, по которому была проведена оплата.
13. Банк отправителя денег направляет Платформе запрос на проведение возврата денег (сообщение pacs.004), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

{% hint style="info" %}
Ошибка INVALID\_TRANSACTION\_STATUS, полученная на данном шаге, означает, что на шаге 8 не удалось доставить сообщение admi.010  в Банк бенефициара
{% endhint %}

13.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

14. Платформа обрабатывает  запрос на проведение возврата денег (сообщение pacs.004), в том числе:&#x20;

* производит проверку, что сумма возврата не превышает суммы исходной транзакции с учетом возвратов по ней (выполненных и находящихся в обработке);
* выполняет проверку позиций участников и лимитов;
* выполняет блокирование средств для проведения транзакции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса возврата денег pacs.004 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса на проведение возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
2. Процесс завершается неуспешно.

</details>

15. Платформа направляет в Банк бенефициара запрос на проведение возврата денег (сообщение pacs.004), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
5. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

15.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

16. Банк бенефициара проверяет счет бенефициара на возможность зачисления денег.
17. Банк бенефициара направляет статус обработки запроса проведения возврата денег Платформе (сообщение pacs.002), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции статусом RJCT (отклонена).&#x20;
3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса проведения возврата денег (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса проведения возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

17.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара&#x20;
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

18. Платформа направляет статус обработки запроса проведения возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Если Банк отправителя денег не направляет ответ, то Платформа считает запрос не доставленным, при этом транзакция не отклоняется и остается в состоянии ожидания сообщения pacs.002 с финальным статусом от Банка отправителя.
3. &#x20;Банк отправителя денег не получив ответ от платформы в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), завершает транзакцию с ошибкой и направляет в Платформу pacs.002 со статусом RJCT с интервалом 3 секунды до тех пор пока не будет получен ответ HTTP 200.

</details>

18.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

19. Банк отправителя денег производит списание денег со счета Отправителя денег (бенефициара из оригинальной транзакции) и уведомляет его о завершении операции.
20. Банк отправителя денег направляет в качестве уведомления об успешной транзакции в Платформу сообщение pacs.002 со статусом транзакции ACSC, подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. При отсутствии ответа от Платформы, Банк отправителя денег осуществляет повторную отправку запроса с интервалом 3 секунды до тех пор, пока не будет получен ответ HTTP 200.

</details>

20.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

21. Платформа успешно завершает транзакцию (commit transaction).
22. Платформа направляет уведомление pacs.002 со статусом ACSC до Банка бенефициара с информацией о дате обработки транзакции (Processing Date) и информацией о размерах комиссий, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Банк бенефициара не получили финальное уведомление от платформы pacs.002 со статусом ACSC с информацией о дате обработки транзакции (Processing Date) и информацией о размерах комиссий.
2. Банк бенефициара отправляет запрос на получение статуса обработки транзакции (pacs.028) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

22.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

22.2. Банк бенефициара производит зачисление денег на счет Бенефициара и уведомляет его о завершении операции.


# Возврат денег по инициативе продавца без участия покупателя (C2BRM\_V2)

Данный сценарий описывает возврат денег по ранее проведенной оплате за товар или услугу, инициируемый поставщиком/продавцом без формирования соответствующего запроса со стороны покупателя.

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

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

Покупатель не участвует в инициировании операции возврата и не формирует отдельный запрос на возврат денег.

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

{% hint style="warning" %}
*Важно! Допускается возврат части суммы или полной суммы по проведенной ранее оплате за товар/услугу. Общая сумма возврата не должна превышать суммы исходной транзакции с учетом возвратов по ней (в том числе выполненных и находящихся в обработке).*
{% endhint %}

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Возврат денег по проведенной ранее оплате за товар/услугу по инициативе продавца без участия покупателя (C2BRM\_V2)» отображает рисунок ниже.

<figure><img src="/files/tZHQnaZ3mMc3gIUdWAly" alt=""><figcaption><p>Схема процесса «Возврат денег по проведенной ранее оплате за товар/услугу по инициативе продавца без участия покупателя (C2BRM_V2)»</p></figcaption></figure>

{% file src="/files/dHVdBY43c9V1J0KxVM5B" %}

Реализация процесса «Возврат денег по ранее проведенной оплате за товар/услугу по инициативе продавца без участия покупателя» (C2BRM\_V2) осуществляется на основе процесса «Возврат денег по ранее проведенной оплате за товар/услугу» (C2BR\_V2).

Основным отличием процесса C2BRM\_V2 является отсутствие информационного обмена с покупателем, включая обмен сообщениями admi.009 и admi.010, поскольку операция возврата инициируется продавцом самостоятельно.

Основным отличием процесса C2BRM\_V2 является отсутствие информационного обмена с покупателем, включая обмен сообщениями admi.009 и admi.010, поскольку операция возврата инициируется продавцом самостоятельно.

Для выполнения возврата используются сообщения pacs.004 и pacs.002, а также аналогичная логика их формирования и обработки как в процессе C2BR\_V2. При этом в сообщениях указывается тип операции C2BRM\_V2, позволяющий идентифицировать возврат, инициированный продавцом без участия покупателя.

{% hint style="info" %}
*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Возврат денег по проведенной ранее оплате за товар/услугу по инициативе продавца без участия покупателя (C2BRM\_V2)», приведены в таблице ниже.

<table><thead><tr><th width="416.5">Метод API (endpoint)</th><th width="187.75">Банк отправителя денег</th><th>Банк бенефициара</th></tr></thead><tbody><tr><td><p>Запрос возврата денег </p><p> (POST /v1/transfers/iso20022/pacs.004.001.12)</p></td><td><br></td><td>+</td></tr><tr><td><p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p></td><td>+</td><td>+</td></tr></tbody></table>

## Взаимосвязь идентификаторов сообщений

Процесс «Возврат денег по проведенной ранее оплате за товар/услугу по инициативе продавца без участия покупателя (C2BRM\_V2)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/dijoFA15XNyAWctty48A" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

Описание успешного сценария процесса «Возврат денег по проведенной ранее оплате за товар/услугу по инициативе продавца без участия покупателя (C2BRM\_V2):

1. Сотрудник мерчанта инициирует осуществление возврата денег по проведенной ранее оплате за товар/услугу.

**Транзакция по проведению возврата денег**

2. Банк отправителя денег производит проверку, что сумма возврата не превышает суммы исходной транзакции с учетом возвратов по ней (выполненных и находящихся в обработке).

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Запрошена некорректная сумма возврата или отсутствуют данные о совершенной ранее оплате, по которой запрошен возврат:**

1. Банк отправителя денег отклоняет запрос возврата по проведенной ранее оплате за товар/услугу.
2. Процесс завершается неуспешно.

</details>

3. Банк отправителя денег проводит проверку счета клиента на:&#x20;

* валидность статуса для его дебетования&#x20;
* отсутствие наложенного ПТП/ РПРО/ ареста и т.п.&#x20;
* достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Проверка счета клиента не прошла успешно:**

1. Банк отправителя денег отклоняет запрос возврата по проведенной ранее оплате за товар/услугу.
2. Процесс завершается неуспешно.

</details>

4. Банк отправителя денег блокирует сумму операции по счету клиента и формирует запрос возврата денег (pacs.004) на основе исходного сообщения pacs.008, по которому была проведена оплата.
5. Банк отправителя денег направляет Платформе запрос на проведение возврата денег (сообщение pacs.004), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

6. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

7. Платформа обрабатывает  запрос на проведение возврата денег (сообщение pacs.004), в том числе:&#x20;

* производит проверку, что сумма возврата не превышает суммы исходной транзакции с учетом возвратов по ней (выполненных и находящихся в обработке);
* выполняет проверку позиций участников и лимитов;
* выполняет блокирование средств для проведения транзакции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса возврата денег pacs.004 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса на проведение возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
2. Процесс завершается неуспешно.

</details>

8. Платформа направляет в Банк бенефициара запрос на проведение возврата денег (сообщение pacs.004), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
5. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

9. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

10. Банк бенефициара проверяет счет бенефициара на возможность зачисления денег.
11. Банк бенефициара направляет статус обработки запроса проведения возврата денег Платформе (сообщение pacs.002), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции статусом RJCT (отклонена).&#x20;
3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса проведения возврата денег (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса проведения возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

12. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара&#x20;
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

13. Платформа направляет статус обработки запроса проведения возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Если Банк отправителя денег не направляет ответ, то Платформа считает запрос не доставленным, при этом транзакция не отклоняется и остается в состоянии ожидания сообщения pacs.002 с финальным статусом от Банка отправителя.
3. &#x20;Банк отправителя денег не получив ответ от платформы в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), завершает транзакцию с ошибкой и направляет в Платформу pacs.002 со статусом RJCT с интервалом 3 секунды до тех пор пока не будет получен ответ HTTP 200.

</details>

14. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

15. Банк отправителя денег производит списание денег со счета Отправителя денег (бенефициара из оригинальной транзакции) и уведомляет его о завершении операции.
16. Банк отправителя денег направляет в качестве уведомления об успешной транзакции в Платформу сообщение pacs.002 со статусом транзакции ACSC, подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. При отсутствии ответа от Платформы, Банк отправителя денег осуществляет повторную отправку запроса с интервалом 3 секунды до тех пор, пока не будет получен ответ HTTP 200.

</details>

17. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

18. Платформа успешно завершает транзакцию (commit transaction).
19. Платформа направляет уведомление pacs.002 со статусом ACSC до Банка бенефициара с информацией о дате обработки транзакции (Processing Date) и информацией о размерах комиссий, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Банк бенефициара не получили финальное уведомление от платформы pacs.002 со статусом ACSC с информацией о дате обработки транзакции (Processing Date) и информацией о размерах комиссий.
2. Банк бенефициара отправляет запрос на получение статуса обработки транзакции (pacs.028) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

20. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

21. Банк бенефициара производит зачисление денег на счет Бенефициара и уведомляет его о завершении операции.


# Инициализация оплаты в рамках электронной коммерции

{% hint style="info" %}
Реализация процессов возвратов основана на методах API, описанных в электронном формате в <https://transfers-openapi.npck.kz/>
{% endhint %}

{% hint style="warning" %}
Во всех запросах должен быть указан **HTTP заголовок end-to-end-id**, в котором должен указываться сквозной идентификатор для всей цепочки сообщений, использующийся в рамках данной операции *(должен совпадать с соответствующим значением, передаваемым в теле сообщения)*
{% endhint %}

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


# Инициализация оплаты в рамках электронной коммерции

Данный сценарий описывает инициализацию проведения оплаты за товар/услугу посредством платежной ссылки в рамках электронной коммерции.

{% hint style="warning" %}
АО «НПК» по запросу Банка готово предоставить презентацию клиентского пути в рабочем порядке.
{% endhint %}

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Инициализация оплаты в рамках электронной коммерции (C2B2E)» отображает рисунок ниже.

<figure><img src="/files/0Y46EMJi5PSIDLgA7GI0" alt=""><figcaption><p>Схема процесса «Инициализация оплаты в рамках электронной коммерции (C2B2E)»</p></figcaption></figure>

{% file src="/files/UwESRZ1nA2JEtUqBB9AT" %}
Схематичное отображение процесса
{% endfile %}

{% hint style="info" %}
*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Инициализация оплаты в рамках электронной коммерции (C2B2E)», приведены в таблице ниже.

<table><thead><tr><th width="388">Метод API (endpoint)</th><th width="170">Банк отправителя денег</th><th>Банк бенефициара</th></tr></thead><tbody><tr><td><p>Запрос данных для оплаты</p><p>(POST /v1/transfers/iso20022/admi.009.001.02)</p></td><td><br></td><td>+</td></tr><tr><td><p>Данные для оплаты</p><p>(POST /v1/transfers/iso20022/admi.010.001.02)</p></td><td>+</td><td>+</td></tr><tr><td><p>Запрос на перевод денег </p><p> (POST /v1/transfers/iso20022/pacs.008.001.11)</p></td><td></td><td>+</td></tr><tr><td><p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p></td><td>+</td><td>+</td></tr></tbody></table>

## Взаимосвязь идентификаторов сообщений

Процесс «Инициализация оплаты в рамках электронной коммерции (C2B2E)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/GU95BHVbDfalBWwxoynZ" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

Описание успешного сценария процесса «Инициализация оплаты в рамках электронной коммерции (C2B2E)»:

Поддерживаются два способа инициирования платежа:

1. **Выведение QR-кода на десктопе.** Данный сценарий осуществляется в рамках процесса [«Инициализация проведения платежей (по QR-коду) в рамках целевой модели (C2B2\_V2)».](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/inicializaciya-provedeniya-platezhei-po-qr-kodu-v-ramkakh-celevoi-modeli)
2. **Мобильная версия сайта/мобильное приложение торгово-сервисного предприятия** (далее — **Mobile App**). Данный сценарий осуществляется по типу транзакции **C2B2E**.

{% hint style="danger" %}
Для сценария **C2B2E** в сообщениях [**admi.009**](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/opisanie-struktury-zaprosov/formaty-soobshenii/soobshenie-admi.009) и [**admi.010**](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/opisanie-struktury-zaprosov/formaty-soobshenii/soobshenie-admi.010) передаются дополнительные параметры: **информация о владельце счета** (от эмитента к эквайеру) и **информация о мерчанте** (от эквайера к эмитенту).
{% endhint %}

***При заказе через Mobile App:***

1. Отправитель денег (клиент) добавляет товар в корзину и подтверждает заказ в Mobile App.
2. При подтверждении заказа в Mobile App отображается страница выбора способа оплаты.
3. Отправитель денег (клиент) выбирает способ оплаты «Оплата посредством сервиса межбанковских QR-платежей Межбанковской системы мобильных платежей (МСМП)».
4. Выполняется переход на страницу банка эквайера по ссылке *https\://{Страница\_эквайера}.kz/* с вариантами выбора банковского приложения для осуществления оплаты. Каждый вариант содержит ссылку deep-link на мобильные приложения указанных в списке банков *(например, https\://{Домен эмитента}.kz/*

   *«{bank\_base\_domain}/{QR\_ID}»).*
5. Отправитель денег (клиент) выбирает Банк для оплаты, из списка доступных на странице выбора банков в Mobile App.
6. После выбора банка для выполнения транзакции выполняется открытие мобильного приложения по deep-link с заполненными полями для оплаты.
7. Отправитель денег (клиент) инициирует оплату в МП Банка отправителя.
8. Банк отправителя денег направляет Платформе запрос данных для оплаты (сообщение admi.009) по ссылке, подписав его своим ЭЦП

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Банк отправителя денег завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).&#x20;
2. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

8.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

9. Платформа направляет в Банк бенефициара запрос данных для оплаты (сообщение admi.009), подписав его ЭЦП Платформы

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа направляет в Банк отправителя сообщение admi.010 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
5. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа завершает процесс, получив сообщение с информацией об ошибке.
3. Платформа направляет в Банк отправителя сообщение admi.010 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
5. Процесс завершается неуспешно.

</details>

9.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей
* выполняет поиск данных по идентификатору QR-кода

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

10. Банк бенефициара направляет данные для оплаты Платформе (сообщение admi.010), подписав его своим ЭЦП

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку бенефициара ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Банк бенефициара завершается процесс с ошибкой.
3. Банк отправителя денег завершает процесс по тайм-ауту (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
4. Процесс завершается неуспешно.

</details>

10.1. Платформа, получив ответ, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

11. Платформа направляет данные для оплаты в Банк отправителя денег (сообщение admi.010), подписав его ЭЦП Платформы

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

11.1. Банк отправителя денег, получив ответ, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

12. Отправитель денег на странице оплаты приложения Банка отправителя проверяет корректность данных по заказу (наименование поставщика товара, работы или услуги, итоговую сумму к оплате, полученные из сообщения admi.010) и подтверждает проведение оплаты нажатием кнопки «Оплатить».

<details>

<summary><strong>Возможные неуспешные сценарии</strong></summary>

1. *Клиент отменил операцию или операция отменена по иной причине на стороне Банка отправителя денег*:

* Банк отправителя денег направляет Платформе уведомление об отмене операции (сообщение admi.010), подписав его своим ЭЦП.

1.1. Платформа, получив запрос, проводит его валидацию, в том числе

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

***

<mark style="color:$info;">**• Возможные неуспешные сценарии**</mark>

<mark style="color:$info;">**• Платформа не отвечает**</mark>

1. <mark style="color:$info;">Если Платформа не направляет ответ, то Банк отправителя денег должен считать, что запрос не доставлен.</mark>
2. <mark style="color:$info;">Банк отправителя денег выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см.</mark>

   &#x20;[<mark style="color:$info;">Тайм-ау ты и логика повторных запросов</mark>](https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/taim-auty-i-logika-povtornykh-zaprosov)<mark style="color:$info;">).</mark>

<mark style="color:$info;">**•    Валидация сообщения не прошла успешно:**</mark>

1. <mark style="color:$info;">Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.</mark>
2. <mark style="color:$info;">Банк отправителя денег завершается процесс с ошибкой.</mark>
3. <mark style="color:$info;">Банк бенефициара завершает процесс по тайм-ауту (см.</mark> [ <mark style="color:$info;">Тайм-ау ты и логика повторных запросов</mark>](https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/taim-auty-i-logika-povtornykh-zaprosov)<mark style="color:$info;">).</mark>
4. <mark style="color:$info;">Процесс завершается неуспешно</mark>

***

1.2. Платформа направляет в Банк бенефициара уведомление об отмене операции (сообщение admi.010), подписав его ЭЦП Платформы.&#x20;

***

<mark style="color:$info;">**• Возможные неуспешные сценарии**</mark>

<mark style="color:$info;">**• Банк бенефициара не отвечает**</mark>

1. <mark style="color:$info;">Если Банк бенефициара не направляет ответ, то Платформа должна считать, что запрос не доставлен.</mark>
2. <mark style="color:$info;">Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см.</mark> [<mark style="color:$info;">Тайм-ауты и логика повторных запросов</mark>](https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/taim-auty-i-logika-povtornykh-zaprosov)<mark style="color:$info;">).</mark>

<mark style="color:$info;">**•    Валидация сообщения не прошла успешно:**</mark>

1. <mark style="color:$info;">Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.</mark>
2. <mark style="color:$info;">Платформа завершает процесс, получив сообщение с информацией об ошибке.</mark>
3. <mark style="color:$info;">Процесс завершается неуспешно.</mark>

***

1.3. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

1.4. В МП ЮЛ/ЛК ЮЛ выводится информация о том, что операция отменена клиентом, и процесс завершается.

</details>

12. Банк отправителя денег проводит проверку счета клиента на:&#x20;

* валидность статуса для его дебетования&#x20;
* отсутствие наложенного ПТП/ РПРО/ ареста и т.п.&#x20;
* достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Проверка счета не прошла успешно:**

1. Банк отправителя денег уведомляет клиента о невозможности проведения операции.&#x20;
2. Процесс завершается неуспешно

</details>

14. Банк отправителя денег проверяет возможность транзакции по счету клиента и формирует платежное поручение (pacs.008), предварительно блокирует сумму операции по счету клиента.
15. Банк отправителя денег направляет Платформе запрос на проведение оплаты (сообщение pacs.008), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ, то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).&#x20;

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

15.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

16. Платформа обрабатывает  запрос на проведение оплаты (сообщение pacs.008), в том числе:&#x20;

* выполняет проверку позиций участников и лимитов;
* выполняет блокирование средств для проведения транзакции.
* осуществляет проверку чистой позиции - при достижении лимита чистой позиции направляет в Банк отправителя и Банк бенефициара сообщение pacs.002 со статусом RJCT и кодом ошибки PACS\_002\_NET\_POSITION\_LIMIT\_REACHED.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса на перевод денег pacs.008 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса на проведение оплаты в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
2. Процесс завершается неуспешно.

</details>

17. Платформа направляет в Банк бенефициара запрос на проведение оплаты (сообщение pacs.008), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
4. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
5. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
6. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

17.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

18. Банк бенефициара проверяет счет бенефициара на возможность зачисления денег.
19. Банк бенефициара направляет статус обработки запроса проведения оплаты Платформе (сообщение pacs.002), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса проведения оплаты (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса проведения оплаты в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

19.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара;&#x20;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

20. Платформа направляет статус обработки запроса проведения оплаты в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

20.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

21. Банк отправителя денег направляет в качестве уведомления об успешной транзакции в Платформу сообщение pacs.002 со статусом транзакции ACSC, подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. При отсутствии ответа от Платформы, Банк отправителя денег осуществляет повторную отправку запроса с интервалом 3 секунды до тех пор, пока не будет получен ответ HTTP 200.

</details>

21.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег;
* проверяет корректность заполнения полей.

&#x20;Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Не получен pacs.002 ACSC от Банка отправителя денег:**

1. Если Платформа в течение 30 секунд не получает сообщение pacs.002 (ACSC) от Банка отправителя денег, то транзакция завершается со статусом RJCT и при получении pacs.002 ACSC от Банка отправителя денег будет возвращен HTTP 408.

</details>

22. Платформа направляет в качестве уведомления сообщение pacs.002 со статусом ACSC в Банк бенефициара, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](https://docs.npck.kz/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Если Банк бенефициара не направляет ответ, то Платформа считает запрос не доставленным, при этом транзакция не отклоняется и остается в состоянии ожидания сообщения pacs.002 с финальным статусом от Банка бенефициара.
3. Банк бенефициара не получив ответ от платформы в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](https://docs.npck.kz/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), завершает транзакцию с ошибкой и направляет в Платформу pacs.002 со статусом RJCT с интервалом 3 секунды до тех пор, пока не будет получен ответ HTTP 200.

</details>

22.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

23. Банк бенефициара производит зачисление денег на счет бенефициара и направляет информацию об этом на мобильное приложение ЮЛ/ЛК ЮЛ.
24. Банк бенефициара направляет в качестве уведомления об успешной транзакции в Платформу сообщение pacs.002 со статусом транзакции ACSC, подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

**Платформа не отвечает:**

1. При отсутствии ответа от Платформы, Банк отправителя денег осуществляет повторную отправку запроса с интервалом 3 секунды до тех пор, пока не будет получен ответ HTTP 200.

</details>

24.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

25. Платформа успешно завершает транзакцию (commit transaction).
26. Платформа направляет уведомление pacs.002 со статусом ACSC до Банка отправителя денег с информацией о дате обработки транзакции (Processing Date) и информацией о размерах комиссий, подписав его ЭЦП Платформы.
27. Банк отправителя завершает транзакцию и уведомляет клиента о завершении операции.

<details>

<summary>Возможные неуспешные сценарии</summary>

1. Банк отправителя денег не получил финальное уведомление от платформы pacs.002 со статусом ACSC с информацией о дате обработки транзакции (Processing Date) и информацией о размерах комиссий.
2. Банк отправителя денег отправляет запрос на получение статуса обработки транзакции (pacs.028) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](https://docs.npck.kz/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

{% hint style="info" %}
*Рекомендуется: Банку отправителя денег начинать направлять запрос статуса обработки транзакции (pacs.028) через 5 секунд после успешной отправки pacs.002.*
{% endhint %}


# Возврат денег по проведенной ранее оплате за товар/ услугу в рамках электронной коммерции (C2BRE)

Данный сценарий описывает возврат денег по проведенной ранее оплате за товар/услугу в рамках электронной коммерции.

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

Бенефициаром является клиент, которому возвращаются деньги (т.е. изначальный плательщик, отправитель денег и оригинально транзакции).

Запрос возврата денег (pacs.004) формируется на основе исходного платежного поручения (pacs.008), по которому была ранее выполнена за товар/услугу.

{% hint style="warning" %}
*Важно! Допускается возврат части суммы или полной суммы по проведенной ранее оплате за товар/услугу. Общая сумма возврата не должна превышать суммы исходной транзакции с учетом возвратов по ней (в том числе выполненных и находящихся в обработке).*
{% endhint %}

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Возврат денег по проведенной ранее оплате за товар/услугу в рамках электронной коммерции (C2BRE)» отображает рисунок ниже.

<figure><img src="/files/tMaNtwWyevRRwmlfdvVw" alt=""><figcaption><p align="center">Схема процесса «Возврат денег по проведенной ранее оплате за товар/услугу в рамках электронной коммерции (C2BRE)»</p></figcaption></figure>

{% hint style="info" %}
*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Возврат денег по проведенной ранее оплате за товар/услугу в рамках электронной коммерции (C2BRE)», приведены в таблице ниже.

| Метод API (endpoint)                                                                                | Банк отправителя денег | Банк бенефициара |
| --------------------------------------------------------------------------------------------------- | ---------------------- | ---------------- |
| <p>Запрос возврата денег </p><p> (POST /v1/transfers/iso20022/pacs.004.001.12)</p>                  | <p><br></p>            | +                |
| <p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p> | +                      | +                |

## Взаимосвязь идентификаторов сообщений

Процесс «Возврат денег по проведенной ранее оплате за товар/услугу в рамках электронной коммерции (C2BRE)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/AMGLNiY5dQ7dxf2rBcDO" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

Описание успешного сценария процесса «Возврат денег по проведенной ранее оплате за товар/услугу в рамках электронной коммерции (C2BRE)»:

1. Отправитель денег (бенефициар из оригинальной транзакции) в приложении юридического лица инициализирует возврат денег по ранее полученному платежу.

**Транзакция по проведению возврата денег**

2. Банк отправителя денег производит проверку, что сумма возврата не превышает суммы исходной транзакции с учетом возвратов по ней (выполненных или находящихся в обработке).

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Запрошена некорректная сумма возврата или отсутствуют данные о полученном ранее переводе, по которому запрошен возврат:**

1. Банк отправителя денег отклоняет запрос возврата по проведенной ранее оплате за товар/услугу в рамках электронной коммерции.
2. Процесс завершается неуспешно.

</details>

3. Банк отправителя денег проводит проверку счета клиента на:&#x20;
   * валидность статуса для его дебетования&#x20;
   * отсутствие наложенного ПТП/ РПРО/ ареста и т.п.&#x20;
   * достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Проверка счета не прошла успешно:**

1. Банк отправителя денег уведомляет клиента о невозможности проведения операции.&#x20;
2. Процесс завершается неуспешно.

</details>

4. Банк отправителя денег блокирует сумму операции по счету клиента и формирует запрос возврата денег (pacs.004) на основе исходного сообщения pacs.008, по которому была проведена оплата.
5. Банк отправителя денег направляет Платформе запрос на проведение возврата денег (сообщение pacs.004), подписав его своим ЭЦП.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::TxInf:RtrId> – сгенерированный уникальный идентификатор транзакции на возврат денег
> * в теге \<Document::TxInf:OrgnlInstrId > – сгенерированный уникальный сквозной идентификатор для всей цепочки сообщений в рамках данной операции возврата денег
> * в теге \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<EndToEndId> исходного сообщения pacs.008, по которому была проведена оплата
> * в теге \<Document::OrgnlTxId> – идентификатор транзакции из тега \<TxId> исходного сообщения pacs.008, по которому была проведена оплата
> * указывается  IBAN для счета Отправителя денег (бенефициар из оригинальной транзакции)
> * указывается  IBAN для счета Бенефициара (отправителя денег из оригинальной транзакции)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

5.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

6. Платформа обрабатывает  запрос на проведение возврата денег (сообщение pacs.004), в том числе:&#x20;
   * производит проверку, что сумма возврата не превышает суммы исходной транзакции с учетом возвратов по ней (выполненных или находящихся в обработке);
   * выполняет проверку позиций участников и лимитов;
   * выполняет блокирование средств для проведения транзакции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса возврата денег pacs.004 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса на проведение возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
2. Процесс завершается неуспешно.

</details>

7. Платформа направляет в Банк бенефициара запрос на проведение возврата денег (сообщение pacs.004), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения
> * в теге \<Document::RtrId> – идентификатор транзакции из тега \<RtrId> сообщения pacs.004 Банка отправителя денег
> * в теге \<Document::OrgnlInstrId> – сквозной идентификатор из тега \<OrgnlInstrId> сообщения pacs.004 Банка отправителя денег
> * в теге \<Document::OrgnlEndToEndId> – сквозной идентификатор исходной операции оплаты из тега \<OrgnlEndToEndId> сообщения pacs.004 Банка отправителя денег
> * в теге \<Document::OrgnlTxId> – идентификатор транзакции исходной операции оплаты из тега \<OrgnlTxId> из сообщения pacs.004 Банка отправителя денег
> * указывается  IBAN для счета Отправителя денег (бенефициара из оригинальной транзакции) из сообщения pacs.004 Банка отправителя денег
> * указывается  IBAN для счета Бенефициара (отправителя денег из оригинальной транзакции)из сообщения pacs.004 Банка отправителя денег

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
4. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
5. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
6. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

7.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

8. Банк бенефициара проверяет счет бенефициара (отправителя денег из оригинальной транзакции) на возможность зачисления денег.
9. Банк бенефициара направляет статус обработки запроса проведения возврата денег Платформе (сообщение pacs.002), подписав его своим ЭЦП.

> В сообщении передается:
>
> * \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<OrgnlInstrId> исходного запроса (pacs.004)
> * \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<RtrId> исходного запроса (из pacs.004)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса проведения возврата денег (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса проведения возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

9.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара&#x20;
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

10. Платформа направляет статус обработки запроса проведения возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

> В сообщении передается:
>
> * в теге \<Document::OrgnlEndToEndId> – сквозной идентификатор из тега \<OrgnlInstrId> исходного запроса (pacs.004)
> * в теге \<Document::OrgnlTxId> – идентификатор  транзакции из тега \<RtrId> исходного запроса (из pacs.004)
> * Статус транзакции PDNG (в обработке)

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

10.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

11. Платформа успешно завершает транзакцию (commit transaction).
12. Платформа направляет в качестве уведомления об успешной транзакции в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

12.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание:*&#x20;

*Если Платформа направляет в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк бенефициара не производит (не производит повторное зачисление денег на счет бенефициара и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк бенефициара ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк бенефициара в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)) завершает транзакцию неуспешно (RJCT) по тайм-ауту, зачисление средств бенефициару не производится. Платформа производит откат транзакции, устанавливает статус транзакции - RJCT (неуспешно). Банк отправителя денег, получив статус транзакции RJCT (неуспешно), разблокирует средства Отправителя денег, списание средств не производится.

*Примечание: перед завершением транзакции Банк бенефициара может проверить статус транзакции на Платформе, отравив сообщение pacs.028 (см.* [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)*)*

</details>

12.2. Банк бенефициара производит зачисление денег на счет бенефициара (отправителя денег из оригинальной транзакции) и уведомляет об этом бенефициара (отправителя денег из оригинальной транзакции).

13. Платформа направляет в качестве уведомления об успешной транзакции в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

13.1. Банк отправителя денег, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк отправителя денег не производит (не производит повторное списание денег со счета отправителя денег и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк отправителя денег ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк отправителя денег  направляет запрос статуса транзакции Платформе (сообщение pacs.028, см. [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)), подписав его своим ЭЦП.&#x20;
3. Платформа, успешно выполнив обработку запроса, направляет ответ с HTTP статусом 200.
4. Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции, подписав его ЭЦП Платформы.

</details>

13.2. Банк отправителя денег производит списание денег со счета Отправителя денег (бенефициара из оригинальной транзакции) и уведомляет его о завершении операции.


# Request to Pay

{% hint style="info" %}
Реализация процессов инициализации платежей и переводов денежных средств основана на методах API, описанных в электронном формате в <https://transfers-openapi.npck.kz/>
{% endhint %}

{% hint style="warning" %}
Во всех запросах должен быть указан **HTTP заголовок end-to-end-id**, в котором должен указываться сквозной идентификатор для всей цепочки сообщений, использующийся в рамках данной операции *(должен совпадать с соответствующим значением, передаваемым в теле сообщения)*
{% endhint %}

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


# Инициализация выставления счета на оплату ФЛ от ЮЛ (C2B2\_RTP)

Данный сценарий описывает инициализацию процесса выставления счета на оплату от одного юридического лица (ЮЛ) в одном БВУ (Банк Бенефициара) другому физическому лицу (ФЛ), обслуживаемому в другом БВУ (Банк отправителя денег).

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Инициализация выставления счета на оплату ФЛ от ЮЛ(C2B2\_RTP)» отображает рисунок ниже.

<figure><img src="/files/0B3pEAhU7RR1r0l4QvLz" alt=""><figcaption><p>Схема процесса «Инициализация выставления счета на оплату ФЛ от ЮЛ(C2B2_RTP)»</p></figcaption></figure>

{% file src="/files/hTKk26dh3S58kBrIN00k" %}
Схематичное отображение процесса
{% endfile %}

{% hint style="info" %}
*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса *«Инициализация выставления счета на оплату ФЛ от ЮЛ(C2B2\_RTP)»*, приведены в таблице ниже.

| Метод API (endpoint)                                                                                     | Банк отправителя денег | Банк бенефициара |
| -------------------------------------------------------------------------------------------------------- | ---------------------- | ---------------- |
| <p>Запрос верификации наличия счета клиента </p><p>(POST /v1/transfers/iso20022/acmt.023.001.03)</p>     | <p><br>+</p>           |                  |
| <p>Результат верификации наличия счета клиента  </p><p>(POST /v1/transfers/iso20022/acmt.024.001.03)</p> |                        | <p>+<br></p>     |
| Запрос на осуществление платежа (POST /v1/transfers/iso20022/ pain.013.001.11)                           | +                      |                  |
| Отчет о статусе запроса на осуществление платежа (POST /v1/transfers/iso20022/ pain.014.001.11)          |                        | +                |
| <p>Запрос на перевод денег </p><p> (POST /v1/transfers/iso20022/pacs.008.001.11)</p>                     | <p><br></p>            | +                |
| <p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p>      | +                      | +                |

## Взаимосвязь идентификаторов сообщений

Успешный процесс «Инициализация выставления счета на оплату ФЛ от ЮЛ(C2B2\_RTP)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/FpD2UjPV9zDsIGVNqua1" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

Неуспешный процесс «Инициализация выставления счета на оплату ФЛ от ЮЛ(C2B2\_RTP)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/oAKZq4YpCO9JQkZlKyQn" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

Описание успешного сценария процесса «Инициализация выставления счета на оплату ФЛ от ЮЛ(C2B2\_RTP)»:

1. ***Верификация наличия счета клиента***

1.1. Бенефициар в приложении Банка бенефициара инициирует запрос на осуществление платежа от отправителя денег по номеру телефона.

1.2. Банк бенефициара направляет Платформе запрос верификации наличия счета клиента по номеру телефона (сообщение acmt.023), подписывая его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ, то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.
2. Процесс завершается неуспешно.

</details>

1.3. Платформа, получив запрос, проводит его обработку и валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

1.4. Платформа направляет в Банк отправителя денег запрос верификации наличия счета клиента по номеру телефона (сообщение acmt.023), подписывая его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Платформа направляет в Банк бенефициара сообщение acmt.024 с ошибкой.
3. Банк бенефициара завершает процесс, получив сообщение с информацией об ошибке.&#x20;
4. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк отправителя денег направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа завершает процесс, получив сообщение с информацией об ошибке.
3. Платформа направляет в Банк бенефициара сообщение acmt.024 с ошибкой.
4. Банк бенефициара завершает процесс, получив сообщение с информацией об ошибке.
5. Процесс завершается неуспешно.

</details>

1.5. Банк отправителя денег, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

1.6. Банк отправителя денег проверяет наличие счета по указанному в запросе номеру телефона.

1.7. Банк отправителя денег направляет результат верификации наличия счета клиента Платформе (сообщение acmt.024), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку отравителя денег с соответствующим ошибке HTTP статусом.&#x20;
2. Банк бенефициара завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Процесс завершается неуспешно.

* **Сведения о счете клиента не найдены:**

1. Банк отправителя денег направляет негативный результат верификации наличия счета клиента Платформе (сообщение acmt.024).
2. Платформа направляет негативный результат верификации наличия счета клиента Банку бенефициара (сообщение acmt.024).&#x20;
3. Процесс завершается неуспешно.

</details>

1.8. Платформа, получив запрос (сообщение acmt.024), проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

1.9. Платформа направляет результат верификации наличия счета клиента в Банк бенефициара (сообщение acmt.024), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

1.10. Банк бенефициара, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

1.11. Банк бенефициара  отображает информацию об отправителе денег (ФИО), чтобы Бенефициар мог удостовериться в корректности получателя.

1.12. Бенефициар подтверждает выставление счета в приложении Банка бенефициара.

2. **Выставление счета на оплату**

2.1. Бенефициар (ЮЛ) инициирует выставление счета с указанием суммы платежа.

2.2. Банк бенефициара направляет Платформе запрос на осуществление платежа от отправителя денег (сообщение pain.013), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ, то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.
2. Процесс завершается неуспешно.

</details>

2.3. Платформа, получив запрос, проводит его обработку и валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

2.4. Платформа направляет в Банк отправителя денег запрос на осуществление платежа от отправителя денег (сообщение pain.013), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Платформа направляет в Банк бенефициара сообщение pain.014 с ошибкой.
3. Банк бенефициара завершает процесс, получив сообщение с информацией об ошибке.&#x20;
4. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк отправителя денег направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа завершает процесс, получив сообщение с информацией об ошибке.
3. Платформа направляет в Банк бенефициара сообщение pain.014 с ошибкой.
4. Банк бенефициара завершает процесс, получив сообщение с информацией об ошибке.
5. Процесс завершается неуспешно.

</details>

2.5. Банк отправителя денег, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

2.6. Банк отправителя денег принимает сообщение pain.013 и отображает информацию о счете клиенту–отправителю денег (ФЛ) через мобильное приложение.

**2.6.1. Уведомление клиента и срок действия счета:**

* После успешной обработки сообщения pain.013 Банк отправителя денег инициирует направление клиенту–отправителю денег (ФЛ) push-уведомления о выставлении счета Бенефициаром (ЮЛ).
* С момента получения Банком отправителя денег сообщения **pain.013** запускается таймер срока действия счета.
* Срок действия счета составляет 24 часа. В течение указанного времени клиент–отправитель денег может подтвердить оплату счета.
* По истечении 24 часов с момента выставления счета, при отсутствии подтверждения оплаты со стороны клиента–отправителя денег, счет автоматически переводится в неактивный статус и становится недоступным для оплаты.

2.7. Отправитель денег просматривает выставленный счет и подтверждает согласие на его оплату.

**2.8. Отказ оплаты выставленного счета**

*2.8.1.  Отправитель денег отклоняет счет на оплату:*

• Банк отправителя денег направляет статус обработки запроса перевода денег Платформе (сообщение pain.014), подписав его своим ЭЦП, со статусом транзакции RJCT (отклонена).

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Банк отправителя денег завершает процесс, не получив ответ в срок в соответствии с установленным регламентом  (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.
2. Процесс завершается неуспешно.

</details>

• Платформа направляет статус обработки запроса перевода денег в Банк бенефициара (сообщение pain.014 со статусом RJCT), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа завершает процесс, получив сообщение с информацией об ошибке.
3. Процесс завершается неуспешно.

</details>

• Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

*2.8.2.  Отправитель денег не совершает оплату **в течение 24 часов** с момента выставления счета:*

• Процесс завершается неуспешно.

3. **Транзакция по проведению платежа**

3.1. Банк отправителя денег проводит проверку счета клиента на:

* валидность статуса для его дебетования
* отсутствие наложенного ПТП/ РПРО/ ареста и т.п.
* достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* &#x20;**Проверка счета не прошла успешно:**

1. Банк отправителя денег уведомляет клиента о невозможности проведения операции.
2. Процесс завершается неуспешно.

</details>

3.2. Банк отправителя денег блокирует сумму операции по счету клиента и формирует платежное поручение (pacs.008).

3.3. Банк отправителя денег направляет Платформе запрос на перевод денег (сообщение pacs.008), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ, то Банк отправителя денег должен считать, что запрос не доставлен
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.
2. Процесс завершается неуспешно.

</details>

3.4. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

3.5. Платформа обрабатывает запрос на перевод денег (сообщение pacs.008), в том числе:

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

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса на перевод денег pacs.008 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).
2. Процесс завершается неуспешно.

</details>

3.6. Платформа направляет в Банк бенефициара запрос на перевод денег (сообщение pacs.008), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
4. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
5. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
6. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

3.7. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

3.8. Банк бенефициара проверяет счет бенефициара на возможность зачисления денег.

3.9. Банк бенефициара направляет статус обработки запроса перевода денег Платформе (сообщение pacs.002 со статусом PDNG), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции статусом RJCT (отклонена).&#x20;
3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса перевода денег (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

3.10. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара&#x20;
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

3.11. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002 со статусом PDNG), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает::**

1. Если Банк отправителя денег не направляет ответ, то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

3.12. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

3.13. Банк отправителя денег направляет в качестве уведомления об успешной транзакции в Платформу сообщение pacs.002 со статусом транзакции ACSC, подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает::**

1. При отсутствии ответа от Платформы, Банк отправителя денег осуществляет повторную отправку запроса с интервалом 3 секунды до тех пор, пока не будет получен ответ HTTP 200

</details>

3.13.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег;
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Не получен pacs.002 ACSC от Банка отправителя денег:**

1. Если Платформа в течение 30 секунд не получает сообщение pacs.002 (ACSC) от Банка отправителя денег, то транзакция завершается со статусом RJCT и при получении pacs.002 ACSC от Банка отправителя денег будет возвращен HTTP 408.

</details>

3.14. Платформа направляет в качестве уведомления сообщение pacs.002 со статусом ACSC в Банк бенефициара, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](https://docs.npck.kz/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Если Банк бенефициара не направляет ответ, то Платформа считает запрос не доставленным, при этом транзакция не отклоняется и остается в состоянии ожидания сообщения pacs.002 с финальным статусом от Банка бенефициара.
3. Банк бенефициара не получив ответ от платформы в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](https://docs.npck.kz/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), завершает транзакцию с ошибкой и направляет в Платформу pacs.002 со статусом RJCT с интервалом 3 секунды до тех пор, пока не будет получен ответ HTTP 200.

</details>

3.14.1.  Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

3.15. Банк бенефициара производит зачисление денег на счет бенефициара и направляет информацию об этом на мобильное приложение ЮЛ.

3.16. Банк бенефициара направляет в качестве уведомления об успешной транзакции в Платформу сообщение pacs.002 со статусом транзакции ACSC, подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. При отсутствии ответа от Платформы, Банк отправителя денег осуществляет повторную отправку запроса с интервалом 3 секунды до тех пор, пока не будет получен ответ HTTP 200.

</details>

3.16.1.  Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

3.17. Платформа успешно завершает транзакцию (commit transaction).

3.18. Платформа направляет уведомление pacs.002 со статусом ACSC до Банка отправителя денег с информацией о дате обработки транзакции (Processing Date) и информацией о размерах комиссий, подписав его ЭЦП Платформы.

3.19. Банк отправителя завершает транзакцию и уведомляет клиента о завершении операции.

<details>

<summary>Возможные неуспешные сценарии</summary>

1. Банк отправителя денег не получил финальное уведомление от платформы pacs.002 со статусом ACSC с информацией о дате обработки транзакции (Processing Date) и информацией о размерах комиссий.
2. Банк отправителя денег отправляет запрос на получение статуса обработки транзакции (pacs.028) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](https://docs.npck.kz/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

{% hint style="info" %}
*Рекомендуется: Банку отправителя денег начинать направлять запрос статуса обработки транзакции (pacs.028) через 5 секунд после успешной отправки pacs.002.*
{% endhint %}


# Возврат перевода по инициативе Отправителя (C2CR\_RTP)

Данный сценарий описывает процесс возврата денег по ранее совершенному переводу, инициируемый бенефициаром (отправителем денег в оригинальной транзакции).

{% hint style="warning" %}
*Важно! Допускается возврат только полной суммы полученного ранее перевода. Возврат по ранее полученному переводу может быть выполнен только один раз. Если запрос возврата денег по переводу находится в обработке, то повторный запрос возврата денег по данному переводу не должен отправляться до ее завершения.*
{% endhint %}

## Методы API (endpoint), которые необходимо реализовать&#x20;

{% hint style="info" %}
При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).
{% endhint %}

Схему успешного сценария процесса «Возврат перевода по инициативе Отправителя (C2CR\_RTP)» отображает рисунок ниже.

<figure><img src="/files/bJoNX8pyd1BrUYJDpRXH" alt=""><figcaption><p>Схема процесса «Возврат перевода по инициативе Отправителя (C2CR_RTP))»</p></figcaption></figure>

{% hint style="info" %}
*Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Возврат перевода по инициативе Отправителя (C2CR\_RTP)», приведены в таблице ниже.

| Метод API (endpoint)                                                                                   | Банк отправителя денег | Банк бенефициара |
| ------------------------------------------------------------------------------------------------------ | ---------------------- | ---------------- |
| Запрос на осуществление возврата от отправителя денег (POST /v1/transfers/iso20022/ pain.013.001.11)   | +                      |                  |
| Отчет о статусе запроса на возврат от отправителя денег (POST /v1/transfers/iso20022/ pain.014.001.11) |                        | +                |
| <p>Запрос возврата денег </p><p> (POST /v1/transfers/iso20022/pacs.004.001.12)</p>                     | <p><br></p>            | +                |
| <p>Статус обработки запроса перевода денег </p><p>(POST /v1/transfers/iso20022/pacs.002.001.13)</p>    | +                      | +                |

## Взаимосвязь идентификаторов сообщений

Успешный процесс «Возврат перевода по инициативе Отправителя (C2CR\_RTP)»построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/KmRxjJTVnmmeeqvtV2lL" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

Неуспешный процесс «Возврат перевода по инициативе Отправителя (C2CR\_RTP)»построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

<figure><img src="/files/6eNJwAi1oTxj1kEFCLi4" alt=""><figcaption><p>Логическая схема взаимосвязи идентификаторов сообщений</p></figcaption></figure>

## Описание процесса

Описание успешного сценария процесса «Возврат перевода по инициативе Отправителя (C2CR\_RTP)»:

1. Отправитель денег из оригинальной транзакции обнаружив ошибку в ранее выполненном переводе, инициирует запрос в приложении Банка бенефициара на возврат денег по ошибочному переводу.

{% hint style="warning" %}
Допускается возврат только полной суммы полученного ранее перевода
{% endhint %}

2. Банк бенефициара направляет Платформе запрос на возврат денег от отправителя перевода (сообщение pain.013), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Банк Бенефициара завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/taim-auty-i-logika-povtornykh-zaprosov)).
2. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет банку бенефициара ответ с соответствующим ошибке HTTP статусом.
2. Процесс завершается неуспешно.

</details>

2.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

3. Платформа направляет в Банк отправителя денег запрос на возврат (сообщение pain.013), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Платформа направляет в Банк бенефициара сообщение pain.014 с ошибкой.
3. Банк бенефициара завершает процесс, получив сообщение с информацией об ошибке.
4. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк отправителя денег направляет ответ Платформе с соответствующим ошибке HTTP статусом.&#x20;
2. Платформа завершает процесс, получив сообщение с информацией об ошибке.
3. Платформа направляет в Банк бенефициара сообщение pain.014 с ошибкой.
4. Банк бенефициара завершает процесс, получив сообщение с информацией об ошибке.
5. Процесс завершается неуспешно.

</details>

3.1. Банк отправителя денег, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя  денег направляет ответ с HTTP статусом 200.

**3.2. Уведомление клиента и срок действия запроса на возврат**

* После успешной обработки сообщения pain.013 Банк отправителя денег инициирует направление клиенту–отправителю денег (ФЛ) push-уведомления в мобильном приложении о поступлении запроса на возврат денег.
* С момента получения Банком отправителя денег сообщения pain.013 запускается таймер срока действия запроса на возврат.
* Срок действия запроса на возврат составляет 7 календарных дней. В течение указанного срока клиент–отправитель денег может подтвердить или отклонить возврат денег.
* По истечении 7 дней с момента поступления запроса, при отсутствии решения клиента–отправителя денег, запрос на возврат автоматически переводится в неактивный статус и считается отклоненным.

4. Отправитель денег просматривает запрос на возврат денег и подтверждает согласие на его возврат.

***4.1.  Отказ в возврате денег:***

4.1.1. Банк отправителя денег направляет статус обработки запроса на возврат денег Платформе (сообщение pain.014), подписав его своим ЭЦП, со статусом транзакции RJCT (отклонена) и соответствующим кодом ошибки.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Банк отправителя денег завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

4.1.2. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

4.1.3. Платформа завершает процесс статусом RJCT.

4.1.4. Платформа направляет статус обработки запроса в Банк бенефициара (сообщение pain.014 со статусом RJCT), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена) и соответствующим кодом ошибки.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа завершает процесс, получив сообщение с информацией об ошибке.
3. Процесс завершается неуспешно.

</details>

4.1.5. Банк бенефициара, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

4.1.6 Банк бенефициара завершает процесс статусом RJCT.

***4.2 Отправитель денег не возвращает средства в течение 7 дней:***

* Процесс завершается неуспешно.

**Транзакция по проведению возврата денег**

5. Банк отправителя денег производит проверку, что сумма возврата соответствует исходной транзакции, и по данному переводу возврат не производился (выполненный или находящийся в обработке).

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Запрошена некорректная сумма возврата или отсутствуют данные о полученном ранее переводе, по которому запрошен возврат:**

1. Банк отправителя денег отклоняет запрос возврата полученного перевода.
2. Процесс завершается неуспешно.

</details>

6. Банк отправителя денег проводит проверку счета клиента на:&#x20;

* валидность статуса для его дебетования&#x20;
* отсутствие наложенного ПТП/ РПРО/ ареста и т.п.&#x20;
* достаточности средств для списания суммы операции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Проверка счета не прошла успешно:**

1. Банк отправителя денег уведомляет клиента о невозможности проведения операции.&#x20;
2. Процесс завершается неуспешно.

</details>

7. Банк отправителя денег блокирует сумму операции по счету клиента и формирует запрос возврата денег (pacs.004) на основе исходного сообщения pacs.008, по которому был проведен перевод.
8. Банк отправителя денег направляет Платформе запрос на проведение возврата денег (сообщение pacs.004), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк отправителя денег должен считать, что запрос не доставлен.
2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.&#x20;
2. Процесс завершается неуспешно.

</details>

8.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка отправителя денег
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

9. Платформа обрабатывает  запрос на проведение возврата денег (сообщение pacs.004), в том числе:&#x20;

* производит проверку, что сумма возврата соответствует исходной транзакции, и по данному переводу возврат не производился (выполненный или находящийся в обработке);
* выполняет проверку позиций участников и лимитов;
* выполняет блокирование средств для проведения транзакции

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Обработка запроса возврата денег pacs.004 Платформой не проходит успешно:**

1. Платформа направляет статус обработки запроса на проведение возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
2. Процесс завершается неуспешно.

</details>

10. Платформа направляет в Банк бенефициара запрос на проведение возврата денег (сообщение pacs.004), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
3. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
4. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
5. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.&#x20;
6. Процесс завершается неуспешно.

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.
2. Платформа устанавливает статус транзакции RJCT (отклонена).
3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.
4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).&#x20;
5. Процесс завершается неуспешно.

</details>

10.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

11. Банк бенефициара проверяет счет бенефициара (отправителя денег из оригинальной транзакции) на возможность зачисления денег.
12. Банк бенефициара направляет статус обработки запроса проведения возврата денег Платформе (сообщение pacs.002), подписав его своим ЭЦП.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Платформа не отвечает:**

1. Если Платформа не направляет ответ,  то Банк бенефициара должен считать, что запрос не доставлен.
2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

* **Валидация сообщения не прошла успешно:**

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).
2. Платформа устанавливает статус транзакции RJCT (отклонена).&#x20;
3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)), устанавливает статус транзакции RJCT (отклонена).&#x20;
4. Процесс завершается неуспешно.

* **Транзакция отклонена (статус транзакции RJCT):**

1. Банк бенефициара направляет Платформе статус обработки запроса проведения возврата денег (сообщение pacs.002) - RJCT (отклонена).
2. Платформа направляет статус обработки запроса проведения возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).&#x20;
3. Процесс завершается неуспешно.

</details>

12.1. Платформа, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Банка бенефициара&#x20;
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

13. Платформа направляет статус обработки запроса проведения возврата денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

13.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

14. Платформа успешно завершает транзакцию (commit transaction).
15. Платформа направляет в качестве уведомления об успешной транзакции в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не отвечает:**

1. Если Банк бенефициара не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

15.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание:*&#x20;

*Если Платформа направляет в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк бенефициара не производит (не производит повторное зачисление денег на счет бенефициара и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк бенефициара не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк бенефициара ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк бенефициара в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)) завершает транзакцию неуспешно (RJCT) по тайм-ауту, зачисление средств бенефициару не производится. Платформа производит откат транзакции, устанавливает статус транзакции - RJCT (неуспешно). Банк отправителя денег, получив статус транзакции RJCT (неуспешно), разблокирует средства Отправителя денег, списание средств не производится.

*Примечание: перед завершением транзакции Банк бенефициара может проверить статус транзакции на Платформе, отравив сообщение pacs.028 (см.* [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)*)*

</details>

15.2. Банк бенефициара производит зачисление денег на счет бенефициара (отправителя денег из оригинальной транзакции) и уведомляет об этом бенефициара (отправителя денег из оригинальной транзакции).

16. Платформа направляет в качестве уведомления об успешной транзакции в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не отвечает:**

1. Если Банк отправителя денег не направляет ответ,  то Платформа должна считать, что запрос не доставлен.
2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).

</details>

16.1. Банк отправителя денег, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

* проверяет подпись Платформы
* проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

{% hint style="warning" %}
*Примечание: Если Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк отправителя денег не производит (не производит повторное списание денег со счета отправителя денег и т.д.), а лишь отправляет ответ с HTTP статусом 200*
{% endhint %}

<details>

<summary>Возможные неуспешные сценарии</summary>

* **Банк отправителя денег не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):**

1. Банк отправителя денег ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)).
2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк отправителя денег  направляет запрос статуса транзакции Платформе (сообщение pacs.028, см. [Сервис получения статуса обработки транзакции](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/servis-polucheniya-statusa-obrabotki-tranzakcii)), подписав его своим ЭЦП.&#x20;
3. Платформа, успешно выполнив обработку запроса, направляет ответ с HTTP статусом 200.
4. Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции, подписав его ЭЦП Платформы.

</details>

16.2. Банк отправителя денег производит списание денег со счета Отправителя денег (бенефициара из оригинальной транзакции) и уведомляет его о завершении операции.


# Сервис получения выписки по счету участника

Для предоставления информации обо всех операциях, проведенных по счету банка, в течение операционного дня используется сообщение «Выписка по счету участника» (сообщение camt.053).&#x20;

{% hint style="info" %}
Выписка может быть получена двумя способами:

* выписка регулярно высылается всем банкам-участникам автоматически Платформой при закрытии операционного дня;
* банки-участники могут получить выписку по счету по запросу
  {% endhint %}

В течении операционного дня банки-участники могут получить выписку по счету по запросу, для этого:

1. Банк-участник формирует запрос получения выписки (сообщение camt.060), подписывает его своей ЭЦП и направляет Платформе.
2. Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.
3. Платформа формирует выписку по счету участника и направляет ее Банку-участнику.

{% hint style="info" %}
*Примечание:*&#x20;

*В составе сообщения camt.053 может быть не более 10 000 транзакции.*&#x20;

*Если в выписке больше 10 000 транзакций, то формируется несколько сообщений camt.053, каждое из которых подписывается ЭЦП Платформы и направляется в Банк-участник. Связь между сообщениями camt.053, относящимися к одной выписке, осуществляется по сквозному идентификатору выписки (тег Stmt -> Id), а для навигации по ним предназначены номер сообщения (GrpHdr -> PgNb) и признак последнего сообщения (GrpHdr -> LastPgInd).*
{% endhint %}

4. Если валидация полученного сообщения camt.053 проходит успешно, Банк-участник направляет ответ с HTTP статусом 200.

<figure><img src="/files/UzrpKiHnkibbWBPMBoHn" alt=""><figcaption><p>Схема получения выписки по счету банком по запросу</p></figcaption></figure>

{% hint style="info" %}
*Примечание:*&#x20;

*На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

{% hint style="warning" %}
*Для получения выписки по счету на стороне Банка должен быть реализован метод (endpoint) «Выписка по счету» (POST /v1/transfers/iso20022/camt.053.001.11).*
{% endhint %}


# Сервис получения статуса обработки транзакции

Для запроса статуса обработки транзакции используется сообщение «Запрос статуса обработки операции» (сообщение pacs.028).&#x20;

Запрос статуса обработки транзакции используется, если участник в соответствии с установленным регламентом (см. [Тайм-ауты и логика повторных запросов](/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/mezhbankovskaya-sistema-mobilnykh-platezhei-msmp/taim-auty-i-logika-povtornykh-zaprosov)) не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT).

<figure><img src="/files/S4TMT6U8jkDd1xrp7FI5" alt=""><figcaption><p>Схема получения статуса обработки транзакции по запросу</p></figcaption></figure>

Получение статуса обработки транзакции по запросу:

1. Банк-участник формирует запрос получения статуса обработки транзакции (сообщение pacs.028), подписывает его своей ЭЦП и направляет Платформе.
2. Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.
3. Платформа формирует сообщение pacs.002 со статусом транзакции и направляет ее Банку-участнику.&#x20;
4. Если валидация полученного сообщения pacs.002 проходит успешно, Банк-участник направляет ответ с HTTP статусом 200.

{% hint style="info" %}
*Примечание:*&#x20;

*На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено  в электронном формате в* [*https://transfers-openapi.npck.kz/*](https://transfers-openapi.npck.kz/)*.*
{% endhint %}

{% hint style="warning" %}
Для получения выписки по счету на стороне Банка должен быть реализован метод (endpoint) «Статус обработки запроса перевода денег» (POST /v1/transfers/iso20022/pacs.002.001.13).
{% endhint %}


# Получение информации о банках и статусе API

Доступны следующие API:

* API для получения информации о банках участниках (см. [#servis-polucheniya-informacii-o-bankakh-uchastnikakh](#servis-polucheniya-informacii-o-bankakh-uchastnikakh "mention")). Например, его можно использовать для отображения списка банков для пользователя (например, для совершения переводов). В API по банкам возвращаются участники со статусом активности.&#x20;
* API для получения информации о статусе доступности сервисов банков участников (см. [#servis-polucheniya-statusa-api-uchastnikov](#servis-polucheniya-statusa-api-uchastnikov "mention")), которое позволяет определять возможность осуществления операций с участником в определенный момент времени. Статус доступности предоставляется по каждому API участника, так как в определенные моменты времени одно API может быть доступно, а другое недоступно по различным причинам.

{% hint style="warning" %}
Важно понимать, что статус участника и статус доступности его API являются разными понятиями: участник может быть активным, однако некоторые из его API могут быть временно недоступны из-за сбоев, технических работ и других причин.
{% endhint %}

## Сервис получения информации о банках участниках

Для получения информации о зарегистрированных на Платформе банках предназначен служебный метод Платформы GET /v1/banks (см. описание в <https://banks-openapi.npck.kz/>).

> Данный метод предоставляет такие сведения как:&#x20;
>
> * наименование банка, указанное при регистрации на Платформе
> * логотип
> * БИК, указанное при регистрации на Платформе
> * БИН, указанное при регистрации на Платформе
> * (acceptsQrV1/acceptsQrV2)  версионность QR, поддерживаемая эквайером (true/false)
> * qrUrl,
> * (provider\_id) идентификатор, присвоенный при регистрации на Платформе,
> * статус активности участника,
> * (features) список опубликованных API у данного участника.

{% hint style="info" %}
*Примечание:*&#x20;

*Для аутентификации в методе API «Получить список банков» (GET /v1/banks) используется аутентификационный токен банка, который можно получить в личном кабинете участника на Платформе.*

&#x20;*Используется* JSON Web Token (JWT) с ограниченным сроком действия, срок действия токена указывается в поле "exp", входящем в соствав JWT.&#x20;

До истечения срока действия токена его необходимо перегенерировать *в личном кабинете участника. Вызов метода с истекшим токеном недоступен (ошибка с HTTP статусом 401).*
{% endhint %}

## Сервис получения статуса API участников

Платформа непрерывно осуществляет мониторинг доступности опубликованных на ней API участников.&#x20;

Для получения списка активных API участников предназначен служебный метод Платформы GET /v1/status/providers (см. описание в <https://status-openapi.npck.kz/>).&#x20;

> Данный метод предоставляет информацию по API участников и их текущем статусе: ACTIVE, NOT\_ACTIVE,BLOCK\_DEBIT, BLOCK\_CREDIT и CLOSED.&#x20;
>
> При статусе **ACTIVE** передается список опубликованных API участников  `(features).`

В ответе метода `GET /v1/banks` будут передаваться параметры `acceptsQrV1` и `acceptsQrV2` (true/false), которые отражают, какую версию QR эквайер поддерживает для приема операций.&#x20;

<pre class="language-jsonc" data-title="Пример:" data-full-width="true"><code class="lang-jsonc">{
    "providerId": "c5e13202-1e8b-4666-a90f-1c9937b6bbff", [Идентификатор, присвоенный при регистрации на Платформе]
<strong>            "name": "Mock Bank 3", [Наименование банка, указанное при регистрации на Платформе]
</strong>            "bic": "EXKAKZKA", [БИК банка,указанное при регистрации на Платформе]
            "bin": "070940006465", [Бин банка, указанное при регистрации на Платформее]
            "acceptsQrV1": true, [Версионность QR, поддерживаемая эквайером (true/false)]
            "acceptsQrV2": true,[Версионность QR, поддерживаемая эквайером (true/false)]
            "status": "ACTIVE", [Статус активности участника]
            "features": [Список опубликованных API участника]  [
                "C2C2_TRANSFERS_SEND", 
                "C2C2_TRANSFERS_RECEIVE",
                "C2CR_RETURN_TRANSFERS_SEND",
                "C2CR_RETURN_TRANSFERS_RECEIVE",
                "C2CR_RTP_RETURN_TRANSFERS_SEND",
                "C2CR_RTP_RETURN_TRANSFERS_RECEIVE",
                "M2M_TRANSFERS_SEND",
                "M2M_TRANSFERS_RECEIVE",
                "C2B2_RTP_PAYMENTS_SEND",
                "C2B2_RTP_PAYMENTS_RECEIVE",
                "C2B2_V2_PAYMENTS_SEND",
                "C2B2_V2_PAYMENTS_RECEIVE",
                "C2B2E_PAYMENTS_SEND",
                "C2B2E_PAYMENTS_RECEIVE",
                "C2BR_V2_RETURN_PAYMENTS_SEND",
                "C2BR_V2_RETURN_PAYMENTS_RECEIVE",
                "C2BRE_RETURN_PAYMENTS_SEND",
                "C2BRE_RETURN_PAYMENTS_RECEIVE",
                "C2BRM_V2_RETURN_PAYMENTS_SEND",
                "C2BRM_V2_RETURN_PAYMENTS_RECEIVE",
                "B2C2I_PAYOUTS_SEND",
                "B2C2I_PAYOUTS_RECEIVE",
                "B2C2U_PAYOUTS_SEND",
                "B2C2U_PAYOUTS_RECEIVE"
            ],
"logoUrl": "https://api.stage.npck.kz/v1/banks-logos?logoId=294afc2d-15eb-424f-9b27-19ad7213e8b8", [URL логотипа банка, доступный через Интернет]
"qrUrl": "https://mock-bank-3.stage.npck.kz", [URL, используемый при формировании QR эквайером]
"internalLogoUrl": "https://transfers-api.stage.npck.kz/v1/banks-logos?logoId=294afc2d-15eb-424f-9b27-19ad7213e8b8" [URL логотипа банка, доступный только через выделенный канал]
        }
</code></pre>

Статус доступности предоставляется по каждому API участника.


# Коды ошибок

## 1. Ошибки, при валидации запроса&#x20;

Если при валидации запроса происходит одна из приведенных ниже ошибок, то сведения о возникшей ошибке направляются в ответе (синхронно).

Используемые HTTP-статусы ответа для ошибок:

<pre data-title="HTTP response status" data-overflow="wrap"><code> - 400 - некорректный запрос.
 - 401 - авторизация не пройдена (например, не прошла проверка подписи сообщения ЭЦП банка). 
<strong> - 403 - используется для обозначения того, что клиент не имеет необходимых разрешений для ресурса или запрос понятен серверу, но сервер отказывается его авторизовать.
</strong> - 404 - запрошен ресурс, который не реализован, или ресурс, который не определен в спецификации.
 - 405 - попытка получить доступ к ресурсу с помощью метода, который не поддерживается
 - 406 - указывает на то, что сервер не может выдать ответ, соответствующий списку допустимых значений, определенному в заголовках запроса.
 - 408 - превышено время обратботки запроса.
 - 429 - превышен лимит запросов.
 - 500 - внутренняя ошибка сервера.
</code></pre>

Коды ошибок, используемые для HTTP-статуса 400:

{% code title="HTTP 400" overflow="wrap" %}

```
 - `FIELD_INVALID` - указано некорректное значение параметра.
 - `HEADER_MISSING` - отсутствует обязательный заголовок запроса.
 - `HEADER_INVALID` - указано некорректное значение в заголовке запроса.
 - `DEBTOR_BLOCKED` - банк отправителя денег заблокирован.
 - `CREDITOR_BLOCKED` - банк получателя денег заблокирован.
 - `DEBTOR_NOT_ACTIVE` - банк отправителя денег неактивен.
 - `CREDITOR_NOT_ACTIVE` - банк получателя денег неактивен.
 - `BANK_NOT_FOUND` - данные по банку не найдены. 
 - `INVALID_DEBTOR_DATA` - некорректные данные отправителя денег.
 - `INVALID_TRANSACTION_TYPE` - некорректный тип транзакции.
 - `INVALID_TRANSACTION_STATUS`- некорректный статус транзакции.
 - `INVALID_TRANSACTION_MESSAGE_STATUS`- неверный статус сообщения.
 - `BUSINESS_DAY_CLOSED` - операционный день закрыт.
 - `POSSIBLE_FRAUD_DETECTED` - зафиксирована подозрительная активность (фрод).
 - `NET_POSITION_LIMIT_REACHED` - превышен лимит баланса банка.
 - `TRANSFER_LIMIT_AMOUNT_EXCEEDED` - превышение лимита: платеж превышает установленный лимит для отправителя или получателя.
 - `REFUND_AMOUNT_EXCEEDED` - превышена сумма, доступная для возврата.
 - `OPERATION_NOT_ALLOWED` - операция не разрешена.
 - `PARTIAL_REFUND_NOT_ALLOWED` - операция не разрешена, не разрешен частичный возврат суммы.
 - `UNKNOWN_ERROR` - возникла непредвиденная ошибка.
```

{% endcode %}

{% hint style="warning" %}
Не используется, сохранено для обратной совместимости:

* `DEBTOR_NOT_FOUND` - данные по банку отправителя денег не найдены.
* `CREDITOR_NOT_FOUND` - данные по банку получателя денег не найдены.
  {% endhint %}

{% hint style="info" %}
Ниже приведено соответствие кодов ошибок, возвращаемых с HTTP-кодом ответа 400, и кодов ошибок, возвращаемых в сообщении pacs.002 при запросе их посредством отправки pacs.028 (*т.е. если при отправке запроса получен HTTP-код ответа 400 с одним из следующих кодов, то при запросе pacs.028 возвращается pacs.002 с соответствующей ошибкой*):

* POSSIBLE\_FRAUD\_DETECTED -> PACS\_002\_POSSIBLE\_FRAUD\_DETECTED
* NET\_POSITION\_LIMIT\_REACHED -> PACS\_002\_NET\_POSITION\_LIMIT\_REACHED
* TRANSFER\_LIMIT\_AMOUNT\_EXCEEDED -> PACS\_002\_LIMIT\_AMOUNT\_EXCEEDED
* REFUND\_AMOUNT\_EXCEEDED -> PACS\_002\_REFUND\_AMOUNT\_EXCEEDED
* OPERATION\_NOT\_ALLOWED -> PACS\_002\_OPERATION\_NOT\_ALLOWED
* PARTIAL\_REFUND\_NOT\_ALLOWED -> PACS\_002\_PARTIAL\_REFUND\_NOT\_ALLOWED
* INVALID\_TRANSACTION\_STATUS, INVALID\_TRANSACTION\_MESSAGE\_STATUS, BUSINESS\_DAY\_CLOSED, UNKNOWN\_ERROR -> PACS\_002\_UNEXPECTED\_ERROR
* FIELD\_INVALID -> PACS\_002\_FIELD\_INVALID&#x20;
* HEADER\_INVALID -> PACS\_002\_HEADER\_INVALID&#x20;
* HEADER\_MISSING -> PACS\_002\_HEADER\_MISSING&#x20;
* DEBTOR\_BLOCKED -> PACS\_002\_DEBTOR\_BLOCKED&#x20;
* CREDITOR\_BLOCKED -> PACS\_002\_CREDITOR\_BLOCKED&#x20;
* DEBTOR\_NOT\_ACTIVE -> PACS\_002\_DEBTOR\_NOT\_ACTIVE&#x20;
* CREDITOR\_NOT\_ACTIVE -> PACS\_002\_CREDITOR\_NOT\_ACTIVE
  {% endhint %}

Коды ошибок, используемые для HTTP-статуса 408:

{% code title="HTTP 408" overflow="wrap" %}

```
- TRANSACTION_TIMEOUT_EXCEEDED - превышено время обработки операции.
```

{% endcode %}

Коды ошибок, используемые для HTTP-статуса 500:

{% code title="HTTP 500" overflow="wrap" %}

```
- INTERNAL_ERROR - внутренняя ошибка сервера.
```

{% endcode %}

## 2. Ошибки, передаваемые в финансовых сообщениях

### 2.1. Сообщение ACMT.024 - Код причины неуспешности верификации

Коды причины неуспешности верификации, используемые в сообщении acmt.024:

<pre data-title="ACMT.024" data-overflow="wrap"><code><strong>  - 'ACMT_023_SENDING_TO_DEBTOR_ERROR' сообщение acmt.023 не доставлено в банк отправителя.
</strong>  - `ACMT_023_SENDING_TO_CREDITOR_ERROR` - сообщение acmt.023 не доставлено в банк бенефициара.
<strong> - `ACMT_024_ACCOUNT_NOT_FOUND` - информация о счете клиента не найдена.
</strong><strong> - `ACMT_024_ACCOUNT_INVALID` - некорректный номер счета.
</strong> - `ACMT_024_ACCOUNT_CLOSED` - счет закрыт. Указывает, что операция не может быть выполнена, поскольку указанный счет был закрыт.
 - `ACMT_024_ACCOUNT_BLOCKED` - счет заблокирован: средства или счет получателя заблокирован.
 - `ACMT_024_OPERATION_NOT_ALLOWED` - операция не разрешена.
 - `ACMT_024_POSSIBLE_FRAUD_DETECTED` - зафиксирована подозрительная активность (фрод).
 - `ACMT_024_UNEXPECTED_ERROR` - возникла непредвиденная ошибка.
</code></pre>

### 2.2. Сообщение PACS.002 - Код причины отклонения транзакции

Коды причины отклонения транзакции, используемые в сообщении pacs.002:

{% code title="PACS.002" overflow="wrap" %}

```
 - `PACS_004_SENDING_TO_CREDITOR_ERROR` - сообщение pacs.004 не доставлено в банк бенефициара.
 - `PACS_008_SENDING_TO_CREDITOR_ERROR` - сообщение pacs.008 не доставлено в банк бенефициара.
 - `PACS_002_SENDING_TO_CREDITOR_ERROR` - сообщение pacs.002 не доставлено в банк бенефициара.
 - `PACS_002_SENDING_TO_DEBTOR_ERROR` - сообщение pacs.002 не доставлено в банк отправителя денег.
 - `PACS_002_POSSIBLE_FRAUD_DETECTED` - зафиксирована подозрительная активность (фрод).
 - `PACS_002_INVALID_ACCOUNT_NUMBER` - неверный номер счета: указанный номер счета недействителен или ошибочен.
 - `PACS_002_LIMIT_AMOUNT_EXCEEDED` - превышение лимита: платеж превышает установленный лимит для отправителя или получателя.
 - `PACS_002_REFUND_AMOUNT_EXCEEDED` - превышена сумма, доступная для возврата.
 - `PACS_002_LIMIT_OPERATIONS_EXCEEDED` - превышен лимит операций.
 - `PACS_002_INVALID_BENEFICIARY_DTLS` - неверные реквизиты получателя: данные получателя некорректны или неполны.
 - `PACS_002_REGULATORY_COMPLIANCE` - несоответствие регулятивным требованиям: платеж не соответствует требованиям регулирующих органов.
 - `PACS_002_OPERATION_NOT_ALLOWED` - операция не разрешена.
 - `PACS_002_PARTIAL_REFUND_NOT_ALLOWED` - операция не разрешена, не разрешен частичный возврат суммы.
 - `PACS_002_NET_POSITION_LIMIT_REACHED` - превышен лимит баланса банка.
 - `PACS_002_UNEXPECTED_ERROR` - возникла непредвиденная ошибка.
 - `PACS_002_FIELD_INVALID` - указано некорректное значение параметра.
 - `PACS_002_HEADER_INVALID` - указано некорректное значение в заголовке запроса.
 - `PACS_002_HEADER_MISSING` - отсутствует обязательный заголовок запроса.
 - `PACS_002_DEBTOR_BLOCKED` - банк отправителя денег заблокирован.
 - `PACS_002_CREDITOR_BLOCKED` - банк получателя денег заблокирован.
 - `PACS_002_DEBTOR_NOT_ACTIVE` - банк отправителя денег неактивен.
 - `PACS_002_CREDITOR_NOT_ACTIVE` - банк получателя денег неактивен.
 - `PACS_002_TIMEOUT_EXCEEDED` - превышено время обработки операции: для процесса “Инициализация оплаты по QR-коду (C2B2_V2)” и для процесса “ Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR__V2)”.
 - `ACMT_023_SENDING_TO_CREDITOR_ERROR` - сообщение acmt.023 не доставлено в банк бенефициара.
 - `ACMT_024_SENDING_TO_DEBTOR_ERROR` - сообщение acmt.024 не доставлено в банк отправителя денег. 
 - `ACMT_024_ACCOUNT_NOT_FOUND` - информация о счете клиента не найдена.
 - `ACMT_024_ACCOUNT_INVALID` - некорректный номер счета.
 - `ACMT_024_ACCOUNT_CLOSED` - счет закрыт. Указывает, что операция не может быть выполнена, поскольку указанный счет был закрыт.
 - `ACMT_024_ACCOUNT_BLOCKED` - счет заблокирован: средства или счет получателя заблокирован.
 - `ACMT_024_OPERATION_NOT_ALLOWED` - операция не разрешена.
 - `ACMT_024_POSSIBLE_FRAUD_DETECTED` - зафиксирована подозрительная активность (фрод).
 - `ACMT_024_UNEXPECTED_ERROR` - возникла непредвиденная ошибка.
 - `ADMI_010_SENDING_ERROR` - сообщение admi.010 не доставлено.
 - `ADMI_009_SENDING_ERROR` - сообщение admi.009 не доставлено.
 - `ADMI_010_DATA_NOT_FOUND` - сведения не найдены.
 - `ADMI_010_UNEXPECTED_ERROR` - возникла непредвиденная ошибка.
 - `ADMI_010_OPERATION_REJECTED`- операция отменена клиентом (для процесса “Инициализация оплаты по QR-коду (C2B2_V2)”.
  - `ADMI_010_POSSIBLE_FRAUD_DETECTED`- зафиксирована подозрительная активность (фрод). (для процесса “Инициализация оплаты по QR-коду (C2B2_V2)".
 - `PAIN_013_SENDING_TO_DEBTOR_ERROR` - сообщение pain.013 не доставлено в банк 
отправителя денег.
 - `PAIN_014_REQUEST_REJECTED` – запрос отклонен.
 - `PAIN_014_SENDING_TO_CREDITOR_ERROR` - сообщение pain.014 не доставлено в банк бенефициара.
 - `PAIN_014_UNEXPECTED_ERROR` - возникла непредвиденная ошибка.

```

{% endcode %}

### 2.3. Сообщение ADMI.010 - Информация об ошибке

Коды ошибки, используемые в сообщении admi.010:

<pre data-title="ADMI.010" data-overflow="wrap"><code> - `ADMI_009_SENDING_ERROR` - сообщение admi.009 не доставлено.
<strong> - `ADMI_010_DATA_NOT_FOUND` - сведения не найдены.
</strong> - `ADMI_010_UNEXPECTED_ERROR` - возникла непредвиденная ошибка.
 - `ADMI_010_OPERATION_REJECTED`- операция отменена клиентом (для процесса “Инициализация оплаты по QR-коду (C2B2_V2)”.
  - `ADMI_010_POSSIBLE_FRAUD_DETECTED`- зафиксирована подозрительная активность (фрод). (для процесса “Инициализация оплаты по QR-коду (C2B2_V2)”.
</code></pre>

{% hint style="warning" %}
Не используется, сохранено для обратной совместимости:

* `ADMI_009_SENDING_TO_CREDITOR_ERROR` - сообщение admi.009 не доставлено в банк бенефициара.
* `ADMI_009_SENDING_TO_DEBTOR_ERROR` - сообщение admi.009 не доставлено в банк отправителя денег.
* `ADMI_010_SENDING_TO_CREDITOR_ERROR` - не используется, сохранено для обратной совместимостисообщение admi.010 не доставлено в банк бенефициара.
* `ADMI_010_SENDING_TO_CREDITOR_ERROR` - сообщение admi.010 не доставлено в банк бенефициара.
  {% endhint %}

### 2.4. Сообщение PAIN.014 - Информация об ошибке

Коды ошибки, используемые в сообщении pain.014:

<pre data-title="PAIN.014" data-overflow="wrap"><code> - `PAIN_013_SENDING_TO_DEBTOR_ERROR` - сообщение pain.013 не доставлено в банк отправителя денег.
<strong> - `PAIN_014_REQUEST_REJECTED ` - запрос отклонен.
</strong> - `PAIN_014_UNEXPECTED_ERROR ` - возникла непредвиденная ошибка.
</code></pre>


# Коды категории продавца (MCC -Merchant Category Code)

{% file src="/files/SdD7CEp0NFPl3DDd6iJQ" %}
Справочник "Коды категории продавца (MCC -Merchant Category Code)"
{% endfile %}


# Таблица изменений

В данном разделе приведены сведения о последних обновлениях спецификации Межбанковской системы переводов и платежей.

<table data-full-width="false"><thead><tr><th width="186">Дата обновления спецификации</th><th>Дата ввода в действие на тестовой среде</th><th width="175.75">Дата ввода в действие на продуктивной среде</th><th>Описание</th></tr></thead><tbody><tr><td>18.08.2026</td><td>18.08.2026</td><td>18.08.2026</td><td><ol><li>Добавлена спецификация процесса <a href="/pages/s2xJTXse11efYSNJul9H"> Возврат денег по проведенной ранее оплате за товар/услугу по инициативе продавца без участия покупателя (C2BRM_V2)</a>.</li><li>Актуализировано описание процесса <a href="/pages/929gY1OZyGKjfy2EHC0O">«Инициализация оплаты в рамках электронной коммерции».</a></li><li>Актуализировано описание процесса <a href="/pages/r65QVlRHjANqrk8vE6Ck">«Инициализация выставления счета на оплату ФЛ от ЮЛ (C2B2_RTP)»</a>.</li></ol></td></tr><tr><td>06.08.2026</td><td>12.08.2026</td><td>18.08.2026</td><td>Добавлена спецификация процесса  <a data-mention href="/pages/6EA3cacu9n5msXp6O54h">/pages/6EA3cacu9n5msXp6O54h</a>. Дополнены описания сообщений acmt.023, acmt.024, pacs.008, pacs.002 новым типом операции M2M</td></tr><tr><td>10.07.2026</td><td>10.07.2026</td><td>17.07.2026</td><td>Увеличена максимальная длина поля DEVICE_IP в сообщениях <a href="/pages/RQgUCLSrWgkRIXhvF7JJ">admi.009</a> и <a href="/pages/ybvcGbr2j9tGlSNcKOFM">admi.010 </a>до 40 символов.</td></tr><tr><td>25.06.2026</td><td>26.06.2026</td><td>02.07.2026</td><td>Добавлены <a href="/pages/GNLjZsETLk55q8e2bQPE">коды ошибок</a>, возвращаемые в сообщении <code>pacs.002</code> при их запросе посредством отправки <code>pacs.028</code>.</td></tr><tr><td>19.06.2026</td><td>19.06.2026</td><td>02.07.2026</td><td>В сообщении <a href="/pages/jZIuIXhM8Tk7MYtBXGfX">camt.053</a> добавлена передача значения MCC для юридических лиц (ЮЛ).</td></tr><tr><td>26.05.2026</td><td>26.05.2026</td><td>02.07.2026</td><td>Для дополнительных параметров в сообщениях <a href="/pages/RQgUCLSrWgkRIXhvF7JJ"><code>admi.009</code> (в рамках целевой модели <code>C2B2_V2</code>)</a> и <a href="/pages/ybvcGbr2j9tGlSNcKOFM"><code>admi.010</code> (в рамках целевой модели <code>C2B2_V2</code>) </a>убрана опциональность полей - все поля переведены в обязательные.</td></tr><tr><td>25.05.2026</td><td>22.05.2026</td><td>введено в действие</td><td>Добавлен новый код ошибки для сообщения <code>admi.010</code> в рамках целевой модели в <a href="/pages/GNLjZsETLk55q8e2bQPE#id-2.3.-soobshenie-admi.010-informaciya-ob-oshibke">справочник кодов ошибок.</a></td></tr><tr><td>12.05.2026</td><td></td><td>02.07.2026</td><td>Дополнено описание данных <a href="/pages/RQgUCLSrWgkRIXhvF7JJ">admi.009</a> и <a href="/pages/ybvcGbr2j9tGlSNcKOFM">admi.010 </a>в части обязательности полей, а также описание полей, которые не допускается передавать пустыми в рамках целевой модели</td></tr><tr><td>31.03.2026</td><td>01.04.2026</td><td>введено в действие</td><td><ol><li>Добавлен раздел <a href="/pages/oJ8MD33jXMI2WwP64CxK">«Инициализация проведения платежей (по QR-коду) в рамках целевой модели»</a>, включающий:</li></ol><ul><li><a href="/pages/qkfyFKBgJGkupKPppONp">Инициализацию оплаты по QR-коду (C2B2_V2);</a></li><li><a href="/pages/nEuMasbh2n7dGjEZkq04">Возврат денег по ранее проведенной оплате (C2BR_V2).</a></li></ul><ol start="2"><li>В разделе <a href="/pages/Mdix3pGB378hq7HtCq33">«Тайм-ауты и логика повторных запросов» </a>добавлена схема тайм-аутов <em>(«Схематичное отображение тайм-аутов»)</em> для процессов в рамках целевой модели.</li><li>В разделе <a href="/pages/GNLjZsETLk55q8e2bQPE">«Коды ошибок» </a>добавлены коды ошибок в рамках целевой модели:</li></ol><ul><li><a href="/pages/GNLjZsETLk55q8e2bQPE#id-2.2.-soobshenie-pacs.002-kod-prichiny-otkloneniya-tranzakcii">коды ошибок, используемые в сообщении pacs.002;</a></li><li><a href="/pages/GNLjZsETLk55q8e2bQPE#id-2.3.-soobshenie-admi.010-informaciya-ob-oshibke">коды ошибок, используемые в сообщении admi.010.</a></li></ul></td></tr><tr><td>20.03.2026</td><td>-</td><td>-</td><td><ol><li>Добавлено описание процессов: </li></ol><ul><li><a href="/pages/r65QVlRHjANqrk8vE6Ck">Инициализация выставления счета на оплату ФЛ от ЮЛ (C2B2_RTP)</a>;</li><li><a href="/pages/I9XOg87lRgo660zHVBFM">Возврат перевода по инициативе Отправителя (C2CR_RTP)</a>.</li></ul><ol start="2"><li>В разделе <a href="/pages/Mdix3pGB378hq7HtCq33">Тайм-ауты и логика повторных запросов</a> в «Схематичном отображении тайм-аутов» добавлена информация по процессам:</li></ol><ul><li><a href="/pages/r65QVlRHjANqrk8vE6Ck">Инициализация выставления счета на оплату ФЛ от ЮЛ (C2B2_RTP)</a>;</li><li><a href="/pages/I9XOg87lRgo660zHVBFM">Возврат перевода по инициативе Отправителя (C2CR_RTP)</a>.</li></ul><ol start="3"><li>В разделе <a href="/pages/tdt4EdH4RzyUaYYahoct">Описание структуры запросов</a> добавлено описание сообщений <a href="/pages/BnRKIj4bDQV7ryrmFwNr">pain.013</a> и <a href="/pages/RPma5PezRaauv3oGxkbM">pain.014</a>.</li><li>В разделе <a href="/pages/GNLjZsETLk55q8e2bQPE">Коды ошибок </a>добавлены:</li></ol><ul><li>Коды ошибки, используемые в сообщении <a href="/pages/GNLjZsETLk55q8e2bQPE#id-2.2.-soobshenie-pacs.002-kod-prichiny-otkloneniya-tranzakcii"><strong>pacs.002</strong></a>;</li><li>Коды ошибки, используемые в сообщении <a href="/pages/GNLjZsETLk55q8e2bQPE#id-2.4.-soobshenie-pain.014-informaciya-ob-oshibke"><strong>pain.014</strong></a>.</li></ul><ol start="5"><li>В разделе <a href="/pages/929gY1OZyGKjfy2EHC0O">«Инициализация оплаты в рамках электронной коммерции (C2B2E)» </a>дополнено описание процесса в части клиентского пути для инициации платежей через сайт или мобильное приложение.</li><li>В процессе <a href="/pages/Vxm5w0MiYI1EoygLT54K">«Инициализация перевода денег другому ФЛ (C2C2)»</a> при передаче результата верификации бенефициаром ранее использовавшийся формат «Имя Ф.» заменен на полное ФИО. <em>*Отображение в МП сохраняется в формате «Имя Ф.».</em> </li><li>Внесены уточняющие редакционные изменения в сообщения <a href="/pages/26eRE2YOC5qD4WdZCpBW">acmt.023</a>, <a href="/pages/87KGVyosqccw2XOAQWrv">acmt.024</a>, <a href="/pages/FZur7kyssQaU74M4JHu1">pacs.004</a>, <a href="/pages/Ki1jnDn9PLAWFmfikHvS">pacs.008</a> в части описания полей SchmeNm.Cd и SchmeNm.Prtry.</li></ol></td></tr><tr><td>03.02.2026</td><td>04.02.2026</td><td>введено в действие</td><td><ol><li>В разделе <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/vozvraty">Возвраты </a>добавлено описание процесса <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/vozvraty/vozvrat-deneg-po-provedennoi-ranee-oplate-za-tovar-uslugu-v-ramkakh-elektronnoi-kommercii-c2bre">«Возврат денег по проведенной ранее оплате за товар/ услугу в рамках электронной коммерции (C2BRE)»</a>. </li><li>В разделе <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/inicializaciya-perevodov-denezhnykh-sredstv">Инициализация переводов денежных средств </a>добавлены описания процессов: </li></ol><ul><li><a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/inicializaciya-perevodov-denezhnykh-sredstv/inicializaciya-perevoda-deneg-ot-yul-na-schet-fl-b2c2u">«Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2U)»</a>;</li><li><a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/inicializaciya-perevodov-denezhnykh-sredstv/inicializaciya-perevoda-deneg-ot-yul-na-schet-fl-b2c2i-s-provedeniem-identifikacii-beneficiara">«Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2I) с проведением идентификации бенефициара»</a>.</li></ul><ol start="3"><li>В разделе <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/opisanie-struktury-zaprosov">Описание структуры запросов </a>добавлено описание дополнительных полей в сообщениях <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/opisanie-struktury-zaprosov/formaty-soobshenii/soobshenie-admi.009-dlya-celevoi-modeli-c2b2_v2">admi/.009</a> и <a href="https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/opisanie-struktury-zaprosov/formaty-soobshenii/soobshenie-admi.010-dlya-celevoi-modeli-c2b2_v2">admi.010</a> в рамках целевой модели C2B2_V2.</li></ol></td></tr><tr><td>15.09.2025</td><td>16.09.2025</td><td>22.09.2025</td><td><ul><li>В <code>pacs.028</code> тег<code>fiToFIPmtStsReq.txInf.orgnlTxId</code> сделан условно обязательным (был обязательным): если сообщение отправляется до <code>pacs.008/004</code> то тег необязательный к заполнению, иначе - обязательный.</li><li>В <code>pacs.002</code> тег<code>fiToFIPmtStsRpt.txInfAndSts.orgnlTxId</code> сделан условно обязательным (был обязательным): в ответе Платформы тег может отсутствовать, если сообщение отправлено в ответ на <code>pacs.028</code> до <code>pacs.008/004</code>.</li><li>В методе API  <code>"Сервис получения информации о банках участниках" (GET /v1/banks)</code> добавлено поле <code>features</code> со списком доступных услуг в системе  (переводы, платежи, возвраты и т.д.).</li><li>Добавлен метод API <code>GET /v1/banks-logos</code> для получения логотипов банков.</li></ul></td></tr><tr><td>27.08.2025</td><td>02.09.2025</td><td>23.09.2025</td><td><p>Внедрена поддержка QR-кодов с длиной идентификатора до 50 символов: </p><ul><li><p>в сообщении admi.009:</p><ul><li>для ключа QR_ID (в теге StatcDataReq->SplmtryData) - увеличивается размерность значения до 50 символов, новый шаблон: [0-9A-Za-z_=-]{8,50} </li></ul></li><li><p>в сообщении admi.010:</p><ul><li>в теге StatcDataRpt->RptDtls->RptKey->Key - должна передаваться фиксированная константа "QR";</li><li>в теге StatcDataRpt->RptDtls->RptKey->RptData добавляется ключ QR_ID, в качестве значения, для которого должен передаваться идентификатора QR-кода, шаблон: [0-9A-Za-z_=-]{8,50}</li></ul></li></ul></td></tr><tr><td>23.07.2025</td><td>30.07.2025</td><td>введено в действие</td><td><ul><li><p>В сообщение camt.053  (см. <a data-mention href="/pages/jZIuIXhM8Tk7MYtBXGfX">/pages/jZIuIXhM8Tk7MYtBXGfX</a>) в теге Refs (BkToCstmrStmt->Stmt->Ntry->NtryDtls->TxDtls->Refs) добавлены вложенные теги:</p><ul><li>EndToEndId - сквозной идентификатор операции;</li><li>TxId - идентификатор транзакции</li></ul></li></ul></td></tr><tr><td>04.04.2025</td><td>10.04.2025</td><td>введено в действие</td><td><ul><li>Внесены изменения в параметры тайм-аутов в разделе <a data-mention href="/pages/Mdix3pGB378hq7HtCq33">/pages/Mdix3pGB378hq7HtCq33</a></li></ul></td></tr><tr><td>01.04.2025</td><td>05.04.2025</td><td>введено в действие</td><td><ul><li>В описании структуры сообщения добавлено уточнение по обязательному использованию префикса пространства имен (см. <a data-mention href="/pages/tdt4EdH4RzyUaYYahoct">/pages/tdt4EdH4RzyUaYYahoct</a>)</li><li>Изменена структура элемента &#x3C;Envlp> в сообщениях acmt.023, acmt.024, admi.009 - добавлен вложенный элемент EnvlpValue для передачи значения</li><li><p>В сообщениях, сформированных Платформой, будет передаваться в качестве идентификатора Платформы значение - 00000000-0000-0000-0000-000000000000 (идентификатор Платформы используется, когда отправка сообщения инициирована непосредственно Платформой (например, когда не удалось доставить acmt.023 до банка бенефициара, банку отправителю будет направлен acmt.024 с информацией о возникшей ошибке и в качестве отправителя будет Платформа с идентификатором 00000000-0000-0000-0000-000000000000, при отправке финального pacs.002 со статусом ACSC и т.д.)):</p><ul><li>В acmt.024 в теге IdVrfctnRpt -> Assgnmt -> Assgnr -> Agt -> FinInstnId -> Nm</li><li>В admi.010 в теге StatcDataRpt -> RptDtls -> RptKey -> RptData (ключ: SENDER_PROVIDER_ID) -> Val</li><li>В pacs.002 в теге FIToFIPmtStsRpt -> GrpHdr -> InstgAgt -> FinInstnId -> Nm</li></ul></li></ul></td></tr><tr><td>28.02.2025</td><td>17.03.2025</td><td>введено в действие</td><td><ul><li><p>Следующие коды ошибок останутся для обратной совместимости, но больше не будут использоваться и отмечены как устаревшие:</p><ul><li>ADMI_009_SENDING_TO_CREDITOR_ERROR </li><li>ADMI_009_SENDING_TO_DEBTOR_ERROR </li><li>ADMI_010_SENDING_TO_CREDITOR_ERROR </li><li>ADMI_010_SENDING_TO_DEBTOR_ERROR DEBTOR_NOT_FOUND </li><li>CREDITOR_NOT_FOUND</li></ul></li><li><p>Добавлены новые коды ошибок:</p><ul><li>BANK_NOT_FOUND ADMI_009_SENDING_ERROR </li><li>ADMI_010_SENDING_ERROR</li></ul></li><li>Актуализирован список ошибок для pacs.002</li><li>В ответе на запрос GET /v1/banks добавлено поле <code>qrUrl</code> (домен банка для QR-кода)</li></ul></td></tr><tr><td>21.02.2025</td><td>17.03.2025</td><td>введено в действие</td><td><ul><li>В разделе <a data-mention href="/pages/ZL8xpXIOxuLDnXDp5jc2">/pages/ZL8xpXIOxuLDnXDp5jc2</a>обновлено описание структуры данных в QR-коде</li><li>В разделе <a data-mention href="/pages/9cvVgxGH4pt9FfWV449g">/pages/9cvVgxGH4pt9FfWV449g</a>обновлена схема взаимодействия: добавлена отправка сообщения admi.010 с данными по QR-коду</li><li><p>Обновлена структура сообщения admi.009:</p><ul><li>поле QR_GENERATOR_ORGANIZATION_ID заменено на RECEIVER_PROVIDER_ID</li><li>поле IIN_TO_REFUND заменено на  IIN</li><li>исключены поля QR_DATA_TYPE, SHA1_FIRST4_CHARS</li></ul></li><li>В описании сообщения admi.010 добавлено уточнение по обязательным полям при успешном ответе при QR_DATA_TYPE=001, 002</li><li>В сообщение pacs.002 добавлено опциональное поле OrgnlTxRef (которое заполняется Платформой), содержащее тип операции, к которой относится сообщение</li></ul></td></tr><tr><td>29.01.2025</td><td>17.03.2025</td><td>введено в действие</td><td><ul><li>В cообщение camt.053 добавлено поле &#x3C;Chrgs> (см. <a data-mention href="/pages/jZIuIXhM8Tk7MYtBXGfX">/pages/jZIuIXhM8Tk7MYtBXGfX</a>)</li><li>В cообщение pacs.002 добавлено поле &#x3C;ChrgsInf> (см. <a data-mention href="/pages/jLq1MtlTdi4ZCSKrga5M">/pages/jLq1MtlTdi4ZCSKrga5M</a>)</li></ul></td></tr></tbody></table>


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

Open Banking - сервис АО «НПК», обеспечивающий безопасный обмен финансовыми данными клиентов между участниками платформы исключительно с согласия самого клиента.

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

#### Роли участников

В системе Open Banking участник может выступать в одной из двух ролей — или в обеих одновременно.

**Пользователь API** - организация, которая запрашивает данные о счетах клиента с его согласия. Клиент проходит биометрическую верификацию через сервисы [ЦОИД](https://docs.npck.kz/servisy-coid) и подтверждает доступ к своим данным. После этого Пользователь API получает токен доступа и может запрашивать данные счетов.

**Поставщик API** — банк или организация, которая раскрывает данные о счетах своих клиентов через платформу НПК по запросу Пользователя API. Поставщик API реализует и публикует API в соответствии с технической спецификацией АО «НПК», обрабатывает входящие запросы и несёт ответственность за корректность и актуальность возвращаемых данных.

{% hint style="warning" %}
**Требуется регистрация согласия в СУС**

Для услуги `OB_SERVICE` обязательный состав согласия: `CT_01`, `CT_02`, `CT_04` (банковская тайна). Согласие формирует ЦОИД в рамках протоколов Open API - передайте `serviceCode = OB_SERVICE`, `consentExpiresAt`, `dataRetentionPeriod` при инициации запроса.

[Подробнее: Сервис управления согласиями (СУС)](/servisy-coid/servis-upravleniya-soglasiyami-sus)
{% endhint %}


# Получение информации о банковских счетах клиента (пилотный проект)

Общий процесс получения информации о банковском счете клиента включает в себя следующие основные шаги:

1. Инициирование получения информации о банковском счете Клиентом (конечным пользователем) в приложении Пользователя API – Клиент (конечный пользователь) инициирует в приложении Пользователя API получение информации о его банковских счетах. Доступ к данным клиента может быть предоставлен только с его согласия и в рамках оказываемых ему услуг Пользователем API.
2. Аутентификация и регистрация согласия клиента на доступ к его данным – Клиент (конечный пользователь) должен дать согласие на доступ у его данным, поле чего Пользователь API получает токен доступа, используя который может получить сведения о банковском счете клиента.
3. Получение информации о банковском счете Пользователем API – для получения информации о банковском счете используется полученный токен доступа.&#x20;


# Рекомендации для мобильного приложения

Разработка дизайна мобильного приложения требует тщательного подхода, чтобы обеспечить интуитивно понятный и привлекательный интерфейс для пользователей.&#x20;

> В этом разделе представлены рекомендации, которые помогут дизайнерам создать удобный и эстетически приятный пользовательский опыт.&#x20;
>
> Эти советы охватывают все ключевые аспекты дизайна, включая визуальную структуру, навигацию, взаимодействие с пользователем.

{% file src="/files/FJBXedyPl4Lq4uhZOpC1" %}
Рекомендации для процессов получения данных по банковским счетам
{% endfile %}


# Рекомендации по реализации интеграции для Пользователя API

{% hint style="info" %}
Необходимо, чтобы Пользователь API:

1\.  Прошел процедуру регистрации на Портале АО «НПК» (см. подробнее в [3. Регистрация и авторизация в Портале НПК](/registraciya-i-avtorizaciya/3.-registraciya-i-avtorizaciya-v-portale-npk))

2\. Подал заявку на подключение к Open Banking в качестве Пользователя API (см. подробнее в [5.2 Подключение к Open Banking/Open API](/registraciya-i-avtorizaciya/5.-podacha-zayavki-na-podklyuchenie-k-servisam/5.2-podklyuchenie-k-open-banking-open-api))

3\. Зарегистрировал приложение Участника (см. подробнее в [6. Добавление и использование приложения](/registraciya-i-avtorizaciya/6.-dobavlenie-i-ispolzovanie-prilozheniya))
{% endhint %}

## Общее описание процесса:

{% hint style="info" %}
Пользователю API  необходимо выполнить доработку программного обеспечения:

* Реализовать перенаправление Клиента для прохождения аутентификации и регистрации его согласия на доступ к данным, реализовать получение кода авторизации.
* Реализовать получение токена доступа.
* Реализовать получение данных посредством интерфейсов API. Для получения информации посредством интерфейсов API используется полученный токен доступа.
* Реализовать отображение клиенту полученной информации в приложении Пользователя API.
  {% endhint %}

<figure><img src="/files/PVg8COrcyWCyPfbMNo5A" alt=""><figcaption><p>Общая схема процесса получения сведений о банковском счете клиента</p></figcaption></figure>

1. Клиент инициирует в приложении Пользователя API получение информации о его банковских счетах.

> Если клиент уже дал согласие на доступ к его счетам для приложения Пользователя API и токен доступа не истек, то выполняется переход к шагу 7.
>
> Если клиент еще не дал согласие на доступ к его счетам для приложения Пользователя API, необходимо изменить список банков, на доступ к счетам в которых предоставляется согласие, или истек токен доступа, то выполняется переход к шагу 2.

2. Для предоставления согласия на доступ к данным приложение Пользователя API перенаправляет клиента на Платформу.

<figure><img src="/files/j7ugF6NpcQapcpUITiVP" alt=""><figcaption><p>Общая диаграмма взаимодействия</p></figcaption></figure>

{% hint style="warning" %}
Если в ОС Android при проведении liveness-сессии не отображается изображение клиента (см. пример на рисунке ниже), то потенциальным решением проблемы может являться применение следующих параметров:

*webView\.settings.allowContentAccess = true; webView\.settings.mediaPlaybackRequiresUserGesture = false; webView\.settings.domStorageEnabled = true*

WebKit в Android, позволяет видео компонентам запускаться только по действию пользователя, при этом для корректной работы сервисов ЦОИД камера запускается программными средствами (autoplay), WebKit блокирует данное действие и выдает ошибку. Чтобы избежать этого, необходимо в компоненте webView указать данную настройку.
{% endhint %}

<figure><img src="/files/oLiWIMREOpKd8CbybRhA" alt="" width="143"><figcaption><p>Пример отсутствия доступа к контенту для WebView</p></figcaption></figure>

{% hint style="warning" %}
В IOS необходимо использовать SafariWebView. WKWebView не поддерживается.
{% endhint %}

<details>

<summary> Перенаправления клиента для прохождения аутентификации</summary>

Для перенаправления клиента для прохождения аутентификации необходимо:

1\) Реализовать получение URL-адреса для перенаправления клиента. Описание метода «Получить URL-адрес для перенаправления клиента» (POST /v1/auth/generate-user-url) приведено в <https://auth-openapi.npck.kz/#tag/Auth/operation/generateUserUrl>.

&#x20;

*Примечание: Метод получения URL-адрес для перенаправления клиента POST /oauth2/generate-user-url (см.* [*https://auth-openapi.npck.kz/#tag/Auth/operation/generateUserUrlDeprecated*](https://auth-openapi.npck.kz/#tag/Auth/operation/generateUserUrlDeprecated)*) является устаревшим, рекомендуется перейти на использование метода POST /v1/auth/generate-user-url (см.* [*https://auth-openapi.npck.kz/#tag/Auth/operation/generateUserUrl*](https://auth-openapi.npck.kz/#tag/Auth/operation/generateUserUrl)*).*

2\) Реализовать перенаправление пользователя на полученный URL-адрес.

</details>

{% hint style="info" %}
То к каким данным клиента запрашивается доступ определяется значениями, указанными в параметре scopes (могут быть указаны несколько значений) при запросе URL-адреса для перенаправления клиента:

* accounts - доступ к списку счетов клиента&#x20;
* account\_balance - доступ к информации о балансе счета
* account\_transactions - доступ к списку транзакций счета
  {% endhint %}

{% hint style="warning" %}
Время действия URL-адреса для перенаправления (время «жизни») составляет 15 минут
{% endhint %}

3. Клиенту отображается форма аутентификации. Клиент проходит двухфакторную аутентификацию личности.&#x20;
4. Клиент должен дать согласие на доступ к его данным для приложения Пользователя API.

{% hint style="info" %}
Клиент может отклонить согласие на доступ к его данным.&#x20;

Если клиент отклоняет согласие на доступ к его данным или происходит  ошибка, то клиент будет перенаправлен на указанный на шаге 2 **redirectUri**, с указанием кода ошибки, по следующему шаблону:

`[redirectUri]?errorCode=[error code]&state=[state]`

В таком случае процесс завершается, код авторизации не предоставляется.&#x20;
{% endhint %}

5. После того, как клиент выполнит все действия по предоставлению согласия на доступ к его данным, осуществляется его возврат в приложение Пользователя API.

{% hint style="info" %}
Если аутентификация клиента проходит успешно и он дает согласие на доступ к его данным, то клиент перенаправляется обратно в приложение Пользователя API (на указанный в запросе *redirectUri*) с одноразовым кодом авторизации (code), по следующему шаблону:

`[redirectUri]?code=[authorization code]&state=[state]`
{% endhint %}

{% hint style="warning" %}
Код авторизации является одноразовым.&#x20;

Время действия кода авторизации (время «жизни») составляет 300 секунд
{% endhint %}

{% hint style="warning" %}
Редирект из webview в случае SafariWebView нужно перехватывать через диплинк (deeplink)
{% endhint %}

6. Приложение Пользователя API получает токен доступа, используя полученный на предыдущем шаге код авторизации.

<details>

<summary>Получение токена доступа</summary>

Для получения токена доступа необходимо:

1\) Реализовать формирование запроса получения токена доступа, используя полученный код авторизации. Описание используемого для этого метода приведено в <https://auth-openapi.npck.kz/#tag/Auth/operation/getOauthToken>.&#x20;

{% hint style="info" %}
Срок действия `access_token` зависит от того, какие данные запрашиваются (scope):

* Для получения информации о счетах клиента (`accounts`, `account_balance`, `account_transactions`) — **30 дней**.
* Для аутентификации клиента через FinID (`openid`, `iin`, `first_name` и т.д.) — **12 часов**.
* Для работы с облачной ЭЦП (`esign`, `organization_esign`) — **5 минут**.
  {% endhint %}

2\) Реализовать отправку сформированного запроса и получение токена доступа.

Токен доступа имеет формате JWT (см. RFC 7519). Токен доступа может использоваться для получения сведений о счете клиента посредством API, в течении срока его действия, после истечения срока действия необходимо получить новый токен доступа.

*Примечание: Дополнительно доступен метод получения списка публичных ключей для проверки токена (см.* [*https://auth-openapi.npck.kz/#tag/Auth/operation/wellKnown*](https://auth-openapi.npck.kz/#tag/Auth/operation/wellKnown)*).*

*Дополнительно доступен опциональный метод интроспекции токена (см описание* [*https://auth-openapi.npck.kz/#tag/Auth/operation/oauth2Introspect*](https://auth-openapi.npck.kz/#tag/Auth/operation/oauth2Introspect)*). Данный метод используется для проверки того, активен или истек ли конкретный токен, а также для получения связанных с токеном метаданных.*

</details>

{% hint style="warning" %}
Важно! Токен доступа должен сохраняться в тайне и не передаваться в публичный доступ, должен храниться на серверной стороне приложения, и вся обработка, связанная с ним, должна производиться на серверной стороне приложения.
{% endhint %}

7. Приложение Пользователя API получает информацию о счетах клиента посредством интерфейсов API используется токен доступа, полученный на предыдущем шаге. Перечень методов API для получения информации о банковском счете клиента, описание форматов запросов и ответов приведены в <https://accounts-openapi.npck.kz/>.

{% hint style="info" %}
*API v2 является устаревшим, рекомендуется перейти на использование API v3*
{% endhint %}

7. Приложение Пользователя API отображает клиенту полученную информацию о его счетах (см. рекомендации [Рекомендации для мобильного приложения](/open-banking/poluchenie-informacii-o-bankovskikh-schetakh-klienta-pilotnyi-proekt/rekomendacii-dlya-mobilnogo-prilozheniya)).


# Рекомендации по реализации интеграции для Поставщика API

{% hint style="info" %}
Необходимо, чтобы Поставщик API:

1\.  Прошел процедуру регистрации на Портале АО «НПК» (см. подробнее в [3. Регистрация и авторизация в Портале НПК](/registraciya-i-avtorizaciya/3.-registraciya-i-avtorizaciya-v-portale-npk))

2\. Подал заявку на подключение к Open Banking  в качестве Поставщика API (см. подробнее в [Подключение к Open Banking/Open API](/registraciya-i-avtorizaciya/5.-podacha-zayavki-na-podklyuchenie-k-servisam/5.2-podklyuchenie-k-open-banking-open-api))
{% endhint %}

<figure><img src="/files/sAJZYh9HlNmxnib2agqF" alt=""><figcaption><p>Общая схема процесса получения сведений о банковском счете клиента</p></figcaption></figure>

1. Поставщику API необходимо выполнить доработку программного обеспечения:
   * Реализовать получение идентификаторов Платформы.

<details>

<summary>Получение идентификаторов Платформы</summary>

Для процессов информационного взаимодействия по получению информации о текущем счете клиента для идентификации счета используется идентификатор, сгенерированный Платформой (Идентификатор Платформы).

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

Описание прикладного программного интерфейса для получения идентификатора Платформы приведено в <https://obid-openapi.npck.kz/#tag/OBID/operation/getOBIDsByIBANs>.

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

1. Поставщик API, получив запрос предоставления списка текущих счетов клиента, проверяет для всех ли открытых текущих счетов клиента имеется идентификатор Платформы.
2. Поставщик API для открытых текущих счетов клиента, по которым ранее не был получен идентификатор Платформы, запрашивает на Платформе идентификаторы (accountId).
3. Поставщик API, получив идентификаторы Платформы, сохраняет их и информацию о том, каким счетам клиента (каким IBAN) они соответствуют.
4. Поставщик API в ответе на запрос предоставления списка текущих счетов в качестве идентификатора счета передает идентификатор Платформы (accountId).
5. Поставщик API при последующем получении запроса предоставления информации по идентификатору Платформы (например, баланса счета) при его обработке использует сопоставление идентификатора Платформы (accountId) с номером банковского счета клиента (IBAN).

</details>

* Выполнить разработку программных интерфейсов взаимодействия (API). Перечень методов API для предоставления информации о банковском счете клиента, описание форматов запросов и ответов приведены в <https://accounts-openapi.npck.kz/>

{% hint style="info" %}
*API v2 является устаревшим, необходимо реализовать API v3*
{% endhint %}

{% hint style="info" %}
Поставщик API предоставляет информацию о счетах только в случае успешной валидации запроса, в том числе:

* Платформа выполняет валидацию токена при маршрутизации сообщений, вместе с тем, для повышения безопасности рекомендуется выполнять проверку валидности токена также на стороне Поставщика API.

Сервер авторизации (Платформы) предоставляет возможность получения сведений из набора опубликованных ключей (JSON Web Key Set) в котором, содержится ключ проверки подписи сервера авторизации. Общие требования к структурам JWK и JWK Set приведены в RFC 7517 (<https://datatracker.ietf.org/doc/html/rfc7517>). Дополнительно доступен метод получения списка публичных ключей для проверки токена (см. <https://auth-openapi.npck.kz/#tag/Auth/operation/wellKnown>).

* должен проверять, что область действия (параметр \<scope>), связанная с предъявленным токеном доступа, соответствует запрошенному доступу;
* должен возвращать только ресурс, соответствующий объекту, явно указанному в запросе на доступ, и при условии, что доступ к этому ресурсу является допустимым с учетом разрешенной области действия (параметр \<scope>).
  {% endhint %}

2. Поставщик API должен войти в личный кабинет и опубликовать разработанные API (активировать соответствующие услуги, чтобы Пользователи API имели возможность к ним подключаться) на Платформе (см. [1.6 Публикация API](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei/1.6-publikaciya-api)).


# Настройка API

Доступно после подключения к Open Banking/Open API или ЦОИД

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

<figure><img src="/files/lorVoSIwYUp78nb7Xqlq" alt=""><figcaption><p>Главная страница Портала НПК</p></figcaption></figure>

Для настройки API авторизованному пользователю, подключившемуся к Open Banking необходимо перейти в раздел <Услуги>, во вкладку <Мои API>, кнопка <Настройки API>.

<figure><img src="/files/Zurer2fsktWudGSNpg3u" alt=""><figcaption><p>Мои API</p></figcaption></figure>

Для того, чтобы заполнить информацию об API необходимо заполнить данные:

<figure><img src="/files/7A2qDcAtYJQrtmJw1nlt" alt=""><figcaption><p>Данные для песочницы</p></figcaption></figure>

{% hint style="info" %}
Срок действия токена — **1 год.**
{% endhint %}

Ввести URL-адрес, по которому будут доступны публикуемые API.

<figure><img src="/files/DKGTTuG0YMC0DXjlbVx9" alt=""><figcaption><p>Основная информация о поставщике</p></figcaption></figure>

Затем заполнить основную информацию о поставщике, после чего необходимо нажать на кнопку <Перейти к публикации API>.

{% hint style="info" %}
Для взаимодействия с Межбанковской системой переводов и платежей необходимо при настройке API импортировать публичную часть ключа  (как получить - см подраздел[ ](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei/1.2-provedenie-rabot-po-poluchennomu-klyuchu)[1.2 Проведение работ по полученному ключу](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei/1.2-provedenie-rabot-po-poluchennomu-klyuchu)).
{% endhint %}

В данной вкладке отображается токен доступа, который используется для доступа к служебным сервисам Open API.

Если необходимо перегенерировать токен доступа (JWT), то необходимо нажать кнопку <Сгенерировать новый токен> - новый токен будет сохранен автоматический (без необходимости нажатия кнопки <Сохранить>)

{% hint style="warning" %}
**Токен доступа (JWT) должен сохраняться в тайне и не передаваться в публичный доступ, должен храниться на серверной стороне приложения, и вся обработка, связанная с ним, должна производиться на серверной стороне приложения.**
{% endhint %}


# Публикация API

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

Участники разрабатывают свои API (согласно опубликованных технических спецификации) и публикуют их на Платформе для взаимодействия с другими Участниками.&#x20;

{% hint style="info" %}
Тестовый стенд опубликован в сети Интернет. Перед публикацией API необходимо предоставить в АО <НПК> URL-адрес API, чтобы к нему был организован доступ.
{% endhint %}

После публикации API становится доступным для вызова другим Участникам. При этом, Платформа обеспечивает маршрутизацию запросов между Участниками.

Для публикации API необходимо перейти в раздел <Услуги> и во вкладке Услуги выбрать сервисы, которые были реализованы и планируется опубликовать (см. список [услуг](/testovoe-okruzhenie-msmp/1.-nastroika-podklyucheniya-k-mezhbankovskoi-sisteme-mobilnykh-platezhei/1.6-publikaciya-api/dostupnye-k-podklyucheniyu-api))  и нажать на кнопку <Активировать услугу>.

{% hint style="danger" %}
Сервисы по получению данных *по банковским счетам* и *по переводам и платежам* имеют разный маршрут после нажатия на кнопку <Активировать услугу>.
{% endhint %}

### Сервисы по получению данных по банковским счетам

<figure><img src="/files/hdV8aFS4RDyX6lT4YOC8" alt=""><figcaption><p>Активация/Публикация услуги</p></figcaption></figure>

{% hint style="info" %}
После нажатия на кнопку <Активировать услугу> в *сервисах **по получению данных по банковским счетам осуществляется переход на вкладку <Мои API>**, где в Песочнице пользователь может самостоятельно запустить проверку API нажав на кнопку*[ *<Запустить проверку>*](/open-banking/poluchenie-informacii-o-bankovskikh-schetakh-klienta-pilotnyi-proekt/rekomendacii-po-realizacii-integracii-dlya-postavshika-api/testirovanie-polucheniya-informacii-o-schetakh-klienta)*.*&#x20;
{% endhint %}


# Тестирование получения информации о счетах  клиента

Пользователь самостоятельно в Песочнице может запустить проверку API нажав на кнопку <Запустить проверку>.

<figure><img src="/files/2Px9ux1oqmtwZ70lhNZ3" alt=""><figcaption><p>Запуск проверки API</p></figcaption></figure>

После запуска проверок Система отображает уведомление с результатом авто-тестов. Если были выявлены ошибки, то пользователь будет уведомлен о них в информации об ошибке и может их исправить согласно [технической документации](/open-banking/poluchenie-informacii-o-bankovskikh-schetakh-klienta-pilotnyi-proekt).

<figure><img src="/files/TzefRuj4gKRZL7RSjtpt" alt=""><figcaption><p>Просмотр ошибок</p></figcaption></figure>

Кнопка <Опубликовать> - справа от кнопки <Запустить проверку> доступна после успешных проверок по данному API.


# Сервис получения статуса API участников

Платформа непрерывно осуществляет мониторинг доступности опубликованных на ней API участников.\
\
Для получения списка активных API участников предназначен служебный метод Платформы GET /v1/status/providers (см. описание в <https://status-openapi.npck.kz/>).

{% hint style="info" %}
Данный метод предоставляет информацию по API участников и их текущем статусе: доступен или недоступен.
{% endhint %}

Статус доступности предоставляется по каждому API участника.


# Интеграция ЦРТР с OpenBanking

### Назначение и цель

**ЦРТР** (Центр развития трудовых ресурсов) использует OpenBanking в рамках пилотного проекта по апробированию механизма назначения **адресной социальной помощи (АСП)**.

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

Для определения права на получение АСП Министерство труда и социальной защиты населения РК (МТСЗН РК) использует данные о банковских счетах, остатках и движении денег по ним, получаемые от банков второго уровня (БВУ) через OpenBanking.

**Расчёт права на АСП:**

| Условие                                                 | Решение            |
| ------------------------------------------------------- | ------------------ |
| Среднедушевой доход семьи < Черты бедности (36 196 тг.) | АСП назначается    |
| Среднедушевой доход семьи ≥ Черты бедности              | АСП не назначается |
| Среднедушевой расход семьи ≥ Черты бедности             | АСП не назначается |

> **Справочно:** Черта бедности (ЧБ) = 35% от регионального медианного дохода, но не ниже 70% от регионального прожиточного минимума.

Таким образом, ЦРТР запрашивает через OpenBanking данные по счетам заявителя и членов его семьи с их явного согласия, передаёт их в МТСЗН РК для расчёта среднедушевого дохода и принятия решения о назначении АСП.

***

### Термины и определения

| Термин               | Определение                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **АО «НПК»**         | АО «Национальная платёжная корпорация Национального Банка Республики Казахстан»                                                                                                                                                                                                                                                                                                                                                                                                            |
| **Инициатор**        | Физическое лицо, претендующее на получение адресной социальной помощи от государства                                                                                                                                                                                                                                                                                                                                                                                                       |
| **Члены семьи**      | Совместно проживающие члены семьи, связанные имущественными и личными неимущественными правами и обязанностями, вытекающими из брака (супружества), родства, свойства, усыновления (удочерения) или иной формы принятия детей на воспитание, а также совместно проживающие лица, фактически сожительствующие, но не состоящие в браке. За исключением лиц: 1) на полном государственном обеспечении; 2) на срочной воинской службе; 3) в местах лишения свободы, на принудительном лечении |
| **ГБД ФЛ**           | Государственная база данных «Физические лица»                                                                                                                                                                                                                                                                                                                                                                                                                                              |
| **ИС**               | Информационная система                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
| **Система Open API** | Информационная система, состоящая из программных и аппаратных средств, предназначенных для технологического и безопасного взаимодействия по передаче информации, относящейся к банковской тайне                                                                                                                                                                                                                                                                                            |
| **АСП**              | Адресная социальная помощь - государственная выплата в денежной форме физическим лицам с месячным среднедушевым доходом ниже черты бедности                                                                                                                                                                                                                                                                                                                                                |
| **БВУ**              | Банки второго уровня - банки-поставщики данных по счетам через OpenBanking                                                                                                                                                                                                                                                                                                                                                                                                                 |
| **МТСЗН РК**         | Министерство труда и социальной защиты населения Республики Казахстан                                                                                                                                                                                                                                                                                                                                                                                                                      |
| **ЦРТР**             | Центр развития трудовых ресурсов                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
| **ШЭП**              | Шлюз электронного правительства                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| **СОД**              | Сервис обмена данными - шлюз между ЦОИД и ШЭП                                                                                                                                                                                                                                                                                                                                                                                                                                              |

***

### Технические особенности

ЦРТР - сервис, расположенный в контуре ШЭП. В отличие от стандартных Клиентов API, ЦРТР имеет два архитектурных ограничения:

* **Отсутствие публичного URL** - сервис не способен принять редирект с `authorization_code` из сети интернет
* **Отсутствие прямого доступа к ЦОИД** - все запросы маршрутизируются исключительно через ШЭП → СОД

Для подобных клиентов в AUTH предусмотрен механизм **auto-exchange**: `clientId` ЦРТР регистрируется в конфигурации AUTH в списке `auto-exchange.clientIds`.

> **Важно:** Отличие от стандартного флоу затрагивает только два этапа: (а) доставка URL осуществляется посредством SMS, а не прямым перенаправлением в приложении; (б) токен извлекается через поллинг из AUTH, а не передаётся с callback-редиректом. Прочие этапы - идентификация, предоставление согласия, взаимодействие с поставщиками - выполняются по стандартной процедуре.

***

### Роль СОД в данном флоу

СОД опубликован на ШЭП в двух ролях одновременно:

| Роль       | Описание                                                                                        |
| ---------- | ----------------------------------------------------------------------------------------------- |
| **Клиент** | Направляет запросы в ШЭП - в частности, запрашивает данные пользователя из ГБД ФЛ               |
| **Сервис** | Принимает входящие запросы из ШЭП и проксирует их через открытый интернет на публичные API ЦОИД |

Двусторонняя роль СОД обеспечивает возможность взаимодействия ЦРТР, функционирующего исключительно в контуре ШЭП, с публичными API ЦОИД:

```
ЦРТР → ШЭП → СОД → публичные API ЦОИД
```

***

### Диаграмма последовательности

```mermaid
---
config:
  theme: neo
  look: neo
---
%% Особый флоу для ЦРТР (через ШЭП и СОД)
sequenceDiagram
    autonumber
    participant CRTR as ЦРТР
    participant SHEP as ШЭП
    participant SOD as СОД
    participant CL as Пользователь
    participant C as COID
    participant A as AUTH
    participant O as OAUTH
    participant GW as API Gateway
    participant B as Поставщик API

    Note over CRTR, B: 1. Запрос OAuth-URL через ШЭП

    CRTR->>SHEP: запрос generate-user-url<br/>clientId + secret, iin, scopes
    SHEP->>SOD: проксирование
    SOD->>C: POST /v1/auth/generate-user-url
    C-->>SOD: URL на AUTH
    SOD-->>SHEP: URL
    SHEP-->>CRTR: URL

    Note over CRTR, B: 2. Доставка URL по SMS

    CRTR->>CL: SMS со ссылкой на AUTH

    Note over CRTR, B: 3. Идентификация и согласие (как обычно)

    CL->>A: переход по ссылке из SMS
    Note over A: Liveness + Facematch<br/>SMS-OTP
    A->>O: переход на выдачу кода
    O->>CL: экран согласия
    CL-->>O: подтверждение

    Note over CRTR, B: 4. Auto-exchange в AUTH (вместо редиректа)

    O->>O: генерация authorization_code
    A->>O: обмен code на токен<br/>(auto-exchange)
    O-->>A: JWT access-token
    A->>A: сохранить токен в сессии

    Note over CRTR, B: 5. Поллинг токена ЦРТР

    loop Пока токен не готов
        CRTR->>SHEP: запрос токена по sessionId
        SHEP->>SOD: проксирование
        SOD->>A: GET токена
        A-->>SOD: токен (или not ready)
        SOD-->>SHEP: ответ
        SHEP-->>CRTR: ответ
    end

    Note over CRTR, B: 6. Запрос данных по счетам через ШЭП

    CRTR->>SHEP: GET /v3/accounts<br/>Bearer JWT, x-provider-id
    SHEP->>SOD: проксирование
    SOD->>GW: проксирование
    Note over GW: валидация JWT,<br/>x-provider-id ⊂ scope,<br/>биллинг
    GW->>B: GET /v3/accounts
    B-->>GW: список счетов
    GW-->>SOD: список счетов
    SOD-->>SHEP: ответ
    SHEP-->>CRTR: ответ
```

***

### Процесс получения согласия

#### Шаг 1 - Инициатор подаёт заявление

Инициатор подаёт заявление в МТСЗН РК на получение выплат по АСП, указав сведения о составе семьи.

***

#### Шаг 2 - Запрос OAuth-URL

МТСЗН РК формирует запрос в АО «НПК» на получение URL-адреса индивидуально для Инициатора и каждого члена семьи.

**Формат запроса:**

```
POST https://api.stage.npck.kz/v1/auth/generate-user-url
Content-Type: application/json
Accept: application/json
Authorization: ••••••
```

```json
{
  "scopes": [
    "openid",
    "accounts",
    "account_balance",
    "account_transactions"
  ],
  "redirectUri": "https://www.google.com/",
  "state": "examplestate",
  "phone": "+77070000000",
  "iin": "123456789123", // ИИН передаётся в хэшированном виде по алгоритму SHA-512 при масштабировании
  "accountsScopeData": {
    "providerIds": [
      "76714972-02ee-4cea-88c1-933b2034da4d"
    ]
  },
  "accountBalanceScopeData": {
    "providerIds": [
      "76714972-02ee-4cea-88c1-933b2034da4d"
    ]
  },
  "accountTransactionsScopeData": {
    "providerIds": [
      "76714972-02ee-4cea-88c1-933b2034da4d"
    ]
  },
  "language": "ru",
  "serviceCode": "OB_SERVICE",
  "consentExpiresAt": "2027-08-24T14:15:22Z",
  "dataRetentionPeriod": 1
}
```

**Формат ответа:**

```json
{
  "url": "https://auth.stage.npck.kz/oauth?session-id=4204be02-1db0-4798-8c56-a40eddd6e0c7"
}
```

***

#### Шаг 3 - Генерация и доставка URL по SMS

АО «НПК» генерирует уникальный URL-адрес и перенаправляет его в ИС МТСЗН РК. ИС МТСЗН РК направляет URL-адрес Инициатору и совершеннолетним членам семьи посредством SMS-уведомления от сервиса рассылки единого контакт-центра **1414**.

> **Важно:** Срок действия сгенерированного URL-адреса составляет **24 часа**.

***

#### Шаг 4 - Идентификация и предоставление согласия

После перехода по URL-адресу Система Open API запрашивает от Инициатора и членов семьи прохождение следующих процедур:

1. **Двухфакторная аутентификация:**
   * Запрос по подтверждению ИИН
   * Биометрическая идентификация личности: liveness-проверка и процедура сопоставления фотоизображения
2. **Ввод одноразового кода**, направленного по SMS на мобильный номер
3. **Регистрация согласия** на сбор, обработку и передачу третьим лицам персональных данных и сведений по банковским счетам, остаткам и (или) движению денег

> **Важно:** Получение информации о счёте без действующего согласия со стороны Инициатора и (или) членов семьи исключено.

***

#### Шаг 5 - Auto-exchange и поллинг токена

После предоставления согласия AUTH **не выполняет перенаправление** на `redirectUri` ввиду его отсутствия у ЦРТР. Вместо этого AUTH самостоятельно:

1. Получает `authorization_code` от OAUTH
2. Производит обмен кода на JWT `access-token` (`POST /oauth2/token`)
3. Сохраняет токен в сессии для последующего извлечения

С момента инициации флоу ЦРТР периодически опрашивает AUTH через **ШЭП → СОД** и забирает токен по завершении идентификации пользователя.

> **Рекомендация:** Интервал поллинга - не чаще одного запроса в 3 секунды во избежание избыточной нагрузки на сервис.

**Формат запроса на получение токена:**

```
POST https://api.stage.npck.kz/oauth2/token
Content-Type: application/x-www-form-urlencoded
Authorization: ••••••

grant_type=<string>
code=<string>
redirect_uri=<string>
```

**Формат ответа:**

```json
{
  "access_token": "string",
  "scope": "string",
  "id_token": "string",
  "token_type": "string",
  "expires_in": 0
}
```

***

#### Шаг 6 - Запрос данных по счетам

С полученным токеном ЦРТР обращается к эндпоинтам `accounts-api` через **ШЭП → СОД → API Gateway ЦОИД**.

Обязательные заголовки запроса:

```
Authorization: Bearer <access-token>
x-provider-id: {providerId}
```

API Gateway выполняет стандартный набор проверок:

* Валидация подписи JWT
* Проверка активности токена (не истёк, не отозван)
* Проверка активности `clientId` владельца токена
* Проверка вхождения `x-provider-id` в скоуп токена (изоляция провайдеров)
* Проверка активности поставщика и публикации вызываемого API

***

#### Условия неуспешного прохождения

Прохождение процедур признаётся неуспешным в следующих случаях:

* Инициатором и (или) членами семьи не осуществлён переход по URL-адресу в установленный период
* Инициатором и (или) членами семьи не предоставлено согласие на сбор, обработку и передачу данных по банковским счетам

> **Важно:** Если один из членов семьи отклоняет согласие - процесс прекращается, запрос отклоняется.

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

Если в течение установленного квартального периода согласие так и не было направлено - предоставление услуги становится невозможным, а все ранее переданные БВУ сведения подлежат уничтожению в порядке, предусмотренном законодательством Республики Казахстан.

> **Важно:** Хранение данных без действующего согласия Инициатора и всех участников семьи является недопустимым.

***

#### Форс-мажоры в рамках взаимодействия

К обстоятельствам, которые могут повлиять на процесс генерации, доставки или использования URL-адреса, относятся:

1. Технические сбои в ИС МТСЗН РК
2. Технический сбой Системы Open API
3. Неисправности в сервисе рассылки SMS-уведомлений (1414)
4. Обновления и техническое обслуживание систем
5. Невозможность доставки уведомлений по причинам, не зависящим от оператора связи
6. Ошибки или сбои на стороне пользователей
7. Форс-мажорные обстоятельства (стихийные бедствия, военные конфликты, эпидемии и т.д.)
8. Ошибки в работе сгенерированного URL-адреса

***

### Получение данных от БВУ

Система Open API направляет запросы **во все БВУ**. Запросы формируются без учёта родственных связей или семейных уз - их обработка осуществляется на стороне МТСЗН РК. В БВУ передаётся запрос исключительно на физическое лицо, давшее согласие на передачу и обработку своих данных.

#### Методы API

Система Open API взаимодействует с БВУ по следующим методам (спецификация: <https://accounts-openapi.npck.kz/#tag/Accounts/operation/getAccountsV3>):

| Метод            | Эндпоинт                                    | Описание                                                                                                                                                                     |
| ---------------- | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Список счетов    | `GET /v3/accounts`                          | Предоставляет информацию об имеющихся банковских счетах Инициатора и членов семьи за установленный период (3 месяца). Возвращает тип счёта, статус, валюту и другие сведения |
| Баланс счёта     | `GET /v3/accounts/{accountId}/balances`     | Предоставляет информацию о текущем балансе по конкретному счёту на последний день установленного периода                                                                     |
| Транзакции счёта | `GET /v3/accounts/{accountId}/transactions` | Предоставляет список транзакций по конкретному счёту. Включает сумму, дату, описание и другие данные о каждой транзакции                                                     |

> **Важно:** Номер счёта (`accountId`) передаётся в формате **UUID**. Для конвертации IBAN в UUID используется метод `getOBIDsByIBANs`: <https://obid-openapi.npck.kz/#tag/OBID/operation/getOBIDsByIBANs>

***

#### Анализ операций

МТСЗН РК анализирует два типа операций:

**Внутрибанковские переводы**

Фильтрация выполняется по ИИН получателя и отправителя. Если хэшированный ИИН получателя (`iinReciever`) или отправителя (`iinSender`), полученный от БВУ, совпадает с хэшированным ИИН Инициатора или одного из членов семьи - перевод идентифицируется как **внутрисемейный** и исключается из расчётов. Если получатель не входит в состав семьи - перевод рассматривается как **внешний** и учитывается в расчётах.

**Межбанковские переводы**

Фильтрация выполняется по атрибутам `transactionId`, `reference` и `RRN`.

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

| Атрибут                            | Сторона                     | Описание                                                   |
| ---------------------------------- | --------------------------- | ---------------------------------------------------------- |
| `Reference`                        | Банк-отправитель (Банк «А») | Уникальный идентификатор операции на стороне отправителя   |
| `RRN` (Reference Retrieval Number) | Банк-получатель (Банк «Б»)  | Кроссовый атрибут операции банка «А» на стороне получателя |
| `transactionId`                    | Оба банка                   | Единый уникальный идентификатор при переводах через СМП    |

МТСЗН РК при получении всех транзакций от БВУ, для исключения межбанковских операций по типу «семейные переводы» и «переводы самому себе», применяет следующую логику:

* **`Reference`** - используется при операциях типа «Перевод» (Transfer) у банка-отправителя
* **`RRN`** - используется при операциях типа «Поступление» (Income) у банка-получателя
* **`transactionId`** - единый идентификатор для обоих банков при переводах через СМП

***

### Требования при масштабировании

По результатам пилотного проекта в рамках фокус-группы планируется масштабирование на всю территорию Республики Казахстан. В связи с этим необходимо реализовать следующие доработки:

#### Хэширование ИИН (SHA-512)

При масштабировании ИИН Инициатора и членов семьи должен передаваться в **хэшированном виде** по алгоритму **SHA-512**.

> **Важно:** На текущий момент и в период проведения пилотного проекта в рамках фокус-группы данное требование не является критичным. Становится обязательным при масштабировании.

Пример хэширования (SHA-512):

```
Исходный ИИН: 123456789123
SHA-512: cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e
```

***

#### Формат номера счёта (UUID)

Номер счёта (`accountId`) при обращении к API БВУ передаётся в формате **UUID** (OBID), а не в формате IBAN. Для конвертации IBAN в UUID необходимо использовать метод `getOBIDsByIBANs`.

**Эндпоинт конвертации:**

```
GET https://obid-openapi.npck.kz/#tag/OBID/operation/getOBIDsByIBANs
```

> **Важно:** На текущий момент и в период проведения пилотного проекта в рамках фокус-группы данное требование не является критичным. Становится обязательным при масштабировании.

***

### Сравнение со стандартным флоу

|                           | Стандартный флоу                         | Флоу ЦРТР                   |
| ------------------------- | ---------------------------------------- | --------------------------- |
| Доставка URL пользователю | Редирект в приложении                    | SMS-сообщение со ссылкой    |
| Получение токена          | Callback-редирект с `authorization_code` | Поллинг из AUTH             |
| Запросы к API ЦОИД        | Напрямую из сети интернет                | ШЭП → СОД → ЦОИД            |
| Идентификация и согласие  | Стандартные                              | Идентичны стандартному флоу |
| Проверки API Gateway      | Стандартные                              | Идентичны стандартному флоу |


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

**Центр обмена идентификационными данными (ЦОИД)** предоставляет комплексные цифровые решения, которые помогут рынку масштабировать свои услуги и создать доступные и удобные продукты, обеспечивая при этом безопасность. Предлагаемые услуги ЦОИД:

1. Услуга сопоставления фотоизображений лица
2. Услуга биометрической аутентификации
3. Услуга двухфакторной аутентификации личности: FinID
4. Услуга управления облачной ЭЦП: E-sign

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

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

{% hint style="warning" %}
**С введением СУС все сервисы ЦОИД требуют регистрации согласия клиента**

При использовании любого из сервисов ЦОИД - фотосопоставления, FinID, облачной ЭЦП - Участник обязан передавать параметры согласия для регистрации в Сервисе управления согласиями (СУС). Без регистрации согласия использование сервисов не допускается.

[Подробнее: Сервис управления согласиями (СУС)](/servisy-coid/servis-upravleniya-soglasiyami-sus)
{% endhint %}

{% hint style="info" %}
Общий порядок работы ЦОИД описан в правилах функционирования Центра обмена идентификационными данными, размещенных по адресу <https://npck.kz/coid/>
{% endhint %}


# Сервис сопоставления фотоизображений

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

{% hint style="warning" %}
Сопоставление могут пройти лица, у которых имеется как минимум один из следующих документов:

* удостоверение личности гражданина РК
* паспорт гражданина РК
* вид на жительство иностранца в РК
* удостоверение лица без гражданства (казахстанского образца)
  {% endhint %}

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

<figure><img src="/files/K8LFrBUCdScYsr3vlFhU" alt=""><figcaption><p><em>Основной сценарий</em> Сервиса сопоставления фотоизображений</p></figcaption></figure>

Для отправки запроса на сопоставление фотоизображения Клиента Участник должен:

1. &#x20;получить согласие Клиента на сбор, обработку и передачу его персональных данных, в том числе третьими лицами;
2. убедиться в том, что Клиентом не используются фотоизображения, видеозаписи, маски и иные средства/технологии для подмены личности Клиента.

Сервис сопоставления фотоизображения Клиента принимает следующие виды и параметры запросов:

1. запрос на получение результатов степени соответствия фотоизображения Клиента, который содержит:

* ИИН Клиента;
* фотоизображение Клиента, полученное от Участника с применением специализированного программного обеспечения, реализующего технологию выявления подмены личности Клиента в процессе дистанционной идентификации.

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

Обработка запроса на стороне сервиса сопоставления включает:

* взаимодействие с ИС КДП для получения токена доступа к персональным данным по ИИН;
* взаимодействие с ГБД ФЛ для направления запросов и получения ответов из ГБД ФЛ.&#x20;

При проценте верификации фотоизображения клиента ниже 85% Участник самостоятельно принимает решение о возможности идентификации по предоставленному проценту степени соответствия и о дальнейшем установлении деловых отношений клиентом. При этом персональные данные Клиента Участнику не предоставляются.

{% hint style="warning" %}
**Требуется регистрация согласия в СУС**

Для интеграции с СУС используйте `POST /v2/identity/sync/verify` вместо `v1`. При успешном сличении фото согласие регистрируется в СУС автоматически - в ответе возвращается `consentId`. Старый метод `v1` СУС не поддерживает.

[Подробнее: Сервис управления согласиями (СУС)](/servisy-coid/servis-upravleniya-soglasiyami-sus)
{% endhint %}


# Рекомендации по реализации интеграции

{% hint style="info" %}
Для использования сервиса сопоставления фотоизображений необходимо, чтобы Участник:

1\.  Прошел процедуру регистрации на Портале АО «НПК» (см. подробнее в  [Регистрация и авторизация в Портале НПК](https://docs.npck.kz/rabota-s-testovym-okruzheniem-is-npk/rabota-s-testovym-portalom-npk/registraciya-i-avtorizaciya-v-portale-npk))

2\. Подал заявку на подключение к ЦОИД (см. подробнее в [5.1 Подключение к ЦОИД](/registraciya-i-avtorizaciya/5.-podacha-zayavki-na-podklyuchenie-k-servisam/5.1-podklyuchenie-k-coid))

3\. Зарегистрировал приложение Участника (см. подробнее в  [Пользователям API (добавление и использование приложения)](https://docs.npck.kz/rabota-s-testovym-okruzheniem-is-npk/rabota-s-testovymi-servisami/polzovatelyam-api-dobavlenie-i-ispolzovanie-prilozheniya))
{% endhint %}

{% hint style="warning" %}
Аутентификацию могут пройти люди, у которых имеется как минимум один из следующих документов:&#x20;

* удостоверение личности гражданина РК
* паспорт гражданина РК
* вид на жительство иностранца в РК
* удостоверение лица без гражданства (казахстанского образца)
  {% endhint %}

#### Авторизация

Авторизация осуществляется по схеме Basic Auth. Для этого используется строка вида:

Authorization: Basic \<Base64(ClientID:ClientSecret)>

Где ClientID:ClientSecret — это пара идентификаторов, объединённых через двоеточие и закодированных в формате Base64. Чтобы бы получить ClientID  и ClientSecret необходимо зарегистрировать приложение (см. подробнее в  [Пользователям API (добавление и использование приложения)](https://docs.npck.kz/rabota-s-testovym-okruzheniem-is-npk/rabota-s-testovymi-servisami/polzovatelyam-api-dobavlenie-i-ispolzovanie-prilozheniya))

#### &#x20;Сервис сопоставления фотоизображения поддерживает два метода взаимодействия:

1. **Синхронный** - метод, при котором результат сравнения возвращается сразу же в рамках одного запроса. <mark style="color:red;">**Регистрация согласия клиента на сбор и обработку персональных данных осуществляется способом биометрической верификации личности на стороне Участника и подписывается ЭЦП организации**</mark>.
2. **Асинхронный** - метод, при котором запрос на сопоставление отправляется, но сопоставление фотоизображений осуществляется только после предоставления клиентом согласия на сбор и обработку его персональных данных. <mark style="color:red;">**Регистрация согласия клиента на сбор и обработку персональных данных осуществляется методом отправки OTP посредством СМС 1414.**</mark>


# Синхронная проверка

#### Синхронная проверка личности с фиксированным подтверждением согласия

**Метод:** POST /v1/identity/sync/verify\
**Описание метода:** <https://identity-openapi.npck.kz/#tag/Identity/operation/syncVerify>

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

**Вендоры которые могут быть выбраны**

* VISIONLABS
* OZFORENSICS
* VERIGRAM
* BIOMETRIC
* BIOMETRICSOLUTION
* FCB
* BTS
* SUNSOFT
* UZINFOCOM

**Типы согласия:**

* BIOMETRY (Система биометрии)
* DIGITAL\_SIGNATURES (Электронно-цифровая подпись)
* OTP (Одноразовый пароль OTP)
* DIGITAL\_ID (Система Digital ID)
* PAPER (Бумажный носитель информации)

#### Пошаговое описание процесса (синхронный метод)

1\. Клиент инициирует получение услуги дистанционным способом в приложении Участника.

2\. Участник запрашивает у клиента согласие на сбор и обработку персональных данных средствами своей системы.

3\. Клиент предоставляет согласие на сбор и обработку персональных данных.

4\. Участник осуществляет проверку сессии идентификации на предмет подлога личности путем проведения liveness / видеоинтервью, извлекает текущее фото клиента из сеанса.

5\. Участник направляет в ЦОИД запрос на сопоставление фото, содержащий ИИН, текущее фото из шага 4, код вендора и метод сбора согласия клиента.

6\. ЦОИД направляет в ИС КДП запрос на регистрацию токена доступа.

7\. ИС КДП возвращает в ЦОИД токен доступа.

8\. ЦОИД направляет в ГБД ФЛ запрос на получение эталонного фото клиента (по ИИН и токену доступа), а также проверяет актуальность сведений о документе.

9\. ГБД ФЛ передает в ЦОИД эталонное фото клиента.

10\. ЦОИД передает в выбранному участником биометрическому решению текущее фото и эталонное фото клиента для сопоставления.

11\. Биометрическое решение (вендор) проводит сопоставление фотоизображений и возвращает ЦОИД результат сопоставления (%).

12\. ЦОИД перенаправляет результат сопоставления фотоизображений клиента (%) в систему Участника.

13\. Участник принимает решение о возможности оказания услуги клиенту.

14\. В случае принятия положительного решения Участник направляет в ЦОИД [запрос на получение персональных данных клиента. ](#zapros-na-poluchenie-personalnykh-dannykh-iz-gosudarstvennoi-bazy-po-identifikatoru-verifikacii)

15\. ЦОИД перенаправляет запрос на получение персональных данных клиента в ГБД ФЛ.

16\. ГБД ФЛ предоставляет в ЦОИД персональные данные физического лица.

17\. ЦОИД перенаправляет полученные персональные данные в систему Участника.

18\. Участник оказывает услугу клиенту.


# Асинхронная проверка

#### Асинхронная проверка личности с подтверждением согласия через SMS 1414 (с использованием базы мобильных граждан, БМГ).

**Метод:** POST /v1/identity/async/verify \
**Описание метода:** <https://identity-openapi.npck.kz/#tag/Identity/operation/asyncVerify>

Используется для запуска процесса верификации, который требует подтверждения от физического лица посредством SMS с номера 1414. В момент выполнения запроса клиенту будет направлено SMS. Номер телефона будет взят из базы мобильных граждан (БМГ), где клиент должен подтвердить согласие или отказ на предоставление персональных данных

{% hint style="warning" %}
В тестовой среде запрос будет направляться в Telegram-бот @NPCK\_TestControl\_bot имитируя запрос на получения согласия на предоставление персональных данных от физического лица (<https://t.me/NPCK_TestControl_bot>). Для работы требуется предварительная авторизация:

* Откройте Telegram-бот @NPCK\_TestControl\_bot.
* Нажмите команду /start.
* Введите свой ИИН для прохождения авторизации.
  {% endhint %}

**Вендоры которые могут быть выбраны**

* VISIONLABS
* OZFORENSICS
* VERIGRAM
* BIOMETRIC
* BIOMETRICSOLUTION
* FCB
* BTS
* SUNSOFT
* UZINFOCOM

#### Пошаговое описание процесса (асинхронный метод)

1\. Клиент инициирует получение услуги дистанционным способом в приложении Участника.

2\. Участник осуществляет проверку сессии идентификации на предмет подлога личности путем проведения liveness / видеоинтервью, извлекает текущее фото клиента из сеанса liveness / видеоинтервью.

3\. Участник направляет в ЦОИД запрос на сопоставление фото, содержащий ИИН, текущее фото из шага 2, код вендора и метод сбора согласия клиента (в данном случае OTP (Одноразовый пароль OTP).

4\. ЦОИД направляет в ИС КДП запрос на регистрацию токена доступа.

5\. ИС КДП для получения согласия клиента на сбор и обработку его персональных данных направляет клиенту запрос посредством СМС 1414.

6\. Клиент предоставляет ИС КДП ответ – согласие или отказ на сбор и обработку персональных данных (через СМС).

7\. ИС КДП регистрирует согласие / отказа клиента на сбор и обработку персональных данных.

8\. Участник, не чаще чем 1 раз в 5 секунд опрашивает (направляет запрос) ЦОИД для [получения статуса регистрации согласия клиента на сбор и обработку персональных данных.](#zapros-poluchenie-statusa-asinkhronnoi-proverki-lichnosti)

9\. ЦОИД направляет запрос в ИС КДП для получения статуса регистрации согласия клиента на сбор и обработку персональных данных.

10\. При наличии ответа клиента (согласие / отказ) ИС КДП возвращает ЦОИД токен доступа / статус с отказом.

11\. При наличии согласия клиента и получения от ИС КДП токена доступа ЦОИД направляет в ГБД ФЛ запрос на получение эталонного фото клиента, а также проверяет актуальность сведений о документе.

12\. ГБД ФЛ передаёт ЦОИД эталонное фото клиента.

13\. ЦОИД направляет биометрическому решению, определенному участником в параметрах своего запроса (шаг 3) два фото клиента (текущее + эталонное) для сопоставления.

14\. Биометрическое решение (вендор) проводит сопоставление фотоизображений и возвращает ЦОИД результат сопоставления (%).

15\. ЦОИД перенаправляет участнику результат сопоставления фотоизображений клиента (%).

16\. Участник принимает решение о возможности оказания услуги клиенту.

17\. В случае принятия участником положительного решения о возможности оказания услуги клиенту участник направляет в ЦОИД [запрос на получение персональных данных клиента.](#zapros-na-poluchenie-personalnykh-dannykh-iz-gosudarstvennoi-bazy-po-identifikatoru-verifikacii)

18\. ЦОИД направляет соответствующий запрос в ГБД ФЛ.

19\. ГБД ФЛ предоставляет ЦОИД персональные данные физического лица.

20\. ЦОИД перенаправляет участнику полученные от ГБД ФЛ персональные данные.

21\. Участник оказывает услуги клиенту.

#### Запрос получение статуса асинхронной проверки личности

**Метод:** /v1/identity/async/verify/{verificationId}\
**Описание метода:** <https://identity-openapi.npck.kz/#tag/Identity/operation/asyncCheckVerify>

Используется для отслеживания результата ранее запущенной асинхронной проверки

Статус асинхронной проверки

* PENDING - ожидание подтверждения согласия от физического лица
* TIMEOUT - время ожидания ответа подтверждения истекло
* NOT\_FOUND – По данному ИИН отсутствует номер телефона в БМГ
* KDP\_ERROR – ошибка КДП
* REJECTED – физическое лицо отклонило согласие на предоставление доступа к персональным данным
* ACCEPTED - физическое лицо дало согласие на предоставление доступа к персональным данным


# Получение персональных данных из государственной базы по идентификатору верификации

**Метод:** /v1/identity/data/{verificationId}\
**Описание метода:** <https://identity-openapi.npck.kz/#tag/Identity/operation/personalData>

Используется для извлечения информации о личности после успешной проверки

Описание полей тела ответа:

<table data-header-hidden><thead><tr><th width="327"></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Поле</strong></td><td><strong>Описание</strong></td><td>Тип</td></tr><tr><td>iin</td><td>ИИН (Индивидуальный идентификационный номер)</td><td>string</td></tr><tr><td>surname</td><td>Фамилия</td><td>string</td></tr><tr><td>name</td><td>Имя</td><td>string</td></tr><tr><td>patronymic</td><td>Отчество</td><td>string</td></tr><tr><td>birthDate</td><td>Дата рождения</td><td>string (date)</td></tr><tr><td>deathDate</td><td>Дата смерти</td><td>string (date)</td></tr><tr><td>nationality</td><td>Национальность</td><td>object</td></tr><tr><td>gender</td><td>Пол</td><td>object</td></tr><tr><td>lifeStatus</td><td>Статус жизни (жив/умер)</td><td>object</td></tr><tr><td>citizenship</td><td>Гражданство</td><td>object</td></tr><tr><td>birthPlace</td><td>Место рождения</td><td>object</td></tr><tr><td>birthPlace.country</td><td>Страна рождения</td><td>object</td></tr><tr><td>birthPlace.city</td><td>Город рождения</td><td>string</td></tr><tr><td>birthPlace.district</td><td>Район рождения</td><td>object</td></tr><tr><td>birthPlace.region</td><td>Область/регион рождения</td><td>object</td></tr><tr><td>regAddress</td><td>Адрес регистрации</td><td>object</td></tr><tr><td>regAddress.country</td><td>Страна</td><td>object</td></tr><tr><td>regAddress.city</td><td>Город</td><td>string</td></tr><tr><td>regAddress.district</td><td>Район</td><td>object</td></tr><tr><td>regAddress.region</td><td>Регион</td><td>object</td></tr><tr><td>regAddress.beginDate</td><td>Дата начала регистрации</td><td>string (date)</td></tr><tr><td>regAddress.street</td><td>Улица</td><td>string</td></tr><tr><td>regAddress.building</td><td>Дом</td><td>string</td></tr><tr><td>regAddress.flat</td><td>Квартира</td><td>string</td></tr><tr><td>documents</td><td>Документы личности</td><td>array(object)</td></tr><tr><td>documents.number</td><td>Номер документа</td><td>string</td></tr><tr><td>documents.beginDate</td><td>Дата выдачи</td><td>string (date)</td></tr><tr><td>documents.endDate</td><td>Дата окончания</td><td>string (date)</td></tr><tr><td>documents.surname</td><td>Фамилия (в документе)</td><td>string</td></tr><tr><td>documents.name</td><td>Имя (в документе)</td><td>string</td></tr><tr><td>documents.patronymic</td><td>Отчество (в документе)</td><td>string</td></tr><tr><td>documents.birthDate</td><td>Дата рождения (в документе)</td><td>string (date)</td></tr><tr><td>documents.type</td><td>Тип документа</td><td>object</td></tr><tr><td>documents.issueOrganization</td><td>Орган, выдавший документ</td><td>object</td></tr><tr><td>documents.status</td><td>Статус документа</td><td>object</td></tr><tr><td>removed</td><td>Признак удаления записи</td><td>boolean</td></tr><tr><td>birthCertificate</td><td>Свидетельство о рождении</td><td>object</td></tr><tr><td>birthCertificate.number</td><td>Номер</td><td>string</td></tr><tr><td>birthCertificate.beginDate</td><td>Дата выдачи</td><td>string (date)</td></tr><tr><td>birthCertificate.issueOrganisation</td><td>Орган выдачи</td><td>string</td></tr><tr><td>deathCertificate</td><td>Свидетельство о смерти</td><td>object</td></tr><tr><td>deathCertificate.number</td><td>Номер</td><td>string</td></tr><tr><td>deathCertificate.beginDate</td><td>Дата выдачи</td><td>string (date)</td></tr><tr><td>deathCertificate.issueOrganisation</td><td>Орган выдачи</td><td>string</td></tr><tr><td>personCapableStatus</td><td>Дееспособность</td><td>object</td></tr><tr><td>personCapableStatus.capableStatus</td><td>Статус дееспособности</td><td>object</td></tr><tr><td>personCapableStatus.capableDate</td><td>Дата начала</td><td>string (date)</td></tr><tr><td>personCapableStatus.capableEndDate</td><td>Дата окончания</td><td>string (date)</td></tr><tr><td>personCapableStatus.capableNumber</td><td>Номер решения</td><td>string</td></tr><tr><td>personCapableStatus.court</td><td>Суд</td><td>object</td></tr><tr><td>missingStatus</td><td>Статус «пропавший без вести»</td><td>object</td></tr><tr><td>missingStatus.missing</td><td>Признак (да/нет)</td><td>boolean</td></tr><tr><td>missingStatus.missingDate</td><td>Дата начала</td><td>string (date)</td></tr><tr><td>missingStatus.missingEndDate</td><td>Дата окончания</td><td>string (date)</td></tr><tr><td>missingStatus.missingNumber</td><td>Номер постановления</td><td>string</td></tr><tr><td>missingStatus.gpTerritorial</td><td>Территориальная прокуратура</td><td>object</td></tr><tr><td>disappearStatus</td><td>Статус «исчезнувший»</td><td>object</td></tr><tr><td>disappearStatus.disappear</td><td>Признак (да/нет)</td><td>boolean</td></tr><tr><td>disappearStatus.disappearDate</td><td>Дата начала</td><td>string (date)</td></tr><tr><td>disappearStatus.disappearEndDate</td><td>Дата окончания</td><td>string (date)</td></tr><tr><td>disappearStatus.disappearNumber</td><td>Номер постановления</td><td>string</td></tr><tr><td>disappearStatus.gpTerritorial</td><td>Территориальная прокуратура</td><td>object</td></tr><tr><td>excludeStatus</td><td>Исключение</td><td>object</td></tr><tr><td>excludeStatus.excludeReason</td><td>Причина исключения</td><td>object</td></tr><tr><td>excludeStatus.excludeReasonDate</td><td>Дата причины</td><td>string (date)</td></tr><tr><td>excludeStatus.excludeDate</td><td>Дата исключения</td><td>string (date)</td></tr><tr><td>excludeStatus.excludeParticipant</td><td>Участник исключения</td><td>object</td></tr><tr><td>repatriationStatus</td><td>Репатриация</td><td>object</td></tr><tr><td>repatriationStatus.repatriationStatus</td><td>Статус репатриации</td><td>object</td></tr><tr><td>repatriationStatus.repatriationDate</td><td>Дата начала</td><td>string (date)</td></tr><tr><td>repatriationStatus.repatriationEndDate</td><td>Дата окончания</td><td>string (date)</td></tr><tr><td>repatriationStatus.repatriationNumber</td><td>Номер</td><td>string</td></tr><tr><td>repatriationStatus.repatriationOrg</td><td>Орган репатриации</td><td>object</td></tr><tr><td>repatriationStatus.repatriationReason</td><td>Причина репатриации</td><td>object</td></tr></tbody></table>


# Получение электронного документа по результатам сличения биометрических данных

#### Запрос на получение электронного документа по результатам сличения биометрических данных&#x20;

**Метод** /v1/identity/report/{verificationId}/download\
**Описание метода** <https://identity-openapi.npck.kz/#tag/Identity/operation/downloadReport>

Используется для получения электронного документа по результатам сличения биометрических данных

Пример  электронного документа по результатам сличения биометрических данных:

<figure><img src="/files/dflA6qUmMFG3EKwYRAQz" alt=""><figcaption></figcaption></figure>


# Выпуск ключей ГОСТ 2015

В рамках **синхронного метода** работы с сервисом сопоставления фотоизображений **выпуск ключей ГОСТ 2015 является обязательным этапом**.

Ключи используются для формирования заголовка **`X-JWS-Signature`** - электронной подписи запроса. Подпись служит подтверждением того, что на стороне участника **получено согласие пользователя на сбор и обработку персональных данных клиента**, а также обеспечивает контроль целостности и подлинности передаваемых данных


# Выпуск ключей для тестовой среды

Для взаимодействия с сервисом сопоставления фотоизображения  Участникам необходимо выпустить комплект
\
криптографических ключей в Удостоверяющем Центре АО «НПК».
\
Для получения криптографических ключей для тестовой среды необходимо заполнить
\
шаблон письма, который размещен на тестовом портале Удостоверяющего Центра по адресу: <https://betacms.npck.kz/info> **Пример сообщения для получения тестовых ключей и регистрационных свидетельств** и отправить на почту: **<supportca@npck.k>**

Комплект криптографических ключей первичной инициализации выпускается на 14 дней и
\
их необходимо продлить на год. В случае возникновения вопросов касательно выпуска
\
регистрационных ключей, в том числе продление, а также установка и настройка ПО
\
«TumarCSP» необходимо обращаться по e-mail: **<supportca@npck.kz>** или по телефону: **8**
\
**(727) 297-91-00.**

Для ГОСТ 2015 требуется новый Tumar конфигуратор, который использует новые
\
алгоритмы и профайлы. Обновленную версию Tumar CSP можно скачать с сайта
\
**<https://cms.npck.kz>**: кнопка «Инфо» → «Программное обеспечение, документация,
\
примеры разработчикам» → «TumarCSP для пользователя», либо по прямой ссылке:
\
**<https://cms.npck.kz/downloads/res-open/client/TumarCSP.zip>**

* Комплект криптографических ключей состоит из GOST и RSA сертификатов. **GOST (.pfx)** сертификат необходим для подписи.
* Для выгрузки криптографических ключей необходимо запустить криптографический провайдер «TumarCSP» и перейти в профайл «FSystem», или «FSystem2015» для криптографических ключей ГОСТ 2015, в списке ключей должны отобразиться выпущенные криптографические ключи: **GOST (отображается синим цветом)** и RSA (отображается красным цветом).&#x20;

<figure><img src="/files/z9HKzdp8NSqLRTqPA0MY" alt=""><figcaption></figcaption></figure>

* Для выгрузки **GOST сертификата** необходимо его выделить, затем нажав на правую кнопку мыши в выпадающем меню выбрать пункт «Импорт/Экспорт…» и далее выбрать пункт «Экспортировать ключ (PKCS#12)», указать пароль и выбрать путь для сохранения.

<figure><img src="/files/bNn6GGWREoHtjGjgZCMP" alt=""><figcaption></figcaption></figure>


# Выпуск ключей для промышленной среды

Для получения криптографических ключей в промышленной среде необходимо заполнить [Приложение №1](https://cms.npck.kz/downloads/res-open/manuals/statement.zip)  Заявления/Соглашения к Договору о предоставлении услуг Удостоверяющего Центра в системах АО «НПК» (сам Договор прикладывать не надо, т.к. он является публичным, необходимо только Приложение №1) и скинуть Приложение для проверки корректности заполнения сотрудникам УЦ (без подписи, в Word файле) на email: <supportca@npck.kz>

После подтверждения о правильном заполнении, необходимо подписать заполненное заявление, поставить печать и скан версию выслать на почту **<supportca@npck.kz>**. После выпуска ключей сотрудниками УЦ Вы получите уведомление о готовности. Далее необходимо принести оригинал заявление нарочно в АО НПК, по адресу г.Алматы, мкр. Коктем 3, здание 21, 1 подъезд. При себе необходимо иметь **удостоверения личности на имя получателя и флешку для записи ключей**. Комплект криптографических ключей первичной инициализации <mark style="color:red;">выпускается на 14 дней и их необходимо продлить на год</mark>. Далее выпуск криптографических ключей производится  на портале УЦ АО «НПК» по адресу: <https://cms.npck.kz/auth>[ ](https://cms.npck.kz/auth)(ГОСТ 2015) – для промышленной среды.

В случае возникновения вопросов касательно выпуска регистрационных ключей, в том числе продление, а также установка и настройка ПО «TumarCSP» необходимо обращаться **по e-mail: <supportca@npck.kz> или по телефону: 8 (727) 297-91-00.**

Для ГОСТ 2015 требуется новый Tumar конфигуратор, который использует новые алгоритмы и профайлы. Обновленную версию Tumar CSP можно скачать с сайта [https://cms.npck.kz](https://cms.npck.kz/)[:](https://cms.npck.kz/) кнопка «Инфо» → «Программное обеспечение, документация, примеры разработчикам» → «[TumarCSP](https://cms.npck.kz/downloads/res-open/client/TumarCSP.zip)[ ](https://cms.npck.kz/downloads/res-open/client/TumarCSP.zip)[для](https://cms.npck.kz/downloads/res-open/client/TumarCSP.zip)[ ](https://cms.npck.kz/downloads/res-open/client/TumarCSP.zip)[пользователя](https://cms.npck.kz/downloads/res-open/client/TumarCSP.zip)[»](https://cms.npck.kz/downloads/res-open/client/TumarCSP.zip), либо по прямой ссылке: [https://cms.npck.kz/downloads/res-open/client/TumarCSP.zip ](<https://cms.npck.kz/downloads/res-open/client/TumarCSP.zip >)

* Комплект криптографических ключей состоит из GOST и RSA сертификатов. **GOST (.pfx)** сертификат необходим для подписи.
* Для выгрузки криптографических ключей необходимо запустить криптографический провайдер «TumarCSP» и перейти в профайл «FSystem», или «FSystem2015» для криптографических ключей ГОСТ 2015, в списке ключей должны отобразиться выпущенные криптографические ключи: **GOST (отображается синим цветом)** и RSA (отображается красным цветом).&#x20;

<figure><img src="/files/z9HKzdp8NSqLRTqPA0MY" alt=""><figcaption></figcaption></figure>

* Для выгрузки **GOST сертификата** необходимо его выделить, затем нажав на правую кнопку мыши в выпадающем меню выбрать пункт «Импорт/Экспорт…» и далее выбрать пункт «Экспортировать ключ (PKCS#12)», указать пароль и выбрать путь для сохранения.

<figure><img src="/files/bNn6GGWREoHtjGjgZCMP" alt=""><figcaption></figcaption></figure>


# Формирование ЭЦП JWS

JWS используется для безопасной передачи данных с цифровой подписью. Он состоит из трёх частей, разделённых точками:&#x20;

<Заголовок>.<Полезная нагрузка>.<Подпись>&#x20;

#### &#x20;1. Заголовок (Header)

Формируется как JSON-объект, затем кодируется в Base64URL.

Пример:

```
{
  "alg": "GOST3410-2015-512",
  "kid": "CN=PCIDTEST.K0000033,O=JSC National payment corporation of the National Bank of the Republic of Kazakhstan,C=KZ",
  "x5t#S256": "eq3zMUIWn4_VXDA2rK6esTxxiivl8mkBkwbqbokSLQI="
}
```

#### Пояснения:

* **alg:** алгоритм подписи. Используется ГОСТ Р 34.10-2012/2015.
* **kid:** Subject DN из сертификата, которым подписывается JWS.
* **x5t#S256:** SHA-256 отпечаток сертификата (Base64URL).&#x20;

#### &#x20;2. Полезная нагрузка (Payload)

Содержит данные, которые подписываются.

Также кодируется в Base64URL.

Пример:

```
{
  "bin": "987654321012",
  "iin": "123456789012",
  "consentType": "BIOMETRY"
} 
```

#### Пояснения:

* bin: БИН участника (например, банка или организации).
* iin: ИИН клиента, по которому проводится верификация.
* consentType: тип согласия. Допустимые значения:
  * BIOMETRY
  * DIGITAL\_SIGNATURES
  * OTP
  * DIGITAL\_ID
  * PAPER&#x20;

#### &#x20;3. Подпись (Signature)

Формируется следующим образом:

1. Кодируются Header и Payload в Base64URL.
2. Объединяются через точку:  &#x20;

```
 signing_input = base64url(header) + "." + base64url(payload) 
```

3. Строка signing\_input хэшируется (ГОСТ 34.11).
4. Полученный хэш подписывается закрытым ключом (ГОСТ 34.10).
5. Подпись кодируется в Base64URL.&#x20;

#### Итоговая структура JWS:&#x20;

\<base64url(header)>.\<base64url(payload)>.\<base64url(signature)>&#x20;

#### Пример полного JWS:&#x20;

eyJ4NXQjUzI1NiI6ImVxM3pNVUlXbjRfVlhEQTJySzZlc1R4eGlpdmw4bWtCa3dicWJva1NMUUk9Iiwia2lkIjoiQ049UENJRFRFU1QuSzAwMDAwMzMsTz1KU0MgTmF0aW9uYWwgcGF5bWVudCBjb3Jwb3JhdGlvbiBvZiB0aGUgTmF0aW9uYWwgQmFuayBvZiB0aGUgUmVwdWJsaWMgb2YgS2F6YWtoc3RhbixDPUtaIiwiYWxnIjoiR09TVDM0MTAtMjAxNS01MTIifQ.eyJiaW4iOiI5NjA0NDAwMDAxNTEiLCJpaW4iOiI4ODAyMjYzMDExMjgiLCJjb25zZW50VHlwZSI6IkJJT01FVFJZIn0.sSJ3wIX3r7SWkbsdyRx5pVKVZa\_ruwBhxfq-QqWU-i6cg-yP1D1QwAUIEMx4QShrDEjgUui57rcFyxSEfHXlFJvHkzOQ0FyPABq43SGYIQHf9wOkp0LvYQUaZxLokfy20iLMDXuDDQ6E2bSlvH5OnWAqBNvVgOOl\_sg0f6\_w\_Zw


# Требования к фотоизображениям

Требования к фотоизображениям Клиента направляемых в ЦОИД для сопоставления

1. изображение человека выше уровня груди;
2. изображение лица должно быть не менее 70% от общей площади фотоизображения;
3. голова должна быть повернута и наклонена на не более чем 8° от фронтального положения;
4. расстояние между центрами глаз при минимальном горизонтальном размере 480 пикселей должна составлять не менее 120 пикселей;
5. размер входного изображения должен быть не менее 640х480 пикселей и не более 4096x4096 пикселей;
6. изображение должно быть свободным от посторонних лиц в кадре;
7. плечи должны быть направлены к камере, исключая портретный стиль со взглядом через плечо;
8. лицо должно быть равномерно освещено без преобладающего направления света, с определенным соотношением интенсивности освещения;
9. изображение не должно содержать ярких пятен или бликов;
10. не допускается наличие головного убора. Необходимо обеспечить четкую видимость всех черт лица от подбородка до верхней линии лба, включая обе стороны лица;
11. разрешается использование очков только с прозрачными стеклами и без отражений вспышки. Окрашенные линзы запрещены. Необходимо избегать использования очков с толстыми оправами, отдавая предпочтение моделям с тонкими и прочными оправами, если они необходимы субъекту. Оправа очков не должна перекрывать глаза, обеспечивая их полную видимость;
12. недопустимы световые артефакты или отражения вспышки;
13. взгляд должен быть направлен прямо в камеру;
14. глаза должны быть открыты и четко видны. Волосы не должны закрывать глаза;
15. выражение лица должно быть нейтральным;
16. фотография лица должна четкой, лицо в фокусе.


# Health Check

### Описание

Эндпоинт проверки работоспособности (health check) сервиса сопоставления фотоизображения . Используется для мониторинга доступности API.

### Запрос

[`GET /v1/identity/health`](https://identity-openapi.npck.kz/#tag/Identity/operation/healthCheck) - ссылка на OpenAPI-спецификацию метода

{% tabs %}
{% tab title="Production" %}

```bash
curl --request GET \
  --url https://api.npck.kz/v1/identity/health \
  --header 'Authorization: <ваши данные авторизации>'
```

{% endtab %}

{% tab title="Stage" %}

```bash
curl --request GET \
  --url https://api.stage.npck.kz/v1/identity/health \
  --header 'Authorization: <ваши данные авторизации>'
```

{% endtab %}
{% endtabs %}

#### Заголовки

| Заголовок     | Обязательный | Описание                       |
| ------------- | ------------ | ------------------------------ |
| Authorization | Да           | Данные для авторизации запроса |

Метод не принимает параметры запроса (query, path) и не требует тела запроса.

### Ответы

**200 OK** - HTTP статус 200 означает, что API исправно работает (healthy).

```http
HTTP/1.1 200 OK
```

### Примечания

* Метод предназначен для мониторинга доступности сервиса сопоставления фотоизображения и не возвращает дополнительных данных о состоянии его внутренних компонентов.
* Рекомендуется периодически опрашивать данный эндпоинт в рамках систем мониторинга для отслеживания доступности API.


# Threshold

## GET /v1/identity/vendors

### Назначение

Справочный метод сервиса сопоставления фотоизображений (Identity), который возвращает список поддерживаемых биометрических вендоров и применяемый для каждого из них порог совпадения (match-score threshold). Метод нужен для того, чтобы клиент мог корректно интерпретировать поле `score` в ответах методов верификации, не хардкодя пороговые значения на своей стороне.

### Endpoint

| Среда | URL                                                 |
| ----- | --------------------------------------------------- |
| Prod  | `GET https://api.npck.kz/v1/identity/vendors`       |
| Test  | `GET https://api.stage.npck.kz/v1/identity/vendors` |

### Авторизация

Basic Auth — тот же механизм, что и у остальных методов Identity API.

```
Authorization: Basic <base64(client_id:client_secret)>
```

Метод не требует активного биллингового контракта IDENTITY на организацию (в отличие от `sync/verify`, `async/verify` и методов получения персональных данных) — доступен любому авторизованному клиенту как справочная информация.

### Параметры запроса

Отсутствуют — запрос не принимает ни query-параметров, ни тела.

### Формат ответа

`200 OK`, `Content-Type: application/json`

```json
{
  "vendors": [
    { "vendor": "VISIONLABS", "threshold": 0.85 },
    { "vendor": "OZFORENSICS", "threshold": 0.85 },
    { "vendor": "VERIGRAM", "threshold": 0.85 },
    { "vendor": "BIOMETRIC", "threshold": 0.85 },
    { "vendor": "BIOMETRICSOLUTION", "threshold": 0.85 },
    { "vendor": "FCB", "threshold": 0.85 },
    { "vendor": "BTS", "threshold": 0.85 },
    { "vendor": "SUNSOFT", "threshold": 0.85 },
    { "vendor": "UZINFOCOM", "threshold": 0.85 }
  ]
}
```

#### Объект `VendorInfo`

| Поле        | Тип                               | Обязательное | Описание                                                                                                                                                                              |
| ----------- | --------------------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `vendor`    | string (enum)                     | да           | Идентификатор вендора биометрической верификации. Возможные значения: `VISIONLABS`, `OZFORENSICS`, `VERIGRAM`, `BIOMETRIC`, `BIOMETRICSOLUTION`, `FCB`, `BTS`, `SUNSOFT`, `UZINFOCOM` |
| `threshold` | number (double), диапазон 0.0–1.0 | да           | Минимальный порог совпадения (`score`), при достижении которого результат верификации данным вендором считается принятым                                                              |

### Как использовать порог

Поле `score` в ответах методов верификации (`POST /v1/identity/sync/verify`, `POST /v2/identity/sync/verify`, `POST /v1/identity/async/verify` + `GET /v1/identity/async/verify/{verificationId}`) — это скор совпадения биометрии (0.0–1.0), полученный от конкретного вендора. Чтобы определить, является ли результат успешным, сравните `score` с `threshold` того же `vendor`, полученным этим методом:

```
score >= threshold  →  верификация считается успешной
```

Важно: этот же порог применяется и на бэкенде сервиса — доступ к персональным данным (`GET /v1/identity/personal-data/{verificationId}` и v2) и регистрация согласия (`POST /v2/identity/sync/verify`) возможны только если `score` верификации не ниже порога вендора; в противном случае сервис возвращает бизнес-ошибку `SCORE_LESS_THRESHOLD`.

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

### Пример запроса

```bash
curl --location 'https://api.npck.kz/v1/identity/vendors' \
  --header 'Accept: application/json' \
  --header 'Authorization: Basic e3tiYXNpY0F1dGhVc2VybmFtZX19Ont7YmFzaWNBdXRoUGFzc3dvcmR9fQ=='
```

### Пример ответа

```json
{
  "vendors": [
    { "vendor": "VISIONLABS", "threshold": 0.85 },
    { "vendor": "OZFORENSICS", "threshold": 0.85 }
  ]
}
```

### Коды ошибок

| HTTP-код | Когда возникает                                                                         |
| -------- | --------------------------------------------------------------------------------------- |
| 401      | Отсутствуют или некорректны учётные данные авторизации                                  |
| 403      | Клиент не имеет прав на вызов метода                                                    |
| 405      | Использован неподдерживаемый HTTP-метод                                                 |
| 406      | Заголовок `Accept` не соответствует поддерживаемому формату ответа (`application/json`) |
| 429      | Превышен лимит частоты запросов                                                         |
| 500      | Внутренняя ошибка сервиса                                                               |

Тело ошибки для 401/403/405/406:

```json
{
  "requestId": "<уникальный идентификатор запроса, нужен при обращении в поддержку>"
}
```

### Связанные методы

* `POST /v1/identity/sync/verify` (deprecated), `POST /v2/identity/sync/verify` — синхронная верификация, возвращает `score`
* `POST /v1/identity/async/verify`, `GET /v1/identity/async/verify/{verificationId}` — асинхронная верификация
* `GET /v1/identity/personal-data/{verificationId}`, `GET /v2/identity/personal-data/{verificationId}` — получение персональных данных (доступно только при `score >= threshold`)




---

[Next Page](/llms-full.txt/1)