Skip to content

ошибочный алгоритм обработки платежа #4

Open
iDdonskoy opened this issue Jan 31, 2018 · 14 comments
Open
Labels

Comments

@iDdonskoy
Copy link

У Вас в модуле заложен странный алгоритм обработки платежа, при котором сразу после редиректа на страницу оплаты яндексКассы из корзины заказа происходит обнуление корзины и приходит уведомление об успешном платеже. При этом сам платеж на стороне яндекса еще не произошел. Клиент не оплатил заказ(передумал) и вернулся в магазин, товар списался, магазин получил уведомление, что все ок, клиент тоже получил уведомление, что все отлично, оплата через яндекс успешна и т.д. Клиент решил все же оплатить, а товара то и нет в наличии. Заходит в личный кабинет и видит, что с него требуют оплату чеком(зачем заложили статус "Ожидание платежа по квитанции" не понятно) и офигивает, как заплатить-то? В прошлых версиях такого не было, все было логично... пока не исправите сей "баг" - модуль видится не рабочим. Алгоритм этот и в в1,6 и 1,7

@ikarmanov
Copy link

Спасибо за информацию. Скоро опубликуем новую версию модуля с исправлением.

@iDdonskoy
Copy link
Author

обновление есть, исправления нет

@iDdonskoy
Copy link
Author

Я в январе описывал проблему, поставили баг, выпустили кучу обновлений, но так и не исправили описанную проблему. Я не понимаю, кто тут пользуется вашим модулем если он не рабочий!? У вас оплата проходит без фактической оплаты клиентом, как можно этим пользоваться вообще?

@ostulov
Copy link

ostulov commented Sep 24, 2018

Для перехода к оплате модуль создает заказ и использует для этого метод Prestashop. При этом происходит списание товара (то есть резервирование товара для данного заказа). Такая логика позволяет предотвратить ситуацию, когда при одной единице товара заказ одновременно оплатят два клиента. Таким образом мы приняли решение не менять используемый метод создания заказа.

При этом заказ при переходе к оплате не должен считаться оплаченным. Смена статуса заказа на "Оплачен" должна происходить при фактической успешной оплате.
Если у Вас при переходе к оплате наблюдается другое поведение, прошу прислать подробности на [email protected]

@iDdonskoy
Copy link
Author

iDdonskoy commented Sep 24, 2018

Написал на почту, проблема не решена, а Вы просто самоустранились. Клиент не может совершить повторную оплату списанного товара, такого просто не предусмотрено в Prestashop. Покажите, как можно оплатить товар из личного кабинета со статусом "в процессе", да и в любом другом? Кнопки "Оплатить", "Купить" или любой другой в истории заказов просто не существует, есть только "Перезаказать" - это продублировать заказ, если есть товар, а он у вас списан. Так тяжело понять? В старом модуле все было нормально! Я бы и со старым работал, но он не подходит на 1.7!
Одновременно оплатить товар можно только в теории, на практике после оплаты одним клиентом, у второго товар становится "нет в наличии" и оплата не проходит. На старом модуле. Сверху лайки люди ставят, наверное, не теоретики и понимают, что так, как Вы пишите - не работает.

И еще, из практики... Вы создаете функцию бессрочного бронирования товара!? Серьезно!? Т.е. клиент или "диверсант" может зайти в магазин и "забронировать" весь товар на неделю, месяц... год? Это логично что ли? Бронирование товара может быть только как доп функция с ограниченным временем, а не как стандартный функционал!

@ramzes-84
Copy link

Тестировал данный API-модуль для перехода на ФФД 1.05 (на тот момент старый HTTP-модуль для Prestashop версии 1.4.7 еще не был доработан для ФФД 1.05). При переходе к оплате корзина действительно "погашается", а заказ формируется. При этом, если покупатель передумал оплачивать на сайте, решив посмотреть другие способы оплаты, вернуться к заказу он уже не может - "Корзина пуста".
Соглашусь с автором темы, что это крайне не удобно и для владельца магазина, и для покупателя. По опыту знаю, что бОльшая часть покупателей (у меня это женщины всех возрастов) мечется между способами оплаты, анализируя, какие способы доступны, есть ли комиссия и т.д. При этом, каждое такое "метание" будет порождать неразбериху: клиент не будет понимать, завершил ли он заказ или нет, магазин не будет понимать, прошёл ли платёж (в стандартном представлении списка заказов в моём случае отображалось "Payment via Yandex.Checkout: Яндекс.Деньги", статус успешного платежа присвоен не был).
Короче, было бы здорово решить данную проблему. В любом случае спасибо за модуль 1.4.8 - прекрасно работает!

