AbleCommerce Shopping Cart Software

The handling of failed payments at checkout is not ideal in RC3. There is no opportunity for the customer to be alerted to a problem and/or correct it. We have produced an update for RC3 that helps to address this, found at the following location:

ftp://ftp.ablecommerce.com/patches/Card ... nPatch.zip

From the readme inside:

The files in this patch make adjustments to the checkout flow. If the payment processor cannot authorize payment, the customer will not see the standard receipt page. Instead they will see the pay order page with an explanation of what went wrong.

This includes an updated pay order page, which also improves the experience when a balance becomes due on a previously paid order (for example if something is added to the order).

This is intended to be used on the RC3 build 9381. Future builds will include this modification by default. This patch is untested on the RC2 build and not guaranteed to work for that version.

A complete discussion of the issue is found in this thread: viewtopic.php?f=42&t=6857

Logan,

I greatly appreciate the new verification patch. However, it still does not verify the billing address along with the credit card, giving us pretty much the exact same problem as before. The cart will accept valid credit cards with incorrect billing addresses, which really makes them invalid credit cards. The cart should reject the order, give the error from the gateway (address-card mismatch), and then take the customer to the billing address page to enter the correct one (or give them some sort of option to change the billing address on the same page to change the credit card). This is standard procedure for most shopping carts.

AbleCommerce claims that this lack of validation will help the merchant to flag more orders. On the contrary, it just creates more hassle for both the customer and the merchant. Usually when there is an address mismatch, either the customer has entered the wrong shipping address for their card, or they misspelled the address. Either way, I have found that the response of almost all customers (including myself) when they get this problem (card rejected due to address mismatch) is not to leave the site but simply to check and type in the correct billing address. 90% of the time the problem is one of these two issues. When the problem is with their card itself, most merchants would rather have the customer fix their card with the bank before processing an order, or call us. However the first issue (typing in the wrong address) is far more common.

Also, not validating the address creates a security problem, opening up the window to fraud. I think that with good reason no shopping cart I know of does not accept orders without validating the credit card and the address. It is also much less of a pain for the customer to be able to correct their order info on the front end than for a phone call to correct it later. They also wonder why their order was accepted if the cart did not validate their card "Why did I not get a message, I thought that the card went through; why do I have to change the info?" I have gotten these responses many times when I was using a cart that was not working properly in the past. In the end, full validation saves the customer and the merchant a lot of hassle and security issues.

Andrew Jasko
http://telephonesystemsforbusiness.com

Hello Andrew-

The decision to accept or decline a card is not made by AbleCommerce. Our function is to gather the information and send it to your payment gateway. Your payment gateway (in conjunction with the card issuer) are the ones who determine what constitutes a valid card.

When invalid billing information is provided, usually this generates an AVS code indicating the problem. With some payment gateways, there are ways to indicate which AVS responses should be accepted. For example, with Authorize.Net:
Ensure that your payment gateway is configured to reject cards that do not have an AVS match. If the gateway is allowing the transaction, we are not going to recognize it as failed.

A comment has been made that the card patch I provided does not allow for the customer to alter their billing address. If that is the case, I will get it corrected. In conjunction with a gateway that rejects invalid addresses, it would correctly handle the situation you describe.

I've been following this thread for some time.

This fix appears to cover all the necessary bases with the exception of the ability to change the billing address and re-try the charge. When that correction is made by Logan, I would expect to see the following:

Customer makes initial entries into payment checkout.

Payment fails.

Customer can change billing address, card number, card expiration, and/or card CVV values.

Customer can re-try payment.

A limited number of attempts are allowed, after that the order flow reverts to the standard "Problem" status and a dialog informs the user someone will contact them to resolve the issue.

Logan, some points to consider:

1. Authorize.Net has a minimum timer limit on retries - this has caught me several times. It appears to be 45-60 seconds. Retrying any sooner automatically fails regardless of the validity of the payment information. Other gateways may or may not have this limitation - PayPal doesn't seem to care at all

2. Retry attempts should be limited to a specific number, configured in the store settings or payment gateway setup screen. I would suggest 2 as the maximum based on my experience.

Most card issuers will lock down the customer charge card due to repeated failures - it's one of their many attempts at detecting fraud. This has happened to me and my customers. The general public doesn't always understand this and can be quite frustrated to learn Solunar Services got their card locked. Technically it was the customer that did it when they tried 17 times to get the info right, but the card issuer customer service WILL tell them it was because of Solunar Services. Trust me on that one

