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

Question

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

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

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

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

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

Ваша аутентификация не может быть завершена из-за ошибки системы. Если это происходит постоянно, обратитесь к CSR www.securesuite.co.uk "»

Или с.":.

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

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

1. ПЧ вы пытаетесь получить доступ деактивируется
2. Доступ к ФИ ограничен для конкретных 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-защищенная организация, тогда у вас проблемы с кредитными картами разных эмитентов (вы назвали securecode и securesuite). Поэтому я думаю, что это не имеет ничего общего с кредитной картой, но только с вашей обработкой.

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

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

Answer 3

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

Answer 4

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

Отношения K