Инициализация оплаты по QR-коду (C2B2)

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

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

Важно! Если отсканированный QR-код выпущен самим Банком отправителя денег, то оплата производится внутри Банка отправителя денег без взаимодействия с Платформой. Т.е. если счет бенефициара, указанный в QR-коде, также обслуживается в данном банке, то производится внутрибанковская операция.

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

Схему успешного сценария процесса «Инициализация оплаты по QR-коду (C2B2)» отображает рисунок ниже.

Схема процесса «Инициализация оплаты по QR-коду (C2B2)»

Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено в электронном формате в https://transfers-openapi.npck.kz/.

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

Метод API (endpoint)	Банк отправителя денег	Банк бенефициара
Запрос данных по QR-коду для оплаты (POST /v1/transfers/iso20022/admi.009.001.02)		+
Данные для оплаты (POST /v1/transfers/iso20022/admi.010.001.02)	+
Запрос на перевод денег (POST /v1/transfers/iso20022/pacs.008.001.11)		+
Статус обработки запроса перевода денег (POST /v1/transfers/iso20022/pacs.002.001.13)	+	+

Взаимосвязь идентификаторов сообщений

Процесс «Инициализация оплаты по QR-коду (C2B2)» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

Логическая схема взаимосвязи идентификаторов сообщений

Описание процесса

Описание успешного сценария процесса «Инициализация оплаты по QR-коду (C2B2)»:

Генерация и считывание QR-кода для оплаты

1. POS-терминал направляет данные о платеже в Банк бенефициара

Для статического QR-кода данный шаг не применяется

2. Банк бенефициара формирует данные для QR-кода для оплаты

3. Отправитель денег в приложении Банка отправителя денег сканирует QR-код в POS-терминале или статический QR-код

Важно! Если отсканированный QR-код выпущен самим Банком отправителя денег, то оплата производится внутри Банка отправителя денег без взаимодействия с Платформой. Т.е. если счет бенефициара, указанный в QR-коде, также обслуживается в данном банке, то производится внутрибанковская операция.

4. Банк отправителя денег направляет Платформе запрос данных для оплаты (сообщение admi.009), по ссылке из QR-кода, подписав его своим ЭЦП

В сообщении передается:

• в теге <Document:MsgId> – сгенерированный уникальный идентификатор нового сообщения

• в теге <Document:SplmtryData:PlcAndNm> с ключом END_TO_END_ID – сгенерированный уникальный идентификатор, который будет выступать в качестве сквозного идентификатора для всей цепочки сообщений в рамках данной операции оплаты

Возможные неуспешные сценарии

• Платформа не отвечает:

1. Банк отправителя денег завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

2. Процесс завершается неуспешно.

• Валидация сообщения не прошла успешно:

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.

2. Процесс завершается неуспешно.

4.1. Платформа, получив запрос, проводит его валидацию, в том числе:

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

• проверяет корректность заполнения полей

5. Платформа направляет в Банк бенефициара запрос данных для оплаты (сообщение admi.009), подписав его ЭЦП Платформы

В сообщении передается:

• в теге <Document:MsgId> – сгенерированный уникальный идентификатор нового сообщения

• в теге <Document:SplmtryData:PlcAndNm> с ключом END_TO_END_ID –

сквозной идентификатор из сообщения admi.009 Банка отправителя денег

Возможные неуспешные сценарии

• Банк бенефициара не отвечает:

1. Если Банк бенефициара не направляет ответ, то Платформа должна считать, что запрос не доставлен.

2. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

3. Платформа направляет в Банк отправителя сообщение admi.010 с ошибкой ADMI_010_RECEIVER_BANK_ERROR.

4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.

5. Процесс завершается неуспешно.

• Валидация сообщения не прошла успешно:

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.

2. Платформа направляет в Банк отправителя сообщение admi.010 с ошибкой ADMI_010_RECEIVER_BANK_ERROR.

3. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.

4. Процесс завершается неуспешно.

5.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

• проверяет подпись Платформы

• проверяет корректность заполнения полей

• выполняет поиск данных по QR-коду, производит сверку контрольной суммы с данными из полученного сообщения admi.009

6. Банк бенефициара направляет данные для оплаты Платформе (сообщение admi.010), подписав его своим ЭЦП

В сообщении передается:

• в теге <Document:MsgId> – сгенерированный уникальный идентификатор нового сообщения

• в теге <Document:RptDtls:ReqRef> – сквозной идентификатор из тега <Document::SplmtryData:PlcAndNm> с ключом END_TO_END_ID исходного запроса (admi.009)

Возможные неуспешные сценарии

• Платформа не отвечает:

1. Если Платформа не направляет ответ, то Банк бенефициара должен считать, что запрос не доставлен.

