---
# System prepended metadata

title: Интеграция PayKeeper в Динамику

---

# Интеграция PayKeeper в Динамику

## :construction: Вопросы

### Вопросы по логике

1. Самый важный вопрос -- что делать, если во время пока пользователь был занят оплатой, произошло одно из следующих событий:
    * кэш динамики сбросился и тур перестал быть доступен,
    * внешняя услуга перестала быть доступной,
    * цена внешней услуги изменилась?
2. Предоставлять пользователю возможность сделать предоплату добровольно?
3. Что считать триггером для создания бронирования?
    * Пользователь оплатил тур + система приняла уведомление об успешной оплате
    * Пользователь оплатил тур + система приняла уведомление об успешной оплате + система убедилась, что пользователь еще доступен (соединение с пользователем есть и корзина не закрыта)
4. Нужен ли чек 54-ФЗ?

### Проблемы с отказоустойчивостью

#### Проблема с откатом забронированных услуг и возвратом денег
Мы обязаны аннулировать заказанные внешние услуги и вернуть деньги клиенту при ошибке при заказе внешней услуги или любых других проблемах.

Откат уже реализован и при ошибке бронирования в АЦ, ГГ или МТ, заказанные услуги отменятся. Но есть проблемы.

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

Ошибки в этом процессе могут быть вызваны падением сервера динамики, проблем с соединением с удаленным сервером, багов в коде и т.п.

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

#### Потеря уведомления об оплате

Если пользователь оплатил тур и, в момент передачи уведомления, система перестала быть доступна, то мы пропустим факт оплаты. В итоге пользователь останется ни с чем.

#### Решение

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

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

### Вопросы по PayKeeper
1. \[PayKeeper\] нужен тестовый аккаунт где разрешено проводить операции с тестовыми кредитками.
2. \[PayKeeper\] в документации есть упоминания, что есть поддержка двух-этапной работы с платежами как у других шлюзов (т.е. сначала AUTHORIZE --- блокировка средств; затем COMPLETE --- списание).
    Но не ясно как это включить и использовать. В документации по API нашел только упоминания, ничего конкретного. Это где-то конфигурируется? Как этим пользоваться?
