How orders move through statuses from checkout to completion, including immediate, deferred, and deposit payment flows.

An order passes through multiple statuses between checkout and completion. The path it takes depends on the payment method selected, whether a deposit is being used, and whether the order requires approval. Understanding these statuses helps you monitor orders and know what action - if any - is needed.

Every order has a status that reflects where it is in the payment lifecycle. The most common statuses you'll encounter are Active (in basket), Processing (payment in progress), Complete (fully paid), and the various Awaiting statuses for deferred payment flows. Not every "awaiting" status means something has gone wrong - payment link, invoice, on-site, and local payment statuses are all intentional flows where payment is expected later.

The most common flow - the customer pays in full at checkout.

1. Customer adds items to basket
   └── Status: Active

2. Customer completes checkout with payment
   └── Status: Processing (while gateway confirms)

3. Payment confirmed
   └── Status: Complete
   └── Confirmation email sent
   └── Items delivered to customer

If the payment fails at step 3, the order moves to Failed and the reserved items are released back to stock.

Deferred flows create the order first and collect payment later. Each method follows a similar pattern but with different customer experiences and expiry behaviour.

A payment link email is sent to the customer with a link to complete payment online.

1. Order created with payment link method
   └── Status: Awaiting payment link
   └── Payment link email sent to customer

2a. Customer clicks link and pays     2b. Link expires
    └── Status: Complete                  └── Status: Expired
    └── Confirmation email sent           └── Items released

Payment links have a configurable expiry period. The default duration is set in Settings > Payment under Payment link default length (typically 72 hours). When generating a payment link from the box office, staff can:

• Set a custom expiry date for the specific link

• Mark the link as editable, allowing the customer to modify their basket before paying

• Include additional information in the payment link email

When the customer clicks the payment link, they are automatically signed in and taken to the checkout to complete payment. If the customer doesn't have an account, a password reset email is sent so they can finalise their registration.

If the customer modifies their basket on an editable payment link, the expiry resets to the default basket timeout. This could cause items to be released sooner than the original payment link expiry.

Admins can resend payment link reminder emails individually from the order detail page, or in bulk from the mass emails section for all orders currently awaiting payment link completion.

The customer receives payment instructions and pays outside the platform. An admin must manually complete the order once payment is received.

1. Order created with invoice payment method
   └── Status: Awaiting invoice
   └── Payment instructions included with order

2. Admin confirms payment received
   └── Status: Complete

Invoice orders can optionally have an expiry date set, controlled by the default payment period setting. See Invoice Payments for full configuration details.

The order is held for the customer to pay in person, typically at the venue.

1. Order created via box office with reserve to pay method
   └── Status: Awaiting onsite payment
   └── Confirmation email sent

2. Customer pays at venue
   └── Status: Complete

Reservations created without an expiry date will never expire automatically. If an expiry date is set, the reservation expires and items are released at that time.

Items requiring approval are reserved but payment is deferred until an admin reviews and approves the order.

1. Order created with items requiring approval
   └── Status: Awaiting approval

2a. Admin approves                    2b. Admin rejects
    ├── If no payment due:                └── Status: Rejected
    │   └── Status: Complete              └── Customer notified
    │                                     └── Items released
    └── If payment is required:
        └── Payment link generated
        └── Customer completes payment
        └── Status: Complete

Local payment methods (such as OXXO via Stripe) redirect the customer to complete payment through a local provider.

1. Customer selects local payment method at checkout
   └── Status: Awaiting local payment
   └── Payment instructions provided

2. Customer completes payment at local provider
   └── Webhook confirms payment
   └── Status: Complete

Local payment orders do not expire. The order remains in Awaiting local payment status until the customer completes payment or an admin manually updates the order.

When deposit payments are configured, the customer pays a percentage of the order total up front and the remaining balance is collected later.

1. Customer selects deposit payment plan at checkout
   └── Deposit amount calculated (percentage of total + fees)

2. Customer pays the deposit
   └── Status: Partially paid
   └── Deposit received email sent

3. Customer returns to pay remaining balance
   └── Status: Complete
   └── Confirmation email sent

The remaining balance must be paid before the configured deadline. If the customer does not pay in time, the reservation may be cancelled and items released. See Deposit Payments for full details.

After an order is completed, it can still transition to these statuses:

Occasionally, the system cannot automatically determine whether a payment succeeded or failed. This is typically caused by gateway communication issues or unexpected responses.

When an order is in Unknown status:

• Items remain reserved (stock is not released)

• You should check the payment status directly in your payment gateway's dashboard

• Once confirmed, manually complete or expire the order in the admin panel

• Introduction

• Payment Processors

• Deposit Payments

• Invoice Payments