Glossary

Airline-industry terms and Deal Engine–specific terms used across this documentation, in one place, with the disambiguations that readers most often trip over called out explicitly.

Alphabetical. Each entry links to the page where the term is defined or used in context.

ACM (Agency Credit Memo): a credit memo an airline issues to a travel agency, for example to reverse or correct an ADM (see the next entry). Standard BSP/ARC industry term, not itself queryable through the Deal Engine API today.

ADM (Agency Debit Memo): a debit memo an airline issues against a travel agency, typically for a fare, ticketing-rule, or commission discrepancy found after issuance. Standard BSP/ARC industry term, not itself queryable through the Deal Engine API today.

ARC (Airlines Reporting Corporation): the settlement and reporting body between airlines and travel agencies in the United States; the North American counterpart to BSP. See Refunds API.

ARP: the value observed on the product field of a refund candidate (as in "product": "ARP"), identifying Deal Engine's automated refund platform as the producing product. The full value set of product is not published. See Status & error reference.

BSP (Billing and Settlement Plan): the IATA settlement layer between an airline and an agency. See Refund amounts & reconciliation.

BSPLink: IATA's web platform through which airlines and agencies interact with BSP (refund applications, ADMs/ACMs, reporting). Standard industry term; BSP settlement is outside the scope of the Deal Engine refunds product. See Refunds API.

Calculation engine: see Engines, the four.

Chargeback: a reversal of a card payment initiated by the cardholder through their bank, distinct from a refund initiated by the airline. This documentation does not describe a procedure for handling a chargeback that arrives after a Deal Engine refund has executed; see Operations runbook §5 for the open question.

Commission recall: recovering the agency commission originally paid on a ticket when that ticket is refunded. Whether Deal Engine recalls commission on refund, and whether the document's total refund amount (gross, per Refund amounts & reconciliation) already accounts for any recall, is not currently documented.

Conjunction ticket: a continuation ticket used when an itinerary has more segments than fit on one ticket document. Read-only context in Deal Engine responses; the refund is always keyed to the requested ticketNum, and a conjunction ticket needs no separate handling. See Request parameters.

Coupon: the unit of a ticket corresponding to one flight segment, carrying its own status in the airline's PSS. Refundability is evaluated per coupon, not per ticket. See Refund lifecycle & statuses §3.

Decision: the outcome Deal Engine's calculation engine attaches to a quote: VOLUNTARY, INVOLUNTARY, IRREGULAR OPERATIONS, VOLUNTARY MILES, or REJECTED (customer configuration may add variants). Drives what action to take next. See Refund lifecycle & statuses §4.

Decision node: an optional checkpoint Deal Engine can insert between the calculation engine and the fulfillment engine, letting a client decide whether to continue with (or stop) a refund before it executes. See High level diagram.

Document: the core record of a travel document (typically an airline ticket) tracked by the platform: identifiers, itinerary, pricing elements, and status. The anchor entity that a Quote and a (refund) Request both link back to. See What is a document?

EMD (Electronic Miscellaneous Document): a document for ancillary services (seats, baggage, and similar), as distinct from an e-ticket for flights. Deal Engine determines whether a document is really an EMD from PSS data (the presence of an RFISC), not from the client-supplied isEmd flag. See Request parameters.

Engines, the four: the four processing stages that make up the Deal Engine refund solution: the Request engine (receives refund requests from the API, UI, PSS queues, settlement systems, bulk/SFTP, or CRM), the Validation engine (separates valid from invalid requests against industry standards and customer rules), the Calculation engine (computes the exact refundable amount; fare, taxes, penalties, admin fees, FX, guardrails), and the Fulfillment engine (executes the refund, cancels the reservation, and changes the coupon status). An optional decision node sits between the calculation and fulfillment engines. See High level diagram.

Fare basis: the code identifying the fare rules, booking class, and fare family applicable to a priced segment (for example IOWSFXFR). Appears on refund-candidate segment data. See API usage & integration.

FoP (Form of Payment): how the ticket was originally paid (card, cash, miles, and similar), which normally determines how the refund is returned. Exposed on quotes as the opt-in fopInfo[] breakdown: fopType identifies the payment type, brand and cardNumber apply to card payments (for credit cards, only the last 4 digits of the card number are returned), plus amount and currencyCode per form of payment; this per-line breakdown is what lets mixed payments (for example miles + cash) be represented as separate entries rather than a single aggregate. Many tenants receive aggregate amounts only. See Refund amounts & reconciliation.

