Некоторые банки-эмитенты отклоняют запросы 3D Secure [закрыто]
-
21-09-2019 - |
Вопрос
У нас есть коммерческий сайт, на котором мы пытаемся настроить 3D Secure (проверено VISA/Mastercard Securecode).
Мы используем DataCash в качестве нашего поставщика платежей.
Мы наблюдаем следующую проблему:
Некоторые карты, зарегистрированные в этих схемах, успешно отображаются на страницах 3D Secure, другие не работают, и общение с банками-эмитентами не помогло, поскольку они говорят нам, что не видели транзакцию.
Мы получаем сообщения от таких серверов, как «cap.securecode.com», в которых говорится:
Ваша аутентификация не может быть завершена из-за системной ошибки.Если это происходит постоянно, обратитесь в свой CSR».
Или с сайта «www.securesuite.co.uk»:
Вы не можете получить доступ к этой странице.
Это может быть вызвано одной из двух причин:
- ФИ, к которому вы пытаетесь получить доступ, деактивирован
- Доступ к ФИ ограничен для определенных IP-адресов, и ваш адрес не входит в их число.
Кто-нибудь еще видел эти ошибки, возвращаемые проверяющими банками, и как я могу их устранить?
Я пытаюсь получить более подробную информацию о любых закономерностях успехов и неудач.
Решение
Похоже, возникла проблема с формой, которую мы использовали для отправки запроса на серверы 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
Атрибут из формы, по-видимому, решил проблему - он не повлиял на успешные транзакции и допускает и те транзакции, которые не увенчались успехом.
Я предполагаю, что это было взято из какого-то другого примера кода.
Другие советы
Позвольте мне попытаться дать вам дополнительную информацию,
Я работаю в банке-эмитенте.Если транзакция включает 3D Secure, то первым шагом является аутентификация по 3D Secure, и только после успеха — авторизация.Если банк-эмитент передал обработку 3D Secure другой организации, то это правда, что они никогда не увидят транзакцию в случае ошибок 3D Secure.Другими словами, они никогда не делали авторизацию.Это зависит от того, знают ли они об ошибке 3D Secure.Поэтому обращение к эмитенту, скорее всего, не поможет.
Если я прав, то у вас проблемы с несколькими организациями, использующими 3D Secure.Если предположить, что у каждого эмитента есть своя организация 3d Secure, то у вас проблемы с кредитными картами разных эмитентов (вы назвали Securecode и SecureSuite).Поэтому я думаю, что это не имеет никакого отношения к кредитной карте, а только к вашей обработке.
Разве проблема не полностью в руках вашей платежной системы?Или, возможно, вы делаете что-то не так при общении с платежной системой?Обратите внимание, что Visa и Mastercard реализовали 3D Secure немного по-другому.
(Может глупый вопрос, но вы уверены, что карты с ошибкой это Visa и Mastercard?Может ли быть правдой, что клиент использует карту (например,JBC), который не поддерживается вашим платежным процессором?)
3D Secure — это беспорядок: ваш платежный процессор перейдет на один из многих сайтов в зависимости от того, кто выпустил вашу карту.Некоторые из этих сайтов принимают запрос GET, а некоторые только запрос POST.Вы можете получить эту ошибку, если отправляете GET, а не POST.
вероятно, всем будет полезно, если я скажу, что некоторые банки (MPI) возвращают ответы PaReq с пробелами, эти пробелы ДОЛЖНЫ быть заменены знаками «+», имейте в виду, что если вы кодируете на PHP, вы не можете просто кодировать их с помощью urlencode, поскольку это может нарушить само перенаправление после предоставления правильных данных.
с уважением К