Ticketing for Zoos, Gardens & Aquariums

The vertical decides the vocabulary, the questions asked at checkout, the inventory model, the door, the payout terms and the theme. This page says "admission" and "visit" because that is what a attraction says; a config whose primary call to action is generic ticketing wording fails validation rather than shipping.

Who this is not for. Excludes major zoos on enterprise contracts. If that is closer to your operation, the vertical you want is probably a different one — all twenty are listed here.

Everyone arrives at eleven, and the car park is the real capacity limit

An attraction with no arrival times has a Saturday that happens between eleven and one. The car park is full while the far end of the site is empty, the queue at the kiosk is longer than the queue for the penguins, and the number the fire officer or the licence actually cares about is being estimated by a volunteer with a clicker. The same staff then work a three o'clock that is a third as busy, and nothing about the day is repeatable enough to plan the next one from.

What bindro does: An open day is generated as a grid of arrival slots, and each slot holds its own inventory pool for every admission type on sale. The shape of the day is therefore decided in advance instead of discovered at half past eleven: a morning slot can hold forty and the noon one eighty, and a slot that fills says so and stops selling. The pool moves only under a row lock inside the transaction that takes the money, so the last family in the 11:00 slot cannot be sold twice in the same second. Capacity is editable while a slot is live — upwards freely, and never below what has already sold, which the database refuses outright — and the day-of screen shows what is left in each slot while you are open.

Half the queue says they are members, and the folder at the gate is the only check

Members are the floor under a small attraction's income and the least automated part of it. At the gate the scheme is enforced by somebody recognising a face or reading a card that expired two summers ago; online it is usually worse, because either members cannot book at all and turn up expecting to walk past the queue, or the member rate is a checkbox anybody can tick. Nobody finds the difference until the month is being reconciled, by which point the discount is given and the visit has happened.

What bindro does: A membership number typed at checkout is looked up in your own roster at the moment the card is charged, and the member price is derived on the server rather than read off the page the buyer is looking at. A number that has lapsed, been revoked or was never on the roster fails on that box instead of quietly charging list price and leaving you the argument at the gate. Read the limit as carefully as the capability: this verifies memberships and never sells them. The roster is typed into the console one person at a time — a name, a number, an expiry — with no import, and only a hash of the number is stored, so the page can never read a working number back out to anybody who reaches it.

The conservation appeal is a bucket by the exit that most people walk past

For an attraction that is a registered charity, the gift is often worth more per head than the admission, and it is collected in a perspex box beside the exit at the end of a day when nobody is carrying cash. The people most likely to give have already decided to come and are sitting at home with a card in their hand, and nothing on the booking page asks them. Raising the entry price instead is the usual answer, and it quietly destroys the only part of the money that was ever deductible.

What bindro does: The donation box sits on the order beside the admission rather than inside its price, and that distinction is the whole point of it. A gift is neither fee base nor tax base, so the platform earns nothing on it and no sales tax is computed on it, and the full amount is credited to the attraction with the rest of the proceeds. A receipt goes out beside the confirmation naming only the donated part as deductible, and stating the zero case in words when there was no gift at all. One setting gates the lot: until a registered charity number is saved in the console nothing is issued, and the reports page says so rather than failing quietly.

The gate hut is at the end of a drive where nothing connects

Attractions are frequently in the worst places in the country for a network: a walled garden, a farm track, a listed lodge nobody may drill through, an aquarium basement, or a router four hundred metres away in the office. A gate that needs a connection is a gate that stops on the busiest afternoon of the year, and the fallback — a printed list and a biro — means that day's attendance never reaches anything the quarter can be reported from.

What bindro does: The door is built offline-first rather than patched for it. A device pulls a signed manifest for the session while it still has signal, validates every code locally with no network call at all, and uploads its scans when it next reaches a connection; a log sent twice by a flaky line applies once, so a bad afternoon cannot inflate your attendance figures. Two entrances scanning at the same time raise a conflict you read afterwards rather than a refusal in front of a queue. When a code will not read at all — cracked screen, flat battery, confirmation in a spam folder — the console has a searchable visitor list with a tap to admit, which keeps that visit inside the numbers instead of outside them.

