Print Page | Close Window

Incomplete Orders

Printed From: ProductCart E-Commerce Solutions
Category: ProductCart
Forum Name: Using ProductCart
Forum Description: Running your store with ProductCart
URL: https://forum.productcart.com/forum_posts.asp?TID=3610
Printed Date: 02-March-2025 at 5:09pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com


Topic: Incomplete Orders
Posted By: Guests
Subject: Incomplete Orders
Date Posted: 09-April-2010 at 1:38am
Working on this with v4 vis a vis:
http://wiki.earlyimpact.com/productcart/orders_status#incomplete_orders - http://wiki.earlyimpact.com/productcart/orders_status#incomplete_orders

If the order is incomplete because the real time credit card payment gateway declined the transaction, are the various gateways set up to show that the card was declined and why under View Incomplete Orders? It does not seem like it is.

Trying to help a client figure out possible reasons for incomplete orders with v4 OPC, and having data on this would really help.

For example, we've tracked some folks who have added a lot of items to cart, enough to hit free shipping level (so shipping cost is ruled out as reason to abandon cart), and have got to almost the end where they entered a discount code (so all that was left was to put in CC info), and they still abandoned. Doesn't make sense unless their credit card was declined . . . but we can't see that info in the CP.

In this particular case, client is using Authorize.Net gateway, the most popular gateway.



Replies:
Posted By: ProductCart
Date Posted: 09-April-2010 at 2:11am
That information is not recorded at this time. It's a good idea for the future, although very time consuming to implement because each payment gateway is different.

To assume that the customer abandoned the shopping trip because their card was declined is not necessarily correct, though. The customer might have simply decided not to pull the trigger. It happens all the time.

With regard to Authorize.Net, one way to study this information is to review "Unsettled Transactions" daily, before they settle. You can view details on a declined transaction and see - for instance - if the decline was due to Address Verification filters that are too strict.

-------------
The ProductCart Team

Home of ProductCart http://www.productcart.com" rel="nofollow - shopping cart software


Posted By: Guests
Date Posted: 09-April-2010 at 2:29am
Originally posted by earlyimp earlyimp wrote:

That information is not recorded at this time. It's a good idea for the future, although very time consuming to implement because each payment gateway is different.

Yeah, for sure. I've done this with my SecurePay integration and will do with the few other new gateway integrations I've got on my plate. Lot's of work to update all of the other gateways PC ships with. I totally understand that.
Originally posted by earlyimp earlyimp wrote:


To assume that the customer abandoned the shopping trip because their card was declined is not necessarily correct, though. The customer might have simply decided not to pull the trigger. It happens all the time.

Agreed, and we didn't assume that -- but it would be nice to have data that would eliminate that as a concern.
Originally posted by earlyimp earlyimp wrote:


With regard to Authorize.Net, one way to study this information is to review "Unsettled Transactions" daily, before they settle. You can view details on a declined transaction and see - for instance - if the decline was due to Address Verification filters that are too strict.

Agreed. It's not the easiest VT, but it's usable for this. Not all gateway VT's are, though. In any event, this would definitely be the right gateway to start this on.


Posted By: ProductCart
Date Posted: 09-April-2010 at 2:39am
Sean,

Thanks for the additional thoughts.

Later this year, as part of ongoing improvements to One Page Checkout, we could look at really taking advantage of all the AJAX calls that happen in OPC to save to the database all sorts of statistics on what is happening with the order.

We could theoretically "log" the steps taken during checkout (e.g. selected shipping; tried discount XYZ, but it was expired; proceeded to payment page; returned to order verification; tried discount ABC, but it had already been used; ... ).

This could provide some really interesting information.

There's so much that could be done! If we had 30 developers working night and day on ProductCart, none of them would be idle. Ever. :-)

Massimo

-------------
The ProductCart Team

Home of ProductCart http://www.productcart.com" rel="nofollow - shopping cart software


Posted By: Guests
Date Posted: 09-April-2010 at 3:31am
Boy howdy, you are preaching to the choir here!

So many things to do, so little man-hours available to do them (well, in my case, a lot of woman-hours).

The information that could be logged here would really be invaluable. It takes so much effort for a merchant to get a customer to this point. That scenario I described ... that's when it becomes a real mystery vis a vis the data. Many interesting things could be revealed to merchant through the control panel this way.

Meanwhile, what say you could at last record info on declined Authorize.net transactions soon, maybe v4.1 as this is by far the most popular gateway. I built that in on SecurePay in 3.51+ and we are doing the same with some new gateways folks are contracting us to build in.


Posted By: benpate
Date Posted: 16-April-2010 at 11:41am
Yes, this would be a very nice feature. Same with checkout logging.


-------------
http://www.web1seo.com - ProductCart SEO - Resellers and Affiliates welcome


Posted By: geoff
Date Posted: 16-April-2010 at 9:01pm
I also agree - incomplete transactions have been a major headache. The ability to log this up to the hand over to the gateway provider would be very useful. 


Posted By: benpate
Date Posted: 21-April-2010 at 12:46pm
I actually coded the invoicing.asp page to also show incomplete orders. It shows them and lets user know they are incomplete by adding " - INCOMPLETE" This has been a great help to the customer service people even though you could see this info on another screen.

-------------
http://www.web1seo.com - ProductCart SEO - Resellers and Affiliates welcome


Posted By: intour
Date Posted: 24-April-2010 at 3:50am
I can see other problems here.
 
Incomplete orders also occur when a successful payment is taken but the callback from the payment gateway does not happen.
 
One of my clients has had a lot of trouble with Worldpay on this. The problem is intermittent so its hard to track. This client sells a lot of downloadable products so without the callback from the gateway the download link is not created. In trying to solve this with EI the conclusion was that some anti-virus software was stripping out the callback link because of the way Worldpay display it.
 
Nigel
 


-------------
http://www.innerview.co.uk - Innerview
Productcart Platinum Reseller
Web Design/Hosting/Virtual Tours


Posted By: benpate
Date Posted: 24-April-2010 at 10:01am
We have also had intermittent issues where Authorize.net will take the persons money but the order does not show up. Maybe setting the entire ASP page to be a transaction would solve this? To my knowledge, making the entire page an ASP transaction would make so that if anything on the page fails then the whole thing will. Can anyone confirm this?

-------------
http://www.web1seo.com - ProductCart SEO - Resellers and Affiliates welcome


Posted By: amgqmp1
Date Posted: 27-April-2010 at 5:15pm
From many years of experience with PC and Authorize.Net...

...most of the time the information coming back through Authorize.Net is extremely generic, and card-type dependent,   For example, most declined AMEX charges I encounter are for a mismatched card code (people use the 3-digit code on the back instead of the 4-digit code on the front), are merely logged as "Declined (contact card issuer to determine a reason)".

If the same person were to mismatch on a Visa or MC, it would actually report the card code mismatch as the declined reason.

I think any store manager using Authorize.Net should have access to the Authorize.Net control panel.  While I can understand why it would be nice if the info did get passed back to the shop, I actually prefer that it not.  I like to keep the credit card transaction history (of which the shop I run has a lot) separate from the data in the shop.  The last thing I need is an extra pile of data to keep intact in my shop db. Wink



Print Page | Close Window

Forum Software by Web Wiz Forums® version 12.04 - http://www.webwizforums.com
Copyright ©2001-2021 Web Wiz Ltd. - https://www.webwiz.net