Why does Virtuemart create orders before receiving payment?

[rainman2000]

In VM 1.x there was the infamous PayPal bug where VM would create an order before payment was received when someone payed via PayPal. A company called B-Planet (http://www.b-planet.com/VirtueMart/paypal-patch.html) created a patch to resolve this issue, but they didn't update it because they said it would be fixed in VM 2. Unfortunately the weird behavior is still there. The only change I see is that now you can stop the user from receiving a confirmation email before the order is confirmed. However, this is still frustrating because users create orders on your system and if you have 10 of these type incomplete orders per week someone has to manually sift through each and contact the customer to see if they really want to pay or not.

I've never seen a major online store thank me for ordering before the order was truly complete. Why would the developers even create an order in VM before you receive the PayPal confirmation? Why not implement the B-Planet PayPal Patch into the core as it worked flawlessly? Even if B-Planet updated the patch, I really don't want to begin hacking our system again. Perhaps there is a real solution for this that I'm unaware of.

Thanks,
Rainman

[stinga]

It is not really a bug.
What about the people who do COD? They need an order before payment or those with account customers, pay at end of month.
Need to think of others as well as cash account customers.
It should be a setting, only create an order on payment type of setting.

[rainman2000]

You're correct Stinga, it's not really a bug. It's just a design flaw that I find hard to believe made it into VM 2 after so much discussion about it from VM 1.x. As for COD and account customers, I'm not forgetting them. We allow this as well, by simply creating a PO payment method and certain customers can see the PO option at checkout. However, I'm unsure if there is ever a time to create an order when the payment method is PayPal or credit card.

To sum it up, order should not be created until entire checkout process has completed successfully. For PO orders, there is just submitting the order and it's successful. However, with PayPal, credit card and other payment methods, the customer must submit order AND pay before it order can be considered successful. Until then it should not tell the customer "Thank You." Again, the B-Planet Paypal patch handled this wonderfully.

[jenkinhill]

In the current version (2.0.24 with 2.0.24a coming very soon) you can set "Default Order Status to send email to shopper " in config so the mail is only sent for a confirmed order.

[stinga]

I don't think it is a design flaw, missing functionality is a better description.
I have a cronjob that runs once an hour to tell us about pending orders, we either mark them cancelled unpaid or sales lead. If order status is sales lead then an email is sent to customer asking them if they need help.
Usually we get a sale.
I agree it can be annoying, but you will find most order management systems work this way.
I have a bigger issue in that there is no invoice number, tax people don't tend to like that

[rainman2000]

In the current version (2.0.24 with 2.0.24a coming very soon) you can set "Default Order Status to send email to shopper " in config so the mail is only sent for a confirmed order.

While this is an improvement over VM 1.x, it does not resolve the issue. The proper solution is a switch that prevents the order from being created if payment is not received. And while most order management systems allow you to have orders created when no payment is received, most also allow you to prevent a transaction from being created if it is incomplete i.e. no payment received.

[AH]

The way it is running now is perfect for our business.

If people have a problem with the payment gateway, we still get to do a follow up call relating to their potential order.  If the order was not created, we would never know and potentially lose business.

So we never introduced the b-planet "hack" in vm 1.1 and are happy with the current function on VM2

[rainman2000]

The way it is running now is perfect for our business.

That's just it. It's perfect for YOUR business, but it's not perfect for thousands of other businesses who prefer not to have an order created when the transaction doesn't complete. We prefer the user to receive an error message stating their order was incomplete with a detailed reason, and if they want the item bad enough they will contact us. I'm not suggesting that the current functionality whereby orders are created upon unsuccessful orders be removed. I'm suggesting that it be enhanced so that companies who do not require such functionality can disable the creation of orders if they desire.

[stinga]

I think you need to decide what the real problem is.
If you are using PP then have no idea if the order has been paid for when you return to the shop from PP.
So maybe the simple solution for is to reword the return page.
With the b-planet hack you would still get a problem if the customer returned to the site before PP IPN had fired.
When you use payment gateways it depends on how they work and some hackery might be required to give all things to all people, which is never going to work since everybody is different.
I do agree it is a bit strange to thank the customer, so I changed our return page to be a bit more helpful.
I think that is why it is called a purchase order rather than an order :-)

[AH]

That's just it. It's perfect for YOUR business, but it's not perfect for thousands of other businesses who prefer not to have an order created when the transaction doesn't complete.

It is also perfect for many e-commerce stores, offering the ability to follow up on potential sales with the details still available.

Just for the hell of it, here is what I think your new business process might look like for failed, non saved orders, If the pending order did not exist:-

1. You wanted to order something from us, I have no idea what it was but I know you failed to pay for them
2. Would you still like the thing you tried to order
3. Perfect, can you tell me what items were on the order
4. Hold on whilst I re-enter those items again for your cart
5. Can you now give me your card details

Hmmm, I just had to employ another back office team member   

Can you describe the business process for your proposed functionality that makes the pending order more effort?

Having the ability to only send order detail emails at specific status points, via simple configuration, makes the issue far less problematic than it was in old VM1 as the customer does NOT get an order confirmation BEFORE the payment is confirmed. 

The b-planet hack was implemented by some because this confirmed order e-mail often got to them before they had completed payment and that confused them enough to stop the payment!  This does not now have to occur with VM2

