Events Setup • Payments

Created 15 September 2026 • Updated 15 September 2026• Updates

How Payments & Refunds Work

Zonal Bookings can take money from your guests at several points in a booking, and give it back when plans change. This page explains what each payment type does, how refunds are processed, how payments and refunds reach your till, and where the current limits are.

To connect or change a payment provider, see Payments.

Ways a guest can pay

What a guest is asked to pay, and when, comes from the booking rule that applies to their booking. Only one booking rule ever applies to a booking, so payment requirements do not stack.

Payment type	Description
Deposit	An upfront amount, charged per guest or per booking. If a required deposit is not paid within ten minutes of the booking being created, the booking is cancelled automatically.
Pre-payment	Payment for pre-ordered food, always used alongside pre-order. The amount due is the pre-order total less any deposit already paid.
Requested payment	An ad-hoc amount a host asks for after the booking is made, which the guest pays through the Guest Portal. The guest must pay the exact amount requested, and only one request can be open on a booking at a time.
Card guarantee	No money is taken when the booking is made. The guest’s card is held against the booking so a charge can be made later, for example after a no-show. Cannot be combined with a deposit or pre-payment.
Extras	Payment for add-ons chosen with the booking, such as drinks packages or party items.
Manual payment	A payment taken outside Events — BACS, voucher, cash, credit/debit card or other — logged against the booking by a host so balances and till figures stay correct. See Logging a payment taken outside Events.
Till payment	A deposit taken on the till against an Aztec booking. Where your sites are set up to sync bookings from Aztec into Events, the deposit appears on the Events booking as a payment and can be refunded from Events afterwards.
API payment	A payment taken in one of your own systems and recorded against the booking through the Events API. See Payments recorded through the API.

Card payments are processed by one payment provider per estate — Braintree, WorldPay or FreedomPay. Card details are never held by Zonal Bookings.

Logging a payment taken outside Events

When money has already been taken somewhere else — a bank transfer, cash at the venue, a gift voucher — a host can log it against the booking so the balance, the booking status and your till figures all stay correct. Events records the payment; it does not take it.

Manual payments are switched off until someone turns them on, and can be set separately for your estate, each brand and each site. When the setting is off, the option to log a payment simply does not appear.

Logging one

Open the booking, go to its payments, and select Log a Manual Payment. You are asked for:

Payment type — BACS, Voucher, Cash, Credit/Debit Card or Other.
Payment value — pre-filled with the amount still outstanding. It cannot be more than that.
Payment date — today by default, and can be back-dated to when the money actually arrived.
Reference number — required. Up to 18 characters for BACS, or 25 for the other types.
Comments — optional, for anything the next person needs to know.

The option to log a payment appears only while something is still outstanding on the booking, and only up to the booking date. It is not offered on enquiries or on cancelled bookings.

What happens once it is logged

It counts towards the booking’s paid total exactly like a card payment, and can confirm the booking if it settles the deposit.
It is sent to the till under the pay type mapped to that payment method. Those mappings are set in Payments → Payment IDs, and should match the pay types in Aztec.
It is written to the booking’s audit history as Manual Payment Logged, with the type, amount, reference and comments.
On the payments list it shows the payment method and a Payment ID rather than the reference you typed — your reference is kept in the audit history.

A manual payment can be refunded like any other: the booking is updated, the guest is notified and the deposit is cleared from the till. But because Events never held the money, returning it to the guest is down to you. See Refunding a payment.

Overpayments and allocating funds

Sometimes a booking holds more money than it needs. The surplus is shown as Other in the booking’s payment breakdown, and the day diary and bookings list show a total-paid-against-total-required marker so it can be spotted at a glance.

This usually happens because:

more was paid than the booking required;
the requirements shrank after payment — covers were reduced, or a deposit is no longer needed;
money was taken before there was anything to put it against, for example before a pre-order was chosen.

Allocating the surplus

Allocating moves money out of Other and puts it against something the booking actually owes. Open the booking’s payments and select Allocate Payments.

Events decides what the money pays for, and works in a fixed order: the deposit first, then pre-payment, then extras. An outstanding deposit has to be cleared before anything can go towards pre-payment, and both before extras.
Funds can be put against the booking as a whole or against an individual guest. Extras can only be paid at booking level.
Allocating enough to cover the deposit confirms the booking. Removing it again can return the booking to provisional.
Surplus cannot be put towards a requested payment — the guest needs to pay that in the usual way.

Allocating funds is switched off until someone turns it on, and can be set separately for your estate, each brand and each site. With the setting off, hosts can still see that a booking is overpaid but cannot move the money.

Existing money is never applied to a new requirement on its own. If a deposit is added to a booking that already holds a surplus, the booking will show both the surplus and an unpaid deposit until someone allocates it.

Removing an allocation

Each allocation appears as its own entry in the booking’s payments, showing what it was put against and when. Select Deallocate and confirm, and the money goes back into Other, ready to be used elsewhere.

Allocations come off in the reverse order to the way they went on: extras first, then pre-payment, then the deposit.

Allocated funds have to be released before the payment can be refunded. While an allocation is still in place the refund option is not offered, and the payments list shows Deallocate manual allocations prior to refund. Remove the allocations first, then refund the payment.

If allocating funds is switched off for a site that already has allocations in place, those allocations can no longer be removed — which also means the payments behind them cannot be refunded from the Host app. Worth checking a site has nothing outstanding before turning the setting off.

Refunding a payment

