Payment analysis

How much work did we put in to handling orders? What did we pay in fees?

Payment method split

Payment methodOrders
PayPal1206
BankTransfer1019
None332
Cash219
Card183
Cheque4

PayPal

1198 orders were paid for via PayPal. These orders are processed automatically & require no input from admin staff apart from:

3 orders required administrator attention due to payment coming through after the due date.

2 orders failed to automatically process due to what looks like corrupt data in the IPN received from PayPal.

1 payment was received for an order that was cancelled in error.

4 orders had other notes relating to payment issues but not actually problems eg. transfer of funds from cancelled BJC, receipt of first instalment of 2 part ticket etc.

This low level of work is good but costs the EJC in payment processing fees.

I don't know the details of the EJA accounts (which country the EJA PayPal account is registered to, if we used separate accounts for EUR/GBP payments etc.) so the following is guesswork. The following figures are undoubtedly wrong but are sufficient to make my point. The following table shows the estimated cost of processing fees for Euro payments. Fees taken from https://www.paypal.com/nl/webapps/mpp/paypal-fees. Total fees = (value * % rate) + (transactions * flat rate)

Reg phaseMonthCurrencyValueTransactions% rateFlat rateTotal fees
12018-11EUR208501052.30.35479.90
12018-12EUR650703331.90.351236.68
22019-01EUR47543.40.3516.50
22019-02EUR15265762.30.35351.445
22019-03EUR309901402.30.35713.12
32019-04EUR8055382.90.35233.945
32019-05EUR20070862.30.35461.96
42019-06EUR12730542.30.35293.14
42019-07EUR10385412.30.35239.205
52019-08EUR124573.40.3542.68
Total4068.575

Same again for GBP. Fees taken from https://www.paypal.com/uk/webapps/mpp/paypal-fees

Reg phaseMonthCurrencyValueTransactions% rateFlat rateTotal fees
12018-11GBP12905772.40.2309.92
12018-12GBP14840872.40.2356.36
22019-01GBP25023.40.28.70
22019-02GBP5055212.90.2146.795
22019-03GBP8360452.40.2200.84
32019-04GBP137073.40.246.78
32019-05GBP6175352.40.2148.40
42019-06GBP3925152.90.2114.025
42019-07GBP4325262.90.2125.625
52019-08GBP180092.90.252.40
Total1509.845

If we only offered two shorter registration phases confining transactions into 1 month (ie. opening on the 1st closing 3 weeks later which gives a 1 week buffer in case there are any problems), I believe we would still see the same orders but would benefit from lower fees. For example reworking the sales figures from above so that phase 1 was confined to 1 month & phases 2 to 5 were in another, the fees are reduced as follows:

Reg phaseMonthCurrencyValueTransactions% rateFlat rateTotal fees
12018-12EUR859204381.90.351632.83
22019-07EUR992154461.90.351885.435
Total3518.265
Saving550.31
Reg phaseMonthCurrencyValueTransactions% rateFlat rateTotal fees
12018-12GBP277451641.90.2527.355
22019-07GBP312601601.90.2594.14
Total1121.495
Saving388.35

Festivals should plan on paying the higher fees & take any reduction in fees as a nice bonus.

The obvious fear is that if we restrict the time users can place orders we will restrict the number of people who register before the event. See Orders placed by date for evidence that jugglers can be trained to place orders at specific times. However, I believe it is true that customers expect to buy online whenever they want. One way around this would be to set up a registration timeline that only restricts card payments but allows other payment methods at any time. eg:

Phase 1: Reduced rate 6 months before festival for 1 month. Accept card, bank transfer
Phase 2: Reduced rate. Accept bank transfer only
Phase 3: Standard rate 3 months before festival for 1 month. Accept card, bank transfer
Phase 4: Standard rate until start of festival. Accept bank transfer only

At no point is the customer stopped from placing an order, but they are nudged into either paying by card when it most benefits the festival or using a less costly payment method.

Bank transfers

1019 orders were paid for by bank transfer.

644 orders were processed without issue.

270 orders were processed but administrator took time to manually record information that is recorded automatically.

31 orders were processed but the administrator recorded the name on the account where it differed from the name given by the purchaser. Do we even need this information?

16 orders required extra attention due to code errors (currency & anonymisation issues, both now fixed).

6 customers transferred the wrong amount.

10 customers did not supply the requested reference number, or supplied an incorrect reference number.

42 orders had other notes relating to payment issues but not software problems.

The following table details how many orders were confirmed within a certain number of days. This is measured from the time the order was created to the time it was marked as confirmed. The time the customer made payment between those two times is unknown.

DaysOrders
075 
125 
237 
357 
460 
5116 
6102 
7112 
883 
944 
1045 
1121 
1221 
1327 
1419 
1522 
1624 
1723 
1816 
1913 
2010 
219 
224 
233 
243 
251 
262 
278 
284 
293 
323 
333 
344 
353 
361 
371 
385 
392 
401 
451 
462 
472 
482 
513 
543 
561 
571 
581 
592 
601 
631 
652 
662 
671 
691 
702 
711 
741 
951 
1001 
1013 
1026 
1034 
1161 
1411 
1421 
1531 
2231 
2431 

Receiving payments by bank transfer means considerable savings on payment processing fees but at the expense of increasing the amount of work required to verify those payments. To encourage more people to pay by bank transfer we need to reduce the amount of work required to verify payments & therefore the time it takes to confirm payment.

Complete: A lot of bank accounts allow you to download transactions to a file. I want to add the ability to upload these files to the ERS which will then scan the files looking for payments from customers & automatically verify orders where the reference & payment value match & create a report of all discrepancies. This will require organisers to provide example files for me to work from.

No payment required

311 orders required no payment (supplier/volunteer tickets only).

155 orders required no input from admins.

121 orders were created by admins on behalf of the customer.

35 orders were created by customers but amended by admins later.

640 free or reduced price tickets issued. That is 1 in 6 of all people who were checked into the festival or 2/3rds of a BJC worth of people. I am surprised by how high this number is.

Nothing I can do about the number of free tickets issued which will always be down to the type of festival/organisers. Reducing the amount of processing by administrators will be dictated by whatever I can come up with to help improve handling of order lines.

I'm guessing the split between orders created by administrators versus those that weren't would be between contractors from outside the community vs volunteers from within the community? In which case if suppliers can supply names of their workers via email & organisers use a webmail service (Gmail seems to be the norm these days) then a bookmarklet that allows you to create new orders by selecting the name & email address from the email would speed things up.

Complete: Discount code system now in place supporting free tickets, percentage and fixed amount discounts.

Cash/card payments on site

See on site processing.

Cheque

4 orders were paid for by cheque. No recorded issues.