Refunds
Atlas API refund flow for refund quotation, refund submission, and refund status tracking.
Use this section for the full refund lifecycle.
Start here when you need to:
decide whether the case should use Refund or Void
follow the standard refund sequence
confirm which identifiers to keep for follow-up
FAQ
What is the standard Atlas API refund flow?
The standard flow is refundQuotation.do → refund.do → queryRefundOrders.do.
Start with quotation before submission.
When can a refund request fail even before submission?
Refund requests can fail when ticketing is not complete, the refund offer expired, the order number is wrong, or the itinerary is incomplete.
Check current order state and refund conditions first.
When should I use Refund instead of Void?
Use Refund when the case is outside the void window or needs the refund flow.
Use Void when the order is still eligible for the dedicated void flow.
Typical flow
What should you confirm before refund submission?
Confirm:
the original
orderNois correctticketing is complete when required
the itinerary in the refund request is complete
the latest
refundOfferIdor quotation result is still valid
The refund path and reconciliation timing can also depend on the payment mode.
Maintain order status
A successful refund request does not update your order status automatically.
Use the refund status to maintain the order status in your system.
Use this page when you need
voluntary refunds
involuntary refunds
refund status follow-up
What this page does not cover
This page does not list full endpoint schemas or field-level definitions.
Use the API reference for request and response details.
Full API reference
Use endpoint-level details here:
Related pages
Last updated
Was this helpful?

