Как получать заказ только после оплаты?

[kitsune44]

Здравствуйте, подскажите как получать заказ в админку ПОСЛЕ оплаты, т.е. сейчас если на сайте заполнить корзину, нажать оплатить, то заказ сразу же приходит в админку, а мне нужно что бы когда человек оплатит, тогда приходил заказ, (мне так люди могут всю админку зас**ть)

[ashap]

23 минуты назад, kitsune44 сказал:

Здравствуйте, подскажите как получать заказ в админку ПОСЛЕ оплаты, т.е. сейчас если на сайте заполнить корзину, нажать оплатить, то заказ сразу же приходит в админку, а мне нужно что бы когда человек оплатит, тогда приходил заказ, (мне так люди могут всю админку зас**ть)

какая плат система или эквайринг какого банка?

[bogdan281989]

1 час назад, kitsune44 сказал:

Здравствуйте, подскажите как получать заказ в админку ПОСЛЕ оплаты, т.е. сейчас если на сайте заполнить корзину, нажать оплатить, то заказ сразу же приходит в админку, а мне нужно что бы когда человек оплатит, тогда приходил заказ, (мне так люди могут всю админку зас**ть)

Отменить запись истории при переходе к оплате, обычно это можно сделать в контроллере платежки (но не факт, не знаю как у вас реализовано), метод confirm(). Заказ создается в любом случае, но если там убрать запись статуса, такие заказы вы видеть не будете. Но также это может быть реализовано другими механизмами, не видя кода сложно сказать.

[nogocuHoBuk]

1 час назад, kitsune44 сказал:

мне так люди могут всю админку зас**ть

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

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

И да, вопрос актуальный (если действительно нужна помощь)
 

1 час назад, ashap сказал:

какая плат система или эквайринг какого банка?

А так же какой именно модуль используете.

[kitsune44]

система сбера стоит, всё увидел разницу, просто когда не оплатили, стоит "Ожидание", а после оплаты "в обработке"

[ashap]

 

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

 

19 часов назад, kitsune44 сказал:

система сбера стоит, всё увидел разницу, просто когда не оплатили, стоит "Ожидание", а после оплаты "в обработке"

есть тут https://opencartforum.com/files/file/4955-sberbank-ekvayring-pro-rasshirennyy-protokol/ вариант работы когда только после оплаты будет нужный статус и много много разных плюшек в дополнение, скидка на неделю 11.11 купон 669218-1111

[Venter]

59 минут назад, nogocuHoBuk сказал:

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

 

отключаем запись в бд при переходе к оплате. Добавляем:

1) Вместо создания заказа узнаем какой должен быть следующий ID заказа

2) Сохраняем в сессию и пишем в куки этот ID

3) После оплаты достаем с сессии или кук ID, создаем заказ

4) Удаляем сессию ID заказа если она есть, удаляем куки

ИЛИ

1) Вместо создания заказа узнаем какой должен быть следующий ID заказа

2) Сохраняем в сессию ID, потом создаем с него хеш и сохраняем в бд (хеш = ID) и куках (Как и где хранить сами решаете)

3) После оплаты проверяем, если есть ID в сессии то создаем заказ, если нету то берем хеш из кук, лезим в бд и сверяем по хешу, если такой есть то берем ID, создаем заказ

4) Удаляем сессию ID заказа если она есть, удаляем хеш из бд и из кук

[nogocuHoBuk]

13 минут назад, Venter сказал:

 

отключаем запись в бд при переходе к оплате. Добавляем:

1) Вместо создания заказа узнаем какой должен быть следующий ID заказа

2) Сохраняем в сессию и пишем в куки этот ID

3) После оплаты достаем с сессии или кук ID, создаем заказ

4) Удаляем сессию ID заказа если она есть, удаляем куки

ИЛИ

1) Вместо создания заказа узнаем какой должен быть следующий ID заказа

2) Сохраняем в сессию ID, потом создаем с него хеш и сохраняем в бд (хеш = ID) и куках (Как и где хранить сами решаете)