The Christmas evenings are sold on one system and the day gate on another

The seasonal overlay is where a small attraction makes its margin: illuminated evenings in December, a spring bulb fortnight, late openings in the school holidays. Because they price differently and run outside normal hours, they usually end up on a second platform with a second set of fees, a second export and a second gate procedure — and the question every pass holder asks at the barrier, which is whether their card gets them in tonight, has two different answers depending on who is asked.

What bindro does: A seasonal run is published as its own event with its own arrival slots, its own tiers and its own pass, on the same platform and the same gate device as the day operation. Priced tiers let an adult, a child, a concession and a member rate sit side by side with separate stock in each slot, and the roster check that gives a member price works across every event you publish. The boundary worth knowing before you advertise anything is the pass: an annual pass admits at the dates of the event it was sold under and nowhere else, so a separately published light event needs its own tier for pass holders — or its own pass — rather than an assumption at the barrier.

The trustees want the quarter and the tea room takings are in a different book

A small attraction reports upwards far more often than it is resourced for: a board pack every quarter, a return to the funder whose grant paid for the education officer, an accreditation return, a line for the local authority. The figures live in three places — the booking export, the bank statement, and somebody's memory of which days were free entry — and reconciling them costs a weekend belonging to the person who can least spare one. A year later nobody can reproduce why the number was that number.

What bindro does: The grant and board report is a quarter-by-quarter table you print for the pack or download as a CSV: sessions delivered, admissions registered, visitors actually scanned in, free places given, gross, refunded and net. The money lines are read from the ledger the payouts reconcile against rather than re-summed from order rows, so they agree with the money page to the cent and agree with it again next year. Two limits before you promise a funder anything: it is your report to submit, because nothing is transmitted to anybody on your behalf, and it counts only money that moved through the platform — a grant, the shop float and the café till are not in it.

A season of open days generated from a pattern, not typed one date at a time

You give a date range, the arrival times you want to run, how long a slot lasts and a capacity, and every time on every day is created as a session with its own inventory pool per admission type. Twenty-four entry times a day is the ceiling and two hundred sessions is the bound on one generation, so a month of half-hourly arrivals is a single pass and a summer is a handful of them. Days you are closed are simply not generated — there is no closure switch to lean on afterwards, which is why the calendar is worth getting right at the start.

• Arrival slots per open day, each holding its own stock for every admission type.
• Per-slot capacity, so the quiet first hour and the eleven o'clock rush are different numbers.
• Up to twenty-four entry times a day; two hundred sessions per generation.
• Capacity is editable while a slot is on sale and can never be cut below what has already sold.

Member prices settled on the server, against a roster you control

Member pricing is a verify-at-checkout rule and it is honest about being exactly that. Any admission type can publish a member rate; the visitor gives their number; the server looks it up in your roster and settles the price there, inside the transaction that charges the card. A current member booking a type that publishes no member rate simply pays list price, because a valid membership is never a reason to refuse a booking, and a lapsed one is told on the box rather than charged the difference in silence.

• The roster is a name, a number and an expiry, typed into the console one at a time.
• Numbers are stored hashed, so the roster page cannot hand a working number back out.
• No import, no renewal reminder, no billing and no card on file: this checks memberships, it does not sell them.
• Nothing adds a buyer to the roster automatically — not an annual pass, not a gift card.

An annual pass that admits at every date of the event it belongs to

An annual pass is a ticket tier with its own stock whose holder is admitted at every session of the event it was sold under, including from an offline gate manifest, without booking a slot each time. That is the right shape for unlimited daily entry on a published season, and it carries one limitation stated in the migration that created it rather than left to be found: a pass takes a seat at none of the slots it opens. An attraction with a genuine ceiling — a car park, a glasshouse, an aquarium tunnel — has to size its slots for the pass holders it expects as well as the admissions it sells.

