Если транзакция прошла с 3DS-аутентификацией, то действительно, оспорить её очень сложно. Но и подделка 3DS-аутентификации сложна: надо перехватывать sms-ки или что-нибудь в этом духе.
Зато, если у вас на карточке включена подписка на 3DS, и по ней как-то провели транзакцию без 3DS — диспут однозначно разрешается в вашу пользу, сумма транзакции и все неустойки ложатся на торговца.
Вообще-то по-хорошему эта статья должна бы иметь в конце предложение альтернативы и доводы, почему она лучше.
Я несколько альтернатив видел (в разной степени), и ни про одну не могу сказать что она лучше чем текст:
* UML и другие воплощения идеи «а давайте у нас менеджеры будут программировать диаграммами». Коротко говоря: ужасно. Причин несколько: 1) менеджеры это не программисты, 2) утечка абстракций, 3) проприетарные закрытые ни с чем не совместимые форматы данных и средства разработки, 4) широко распространённые средства работы с исходниками (sed/grep/diff/merge итд) не работают с этими форматами, 5) итд. В общем, это скорее средства для попила бюджетов, чем для программирования.
* Исходники на каком-нибудь DSL (хорошо если основанном на чём-то широко известном), снабжённые метаинформацией и вместе с ней хранимые в XML. Т.е. вместо просто имени переменной идёт xml-элемент, содержащий её имя, описание, тип и чёрте знает что ещё. Коротко говоря: очень плохо. Причин несколько: 1) специализированный ни с чем не совместимый XML, 2) следствие: разрабатывать возможно только в одной специализированной среде, у которой куча проблем с юзабилити и производительностью, 3) опять же, всякие диффы плохо работают с XML, 4) итд
* Исходники на DSL, хранимые вместе с метаинформацией в бинарном формате. Коротко: очень плохо. Причины те же что с предыдущим, только стандартные средства ещё хуже работают с бинарными файлами, а формат конечно же уникальный и ни с чем не совместимый.
Некоторые — допускаю (хотя ни я ни мои знакомые с таким не сталкивались); но даже если через суд — закон на вашей стороне и деньги вы заведомо получите, только конечно потратите кучу времени и нервов.
С другой стороны, «юзер» (покупатель, картхолдер) сейчас как раз наиболее защищённая сторона во всей этой истории. Во-первых, у юзеров уводят гораздо меньшие суммы, чем у банков/процессингов — это и так понятно, у юзеров просто нет много денег. Во-вторых, если вы как юзер видите фродовую транзакцию в выписке — вы пишете в банке заявление и в разумные сроки почти всегда получаете деньги назад (многие банки предпочитают всегда возвращать деньги клиенту, независимо от исхода диспута). А вот банк как минимум вынужден оплачивать организацию диспута, да ещё и саму сумму транзакции в случае, если деньги клиенту он уже выдал, а от платёжной системы/мошенника/wtf не получил. Ну и самые незащищённые — торговцы.
Зато, если у вас на карточке включена подписка на 3DS, и по ней как-то провели транзакцию без 3DS — диспут однозначно разрешается в вашу пользу, сумма транзакции и все неустойки ложатся на торговца.
Я несколько альтернатив видел (в разной степени), и ни про одну не могу сказать что она лучше чем текст:
* UML и другие воплощения идеи «а давайте у нас менеджеры будут программировать диаграммами». Коротко говоря: ужасно. Причин несколько: 1) менеджеры это не программисты, 2) утечка абстракций, 3) проприетарные закрытые ни с чем не совместимые форматы данных и средства разработки, 4) широко распространённые средства работы с исходниками (sed/grep/diff/merge итд) не работают с этими форматами, 5) итд. В общем, это скорее средства для попила бюджетов, чем для программирования.
* Исходники на каком-нибудь DSL (хорошо если основанном на чём-то широко известном), снабжённые метаинформацией и вместе с ней хранимые в XML. Т.е. вместо просто имени переменной идёт xml-элемент, содержащий её имя, описание, тип и чёрте знает что ещё. Коротко говоря: очень плохо. Причин несколько: 1) специализированный ни с чем не совместимый XML, 2) следствие: разрабатывать возможно только в одной специализированной среде, у которой куча проблем с юзабилити и производительностью, 3) опять же, всякие диффы плохо работают с XML, 4) итд
* Исходники на DSL, хранимые вместе с метаинформацией в бинарном формате. Коротко: очень плохо. Причины те же что с предыдущим, только стандартные средства ещё хуже работают с бинарными файлами, а формат конечно же уникальный и ни с чем не совместимый.