# Events & ticketing

Events & ticketing lets you stand up a branded, hosted event page without writing any code. You create an event, define your ticket types, publish it at a public slug, and attendees buy admission over Mobile Money (MTN or Orange) right on the page. Every paid registration issues a ticket code, and sales settle into your Kwik Nkap merchant balance through the same collection engine that backs the public [Payments & Collections](/en/payments/overview) API.

:::note
Events & ticketing is managed in the Kwik Nkap **dashboard** ([app.kwiknkap.com](https://app.kwiknkap.com)) today. It is not yet exposed on the public developer API, which is currently limited to raw Mobile Money collections (`POST /v1/payments`, `GET /v1/payments`, `GET /v1/payments/{paymentId}/status`). Exposing events and ticketing on the public API is planned. The concepts, money movement, and statuses below describe the real product as it works in the dashboard.
:::

## What an event page is

An event page is a hosted, public web page that sells admission to a single event. You build it from a **`TICKET`** template, attach one or more **ticket types**, and publish it. Once published, the page is reachable at a public slug:

```text
https://pay.kwiknkap.com/events/<shortCode>
```

Attendees never need a Kwik Nkap account. They open the page, pick a ticket type, register, and pay over Mobile Money on the hosted checkout. The event page is bound one-to-one to the event behind it, so everything you sell on the page is a ticket type of that event.

## Core concepts

An event page is built from a small set of objects:

| Concept | What it is |
| --- | --- |
| Template (`TICKET`) | The starting design for a ticketing page. A `TICKET` template gives you a themed event page bound one-to-one to a single event. Some templates are free; premium templates are purchased once. |
| Event page | The hosted page you create from a `TICKET` template. It has a public `shortCode`, a title, a description, and your customized theme and content. |
| Event | The thing the page sells admission to. Each event page is linked one-to-one to its event. |
| Ticket type | A class of ticket on the event (for example General, VIP), each with its own price, capacity, and optional early-bird pricing. |
| Registration | An attendee's claim on a ticket. Created when an attendee registers, carries a `ticketCode`, and settles `SUCCESS` or `FAILED` with the Mobile Money payment. |

## Creating an event

You build an event from a `TICKET` template, then attach the event and its ticket types.

1. Create a page from a `TICKET` template, choosing a title and description. The page is linked one-to-one to an event.
2. Create the event, then add one or more **ticket types**.
3. Customize branding: upload images, edit the theme, and edit the page content and sections. You can preview the unpublished page before it goes live.

Free templates are usable immediately. For a premium template, the dashboard quotes an amount and you pay Kwik Nkap for it over Mobile Money (a platform collection from your own line). That purchase unlocks the template so the page can use it.

:::info
A template purchase is a separate money flow from your ticket sales. When you buy a premium template, money moves **from you to Kwik Nkap**. When an attendee registers on a published event page, money moves **from the attendee to your merchant balance**.
:::

### Ticket types

Each ticket type is a class of admission with its own price and capacity. For every ticket type you set:

| Setting | What it controls |
| --- | --- |
| Price | The ticket's base price in XAF (whole francs). |
| Capacity | The total number of tickets available for that type (`totalQuantity`). |
| Early-bird | An optional discounted price applied while the early-bird window is open. After the window closes, the base price applies. |
| Required fields | Information collected from each registrant at checkout (for example full name, email, phone). |

Remaining capacity for a ticket type is computed live as `totalQuantity` minus the registrations that are `PENDING` or `SUCCESS`. Both held states count against capacity, so a ticket in flight is not double-sold while the buyer is still approving the prompt. See [Registration lifecycle and capacity](#registration-lifecycle-and-capacity) below.

## Publishing

An event page stays private until you publish it. Publishing flips it to published and makes it reachable at its public slug:

```text
https://pay.kwiknkap.com/events/<shortCode>
```

Before publishing, you can preview the unpublished page to check theme and content. After publishing, the hosted page is served to attendees with your theme and content merged for their locale, and each ticket type enriched with its live remaining capacity and current price (early-bird or base).

:::tip
Preview the page before you publish. Confirm your ticket types, prices, early-bird windows, and required fields read correctly, since attendees see exactly what you publish.
:::

## The attendee flow

Attendees buy tickets directly on the hosted page. No account is required.

1. The attendee opens `events/<shortCode>` and browses the available ticket types with their prices and remaining capacity.
2. The attendee selects a ticket type and fills in any required fields.
3. The attendee enters their phone number and picks an operator (`MTN` or `ORANGE`), then registers.
4. A registration is created with status `PENDING` and a generated `ticketCode`, and a Mobile Money collection is initiated against your business.
5. The attendee approves the prompt on their phone with their Mobile Money PIN.
6. The hosted checkout polls the collection status until it settles. On `SUCCESS` the `ticketCode` becomes a valid ticket; the page may redirect to the success URL you configured.

```text
browse ticket types
   -> select ticket type
   -> fill required fields
   -> enter phone + operator (MTN | ORANGE)
   -> register  (registration PENDING, ticketCode generated)
   -> approve Mobile Money prompt on phone
   -> poll status until SUCCESS or FAILED
```

## Registration lifecycle and capacity

Event registration follows the same lifecycle as a Mobile Money collection:

| Registration status | Meaning |
| --- | --- |
| `PENDING` | Created at registration. Holds ticket capacity while the attendee approves the Mobile Money prompt. The `ticketCode` exists but is not yet a valid ticket. |
| `SUCCESS` | The collection settled. The `ticketCode` is now the attendee's valid ticket. |
| `FAILED` | The collection failed. The held capacity is released back to the ticket type. |

The `ticketCode` is generated the moment the registration is created, but it only becomes a valid, admissible ticket once the collection reaches `SUCCESS`. Because both `PENDING` and `SUCCESS` registrations count against `totalQuantity`, capacity is protected during the approval window without overselling: a ticket held by an in-flight registration cannot be sold to someone else until that registration either settles `SUCCESS` (keeping the hold) or fails (releasing it).

:::warning
A `PENDING` registration holds a seat. If you reduce a ticket type's capacity, remember that pending registrations still in their approval window are already counted against `totalQuantity`.
:::

## How the money settles

All amounts are in whole XAF francs. When an attendee registers and pays:

1. Registering creates a `PENDING` registration and initiates a Mobile Money collection against your business, the same collection primitive that backs the public [Payments & Collections](/en/payments/overview) API.
2. The attendee approves the request-to-pay prompt on their handset (MTN MoMo or Orange Money).
3. When the collection settles, a gateway callback flips the registration and its transaction to `SUCCESS` (issuing the ticket) or `FAILED`.

Settled ticket sales accrue to your Kwik Nkap merchant balance net of the application fee, the same way every [collection settles](/en/payments/overview). Payouts from that balance are handled by Kwik Nkap's internal disbursement flow, not by this product.

Separately, if you buy a premium template, that runs a platform collection from your own Mobile Money line (money from you to Kwik Nkap) and unlocks the template for your event page. That flow is distinct from your incoming ticket sales.

## Viewing registrations and sales

From the event's dashboard you can review:

- Paid registrations (`SUCCESS`) and pending registrations (`PENDING`), each with its `ticketCode`.
- Per-event and per-ticket-type sales.
- Remaining capacity per ticket type, computed live from `PENDING` and `SUCCESS` registrations.

This is where you reconcile who has a valid ticket and how many seats remain.

## Where this lives

Event pages are built and managed in the [dashboard](https://app.kwiknkap.com), and the published pages are hosted on `pay.kwiknkap.com`. They reuse the same Mobile Money collection engine as the public Payments API, but the event, ticket type, and registration objects are not callable through the public developer API today.

## Next steps

- Read [Storefronts](/en/products/storefronts) for the online-store sibling of event pages, built from the same hosted-page system.
- See [Payment links](/en/products/payment-links), the building block that hosted checkout reuses.
- Read [Payments & Collections](/en/payments/overview) to understand the collection lifecycle that settles every ticket sale.