Один платёж может трижды попасть в отчёт о продажах.

Условный пример: магазин считает одну покупку на один успешно завершённый платёж. Уведомление пришло, обработчик записал оплату, но провайдер не получил ответ. Затем прислал уведомление ещё раз. Если при каждом получении отправлять новую покупку в аналитику, один платёж посчитается несколько раз.

После проверки подлинности уведомления здесь нужны две отдельные проверки: получали ли мы это событие и учитывали ли уже саму оплату.

Например, в Stripe event.id — идентификатор события. В документации описана не только повторная доставка одного события: иногда создаются разные Event-объекты об одном объекте. Поэтому для однократной фиксации оплаты недостаточно проверять только event.id.

Для нашей упрощённой модели ключ факта оплаты можно составить из провайдера, аккаунта продавца, идентификатора платежа и операции «учесть успешную оплату». Разные уведомления об этой оплате должны приводить к одной записи. Для частичных оплат, нескольких списаний и возвратов правила нужны отдельные.

В одной БД я бы закрепил такой ключ ограничением уникальности, а результат и отметку успешной обработки сохранял в одной транзакции. Повтор не должен заново применять уже записанный результат. Если отметить событие обработанным заранее, сбой между отметкой и записью оплаты может вообще потерять покупку.

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

Для выбранного набора платежей полезно сопоставлять число доставок, уникальных событий и учтённых оплат. Три доставки, одно событие и одна оплата могут быть нормой. Три записи об одной оплате — уже повод проверить обработчик.