Fortunately for our business, and the tens of thousands like us using VM, we prefer the currently available functionality.

We prefer the user to receive an error message stating their order was incomplete with a detailed reason

This really depends on the capability of the PSP and the related payment plugin

VM order capability has come a long way since VM1. If there was a vote of what new functionality could be added for orders, I would plump for the ability to add an order line in the backend without the need for a third party plugin.

[rainman2000]

I think you need to decide what the real problem is.
If you are using PP then have no idea if the order has been paid for when you return to the shop from PP.
So maybe the simple solution for is to reword the return page.
With the b-planet hack you would still get a problem if the customer returned to the site before PP IPN had fired.
When you use payment gateways it depends on how they work and some hackery might be required to give all things to all people, which is never going to work since everybody is different.
I do agree it is a bit strange to thank the customer, so I changed our return page to be a bit more helpful.
I think that is why it is called a purchase order rather than an order :-)

You're correct Stinga, changing the language on the return page will be helpful, so I'll get that done, but it's simply not as robust of a solution as the b-planet hack. When using the b-planet hack, there was not problem if the customer returned to the site before the PP IPN fired. In fact it usually returned the customer to the site before the IPN fired and it simply let the customer know the payment was pending as indicated from their language below.

When the client returns to your site (by either using the back button, completing the transaction or hitting the PayPal cancel button) the transaction status is checked. If the confirmation from the payment gateway has been received the client is redirected to the thank you page and his cart emptied. If the confirmation hasn't been received, the client is informed that the payment is still pending. His cart is still full. He can either hit the refresh button if he believes the payment confirmation should arrive anytime or he can repeat his checkout as desired.

For nearly 4 years we used this and it worked flawlessly. The only pending orders we had in VM was those where payment was received but configured the payment method to flag it because of some security issue such as different ship to and bill to addresses or the person's address could not be matched to the credit card.

[rainman2000]

It is also perfect for many e-commerce stores, offering the ability to follow up on potential sales with the details still available.

Just for the hell of it, here is what I think your new business process might look like for failed, non saved orders, If the pending order did not exist:-

1. You wanted to order something from us, I have no idea what it was but I know you failed to pay for them
2. Would you still like the thing you tried to order
3. Perfect, can you tell me what items were on the order
4. Hold on whilst I re-enter those items again for your cart
5. Can you now give me your card details

Hmmm, I just had to employ another back office team member   

Not by a long shot. About the only reasons we get failed transactions is when the customer's card is rejected by their bank or it's a fraudulent transaction (which we get a fair amount of).
1. Customer calls and says transaction was unsuccessful.
2. We ask if they recall the error code and if they do we look it up and almost know immediately why the transaction failed.
3. If no error code, then we simply log into the person's account using their username with our password (so we don't have to ask for their password or reset it).
4. All the items are still saved in their cart so we try the transaction again.

Now of course I'm speaking of VM 1 since VM 2 no longer saves the shopping cart which is something else I fail to understand.

Can you describe the business process for your proposed functionality that makes the pending order more effort?

1. Some days out the year during big sales we reach 100 transactions in a day over several days.
2. Because we have a high rate of fraudulent transaction attempts we default many successful transactions to pending status. If it's a new customer and we can't verify them via publicly available databases, he/she may be required to complete a verification check by telephone or completing a form.
3. Now you introduce all these pending transactions into Virtuemart that are from declined transactions and someone has to distinguish between pending where we received payment and pending where it was a declined transaction.
4. With these declined transactions in VM there is now a temptation from the customer service personnel to "follow-up" to see if the person "really" wants the product or not. We were happy doing this with an abandoned cart module (which by the way we had to scrap because VM2 no longer saves your cart).

And you're correct, the issue is far less problematic in VM2 than it was in VM1, but remove the "far less" and you are still left with "is problematic".

[jenkinhill]

Now of course I'm speaking of VM 1 since VM 2 no longer saves the shopping cart which is something else I fail to understand.

In VM2 if the payment is declined or fails the shopper is refered back to the cart, the details of which are still present in their session, to use an alternate payment method if one is offered.  With Paypal we have a record of failed and cancelled orders in the BE.  I have seen mention of a 3rd party plugin to save all failed purchase details  to a log file, but I don't know if it has been fully developed yet. That function may also depend on changes to payment plugins.

[rainman2000]

I have seen mention of a 3rd party plugin to save all failed purchase details  to a log file, but I don't know if it has been fully developed yet. That function may also depend on changes to payment plugins.

Yes, we have actually implemented one recently made by awebsupport (http://awebsupport.com/virtuemart-cart-autosave) and so far it is working fine. It doesn't allow you to easily manage abandoned cart reports, but they are working on an add-on for that as well.

[AH]

Thanks for clarifying your business process and rationales.

You may want to consider coding your payment plugin to have your declined transactions to set a different status to pending, differentiated by return code groupings. 

Then the pending orders can be "dumped" pretty quickly and you can follow up as required with the order and all details saved, even when the customer did not register (unless of course you still have everyone register on your site )

Vm1 order process worked for us VM2 order process works even better, I guess us and many others are fortunate that it worked for our business process.  Maybe one someone will develop a plugin to resolve your issue or create a hack to make it work how you need.