3D secure problems

[Cakes For You]

We use SECpay for our on-line card banking. Earlier this week we had the new '3D secure' enabled and since then we have not had any orders :-(

Customers have reported they are being re-directed to web sites asking them to verify card details. All this is to do with credit cards requiring to be 'enrolled' as part of the 3D secure system.

It is a huge mine field that we will all have to use before long - beware.

As it is Saturday we have to wait until Monday in order to get support which means a very quiet weekend sales wise :-(

When customers go to the Actinic Express checkout the following error message is returned;

Sorry but payment could not be accepted using the selected method. The error returned was "NO DATA MATCHES : 9999". Please try again.

I have posted this here to make you aware of what you may soon encounter so that you can identify it faster than we have been able to

Keith

[TraceyHand]

ok...you should be able to set your 3D secure up with some rules to allow non-3d secure enabled cards to still process.
I know, with Protx, it automatically ONLY allows 3d secure authorised cards to go through..alienating customers whose cards don't use it
Perhaps finding out how to set up the settings for your particular 3D secure processing could help?

[Cakes For You]

ok...you should be able to set your 3D secure up with some rules to allow non-3d secure enabled cards to still process.
I know, with Protx, it automatically ONLY allows 3d secure authorised cards to go through..alienating customers whose cards don't use it
Perhaps finding out how to set up the settings for your particular 3D secure processing could help?

Thanks for the response.

I will have a(nother) look on the sECpay pages to see if we can see any rules for non 3D secure.
"alienating customers whose cards don't use it" is how customers are reacting right now.

Keith

[wjcampbe]

with Protx, it automatically ONLY allows 3d secure authorised cards to go through
...No!

Protx allow you to process Amex and Diners, etc which are not members of the 3D secure/ VbyVisa loop.

The Card Issuing Companies require Protx to use the 3D Secure where it is available and, as the Protx website explains

In a 3D secure transaction, your customers must first register for VbV or MSC with their issuing bank. If they do not register before ordering online, the first time they order from a merchant who supports VbV or MSC they will be asked to register their card before continuing with the transaction.

[Cakes For You]

Thank you both for your responses.

After digging deeper I found the cause of the problems was due to the account being set to 'test' mode!

I can only assume this is how it was left after SECpay had enabled the 3D secure. It is certainly a well timed coincidence:(

So, if you are using SECpay and after 3D secure has been enabled check that test status is turned off and the system is 'live'.

Keith

[hristian.kostov]

Hi!

It's been a long time since last reply, but I have the solution for others going to deal with this problem. Here's what I learned from the PayPoint (SecPay) support:

The transaction has received test authorisation (auth_code=9999) in line with the test_status of true.

Then, the transaction has been blocked by CV2AVS checking, in line with the req_cv2=true (reject transactions that don't have cv2) and mand_cv2=true (reject transactions where the bank does not returen a successful match).

This is because there is no successful match available on test transactions.

the solution is to add the parameter "default_cv2avs=ALL MATCH" to your options string while testing. This will simulate a successful CV2AVS result.