Токенизация карт и PCI DSS 4

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

Начните с платёжной задачи и границ применения

Определите, для чего нужен токен: регулярных платежей, операций по инициативе мерчанта, сохранённой карты, переноса между провайдерами или другого конкретного сценария. Укажите, куда поступают исходные карточные данные и какая система создаёт, хранит токен и восстанавливает по нему исходные данные.

Разберитесь с контролем токенов и их переносом

Токен конкретного провайдера может упростить работу с одним PSP, но ограничить возможность его смены. Токены платёжной системы или уровня оркестрации предъявляют другие коммерческие и технические требования. Уточните, кто контролирует токен, где его можно использовать и что происходит при смене маршрута.

Защитите весь жизненный цикл

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

Токен — это мера защиты и часть условий интеграции. Он не должен создавать недокументированную зависимость от одного маршрута.

Опишите поведение для разработчиков и поддержки

Зафиксируйте создание, повторное использование, срок действия, ошибки, callback и ответы провайдера. Поддержка должна находить платёж и объяснять ошибки токенизации без доступа к чувствительным карточным данным.