Order Processing Back to Front

My post https://www.nopcommerce.com/boards/t/13652/summary-of-issues-with-the-checkout-process.aspx  summarises the current issues I see with the checkout process and I have also submitted an improvement proposal at http://nopcommerce.codeplex.com/workitem/10392

Please vote if you think this is an important area for future versions!

Alternative views on how to solve these issues are welcome. The two key objectives should in my opinion be that the customer only get an order confimation after the order is paid and that a customer who cancels payment still has the products in the shopping cart when returning to NopCommerce

I agree this is a problem that needs to be look at...

#1
Just because a customer decides to pay differently, should not be assumed that he wants to cancel the transaction itself.
It could also mean that he wants to change the way he pays for it.

#2
Interesting research link, I need to follow up on that cause 29% is quite a lot.

This issue of Paypal Standard redirect clearing out shopping cart, creating order and changing Stock Quantity is a show stopper and may I emphasise is a MAJOR flaw to the nopCommerce product itself.

This has hindered my go live because I really need Paypal Standard payment method on my e-commerce website but having read this thread and seeing that these issues were raised over a year ago and still has not been resolved is disappointing.

Yes there is a scenario where two people may be redirected at the same time which may cause negative stock  quantity as explained which I fully understand but there must be a better solution then to just leave this problem hanging.  Both cases are a major problem and how do other e-commerce websites deal with this issue?  There must be a way to deal with this issue.

I'm on the latest nopCommerce 2.5 now hoping that these issues have been resolved but still not a single sign of change in the Ordering process has been implemented as far as I can see which is a deep disappointment.  I guess the question is when and how fast can this major problem be resolved???

I need to go live with my website and this is the only factor that is hindering my go live.  I need your urgent and honest reply as to when this problem can be resolved fully?

Possible 'solution' for 1.9 users.

I run into this problem with SagePay and have implemented the following solution. BEWARE! This might not work for you, so please full understand what you're doing.

First, open the OrderService logic (Libraries/Nop.Business.Logic/Orders/OrderService.cs) and go to lines: -

3101 - 3105: -
int orderPlacedCustomerNotificationQueuedEmailId = messageService.SendOrderPlacedCustomerNotification(order, order.CustomerLanguageId);
                        if (orderPlacedCustomerNotificationQueuedEmailId > 0)
                        {
                            InsertOrderNote(order.OrderId, string.Format("\"Order placed\" email (to customer) has been queued. Queued email identifier: {0}.", orderPlacedCustomerNotificationQueuedEmailId), false, DateTime.UtcNow);
                        }

