Направление работ: Back
Код раздела: 5.2 Платежи > Сценарии и Методы оплаты
Статус: Готов
Ответственный: Панкова Л.А.
Версия: 0.2
Обновлено: 02.10.26
1. Назначение
Сценарии оплаты задают порядок инициации, подтверждения и отмены Платежа, связанные уведомления и изменения оплачиваемых сущностей.
Методы оплаты определяют допустимые способы выполнения финансовых обязательств Плательщика перед Получателем платежа и совместимость каждого способа со Сценариями оплаты.
Раздел также задает последовательность Платежной операции, ее Статусы и Типы, которые хранятся только в составе Платежного документа.
2. Ключевые понятия
Сценарий оплаты — допустимый платформой порядок инициации, подтверждения и отмены Платежа, отправки уведомлений и изменения связанных сущностей.
Метод оплаты — допустимый платформой способ выполнения финансовых обязательств Плательщика перед Получателем платежа.
Объект оплаты — оплачиваемая сущность, для которой Канал оплаты определяет допустимые Сценарии и Методы.
Платежный документ — сущность, в составе которой хранятся виртуальные Статус и Тип Платежа.
Баллы — дополнительный учетный Метод, который не участвует в самом Платеже, но фиксируется в Платежном документе как предоставленная Получателем скидка.
3. Scope
Входит
S1 Сценарии оплаты: три допустимых Сценария, порядок инициации и выполнения Платежа, связанные уведомления и изменения Объектов оплаты.
S2 Методы оплаты: пять реализованных основных Методов, будущий Метод «Депозит», дополнительный Метод «Баллы» и совместимость Методов со Сценариями.
S3 Статусы и Типы Платежа: допустимые значения, правила их применения, Холдирование и Выплата для Заказов и Сборов, будущий Тип операции «Пополнение депозита».
S4 Порядок Платежной операции: последовательность выбора Канала, Объекта, Сценария, Метода, Типа и переходов Статуса Платежного документа.
Не входит
- Back: 5.1 Каналы и Объекты оплаты — параметры Канала, перечень Объектов и маршрутизация между Сторонами
- Back: 5.3 Сценарии возврата — детальные правила возврата ранее оплаченных средств
- Back: 5.4 Платежные документы — состав, создание и жизненный цикл Платежного документа
- Back: 5.5 Провайдеры онлайн оплат — интеграция инструментов онлайн-оплаты и Торговых терминалов
- Back: 7.1 Шаблоны уведомлений и список событий — содержание шаблонов и каталог событий
- Back: 2.8 Настройки партнерской зоны — параметры приема онлайн-платежей и срок оплаты
- Back: 8.4.2 Настройки балльной системы — учет Баллов платформы
- Back: 2.7.3 Скидки баллами — применение Баллов в качестве скидки
4. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе.
| ID | Требование | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1: BR5.2-1 | Сценарий оплаты должен определять порядок инициации, подтверждения и отмены Платежа, а также связанные уведомления и изменения Объектов оплаты | Связи: - шаблоны отправляемых уведомлений определяются в Back: 7.1 Шаблоны уведомлений и список событий - состав Объектов оплаты определяется в Back: 5.1 Каналы и Объекты оплаты | Бизнес | 1 | Частично OQ5.2-1, OQ5.2-2 |
| S1: BR5.2-2 | Платформа должна поддерживать три Сценария оплаты | Допустимые Сценарии: 1. На месте — Платеж совершается вне платформы и выполняется вследствие завершения процессинга сущности, связанной с Объектом оплаты 2. Онлайн в интерфейсе — Платеж проводится интегрированными в платформу инструментами и выполняется вследствие прохождения определенных этапов процессинга связанной сущности 3. По инструкции — Платеж совершается вне платформы с частичной интеграцией в процессинг; инициируется вследствие прохождения определенных этапов процессинга связанной сущности, а выполняется после подтверждающих действий Плательщика и Получателя платежа | Бизнес | 1 | Частично OQ5.2-1, OQ5.2-2 |
| S2: BR5.2-3 | Платформа должна поддерживать пять реализованных основных Методов оплаты и их совместимость со Сценариями | Допустимые Методы: 1. Наличные — передача Получателю платежа необходимой суммы наличными; доступен только для Сценария «На месте» 2. Перевод — прямой перевод необходимой суммы на банковскую карту Получателя платежа; доступен для Сценариев «На месте» и «По инструкции» 3. Карта — применение банковской карты для оплаты необходимой суммы через терминал Получателя платежа; доступен для Сценариев «На месте» и «Онлайн в интерфейсе» 4. СБП — перевод по Системе быстрых платежей или оплата по QR-коду необходимой суммы через терминал Получателя платежа; доступен для любого Сценария 5. Счет — оплата выставленного Получателем платежа счета на необходимую сумму; доступен для Сценария «По инструкции» | Бизнес | 1 | Частично OQ5.2-1, OQ5.2-3, OQ5.2-7, OQ5.2-9 |
| S2: BR5.2-4 | Метод оплаты «Счет» должен быть доступен для Сценария «Онлайн в интерфейсе» (после релиза реализация) | В гайдбуке совместимость Метода «Счет» со Сценарием «Онлайн в интерфейсе» выделена красным | Бизнес | 3 | Не реализовано OQ5.2-7 |
| S2: BR5.2-5 | Платформа должна поддерживать Метод оплаты «Депозит» для списания необходимой суммы с ранее пополненного баланса Плательщика в пользу Получателя платежа (после релиза реализация) | Гайдбук указывает, что в текущей версии реализовано пять из шести основных Методов оплаты, и выделяет «Депозит» красным. Допустимые Сценарии и Объекты для Метода в гайдбуке не определены | Бизнес | 3 | Не реализовано OQ5.2-8 |
| S2: BR5.2-6 | Баллы должны учитываться как дополнительный Метод при создании Платежного документа, но не должны участвовать в самом Платеже и связываться со Сценарием оплаты | Баллы списываются с баланса Плательщика в счет скидки, предоставленной Получателем платежа, фиксируются в глобальных данных по Платежам и являются внутренней валютой, реализуемой через Back: 2.7.3 Скидки баллами. Балльная система определяется в Back: 8.4.2, отражение в документе — в Back: 5.4 | Бизнес | 1 | Частично OQ5.2-6 |
| S3: BR5.2-7 | Платежный документ должен хранить один из шести Статусов Платежа | Допустимые Статусы: - Ожидает выполнения — Платежный документ создан, но еще не оплачен - Выполняется — Платеж выполняется в среде Провайдера онлайн оплат; применяется только для Сценария «Онлайн в интерфейсе» - Просрочен — истек срок оплаты, установленный в параметрах приема онлайн-платежей из Back: 2.8 Настройки партнерской зоны; применяется только для Сценария «Онлайн в интерфейсе» - Ошибка — при проведении Платежа в среде Провайдера онлайн оплат возникла ошибка; применяется только для Сценария «Онлайн в интерфейсе» - Отменен — оплата отменена пользователем - Выполнен — оплата прошла успешно | Системное | 1 | Частично OQ5.2-4 |
| S3: BR5.2-8 | Платежный документ должен хранить один из четырех реализованных Типов Платежа | Допустимые Типы: - Оплата — денежные средства по Объекту оплаты из Back: 5.1 сразу поступают Получателю платежа - Холдирование — для Объектов «Заказ» и «Сбор» денежные средства замораживаются в среде Провайдера онлайн оплат - Выплата — для Объектов «Заказ» и «Сбор» ранее холдированные денежные средства размораживаются и поступают Получателю платежа - Возврат — денежные средства возвращаются Плательщику; правила определяются в Back: 5.3 Сценарии возврата | Системное | 1 | Частично OQ5.2-5 |
| S3: BR5.2-9 | Платежный документ должен поддерживать Тип Платежа «Пополнение депозита» для фиксации денежных средств на балансе Пользователя с целью их использования в будущих Платежных операциях (после релиза реализация) | Гайдбук выделяет «Пополнение депозита» красным, а на схеме показывает перечеркнутый Тип «Депозит» с пометкой «Не реализован» | Системное | 3 | Не реализовано OQ5.2-8 |
| S4: BR5.2-10 | Платежная операция должна выполняться только по допустимой комбинации Объекта, Сценария, Метода, Типа и Статуса | Последовательность: инициация Платежа → Канал оплаты → Объект оплаты → Сценарий оплаты → Метод оплаты → Тип Платежа → Платежный документ → Статус «Ожидает выполнения» или «Выполняется» для онлайн-оплаты → итоговый Статус. Матрица из схемы гайдбука: - На месте — Объекты «Заказ», «Абонемент», «Сбор»; Методы «Наличные», «Карта», «СБП», «Перевод» - Онлайн в интерфейсе — все Объекты оплаты; Методы «Карта», «СБП», а также «Счет» после реализации BR5.2-4 - По инструкции — Объекты «Заказ», «Абонемент», «Сбор»; Методы «СБП», «Перевод», «Счет» - Типы текущей реализации — «Оплата», «Холдирование», «Выплата» и «Возврат»; Холдирование и Выплата применяются только к Заказам и Сборам - Будущий Тип — «Пополнение депозита» из BR5.2-9; на схеме обозначен как «Депозит — не реализован» - Итоговые Статусы — «Выполнен», «Просрочен», «Отменен» или «Ошибка» | Системное | 1 | Частично OQ5.2-1, OQ5.2-3, OQ5.2-5 |
5. Открытые вопросы
Первая сверка с кодом (05.10.2026): BRD 5.2 v0.2 · репозиторий
booking-monorepo· commit16e24036/main(последний мердж 14.09.2026) · 2026-10-05 · якорьsrc/services/TinkoffPayments(Платежный документ, Канал оплаты, провайдер),src/services/booking.orders(создание оплаты заказа, ссылка на оплату, обработка документов),src/services/booking.partner-management(настройки оплаты и проверка способа оплаты),src/libs/booking.domain.abstractions/.../Enums/Payments(перечни Сценариев, Методов, Объектов, Статусов),src/services/booking.notifications/.../Features/Orders, шлюзTinkoffController. Гайдбук на вход не передавался — маршрутизация без сверки с гайдбуком. Сводка: 10 вопросов (Open 10 · Бизнесу 5 · Разработке 5). Перечни трех Сценариев и пяти Методов (плюс «Баллы») в коде есть, но ход оплаты определяется Методом, а не Сценарием, и матрица совместимости нигде не проверяется. Из Статусов нет «Выполняется» и «Просрочен», а «Ошибка» и «Отменен» не ставятся; поля «Тип» нет, Холдирования и Выплаты нет; «Счет», «Баллы» и «Депозит» в Платежных документах не используются. Обратный проход: 4 находки вынесены в OQ5.2-9 и OQ5.2-10, 2 отрезаны как не относящиеся к разделу (событие Канала оплаты передает Сценарий в поле «статус» и теряет «На месте» → Back 5.1; живые обработчики платежей помечены «не используется» — техуборка).
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ5.2-1 | Код BR5.2-1, BR5.2-2, BR5.2-3 | Требование говорит: порядок инициации, подтверждения и отмены Платежа задает Сценарий оплаты; «Карта» и «СБП» допустимы и в Сценарии «На месте» (через терминал Получателя платежа), «СБП» — еще и «По инструкции». В коде ход оплаты заказа определяется Методом, а не Сценарием: «Наличные» и «Перевод» партнер сразу записывает как выполненный платеж (Сценарий берется из настройки оплаты); «Карта» и «СБП» всегда запускают онлайн-оплату через провайдера, и в Платежный документ жестко пишется «Онлайн в интерфейсе», даже если в настройке стоит «На месте»; остальные Методы отбиваются ошибкой. Поэтому отметить оплату картой или по СБП через терминал на площадке, а также СБП по инструкции нельзя. Уведомления выбираются то по Методу (об оплате), то по Сценарию (о брони и об отмене). Из изменений Объекта оплаты, зависящих от Сценария, найдено одно: у заказа с онлайн-оплатой нельзя сменить способ оплаты. \ src/services/booking.orders/src/Orders.Application/Commands/Orders/CreatePayment/CreateOrderPaymentCommandHandler.cs:205-264, 267-334, 336, src/services/TinkoffPayments/Application/Handlers/PaymentDocuments/InitOnlinePayment/InitOnlinePaymentCommandHandler.cs:137, src/services/booking.notifications/src/Booking.Notifications/Features/Orders/OrderPayed/OrderPayedEventConsumer.cs:80-132, src/services/booking.notifications/src/Booking.Notifications/Features/Orders/OrderCancelled/OrderCancelledNotificationsConsumer.cs:65-83, src/services/booking.orders/src/Orders.Domain/OrdersAggregate/OrderAggregate.cs:574-577 | Бизнес | Open | (А) развести ход оплаты по Сценарию: «На месте» — ручная запись для любого из четырех Методов (в том числе Карта и СБП через терминал партнера), «Онлайн в интерфейсе» — через провайдера, «По инструкции» — с ожиданием подтверждения (OQ5.2-2). Рекомендуется: без этого матрица BR5.2-3 невыполнима. (Б) зафиксировать в BRD текущую модель: Карта и СБП — только онлайн. Решение разблокирует OQ5.2-3. | ОТ БИЗНЕСА: А. Привязать порядок оплаты к сценариям. Способы/методы оплаты указываются в дополнение к сценарию: для «На месте» — справочно, для «Онлайн» и «По инструкции» возможна частичная автоматизация исходя из переданного Метода оплаты (OQ5.2-9). Вес 1. |
| OQ5.2-2 | Код BR5.2-2, BR5.2-1 | Требование говорит: при Сценарии «По инструкции» Платеж совершается вне платформы, инициируется на определенном этапе процессинга, а выполняется после подтверждающих действий и Плательщика, и Получателя платежа. В коде при запросе оплаты по инструкции клиенту возвращается только ссылка на инструкцию — Платежный документ не создается. Документ появляется, только когда партнер сам регистрирует оплату «Переводом», и сразу в статусе «Выполнен» с ручным форматом. Шага «клиент сообщил об оплате → партнер подтвердил» и документа в ожидании нет. \ src/services/booking.orders/src/Orders.Application/Commands/Orders/GetPaymentLink/GetPaymentLinkMobileCommandHandler.cs:191-197, src/services/booking.orders/src/Orders.Application/Commands/Orders/CreatePayment/CreateOrderPaymentCommandHandler.cs:205-263, src/services/TinkoffPayments/Presentation/Controllers/Grpc/TinkoffPaymentsService.cs:82-87 | Бизнес | Open | (А) при выдаче инструкции создавать документ «Ожидает выполнения»; клиент отмечает «оплатил», партнер подтверждает — документ переходит в «Выполнен». Рекомендуется: так сходятся и Сценарий, и Статусы BR5.2-7. (Б) поправить BRD: подтверждает только Получатель платежа, документ создается по факту регистрации оплаты. Связать с OQ5.2-1. | ОТ БИЗНЕСА: А. Добавить стадию подтверждения платежа для оплат «По инструкции». Текущую реализацию можно оставить, если у используемой в проведении платежа инструкции в настройках партнерской зоны (Back: 2.8) не заданы тайминги подтверждения. Вес 2. |
| OQ5.2-3 | Код BR5.2-10, BR5.2-3 | Требование говорит: Платежная операция выполняется только по допустимой комбинации Объекта, Сценария, Метода, Типа и Статуса: «На месте» — Наличные, Карта, СБП, Перевод; «Онлайн в интерфейсе» — Карта и СБП; «По инструкции» — СБП, Перевод, Счет. В коде эта матрица нигде не проверяется. Канал оплаты сохраняет любые наборы Сценариев и Методов; настройка оплаты партнера не сверяет свой Сценарий со Сценариями Канала; при оплате Метод сверяется только со списком Методов Канала, а если в Канале Методы не заданы — разрешены все шесть, включая «Счет» и «Баллы». Онлайн-инициация не проверяет, что Канал допускает Сценарий «Онлайн» и Объект «Заказ». В итоге возможна, например, запись «Наличные» со Сценарием «Онлайн в интерфейсе». Отдельный Сбор (вне заказа) оплачивается только онлайн: ручная регистрация на месте или по инструкции всегда пишет Объект «Заказ». \ src/services/TinkoffPayments/Domain/Aggregates/PaymentChannel/PaymentChannelAggregate.cs:103-143, 189-238, src/services/booking.partner-management/src/PartnerZones.Application/Commands/PaymentSettings/Create/CreatePaymentSettingCommandHandler.cs:55-89, src/services/booking.partner-management/src/PartnerZones.Application/Queries/PaymentFilters/ValidatePaymentFilterAndGetTtl/ValidatePaymentFilterAndGetTtlQueryHandler.cs:150-156, src/services/booking.partner-management/src/PartnerZones.Persistence/PaymentSettings/Repositories/PaymentSettingsReadOnlyRepository.cs:152-158, src/services/TinkoffPayments/Application/Handlers/PaymentDocuments/InitOnlinePayment/InitOnlinePaymentCommandHandler.cs:53-70, src/services/TinkoffPayments/Presentation/Controllers/Grpc/TinkoffPaymentsService.cs:68, src/services/TinkoffPayments/Application/Handlers/PaymentDocuments/InitForfeitOnlinePayment/InitForfeitOnlinePaymentCommandHandler.cs:117-119 | Разработка | Open | Завести тикет в Bitrix: одна общая проверка матрицы Сценарий × Метод × Объект (рядом с перечнями в общей библиотеке) — при сохранении Канала и настройки оплаты и при создании Платежного документа; пустой список Методов в Канале считать «ничего не разрешено», а не «разрешено все». Делать после решения по OQ5.2-1 — от него зависит, какие Методы реально проходят «На месте». | ОТ БИЗНЕСА: Реализовать матрицу допустимых соответствий при инициализации платежа. Вес 1. |
| OQ5.2-4 | Код BR5.2-7 | Требование говорит: Платежный документ хранит один из шести Статусов: «Ожидает выполнения», «Выполняется», «Просрочен» (истек срок оплаты из настроек партнерской зоны), «Ошибка», «Отменен», «Выполнен». В коде у документа пять значений: «Ожидает», «Выполнен», «Ошибка», «Отменен» и лишнее «Возвращен»; «Выполняется» и «Просрочен» нет — онлайн-документ создается сразу в «Ожидает». «Ошибка» и «Отменен» нигде не ставятся: сообщение банка о неуспешной оплате шлюз публикует, но подписчика на него не найдено за обход всех сервисов, и документ остается «Ожидает» навсегда; даже неудавшийся возврат записывается как «Возвращен». Ссылка на оплату живет жестко 5 минут, а срок оплаты из настройки партнера применяется только к брони, не к документу. Другим сервисам «Ошибка» и «Отменен» передаются как «Ожидает» — в общем перечне всего три статуса. \ src/services/TinkoffPayments/Domain/Enums/PaymentDocument/PaymentStatus.cs:3-10, src/services/TinkoffPayments/Application/Handlers/PaymentDocuments/InitOnlinePayment/InitOnlinePaymentCommandHandler.cs:153, src/services/booking.apigateway/Musbooking.ApiGateway/Controllers/TinkoffController.cs:74-85, src/services/TinkoffPayments/Infrastructure/Consumers/OrderCancelledEventConsumer.cs:124-183, 220, src/services/TinkoffPayments/Infrastructure/Services/TinkoffPaymentService.cs:365, src/services/booking.partner-management/src/PartnerZones.Persistence/PaymentFilters/Repositories/PaymentFiltersReadOnlyRepository.cs:232, src/services/TinkoffPayments/Domain/Aggregates/PaymentDocument/PaymentDocumentAggregate.cs:249-256, src/libs/booking.domain.abstractions/src/Booking.Domain.Abstractions/AggregateRoot/Enums/Payments/PaymentStatus.cs:3-8 | Разработка | Open | Завести тикет в Bitrix: добавить Статусы «Выполняется» (после перехода клиента к оплате у провайдера) и «Просрочен» (по сроку оплаты из настройки партнера, этот же срок отдавать провайдеру вместо 5 минут); обработать сообщение банка о неуспешной оплате → «Ошибка», отмену → «Отменен», неудавшийся возврат не помечать «Возвращен»; передавать все Статусы другим сервисам без схлопывания. Судьбу «Возвращен» как Статуса решить вместе с OQ5.2-5. | ОТ БИЗНЕСА: Реализовать статусы в соответствии с требованием и рекомендациями. Вес 1. |
| OQ5.2-5 | Код BR5.2-8, BR5.2-10 | Требование говорит: Платежный документ хранит один из четырех реализованных Типов: «Оплата», «Холдирование» (для Заказов и Сборов деньги замораживаются у провайдера), «Выплата» (замороженные деньги поступают Получателю), «Возврат». В коде поля «Тип» у Платежного документа нет. «Оплата» — любой документ по умолчанию, «Возврат» — отдельный документ со Статусом «Возвращен». Холдирования и Выплаты не найдено за обход: оплата у провайдера одностадийная — вызываются только создание платежа, списание по сохраненной карте, отмена с возвратом и получение QR; признака двухстадийной оплаты и подтверждения списания нет, сообщение банка обрабатывается только для итогового «подтвержден». \ src/services/TinkoffPayments/Domain/Aggregates/PaymentDocument/PaymentDocumentAggregate.cs:28-180, src/services/TinkoffPayments/Infrastructure/Consumers/OrderCancelledEventConsumer.cs:195-226, src/services/TinkoffPayments/Infrastructure/Services/TinkoffPaymentService.cs:85, 135, 187, 239, src/services/TinkoffPayments/Infrastructure/Services/Tinkoff/Models/Requests/Init/InitTinkoffRequest.cs:13-27, src/services/booking.apigateway/Musbooking.ApiGateway/Controllers/TinkoffController.cs:87-88, 164 | Бизнес | Open | (А) поправить BRD: «Холдирование» и «Выплата» — «после релиза реализация», как Депозит; поле «Тип» в документе завести уже сейчас для «Оплаты» и «Возврата» (тогда «Возвращен» уходит из Статусов). Рекомендуется: BRD перестанет обещать то, чего в системе нет. (Б) если холдирование нужно сейчас (маршрут Заказ/Сбор → Комиссия из Back 5.1) — отдельная задача: двухстадийная оплата у провайдера, Выплата по завершении процессинга, поле «Тип». В невлитых ветках работ по платежному сервису после 14.09 нет. | ОТ БИЗНЕСА: Б. Реализовать холдирование и связанные с данным порядком проведения платежа данные в Back: 5.4, Back: 5.5 и Back: 5.5.1. Вес 1. |
| OQ5.2-6 | Код BR5.2-6 | Требование говорит: Баллы — дополнительный Метод: при создании Платежного документа фиксируются как скидка Получателя платежа, но в самом Платеже не участвуют и к Сценарию не привязаны. В коде значение «Баллы» в перечне Методов есть, но нигде не используется. Баллы учитываются в расчете заказа и уменьшают его цену — в Платеже они не участвуют и к Сценарию не привязаны, это совпадает. Но в Платежный документ Баллы не попадают: ни записи с Методом «Баллы», ни поля с суммой списанных баллов в документе нет. \ src/libs/booking.domain.abstractions/src/Booking.Domain.Abstractions/AggregateRoot/Enums/Payments/PaymentMethod.cs:10, src/services/booking.orders/src/Orders.Domain/Common/ValueObjects/CalculationInfo.cs:15-16, 25, src/services/TinkoffPayments/Domain/Aggregates/PaymentDocument/PaymentDocumentAggregate.cs:120-162 | Разработка | Open | (А) при создании Платежного документа по заказу добавлять запись с Методом «Баллы» и суммой списанных баллов (без провайдера, сразу «Выполнен») — значение в перечне уже есть. Рекомендуется: меньше всего правок. (Б) поле «списано баллами» в самом документе. Формат согласовать с Back 5.4, затем завести тикет в Bitrix. | ОТ БИЗНЕСА: А. Реализовать списание баллов с фиксацией в платежном документе отдельным способом оплаты. Вес 1. |
| OQ5.2-7 | Код BR5.2-3, BR5.2-4 | Требование говорит: «Счет» — один из пяти реализованных Методов, доступен для Сценария «По инструкции»; для «Онлайн в интерфейсе» — после релиза (BR5.2-4). В коде значение «Счет» в перечне есть, но оплатить им заказ нельзя ни в одном Сценарии: при создании оплаты все, кроме Наличных, Перевода, Карты и СБП, отбивается ошибкой «Не удалось определить метод оплаты»; выставления счета не найдено за обход. Поле документа, описанное как «идентификатор счета для Метода «Счет»», на деле заполняется аккаунтом пользователя, создавшего платеж. \ src/libs/booking.domain.abstractions/src/Booking.Domain.Abstractions/AggregateRoot/Enums/Payments/PaymentMethod.cs:9, src/services/booking.orders/src/Orders.Application/Commands/Orders/CreatePayment/CreateOrderPaymentCommandHandler.cs:205, 267, 336, src/services/TinkoffPayments/Domain/Aggregates/PaymentDocument/PaymentDocumentAggregate.cs:127-130, 235, 298 | Бизнес | Open | (А) считать «Счет» по инструкции аналогом «Перевода»: партнер регистрирует оплату счета вручную (точечная правка ветки ручной регистрации), выставление счета — отдельная задача. Рекомендуется: быстро закрывает BR5.2-3. (Б) поправить BRD: «Счет» пока не реализован ни в одном Сценарии. В обоих случаях Разработке — переименовать поле «идентификатор счета» по факту (это автор операции). | ОТ БИЗНЕСА: А. Считать аналогом «Перевода», но использовать метод «Счет» и сценарий «По инструкции». Вес 2. Полная реализация с использованием сценария «Онлайн в интерфейсе» — после релиза. Вес 3. |
| OQ5.2-8 | Код BR5.2-5, BR5.2-9 | Требование говорит: Метод «Депозит» и Тип «Пополнение депозита» — после релиза; допустимые Сценарии и Объекты для Депозита в гайдбуке не определены. В коде ни Метода, ни Типа, ни баланса Плательщика для депозита не найдено за обход (перечни Методов и Статусов, платежный сервис, сервисы заказов и клиентов) — это совпадает с пометкой «после релиза». \ src/libs/booking.domain.abstractions/src/Booking.Domain.Abstractions/AggregateRoot/Enums/Payments/PaymentMethod.cs:3-11, src/services/TinkoffPayments/Domain/Enums/PaymentDocument/PaymentStatus.cs:3-10 | Бизнес | Closed | До постановки в разработку определить: допустимые Сценарии и Объекты для Депозита, кто и как пополняет баланс, возвращается ли остаток и как это отражается в Платежном документе (Back 5.4). Статус «Не реализовано» ожидаем. | ОТ БИЗНЕСА: Метод оплаты «Депозит» в релиз не входит. Вес 3. Вопрос закрываю. |
| OQ5.2-9 | Код (обратный проход) | Что нашли: при онлайн-оплате выбранный пользователем Метод («Карта» или «СБП») в платежный сервис не передается — в контракте инициации поля Метода нет. Сервис сам ставит «СБП», если он разрешен в Канале, иначе «Карта», и именно это пишет в Платежный документ; при «СБП» сразу запрашивается QR. Фактический способ оплаты из сообщения банка не сохраняется. То же при онлайн-оплате Сбора. В требованиях такого правила нет; из-за него Метод в документе может не совпадать с тем, как клиент реально заплатил. \ src/services/booking.orders/src/Orders.Application/Commands/Orders/CreatePayment/CreateOrderPaymentCommandHandler.cs:312-327, src/services/TinkoffPayments/Application/Handlers/PaymentDocuments/InitOnlinePayment/InitOnlinePaymentCommandHandler.cs:61-70, 114-118, 150, src/services/TinkoffPayments/Application/Handlers/PaymentDocuments/InitForfeitOnlinePayment/InitForfeitOnlinePaymentCommandHandler.cs:56-65 | Разработка | Open | Завести тикет в Bitrix: передавать выбранный Метод в инициацию онлайн-оплаты и после оплаты записывать в документ фактический способ из сообщения банка. Иначе отчеты по Методам оплаты недостоверны. | ОТ БИЗНЕСА: Реализовать исходя из возможностей, предоставленных Т-банком (Back: 5.5.1). Вес 2. |
| OQ5.2-10 | Код (обратный проход) | Что нашли: три дефекта платежного контура, которые относятся к соседним разделам. (1) Уведомление о новой брони берет Сценарий из последнего платежа заказа: если оплат еще нет или Сценарий «По инструкции», обработчик завершается ошибкой (Не входит → Back 7.1). (2) После онлайн-оплаты Сбора сервис заказов обрабатывает документ Сбора как оплату заказа и падает на пустой настройке оплаты — сообщение уходит в повторы (Не входит → Back 5.4). (3) Адрес для сообщений банка: если сервис запущен как боевой, в запрос к провайдеру всегда подставляется адрес стенда dev5 (Не входит → Back 5.5). \ src/services/booking.notifications/src/Booking.Notifications/Features/Orders/OrderCreated/OrderCreatedNotificationsConsumer.cs:79-83, 121-126, src/services/booking.orders/src/Orders.Infrastructure/Consumers/Orders/PaymentDocumentUpdatedConsumer.cs:43-63, src/services/TinkoffPayments/Application/Handlers/PaymentDocuments/InitForfeitOnlinePayment/InitForfeitOnlinePaymentCommandHandler.cs:117-120, src/services/TinkoffPayments/Infrastructure/Services/TinkoffPaymentService.cs:386-389 | Разработка | Open | Завести тикеты в Bitrix: (1) уведомление о брони выбирать по Сценарию настройки оплаты заказа, а не по последнему платежу, добавить вариант «По инструкции»; (2) сервису заказов пропускать документы, у которых Объект не «Заказ»; (3) брать адрес сообщений банка из настроек окружения без подстановки dev5. | ОТ БИЗНЕСА: Починить. Вес 2. |