Решение ошибок сверки платежей
Клиент потерял 2000 долларов. Руководитель финансового отдела провел четыре ночи в поисках причины расхождения.
Проблема заключалась в задаче повторной обработки (retry job). Система дважды обработала 120 платежей. Она не списывала деньги с клиентов повторно, а лишь создавала дублирующие записи в реестре.
Мы решили это с помощью слоя идемпотентности. Это гарантирует, что платеж будет обработан только один раз.
Вот как мы это сделали:
- Мы использовали блокировку Redis, чтобы предотвратить повторные запросы.
- В качестве резервного механизма мы добавили уникальный индекс в базу данных.
- Мы использовали ключ, состоящий из названия шлюза и ID транзакции.
Мы также исправили проблему с обменными курсами. Система использовала курсы в реальном времени. Курсы меняются быстро, что приводило к расхождениям.
Теперь мы фиксируем курс в момент создания заказа. Клиент видит одну цену, и финансовая команда видит ту же самую цену.
Кроме того, мы внедрили ежедневный отчет. Он сравнивает банковские CSV-файлы с нашими записями. Объем ежемесячной работы сократился с 15 до 2 часов.
Хватит полагаться на Excel и бессонные ночи. Ошибки в платежах — это проблемы проектирования.
Начните с индекса в базе данных. По мере роста добавляйте блокировки Redis. Никогда не полагайте, что уведомление о платеже придет только один раз.