Results at a glance
- Card payments taken on the existing site, with no rebuild
- Lesson fees, donations and event tickets all handled online
- PCI DSS status: passing
- Zero failing vulnerabilities
- TLSv1.3 encryption on all payment pages
- Cloudflare security rules in place
- Quarterly SecurityMetrics scans passing
Background
Musica Kirklees already had a website that worked but they needed it to take secure payments.
Lesson fees and event tickets were being handled outside the site. That is manageable at first and gradually stops being manageable. Every payment that happens somewhere else is a payment somebody has to chase, record and match up by hand. For a ticketed concert it also means the booking and the money live in two different places, and somebody in the office has to keep them in step.
The obvious answer at this point is to move the whole thing onto a platform that comes with a checkout built in. That answer costs you the site you already have. Everything that works has to be rebuilt around somebody else's shop, and the parts that do not fit get dropped. We took the other route and added payments to what was already there.
How we approached it
We integrated the Pay360 API directly into the existing site a few years ago. Pay360 is now part of Access PaySuite, and it handles the card details, which is where they belong. The site handles everything either side of that.
For lessons and donations that meant a straightforward payments page. For ticketed events it meant something more considered, because a ticket sale is a booking as well as a payment. We built the booking flow into the CMS so that the details are captured on the site, the visitor moves through to the card step and back again, and the whole thing holds together as one process. From their point of view they filled in a form and paid for a ticket without ever leaving the site.
That is the part worth dwelling on. Bolting a payment provider onto a site usually shows, and it shows at exactly the moment a customer is deciding whether to trust you with a card. Building it into the CMS instead of alongside it is more work upfront and it is the difference between a checkout that belongs to the site and one that has clearly been borrowed.
What the payment system does
Then the bank got in touch
In August 2025 we received an email from the Finance Director. Their bank had insisted they use a company called SecurityMetrics to assess whether the website was PCI compliant. SecurityMetrics had run a scan and found potential vulnerabilities. The email set out the situation plainly:
Securitymetrics have carried out a scan of our website and say there are some potential vulnerabilities. Apparently a hacker may be able to infiltrate our website, give themselves administrator rights and possibly divert our customers to a criminal site rather than the Access Paysuite one and trick our customers into giving their credit card details.
This is a common sequence and it catches people off guard. A business takes payments through a reputable gateway, everything works, and then the bank points at PCI DSS and asks for evidence. PCI DSS is not optional. If a business cannot demonstrate compliance, the payment provider can withdraw its guarantee against online fraud, which is a commercial problem rather than a technical one.
It also arrives with no warning and no obvious first step. The report lands. It is written for security engineers, and somebody has to work out what it actually means.
What we fixed
It took several attempts to get through. Each failed scan named specific issues and each one had to be closed and retested. We worked through internal patches to the CMS and server configuration, then put Cloudflare security rules in front of the server to block the injection and cross site scripting attacks the scan tests for. All payment pages were confirmed on TLSv1.3 and older encryption versions were disabled so they could not be used as a way in.
The scanning itself is aggressive, which is the part nobody mentions in advance. SecurityMetrics are running controlled attacks against a live hosting environment, so the tests add load and can disrupt the site while they run. That is simply what compliance validation involves, and it is easier to live with when you know it is coming.
Once the fixes were in place, the site passed. PCI DSS compliant, zero failing vulnerabilities, current encryption across the payment pages, and quarterly scans scheduled to keep the status rather than let it lapse.
Security standards met
| Standard | Implementation | Status |
|---|---|---|
| PCI DSS compliance | Quarterly SecurityMetrics validation scans | Passing |
| Vulnerability scanning | Zero failing issues across all tests | Clean |
| Encryption | TLSv1.3 on all payment pages | Current standard |
| DDoS protection | Cloudflare infrastructure | Active |
| Web application firewall | Cloudflare security rules | Active |
Where it is now
The payments and the booking flow are live and have been for years. Lesson fees, donations and event tickets all come through the site, and the site is still theirs rather than a page inside somebody else's platform.
Compliance is now a standing arrangement rather than a one off scramble. Quarterly scans run, scan dates are tracked, and anything raised is dealt with before it becomes a conversation with the payment provider. That is the part that matters when a bank is involved. Passing once proves very little. Continuing to pass is what the relationship depends on.
Does this sound familiar?
This is for anyone whose website is doing its job in every respect except taking money, and who has been told the only way forward is to start again somewhere else. Usually that is not true. If the site is sound, payments can be added to it, and the booking or ordering process around them can be built to suit how the organisation actually works.
It is also for anyone holding a compliance report they did not ask for and do not fully understand. The requirements come from the card schemes and are enforced by your bank, whichever gateway you use. The technical work lands on your website and hosting environment, which is where we come in.
- Payments handled outside the site, then reconciled by hand
- Bookings and payments recorded in two separate places
- Being told a rebuild on a new platform is the only option
- A bank or payment provider asking for evidence of PCI DSS compliance
- A failed scan report and no idea what it is asking for
- A payment step that visibly belongs to somebody else
Worth a Conversation?
If our content sounds familiar or you are looking for alternative ideas to solve duplication and improve communication, give us a call.
No commitment, no sales pitch, just a conversation about whether we are the right people for you.
Please call +44 (0) 3330 066 280 or email [email protected]