Что необходимо учесть при переводе денег через внешний банк по HTTP, прежде чем выпускать это в прод?

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

Идемпотентность и повторные запросы

Сеть ненадёжна: запрос мог дойти до банка, а ответ потеряться. Если вы повторите запрос, деньги могут уйти дважды. Решение — передавать уникальный idempotency key (например, UUID транзакции) в заголовке, а банк должен возвращать тот же результат при повторе.

POST /payments HTTP/1.1
Idempotency-Key: 7f3c1e2a-...-9b
Content-Type: application/json

{ "amount": 1000, "currency": "RUB", "to": "..." }

Таймауты, ретраи и circuit breaker

• Жёсткий timeout на connect и read — иначе потоки зависнут.
• Retry только для идемпотентных операций и только на сетевые ошибки/5xx, с экспоненциальным backoff и jitter.
• Circuit breaker: если банк стабильно падает, перестать долбить его и быстро отдавать ошибку.

Сверка и статусы

Нельзя считать перевод успешным только по HTTP 200. Нужен отдельный процесс reconciliation: периодически запрашивать статус транзакций по их id и сверять с внутренним состоянием. Все переходы статусов (pending, sent, confirmed, failed) должны быть явными и логироваться.

Безопасность и наблюдаемость

• TLS, mTLS или подпись тела запроса (HMAC), чтобы исключить подмену.
• Секреты — в vault, не в коде и не в логах.
• Correlation id во всех логах, метрики latency/error rate, алерты на аномалии.
• Лимиты на сумму и частоту, ручной разбор подозрительных операций.

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