В этой статье
Миграция платформы проваливается в деталях, а не в архитектуре: мерчант, у которого изменился формат вебхука, токен, который не работает в новом хранилище, отчёт, который финансы не могут сверить. Этот чек-лист — то, что мы проходим с каждым клиентом, переходящим на Tranzify, в том порядке, который сохраняет платежи мерчантов во время переезда.
До первого мерчанта
- Провайдеры и терминалы. Каждый эквайер и провайдер методов с его аккаунтами, валютами, операциями и лимитами, внесённый в новые терминалы; тестовые платежи через каждый.
- Правила маршрутизации. Пересобраны в конструкторе потоков из старых правил, проверены с операционной командой, с цифрами возврата старой платформы как базой для сравнения.
- Комиссии и резервы. По мерчантам, как в старом леджере; первый расчёт — проверка.
- Пользователи и роли. Кто что видит в бэк-офисе; журнал аудита включён с первого дня.
- Домен и бренд. Сеть под доменом PSP, вид формы, отправитель писем.
- Опись мерчантов. Каждый мерчант с типом интеграции, методами, сохранёнными картами и подписками, точкой приёма вебхуков и человеком, который за него отвечает; порядок миграции следует этому списку.
По каждому мерчанту
- Тип интеграции. Мерчанты на размещённой форме меняют ссылку; API-мерчанты переносят свой поток на API Tranzify в песочнице и переключают ключи, когда тесты проходят.
- Вебхуки. Формат, который мерчант разбирает сегодня; новой интеграции нужна проверка обработки вебхуков до переключения.
- Токены. Сохранённые карты перетокенизируются при первом успешном платеже там, где позволяет эквайер; сообщите мерчанту, каким подпискам нужна новая аутентификация.
- Отчёты. Финансовая команда мерчанта сверяет первую неделю вручную со старыми отчётами.
- Возвраты старых платежей. Возвраты платежей, сделанных на старой платформе, делаются там до её отключения; поддержка мерчанта должна знать, на какой платформе живёт платёж, по его дате.
Порядок мерчантов
| Волна | Кто | Почему первыми |
|---|---|---|
| 1 | Один мерчант на размещённой форме с небольшим объёмом и отзывчивой командой | Проверяет сеть, провайдеров и отчёты на реальных деньгах без работы по интеграции |
| 2 | Мерчанты на размещённой форме, крупнейшие последними | Смена ссылки у каждого; операционная команда осваивает бэк-офис на реальном трафике |
| 3 | API-мерчанты с собственными разработчиками | Тесты в песочнице, затем ключи; каждый переключается, когда его тесты проходят |
| 4 | Мерчанты с подписками и сохранёнными картами | Перетокенизация при первом платеже; эквайеры, которые её допускают, идут первыми |
| 5 | Мерчант с нестандартным потоком, которого никто не помнит | Последним, со временем выяснить, каким был этот поток |
Параллельная работа
Обе платформы работают параллельно. Мерчанты переходят по одному, начиная с того, чья команда отвечает быстрее всех, а старая платформа продолжает обслуживать остальных. Ничего не отключается, пока последний мерчант не прошёл полный цикл расчётов на новой. Во время параллельной работы операционная команда с первого дня следит за обеими платформами: проценты одобрений по терминалам на новой против базы старой, колбэки и вебхуки каждого перенесённого мерчанта в трассировке и расчёт первого цикла против собственных цифр мерчанта.
День переключения
- Тесты мерчанта прошли в песочнице накануне; выданы ключи продакшена.
- Мерчант меняет ссылку или ключи в тихий час; первые платежи поддержка PSP и разработчик мерчанта смотрят в трассировке вместе.
- Вебхуки первых платежей сверяются с системой мерчанта; расхождение исправляется до следующего платежа, а не после сотни.
- Старая платформа хранит старые платежи мерчанта для возвратов; новые возвраты идут через новую.
- Финансовая команда мерчанта получает отчёт за первый день и сверяет его со своими записями.
Что идёт не так и как чинится
- Вебхук, которого мерчант не ждал: событие, которого старая платформа никогда не отправляла. Обработчик мерчанта игнорирует неизвестные ему события, пока не готов к ним.
- Сохранённая карта, которую эквайер не принимает по чужому токену: плательщика спрашивают один раз, и дальше хранилище держит карту для каждого эквайера.
- Отчёт с другими названиями колонок: финансовая команда сопоставляет их один раз; настройки выгрузки хранят сопоставление.
- Правило маршрутизации, которое ведёт себя иначе: трассировка показывает выбранную ветвь; правило исправляется в конструкторе и активируется новой версией с сохранением предыдущей.
- Аккаунт провайдера, который работает в песочнице и не работает в продакшене: обычная причина — учётные данные и разрешённые IP-адреса; тестовый платёж терминала находит это раньше мерчанта.
История
История платежей импортируется для отчётов и споров; переносить её в живой поток не нужно. Журналы на Tranzify начинаются с первого перенесённого платежа и хранятся пять лет. Импорт переносит платежи, возвраты и чарджбэки с их ссылками, суммами, датами и статусами, поэтому кабинеты мерчантов показывают их историю, а спор о старом платеже разбирается из нового бэк-офиса.
После последнего мерчанта
Старая платформа отключается после закрытия последнего расчёта с неё и истечения последнего срока возвратов по её платежам; её выгрузка хранится как архив. Правила маршрутизации ещё раз проверяются по месяцу цифр на новой платформе; цифры возврата и стоимости становятся новой базой. Страница о миграции описывает путь с точки зрения PSP, а страница решения для PSP — что платформа даёт после переезда.