An event ticket sales page for small events, and where it stops

Is a payment link enough for your event?

What the page needs

• The essentials first: event name, date, start and end times, venue and town, all above the first button.
• Each ticket type with what it includes: standard, concession, VIP, early-bird. Name the currency next to every price.
• What buyers get after paying: "You'll get a receipt by email; your name will be on the door list". People worry when there's no ticket.
• Refund and transfer policy, in two or three sentences, with a link to the full version.
• Access information: step-free entry, seating, quiet space, age limits.
• A contact for questions before buying, so nobody buys to ask.

Setting up the payment link

To sell tickets on your website with Anticode, create a checkout link in your own provider: Stripe Payment Links, PayPal, Gumroad, Lemon Squeezy, Shopify or Whop. There's one payment link per account, so every ticket button opens the same checkout; set it up as a product list or multi-item checkout that offers each ticket type. The payment, receipt and refunds all happen at the provider, so check its own settings for collecting buyers' names, any custom questions you need (such as dietary requirements for a dinner) and whether it can cap the number of sales. Anticode doesn't see payments, so it can't know when you've sold out.

Write each ticket's product name at the provider clearly, such as "Spring Social, 12 April, standard ticket", because that's what appears on the buyer's receipt and on your sales export. The payment links page explains how buttons are pointed at checkout links.

Running the door without scanning

1. Export the sales list from your payment provider the day before.
2. Sort it by surname and print it, or load it on a tablet.
3. Tick names off as people arrive; ask for the email used to buy if a name is missing.
4. Keep a few spare places for the inevitable mix-up, and decide in advance whether you sell on the door.

For a free event with registration rather than sales, use a form instead of a payment link, and send each registration to a Google Sheet through a connector; the webinar registration and RSVP website pages cover that case.

Building the page

Describe the event: "a ticket page for a 40-seat jazz supper club on 12 April at the Grain Store, with standard and student tickets, the menu, access info and refund policy". The Architect plans the sections; include your payment link in the request, or add it to the buttons afterwards. Use your own photos of the venue or past events rather than generic crowds. If several dates are on sale, give each date its own section, offer each date as an option in the provider's checkout, and say plainly when one sells out.

The gaps, plainly

• No capacity limit on the page. Nothing stops sales when you're full unless your payment provider can cap them. Watch sales and swap the button for "Sold out" yourself.
• No tickets, QR codes or scanning. Buyers get the provider's receipt; you run the door from a list.
• No seating plans or timed entry slots.
• No payments taken on the page itself. Every purchase goes through your provider's checkout.
• No embedded ticket widgets. Published pages can't embed a ticketing platform's checkout; link to it instead.

Questions people ask

Can I sell different prices for early-bird and standard tickets?

Yes, as two options in your provider's checkout or product list. Remove the early-bird option there, and its line on the page, when that price ends.

What happens if I oversell?

You'll need to refund through your payment provider. To avoid it, set a sales limit there if it offers one, or close sales a few places before capacity.

Can I link to Eventbrite or another platform instead?

Yes. Point the buy buttons at your event's page on that platform, and use your own page for the details, photos and FAQ.