Life of an order and a reservation¶

Orders¶

An order starts as a hold while the guest is in checkout. The sync route only returns orders that reached SUCCESS.

stateDiagram-v2
    direction LR
    [*] --> PENDING: Guest starts checkout, tickets are held
    PENDING --> SUCCESS: Paid
    PENDING --> FAILED: Hold ended or checkout canceled
    [*] --> SUCCESS: Comp or free ticket

A PENDING order that is more than a day old is a checkout the guest left, not a sale.

An order stays SUCCESS after a refund. Look at refundType on each ticket, and at the refund routes, to see what came back.

Reservations¶

reservationStatus is a text field that staff change in the Web Manager and the door apps, so a reservation does not have to follow one path. This is the usual one.

stateDiagram-v2
    direction TB
    [*] --> REQUESTED: Request
    [*] --> BOOKED: Staff or online
    REQUESTED --> BOOKED: Accepted
    REQUESTED --> PENDING_PAYMENT: Payment needed
    REQUESTED --> EXPIRED: No answer
    PENDING_PAYMENT --> CANCELED: Not paid
    PENDING_PAYMENT --> CONFIRMED: Paid
    BOOKED --> CONFIRMED: Guest confirms
    BOOKED --> ARRIVED
    CONFIRMED --> ARRIVED
    ARRIVED --> SEATED
    SEATED --> PAID
    PAID --> LEFT
    LEFT --> [*]

All the values you can see:

`reservationStatus`	Meaning
`REQUESTED`	A guest's request. See the warning below.
`HOLD`	Held by staff
`PENDING_PAYMENT`	Accepted, waiting for payment
`BOOKED`	Booked
`CONFIRMED`	The guest confirmed, or paid what the venue asked for
`ARRIVED`	The guest arrived
`PARTIALLY_SEATED`, `SEATED`	Some or all of the party is at the table
`PAID`	The check is paid
`LEFT`	The party left
`NO_SHOW`	The party did not come
`CANCELED`, `CANCELED_AND_NOTIFY`	Canceled. With `CANCELED_AND_NOTIFY`, staff chose to tell the guest.
`EXPIRED`	A request nobody answered in time

The field is free text in our database, so treat a value you do not know as "other" and do not fail on it.

A declined request can still say REQUESTED

When a venue declines a request, reservationStatus stays REQUESTED. The routes do not return the request's own status today, so REQUESTED does not prove a request is still open.

paymentStatus on a reservation only follows paylinks. A table paid online has its payment in tableBooking.paymentStatus.

Paylinks¶

paymentStatus on a paylink:

Value	Meaning
`PENDING_APPROVAL`	Waiting for the venue to approve it
`REJECTED`	The venue said no
`PENDING`	Sent, waiting for the guest
`SUCCESS`	Paid
`EXPIRED`	The time to pay ran out
`DEACTIVATED`	Staff turned it off

Refunds¶

refundStatus is the same on all three refund routes.

stateDiagram-v2
    direction LR
    [*] --> REQUESTED: Staff start a refund
    REQUESTED --> INPROGRESS: Sent to the payment processor
    REQUESTED --> FAILED: The processor refused it
    INPROGRESS --> SUCCESS: The processor confirmed it

Disputes¶

status on the dispute routes comes from the card networks through our payment processor.

Value	Meaning
`WARNING_NEEDS_RESPONSE`, `WARNING_UNDER_REVIEW`, `WARNING_CLOSED`	An early warning from the bank, not yet a full dispute
`NEEDS_RESPONSE`	The venue can send evidence
`UNDER_REVIEW`	The bank is looking at the evidence
`CHARGE_REFUNDED`	The charge was refunded
`WON`	Decided for the venue
`LOST`	Decided for the guest