Capabilities

TicketFlowactivated with our team

Collect before the door.

Paid attendance that lives inside the event: ticket types on the same event record, a checkout that issues an ordinary entry code, and a door that already knows who has paid.

Paid attendance belongs inside the event workflow, not beside it.

Talk to Sales See how it works

Activated with our team. Because payment set-up depends on your event, currency, commercial model and payment requirements, we configure it with you before it goes live.

One guest, from a held place to the door. The name and the figures are invented.

The problem

Money at the door is a queue, a spreadsheet and an argument.

When some guests pay to attend, the payment usually lives somewhere else: a form, a transfer, a spreadsheet kept by whoever sent the invoice. On the night, the door works from the guest list, the finance person works from the payment list, and the two were last reconciled on Tuesday.

So a paid guest is not on the list, an unpaid one is, somebody pays at the door with no receipt, and the report at the end says how many came but not how many paid. None of that is a people problem. It is two records where there should be one.

Where it goes wrong

01
The guest has paid and is not on the list
The transfer arrived this morning; the list was exported last night. The guest waits while somebody searches an inbox.
02
The guest is on the list and has not paid
They were added when they said yes. Nobody checked whether the payment ever followed.
03
Cash at the entrance
A receipt written by hand, a float to count, and no record that ties the money to a name.
04
Two teams, two systems
Tickets were sold on one platform and the door runs on another. The check-in staff has a second phone and a second login for the night.

The model

From the event to the attendance record, in one line.

Every step below writes to the same event. A buyer becomes a guest, a payment becomes an entry code, and the door reads what the checkout already settled.

A working model of the path an order takes. Nothing here is charged or sent anywhere.

01Event
The same event that holds the invited guests. Ticketing is switched on for it, with a currency and a refund policy.
02Ticket types
Standard, member, student, a complimentary type at zero — each with its own price, capacity, sales window and visibility.
03Order
A buyer chooses on the event’s own sales page. Their places are held for fifteen minutes while they pay.
04Payment
The checkout is hosted by the payment provider. Winglark never sees a card number, and the price is set on the server, never by the browser.
05Confirmation
The order is marked paid and a confirmation with the tickets goes out through the same sending as invitations.
06Entry code
Each ticket becomes a guest record with an ordinary entry code — the same kind an invitation carries.
07The door
Any phone scans it. The door does not ask whether the guest paid; the code exists because they did.
08Attendance
Checked in, and counted with everyone else in the event’s report.

How it works

How it works, once it is switched on

See it in the full walkthrough

01
Ticketing is opened on the event
With our team: the currency, the refund policy, the sales window and how visible the sales page is — public, unlisted or private.
02
Define the ticket types
Name, description, price, capacity, minimum and maximum per order, and whether the type is shown or hidden. A zero price is a free ticket.
03
Open sales
Draft, scheduled, on sale, paused, sold out, closed. The sales page follows the state, and a sold-out type says so before anyone tries.
04
Orders arrive
Each order is held, paid, then fulfilled: a guest record and an entry code per ticket, and a confirmation to the buyer.
05
Refund when you must
A full refund returns the money through the payment provider first, then revokes the tickets — the door refuses a revoked code, online or off.

Before the door

Payment is resolved before anyone reaches the entrance.

By the time a buyer arrives, the question of whether they paid was answered — by the checkout, hours or weeks earlier. The door only has to recognise a code.

The door sees one answer: Admitted, already in, revoked, not found. Never “let me check whether they paid”.
You know who has completed payment: Held, awaiting payment, paid, fulfilled — every order in one state, on one screen, before the night.
Buyers hold the right thing: A confirmation and an entry code, delivered to the address they gave, resent if they lose it.
Fewer manual checks: No payment list at the entrance. A refunded ticket is already revoked; an unpaid order never became a code.
One report at the end: Paid guests and invited guests are counted together, because they were on one list all along.

Orders on the left, the door on the right. Only a paid, fulfilled order becomes a code the door can admit.
Order	Payment	Entry code	At the door
WT-0F44A4	Paid	Issued	Admitted
WT-1C09B2	Paid	Issued	Admitted
WT-2A71E8	Awaiting	—	No code
WT-3D5F10	Refunded	Revoked	Refused
WT-4E22C7	Paid	Issued	Admitted

