Некоторые банки-эмитенты отказываются от запросов 3D Secure

Question

У нас есть коммерческий сайт, с которым мы пытаемся настроить 3D Secure (проверено VISA/Mastercard Securecode).

Мы используем DataCash в качестве нашего поставщика платежей.

Мы видим следующую проблему:

Некоторым картам, зарегистрированным в этих схемах, успешно показываются страницы 3D Secure, другие терпят неудачу, и общение с банками-эмитентами не помогло, поскольку они говорят нам, что не видели транзакцию.

Мы получаем сообщения от серверов, таких как "cap.securecode.com", заявляющих:

Ваша аутентификация не может быть завершена из-за системной ошибки. Если это происходит постоянно, пожалуйста, свяжитесь с вашим КСО ".

Или с "www.securesuite.co.uk":

Вы не можете получить доступ к этой странице.

Это может быть связано с одной из двух причин:

1. FI, к которой вы пытаетесь обратиться, деактивирована
2. Доступ к FI ограничен для определенных IP-адресов, и ваш адрес не является одним из них

Кто-нибудь еще видел эти ошибки, возвращенные проверяющими банками, и как я могу их исправить?

Я пытаюсь получить более подробную информацию о любой модели к успехам и неудачам.

Answer 1

Похоже, возникла проблема с формой, которую мы использовали для отправки запроса на серверы 3D Secure:

<form method="post" 
      enctype="multipart/form-data" 
      action="https://[3dSecureServer]">
  <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>

Удаление enctype атрибут из формы, похоже, решил проблему - он не оказал влияния на транзакции, которые были успешными, и позволяет тем транзакциям, которые также не могут быть успешными.

Я предполагаю, что это было взято из некоторого другого примера кода.

Answer 2

Позвольте мне попытаться дать вам дополнительную информацию,

Я работаю в банке-эмитенте. Если в транзакции используется 3D Secure, то первым шагом является 3D-аутентификация и только после успешной авторизации. Если банк-эмитент передал обработку 3D-безопасности другой организации, то это правда, что они никогда не увидят транзакцию в случае ошибок 3D-безопасности. Другими словами, они никогда не делали авторизацию. Это зависит от того, знают ли они об ошибке 3D-безопасности. Поэтому связаться с эмитентом, вероятно, не поможет.

Если я прав, то у вас проблемы с несколькими 3D безопасными организациями. Если я предполагаю, что у каждого эмитента есть собственная организация 3d secure, то у вас проблемы с кредитными картами разных эмитентов (вы назвали securecode и securesuite). Поэтому я думаю, что это не имеет ничего общего с кредитной картой, но только с вашей обработкой.

Разве проблема не полностью в руках вашего обработчика платежей? Или вы что-то не так делаете в общении с процессором платежей? Обратите внимание, что Visa и Mastercard реализовали 3D Secure немного по-другому.

(Возможно, глупый вопрос, но вы уверены, что карты с ошибкой - это Visa и Mastercard? Может ли быть так, что клиент использует карту (например, JBC), которая не поддерживается вашим платежным процессором?)

Answer 3

3D-безопасность - беспорядок - ваш платежный процессор будет передавать на один из многих сайтов в зависимости от того, кто выпустил вашу карту. Некоторые из этих сайтов принимают запрос GET, а некоторые только запрос POST. Вы можете получить эту ошибку, если отправляете GET, а не POST.

Answer 4

Вероятно, будет полезно всем, если я скажу, что некоторые банки (MPI) возвращают ответы PaReq с пробелами, эти пробелы ДОЛЖНЫ быть заменены знаками "+", помните, что если вы кодируете в PHP, вы не можете просто кодировать они с urlencode, так как это может нарушить само перенаправление после предоставления правильных деталей.

С уважением К