Then comment those lines out. Once the order is ACTUALLY paid for, you can notify the customer by implementing the Message Service whereever you need to (most likely checkoutcompleted.ascx.cs, like so: -

Add using statement: -
using NopSolutions.NopCommerce.BusinessLogic.Messages;

Then add code: -
var essageService = IoC.Resolve<IMessageService>();
messageService.SendOrderPlacedCustomerNotification(order, order.CustomerLanguageId);

Obviously you must have the order.

I hope this helps people. Please note: this does not cover other problems that this bug causes - it's purely for fixing the problem of sending emails too early.

Nathan

Thanks Boogle_C.  I ended up using that solution using a similar solution, but that does not really solve the problem.  

IMHO it would be fairly simple to use a decorator on CC purchases that holds or intercepts the order processing until an authorization is received back from the payment processor.  If the NopCom receives anything other than authorized or approved (depending on the payment provider), then it just cancels the order process and leaves the order intact.  Of Course one would want to log it as a failed transaction, and notify the user that the payment transaction failed and to try again or contact customer support.

Another big problem was there was no e-mail verification while registering, i.e. ask new users to type their email twice while registering.  About 1 out of 8 people registering typed in the wrong e-mail address, since the email address was their login, and where their confirmation emails were sent; It caused a huge problems.  The thing is that it's so simple a fix in MVC3 2+ versions of nopCom e.g. all one has to do is add a validation attribute that is included in MVC3, yet it's not implemented.  It can easily be fixed by programming, but how many users are programmers?

It's simple stuff like like payment processing and e-mail validation that really fails NopCom for use as a serious eCommerce solution.  I took a lot of grief from my client because of issues like these, and I don't even want to get into the inventory  system, or lack of it.  I am seriously wondering whether I will use nopCom again.  

There are some great features in nopCom, but if one is not prepared to extend it, I am not sure it's ready for Prime Time.  If you are planning to use nopCom on a high volume sites, issues that users have identified, like payment processing, validation, and inventory need to be addressed.  At least MVC3 makes it easier to do this, but currently you will need some programing experience to implement needed the solutions.

Hi Chorse,

I absolutely agree. I think if this bug was documented and I was aware of the full complications I might have chosen a different route. I'm now knee deep in modifications to a full completed site and i've got to add the changes to what you described.

I will post my end result so people can avoid all the leg work in the future. I have also noticed that when people cancel an order half-way through paying, this creates a mass of manual interventions and maintenance, i.e. cancelling the order and noting why manually. I don't use any stock options within Nop so I can only imagine what effect this would have on those and other possible features?

I heard that Nop 2.0 was re-written from scratch - are you saying they didn't fix that bug even then? I did see a link from one of the devs saying that this was design but with all due respect (and you Nop Devs are dur a lot!), I think the design they've chosen only beneifts 1 in 10 people, whereas what we're describing will benefit the other 9.

Thanks

Going to add my 2 pence.

When the customer confirms the order they are entering into a contract with the seller.

They contract to pay and the seller contracts to sell at the current price.

For this to happen correctly the order must be created and the product variants added to the orderProductVariant table.

Otherwise changes to the PVs price would be reflected in the overall cost of the order.

You should be aware that any discount use-age on the order is recorded at this time.

So for example; if the customer enters a discount code with '1 use per customer only' and confirms the order they then cannot use it again.

I would expect customer services/ sales to contact any customers that have placed an order but not paid for the order, to resolve any payment issues they have. For instance a payment could be taken over the phone or they may be paying at a store when picking up their order.

If the prices are not fixed when the order is placed ie when the customer confirms the order, the seller could be in the embarrassing position of asking for more money than the customer agreed to pay for the goods/services.

What you all seem to be missing is that when the customer confirms an order it should become an order. Payment is a separate step in completion of the agreed contract. Usually this runs as follows but not always.

eg Order -> Payment -> Delivery

it could be in the case of say B2B purchase orders

Order -> Delivery -> Payment

HTH

Dave

Hi Dave,

I agree with you also, your post makes sense, however it does not explain why an email is sent to the customer saying 'Thanks for your order' quoting the amount they have paid... when in fact, they haven't paid?

Perhaps, to circumvent this, there should be a Nop setting for the admin to tell Nop when to send which email, and whether or not to keep orders as 'pending' if a payment failed/the customer backed out of an order. Some indsutries and market sectors' audience will NOT appreciate been cold-called because an order attempt was made.

I'm sure there's many ways to look at this from a business point of view and hey, the source code is there, so if we're not happy with it let's change it, but regardless of all that, i'm confident that the order email is sent too early.

Thanks
Nathan

@daveb.  I understand your point for non CC payments, but the nopCom payment system doesn't meet the real world business needs and actually lowers the conversion rate.  If something happens at the payment phase (http post), and this happens quite a lot. there is no second email confirmation sent notifying the customer that it has failed, but the customer does get an order confirmation.  In addition the cart is cleared, and order has been placed, the inventory subtracted, it's a mess and creates a lot of confusion, and work for the store owner, and creates unhappy customers.
  
On most ecomm sites if the payment fails you are notified that the payment has failed and you are returned to the basket to either try again or change payment method, card etc.  In nopCom this is not possible.  Maybe if you have a few orders a day this is not a big deal, but if one is getting 50 -100 digital orders a day and 10 - 15 of them are failing at the payment stage it's a big mess.  

nopCom should be helping the store owner, not creating more work and alienating the customers.  This causes a lot more embarrassment for the seller.  The cure is worse than the disease.  nopCom has some great features, but the CC payment system needs work.

@BoogleC - Yeah I agree it should not say a payment has been received. Change the message template to do this I guess. And add an email after payment is confirmed. Agreed cold calling may not be acceptable however an email almost certainly will be - I'd include a helpline number in it so they can ring to get help.

@chorse - It is your/the store holders responsibility to convert those 10-15 orders per day that are failing. They are orders, just unpaid. While I realise that it would be easier for you to get the customer to retry payment, I feel you should be putting some effort in rather than expecting everything to be done for you.

This is an opportunity for you to provide added value to your customer with a personal touch. Maybe it will encourage them to trade with your store again? Maybe you will get a good review/ personal recommendations out of it? 15%-20% failure rate. Looking at this as an opertunity rather than a chore is what separates a good store owner from an indifferent or bad one.