How to sell and scan event tickets with Shopify POS

No. The web check-in page runs in any phone browser and needs no POS subscription, so a volunteer with their own phone can work the door. POS check-in is the better option if you already run POS, because door staff stay in one app instead of two.

In practice, reach for POS when you are also taking money at the door and the hardware is already standing there. Use the web page when you have borrowed phones, casual staff, or a venue where nobody is selling anything.

Both sides are drawing down the same number, right up to the last place. The event is a Shopify product, so a sale rung up at the register and an order placed on your website reduce one inventory count, and there is no second system holding a different figure. Selling some online and some at the door normally means exactly that second system, and you find out the two disagreed at the worst possible moment.

You also get one attendee list rather than two, whether the ticket was bought a week ahead or ninety seconds ago at the register. The register is reading the same number the website is.

What that number does not do is close the till. Shopify's help page on inventory tracking says the Continue selling when out of stock option "doesn't apply to Shopify POS", and that "Staff can continue selling products when available inventory reaches zero and below" (checked 13 August 2026). So the room closes on your storefront and the register can keep selling past it, which makes the last few places a decision for whoever is on the till rather than something the count settles for them.

Staff scan the QR code on each ticket, either from the check-in tile in Shopify POS or from the web check-in page using the phone camera. There is no separate scanning app for door staff to install and no scanner hardware to buy or charge.

When a code will not read, the two screens part company. The web check-in page has a box marked Ticket number that expects the number printed on the ticket, in the form #1001. Shopify POS has no such box, only a Search attendees field that takes a name, an email address or the ticket code, with a Check In button on the row it finds.

Out of the box a code admits one person once, and a second scan of the same ticket refuses rather than quietly admitting, which is the thing that stops one forwarded screenshot getting four people through. That is a setting rather than a law, and the section on re-entry below is where you change it.

The arrivals list on the door device refreshes every time that device scans, and it picks up anything a second door phone has scanned in the meantime. A screen that is not scanning shows what it showed when it loaded, so reload it before you read a count off it. Every check-in also has an undo, on the row in the list and on the confirmation that appears as you scan.

Through a link, not an account. Every event has its own check-in page, and you find it in the app under the event's Check-in settings, where it is labelled Check-in URL with a Start now button beside it. Open that link on the phone at the door and the scanner is there.

Nobody at the door needs a Shopify account, a staff invite or the POS app. That is the whole reason this path exists: the person working the door is often a volunteer, a friend of the promoter or one of the venue's own staff, and none of them belong in your admin.

The obvious worry is the other side of the same coin. Anyone holding that link can open the scanner, so the same screen carries a Check-in PIN. Set one and the page asks for it before it shows anything, and it is not a curtain over a page that has already loaded: without the PIN the scanner shows no attendee list, no arrival count, and refuses every check-in and every undo.

Staff type the PIN once on their device and carry on scanning. A sensible pattern is one PIN per event, written on the run sheet rather than sent in a group chat that outlives the night.

Any time, until you say otherwise. Each ticket type carries its own answer under When is check-in allowed?, and the four choices are Any time, Only during scheduled event time, Any time after event starts, and Custom start / end times.

Any time is the default and it is the right one for most rooms, because it lets you scan the queue that forms before doors open. Pick one of the others when scanning early is the problem rather than the point: a festival where Saturday passes must not work on Friday, or a members' night where the early arrivals are supposed to wait.

The two open-ended choices, Any time and Any time after event starts, also offer Ticket expires after (days). That is the one for a pass with a life of its own, like a ten-visit class card, and it counts from when the ticket was bought rather than from the event date. Leave it empty and tickets do not expire.

A ticket presented outside its window is refused rather than admitted, and the next section is the list of what the door staff will actually read on screen.

Not by default, and that default is a number you can change. Every ticket type has an Entrance limit, set to 1, described on the screen as the maximum number of check-ins allowed per attendee. At 1, the second scan of a code refuses and names the count it has reached.

Raise it when re-entry is part of the night. A limit of 2 covers a smoking area or a cinema interval where people leave and come back.

What the number cannot do is ration entries by day. Three is three scans in total, so a festival wristband set to 3 can spend all three on the Friday, which is why a multi-day pass is safer sold as one ticket per date.

The counter is per attendee, not per event, so the scanner can tell one person on their second entry from the person trying a friend's screenshot. In Shopify POS, an attendee found through search who has used every entry shows a Limit reached badge instead of a check-in button.

One thing to decide with it: Allow undo check-in is on by default and it is what lets staff reverse a scan made in error. Turn it off for a ticket type only if you need the arrivals list to be a record nobody at the door can edit.

It names the reason, and it is worth knowing the list before the night rather than reading it for the first time with forty people behind the person at the front.

Every scan runs the same six checks in the same order, the scanner stops at the first one that fails, and the seventh line below is the one you want to see:

The door stops, so this is worth planning around rather than discovering. Basements, marquees, old buildings and any room with 400 people on the same network will lose you a connection at exactly the wrong moment.

Each check-in is recorded as it happens, which means the door device needs a live connection at the moment it scans. You can add the check-in page to a phone's home screen and it opens instantly, because the page itself is kept on the phone, but the scan still has to get through.

Three things make this a non-event, and all three happen before doors rather than during them.

It happens at every event, usually because the confirmation went to a spam folder or the buyer sent someone else in their place. What you do about it depends on which screen the door is running, and the two are not the same, so it is worth knowing before you are the one holding the phone.

In Shopify POS, the check-in tile has a Search attendees box that takes a name, an email address or the ticket code. Find the person, press Check In on their row, and they are in without a code ever being scanned.

The web check-in page has no name search. It takes the ticket number, in the form #1001, or the ticket link pasted in. If the person can find the confirmation email on their phone the number is on it, and that is the quickest way through.

When they cannot, somebody with access to the app looks them up in the attendee list and either reads the ticket number back to the door or resends the ticket to their address while they wait. That is the reason one name on the run sheet needs admin access on the night.

The nearest upcoming one, chosen for you. On the web check-in page a repeating event has one link covering the whole series, and opening it lands on the next session by date rather than on the series as a whole.

A Timeslot picker sits at the top of that page with every session in the series and the number of attendees against each, so switching to tonight, or to the 11am slot rather than the 2pm, is one tap.

The failure worth knowing costs about ten minutes of queue. The picker is showing next Thursday, tonight is Tuesday, and every ticket number staff type comes back as not found - because those tickets belong to a session that is not open on that screen. Glance at the picker before doors, on every device.

Less than most people prepare. A charged phone per door, the event open on it, and a plan for what happens if the network goes. That is the whole list.

Ring it up in Shopify POS the way you would any other product. Card, cash and whatever else you accept work as normal, and the sale lands in the same reporting as the rest of the night's takings, so you are not reconciling a separate ticketing float afterwards.

For the full flow from creating an event to sending the ticket, see how to sell event tickets on Shopify.