Order Lifecycle
Understanding order status transitions from creation through finalization or refund
Order Lifecycle
Every order progresses through a series of statuses as it moves from initial creation to final completion. Understanding these transitions is essential for troubleshooting and order management.
Order Statuses
| Status | Description | Next States |
|---|---|---|
ACCEPTED | Order created, awaiting payment verification | PAID, NOT_PAID |
PAID | Payment verified, processing reservations | FINALIZED, IN_PROGRESS |
IN_PROGRESS | Reservations being processed (async ticketing) | FINALIZED, FAILED |
FINALIZED | All reservations successfully completed | REFUNDED |
NOT_PAID | Payment not received within time window | Terminal |
FAILED | Processing error occurred | Can be manually resolved |
REFUNDED | Order has been refunded | Terminal |
Lifecycle Flow Diagram
Detailed Status Descriptions
ACCEPTED
The initial status when an order is created. At this point:
- Order record exists in the database
- Prebook sessions are linked to the order
- Payment session is initiated with the provider
- User has not yet completed payment
Automatic Transition: Orders in ACCEPTED status for more than 24 hours are automatically transitioned to NOT_PAID by a daily cron job.
The unpaid order cleanup runs daily at 4 AM. Orders stuck in ACCEPTED will be marked as NOT_PAID if payment isn't verified within 24 hours.
PAID
Payment has been verified by the payment provider. The system now:
- Creates internal reservation records
- Calls the external travel supplier (IRIX) to create actual bookings
- For flights: initiates ticket issuance
For non-auto-ticketing flights: Transitions directly to FINALIZED if ticket issuance succeeds.
For auto-ticketing flights: Transitions to IN_PROGRESS while awaiting supplier confirmation.
IN_PROGRESS
Used when reservations are being processed asynchronously. This typically happens with:
- Auto-ticketing flight suppliers
- Multi-reservation orders where some succeeded and others are pending
The system will retry ticket verification up to 12 times with 5-minute intervals.
FINALIZED
The happy path completion status. All reservations have been successfully:
- Created with the travel supplier
- Verified (tickets issued for flights)
- Confirmed with service dates
For corporate direct orders, this also triggers budget confirmation.
NOT_PAID
Payment was not completed within the allowed time window. This is typically because:
- User abandoned the payment flow
- Payment was declined
- Session expired
NOT_PAID is a terminal status. These orders cannot be recovered—the user must create a new order.
FAILED
An error occurred during order processing. Common causes:
- External supplier (IRIX) returned an error
- Network timeout during reservation creation
- Ticket issuance failed
Failed orders appear with an error event in the audit trail and can be:
- Manually marked as FINALIZED (if resolved externally)
- Refunded if the booking couldn't be recovered
REFUNDED
The order has been refunded, either:
- Partially (one or more reservations refunded)
- Fully (entire order refunded)
Refund records are linked to the transaction, tracking:
- Refund amount
- External reference
- Refund reason
Corporate Direct Lifecycle
For corporate bookings using CORPORATE_DIRECT provider, the lifecycle includes additional steps:
Key differences:
- Policy Evaluation: Before order creation, policy rules are checked
- Budget Reservation: Budget is reserved when the order is created
- Budget Confirmation: On finalization, reserved budget becomes spent
- Budget Release: On failure, reserved budget is released
See Corporate Direct for details.
Automatic Cleanup
The system runs scheduled jobs to maintain order integrity:
| Job | Schedule | Action |
|---|---|---|
| Unpaid Order Cleanup | Daily 4 AM | Marks 24h+ ACCEPTED orders as NOT_PAID |
| Ticket Verification | Retries every 5 min | Checks auto-ticketing status, up to 12 attempts |
Status Change Events
Every status change is recorded as an event. See Events for the complete event catalog.