ПРО АНАЛИТИКА | СИСТЕМНЫЙ АНАЛИТИК | АЛЕКСАНДР НЕЗДЕМИНА
Образование · 27 августа 2026 г.
ЧТО ДЕЛАТЬ, ЧТОБЫ НЕ СПИСАТЬ БАБЛО ДВА РАЗА ПРИ ИНТЕГРАЦИИ С ВНEШНИМ ШЛЮЗОМ? — 27 августа 2026 г. в 11:31:44.262
ЧТО ДЕЛАТЬ, ЧТОБЫ НЕ СПИСАТЬ БАБЛО ДВА РАЗА ПРИ ИНТЕГРАЦИИ С ВНEШНИМ ШЛЮЗОМ? Представьте, что вы проектируете оплату заказа и при этом работаете с внешним шлюзом. Хэппи пас абсолютно понятен: пользователь жмет "оплатить", мы отправляем запрос в платежный шлюз и получаем ответ о том, прошла оплата или нет. Но что делать, если у нас что-то пошло не так? Например, словили таймаут и теперь не понимаем, что с платежом произошло и списалось ли баблишко? ➖➖➖ Часто, когда делаются интеграции, все проектируют стандартную логику. Получилось выполнить запрос — отлично. Не получилось — что-то с этим делаем. Например, повторяем запрос или просто выдаем ошибку. Но в этом кейсе все немного сложнее, потому что у нас есть внешняя сторона у которой состояние может отличаться от полученных нами данных. То есть фактически у нас на руках три возможные реальности: ✔️ запрос не дошел до шлюза и денег нет, ✔️ запрос дошел, деньги списались, а ответ потерялся по дороге к нам, ✔️ запрос дошел и прямо сейчас обрабатывается. Получается, что фактически сам платеж находится в каком-то состоянии, но на нашей стороне появляется неопределенность. И что с этим можно сделать? 1️⃣ Проработать правильно статусную модель. Не делать категорично SUCCESS или CANCELED, а добавить еще промежуточные статусы, например, IN_PROGRESS, ERROR. Это нужно, чтобы не показать пользователю в случае 500-ки или timeout ошибку с какой-нибудь кнопкой "Повторить". В этом случае у нас есть риск двойного списания деньжат, а промежуточный статус как раз решает проблему до выяснения обстоятельств. 2️⃣ Прорабатываем механизм уточнения статуса транзакции у шлюза. Без этого у нас могут зависнуть транзакции без движения. 3️⃣ Обязательно продумываем SLA промежуточного статуса. Грубо говоря, нам надо прописать, через сколько статус IN_PROGRESS должен перейти в другой и при наступлении этого времени еще раз продергиваем шлюз, чтобы подтвердить реальный статус и либо отменяем оплату или меняем на CANCELED, если шлюз так это подтвердил, потому что если мы такую логику не продумаем, то у нас будут зависшие транзакции. 4️⃣ Всегда помним про идемпотентный ключ, чтобы не создать новый платеж. Еще можно продумать функциональность сверки данных между внешним шлюзом и нами. Грубо говоря, раз в сутки забирать у шлюза реестр операций и сравнивать его со своим, чтобы найти косячные транзакции и лишние проводки в случае чего. И конечно, корректно работаем с ошибками и отдаем фронту промежуточные статусы, например, "Платеж обрабатывается, мы сообщим об окончании" вместо того, чтобы просто кидать ошибку и давать возможность делать повторный запрос. ➖➖➖ В итоге, при работе с внешней системой всегда закладывайте чуть больше, чем в интеграциях между сервисами, потому что внешний шлюз или какая-то другая система нам не подчиняется и нам всегда нужна перестраховка.