Order Processing Back to Front

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
13 years ago
Hi Deval,

That sounds really good and you're right it needs some careful thought and is too important to just come up with some dirty fix.

And yes I would like to work on a solution with you, one that resolves all our problems and hopefully does make it into the next release. We don’t want to be amending code in future versions of the software.

Look forward to seeing the diagrams. How do you feel about taking this off-line or would you prefer to stick to the forum?

Regards,

acessl.
13 years ago
Sure, I finished the first walkthrough for what happens when the user clicks on confirm.

I send you PM with my contact details.

We let the others know about our findings once we have an idea. Anyone interested in the process, PM me.

Cheers
13 years ago
Interesting. I've just been looking at the same code and it's not pretty is it?! I need to get a callback when an order has been definitively paid for or rejected (please see thread if you have time). Does your research help me at all?
13 years ago
PS Don't forget there are some payment types which require admin approval, such as purchase order. You wouldn't keep them in the cart until the admin has marked as paid (but we *do* want an order paid status changed handler to notify of that change when it happens).
12 years ago
Did anyone solve the PayPal Standard order cancel / customer returns to website / shopping cart empty problem?  If so, can someone please post the solution or PM the solution to me.  Experiencing this problem with PayPal standard adn nopCommerce 1.90.

Thank you.
12 years ago
I have experienced the exact same problem, and it is going to occur on any http post to a payment provider when the payment fails for whatever reason.  Once the http post is made for payment approval i.e. after the last confirm; the basket is cleared and a order placement e-mail is sent to the customer, and the order is written to nopCommerce.   If nopCommerce it gets back and authorization from the payment provider then it marks it as paid, in all other instances it remains pending.  

This is OK for manual payments (checks, Bank transfers, etc.), but for any type of hosting credit card payment providers (there probably needs to be an enum to differentiate between the two); It would make a lot more sense that the cart is not emptied, nor email sent, until the payment providers authorization is received.   All other transactions from the payment provider, no answer, failed connections, credit card refusals, etc.  Should just return the use to a customizable failure message (template) page on the site, with shopping cart item intact, and without sending an order .  This will allow the user to try the transaction again without the confusion of the placed order message for failed transactions.

For me this is a major show stopper.  I will not use, nor could I recommend nopCommerce again for a live eCommerce site as long as this problem exists.
12 years ago
Is this issue being resolved?
I just cannot believe the system is sending an email when it does not yet, if a payment is being provided.

I hope the idea was not to have a system that sends our customers 1 email for every step it does.
Customers don't care nor want various emails for 1 transaction.

They just care to receive ONE email with a payment acknowledgement of their purchase.

If I ever had to buy from a site that sends me an email confirming an order is being placed
when I know the order was cancelled by me ...i would not want to buy any longer from that site
(if you know what I mean).

Please tell me this has been resolved, cause ..it is a total show stopper.
12 years ago
Hi,


Is there any more info regarding this.
12 years ago
It's not the bug. It's by design. Find more info about the reasons here
12 years ago
Andrei.  Thanks for the explanation, but...

I am sorry, but this is a case of the cure being much worse than the disease!!!!  Yes Dr. we cured the disease, but the patient died.

IMHO, The chances of ordering an out of stock item is miniscule compared to the problem that that you have created.  The out of stock issue can be easily handled by an e-mail informing the user that the item is out of stock and the customer can wait for restock, or get a refund.  I do not anticipate this happening to often.  On the other hand pending and incomplete orders are a big problem on every 4th or 5th transaction and they cause confusion and a lot of work by the customer service reps answering questions, about whether the order has been placed, why they are getting two order placements, why they are getting cancellations etc.. It's a big mess, and it should be unacceptable.  

A more elegant solution and correct solution would be to reduced the stock by the order amount on the final confirm (HTTP post) , but if the return code is anything but an authorization, then rollback the change and add the stock quantity back.  This could be done programically or through a stored procedure that fires if anything but an authorization received.  Finally, no notification should sent until authorization is or alternatively let the placement order notification be sent as it is now, but send an automatic cancellation notice is sent if the stock transaction is rolled-back.   This is much better solution to the stock issue, than creating a large bug in the program, to solve a smaller problem.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.