FSD (Functional Specification Document): the per-customer specification aligned between Deal Engine and the airline during onboarding/PoC, recording the in-scope refund scenarios, coupon-status mappings, decision values, and regulatory configuration for that customer. See Onboarding & prerequisites.

Fulfillment: the execution stage of a refund: the fulfillment engine submits the refund to the PSS, cancels the reservation, and updates the coupon status, writing the terminal REFUNDED/ERROR outcome. In a synchronous quote response the corresponding section is keyed refundCandidateFulfillment; the bare name fulfillment appears as an updateQuote input field, not as a response key. See Refund lifecycle & statuses §1.

GDS (Global Distribution System): a global network (Amadeus, Sabre, Travelport, and similar) that distributes travel inventory and enables real-time booking across airlines and agencies, as distinct from an airline's own host system. See PSS vs GDS below for the disambiguation, and API usage & integration.

Guardrails / cross-check process: a verification step named in the calculation and fulfillment engines' descriptions (High level diagram) that cross-checks computed amounts before execution. Its mechanics and any exposed result are not currently documented.

Interline / codeshare: industry terms for tickets involving more than one carrier: interline when one airline's ticket includes flights operated by another under a bilateral agreement, codeshare when a flight is sold under one carrier's code but operated by another. Whether and how Deal Engine handles refunds for interline/codeshare tickets is agreed per customer in the FSD; supported when the needed information is available in the PSS.

IROPS (Irregular Operations): industry shorthand for an operational disruption (schedule change, cancellation, and similar). Appears in Deal Engine as the IRREGULAR OPERATIONS decision value. See Refund lifecycle & statuses §4.1.

Manual refund: a refund executed outside Deal Engine (or with hand-entered figures) and recorded via the manuallyRefunded flag and manualTotalAmount, which take precedence over automated values when set. Exact precedence semantics and the write path for these fields are open questions; see Refund amounts & reconciliation and Operations runbook §6.

Marketing carrier vs. operating carrier: the airline whose code the flight is sold under (marketing, exposed as marketingAirlineCode on segment data) versus the airline that actually operates it. See API usage & integration, and Interline / codeshare above.

Metabase: the BI tool through which Deal Engine provides reporting dashboards for refunds and transactions. See BI & reporting.

NDC (New Distribution Capability): IATA's XML-based airline distribution standard; one of the systems Deal Engine's request engine can connect to alongside PSS, GDS, BSP, and ARC. See Refunds API.

No-show: a passenger who held a confirmed booking but did not travel and did not cancel; fare rules often reduce or remove refundability for no-show coupons. Surfaces as the isNoShow flag on segment extraParams. See API usage & integration.

NUC (Neutral Unit of Construction): IATA's currency-neutral unit used in international fare construction; amounts in NUC are converted to a real currency using the ticket's ROE (see below). Appears as currencyCode: "NUC" inside currencyExchangeDetails.input on segment data.

OnePoint: Deal Engine's web user interface, used to configure roles, manage users, and (for permitted roles) create quotes and process refunds directly rather than through the API. See Role & user guide.

⚠️
Disambiguation; "Open"
Open (coupon status); the O / OPEN normalized-or-long-form status meaning a coupon is unused on an already-issued, dated ticket. See Refund lifecycle & statuses §3.1.
Open ticket (industry sense); an undated, unflown ticket held for exchange against a future flight. This is a different concept from the O/OPEN coupon status above, and this documentation does not state whether Deal Engine supports refund handling for it.

PCC (Pseudo City Code) / Office ID: the GDS or PSS identifier for the specific agency office or point of sale that a transaction is executed under. GDS refund transactions are typically executed under a specific PCC or office ID, which determines who is accountable for the transaction in the GDS's own audit trail and who absorbs any GDS transaction fee.

PNR (Passenger Name Record): the digital record of a passenger's booking: flights, details, and services. See API usage & integration.

⚠️
Disambiguation; "PSS vs GDS"
PSS (Passenger Service System); the airline's own reservation/host system, which holds the ticket and performs the refund. See Refund amounts & reconciliation.
A PSS and a GDS are not the same thing: a PSS is an airline host system; a GDS is a distribution system used when the ticket is held outside the airline's own host (Amadeus, Sabre, Travelport, and similar), in which case the GDS performs the refund instead. Several pages in this documentation mark this distinction with a no-term-swap note, because elsewhere the docs may render "GDS" in place of "PSS" for agency readers; a terminology substitution, not a claim that the two are interchangeable. See Request parameters and Refund amounts & reconciliation.

