How to handle a queue where payment comes before service, not after

Most queues work the same way: a customer takes a token, joins the line, and waits their turn. But plenty of walk-in businesses have a step that has to happen first - and the order matters. A customer who hasn't paid, hasn't filled in a form, or hasn't had a document checked isn't really ready to be served yet, even if they're standing right there holding a token.

Why "take a token, then wait" isn't always the right order

If a queue adds every token straight to the waiting list, a customer who still needs to complete something else ends up mixed in with people who are genuinely ready. Staff either call them too early and have to skip them, which looks unfair to everyone else waiting, or the business has to run a second, informal system on the side just to track who's actually done their part. Neither is a good experience.

A counter order example

A busy sandwich counter takes orders and payment at the register, then hands the customer a token for pickup. If every token joined the pickup line the instant it was issued, the kitchen would see orders that haven't been paid for yet mixed in with ones that have - and a customer who steps away to find a seat before paying would still show up as "waiting" even though their order was never actually placed. What the counter needs is a token that exists the moment someone pays, but only joins the pickup line once a staff member confirms the order went to the kitchen.

Two settings, not one feature

This comes down to two separate queue settings, used together.

• Queue behavior - whether staff call whoever has waited longest, in order, or staff choose any waiting customer themselves. A pay-first counter often wants the second option, since orders don't always finish cooking in the order they were paid for.
• Initial token state - whether a customer joins the waiting list the instant they get a token, or only once staff add them to the line. The second option is what makes a "pay first, then queue" pattern work: the token exists as soon as payment happens, but a staff member moves the customer into the actual line once the order (or form, or check) is actually done.

Set up this way, nobody waiting in the visible line is still mid-payment or mid-paperwork. The line only ever shows people who are genuinely ready to be called.

Other places this pattern shows up

A food counter is one example, but the same shape appears anywhere a business needs something confirmed before a customer is really in line: a deposit before a salon chair, a document check before a government counter, an intake form before a clinic consultation. The settings are the same in every case - only what has to happen before staff confirm the customer in changes.

Where Qrua fits

Qrua's queue behavior and initial token state settings are built for exactly this. Set initial token state to "staff confirm first" and a customer's token exists as soon as they're issued one, but they don't appear in the waiting list until a staff member adds them in - typically right after whatever has to happen first (payment, a form, a document) is done. Combine that with "staff picks who's next" if the order customers are ready in doesn't match the order they arrived in. Both settings are configured per queue, so a business can use the normal "join immediately, call in order" setup for one queue and the pay-first pattern for another.