Как происходит интеграция с платежными системами

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

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

Как отвечать

Опишите поток на бэкенде, например на Django или FastAPI:

• создание платежа: сервер создаёт у себя заказ, затем вызывает API шлюза с суммой, валютой и ключом идемпотентности. В ответ приходит идентификатор платежа и ссылка на платёжную страницу или токен для виджета;
• данные карты: к вашему серверу они не попадают. Пользователь вводит их на странице шлюза или в его виджете, и это резко сужает объём требований PCI DSS;
• статус: окончательный результат приходит вебхуком. Обработчик проверяет подпись (обычно HMAC) или адрес отправителя, при необходимости перезапрашивает статус через API и только потом меняет заказ;
• идемпотентность: одно уведомление может прийти несколько раз и не по порядку. Обработка строится на уникальном идентификаторе платежа и переходах конечного автомата: pending, succeeded, canceled, refunded;
• деньги: сумма хранится целым числом в копейках или в Decimal, никогда во float;
• фон: опрос зависших платежей, возвраты и ежедневная сверка с реестром шлюза идут фоновыми задачами, например в Celery.

Для России добавьте чеки по 54-ФЗ: данные чека обычно передаются вместе с платежом, и ошибка в них ломает оплату. Для отладки есть тестовый режим шлюза с тестовыми картами, вебхуки на локальную машину пробрасывают туннелем.

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

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

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

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

Обрабатывают вебхук долго и синхронно. Шлюз не дождётся ответа и повторит уведомление, а без проверки на дубли заказ проведётся дважды.