Untangling payment problems in a festival ticket shop

In June and July 2026 a festival’s ticket shop was losing payments and data. It was a live WooCommerce store built by other developers. Buyers who chose direct debit ended up in PayPal, some orders arrived without the customer’s address, and the quick PayPal button charged the ticket price without the booking fee.

I looked into direct debit on a local restore of a backup and left the live shop untouched. The PayPal plugin itself offered direct debit and had no switch for it. After the client decided, I turned it off with a small filter in the child theme and checked it on the live checkout.

For the missing addresses I went through every order in the shop. Both affected orders had gone through one particular PayPal checkout path, and the error log showed where it failed. I proposed a workaround and explained why a plugin update would not help.

The shop’s own emails were failing the SPF check. The domain allowed only Microsoft 365 to send mail, while the shop sent through the host. I found it from one bounced order email and gave the agency two ways to fix it.

The booking fee went missing because the quick PayPal button sent PayPal a different amount than the order, which was calculated correctly. The agency decided to switch those buttons off, so every order goes through the normal checkout, and I wrote down the steps to switch them back. I also changed the PDF invoice layout to match the client’s marked-up example.

Until the client decided, I only looked at the live shop, and each fix was the smallest change that solved the problem. Direct debit no longer sends buyers to PayPal, every order carries the booking fee, and the client has the cause of each problem written down.