Orders on the left, the door on the right. Only a paid, fulfilled order becomes a code the door can admit.

Kinds of attendance

Paid, complimentary and invited, on one list.

A ticket type is a price, a capacity, a sales window and a visibility. Invited guests stay invitations. All of them end at the same door.

Paid types: As many as the event needs — early, standard, member — each with its own price and capacity in the event’s currency.
Complimentary types: A type priced at zero is a free ticket: same sales page, same confirmation, same entry code, no payment step.
Hidden types: A type can be kept off the public list and shared with the people it is for.
Invited guests: A guest you invite is not a ticket and never sees a checkout. Paid and invited guests share the list, the door and the report.

Ticket types set price, capacity and visibility. They do not yet decide which doors a code opens, and there are no discount codes.

The buyer’s side

What a guest sees, from the sales page to the entrance.

No account, no app. The sales page speaks the event’s language and asks only for what a ticket needs.

1
The event’s sales page
Ticket types with prices and a short description; “only a few left” when that is true, never the raw count.
2
Name, email, phone
The purchaser’s details and nothing else. The price is not in the form — the server prices the order from its own records.
3
Secure checkout
Payment happens with the payment provider, on their page. Winglark never handles the card.
4
Confirmation
An order page that says what is known — held, payment submitted, paid — and an email with the tickets once the order is fulfilled.
5
The entry code
A personal code per ticket, opened from the confirmation. It carries no name, email or order — an opaque token, nothing more.
6
Arrival
Shown on a phone or on paper. One scan, one answer.

The sales page and the checkout exist only for an event that has been activated. Nothing on this page sells anything.

With the door

The checkout resolves the commercial state. The door resolves the admission state.

Two questions, answered at two different times by two different parts of the same system — and never confused.

Before arrival: Was this place paid for? Answered by the checkout. A paid, fulfilled order becomes a guest record and an entry code; nothing else does.
At the door: Is this code valid, and has it been used? Answered by the scan, online or offline, against the code itself — the same rule for a buyer and for an invited guest.

The two meet in one place: the code. It exists only because the order was paid, and it is revoked the moment a refund goes through — so the door never has to know what a ticket is.

The door does not re-check payment at scan time, and it does not need to. A code that reaches the door is one the checkout already settled.

One lifecycle

Not a sixth tool. The sixth step of the same event.

The list is cleaned, the invitations designed and sent, the late names added, the door run, and — where the event asks for it — the places paid for. One guest record carries all of it.

What you can read

Operational truth, per event and per order.

What is shown is what was recorded when it happened — snapshots on each order, not a recalculation. Financial reconciliation and payouts are handled with our team; the screens below are the operational view.

Sales per event: Orders, tickets, gross amount, by ticket type and by day.
Order state: Held, awaiting payment, paid, fulfilled, cancelled, expired, refunded — and the refund state beside it, not mixed into it.
Ticket state: Issued, checked in, revoked, cancelled, refunded, per ticket, with when the door scanned it.
Finance by period: Gross, Winglark’s commission and your proceeds for a range, from the figures snapshotted on each order.
Exceptions: An order paid and not fulfilled, a refund the provider has not confirmed — listed with what to do, not hidden in a total.

What is included

Ticket types with real limits: Price, capacity, per-order minimum and maximum, a sales window and a visibility, per type.
A sales page per event: Public, unlisted or private, in the event’s language, with the refund policy stated on it.
Held places and honest counts: A place is held for fifteen minutes while the buyer pays, then released. “Sold out” is a fact, not a guess.
Hosted, provider-side payment: Cards are handled by the payment provider on its own page. The server sets the price; the browser cannot.
A guest and an entry code per ticket: Fulfilment writes an ordinary guest record with an ordinary code, so the door and the report need nothing new.
Confirmations through the same sending: Ticket issued, resend, refund, event cancelled — each recorded like an invitation, and never sent to an address that said no.
Full refunds that revoke: The money goes back first, through the provider; the tickets are revoked only when it has.
Orders, tickets, finance: Payment, fulfilment and refund states as separate columns; issued and checked-in tickets; gross, commission and proceeds by period.

