Onboarding & prerequisites

This page answers the question integrations keep hitting first: what does Deal Engine need from us before anything can work? It covers what to gather before you start, who on your side is responsible for what, the phase sequence from first access to go-live, how to get test data, and how to confirm the specific rule configuration active on your account.

Nothing here overrides your commercial or security agreement with Deal Engine; where a detail isn't yet documented, it's marked FACT-NEEDED rather than guessed.

---

What is the FSD?

You'll see "FSD" (Functional Specification Document) referenced throughout this page and elsewhere in this documentation. It's the per-customer specification aligned between Deal Engine and your airline during onboarding/PoC. It records:

• which refund scenarios are in scope for your account,
• your coupon-status mappings; which coupon states count as open vs. flown,
• your decision values,
• your regulatory configurations (e.g. EU261, US DOT), and
• your validation and rejection rules.

Wherever another page in this documentation says "confirm with your FSD" or "your active configuration," this is the document it means.

---

1. What Deal Engine needs from you

Deal Engine connects to your ticketing environment rather than replacing it. The exact credentials depend on which systems you use; see Supported systems for the full list (Amadeus Altea, Sabre Sonic, or your own PSS; Amadeus/Sabre/Travelport GDS; NDC providers; BSPLink/ARC settlement).

Identity & routing data

Requests are keyed on ticket number, but routing and ownership fields are read from your PSS and can also be supplied on the request; see What is a request? and API usage & integration:

• gds: which GDS holds the record, when applicable.
• iataCode: the IATA identifier for the airline/agency the ticket was issued under.
• travelAgencyId: the issuing or servicing agency identifier.
• pnr: the booking record locator.

Network access

Webhook endpoint

To receive refund_request.status_updated and refund_candidate.status_updated events, you supply:

• An HTTPS endpoint URL, reachable from the internet; see Webhooks.
• An authentication choice: HMAC signature (recommended) or static API key; see Webhook API Reference. Either can use a Deal Engine–generated secret or one you provide.

Account & API access

• Account creation and initial credentials come from your Deal Engine account manager; see Getting started.
• Authentication uses JWT (login mutation → access + refresh token); see Authentication & authorization.
• Environment names, URLs, and how to request Sandbox access are canonicalized in Environments & access; including the full US/EU × Production/Sandbox endpoint matrix.

Which credentials come from whom

---

2. Who does what

A RACI-style view across your organization and Deal Engine. Complexity is a rough indicator of how much cross-team coordination a step needs; not a time estimate.

R = Responsible, A = Accountable, C = Consulted, I = Informed. Rows are illustrative based on what's documented elsewhere in this corpus; confirm actual ownership with your Deal Engine account manager.

---

3. Phase sequence

Each phase has an entry condition (what must be true to start) and an exit condition (what must be true to move on). Decision-rule configuration is called out as its own phase because rejection rules, the non-refundable coupon-status list, and decision values are all configured per customer; see Refund lifecycle & statuses; so this phase genuinely requires your input, not just Deal Engine setup. The output of this phase is captured in your FSD; see What is the FSD? above.

Phase 1: Access

• Entry: Commercial agreement in place; Deal Engine account manager assigned.
• Exit: You have login credentials, can authenticate via the login mutation, and can reach the GraphQL playground for the Sandbox environment; see Getting started and Environments & access. The Quickstart walks the full authenticate → quote → refund path once you're through this phase.

Phase 2: Connectivity

• Entry: Phase 1 complete.
• Exit: Deal Engine can read a known ticket from your PSS; i.e., a createQuote call against a real or seeded test ticket successfully returns data rather than a connection/lookup error.

Phase 3: Quote validation

• Entry: Phase 2 complete; test tickets available (see Section 4).
• Exit: Quote amounts (fare, taxes, penalties, admin fees) for your test tickets match your independently calculated expected values, across the ticket scenarios you and Deal Engine agreed to cover.

Phase 4: Decision-rule configuration

• Entry: Phase 3 complete.
• Exit: Your rejection rules, non-refundable coupon-status list, decision values, and regulatory configuration (e.g. EU261, US DOT) are aligned and recorded in your FSD, configured in the rule engine, and test tickets produce the decision (VOLUNTARY, INVOLUNTARY, REJECTED, etc.; see Refund lifecycle & statuses) you expect for each rule, including at least one deliberate rejection case.

Phase 5: Webhook integration

• Entry: Phase 4 complete.
• Exit: Your endpoint receives and correctly verifies both event types for non-terminal status changes, and handles duplicate delivery idempotently; see Webhooks and Webhook API Reference.

Phase 6: UAT

• Entry: Phase 5 complete.
• Exit: A full end-to-end pass (quote → candidate → READY) is exercised per Testing & environments, and a coordinated test report is produced and reviewed with your Deal Engine contact.

Phase 7: Go-live

• Entry: Phase 6 sign-off obtained.
• Exit: Production cutover complete; a first controlled live refund reaches REFUNDED (or a handled ERROR) and reconciles correctly. This first live refund is the first end-to-end proof of fulfillment (Sandbox cannot execute refunds) so plan it as a supervised canary with your Deal Engine contact on standby.

---

4. Test data

Testing & environments confirms that Deal Engine provides sample data and test tickets before go-live. During the PoC, your team assembles a set of sample tickets covering the scenarios you need certified; for example fully open, partially open, government fares, staff fares, and miles/award tickets, plus any other scenario relevant to your operations. These are usually sourced from your sales team or the airline's internal refund department, since they're best positioned to locate real (or representative) tickets covering each scenario.

---

5. Your active configuration

Several behaviors are per-customer and configured on request rather than fixed defaults. All of the below are recorded in your FSD (see What is the FSD? above); confirm each with Deal Engine (via your account manager or Support) rather than assuming the default:

• Rejection-signal mode: whether rejections surface only via notes + a 0 refund amount (default) or via an explicit REJECTED quote status; see Refund lifecycle & statuses §4.2.
• Non-refundable coupon-status list: the default is documented in Refund lifecycle & statuses §3.2, but your agreed configuration is the source of truth.
• FoP distribution: whether Quote.fopInfo[] per-form-of-payment breakdown is enabled, or you receive aggregate amounts only; see Refund amounts & reconciliation.
• Decision values: the standard set plus any customer-specific variants (e.g. VOLUNTARY_BEFORE_DEPARTURE); Deal Engine provides your active list at onboarding per Refund lifecycle & statuses §4.1.
• Regulatory configuration: e.g. EU261, US DOT; which regulatory regimes apply and how they're enforced is configurable per customer.