ChinaTicket.Online OPEN API Document
  1. Open API
ChinaTicket.Online OPEN API Document
  • Open API
    • flight
      • Flight Shopping
      • Flight Pricing
      • Price validation
      • Create origin order
      • pay an order
      • cancel an order
      • order detail
      • search change solutions
      • request an flight change
      • request an refund
      • confirm to refund the tiekct
    • train
      • Train Stations
      • Train shopping
      • Create train order
      • Order detail
      • Cancel an order
      • Pay an order
      • Intercept an order
      • Refund an order
    • Get Balance
      GET
  • Schemas
    • request
      • request.FlightShoppingRequest
      • request.PayFlightOrderRequest
      • request.ChangeFlightOrderRequests
      • request.CreateFlightOriginOrderRequest
      • request.FlightChangeSearchRequest
      • request.RefundFlightOrderRequest
    • consts
      • consts.CabinClass
      • consts.RefundReason
      • consts.FlightOrderStatus
      • consts.FlightOrderType
      • consts.FlightTicketStatus
      • consts.FlightProductType
      • consts.FlightInvoiceType
      • consts.FlightTaxType
      • consts.PassengerEligibility
    • model
      • model.FlightJourneyCore
      • model.PassengerCountRequest
      • model.ChangeSegment
      • model.PassengerFlightOrder
      • model.ChangeShoppingResult
      • model.ChangeShoppingSegment
      • model.FlightSegmentInfo
      • model.BaggageRule
      • model.BaggageRuleDetail
      • model.FlightCoreSegmentCache
      • model.StopOver
      • model.OrderDetail
      • model.FareRule
      • model.FlightJourney
      • model.FlightSegmentWithCoreSegment
      • model.CoreSegmentDetail
      • model.FlightScheduleChange
      • model.FlightPassengerTickets
      • model.FlightTicket
      • model.PriceDetail
      • model.PriceInFlightOriginOrder
      • model.PriceInFlightChangeOrder
      • model.PriceInFlightRefundOrder
      • model.PriceInFlightVoidOrder
      • model.FlightSolutionResp
      • model.FlightJourneyResp
      • model.FlightPriceDetail
      • model.FlightPrice
      • model.FlightTax
      • model.FlightSolutionLimitation
      • model.FlightLimitAgePair
    • Schemas
      • consts.PassengerType
      • consts.Gender
      • consts.TrainIssueWay
      • consts.TravelDocumentType
      • consts.TrainOrderStatus
      • consts.TrainOrderTicketStatus
      • consts.TrainPassengerStatus
      • consts.TrainRefundStatus
      • dto.PaginationList-array_resp_TrainOrderResp
      • resp.TrainOrderResp
      • resp.TrainOriginTicketDetail
      • req.TrainOrderListReq
      • response.Response-dto_PaginationList-array_resp_TrainOrderResp
      • model.CreateTrainOriginOrderReq
      • response.Response-resp_TrainOrderResp
      • resp.TrainChangeDetail
      • resp.TrainChangeTicketDetail
      • resp.StationDetail
      • model.ShoppingCNTrainStationsResp
      • req.TrainShoppingReq
      • response.Response-array_model_ShoppingCNTrainStationsResp
      • resp.Seats
      • resp.StationInfo
      • response.Response-array_resp_TrainShoppingResp
      • resp.TrainShoppingResp
  1. Open API

flight

Order types and status#

Order types#

We have 3 types of order: origin, change and refund:
origin for original order
change for change order
refund for refund order

Original order#

