2009-12-13 1 views
11

Есть ли какая-либо техническая/юридическая/финансовая/контрактная/конструктивная причина для того, чтобы не принимать номера кредитных карт с пробелами в них?Есть ли хорошая причина, по которой многие веб-сайты не принимают кредитные карты с пробелами и тире в них?

Так много веб-сайтов не позволяют помещать пробелы или тире в номер кредитной карты. Я всегда ставил это на неряшливое программирование, но раньше я использовал торговые API. Если вы можете выяснить, как обрабатывать кредитную карту, вы можете выяснить, как удалить символы из строки. Дизайнеры знают, что они генерируют разочарование пользователя, потому что они помещают предупреждение прямо на веб-сайт. Они прямо на карте! Для этого есть даже wall of shame.

Ложная лень, плохое программирование, черствость, садизм ... все это предполагает худшее в человеке, выполняющем код. Самое щедрое, что я могу придумать, это то, что они действительно консервативны с чем-то, что связано с деньгами. Я всегда задавался вопросом, есть ли какая-то глубокая и действительно важная причина, почему вы не должны принимать номера кредитных карт с пробелами в них? Почему вы не должны пытаться применять какие-либо эвристики. Может быть, какое-то причудливое финансовое право, относящееся к телеграфному возрасту? Возможно, они невоспетые герои, защищая нас от какого-то неизвестного зла, чтобы три раза не вводить номер кредитной карты Хастура.

+2

Ну, это точно не означает ограничения пропускной способности. –

+7

Я думаю, что определение «связанное с программированием» здесь становится немного фашистом. Вопросы, которые напрямую не связаны с техническими аспектами программирования, но явно являются тем, что многие программисты должны решать в ходе своей работы, имеют законное место в SO. Это явно программирование, связанное с любым разумным определением, поскольку он пытается понять, почему веб-сайты ** запрограммированы ** так, как они есть. – dsimcha

+3

Пожалуйста, заново открыть. См. Http://meta.stackexchange.com/questions/5018/describing-close-reasons «не связанное с программированием»: «Как правило, вопросы о stackoverflow.com относятся к программированию. Этот вопрос очень далек от программирования. «.. Говоря, что этот вопрос:« ОЧЕНЬ ДАЛЬНЕЙШИЙ АФИТИТ »- это смешно. –

ответ

0

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

+2

У всех есть причина. Не все имеет хорошую или вескую причину. :) –

0

Я не помню ничего в своем торговом соглашении, в котором указано, что пользователи должны были ввести в поле формы, запрашивая номер кредитной карты. Я не очень стараюсь нормализовать его, но я удаляю пробелы и дефисы. Существуют правила о том, что вы можете повторно отобразить, но это всего лишь количество контента, а не точная форма.

Вы увидите похожие вещи для номеров телефонов и номеров социального страхования, поэтому я не думаю, что это проблема номер кредитной карты.

В основном я считаю, что это в основном проблема промежуточного программного обеспечения. У вас есть интерфейс, разработанный одной группой, бэкэнд, разработанный другим, и между ними есть готовый компонент промежуточного программного обеспечения, которому никто не нравится, и каждый должен настроить таргетинг. Среднее программное обеспечение написано настолько строго, насколько возможно, думая, что ответственность за нормализацию всех данных лежит на обеих сторонах. Затем начинается перфорация, и все начинают плакать, и вы не можете использовать пробелы в своем номере кредитной карты.

8

На самом деле нет веской причины, что это лень или временные ограничения.

Хорошие пользовательские интерфейсы должны адаптироваться к пользователю и несколько способов, которыми пользователи могут думать об их данных.

Для пользовательского интерфейса достаточно легко адаптировать пользователя к тире или пробелам на кредитной карте.

+1

Да, это просто sucky UI. Поместите его в поля адреса, которые не ожидают, что вы добавите запятые после имен, чтобы вы получили двойные запятые. И поля даты, которые заставляют вас вводить «02 09 2009», когда 2 9 09 будут столь же значимыми и правильными. И страницы, которые забывают половину деталей, которые вы набрали, если вы получите какой-либо из вышеперечисленных «неправильных». –

1

Моим первым ответом было бы «уменьшить сложность до абсолютного минимума», но я думаю, вы также можете утверждать, что он запутывает данные, если где-то есть поверхность атаки - изворотливый маршрутизатор/сниффер/человек-в- the-middle - «xxxx xxxx xxxx xxxx» - почти наверняка номер кредитной карты, но «xxxxxxxxxxxxxxxx» может быть рядом. Конечно, это не будет сдерживать много решительных хакерство, и мы надеемся, в значительной степени смягчается SSL и т.д.

Подчеркиваю, я не думаю, что это хорошая причина, но это может быть в причина ...

+0

Конечно, эта обработка может (и должна в этом случае) выполняться на стороне клиента, поэтому отформатированная версия никогда не покидает машину ...Но я думаю, что отправка номеров кредитных карт в открытом виде вообще является возмутительной. – KernelJ

+0

@ KernelJ - кто упомянул открытый текст? Я сказал SSL. –

+0

Если ваш изворотливый маршрутизатор генерирует действительные номера кредитных карт, поставьте его на EBay и уйдете на пенсию. : P – Schwern

-1

Я думаю, что это просто вопрос лени и менее программирование, потому что можно принять его с помощью AND без тире. или даже создавать разные текстовые поля для каждой части (используя 4 или 5 небольших текстовых полей вместо использования гигантского текстового поля. или, может быть, просто потому, что люди могут запутаться

+1

Oooh, отдельные коробки больше зла, чем пользы из-за несоответствия в длине и расположения номеров кредитных карт. Например, карта AmEx использует 3 группы. Я уверен, что вы могли бы придумать какую-нибудь умную вещь Javascripty, которая изменила формат коробки на основе типа кредитной карты, но я уверен, что вы оставите некоторых пользователей, которые не будут думать, чтобы установить тип до номер озадачен. – Schwern

-1

Я всегда находил это очень странным, так как его тривиальное чтобы удалить цифры из строки.

Это еще более запутанно, учитывая, что каждый тип карты (Visa/MC/Amex/Discover) имеет уникальную кодировку с использованием check digits. Поэтому, когда я ввожу номер кредитной карты и выбираю VISA в качестве типа карты интеллектуальный валидатор будет проверять, что номер является номером Visa. Итак, если вы собираетесь правильно проверить номер CC, вам придется удалить цифры без какой-либо строки, предоставленной пользователем.

Там три основные причины, я могу думать о том, почему проверка карты осуществляется плохо:

  • контрольная цифра проверки, что не ожидает невыполнения номера.
  • Ленивый/проблемный программист передает все аргументы без предварительной проверки на платежный шлюз и позволяет шлюзу проверять информацию о кредитной карте. Платежный шлюз гораздо более жесткий с его аргументом/проверкой данных, тогда должен быть пользовательский интерфейс.
  • Непонимание о мнимых юридических последствиях изменения пользовательских данных cc.
+2

На самом деле, контрольная цифра не различается по картам. Почти все они используют алгоритм Луна (и это не кодирует ничего). Вы можете рассчитать действительные номера карт отдельно по первым цифрам, иногда даже идентифицируя банк-эмитент. –

Смежные вопросы