views:

532

answers:

2

We have a commerce site we're attempting to get 3D Secure (Verified by VISA/Mastercard Securecode) set up with.

We are using DataCash as our payment provider.

We are seeing the following issue:

Some cards that are enrolled in these schemes are being successfully shown the 3D Secure pages, others are failing, and talking to the issuing banks hasn't helped as they are telling us they haven't seen the transaction.

We are getting messages from servers like "cap.securecode.com" stating:

Your authentication could not be completed because of a system error. If this happens consistently, please contact your CSR".

Or from "www.securesuite.co.uk":

You cannot access this page.

This may be due to one of two reasons:

  1. The FI you are trying to access is deactivated
  2. The access to the FI is restricted for specific IP addresses, and your address is not one of them

Has anyone else seen these errors returned from the verifying banks, and how can I resolve it?

I'm trying to get further details of any pattern to the successes and failures.

+1  A: 

Let me try to give you some additional information,

I am working at a issuer bank. If the transaction involves 3D Secure, then the first step is 3D secure authentication, and only after success the autorisation. If the issuer bank did hand over the handling of 3D secure to another organisation, then it is true that they never see the transaction in case of 3D secure errors. In other words, they never did an authorisation. It depends if they know about the 3D secure error. Therefore, contacting the issuer will probably not help.

If I am correct, then you've issues with multiple 3D secure organisations. If I assume that every issuer has his own 3d secure organisation, then you have problems with credit cards from different issuers (you named securecode and securesuite). Therefore I think it has nothing to do with the credit card, but with your processing only.

Isn't the problem completely in hands of your payment processor? Or are you maybe doing something wrong in your communication with the payment processor? Notice that Visa and Mastercard did implement 3D Secure a little bit different.

(Maybe a stupid question, but are you sure that the cards with an error are Visa and Mastercard? Could it be true that the customer uses a card (e.g. JBC) that is not supported by your payment processor?)

robertnl
Thanks for the answer, and good comments, I'll try to answer them here: 1) Agreed, contacting the issuing bank has indeed not helped - the errors are being returned from the servers that should show the 3D Secure page BEFORE that page is shown. 2) I'm trying to get more details from the client, but it would appear to be issuer based rather than card based - i.e. cards from Lloyds bank worked, ones from HSBC didn't, rather than all VISA cards worked, no MasterCard cards worked.
Zhaph - Ben Duguid
3) The payment processor (Datacash) is responding in the same way regardless of type, it returns a PaReq value that we must submit to the URL that it also supplies. Yes, I've noticed that the screens displayed to the user can be different. 4) Not a stupid question, but I get a different (handled) error code from Datacash stating that I'm not allowed to use (for example) AmEx or JCB.
Zhaph - Ben Duguid
Are you trying to do 3D secure for a card that is not enable for 3D secure yet? (Remember I do work on the issuer site) From our point of view we (or the customer) activate or deactivate 3D secure for the card. This is on card level, not on schema or BIN level. You can receive 2 cards from the same issuer, same scheme, same BIN while one is enabled, and one is not. I happen to know that some issuers did not activate 3D for their cards in one scheme (e.g. all Visa cards of that issuer are enabled, AMex is not). This all would explain why your errors are on issuer-level instead of scheme
robertnl
A: 

It looks like there was an issue with the form we were using to submit the request to the 3D Secure servers:

<form method="post" 
      enctype="multipart/form-data" 
      action="https://[3dSecureServer]"&gt;
  <input value="[EncodedRequest]" name="PaReq" type="hidden">
  <input value="[RetailerReference]" name="MD" type="hidden">
  <input value="[RetailerReturnUrl]" type="hidden" name="TermUrl">
  <p>If you do not see your card issuer's instructions, below, 
     please click <input value="Continue" name="TDAction" type="submit"></p>
</form>

Removing the enctype attribute from the form seems to have resolved the issue - it's had no effect on the transactions that were succeeding, and allows those transactions that where failing to succeed as well.

I imagine that this was taken from some other sample code.

Zhaph - Ben Duguid