Orders.

Every registration has an order behind it, including a free one worth nothing. Orders on an event is where that money lives: what was bought, what was paid, what was refunded, and what is still outstanding.

What an order holds

Three things.

Lines. What was bought. One line per attendee on the registration, each naming the ticket tier and its price.

Transactions. What moved. A payment is a debit, a refund is a credit, and each carries its status, the method it went through, who recorded it, and the provider's own reference where there is one.

The billing contact. Who was billed, and the address every mail about this order goes to. Not always an attendee.

Reading the list

The Orders list shows who each order was billed to, its status, its total, what has been collected, what has been refunded, and when it was placed. What is still outstanding is on the order itself.

The status is the state of the money, not of the guest: awaiting payment, free, paid, part refunded, refunded, rejected or expired. A guest whose order is not paid holds no ticket, whatever else is true about them.

To find the order behind a guest, search by the billing contact's name or email. One order can cover several attendees, so the guest you are looking at may not be the person the order is named for.

Confirming an offline payment

An order paid through instructions you published sits waiting for you.

Open it and press Confirm Payment on the pending payment. Check the proof of payment the buyer sent first, if they sent one; the dialog warns you when none was uploaded, because at that point you are confirming from your own bank statement rather than from anything on screen.

Confirming settles the order, marks its guests paid, and sends the tickets.

Rejecting one

Reject Payment turns the payment down and closes the order.

You pick a reason, and the reason is emailed to the buyer in words they can act on: the amount does not match, no matching transfer was found, the proof could not be read, or none of those. You can also write a note, and the note stays with your team. The buyer never sees it.

Rejecting does not delete anybody. The guests stay on the event, unpaid and without tickets, because a rejection is a statement about money and erasing the people who registered would destroy the only evidence of what happened. The buyer is told that registering again is the way back in while tickets remain.

Three more actions

Set price. A line on an order that is still free can be given a price. It can be set once and the line cannot be edited afterwards, so read it back before you save.

Record Payment. Money you took outside the platform, written down against the order so the books match reality. Use it for a transfer that landed in your account, or cash you took in the room.

Record Refund. Money going back. How it behaves depends on how it arrived, which is covered in refunds.

All three of these need payments activated, because each of them names an amount and a team without a billing currency has nothing to write it in.

What the buyer sees

The same order, from the other side. Their acknowledgment email links to a public status page showing where the order stands, what is outstanding, and your payment instructions if they still owe you.

That page is also where they ask for an upload link so they can send you proof of payment. The link goes to the address the order was billed to, which is what keeps the upload with the person who paid. An order carries one proof.