• Admits at every session of its own event; opens nothing on a separately published one.
• The pass tier's own pool bounds how many passes exist, not how many visits they make.
• Works from the offline manifest, so a pass holder is admitted with the network down.
• Sold like any other tier, at any price, with a member rate of its own if you want one.

Donations that reach the attraction whole, and receipts that claim only what is true

The gift is added to the order rather than to the price of entry, which is what keeps it deductible and what keeps it out of the fee. Nothing is charged on it, no sales tax is computed on it, and the whole amount is credited with the rest of your proceeds. The receipt quotes only the donated part, because money folded into a higher admission price is not a gift at all — the visitor received goods and services worth what they paid — and a receipt that says otherwise is worse for a charity than no receipt.

• No platform fee and no sales tax on the gift; it is credited to you in full.
• Receipts are issued only once a registered charity number is saved, and the reports page says so until then.
• The zero case is stated out loud when an order carried no gift.
• A refund reverses the gift along with the rest of the order.

A gate that works with the network off, at more than one entrance

Offline is designed in rather than bolted on: the device downloads a signed manifest while it has signal, admits from it with no connection, and replays afterwards, and the upload is idempotent so a log sent twice counts once. Be clear about what this is before planning around it. The offline path is an API and there is no bindro scanner app to install, so a genuinely disconnected second entrance needs somebody technical before opening day; what works out of the box is the console's searchable visitor list with a tap to admit.

• A signed manifest per session, validated locally with no network call.
• Re-uploaded scan logs apply once, so attendance cannot be inflated by a bad line.
• Two gates scanning at once produce conflicts to read, never a refusal at the barrier.
• A returning visitor is readmitted at the gate that let them in; the same code at another gate reads as already used.

The kiosk, the shop and the café in one day's numbers — with only one in the ledger

An attraction that cannot sell to the family who drove up without booking is turning away its easiest income. A walk-up admission takes a card on the operator's own device and runs through exactly the same checkout as the website: the same server-derived price, the same inventory lock, the same credential in the same pool. The shop and the café are catalogues whose sales are recorded against the day. One thing is deliberately not implemented, and it is the difference between the two: a cash admission cannot be recorded, because crediting your balance for money the platform never held would pay you for the same sale twice at payout.

• Card walk-ups at the kiosk, drawing on the same slot stock as an online booking.
• Shop and café takings recorded against the day as an auditable record of your own.
• Till takings never enter the platform ledger — that money is already yours.
• Back-office orders for the phone booking, the coach party of nine and the correction.

Parking, keeper talks, gift cards and the codes that fill a wet Wednesday

Anything you can count sells beside the admission with its own finite stock, which is what a car park space, a keeper talk, a behind-the-scenes tour or a bag of animal feed actually is. An admission is fixed to a date and a slot and cannot be handed on, so the giftable instrument is a gift card rather than a ticket: it is emailed as a code to the person receiving it, valid for two years, and spent as real tender against any booking, with a larger booking charged the difference.

• Add-ons carry per-variant stock, so twelve parking spaces means twelve.
• Gift cards are held as a liability until redeemed, which is why unredeemed value cannot be paid out to you.
• Promo codes carry their value on the code; the browser is never trusted to name an amount.
• Comp admissions consume real stock and scan exactly like a sale while writing no revenue lines — the trustee, the lender, the local paper, the volunteer's family.

Sales tax, refunds visitors do themselves, and the disputes nobody plans for

US sales tax, at a rate you set, is applied on top of the admission and computed on the discounted amount by the server, itemised on the pay page so the visitor sees it; leave the rate at zero if your admissions are exempt and nothing is added. Visitors refund themselves in full from the link in their own confirmation right up until their arrival slot begins, which is the single biggest reduction in inbox volume this vertical gets, and after that the decision is yours from the console.

• Refunds are one order at a time: there is no bulk refund and no way to clear a whole day in one action.
• Refunds reverse in a fixed order — your proceeds, then tax, then the platform fee.
• Chargebacks debit the attraction in full and are applied idempotently by provider reference, so one dispute cannot land twice.
• Financial reports per event come off the ledger the payout reconciles against.

