Как ты решал задачу по платежам

Что проверяют

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

Как отвечать

Нужна своя история с конкретикой. Удобно пройти по местам, где платёжная интеграция обычно ломается:

• контекст: продукт, провайдер, сценарии (разовая оплата, рекуррентные списания, возвраты), объём;
• статусы: платёж как конечный автомат created → pending → succeeded / failed с запретом недопустимых переходов;
• идемпотентность: ключ идемпотентности в запросе на создание платежа и уникальный индекс у себя, чтобы повтор после таймаута не создал второй платёж;
• вебхуки: проверка подписи, обработка повторных и пришедших не по порядку уведомлений, быстрый ответ 200 и обработка в фоне через Celery или другую очередь;
• деньги в коде: Decimal или целые копейки, никакого float;
• безопасность: данные карт к вам не попадают, оплата идёт через форму провайдера и токены, так проще с PCI DSS; ключи в секретах, не в репозитории;
• сверка: реестр провайдера сравнивается со своей базой, расхождения разбираются.

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

Если с платежами вы не работали, скажите прямо и разберите, как спроектировали бы интеграцию по этим пунктам. Честное рассуждение ценится выше, чем придуманная история.

Где спотыкаются

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

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

Называют эффект вроде «конверсия выросла на 20%» и не могут объяснить, как считали. На первом же уточнении такая цифра рассыпается.