Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

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


kitsune44

Recommended Posts

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

Надіслати
Поділитися на інших сайтах


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

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

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

Надіслати
Поділитися на інших сайтах

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

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

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

Надіслати
Поділитися на інших сайтах

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

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

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

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


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

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

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


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

  • +1 1
Надіслати
Поділитися на інших сайтах

 

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

 

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

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

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

Надіслати
Поділитися на інших сайтах

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

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

 

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

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

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

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

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

ИЛИ

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

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

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

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

Надіслати
Поділитися на інших сайтах

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

 

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

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

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

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

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

ИЛИ

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

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

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

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

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

Спойлер

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

 

  • +1 2
Надіслати
Поділитися на інших сайтах

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

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

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

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

Надіслати
Поділитися на інших сайтах

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

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

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

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

Надіслати
Поділитися на інших сайтах

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

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

 

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

 

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

Надіслати
Поділитися на інших сайтах

  

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

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

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

 

Надіслати
Поділитися на інших сайтах

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

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

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

 

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

Надіслати
Поділитися на інших сайтах

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

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

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

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

Надіслати
Поділитися на інших сайтах

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

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

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

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

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

  • +1 1
Надіслати
Поділитися на інших сайтах

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

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

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

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

Надіслати
Поділитися на інших сайтах


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

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

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

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

  • +1 2
Надіслати
Поділитися на інших сайтах

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 сказал:

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

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

 

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

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

 

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

Надіслати
Поділитися на інших сайтах

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

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

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

жесть...

Надіслати
Поділитися на інших сайтах

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

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

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

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

Надіслати
Поділитися на інших сайтах

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

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

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

Надіслати
Поділитися на інших сайтах

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

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

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

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

 

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

 

  • +1 1
Надіслати
Поділитися на інших сайтах

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

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

верно.

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

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

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

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

ну да такое. 

Надіслати
Поділитися на інших сайтах

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

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

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

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

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

 

 

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

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

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

Надіслати
Поділитися на інших сайтах

Створіть аккаунт або увійдіть для коментування

Ви повинні бути користувачем, щоб залишити коментар

Створити обліковий запис

Зареєструйтеся для отримання облікового запису. Це просто!

Зареєструвати аккаунт

Вхід

Уже зареєстровані? Увійдіть тут.

Вхід зараз
  • Зараз на сторінці   0 користувачів

    • Ні користувачів, які переглядиють цю сторінку
×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.