Краткий ответ
Как тестировать вебхуки PayPal локально с Oxaa дает прямой ответ, точное описание поведения продукта, важные для решения ограничения и практический путь проверки.
Это руководство подключает реальный тестовый запрос от PayPal к локальному коду. Публикация допускается только после теста в контролируемом sandbox, проверки актуальных официальных источников и назначения владельца поддержки.
Пошагово
- Подготовьте sandbox или тестовый аккаунт, тип события, secret и минимальный локальный handler.
- Запустите handler и проверьте детерминированный health route.
- Установите/войдите в Oxaa, выполните
oxaa http <port>и дождитесь edge-ready. - Скопируйте точный HTTPS URL и path в актуальную настройку провайдера.
- Вызовите реальное тестовое событие.
- Подтвердите delivery провайдера, метаданные Oxaa и ответ локального handler.
- Проверьте raw body/подпись, timestamp, retry и trusted proxy.
- Включайте ограниченный локальный capture только при необходимости; маскируйте и удаляйте чувствительные данные.
- Используйте replay Oxaa только для подходящих запросов; если нужны свежие timestamp/token, запросите provider redelivery.
- Удалите callback, смените test secret, удалите capture и переведите production на развернутый endpoint или event platform.
Проверка, специфичная для PayPal
Настройте актуальный webhook или callback PayPal с точным URL и путем Oxaa. Вызовите реальное тестовое событие и проверьте delivery record провайдера, метаданные запроса Oxaa и ответ локального приложения. Production-руководство должно проверить transmission headers, проверку события и sandbox mode.
Как обрабатываются трафик и данные Inspector
На публичном edge завершается публичный TLS, чтобы Oxaa мог определить точный hostname, найти текущий аутентифицированный маршрут и переслать запрос. Сессия между зарегистрированным устройством и Oxaa зашифрована; по ней запрос попадает только в выбранный локальный сервис.
Oxaa хранит ограниченные метаданные аккаунта, маршрута, использования, безопасности, оплаты, поддержки и диагностики, необходимые для работы и защиты сервиса. Capture body в Inspector — отдельное, явно включаемое действие отладки: ограниченная копия request или response body, показанная локальным Inspector, остается на устройстве разработчика и может быть замаскирована, немедленно удалена или автоматически истечь. Публичный трафик все равно обрабатывается на edge; корректная формулировка — «копии Inspector остаются локально», а не «Oxaa не видит трафик».
Устранение неполадок
Сначала проверьте локальный процесс, порт и scheme. Затем — аутентификацию и часы, DNS, UDP/443, fallback на TCP/443, корпоративный proxy или перехват TLS, владение маршрутом и edge-ready. Используйте oxaa routes list, oxaa diagnose --network и стабильные error ID; перед отправкой диагностики удалите secrets, body и приватные пути.
Очистка и переход к production
Удалите внешний callback, preview URL или DNS-привязку; смените тестовые секреты; удалите локальные capture; остановите маршрут и при необходимости отзовите устройство или сессию. Production-трафик следует перевести на развернутое приложение, production ingress или специализированную платформу доставки событий.
Что такое Oxaa — и чем он не является
Oxaa — это соединение для разработки с выбранным локальным HTTP/HTTPS-сервисом, пока зарегистрированное устройство и аутентифицированный маршрут активны. Это не хостинг, не универсальный VPN, не forward proxy, не постоянный production-деплой, не raw TCP/UDP-туннель, не произвольный TLS passthrough, не замена CDN/WAF и не платформа production-доставки вебхуков.
Выполните следующий реальный шаг
Переходите к Получить первое событие PayPal, только если текущий продукт, тариф и страна поддерживают это действие. Через Выбрать руководство провайдера заранее проверьте точный технический путь, доказательства доверия или варианты поддержки.
oxaa login
oxaa http 3000