Насколько мне известно, как конкретно будет проходить аутентификация (по фиксированному платежному паролю, одноразовому, или по тому и другому) решает банк-эмитент. У продавца нет возможности влиять на это, он может только запросить сам факт аутентификации.
Некоторые банки с фиксированным паролем используют одноразовый при неправильном вводе первого, либо раз в определенный промежуток времени.
Про 90% вы правы, почти все банки создают свои процессинговые центры и большинство из них делают это на платформе от openway. В решении от openway для взаимодействия с клиентами используется как раз упомянутый выше ISO, который всего лишь описывает формат сообщений для взаимодействия. Так что, во-первых, он работает не только между банками, как вы утверждаете. А во-вторых, если клиент работает с банком напрямую, а не через платежную форму, то имя держателя карты и прочие данные не доходят даже до ПЦ банка. Стоит заметить, что в качестве таких «прямых» клиентов обычно выступают платежные шлюзы, которые берут все обязанности по фродмониторингу на себя.
Я говорю об имени владельца. Не может банк включить никаких стоплистов, потому что имя владельца ему не передается. Использовать стоплисты (по имени владельца, ip-адресу, номеру карты) может процессинговый центр, но конкретно по кардхолдеру это делать бессмысленно — ниже описал почему.
Ну а делать стоп-листы по имени владельца — это затея неблагодарная, т.к. имя можно ввести произвольное и нет технической возможности сверить его с именем, нанесенным на карте.
Банк (в действительности даже не банк, но это не столь важно) не может дать ответ о принудительном 3ds. Он может только сказать, поддерживает ли карта 3ds или нет. Хотя, действительно, существуют карты которые процессется только по 3ds.
Вы несете полную ахинею. Процессинговый центр работает с банком-эквайером по ISO 8583, среди данных клиента: номер карты, дата истечения и cvv (и то не всегда). Никаких данных о владельце карты, ip адресе и т.д. там нет.
Все верно говорят, процессить с 3ds или без решает в конечном счете магазин. Плюс для магазина: ответственность за чарджбеки по 3ds транзакциям ложится на плечи банка-эмитента. Минус для магазина: падает проходимость, т.к. некоторые карты не поддерживают 3ds.
«где главными компонентами выступают GUI и БД» — это справедливо почти для любого веб-приложения. А они вполне хорошо проектируется и покрываются тестами (как модульными, так и функциональными), особенно если используют MVC.
В таких случаях рекомендуют потратить время и зафиксировать поведение хотя бы наиболее критичных участков системы функциональными тестами. Это позволит сделать месиво менее кровавым :)
Вариант «outside-in approach» хорошо описан в Getting Real от 37signals и он отлично работает для проектов с тонкой моделью. Но для продуктов со сложной бизнес-логикой его использовать затруднительно.
Некоторые банки с фиксированным паролем используют одноразовый при неправильном вводе первого, либо раз в определенный промежуток времени.