I don't know if you knew this or not, but the Authorize.Net AVS system actually does charge the customer even if the AVS fails. First they have to test the card info itself and initiate the charge. When the charge responds as valid, then they test address info. If address info fails, they immediately reverse the charge.
Some card issuer customer service people can see these transactions, others cannot. I had one case where the customer actually had to get the card issuer customer service rep on a conference call so I could educate both of them on how it works. Both of them were convinced the charge went through and the money was transferred. I never did the capture, the initial request was just for an authorization.

SolunarServices wrote:A limited number of attempts are allowed, after that the order flow reverts to the standard "Problem" status and a dialog informs the user someone will contact them to resolve the issue.

For some reason I thought that was in place with my previous patch? I thought I hard coded the limit to 3 tries.

1. Authorize.Net has a minimum timer limit on retries - this has caught me several times. It appears to be 45-60 seconds. Retrying any sooner automatically fails regardless of the validity of the payment information.

They automatically reject duplicate transactions within a minute. Strange that it also applies to failed transactions! I will have to think about how we could handle this.

2. Retry attempts should be limited to a specific number, configured in the store settings or payment gateway setup screen. I would suggest 2 as the maximum based on my experience.

I will check on this.

I don't know if you knew this or not, but the Authorize.Net AVS system actually does charge the customer even if the AVS fails. First they have to test the card info itself and initiate the charge. When the charge responds as valid, then they test address info. If address info fails, they immediately reverse the charge.

I imagine it also depends on the backend bank processor, who decides whether to reject it outright or authorize when AVS fails. There are a lot of variances among different providers, banks, etc.

