Order Statuses
Complete reference for order status values, meanings, and transitions
Order Statuses
Orders progress through a defined set of statuses as they move from creation to completion.
Status Values
| Status | Code | Description |
|---|---|---|
| Accepted | ACCEPTED | Order created, awaiting payment |
| Paid | PAID | Payment verified, processing |
| In Progress | IN_PROGRESS | Reservations being processed |
| Finalized | FINALIZED | Successfully completed |
| Not Paid | NOT_PAID | Payment not received (timeout) |
| Failed | FAILED | Processing error occurred |
| Refunded | REFUNDED | Order has been refunded |
Detailed Descriptions
ACCEPTED
The initial status when an order is created.
Characteristics:
- Order exists in the database
- Payment session initiated but not completed
- Prebook sessions linked to order
- User has not finished payment
Next States: PAID, NOT_PAID
Automatic Transition: Orders in ACCEPTED for 24+ hours automatically transition to NOT_PAID via daily cron job (4 AM).
PAID
Payment has been verified by the payment provider.
Characteristics:
- Transaction record created
- System begins reservation processing
- External bookings being created
Next States: IN_PROGRESS, FINALIZED, FAILED
IN_PROGRESS
Reservations are being processed asynchronously.
Characteristics:
- Used for auto-ticketing suppliers
- Background jobs verifying ticket issuance
- Retries may be in progress
Next States: FINALIZED, FAILED
Retry Logic: System retries ticket verification up to 12 times with 5-minute intervals.
FINALIZED
All reservations successfully completed.
Characteristics:
- All reservations have OK status
- For flights: tickets issued
- For corporate: budget confirmed
- Order is complete
Next States: REFUNDED (if refunded later)
NOT_PAID
Payment was not completed within the allowed window.
Characteristics:
- Automatic cleanup by cron job
- Order cannot be recovered
- User must create new order
Terminal State: No transitions from this status.
FAILED
An error occurred during order processing.
Characteristics:
- Error event logged with details
- May be recoverable with manual intervention
- Requires investigation
Next States: FINALIZED (manual), REFUNDED
REFUNDED
Order has been refunded.
Characteristics:
- One or more refunds processed
- May be partial or full refund
- Typically marks end of order lifecycle
Terminal State: No transitions from this status.
Status Transitions
Status by Provider
Different providers may have different typical status flows:
Consumer Payments (SUPER_QI_APP, CHECKOUT_COM)
ACCEPTED → PAID → FINALIZED
ACCEPTED → PAID → IN_PROGRESS → FINALIZED
ACCEPTED → NOT_PAID (timeout)BNPL
ACCEPTED → PAID → FINALIZED
(Transaction isPaid=false until installments complete)CORPORATE_DIRECT
ACCEPTED → PAID → FINALIZED (immediate, no payment)
Policy block → Order rejected (no ACCEPTED status)
Budget block → Order rejected (no ACCEPTED status)SANDBOX
ACCEPTED → PAID → FINALIZED (immediate, testing)Manual Status Changes
Administrators can manually change order status in certain cases:
| Action | Target Status | Use Case |
|---|---|---|
| Mark as Finalized | FINALIZED | Manual resolution of failed order |
| Mark as Refunded | REFUNDED | Mark order as refunded after processing |
Manual status changes are logged as events. Use only when appropriate for the situation.
Dashboard Display
Status is displayed with color coding:
| Status | Color | Chip Color |
|---|---|---|
PAID, FINALIZED | Green | success |
FAILED | Red | error |
| All others | Blue | info |
API Representation
In API responses, status is a string field:
{
"id": "order_abc123",
"status": "FINALIZED",
...
}Filter orders by status:
GET /admin/orders?status=FAILED
GET /admin/orders?status=FINALIZED