Hi,
we recently ran a series of events whereby customers could choose to pay a deposit up front. The current implementation of deposits is less than perfect.
Some major problems...
1) No way to complete the payment
2) Very difficult to know what a customer has paid based on the export of registrants from the back end. Nightmare for accounting.
Possible Solutions
1) Ideally, the administrator could send filtered customers (e.g. all customers with an outstanding balance) an email with a personalised link to complete the payment. This link should load up the event registration page, populated with the customer details, and showing the remainder to be paid, and allow the customer to pay with the normal payment options.
2) The registrants report currently has 2 fields which indicate what somebody has paid...
Payment Status: Paid / Pending
Deposit Amount: used to show that somebody has chosen to pay a deposit.
But with a deposit transaction, which shows Paid, then what exactly has been paid? The Deposit or the Total? How we manage it is by changing the Payment Status in the back end from Partial Payment to Full Payment. Unfortunately, the exported report doesn't differenciate between fully paid and only deposit paid.
This back end payment status is tied to the "Payment Status" column in the mySQL DB. 1 = Full Payment, 0 = Partial Payment
To decipher what has actually been paid, the Payment Status column needs to be referenced from the mySQL database.
Meanings:
Paid and 1 = Fully Paid (Whether transaction had a deposit or not)
Paid and 0 = Deposit only paid (Back end not yet changed from Partial to Full payment)
Pending = No payment made at all.
Could you please include a Due column to the registrants report which says how much exactly is currently due, using the info given above? The date of the completion payment should also be logged for accounting purposes.
Some other limitations which we encountered, but which are less important...
1) We need to be able to collect group information and use the shopping cart
2) A lot of our customers have paid a deposit, and forgotten to enter a sibling discount code. Event Booking offers no mechanism for retrospectively applying the discount code via the back end.
3) Discounts are confusing, and are costing us a lot of money. We offer a €10 sibling discount for the first sibling. We also offer two events for different age groups. If a customers speaks with us and tells us that they have a Junior and a Senior that they would like to book in, they need to complete 2 transactions and so we give them a voucher code for €10. If they then incorrectly book both kids into the Senior event, they get a €10 discount for both members, for a total of €20 (even if the voucher is configured as single use only). This has cost us a lot of money, and the coupons should have 1 more parameter - Apply Per User or Per Transaction?
4) It is currently impossible through the back end to move or cancel 1 member of a group, without moving or cancelling the whole group.
Your feedback on the above points would be greatly appreciated.
Regards,
D
