Travel Insured Partner Documentation

The GraphQL schema and canonical collections show two completion patterns. Use one approved pattern for a transaction; do not combine completion paths.

Choose the Pattern

Pattern	Verified operations	Best fit	Completion
Streamlined single-trip purchase	`quote` then `purchasePolicy`	Partners approved to submit the supported payment input directly	`purchasePolicy` returns the purchase result
Staged single-trip purchase	`quote`, `stagePolicyPurchase`, embedded payment session	Hosted or deferred payment journey	Embedded payment app processes payment and automatically binds
Staged annual purchase	`annualPlanQuote`, `stageAnnualPolicyPurchase`, embedded payment session	Annual-plan hosted or deferred payment journey	Embedded payment app processes payment and automatically binds

Streamlined Flow

MERMAID


sequenceDiagram
    participant P as Partner server
    participant G as Travel Insured GraphQL
    P->>G: quote
    G-->>P: quoteNumber and products
    P->>G: purchasePolicy
    G-->>P: purchase result

Text equivalent: the partner server requests a quote, selects a returned product, submits the approved purchasePolicy input, and stores the returned purchase result.

Staged Flow

MERMAID


sequenceDiagram
  participant B as Partner browser
    participant P as Partner server
    participant G as Travel Insured GraphQL
  participant H as Embedded payment app
    P->>G: quote or annualPlanQuote
    G-->>P: quoteNumber and products
    P->>G: stagePolicyPurchase or stageAnnualPolicyPurchase
    G-->>P: planGuid
  P->>H: Create payment session for planGuid
  H-->>P: paymentSessionId, embedToken, expiresAt
  P-->>B: Short-lived widget configuration
  B->>H: Submit card in hosted PCI form
  H->>H: Process payment and bind policy
  H-->>B: Payment or policy UX event
  P->>H: Poll session status
  H-->>P: Bound status, planNumber, document links

Text equivalent: quote, stage the selected policy, create an embedded payment session, and capture card data in the hosted PCI form. The embedded payment app processes payment and automatically binds the policy on the backend. The partner reconciles the authoritative policy result without another payment or bind API call.

Carry-Forward Identifiers

Identifier	Verified source	Used by
`quoteNumber`	Quote result	Staging or streamlined purchase input
selected product identifier	Quote result	Purchase choice
`planGuid`	Staging result	Embedded payment-session creation
`paymentSessionId`	Embedded payment-session response	Widget mounting and payment correlation
`planNumber`	Streamlined purchase result or a `Bound` embedded-session status response	Exact `searchPlan` lookup, confirmation, and servicing

Do not call processPayment or policyBindRequest in the embedded journey. The payment app owns payment processing and binding behind the scenes.

Server Authority

Browser callbacks or events may update the customer experience, but they are untrusted input. From the partner backend, poll the payment-session status endpoint documented in the Payment Integration Guide before showing final success or releasing documents.

After payment completes

Only a session response with status: "Bound" and bindStatus: "Bound" confirms completion. It supplies the trusted planNumber and available document links. Treat BindFailed, Failed, Cancelled, and Expired as terminal non-success states and keep all other statuses in progress. Browser events, redirects, and browser-reported transaction identifiers are not authoritative substitutes.

Continue with Error Handling and Retries & Idempotency.