Home / Company / Engineering
Engineering
Bristol Pay has been in payments since 2005. The code, the connectors and the releases are ours — not a licensed platform with our name on it. This page is what that looks like in practice.
Twenty years in payments and transaction processing — card and ACH, in person, online and over the phone, across POS, terminal, mobile and web, with the standards each of those carries.
The acceptance, authorization and settlement paths a business actually depends on, and the reporting that has to reconcile against them.
Connectors into the systems a business already runs on, so payment data lands where the work is rather than in a second place to check.
Customer-facing and internal, built to behave the same on a phone as on a desk.
Deployment, monitoring and the unglamorous work that decides whether a release is a routine Tuesday or an incident.
The numbers an operator needs to run the business, surfaced where a decision gets made instead of in an export.
Systems that have outlived their original design and cannot simply be switched off. Migrated in steps, with the business still running.
Print and sign is where we go deepest, because that is where our own product lives. Beyond it: construction, healthcare, professional services and hospitality.
Payment software fails expensively. A defect is not a bad user experience — it is somebody's money.
So testing is a discipline here rather than a phase at the end. Automated where coverage earns its keep, manual where it does not, and run against every release rather than the ones that feel risky.
Functional and regression
Risk-based and exploratory
Unit testing in continuous integration
Load, stress and performance
API and integration
Security testing
Cross-browser and cross-device
Acceptance, installation and configuration
Chosen to last the life of the system, not to be fashionable on the day it started.
Java, .NET, Python and Node. React, Angular and Vue. Azure. Front-end, back-end, DevOps, QA and design — staffed to what a piece of work actually needs rather than to whoever was free that week.
The expensive mistakes in software get made before the first commit, not after. So work starts with discovery and business analysis — understanding how a business actually operates, including the parts that only make sense once someone explains them.
Then build, deploy and maintain, agile, with the same people across the whole arc. Nobody hands your system to a team that has never seen it.
FIRST
What the business does, and what the software has to not break.
THEN
In increments you can see, tested before they ship.
AFTER
Same team. A change is a release, not a renegotiation.
We will tell you plainly whether we are the right fit — including when we are not.