Refunds are made by your team in the Events Host application. Open the booking, go to its payments, and select Refund against the payment you want to return. Any payment recorded against a booking can be refunded, including deposits, pre-payments, requested payments, extras and manually recorded payments.

Refunds are available unless someone has switched them off, and can be set separately for your estate, each brand and each site. If your team cannot see a Refund option against payments, ask your Account Representative to check this setting.

What to expect

A refund returns the whole payment. Part-refunding a single payment is not currently supported. Where several payments are recorded against a booking, each can be refunded separately.
A payment can only be refunded once.
There is no time limit. A payment can be refunded at any point, including after the event has taken place.
Very recent payments are cancelled rather than refunded. If the payment has not yet settled with the card provider, it is cancelled instead. The guest sees the pending charge disappear rather than a refund arriving, and no money ever leaves their account.
Guests cannot refund themselves. A guest removing a paid attendee in the Guest Portal is asked to contact the venue.

What happens once a refund is made

The payment is marked as refunded and the amount comes off the booking’s paid total.
The booking status is recalculated. A confirmed booking whose deposit has been refunded returns to provisional, because the payment that confirmed it is no longer held.
The guest is emailed to tell them a refund has been made. The host can choose not to notify the guest — useful where the guest has already been dealt with another way.
The refund is written to the booking’s audit history, with the amount, who made it and when.
If the payment was linked to an invoice, that invoice returns to outstanding.

Your estate can be set up to refund card payments automatically whenever a booking is cancelled, so nobody has to remember to do it. This applies however the booking is cancelled, including by the guest in the Guest Portal. Manually recorded payments are never refunded automatically, because the money did not move through Events.

Where a payment has had funds allocated from it, those allocations need releasing before it can be refunded. See Overpayments and allocating funds.

Payments, refunds and your till

Where your sites are integrated with Aztec, deposits taken in Bookings are sent to the till so the deposit sits against the booking and can be redeemed against the guest’s bill on the day.

The guest pays. The payment is taken by your payment provider and recorded against the booking.
The deposit is sent to the till. Bookings sends it to Aztec within seconds, under the pay type mapped for that payment method.
The deposit is used or returned. It is either redeemed against the bill on the day, or refunded from Events.

Deposits taken on the till

Money can travel the other way too. Where your sites are set up to sync bookings from Aztec into Events, a deposit taken on the till arrives on the Events booking as a payment, counts towards the booking’s paid total, and can be refunded from Events later in the same way as a deposit taken online.

Charging a card guarantee

A card guarantee charge is not sent to the till. Charging a stored card takes real money from the guest and is recorded against the Events booking, but no deposit or payment reaches Aztec for it. Anything you need on the till — a no-show charge on the bill, for example — has to be entered there separately.

What happens on the till when you refund

When a payment is refunded in Events, the guest’s money is returned by the payment provider first. Bookings then tells the till to clear the deposit from the booking, so the till is not left holding a deposit that no longer exists.

The guest is always refunded. If the till cannot be updated — because the site is offline, for instance — the refund still stands and the guest still gets their money. The failure is recorded against the booking so it can be picked up.
The original deposit must have reached the till. Where a deposit never made it to Aztec there is nothing on the till to clear, so only the Events record is updated.
Nothing waits for your end of day. Deposits and refunds are sent as they happen rather than batched overnight. Which trading day a deposit or refund falls into is decided by Aztec when it processes it — Bookings does not set a date.

Refunds made on the till are not sent back to Events. If a deposit is refunded or redeemed at the POS, the booking in Events will still show the payment as held. The refund needs recording in Events as well, to keep the two in step — and because the deposit has already gone from the till, that Events refund will not change anything on the till.

Payments recorded through the API

If you take payments in your own systems — a website, an app or a call centre — the Events API lets you record those payments against a booking. This keeps the booking’s balance, its status and your till figures correct without anyone re-keying amounts.

An API payment records a payment; it does not process one. The money is taken by your own payment provider, and Zonal Bookings never handles or holds it.

How they behave

They count like any other payment. An API payment contributes to the booking’s paid total, can confirm the booking, and is sent to the till as a deposit under the pay type you specify.
Each payment carries your own reference. The reference is required and can be up to 50 characters in any format you choose. Sending the same reference twice against a booking is rejected, so a repeated call cannot record the payment twice.
Refunding one only updates the records. Because the money was never taken by Bookings, refunding an API payment marks it as refunded, adjusts the booking, notifies the guest and clears the deposit from the till — but returning the money to the guest stays with you, in whichever system took the payment.

Refunds cannot currently be started or reported through the API, and no notification is sent when a refund is made in Events. If you refund a guest in your own system, the payment also needs refunding in Events; if your team refunds in Events, your own systems are not told.

Current limits

A short summary, so you can plan around them.

A payment is refunded in full, and only once. Refunds are made by your team in the Host application, or automatically on cancellation where that has been switched on.
Refunds and redemptions made on the till are not sent back to Events.
Card guarantee charges are never sent to the till.
Logging manual payments and allocating overpaid funds are both switched off until enabled, and are set per estate, brand and site.
Overpaid funds cannot be put towards a requested payment, and allocated funds must be released before the payment can be refunded.
Refunds cannot be started through the API, and no refund notification is sent to connected systems.
One payment provider is used per estate.
Refunds made directly in your payment provider’s own portal are seen by neither Events nor the till. Refund from Events wherever possible, so the records stay aligned.

Planning a change to how you handle payments or refunds — a new provider, a change to your end of day, or connecting another system? Speak to your Account Representative first, so we can talk it through.