Как спроектировать API для платежей так, чтобы отличать повторный запрос пользователя от повторной доставки сообщения?

Question

Для различения повторного запроса и повторной доставки используют идемпотентные ключи. Клиент передает уникальный idempotency key, который сервер сохраняет вместе с результатом операции. При повторном запросе с тем же ключом сервер возвращает прежний результат вместо повторного выполнения операции. Это предотвращает двойные списания.

YeaHub · Accepted Answer

Проблема повторных запросовВ платежных системах повторные запросы возникают из-за:Повторной отправки пользователемПовторов со стороны сети или балансировщикаПовторной доставки сообщенийБез защиты это может привести к двойным списаниям.ИдемпотентностьОпределение:Идемпотентность — это свойство операции, при котором повторный вызов с теми же параметрами дает тот же результат без повторного выполнения.Использование idempotency keyАлгоритм работы:Клиент генерирует уникальный ключОтправляет его в заголовке или теле запросаСервер сохраняет ключ и результат операцииПри повторном запросе возвращает сохраненный результатПример:POST /payments
Idempotency-Key: abc123
Где хранить ключиЧасто используют:RedisPostgreSQLспециализированный storageВажные детали проектированияКлюч должен быть уникален для операцииНужно хранить статус операцииНужно обрабатывать частично завершенные операцииВыводИдемпотентные ключи — основной механизм защиты платежных API от повторного выполнения операций.