Turing a cart into an order without payment

Does anyone know if it is possible to turn a cart into an order BEFORE paying, but postponing the sending of emails until the payment succeeded.

Our current most used payment module requires returning to the shop after the payment provider was successful. However, our payment provider shows a web page stating the payment was made before returning to the shop, and some users close their browser there. Which means the cart is never made into an order. Not good.

Now, it is possible to have a more expensive service which can skip that page, but surely it also is possible to split the creation of the order and the advance its status into two parts?

One for creating the order from the cart and giving it the initial "pending" status (or updating it as long as it has the pending status), and one for simply increasing that status to "processing" and sending emails.

The checkout process is exactly what it says it is...

... if I go into a supermarket and fill a trolley with groceries, I then stand in the queue for the cash register. All the while I am filling my trolley, I do not have a "formal" order.

Now, unlike in a real shop, where I would not bother filling a trolley UNLESS I intended buying the stuff, a zencart shop can STORE the trolley for registered users...

It's like going into Walmart on Wednesday, filling a trolley, and leaving it parked in the aisle with my name on it, ready for me to go back and pay for it on Friday.

But CHECKOUT has to be a seamless process, taking the shopper through the final steps in order to compete the transaction.

If your shoppers are abandoning their cart at your payment gateway, then that is a different matter and you need to analyse why they are doing this... not be looking for ways to bypass a logical process.

If you want to be able to have people complete an order, without having to pay at the same time, consider using Check/moneyorder or my account holder module.

I understand your reasoning, the problem is in the "payment succesful" page the payment provider shows before returning to the shop. I do not have control over that. Naturally the more expensive version does have the ability to return immediately, but that is more costely. (I think they do this on purpose to sell more expensive subscriptions.)

Anyhow, the situation as-is results in the situation where the shopping cart is paid for, but it is still standing in the reserved area. If the client returns shortly after and starts another order, the reserved cart is cleared and I cannot see anymore what he has bought and paid for.

BTW, even though your reasoning is sound, it is applicable for a real life supermarket, and not necessarily for a webshop. These are different things. One could also reason that every potential buyer that enters the shop starts a new cart, the only question is if that cart ever will be paid for. (This is how I implemented it in my other custom written webshop - in order to by pass this problem.)

Who is your payment provider?

What I do, for example, on PayPal, is create a customized payment screen, with our logo at the top.

I embed the following into the logo:

"Please ensure you click the link that returns you to our webshop, after you have made payment. If you do not do this, we may not receive details of the order you have just paid for."

I do this becuase with PayPal, the customer is only returned AUTOMATICALLY if they use their paypal account to pay. If they use a credit card, they don't get auto-returned, but have to click the "Return to Merchant" link.

We recently upgraded to WPP and it's made life a lot easier.

In this case ABN Amro iDeal (payment method only available in the Netherlands which is a direct bank account to bank account transfer). And naturally we have the same text, but that does not mean the customers actually do that. :-(

ATM I need to set up 3 more shops, want to user Zencart, but have this problem and do not want to force the client in a more expensive account just because of the shop.

I've written a payment module for DPS and they do something where at the same time where they display the 'payment successful' page they create a hidden request back to the store. In that case either the hidden (threaded) request completes the order, and/or the customer really completes the checkout by clicking a link that brings them back to the store (same as in your case).

I wonder if you could simulate the 'coming back' request using some delayed PHP code from the store yourself (assuming that you can figure out the URL that you need).

However, there are a couple issues at hand:

1. The payment module would need to be patched/improved in a way that it can handle existing order at the point where a user clicks on the final link.
2. The custom created request would presumably have to create dummy payment confirmation data, like, for example a transaction number from the payment provider, etc. and the customer initiated request (from the final click) would have to recognize that and update the order, rather than create one.

If you think that might be worth a try let me know (PM), perhaps I am able to help.

mano

The advanced version indeed allows for such a hidden request and I'm using that for one shop now. But the regular version... If only I would be able to spoof in a request back home somewhere. Hm. I will reexamine the documentation to see if I can find a place.

Did you have the hidden request do a checkout_process and the final request jump directly to checkout_succes?

I did not find any place to sneek a callback in. Hm.