Українська
Հայերեն
ქართული
English
Қазақша
Español
Français
Deutsch
Italiano
فارسی
В фокусе статьи
Исходная задача: способы оплаты не должны дробить заказ
Клиенту нужен выбор, а команде нужен один order id и один понятный результат независимо от метода оплаты.
Когда способы оплаты подключаются отдельными кнопками без общего backend-контракта, один и тот же заказ получает разные идентификаторы и статусы. Поддержке сложно ответить клиенту, а бухгалтерии сложно сверить результат между кабинетами.
В кейсе заказ сохраняет единый внутренний id, а для каждого выбранного метода создается отдельная payment attempt. Метод, provider, внешний id, сумма, валюта и статус остаются структурированными полями одной платежной модели.
- не менять состав заказа после выбора способа оплаты без новой попытки;
- сохранять provider и method как нормализованные значения;
- давать пользователю понятный fallback после failed или expired;
- не считать метод оплаты подтвержденным до server-side результата.
Решение: нормализовать статусы и правила переходов
Провайдерские статусы могут отличаться, но бизнес должен работать с единым набором состояний и исключений.
Backend принимает событие выбранного способа оплаты и приводит его к общей статусной модели. До этого проверяются подлинность, сумма, валюта и связь с конкретной попыткой оплаты.
Такой слой особенно важен для возвратов, повторных событий и отчетности: бизнес-процесс не должен зависеть от формулировки статуса во внешнем кабинете. Нормализация не отменяет проверку актуальных правил каждого провайдера.
- описать таблицу соответствия внешних и внутренних статусов;
- вести provider-specific raw status для расследования;
- не переводить paid обратно в failed поздним событием;
- маршрутизировать неясные случаи в manual review.
Контроль после запуска: сверка по методу и провайдеру
Один дашборд должен показывать подтвержденные операции, pending, возвраты и расхождения в разрезе каждого способа оплаты.
Операционная команда видит общую сумму и одновременно может отфильтровать операции по способу оплаты, провайдеру, периоду, статусу и возврату. Это полезно для поддержки и закрытия смены.
Если отчет провайдера и внутренний ledger расходятся, исключение привязывается к конкретной попытке платежа. Команда не должна исправлять заказ вручную без причины, истории и проверки первичного источника.
- сверять provider report с internal payment ledger;
- показывать pending и expired отдельно от paid;
- сохранять исходный method при возврате;
- регламентировать ручные корректировки и роли доступа.
FAQ
Нужно ли создавать отдельный заказ для каждого способа оплаты?
Нет. Один заказ может иметь несколько payment attempts. Отдельной сущностью должна быть попытка оплаты, а не сам заказ.
Можно ли использовать одинаковые статусы для разных провайдеров?
Да, на уровне бизнес-процесса нужна нормализованная модель. При этом исходный статус провайдера нужно сохранять для аудита и разбора исключений.
Что проверять перед добавлением нового метода оплаты?
Актуальные условия провайдера, доступные статусы и возвраты, способ серверной проверки, требования к сайту и формат отчетности для сверки.