2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

• Валидация сообщения не прошла успешно:

1. Валидация сообщения не проходит успешно, Платформа направляет Банку бенефициара ответ с соответствующим ошибке HTTP статусом.

2. Банк бенефициара завершается процесс с ошибкой.

3. Банк отправителя денег завершает процесс по тайм-ауту.

4. Процесс завершается неуспешно.

6.1. Платформа, получив ответ, проводит его валидацию, в том числе:

• проверяет подпись Банка бенефициара

• проверяет корректность заполнения полей

7. Платформа направляет данные для оплаты в Банк отправителя денег (сообщение admi.010), подписав его ЭЦП Платформы

В сообщении передается:

• в теге <Document:MsgId> – сгенерированный уникальный идентификатор нового сообщения

• в теге <Document:RptDtls:ReqRef> – сквозной идентификатор из тега <Document::SplmtryData:PlcAndNm> с ключом END_TO_END_ID исходного запроса (admi.009)

Возможные неуспешные сценарии

• Банк отправителя денег не отвечает:

1. Если Банк отправителя денег не направляет ответ, то Платформа должна считать, что запрос не доставлен.

2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

7.1. Банк отправителя денег, получив ответ, проводит его валидацию, в том числе:

• проверяет подпись Платформы

• проверяет корректность заполнения полей

8. Отправителю денег в приложении Банка отправителя денег отображается информация о платеже, он выбирает счет для оплаты и подтверждает проведение оплаты.

Транзакция по проведению платежа

9. Банк отправителя денег проводит проверку счета клиента на:

• валидность статуса для его дебетования

• отсутствие наложенного ПТП/ РПРО/ ареста и т.п.

• достаточности средств для списания суммы операции

Возможные неуспешные сценарии

• Проверка счета не прошла успешно:

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

2. Процесс завершается неуспешно

10. Банк отправителя денег блокирует сумму операции по счету клиента и формирует платежное поручение (pacs.008).

11. Банк отправителя денег направляет Платформе запрос на проведение оплаты (сообщение pacs.008), подписав его своим ЭЦП.

В сообщении передается:

• в теге <Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения

• в теге <Document::PmtId:EndToEndId> – сгенерированный уникальный сквозной идентификатор

• в поле <Document::PmtId:TxId> – сгенерированный уникальный идентификатор новой транзакции

• указывается IBAN для счета Отправителя денег

• указывается IBAN для счета Бенефициара

Возможные неуспешные сценарии

• Платформа не отвечает:

1. Если Платформа не направляет ответ, то Банк отправителя денег должен считать, что запрос не доставлен.

2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

• Валидация сообщения не прошла успешно:

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.

2. Процесс завершается неуспешно.

11.1. Платформа, получив запрос, проводит его валидацию, в том числе:

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

• проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

12. Платформа обрабатывает запрос на проведение оплаты (сообщение pacs.008), в том числе:

• выполняет проверку позиций участников и лимитов;

• выполняет блокирование средств для проведения транзакции.

Возможные неуспешные сценарии

• Обработка запроса на перевод денег pacs.008 Платформой не проходит успешно:

1. Платформа направляет статус обработки запроса на проведение оплаты в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).

2. Процесс завершается неуспешно.

13. Платформа направляет в Банк бенефициара запрос на проведение оплаты (сообщение pacs.008), подписав его ЭЦП Платформы.

В сообщении передается:

• в теге <Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения

• в теге <Document::PmtId:EndToEndId> – сквозной идентификатор из тега <EndToEndId> сообщения pacs.008 Банка отправителя денег

• в поле <Document::PmtId:TxId> – идентификатор транзакции из тега <TxId> из сообщения pacs.008 Банка отправителя денег

• указывается IBAN для счета Отправителя денег из сообщения pacs.008 Банка отправителя денег

• указывается IBAN для счета Бенефициара из сообщения pacs.008 Банка отправителя денег

Возможные неуспешные сценарии

• Банк бенефициара не отвечает:

1. Если Банк бенефициара не направляет ответ, то Платформа должна считать, что запрос не доставлен.

2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

3. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

4. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой PACS_002_BENEFICIARY_BANK_ERROR.

5. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.

6. Процесс завершается неуспешно.

• Валидация сообщения не прошла успешно:

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.

2. Платформа устанавливает статус транзакции RJCT (отклонена).

3. Платформа направляет в Банк отправителя сообщение pacs.002 со статусом транзакции RJCT (отклонена) с ошибкой PACS_002_BENEFICIARY_BANK_ERROR.

4. Банк отправителя денег, получив сообщение pacs.002 со статусом транзакции RJCT (отклонена), устанавливает статус транзакции RJCT (отклонена).

5. Процесс завершается неуспешно.

13.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

