Oxaa
Sign inDownload
  1. Localhost. Online. Without opening your network.
  2. Integration guides hub
  3. PayPal local development guide

Secure public endpoints for local development

PayPal local development guide

Configure PayPal, send a real payment event to localhost through Oxaa, verify authenticity, inspect it locally and clean up safely.

Fast answer

This guide connects a real PayPal payment event to the code running locally. It is publishable only after an owned sandbox test, current official-source review and a scheduled maintenance owner.

Step-by-step

  1. Prepare a provider sandbox or test account, event type, secret and minimal local handler.
  2. Start the local handler and verify a deterministic health route.
  3. Install/login to Oxaa and run oxaa http <port>; wait for edge readiness.
  4. Copy the exact HTTPS URL and path into the current provider setting.
  5. Trigger a real provider test event.
  6. Confirm provider delivery, Oxaa metadata and the local handler response.
  7. Verify raw-body/signature, timestamp, retry and trusted-proxy behavior.
  8. Use local bounded capture only when needed; redact and delete sensitive data.
  9. Use Oxaa replay only for eligible requests; request provider redelivery when authenticity depends on fresh timestamps or tokens.
  10. Remove the callback, rotate the test secret, delete captures and move production traffic to the deployed endpoint or event platform.

PayPal-specific verification

Configure the current PayPal webhook or callback setting with the exact Oxaa URL and path. Trigger a real test event and verify the provider delivery record, Oxaa request metadata and local application response. The production guide must validate transmission headers, event verification and sandbox mode.

How traffic and Inspector data are handled

Oxaa's public edge terminates public HTTPS so it can resolve the exact hostname, identify the current authenticated route and forward the request. The session between the enrolled device and Oxaa is encrypted; the selected local service receives the request through that session.

Oxaa retains bounded account, route, usage, security, billing, support and diagnostic metadata required to operate and protect the service. Inspector body capture is a separate, explicit debugging action: the bounded request or response body copy shown by the local Inspector remains on the developer device and can be redacted, deleted or allowed to expire. Public traffic still has to be processed by the edge, so the accurate claim is local Inspector copies-not “Oxaa cannot see traffic.”

Troubleshooting

Start with the local process, port and scheme. Then check authentication and clock, DNS, UDP/443, TCP/443 fallback, corporate proxy or TLS interception, route ownership and edge readiness. Use oxaa routes list, oxaa diagnose --network and stable error IDs; review diagnostic output before sharing it and remove secrets, bodies and private paths.

Cleanup and production handoff

Remove the external callback, preview URL or DNS binding; rotate test credentials; delete local captures; stop the route; and revoke the device or session when appropriate. Move production traffic to the deployed application, production ingress or event-delivery platform designed for that job.

What Oxaa is - and is not

Oxaa is development connectivity for a selected local HTTP or HTTPS service while the enrolled device and authenticated route are live. It is not application hosting, a general VPN, a forward proxy, permanent production deployment, raw TCP/UDP tunneling, arbitrary TLS passthrough, a CDN/WAF replacement or a production webhook delivery platform.