Токенизация карт: замена данных карты токеном

Прямой ответ

Токен — идентификатор сохранённого способа оплаты, который используется вместо данных карты. Токен создаётся на стороне провайдера, поэтому данные карты не попадают в сервис.

import httpx

# 1. Способ оплаты создаётся на стороне провайдера (форма либо SDK)
# 2. Сервис получает идентификатор и привязывает его к клиенту
r = httpx.post(
    "",
    auth=(SHOP_ID, SECRET_KEY),
    json={"payment_method": "pm_9xY2abcd", "type": "card"},
    timeout=10.0,
)
saved = r.json()["id"]

Собственная база хранит только токен и сведения для отображения:

CREATE TABLE payment_methods (
    id           bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    user_id      bigint NOT NULL,
    provider_id  text NOT NULL UNIQUE,
    brand        text,
    last4        char(4),
    exp_month    smallint,
    exp_year     smallint,
    is_default   boolean NOT NULL DEFAULT false,
    created_at   timestamptz NOT NULL DEFAULT now()
);

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

Влияние на требования безопасности принципиально: сервис, не хранящий и не передающий данные карты, попадает в уменьшенный объём требований. О требованиях — в статье про PCI DSS и платёжную форму.

Срок действия токена и обновление способа оплаты

Токен не бессрочен. Срок определяется политикой провайдера и сроком действия карты, на которую токен ссылается.

Истечение срока карты. Токен остаётся валидным идентификатором, но операция по нему отклоняется, поскольку срок действия карты истёк. Пользователь уведомляется до истечения, и добавляется новый способ оплаты.

Отзыв токена. Пользователь либо банк отзывает способ оплаты, и операции по токену отклоняются. Сервис обрабатывает отказ запросом нового способа оплаты.

Удаление способа оплаты. Удаление у провайдера делает токен недействительным, поэтому запись в сервисе помечается удалённой, а не используется для списания.

Практическое следствие: перед списанием токен проверяется, а отказ по токену обрабатывается отдельной веткой, а не общей ошибкой платежа. О повторных списаниях — в статье про рекуррентные платежи.

Отдельный аспект — привязка токена к клиенту. Токен, созданный без привязки, используется однократно, а привязанный к клиенту — многократно. Выбор определяется сценарием: разовая оплата не требует сохранения, подписка требует.

Обновление способа оплаты при истечении выполняется провайдером автоматически для части платёжных систем, но не для всех, поэтому сервис отслеживает срок и уведомляет пользователя. Ключи доступа к API провайдера хранятся вне кода и периодически заменяются; о замене — в статье про ротацию секретов.

Практика: работа с сохранёнными способами оплаты

1. Не сохраняйте данные карты в своей базе. Токен провайдера исключает хранение и уменьшает объём требований безопасности.

2. Храните только отображаемые сведения. Последние четыре цифры и бренд достаточны для выбора способа оплаты в интерфейсе.

3. Привязывайте токен к клиенту для повторных операций. Непривязанный токен используется однократно и не подходит для подписки.

4. Проверяйте токен перед списанием. Отказ по токену обрабатывается запросом нового способа оплаты.

5. Отслеживайте срок действия карты. Уведомление до истечения снижает число отказов списания.

6. Помечайте удалённые способы оплаты. Удаление у провайдера делает токен недействительным, поэтому запись не используется для списания.

7. Ограничивайте число сохранённых способов оплаты. Избыточный список усложняет выбор и увеличивает поверхность ошибок.

Рекомендации:

1. Различайте токен и данные карты. Токен — идентификатор, утечка которого не позволяет выполнить операцию без ключей API провайдера.
2. Защищайте ключи API строже токенов. Ключи позволяют создавать операции, поэтому их компрометация опаснее утечки токенов.
3. Не логируйте токены в открытом виде. Токен идентифицирует способ оплаты, поэтому в журнале хранится его сокращённая форма.
4. Проверяйте идемпотентность сохранения. Повторный запрос привязки не должен создавать дубли записи способа оплаты.
5. Документируйте поведение при отказе по токену. Пользователь получает запрос нового способа оплаты, а не общее сообщение об ошибке.

Практический сценарий: списание по отозванному способу оплаты

Контекст: ежемесячное списание по подписке отклонялось в течение двух периодов, пользователь не получал уведомлений.

1. Диагностика. В истории платежей отказы со стороны провайдера с причиной, указывающей на недействительный способ оплаты. Подписка оставалась в статусе «активна», поскольку отказ обрабатывался как временный.
2. Причина. Пользователь отозвал способ оплаты в банке, токен стал недействителен, а сервис относил отказ к временным причинам и повторял списание без запроса нового способа оплаты.
3. Действия. (а) Разделили причины отказа: отказ по способу оплаты отнесён к постоянным, требующим нового способа; (б) добавили уведомление пользователя с запросом нового способа оплаты при постоянном отказе; (в) перевели подписку в ограниченное состояние после исчерпания попыток; (г) добавили проверку токена перед списанием; (д) добавили метрику доли отказов по причине способа оплаты для раннего обнаружения.
4. Результат. Постоянный отказ приводит к запросу нового способа оплаты, а пользователь уведомляется до исчерпания периода.

Вывод: отказ по токену требует отдельной обработки, поскольку повтор списания по недействительному способу оплаты не даёт результата. Разделение временных и постоянных причин отказа с уведомлением пользователя устраняет накопление просроченных периодов.

FAQ

Можно ли выполнить операцию по украденному токену? Токен используется вместе с ключами API провайдера, поэтому его утечка без ключей не позволяет выполнить операцию. Ключи требуют отдельной защиты.

Нужно ли хранить данные карты для повторных списаний? Нет. Привязанный к клиенту токен используется многократно без хранения данных карты.

Что происходит при истечении срока карты? Операции по токену отклоняются. Пользователь уведомляется заранее и добавляет новый способ оплаты.

Сокращает ли токенизация объём требований безопасности? Да, поскольку сервис не хранит и не передаёт данные карты, что уменьшает область применения требований.

Источники: Stripe payment methods, PCI Security Standards Council, PayPal save payment methods — ссылки в шапке.