Дайте каждой сущности собственный идентификатор
Заказ описывает покупку: товары, количество, доставку и покупателя. Счёт фиксирует предложение оплатить определённую сумму. Платёж представляет конкретную операцию у платёжного провайдера. У этих объектов должны быть отдельные идентификаторы и сохранённые связи. Допустим, заказ содержит два блокнота по четыреста рублей и доставку за двести. Итог составляет тысячу рублей. В момент выставления счёта полезно сохранить снимок состава заказа и расчёта суммы. Позднейшее изменение карточки товара не должно незаметно менять смысл уже отправленного счёта. Название товара или фамилия покупателя плохо подходят для сопоставления платежей: они могут повторяться. Надёжнее опираться на идентификаторы, которые система связывает при создании операции.
Обрабатывайте изменение суммы как отдельное событие
Покупатель добавил третий блокнот. Новый итог составляет тысячу четыреста рублей, но прежний счёт на тысячу может оставаться у него в переписке. Поэтому изменение заказа должно запускать явно определённый сценарий: например, отмену прежнего неоплаченного счёта и создание нового, если выбранный сервис поддерживает такие действия. Не стоит молча заменять сумму в собственной базе и считать, что старая ссылка тоже изменилась. Поведение ссылки и возможность отмены проверяют по документации конкретной интеграции. Если оплата уже началась или завершилась, потребуется другой сценарий согласования расхождения. В журнале полезно сохранять основание изменения, время и связи между старым и новым счётом. Тогда сотрудник поддержки увидит историю, а не только последнюю цифру.
Разделите оплату покупателя и расчёты с продавцом
Полученная ссылка означает, что счёт создан. Его фактический статус проверяют через предусмотренный сервисом интерфейс или API. Платёж также имеет собственный жизненный цикл: промежуточное состояние нельзя произвольно трактовать как окончательный успех. Деньги, которые покупатель оплатил через посредника, и сумма последующего перечисления на расчётный счёт продавца могут различаться из-за комиссии, возвратов и состава расчётного перечисления. Поэтому сверка банковской выписки требует отдельной связи с отчётами провайдера. По одной сумме поступления не всегда можно определить конкретный заказ. Для условного магазина полезны три проверки: соответствует ли подтверждённый платёж выставленному счёту, связан ли счёт с правильной версией заказа и отражено ли последующее перечисление в расчётных документах. Расхождение направляют на разбор, сохраняя исходные данные. Автоматическое исправление цифр ради совпадения скрывает причину ошибки.
Попробуйте на практике
На бумаге проверьте логику счёта для вымышленного заказа, не создавая реальных платежей.
- Запишите заказ с двумя блокнотами по четыреста рублей и доставкой за двести. Присвойте заказу и счёту разные условные номера.
- Сохраните рядом состав и сумму первой версии: тысяча рублей. Добавьте третий блокнот и создайте вторую версию расчёта.
- Опишите, что должна сделать система со старым неоплаченным счётом и как поступить, если сведения об оплате пришли позднее.
- Для каждой версии укажите, какие идентификаторы, суммы и статусы потребуются сотруднику для сверки.
Как проверить результат. Схема понятна, если платёж по старому счёту нельзя незаметно приписать новой версии заказа, а банковское зачисление не подменяет историю отдельной оплаты. Неопределённые состояния должны иметь явный путь разбора.
Частые вопросы
Можно ли сопоставлять оплаты только по сумме?
Этого недостаточно: несколько заказов могут иметь одинаковый итог. Используйте сохранённые идентификаторы и проверяйте сумму как дополнительное условие соответствия.
Подходит ли инструкция для старого модуля современному сервису?
Это нужно проверять по текущей документации и совместимости. Название способа оплаты или прежний номер версии не подтверждают, что интерфейсы, статусы и правила работы остались прежними.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.