Your own website, our page, or both selling the same arrival slots

Most attractions already have a site a designer or a volunteer built, and asking visitors to leave it is where bookings are lost. There is a hosted page per event that works on a phone held in one hand in a car park, and an embeddable checkout for the site you already have — and both sell the same pools, so there is no second set of numbers to reconcile and no way for the two to oversell each other. The visitor record persists across seasons, and names and addresses are anonymised two years after somebody's last visit, while the answers typed on an order are not.

• A hosted page per event with the date picker, the arrival picker, tiers and add-ons.
• Embedded checkout on your own domain, selling the same stock as everything else.
• The booking fee is the visitor's by default, yours to absorb, or split — per event.
• Access requirements are classed as health information: out of exports, out of the funder breakdown and out of AI context, with no override.

Who pays the booking fee?

The visitor, unless you say otherwise. Every visit carries its own setting — the visitor pays, you absorb it, or you split it — and the fee itself does not change with the choice, only which side of the sale it comes from. On a ten-admission $25.00 visit that is $16.20 either added to what visitors pay or taken out of what you keep.

Because the default is the visitor, a attraction can go from signing up to a sold-out visit without paying bindro anything up front, at any point, ever. We are paid out of sales that happened or we are not paid.

The word "event" is load-bearing and worth reading twice. The scheduler groups by visit, admits one only once its LAST session has ended, and pays it once. A visit sold as a run of dates therefore pays after the final date, not after each one — a season's float is not something an operator should discover halfway through the season.

Bindro never pays before delivery, in any vertical. A pre-event advance is a configuration violation platform-wide rather than a policy someone can be talked out of, because paying out on visits that have not happened is exactly how a cancellation becomes visitors with no refund. "Paid" also means the money moved: a payout only reaches its paid state with a real transfer reference attached, enforced by the database rather than by a status field someone can set.

• One payout per visit, after its last session ends, one in flight at a time.
• T+2 for this vertical (low risk tier), no reserve.
• Refunds reverse in a fixed order — your proceeds first, then tax, then our fee — so a refund never leaves you charged for a sale that was undone.
• Sales tax, where it applies, is held as a liability rather than mixed into your balance, so the payout figure is proceeds rather than a number you still have to do subtraction on.

How finely you can read that number is decided by how you publish the calendar, which is the one thing on this page worth deciding before you sell anything. Money groups by event and attendance groups by session, so a whole year published as one long event gives you a single gross figure and 365 attendance rows, while the same year published month by month gives twelve of each and lets you put February beside May without exporting anything.

Of the three measures this vertical is built around, seasonal event uplift is the one the platform serves best — and only if you publish the seasonal run as its own event. Done that way, the illuminated evenings settle on their own, report as their own line and can be compared with the ordinary week beside them. Run as extra tiers on your normal arrival slots, that income sits inside the month's figure and is separable only by exporting the orders and filtering them yourself.

Membership renewal rate is the harder truth, and the honest answer is half a number. The platform can tell you how many admissions went at a member price, because that is a priced tier on an order — but not how many people joined or renewed, because nothing here ever sells a membership. Members reach the roster by somebody typing them in, so the renewal figure a board asks for is assembled from your own scheme on one side and member-rate admissions on the other.

Spend per visitor in the shop and the café is the case where the till being a record rather than a payment rail changes what you can compute. Those takings are written against the day and exported with everything else, so spend against scanned visitors is a division you can do per open day today — but they are deliberately absent from the ledger and therefore from the money page and the funder table, because that money was never ours to hold and crediting it would pay you twice.

What the console shows today, without an integration or a spreadsheet:

• Gross, platform fees and refunds per visit, read from the ledger the payouts reconcile against.
• Admissions sold against visitors checked in, with a no-show percentage per session.
• Live remaining capacity while the visit is running, per pool, on the day-of screen.
• This attraction's own funnel — view → slot selected → checkout → paid → attended → member joined — stage by stage with the drop-off between them, and any step the platform cannot see said so rather than shown as a zero.
• Refunds, transfers, turnout, no-shows, add-on attach and repeat buyers, each printed with the two numbers it was divided from.
• Orders and visitors as CSV, so anything not on the screen is one export away.

