This is the second time I got one of these since we went live. Here is what I think is happening and what the difference is from BV4. Just a guess but.....

Under BV4 if you entered an invalid card number, exp date etc. the customer could not go past that screen until they fixed it. An invalid exp date would be something that expired prior to today. An invalid card number would be some number that didn't match the algorithm set up as the first check for invalid card numbers. These errors are stopped before they make to the CC processor for authorization.

Under BV5 they still don't make it to the CC processor but they do make it through the order process complete with order number and error msg in the notes section "Declined Invalid Credit Card Number".

In BV4 you use to link directly to the CC processor but in BV5 you chose to link through a third party for the proper formats and such. Which by the way I think is an excellent idea.

However I would suggest putting the algorithm back in BV5 as part of the check out process if this is indeed the cause of the issue I am seeing.

Bob Noble

Hi Bob,
Service Pack 2 will include this feature to check the credit card number against the credit card type, as well as requiring the correct security code format. All credit transaction errors will occur at the checkout page, and will not allow the customer to continue until they enter the correct payment information.

Thanks,
Everett

Hello Everett,
Would SP2 allow an incorrect credit card "Billing Address" to pass or would it be
stopped at the Checkout page?

Hey Rudy,
Just so you know, the situation that you describe actually needs to be configured with the your payment processor. For example, if you use Authorize.Net, you will need to configure your settings in your Authorize.Net account to enable billing address verification or CVV code verification. Some customers choose not to enable these additional forms of verification because some processors charge additional monthly or additional transaction fees. If you have your processor configured to verify these fields, and authorization or payment is declined, BVC5 will not allow the order to continue. This is the process for all versions of BVC5. If you have implemented these forms of verification with your processor, and your orders are still being allowed to process, I would double check your BVC5 payment configuration and the Receive Credit Cards workflow to make sure everything is setup properly.

Thanks,
Everett

Rudy,

You have orders of magnitude more experience than I do collecting orders. Would the "street address did not match" or "zip code did not match" messages give identity thieves too much information? My intuition is that it would, but I am not an identity thief so my intuition is unreliable. You must get quite a few AVS mismatches and since you call the customer, you must have developed a pretty good sense of whether identity thieves are using your site to fish for credit card numbers with matching addresses.

Hello Andy,
I agree with you that advising of the specific error is not be the best way. I am searching for
better ways to handle the exceptions, eliminate the exception or handle it by programing.
Thats why when I read the post, I asked:

Selecting which "Orders" to go after and solve the problem is the challenge.
Calling every "unknown" customer with an AVS mismatch does not work,is time consuming
and as you pointed out risky.
I do try and solve the problem when I feel there is "some" level of confidence success
might be achieved.
Your points are well taken. I will still continue to search for a better way to handle this
type of an exception.

I just discovered how to set this using the Workflow. I think it would be easier if it were part of the Options - Payment - Credit Card screen.