Как правильно построить логику заказа в магазине?

Question

[semki096]

Смотрю процесс заказа в некоторых магазинах. Например страница заказа /checkout - почему эта страница не привязана к номеру заказа, например не /checkout/88. Или номер заказа в сессии хранится?

А также непонятно как сформировать данные заказа перед отправкой на платёжный сервис. К примеру я беру данные из корзины перед отправкой. Но мне же надо ещё и очистить эту корзину. Значит к примеру если перед отправкой данных пользователь решит обновить страницу, то данных не будет так как корзина уже очищена.

Буду признателен за разьяснение логики очередности действий для реализации заказа.

Comments

[Максим Федоров]

Почему когда вы в магазине, продавец не даёт вам номерок, но знает, какие у вас товары?

Хранится в сессии пользователь, он владелец, а не какой-то номер хранит эту инфу

[Максим Федоров]

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

[semki096]

Максим Федоров, спасибо. А если к примеру у пользователя 2 заказа, и он решает один из них оплатить, переходит на страницу /checkout - откуда системе знать какой заказ оплачивать? Заказы у меня к примеру хранятся в профиле пользователя, в принципе можно передавать параметры. Либо как то запрещать иметь несколько неоплаченных заказов. Короче здесь не понимаю как быть.

[alex-1917]

semki096, можно делать отложенные товары (в битриксе есть такое)
несколько неоплаченных заказов - это нонсенс.
такой покупатель - это не покупатель, нахрен он никому не нужен.
это скорее сборщики ценовых предложений - пример из оффлайна - наберут счетов и бегут сравнивать к конкурентам, вымаливая скидосы...
для владельца магазина- это одни расходы.
поэтому нет.

[semki096]

alex-1917, да согласен, на данном этапе решил просто обновлять ордер при изменении корзины.

Answer 1

[nrgian]

Например страница заказа /checkout - почему эта страница не привязана к номеру заказа, например не /checkout/88. Или номер заказа в сессии хранится?

Существуют запросы GET,
существуют запросы POST
И да, еще есть сессии.

Смысла в /checkout/88 нет - так как это разовая операция и нет необходимости иметь возможность попасть туда по ссылке когда угодно (что обеспечивает GET)

А также непонятно как сформировать данные заказа перед отправкой на платёжный сервис. К примеру я беру данные из корзины перед отправкой. Но мне же надо ещё и очистить эту корзину. Значит к примеру если перед отправкой данных пользователь решит обновить страницу, то данных не будет так как корзина уже очищена.

То, что пользователь ушел на платежный сервис, не означает, что он оплатил.
У него мог быть сбой по оплате (например, на этой карте нет денег) и вам нужно еще раз отправить его на платежный сервис.
Или он решил оплатить другим методом и вам нужно отправить его на платежный сервис иначе.
Или он решил добавить еще товара.

А вы в это время очистили уже корзину и потеряли тем самым клиента с большой вероятностью

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

Comments

[semki096]

По поводу очистки корзины - спасибо, полностью согласен.
"Смысла в /checkout/88 нет" - не совсем согласен, так как есть история покупок, кроме того таким способом мы можем вернуться, положить ещё что то в корзину, и дальше работать с этим же заказом. Нашёл пример как это работает, и это мне нравится - d7.commercekickstart.com

[nrgian]

semki096,

"Смысла в /checkout/88 нет" - не совсем согласен, так как есть история покупок, кроме того таким способом мы можем вернуться, положить ещё что то в корзину, и дальше работать с этим же заказом

Не можем.
Checkout - это полное завершение покупки, закрытие чека, оплата. После этого нельзя возвращаться.

[semki096]

nrgian, там на примере, как и в многих магазинах, checkout разбит по шагам, и в принципе можно вернуться на любом шаге кроме последнего.

[nrgian]

semki096,

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

Не можем вернуться ни на какой шаг, если последний шаг уже прошел и платежная система подтвердила.