Refund policy
Clear refund rules before payment.
Refund decisions follow a documented workflow so customer expectations, finance records, and compliance review stay aligned.
Eligibility overview
| Situation | Policy direction |
|---|---|
| Service cannot deliver the promised reservation support document | Support records failed fulfillment and provides a refund or documented resolution path. |
| Payment fails | Order does not enter fulfillment until a payment event is linked. |
| Minor typo before delivery | Support can review a correction request before fulfillment completes. |
| Issued digital service after delivery | Refund eligibility may be limited and is reviewed against the published policy. |
| Customer changes route, dates, or passenger after delivery | A new order may be required depending on fulfillment state. |
Required refund records
- Refund decision reason code.
- Payment and refund records linked to the order.
- Internal support note for disputes or chargebacks.
- Customer-facing explanation of the decision and next step.
- Timestamp for request received, decision made, payment-provider submission, and customer notification.
Timing and payment-provider handling
- Support should acknowledge refund requests within the published support target when enough order information is provided.
- Approved refunds should be submitted to the production payment provider promptly after the decision is recorded.
- Bank, card-network, wallet, or payment-provider posting times may control when funds appear to the customer.
- Production launch must publish the selected payment provider, dispute channel, and expected refund-posting window.