We have 10 status for original orders:
1.
reviewing
2.
to_be_paid
3.
proceeding
4.
issued
5.
failed
6.
failed_reimbursing
7.
failed_reimbursed
8.
closed
9.
canceled
10.
holding
4ef73c23-0078-48dc-92bb-147b0ed7b93d.png
1.
When an order is created, the system will first verify the validity of the price. If the price is valid, the order will proceed to the "to_be_paid" status. If not, it will enter the "reviewing" stage.
2.
During the "reviewing" stage, our team will manually check the order. If we discover an alternative method for issuing the ticket, the order will be moved back to the "to_be_paid" status. Otherwise, it will be marked as "failed".
3.
While an order is in either the "reviewing" or "to_be_paid" status, users have the option to cancel the order. Once canceled, the order's status will be updated to "canceled".
4.
When an order reaches the "to_be_paid" status, a final payment deadline will be set. If this deadline is not met, the order will automatically transition to the "closed" status.
5.
During the "to_be_paid" status, users may proceed with payment. If the price remains valid, the order will move to the "proceeding" stage. However, if the price is invalid, the order will be marked as "failed".
6.
In the "proceeding" stage, once the ticket is successfully issued, the order's status will update to "issued". If the supplier is unable to issue the ticket, the order will shift to the "failed_reimbursing" status. After the refund process is completed, the order's status will finally update to "failed_reimbursed".

Change order#

we have 11 status for change orders:
1.
chg_reviewing
2.
chg_rejected
3.
chg_to_be_paid
4.
chg_proceeding
5.
changed
6.
failed
7.
failed_reimbursing
8.
failed_reimbursed
9.
closed
10.
canceled
11.
holding
ed8313a7-bfdf-46ff-b8bc-2bd4ad90c51a.png
1.
Upon submission of a change request, a change order is promptly generated and transitions into the "chg_reviewing" phase.
2.
In the "chg_reviewing" phase, our supplier meticulously examines the order. If the change is deemed feasible, they assign the change fee, advancing the order to the "chg_to_be_paid" status. If not, the order is flagged as "chg_rejected".
3.
While the order is in either the "chg_reviewing" or "chg_to_be_paid" status, users have the flexibility to cancel the order. Cancellation updates the order's status to "canceled."
4.
Once an order attains the "chg_to_be_paid" status, a definitive payment deadline is established. Failure to meet this deadline automatically shifts the order to the "closed" status.
5.
During the "chg_to_be_paid" status, users may proceed with payment. If the price remains valid, the order seamlessly transitions to the "chg_proceeding" phase. Conversely, an invalid price marks the order as "failed."
6.
In the "chg_proceeding" phase, successful ticket issuance updates the order's status to "changed." If the supplier is unable to issue the ticket, the order shifts to the "failed_reimbursing" status. Upon completion of the refund process, the order's status is finally updated to "failed_reimbursed," marking the end of the process.

Refund order#

We have 10 status for refund order:
1.
rfd_reviewing
2.
rfd_rejected
3.
rfd_to_be_confirm
4.
rfd_proceeding
5.
refunded_reimbursing
6.
refunded_reimbursed
7.
failed
8.
closed
9.
canceled
10.
holding
f713d9cc-8b10-4ede-9c8e-fbc3ed78a52c.png
1.
Upon submission of a refund request, a refund order is instantly created and transitions to the "rfd_reviewing" phase.
2.
In the "rfd_reviewing" phase, our supplier thoroughly examines the order. If the refund is deemed viable, they assign the refund amount and move the order to the "rfd_to_be_confirm" status. If not, the order is labeled as "rfd_rejected".
3.
While the order is in either the "rfd_reviewing" or "rfd_to_be_confirm" status, users have the option to cancel the order. Cancellation updates the order's status to "canceled."
4.
Once an order reaches the "rfd_to_be_confirm" status, a specific confirmation deadline is set. Failure to meet this deadline automatically changes the order's status to "closed."
5.
During the "rfd_to_be_confirm" status, users may proceed with confirmation. If the refund fee remains valid, the order smoothly transitions to the "rfd_proceeding" phase. Conversely, results in the order being marked as "failed."
6.
In the "rfd_proceeding" phase, a successful refund ticket updates the order's status to "refunded_reimbursing." If the supplier is unable to process the refund, the order shifts to the "failed" status.
7.
In the "refunded_reimbursing" phase, upon the completion of the refund process, the order's status is updated to "refunded_reimbursed," indicating the end of the refund process.
Modified at 2025-03-18 06:10:58
Previous
Open API
Next
Flight Shopping
Built with