Идемпотентность в платежах: почему без неё теряют деньги

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

Что именно означает идемпотентность

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

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

Идемпотентность не предотвращает повторы. Она делает повтор безопасным.

Ключ идемпотентности — идентификатор конкретной операции, по которому сервер или платёжный провайдер узнаёт повтор. Это не номер заказа сам по себе: у одного заказа могут быть разные попытки оплаты, а один ключ должен относиться к одной попытке с неизменными параметрами.

Как возникает двойное списание

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

Похожая ошибка возникает при двойном нажатии, повторе запроса браузером или автоматическом retry в сетевой библиотеке. Защита только на кнопке не решает проблему: запросы могут повторяться между сервером и провайдером, а мобильная сеть не знает, выполнилась ли операция на другой стороне.

Полезно разделять три уровня:

• Клиентский: отключить повторное нажатие, пока интерфейс ждёт ответ. Это улучшает UX, но не защищает сервер.
• Сервер приложения: сохранить попытку оплаты и не создавать вторую для того же намерения.
• Платёжный провайдер: передать поддерживаемый им ключ идемпотентности. Конкретные правила ключа, область действия и срок хранения зависят от провайдера.

Как строить безопасную попытку оплаты

Ключ создавайте на сервере, когда пользователь начинает конкретную попытку оплаты. Сохраните его вместе с заказом или отдельной записью попытки, суммой, валютой и текущим состоянием. При повторной отправке той же попытки используйте тот же ключ и те же параметры. Не генерируйте новый ключ только потому, что клиент получил тайм-аут.

Минимальный жизненный цикл может включать состояния «создана», «обрабатывается», «успешна», «отклонена» и «результат неизвестен». Последнее важно: тайм-аут не доказывает ни успех, ни отказ. В таком состоянии нельзя слепо запускать новую оплату. Сначала проверьте результат через доступный механизм провайдера — например, повторный запрос с тем же ключом, чтение статуса операции или обработку его уведомления.

1. Зафиксируйте намерение. Создайте запись попытки оплаты до обращения к провайдеру. Проверка: у заказа есть стабильный идентификатор попытки, который переживает перезапуск приложения.
2. Свяжите ключ с неизменными параметрами. Сумма, валюта и заказ должны соответствовать сохранённой попытке. Проверка: повторный запрос не может незаметно изменить сумму при том же ключе.
3. Передавайте ключ провайдеру, если его API это поддерживает. Уточните в документации провайдера формат ключа, период хранения и поведение при несовпадающих параметрах. Проверка: повтор идентичного запроса не создаёт второе списание в тестовом сценарии.
4. Обрабатывайте неопределённый результат отдельно. После тайм-аута запросите актуальный статус или дождитесь подтверждённого события, а не объявляйте оплату неуспешной автоматически. Проверка: система не создаёт новую попытку, пока исход первой не выяснен.
5. Сделайте обработку уведомлений повторяемой. Провайдер может прислать одно событие несколько раз. Сохраняйте идентификатор события и не применяйте один и тот же переход состояния повторно. Проверка: повторная доставка не удваивает зачисление или выдачу товара.

Где чаще всего ломается реализация

Ключ создают на каждое обращение

Если приложение генерирует новый ключ при каждом retry, защита провайдера не распознает повторы. Ключ должен жить столько же, сколько конкретная попытка оплаты, и повторно использоваться при восстановлении после тайм-аута.

Один ключ используют для всех платежей заказа

После отказа покупатель может начать новую попытку. Это уже отдельная операция: ей нужен новый ключ и новая запись. Иначе система рискует вернуть старый результат вместо обработки новой попытки. Заказ и попытка оплаты — разные сущности.

Параметры меняются, а ключ остаётся прежним

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

Запись в базе и запрос провайдеру не атомарны

Обычная транзакция базы данных не охватывает внешний платёжный сервис. Приложение может сохранить попытку и упасть до отправки запроса или отправить запрос и упасть до сохранения ответа. Поэтому нужны сохранённое состояние, безопасные повторы и сверка с провайдером; для надёжной фоновой доставки команд часто применяют transactional outbox*.

Событие об оплате применяют несколько раз

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

Что измерять и проверять

Универсальных цифр задержки или доли повторов нет: они зависят от приложения, сети и провайдера. Начните с метрик, которые показывают неопределённость и последствия:

• число повторных запросов по одной попытке и число созданных для неё операций у провайдера;
• сколько попыток остаются в состоянии «результат неизвестен» и как долго;
• сколько уведомлений пришло повторно и сколько из них система обработала повторно;
• расхождения между статусами в приложении и данными провайдера;
• ошибки сверки, двойные зачисления и повторная выдача одного товара.

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

Границы подхода

Идемпотентный ключ защищает только ту операцию и в той системе, где его проверяют. Он не объединяет автоматически базу приложения, провайдера и учётную систему. Если провайдер хранит ключ ограниченное время, поздний повтор может вести себя иначе — срок и правила нужно проверять в его актуальной документации.

Также ключ не должен быть глобальным идентификатором заказа без учёта попытки. Повторить ту же попытку — значит повторить тот же ключ и параметры. Начать новую после подтверждённого отказа — создать новую попытку. При сомнении сначала сверяйте статус, а не отправляйте новое списание.

*Transactional outbox — шаблон, при котором приложение в одной транзакции сохраняет изменение в базе и сообщение для последующей отправки. Отдельный процесс доставляет сообщение повторно, не теряя связь с сохранённым состоянием.

Что делать дальше

Возьмите один реальный путь оплаты и нарисуйте его состояния: от нажатия кнопки до подтверждения провайдера и выдачи товара. Для каждого перехода отметьте, что произойдёт при тайм-ауте, повторе запроса и повторном уведомлении. Затем проверьте документацию именно вашего платёжного API: срок хранения ключей, область их действия и способ узнать итог операции. Следующий полезный шаг — добавить тест потери ответа после списания и мониторинг попыток с неизвестным результатом.