---
title: "How Gravity Pass fits together"
description: "The four parts of Gravity Pass, and the idea that makes availability work: slots, sessions and tickets."
---

> Documentation Index
> Fetch the complete documentation index at: http://localhost:4321/llms.txt
> Use this file to discover all available pages before exploring further.

# How Gravity Pass fits together

Gravity Pass has four parts. You only work in one of them, the **management portal**, but it helps to know what the others are.

## The four parts

- **Management portal** — This is where you work. Everything in this guide happens here: setting up, watching bookings, checking people in, packing orders.
- **Booking site** — Your customers choose a day, pick tickets, add the people riding and pay. Also where they buy season passes and see your events.
- **Merchandise shop** — A separate site for selling products. It shares customers, branding and your payment account with the booking site.
- **Check-in app** — The Gravity Pass app for iPhone, for checking people in on the day. The portal's [Check in](/daily/check-in) screen does the same job on any device.

## How availability works

There is no calendar to fill in. Availability comes from two things you set up, and they work together.

1. **A slot says when you run**

   A [slot](/selling/slots) is a repeating time, such as "Weekend morning, Saturday and Sunday, 10:00 to 13:00, 12 bookings per day". You can limit it to a date range, such as half term.
2. **Gravity Pass creates the days**

   Each day a slot runs becomes a dated **session**: the thing customers actually book, with its own places. Sessions are created about 90 days ahead and topped up automatically, so you never create them by hand.
3. **A ticket puts it on sale**

   A [ticket](/selling/tickets) is what the customer buys. Each ticket lists the slots it can be booked on. A slot only goes on sale once an **enabled** ticket is attached to it.
4. **Closures take days off**

   A [closure](/selling/closures) hides specific dates from the booking calendar, such as bank holidays or a maintenance week.

[Events](/selling/events) are different: they are a one-off ticket for a single date, with their own capacity, and don't need a slot.

## How a booking happens

1. The customer picks a session and tickets. Their places are **held for 15 minutes** while they pay.
2. They pay online. The booking becomes **Confirmed** and they get a confirmation email.
3. If they don't pay in time, the hold expires, the places are released, and the booking shows as **Expired**.
4. Everyone riding who hasn't signed your [waiver](/daily/waivers) is emailed a link to sign it.
5. On the day, you [check them in](/daily/check-in).

> **Note**
>
> If a payment somehow arrives after a hold has expired, the customer is refunded automatically.

## Next

- [Sign in to the portal](/getting-started/signing-in)
- [Take a tour of the portal](/getting-started/portal-tour)
- [Follow the setup checklist](/getting-started/setup-checklist)

Source: http://localhost:4321/getting-started/index.mdx
