Существует ли Серьезное основание, много веб-сайтов не примут кредитные карты с пробелами и тире в них? [закрытый]

Существует книга, названная Практические Диаграммы состояний в C/C++ . Однако это путь слишком тяжело для того, в чем мы нуждаемся.

11
задан skaffman 13 December 2009 в 20:20
поделиться

6 ответов

There really is no good reason other that laziness or time constraints.

Good UI's should adapt to the user and the multiple ways that users think about their data.

It's easy enough for the UI to adapt to the user entering dashes or spaces in the credit card.

8
ответ дан 3 December 2019 в 11:04
поделиться

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

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

1
ответ дан 3 December 2019 в 11:04
поделиться

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

0
ответ дан 3 December 2019 в 11:04
поделиться

I don't recall anything in my merchant agreement that stipulated what users had to enter in a form field asking for a credit card number. I don't go to great lengths to normalize it, but I do remove whitespace and hyphens. There are rules about what you can re-display though, but that is merely an amount of content and not the precise form.

You'll see similar things for phone numbers and social security numbers, though, so I don't think it's a credit card number problem.

I mostly think that this is mostly a middleware problem. You have the front-end developed by one group, the backend developed by another, and inbetween there is an off-the-shelf middleware component that nobody likes and everyone has to target. The middleware is written as strictly as possible thinking that it's the responsibility of either side to normalize all data. Then the fingerpointing starts and everyone goes home crying, and you can't use spaces in your credit card number.

0
ответ дан 3 December 2019 в 11:04
поделиться

I think its just a matter of laziness and less programing because one can make it accept with AND without dash. or even make different text boxes for each part(using 4 or 5 small text boxes instead of using a giant text box. or maybe its just because people might get confused

-1
ответ дан 3 December 2019 в 11:04
поделиться

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

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

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

  • Проверка правильности цифр, которая не предполагает отсутствия чисел.
  • Ленивый / обеспокоенный программист передает все аргументы без предварительной проверки на платежный шлюз и позволяет шлюзу проверять данные кредитной карты. Платежный шлюз гораздо более жесткий с проверкой аргументов / данных, чем должен быть пользовательский интерфейс.
  • Неправильное представление о мнимых юридических последствиях изменения предоставленных пользователем данных cc.
-1
ответ дан 3 December 2019 в 11:04
поделиться
Другие вопросы по тегам:

Похожие вопросы: