> ## Documentation Index
> Fetch the complete documentation index at: https://docs.riservahq.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Reservations in Shopify POS
Riserva puts **three tiles** on your Shopify POS smart grid, so staff can run
reservations from the register with no trip to the admin:
* **Reservations** — the host stand. It shows who's arriving, who's on
property, the waitlist and who's done, with one-tap check-in and seating.
* **Book reservation** — a step-by-step booking flow for walk-ins and phone
bookings. Payment is collected through the register.
* **Bill credits** — lights up when the cart's customer holds prepaid credit
or has an entry fee still open today. One tap applies the credit or settles
the fee with the sale.
***
## Add the tiles to every register
Do this once in Shopify admin and every register gets the tiles.
1. In Shopify admin, go to **Sales channels → Point of Sale**.
2. Open the POS editor: **Customize the in-store experience → Edit Point of
Sale**.
3. In the editor's **Apps** section, activate **Riserva**'s extensions.
4. Add **Riserva Reservations**, **Riserva — Book reservation** and **Riserva
Bill Credits** to the smart grid.
5. Save the layout **as the default**, so it applies across all your retail
locations.
Step 3 is what makes the tiles available at all. Until it's done, they won't
appear in any Add tile list.
On the home screen, the **Reservations** tile shows today's count for this
register's location. The count includes every reservation on today's book
that isn't cancelled, including parties already completed or marked no-show.
The **Bill credits** tile lights up when the cart's customer holds credit.
The device path still works. In the Shopify POS app, go to **≡ More →
Settings → Smart grid → ⊕ Add tile → Embedded Apps**.
It only covers that device's location. The tiles only appear there after
the activation in step 3 above.
A tile reads **Not enabled**, and opening it says "POS reservations aren't
enabled for this shop." Contact support: the POS surface is switched on per
shop.
***
## Linking a register to a location
Each register shows the reservations for its own store location in Shopify
POS. You don't link anything by hand. Riserva's locations *are* your Shopify
locations, copied over whenever you open **Settings → Venues & floor maps**.
A register finds its location as long as that Shopify location is active and
Riserva has seen it.
* **Your venues must sit under the location the register is in.** A
reservation shows on the register at the location its venue belongs to.
* **Added a location in Shopify recently?** Open Settings → Venues & floor
maps once, so Riserva picks it up.
This happens when the register's location isn't one Riserva knows. That
means a brand-new Shopify location, an inactive one, or an old location
listed as *Not linked to a Shopify location*. You'll see:
* *"This register isn't linked to a Riserva location. Link it in the Riserva
admin under Venues & floor maps."* on the Reservations tile, instead of the
day's list. The tile shows no count.
* On **Book reservation**, times from **every** location, because the
register can't tell which one it is at.
* No waitlist on **Book reservation**. A fully booked experience today reads
**Fully booked** instead of offering **Join waitlist**, because the party
would have nowhere to queue. On a future day with nothing open, the badge
reads **No times**.
***
## The host tile: Reservations
The **Reservations** tile shows today's parties at this location in four
tabs: **Arriving**, **On property**, **Waitlist** and **Done**. Guests give
their name or reservation code, and typing either in the search field on top
filters every tab instantly.
**Done** lists the day's completed visits and no-shows, newest first. Each
has a **Completed** or **No-show** badge and when it ended ("ended 3:40 PM" /
"marked 3:40 PM"). That's handy when a guest comes back for a bill credit or
a balance.
### Look up another day
The Reservations tile isn't locked to today. **‹ Prev**, **Next ›** and the
date field walk or jump to any service day. The **Today** button brings you
back. The **Waitlist** tab always shows who's waiting *right now*, whatever
day is on screen.
The search also looks **across every day and property**. When a guest swears
they have a reservation and today's list disagrees, type their name or code.
Matches from other days appear below the tabs, labeled plainly ("Yesterday",
"In 3 days", the other property's name). Cancelled reservations are included,
so you can give a straight answer at the door.
Tap a match to open it. If the party simply came a day late, check-in works
from right there.
### Read a party's card
Each reservation on the Reservations tile is a card. It shows the guest's
initials, name, badges and one line of context. The badges:
* **Late** (yellow) — a confirmed or pending-payment party 10+ minutes past
its time.
* A red payment badge when money is owed — **Payment due**, **Partially
paid** or **Charge failed**.
* **Booked after its time** (red) — the guest paid after the visit had ended.
* **Refund due** or **Credit \$X**, where they apply.
**Card on file**, **Charge scheduled** and **Charging** badges appear on the
detail page only, not on the list.
### Open a party's detail page
**Tap the card** to open the party's detail page. It shows:
* the code, time, experience and venue
* the table (tap it to change it)
* any **add-ons the guest already paid for** — your delivery checklist. A
refunded add-on says so, so it doesn't get handed over.
* the guest's phone and email when they're on file, so a late party is one
call away.
The actions that make sense right now are pinned at the bottom. See [Ending
a visit from the register](#ending-a-visit-from-the-register) for the full
list. When the reservation still owes money, **Add to cart — collect \$X**
collects the balance through the register, exactly like the booking flow's
payment step.
### Check in a party that arrived early
When a party is more than your early-arrival window before their
reservation's time, **Check in** (and **Partial check-in…**) asks before it
acts. That holds however many days away the reservation is. The question
names the slot it would move them to:
*Booked for Mon, Sep 21 at 8:00 AM — move to today's next slot, 11:00 AM, and
check in?* (or *move to the 10:30 AM slot (in progress)*)
* **Move to 11:00 AM and check in** — puts the reservation on that slot,
releases the later seat, and checks them in.
* **Check in without moving** — keeps the original date.
* **Cancel** — goes back.
A full slot says so and offers **Seat them anyway**. The window lives in the
admin under Settings → Reservations → Early arrivals. More in [Set up the
waitlist, early arrivals, ending visits and
no-shows](/daily-operations/waitlist-early-arrivals-and-ending-visits).
### Collect a balance at the register
**Add to cart — collect \$X** works for any reservation that owes money,
however it was booked. That covers an online booking whose card failed, a
phone booking, or one whose payment link the guest never opened. Ring it
like any other sale and the reservation settles itself.
**The sale is the guest's.** Adding a reservation to the cart attaches its
guest as the cart's customer, so the order lands on the right profile. If a
different customer is already in the cart, the tile asks before switching. A
reservation with no customer on file clears the cart's customer instead. The
toast always says who the sale is for.
### Guests who saved a card online
Don't ring these parties up — Riserva charges the saved card itself. They
booked online with a saved card and have paid nothing yet. Leaving them to
Riserva means nobody rings the party up twice.
* **The blue banner says when.** The detail page's **Payment** section shows
the amount, when the card is charged, and the card.
* **Checking in charges the card.** Confirming the check-in charges the saved
card right then, and nothing is rung at the till.
* **"At the visit" is the exception.** For an experience charged *at the
visit*, the card waits for close-out, so the register can take the fee with
the rest of the sale. The page offers **Add to cart — collect \$X** until
then.
* **Card declined?** A red banner carries the reason, and **Add to cart —
collect \$X** appears. Ring it like any other sale and the reservation
settles itself.
The blue banner reads, for example, *Charges \$120.00 from Sun, Sep 20, 2026,
2:00 PM · collected within the hour · Visa •••• 4242*. Or, when the card is
charged at check-in: *Charges \$120.00 when you check the party in · Visa ••••
4242*.
When check-in charges the card:
* The toast reads *"Charge submitted — Shopify is confirming it."* and the
reservation turns **Paid** within seconds.
* If Riserva can't reach Shopify at that moment, it hands the balance to the
hourly collector instead. The toast then says *"collected within the
hour."*
### Apply a bill credit from the party's page
A reservation holds a fee credit when the guest prepaid a tasting fee on an
experience with "Credit the fee toward the guest's bill" turned on. The
party's row carries a **Credit \$X** badge, and the detail page shows the
amount.
1. Ring the guest's purchase, at least one item.
2. Open the party.
3. Tap **More actions → Apply \$X credit to sale**. (Or use the **Bill
credits** tile.)
The register cart gets a matching discount named after the reservation code.
The timeline records who put it on the sale. The credit is only *spent* when
that sale completes. The timeline then reads "\$X bill credit applied to
register sale #1234" and the badge goes away.
* **Cart cleared or sale abandoned:** nothing is lost. The credit stays on
the reservation and you can apply it again.
* **Empty cart:** the tap is refused ("Add items to the sale first — a credit
needs something to come off").
* **Discount didn't reach the cart:** the screen says "Couldn't add the
discount to the sale — try again" and nothing is recorded.
### Seat, notify or remove a waiting party
Parties on the **Waitlist** tab have their own actions:
* **Seat party** converts them into a seated reservation. Pick from today's
open times, with their requested experience first. You land straight on
the new reservation, where a priced experience shows **Add to cart —
collect \$X**. Charging the party is one tap, not a search.
* **More actions → Notify** marks the party called. It emails the
table-ready note when an email is on file, so collect one when adding them
to the waitlist. Riserva doesn't send text messages.
* **More actions → Remove** takes them off the list.
### Change the party size
Checking in never changes the reservation. Change the size only when the
party itself has changed: "we're 6 now, not 4", or two guests cancelled and
want their share back.
1. Open the party (an arriving party).
2. Tap **More actions → Adjust party size**.
3. Set the size on the stepper, which starts at the booked size.
4. Tap **Save**.
The page says "This changes the reservation itself. To record that only part
of the party came, use Partial check-in instead."
**The refund follows your cancellation policy.** Removing seats is a partial
cancellation. A same-day shrink under a "no refund within 24 hours" policy
refunds nothing. The screen says exactly what's refundable and what stays
before you confirm.
Whatever the policy grants is recorded as owed and queued. It's never
silently dropped. The reservation shows a **Refund due** badge on the
Reservations tile. In the admin, the reservation page's Payment card carries
the callout, with a Retry to send the money back.
If your shop allows it (Settings → Policies → Refund overrides), a **Refund \$X
in full instead** button (with the amount) lets the register go beyond the policy. The
override lands on the timeline.
### Who an action is recorded against
Everything you do on the Reservations tile shows up everywhere else: the
admin host view and the reservation's timeline. Actions are recorded against
the staff member whose PIN is active, not the account the iPad is signed in
with ("Dana Kim · POS"). That works once the person has opened the Riserva
admin at least once. Until then their actions show as "POS".
***
## The booking tile: Book reservation
The **Book reservation** tile starts the way the admin does, with the day,
not a menu.
1. **Day & party** — Today is one tap, Tomorrow is another, or pick any
future date.
2. **See what's available** — tap **Pick time** on an experience card.
3. **Time** — tap one of the day's open times for the card you picked.
4. **Guest** — search your Shopify customers and tap the match, or type the
details.
A POS device is a perfectly good way to take a phone reservation for next
Saturday.
**The experience cards** show every experience that fits the party. Each
card has its photo, duration and price ("per guest", or one price "for the
venue" on buyouts). They follow the order you set with **Reorder** on the
Experiences page, and are alphabetical until you do. A card with open times
says **Pick time**.
A card with nothing left *today* offers **Join waitlist** instead. Enter the
name and party, plus a phone and an email for the table-ready note if you
have them. The party appears on the host tile's **Waitlist** tab.
**The guest step** searches your Shopify customers by name, email or phone.
* Tap the match to fill everything in. Fields the customer record knows are
locked.
* A **Member** badge appears beside recognized members, with the same
recognition as everywhere else in Riserva.
* If the register cart already has a customer attached, the form pre-fills
itself.
* Or type details directly, or tap **Book as guest — no details** to book
anonymously on purpose.
Special requests live in the guest step too. With an email in **Email (for
the confirmation)**, the guest gets the **Reservation confirmed** email as
soon as you book, unless it's switched off in Settings → Emails.
### Collect payment for a new reservation
For a priced experience, the reservation starts as **Payment due**. The done
screen offers **Add to cart to collect payment**.
* The experience lands in the POS cart at the right quantity. A buyout is one
line at the room price.
* The reservation's code, date, time and party are printed on the line. They
show on the register receipt too.
* The sale completes like any other, including register discounts. Those
settle at what you actually charged.
* The payment attaches itself to the reservation automatically.
If the guest doesn't pay now, the reservation stays Payment due with all the
usual resolutions.
A guest-booked reservation may later be paid through the register with a
customer attached, or through a payment link online. It then fills in its
missing name, email and phone from that order automatically. Details you
typed yourself are never overwritten.
***
## The credit tile: Bill credits
The **Bill credits** tile watches the cart and lights up when the attached
customer has money the register should honor. That's a bill credit, or an
entry fee still open today. Nobody has to go looking.
What the Bill credits tile reads:
* "Add a customer to the cart" — dimmed, no customer attached yet.
* "\$40.00 available" — the customer holds credit.
* "Entry fee due" or "Entry fee — saved card" — a fee still open today.
* "No credit for this customer".
### Apply a bill credit with the tile
A bill credit is an entry fee paid online for an experience set to credit
that fee toward the guest's bill. You can always apply it from the
reservation's detail page on the host tile. The Bill credits tile is the
shortcut.
1. Attach the customer to the cart.
2. Ring at least one item.
3. Tap the **Bill credits** tile. It lists the guest's credited reservations
(amount, reservation code, date, experience).
4. Tap **Apply \$X credit to sale**.
The discount goes on the register cart. Applying only puts the credit on the
sale; it is spent when the sale completes. A cleared cart or an abandoned
sale costs the guest nothing, and the credit stays listed.
**Apply \$X credit to sale** stays greyed out until the cart has something in
it ("Add items to the sale first — a credit needs something to come off").
The register holds one discount per sale. Complete the sale before applying
the next credit.
While a credit is on the cart, the others are greyed out:
* The Bill credits tile says "A credit is on this sale — it is used when the
sale completes. The register holds one discount per sale."
* The Reservations tile's button reads "A credit is on this sale — it is used
when the sale completes".
On both tiles the lock lifts as soon as the cart is empty again.
### Settle or waive today's entry fee
The Bill credits tile also lists the customer's **Entry fees today**. That's a
party visiting today whose entry fee is still open. It is either due, or
waiting on the saved card until close-out for an experience charged *at the
visit*. Each fee offers **Add \$X fee to sale** and **Waive fee**. Completing the
sale settles the fee, and the saved card is then never charged.
You can set an amount under **Settings → Policies → Entry fees at the
register**, or on the experience's Pricing card. A purchase over that amount
makes **Waive fee** the suggested button ("Purchase over \$150.00 — waive
suggested.").
***
## Ending a visit from the register
A party's detail page keeps the one thing you most likely came to do as its
big button. Then comes **More actions**, and **Back** is always last.
| The party is | Big button | Under it | Under **More actions** |
| - | - | - | - |
| Arriving | **Check in** | **Partial check-in…** (parties of two or more) | **Adjust party size**, **No-show** |
| Checked in | **Seat** | **Complete** — or **Still here** once running over | **Edit guests here** (parties of two or more), **Undo check-in**, plus **Complete** while **Still here** has taken its place beside **Seat** |
| Seated | **Complete** | **Still here** once running over | **Edit guests here**, **Unseat** |
**More actions** swaps the bottom of the page for the rest of the list, with
its own **Back** to return. It also holds the bill-credit button when the
guest holds one.
The page itself is in sections, like the admin's party panel: **Reservation**,
**Guests**, **Table**, **Payment** and **Contact**. **Guests** appears only
while part of the party is missing, with **All here** and **Edit**.
**You rarely need Complete.** Visits end by themselves when your Ending visits
setting says (Settings → Reservations → Ending visits). That's after the
reservation's end plus the grace period, or at the end of the day. Once the party is
past its end, the page shows a yellow **Running over** badge. It offers
**Still here** under the big button, which moves that end out by 30 minutes
each time you press it. That's the same as the Host page.
### Change a party's table
On a floor-map experience, the **Table** section shows the table and its
state. **Suggested** is Riserva's pick, which it may still move. **Assigned**
means a host chose it. The third state is **Locked**.
1. Tap the table in the **Table** section to open the table page.
2. Tap **Change table…** to list every table at the party's time.
3. Tap a table to assign it.
**More actions → Change table** goes straight to the list. A locked table must
be unlocked before it can change. It works the same as the Host page in the
admin, and the reservation's history names who did it.
The table page also has:
* **Keep** — makes Riserva's pick yours.
* **Let Riserva choose** — hands an assigned table back.
* **Lock** / **Unlock**.
Each table in the **Change table…** list reads **Free**, **Taken — Maria G.
at 2:00 PM**, **Riserva's pick for … — they would be moved**, or **Too small
for 4**. Joined tables that seat the party come at the end.
A taken table asks first. **Assign anyway** double-books it; **Cancel**
changes nothing.
### Undo a check-in or a seat
Tapped **Check in** or **Seat** by mistake? The detail page walks the party
one step back, under **More actions**:
* **Undo check-in** on a checked-in party ("Check-in undone"). The party is
back among the arrivals.
* **Unseat** on a seated party ("Unseated"). The party is checked in again.
A seated party goes back one step at a time.
The undo is refused if the check-in already charged the guest's saved card,
or marked the reservation's order fulfilled. The message says why. Edit or
cancel the reservation from the admin instead.
### Check in part of a party
Only part of the party here? Record who came without changing the
reservation.
1. Tap **Partial check-in…** instead of **Check in**.
2. Step the number to how many are here. The page asks "How many of the party
of 4 are here?", from 1 to the party size.
3. Tap **Check in** at the bottom (or **Cancel**).
The toast says, for example, "Checked in — 2 of 4 here". The **On property**
list reads "2 of 4 here" instead of "Party of 4".
When the rest arrive, open the party. Its **Guests** section has **All here**
(one tap) and **Edit** (another number). Or use **More actions → Edit guests
here**.
The party size and what was paid do not change. Partial check-in only records
who came, for Reports and the reservation's history.
### Undo a no-show
Marked a no-show and they walked in? Open the party from the **Done** tab. A
no-show's detail page has **Undo no-show** in its footer ("No-show undone").
It works for a no-show a host marked, and for one your automatic no-show
setting marked (Settings → Reservations → No-shows). The reservation goes
back to Confirmed, or to Pending payment if that is what it was marked from.
It returns to **Arriving**, ready to check in.
## Good to know
* The Reservations tile's count is a snapshot from when the home screen
loaded. The day view is always current.
* POS needs a network connection for Riserva. The secure tokens it uses can't
be minted offline.
* A split-tender sale left partially paid keeps the reservation at Payment
due until the remainder is collected. Then it flips to Paid.
* A reservation whose detail page reads **Charging** has a payment in flight
with Shopify. Don't collect it again at the register. Wait for it to land on
Paid or Charge failed.
* **Add to cart** rings a whole number of the experience's own line. An
unusual part-balance, like a partly-paid deposit, is collected from admin
with a payment link instead.
***
## Related
**What things mean on this screen:** [What things mean: Riserva in Shopify POS](/reference/pos)
* [Host view](/daily-operations/host-view)
* [Book a reservation](/daily-operations/book-a-reservation)
* [Payment policies and money states](/core-concepts/payment-policies)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.