Начинать нужно с модели заказа
Платеж нельзя проектировать отдельно от корзины, доставки, скидок и статуса заказа.
В интернет-магазине оплата связана не только с суммой. На результат платежа влияют корзина, скидки, доставка, наличие товара, клиентские данные и правила резервирования.
Перед интеграцией нужно определить, когда создается заказ: до перехода на оплату или после подтверждения платежа. На практике чаще безопаснее создавать заказ до оплаты в статусе pending payment, а затем менять статус только после server-side проверки.
- фиксировать сумму и валюту до создания платежа;
- сохранять order id до перехода покупателя на оплату;
- не менять заказ в paid только по frontend-событию;
- учитывать отмену, таймаут и повторную попытку оплаты.
Как обрабатывать неуспешные и отложенные оплаты
Не каждый платеж заканчивается мгновенным успехом или ошибкой, поэтому checkout должен жить с промежуточными статусами.
Покупатель может закрыть платежную страницу, банк может потребовать дополнительную проверку, а callback может прийти позже. Поэтому статус pending payment должен быть нормальным состоянием, а не технической ошибкой.
Повторная попытка оплаты должна создаваться как новая payment attempt, но привязываться к тому же заказу. Это помогает избежать дублей заказов и сохранить историю действий клиента.
- разделять order status и payment attempt status;
- показывать пользователю понятный retry-сценарий;
- не создавать новый заказ при повторной оплате той же корзины;
- логировать причину ошибки провайдера в техническом журнале.
Что передавать в CRM после оплаты
CRM должна получать проверенный бизнес-результат, а не сырой ответ платежного провайдера.
После успешной оплаты CRM обычно нужно знать номер заказа, сумму, валюту, статус, клиента, канал продажи и внешний номер платежа. Raw response провайдера лучше хранить в backend-журнале, а не делать основным объектом CRM.
Если есть фискализация, в CRM полезно передавать отдельный статус чека. Так менеджер видит, что оплата успешна, но чек может ожидать retry или ручного разбора.
- order id, payment id, amount, currency;
- customer id или контактные данные в разрешенном объеме;
- payment status и fiscal status отдельно;
- correlation id для поддержки.
FAQ
Когда создавать заказ: до или после оплаты?
Чаще безопаснее создать заказ до оплаты в промежуточном статусе, а финальный paid выставить только после server-side подтверждения платежа.
Что делать, если покупатель закрыл платежную страницу?
Сохранять заказ в pending payment и обновлять его после webhook или отдельной проверки статуса у провайдера.
Можно ли повторно оплатить тот же заказ?
Да, но повторная попытка должна быть новой payment attempt, привязанной к тому же order id, без создания дубля заказа.