@anvarkzn
Copy link

anvarkzn commented Mar 4, 2019

Разработчики Яндекса! Вы действительно, собираетесь устранить данную проблему?
Сколько можно писать сюда, чтобы вы исправили этот баг?

@ostulov
Copy link

ostulov commented Mar 4, 2019

Добрый день!

Для перехода к оплате необходимо обнулить корзину.
Статус заказа меняется на успешно оплаченный только после фактической оплаты.
До момента успешной оплаты заказу присваивается промежуточный статус. Установите настройки промежуточного статуса в админпанели Prestashop таким образом, чтобы он не считался оплаченным.

@ramzes-84
Copy link

Добрый день!
В модуле 1.4.8. корзина не обнуляется. При возврате с сайта Яндекса корзина сохраняется и можно спокойно выбрать иной способ оплаты.
Нельзя ли сделать такой же принцип работы в модуле версии 2?

@Olegu13
Copy link

Olegu13 commented Mar 14, 2020

Проблема осталась.
при переходе к оплате статус товара переходит в обработку и сразу же в оплачено!
{ module_version: "1.1.11", cms_version: "1.7.6.3" }

к сожалению если проблему не устранят прийдется выбирать другую компанию Эквайринга

@Olegu13
Copy link

Olegu13 commented Mar 15, 2020

Для перехода к оплате модуль создает заказ и использует для этого метод Prestashop. При этом происходит списание товара (то есть резервирование товара для данного заказа). Такая логика позволяет предотвратить ситуацию, когда при одной единице товара заказ одновременно оплатят два клиента. Таким образом мы приняли решение не менять используемый метод создания заказа.

При этом заказ при переходе к оплате не должен считаться оплаченным. Смена статуса заказа на "Оплачен" должна происходить при фактической успешной оплате.
Если у Вас при переходе к оплате наблюдается другое поведение, прошу прислать подробности на [email protected]

Логика не верная -> в итоге модуль не рабочий -> впустую потраченные ресурсы время разработчиков.
!!!Вы используете резервирование товара до оплаты, а должны использовать это только после успешной оплаты.
С стороны бизнеса ваша логика не верна потому что:
1)клиент что-то забыл хочет вернуться исправить
2)у клиента закончились средства на карте или другом средстве платежа он хочет вернуться и выбрать другой метод оплаты
3)клиенту нужно срочно куда-то уйти и он решает не оплачивать сейчас
В всех этих случаях клиент не сможет оплатить в дальнейшем свою корзину!!!

@spinybeast
Copy link

Добрый вечер! Планируется ли что-то делать с этим багом?
Сейчас в последней версии корзина не обнуляется, и можно исправить заказ, но перед этим уже создался заказ, со статусом "В обработке". Этот статус ставится всем новым заказам. Как клиенту оплатить неоплаченный заказ, не понятно. Как отличить оплаченный от неоплаченного в админке - тоже.
Очень бы хотелось дальше использовать ваш модуль, без этого недоразумения. Надеюсь на ответ.

@anvarkzn
Copy link

Добрый день!

Для перехода к оплате необходимо обнулить корзину.
Статус заказа меняется на успешно оплаченный только после фактической оплаты.
До момента успешной оплаты заказу присваивается промежуточный статус. Установите настройки промежуточного статуса в админпанели Prestashop таким образом, чтобы он не считался оплаченным.

Проблема в том, что после возврата в корзину без завершения оплаты(причины могут быть разные), корзина обнуляется и формируется заказ. Покупателю приходится формировать заказ повторно!
Раз нельзя изменить логику покупки... возможно ли, добавить в детали заказа(во фронте) кнопку, для завершения платежа?

@ostulov
Copy link

ostulov commented Mar 22, 2021

Добрый день!

Благодарю за предложение, рассмотрим такую возможность.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests

7 participants