Переход на оплату в рублях без остановки сервиса

Ситуация типичная: продукт работает, доступ оформлен на зарубежную карту сотрудника, и с каждым месяцем это всё менее устойчиво. Разберём, как перевести оплату на рублёвый счёт, ничего не сломав.

Почему это не разовое действие

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

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

Порядок действий

**Получить новый доступ.** Ключ выпускается заранее, до всяких изменений в продакшене.

**Провести тестовый платёж.** На минимальную сумму, с полным комплектом документов. Если документы не устраивают бухгалтерию, дальше идти нет смысла.

**Сверить поведение.** Прогнать тестовый набор на обоих доступах и сравнить.

**Перевести долю трафика.** Процентов десять, через флаг в конфигурации.

**Понаблюдать сутки.** Ошибки, время отклика, расход.

**Перенести остальное.** Старый доступ оставить до следующего релиза.

Что сверить

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

Лимиты у нового адреса свои. Нагрузка, которая проходила раньше, может начать упираться в потолок.

Формат ошибок совпадает не всегда. Ваша обработка кодов ответа заслуживает отдельной проверки.

Разбивка расхода по ключам должна сохраниться, иначе вы потеряете возможность считать себестоимость проектов.

Что происходит с остатком

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

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

Флаг вместо релиза

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

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

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

Что сказать команде

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

Короткое письмо на три абзаца снимает большую часть вопросов и позволяет заметить проблему раньше: люди знают, на что смотреть.

После перехода

Через неделю сравните расход за сопоставимый период. Разница в пределах десятка процентов — норма, заметное расхождение требует объяснения: изменились тарификация, размер запросов или доля повторов.

Через месяц проверьте, что комплект документов пришёл полностью и сходится с выгрузкой расхода. Это последний шаг, после которого переход можно считать завершённым, а старый доступ — закрыть окончательно.

Что делать с ключами и доступами

Переход — удобный момент навести порядок, который иначе откладывается годами.

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

Новые ключи выпускайте сразу раздельно: по одному на окружение и на подрядчика, с лимитами. Возвращаться к этому потом никто не станет, а сейчас это ничего не стоит.

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

Чего ожидать в первые дни

Небольшая доля ошибок в первые часы — это нормально: часть процессов кеширует конфигурацию и подхватывает новую не сразу.

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

А вот резкий рост числа ошибок определённого типа — не нормально, и разбираться нужно сразу. Чаще всего это несовпадение названия модели или более строгий лимит на новом адресе.

Коротко

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