Being new to NopCommerce I may be missing something, but it appears to me that the order processing is back to front. After configuring NopCommerce to use PayPal Standard as the only payment method and setting up a SandBox for testing I noticed that email confirmations are being sent before the customer has paid for the goods. I also notice that the shopping cart is cleared down and an order submitted to the database prior to the customer paying for the goods. Surely all this processing should take place when the customer is returned to NopCommerce after paying for the goods, otherwise the order management side of the site and the database becomes filled with bogus orders, i.e. if the customer decides to return to the site to make changes to the order or the customer decides to navigate away all together when on the PayPay payment screen.
As stated NopCommerce is all new to me and I was wondering if anyone else has experienced these problems and how they have been overcome.
Any help would be much appreciated.
Order Processing Back to Front
- 23
- 125
- 10/28/2009
- Germany
I'm experiencing a similar "issue" with manual processing.
I wouldn't mind if it would go this way:
1. Email to customer that someone has placed an order. This happens when then user confirms the order.
This is just before he is being redirected to Paypal etc. or in case it is a manual process.
2A. Paypal/Wirepay... etc. returns a success. Depending on your setup I expect an email to be sent to the customer saying that everything is alright and that the store is packaging all the goods in order to be send to him.
2B. Say it was a manual order, the admin sets the status to Mark as paid, I expect the mail mechanism to trigger that notification as well. This is my problem as it will not send one
3. Admin sets the order as shipped, an email is sent, that is fine
4. Admin sets the order as delivered, an email is sent, that is fine as well
5. Another email is send that the order has now been completed, ok. This might only make sense if there were
multiple delivieries??? Anyways, you could leave that
But I'm really missing the Mark as Paid trigger to send an email. Is this by Design? This makes a bit more sense in the whole process.
By not having the 2nd step, the customers and my clients (store owners) get a bit confused "does that mean it is paid?" And then they get 3 mails in a row Shipped, Delivered, Completed (ok, we switched that off).
Any thoughts?
Cheers, deval
@acessl:
Missed what I actually wanted to say, I think it is neccessary that there is an order entry in nopcommerce, whether they have paod or not, as they are several ways to pay. And if you chose Paypal etc, in case the payment failed for whatever reason ( I forget pretty often my paypal credentials), the order is still in the system, and the user can try it again sometime later. Store owner could contact him..
I wouldn't mind if it would go this way:
1. Email to customer that someone has placed an order. This happens when then user confirms the order.
This is just before he is being redirected to Paypal etc. or in case it is a manual process.
2A. Paypal/Wirepay... etc. returns a success. Depending on your setup I expect an email to be sent to the customer saying that everything is alright and that the store is packaging all the goods in order to be send to him.
2B. Say it was a manual order, the admin sets the status to Mark as paid, I expect the mail mechanism to trigger that notification as well. This is my problem as it will not send one
3. Admin sets the order as shipped, an email is sent, that is fine
4. Admin sets the order as delivered, an email is sent, that is fine as well
5. Another email is send that the order has now been completed, ok. This might only make sense if there were
multiple delivieries??? Anyways, you could leave that
But I'm really missing the Mark as Paid trigger to send an email. Is this by Design? This makes a bit more sense in the whole process.
By not having the 2nd step, the customers and my clients (store owners) get a bit confused "does that mean it is paid?" And then they get 3 mails in a row Shipped, Delivered, Completed (ok, we switched that off).
Any thoughts?
Cheers, deval
@acessl:
Missed what I actually wanted to say, I think it is neccessary that there is an order entry in nopcommerce, whether they have paod or not, as they are several ways to pay. And if you chose Paypal etc, in case the payment failed for whatever reason ( I forget pretty often my paypal credentials), the order is still in the system, and the user can try it again sometime later. Store owner could contact him..
- 10
- 60
- 9/4/2010
- United Kingdom
Hi Deval,
I appreciate your argument with regards to writing the order to the database, but until the customer has paid there is no order. Semantics I know, but less confusing all round. Personally I would be very confused and some what concerned if I received an email stating I'd made an order knowing full well I hadn't.
Furthermore the items the customer is interested in purchasing are in fact still in the shopping cart and that is where, in my opinion, they should stay until paid for. Thus if the customer returns to the site before paying, their shopping cart would still be in tact.
If the payment process failed, still having the shopping cart in tact then the customer could resubmit the order as well.
If the customer wanted to save the contents of the shopping cart for later use, it can be saved as a wishlist.
Regards.
I appreciate your argument with regards to writing the order to the database, but until the customer has paid there is no order. Semantics I know, but less confusing all round. Personally I would be very confused and some what concerned if I received an email stating I'd made an order knowing full well I hadn't.
Furthermore the items the customer is interested in purchasing are in fact still in the shopping cart and that is where, in my opinion, they should stay until paid for. Thus if the customer returns to the site before paying, their shopping cart would still be in tact.
If the payment process failed, still having the shopping cart in tact then the customer could resubmit the order as well.
If the customer wanted to save the contents of the shopping cart for later use, it can be saved as a wishlist.
Regards.
- 10
- 60
- 9/4/2010
- United Kingdom
Hi Deval,
Apologies for not responding to your question/issue. I've been stepping through the code to determine where the order is written to the database and where all these emails get fired. Not quite there yet, but narrowing it down.
I suspect you'll have to do the same within the admin side of the site and implement your own event handler that you can wire up and send your email as required.
Regards.
Apologies for not responding to your question/issue. I've been stepping through the code to determine where the order is written to the database and where all these emails get fired. Not quite there yet, but narrowing it down.
I suspect you'll have to do the same within the admin side of the site and implement your own event handler that you can wire up and send your email as required.
Regards.
- 23
- 125
- 10/28/2009
- Germany
accesl,
I can see where you're coming from.
So you're basically saying after a user clicks the confirm button, the shopping cart should keep all items until the Order gets an payment status of Paid.
Actually after having tried a test purchase and cancelling on the PayPal side,
Cart is empty.. hmm. I'm actually on your side now (partially) :-)
Well I think we would need two approaches here.
1. Immediate Payment (Paypal etc.)
Cart gets only cleared when feedback from payment provider is a success. Optionally having a setting saying if you still want that order to be placed (Reason is not a negative provider response, no provider response at all. Network issue whatnot. So you as a store owner might want to contact the customer asking him what happened etc. Backorder ...)
2. Non-Immediate Payment (Purchase on delivery, Money order)
After the user clicks on confirm, carts get cleared and order is placed.
AND A EMAIL TRIGGER FOR Mark As Paid.
(EDIT 21/09/2010: I mean the email should be triggered when the admin clicks on mark as paid, not when the user clicks on confirm. Sorry for the confusion)
What do you think?
As a workarround you could switch of all Mail Messages except the OrderShipped.CustomerNotification
Change the wording to smth like "Paid and on its way", so no emails will be sent when an order alone has been placed.
Deval
I can see where you're coming from.
So you're basically saying after a user clicks the confirm button, the shopping cart should keep all items until the Order gets an payment status of Paid.
Actually after having tried a test purchase and cancelling on the PayPal side,
Cart is empty.. hmm. I'm actually on your side now (partially) :-)
Well I think we would need two approaches here.
1. Immediate Payment (Paypal etc.)
Cart gets only cleared when feedback from payment provider is a success. Optionally having a setting saying if you still want that order to be placed (Reason is not a negative provider response, no provider response at all. Network issue whatnot. So you as a store owner might want to contact the customer asking him what happened etc. Backorder ...)
2. Non-Immediate Payment (Purchase on delivery, Money order)
After the user clicks on confirm, carts get cleared and order is placed.
AND A EMAIL TRIGGER FOR Mark As Paid.
(EDIT 21/09/2010: I mean the email should be triggered when the admin clicks on mark as paid, not when the user clicks on confirm. Sorry for the confusion)
What do you think?
As a workarround you could switch of all Mail Messages except the OrderShipped.CustomerNotification
Change the wording to smth like "Paid and on its way", so no emails will be sent when an order alone has been placed.
Deval
- 10
- 60
- 9/4/2010
- United Kingdom
Hi Deval,
To your first part yes, the shopping cart should only be cleared down on a successful transaction (payment status paid). In all other situations, payment failure, gateway error, network error, etc. the shopping cart should remain in tact. This allows the customer the freedom to choose what next and if their shopping cart is in tact they are more likely to try again than if it were empty and they had to start selecting the items again. Remember the customer is in control! In this situation there is no reason why the "Seller" could not be informed, e.g. email, log entry, etc. Though I suspect the "Seller" would soon get bored of the number entries and trying to determine which ones are genuine orders that the customer would have liked to have placed and which ones are not, i.e. the customer decided just not to bother and bailed out at the payment stage. Of course this could all be automated and a generic email sent off when ever a payment error occurred.
I guess this is all down to preference and your client's requirements. But, having worked on and developed a number of e-commerce sites myself in the past, I have to say the functionality exhibited by NopCommerce is not what I was expecting.
I have to stress though that my main concern is NopCommerce sending an email, "Thanks for buying from ....... Below is the summary of the order.", before any transaction has taken place, i.e. as soon as the customer clicks the "confirm" button.
In fact you have highlighted a very valid scenario for not firing emails off until a successful transaction has taken place, i.e. the customer has selected items to purchase, goes through the checkout process and clicks "confirm", at this point the customer is emailed with a "Thanks for buying from..." and taken off to the payment provider, at this point there is a network failure and the customer is unable to complete the transaction, yet the customer has an email sat in his inbox now saying thanks for buying. So does the customer assume it all went through before the network failure and wait for his goods to arrive or does he think that can't be right I never completed the transaction, tries again or contacts the site to find out what's going on or just leaves it and goes somewhere else?!! Furthermore what does the seller do? Does the seller contact the buyer, if details known, and explain that the transaction didn't actually take place and if the buyer would like the goods could they resubmit their order? It all starts to get a bit to smelly for me and personally as a buyer I would start to question the validity of the site I was trying to buy from.
With regards to your suggestion of having two approaches, in my opinion there is only one and it fits all payment methods. The shopping cart should not be cleared, an order should not be writen to the database and emails should not be fired until a successful transaction has taken place. The only difference, in my view, is the wording of the email when a successful transaction has taken place and this is dependent on the payment method, i.e. where the customer has actually paid for the goods via credit card or some other immediate online payment method (PayPal, etc.) then the customer should be emailed with an order confirmation saying "Thank you for buying from xyz. Your order is being processed and will be dispatched shortly". If the customer has chosen to pay manually (cash on delivery, mail order, cheque, etc) then the email should be worded appropriately, e.g. in the case of paying by cheque the email could say "Thanks for your order which is now being processed. On receipt of your cheque and funds being cleared, the goods will be dispatched.".
I don't think switching off all messages except the OrderShipped message is a valid work around. Most online payment gateways will email the buyer independently of the seller to inform them that their credit card has been used to make an online purchase. I also believe there is a legal requirement to inform the buyer as well.
I hope this all makes sense. If you disagree then please let me, I would like to hear your comments.
Regards,
acessl.
To your first part yes, the shopping cart should only be cleared down on a successful transaction (payment status paid). In all other situations, payment failure, gateway error, network error, etc. the shopping cart should remain in tact. This allows the customer the freedom to choose what next and if their shopping cart is in tact they are more likely to try again than if it were empty and they had to start selecting the items again. Remember the customer is in control! In this situation there is no reason why the "Seller" could not be informed, e.g. email, log entry, etc. Though I suspect the "Seller" would soon get bored of the number entries and trying to determine which ones are genuine orders that the customer would have liked to have placed and which ones are not, i.e. the customer decided just not to bother and bailed out at the payment stage. Of course this could all be automated and a generic email sent off when ever a payment error occurred.
I guess this is all down to preference and your client's requirements. But, having worked on and developed a number of e-commerce sites myself in the past, I have to say the functionality exhibited by NopCommerce is not what I was expecting.
I have to stress though that my main concern is NopCommerce sending an email, "Thanks for buying from ....... Below is the summary of the order.", before any transaction has taken place, i.e. as soon as the customer clicks the "confirm" button.
In fact you have highlighted a very valid scenario for not firing emails off until a successful transaction has taken place, i.e. the customer has selected items to purchase, goes through the checkout process and clicks "confirm", at this point the customer is emailed with a "Thanks for buying from..." and taken off to the payment provider, at this point there is a network failure and the customer is unable to complete the transaction, yet the customer has an email sat in his inbox now saying thanks for buying. So does the customer assume it all went through before the network failure and wait for his goods to arrive or does he think that can't be right I never completed the transaction, tries again or contacts the site to find out what's going on or just leaves it and goes somewhere else?!! Furthermore what does the seller do? Does the seller contact the buyer, if details known, and explain that the transaction didn't actually take place and if the buyer would like the goods could they resubmit their order? It all starts to get a bit to smelly for me and personally as a buyer I would start to question the validity of the site I was trying to buy from.
With regards to your suggestion of having two approaches, in my opinion there is only one and it fits all payment methods. The shopping cart should not be cleared, an order should not be writen to the database and emails should not be fired until a successful transaction has taken place. The only difference, in my view, is the wording of the email when a successful transaction has taken place and this is dependent on the payment method, i.e. where the customer has actually paid for the goods via credit card or some other immediate online payment method (PayPal, etc.) then the customer should be emailed with an order confirmation saying "Thank you for buying from xyz. Your order is being processed and will be dispatched shortly". If the customer has chosen to pay manually (cash on delivery, mail order, cheque, etc) then the email should be worded appropriately, e.g. in the case of paying by cheque the email could say "Thanks for your order which is now being processed. On receipt of your cheque and funds being cleared, the goods will be dispatched.".
I don't think switching off all messages except the OrderShipped message is a valid work around. Most online payment gateways will email the buyer independently of the seller to inform them that their credit card has been used to make an online purchase. I also believe there is a legal requirement to inform the buyer as well.
I hope this all makes sense. If you disagree then please let me, I would like to hear your comments.
Regards,
acessl.
- 23
- 125
- 10/28/2009
- Germany
Hi there,
I'm gonna go through the code and compile some diagrams to illustrate what code has to be modified.
Maybe we can go through it together and think about a good solution, maybe this is then going to be included in the next release. It's just too important for a quick and dirty fix.
Hopefully by the end of today I'm done with it.
Cheers
I'm gonna go through the code and compile some diagrams to illustrate what code has to be modified.
Maybe we can go through it together and think about a good solution, maybe this is then going to be included in the next release. It's just too important for a quick and dirty fix.
Hopefully by the end of today I'm done with it.
Cheers