Two more that are worth stating plainly. Sensitive answers are classified on the field rather than by convention, and health data is excluded from analytics exports and from AI context absolutely, with no override in any vertical. And a attraction's own people see only what their role allows — a door login sees a name and whether the code admits, not what anyone paid — which is checked in the handler rather than by hiding a button.

• bindro does not sell, renew or bill a membership. There is no recurring charge anywhere in the product, no renewal reminder, no membership card, no household or add-a-member logic and no lapsed-member sweep. The roster that unlocks member prices is typed into the console by hand, one member at a time, with no CSV import — and buying an annual pass adds nobody to it. Whatever runs your membership scheme today keeps running it.
• An annual pass admits at the dates of its OWN event and nowhere else. A pass is a ticket tier flagged as a season pass, so it opens every session of the event it was sold under — and a Christmas light event, a members-only evening or a summer festival run as a separate event is not covered by it. Nothing bundles two events into one entitlement, and the gate will read the pass as unknown at the other event rather than admitting it.
• A season pass consumes no slot inventory. A pass admits its holder at every arrival slot of its event and takes a seat at none of them, so an attraction with a real capacity limit — a car park, a glasshouse, an aquarium tunnel — has to size its slots for the pass holders it expects as well as for the admissions it sells. Nothing warns the gate that a busy slot is fuller than the number on the screen.
• No group product and no school invoicing. Group registration is not enabled for this vertical, so there is no group rate, no roster for a teacher to fill in and no per-place name collection, and billing on terms is a separate capability this vertical does not resolve. A school visit is a quantity of ordinary admissions on one card payment; anything on an invoice is an arrangement you make off the platform.
• No waiting list, and a refund does not put the slot back on sale. When an arrival slot is full the page says fully booked and stops: nobody joins a list and nobody is emailed when an admission is refunded. The count of what has sold is never decremented, so if you want to let one more family in, raise that slot's capacity by one rather than waiting for a cancellation to free it.
• No transfers and no date changes. A visitor who cannot come on the Saturday cannot hand their admission to a friend and cannot move it to the Sunday: this vertical resolves neither ticket transfer nor deferral, and there is no credit note to issue. The only lever is a refund, after which they book again at whatever is on sale. A gift card is the giftable instrument; an admission is not.
• bindro cannot close a day, and cannot email the visitors booked into it. Nothing in the product predicts weather, so a storm closure is your call to make. Once you make it, closing the day settles every booking on it at once and writes to each visitor if you ask — but that is the only message bindro sends: the automatic post-visit email goes to opted-in buyers of a visit that has already happened, and telling tomorrow's visitors anything else is your own channels' job.
• Re-entry is performed by the gate, not just permitted by your policy. A visitor who leaves for the car park and comes back through the gate that admitted them is scanned in again as a return, with the time they first arrived; the same credential at a different gate reads as already used and names the one that used it, which is the phone-over-the- fence case. Attendance counts each visitor once however often they are scanned.
• Cash is not a ticket sale, and the till is not a payment rail. The walk-up gate sale takes a card on the operator's own device; recording a cash admission is deliberately not implemented, because crediting your balance for money bindro never held would pay you twice at payout. Shop and café takings recorded at the till are an auditable record for your own numbers and never enter the platform ledger — that money is already yours.
• No wristbands, no staff rota and no photo sales. RFID wristbands, staff scheduling and media delivery are listed as optional for this vertical and none of them is enabled, so there is no band to bind, no shift to publish and no ride or safari photo to sell. The credential is a QR code, the rota lives wherever it lives today, and a photo concession is a separate arrangement.
• United States only, so no VAT. Onboarding offers one country, and the tax the engine applies is price-exclusive US sales tax added on top of the admission; inclusive VAT is a separate capability this vertical does not resolve, and nothing anywhere claims Gift Aid on a donation. An attraction outside the United States cannot be onboarded today, whatever its currency looks like on the page.

