Очищать корзину после оплаты или нет?

Question

[evomed]

Когда пользователь оплачивает, нужно ли сохранять items корзины с пометкой "опачено" и исключать из запроса или просто очищать корзину? Какая бест практика по данному вопросу?

Comments

[maksam07]

Делайте как в жизни. В корзине, пока несете до "кассы". Затем же перекладывайте в "пакет". Корзина пуста, может снова наполняться.

Смысл в том, что это временное хранилище выбранных товаров. Их может быть даже в БД не будет, пока клиент не "оплатит".

[VolgaVolga]

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

[evomed]

VolgaVolga, тогда надо будет полностью дублировать таблицу cart_items, а это дублирование данных

[evomed]

maksam07, на практике дублируют таблицы? Не сталкивался с данными процессами. Или я не понял, как перекладывать. Пересоздать cart_items - это не перекладывать. Перекладывать -это если добавить cart_items полиморфизма и cart_id заменять на order_id.

[maksam07]

evomed, на практике для заказов у тебя есть всего 1 таблица (грубо говоря). А для корзины просто сессия, которая живет до очистки

[evomed]

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

[VolgaVolga]

evomed, не дублирование, а изменение состояния или перенос. И уже написали, что содержимое корзины, как правило, не хранится в БД.

[evomed]

VolgaVolga, я имею ввиду дублирование таблиц. Сессия ненадежный вариант, если содержимое корзины до оплаты должно быть сохранено.

[VolgaVolga]

evomed, как правило, web storage бывает достаточно.

[evomed]

VolgaVolga, какая разница где дублировать структуру сущности? Если дублировать и есть юзер, тогда бд лучше всего.

[VolgaVolga]

evomed, очень спорно. Но раз вы так уверены, зачем было вопрос задавать?

[Талян]

evomed, что вы там собрались дублировать? Название товара с характеристиками и картинкой хотите что ли хранить вместо всего трех полей: item_id, cart_id, count? Ну прям нереальное количество данных!

Правильно говорят - просто храните в LocalStorage айдишники товара с количеством. Если хранить в LocalStorage - тогда вообще всего 2 поля нужно хранить: item_id и count.

[evomed]

Талян, название товара, цена скидки, процент, тип скидки, купон - и все это может меняться. Пользователю и для истории нужно сохранить данные на момент заказа. И цену в корзине высчитывать неудобно если нет "продуктов" и цена формируется в результате логики.

Если хранить в LocalStorage

Зачем? у меня есть user_id

Answer 1

[Сергей Горностаев]

Ни разу не видел ни одного интернет-магазина, где она бы не очищалась после оформления заказа.

Comments

[evomed]

Если хранить cart_items в бд, тогда какой вариант? Просто продублировать позиции из cart_items в order_items после заказа?

[Сергей Горностаев]

evomed, не дублировать. У таблицы заказов другая структура должна быть.

[evomed]

Сергей Горностаев, не у таблицы заказов, а у order_items. Получается carts связанная с cart_items, orders связанная с order_items и orders, связанная с carts. cart_items будет дублировать по структуре order_items

[Сергей Горностаев]

evomed, я её и имел ввиду. Таблица корзин должна хранить внешний ключ на покупателя, внешний ключ на товар и поле для количества товара. Можно ещё дату добавления товара в корзину для обнаружения брошенных корзин. А таблица элементов заказа - это наименование заказа, цена товара на момент покупки и количество купленных товаров. Можно дополнительно хранить внешний ключ на товар для аналитики.

[evomed]

Сергей Горностаев, цену товаров, скидки и т.д. не хранить в cart_items и расчитывать "налету" в корзине?

[Сергей Горностаев]

evomed, конечно нет. Пока клиент не купил товар, у него может много раз измениться цена например. А вот после покупки история должна оставаться неизменной, если не хочется намотаться на проблем с роспотребнадзором и налоговой.

[evomed]

