No Regrets case study
The mistake that cost more than it saved
Chapter 3 of the No Regrets case study: what happens when payment processing gets chosen on fees alone, and what fixed it.
The mistake
In the early stages of runningdigital operations for the group, we tried to save money on payment processor fees. In the end, that decision cost far more than it saved.
It's worth highlighting this mistake because it's easy to make, even with best intentions. Processor fees are one of the few website costs that scale directly with revenue, so they are visible and easy to compare. Therefore, on paper, it makes sense to go with the cheaper rate. However, what that comparison leaves out is everything the cheaper option fails to do well. And sadly, these things only become obvious when they're already costing the business in other ways.
What it looked like
The first thing that became apparent was how outdated the card terminals were - they looked like old brick mobile handsets. Not quite the impression a premium studio wants to present after someone has spent several hours in the chair for a piece with a luxury price tag. A studio can get everything else right - the work, the consultation, the atmosphere - but if the customer's last impression is a device that looks like it belongs in a drawer from fifteen years ago, that is going to be the lasting memory.
The second thing was a poorly built WordPress plugin which handled online and deposit payments, and it was never reliable. Payments would occasionally fail without a clear reason, which meant staff time spent chasing what should have been a completed transaction. In some cases, customers would simply give up and never even rebook the deposit. On top of that, it could not support Apple Pay or Google Pay - a necessity given how most bookings and enquiries are made from mobiles.
Plug-ins such as this also become a maintenance liability, due to the fact they sit outside of the core system. This means an update elsewhere can cause them to break without warning, and the person who built it is not necessarily the person who still supports it years later. It goes without saying that a watertight payment infrastructure is critical, since it's the one part of the site dealing with the customer's money.
What it cost
The financial burden of having to pay maintenance for a system that needed constant attention, instead of running efficiently in the background as it should, was the first thing. Second was the damage that was caused to the brand at the exact moment a customer was forming their opinion of the studio - at the counter, with cash already spent on their time and their design. Then there was revenue lost every time a payment simply failed to go through, whether that meant a deposit never landing or a customer walking away from an online booking instead of persevering with a broken checkout.
The deposit failures were the more expensive of the two. A failed in-person card payment gets noticed and retried on the spot. A failed online deposit, taken while a customer is filling in a form at home instead of standing at a counter, often just ends the booking right there, before anyone at the studio was aware an enquiry had reached the point of booking.
The fix
We moved payment processing to Stripe. The extra fees were minimal in comparison to the grief the old setup had caused. Also, the switch brought reliable Apple Pay and Google Pay support along with it, removing a critical source of friction from the customer journey.
It also freed up staff time that had been going on chasing failed payments manually, by either phoning customers back to try a deposit again or reconciling a transaction that had partially gone through. That time then went back into the follow-up and confirmation work covered in theCRM and automation chapter, which is a reasonable outcome for a fix that started as a payments decision and ended up improving the business's reliability in collecting deposits.
How deposits get handled badly across the industry
The processor is one aspect, but how deposits are handled more broadly is where most studios lose money without noticing. This is evident in a few consistent patterns, most of which have nothing to do with the technology itself, and more to do with policy and timing.
Deposits taken by bank transfer or cash leave no record tied to the booking. This means that, if a dispute arises, there is nothing to point back to - and the conversation starts from scratch again. No written policy has the same effect from a different angle. Without agreed terms in writing, every disagreement over a no-show or a cancellation becomes a fresh negotiation rather than something both sides have pre-agreed to. A fixed deposit, regardless of session length, is another risk - because it under-protects the studio from its longest, most valuable bookings. And terms that only surface after the customer has already committed tend to arrive too late to do their job, since the point of stating a policy clearly is to shape the decision, not to justify it afterwards.
Instead, a deposit taken at the point of consultation, while the customer is most keen, did the majority of the work - especially when it sat alongside the automated confirmation reminders covered in the previous chapter. Both are part of the same coherentCRM system, not separate fixes, which is why they had to be designed together, not solved one at a time.