If one of those is the thing you need, say so — the answer is a capability declared, built and gated properly, or a straight no. It is never a feature flag that collects the request and does nothing.

The mechanism is set out in the payout section above; what matters here is what it implies for an attraction's calendar. This vertical sits in the low-risk tier, which is the shortest delay the platform runs and holds no reserve back at all — but the clock starts when the event ends, not when the visitor pays, and that is the part people plan around wrongly. Monthly or seasonal events cost a little more setup, since each is its own generation of arrival slots and its own page, and buy you cash arriving through the season rather than after it.

There is a real cost to splitting and it is not the setup. Reporting groups by event too, so twelve events mean twelve financial reports rather than one annual figure, and a visitor browsing sees several pages instead of one long calendar. The quarterly grant and board table is unaffected either way, because it is computed from the ledger across whatever events fall inside the quarter — which is usually the reassurance that makes the decision easy for a board that reports quarterly anyway.

The seasonal run is the case where the answer is not merely convenient but structural. Illuminated evenings in December published as their own event settle on their own, about a week after the last night rather than after next August, and report as their own line when somebody asks whether the lighting hire was worth it. That is the same decision as the pass question below, arriving from the money side instead of the gate side, and the two answers have to agree with each other.

There are two workable shapes and the choice is yours. Put the evenings on the same event as daily entry, as extra sessions with their own tiers, and the pass admits at them — at the cost of one payout covering both, released after the last session of the whole thing. Or publish the evenings separately, settle them on their own, and sell pass holders a discounted evening tier or a second pass. Whichever you choose, say it on the pass's own description, because the barrier cannot explain it for you.

Size the slots for pass holders either way. A pass consumes no slot stock, so on an ordinary Wednesday the difference is invisible and on the first Sunday of the school holidays it is the gap between comfortable and over the number the licence names. The practical approach is to hold back a share of each slot's capacity rather than selling every seat, and to watch the day-of screen against what actually comes through the gate for the first few busy days of a season.

Choose what happens to the money — refund everybody to the card they paid with, credit everybody for another visit, or keep their booking for a date you will offer — and it is applied to every booking on the day at once. Nothing is preselected. Tick the box and each visitor is written to once, after the money has actually moved, saying which of the three happened to theirs; that is the only bulk message bindro sends, so anything else still goes out through your own channels.

Timing matters more than most attractions expect. Until an arrival slot has started, every visitor can refund themselves in full from the link in their own confirmation, with no notice window to configure. Deciding early and announcing early therefore does a good share of the work for you; once the slot has begun, every refund is yours to issue by hand. The animal-welfare closure at short notice is the hard case, and the only lever that helps is a closure policy on your own site that says what you do.

The part that catches people is the payout. A closed day drops out of the payout schedule rather than delaying it, so closing the last open day of an event can bring your payout forward; close every date and there is no delivered date left to settle against, so nothing is paid out until you have settled it. Refunding or crediting in bulk is an owner or finance action, which is worth agreeing before the season.

The country question comes first because it is absolute. Onboarding offers the United States, the tax the engine applies is price-exclusive US sales tax, and there is no inclusive VAT and no Gift Aid anywhere in the product despite the vocabulary a British garden would expect. An attraction outside the United States cannot be onboarded today, and nothing else on this page changes that.

The second is the schools and groups question, and it is the most common reason an attraction should choose something else. There is no group rate, no roster for a teacher to fill in, no per-place name collection and no invoice on terms; the party size question is stored and shown to you and prices nothing. If a third of your admissions are invoiced school visits, weigh that before anything else here, because the workaround is an arrangement you make off the platform and record yourself.

Then rehearse the gate, which takes half an hour and settles the evaluation. Comp yourself four admissions across two arrival slots, walk them through the real entrance on the real device with the network switched off, and let the upload run when you get back to the office. Comps consume real stock and scan exactly like a sale while writing no revenue lines, which makes them the right instrument for it — you are testing the gate, not polluting the quarter. If your entrance is a hut where nothing connects, that half hour is the whole decision.