Guide

How to restrict sessions to ticket holders with ticket-linked access

Limit sessions, chat and entry to people who hold the right ticket: set ticket types, link access rules, check at the door and read the access list.

To restrict sessions to ticket holders, define ticket types with prices, switch on ticket-linked access and set each session’s activity rule to require a ticket. A paid purchase creates the member and unlocks only what that ticket allows; the door scan then accepts or rejects the guest. Sociana shows the ticket-holder access list.

Who this guide is for

You run a conference or show with tiers: a general pass, a premium pass with workshops, a one-day pass, a sponsor pass. Some sessions are open to all; others are only for people who paid. You want the app to know the difference, so your volunteers are not arguing about wristbands at a door.

What goes wrong with manual tiers

Paper tiers rely on volunteers recognising colours. The workshop door has a queue and an argument. Exports of paid delegates are emailed and are out of date. A delegate who bought the premium pass cannot show proof, and one who did not walks in anyway. After the event, the organiser cannot reconcile who attended which tier.

Linking access to the ticket moves the decision from the volunteer to the system. The purchase is the key; the scan is the lock.

How tiers map to access

Ticket type Sessions open Chat and networking Entry pass Invoice
General Plenaries and open sessions As the organiser allows Yes On request or automatic
Premium General plus workshops Ticket-holder chat where enabled Yes Yes
One-day The chosen day only Limited Day-limited Yes
Sponsor Sponsor sessions and zones Sponsor zone Yes By arrangement
Complimentary As set by group As set by group Yes None

Your own tiers will differ; the principle is that each ticket type carries its own access.

Step by step

Step 1: Define the ticket types and what each unlocks

Write the matrix above for your conference before opening sales. Fewer tiers are easier to explain. Check which sessions have capacity limits.

Step 2: Create ticket types with prices

Each ticket is a type with a price, a purchase flow and an access rule. Buyers pay through Razorpay in the app or on a public web page, so people can buy without installing anything. See tickets and payments and public web flows.

Step 3: Turn on purchase-creates-membership

A paid ticket adds the buyer to the occasion with the matching role and groups, so there is no separate import. At BWF Meet Up 4.0, networking unlocked after registration and payment, and My Booked Tickets showed the reference, amount paid and invoice PDF.

Step 4: Link the entry pass

Switch on ticket-linked access so that the entry pass and the sections the ticket allows appear only for ticket holders. The personal QR is the same one used at the door.

Step 5: Set the activity rules to require a ticket

For each restricted session, create an activity and set the ticket requirement and group eligibility. A scan by a person without the ticket is rejected and logged. See QR attendance and activities and the how-to on checking in guests with QR codes.

Step 6: Limit chat where it matters

Where enabled, chat can be restricted to ticket holders, which protects the value of a paid tier. Decide whether general-pass holders can message premium holders.

Step 7: Test every ticket type

Buy one of each as a test, with a test payment if your gateway offers it, and walk through the app: what appears, what is locked, what the door scan says. A locked section shows a padlock, which is a scheduling and access decision, not an error.

Step 8: Reconcile after the event

Read tickets sold by type, payments and invoices, and the ticket-holder access list. Compare attendance by tier with sales. Use the ticket revenue and fees calculator when you plan next year’s tiers.

Writing the ticket matrix

Before you configure anything, put the matrix on a single page and share it with finance, the programme team and the person who runs the door. Each row is a ticket type; each column is a session, a zone or a feature; each cell is yes, no or limited. Add a column for price and a column for capacity.

Ask the door lead to read the matrix aloud and spot any row that would be hard to enforce. Then build exactly what the page says. When a delegate calls the helpdesk to ask why they cannot enter a session, the answer should be on that page, not in anyone’s memory.

Checklist before sales open

  • Each ticket type has a price, an access rule and a capacity where relevant.
  • The purchase flow works on the public web page and inside the app.
  • Purchase creates membership, and the correct role and groups are applied.
  • A test purchase of each ticket type has been walked through, from payment to door scan.
  • Invoices are available and the billing details match what finance needs.
  • Restricted sessions have activities that require a ticket.
  • The helpdesk knows what to do when a payment clears but access does not unlock.
  • The refund and transfer policy is published and linked from the purchase page.

Once sales open, check the first ten purchases by hand. Early mistakes in a ticket rule are cheap to fix before the hundredth buyer.

Pitfalls

  1. Too many tiers. Keep them explainable.
  2. Selling a session beyond capacity. Cap it.
  3. No path for a payment that failed to unlock. Staff a help desk and set a policy.
  4. Skipping invoices. Business buyers need GST invoices.
  5. Treating Sociana as a ticket marketplace. It is not; it ties tickets to access.

India and SAARC notes

UPI processed about 208.8 billion transactions in 2025 and accounts for 84% of India’s digital payments (NPCI data via Wikipedia, 2025), so paying for a ticket by UPI inside a checkout is normal for Indian buyers; keep the flow short. B2B buyers expect GST invoices and may need company details at checkout. For delegates in Sri Lanka, Nepal, Bangladesh or Bhutan, Razorpay does not settle in those countries; offer an invoice or offline route. Sociana is not a ticketing marketplace or consumer event-discovery service and states gateway fees at actuals rather than a commission.

How Sociana handles this

A ticket in Sociana is a type with a price, a purchase flow and an access rule. A successful purchase creates the member record and unlocks the sections the ticket allows. Organisers see ticket types, sales and access status in the admin panel and in exports, and can link purchase to the entry pass. The Download Invoice action saves the invoice as a PDF where one exists. The APMI 3rd Annual Conference combined a registration whitelist with paid meeting-room slots through Razorpay; the BWF Meet Up 4.0 case showed tickets and invoices with ticket-linked networking. Try the ticket checkout and invoice demo.

FAQ

Can free sessions and paid sessions live in the same app?

Yes. Activities carry their own rules, so open sessions need no ticket while restricted ones require it.

What does a person without a ticket see?

Sections not unlocked by their ticket may show a padlock or stay hidden, depending on how you set the layout. Test it before the event.

How are refunds handled?

Refund policy is the organiser’s, handled through the payment gateway. Decide it before sales open and publish it.

Does the door scan check the ticket?

If the activity requires a ticket, a scan by a non-holder is rejected and logged.

Glossary: ticket-linked access, QR entry pass, attendance rule, whitelist. Occasion hubs: conferences, exhibitions, festivals.

Want us to run this for you?

Our team sets it up for your event, checks it with your desk and runs it with you on the day.