• проверяет подпись Платформы;

• проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

14. Банк бенефициара направляет информацию о том, что qr-код считан на POS-терминал

15. Банк бенефициара проверяет счет бенефициара на возможность зачисления денег

16. Банк бенефициара направляет статус обработки запроса проведения оплаты Платформе (сообщение pacs.002), подписав его своим ЭЦП.

В сообщении передается:

• <Document::OrgnlEndToEndId> – сквозной идентификатор из тега <EndToEndId> исходного запроса (pacs.008)

• <Document::OrgnlTxId> – идентификатор транзакции из тега <TxId> исходного запроса (из pacs.008)

• Статус транзакции PDNG (в обработке)

Возможные неуспешные сценарии

• Платформа не отвечает:

1. Если Платформа не направляет ответ, то Банк бенефициара должен считать, что запрос не доставлен.

2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

• Валидация сообщения не прошла успешно:

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).

2. Платформа устанавливает статус транзакции RJCT (отклонена).

3. Платформа направляет в Банк отправителя сообщение pacs.002 со статусом транзакции RJCT (отклонена) с ошибкой PACS_002_BENEFICIARY_BANK_ERROR.

4. Банк отправителя денег, получив сообщение pacs.002 со статусом транзакции RJCT (отклонена), устанавливает статус транзакции RJCT (отклонена).

5. Процесс завершается неуспешно.

• Транзакция отклонена (статус транзакции RJCT):

1. Банк бенефициара направляет Платформе статус обработки запроса проведения оплаты (сообщение pacs.002) - RJCT (отклонена).

2. Платформа направляет статус обработки запроса проведения оплаты в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).

3. Процесс завершается неуспешно.

16.1. Платформа, получив запрос, проводит его валидацию, в том числе:

• проверяет подпись Банка бенефициара;

• проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

17. Платформа направляет статус обработки запроса проведения оплаты в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

В сообщении передается:

• в теге <Document::OrgnlEndToEndId> – сквозной идентификатор из тега <EndToEndId> исходного запроса (pacs.008)

• в теге <Document::OrgnlTxId> – идентификатор транзакции из тега <TxId> исходного запроса (из pacs.008)

• Статус транзакции PDNG (в обработке)

Возможные неуспешные сценарии

• Банк отправителя денег не отвечает:

1. Если Банк отправителя денег не направляет ответ, то Платформа должна считать, что запрос не доставлен.

2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

17.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

• проверяет подпись Платформы;

• проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

18. Платформа успешно завершает транзакцию (commit transaction).

19. Платформа направляет в качестве уведомления об успешной транзакции в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

Возможные неуспешные сценарии

• Банк бенефициара не отвечает:

1. Если Банк бенефициара не направляет ответ, то Платформа должна считать, что запрос не доставлен.

2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

19.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

• проверяет подпись Платформы;

• проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

Примечание: Если Платформа направляет в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк бенефициара не производит (не производит повторное зачисление денег на счет бенефициара и т.д.), а лишь отправляет ответ с HTTP статусом 200

Возможные неуспешные сценарии

• Банк бенефициара не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):

1. Банк бенефициара ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк бенефициара в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов) завершает транзакцию неуспешно (RJCT) по тайм-ауту, зачисление средств бенефициару не производится. Платформа производит откат транзакции, устанавливает статус транзакции - RJCT (неуспешно). Банк отправителя денег, получив статус транзакции RJCT (неуспешно), разблокирует средства Отправителя денег, списание средств не производится.

19.2. Банк бенефициара производит зачисление денег на счет бенефициара и направляет информацию об этом на POS-терминал.

20. Платформа направляет в качестве уведомления об успешной транзакции в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

Возможные неуспешные сценарии

Банк отправителя денег не отвечает:

1. Если Банк отправителя денег не направляет ответ, то Платформа должна считать, что запрос не доставлен.

2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

20.1. Банк отправителя денег, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

• проверяет подпись Платформы;

• проверяет корректность заполнения полей.

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

Примечание: Если Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк отправителя денег не производит (не производит повторное списание денег со счета отправителя денег и т.д.), а лишь отправляет ответ с HTTP статусом 200

Возможные неуспешные сценарии

• Банк отправителя денег не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):

1. Банк отправителя денег ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом(см. Тайм-ауты и логика повторных запросов).

2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк отправителя денег направляет запрос статуса транзакции Платформе (сообщение pacs.028, см. Сервис получения статуса обработки транзакции), подписав его своим ЭЦП.

3. Платформа, успешно выполнив обработку запроса, направляет ответ с HTTP статусом 200.

4. Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции, подписав его ЭЦП Платформы.

20.2. Банк отправителя денег производит списание денег со счета отправителя денег и уведомляет его о завершении операции.