Сергей Горностаев, здесь есть проблема, что пока юзер оплачивает (или идет уведомление) цена может поменяться и есть шанс после оплаты записать в order_items неневерные данные. А если сохранять все условия в cart_items, то тогда данные получишь строго на момент покупки. Но тогда еще придется хранить версии корзин (создавать новую корзину с items при каждом ее открытии).

[Сергей Горностаев]

evomed, используйте оптимистичную блокировку.

[evomed]

Сергей Горностаев, блокировать изменение цены товара?

[Сергей Горностаев]

evomed, нет. Контролировать версию данных. Если в момент покупки данные в каталоги изменились, выдавать клиенту ошибку.

[evomed]

Сергей Горностаев, в момент покупки - это когда? Когда нажимает на кнопку перейти к оплате не проблема. Я имею ввиду когда клиент уже смотрит на форму ввода карты на сайте платежной системы. И тут он забыл карту, пошел ее искать и в процессе решил попить чаю. А потом, когда оплатил, у платежной системы или у меня сбой и уведомление пришло через 2 часа. А за это время цена товара изменилась и ты записываешь в order_items не то, что было по факту.

[Сергей Горностаев]

evomed, а вот это должен решить бизнес-аналитик.

[evomed]

Сергей Горностаев, что должен решить бизнес аналитик? Как устранить уязвимость?

[Сергей Горностаев]

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

[evomed]

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

Answer 2

[Adamos]

Если хочется хранить корзину в БД - так вам ее все равно хранить после оформления заказа.
Сделайте таблицу, где большинство полей - NULL до момента оформления заказа (цены и проч. для отображения берется с текущих карточек). Выборка текущей корзины - по order_id = NULL. Заказ оформлен - текущая корзина опустела, товары естественным порядком перекочевали в заказ.

Comments

[evomed]

Не понял процесс.. Как товары естественным образом перекочуют в заказ? Откуда перекочуют? Если брать из products то в соседнем ответе обсуждали, что там может быть не актуальная информация пока юзер платит. Дыра безопасности.

[evomed]

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

[Adamos]

evomed, при создании заказа товарам в корзине присвоится ID этого заказа и актуальные цены/скидки вместо NULL. Корзина опустела, теперь эти самые записи - состав заказа, который можно оплачивать. Никакого "возвращаемся к корзине" после формирования заказа уже не будет.

[evomed]

Adamos, т.е. добавляем товары в cart_items где все поля условий null. В cart добавляем order_id = null. Когда оплачено, создаем order и сетаем в cart order_id, а в cart_items поля null заполняем данными из products - так, чтоли?

[Adamos]

evomed, ну, я не знаю ваших таблиц.
Возможно, до оформления заказа в cart_items будут заполнены только id, created_at, product_id и amount.
Зато при оформлении зафиксируются текущие данные из prices, bonuses, coupons etc.

[evomed]

Adamos, допустим есть только products, я все равно не понял процесса. Если до оформления заказа в cart_items не будет всех условий (прайс скидки название), то после оформления (поступления оплаты) - если данные изменятся то правильную инфу будет неоткуда брать.

[Adamos]

evomed, юзер набрал корзину.
В таблицу накиданы записи: товар, количество. Все остальное - NULL, юзеру оно отображается из текущих данных по товарам.
Юзер захотел оплатить - формируется заказ: запись в таблице заказов, order_id на все строки корзины, все прочие данные в них заполняются из текущих цен и акций.
Теперь юзер может оплачивать готовый заказ с текущими ценами - или протормозить, и заказ, созданный больше суток (трех, недели?) назад, уходит в "не оплаченные". Хочешь заказать - начинай сначала.

[evomed]

Adamos, здесь есть проблема в одинаковом cart_id, что если пользователь вернется с платежной системы в корзину и изменит заказ, а потом обратно переключится на сайт платежки и оплатит, то, когда мой сайт получит уведомление там будет order_id корзины, в которой уже другой состав. Уязвимость. Решается созданием новой carts и всех cart_items при каждом открытии корзины, но тогда нагрузка на бд.

[evomed]

Adamos, то есть у пользователя будет много корзин, отображаться будет последняя неоплаченная - ну или что-то типа того