3) После оплаты проверяем, если есть ID в сессии то создаем заказ, если нету то берем хеш из кук, лезим в бд и сверяем по хешу, если такой есть то берем ID, создаем заказ

4) Удаляем сессию ID заказа если она есть, удаляем хеш из бд и из кук

Отличное решение.  А подскажите, как оно будет работать если на сайте заказ оформляют больше чем 2 человека одновременно? Причем с разными способами оплаты.
 

Спойлер

Единственным ПРАВИЛЬНЫМ решением будет повесить удаление заказов со статусом 0 на крон. А все вот эти "посмотреть какой будет следующим" ведут к таким проблемам, что "за***ная админка заказов" покажется детским лепетом.

 

[Venter]

2 минуты назад, nogocuHoBuk сказал:

Отличное решение. А подскажите, как оно будет работать если на сайте заказ оформляют больше чем 2 человека одновременно? Причем с разными способами оплаты.

у каждого юсера своя сессия и свой браузер с куками вот и всё

И причем тут способы оплаты?

[nogocuHoBuk]

2 минуты назад, Venter сказал:

у каждого юсера своя сессия и свой браузер с куками вот и всё

И причем тут способы оплаты?

При чём тут сессия и кука?
Я офомрляю заказ. Следующий 100. Акей. Запомнили, 
Но в этот момент Вы оформляете заказ который НУЖНО создать сразу, ибо у него наложеный платеж (это к вопросу о том, какой способ оплаты).
И заказ создается. Какой у него будет номер?
И что потом делать "Платежной системе, когда она вернет колбек, что заказ номер 100 "оплачен"? Как всё это разруливать?

[Venter]

11 часов назад, nogocuHoBuk сказал:

Единственным ПРАВИЛЬНЫМ решением будет повесить удаление заказов со статусом 0 на крон. А все вот эти "посмотреть какой будет следующим" ведут к таким проблемам, что "за***ная админка заказов" покажется детским лепетом.

 

Кто решил что единственное правильное решение??? Есть разные нюансы, где то так подайдет, где нужно по другому. 

 

имхо, чисто заблуждение

[nogocuHoBuk]

  

Только что, Venter сказал:

ну так вы и передавайте тот будущий ID

Я и передаю будущий. Вы правда не понимаете?
Сейчас создано 99. Следующий 100. 
Я передаю платежной системе, что следующий 100.
А Вы создаете заказ, которыцй нужно создать СРАЗУ. А аутоинкремент - 100. Понимаете?
И создавая заказ (ВАШ) он будет с номером 100.
Вас ничего не смущает?
 

[Venter]

Только что, Venter сказал:

за***ная админка заказов"

причем тут вообще админка.....??

 

Короче, решайте так как считаете нужным. Я привел свой вариант, хотите используйте, хотите не используйте, всё остальное зависит от ваших знаний

[ashap]

друзья скажу по секрету

сессии может уже не быть после ухода с сайта

[Venter]

Только что, ashap сказал:

друзья скажу по секрету

сессии может уже не быть после ухода с сайта

ну так я для чего писал про куки и бд

[ashap]

Только что, Venter сказал:

ну так я для чего писал про куки и бд

а сессия то откуда возьмется, Сессия это что Куки ? БД?

или $this_>session это магия?

опять лиж бы че написать

[niger]

и все это, чтобы не за..... админку? 

Узнать какой будет следующий заказ.

Где-то запомнить это состояние - занять место в очереди

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

[ashap]

потерянные заказы служат как раз той базой для восстановления заказа, для продолжения покупок

вообще ктото читает ТС ? )

вопрос в том что статус сначала один потом другой

не потерянный заказ

[Venter]

2 минуты назад, nogocuHoBuk сказал:

Вопрос при одновременном создании заказа - вообще не решен...

