You can now take partial payments for events – a deposit – and manage the balance due. There are several changes to support this spread throughout Cameo.

Creating an event with partial payments

When creating a payment plan for the event, select the new ticket type deposit only for the price zone / category combination (Fig 1: 1). This reveals a box for the balance due (Fig 1: 2). Put the amount you want them to pay now as the ticket cost, and the remainder in balance due, which is initially just for their information when they book.

Fig 2: price plan for partial payments

Bookings made with partial payment

In the booking form, the amount they are charged for a place of this kind will take payment for the deposit and just show the amount due. Your confirmation email can also include the balance (see below for templates).

The balance due is stored with the booking, and displayed in the list of bookings in the Reservations section both for the individual places (Fig 2: 1 – they may book more than one, with differing cost and balance) and the total (Fig 2: 2).

Taking further payment

The payment form has an option to say that it is being used to take balance payments for events. When you set this, provide the booking reference number (e.g. 1567 from Fig 2) as the form reference, usually via a personalised link. You can also pass in the amount due using the payment form’s existing amount query parameter and option.

You can try out these query parameters using the simulate query control in the forms → form editor (Fig 3).

Fig 3: simulate query

When a payment form is completed that is set up to take balance payments, the payment is applied to the booking whoise reference is supplied. It does this by deducting the new payment from each place/ticket in turn until either the balance is paid in full or the payment is used up (hopefully, in most cases, the payment will equal the balance due). It also adds an entry to the booking’s More info area in the first column of the booking list. If you open that up you’ll see a record of any additional payment(s) applied (Fig 2: 3).

Requesting payments

When a balances are outstanding you will want to know what these are and request payment (or more formally, send an invoice). That demand/invoice would naturally contain a personalised link to the payment form for them to pay the amount due.

To achieve this, the existing method of communicating with attendees has been slightly extended. To recap briefly, you can use a mailing list to create correspondence with people who have booked for an event. There are two list sources that do this: events assigned and event attendees (Fig 4: 1). The former selects people who have booked for events which have that list selected in the Assigned to lists box, at the very end of the event definition (Fig 4: 3). The latter works the other way around, in that you specify event instances or booking references manually in the list definition.

Either way, however, you can further choose what criteria to use to select among the people who have booked for the identified event(s). To support balance requests, these criteria now include outstanding balance. Choosing that for your list will target it just at people with non-zero balances outstanding (Fig 4: 2).

Having created such a list, you can now use it in three ways:

  • to display those with outstanding balances, using show subscribers, and
  • as the audience of a template to send those people emails and/or letters, which we’ll look at next.
  • as the audience of a template to produce a table of debtors and the amounts.
Fig 4: list of event attendees using ‘outstanding balance’ as a means to select those with payments due

Invoice templates

Finally, then, a template which creates a message requesting payment completes the workflow. You create this in the usual way, with a fallback to a letter template if necessary to send by post. (By the way, recall that these templates target the individual making a booking, not the whole membership record when there is more than one individual: address emails to “Dear {individual: name}”, not “Dear {show: called}”).

Because the merge is generated using a list that references event bookings, just like generating tickets it has access to the ticket substitutions. Along with the already existing {ticket: booking reference}, three additional substitutions support outstanding balances:

  • {ticket: total balance due} which substitutes the total outstanding balance for the booking being merged, for example “£300.00”.
  • {ticket: total amount due} which is similar but excludes the currency symbol (e.g. “300.00”), so it is suitable for including in a link to the payment form, as a query parameter. For example, the payment link might be:
    https://example.com/payment/?amount={ticket: total amount due}&bookingref={ticket: booking reference}
  • {ticket: balance due} which is the amount due for each individual reservation (when you want to itemise these). You would use this in a subordinate template as for producing a set of tickets, using {tickets: template name} – see “Tickets, lanyard badges and attendance lists” in Events: communicating with attendees for how this works.

Attendance spreadsheets

As well as correspondence, you can use the substitutions above, the outstanding balance list source, and tabular letter templates with the Expected List and Attendance List buttons, to generate summary lists of outstanding payments. There are no further changes needed to support this.

However, two additional columns have been added to the CSV equivalents:

  • the email address of the attendee now appears in column D (alongside their name and membership number), and
  • the balance due is shown in column N (for each ticket or reservation when there is more than one for a booking, not the total, because each reservation has its own row).