Плановая смена PSP: перенос подписок и закрытие старых обязательств

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

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

Сначала составьте карту того, что остаётся

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

Предложенный принцип маршрутизации прост: новое действие обслуживает тот процесс, которому оно действительно принадлежит. Возврат старого платежа нельзя автоматически отправить новому PSP с прежним идентификатором. Уточните поддерживаемый путь у сторон и сохраните доступ, необходимый для согласованных операций. Если прежний договор заканчивается, отдельно согласуйте дальнейшее обслуживание и возможные ограничения.

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

Перенос данных ещё не переносит подписку

Платёжный токен, карточные данные, профиль клиента и график списаний являются разными объектами. Наличие строки token в экспорте не доказывает, что её можно использовать у нового провайдера. Stripe описывает отдельные процессы миграции платёжных данных с участием своей команды. Обзор миграций Stripe. Доступность и условия проверяют для конкретных методов и сторон.

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

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

У одного счёта должен быть один исполнитель

Представим подписку на 30 евро с ближайшим продлением 15 числа. Во время переезда старый планировщик ещё активен, а новая система уже получила клиента и дату продления. Оба могут корректно выполнить свои инструкции и создать два списания. Идемпотентность внутри каждого PSP такую коллизию между независимыми системами не разрешает.

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

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

Проверяйте перенос по группам

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

Для каждой группы сохраните исходный состав. Тогда отсутствие клиента в новой системе заметно, а сравнение конверсии не смешивает разных покупателей. Откат тоже требует правил: какие новые операции можно вернуть на прежний маршрут, а какие уже должны завершаться там, где начались? Нельзя отменить проведённые платежи простым откатом версии сайта.

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