Q fare / Q surcharge: a carrier-imposed surcharge embedded in the fare construction (labelled with Q in the fare calculation line), commonly a fuel or similar carrier surcharge, expressed in NUC during construction. Referenced in the OnePoint refund-candidate view, not itemized in the documented API amount tables. See YQ / YR below for the tax-code counterpart.

Quote: the pricing evaluation for a ticket's refundability: computed amounts (refundable fare, taxes, penalties), a decision, and audit fields. Produced from a Document's data by createQuote and may be revised with updateQuote. See What is a quote?

RA (Refund Application): the standard BSP/ARC document type an agent submits to process a refund through the settlement system, as distinct from a void (see Void vs. refund below). Standard industry term, not itself queryable through the Deal Engine API today.

Refund candidate: the record createQuote produces once a quote exists: amounts plus a decision, tracked through its own status (NEW, REVIEW, READY, REFUNDED, ERROR). REVIEW means the quotation needs customer-side validation (for example a purged reservation or private fare rules) before it can proceed. See Refund lifecycle & statuses §2.

Reissue / exchange: the process of replacing a ticket with a new one (fare or itinerary change). Deal Engine tracks the link via parentTicketNum (the previous ticket in the exchange/reissue chain), used internally for correct refund math; a coupon status of E routes through reissue-chain handling. See Request parameters.

Request: the refund/document-tracking type described in What is a request?, exposed via a top-level field literally called requests and keyed by ticketNum. Captures who requested a refund, when, and how it was processed, linked back to a Document.

Request engine: see Engines, the four.

RFISC (Reason for Issuance Sub-Code): the code on an EMD identifying which ancillary service it was issued for. Deal Engine uses its presence in PSS data to detect that a document is really an EMD, regardless of the client-supplied isEmd flag. See Request parameters.

ROE (Rate of Exchange): the fare-construction currency conversion rate used to convert an amount from NUC (Neutral Unit of Construction) into a settlement currency. Appears as the roe field alongside currencyExchangeDetails on refund-candidate segment data. See API usage & integration.

Rudder / RUDDER_TS: an internal Deal Engine component referenced as the source of tax adjustments (notably AMOUNT_RECONCILIATION, which restates tax line amounts) and as the invokeRudder flag on quote refundability data. Its rules and the pre-adjustment values are not exposed.

Safe / not-safe quote: the isSafeForRefund flag and safeBadge on a quote, surfaced in OnePoint as "Quote type: safe / not safe". What makes a quote "safe" (presumably passage of the guardrails cross-check) is not currently documented.

⚠️
Disambiguation; "Sandbox"
Apollo Sandbox; the GraphQL IDE you type queries into (schema explorer, editor, headers panel). See How to test in other environments.
Deal Engine sandbox; the separate test environment, with fulfillment disabled, used to validate an integration before go-live. See Testing & environments.
The two are unrelated: one is a tool, the other is an environment. See Getting started for the explicit statement of this distinction.

Segment: one flight within an itinerary; each segment carries one or more coupons. See Refund lifecycle & statuses §3.

Terminal status: a status a record never leaves once reached. A refund candidate's status moves through NEW, REVIEW, and READY before reaching one of the two terminal statuses, REFUNDED or ERROR; terminal statuses are set by the engine only and never transition again. Pollers should stop on a terminal status. See Refund lifecycle & statuses §2.

Validation engine: see Engines, the four.

Void vs. refund: a void cancels a ticket transaction within a short, airline-defined window (often same-day), reversing the sale with no refund process needed; a refund returns money for a ticket after that window, through the standard refund flow and subject to fare rules and penalties. This documentation does not describe Deal Engine's own void-window mechanics or how a void is requested or detected distinctly from a refund.

Waiver: an exception granted by the airline that overrides normal fare rules or penalties for a given ticket. Adding or removing a waiver is a "material" quote change that should be submitted with requote: true. See API usage & integration.

YQ / YR: IATA tax/fee codes for carrier-imposed surcharges (for example fuel or other carrier-assessed amounts), as distinct from government-imposed taxes. YQ appears as a taxCode on refund-candidate tax lines; YR is referenced as a fuel surcharge in rejection-rule examples. See API usage & integration and Refund lifecycle & statuses §4.2.