Как решить данную задачу?

Question

[jasonOk]

На сайте есть покупка, а также промо-коды, которые предоставляют скидку на товар и имеют ограниченное кол-во использований.
Когда человек нажал "оплатить", ему предлагает ввести промо-код, после чего в БД создается запись заказа, там же от счётчика оставшихся использований промо-кода отнимается 1. Затем появляется форма для оплаты с которой пользователя перекидывает в платежную систему.

Проблема: пользователь может создать заказ, использовать промо-код, но оплату не произвести. При этом использование (счетчик -1) засчитывается.
Как правильно организовать так, чтобы на одно использование промо-кода приходилась действительная (оплаченная) покупка?

Answer 1

[nirvimel]

Я считаю логически неверным такой подход, при котором промокоды представляются простым количеством и соответственно одним полем целого пита. Я бы спроектировал систему по-другому: Каждый отдельный промокод - это отдельная сущность со своим уникальным ID, внешним клюем к таблице "Клиенты" и внешним ключем к таблице "Оплаты", значение NULL в этом поле обозначает, что промокод еще не израсходован. Легко написать (под)запрос, который возвращает количество неизрасходованных промокодов для клиента, можно даже в БД сделать view (readonly) с клиентами и количеством неизрасходованных промокодов для них. Расходование промокода осуществятся сопоставлением его с записью в таблице "Оплаты". При удалении соответствующей оплаты для поддержания целостности внешних ключей соответствующее поле в промокоде будет сброшено в NULL автоматически, тем самым промокод вернется в число неизрасходованных.

Answer 2

[deadmemoras]

Эм, принять колбек от платежных систем и сделать как условие?
Если вернулось тру(не знаю что у них там) : выполняет
Иначе:
Выводит ошибку

Comments

[jasonOk]

>сделать как условие ...?
Если только после оплаты ставить -1, то тогда можно создать три заказа с одним купоном.

Или после того как я получу сумму N минус скидка я буду запрашивать обратно скидку т.к. промо уже использовано?

[deadmemoras]

jasonOk: действительно, не подумал.
У меня в голову лезет только ещё один вариант: создать ещё одну ячейку in_used, но тогда придётся вносить ещё правки (если используется -ошибка , но если человек не оплатить, статус поменяется( я имею ввиду, если два ведут один код, он будет доступен только для одного, а если он не оплатит, то второй будет в замешательстве)

Answer 3

[ThunderCat]

Вариантов много, 2 очевидных -
1)

пользователь может создать заказ, использовать промо-код, но оплату не произвести. При этом использование (счетчик -1) засчитывается.

. Пользователь сам себе злой буратина, предупреждать о "зависших" транзакциях с промо тикетами, смотрите в гугле тему "конверсия брошенных корзин".
2) Не снимать промо до оплаты, но тут возникает другая проблема - если человек проводит одновременно несколько оплат - промо на счету остаются, и можно начать процедуру оплаты по промо неограниченного количества товаров, решается только дополнительным полем, в которое пишется количество открытых транзакций на промо покупку. Если лимит транзакций достигнут, а счетчик промокодов еще не 0, выдавать предупреждение типа "Возможно у вас исчерпан лимит на промо, проверьте все ли товары купленные по промо оплачены и подтверждены." При отмене покупки - возвращать +1 к промо.

Comments

[jasonOk]

№2 Неплохой вариант

Answer 4

[Артемий]

Самое простое - добавить второй счетчик и построить логику на двух счетчиках.