Генератор номеров кредитных карт нужен командам, которые проверяют платежные формы, корзину и обработку заказов, но не могут использовать в тестах настоящие реквизиты клиентов. Такой генератор собирает номер, который устроен по правилам платежных систем: правильная длина, осмысленный префикс выпуска и корректная контрольная цифра. Путаница возникает из-за того, что структурно верный номер легко принять за что-то большее, чем он есть: он не привязан ни к одному счету, не проводит ни одного платежа и не должен использоваться вне тестового окружения. Дальше разберём, из чего состоит номер, какую роль играет контрольная цифра и почему срок действия и код проверки обязаны быть согласованы с остальными полями. В конце вы получите список проверок для платежной формы и ясное понимание, где проходит граница допустимого.
Чем тестовый номер отличается от настоящего
Настоящий номер выпускается банком и привязан к конкретному счету, конкретному клиенту и конкретному сроку действия. Он существует в процессинговой системе, по нему проходят авторизации, и его утечка означает реальный финансовый риск для владельца. Тестовый номер не выпущен никем: он построен по тем же правилам формата, но за ним нет счета, и любая попытка провести по нему платеж закончится отказом.
Разница видна не в длине и не в структуре, а в происхождении. Поэтому вопрос «как отличить тестовый номер от настоящего» не имеет универсального ответа на уровне строки: внешне они устроены одинаково. Отличать их нужно по контексту — по тому, откуда взято значение и где оно используется.
Отсюда первое практическое правило: тестовые значения должны быть получены из контролируемого источника и помечены как тестовые в самом наборе. Если номер появился из переписки, скриншота или копии рабочей базы, он не тестовый, даже если выглядит безобидно, и обращаться с ним следует как с настоящими реквизитами.
Второе правило касается хранения. Тестовые номера можно держать в репозитории рядом с другими образцами данных, потому что они не принадлежат никому. Настоящие нельзя, и никакие послабления для тестового окружения здесь не действуют.
Что означает префикс выпуска
Первые знаки номера указывают на платежную систему и на банк, выпустивший карту. Эта часть называется идентификационным номером эмитента: по ней маршрутизируется запрос и определяется, к какой сети относится карта. Разные системы используют разные диапазоны, и форма, которая проверяет только длину, не увидит подмены.
Практическая ценность префикса в тестах двоякая. Во-первых, он позволяет проверить, что форма правильно определяет тип карты и показывает подходящий значок. Во-вторых, он даёт негативные случаи: номер с префиксом одной системы и длиной, характерной для другой, должен быть отвергнут.
Третья деталь — длина. У разных систем она различается и обычно составляет от пятнадцати до девятнадцати знаков, причём платёжные системы внутри себя допускают не одно значение. Форма, которая жёстко ожидает шестнадцать знаков, отвергнет часть корректных номеров, и это отдельный дефект, который ловится только на правильно подобранном наборе.
Наконец, префикс не выводится из названия банка и не проверяется по внешнему справочнику в момент ввода. Это просто диапазон значений, и для тестов достаточно, чтобы генератор брал его из осмысленного набора, а не выдавал произвольные цифры.
Зачем нужна контрольная цифра
Последний знак номера вычисляется по опубликованному правилу и называется контрольной цифрой. Алгоритм прост: цифры поочерёдно умножаются на два и на единицу, результаты, превысившие девять, заменяются разностью с числом девять, затем всё складывается, и остаток от деления на десять определяет, каким должен быть последний знак. Подробный разбор этого правила есть в статье про алгоритм Люна.
Смысл контрольной цифры чисто практический: она ловит опечатку и перестановку соседних знаков. Если пользователь набрал номер с ошибкой в одной цифре, проверка почти всегда это заметит. Именно поэтому все платёжные формы выполняют такую проверку перед отправкой: она дешёвая, мгновенная и отсекает значительную часть ошибок ввода.
Важно понимать границы этой проверки. Контрольная цифра подтверждает, что номер построен по правилам, и ничего не говорит о том, существует ли он. Последовательность из повторяющихся цифр или простой ряд вроде возрастающего на единицу не проходит проверку именно потому, что контрольная цифра не сходится, и это хороший тестовый случай, показывающий, что форма действительно считает, а не просто смотрит на длину.
Отсюда следует и главный вывод для тестового набора. Генератор должен вычислять контрольную цифру, а не подставлять случайную. Номер со случайным последним знаком выглядит правильно для человека и разваливается на первой же проверке, и тест, построенный на таких значениях, проверяет не форму, а случайность.
Почему срок действия и код проверки должны совпадать
Номер — только часть реквизитов. Рядом стоят срок действия и короткий код проверки, и форма проверяет их вместе с номером. Если срок уже истёк, платёж не пройдёт даже при верном номере; если формат срока не совпадает с ожидаемым, форма отвергнет запись до обращения к сети.
Тестовый набор должен учитывать эту связку. Полезно иметь записи с действующим сроком, с истекающим в текущем месяце и с уже истёкшим. Отдельно стоит проверить формат: две цифры месяца и две цифры года, с разделителем и без него, с ведущим нулём и в однозначном виде. Все варианты означают одно и то же, и форма должна либо принимать их, либо явно объяснять требование.
Код проверки на обратной стороне карты тоже имеет смысл только в связке с остальными полями. Для разных систем его длина различается, и универсальное правило тут не работает. Форма не должна отвергать корректное значение из-за слишком строгой проверки, но и не должна принимать любое число знаков.
Наконец, стоит помнить, что срок действия и код проверки не участвуют в проверке контрольной цифры: она относится только к номеру. Смешивать эти правила в одной процедуре неверно, и тесты, которые этого не учитывают, дают ложные срабатывания.
Где брать официальные тестовые карты?
Платёжные шлюзы публикуют собственные наборы тестовых номеров, привязанные к их тестовому окружению. Такие значения удобны тем, что обработчик заранее знает, что с ними делать: одни номера всегда одобряются, другие всегда отклоняются, третьи воспроизводят конкретный сценарий вроде требования дополнительной проверки. Для отладки интеграции со шлюзом это самый надёжный путь, и в статье про тестовые карты платёжных сервисов разобрано, как такими наборами пользоваться.
У этого пути есть ограничение: набор привязан к конкретному шлюзу и не переносится на другой. Если ваша система работает с несколькими провайдерами, придётся держать несколько наборов, и это нормально.
Второй путь — генерировать значения самостоятельно по правилам формата. Это удобно, когда нужно много записей, когда проверяется сама форма без обращения к внешнему шлюзу или когда требуется нестандартное сочетание системы, длины и срока. Такой набор полностью подконтролен и не зависит от чужой документации, которая со временем меняется.
Разумная практика — совмещать оба подхода. Официальные значения используются для проверки интеграции с конкретным провайдером, а сгенерированные — для проверки формы, валидации и нагрузки.
Что говорит стандарт безопасности платежных данных?
Стандарт, регулирующий обращение с данными платёжных карт, распространяется на любую среду, где такие данные хранятся, обрабатываются или передаются. Тестовое окружение не является исключением: если в нём лежат настоящие номера, требования действуют в полном объёме, со всеми последствиями для архитектуры, аудита и ответственности.
Из этого следует простое и жёсткое правило: настоящие реквизиты не должны попадать в тестовые среды. Ни целиком, ни частями, которые позволяют восстановить номер, ни в виде копий рабочих таблиц. Об этом подробно говорится в статье про данные для тестов и требования безопасности, и там же разобрано, какие послабления допустимы для синтетических значений.
Второе следствие — маскирование. Если по каким-то причинам в тестовом контуре оказываются настоящие данные, они должны быть закрыты так, чтобы номер нельзя было прочитать. Но правильнее не допускать их появления вовсе, потому что любая защита на уровне отображения не отменяет факта хранения.
Третье следствие — журналы. Номера попадают в логи, в отчёты об ошибках, в трассировки запросов и в скриншоты. Тестовый набор из синтетических значений полностью снимает эту проблему: даже если он просочится в лог, вреда не будет.
Что проверить в платежной форме?
Начните с проверки самого номера. Форма должна принимать допустимые длины, отвергать неверную контрольную цифру и правильно определять систему по префиксу. Отдельно проверьте ввод с пробелами, дефисами и без разделителей: все варианты означают одно и то же.
Затем проверьте поля рядом. Срок действия должен принимать оба распространённых формата и отвергать явно истёкшие значения. Код проверки должен соответствовать правилам системы, а не универсальному шаблону. Имя владельца должно выдерживать длинные записи, дефисы и нелатинские буквы.
Дальше проверьте поведение при ошибках. Сообщения об ошибке не должны раскрывать, какая именно проверка не прошла, если это даёт подсказку потенциальному нарушителю. При этом они должны быть достаточно внятными, чтобы пользователь понял, что исправить. Разбор типовых сценариев приведён в статье про проверку платежной формы.
И последнее — проверьте, что номер нигде не сохраняется в открытом виде и не попадает в адресную строку или в журнал браузера. Это требование относится и к тестовому окружению, потому что привычка, закреплённая в тестах, легко переезжает в рабочую версию.
Как проверить, что набор не примут всерьёз?
Полезно убедиться, что набор невозможно спутать с рабочими данными. Номера тестовых диапазонов опубликованы платёжными системами именно для проверок, и они не обслуживаются в реальных сетях. Если же в наборе появляется значение, выданное когда-либо живому держателю, это уже не тестовые данные, а чужая платёжная информация, и хранить её в репозитории нельзя.
Второй момент — подписи и комментарии к набору. Если рядом с ним не написано, что это образцы для автотестов, следующий разработчик может принять их за рабочие ключи и попытаться использовать вне тестового контура. Одна короткая пометка в описании набора снимает этот риск полностью и стоит нескольких секунд работы.
Границы этих данных
Все значения, которые выдаёт генератор платёжных данных, синтетические. Они построены по правилам формата и содержат корректную контрольную цифру, но не привязаны ни к одному счёту, ни к одному человеку и не могут быть использованы для проведения платежа.
Практически это означает, что такие номера нельзя предъявлять как свои реквизиты, нельзя использовать для оплаты и нельзя применять, чтобы выдать себя за другого человека. Назначение этих образцов — проверка ваших собственных форм, валидаторов и тестовых окружений. Всё остальное лежит вне задачи.
Что делать дальше
Соберите для своей платежной формы короткий набор: несколько номеров разных систем с корректной контрольной цифрой, один номер с намеренно неверной цифрой, один с неверной длиной, случаи с истёкшим и истекающим сроком и один случай с некорректным кодом проверки. Затем зафиксируйте в документации проекта, что все реквизиты в тестах синтетические и получены из генератора, а настоящие данные в тестовое окружение не попадают ни при каких обстоятельствах.