用途：payment-migrator 用于规划并执行从一家支付服务商迁移到另一家的过程，核心目标是不停机。它把迁移视为新旧服务商并存的一段时期，并尽量让这段时期短、可观测、可回滚。
主要能力与流程：
- 盘点现状：读取 PAGOKIT_INTEGRATION.md 并与代码核对，梳理路由事件、已存储支付方式的客户数量、活跃订阅及下次扣款日期、所有持久化服务商标识的位置。
- 确认不可迁移项：已存储的卡令牌通常无法迁移，因其属于原服务商的金库；少数服务商支持 PCI 范围内的令牌导出或网络令牌迁移，但需双方书面协议。未获书面确认前，应计划让现有订阅用户重新输入卡号，这属于流失事件。
- 对比两家服务商：逐项比较 notification_model、webhook.required_events_minimum、mor.is_mor、支付方式及其可逆性、settlement.payout_delay_days、recurring.rails、pci.scope，并标出架构层面的差异。
- 安排并存顺序：新旧服务商并行，两套 webhook 路由同时存在；新支付走新服务商，存量保持不动；订阅在自然续费时迁移而非批量迁移；旧处理器需保留至旧服务商不再发送争议和退款；支付行上的服务商字段永久保留。
- 文档化：编写 PAGOKIT_MIGRATION.md，说明迁移内容、时间、不可迁移项、客户可见变化、验证方式与回滚方案。
可观测性：在首笔支付路由到新服务商前，需监控按服务商的成功率、拒付原因、webhook 投递失败、从结账到确认支付的时间。
限制与反模式：不要原子切换；不要在同一变更中迁移与重构；不要在最后一笔支付创建后删除旧 webhook 处理器；不要在双方书面确认前承诺已存储卡可迁移；不要在订阅周期中途迁移而不决定未使用部分的处理方式。具体支持的服务商、命令与配置细节暂未提供。