Architecture

Mini App integration has 3 operator-owned backend responsibilities:

• call launch API
• implement wallet adapter
• implement webhook receiver

OpenPoly owns the Mini App UI, Opinion market engine, shared Polyflight engine, execution state, and callback dispatch.

Actors

• operator backend
• operator wallet service
• operator webhook receiver
• OpenPoly operator API
• OpenPoly Mini App client
• OpenPoly execution and webhook systems

End-to-end shape

sequenceDiagram
  participant O as Operator Backend
  participant P as OpenPoly Operator API
  participant C as Mini App Client
  participant W as Operator Wallet
  participant H as Operator Webhook Receiver

  O->>P: POST /api/operator/launch
  P-->>O: launch_url + expires_at
  O->>C: redirect user to launch_url
  C->>P: redeem launch token
  P-->>C: Mini App session
  C->>P: quote and submit Opinion order or Polyflight ticket
  P->>W: exact native debit/credit/reversal as needed
  W-->>P: wallet operation result
  P-->>C: updated order, ticket, or payment state
  P->>H: signed webhook event
  H-->>P: 2xx or retryable failure

Core invariants

• browser never receives operator API key
• browser never receives wallet adapter secret
• launch token is short-lived and single-use
• wallet mutation and Polynion DB write are not one atomic transaction
• webhook delivery happens after business state commit
• Polyflight wallet amounts are native IDR; its frozen FX observation affects shared-flight comparison only
• one operator wallet outage does not change a committed Polyflight result

What operator builds

• server-side launch call
• wallet adapter endpoints
• webhook receiver with dedupe
• dashboard configuration and operational process

What Polynion provides

• Mini App UX
• quote and execution engine
• session and launch token handling
• operator-facing reporting APIs
• webhook dispatch and replay surfaces