ENTR
← Log viewer

Android WebView logging and Paytm handoff

Version 1 · metadata only · machine-readable JSON schema

Transport

POST https://namepractical.pro/v1/mobile-events
Content-Type: application/json
Authorization: Bearer <INGEST_TOKEN>

The ingestion token is provided separately. It cannot access the log viewer. Allowed app IDs: com.artworkss.ais.epaq and com.worksphoto.artaipic. Maximum: 50 events and 64 KiB per request; 120 requests/minute per token. HTTPS with certificate verification is required.

Example request

{
  "schema_version": 1,
  "app_id": "com.artworkss.ais.epaq",
  "app_version": "1.0.1",
  "android_api": 35,
  "webview_version": "133.0.6943.137",
  "device_model": "Pixel 8",
  "session_id": "e75ff110-0124-42a4-8cd7-ec25cfc63bd2",
  "test_event": false,
  "events": [{
    "event_id": "9602f264-829b-45b3-b278-7f1f4955a77d",
    "seq": 1,
    "at": "2026-10-05T12:00:00Z",
    "event": "external_launch_failed",
    "level": "error",
    "source": "native",
    "window_id": "root",
    "attempt_id": "d7954010-0a66-428a-89c6-f26a760aa881",
    "scheme": "paytmmp",
    "route": "external_payment",
    "data": {
      "error_code": "ActivityNotFoundException",
      "reason": "app_not_installed",
      "is_user_gesture": true
    }
  }]
}

Use the actual current UTC timestamp with timezone, not the example date. Session IDs and attempt IDs are random UUIDs, never user identifiers. seq increases within a session. Assign a UUID to each event once; retries must preserve the entire event and batch context.

Events and Android callbacks

Optional context: window_id, parent_window_id, attempt_id, scheme, host, route. host is hostname only; route is a fixed label such as checkout, never a URL path. All accepted fields, types, limits and enum values are in the schema. Unknown fields are rejected.

Delivery and response

Use a durable local queue, send asynchronously from native networking, flush every 5–10 seconds or 20 events, and attempt immediate flush for critical errors. Do not block WebView navigation. Cap queue at 1,000 events / 2 MiB and remove entries older than 7 days; track dropped event counts locally.

{"accepted_event_ids":["…"],"duplicate_event_ids":[],"received_at":"…"}

HTTP 200 confirms the batch was committed to storage. Delete only IDs listed in either acknowledgement array. Retry network errors, 429 and 5xx using exponential backoff with jitter (1 second → 5 minutes), honoring Retry-After. Do not automatically retry 400/401/403/409/413/415/422; surface integration errors and split oversized batches before sending. Same app + same event UUID + identical payload is idempotent; changed payload returns 409 and the entire batch is rolled back. Deduplication lasts while the event is retained (30 days).

Data boundaries and acceptance

Never send full URLs, query strings, fragments, cookies, authorization headers, request/response bodies, card numbers, CVV, names, email, phone, payment identifiers or raw console text. Use fixed reason codes and random correlation UUIDs. This receiver collects client diagnostics; actual payment success must come from the payment provider's authenticated webhook/backend and be correlated there using attempt_id.

Validate root and popup flows, Paytm installed/absent, return/cancel, renderer failure, Activity recreation, offline queue delivery, duplicate retries, and 3DS. Mark integration tests test_event: true. Logs are kept 30 days; local backups are retained 7 days. A backup on this same server does not protect against complete server loss.

Paytm: “click here to pay” on Android smartphones

Confirmed defect: the audited APK catches an external ACTION_VIEW failure and returns false. WebView then loads paytmmp://… and shows ERR_UNKNOWN_URL_SCHEME. Missing Paytm and incorrect failure routing are separate conditions; neither proves a PSP payment outcome.

  1. Use one navigation router in every root/popup WebView and in app-owned navigation entry points. Keep normal HTTP(S) navigation in WebView. Do not rewrite payment parameters or convert Paytm links to another payment scheme without a verified provider contract.
  2. For an approved Paytm link from trusted checkout, launch Intent.ACTION_VIEW with CATEGORY_BROWSABLE; handle ActivityNotFoundException and SecurityException explicitly. Return true for external/blocked schemes on success and failure so custom URIs never enter WebView. Normal web navigation returns false.
  3. If no handler exists, log external_launch_failed with reason: no_handler and the exception class. Use only an existing, validated provider-approved HTTPS fallback. If none exists, preserve checkout and offer another payment method or installation of Paytm. Do not invent a Paytm web URL or silently return to the offer start page. A missing handler is not necessarily proof that the app is uninstalled.
  4. For intent://, use Intent.parseUri(..., URI_INTENT_SCHEME), enforce allowed action/scheme/package, clear component/selector, reject unsafe flags/extras, and validate browser_fallback_url. Android package visibility can affect resolveActivity; do not treat a null result as proof of app absence. Declare specific queries if preflight/package checks are required.
  5. Preserve the originating checkout window, parent/child ownership and attempt_id through launch, Back, return and Activity recreation. Log requested → dispatched → background/resume/return. Do not reload checkout, re-submit payment or mark payment success on app resume. The PSP backend/webhook remains authoritative.
  6. shouldOverrideUrlLoading does not cover POST or the app's own loadUrl calls. Verify the actual CTA and redirect chain, and route owned navigation explicitly. Never replay a payment POST. Permit only approved providers from trusted checkout context; legitimate redirects may have no immediate user gesture.

Acceptance: test the actual in-app CTA on physical Android smartphones with Paytm installed/absent; root and popup; approved fallback/no fallback; success/decline/cancel/Back; background/resume and Activity recreation. No unknown-scheme error, lost checkout, replayed payment or success inferred from app launch is allowed. Cover supported Android versions including Android 11+ package visibility. Desktop and ordinary Chrome are not substitutes.

Delivery phases: (1) capture sanitized CTA/redirects and agree provider/origin/fallback contracts; (2) implement the shared router and correlated logging together; (3) validate the smartphone matrix using client traces and provider outcomes. APK changes and real Paytm acceptance are not yet validated.

Official references: WebViewClient, Android package visibility, intent URI / fallback format.