Credit Card Validation

500lbdev · Post by **500lbdev** » Tue Mar 25, 2008 1:33 pm

Is there any way using AbleCommerce to validate the credit card before an order is inserted into the system? As an ecommerce shopper, I would not expect to see a receipt until I've entered a valid credit card number. I would expect to get an error message and stay on the payment page if I entered an invalid credit card number, expiration date, etc. Unfortunately, AbleCommerce displays the receipt and sends an order confirmation email even if the credit card is returned as invalid from the Payment Gateway (Authorize.net in my case). Is there any way around this so that the credit card is validated before the gets redirected to the order confirmation(receipt) page? Any help with this would be much appreciated.

Post by **Logan Rhodehamel** » Wed Mar 26, 2008 3:15 pm

This was one of the changes in our checkout flow from AC55. Orders are always accepted, even if the credit card authorization fails. This allows us to provide better reconciliation between AC and the payment gateway, among other things.

I imagine others may have the same concern. What if the order receipt page advertised to the customer that something went wrong with the payment (we could even say what) and allowed them to try again or cancel the order?

Preventing the order from being entered at all is not going to be an option at this point.

compunerdy · Post by **compunerdy** » Wed Mar 26, 2008 3:29 pm

I imagine others may have the same concern. What if the order receipt page advertised to the customer that something went wrong with the payment (we could even say what) and allowed them to try again or cancel the order?

This would be great.

Preventing the order from being entered at all is not going to be an option at this point.

Good!! my last cart did not create a order until the order was paid. As in the customer returned from paypal. So when there was a error you would get the paypal payment but no order in the system...not good at all.

Post by **Logan Rhodehamel** » Wed Mar 26, 2008 3:32 pm

compunerdy wrote:Good!! my last cart did not create a order until the order was paid. As in the customer returned from paypal. So when there was a error you would get the paypal payment but no order in the system...not good at all.

Yes, that is one of the other scenarios we considered when we decided to make this change. And another reason is to help prevent fraudsters from hunting for valid card numbers.

AbleMods · Post by **AbleMods** » Wed Mar 26, 2008 9:38 pm

Yes, that is one of the other scenarios we considered when we decided to make this change. And another reason is to help prevent fraudsters from hunting for valid card numbers.

...at the expense of the site staff chasing down mis-typed CVVs all day long.

On any large scale this will become a nightmare Logan. It's fine if only 1 in 10 order customers need to be hunted down for valid information. What happens when I hit 30 orders a day (again)? What about 75 a day? 100?

It makes no sense to pay the manpower necessary to track down what will become a consistent percentage of customers who mis-type key data that ultimately cause the authorization/capture to fail. So much time and effort on both sides can be saved if the customer knows and can correct the error prior to completion of the order.

If that's important to save the order, reject the information to the visitor and offer a choice to save the order for telephone followup or retry payment entry again - throw a CAPTCHA on that save/retry dialog and call it a day. No bot problems, customers know what just happened and site admins are spending their time filling orders instead of racking up long distance phone calls all day.

We've been over this so many times already. When I reach 100 orders a day, I'm going to be paying one full time staff member just to chase down the 10%+ typo payment orders. Is this how Target.com does it? Is this how Dell.com does it??

compunerdy · Post by **compunerdy** » Wed Mar 26, 2008 10:49 pm

I only have like maybe 4 or 5 out of 250 or so a month that have a payment issue. I send them a quick email and call it a day.

500lbdev · Post by **500lbdev** » Thu Mar 27, 2008 8:04 am

Logan, thanks for your reply. Your decision to not validate credit cards seems to be against stardard protocol. Knowing this, the agency that I work for is less likely to purchase AC for future eCommerce implementations. Credit card validation before order entry is a very important piece of an ecommerce system. You should at least give the option to validate or not. I'm going to have to figure out a way around this for the site I just deployed because revenue is being lost.

Post by **Logan Rhodehamel** » Thu Mar 27, 2008 8:39 am

It is good this issue is being discussed. Things are set in stone for this release only. Customer feedback has a huge impact on our development work.

I have created bug 6692 so that we can discuss this issue internally and find a resolution.

WylieE · Post by **WylieE** » Thu Mar 27, 2008 8:41 am

I must agree this is a concern for us.

Our current configuration is osCommerce/USAePay. If a customer enters and invalid number, wrong billing info, etc.... the order is bounced back to the customer. According to our error logs, we average 3-4 a day with card issues. Having the order go through in the customers eye but not capturing payment would not be a step forward for us.

