Staging overview

Staging exists to validate integration behavior before production with same docs, same paths, same request and response shapes.

Single source of truth

• operator API paths stay same
• wallet adapter paths stay same
• webhook payloads stay same
• dashboard concepts stay same

The production integration contract is the same, but staging has additional simulator-user and test-receiver routes. Their presence does not change normal users' real wallet routing. Feature enablement, operator permissions, credentials and retained data are environment-specific; repository support does not certify that an operator/environment is provisioned or ready.

Do not maintain separate staging implementation docs.

What to validate in staging

• launch Opinion and Polyflight through their real product selections
• user can view Opinion markets
• Polyflight user can view the shared board and submit native IDR
• Opinion buy/sell or redemption works
• Polyflight win, loss, cancellation/refund, compensation, and manual-review states work
• webhook receiver verifies signatures and accepts both product catalogues
• webhook retries behave as expected
• duplicate idempotency is safe
• failure and unknown wallet states are visible to operator
• Polyflight terms, statement, liability, payment history, and export views reconcile

Evidence to collect

• API request and response samples
• wallet adapter logs keyed by idempotency_key
• webhook receiver logs keyed by event_id
• operator dashboard screenshots for failed or replayed deliveries
• timestamps in UTC for each drill

Keep evidence operator-scoped and remove bearer/signing secrets, launch URLs/tokens and session credentials before sharing. Redacted dashboard evidence is bounded and can omit headers or unknown fields; a blank/withheld value is not evidence that the original request lacked it.

Required drill order

1. create/select a dedicated simulator-tagged user under Operator Dashboard /simulator/users
2. fund only that user's simulated IDR wallet; leave operator rest_v1 configuration unchanged
3. launch polyflight from dashboard /simulator and follow the real single-use launch URL
4. validate native purchase and win/loss/refund/compensation states in the launched Mini App
5. validate Opinion separately
6. validate wallet failure and webhook retry/replay drills
7. reconcile wallet operation, event, statement, and export evidence in dashboard/admin views
8. run separate real-HTTP adapter contract checks against dedicated non-production wallet infrastructure

The dashboard-hosted simulator exercises the OpenPoly UI/session/state-machine path when those drills are actually completed. It does not certify a real external operator wallet, and API-only requests or injected cookies do not replace the launched-client workflow.

Integration UAT versus simulator

Integration UAT (/integrations/uat) is not staging-only. Check its environment badge before acting; ordinary users use the saved real wallet adapter. Run safe UAT checks performs one balance lookup and checks saved active subscriptions for the selected product. It does not send a callback or exercise purchase/payout logic.

The saved-config check requires both wallet_adapter:read and wallet_adapter:write; write scope does not imply read. webhooks:read is required for subscription readiness. Launch requires launch:write. Polyflight ticket evidence requires polyflight:read + polyflight_terms:read; Polyflight wallet evidence requires polyflight:read + balance_operations:read; callbacks require webhooks:read + polyflight:read. See current UAT permissions.

The UAT result is not a production sign-off. Correlate the product source, wallet's original idempotency key and public callback event_id; receiving a callback does not prove a separate wallet effect.

Related pages

• simulator tools: /docs/testing-and-staging/simulator
• webhook drills: /docs/testing-and-staging/webhook-drills
• wallet failures: /docs/testing-and-staging/wallet-failure-drills