A senior-only engineering team that designs, builds and operates payment gateways end to end — architecture, acquirer integrations, ledger, reconciliation and the risk layer around them.
Annual volume processed by systems we have built
Uptime across the platforms we operate
Clients whose payment systems we have built or operate
Average engineering experience in the team
We work where a mistake costs real money: gateways, rails, ledgers and the compliance perimeter around them. Every discipline below sits in our own team.
Card-present and card-not-present flows, tokenisation, vaulting, smart routing, retries and idempotency. Built to stay correct when the acquirer is having a bad night.
ISO 8583, ISO 20022, REST and everything undocumented in between. New rails, legacy rails, and the behaviour the specification forgot to mention.
Double-entry ledgers, settlement files, payout flows and dispute handling. Numbers that reconcile on their own, without a spreadsheet and a long evening.
Scoring pipelines, velocity rules, SCA exemption logic and audit trails. Compliance implemented as code and evidence, not as a document nobody reads.
An outside read on a system you already own: bottlenecks, failure modes, security posture and the honest cost of the next twelve months.
Infrastructure as code, zero-downtime deploys, observability and incident response. We stay on the systems we build.
Every phase ends in something you can open and check — a document, a diagram, a running branch. None of them ends in a status call.
Flows, rails, volumes, and where the regulatory perimeter actually falls. On existing platforms this usually changes what the project turns out to be.
Data model, sequence diagrams, threat model, failure modes. Reviewed with your engineers — the people who will be paged, not the people who sign.
Two-week increments in your repository, on your CI. Every slice is deployable. None of them is a demo built to survive one meeting.
Deploy, monitor, take the pager. Or hand over — runbooks, diagrams and known weak points, documented well enough that you never call us back.
A card authorisation is not one request. It is seven, in sequence, and each has its own way of failing.
On the right is a representative budget for a single card-not-present authorisation through a European acquirer. Six of the seven steps are ours to control. The sixth is not — that is the round trip out to the acquirer, on through the scheme, to the issuing bank and back.
That asymmetry is the entire job. You cannot make the network faster, so everything on your side of it has to be quick enough that the network is the only thing anyone is waiting for — and careful enough that when the network misbehaves, nothing is double-charged, lost, or silently dropped.
Every figure here is a budget rather than a measurement: a threshold that fails the build when it is exceeded.
Send the shape of the problem — rails, volumes, deadline, and the part that worries you. You will get an engineer's reply, not a sales sequence.
or write directly — business@firelake-dev.com
Both, but we prefer to deliver as a team. A payment system fails at the seams between components, and a team that owns the whole picture finds those seams before production does.
Yes. We design with scope reduction in mind — tokenisation, isolation of the cardholder data environment, and clear boundaries so the audit surface stays as small as the business allows.
You do, from the first commit. We work in your repository where possible and hand over everything — infrastructure definitions, runbooks, documentation — as a matter of course, not as a negotiation.
It starts with a short, paid discovery: we look at what exists, agree the target architecture and put a real number on the work. From there it is either a fixed scope or a dedicated team, whichever fits the risk profile.
Often that is exactly what we are asked to do. The first fortnight goes to reading the code and the incident history rather than writing anything — a rescue that opens with a rewrite proposal is usually just a second failure being scheduled. Sometimes the honest answer is that the system is fine and the problem is somewhere else; we would rather say so early than bill for discovering it late.