We currently average 40-50 orders a day. About 30% of those are overseas and it would not be feasible to assign a sales rep to contact customers around the world if our volume continue to increase as it has over the past year online.

Logan, (or anyone else) we're still evaluating AbleCommerce. Can you clarify exactly what a customer sees under 7.0 when invalid billing information is entered?

Post by **Logan Rhodehamel** » Thu Mar 27, 2008 8:57 am

I have shelved what I was working on for today and I am going to investigate this issue in depth now. I want to make sure we are able to meet the requirements of our merchants!

AbleMods · Post by **AbleMods** » Thu Mar 27, 2008 9:22 am

WylieE wrote:Logan, (or anyone else) we're still evaluating AbleCommerce. Can you clarify exactly what a customer sees under 7.0 when invalid billing information is entered?

The process varies somewhat, based on the payment method selected. The majority of my orders come via MC/Visa - I can only presume that's the case for everyone else these days.

When checkout process reaches the 2nd page of the one-page checkout (that's an inside joke btw), the customer is presented with the fields necessary for credit card payment entry.

Once the payment entry is complete, valid or invalid, the system reaches the Receipt.aspx page and displays an order summary for the customer. If the payment processing was successful, the order status will show "Pending" - that's a default and can be changed by the site admin so say something else.

But if the processing failed for any reason, the status of the receipt page simply says "Problem". There is no indication of why there's a problem nor is it very noticeable that a problem exists at all. Many customers I've contacted were surprised there was ever a problem.

So, I have implemented an email template trigger to fire when authorization fails. That way, at least the customer receives a message (post-order of course) that something didn't go as expected and it BCC's me as well. This has helped quite a bit so far as customer awareness but does not alleviate the additional effort required.

The downside to the email trigger idea is that repeated attempts to authorize the charge are made, either by me or the customer, just bombard the customer with failed-authorization emails. Usually the customer and I get it right on the very next try, but that's not always the case.

I've been running AC7 almost 6 months now and this is the best I could come up with so far as procedure and customer notification. Between some unusual Ajax bugs (checkout uses Ajax) and this issue, I'm at the point now where it's worth my time to build a new checkout page using standard postbacks and step-by-step processing.

When my customers are trying to give me money, I just don't care about saving a few postbacks or making it easier to integrate future payment methods I might or might not ever use. The checkout page is the absolute worst place to have a problem with your site technology. Keep it simple and make it 100% stable - anything less will cost me money every day.

Post by **Logan Rhodehamel** » Thu Mar 27, 2008 9:29 am

Logan Rhodehamel wrote:I imagine others may have the same concern. What if the order receipt page advertised to the customer that something went wrong with the payment (we could even say what) and allowed them to try again or cancel the order?

Nobody chimed in on whether this would be an acceptable solution.

This is one possible solution I can implement immediately. Right now the the customer submits the order with payment info. Then they are taken to the "receipt/order confirmation" page.

At this order confrimation stage, I could identify when there is a failed payment. At the top it could display a very prominent message:

Oops! We could not process your payment and it has been cancelled. The bank said 'Card cannot be authorized due to insufficient funds.' Your order has been saved, but it will not be completed until we receive payment. Please click here to make a payment for this order.

So, we would not prevent the order from being recorded into the system, but the customer would get immediate feedback on what went wrong and have a chance to fix it. And of course, from the admin side of things you get a complete history and would be able to see that this order is not paid as well as more detail on why the payment(s) failed.

Is this an acceptable compromise?

Post by **Logan Rhodehamel** » Thu Mar 27, 2008 9:33 am

SolunarServices wrote:Between some unusual Ajax bugs (checkout uses Ajax) and this issue, I'm at the point now where it's worth my time to build a new checkout page using standard postbacks and step-by-step processing.

Our original multi-step checkout without ajax postbacks is still present, BTW. Are you getting reports of ajax problems frequently?

WylieE · Post by **WylieE** » Thu Mar 27, 2008 11:59 am

Logan Rhodehamel wrote:
This is one possible solution I can implement immediately. Right now the the customer submits the order with payment info. Then they are taken to the "receipt/order confirmation" page.

At this order confrimation stage, I could identify when there is a failed payment. At the top it could display a very prominent message:

Oops! We could not process your payment and it has been cancelled. The bank said 'Card cannot be authorized due to insufficient funds.' Your order has been saved, but it will not be completed until we receive payment. Please click here to make a payment for this order.

So, we would not prevent the order from being recorded into the system, but the customer would get immediate feedback on what went wrong and have a chance to fix it. And of course, from the admin side of things you get a complete history and would be able to see that this order is not paid as well as more detail on why the payment(s) failed.

Is this an acceptable compromise?

Any sort of high visibility feedback to the customer that there was a problem would help. If there's any way to post back to the customer what the error was, it would help too. Would it be possible to give the customer a way to change the card information and resubmit payment?

If the customer is unable to resolve their payment issue online, it would also help if they were directed to contact our sales department for resolution. That could limit the amount of time we might spend chasing payments down.

500lbdev · Post by **500lbdev** » Thu Mar 27, 2008 12:07 pm

Logan, thanks for responding to the issue so quickly. I think that all of these suggestions may be sort of a band-aid to the problem Ultimately, allowing for validation before the customer is redirected to the receipt page, sent a confirmation email and has his/her order entered into the system seems to be the only good solution to this problem. If payment gateway and AC system reconciliation is an issue, just keep a failed transaction table available with order id, response code from payment gateway and payment amount. This way all transactions could be reconciled. Thanks!

Post by **Logan Rhodehamel** » Thu Mar 27, 2008 12:22 pm

WylieE wrote:Any sort of high visibility feedback to the customer that there was a problem would help. If there's any way to post back to the customer what the error was, it would help too. Would it be possible to give the customer a way to change the card information and resubmit payment?

What I am working on now is an updated flow to the checkout. Once the customer enters payment information and submits, if the payment fails they are going be shown a screen with an error message like the one I described. Just below that will be the payment form (like on one page checkout) so they can retry. They will be made aware of the problem and allowed to fix it.

Agreed with 500lbdev, it is a workaround, but I think it will solve the problems of customer awareness and self-help. Plus it will work on any 7.0 install. A longer term correction to halt the order process will also be made, but it is more intensive (perhaps a new DB field) and we won't be able to provide it on a patch basis outside of an upgrade release.

AbleMods · Post by **AbleMods** » Thu Mar 27, 2008 1:47 pm

Yeah I think there's three things that need to occur:

1. Transaction is halted
2. Customer awareness to a problem and (hopefully) what that problem is
3. Opportunity to proceed with saving order for phone followup or retry payment information again.

Step 3 will need a counter tagged to it limiting the number of retries possible. And probably a CAPTCHA to ensure bot protection for the page.

Definitely don't want to give a situation where unlimited retries are possible. Bots or not, credit card companies don't like the account getting hit for 5 authorization attempts in a short period.

As a side note, there is a time delay for retrying an authorization with Authorize.net. It appears to be 45-60 seconds and even stops me if I completely delete the payment and re-enter it.

Logan, if there's some sort of transaction ID created upon the initial authorization and sent to ANet, that will have to be re-generated upon retries or ANet will block customer attempts to try again due to this duplication transaction delay they have implemented.

Post by **Logan Rhodehamel** » Fri Mar 28, 2008 4:25 pm

I am almost complete with a modification that will improve customer awareness and ability to self-correct. I want to go over what it does so that anyone here can chime in with suggestions. Keep in mind, with 70 it will not be possible for me to stop the order from being entered. We can look at that for 71 with a database change, but right now there would not be a good way to do it.

The update will consist mainly of updated files for Checkout/PaymentForm directory, and three updated ConLib controls - the receipt page, view order page, and pay order page. Once installed, you get new checkout handling.

One page checkout - customer enters payment information and submits the form. The payment fails to process through the gateway. The customer is redirected to the "Receipt" page (so far no behavior is different)

Receipt page detects that the order has a balance due, and that the last payment resulted in an error. The customer is redirected to the Pay Order page.

The pay order page also detects the last payment resulted in error, and displays a warning message. This is the screen the customer will see immediately after submitting their payment:

http://bugs.ablecommerce.com/attachment ... ction=view

The customer can then use this form to try again, with a completely different payment method if desired.

If the customer visits the "view order" page, it will also redirect them to this page. They cannot view the online receipt without providing one of your accepted forms of payment first. So for example if they clicked the link in the order notification email, it would also display the screen above.

You can't see in the image, but below the payment form is shown a complete payment history that indicates the prior payment along with a "VOID" status and the reason. This will show all payment attempts to the customer. And below that, there is a list of the items in the order.

I will add some sort of limit to the control - a customer will only be able to try X number of times before it disables the form and asks them to contact you for assistance.

What do you all think? Is this going to reduce your involvement in the process? Anything you wish it did different?

compunerdy · Post by **compunerdy** » Fri Mar 28, 2008 7:11 pm

Sounds like a good solution to me.

nickc · Post by **nickc** » Fri Mar 28, 2008 7:41 pm

I'm hoping these changes support the anonymous checkout model...

AbleMods · Post by **AbleMods** » Sat Mar 29, 2008 5:17 am

I can't see the image - says I don't have permission to view it in Bugzilla.

From what you've described, it sounds goods.

Customer awareness is such they know their order payment did not go through.

Customer has the ability to re-enter payment information even using a different payment method. Just for debate purposes, should (or could) there be a limit on the number of attempts per payment method? In other words, can you make the attempt count track that way?

Then we could set very strong security limits like, 2 chances per method. Hard-code it if you have to and we can just change the limit to suite our specific business needs individually. This increases security (always a concern), limits fraud guessing etc.

One thing to consider with this design:

1. What happens when a customer adds something to their order (after it was originally accepted just fine) and it now has a balance when it was previously paid? This happpens with me, and it's very easy to instruct the customer to return to their order and click the "Pay Order" button on the View Order page. Will these changes get them stuck in a loop between receipt and pay order AFTER the order was originally accepted? Or will these changes in fact make it easier, since they'll get the payment screen as soon as they click the View Order button?

I *really* like the idea of the customer knowing something went wrong and having the opportunity to "make it right" before their checkout experience is completed.

bobr2k · Post by **bobr2k** » Sat Mar 29, 2008 6:44 am

Logan Rhodehamel wrote:I am almost complete with a modification that will improve customer awareness and ability to self-correct. I want to go over what it does so that anyone here can chime in with suggestions.

multipart question: Was this change the reason for build 9381? or is this change still pending?
Does this apply only to authorize.net gateway or also to paypal?

Post by **Logan Rhodehamel** » Sat Mar 29, 2008 7:55 am

nickc wrote:I'm hoping these changes support the anonymous checkout model...

Yes, they will. When you check out "anonymously" what we do is create a dummy user account for the customer. The account has a name like "zz_anonymous_##". We log the customer in automatically during the order checkout process. This allows them to get access to the receipt page and other member features as long as their current session remains open. This will include the pay order feature.

Also note while logged in, the anonymous customer may go to the "my account" page and update the login information. This will allow them to convert their temporary account into a real one.

Otherwise, anonymous accounts are scrubbed out periodically.

Post by **Logan Rhodehamel** » Sat Mar 29, 2008 8:00 am

SolunarServices wrote:I can't see the image - says I don't have permission to view it in Bugzilla.

I was afraid of that. Sorry guys, I don't have a good place to put the image until I get the forums updated.

SolunarServices wrote:Just for debate purposes, should (or could) there be a limit on the number of attempts per payment method? In other words, can you make the attempt count track that way?

Well, what I did was made it number of failed tries in a row. It seems the safest. The customer can try any payment method, but in the default if they fail three times in a row it's over. They get a message saying to contact you for help.

There is a method called "HasTooManyTries" in the control. You will be more than welcome to customize this if you want to suit your particular needs.

SolunarServices wrote:1. What happens when a customer adds something to their order (after it was originally accepted just fine) and it now has a balance when it was previously paid?

They still can go to the view order page, then (by default) in the top right column it says "balance due" with a pay order link. The new pay order page also works in this scenario - customers get the cleaned up interface as well as the ability to use any payment method. They will NOT see an error message. Also, they will not be automatically redirected to the payment screen. This only happens when a balance is due and the last payment resulted in an authorization failure.

So here's a question... would you rather it always redirect to the pay order screen if there is a balance and no pending payments?

Post by **Logan Rhodehamel** » Sat Mar 29, 2008 8:04 am

bobr2k wrote:multipart question: Was this change the reason for build 9381? or is this change still pending? Does this apply only to authorize.net gateway or also to paypal?

This change is still pending. I have it functional in my local copy, but I am doing my own QA and final adjustments. I will provide it as a modification that can be installed on top of RC3.

PayPal... I am not sure how you mean. If you are using PayPal Website Payments Pro, and the customer tries to use a credit card, and the PayPal gateway does not return a successful authorization, then this new code will apply.

If the customer chooses to pay with "PayPal" payment method, and on the order invoice they get a Pay Now button, I don't think that IPN ever reports back a decline. If they did, then yes this would work. But probably, if the customer has trouble using the Pay Now button, you are going to have to intervene.