search

202-ecommerce / stripe_official

After years of hard work with Stripe connector for PrestaShop, 202 ecommerce stop the development of Stripe module on January 9th 2023. Thanks for all contributors that help us!
20 stars 20 forks source link

Customer selected Carrier/Shipping option is removed on order creation and replaced with $0 shipping method. #171

Closed skellatore closed 2 years ago

skellatore commented 2 years ago

Stripe Module Version: 2.4.4 Prestashop Version: 1.7.8.5

Intro We've been having a problem with Stripe since about Jan 2022 where it breaks an order that has a "External Carrier" selected. I know it was working OK with v2.3.6 and it was spewing weird problems in the messages box in v2.3.4 where we logged a bug report. As a work-a-round we've been forced to process orders manually (Authorize+Capture) when a client pays with stripe as a result - which is quite infuriating and slow.

For the sake of Clarity, only Stripe has this problem. Other payment gateways such as PayPal does not have any of these problems with the same ordering process and shipping method selection, so I know it's not a problem with the Carrier/Shipping module.

Description of problem: When an order comes in that has used a "External Carrier" - that is a Carrier that has live-rates:

If you're unfortunate enough to change the order status to anything that triggers the Capture, You're screwed because;

  1. You can no longer edit the order
  2. Stripe will only capture the Product Amount - not the full/total order amount as originally intended (so you wont be getting paid for shipping!)
  3. You have no way to get Stripe to re-capture the remaining/outstanding Shipping amount.

Because this breaks so badly that we have to refer to the "Shopping Carts" section to actually figure out what carrier the customer selected in the first place. Even the Cart still has the correct information in it - the Order just breaks big-time.

As a side note, The customers are also confused because they selected a shipping method but get emailed telling them it's for "Pickup" and they are on the other side of the earth.

Any assistance or remediation would be greatly appreciated as I'm about to ditch Stripe all-together as a result of the continuous problems.

clotairer commented 2 years ago

Hello,

Thank you for your clear explanation. It looks like an issue due to Stripe specific "State" associated to the wrong configuration. In previous release 2.3.x there is some mistake of associations on upgrades.

We create a diagnostic module to verify this kind of errors:

  1. Install this module v1.0.0-prod-totsupport.zip
  2. Go to the configuration of this module and choose in the list the module Stripe.
  3. Got to the Diagnostic tab
  4. In the section "Orders states", you will have an array like that. Please verify all associations are fine. image If not, it tells what is not valid. You can also verify, if tables of the module, hooks, and some others checks are OK.

If you want more assistance in private, do not hesitate to write us to this contact form in FR / EN or IT.

skellatore commented 2 years ago

Thanks for your rapid response. Order States: image

I also noticed this: image

skellatore commented 2 years ago

I also note that i tried both "Fix Order states" and "Associate Order states" after selecting what I thought was correct and nothing happened/changed that I could see :(

skellatore commented 2 years ago

The Hooks were able to be fixed.

clotairer commented 2 years ago

This diagnostic module is quite experimental...

  1. For states, you need to select the good state manually and after clic on "Associate". If it doesn't work, you need to update the ps_configuration table with the right ID. You could verify after that the association in the Diagnostic module. The fix button update characteristics of the selected state to align with the right values (for instance in your case, it will change the color of Awaiting Sofort... ). No need to fix for you.
  2. These two hooks should be plugged but manage only display data. No action
skellatore commented 2 years ago

STRIPE_OS_SOFORT_WAITING didnt even exist in the ps_configuration table, but a different name that was similar did (STRIPE_SOFORT_WAITING_OS).

I fixed the colours - not that it mattered, just to make sure it showed up as valid: image

And it still didn't work. It's stripped the shipping and and now is worse than before because it's marking the order as "Payment Error". This thing is totally ignoring the statuses configured. I'm at a total loss. image image image

clotairer commented 2 years ago

Hello,

Could you send us a message in this contact form for a private exchange. Write you are in contact with me on github issue 171. I could find you and analyze your logs, specific development like overides, ...

Thank you.

skellatore commented 2 years ago

I have done this, but this is becoming urgent as now customers are placing duplicate/triplicate orders as when the order is created, it's being marked as "Payment Failed" even though it's gone through and "authorised" correctly. This is a ghastly bug.

clotairer commented 2 years ago

I recieved your support ticket. And linked to this issue. Thank you.