Support escalation

Escalation quality depends on identifiers, not screenshots alone.

Open and follow up a support ticket

In Operator Dashboard → Operator Support (/support-tickets), create a ticket with a subject, category, and description. Choose Technical, Billing, Operations, or Other, and include the sanitized evidence listed below.

Tickets are shared with active staff in your operator account, not with other operators. Support access requires a human staff session; backend API keys cannot read or write these conversations. No additional trading, wallet, or settlement scope is required.

Open a ticket to read Polynion Support replies and send follow-up messages. If Polynion closes a ticket and the issue remains unresolved, reopen it before replying. Use Refresh to retrieve the latest conversation. Closure and reopening are recorded in the ticket history.

Support conversations are separate from end-user support and Polyflight purchase tickets. Operators can create, read, reply, and reopen; Polynion closes tickets. There is no operator-side close action, payment authorization, or wallet-resolution action.

Messages are plain text. Do not paste credentials or unrelated personal data; keep the evidence minimal and redacted.

Subjects are limited to 255 characters; descriptions and replies to 20,000 characters after trimming. Use one conversation per incident and follow up with new evidence instead of creating duplicates. See the dashboard workflow and staff-only API contract.

Always include

• operator name or operator ID
• affected environment
• exact UTC timestamp window
• request path
• HTTP status code
• error code or status message

Include by workflow

Launch issues

• external_user_id
• launch request correlation ID if available in your logs
• returned launch error payload

Trade or redemption issues

• order_id
• trade_id if present
• redemption_item_id if present
• idempotency_key
• balance operation IDs if wallet mutation happened
• market ID and exact external_user_id
• expected versus observed amount and currency; say whether the original wallet outcome is unknown, confirmed applied, or confirmed not applied
• Cash Flow Triage source kind/ID, operation attempt times, and resolution history where available

Polyflight issues

• flight, purchase, ticket, and payment obligation IDs where available
• ticket result separately from wallet/payment status
• effect (win, loss, refund, or compensation), original idempotency key, exact IDR amount, and remote reference
• whether the issue is an unpaid monetary obligation or a zero-amount loss acknowledgement
• terms version, statement period/timezone, adjustment/payment IDs, and export format for settlement disputes

Webhook issues

• event_id
• event_type
• webhook endpoint ID
• webhook delivery ID
• last status code
• last response body sample
• selected product, exact external user/transaction identifiers, incident window, and whether the event has any delivery row
• whether recovery used single replay or historical backfill/bulk resend, selected target IDs, queued result counts, and whether already-sent deliveries were deliberately included

Wallet adapter issues

• sanitized operator-side request/response and ledger evidence, with key, user, direction, amount, currency, and remote reference
• any contradictory echoed fields or timeout/connection errors; separate HTTP success from confirmed ledger effect
• preserve original signed bytes privately if needed; share redacted samples, not bearer/auth headers or credentials

Never send

• raw API bearer tokens
• webhook secrets
• wallet adapter secrets
• private signing keys
• database dumps with unrelated user data

Safe escalation flow

1. preserve the original failure; do not repeat a money mutation to reproduce it
2. collect IDs and UTC timestamps
3. collect minimal sanitized request and response samples
4. note whether issue is deterministic, intermittent, or already recovered
5. include what changed before failure: key rotation, webhook secret rotation, config patch, deploy, or receiver release

Fastest route to resolution

• include one concrete failing example
• include one known-good example from same environment if available
• state whether money movement may be affected
• state whether webhook replay already attempted

Copyable incident template

Environment / product:
Operator / exact external user ID:
UTC incident window:
Request path / HTTP status / error:
Order, redemption, market, or flight/purchase/ticket/obligation IDs:
Wallet operation / original idempotency key / remote reference:
Expected amount / observed ledger effect / currency:
Event / endpoint / delivery IDs and last attempt:
Replays, resends, or manual actions already taken:
What changed before failure:
Sanitized evidence and remaining impact:

If dashboard login itself is unavailable, use the onboarding incident contact and the same evidence template. Never send a password, session token, API key, or secret to restore access.