[quote="Logan RhodehamelFor some reason I thought that was in place with my previous patch? I thought I hard coded the limit to 3 tries.[/quote]

It may very well be there. I haven't installed it so I do not know. My comment was more a suggestion than a correction.

I had stopped following this for awhile, Has this been resolved so the shopper can edit their billing address?

Will the patch work for AC7 v2 or v3 only?

Road Rider wrote:Will the patch work for AC7 v2 or v3 only?

the answer my friend is blowing in the wind (go to top of post) ...

... We have produced an update for RC3 that helps to address this

Also, for those of you who obtain the final release, this patch is integrated as part of that upgrade. However we did not wish to alter the behavior of existing stores without warning, so this feature has to be enabled with two scriptlet edits via the admin. This is documented in the upgrade instructions.

I installed the final release, followed the post upgrade instructions and this was still not working on the receipt page. I finally figured out that the code,for some reason, was not accepting my HandleFailedPayments=”true” parameter. When I copied receiptpage.ascx and receiptpage.ascx.cs to the custom folder and changed the default of false to true, it worked.

Here's what I had in the Receipt Page scriptlet [[ConLib:ReceiptPage HandleFailedPayments=”true”]] ; this was copied and pasted from the post upgrade instructions.

This does seem to be working on the myorder page.

I can't seem to get this to work on my site I changed the scriplet pages and have upgrade I even changed the false to true on the receiptpage.aspx what am i missing ...any suggestions

thanks Joe

does anyone have a page view what it is suppose to look like for the invalid credit information page

What I had to do was copy receiptpage.ascx and receiptpage.ascx.cs from conlib to conlib/custom.

I then edited both pages did a find on HandleFailedPayments and changed the 'false' to 'true'.

In receiptpage.ascx.cs on line 40 you will find:

private bool _HandleFailedPayments = false;

I changed that to:

private bool _HandleFailedPayments = true;

In receiptpage.ascx on line 6 you'll find:

<param name="HandleFailedPayments" default="false">If true, the customer is redirected to an order payment page if the payment fails at checkout.</param>

I changed that to:

<param name="HandleFailedPayments" default="true">If true, the customer is redirected to an order payment page if the payment fails at checkout.</param>

Then on the receipt page scriptlet, I changed;

[[ConLib:ReceiptPage HandleFailedPayments=”true”]]
to:

[[ConLib:Custom/ReceiptPage HandleFailedPayments=”true”]]

After I made these changes, an error in authorization brought up a payment page with a message that the authorization failed.

The only problem I see with all of this is that if the error is in the billing address, the payment page does not give them an opportunity to change that information. My customers tell me that a large number of authorization failures are due to an error in the address so this does not resolve that issue.

Thank You Very Much I read down the page and changed all the files and then to bottom of the page the read about billing address and 75 percent of my customers have this problem ... So I guess I should not use this ..should I

cerami2 wrote:I read down the page and changed all the files and then to bottom of the page the read about billing address and 75 percent of my customers have this problem ... So I guess I should not use this ..should I

Same reason I'm not using it.

The reality is AVS is near-mandatory when accepting orders online. Until the modification allows for revisions to the billing address, it's not useful to my business - I won't even begin to consider installing it until it does. I appreciate the effort put forth to make a solution to the problem, but it's simply not a solution the majority of the time.

As a side note, Able really needs to quit hiding solutions behind parameters on user controls and start putting switches and toggles in user-friendly configuration pages. First it was the AllowAnonymous on the OnePageCheckout control and now it's the HandleFailedPayments. Sure, it's documented - but why make people hunt for key features that are critical to the checkout process?

Not everyone fully understands how to modify user control parameters in HTML scriptlets. Keep it simple and put it on a configuration page.

Not everyone fully understands how to modify user control parameters in HTML scriptlets. Keep it simple and put it on a configuration page.

Amen to that. I made a post about this before..there are tons of options hidden behind the screens. Would be nice to start seeing some of these good bits of code like the delete function, review notifications, etc.. added in so we dont have to modify so much everytime a new version comes out also.

Since we do a lot of development work, I am fine with changing the user controls but I can see everybody's point about an easier way to control the options.

My BIG problem right now is the inability to change incorrect billing address information. This is a must have for all the customers of my sites; they need a way to correct these errors.

Hello all,

Here is something I hashed together that will allow the customer to edit the billing address in case that is why the card failed authorization. It is not elegant, but it works and that's all I really need.

I tested it out on my site and it seems to work great. There may be some usability improvements that could be made, but I think it's pretty clear.

Anyway, hopefully this will help some who've been waiting for this addon until we get an "official" one or somebody can clean up what I post.

Drop the files from the zip into the ConLib folder (I know the preferred method is to use the Custom folder, but I didn't do that ... however, if you want to change the scriptlet to the custom folder, then you'll be covered).

Have fun! Let me know how it works out!


Mike


________________________EDIT___________________________
With the release of SR1, this feature has been added by AbleCommerce.
Mine is now taken off because I'm sure their's is better. To download, see viewtopic.php?f=42&t=7897

thanks mike
I dropped it in the conlib folder is there anything else that has to be done so this works?
thanks
Joe

If you're the Final version, you just need to add the HandleFailedPayment="true" parameter to the ReceiptPage and MyOrderPage page scriptlets.

The documentation reads:

Issue ID 6692 - Validate credit cards prior to order completion

This update is optional unless you have previously installed the patch made available for RC3. By making this change, you are changing the behavior of the checkout process with credit card payments. If a credit card fails to authorize during an order, the customer is directed to another page where they can try to re-enter the credit card information or try a new payment method.

If you do not want to make this change, the default behavior is to accept all orders regardless of the outcome of the credit card transaction.

This change has not been fully tested. If you find a bug, please report it.

Login to the AbleCommerce merchant menu as the admin, or a user with website edit permissions.

Go to Website > Content and Layout

Find and edit the “My Order Page” content scriptlet.

The content field should have this tag:

[[ConLib:MyOrderPage]]

You need to include the "HandleFailedPayments" attribute to turn on failed payment handling, so change it to look like this instead:

[[ConLib:MyOrderPage HandleFailedPayments=”true”]]

After updating the scriptlet content, save the changes.

Find and edit the "Receipt Page" content scriptlet.

The content field should have this tag:

[[ConLib:ReceiptPage]]

Again, you need to include the "HandleFailedPayments" attribute to turn on failed payment handling, so change it to look like this instead:

[[ConLib:ReceiptPage HandleFailedPayments=”true”]]

After updating the scriptlet content, save the changes.

i did all you mention above and it still goes to the recieipt.aspx page

It may depend on your processor and whether you're validating addresses and such. With ours, we have it set to the highest level, but I know we can turn off address verification if we want or even turn off cvv verification as well.

You should also make sure you're actually testing a credit card with a bad address, zip code and expiration date or cvv code. I just did all those things wrong to make sure the processor would kick the authorization back and I would get to the error page.

Hopefully that helps.

Mike

i did all you mention above and it still goes to the recieipt.aspx page

I had the same problem. See my post above regarding how I 'fixed' it.

i copied the receiptpaages to the custom folder and it still doest work do i leave a copy in the conlib root or do i take it


is there any other pages i have to fix if it did not do the patch ... I thought i did it thou
joe

is there anywere i can down load the patch I can't find it
thsnks
joe