Рекуррентные платежи

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

Как это выглядит целиком

Как это работает

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

Дальше мерчант вызывает отдельную операцию повторного списания — Recurrent, передавая ссылку на исходный платёж и новую сумму. Система находит исходную транзакцию, берёт сохранённые карточные данные по токену и проводит новый платёж через тот же гейт. Аутентификация держателя не требуется — в этом и смысл сценария.

Каждое повторное списание — отдельная транзакция, связанная с исходной. У неё свой результат, своё уведомление мерчанту и своё влияние на баланс. Система ведёт счёт таких списаний по исходному платежу.

Что делает это возможным

Ключ ко всему — токенизация. Мы не храним карту у мерчанта и не просим её повторно: постоянный токен позволяет обратиться к тем же данным спустя месяцы. Именно поэтому токен и должен быть обратимым — без этого подписки были бы невозможны.

Что важно помнить

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

Не каждый гейт поддерживает такие операции. Возможность зависит от банка и от того, как настроен гейт.

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

Куда дальше

• Платёж картой server-to-server — как проходит первый платёж.
• Карточные данные и токены — почему повторное списание возможно без карты.
• Двухстадийные платежи — другой сценарий, где операция растянута во времени.