Mobile WebViews
Open hosted 0Gate flows from native iOS or Android containers without moving secret-key work into the app.
Mobile apps should keep the same trust model as web integrations: the native app asks your backend for a session, receives only browser-safe values, opens a hosted 0Gate surface, and waits for your backend to confirm the signed event.
Recommended architecture
Use a secure browser surface or hosted WebView that can complete the 0Gate page, then return through an HTTPS universal link or app link. Your app should query your backend for the final order state after return instead of trusting the return URL alone.
Implementation checklist
| Area | Requirement |
|---|---|
| Session creation | Server-side only, with sk_*, idempotency, and your order reference. |
| Mobile launch | Open hosted redirect with pk_* and client_secret, not a secret key. |
| Return URL | Use HTTPS universal links or app links where possible. |
| App resume | Show pending while your backend waits for the verified webhook. |
| WebView storage | Avoid persisting secrets, identity data, or raw hosted payloads in mobile logs. |
| Retry | Create a new session for a new attempt after expiry, cancellation, or stale state. |
Mobile states
| App state | Meaning |
|---|---|
opening_hosted_flow | The app has received client_secret and is opening the hosted page. |
waiting_for_user | The user is inside the hosted surface. |
returned_to_app | The hosted surface navigated back to your HTTPS return URL. |
pending_backend_event | The app is waiting for your backend state after webhook processing. |
completed | Your backend verified a terminal event and updated durable state. |
failed_or_cancelled | Your backend recorded a failed, expired, or cancelled attempt. |
Do not put sk_* in mobile apps
Native apps can be inspected. Keep all secret-key operations behind your backend, even when the UX feels like an app-only flow.