Why it matters

What changes on the day

No money at the entrance
Every paid place was paid before the night. The door carries a phone, not a cash box.
One list, not two
Buyers and invited guests arrive on the same screen and are counted in the same report.
A refund is a refused code
When the money goes back, the door already knows. Nobody has to remember a name.

Where it is used

Where it earns its place

01
A conference with paid and invited seats
Speakers and press invited, delegates buying — one list, one door, one count.
02
A workshop with limited places
Twenty seats, a price, a sales window, and the sales page closing itself at twenty.
03
An agency running a client’s paid event
Ticketing inside the client’s own workspace, with the same roles and the same separation as everything else.

Corporate events with a paid track
Private dinners and members’ evenings
Professional gatherings and networking evenings
Limited-capacity experiences and openings

Managed activation

Configured with you, before it goes live.

Ticketing is switched on for a workspace by Winglark, not by a button — because the set-up depends on things a form cannot know about your event.

The event: What is sold, to whom, and whether some guests are invited rather than charged.
Currency and pricing: One currency per event, chosen with you, and the ticket types priced in it.
The commercial model: Winglark’s commission and how your proceeds are settled are agreed before the first sale, not discovered after it.
The refund policy: Refundable, refundable until a date, non-refundable, or on your approval — stated on the sales page.
Payment set-up: The payment provider is switched on for your workspace and tested with you before a real buyer meets it.

How activation runs

1
Tell us about the event
What is sold, when sales should open, how many places, which currency.
2
We define the payment structure
Ticket types, prices, refund policy, commission and settlement, written down.
3
Ticketing is configured
On your event, in your workspace, with the sales page visible only to whom you choose.
4
You review and test
A test order end to end: sales page, checkout, confirmation, code, scan.
5
It goes live
Sales open on the date you set. The same screens run the night.

This is a service layer, not a waiting list. Availability and commercial terms are confirmed during activation.

Talk to Sales

Questions

Can I activate ticketing myself?

No. Ticketing is switched on for your workspace by the Winglark team after a short conversation about the event, the currency and the commercial model. Contact Sales from this page and we set it up with you.

Why does activation require Winglark?

Because the set-up is commercial as well as technical: currency, pricing, refund policy, commission and settlement have to be agreed before the first sale. Doing that with you, once, is faster than a form that guesses.

Does ticketing work with the door?

Yes. A paid ticket is fulfilled as an ordinary guest record with an ordinary entry code, so the door scans it like any invitation — online or offline. A refunded ticket is revoked, and the door refuses it.

Can some guests be complimentary?

Yes, two ways: a ticket type priced at zero goes through the sales page without a payment step, or the guest is simply invited and never sees a checkout. Both end on the same list.

When does the guest pay?

At the checkout, on the event’s sales page, before the event. Their places are held for fifteen minutes while they pay; the confirmation and the entry code follow once the order is paid and fulfilled.

Does Winglark handle refunds?

Full-order refunds, yes: the money is returned through the payment provider and the tickets are revoked once it has been. Partial refunds are not offered.

Which currencies and payment methods are supported?

One currency per event, from those the payment provider supports — confirmed during activation. Cards are handled by the provider on its own hosted checkout; Winglark never sees card details.

Can agencies use it?

Yes. Ticketing runs inside a client’s workspace with the same roles and the same separation as the rest of Winglark, and each client’s sales stay in that client’s workspace.

Is ticketing included in my plan?

It is not a line on a plan. Availability and commercial terms — commission, settlement, the plans it runs alongside — are confirmed during activation.

Planning a paid event?

Talk to Winglark before activating ticketing, so the payment and attendance model is configured for your event — not guessed.

Talk to Sales See the door

This is a service layer, not a waiting list. Availability and commercial terms are confirmed during activation.

Collect before the door.

Money at the door is a queue, a spreadsheet and an argument.

From the event to the attendance record, in one line.

How it works, once it is switched on

Ticketing is opened on the event

Define the ticket types

Open sales

Orders arrive

Refund when you must