superpos-callback

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

Стек: Node.js, TypeScript, NestJS. Очередь — Bull поверх Redis.

Чего не делает

Не принимает входящие колбеки от банков. Название сервиса вводит в заблуждение, и это самая частая ошибка новичка. Уведомление банка или провайдера о судьбе платежа приходит в ядро и обрабатывается там; здесь живёт только исходящее направление — от нас к мерчанту. Если вы разбираетесь, почему не сработал колбек банка, вам в Колбек от банка.

Не решает, когда и что отправлять: адрес, состав тела и подпись формирует ядро в момент финализации транзакции. Не подписывает уведомление сам. Не заглядывает в транзакцию и не меняет её статус — для него это просто задача с телом и адресом. Не принимает запросы мерчанта.

Входы

• Задачи из очереди колбеков в Redis. В задаче — идентификатор транзакции, адрес мерчанта, готовое тело уведомления вместе с подписью и счётчик попыток.
• Отдельный служебный запрос от ядра: переслать браузерное уведомление 3DS-метода на адрес банка. Формально это тоже исходящая доставка, поэтому досталась этому сервису, но к колбекам мерчанту отношения не имеет.

Выходы

• Адрес мерчанта: уведомление уходит обычным POST в формате формы. Успехом считается любой нормальный ответ; всё остальное — повод повторить.
• Запись о каждой попытке — в общий лог взаимодействий, тот же, в котором видна переписка с банками.

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

Хранилища

Своих данных не держит. Redis — это очередь, из которой сервис читает задачи, а MongoDB ядра — место, куда он дописывает историю отправок. Отдельной базы у сервиса нет.

Участвует во флоу

• Платёж картой server-to-server — последний шаг, уведомление мерчанту о результате.
• Колбек мерчанту — тот же шаг подробно: состав тела, подпись, что делать, когда доставка не удалась.
• Любой другой флоу, который заканчивается результатом для мерчанта: выплаты, возвраты, двухстадийные операции.

Где искать

• Репозиторий: smartpayments-dev/superpos-callback.
• Инфраструктура и логи: карточка сервиса в описании прод-контура.
• Публичная документация: формат колбека мерчанту и логика повторов — ровно то, что этот сервис и делает.
• Постановка задачи в очередь и расчёт подписи — на стороне ядра, в коде финализации транзакции.