Ключевые выводы
- Смоделируйте полный жизненный цикл, а не только создание профиля.
- Считайте обновления подготовки и использования асинхронными.
- Защитите данные активации и учетные данные.
- Обеспечьте согласование, поддерживайте прозрачность и восстановление после сбоев с самого начала.
Определить системы и право собственности
Определите систему учета клиентов, продуктов, цен, заказов, платежей и статуса подключения. Многие проблемы интеграции возникают из-за того, что двум системам разрешено владеть одним и тем же месторождением. Создавайте идентификаторы, которые будут сохраняться на витрине магазина, в платежной системе и на платформе подключения.
Задокументируйте, какая система может повторить, отменить, вернуть деньги или изменить заказ. Определите представление поддержки, чтобы агенты могли находить одну и ту же транзакцию без поиска отдельных инструментов.
Проектирование основных потоков API
Типичный процесс извлекает подходящие планы, создает или резервирует заказ, подтверждает оплату, назначает профиль eSIM и возвращает информацию об активации. Последующие потоки получают статус и использование, добавляют пакеты, обрабатывают истечение срока действия и поддерживают приостановку или замену, если это позволяет продукт.
Идентификаторы коммерческих продуктов следует хранить отдельно от идентификаторов сетей или поставщиков. Это позволяет клиентскому предложению оставаться стабильным при изменении базового подключения.
Безопасное использование асинхронных событий
Подготовка и сетевые обновления не всегда происходят мгновенно. Веб-перехватчики или опросы событий должны обновлять локальное состояние без создания дублирующихся заказов. Проверяйте подписи, сохраняйте идентификаторы событий и идемпотентно обрабатывайте события.
Явно обозначайте такие состояния, как ожидание, готовность, установленный, активный, исчерпанный, срок действия истек, приостановленный и сбой. Не делайте вывод об успехе только потому, что запрос API вернулся без ошибок.
Безопасная активация и данные клиента
Коды активации, QR-данные, идентификаторы клиентов и учетные данные API требуют соответствующего контроля доступа. Избегайте записи секретов в журналы или аналитику. Используйте кратковременные учетные данные там, где это поддерживается, разделяйте рабочую и тестовую среды и чередуйте ключи.
Базовый сертификат eSIM и экосистема обеспечения соответствуют спецификациям GSMA. Ваша интеграция по-прежнему требует безопасности на уровне приложений, контроля конфиденциальности и обработки инцидентов.
Тестирование и запуск
Создавайте тестовые сценарии для повторяющихся запросов, тайм-аутов, задержек веб-перехватчиков, недостаточного баланса, недоступных планов, успешных платежей с ошибкой подготовки, ошибок пополнения счета, возврата средств и эскалации поддержки. Добавьте идентификаторы корреляции и информационные панели перед началом работы.
Запускайте с контролируемым объемом, ежедневно сравнивайте заказы с записями платформы и определите, кто может остановить продажи, если возникнет проблема с исходным кодом. Хорошая интеграция — это рабочий процесс, поддерживаемый кодом, а не только кодом.
Вопросы и ответы
Что такое идемпотентность в API заказа eSIM?
Это означает, что повторная попытка одного и того же логического запроса не приводит к созданию нескольких профилей или платежей. Используйте стабильный ключ идемпотентности и сохраните результат.
Что следует использовать: веб-перехватчики или опросы?
Веб-перехватчики обеспечивают более быстрое обновление, а опрос может поддерживать восстановление и согласование. Многие надежные интеграции используют оба.
Что никогда не следует регистрироваться?
Избегайте регистрации секретов API, полных кодов активации, полезных данных QR, платежных данных и ненужных личных данных.