CREATE TABLE `new_orders` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `token` varchar(255) NOT NULL COMMENT 'это хеш ID будущего заказа',
  `new_id` int(11) NOT NULL COMMENT 'будущий ID',
  `order_date` int(11) NOT NULL COMMENT 'дата создания в формате time',
  `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT 'статус обработано/нет',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

status 1- нет, 2 - обработан

1) Перед тем как перейти к оплате:
  - лезим в таблицу new_orders и выбираем допустим с максим числом поле new_id и status = 1
  - если есть такой, то в сессию уже пишем ID = new_id + 1
  - иначе ID = будущий id
  
2) ID записали в сессию, сделали хеш - записали в куки, в бд - token = хеш, new_id 

3) если в платежке нужно передать ID то передаем тот который создан в 1

4) после успешной оплаты:
  - если есть сессия = создаем заказ, идем в бд и по ID ставим статус 2
  - если нет сессии получаем куки, лезим в бд и получаем new_id, создаем заказ, идем в бд и по ID или по хешу или все вместе и ставим статус 2
  - удаляем сессию, куки

 

2 минуты назад, nogocuHoBuk сказал:

Есть механизм - создание заказа со статусом 0 (чтобы не вмешиваться в аутоинкремент)

блин, да какой же вы тяжолый, я ж сказал что есть моменты разные и решения разные. или не ясно???

я что заставлю использовать свое??? НЕТ

4 минуты назад, nogocuHoBuk сказал:

Подпишусь на Вас. Вы веселый. Прикреплю подпись - велосипедист

сам ты велосипедист ... ))

 

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

а может вообще кто то другое решение зделает под свои хотелки.

 

Блин.... просто взял написал дополнительное решение и начинается..... После вот такого вообще на..у не хочется никому помогать

[Venter]

1 минуту назад, ashap сказал:

вообще ктото читает ТС ? )

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

жесть...

[nogocuHoBuk]

11 часов назад, Venter сказал:

Блин.... просто взял написал дополнительное решение и начинается

Вот серьезно. Не хотел обидеть... Но @ashap прав же. ТС написал, чтобоится, что у него админка будет "за**ана" "временными" заказами. Это изначальная его проблема.
Решение - его конкретной проблемы - понять зачем модуль оплаты  пишет в историю и переводит заказ из потерянного в рабочий. 
Ваше ж решение основано на том, что "так пиши не в ордер, а в нью_ордер". А разница в чём? Причем изначально это Вами (хотя я могу заблуждаться) даже не предполагалось. Просто хранить номер заказа в сессии...
Вот я и отписался с фразой - "это не решение, а костыль"...

 Всё, удаляюсь из темы чтоб не флудить...

[Venter]

12 минут назад, nogocuHoBuk сказал:

Просто хранить номер заказа в сессии...

внимательно читай, очень внимательно, там написано ИЛИ

[chukcha]

делаем дубль таблиц oc_order*

и кладем такой заказ в него
можно даже "забронировать" место в оригинальном oc_order

Сессия здесь не причем..
И куки и прочее, потому как за смену статуса отвечает платежная система

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

 

Все счастливы

 

[nogocuHoBuk]

21 минуту назад, chukcha сказал:

делаем дубль таблиц oc_order*

верно.

2 часа назад, nogocuHoBuk сказал:

Понятно, что можно полностью клонировать все классы checkout, создать дополнительную таблицу (опять же клонировать ордер и орде_хистори, ордер_продуктс, ордер_опшинс и так далее). Но решение ли это?

ведь изначальный вопрос возник у ТС, как я понял, из-за опаски "за***ать" базу (админку). 

а подобная реализация этому не способствует...

ну да такое. 

[chukcha]

5 минут назад, nogocuHoBuk сказал:

едь изначальный вопрос возник у ТС, как я понял, из-за опаски "за***ать" базу (админку). 

а подобная реализация этому не способствует...

Еще как способствует..

создается теневая таблицы(ы) за которыми никто не следит

 

 

7 минут назад, nogocuHoBuk сказал:

онятно, что можно полностью клонировать все классы checkout, создать дополнительную таблицу (опять же клонировать ордер и орде_хистори, ордер_продуктс, ордер_опшинс и так далее). Но решение ли это?

не читал, точнее не следил. Написал свое видение
В принципе достаточно и одной таблицы, а остальные хранить в json